Um Esquema de Serviço de Diretórios Tolerante a Falhas e Intrusão

UNIVERSIDADE FEDERAL DO AMAZONAS INTITUTO DE COMPUTAÇÃO BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO

Um Esquema de Serviço de Diretórios Tolerante a Falhas e Intrusão

Bruno Eduardo Gomes Barreto

Manaus – AM Agosto de 2015

Bruno Eduardo Gomes Barreto

Um Esquema de Serviço de Diretórios Tolerante a Falhas e Intrusão

Monografia de Graduação apresentada ao Instituto de Computação da Universidade Federal do Amazonas como requisito parcial para a obtenção do grau de bacharel em Ciência da Computação.

Orientador (a)

Dr. Eduardo Luzeiro Feitosa

Coorientador (a)

Rayol de Mendonça Neto

Universidade Federal do Amazonas – UFAM Instituto de Computação – IComp

Manaus-AM Agosto de 2015

Monografia de Graduação sob o título Um Esquema de Serviço de Diretórios Tolerante a Falhas e Intrusão apresentada por Bruno Eduardo Gomes Barreto e aceita pelo Instituto de Computação da Universidade Federal do Amazonas, sendo aprovada por todos os membros da banca examinadora abaixo especificada:

__________________________________________ Dr. Eduardo Luzeiro Feitosa Orientador (a) Instituto de Computação Universidade Federal do Amazonas

__________________________________________ Dr. Horácio Antonio Braga Fernandes de Oliveira Instituto de Computação Universidade Federal do Amazonas

Manaus-AM, 7 de agosto de 2015

Aos meus pais, aos meus amigos, dedico este trabalho.

Agradecimentos Agradeço à minha mãe, minha irmã e ao meu padrasto, que são o meu pilar e minha motivação para continuar sempre alcançando meus objetivos e realizando meus sonhos. Agradeço também a esta instituição que, por meio do IComp, ofereceu-me um vasto conhecimento, o qual irei levar para toda a vida. Agradeço a todos meus colegas e amigos adquiridos durante esta graduação pela companhia e incentivo dado para o término deste curso. Agradeço também a meu orientador e ao meu coorientador que me deram a oportunidade de trabalhar neste projeto e estiveram sempre disponíveis para ajudar-me nas dificuldades encontradas.

Um Esquema de Serviço de Diretórios Tolerante a Falhas e Intrusão

Autor: Bruno Eduardo Gomes Barreto Orientador (a): Dr. Eduardo Luzeiro Feitosa

RESUMO

Serviços de diretório são mais comumente utilizados com a finalidade de manter informações sensíveis (e.g., dados e credenciais de usuários) em sistemas críticos tais como: servidores DNS, mecanismos de controle de acesso e infraestrutura de chaves públicas (PKI). Esta pesquisa apresenta uma arquitetura de serviços de diretórios com mecanismos para prover tolerância a falhas e intrusão. Para atingir este objetivo são empregadas diferentes técnicas de sistemas distribuídos, dependabilidade e segurança. A viabilidade da solução proposta é demonstrada através da implementação e avaliação de um protótipo que utiliza protocolos e técnicas avançadas de tolerância a falhas e intrusão. Os resultados demonstram que a arquitetura é capaz de tolerar falhas e intrusões sem comprometer o desempenho do sistema.

Palavras-chave: Serviços de diretório, Tolerância a Falhas, Tolerância a Intrusão.

A Directory Service Scheme Fault and Intrusion Tolerant

Author: Bruno Eduardo Gomes Barreto Advisor: Dr. Eduardo Luzeiro Feitosa

ABSTRACT

Directory services are most commonly used in order to keep sensitive information (eg, data and user credentials) on critical systems such as: DNS servers, access control mechanisms and public key infrastructure (PKI). This research presents a directory services architecture with mechanisms to provide fault and intrusion tolerance. To achieve this goal are employed different techniques of distributed systems, dependability and safety. The feasibility of the proposed solution is demonstrated through the implementation and evaluation of a prototype that uses protocols and advanced techniques of fault and intrusion tolerance. The results demonstrate that the architecture is able to tolerate faults and intrusions without compromising system performance.

Keywords: Directory services, Fault Tolerance, tolerance Intrusion.

8

Lista de Figuras Figura 1 Estrutura LDAP..........................................................................................................16 Figura 2 DIT Distribuído..........................................................................................................17 Figura 3 Replicação de Único Mestre. Fonte [Sermersheim 2006]..........................................18 Figura 4 Replicação com Múltiplos Mestres. Fonte [Sermersheim 2006]...............................19 Figura 5 Programação N-versões..............................................................................................20 Figura 6 Arquitetura Proposta para o Serviço de Diretório LDAP Replicado.........................25 Figura 7 Elementos de Implementação do Diretório LDAP Replicado...................................29 Figura 8 Vazão do Modelo sem Diversidade............................................................................31 Figura 9 Vazão do Modelo com Diversidade (OpenLDAP e OpenDJ....................................32

9

Lista de Tabelas

Tabela 1 Comparação dos Trabalhos Relacionados e Abordagem Proposta............................24 Tabela 2 Ambiente Utilizado para o Teste...............................................................................30

10

Lista de Abreviaturas e Siglas SSO – Single-Sign-On LDAP – Lighweight Directory Access Protocol DNS – Domain Name System DHCP – Dynamic Host Configuration Protocol IP – Internet Protocol PKI – Public Key Infrastructure BFT – Byzantine Fault Tolerance SASL – Simple Authentication and Security Layer TLS – Transport Layer Security SSL – Secure Socket Layer DIT – Directory Information Tree DN – Distinguished Name RFC – Request for Comments AAI – Authentication and Authorization Infrastructure TCP – Transmission Control Protocol VM – Virtual Machine DDoS – Distributed Denial of Service SMR – State Machine Replication

11

Sumário 1 Introdução ..............................................................................................................12 1.1 Contextualização ......................................................................................................................... 13 1.2 Objetivos ..................................................................................................................................... 14 1.3 Organização do Trabalho ............................................................................................................ 14

2 Referencial Teórico .................................................................................................15 2.1 LDAP .......................................................................................................................................... 15 2.1.1 Versão .................................................................................................................................. 15 2.1.2 Estrutura de Dados LDAP .................................................................................................... 16 2.1.2 Operações LDAP.................................................................................................................. 17 2.1.3 Replicação LDAP ................................................................................................................. 18 2.2 Tolerância a Falhas...................................................................................................................... 19 2.2.1 Mascaramento de Falhas ...................................................................................................... 20 2.2.2 Diversidade........................................................................................................................... 20

3 Trabalhos Relacionados ...........................................................................................22 4 Arquitetura e Implementação ..................................................................................25 4.1 Arquitetura .................................................................................................................................. 25 4.2 Modelo e Suposições................................................................................................................... 28 4.3 Implementação ............................................................................................................................ 28

5 Avaliação ................................................................................................................30 5.1 Desempenho ................................................................................................................................ 30 5.2 Falhas e Ataques ......................................................................................................................... 33

6 Considerações Finais ...............................................................................................34 7 Referências ..............................................................................................................35

12

1 Introdução Armazenar dados críticos garantindo acesso rápido e seguro é um desafio infindável devido ao aumento desta massa de dados. Mecanismos que permitem a um usuário utilizar diferentes serviços com um único processo de autenticação são classificados como SSO (single-sign-on) e são demasiadamente usados para armazenar dados críticos. Dentre os benefícios do uso do single-sign-on estão a redução: do tempo gasto, de senhas para um mesmo usuário e dos custos de TI devido ao menor número de chamadas de help desk. Serviços de diretórios são normalmente usados em autenticações de padrão single-sign-on por ser um serviço cuja finalidade é armazenar dados críticos. Os serviços de diretórios, ou simplesmente diretórios, são mais comumente utilizados como banco de dados especializados em consultas, onde os dados são armazenados de forma flexível e hierárquica. Embora existam diferentes soluções de diretórios como eDirectory, Active Directory, NIS e StreeTalk [Howes et al. 2003], LDAP (Lightweight Directory Access Protocol) [Sermersheim 2006] é o protocolo mais difundido e utilizado no suporte à serviços críticos de segurança como: autenticação e autorização. LDAP é um protocolo de aplicação aberto e amplamente suportado pela indústria para acessar e manter informações em serviços de diretório distribuídos. Alguns exemplos de sistemas que comumente utilizam diretórios LDAP são: serviços de rede como e-mail, DNS (Domain Name System) e DHCP (Dynamic Host Configuration Protocol) [Vasiliadis et al. 2007, Borsato et al. 2003], mecanismos de controle de acesso [Zhou and Meinel 2004, Park et al. 2002], infraestruturas de chave pública (PKI) [Karatsiolis et al. 2004], soluções de interoperabilidade de sistemas [Flechl and Field 2008], entre outros [Ardizzone et al. 2011, Flechl and Field 2008]. Diretórios LDAP possuem características que o tornaram um serviço indispensável quando em se tratando de manter dados críticos, dentre as características plausíveis de citação, estão: flexibilidade, eficiência das consultas e o suporte nativo à replicação, ou seja, sua capacidade de simplificar a escalabilidade e a disponibilidade dos serviços de diretório. Entretanto, considerando o presente e o futuro cenário de ameaças persistentes [Tankard 2011, Kushner 2013] e o estado de guerra digital, a segurança e a dependabilidade de sistemas críticos, como diretórios LDAP, tomam novas proporções. É necessário dar um passo além,

13

ou seja, o caminho para proteger infraestruturas de TI contra as ameaças avançadas de segurança passa a ser a cyber resiliência [Goche and Gouveia 2014, Boyd 2014]. Serviços de diretórios suportam nativamente a replicação de dados, permitindo a operação em três diferentes modos, um único mestre (Single-Master), mestres espelho (Mirror-Mode) e com múltiplos mestres (Multi-Master). Estas três configurações suportam apenas falhas por parada, devido a essa limitação foram investigadas novas técnicas capazes de tolerar falhas arbitrárias, anomalias de funcionamento de sistemas, anomalias dos canais de comunicação ou da infraestrutura de TI em si. Um dos recursos frequentemente utilizados para prover tolerância a falhas arbitrárias são os protocolos BFT (Byzantine Fault Tolerance). A forma mais comum de implementar estes protocolos é através da replicação ativa ou de máquina de estados [Bessani et al. 2014b], que oferece consistência forte e favorece a disponibilidade. Tomando a diversidade de sistemas como um exemplo, as soluções existentes suportam apenas uma única implementação de serviços de diretório LDAP (e.g., OpenLDAP) em todas as réplicas. Isso significa que um atacante precisa descobrir apenas uma única vulnerabilidade no serviço de diretórios utilizado para comprometer todas as réplicas ao mesmo tempo (e.g., ataque paralelo). Da mesma forma, um simples bug na implementação do diretório irá potencialmente afetar todas as instâncias LDAP ao mesmo tempo, uma vez que a execução das réplicas é baseada em máquina de estados. Portanto, diversidade é um componente de suma importância para tolerar falhas arbitrárias e intrusões.

1.1 Contextualização

Seguindo as especificações LDAP, a maioria das implementações, especialmente OpenLDAP, tem suporte para SASL (Simple Authentication and Security Layer) e TLS (Transport Layer Security) para aumentar a segurança e permitir um conjunto mais rico de aplicações LDAP. Uma alternativa para melhorar a segurança e a resiliência em serviços que utilizam diretórios LDAP seria através da diversidade de sistema operacional e de implementações LDAP. Embora sejam interessantes, as propostas existentes falham em dois aspectos. Estas não tiram proveito de múltiplas infraestruturas de rede e da nuvem (ex: centros de dados) para aumentar a robustez e com isso tolerar diferentes tipos de falhas e ataques. Pelo contrário, eles

14

são implantados em uma única infraestrutura física, onde uma simples queda de energia pode afetar a disponibilidade do serviço. Por fim, nenhum deles é tolerante a falhas arbitrárias e intrusão. Neste contexto, a presente proposta apresenta um esquema de serviços de diretórios tolerante a falhas e intrusão. Para isso, são combinadas técnicas avançadas de sistemas distribuídos, confiabilidade e segurança. Em outras palavras, a proposta baseia-se em diversificar a infraestrutura e as instâncias de serviços de diretórios utilizados.

1.2 Objetivos

O principal objetivo desta proposta é desenvolver e avaliar um serviço de diretório LDAP resiliente por meio de técnicas de replicação de máquinas de estado, utilizando serviços de diretórios LDAP diferentes para fornecer tolerância a falhas e intrusão. Além disso, vamos discutir alguns dos desafios de implantação de serviços de diretório LDAP como um modelo de nuvem de nuvens para garantir propriedades importantes, tais como a resistência contra diversos tipos de ameaças, ataques e falhas arbitrárias. Para atingir esse objetivo, três etapas identificadas são cruciais: 

Identificar diferentes serviços de diretórios LDAP.



Adaptar um modelo funcional que respeite o sistema desenvolvido em termos de tolerância a falhas e intrusão.



Apresentar os resultados obtidos.

1.3 Organização do Trabalho

Esta dissertação está organizada da seguinte forma. No capitulo 2 consta o referencial teórico, características de serviços de diretórios e discorre sobre tolerância a falhas. No capítulo 3 são apresentados os trabalhos relacionados. Uma arquitetura de diferentes serviços de diretório LDAP replicado e sua a implementação são descritas no capítulo 4. No capítulo 5, é apresentada a avaliação do modelo proposto. As considerações finais e trabalhos futuros constam no capítulo 6.

15

2 Referencial Teórico 2.1 LDAP

Lighweight Directory Access Protocol (LDAP) é um protocolo de acesso a serviços de diretório, especificamente baseados em serviços de diretórios X 500. Especificado como um protocolo padrão definido na RFC4511 [Sermersheim 2006], o LDAP define um protocolo de comunicação que funciona sobre outros serviços de transferência orientada a conexão TCP/IP ou mais especificamente, de forma semelhante define o transporte e o formato das mensagens utilizadas por um cliente para acessar dados em um diretório X 500, mas não define o serviço de diretório em si. LDAP utiliza um modelo cliente-servidor. O cliente se conecta a servidores e faz requisições. O servidor responde a requisição e/ou indica onde o cliente pode obter informações adicionais (geralmente, outro servidor LDAP). Esta é uma característica importante de um serviço de diretório

2.1.1 Versão

A versão atual do protocolo LDAP é a 3 (v3), definida na RFC4511, “Lightweight Directory Access Protocol (LDAP): The Protocol” [Sermersheim 2006]. LDAPv3 foi desenvolvido no final da década de 1990 para substituir o LDAPv2, acrescentando as seguintes características: 

Serviços de autenticação e segurança de dados fortes via SASL, pois este oferece uma forma de adicionar mecanismos de autenticação para qualquer protocolo.



Autenticação certificada e os serviços de segurança de dados via TLS (SSL (Secure Socket Layer)) – Sessão criptografada que proporciona privacidade para as informações do diretório.



Internacionalização através do uso de Unicode – Usa um único código para evitar diferentes interpretações.

16



Referências e Continuações. A referência indica a localização da entrada em outro serviço de diretório.



Extensibilidade – A semântica e argumentos das operações LDAP existentes podem ser prorrogados. Um ou mais controles podem ser ligados a uma única mensagem LDAP.

LDAP também suporta sessão criptografada para privacidade. Todas as informações que são transferidas durante uma sessão cliente-servidor podem ser criptografadas. Tanto o protocolo SSL (Secure Socket Layer) quanto o TSL (Transport Layer Security) são suportados.

2.1.2 Estrutura de Dados LDAP

A figura 1 ilustra o diretório LDAP. Basicamente, possui uma estrutura de árvore como DIT (Directory Information Tree), onde os nós são as entradas de diretório.

Na DIT, o primeiro nó é a raiz (sufixo). Uma entrada é um conjunto de atributos e tem um nome distinto global (DN), o DN (Distinguished Name) é único, qualquer entrada deve ser diferenciada de outras entradas. Cada entrada tem um tipo e um ou mais valores. Os tipos têm nomes simples, como ‘cn’ para o nome comum ou ‘ou’ para unidades organizacionais. A DIT organiza dados por um atributo, por exemplo, pessoa, unidade organizacional ou organização. Os atributos podem ter vários valores; Outros atributos são restritos a um único valor. O ObjectClass define seus atributos membros e se estes devem estar presentes ou podem estar presentes em uma entrada. Ainda mais, a DIT determina como os dados são particionados em vários serviços, ver Figura 2. Como os dados só podem ser particionados no

17

nível do sufixo, uma estrutura de árvore de diretórios adequada é necessária para permitir que seus dados sejam distribuídos através de múltiplos servidores. O projeto da árvore do diretório também tem impacto na configuração de replicação. É possível replicar apenas partes de sua árvore de diretórios.

2.1.2 Operações LDAP

De acordo com a RFC4511 [Sermersheim 2006], LDAP tem nove operações divididas em três categorias: 1. Operações de interrogatório (pesquisa e compara): aquelas que permitem recuperar dados a partir do diretório. A operação de busca (search) permite ao cliente encontrar entradas no diretório. Além disso, o cliente pode testar se uma entrada contém ou não determinado atributo usando a operação de comparação (compare) através de pesquisas e comparações. 2. Operações de atualização (adicionar, excluir, renomear e modificar): é responsável por atualizar as informações no diretório. 3. As operações de autenticação e controle (autenticar, desautenticar e abandonar): são responsáveis pela autenticação, encerrar sessões e abandonar uma operação anterior. A operação de autenticação (bind) é usada para dar acesso ao cliente. A operação de desautenticação (unbind) é usada pelo servidor para descartar qualquer informação de autenticação, terminando qualquer operação e desconectando o cliente. A operação de abandono (abandon) permite ao cliente abandonar a sessão e faz com que o servidor LDAP não processe a operação.

18

2.1.3 Replicação LDAP

O LDAP tem o seu próprio método de replicação para aumentar a disponibilidade do serviço de diretório, os métodos com único mestre (single-master) e com múltiplos mestres (multi-master) de replicação. De acordo com a RFC4511 [Sermersheim 2006] na replicação de único mestre (single-master), todas as réplicas contêm cópias de entradas disponíveis apenas para leitura e apenas um servidor contém uma cópia de escrita de uma dada entrada de diretório (Figura 3). Portanto, somente o mestre tem permissão para executar operação de atualização, qualquer outro servidor pode executar pesquisa, comparar ou realizar uma operação de autenticação. O cliente envia a requisição para o LDAP, o pedido vai para apenas uma réplica, o mestre, esta réplica é responsável por atualizar as outras réplicas.

Na abordagem de replicação de múltiplos mestres (multi-master), o provedor replica atualizações de diretório para os consumidores; os consumidores recebem atualizações de replicação de fornecedores. Ao contrário das relações rigidamente definidas como regras, os papéis mestre/escravo, fornecedor/consumidor são bastante fluentes: replicação de atualizações recebidas em um consumidor podem ainda ser propagadas por esse consumidor para outros servidores, por isso, um consumidor pode também atuar simultaneamente como um fornecedor. Além disso, o consumidor não precisa ser um servidor LDAP propriamente dito, este pode ser apenas um cliente LDAP. Além disso, na replicação multi-master os dados estão disponíveis em mais de um servidor para fazer leitura/escrita. Como mostrado na Figura 4, o cliente envia uma operação de atualização para qualquer réplica, a atualização é então propagada para todas as réplicas

19

para manter a consistência. Portanto, todas as réplicas têm os mesmos dados. A taxa de transferência é um pouco maior do que na replicação single-master.

2.2 Tolerância a Falhas

Prevenção e remoção de falhas não são suficientes quando o sistema exige alta confiabilidade ou alta disponibilidade. Nesses casos o sistema deve ser construído usando técnicas de tolerância a falhas. Essas técnicas garantem funcionamento correto do sistema mesmo na ocorrência de falhas e são todas baseadas em redundância, exigindo componentes adicionais ou algoritmos especiais. A tolerância a falhas não dispensa as técnicas de prevenção e remoção. Sistemas construídos com componentes frágeis e técnicas inadequadas de projeto não conseguem ser confiáveis pela simples aplicação de tolerância a falhas [Weber 2002]. O termo “tolerância a falhas” foi apresentado originalmente por Avizienis em 1967 [Avizienis 1998]. Entretanto estratégias para construção de sistemas mais confiáveis já eram usadas desde a construção dos primeiros computadores [Newmann 1956]. Apesar de envolver técnicas e estratégias tão antigas, a tolerância a falhas ainda não é uma preocupação rotineira de projetistas e usuários, ficando sua aplicação quase sempre restrita a sistemas críticos e mais recentemente a sistemas de missão crítica. As técnicas de tolerância a falhas são de duas classes disjuntas:

20



mascaramento ou



detecção, localização e reconfiguração Na primeira classe, mascaramento, falhas não se manifestam como erros, pois são

mascaradas na origem. A primeira classe geralmente emprega mais redundância que a segunda e, por não envolver os tempos gastos para as tarefas de detecção, localização e reconfiguração, é a preferida para sistemas de tempo real críticos [Weber 2002].

2.2.1 Mascaramento de Falhas O mascaramento de falhas garante resposta correta mesmo na presença de falhas. A falha não se manifesta como erro, o sistema não entra em estado errôneo e, portanto, erros não precisam ser detectados, confinados e recuperados. Entretanto, em caso de falhas permanentes, a localização e o reparo da falha ainda são necessários [Weber 2002]. A diversidade é um mecanismo usual para implementação de mascaramento de falhas.

2.2.2 Diversidade

Diversidade, também chamada programação diversitária, é uma técnica de redundância usada para obter tolerância a falhas em software. A partir de um problema a ser solucionado, são implementadas diversas soluções alternativas, sendo a resposta do sistema determinada por votação (Figura 5).

A aplicação da técnica não leva em conta se erros em programas alternativos apresentam a mesma causa (por exemplo: falsa interpretação de uma especificação ou uma troca de um sinal em uma fórmula). Os erros, para poderem ser detectados, devem necessariamente se manifestar de forma diferente nas diversas alternativas, ou seja, devem ser

21

estatisticamente independentes. Experimentos comprovam que o número de manifestações idênticas (erros que assim não seriam detectados) é significativamente menor que o número total de erros [Weber 2002]. Diversidade pode ser utilizada em todas as fases do desenvolvimento de um programa, desde sua especificação até o teste, dependendo do tipo de erro que se deseja detectar (erro de especificação, de projeto, ou de implementação). Essa técnica é chamada de projeto diversitário, quando o desenvolvimento do sistema é realizado usando diversidade de metodologias e equipes, e de programação em n-versões, quando se restringe à implementação [Weber 2002]. Diversidade pode ser também usada como técnica de prevenção de falhas. Nesse último caso, várias alternativas de projeto ou de implementação são desenvolvidas para que, na fase de teste, erros eventuais possam ser localizados e corrigidos de uma forma mais simples e efetiva. No final da fase de teste, é então escolhida a alternativa em que se detectou a menor ocorrência de erros, e apenas esta alternativa é integrada ao sistema [Weber 2002]. A facilidade no reconhecimento de erros na fase de teste do sistema, a tolerância tanto de falhas intermitentes quanto de permanentes e a atuação potencial também contra erros externos ao sistema (como por exemplo: erros do compilador, do sistema operacional e até mesmo falhas de hardware) são vantagens atribuídas a programação diversitária. Entretanto, desvantagens da técnica também devem ser citadas, como o aumento dos custos de desenvolvimento e manutenção, a complexidade de sincronização das versões e o problema de determinar a correlação das fontes de erro [Weber 2002]. Enquanto pode ser provado formalmente que a redundância de elementos de hardware aumenta a confiabilidade do sistema, tal prova não existe para a diversidade em software. Vários fatores influenciam a eficácia da programação diversitária: as equipes podem trocar algoritmos entre si, os membros das equipes podem, por formação, tender a adotar os mesmos métodos de desenvolvimento, ou as equipes podem buscar suporte nas mesmas fontes. Qualquer uma dessas correlações imprevisíveis se constitui uma fonte potencial de erros [Weber 2002].

22

3 Trabalhos Relacionados Tolerância a falhas é um dos pontos cobertos pela especificação do protocolo LDAP [Harrison 2006]. Tomando como exemplo o OpenLDAP [OpenLDAP 2014], é comum implementações do LDAP oferecerem três esquemas de replicação, Single-Master, MirrorMode e Multi-Master. O primeiro, mais simples, é baseado no modelo mestre e escravos, ou seja, um único processo mestre e múltiplos processos escravos. Enquanto que as escritas de dados podem ser realizadas somente no processo mestre, as leituras podem ser realizadas em todos os processos. Naturalmente, as escritas ficam comprometidas no caso de falha do processo mestre. No modelo Single-Master tanto o processo mestre quanto os escravos toleram apenas falhas por parada. O modelo Mirror-Mode é similar ao Single-Master, com a diferença de ter dois processos mestre que cooperam na atualização dos dados. Portanto, as escritas ficam comprometidas somente quando os dois mestres falharem. Finalmente, no modelo MultiMaster todos os processos são mestres, ou seja, suportam operações de escrita. Os dados escritos num processo mestre são replicados para os outros os demais servidores. Assim como no caso do modelo Single-Master, os modelos Mirror-Mode e Multi-Mater suportam apenas falhas por paragem. Além disso, em todos os modelos, escritas realizadas num processo mestre falho são comprometidas. Caso o processo falhe durante a escrita, os dados serão perdidos. Em outras palavras, os clientes precisam tratar falhas dos processos mestre, ou seja, reencaminhar os pedidos de escrita para eventuais processos mestres não falhos. Apesar dos modelos de replicação do LDAP ajudarem a aumentar o desempenho e a disponibilidade do serviço, eles não oferecem efetivo suporte à resiliência e confiabilidade do serviço no caso de falhas da sincronização entre os processos ou no caso de falhas arbitrarias [Shoker and Bahsoun 2012]. O bftLDAP é uma das primeiras soluções a propor protocolos de tolerância a falhas arbitrárias, como o CLBFT, para garantir a consistência dos dados entre as réplicas e a disponibilidade do serviço no caso de falhas arbitrárias [Wang et al. 2006]. O bftLDAP utiliza o modelo tradicional de 3f +1 réplicas para tolerar f falhas simultâneas sem comprometer a operação do serviço. Os testes realizados com o bftLDAP apontaram que a replicação dos dados utilizando o CLBFT leva a uma sobrecarga de até 42,29% (para

23

operação de busca) em relação a um serviço LDAP simples, i.e., que não tolera falhas arbitrárias. Um segundo exemplo de implementação tolerante a falhas arbitrárias é o HBFTLDAP [Hou et al. 2006]. Apesar do HBFTLDAP criar um serviço de diretório hierárquico tolerante a falhas, com o objetivo de garantir maior escalabilidade, os resultados, em termos de desempenho, são idênticos ao bftLDAP. Mais recentemente, diferentes protocolos para tolerar falhas arbitrárias em serviços LDAP foram testados, como o PBFT [Castro and Liskov 1999], Chain [Guerraoui et al. 2010], Zyzzyva [Kotla et al. 2007] e o Quorum [Guerraoui et al. 2010], foram testados por Shoker e Bahsoun [Shoker and Bahsoun 2012]. Considerando apenas funções de busca, as implementações BFTLDAP com os protocolos PBFT e Zyzzyva atingiram um desempenho similar ao do OpenLDAP. Este apresenta um desempenho 5% melhor que o BFTLDAP/Zyzzyva e 10% melhor que o BFTLDAP/PBFT para mensagens pequenas, ou seja, apenas ligeiramente superior. No caso de mensagens maiores, a diferença de desempenho reduz ainda mais, ou seja, as implementações com suporte a falhas arbitrárias atingem praticamente o mesmo número de operações por segundo do OpenLDAP, girando em torno de 1200 operações por segundo. A Tabela 1 resume as principais características das soluções existentes, bem como da solução proposta. Enquanto que o OpenLDAP necessita f +1 réplicas para tolerar falhas por parada, todas as soluções que toleram falhas arbitrárias (parcialmente ou totalmente) utilizam 3f+1 réplicas para tolerar f falhas sem comprometer a operação do serviço. A única solução projetada para suportar múltiplas implementações (e.g., OpenLDAP, OpenDJ e ApacheDS) de serviços LDAP é o modelo proposto. As demais soluções, como bftLDAP, HBFTLDAP e BFTLDAP, utilizam apenas o OpenLDAP e suportam (parcialmente) falhas arbitrárias. Tomando como exemplo um bug de implementação no serviço LDAP, com exceção da solução proposta, nenhuma das soluções existentes é capaz de efetivamente suportar esse tipo de falha, ou seja, quaisquer falhas arbitrárias. Além disso, a solução proposta por este trabalho é a única projetada para tolerar intrusões.

24

Resumidamente, os principais diferenciais da solução proposta, quando comparada às soluções existentes, são: (1) maior disponibilidade, resistindo a diferentes tipos de falhas físicas e lógicas (e.g., bugs de implementação e ataques paralelos); (2) resistência a ataques de exaustão de recursos, uma vez que as réplicas podem ser instanciadas em diferentes máquinas físicas e/ou domínios administrativos; (3) capacidade de tirar vantagem de ambientes multidata center e multi-cloud, usufruindo dos respectivos mecanismos de defesa dessas infraestruturas, como mecanismos de mitigação de ataques de negação de serviços [Prince 2013, Kreutz and Feitosa 2014]; e (4) maior desempenho, atingindo um número de operações por segundo ligeiramente superior ao BFTLDAP, como pode ser visto na Seção 5.

25

4 Arquitetura e Implementação 4.1 Arquitetura

Recentemente, foram propostos e sistematizados um modelo funcional, artefatos de sistema e técnicas essenciais necessárias para o projeto, implementação e implantação de infraestruturas de autenticação e autorização (AAI) mais seguras e confiáveis [Kreutz et al. 2014d, Kreutz et al. 2014a]. A arquitetura proposta, ilustrada na Figura 1, segue e estende o modelo proposto para serviços de diretórios LDAP. Os componentes e mecanismos adotados, descritos na arquitetura e implementação permitem ao modelo proposto tolerar falhas arbitrárias e intrusões em serviços de diretório LDAP. O modelo funcional da arquitetura pode ser resumido em quatro elementos: (a) cliente; (b) gateway; (c) réplicas SMR (State Machine Replication); e (d) serviços de diretório LDAP. O conjunto dos gateways, réplicas e serviços de diretório LDAP formam a infraestrutura.

O cliente representa um usuário ou serviço que tenta acessar alguma informação do diretório LDAP. Em termos práticos, o cliente é uma aplicação de autenticação, por exemplo. Em relação a outras soluções como o BFTLDAP [Shoker and Bahsoun 2012], o modelo proposto apresenta um novo componente, mais simples e transparente, o gateway. Uma das principais funções do gateway é manter compatibilidade com os clientes existentes. Em outras palavras, o gateway é visto como um servidor LDAP convencional pelos clientes, não sendo necessário qualquer tipo de modificação nos clientes. A segunda função do gateway é mascarar o protocolo de replicação BFT-SMaRt e outros mecanismos utilizados para tolerar falhas arbitrárias e intrusões em diretórios LDAP.

26

Ao receber a requisição do cliente, o gateway verifica se é uma requisição LDAP e então encapsula os dados no protocolo BFT e envia para as 3f + 1 réplicas do sistema. Similarmente, a resposta das réplicas é enviada aos respectivos clientes. Em outras palavras, o gateway atua de forma análoga a um gateway de rede, repassando dados de um lado para outro sem a necessidade dos processos comunicantes conhecerem os diferentes segmentos de rede. Por fim, o gateway pode também agregar funcionalidades adicionais, como a função de barreira de defesa (e.g, firewall), limitando as atividades maliciosas dos clientes. O papel das réplicas SMR é processar as requisições dos clientes de forma determinista e ordenada. Por isso da necessidade de protocolos de replicação de máquinas de estado, como é o caso do BFT-SMaRt. As réplicas podem conectar-se a um único serviço ou a múltiplos serviços de LDAP. Entretanto, o cenário mais comum é cada réplica estar associada a um único servidor LDAP. Além disso, tanto a réplica quanto o serviço de diretórios LDAP podem ser instanciados na mesma máquina por questões de desempenho e segurança. No caso de ambos os componentes estarem na mesma máquina, não é necessário a utilização de canais cifrados (e.g., LDAPS) entre a réplica e o servidor LDAP, por exemplo. Finalmente, o serviço de diretório LDAP pode ser parte integrante do domínio local ou ainda um serviço prestado por terceiros, i.e., localizado geograficamente em outro domínio. Isso aumenta a flexibilidade e robustez do modelo proposto, uma vez que múltiplas infraestruturas físicas podem ser utilizadas para aumentar a disponibilidade do sistema e a resistência contra diferentes tipos de ataques. Múltiplos domínios e infraestruturas físicas são um importante aliado contra ameaças avançadas, para aumentar a disponibilidade do sistema, para evitar problemas de vendor lock-in em provedores de nuvem, entre outros [Kreutz et al. 2014d, Kreutz et al. 2014c, Kreutz and Feitosa 2014]. Duas das principais características, que também representam um diferencial em relação às soluções existentes são: o suporte a diversidade em diretórios LDAP e a capacidade de tirar proveito das vantagens de diferentes cenários de implantação. Ambas as características contribuem para aumentar a disponibilidade do sistema e tolerar falhas arbitrárias (de uma maneira geral e abrangente) e intrusões. Suporte a diversidade em diretórios LDAP. O princípio básico da diversidade é evitar que falhas comuns (e.g., bugs de software ou hardware) e vulnerabilidades possam ser exploradas por atacantes. Como exemplo prático, assumindo um sistema replicado de diretórios LDAP para tolerar falhas arbitrárias que utilize o mesmo serviço LDAP em todas as réplicas, como é

27

o caso do bftLDAP, HBFTLDAP e BFTLDAP, uma única vulnerabilidade na implementação do serviço permitirá ao usuário malicioso realizar um ataque paralelo e comprometer simultaneamente todas as réplicas. Similarmente, um bug de implementação também irá (potencialmente) afetar todas as réplicas ao mesmo tempo uma vez que protocolos de replicação de máquinas de estado são utilizados nas réplicas. De forma similar, o conceito de diversidade pode ser aplicado a diferentes níveis, desde hardware (e.g., utilizar diferentes infraestruturas físicas) até sistemas operacionais, bibliotecas e aplicações. No caso do modelo aqui proposto, o conceito de diversidade é estendido a todos os componentes do sistema (gateway, réplica e serviço LDAP). É assumido que a diversidade pode ser atingida com diferentes: (i) sistemas operacionais; (ii) implementações do serviço LDAP (e.g., OpenLDAP, ApacheDS, 389Directory e OpenDJ); (iii) hypervisors (e.g., Xen, VirtualBox e VMWare); e (iv) infraestruturas físicas (e.g, diferentes máquinas físicas, data centers ou provedores de nuvem). A arquitetura e implementação do modelo proposto foram especialmente pensadas para os casos (ii) e (iv), ou seja, o suporte a múltiplas implementações LDAP e infraestruturas físicas. As outras formas de diversidade podem ser consideradas como comuns, ou seja, facilmente aplicáveis às soluções existentes uma vez que não interferem na arquitetura e nem na implementação do sistema. Suporte a implantação em diferentes cenários. O modelo proposto foi arquitetado e implementado para permitir que os gateways, as réplicas e os serviços de diretório LDAP sejam instanciados em quaisquer lugar. Mais especificamente, diferentes máquinas físicas em um único domínio, múltiplas máquinas físicas em diferentes domínios, múltiplos data centers, ou ainda múltiplos provedores de nuvem. Essa característica permite ao sistema tolerar uma vasta gama de falhas físicas (e.g., problemas de conexão de rede, falhas de energia e falhas de disco) e lógicas (e.g., erros de configuração de sistemas/redes e ataques de negação de serviço). Adicionalmente, a implantação em múltiplas infraestruturas físicas contribui para garantir altos níveis de disponibilidade e fornecer mecanismos extras de proteção para contra diferentes tipos de ataques de exaustão de recursos, DDoS (Distributed Denial of Service) em grande escala, e assim por diante [Kreutz et al. 2014d, Kreutz et al. 2014c, Kreutz and Feitosa 2014]. Vale a pena ressaltar que a implantação do sistema em diferentes infraestruturas físicas permite atingir níveis de desempenho bons o suficiente para suportar demandas corriqueiras de instituições de diferentes portes, como demonstrado anteriormente [Kreutz et al. 2014c, Kreutz and Feitosa 2014, Kreutz et al. 2014a].

28

4.2 Modelo e Suposições

Em primeiro lugar, é assumido um modelo de sincronia parcial, ou seja, o sistema pode se comportar de forma assíncrona por algum tempo, até que se torne síncrono, quando haverá algum processamento desconhecido e limites de tempo de comunicação. Este é um requisito essencial para garantir o término dos protocolos de consenso, um alicerce fundamental para a implementação de replicação máquina de estado. É assumido que os gateways conseguem comunicar-se com todas as réplicas SMR através do protocolo BFT-SMaRt. Ao receber um pacote de um cliente, o gateway encapsula os dados no protocolo BFT e enviada para as réplicas. O gateway aguarda a resposta correta (igual) de 2fR +1 réplicas antes de responder ao cliente. Com relação ao modelo de falhas, são assumidas falhas por parada no gateway, até fG gateways, e falhas arbitrárias nas réplicas SMR (fR) e serviços LDAP (fL). Não é assumido nada em relação aos clientes, ou seja, o sistema suporta um número ilimitado de clientes. Por último, em relação ao modelo de ameaça, assume-se que um atacante pode: (i) comprometer simultaneamente até fG gateways, fR réplicas, e fL diretórios LDAP, respectivamente; (ii) interceptar e injetar mensagens; e (iii) alterar mensagens em trânsito. A proposta deste trabalho considera um modelo de ameaça onde o atacante pode ter controle dos canais de comunicação entre os elementos do sistema. No entanto, é assumido que o atacante não é capaz de quebrar quaisquer mecanismos criptográficos sem obter as chaves criptográficas adequadas. Um atacante pode ainda ter o controle da rede por algum tempo, mas não pode controlar toda a rede durante todo o tempo. Esta é uma suposição razoável, já que todos os elementos do sistema, incluindo réplicas, podem estar em execução em diferentes infraestruturas físicas e, consequentemente, é altamente improvável que um atacante obtenha controle sobre os canais de comunicação ou recursos em lugares distintos.

4.3 Implementação

Na implementação foram utilizadas as bibliotecas UnboundID LDAP [UnboundID 2015] (versão 0.9.8), que suporta a versão 3 do protocolo LDAP, e a biblioteca BFT-SMaRt [bft smart 2015] para replicação de máquina de estados. Esta biblioteca fornece um conjunto

29

de módulos e protocolos de comunicação para assegurar canais de comunicação seguros e eficientes entre as réplicas. A Figura 6 ilustra a implementação do modelo proposto. Os clientes se comunicam com os gateways através de TCP/IP (Transmission Control Protocol/Internet Protocol), assim como ocorre com servidores LDAP tradicionais. Para fins de testes, foi implementado uma aplicação cliente utilizando a biblioteca UnboundID LDAP. Esta aplicação realiza operações (e.g., consultas) no diretório LDAP.

O gateway recebe as conexões dos clientes (via TCP, na porta 389) e simplesmente as repassa à interface BFT proxy do BFT-SMaRt. O BFT proxy envia, de forma ativa, uma cópia das requisições dos clientes para cada réplicas SMR. De maneira similar, respostas vindas das réplicas são enviadas aos clientes através dos canais TCP/IP previamente estabelecidos. Uma réplica SMR mantém um arcabouço de conexões com um ou mais serviços de diretório LDAP. Ao receber a requisição do cliente, encaminhada pelo gateway, a réplica encaminha a requisição para o(s) respectivo (s) servidor(es) LDAP. O servidor LDAP pode ser qualquer implementação LDAP disponível, desde que suporte a versão 3 do protocolo. Após executar a operação requisitada, a réplica SMR encaminha a resposta do serviço LDAP ao gateway. Ao receber 2fR + 1 respostas idênticas, o gateway envia a resposta ao respectivo cliente. Caso não haja 2fR + 1 respostas idênticas, o proxy BFT reenvia a requisição original às réplicas SMR.

30

5 Avaliação Esta apresenta uma avaliação de desempenho do modelo proposto e uma análise em relação a diferentes ataques e tipos de falhas.

5.1 Desempenho

Para a avaliação de desempenho do modelo posposto foi utilizando um ambiente composto por seis máquinas virtuais (VMs), como resumido na Tabela 2. Uma para executar os clientes e uma segunda para executar um gateway. Adicionalmente, mais quatro VMs para executar as réplicas SMR e os serviços de diretório LDAP, sendo uma réplica e um serviço de diretório por VM.

Para os testes foram utilizadas duas implementações LDAP, o OpenLDAP (versão 2.4.31) e o OpenDJ xpress (versão 2.5.0). Cada uma das quatro instâncias de serviços de diretório foi povoada com 45000 entradas. Duas réplicas SMR foram conectadas à implementação OpenLDAP, enquanto as outras duas foram conectadas à implementação OpenDJ. Vazão do sistema. O desempenho do modelo foi medido em duas configurações distintas, uma utilizando apenas o OpenLDAP em todas as réplicas e a outra utilizando diversidade (OpenLDAP e OpenDJ). A Figura 8 apresenta os resultados dos experimentos no ambiente sem diversidade. Foram utilizados 10, 25, 50 e 100 clientes simultâneos, executados na VM clientes (Tabela 2). Cada cliente foi configurado para realizar 1.000 operações de busca com tamanhos de mensagem variando de 1byte a 512bytes. Conforme outros trabalhos de avaliação de desempenho de diretórios LDAP, um dos tamanhos de mensagens mais comuns é de 488 bytes [Wang et al. 2008], o qual foi incluído nas avaliações realizadas. Para cada configuração de cliente, foram realizadas 5 execuções. Como pode ser observado na Figura 8, a diferença de desempenho é pequena com a variação dos tamanhos das mensagens e o número de clientes. Tal fato é explicado por uma

31

das características da biblioteca BFT-SMaRt, que é operar garantindo o ordenamento total das mensagens (Total Order Multicast) [Bessani et al. 2014b]. Durante a execução normal, os clientes enviam seus pedidos para todas as réplicas, em lote, e esperam por suas respostas. O ordenamento total é realizado através de uma sequência de instâncias de consenso entre as réplicas.

No melhor caso, com 100 clientes e mensagens de 64 bytes, a vazão do sistema chega próximo a 1400 operações por segundo. Essa vazão é superior à dos trabalhos, como o BFTLDAP, cujo desempenho, no melhor caso, chega a 1200 operações por segundo. Cabe ressaltar que a proposta atinge um desempenho de 1400 operações no pior caso, que são operações totalmente ordenadas e serializadas nas réplicas. Este tipo de operação é necessária somente para operações de escrita, para manter a consistência forte dos dados. As operações de leitura, como é o caso das buscas, podem ser executadas de forma não ordenada e não serializada. O BFT-SMaRt suporta este tipo de operação. Um dos trabalhos futuro é avaliar os limites do sistema em termos de escalabilidade e desempenho. A Figura 9 mostra os resultados do sistema no ambiente com diversidade (2 servidores OpenLDAP e 2 servidores OpenDJ). Como pode ser observado, a vazão do sistema é similar à do ambiente sem diversidade. Devido a isso, pode-se concluir que a diversidade de diretórios LDAP não tem qualquer impacto negativo no desempenho do sistema.

32

33

5.2 Falhas e Ataques

Servidores de diretório LDAP tradicionais (e.g., OpenLDAP e OpenDJ) não toleram falhas arbitrárias. Soluções como o bftLDAP, HBFTLDAP e BFTLDAP suportam apenas parcialmente falhas arbitrárias (vide Seção 3). Já a solução proposta, além de tolerar falhas arbitrárias nas réplicas, suporta diversidade de serviços de diretório, o que permite tolerar quaisquer falhas arbitrárias no sistema (e.g., bugs de implementação dos serviços LDAP). Como o modelo proposto utiliza o mesmo modelo funcional do R-RADIUS e do ROpenID [Kreutz et al. 2014d, Kreutz et al. 2014a] e, também, os mesmos protocolos de tolerância a falhas, como é o caso do BFT-SMaRt, ele tolera os mesmos tipos de falhas e ataques. Em outras palavras, o modelo proposto suporta falhas por parada em fG e falhas arbitrárias em até fR réplicas. As falhas arbitrárias incluem quaisquer anomalias de protocolo, falhas de infraestruturas e ataques como negação de serviço e exaustão de recursos. O impacto desse tipo de falhas e ataques no sistema já foi demonstrado em detalhes anteriormente [Kreutz et al. 2014a, Kreutz et al. 2014c].

34

6 Considerações Finais Este trabalho apresenta um modelo de serviço de diretório tolerante a falhas arbitrárias e intrusões, que combina diferentes técnicas de sistemas distribuídos, dependabilidade e segurança. Como forma de validar a arquitetura proposta, foi implementado e avaliado um protótipo. Os resultados de desempenho desta proposta são ligeiramente superiores aos dos trabalhos relacionados, como é o caso do BFTLDAP. Enquanto que o BFTLDAP atinge uma vazão de 1200 operações de busca por segundo, o desempenho da proposta deste trabalho atinge no pior caso, aproximadamente 1400 operações por segundo. Além disso, a solução proposta é a única a tolerar falhas arbitrárias e intrusões. Um dos componentes essenciais para atingir este objetivo é o uso da diversidade de serviços de diretório LDAP, o que garante maior robustez e resistência ao sistema. Já os trabalhos relacionados toleram apenas parcialmente falhas arbitrárias. Com trabalhos futuros, podem ser relacionados testes da arquitetura em outros ambientes, identificar os limites de desempenho e escalabilidade do sistema (e.g., incluindo operações de busca sem ordenação total e serialização) e aumentar a diversidade através de outras implementações de serviços de diretórios.

35

7 Referências Ardizzone, V., Barbera, R., Calanducci, A., Fargetta, M., Ingrà, E., La Rocca, G., Monforte, S., Pistagna, F., Rotondo, R., and Scardaci, D. (2011). A european framework to build science gateways: Architecture and use cases. In Proceedings of the 2011 TeraGrid Conference: Extreme Digital Discovery, TG ’11, pages 43:1– 43:2, New York, NY, USA. ACM. Bessani, A. (2011). From byzantine fault tolerance to intrusion tolerance (a position paper). In Dependable Systems and Networks Workshops (DSN-W), 2011 IEEE/IFIP 41st International Conference on, pages 15–18. Bessani, A., Mendes, R., Oliveira, T., Neves, N., Correia, M., Pasin, M., and Verissimo, P. (2014a). Scfs: a shared cloud-backed file system. In Proc. of the 2014 USENIX Annual Technical Conference. Bessani, A., Sousa, J., and Alchieri, E. (2014b). State machine replication for the masses with bft-smart. In Dependable Systems and Networks (DSN), 2014 44th Annual IEEE/IFIP International Conference on, pages 355–362. bft smart (2015). Bft-smart. http://bft-smart.github.io/library/. Borsato, L., Gaudet, M., Hamilton, I., Anderson, R., andWaters, G. (2003). Trusted network binding using ldap (lightweight directory access protocol). US Patent 6,654,891. BOYD, A. (2014). It security shifts from prevention to resiliency. http://goo.gl/01poFz. Brandão, L. and Bessani, A. (2012). On the reliability and availability of replicated and rejuvenating systems under stealth attacks and intrusions. Journal of the Brazilian Computer Society, 18(1):61–80. Castro, M. and Liskov, B. (1999). Practical byzantine fault tolerance. In Proceedings of the Third Symposium on Operating Systems Design and Implementation, OSDI ’99, pages 173–186, Berkeley, CA, USA. USENIX Association. Ficco, M. and Rak, M. (2012). Intrusion tolerance of stealth dos attacks to web services. In Gritzalis, D., Furnell, S., and Theoharidou, M., editors, Information Security and Privacy Research, volume 376 of IFIP Advances in Information and Communication Technology, pages 579–584. Springer Berlin Heidelberg.

36

Flechl, M. and Field, L. (2008). Grid interoperability: joining grid information systems. Journal of Physics: Conference Series, 119(6):062030. Goche, M. and Gouveia, W. (2014). Why cyber security is not enough: You need cyber resilience. http://goo.gl/jNZ3Bw. Guerraoui, R., Kneževic, N., Quéma, V., and Vukolic, M. (2010). The next 700 bft protocols. In Proceedings of the 5th European conference on Computer systems, pages 363–376. ACM. Harrison, R. (2006). Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms. RFC 4513 (Proposed Standard). Hou, H., Wang, X., and Wu, M. (2006). Hierarchical byzantine fault tolerant secure ldap. In IEEE SMC’06, pages 3844–3849. Howes, T. A., Smith, M. C., and Good, G. S. (2003). Understanding and Deploying LDAP Directory Services. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2 edition. Karatsiolis, V., Lippert, M., and Wiesmaier, A. (2004). Using ldap directories for management of pki processes. In Public Key Infrastructure, pages 126–134. Springer. Kotla, R., Alvisi, L., Dahlin, M., Clement, A., and Wong, E. (2007). Zyzzyva: speculative byzantine fault tolerance. In ACM SIGOPS Operating Systems Review, volume 41, pages 45–58. ACM. Kreutz, D., Bessani, A., Feitosa, E., and Cunha, H. (2014a). Towards secure and dependable authentication and authorization infrastructures. In Dependable Computing (PRDC), 2014 IEEE 20th Pacific Rim International Symposium on, pages 43–52. IEEE. Kreutz, D. and Feitosa, E. (2014). Identity providers-as-a-service built as cloud-ofclouds: challenges and opportunities. In Position Papers of the 2014 Federated Conference on Computer Science and Information Systems, pages 101–108. Kreutz, D., Feitosa, E., and Cunha, H. (2014b). Provedores de identidade resilientes e confiáveis. In Anais do XXXII SBRC - XV WTF, pages 174–187. Kreutz, D., Feitosa, E., Cunha, H., Niedermayer, H., and Kinkelin, H. (2014c). Increasing the resilience and trustworthiness of openid identity providers for future networks and services. In ARES 2014, pages 317–324.

37

Kreutz, D., Malichevskyy, O., Feitosa, E., Barbosa, K. R. S., and Cunha, H. (2014d). System design artifacts for resilient identification and authentication infrastructures. In ICNS. IARIA. Kushner, D. (2013). The real story of stuxnet. IEEE Spectrum, 50(3):48–53. Malichevskyy, O., Kreutz, D., Pasin, M., and Bessani, A. (2012). O vigia dos vigias: um serviço radius resiliente. In INForum. OpenLDAP (2014). OpenLDAP Software 2.4 Administrator’s Guide. Park, J., Ahn, G.-J., and Sandhu, R. (2002). Role-based access control on the web using ldap. In Olivier, M. and Spooner, D., editors, Database and Application Security XV, volume 87 of IFIP - The International Federation for Information Processing, pages 19–30. Springer US. Prince, M. (2013). The DDoS that almost broke the internet. http://goo.gl/oeDrMY. Sermersheim, J. (2006). Lightweight Directory Access Protocol (LDAP): The Protocol. RFC 4511 (Proposed Standard). Shoker, A. and Bahsoun, J.-P. (2012). Towards byzantine resilient directories. In Proceedings of NCA ’12, pages 52–60. Sousa, P., Bessani, A. N., Correia, M., Neves, N. F., and Verissimo, P. (2007). Resilient intrusion tolerance through proactive and reactive recovery. In Proceedings of PRDC ’07, pages 373–380. Tankard, C. (2011). Advanced Persistent threats and how to monitor and deter them. Network Security, (8). UnboundID (2015). Unboundid ldap sdk for java. https://www.ldap.com/unboundid-ldap-sdkfor-java. Vasiliadis, D., Rizos, G., Stergiou, E., and Margariti, S. (2007). A trusted network model using the lightweight directory access protocol. In Proceedings of AIC, pages 252–256. Verissimo, P., Neves, N., Cachin, C., Poritz, J., Powell, D., Deswarte, Y., Stroud, R., and Welch, I. (2006). Intrusion-tolerant middleware: the road to automatic security. Security Privacy, IEEE, 4(4):54–62. Wang, X., Hou, H., and Zhuang, Y. (2006). Secure byzantine fault tolerant ldap system. In Proceedings of IMSCCS ’06, pages 34–39.

38

Wang, X., Schulzrinne, H., Kandlur, D., and Verma, D. (2008). Measurement and analysis of ldap performance. Networking, IEEE/ACM Transactions on, 16(1):232–243. Zhou, W. and Meinel, C. (2004). Implement role based access control with attribute certificates. In Advanced Communication Technology, 2004. The 6th International Conference on, volume 1, pages 536–540. Weber, T. S. (2002). Um roteiro para exploração dos conceitos básicos de tolerância a falhas. (Desenvolvimento de material didático ou instrucional - Notas de aula). VON NEWMANN, J. Probabilistic logics and the synthesis of reliable organisms from unreliable components. In: Automata Studies, Shannon & McCarthy eds. Princeton Univ. Press, 1956. p. 43-98. AVIZIENIS, A. Infraestructure-based design of fault-tolerant systems. In: Proceedings of the IFIP International Workshop on Dependable Computing and its Applications. DCIA 98, Johannesburg, South Africa, January 12-14, 1998. p. 51-69.