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:
-
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).
- (Sujeito) O papel do sujeito é
-
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.
- (Sujeito) O papel do sujeito não é
-
Política 3: Permitir acesso se:
- (Sujeito) O papel do sujeito é
employee
oumanager
. - (Atributo) O nível de sensibilidade do recurso é
low
. - (Ambiente) Qualquer localização.
- (Ação) Ação de
read
. - (Ambiente) Qualquer tempo.
- (Sujeito) O papel do sujeito é
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 demanager
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 demanager
.
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 demanager
.
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 deemployee
.
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 deemployee
.
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:
RBAC | ABAC | |
---|---|---|
Política de controlo de acesso | Baseada em papéis | Baseada em atributos |
Granularidade | Grossa | Fina |
Flexibilidade | Limitada | Altamente flexível |
Complexidade | Mais simples | Mais complexa |
Impacto no desempenho | Mínimo | Pode ser significativo |
Gestão de acesso | Gestão de papéis | Gestão de políticas |
Melhor para | Estruturas de permissão bem definidas | Controlo de acesso dinâmico e sensível ao contexto |