Gestão de políticas de segurança para infra-estruturas críticas

(1)

U

NIVERSIDADE DE

L

ISBOA

Faculdade de Ciˆencias

Departamento de Inform´atica

GEST ˜

AO DE POL´ITICAS DE SEGURANC

¸ A PARA

INFRA-ESTRUTURAS CR´ITICAS

Hugo Miguel Pimenta Monteiro

MESTRADO EM ENGENHARIA INFORM ´

ATICA

Especializac¸˜ao em Engenharia de Software

(2)

(3)

U

NIVERSIDADE DE

L

ISBOA

Faculdade de Ciˆencias

Departamento de Inform´atica

GEST ˜

AO DE POL´ITICAS DE SEGURANC

¸ A PARA

INFRA-ESTRUTURAS CR´ITICAS

Hugo Miguel Pimenta Monteiro

DISSERTAC

¸ ˜

AO

Projecto orientado pelo Prof. Doutor Alysson Neves Bessani

MESTRADO EM ENGENHARIA INFORM ´

ATICA

Especializac¸˜ao em Engenharia de Software

(4)

(5)

Agradecimentos

Expresso a minha gratidão a todos aqueles que de alguma forma contribu´ıram para a realização desta dissertação:

• Quero manifestar o meu agradecimento ao Prof. Dr. Alysson Neves Bessani, o meu orientador, pela paciência, pelos seus ensinamentos e comentários durante o projecto de investigação;

• Ao Prof. Dr. Paulo Sousa e ao Prof. Dr. Paulo Ver´ıssimo pela motivação dada durante as aulas de Segurança. O vosso esforço e dedicação foram das principais razões por ter escolhido este projecto;

• Aos meus pais, um agradecimento muito especial, por tudo o que me deram até hoje e me continuam a dar. Sempre se esforçaram para dar o melhor aos seus filhos; • Um obrigado ao meu irmão pela motivação em ser cada vez melhor em tudo o que

fac¸o;

• Aos meus colegas, Dan Mihai e Romeu, por me terem acompanhado desde o 1o

ano de faculdade, nos bons e maus momentos nos trabalhos e exames. Foram sem d´uvida os melhores colegas de grupo que se poderia ter;

• Aos meus colegas dos Navigators e LaSIGE, principalmente aos da sala 29, pe-los momentos passados, pelo apoio em todas as minhas d´uvidas pertinentes e pelo ambiente agrad´avel com que me brindaram;

• A todos os professores do Departamento de Informática, por todo o esforço e dedicação em ensinar todos os alunos. São a razão por ter continuado e por ter vencido todos os meus obstáculos em todos os trabalhos e disciplinas;

• Ao Jorge e à Dulce, meus primos, pela ajuda na escrita desta dissertação forne-cendo-me algum material necessário;

• Aos meus amigos, principalmente aos Jovens Sem Fronteiras, por me terem dado sempre a motivação necessária para continuar nesta caminhada;

• À minha fam´ılia, um agradecimento especial, pela atenção e apoio dado, durante estes anos todos;

(6)

(7)

(8)

(9)

Resumo

As infra-estruturas cr´ıticas (ICs) são cruciais para a nossa sociedade, pois elas contro-lam serviços básicos como a electricidade, água ou gás e o seu funcionamento depende muito de sistemas informáticos.

Nos últimos anos, estes sistemas informáticos têm estado a migrar de tecnologias proprietárias e isoladas para tecnologias ditas comuns, como o TCP/IP, o windows ou o linux, por razões de eficiência operacional.

Este factor de modernização esconde um problema muito sério, no que diz respeito à segurança informática: se colocarmos as infra-estruturas em redes convencionais, pos-sivelmente ligadas, mesmo que indirectamente à Internet, usando software comum, elas automaticamente passam a ser alvo do mesmo tipo de ataques efectuados aos outros tipos de software.

Recentemente, no contexto do projecto EU-IST CRUTIAL, foram propostos vários mecanismos de protecção para ICs. Muitos desses mecanismos assumem a existência de pol´ıticas de controlo de acesso ao n´ıvel de aplicação, que têm em conta o estado da infra-estrutura e podem ser modificadas e actualizadas em tempo de operação do sistema. Nesta dissertação apresentamos uma solução que permite resolver o problema de distribuição de pol´ıticas numa IC em um ou mais dom´ınios, usando um serviço de coor-denação confiável que garante a comunicação entre os vários intervenientes do sistema. Este projecto complementa os trabalhos anteriores no projecto CRUTIAL, respondendo ao requisito de actualização de pol´ıticas de maneira automática e coordenada.

Palavras-chave: Infra-estruturas cr´ıticas, anteparas distribu´ıdas, coordenac¸˜ao

(10)

(11)

Abstract

Critical infrastructures are crucial for our society because they control basic services such as electricity, water or gas. The operation of these infrastructures depends on com-puter systems.

In the last years, these computer systems have been migrating from proprietary and isolated technologies to common technologies, such as TCP/IP protocols, windows or linux operating systems, for efficiency operation reasons.

This modernization factor hides a very serious problem about computer security: if we put these infrastructures in conventional networks, possibly connected even indirectly to the Internet using common software, they automatically becomes targets of the same types of attacks done to other types of software.

Recently, in the EU-IST CRUTIAL project, various protection mechanisms for critical infrastructures were proposed, many of which assume the existence of application level access control policies, which take into account the state of the infrastructure and can be modified and updated during the system operation.

In this dissertation, we present a solution that solves the problem of distributing poli-cies in a critical infrastructure in one or more domains, using a dependable coordination service that provides certain guaranties on the communication between all the compo-nents of the system. This project complements many of the previous works done in the CRUTIAL project, providing a mechanism for update security policies in an automatic and coordinated way.

Keywords: critical infrastructures, coordination, distributed firewalls

(12)

(13)

Conte ´udo

Lista de Figuras xv

Lista de Tabelas xvii

1 Introdução 1 1.1 Motivação . . . 2 1.2 Objectivos . . . 2 1.3 Metodologia Utilizada . . . 2 1.4 Organização do documento . . . 3 2 Conceitos Fundamentais 5 2.1 Controlos de Acesso . . . 5 2.1.1 OrBAC . . . 5 2.2 Modelos de Pol´ıticas . . . 7 2.2.1 Modelo Bell-LaPadula . . . 7 2.2.2 Modelo Biba . . . 8 2.2.3 Modelo Clark-Wilson . . . 8 2.3 Anteparas . . . 9 2.3.1 Antepara Tradicional . . . 9 2.3.2 Antepara Distribu´ıda . . . 10

2.3.3 Pol´ıticas de Controlo de Acesso em Anteparas . . . 10

2.4 Espac¸o de Tuplos . . . 11

2.4.1 Definic¸˜ao . . . 11

2.4.2 DepSpace . . . 12

2.4.3 Verificação de Pol´ıticas de Segurança . . . 12

2.5 Infra-estruturas cr´ıticas . . . 14

2.5.1 Ameac¸as e Vulnerabilidades em IC . . . 15

2.5.2 Arquitectura CRUTIAL para actualizac¸˜ao de pol´ıticas . . . 16

2.5.3 Actualizac¸˜ao coordenada de pol´ıticas . . . 17

2.6 Considerac¸˜oes Finais . . . 18 xi

(14)

3 Algoritmos de actualizac¸˜ao de pol´ıticas coordenadas 19

3.1 Princ´ıpios de Funcionamento . . . 19

3.2 Protocolo de Comunicac¸˜ao . . . 22

3.3 Modelo de Sistema . . . 22

3.4 Actualizac¸˜ao de Anteparas em um Dom´ınio . . . 24

3.5 Actualização de Anteparas em Vários Dom´ınios . . . 28

3.6 Tolerˆancia a faltas . . . 32

3.7 Tipos de Actualização e Comunicação Ass´ıncrona . . . 32

3.8 Limpeza de Lixo . . . 33

3.9 Propriedades . . . 33

3.10 Avaliac¸˜ao dos Algoritmos . . . 34

3.11 Considerações Finais . . . 35 4 Concretização 37 4.1 Ferramentas Utilizadas . . . 37 4.2 Desenho . . . 38 4.2.1 Manager . . . 38 4.2.2 Enforcer . . . 40 4.2.3 Comunicação . . . 42 4.3 Execução da Ferramenta . . . 42 4.3.1 DepSpace . . . 42 4.3.2 Manager . . . 43 4.3.3 Enforcer . . . 43

4.4 Integrac¸˜ao com o CIS . . . 45

4.5 Considerações Finais . . . 46 5 Sumário e Conclusões 47 5.1 Trabalhos Relacionados . . . 48 5.2 Impressões Pessoais . . . 48 5.3 Trabalho futuro . . . 49 Abreviaturas 51 Bibliografia 55 xii

(15)

(16)

(17)

Lista de Figuras

2.1 Exemplo de uma topologia de rede usando uma antepara tradicional . . . 9 2.2 Exemplo de uma topologia de rede usando uma antepara distribu´ıda . . . 10 2.3 Exemplo de uma regra de segurança, usando iptables . . . 11 2.4 Arquitectura do Serviço de Coordenação DEPSPACE. . . 13 2.5 Exemplo de uma pol´ıtica de controlo acesso definida no espaço de tuplos 13 2.6 Infra-estrutura Cr´ıtica que controla a rede de energia eléctrica. . . 15 2.7 Arquitectura de uma IC com um fluxo de informação permitido. . . 17 3.1 Descrição de interacções, desde a criação de pol´ıtica até à sua distribuição. . . . 20 3.2 Actualização de Pol´ıticas em um dom´ınio no SACP. . . 20 3.3 Actualização de Pol´ıticas em vários dom´ınios no SACP. . . 21 3.4 Intervenientes do SACP e o modelo Biba. . . 24 3.5 Pol´ıtica de segurança do espaço de tuplos usada nos Algoritmos 1 e 2. . . 27 3.6 Pol´ıtica de segurança do espaço de tuplos usada nos Algoritmos 3 e 4. . . 31 4.1 Diagrama de classes do Manager. . . 39 4.2 Diagrama de classes do enforcer. . . 41 4.3 Exemplo de configuração da topologia de rede no ficheiro topology.config. . . . 42 4.4 Interface gráfico do manager - Actualização de Pol´ıticas em um dom´ınio. . . 43 4.5 Interface gráfico do manager - Actualização de Pol´ıticas em vários dom´ınios. . . 44 4.6 Interface gráfico do enforcer. . . 44 4.7 Integração do enforcer na Arquitectura CIS-PS. . . 45

(18)

(19)

Lista de Tabelas

2.1 Operações suportadas pelo DEPSPACE . . . 14 3.1 Tuplos usados no SACP. . . 23 3.2 Número de acessos realizados ao espaço de tuplos. A variável n identifica

o n´umero de enforcers. . . 34

(20)

(21)

Cap´ıtulo 1

Introduc¸˜ao

Nos últimos anos, os sistemas informáticos que controlam as infra-estruturas cr´ıticas (IC) (e.g., sistemas que controlam a energia eléctrica, produção de gás, telecomunicações, entre outros), estão a migrar de sistemas proprietários e isolados para tecnologias ditas comuns, como as redes TCP/IP (muitas vezes ligadas directa ou indirectamente à Inter-net) e sistemas operativos como o windows e linux. Estas mudanças têm sempre como objectivo diminuir os custos, aumentar a eficiência dos sistemas e melhorar a qualidade do serviço prestado. Por outro lado, esta modernização pode afectar de maneira significativa a segurança informática destes sistemas: se colocarmos as infra-estruturas cr´ıticas em re-des convencionais, usando software comum, elas automaticamente passam a ser alvo dos mesmos tipos de ataques efectuados a outros tipos de software.

Além disso, as ICs muitas vezes se expandem por vários dom´ınios administrativos e possuem muitos pontos de acesso, como por exemplo, VPNs, ligações sem fios, entre outros, tornando dif´ıcil a sua protecção utilizando mecanismos de segurança fornecidos por uma antepara tradicional. Desta forma, para responder às necessidades actuais, é necessário descentralizar a antepara e implementar este tipo de mecanismo na sa´ıda de cada nó ou rede cr´ıtica do sistema.

Para que esta infra-estrutura de protecção altamente distribu´ıda funcione, é necessário que haja algum tipo de gestão coordenada que active/desactive os fluxos de informação na rede da IC, de forma similar à distribuição de pol´ıticas feitas nas anteparas distribu´ıdas [1, 17].

Recentemente, no contexto do projecto europeu CRUTIAL, foram propostos uma série de mecanismos para a protecção destas ICs [2, 11, 26]. Estes mecanismos aplicam pol´ıti-cas de controlo de acesso que têm em conta o estado da IC e que podem ser modificadas e actualizadas em tempo de operação do sistema. Entretanto, nenhum destes trabalhos se preocupa em como estas pol´ıticas são instaladas nas anteparas, ou como estas descobrem sobre mudanças de estados (chamados contextos) no sistema. Este trabalho apresenta uma solução para este problema fazendo uso de um serviço de coordenação seguro e fiável [3] que actua como meio de comunicação entre o nó que envia as pol´ıticas e os

(22)

Cap´ıtulo 1. Introduc¸˜ao 2

nós que as recebem. A solução aqui proposta consiste em um conjunto de algoritmos para a actualização de pol´ıticas em anteparas em um ou mais dom´ınios, garantindo uma semântica “tudo ou nada” (de forma similar à propriedade de atomicidade das transacções [14]).

1.1 Motivac¸˜ao

A segurança das ICs é um assunto cada vez mais discutido actualmente. Estas infra-estruturas são muito importantes na sociedade porque controlam serviços básicos como a água ou a energia. Qualquer falha neste tipo de infra-estruturas pode gerar consequências catastróficas.

A protecção de ICs numa sociedade cada vez mais digital torna-se crucial para o constante fornecimento destes serviços básicos. É necessário proteger toda a rede da IC com dispositivos de protecção, ou seja, anteparas de segurança.

As ICs, muitas vezes, precisam autorizar certas acções de acordo com os diferen-tes estados da infra-estrutura. Por exemplo, o desligamento de equipamentos da rede eléctrica só acontece, quando a rede entra em estado de emergência, fazendo com que seja necessário actualizar as anteparas para aceitarem esses comandos.

Este projecto apresenta uma solução para o problema de configuração de fluxos de informação nas anteparas da IC.

1.2 Objectivos

Este projecto tem como objectivo a concretização de um sistema de gestão de pol´ıticas de segurança para ICs, que permite manter a consistência e segurança durante as suas operações. Além da concretização, existe a necessidade também de integrar este sistema de gestão com o componente principal da arquitectura CRUTIAL, o CIS (CRUTIAL Infor-mation Switch).

1.3 Metodologia Utilizada

Para realizar este trabalho, primeiro procedeu-se à pesquisa de trabalhos, relacionado com o tema do projecto: desde modelo de pol´ıticas, anteparas distribu´ıdas e mecanismos de distribuição de pol´ıticas.

Depois de se fazer uma revis˜ao bibliogr´afica exaustiva e de se ter um maior conhe-cimento do problema, surgiu a necessidade de criar o modelo do sistema e algoritmos, desenhando a arquitectura e todo o seu funcionamento para obter um trabalho de melhor qualidade com o m´ınimo de desvio poss´ıvel.

(23)

Cap´ıtulo 1. Introduc¸˜ao 3

Depois de todas as tarefas de revisão bibliográfica e de desenho, concretizou-se o protótipo, que veio aplicar toda a teoria anterior.

1.4 Organizac¸˜ao do documento

O próximo cap´ıtulo descreve alguns conceitos importantes para a compreensão do pro-jecto, tais como: os diferentes tipos de controlo de acesso, um modelo de controlo de acesso focado nas organizações, o OrBAC, passando pelos modelos de pol´ıticas mais im-portantes, os diferentes tipos de anteparas, o que é um espaço de tuplos e como este se aplica no projecto actual. Explica-se o que são ICs e que tipo de vulnerabilidades estas estão sujeitas, actualmente.

O Cap´ıtulo 3 descreve o SACP (Sistema de Actualização Coordenada de Pol´ıticas), apresentando todo o funcionamento deste sistema com a descrição de algoritmos de actu-alização coordenada de pol´ıticas.

A parte da concretização, no Cap´ıtulo 4, descreve como o protótipo foi desenvolvido, aplicando a teoria dos cap´ıtulos anteriores.

A tese conclui com o Cap´ıtulo 5, que descreve de uma forma cr´ıtica todo o trabalho desenvolvido e apresenta o que pode ser melhorado no futuro.

(24)

(25)

Cap´ıtulo 2

Conceitos Fundamentais

Este cap´ıtulo descreve os conceitos fundamentais que são necessários para a compreensão do problema descrito no cap´ıtulo anterior.

2.1 Controlos de Acesso

O controlo de acesso permite autorizar ou proibir o acesso de uma entidade (sujeito) a um determinado recurso. Existem v´arios tipos de controlo de acesso. Os modelos mais usados s˜ao os seguintes:

Controlo de acesso mandatório: O controlo de acesso mandatório (MACC) permite que o sistema restrinja a capacidade de um sujeito de aceder a um objecto, ou seja, o utilizador não pode mudar os direitos de acesso de um objecto mesmo que seja seu pro-prietário.

Controlo de acesso discricion´ario: O controlo de acesso discricion´ario (DACC) per-mite que o sujeito possa atribuir os direitos de acesso que quiser a outros sujeitos, apenas nos objectos que criou e controla.

Controlo de acesso baseado em papéis: No controlo de acesso baseado em papéis (RBAC), a pol´ıtica de segurança não concede permissões directamente aos utilizadores, mas sim aos papéis, que são posteriormente associados a utilizadores. Um determinado utilizador obtém permissões se desempenhar um determinado papel.

2.1.1 OrBAC

O OrBAC (organization-based access control) [18], como o nome indica, é um modelo de controlo de acesso baseado em papéis com especial foco em organizações. Este mo-delo está assente sobre três entidades básicas (sujeito, acção, objecto) e permite defi-nir permissões, seguindo a lógica de que o sujeito realiza uma determinada acção sobre

(26)

Cap´ıtulo 2. Conceitos Fundamentais 6

um qualquer objecto. A entidade mais importante neste modelo é a organização. Uma organização pode ser vista como um grupo organizado de sujeitos, a desempenhar um determinado papel.

Sujeitos e papéis Os sujeitos podem ser utilizadores, e.g., João ou Mariana. As or-ganizações podem ser por exemplo, o departamento financeiro da organização. O pa-pel é usado na estrutura de uma ligação entre sujeitos e organizações. No dom´ınio da educação, os papéis “professor”, “aluno”, entre outros, vão ser desempenhados por su-jeitos, assim como os papéis, “departamento de engenharia de software”, “secretaria”, “grupo de investigação LaSIGE” ou outros, vão ser desempenhados por organizações.

Objectos e Vistas Uma vista corresponde a um conjunto de objectos que satisfazem uma propriedade comum. Por exemplo, numa aplicação web concebida para os profes-sores, a vista “registo de avaliação”, corresponde aos registos de avaliação dos alunos (objectos).

Acções e Actividades Uma actividade é um conjunto de acções que satisfazem uma propriedade comum. Neste modelo, uma actividade é por exemplo, “conduzindo”, “pes-quisando”, entre outros.

A entidade acção vai sobretudo conter acções como “ler”, “escrever”, “enviar”, entre outros. As actividades vão unir-se a acções. Por exemplo, a actividade “lançamento de notas” numa Universidade, corresponde a uma acção escrever que pode ser executada em um conjunto de dados numa base de dados relacional.

Contextos Os contextos [10] são usados para especificar circunstâncias concretas onde as organizações mudam as suas pol´ıticas de segurança. Nas centrais de energia, a nova entidade contexto, vai cobrir circunstâncias em que existem mudanças de estado, por exemplo: “emergência”, “normal” ou “restauro”. Os vários diferentes tipos de contextos são os seguintes:

• Temporal: Uma acção feita por um utilizador em um determinado objecto é auto-rizada apenas durante um intervalo de tempo. Por exemplo, autorizar determinados fluxos de informação a um técnico de manutenção durante um tempo pré-determi-nado. Passado esse tempo estipulado, o contexto é alterado.

• Espacial: A localização onde o utilizador faz o pedido é útil para especificar a pol´ıtica de controlo de acesso. Por exemplo, numa central de energia, os empre-gados apenas podem aceder aos dados cr´ıticos de cada subestação quando estes se encontram em um terminal de manutenção.

(27)

O contexto espacial divide-se em dois tipos: f´ısico (i.e., a localização f´ısica do utilizador, podendo ser o escritório, um edif´ıcio ou mesmo o pa´ıs) e o lógico, ou seja, a localização “lógica” onde o utilizador se encontra (i.e., o computador ou uma determinada rede).

• Declarado pelo utilizador: O utilizador define o contexto, ou seja, por exemplo, quando este determina que está a fazer algum tipo de manutenção a um dispositivo. A partir deste momento, o utilizador tem acesso a dados do dispositivo.

• Pré-requisito: A permissão é concedida a um sujeito apenas se algumas restrições são satisfeitas. Por exemplo, quando um conjunto de técnicos de manutenção acede a vários dispositivos, esta manutenção e todos os dados referentes à mesma, ficam guardados numa base de dados, onde a verificação da restrição é feita com um pedido à mesma. Esta restrição pode ser por exemplo, restringir o acesso aos dados de manutenção, mostrando apenas a cada técnico os dados das suas manutenções. • Provisório: Uma obrigação provisória é uma obrigação que realiza alguma acção

que é aplicada quando um sujeito desempenha outra acção, geralmente num con-texto dado (tipicamente quando o concon-texto é declarado pelo utilizador). Por exem-plo, se o técnico de manutenção em um contexto de emergência finaliza o seu tra-balho, tem por obrigação enviar o relatório de manutenção para a administração.

2.2 Modelos de Pol´ıticas

Depois de se descrever os tipos de controlo de acesso e um modelo focado nas organiza-ções, é altura de definir o modelo de pol´ıticas e perceber qual a sua função no contexto deste trabalho.

Para definir as pol´ıticas de controlo de acesso e as regras de negócio que vão ser usadas na infra-estrutura da organização, tem que se definir qual o modelo de pol´ıticas a aplicar. A escolha de um modelo de pol´ıticas ajuda na descrição das pol´ıticas da organização.

Existem v´arios modelos de pol´ıticas actualmente. De seguida s˜ao apresentados os modelos mais importantes.

2.2.1 Modelo Bell-LaPadula

O modelo Bell-LaPadula [6] previne o acesso (de leitura) não autorizado a informação, garantindo assim a confidencialidade da mesma.

Este modelo descreve um conjunto de regras em que se usam n´ıveis de seguranc¸a (“security labels”) para objectos e clearances para sujeitos. O conjunto de regras do modelo s˜ao:

(28)

• um sujeito em um determinado n´ıvel de segurança não pode ler um objecto que está num n´ıvel superior;

• um sujeito em um determinado n´ıvel de segurança não pode escrever em qualquer objecto de n´ıvel de segurança inferior;

2.2.2 Modelo Biba

O modelo Biba [6] descreve um conjunto de regras de controlo de acesso desenhadas para assegurar a integridade dos dados. Este modelo foi desenvolvido para colmatar a fraqueza do modelo Bell-LaPadula, descrito anteriormente.

Os dados e sujeitos estão agrupados por n´ıveis de integridade, isto é, o modelo está desenhado de maneira que os sujeitos não corrompam os dados de n´ıvel superior.

No modelo Biba, os utilizadores podem apenas criar conte´udo, no mesmo ou abaixo do seu n´ıvel de integridade e podem apenas ler no mesmo n´ıvel de integridade ou acima.

Este modelo define um conjunto de propriedades similares ao modelo Bell-LaPadula, mas inversas:

• um sujeito em um determinado n´ıvel de segurança não pode ler um objecto que está num n´ıvel inferior (i.e., se o n´ıvel do objecto é dominado pelo n´ıvel do sujeito); • um sujeito em um determinado n´ıvel de segurança não pode escrever em qualquer

objecto de n´ıvel de seguranc¸a superior;

2.2.3 Modelo Clark-Wilson

O modelo de integridade Clark-Wilson, é baseado na noção de transacção (conjunto de operações que fazem o sistema transitar de um estado consistente para outro estado con-sistente).

Este modelo respeita o princ´ıpio de separação de responsabilidades onde requer que a entidade que certifica a transacção seja diferente daquela que a implementa.

O tipo de dados principal neste modelo, é o CDI (Constrained Data Item). O IVP (Integrity Verification Procedure) garante que todos os CDIs no sistema estão válidos num determinado estado.

As transacções que reforçam a pol´ıtica de integridade são representados por TP (Trans-formation Procedures). Um TP tem como valores de entrada, um CDI ou um UDI (Un-constrained Data Item), produzindo depois um CDI.

Um TP deve fazer a transição de um sistema, de um estado válido para outro. Os UDIsrepresentam os valores de entrada do sistema (como aqueles dados pelo utilizador). Um TP deve garantir, através da certificação, que transporta todos os valores poss´ıveis do UDIem um CDI seguro [6].

(29)

2.3 Anteparas

A antepara [1, 17] é um dispositivo de protecção a n´ıvel de software ou hardware, que é configurado para filtrar o tráfego de dados nas redes. Existem dois tipos de anteparas: a tradicionale a distribu´ıda.

2.3.1 Antepara Tradicional

A antepara tradicional tem como função evitar que intrusos acedam à rede onde esta está instalada, filtrando todo o tráfego baseando-se num conjunto de regras ou pol´ıticas definidas pelo próprio utilizador, ou no caso de algumas organizações, pelo administrador de sistemas ou pela equipa de segurança.

A Figura 2.1 representa como a antepara tradicional est´a situada na topologia da rede, protegendo a rede de atacantes provenientes da WAN (Wide Area Network), ou seja, pro-tegendo a LAN (Local Area Network).

As ICs (ver Secção 2.5) têm vários dom´ınios administrativos e muitos pontos de acesso, como VPNs, ligações sem fios, entre outros, que facilmente ultrapassam os meca-nismos de segurança fornecidos por uma antepara tradicional, que apenas protege a rede de ataques externos (e.g., Internet) e não tem em conta os ataques internos, provenientes da própria rede.

Existe uma maior necessidade em utilizar outro tipo de anteparas, que seja mais dis-tribu´ıda e menos centralizada (com menos dependência na própria topologia da rede), que resolva o problema da existência de muitos pontos de acesso numa infra-estrutura tão expandida como é o caso da IC.

LAN

WAN Protegido

(30)

2.3.2 Antepara Distribu´ıda

As anteparas distribu´ıdas [1, 16, 17, 25] surgiram para tentar resolver o problema de existir muitos pontos de acesso numa determinada infra-estrutura. Pontos esses que ultra-passavam os mecanismos de seguranc¸a fornecidos por uma antepara tradicional.

Este tipo de antepara descentraliza toda a gestão de pol´ıticas de segurança e não está restringida à própria topologia da rede (como se pode observar pela Figura 2.2), ao contrário da antepara tradicional, que distingue quem está dentro da rede como sendo confiável, e fora, como não confiável. Esta pode ser instalada na entrada de cada nó cr´ıtico da rede, protegendo-a de qualquer ataque, seja ele interno ou externo.

As anteparas filtram a informação na sua rede de acordo com as pol´ıticas de segurança definidas. Estas pol´ıticas são muito importantes, porque são elas que definem quais os fluxos de informação autorizados na rede.

LAN

WAN

Figura 2.2: Exemplo de uma topologia de rede usando uma antepara distribu´ıda

2.3.3 Pol´ıticas de Controlo de Acesso em Anteparas

As pol´ıticas de segurança definem que tipo de informação pode fluir na rede. Estas são condições que dividem um conjunto de estados no sistema em autorizados ou seguros, não autorizadosou não seguros.

A Figura 2.3 apresenta um exemplo de uma regra de seguranc¸a usando o iptables1_{, que}

permite definir regras de controlo de fluxos de informação. Esta regra quando aplicada no sistema, aceita pacotes TCP do IP 192.168.1.100, que iniciem uma nova ligação para o porto 22. Uma pol´ıtica de controlo de acesso de iptables é uma lista destas regras.

(31)

Cap´ıtulo 2. Conceitos Fundamentais 11 /sbin/iptables -A INPUT -p tcp -s 192.168.1.100/32

–dport 22 -m state –state NEW -j ACCEPT

Figura 2.3: Exemplo de uma regra de seguranc¸a, usando iptables

A pol´ıtica de segurança apresentada é muito básica, porque apenas faz inspecção ao n´ıvel de pacotes. Existem application gateways que permitem filtrar a informação se-guindo pol´ıticas de segurança ao n´ıvel de aplicação [24]. Um exemplo de pol´ıticas ao n´ıvel da aplicação é o OrBAC (ver Secção 2.1.1), que permite definir regras de controlo de acesso com foco na própria organização, não havendo a necessidade de definir proto-colos, portos ou endereços IP, tornando mais fácil e menos prop´ıcio a erros a definição de pol´ıticas de segurança.

2.4 Espac¸o de Tuplos

Os sistemas distribu´ıdos abertos são uma peça fundamental na sociedade de informação actual. Estes sistemas são constitu´ıdos por vários processos que se executam em anfitriões heterogéneos ligados a uma rede também heterogénea, como a Internet. Muitas aplicações distribu´ıdas são constru´ıdas usando primitivas simples como os sockets TCP/IP e chama-das a procedimentos remotos. Existe uma grande necessidade de haver ferramentas mais eficazes que permitam a criação de aplicações complexas com um baixo time-for-market, ao mesmo tempo que garanta a tolerância a desconexões, recuperação de crashes no ser-vidor e segurança contra acções maliciosas.

O espaço de tuplos veio introduzir uma nova forma de comunicação entre sistemas distribu´ıdos, com o objectivo de resolver todos os problemas descritos anteriormente.

2.4.1 Definic¸˜ao

O espaço de tuplos foi originalmente introduzido na linguagem de programação LINDA [13]. Este guarda e recupera tuplos (sequências finitas de valores). As operações suporta-das são essencialmente a de inserir, ler e remover tuplos.

Um tuplo t = hf1, f2, . . . , fni em que todos os campos tˆem um valor j´a definido tem

o nome de entrada. Um tuplo que tem um ou mais campos indefinidos é denominado de template(denotado com uma barra, e.g. t). Uma entrada t e um template t combinam, se tiverem o mesmo número de campos e todos os valores desses campos são iguais. Por exemplo, o template ha, b, ∗i combina com qualquer tuplo que tenha três campos e que estes tenham como primeiro e segundo campo, os valores a e b (o s´ımbolo ∗ significa que esse campo pode ser qualquer valor). Um tuplo t pode ser inserido no espaço de tuplos usando a operação out(t). A operação rd(t) é usada para ler e obter tuplos do espaço que combinem com o template t. Um tuplo pode ser lido e removido do espaço usando a

(32)

operação in(t). As operações in e rd são bloqueantes. As versões não bloqueantes, inp e rdp são muitas vezes fornecidas pelo espaço de tuplos.

O espaço de tuplos suporta um modelo de comunicação que é desacopolado no tempo (os processos podem não estar activos ao mesmo tempo) e no espaço (os processos não precisam de saber a identidade e localização dos outros) [9], fornecendo algum tipo de sincronização, ao mesmo tempo [23].

As grandes vantagens em usar o espaço de tuplos são a sua simplicidade, possuindo apenas quatro operações básicas (e outras variantes), ser content-addressable, ou seja, o facto de os tuplos serem acedidos através do seu conteúdo fornece uma grande flexibili-dade ao modelo e por último, ter uma comunicação desacopolada.

2.4.2 DepSpace

O DEPSPACE [3] é um serviço de coordenação que usa o modelo da máquina de estados [22] para implementar a sua tolerância a faltas Bizantinas e prover uma abstracção de um espaço de tuplos. Este espaço de tuplos é replicado em um conjunto de servidores. Esse conjunto forma um repositório de tuplos, garantindo que o serviço seja confiável. Para o DEPSPACEser confiável tem que satisfazer os atributos de confiabilidade [20]. Os atribu-tos relevantes na definição de um sistema confiável são: integridade (nenhuma alteração imprópria ao espaço de tuplos pode ocorrer), disponibilidade (o espaço de tuplos tem que estar dispon´ıvel para executar as operações pedidas) e confidencialidade (o conteúdo dos campos de cada tuplo não podem ser divulgados para intervenientes não autorizados). O serviço de coordenação fornecido pelo DEPSPACE é confiável enquanto menos de um

terço das réplicas não falhem.

A Figura 2.4 descreve dois clientes a executar operações sobre as réplicas do serviço de coordenação DEPSPACE. Esta descreve que o Cliente 1 quando executa uma operação

sobre o serviço de coordenação, a mesma é executada sobre todas as réplicas, assim como a operação do Cliente 2. Outro ponto importante é que estas operações são executadas na mesma ordem em todas as réplicas correctas.

A Tabela 2.1 apresenta todas as operac¸˜oes suportadas pelo DEPSPACE.

2.4.3 Verificação de Pol´ıticas de Segurança

O controlo de acesso do DEPSPACEsegue o modelo de pol´ıticas Clark-Wilson (ver Secc¸˜ao

2.2.3). Este tipo de protecção de granularidade fina, tem em conta três tipos de parâmetros para decidir se uma operação pode ou não ser em um espaço de tuplos:

• o identificador do processo p que invocou a operação; • a operação op e os seus argumentos;

(33)

DepSpace

Cliente 1 Cliente 2 out(<f1,f2,...fn>) inp(<f1,f2,...fn>) Replica 1 Replica 2 Replica 3 Replica 4

Figura 2.4: Arquitectura do Serviço de Coordenação DEPSPACE.

Cada espaço lógico definido no DEPSPACE tem uma única pol´ıtica de acesso que deve ser definida durante a configuração do sistema, pelo criador do espaço. Quando uma operação é invocada pelo servidor, existe uma verificação se a operação satisfaz a pol´ıtica de acesso do espaço. Os servidores correctos verificam correctamente essa pol´ıtica, ao contrário dos servidores faltosos. A verificação é feita sobre uma condição lógica criada na regra da operação invocada.

Object State T S

Rrd: execute(read(hPERSON, id, name, agei)) : −

invoke(p, rd(hPERSON, id, name, agei)) ∧ p = id Rout : execute(p, out(hPERSON, id, name, agei) : −

invoke(p, write(out(hPERSON, id, name, agei))) ∧ p = id ∧ @id : hPERSON, id, ∗, ∗i

Figura 2.5: Exemplo de uma pol´ıtica de controlo acesso definida no espaço de tuplos A pol´ıtica de controlo de acesso é representada usando a sintaxe da linguagem de programação PROLOG, ou seja, o lado esquerdo da função (antes do s´ımbolo “:-”) é verdadeiro se e só se a condição do lado direito é verdadeira. A Figura 2.5 descreve uma

(34)

Operação Descrição

out(t) insere o tuplo t no espac¸o

rdp(t) lê um tuplo que combina com t do espaço (retornando true); retorna false se não encontrar nenhum tuplo

inp(t) lê e elimina o tuplo que combina com t do espaço (retor-nando true); retorna f alse se não encontrar nenhum tuplo rd(t) lê um tuplo que combina com t do espaço; fica bloqueado

até que algum tuplo que combine com t seja encontrado in(t) lê e elimina o tuplo que combina com t do espaço; fica

blo-queado at´e que algum tuplo combine com t seja encontrado cas(t, t)

Se não existir um tuplo que combine com t no espaço, t é inserido e a operação retorna true; caso contrário retorna f alse

Tabela 2.1: Operac¸˜oes suportadas pelo DEPSPACE

pol´ıtica de controlo de acesso que restringe o acesso ao espaço de tuplos. A primeira regra permite a qualquer processo ler os seus próprios dados (através da condição “p = id”). A segunda e última regra Rwrite permite a um processo com um determinado id, inserir

um tuplo PERSON se e só se esse mesmo tuplo não existir no espaço de tuplos (i.e., se não tiver o mesmo id). Uma descrição mais pormenorizada sobre o funcionamento das pol´ıticas de controlo de acesso usadas no DEPSPACE, pode ser encontrada em [4].

2.5 Infra-estruturas cr´ıticas

Hoje em dia, a sociedade depende de serviços básicos como a água, a electricidade, o gás, entre outros. As ICs são infra-estruturas que controlam estes serviços básicos e não conseguem operar sem a ajuda de sistemas informáticos. Estes sistemas, compostos por muitos dispositivos, coleccionam milhares de medições sobre os processos em execução e realizam acções através de actuadores (válvulas e bombas) e apresentam a informação integrada com alarmes para posterior visualização por parte dos operadores (nos centros de controlo). Estes sistemas de computadores complexos são tipicamente chamados de SCADA(Supervisory Control and Data Aquisition).

A Figura 2.6 apresenta a hierarquia de uma IC, que produz, transforma e distribui energia. A energia é produzida por uma central eléctrica. De seguida essa energia é en-viada para as subestações, que são controladas por centros de controlo regionais que as monitorizam. Este controlo hierárquico transfere responsabilidades de quem se encontra no topo até à base. Alguns detalhes na figura foram eliminados para uma melhor compre-ensão do funcionamento da infra-estrutura.

(35)

CENTRAL ELÉCTRICA

produz energia

SUBESTAÇÃO

diminui voltagem

CENTRO DE CONTROLO REGIONAL

controla as subestações

S1 S2 S3 S4 S5 S6

Figura 2.6:Infra-estrutura Cr´ıtica que controla a rede de energia el´ectrica.

2.5.1 Ameac¸as e Vulnerabilidades em IC

Quando os protocolos para o SCADA foram desenvolvidos, o seu principal objectivo foi o de fornecer apenas as funcionalidades que garantissem o funcionamento do sistema, com um bom desempenho. A segurança nunca foi uma preocupação na construção destas redes de grande escala.

A única ideia de “segurança” que havia, eram que estas redes SCADA estavam elec-tronicamente isoladas de todas as outras, havendo um pressuposto de que os atacantes não podiam aceder às mesmas [7]. A isolação f´ısica não garante a segurança da rede, por-que existe sempre a possibilidade de haver uma ligação da rede local para a rede externa, através por exemplo, da linha de telefone ou da Internet. Essa ligação é muitas vezes necessária devido à necessidade de interligação das organizações, por razões de eficiência [15].

Um atacante determinado, pode explorar cada um destes pontos de acesso e obter o acesso a máquinas dentro da IC. A ameaça a estes sistemas é real, comprovado por vários incidentes actuais [8].

Existe um grande número de redes e dispositivos cr´ıticos que necessitam de ser prote-gidos nas ICs, utilizando algum mecanismo de protecção.2

No desenvolvimento destes mecanismos de protecção (e.g., anteparas) é necessário ter em conta alguns aspectos:

(36)

• As ICs possuem muitos sistemas legados e componentes não computacionais: con-troladores, sensores, actuadores, entre outros, que não podem ser modificados por razões operacionais.

• A principal preocupação das organizações é que a IC tem que continuar a funcionar com o mesmo n´ıvel de serviço esperado com os novos mecanismos de segurança, fazendo com que estes não sejam implementados se complicarem o funcionamento das operações. Por exemplo diminu´ırem a produtividade com a criação de palavras--chave para executar determinada operação.

Estas duas condições sugerem algum cuidado na definição de mecanismos de segu-rança neste tipo de infra-estruturas. Para tentar endereçar todos os aspectos descritos anteriormente no desenvolvimento de mecanismos de protecção de ICs, surgiu a arquitec-tura CRUTIAL.

2.5.2 Arquitectura CRUTIAL para actualizac¸˜ao de pol´ıticas

O CRUTIAL (CRitical UTility InfrastructurAL resilience) [2, 26], surgiu com o objec-tivo de criar uma nova arquitectura e protocolos de protecção para as ICs sem requerer alterações nos sistemas legados.

Esta é representada por uma WAN-of-LANs (ver Figura 2.7). Por exemplo, a rede de distribuição de energia é formada por subestações de transformação de energia ou escritórios, modelados como uma colecção de LANs, que estão interligados por uma rede maior, a WAN (i.e., redes dedicadas ou a Internet).

Esta arquitectura permite a definição de dom´ınios de segurança (e.g., LANs) com di-ferentes n´ıveis de criticidade.

A ligação de todos os nós da rede e de todos os dom´ınios é feita através de fluxos de informação que necessitam de ser configurados de alguma maneira, para proteger a rede. Por exemplo, na Figura 2.7, o fluxo de informação que vai desde o PLC3(Programmable Logic Controller) até ao servidor que guarda o histórico, necessita de passar pelas antepa-ras 1, 2 e 3, que devem filtrar este tráfego através das suas pol´ıticas de controlo de acesso que necessitam de ser configuradas ou actualizadas de alguma forma.

A antepara que protege cada LAN é um dispositivo denominado CIS (Crutial Infor-mation Switch). Este componente é uma antepara distribu´ıda avançada (ver Secção 2.3.2) que fornece protecção e resiliência a diferentes partes da IC.

O CIS fornece dois tipos de serviços: o serviço de protecção [2], que assegura que o tráfego de entrada e de sa´ıda da LAN satisfaz a pol´ıtica de segurança da organização, e o serviço de comunicação [11], que tem como principal objectivo suportar a comunicação segura entre CIS e também entre LANs.

3_{O PLC é usado para ler inputs analógicos e digitais, aplicar um conjunto de declarações lógicas e gerar}

(37)

1 2

3

Figura 2.7: Arquitectura de uma IC com um fluxo de informac¸˜ao permitido.

O modelo de controlo de acesso suportado pelo CIS, tem em consideração o envol-vimento de diferentes organizações, assim como o de possibilitar que as pol´ıticas sejam dinâmicas, i.e., que mudem de acordo com o contexto [10] e estado [12] da IC. O cerne desta tese é a definição de algoritmos para a distribuição consistente destas pol´ıticas.

2.5.3 Actualizac¸˜ao coordenada de pol´ıticas

Nas ICs existem um grande número de redes e dispositivos cr´ıticos que necessitam de ser protegidos, envolvendo mecanismos de protecção que precisam de ser configurados. O processo de configuração destes mecanismos é suscept´ıvel a erros porque é necessário configurar cada dispositivo da infra-estrutura, ou seja, cada antepara.

Além da configuração exaustiva de cada dispositivo de protecção, existe também o caso em que o controlo de acesso é dinâmico, i.e., as pol´ıticas não são estáticas e todas elas dependem do contexto (apresentado na Secção 2.1.1) influenciado pelos diferentes estados da IC (e.g., os estados de um sistema de geração e distribuição de energia [12]).

Para trocar pol´ıticas de forma coordenada e segura, é necessário criar algum sistema que consiga distribuir e actualizar as pol´ıticas de segurança de uma forma coordenada e sincronizada, de maneira que já não seja necessário configurar cada antepara da infra-estrutura manualmente.

(38)

2.6 Considerac¸˜oes Finais

Neste cap´ıtulo descreveu-se alguns conceitos fundamentais, entre os quais, os vários tipos de controlo de acesso (mandatório, discricionário, baseado em papéis), passando pela descrição de um modelo de controlo de acesso focado nas organizações, o OrBAC. Em seguida, foram apresentados alguns modelos de pol´ıticas mais conhecidos, descreveu-se também os vários tipos de anteparas (tradicional e distribu´ıda) e como as pol´ıticas de controlo de acesso em anteparas ao n´ıvel de pacotes, estão ultrapassadas. De seguida, apresentou-se o espaço de tuplos e como este pode facilitar a implementação de sistemas distribu´ıdos. Um exemplo que usa uma abstracção de um espaço de tuplos é o DEPSPACE, um serviço de coordenação confiável que possui um controlo de acesso que restringe o acesso ao espaço. Descreveu-se as ICs e como estas são importantes na sociedade. As ICs são controladas por sistemas SCADA que estão ligados à Internet. O SCADA não se preocupa com a segurança da rede da IC, logo é necessário instalar algum tipo de dispositivo de protecção que faça o filtro ao n´ıvel da aplicação, dos fluxos de informação da rede e que distribua as pol´ıticas de segurança, tendo em conta o estado do sistema.

O cap´ıtulo seguinte descreve uma poss´ıvel solução para a resolução do problema de actualização de pol´ıticas coordenadas, apresentando algoritmos e descrevendo o seu funcionamento. Também são apresentadas as pol´ıticas de controlo de acesso usadas no espaço de tuplos.

(39)

Cap´ıtulo 3

Algoritmos de actualizac¸˜ao de pol´ıticas

coordenadas

O sistema de actualizac¸˜ao de pol´ıticas tem de ser capaz de distribuir as pol´ıticas de con-trolo de acesso de uma forma coordenada e sincronizada.

Para resolver os vários problemas de sincronização de pol´ıticas, desenvolveu-se através desta dissertação uma solução que permite resolver os problemas descritos no cap´ıtulo anterior, nomeadamente na protecção de ICs, ao n´ıvel de distribuição de pol´ıticas pelas anteparas.

3.1 Princ´ıpios de Funcionamento

A nossa solução para a actualização coordenada de pol´ıticas é constitu´ıda por um conjunto de intervenientes que funcionam com outros componentes, ou seja, antes da pol´ıtica ser enviada para o nosso SACP (Sistema de Actualização Coordenada de Pol´ıticas), tem que ser criada e verificada, como está descrito na Figura 3.1.

Antes de tudo, é necessário definir a pol´ıtica de segurança que vai ser aplicada na IC. O administrador de sistemas (ou algum grupo especializado em segurança) cria a pol´ıtica de controlo de acesso. Como já foi definido anteriormente, o modelo OrBAC (descrito na Secção 2.1.1) permite descrever tais pol´ıticas, a um n´ıvel abstracto focado nas organizações, não havendo a preocupação de descrever portos ou protocolos.

De seguida, depois da pol´ıtica ter sido criada, é necessário verificá-la, ou seja, se esta está correcta e não tem ambiguidades. Actualmente, ferramentas como o APT (Ac-cess Policy Tool)[21], conseguem com vários algoritmos sofisticados analisar pol´ıticas de segurança de grandes sistemas.

Por fim, depois de criada e analisada, a pol´ıtica ´e enviada para o SACP.

O SACP é constitu´ıdo por três componentes: o manager, o enforcer e o serviço de coordenação. As duas primeiras entidades compõem o sistema e comunicam directamente com a terceira.

(40)

Cap´ıtulo 3. Algoritmos de actualizac¸˜ao de pol´ıticas coordenadas 20 Verificador de Políticas SACP Administrador cria a política de segurança usando o OrBAC Manager política já verificada OrBAC Política Enforcer distribuição de políticas CIS1 CIS2 CIS3

Figura 3.1:Descrição de interacções, desde a criação de pol´ıtica até à sua distribuição.

<NEW_POLICY, id, ...> <POLICY, e2, ...> <POLICY, e1, ...> <DEPLOYED, e2, ...> Manager (DepSpace) Coordination Service Enforcer e1 Enforcer e2 Enforcer e3 CIS CIS CIS

(41)

Cap´ıtulo 3. Algoritmos de actualizac¸˜ao de pol´ıticas coordenadas 21

De um modo geral, o manager tem o papel de iniciar o processo de actualizac¸˜ao de pol´ıticas em um ou mais dom´ınios.

Na actualização de pol´ıticas em um dom´ınio (ver Figura 3.2), o manager inicia o processo de actualização enviando as pol´ıticas para o espaço de tuplos (i.e., para uma instância do DEPSPACE). O enforcer que está a observar o espaço de tuplos, verifica que existe uma nova pol´ıtica e vai buscá-la para depois aplicá-la. Tanto o enforcer como o manager observam o espaço de tuplos e esperam pela resposta dos outros enforcers que ainda não actualizaram para a nova pol´ıtica. Depois de todos os enforcers actualizarem as suas pol´ıticas, o processo de actualização é finalizado.

Na actualização de pol´ıticas em vários dom´ınios (ver Figura 3.3), o manager ao iniciar este processo, envia as pol´ıticas para cada espaço de tuplos associado a cada dom´ınio. Os enforcersque observam o espaço de tuplos correspondente obtêm as pol´ıticas e aplicam-nas. A partir deste momento, o enforcer observa o espaço e espera a resposta do manager, isto porque este tem que observar todos os espaços de tuplos e verificar se os enforcers aplicaram ou não a pol´ıtica, de maneira a poder finalizar o processo.

Manager

DepSpace

Manager envia as políticas para os enforcers através do serviço de coordenação, para vários domínios

Enforcer e1 Enforcer e2 Enforcer e3 Enforcer e4 Enforcer e5 Enforcer e6 Enforcer e7 Enforcer e8 Enforcer e9 CIS CIS CIS CIS CIS CIS CIS CIS CIS d1 d2 d3

(42)

3.2 Protocolo de Comunicac¸˜ao

O manager e o enforcer trocam informação entre si quando actualizam as suas pol´ıticas através de um serviço de coordenação tolerante a faltas Bizantinas, o DEPSPACE (ver Secção 2.4.2), recorrendo à utilização de tuplos (sequências finitas de valores). Estes tuplos definem o protocolo de comunicação entre o manager e os enforcers. Os vários tipos de tuplos definidos no protocolo são os seguintes:

• hNEW POLICY, id, f, ugroup, timeout, ts(new p), utype, toConsumei

• hCONTEXT, id, f, ugroup, timeout, ts(new p), utype, toConsumei

• hPOLICY, id, pi, new pi

• hDEPLOYED, id, h(new p), pii

• hCONTEXT DEPLOYED, id, status, f ailed, successi

Todos os tipos de tuplos e seus campos têm um papel muito importante no processo de distribuição de pol´ıticas, como está descrito na Tabela 3.1.

As próximas secções descrevem os algoritmos distribu´ıdos usados na actualização de pol´ıticas. Note que nestes algoritmos, o manager e os enforcers comunicam-se apenas através do serviço de coordenação que garante fiabilidade e segurança nas suas interacções.

3.3 Modelo de Sistema

Como foi descrito anteriormente, o sistema é constitu´ıdo por três entidades: o manager, o enforcer e o serviço de coordenação. Estes intervenientes actuam sobre dom´ınios de segurança da IC. Um dom´ınio consiste basicamente em um conjunto de um ou mais en-forcerse uma instância do DEPSPACE (ver Secção 2.4.2). Um manager pode actualizar

as pol´ıticas em um ou mais dom´ınios.

Em termos de hipóteses temporais, o sistema assume que existe um timeout para a actualização de pol´ıticas, i.e., define-se um valor para o tempo que o manager e enforcers esperam pela aplicação de pol´ıticas pelas anteparas (os enforcers) que as aplicam. Ultra-passado este per´ıodo de timeout, o sistema regressa ao estado anterior, ou seja, ao estado antes do in´ıcio do processo de actualização.

A actualização de pol´ıticas de segurança em um ou mais dom´ınios tem uma semântica “tudo ou nada”, similar à propriedade de atomicidade das transacções [14], o que quer dizer que ou as pol´ıticas são aplicadas em todos os enforcers ou o sistema volta ao estado anterior.

Se um enforcer confirmar que recebeu a nova pol´ıtica (através da inserção do tuplo DEPLOYED no espaço de tuplos) e se o mesmo falhar a seguir à inserção, o sistema só descobre essa falha na próxima actualização de pol´ıticas.

(43)

campo comum id identificador único de cada actualização.

NEW POLICY

anuncia que existem novas pol´ıticas no espac¸o de tuplos.

CONTEXT

f número máximo de falhas nos enforcers que o sistema de distribuição de pol´ıticas tolera.

ugroup conjunto de enforcers onde vai ser aplicada a nova pol´ıtica de seguranc¸a.

timeout tempo m´aximo que o manager e enforcers esperam que todos actualizem a nova pol´ıtica.

ts(new p)

data de quando foi efectuado o anúncio da nova pol´ıtica. Tem como principal função facilitar a procura do último id único do tuplo existente no espaço de tuplos.

utype indica o tipo de actualização, ou seja, parâmetro usado para decidir que pol´ıtica é aplicada enquanto os enforcers estão a actualizar a sua pol´ıtica.

toConsume define se as pol´ıticas que estão no espaço são para consu-mir ou não, isto é, se o enforcer lê e retira a pol´ıtica ou se existe apenas uma pol´ıtica para todos lerem.

POLICY

tuplo que contém a pol´ıtica de segurança que o conjunto de enforcers vão aplicar.

pi id do enforcer a aplicar na pol´ıtica.

new p pol´ıtica de controlo de acesso a aplicar. DEPLOYED

tuplo usado para identificar que o enforcer aplicou a pol´ıtica com su-cesso.

h(new p) hash da pol´ıtica tem a func¸˜ao de garantir que o enforcer recebeu e aplicou a pol´ıtica correcta.

pi id ´unico do enforcer que inseriu o tuplo DEPLOYED.

CONTEXT DEPLOYED

tuplo usado para enviar a informação aos enforcers do su-cesso/insucesso da aplicação do contexto.

status indica o sucesso/insucesso da operação. failed conjunto de nós que não aplicaram a pol´ıtica. success conjunto de nós que aplicaram a pol´ıtica.

Tabela 3.1: Tuplos usados no SACP.

A comunicação entre enforcers e managers é autenticada com o DEPSPACE, ou seja,

se estes não forem autenticados, não podem participar no processo de actualização de pol´ıticas devido à sua incapacidade de trocar informação com o serviço de coordenação. Modelo de Pol´ıticas

O modelo de pol´ıticas usado no SACP é similar ao modelo Biba (apresentado na Secção 2.2.2), preservando a integridade dos dados (neste caso, as pol´ıticas de segurança). Os dados e sujeitos estão agrupados em diferentes n´ıveis de integridade.

Os sujeitos são o manager e o enforcer, como está representado na Figura 3.4. O manager “escreve” no enforcer, através do envio de pol´ıticas de segurança que este tem que aplicar. O enforcer “lê” a informação do manager, isto é, por exemplo quando este envia tuplos de controlo para finalizar o processo de distribuição de pol´ıticas em vários dom´ınios.

Este modelo é reforçado pelo controlo de acesso do espaço de tuplos (ver Secção 2.4.3), concretizado no DEPSPACE.

(44)

Enforcer Manager

Leitura Escrita

Figura 3.4:Intervenientes do SACP e o modelo Biba.

3.4 Actualizac¸˜ao de Anteparas em um Dom´ınio

O algoritmo 1 descreve o comportamento do manager m quando o mesmo quer iniciar o processo de actualizac¸˜ao de pol´ıticas em um dom´ınio. Este processo depois de iniciado, distribui as pol´ıticas para os enforcers que de seguida aplicam as mesmas.

O método policyUpdate() do algoritmo, recebe cinco parâmetros: ugroup (grupo de enforcersque terão as suas pol´ıticas actualizadas), f (número máximo de falhas de enfor-cersque podem ocorrer durante a actualização), timeout (tempo máximo que o manager e os enforcers esperam pela aplicação das pol´ıticas em todos os nós do grupo de enfor-cers), new p (define um vector com n pol´ıticas a enviar para os enforcers) e por último o parâmetro utype (tipo de actualização, i.e., qual deve ser o comportamento do enforcer durante a actualização). O funcionamento do tipo de actualização está descrito mais à frente, na Secção 3.7). Os parâmetros desta função são usados na definição de alguns tuplos (ver Tabela 3.1).

Os algoritmos seguintes usam algumas funções externas: nextId(), getTime() e h(). A função nextId() retorna um novo id, que representa o identificador único de cada processo de actualização de pol´ıticas. A função getTime() retorna o instante de tempo UTC (Coor-dinated Universal Time), enquanto que a função h() recebe como parâmetro um objecto e retorna a sua assinatura (usando o algoritmo MD51₎

(45)

Algoritmo 1 Manager - Actualizac¸˜ao de Anteparas em um dom´ınio Shared variables:

1: ts ← ∅ {espac¸o de tuplos partilhado}

procedure policy update(ugroup, f, timeout, new p, utype)

1: id ← nextId()

2: for all pj ∈ ugroup do

3: ts.out(hPOLICY, id, pj, new p[j]i)

4: end for

5: ts.out(hNEW POLICY, id, f, ugroup, timeout, getT ime(), utypei)

6: expired ← f alse

7: notDeployed ← ugroup {enforcers que ainda n˜ao aplicaram a pol´ıtica}

8: while | notDeployed |> f ∧ ¬expired do

9: if ts.rd(hDEPLOYED, id, h(new p), ?pi, timeout) then 10: notDeployed ← notDeployed \ {p}

11: else

12: expired ← true 13: end if

14: end while

O algoritmo 1 ´e constitu´ıdo pelos seguintes passos:

1. m insere |ugroup| tuplos POLICY no espac¸o de tuplos associado ao dom´ınio, um para cada enforcer a ser actualizado (linhas 2 a 4);

2. m insere um tuplo NEW POLICY no espaço de tuplos associado ao dom´ınio para anunciar que existe uma nova actualização de pol´ıtica que deve ser aplicada por um grupo de enforcers (linha 5);

3. m continua a ler tuplos DEPLOYED no espac¸o de tuplos associado ao dom´ınio at´e que que todos (menos poss´ıveis faltas toleradas) os enforcers definidos em ugroup estejam actualizados e apliquem as suas novas pol´ıticas (linhas 8 a 14);

O algoritmo 2 descreve o comportamento do enforcer pi quando ao observar o espac¸o

(46)

Algoritmo 2 Enforcer pi - Actualizac¸˜ao de anteparas em um dom´ınio

Shared variables:

procedure policy update()

1: id ← nextId()

2: if ts.rd(hNEW POLICY, id, ?f, ?ugroup, ?timeout, ?ts, ?utype)i) then

3: if pi ∈ ugroup then/

4: return

5: end if

6: ts.rd(hPOLICY, id, pi, ?new pi)

7: applyP olicy(new p, utype)

8: ts.out(hDEPLOYED, id, h(new p), pii)

10: notDeployed ← ugroup {enforcers que ainda n˜ao aplicaram a pol´ıtica}

11: while | notDeployed |> f ∧ ¬expired do

12: if ts.rd(hDEPLOYED, id, h(new p), ?pi, timeout) then 13: notDeployed ← notDeployed \ {p} 14: else 15: expired ← true 16: end if 17: end while 18: if ¬expired then 19: applyP olicy(new p, N EW ) 20: else

21: applyP olicy(φ, ROLLBACK) 22: end if

23: end if

O algoritmo 2 ´e constitu´ıdo pelos seguintes passos:

1. pilˆe um tuplo NEW POLICY do espac¸o de tuplos associado ao dom´ınio (linha 2).

Se piestá em ugroup, o algoritmo é executado, senão retorna (linhas 3 a 5);

2. pilê o tuplo POLICY do espaço de tuplos associado ao dom´ınio que contém a nova

pol´ıtica a ser aplicada (linha 6);

3. pi aplica a pol´ıtica de segurança de acordo com o tipo de actualização (ver Secção

3.7), usando a func¸˜ao applyPolicy() (linha 7);

4. pi insere um tuplo DEPLOYED que representa o sucesso ao obter a nova pol´ıtica

(linha 8);

5. pi espera que todos os membros do ugroup (menos poss´ıveis faltas toleradas)

in-siram tuplos DEPLOYED no espac¸o de tuplos associado ao dom´ınio (linhas 11 a 17);

(47)

6. o algoritmo é finalizado com a aplicação da pol´ıtica, através da execução do método applyPolicy(). O tipo de actualização que recebe como parâmetro está definido como NEW, ou seja, a partir desse momento, o enforcer aceita apenas pacotes que respeitem a nova pol´ıtica recebida (ver Secção 3.7 para mais detalhes). Se ocorrer um timeout, pi faz um ROLLBACK e aplica a pol´ıtica antiga, ou seja, a que estava

em aplicação antes do in´ıcio do processo de actualização (linhas 18 a 22);

Object State T S

Rrd: execute(rd(t)) : − invoke(p, rd(t))

Rpolicy: execute(out(hPOLICY, id, e, new pi)) : −

invoke(m, out(hPOLICY, id, e, new pi)) ∧ @id, e : hPOLICY, id, e, ∗i ∈ T S ∧ manager(m)

Rnew policy : execute(out(hNEW POLICY, id, f, ugroup, timeout, ts, utypei)) : −

invoke(m, out(hNEW POLICY, id, f, ugroup, timeout, ts, utypei)) ∧ @id : hNEW POLICY, id, ∗, ∗, ∗, ∗, ∗i ∈ T S

∀j ∈ ugroup : hPOLICY, id, j, ∗i ∈ T S ∧ manager(m)

Rdeployed: execute(out(hDEPLOYED, id, h, ei) : −

invoke(p, out(hDEPLOYED, id, h, ei)) ∧

∃id : hPOLICY, id, e, new pi ∈ T S ∧ enf orcer(e) ∧ p = e ∧ h = h(new p))

Figura 3.5: Pol´ıtica de segurança do espaço de tuplos usada nos Algoritmos 1 e 2. A Figura 3.5 apresenta a pol´ıtica de controlo de acesso (ver Secção 2.4.3) do espaço de tuplos usada pelos dois algoritmos (1 e 2).

A regra Rrdpermite a qualquer processo ler qualquer tuplo do espac¸o. A regra Rpolicy

permite a um processo inserir tuplos POLICY (i.e., tuplo que contém a pol´ıtica a ser aplicada pelos enforcers) com o id da actualização e do enforcer diferente daquele que está no espaço de tuplos. A regra Rnew policy permite a um processo inserir o tuplo

NEW POLICY (i.e., tuplo que anuncia a existência de uma nova pol´ıtica) se não houver outro do mesmo tipo com o mesmo id de actualização, e que todos os tuplos POLICY com o mesmo identificador da actualização definidos no ugroup estejam no espaço. A regra Rdeployedpermite a um processo inserir um tuplo DEPLOYED (i.e., tuplo que

iden-tifica o enforcer que recebeu a pol´ıtica com sucesso) se houver outro tuplo POLICY no espaço de tuplos que tenha o mesmo id da actualização, o mesmo identificador do enfor-cer e a assinatura da pol´ıtica seja igual à assinatura definida no tuplo DEPLOYED. O tuplo DEPLOYED só pode ser inserido no espaço com o id do processo que executou Rdeployed.

As regras Rpolicy e Rnew policy definem as restrições de operações que são executadas

(48)

3.5 Actualização de Anteparas em Vários Dom´ınios

Quando se quer fazer uma mudança de pol´ıticas global envolvendo vários dom´ınios de segurança, é utilizado o algoritmo de actualização de anteparas em vários dom´ınios.

O algoritmo 3 descreve o comportamento do manager m quando este inicia o processo de actualização de pol´ıticas em vários dom´ınios, ou seja, a actualização de um conjunto de enforcers que se encontram em vários espaços lógicos. O manager tem acesso a todos os espaços de tuplos nos vários dom´ınios. Para cada dom´ınio, existe um conjunto de variáveis privadas: o status define se houve sucesso ou insucesso na aplicação da nova pol´ıtica num determinada espaço, o ugroup é o conjunto de enforcers de cada dom´ınio que vai ser actualizado com novas pol´ıticas e por último, a variável notDeployed define quais os enforcers de cada dom´ınio que não aplicaram a pol´ıtica de segurança.

A função policy update context() recebe quatro parâmetros: f (define o número máxi-mo de falhas de enforcers que pode ocorrer durante o processo de actualização de pol´ıti-cas), new p (matriz com as novas pol´ıticas que serão enviadas para todos os enforcers, de todos os dom´ınios), timeout (tempo máximo que os enforcers esperam pelo manager pela finalização do processo de actualização) e por último, o utype (tipo de actualização que define que pol´ıticas devem ser aceites enquanto o processo de actualização ainda não foi finalizado, descrito na Secção 3.7).

O algoritmo 3 utiliza as mesmas funções externas que os algoritmos anteriores e é constitu´ıdo pelos seguintes passos:

1. m insere um tuplo POLICY (para cada enforcer em cada dom´ınio administrativo). Estes tuplos ser˜ao depois consumidos pelos enforcers. (linhas 2 a 5);

2. m insere um tuplo CONTEXT em todos os espaços de tuplos associados aos dom´ınios para anunciar que existe um novo contexto. Este novo contexto (ver Secção 2.1.1) irá actualizar as pol´ıticas destes espaços de tuplos (linha 6);

3. m continua a ler tuplos DEPLOYED em todos os espaços de tuplos associados aos dom´ınios, até que todos os enforcers (menos poss´ıveis faltosos) apliquem as suas novas pol´ıticas. Esta parte é executada em paralelo, através de várias threads, uma para cada dom´ınio, no entanto, optou-se por descrevê-la de forma sequencial para manter a simplicidade (linhas 8 a 23);

4. Depois de todos os enforcers actualizarem as suas pol´ıticas, é altura de verificar se o contexto foi aplicado com sucesso ou não, em cada espaço (linha 24);

5. m insere um tuplo CONTEXT DEPLOYED em todos os espaços de tuplos asso-ciados aos dom´ınios, indicando o sucesso/insucesso na realização da actualização (linhas 25 a 27);

(49)

Algoritmo 3 Manager - Actualização de Anteparas em vários dom´ınios Shared variables:

1: ts1, · · · , tsn← ∅ {espac¸o de tuplos partilhado}

Private variables:

1: statusj ← ∅ {para cada dom´ınio 1 . . . n}

2: ugroupj ← ∅ {para cada dom´ınio 1 . . . n}

3: notDeployedj ← ∅ {para cada dom´ınio 1 . . . n}

procedure policy update context(f, new p, timeout, utype)

1: id ← nextId()

2: for all 1 ≤ j ≤ n do 3: for all pk∈ ugroupj do

4: tsj.out(hPOLICY, id, pk, new p[j][k]i)

5: end for

6: tsj.out(hCONTEXT, id, f, ugroupj, timeout, getT ime(), utypei)

7: end for

8: for all 1 ≤ j ≤ n do 9: expired ← f alse

10: notDeployed ← ugroupj {enforcers que ainda n˜ao aplicaram a pol´ıtica}

11: while | notDeployed |> f ∧ ¬expired do 12: for all pk ∈ ugroupj do

13: if tsj.rd(hDEPLOYED, id, h(new p), ?pji), timeout) then

14: notDeployed ← notDeployed \ {p} 15: else 16: expired ← f alse 17: end if 18: end for 19: end while 20: if ¬expired then 21: status ← true 22: end if 23: end for

24: status = statusj∧ · · · ∧ statusn

25: for all 1 ≤ j ≤ n do

26: tsj.out(hCONTEXT DEPLOYED, id, status, notDeployedj, ugroupj \

{notDeployedj}i)

27: end for

(50)

O algoritmo 4 descreve o comportamento do enforcer pi quando o mesmo transita

para o estado de actualização de pol´ıticas em vários dom´ınios, i.e., quando o manager cria um novo contexto no espaço lógico onde pi está inserido.

Algoritmo 4 Enforcer pi - Actualização de Anteparas em vários dom´ınios

Shared variables:

procedure policy update()

1: id ← nextId()

2: if ts.rd(hCONTEXT, id, ?f, ?ugroup, ?timeout, ?ts, ?utypei then

3: if pi ∈ ugroup then/

4: return

5: end if

6: if ts.rd(hPOLICY, id, pi, ?new pi) then

7: applyP olicy(new p, utype)

8: ts.out(hDEPLOYED, id, h(new p), pii)

10: if ts.rd(hCONTEXT DEPLOYED, id, ?status, ?f ailed, ?successi, timeout) then

11: if status = true ∧ ¬expired then

12: applyP olicy(new p, N EW ) 13: else

14: applyP olicy(φ, ROLLBACK)

15: end if 16: end if

17: end if

18: end if

O algoritmo ´e constitu´ıdo pelos seguintes passos:

1. Se pi lê um tuplo CONTEXT, o processo de mudança de contexto é iniciado e o

algoritmo é executado (linha 2). Se pi é um membro desse grupo, o algoritmo é

executado, sen˜ao retorna (linhas 3 a 5);

2. pi lê o tuplo POLICY do espaço de tuplos associado ao dom´ınio, que contém a

pol´ıtica a ser aplicada (linha 6);

3. pi aplica a pol´ıtica de segurança (de acordo com o tipo de actualização que se

en-contra descrito na Secção 3.7), através da função applyPolicy() (linha 7);

4. pi insere um tuplo DEPLOYED, representando o sucesso de obter a nova pol´ıtica

(linha 8);

5. pi espera pela resposta do manager, indicando o sucesso/insucesso no processo de