Logo Logo
GitHub Designed by Logto

O que é o controlo de acesso baseado em atributos (ABAC)?

ABAC é um modelo de Controlo de acesso que utiliza atributos para tomar decisões de controlo de acesso. Estes atributos podem incluir vários fatores, tais como:

  • Atributos do utilizador: por exemplo, papéis, departamento, localização, etc.
  • Atributos do recurso: por exemplo, nível de sensibilidade, proprietário, tipo, etc.
  • Atributos ambientais: por exemplo, hora de acesso, localização, dispositivo, etc.

Ao avaliar estes atributos e executá-los através de um conjunto de regras, o ABAC pode determinar se um sujeito (por exemplo, utilizador, serviço) deve ter acesso a um recurso. Esta abordagem permite um controlo de acesso detalhado e uma aplicação de políticas dinâmica com base no contexto.

Como funciona o ABAC?

O ABAC utiliza uma abordagem baseada em políticas para o controlo de acesso. Uma política típica de ABAC consiste em:

  • Sujeito: A entidade que solicita acesso (por exemplo, utilizador, serviço, dispositivo).
  • Ação: A operação que está a ser realizada no recurso (por exemplo, ler, escrever, eliminar).
  • Recurso: A entidade que está a ser acedida (por exemplo, ficheiro, base de dados, API).
  • Ambiente: O contexto em que o acesso é solicitado (por exemplo, hora, localização, dispositivo).
  • Atributos: As propriedades do sujeito, recurso e ambiente que são avaliadas para tomar decisões de acesso.
  • Políticas: Um conjunto de regras que definem as condições sob as quais o acesso é concedido ou negado.

As políticas de ABAC são mais complexas do que os modelos tradicionais de controlo de acesso, como o Controlo de acesso baseado em funções (RBAC) . Por outro lado, o ABAC oferece mais flexibilidade e granularidade nas decisões de controlo de acesso.

Exemplo de políticas ABAC

Por exemplo, um sistema tem várias políticas ABAC:

  1. Política 1: Permitir acesso se:

    • (Sujeito) O papel do sujeito é manager.
    • (Atributo) O nível de sensibilidade do recurso é high.
    • (Ambiente) A localização é internal.
    • (Ação) Qualquer ação.
    • (Ambiente) O tempo é entre as 9h e as 17h (horário de expediente).
  2. Política 2: Negar acesso se:

    • (Sujeito) O papel do sujeito não é manager.
    • (Atributo) O nível de sensibilidade do recurso é high.
    • (Ambiente) Qualquer localização.
    • (Ação) Qualquer ação.
    • (Ambiente) Qualquer tempo.
  3. Política 3: Permitir acesso se:

    • (Sujeito) O papel do sujeito é employee ou manager.
    • (Atributo) O nível de sensibilidade do recurso é low.
    • (Ambiente) Qualquer localização.
    • (Ação) Ação de read.
    • (Ambiente) Qualquer tempo.

O motor de avaliação de políticas verificará estas políticas por ordem, e a primeira política que corresponder às condições determinará a decisão de acesso. Entretanto, uma política de negação padrão é aplicada se nenhuma outra política corresponder.

Vamos passar por alguns cenários para entender como o ABAC funciona:

Cenário 1. Um utilizador quer aceder (realizar a ação de read) a um documento de alto nível de sensibilidade (recurso) fora do escritório (ambiente). O utilizador tem o papel de manager armazenado no sistema.

Decisão: O acesso é negado porque o utilizador está fora do escritório (a localização não é internal).

Cenário 2. Um utilizador quer aceder (realizar a ação de read) a um documento de alto nível de sensibilidade (recurso) durante o horário de expediente (ambiente) na rede do escritório (localização=internal). O utilizador tem o papel de manager.

Decisão: O acesso é concedido porque todas as condições na Política 1 são atendidas.

Cenário 3. Todas as condições no cenário 2 são as mesmas, mas o utilizador tem o papel de employee em vez de manager.

Decisão: O acesso é negado porque o papel do utilizador não corresponde às condições na Política 1.

Cenário 4. Um utilizador quer aceder (realizar a ação de read) a um documento de baixo nível de sensibilidade (recurso). O utilizador tem o papel de employee.

Decisão: O acesso é concedido porque todas as condições na Política 3 são atendidas.

Cenário 5. Um utilizador quer eliminar (realizar a ação de delete) um documento de baixo nível de sensibilidade (recurso). O utilizador tem o papel de employee.

Decisão: O acesso é negado porque não há nenhuma política que permita a ação de delete em documentos de baixo nível de sensibilidade.

Pode-se notar que nem todos os atributos são necessários em cada política. Esta flexibilidade permite um mecanismo de controlo de acesso mais dinâmico e sensível ao contexto.

eXtensible Access Control Markup Language (XACML)

XACML é um padrão baseado em XML para expressar políticas de controlo de acesso. Embora não defina um modelo específico de controlo de acesso, o XACML é frequentemente usado para implementar políticas ABAC. Vamos ver um exemplo não normativo de como o XACML pode ser usado para representar as políticas ABAC do exemplo anterior:

<PolicySet PolicySetId="ABAC_Policies" PolicyCombiningAlgId="urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-overrides">
  <Policy PolicyId="Policy1" RuleCombiningAlgId="urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-overrides">
    <Target>
      <Subjects>
        <Subject>
          <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
            <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">manager</AttributeValue>
            <SubjectAttributeDesignator AttributeId="role" DataType="http://www.w3.org/2001/XMLSchema#string"/>
          </SubjectMatch>
        </Subject>
      </Subjects>
      <Resources>
        <Resource>
          <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
            <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">high</AttributeValue>
            <ResourceAttributeDesignator AttributeId="sensitivity-level" DataType="http://www.w3.org/2001/XMLSchema#string"/>
          </ResourceMatch>
        </Resource>
      </Resources>
      <Environments>
        <Environment>
          <EnvironmentMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
            <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">internal</AttributeValue>
            <EnvironmentAttributeDesignator AttributeId="location" DataType="http://www.w3.org/2001/XMLSchema#string"/>
          </EnvironmentMatch>
        </Environment>
        <Environment>
          <EnvironmentMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:time-in-range">
            <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#time">09:00:00</AttributeValue>
            <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#time">17:00:00</AttributeValue>
            <EnvironmentAttributeDesignator AttributeId="time" DataType="http://www.w3.org/2001/XMLSchema#time"/>
          </EnvironmentMatch>
        </Environment>
      </Environments>
    </Target>
    <Rule RuleId="Rule1" Effect="Permit"/>
  </Policy>
  <!-- Outras políticas (Policy 2, Policy 3) -->
</PolicySet>

Para mais informações sobre XACML, veja Linguagem de Marcação Extensível de Controlo de Acesso (XACML) .

Considerações de implementação

Embora o ABAC ofereça uma forma poderosa de gerir o controlo de acesso, também apresenta algumas considerações de implementação:

  • Complexidade do sistema: As políticas de ABAC podem tornar-se complexas à medida que o número de atributos e regras aumenta. A gestão e teste adequados das políticas são mais demorados do que em modelos de controlo de acesso mais simples.
  • Desempenho: A avaliação de políticas complexas de ABAC pode impactar o desempenho do sistema. Técnicas de caching e otimização podem ajudar a mitigar este problema.
  • Conflitos de políticas: Políticas conflitantes podem levar a decisões de acesso imprevisíveis. A revisão regular de políticas e a resolução de conflitos devem fazer parte do processo de gestão de políticas.

ABAC vs. RBAC

Comparar o ABAC com o Controlo de acesso baseado em funções (RBAC) pode ajudar a entender as diferenças entre os dois modelos:

RBACABAC
Política de controlo de acessoBaseada em papéisBaseada em atributos
GranularidadeGrossaFina
FlexibilidadeLimitadaAltamente flexível
ComplexidadeMais simplesMais complexa
Impacto no desempenhoMínimoPode ser significativo
Gestão de acessoGestão de papéisGestão de políticas
Melhor paraEstruturas de permissão bem definidasControlo de acesso dinâmico e sensível ao contexto

Veja também