Escolar Documentos
Profissional Documentos
Cultura Documentos
Cotrole de Acesso
Novembro 2006
Sumário
1 Conceitos Básicos 3
1.1 Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Ameaças, Vulnerabilidades e Ataques . . . . . . . . . . . . . . 4
1.2.1 Tipos de Ameaças . . . . . . . . . . . . . . . . . . . . 4
1.3 Polı́ticas de segurança . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Mecanismos de Segurança . . . . . . . . . . . . . . . . . . . . 5
1.5 Garantia de Controle . . . . . . . . . . . . . . . . . . . . . . . 5
3 Polı́ticas 13
3.1 Definição Formal de Polı́ticas . . . . . . . . . . . . . . . . . . 13
4 Autenticação 15
4.1 UNIX Passwords . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2 Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.1 Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2
Capı́tulo 1
Conceitos Básicos
1.1 Segurança
Quando se fala de segurança, durante esta apostila, é importante saber que
trata-se do que a palavra em inglês security, ao invés de safety, descreve.
Segurança em computação, neste contexto, é o processo que garante as ca-
racterı́sticas de confidencialidade, integridade e disponibilidade, além
de autenticidade e não-repúdio1 .
Integridade Estes sujeitos devem poder verificar que a informação não foi
indevidamente modificada; um intruso não deve poder modificar uma
informação sem que esta alteração não seja identificável.
Não-repúdio Um sujeito não pode falsamente negar ter gerado uma in-
formação.
1
Segurança no sentido de safety descreve uma proteção contra acidentes ou riscos pes-
soais.
3
1.2 Ameaças, Vulnerabilidades e Ataques
Estas definições são ainda inconsistentes nos trabalhos nesta área. Este do-
cumento utiliza as definições para estes termos que é encontrada em [Amo94].
Ataque é uma ação executada por um intruso que envolve o abuso de uma
vulnerabilidade para provocar a ocorrência de uma ameaça.
Negação de Serviço ou DoS2 é uma ameaça que impede que usuários au-
torizados utilizem algum recurso por este estar maliciosamente bloque-
ado.
4
sem que se tenha que alterar o mecanismo, que normalmente está implemen-
tado no software.
Existem dois tipos de mecanismos que garantem a efetivação das polı́ticas,
que devem ser destacados: aqueles que abrangem todo o sistema, e aqueles
que são controlados pelo sujeito responsável pelo objeto. Estes mecanismos
são chamados, respectivamente, de mandatórios e discricionários.
Monitor de referência Pode ser visto como um filtro de acesso, por onde
todas as requisições de acesso devem passar e que não pode ser desviado
ou evitado, que decide, através de avaliações, se uma requisição deve
ser autorizada ou não. É um modelo conceitual de um mediador de
acesso.
5
Capı́tulo 2
Principais Modelos e os
Mecanismos que os
Implementam
∃ s ∈ S ∧ ∃ o ∈ O/r(s, o) ∈ R
s1
s2
Sujeitos Direitos
sS
o1 o2 Objetos oO
6
O direito que se encontra na célula indexada pelo sujeito e objeto é aquele
que será concedido durante a requisição de acesso.
7
Um administrador pode, quando necessário, mover informações de uma
classificação maior para outra menor (violando a propriedade *).
O modelo Biba pode ser visto como o oposto do modelo Bell-LaPadula:
sua preocupação é com a integridade das informações. Um sujeito pode
visualizar informação classificada no seu nı́vel de acesso, ou em um nı́vel
superior (no read-down), e escrever apenas em um objeto classificado em
seu nı́vel, ou inferior (no write-up).
8
papéis e um papel pode ser atribuı́do a vários sujeitos; sujeitos de-
vem poder habilitar vários papéis simultaneamente; e deve ser possı́vel,
através de uma ação administrativa, verificar quais papéis estão dis-
ponı́veis para um dado sujeito.
9
por fatores externos como a aceitação de um contrato através de um clique
do mouse (obrigação) ou o horário do dia (condição).
Os predicados do UCONABC também podem ser verificados durante a
utilização, e não apenas na requisição inicial de acesso, possibilitando que
um usuário tenha sua permissão de uso revogada enquanto detém o controle
do recurso. Outra facilidade que é introduzida nesse modelo é a mutabilidade
dos atributos do recurso e do usuário, possibilitando polı́ticas que garantam,
por exemplo, a dedução do custo de uso de um recurso do crédito disponı́vel
a um usuário.
Usuários e objetos possuem atributos que são utilizados para a tomada
de decisão pelo monitor de referência e esses atributos podem ser atualizados
como resultado da avaliação de uma requisição de uso. Assim, um atributo
de um objeto, atualizado durante uma requisição de uso de um usuário, pode
influenciar a avaliação do uso de outro usuário.
A avaliação considera, além dos atributos, predicados para autorização,
obrigação e condição. Estes predicados podem ser compostos separadamente,
ou utilizados em conjunto, dependendo do controle de uso que se deseja
implementar.
Autorização é um conjunto de predicados funcionais que são avaliados para
decidir se um usuário pode exercer um dado direito sobre um objeto.
Estes predicados englobam os modelos clássicos de controle de acesso,
como o Controle de Acesso Discricionário (DAC), Mandatório (MAC)
e Baseado em Papéis (RBAC).
oBrigações são predicados funcionais que tratam ações que devem ser cum-
pridas antes ou durante o uso para que um usuário possa exercer seus
direitos sobre o objeto. Por exemplo, para um usuário conseguir exe-
cutar um software novo, ele tem que enviar um email para o adminis-
trador informando que um novo executável foi instalado.
Condições são fatores de decisão ambientais ou externos ao objeto e ao
sujeito. Esses fatores podem ser indicados em atributos, mas nenhum
atributo deve ser utilizado diretamente no predicado. Por exemplo, o
predicado “qualquer usuário não administrativo só pode executar um
software se a carga total do processamento do sistema for menor que
80%” é uma condição, mas “um usuário só pode executar um software
se sua utilização do sistema for menor que 80%”, não o é. O fato de a
utilização do processador por um usuário ser um atributo especı́fico do
usuário faz com que a avaliação não seja do sistema, mas de um atributo
do usuário apenas, não se enquadrando na definição de condição dada
por Park e Sandhu [PS04].
10
2.4.1 Momentos de Avaliação e Atualização
Os predicados do UCONABC podem ser avaliados para se obter direito de
uso de um objeto, ou para manter este direito. Quando o usuário ainda não
detém direito de uso, e um conjunto de predicados será avaliado, a avaliação
acontece antes do uso, então chama-se esta avaliação de pre. Assim, tem-se
preA, preB e preC, para avaliações de Autorização, oBrigações e Condições.
Da mesma forma, quando avalia-se o direito de permanecer utilizando um
recurso, a avaliação acontece durante o uso, e ela é chamada de on: onA,
onB e onC. A figura 2.2 mostra esta continuidade na tomada de decisão.
Decision
pre(ABC) on(ABC)
Continuity
Como pode ser visto na figura 2.2, assim como existem momentos dife-
rentes para a verificação, existem, também, momentos diferentes para a atu-
alização de atributos. Atributos do recurso e do sujeito podem ser imutáveis
(0, ou modificados antes (1), durante (2) ou após (3) o uso (e.g. onA0 , onA1 ,
onA2 e onA3 ). A combinação dos momentos de avaliação com os de atua-
lização gera os 16 modelos centrais do UCONABC , como mostra a tabela 2.1:
cada “S” (sim) indica a existência de uma combinação no modelo.
Para avaliações pre, não existe atualização durante o uso. Isso ocorre
porque, como não há avaliações neste momento (on), qualquer atributo al-
11
terado somente seria utilizado na próxima avaliação, antes do próximo uso,
fazendo com que uma atualização 2 tenha o mesmo efeito de uma atualização
3 (após o uso).
Nota-se, também, que os predicados de condição não atualizam atributos,
existindo apenas preC0 e onC0 . Isso acontece porque as condições são ava-
liadas apenas um função do sistema, e não dos atributos (mas um atributo
pode informar qual condição deve ser avaliada).
12
Capı́tulo 3
Polı́ticas
13
regra : conjunto → booleano
Pode-se, então, construir expressões como:
Estas expressões podem ser vistas como funções que retornam um va-
lor booleano. Por exemplo, a função dono definida acima poderia retornar
verdadeiro para dono(pedro, /tmp/arq.txt).
Expressões mais complexas podem ser criadas, agrupando-se funções di-
ferentes:
14
Capı́tulo 4
Autenticação
15
As palavras-chave podem ainda ser conseguidas ao ver o usuário as digi-
tando (“shoulder surfing”), ou em anotações em sua mesa. Em alguns casos,
usuários podem até mesmo fornecer suas senhas para qualquer pessoa que
identifique-se como profissional de informática ou para “ceder” sua conta
para um colega realizar um serviço mais facilmente.
Para evitar problemas como estes, deve-se:
16
Para dificultar este tipo de ataque, adiciona-se à palavra-chave uma seqüência
aleatória de caracteres, chamada de salt, antes de aplicar a função one-way, e
armazena-se estes caracteres junto com o resultado no banco de dados. Se o
salt for suficientemente longo e variado, um ataque de dicionário seria prati-
camente inviabilizado devido ao tempo para se computar um dicionário com
todos os caracteres aleatórios possı́veis para cada palavra, e devido também
ao grande espaço necessário para armazenar os resultados.
Um salt de 4 caracteres entre 0-9 e a-Z (60 valores) resultaria em 12.960.000
diferentes resultados para cada palavra do dicionário. É mais fácil calcular
o dicionário utilizando-se apenas os valores aleatórios encontrados no banco
de dados, mas assim perde-se a vantagem de se poder utilizar o mesmo di-
cionário para vários ataques, e aumenta muito o tempo de cada ataque.
4.2.1 Kerberos
Kerberos é um protocolo que provê uma autenticação segura em rede, permi-
tindo que um usuário ou processo acesse diversos serviços realizando apenas
uma autenticação. Este protocolo é baseado em criptografia simétrica, e
compartilha uma chave secreta com cada entidade (clientes e servidores) na
rede; conhecimento desta chave secreta é prova de identidade.
17
Figura 4.1: Passos de autenticação no Kerberos (Extraı́da de [Sch96]
Credenciais
O Kerberos utiliza dois tipos de credenciais, tickets e autenticadores. Um
ticket é utilizado para, de maneira segura, passar a identidade de seu portador
para um servidor. É válido apenas para um cliente utilizá-lo em conjunto
18
Tabela 4.1: Tabela de Abreviações (Extraı́da de [Sch96])
c cliente
s servidor
a endereço de rede do cliente
v inı́cio e término do tempo de validade de um ticket
t timestamp
Kx chave secreta de x
Kx,y chave de sessão para x e y
{m}Kx m criptografado com a chave secreta de x
Tx,y ticket de x para acessar y
Ax,y autenticador de x para y
19
1. Cliente para Kerberos: c, tgs
2. Kerberos para Cliente: {Kc,tgs }Kc , {Tc,tgs }Ktgs
3. Cliente para TGS: {Ac,s }Kc,tgs , {Tc,tgs }Ktgs
4. TGS para Cliente: {Kc,s }Kc,tgs , {Tc,s}Ks
5. Cliente para Servidor: {Ac,s }Kc,s , {Tc,s}Ks
20
Referências Bibliográficas
[PS03] Jaehong Park and Ravi Sandhu. Usage control: A vision for
next generation access control. In Vladimir Gorodetsky, Leo-
nard J. Popyack, and Victor A. Skormin, editors, 2nd International
Workshop on Mathematical Methods, Models, and Architectures for
Computer Network Security, volume 2776 of Lecture Notes in Com-
puter Science, pages 17–31. Springer, 2003.
[PS04] Jaehong Park and Ravi Sandhu. The U CONABC usage control
model. ACM Transactions on Information and System Security,
7(1):128–174, 2004.
[SFK00] Ravi Sandhu, David Ferraiolo, and Richard Kuhn. The NIST model
for role-based access control: towards a unified standard. In RBAC
’00: Proceedings of the fifth ACM workshop on Role-based access
control, pages 47–63, New York, NY, USA, 2000. ACM Press.
21
Índice Remissivo
ameaça, 4 restrito, 9
negação de serviço, 3, 4 simétrico, 9
tipos de, 4 modelo
vazamento de informações, 4 Bell-LaPadula, 7
violação de integridade, 4 Biba, 8
ataque, 4 matriz de acesso, 6
autenticação, 15 monitor de referência, 5
single sign-on, 17
funções one-way, 16 não-repúdio, 3
kerberos, 17 polı́ticas, 4, 13
credenciais, 18 definição formal de, 13
mensagens do protocolo, 18, 19
problemas, 15 segurança
UNIX passwords, 16 safety, 3
autenticidade, 3 security, 3
confidencialidade, 3 TCB, 5
criptografia
salt, 17 UCON, 9
de passwords, 16 vulnerabilidade, 4
funções one-way, 16
disponibilidade, 3
integridade, 3
mecanismos de segurança, 4, 5
Capabilities, 7
ACL, 7
DAC, 5, 7
MAC, 5, 8
RBAC, 5, 8
básico, 8
hierárquico, 9
22