Um Modelo Funcional para Serviços de Identificação e Autenticação Tolerantes a Faltas e Intrusões

Please download to get full document.

View again

All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
 4
 
  The correct and continuous operation of identity providers and access control services is critical in new generations of networks and online systems, such as virtualized networks and on-demand services of cloud computing. In this perspective, this
Share
Transcript
  Um Modelo Funcional para Servic¸os de Identificac¸ ˜ ao eAutenticac¸ ˜ ao Tolerantes a Faltas e Intrus ˜ oes Diego Kreutz 1 , Eduardo Feitosa 2 , Oleksandr Malichevskyy 1 Kaio R. S. Barbosa 2 , Hugo Cunha 21 LaSIGE/FCUL, Universidade de Lisboa, Portugal { kreutz,olexmal } @lasige.di.fc.ul.pt 2 Instituto de Computac¸˜ao, UFAM, Manaus, Brasil { efeitosa,kaiorafael,hugo.cunha } @icomp.ufam.edu.br  Abstract.  The correct and continuous operation of identity providers and accesscontrol services is critical in new generations of networks and online systems,such as virtualized networks and on-demand services of cloud computing. Inthis perspective, this paper proposes and demonstrates a functional model for architectures of identification and authentication services that are fault- and intrusion-tolerant. The feasibility and applicability of the model are evaluated through prototypes implemented for OpenID and RADIUS services. The resultsand analysis indicate that a functional model for prototyping and deployingmore resilient and reliable identification and authentication services is feasible.  Resumo.  A operac¸˜ ao correta e cont ´ ınua de provedores de identidade e servic¸osde controle de acesso s˜ ao pontos cr ´ ıticos em novas gerac¸˜ oes de redes e sistemasonline, como redes virtualizadas e servic¸os sob demanda da computac¸˜ ao em nu-vem. Nesta perspectiva, este artigo tem como objetivo propor e demonstrar ummodelo funcional para arquiteturas de servic¸os de identificac¸˜ ao e autenticac¸˜ aotolerantes a faltas e intrus˜ oes. A viabilidade e aplicabilidade do modelo s˜ aoavaliadas atrav´ es de prot ´ otipos concretizados para os servic¸os OpenID e RA-  DIUS. Os resultados indicam que um modelo funcional para o desenvolvimentode servic¸os de identificac¸˜ ao e autenticac¸˜ ao mais resilientes e confi´ aveis ´ e vi´ avel. 1. Introduc¸ ˜ ao A proliferac¸˜ao de provedores de infraestrutura de autenticac¸˜ao e autorizac¸˜ao (AAI) vem aumentando e grande parte desse movimento se deve a necessidade de permitir queusu´arios acessem diferentes servic¸os (e.g. Facebook, Google, Twitter, Amazon) sem pre-cisar efetuar v´arias autenticac¸˜oes ou usar credenciais espec´ıficas (uma por servic¸o).Tipicamente, provedores de AAI empregam provedores de identidade e protoco-los de autenticac¸˜ao e autorizac¸˜ao para identificar o usu´ario e fornecer as informac¸˜oes ne- cess´ariasparaautorizaroacessoaorecursoousistema. Emborasejamservic¸oscomumen-temente essenciais para suportar controle de acesso em infraestruturas de redes,  clouds  e grids , a resiliˆencia e a confiabilidade desses provedores ainda representam quest˜oes emaberto. Isto ´e algo preocupante com o crescente aumento dos incidentes causados porataques digitais [Verizon RISK Team 2013]. Adicionalmente, ameac¸as avanc¸adas persis-tentes [Tankard 2011] est˜ao ganhando forc¸a e tornando-se um dos centros de atenc¸˜ao das equipes de seguranc¸a, instituic¸˜oes e governos.Em termos pr´aticos, a maioria dos servic¸os autenticac¸˜ao, autorizac¸˜ao e  accounting (AAA), baseados em RADIUS [Rigney et al. 2000], e provedores de identidade, basea- XIII Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais — SBSeg 2013 30  c  2013 SBC — Soc. Bras. de Computação  dosemOpenID[Recordon and Reed 2006], n˜aoconsideramcertaspropriedadesourecur- sos de seguranc¸a e dependabilidade, como pode ser observado em [FreeRADIUS 2012,RADIUS Partnerships 2008, Juniper Networks 2010, OpenID 2010, Clamshell 2013]. Em alguns casos (implementac¸˜oes), apenas conex˜oes SSL e esquemas simples de replicac¸˜ao (  primary-master  ) para tolerar falhas por paragem s˜ao utilizados. Consequente-mente, ainda h´a espac¸o para investigac¸˜ao e desenvolvimento de soluc¸˜oes mais resilientese confi´aveis, capazes de lidar com os novos desafios pela frente, como ataques mais fre-quentes e avanc¸ados.Neste contexto, este trabalho prop˜oe o primeiro modelo funcional para arquitetu-ras de servic¸os de identificac¸˜ao e autenticac¸˜ao tolerantes a faltas e intrus˜oes. A aplica- bilidade do modelo ´e demonstrada atrav´es de dois casos de uso, como prova de con-ceito. O artigo discute os componentes, modelos de sistema e blocos de construc¸˜aofundamentais no desenvolvimento de servic¸os tolerantes a faltas e intrus˜oes. Comple-mentarmente, s˜ao analisados aspectos sobre as vantagens e desvantagens de diferentesabordagens de implementac¸˜ao e implantac¸˜ao, como a utilizac¸˜ao de uma  versus  m´ultiplasm´aquinas f ´ısicas. O artigo est´a estruturado da seguinte forma. Na sec¸˜ao 2 ´e apresentada a motivac¸˜ao do trabalho. O modelo funcional ´e discriminado e discutido na sec¸˜ao 3. Finalmente, a sec¸˜ao 4 discute os resultados e a sec¸˜ao 5 apresenta as considerac¸˜oes finais. 2. Motivac¸ ˜ ao Servic¸osresilienteseconfi´aveisest˜aosetornandopartesessenciaisdequalquersistemadecomputac¸˜ao ou infraestrutura de rede que necessite de caracter´ısticas como elasticidade, disponibilidade, escalabilidade e confiabilidade. Sob esta perspectiva, os provedores deidentificac¸˜ao e autenticac¸˜ao s˜ao exemplos da falta de soluc¸˜oes com propriedades de re-siliˆencia e confiabilidade mais fortes.Soluc¸˜oes de identificac¸˜ao e autenticac¸˜ao s˜ao comumente baseadas em protocoloscomo RADIUS [Rigney et al. 2000] e o OpenID [Recordon and Reed 2006]. O primeiro fornece autenticac¸˜ao, autorizac¸˜ao e contabilidade para infraestrutura de redes, como redesinstitucionais, provedores de comunicac¸˜ao de dados DSL/ADSL e redes GSM/3G/4G. Osegundo ´e utilizado para autenticar usu´arios de servic¸os online em provedores de identi- dade, permitindo uma ´unica identificac¸˜ao para o acesso a diferentes servic¸os, em outraspalavras, tornando mais pratic´avel sistemas  Single Sign-On .Contudo, ambos os protocolos n˜ao foram projetados com caracter´ısticas robus-tas de seguranc¸a (e.g. confidencialidade) e dependabilidade, sendo alvos frequentesde ataques e tentativas de furto de dados (e.g. credenciais de usu´arios). O RADIUSapresenta um conjunto de vulnerabilidades decorrentes da pr´opria especificac¸˜ao ou m´a implementac¸˜ao [Feng 2009]. Em relac¸˜ao a falhas no protocolo, o RADIUS n˜ao validaa integridade de alguns pacotes ( Access-Request ), usa o algoritmo  MD5hashing para criptografar atributos e n˜ao fornece prevenc¸˜ao contra ataques de reflex˜ao ( replay ). J´ana implementac¸˜ao, o RADIUS ´e suscet´ıvel a ataques de dicion´ario,  man-in-the-middle , spoofing , entre outros. Por sua vez, o OpenID tamb´em possui uma s´erie de problemas. Pesquisas recentes mostram que ele ´e vulner´avel a ataques de  cross-site request forgery [Sun et al. 2012], al´em de  phishing ,  man-in-the-middle ,  replay , DoS e manipulac¸˜ao deparˆametros do protocolo [van Delft and Oostdijk 2010, Uruena et al. 2012]. Finalmente, existe o fato do n´umero de ameac¸as e ataques estar em crescimento XIII Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais — SBSeg 2013 31  c  2013 SBC — Soc. Bras. de Computação  cont´ınuo e o surgimento de novas ameac¸as avanc¸adas persistentes [Tankard 2011] traz preocupac¸˜oes adicionais. Hoje, a maioria dos servic¸os de rede n˜ao est´a preparada para assegurar uma correta operac¸˜ao em circustˆancias adversas, como aquelas representadaspor falhas de infraestrutura local, ataques e ameac¸as avanc¸adas.Embora existam poss´ıveis soluc¸˜oes para melhorar a seguranc¸a desses servic¸os,como o uso de t´ecnicas avanc¸adas de replicac¸˜ao, virtualizac¸˜ao e componentes seguros (e.g.  smart cards  e TPMs), essas abordagens s˜ao complexas ou utilizadas de forma iso-lada. Um exemplo ´e a utilizac¸˜ao de TPMs para criar variantes confi´aveis de sistemasde gerenciamento de identidades [Leicher et al. 2010]. Embora a soluc¸˜ao permita criar servic¸os OpenID confi´aveis, ela n˜ao suporta propridades como alta disponibilidade e to-lerˆancia a faltas ou intrus˜oes no servic¸o como um todo, focando apenas na confianc¸a daemiss˜ao dos tickets. Outro examplo ´e uma infraestrutura de coordenac¸˜ao cooperativa deservic¸os Web [Alchieri et al. 2008], que prop˜oe mecanismos de seguranc¸a que permitem uma coordenac¸˜ao confi´avel mesmo na presenc¸a de componentes maliciosos. A soluc¸˜aoproposta atua como infrastrutura integradora de servic¸os Web, contando com um conjuntode gateways de servic¸os e um espac¸o de tuplas resiliente. Embora a soluc¸˜ao oferec¸a to-lerˆancia a faltas e intrus˜oes, n˜ao representa um modelo geral para servic¸os de rede e nem oferece recursos como componentes seguros para garantir a confidencialidade de dadossens´ıveis. Isso evidencia a falta de modelos e arquiteturas de sistemas que sirvam de su-porte ao desenvolvimento de servic¸os de identificac¸˜ao e autenticac¸˜ao seguros e resilientes.A principal motivac¸˜ao para do trabalho ´e a falta de modelos funcionais, t´ecnicas e metodologias para o suporte ao desenvolvimento de servic¸os tolerantes a faltas e in-trus˜oes. Estes servic¸os, ao inv´es de resolver todos os problemas existentes, partem dopressuposto que falhas, ataques e intrus˜oes ir˜ao eventualmente ocorrer. Sendo assim, uti- lizam mecanismos capazes de manter a correta operac¸˜ao do servic¸o mesmo em casos deintrus˜oes. O modelo proposto ´e analisado e discutido a partir de dois prot´otipos. 3. Modelo Funcional Assec¸˜oesseguintesapresentamumavis˜aogeraldomodelofuncional, omodeloestendido(com mecanismos de resiliˆencia), os principais blocos de construc¸˜ao para concretizac¸˜aodo modelo, propriedades e cen´arios de uso. 3.1. Vis ˜ ao Geral A Figura 1 ilustra os componentes b´asicos do modelo funcional. Os quatro principais elementos s˜ao: (a) cliente; (b) servic¸o alvo; (c)  gateway ; e (d) Servic¸o Tolerante a Fal-tas e Intrus˜oes (STFI). Adicionalmente, o modelo permite o uso de componentes segu-ros, em qualquer um dos elementos, para fornecer propriedades/garantias adicionais detemporizac¸˜ao e/ou seguranc¸a a partes cr´ıticas da soluc¸˜ao. Cliente   Servi•o TFI (STFI)   Servi•o Alvo   Gateway   = componente seguro   Figura 1. Modelo funcional Um cliente pode ser um usu´ario tentando acessar a rede ou um dispositivo de redeque precisa consultar um controlador para tomar alguma decis˜ao sobre um novo evento XIII Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais — SBSeg 2013 32  c  2013 SBC — Soc. Bras. de Computação  registrado. J´a um servic¸o alvo ´e um elemento gen´erico. Em uma infrastrutura t´ıpica de redeelepoderepresentarcomponentescomoroteadoressemfiooucomutadoresdeacessoEthernet. No caso de uso do OpenID, o servic¸o alvo pode ser praticamente qualquer coisa,indo desde aplicac¸˜oes de gest˜ao da rede at´e sub-sistemas de controle de acesso em sites de com´ercio eletrˆonico. Na sequˆencia, o  gateway  ´e um elemento de prop´osito mais espec´ıfico. Sua fun- cionalidade prim´aria ´e prover conex˜ao entre o servic¸o alvo e o servic¸o tolerante a faltas e intrus˜oes. Consequentemente, este elemento precisa compreender diferentes protoco-los, atuando de forma similar a um  gateway  de rede entre STFIs, servic¸os alvo e clientes.Uma segunda atribuic¸˜ao do  gateway  ´e mascarar os protocolos de replicac¸˜ao e mecanismosutilizados para implementar STFIs.J´a o STFI representa o servic¸o cr´ıtico da infraestrutura, com requisitos deseguranc¸a e dependabilidade mais elevados. Um dos pressupostos ´e que estes servic¸osdevem tolerar diferentes tipos de faltas, como as Bizantinas (faltas arbitr´arias, como ascausadasporcomportamentosimprevistosouataques). Adicionalmente, ofuncionamentocorreto e seguro do servic¸o deve ser assegurado mesmo no caso de intrus˜oes. Servic¸osAAA, provedores OpenID, sistemas de monitoramento e controladores de rede s˜ao exem-plosdesistemascr´ıticoseminfraestruturasderede. Qualquerfalhaemumdessesservic¸ospode ter um grande impacto na operac¸˜ao da rede e/ou dos outros servic¸os, com potencialimpacto negativo a usu´arios e neg´ocios.Por fim, o componente seguro pode ser utilizado em qualquer um dos elementosdo modelo para garantir propriedades ou funcionalidades adicionais, como confidencia-lidade, verificac¸˜oes de integridade e garantias temporais para partes espec´ıficas dos ou-tros elementos. Por exemplo, as chaves dos usu´arios podem ser armazenadas em  smart cards . Similarmente, chaves de autoridades certificadoras (CAs) locais e de servidorespodem ser tamb´em armazenadas dentro de componentes seguros. Adicionalmente, to-das as operac¸˜oes criptogr´aficas cr´ıticas, que utilizam o material sens´ıvel armazenado deforma segura, devem ser executadas dentro do componente seguro, sem comprometer aconfidencialidade dos dados mesmo na presenc¸a de um invasor. 3.2. Agregando Toler ˆancia a Faltas e Intrus ˜ oes Como pode ser observado na Figura 2, a arquitetura geral do modelo funcional assumea existˆencia de diferentes limiares e/ou t´ecnicas de replicac¸˜ao de elementos. Os cortesverticais indicam os trˆes grupos de elementos com diferentes e independentes n´ıveis de replicac¸˜ao, propriedades de seguranc¸a e dependabilidade. Cada um dos elementos podeassumir um modelo de faltas distinto e prover garantias diferenciadas em termos de fun-cionalidades oferecidas (e.g. garantia de entrega das mensagens).Como o objetivo ´e garantir que o cliente consiga acessar o servic¸o alvo, este podeestar replicado de forma a garantir a disponibilidade do servic¸o. Pode-se assumir que areplicac¸˜ao do servic¸o alvo e do  gateway  ´e simples, ou seja, apenas para lidar com falhaspor paragem. N˜ao obstante, esses elementos podem tamb´em utilizar t´ecnicas mais sofisti-cadas como tolerˆancia a faltas arbitr´arias, que demandam algoritmos e mecanismos mais sofisticados e complexos e tˆem um custo mais elevado. Entretanto, o modelo funcionalproposto assume que faltas Bizantinas s˜ao toleradas apenas nos pontos mais cr´ıticos daarquitetura.Tanto o servic¸o alvo quanto o  gateway  podem tolerar pelo menos falhas por pa- XIII Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais — SBSeg 2013 33  c  2013 SBC — Soc. Bras. de Computação  Cliente   STFI   (m f   +1)   Servi•o Alvo ( f  S    + 1)   Gateway ( f  G   + 1)   Figura 2. Modelo funcional estendido ragem ( f  S   e  f  G , respectivamente) no processo de acesso e utilizac¸˜ao dos recursos doSTFI. Complementarmente, ambos os elementos podem suportar detecc¸˜ao de alguns ti-pos de faltas arbitr´arias, como violac¸˜ao de integridade ou autenticidade de mensagens. A verificac¸˜ao das mensagens pode ser realizada atrav´es da utilizac¸˜ao, ou n˜ao, dos com-ponentes seguros. Caso alguma informac¸˜ao criptogr´afica sigilosa seja necess´aria naverificac¸˜ao, componentes seguros devem ser utilizados. Caso contr´ario, m´etodos simples de verificac¸˜ao de pacotes podem ser aplicados.Os clientes podem conectar-se a qualquer uma das r´eplicas do servic¸o alvo (e.g.servic¸o de autenticac¸˜ao de um site de com´ercio eletrˆonico). As r´eplicas deste podemconectar-se a quaisquer r´eplicas do  gateway . O acesso `as r´eplicas dos servic¸os ou  ga-teway s pode ser baseado em informac¸˜ao contida em listas simples, como ocorre na pr´atica em protocolos do tipo AAA, ou  round-robin  para balanceamento de carga, como ´e ofere-cidonoservic¸odeDNS.Nomodeloproposton˜aoh´anecessidadeestritadebalanceamentode carga, uma vez que o maior objetivo ´e prover tolerˆancia a faltas e intrus˜oes. Sendo as- sim, em princ´ıpio, uma lista de enderec¸os das r´eplicas ´e o suficiente, seja ela provida poralgum servic¸o externo, como DNS ou algum tipo de diret´orio de descoberta, ou atrav´esde configurac¸˜ao direta dos elementos da arquitetura. Um servic¸o alvo, por exemplo, vaitentar a pr´oxima r´eplica do  gateway  toda vez que n˜ao receber uma resposta ou receberuma mensagem corrompida da r´eplica atual.O STFI foge `a excess˜ao da lista simples e m´etodo vari´avel de acesso `as r´eplicas.O  gateway  precisa conhecer todas as r´eplicas necess´arias para suportar o limite de faltasestabelecido no sistema. Tomando como exemplo uma soluc¸˜ao de  2 f   + 1  r´eplicas noSTFI, o  gateway  deve conhecer pelo menos  2 f  +1  r´eplicas de forma a assegurar que faltasarbitr´arias no STFI ser˜ao mascaradas enquanto que f   + 1  r´eplicas estiverem funcionandocorretamente.    C   l   i  e  n   t  e   C  w      S   T   F   I   B  z   S  e  r  v   i  •  o   A   l  v  o   S  x   G  a   t  e  w  a  y   G  y Timeout A   Timeout B   Resposta corrompida da rŽplica Sx   Resposta corrompida da rŽplica Gy   Comportamento Bizantino da rŽplica Bz   Figura 3. Mecanismos para detectar r´eplicas faltosas A Figura 3 ilustra os mecanismos de detecc¸˜ao de faltas entre os componentes do modelo funcional. As alternativas de detecc¸˜ao entre os clientes, servic¸os alvo e  gateway s XIII Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais — SBSeg 2013 34  c  2013 SBC — Soc. Bras. de Computação
Related Search
Similar documents
View more
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks