10 de Dezembro de 2009.
Este artigo têm por objetivo apresentar de maneira sucinta o propósito do modelo de controle de acesso UCON. Serão descritos os conceitos básicos sem se aprofundar em fórmulas e definições lógicas. Permitindo uma visão geral e funcional deste modelo.
Introdução ao UCON
No artigo publicado por Sandhu e Park [1] em 2003, observou-se que o modelo de matriz de acesso estava inalterável a pelo menos três décadas e que a maioria dos modelos tradicionais tratavam somente de autorização de acesso. Também foi observado que os modelos tradicionais apresentam diversas limitações, tais como no controle de acesso que não pode ser feito de maneira distribuída e a ausência de uma avaliação dinâmica de direitos. Por esses e demais motivos, os autores propuseram um modelo para controle de acesso chamado UCON (Usage Control).
O Modelo UCON é um modelo lógico e matemático que não se preocupa com implementação. Engloba controles tradicionais como DAC (Discretionary Access Control), MAC (Mandatory Access Control) e RBAC (Role-Based Access Control). E suporta controles modernos como TM (Trust Management) e DRM (Digital Rights Management).
Componentes do UCON
Os componentes do modelo UCON são oito: sujeito, atributos do sujeito, objetos, atributos do objeto, direitos, autorizações, obrigações e condições. Abaixo uma breve descrição de cada componente juntamente com uma letra ou sigla de sua representação [1,2]:
Sujeitos, objetos e direitos são comuns em diversos modelos tradicionais:
* Sujeito (S) - entidade que pode ser uma pessoa/grupo ou sistema que quer ter direitos no acesso a(os) objeto(s).
* Atributos do sujeito (ATT(S)) - alguns exemplos de atributos de sujeito são: nome, login, grupo, entre outros (obs.: o modelo UCON não obriga o uso de atributos de identificação para permitir o acesso de sujeitos anônimos).
* Objeto (O) - alguns exemplos são: arquivos, vídeos, músicas, programas, etc; ou seja, são entidades as quais um sujeito possui determinados direitos de acesso.
* Atributos do objeto (ATT(O)) - por exemplo: rótulo de segurança, autor, dono, classificação, etc.
Um diferencial do UCON está nos atributos, que tanto nos sujeitos como nos objetos os atribuitos podem ser mutáveis. Essa mutabilidade ocorre por conseqüência do acesso. No caso de atributos imutáveis, estes só poderão ser alterados por ação administrativa.
* Direitos (R) - são privilégios que um sujeito tem sobre o objeto.
Os três fatores de decisão conhecidos como ABC são:
* Autorização (A) - é um fator que decide se o sujeito pode exercer ou não o seu direito sobre um objeto. As autorizações são baseadas nos atributos do sujeito e nos atributos do objeto.
* Obrigações (B) - são requisitos que o sujeito deve executar antes ou durante o acesso ao objeto. As obrigações não usam os atributos como tomada de decisão, mas para saber qual obrigação aplicar.
* Condições (C) - são fatores relacionados ao ambiente do sistema. Por definição do modelo as condições podem influenciar os acessos mas não podem alterar os atributos do sujeito e do objeto.
Família UCON
Processos que ocorrem antes (pre) e durante (ongoing) o acesso, combinados com os fatores de decisão A, B e C e relacionados com mutabilidade e imutabilidade de atributos, formam 24 modelos de UCON:
* Pré: decide-se antes do acesso. Ex: preA (pré-autorização), preB (pré-obrigação) e preC (pré-condição).
* Durante: decide-se durante o acesso. Ex: onA (autorização em curso), onB (obrigação em curso) e onC (condição em curso).
E, no caso de permitir aos atributos serem mutáveis ou não, enumera-se:
* Imutável (0): os atributos dos sujeitos e dos objetos não podem ser alterados.
* Mutável (1, 2 e 3): opcionalmente, os atributos dos sujeitos e dos objetos poderão ser alterados antes (1), durante (2) e depois (3) do acesso.
Não há necessidade de alterar atributos durante o acesso se este está pendente na pré-autorização ou na pré-obrigação: logo, os modelos preA2 e preB2 não existem. E, também, os modelos preC1, onC1, preC2, onC2, preC3 e onC3 não existem por definição própria do modelo UCON. Restando, então, 16 modelos que são detalhados a seguir.
Estados de Transição
O mesmo artigo que propõe uma especificação lógica do UCON [3] apresenta um diagrama de transição de estados. Um diagrama que será utilizado no artigo presente para representar os modelos de UCON. Componentes desse diagrama:
1. Estados: inicial (initial state), solicitando (requesting), acessando (accessing), negado (denied), revogado (revoked) e fim (end).
2. Ações: tentar acesso (try access), negar acesso (denyaccess), permitir acesso (permitaccess), revogar acesso (revokeaccess) e encerrar acesso (endaccess). E, também, as ações que permitem a alteração de atributos são: pré-alteração (preupdate), alteração em curso (onupdate) e pós-alteração (postupdate).
Ilustrando o UCON
Apresentam-se os exemplos dos 16 modelos de UCON. Para fazer essa representação, será utilizado o seguinte cenário:
"Um exército deve atacar seu inimigo. Para isso o comandante geral deixa três instruções de ataques armazenadas em um sistema computacional: planoA.doc, planoB.pdf e planoC.avi. O exército está dividido em cinco esquadras: amarela, azul, branca, verde, vermelha. O modelo escolhido para o controlar os acesso no sistema foi o UCONABC."
Com base nesse cenário, exemplos são aplicados a seguir.
Pré-autorização (preA): é realizada antes do direto solicitado ser executado.
* PreA0 - é a abordagem clássica de controle de acesso, os atributos do sujeito e do objeto são verificados para permitir ou não o acesso. Os atributos são imutáveis.
Exemplo: Somente as esquadras amarela, azul, verde e vermelha têm permissão para acessar o arquivo planoA.doc. Logo, a esquadra branca não têm permissão para acessar esse arquivo.
* preA1 - além de verificar os atributos do sujeito e do objeto para permitir (ou não) o acesso, também permite opcionalmente alterar esses atributos (mutabilidade).
* preA3 - opcionalmente permite alterar os atributos do sujeito e do objeto após realizar o acesso.
Exemplo: O arquivo planoA.doc poderá ser acessado no máximo 20 vezes. Ou seja, a cada acesso (preA1) o atributo contador do objeto é verificado, e se for menor ou igual a 20, o acesso é permitido; e cada vez que o acesso é realizado (preA3), o atributo contador é incrementado.
Autorização em curso (onA): a autorização é feita em curso, ou seja, a verificação é feita continuamente ou periodicamente. Nesses modelos, o acesso é autorizado sem qualquer pré-decisão e, se determinadas exigências se tornam insatisfeitas, o direito de uso é revogado.
* onA0 - a autorização é feita em curso, mas os atributos do sujeito e do objeto são imutáveis.
Exemplo: De minuto em minuto, é verificado se as esquadras que acessam o arquivo planoB.pdf são das esquadras amarela, azul, verde ou vermelha. Caso contrário, o acesso será barrado (stopped).
* onA1 - a autorização é feita em curso, e os atributos de sujeito e do objeto opcionalmente podem ser alterados antes do acesso.
* onA2 - a autorização é feita em curso, e os atributos de sujeito e do objeto opcionalmente podem ser alterados durante o acesso.
* onA3 - a autorização é feita em curso, e os atributos de sujeito e do objeto opcionalmente podem ser alterados depois do acesso.
Exemplo: O comandante determinou que o arquivo planoB.pdf só pode ser acessado por duas esquadras ao mesmo tempo. Quando ocorrer de uma terceira esquadra abrir o arquivo, o acesso mais antigo será derrubado. Portanto, a cada esquadra que acessar o planoB.pdf (onA1), serão incrementados o contador de acessos do objeto e o contador de tempo do sujeito. Se esta for a terceira esquadra, o sistema vai barrar o acesso da esquadra que têm o contador de tempo maior e decrementar o contador de acessos (onA2). Ao encerrar o acesso (onA3), o contador de acesso é decrementado, e o contador de tempo é zerado.
Pré-obrigação (preB): antes do acesso, verifica funções históricas para identificar atividades que foram cumpridas ou não. E acaba resultando em verdadeiro ou falso.
* preB0 - a obrigação deve ser cumprida antes de ocorrer o acesso, os atributos de sujeito e de objeto são imutáveis e não interferem no processo de decisão.
Exemplo: Quando se tenta o acesso ao arquivo planoA.doc, abre-se uma tela fazendo uma pergunta conhecida por soldados. Se a resposta escolhida pelo soldado da esquadra estiver correta, o acesso será permitido.
* preB1 - a obrigação deve ser cumprida antes de ocorrer o acesso e, opcionalmente, os atributos do sujeito e do objeto podem ser alterados antes desse acesso.
* preB3 - a obrigação deve ser cumprida antes de ocorrer o acesso e, opcionalmente, os atributos do sujeito e do objeto podem ser alterados depois desse acesso
Exemplo: O comandante determinou ao sistema que se houver mais de três respostas erradas em uma obrigação, o acesso da esquadra será bloqueado. Portanto, antes de acessar o arquivo planoA.doc, é feita uma pergunta, e a cada erro, o atributo contador de erro é incrementado (preB1). Se ocorreu quatro erros, o acesso é negado (preA1). Agora se houver apenas três erros ou menos, ao encerrar o acesso, o contador de erros é zerado (preB3).
Obrigação em curso (onB): a obrigação deve ser cumprida em curso, continuamente ou periodicamente. Nesse modelo, não existe pré-obrigação, pois todas obrigações são tratadas durante o acesso.
* onB0 - a obrigação deve ser cumprida em curso, os atributos de sujeito e de objeto são imutáveis e não interferem no processo de decisão.
Exemplo: O comandante determinou que enquanto uma esquadra acessa o arquivo planoB.pdf, deve também estar acessando arquivo planoA.doc. Essa verificação será feita continuamente, e caso o arquivo planoA.doc seja fechado, o acesso ao planoB.pdf será revogado.
* onB1 - a obrigação deve ser cumprida em curso e, opcionalmente, os atributos de sujeito e de objeto poderão ser alterados antes do acesso.
* onB2 - a obrigação deve ser cumprida em curso e, opcionalmente, os atributos do sujeito e do objeto poderão ser alterados durante o acesso.
* onB3 - a obrigação deve ser cumprida em curso e, opcionalmente , os atributos do sujeito e do objeto poderão ser alterados depois do acesso.
Exemplo: O comandante determinou que é obrigatório ao sujeito manter o cursor do mouse sobre a janela no momento da leitura do arquivo planoB.pdf. E, por questões forenses, o velocímetro do mouse deverá ser armazenado em logs. Portanto, o sujeito têm acesso direto ao planoB.pdf e o atributo velocímetro do mouse é zerado (onB1). Durante o acesso, o velocímetro é contabilizado (onB2), e caso o mouse saia da janela atual, o acesso ao planoB.pdf será revogado. Ao final, quando o acesso é encerrado (onB3), o valor resultante do velocímetro do mouse é armazenado em arquivo de log.
Pré-condição (preC): é uma pré-condição do ambiente para ser atendida antes de realizar o acesso.
* preC0 - uma pré-condição onde os atributos de sujeito e objeto são imutáveis.
Exemplo: Antes de permitir o acesso aos documentos "avi", verificar se a carga do sistema está abaixo de 3%.
Condição em curso (onC): é uma condição do ambiente que deve ser atendida durante os acessos.
* onC0 - uma condição que deve ser atendida continuamente ou periodicamente, onde os atributos de sujeito e objeto são imutáveis.
Exemplo: O consumo de memória e CPU não devem ultrapassar de 80%. Se isso ocorrer, os acessos serão revogados até que o sistema normalize.
Considerações Finais
Apresentou-se aqui de maneira simples o funcionamento do modelo UCONabc. Quando se trata de modelos de controle de acesso, esse modelo é considerado expressivo e flexível. Por se tratar de um modelo um tanto completo e complexo, até então não foram encontradas implementações, e as que existem são incompletas e não implementam recursos de tempo real ou de atualização de atributos.
Procurou-se aqui apenas demonstrar o funcionamento básico deste modelo. Mais detalhes de como funciona o monitor de referência e a comparação entre os modelos existentes, poderão ser encontrados nos artigos que estão nas referências.
Referências:
[1] R. Sandhu and J. Park, Usage Control: A Vision for Next Generation Access Control, The Second International Workshop on Mathematical Methods, Models and Architectures for Computer Networks Security, 2003.
[2] Jaehong Park , Ravi Sandhu, The UCONABC usage control model, ACM Transactions on Information and System Security (TISSEC), v.7 n.1, p.128-174, February 2004.
[3] Xinwen Zhang , Jaehong Park , Francesco Parisi-Presicce , Ravi Sandhu, A logical specification for usage control, Proceedings of the ninth ACM symposium on Access control models and technologies, June 02-04, 2004, Yorktown Heights, New York, USA.