V.
Infraestrutura de Segurança de Grades (GSI)
5.1)
Política de Segurança em Grades Computacionais
Antes de permearmos as especificidades da GSI, é importante identificarmos
os objetivos da segurança, ou seja, devemos definir uma “Política
de Segurança”, um conjunto de regras que define as relações
entre os sujeitos da grade (como os usuários) e os objetos da
mesma (como os recursos). Apesar de diversas políticas serem possíveis,
será apresentada aquela que leva em conta os requisitos e os problemas
evidenciados nos tópicos anteriores, a fim de solucioná-los.
Tendo estes preceitos em mente, segue a política de segurança:
•
O ambiente da grade computacional consiste em diversos domínios
confiáveis. Isto fica claro uma vez que a política de segurança
da grade deve abarcar uma coleção heterogênea de
recursos e usuários administrados localmente,
•
Operações que são confinadas a um único domínio
confiável estão sujeitas unicamente a política de
segurança local. Fica claro isto uma vez que não são
impostos pela política de segurança de grades operações
ou serviços de segurança em operações locais,
•
Existem sujeitos (i.e. usuários) locais e globais. Para cada domínio
confiável, existe um mapeamento parcial de sujeitos globais para
locais. De fato, cada usuário dos recursos terá dois nomes,
um global e um potencialmente diferente nome local em cada recurso. O
mapeamento do nome global para o nome local é específico
de cada local. A existência de um nome global permite a provisão
de login único.
•
Operações entre entidades localizadas em domínios
de segurança diferentes requerem autenticação mútua.
•
Um sujeito (i.e. usuário) autenticado globalmente mapeado em um
sujeito local é tido como equivalente a estar localmente autenticado
como sujeito local. Em outras palavras, a combinação da
política de autenticação da grade e o mapeamento
local asseguram o objetivo de segurança do domínio hospedeiro.
•
Todas as decisões de controle de acesso são realizadas
localmente no domínio do sujeito local. Essa política requer
basicamente que as decisões de controle de acesso permaneçam
com os administradores dos sistemas locais.
•
Um programa ou processo pode atuar sob a possessão de um usuário
e possuir parte dos direitos do usuário. Essa política é necessária
para possibilitar a execução de programas que tomam grande
tempo para serem executados e que podem adquirir recursos dinamicamente
sem intervenção adicional do usuário. Ela também é necessária
para permitir a criação de processos a partir de outros
processos.
•
Processos rodando sob o mesmo sujeito no mesmo domínio de segurança
podem compartilhar as mesmas credenciais. Essa política possibilita
a escalabilidade da arquitetura de segurança para aplicações
paralelas de larga-escala, evitando a necessidade de criar uma única
credencial para cada processo.
Vale ressaltar que a política de segurança evidenciada
foi estruturada de modo a não necessitar de privacidade em massa,
isto é, encriptação, por razão alguma. Isto
se deu pois as leis de controle de exportação que visam às
tecnologias de encriptação são complexas, dinâmicas
e variam de país para país. Como as grades computacionais
podem ter dimensões internacionais, foi necessário observar
este aspecto. Por fim, observa-se que esta política possibilita
a integração de diversas políticas de segurança
locais encontradas em um ambiente de grades. Definida as políticas
da GSI, podemos enfim partir para a definição especifica
da própria.
5.2) Arquitetura de Segurança de Grades Computacionais
Rotinas de grades podem aumentar e diminuir dinamicamente, adquirindo
recursos quando necessário e liberando-os quando não são
mais necessários. Cada vez que uma rotina obtém um recurso,
ela o faz a partir de um usuário especifico. Todavia, é freqüentemente
impraticável para o usuário interagir diretamente com cada
um dos recursos para realizar a autenticação, uma vez que
o número de recursos envolvidos pode ser enorme ou mesmo porque
algumas aplicações podem ser executadas por um extenso
período de tempo, como semanas. Assim, segue o conceito de Proxy
de Usuário, que pode agir conforme um usuário sem requerer
a sua intervenção.
Proxy de Usuário: Um Proxy de usuário é um processo
controlador de sessão que tem permissão para agir conforme
o usuário por um período de tempo limitado. O Proxy de
usuário possui suas próprias credenciais, eliminando a
necessidade de o usuário estar online durante a execução
da rotina e eliminando a necessidade de ter as credenciais do usuário
para cada operação de segurança. Além disso,
como o tempo de vida do Proxy está sob controle do usuário
e pode ser limitado para a duração da rotina, as conseqüências
de segurança deste Proxy são mínimas.
Seguindo o conceito de Proxy de usuário acima introduzido, segue
abaixo o conceito de Proxy de Recursos, que se dá de maneira análoga
ao Proxy de Usuário.
Proxy de Recursos: Um Proxy de Recursos é um agente utilizado
para realizar a tradução entre operações
de segurança interdominios e mecanismos locais.
Dados os sujeitos e objetos, a arquitetura é determinada pela
especificação dos protocolos utilizados quando sujeitos
e objetos interagem. Quando da definição dos protocolos,
que segue abaixo, serão utilizadas
algumas notações,
sendo elas U, R e P para referirem-se a Usuário, Recurso e Processo
respectivamente, além de PU e PR para Proxy de Usuário
e Proxy de Recurso. Muitos dos protocolos que seguem dependerão
da habilidade de garantir que certos dados são originários
de uma fonte conhecida X, sem modificações. Sabemos que
estas condições são verdadeiras quando estes estão “assinados” por
X. Para esta assinatura, será utilizada a notação
Sig(X){text}. Tendo estas notações definidas, seguem os
protocolos.
5.3) Protocolo de Criação de Proxy de Usuário
Este protocolo permite ao usuário logar no sistema da grade
computacional, criando o Proxy de Usuário. Segue o protocolo para
tal:
1. O usuário possui acesso ao computador a partir do qual o Proxy
de Usuário será criado, utilizando qualquer forma de autenticação
local localizada no computador em questão.
2. O usuário produz a credencial do Proxy de Usuário, C(PU),
usando sua própria credencial, C(U), para assinar uma tupla contendo
o id de usuário, o nome do hospedeiro local, a validade de C(PU)
e outras informações requeridas pelo protocolo de autenticação
usado para implementar a arquitetura, como uma chave-pública.
C(PU)=Sig(U){id, hospedeiro, hora de inicio, hora de fim, informação
de autenticação}
3. Um processo de Proxy de Usuário é criado e concedido
com C(PU). A integridade de C(PU) fica a cargo da política de
segurança local no computador no qual o Proxy está localizado.
5.4) Protocolo de Alocação de Recursos
Este protocolo permite que um Proxy de Usuário aloque recursos
e crie processos. Segue o protocolo para tal:
1. O PU e o PR autenticam-se usando C(PU) e C(PR). Como parte do processo,
o PR certifica-se que as credenciais do PU não expiraram.
2. O PU envia um pedido ao PR assinado na forma Sig(PU){especificação
da alocação}
3. O PR verifica se o usuário que assinou as credencias do Proxy
de Usuário está autorizado por políticas locais
a requisitar alocação de recursos.
4. Em caso positivo, o PR cria a tupla de Credenciais do Recurso contendo
o nome do usuário para o qual o recurso está sendo alocado,
o nome do recurso, entre outros.
5. O PR envia de forma segura as Credenciais do Recurso para o PU, sendo
isto possível devido ao primeiro passo.
6. O PU examina o pedido das Credenciais do Recurso e se desejar aprová-lo,
assina a tupla para produzir C(P), uma credencial para o recurso requisitado.
7. O PU envia seguramente C(P) para o PR, sendo isto possível
novamente graças ao primeiro passo.
8. O PR aloca o recurso e passa o(s) novo(s) processo(s) C(P).
5.5) Alocação de Recursos a partir de um Protocolo de
Processo
Este protocolo permite que um processo criado possa alocar recursos
adicionais diretamente. Segue o protocolo para tal:
1. O processo e o seu PU autenticam-se usando C(P) e C(PU).
2. O processo envia um pedido assinado para o seu PU, na forma
Sig(P){ “alocar”, parâmetros do pedido de alocação}.
3. Se o PU aceitar o pedido de alocação, ele inicia o pedido
de alocação de recursos para o PR especificado usando o
protocolo de alocação de recursos.
4. O processo resultante é assinado pelo PU e retornado ao processo
requerente.
5.6) Protocolo de Registro de Mapeamento
Este protocolo permite definir o mapeamento local de um sujeito a partir
do seu mapeamento global. Segue o protocolo para tal:
1.a. O PU autentica-se com o PR.
1.b. O PU envia o pedido de Mapeamento do Sujeito do Proxy do Usuário
assinado para o PR, que tem como argumentos os nomes do sujeito global e local.
2.a. O usuário loga no recurso usando o método de autenticação
do recurso e inicia o processo de registro do mapeamento.
2.b. O processo de registro de mapeamento envia o pedido de Mapeamento do Sujeito
do Processo assinado para o PR, que tem como argumentos os nomes do sujeito
global e local.
1. O PR espera pelo pedido de ambos os mapeamentos com os argumentos iguais.
2. O PR verifica que o processo de registro de mapeamento pertence ao sujeito
especificado na requisição de mapeamento.
3. Caso ambos os argumentos dos pedidos de mapeamento sejam iguais, o PR inicia
o mapeamento e envia as informações ao Proxy de Usuário
e ao Processo de Registro de Mapeamento.
4. Se os argumentos dos pedidos de mapeamento não forem tidos como iguais
dentro do tempo limite do mapeamento o PR elimina os pedidos e envia a informação à entidade
que requisitou o mapeamento.
5. Se não for recebida nenhuma informação dentro do tempo
limite do mapeamento, é considerado que a requisição falhou.
