Sistema de Permissões

A plataforma Mirox controla o acesso através de um modelo de permissões em camadas, baseado em funções, que lhe dá controlo preciso sobre quem pode ver e alterar quais centrais — sem o obrigar a gerir direitos individuais um a um. As funções fazem o agrupamento; a hierarquia faz a herança.

Filosofia de Permissões

O sistema de permissões assenta em alguns princípios que mantêm o acesso ao mesmo tempo seguro e fácil de compreender:

1. Herança Hierárquica — O acesso segue a hierarquia natural de recursos e organizações: conceda uma vez no topo e propaga-se para baixo.
2. Privilégio Mínimo — Cada função detém apenas os direitos de que a sua tarefa realmente necessita.
3. Separação de Responsabilidades — A posição organizacional e o acesso a recursos são dois eixos distintos, pelo que pode dar a alguém uma função organizacional sénior sem expor todas as centrais, e vice-versa.
4. Atribuição Explícita — O acesso é concedido de propósito, nunca presumido.
5. Consciência de Contexto — A mesma pessoa pode ter direitos diferentes em centrais diferentes.

Em conjunto, estes princípios mantêm uma abordagem segura mas flexível à gestão do acesso em toda a plataforma Mirox.

Camadas de Permissão

Um pedido passa por uma sequência de verificações. Cada camada responde a uma questão; todas as camadas relevantes têm de concordar antes de o acesso ser concedido.

Nota: a Camada de API aplica-se apenas a pedidos autenticados com um token de API; as sessões interativas passam diretamente para a Camada de Sistema.

As camadas:

• Camada de API (laranja) — Apenas para pedidos com token de API. Valida o token e aplica o seu grupo de permissão, que só pode alguma vez restringir o que o proprietário do token já poderia fazer.
• Camada de Sistema (vermelho) — A primeira barreira para todos os pedidos. Estabelece a posição ao nível da plataforma (utilizador comum vs. administrador da plataforma) e protege operações críticas do sistema, independentemente de qualquer outra camada.
• Camada de Organização (azul) — Confirma que pertence à organização que possui o recurso e aplica a sua função organizacional.
• Camada de Trabalho (verde) — A verificação mais granular: decide o que pode fazer numa central ou carteira específica.

O diagrama abaixo mostra as combinações comuns. Os dados de toda a organização requerem a verificação da organização; uma única central requer a verificação de trabalho; muitos pedidos requerem ambas.

Camada de Permissão de Sistema

A camada de sistema é a primeira barreira de segurança. Distingue os administradores da plataforma dos utilizadores comuns e protege as operações ao nível de todo o sistema:

• Os administradores da plataforma podem realizar operações ao nível de todo o sistema.
• Os utilizadores comuns não podem realizar ações que afetem a própria plataforma.
• Esta camada não avalia o acesso ao nível de funcionalidades (como a geração de relatórios) — isso acontece mais abaixo.

A integridade do sistema mantém-se protegida mesmo que uma verificação mais granular esteja mal configurada.

Camada de Permissão de Organização

Cada utilizador pertence a exatamente uma organização, que é a porta de acesso aos recursos:

• As organizações possuem recursos (carteiras e parques).
• Recebe o seu acesso de base através da sua função organizacional.
• As organizações podem estabelecer acordos de cooperação para partilhar recursos específicos para além da fronteira da organização.

Esta camada impõe as fronteiras organizacionais: só alcança recursos que a sua organização possui ou que lhe foram concedidos através de uma cooperação.

Camada de Permissão de Recurso (Trabalho)

O nível mais granular controla o que pode fazer numa central ou carteira individual. O acesso aqui é expresso como uma função de trabalho (ver abaixo):

• A sua função organizacional fornece uma função de trabalho predefinida em todos os recursos detidos.
• As organizações podem substituir essa predefinição concedendo-lhe uma função de trabalho específica num recurso específico — mais ampla ou mais restrita do que a sua predefinição.
• Uma concessão direta prevalece sempre sobre a predefinição herdada, pelo que as exceções são fáceis.

Esta camada permite um controlo preciso, por central, sem alterar a função organizacional de ninguém.

Camada de Permissão de Token de API

Uma camada opcional para automação e integrações:

• Os tokens de API são criados por utilizadores para conduzir scripts e sistemas externos.
• Um token nunca pode exceder as permissões do utilizador que o criou — apenas as restringe.
• Um token está vinculado a um grupo de permissão que o limita a uma área de funcionalidades (ver Grupos de Permissão de API).
• Nunca é pedido um segundo fator a um token, e as regras de duração do início de sessão não o terminam. Uma regra: um utilizador sem segundo fator não pode criar um novo token enquanto a sua própria organização exigir autenticação de dois fatores (2FA).

Isto mantém a automação segura ao mesmo tempo que respeita o privilégio mínimo. Para detalhes, consulte a documentação da funcionalidade Tokens de API.

Exigência de Dois Fatores para Além das Funções

As funções decidem a que centrais pode aceder. Uma organização pode acrescentar uma condição: pode exigir autenticação de dois fatores (2FA) para o acesso às suas centrais.

• Uma função concede a central. A exigência decide se ela lhe é mostrada. Se a organização proprietária de uma central exigir 2FA e a sua conta não tiver segundo fator (aplicação de autenticação ou passkey), não vê as centrais dessa organização — seja qual for a função que nelas tenha.
• Nada é retirado. As suas funções e concessões mantêm-se como estão. Continua com sessão iniciada, e um aviso no cabeçalho indica-lhe que ative o 2FA. Assim que o ativa, as centrais voltam a aparecer.
• Decide o proprietário da central. A exigência aplica-se a todos os que acedem à central: os membros da própria organização e os utilizadores de um parceiro de cooperação.

Quem define a exigência e o que fica exatamente oculto está descrito na página Política de Segurança da Organização.

Sistema de Controlo de Acesso Baseado em Funções

A Mirox utiliza Controlo de Acesso Baseado em Funções (RBAC) com funções predefinidas em três eixos: uma função de sistema ao nível da plataforma, uma função organizacional e funções de trabalho por recurso.

Funções de Sistema

As funções de sistema definem a posição ao nível da plataforma:

• Administrador — Pessoal da plataforma com acesso a operações e configuração ao nível de todo o sistema.
• Utilizador — A função padrão para todos os que utilizam a plataforma; sem privilégios administrativos.

Funções de Organização

A sua função organizacional é a sua posição predefinida dentro da sua organização. As duas funções de gestor são o núcleo da atual estrutura de permissões: permitem-lhe delegar responsabilidade sénior sem entregar o controlo total de moderador.

As duas funções de gestor são irmãs — pares sob o Moderador, uma técnica e uma comercial. Esta divisão permite que uma única organização separe de forma clara a propriedade de engenharia da propriedade de contratos e faturação.

Conteúdos partilhados da organização. Administradores, Moderadores e as duas funções de Gestor de ativos criam, duplicam, alteram e eliminam os modelos, capítulos e métricas de relatório da organização, os seus modelos e fórmulas de exportação de dados, e as regras, destinatários, modelos e silenciamentos do Gestor de alertas; os Membros veem-nos e usam-nos. Um elemento marcado como Privado só é alterado pelo seu criador, por um Administrador ou por um Moderador — consulte Relatórios e Gestor de alertas. Os comercializadores diretos ficam reservados a Administradores e Moderadores.

Permissões de Recurso Baseadas em Trabalho

As funções de trabalho definem o que um utilizador pode fazer numa central ou carteira específica, independentemente da sua função organizacional:

Responsável de segurança é atribuído apenas explicitamente. Nenhuma função da organização corresponde a ele, por isso ninguém se torna responsável de segurança ao aderir a uma organização — é concedido deliberadamente, por central ou por carteira, ou partilhado através de uma cooperação.

Cliente também é atribuído apenas explicitamente, e é a única função cuja atribuição pode estreitar uma conta: as atribuições somam-se, pelo que um Membro que recebe uma atribuição de Cliente mantém o acesso de Visualizador do Membro — a vista limitada só tem efeito para um membro Externo ou uma partilha por cooperação. Uma atribuição de Cliente pode ter uma data de validade.

O token entre parênteses é o identificador utilizado em concessões de API e partilhas de cooperação; em toda a interface vê a etiqueta descritiva.

Grupos de Permissão de API

Os tokens de API são atribuídos a exatamente um grupo de permissão que delimita o que o token pode alcançar:

• Acesso Total — As mesmas permissões do utilizador que o cria, dentro do seu âmbito.
• Metric Export — Limitado à leitura da exportação de dados: métricas como séries temporais, modelos de exportação, o catálogo de métricas, informações da central e eventos. Não pode alterar nada.
• Base de Dados de Séries Temporais — Acesso aos endpoints de séries temporais para ler as séries de medição em bruto.

Para casos de uso e exemplos, consulte a documentação da funcionalidade Tokens de API.

Herança de Permissões

O acesso propaga-se para baixo na hierarquia de recursos, pelo que concede em cima e refina em baixo:

Organization
├── Organization Role (your default standing)
│
├── Portfolio 1
│   ├── Inherits organization-level access
│   ├── Portfolio-specific grants (optional)
│   │
│   ├── Park A
│   │   ├── Inherits portfolio access
│   │   └── Park-specific grants (optional)
│   │
│   └── Park B
│       ├── Inherits portfolio access
│       └── Park-specific grants (optional)
│
└── Portfolio 2
    └── Park C
        └── Inherits portfolio access

Este modelo de herança significa que:

1. O acesso a partir da sua função organizacional aplica-se a todas as carteiras e parques que a sua organização possui.
2. Uma concessão ao nível da carteira aplica-se a todos os parques dessa carteira.
3. Uma concessão num único parque refina o acesso apenas a esse parque, substituindo a predefinição herdada.

Mapeamento de Função de Organização para Função de Trabalho

Quando acede a um recurso, a sua função organizacional determina automaticamente a sua função de trabalho predefinida:

Esta separação mantém as permissões de recurso (funções de trabalho) distintas da posição organizacional. A sua função organizacional define a predefinição, mas concessões explícitas por recurso podem elevá-la ou reduzi-la para qualquer central individual.

Cooperação entre Organizações

As organizações podem estabelecer acordos de cooperação para partilhar recursos específicos para além da fronteira da organização:

1. Duas organizações formam uma cooperação formal.
2. A organização proprietária do recurso concede acesso específico utilizando funções de trabalho.
3. Aquilo que é partilhado ao nível da cooperação limita o que a organização recetora pode depois delegar nos seus próprios membros.
4. Todo o acesso permanece auditável e pode ser revogado pelo proprietário do recurso a qualquer momento.

Se a organização proprietária de uma central partilhada exigir 2FA, isto aplica-se também ao Administrador recetor e a todos os membros com delegação — consulte Exigência de Dois Fatores para Além das Funções.

Para as regras completas sobre como o acesso partilhado é delimitado e delegado, consulte Restrições de Cooperação.

Boas Práticas

Para uma gestão eficaz de permissões na Mirox:

1. Utilize as Funções Padrão — As funções organizacionais e de trabalho predefinidas cobrem a grande maioria das situações reais.
2. Adeque o Gestor à Responsabilidade — Utilize a função Asset Manager (Technical) para a propriedade de engenharia e a função Asset Manager (Commercial) para a propriedade de contratos e faturação.
3. Atribua ao Nível Adequado Mais Elevado — Conceda ao nível da organização ou da carteira quando o acesso deva aplicar-se amplamente; refine ao nível do parque apenas para exceções genuínas.
4. Reveja Regularmente — Audite periodicamente as funções dos membros e as concessões por recurso, e defina datas de expiração para acessos com limite de tempo.
5. Verifique o Acesso — Confirme uma configuração verificando o que um determinado membro consegue realmente alcançar antes de confiar nela.

Exemplos Práticos

Gestão de Múltiplos Locais

Uma organização que gere vários parques solares poderá configurar:

• Um responsável de operações como Administrador, com controlo total da organização.
• Um responsável de engenharia como Asset Manager (Technical), tratando do estado dos componentes, eventos e tickets em todas as centrais.
• Um responsável financeiro como Asset Manager (Commercial), gerindo contratos, faturação e tarifas sem qualquer acesso remoto às redes das centrais.

Acesso de Prestadores de Serviços

Um prestador de serviços de manutenção convidado do exterior poderá receber:

• Uma função organizacional Externo com uma função de trabalho Gestor Técnico ou Visualizador nos parques específicos que assiste.
• Uma concessão por recurso limitada apenas a essas centrais.
• Uma data de expiração para que o acesso termine automaticamente quando o serviço terminar.

Visibilidade para Investidores

Aos investidores pode ser dado:

• Uma função organizacional Membro ou Externo com uma função de trabalho Visualizador em carteiras específicas.
• Acesso de leitura aos dados de desempenho e de relatórios, sem capacidades de gestão.

Funcionalidades Relacionadas

• Restrições de Cooperação — como o acesso partilhado é delimitado entre organizações cooperantes
• Política de Segurança da Organização — a exigência de 2FA e as regras de início de sessão que uma organização define
• Cooperações — partilha de centrais e carteiras para além da fronteira da organização
• Convites — convidar membros e atribuir a sua função organizacional
• Tokens de API — tokens delimitados para automação e integrações
• Registo de Auditoria — quem acedeu a quais dispositivos de central e quando
• Tickets — a camada humana de gestão de trabalho controlada pela função de trabalho