1 / 36

Gustavo Motta Departamento de Informática-UFPB

MACA: uma solução para autenticação de usuários e autorização de acesso em ambientes abertos e distribuídos. Gustavo Motta Departamento de Informática-UFPB. Sumário. Introdução Conceitos de controle de acesso Modelo de autorização contextual - MACA Arquitetura e implementação Resultados

ashlyn
Download Presentation

Gustavo Motta Departamento de Informática-UFPB

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. MACA: uma solução para autenticação de usuários e autorização de acesso em ambientes abertos e distribuídos Gustavo MottaDepartamento de Informática-UFPB Recife, 6 de agosto de 2004

  2. Sumário • Introdução • Conceitos de controle de acesso • Modelo de autorização contextual - MACA • Arquitetura e implementação • Resultados • Conclusão Recife, 6 de agosto de 2004

  3. Introdução • Prontuário Eletrônico do Paciente - PEP • Avanços nas tecnologias de computação e comunicação • PEP distribuído • Maior potencial de acesso à informações clínicas • Benefícios para o paciente • Ameaças à privacidade e à confidencialidade • Desafio • O controle de acesso ao PEP não pode prejudicar o atendimento ao paciente, tampouco deve facilitar a violação de sua privacidade • Dilema • PermissividadeSeveridade • Quais políticas adotar? Recife, 6 de agosto de 2004

  4. Introdução • Controle de acesso • Centrado em papéis – autoridade e responsabilidade • Perspectiva do modelo organizacional • Autorizações contextuais • Arquitetura aberta e distribuída • Administrar políticas de autenticação, autorização e impor a autenticação e o controle de acesso de modo unificado e coerente • Acesso padronizado a partir de sistemas distintos em plataformas e linguagens de programação heterogêneas • Aspectos computacionais do acesso ao PEP • Confidencialidade e a privacidade do paciente • Responsabilidade também compartilhada pelos SIHs • Desafios para aplicação no PEP distribuído • Como implementar políticas de acesso ad hoc • Formuladas com o único objetivo de atender as necessidades de controle de acesso de uma organização, levando em conta o seu ambiente e a sua cultura • Administrar políticas de autenticação, de autorização e impor o controle de acesso • PEP composto por segmentos distribuídos • Bases de dados distintas • Múltiplas aplicações • Plataformas heterogêneas • Serviços de segurançaestanques Solução Recife, 6 de agosto de 2004

  5. Security Services Introdução • Objetivo • Apresentar o MACA - Middleware de Autenticação e Controle de Acesso • Modelo de autorização contextual • Controle de Acesso Baseado em Papéis - CABP/NIST • Arquitetura de software LDAP Recife, 6 de agosto de 2004

  6. Política de Acesso Banco de Dados de Autorizações Controle de Acesso Autenticação Administrador de Segurança Monitor de Referência Usuário Objetos Auditoria Conceitos de controle de acesso Autenticação, autorização, controle de acesso e auditoria Recife, 6 de agosto de 2004

  7. Conceitos de controle de acesso • Controle de acesso baseado em papéis • Acesso regulado segundo os papéis exercidos • Um papel denota uma função organizacional • Autoridade e Responsabilidade • Adequado para aplicação ao PEP em organizações de saúde • Processos de negócio complexos • Equipes multiprofissionais • Suporta o princípio da necessidade de saber/fazer • Um usuário somente deve ter os privilégios necessários para desempenhar suas funções • Politicamente neutro Recife, 6 de agosto de 2004

  8. Conceitos de controle de acesso • Reduz o tempo para gerenciar contas e atribuição/revogação de privilégios • Para uma empresa com 100.000 empregados, produz um benefício estimado da ordem de US$934.321,00/ano • Reduz ociosidade entre a contração de um empregado e a concessão de seus privilégios • Para uma empresa com 100.000 empregados, produz um benefício estimado da ordem de US$3.436.966,00/ano; • Reduz a gravidade e a freqüência das violações de segurança nas organizações, particularmente a fraude financeira com a definição de políticas de separação de responsabilidades Fonte: NIST • Controle de acesso baseado em papéis • Separação de responsabilidades • Distribui tarefas críticas por múltiplos usuários • Minimiza conflitos de interesses • Favorece a administração da política de acesso • Visão organizacional • Facilita procedimentos de • Admissão/demissão • Realocação funcional Recife, 6 de agosto de 2004

  9. Relação pa Médico, Prescrever, PEP; Diretor Clínico, VerLogAuditoria, PEP; Auxiliar de Enfermagem, VerPrescrição, PEP; Modelos de controle de acesso Esquema do modelo de referência para o CABP do NIST Recife, 6 de agosto de 2004

  10. Modelo de autorização contextual – MACA • Motivação • Políticas de acesso ad hoc para o PEP • Enfermeiras somente podem ver registros de pacientes internados em sua enfermaria ou que lá estiveram nos últimos 30 dias • Médicos que são membros de uma equipe somente podem ver registros de pacientes sob os cuidados de algum membro da equipe • Necessárias para estabelecimentos de saúde com atendimentos em níveis secundário e terciário • Paciente cuidado por equipes multiprofissionais e multidisciplinares • Inviáveis nos modelos tradicionais de controle de acesso e no modelo de referência para CABP NIST Recife, 6 de agosto de 2004

  11. +, VerLaudo, PEP, fraca , VerLaudo, PEP, fraca Modelo de autorização contextual – MACA • Estende o CABP do NIST • Autorizações contextuais • Incorporam regras relacionando informações do contexto relevantes para decisão de permitir ou proibir o acesso • Positivas ou negativas • Conflitos • Fortes ou fracas • Fortes  políticas estritas • Fracas  políticas permissivas Recife, 6 de agosto de 2004

  12. Modelo de autorização contextual – MACA • Hierarquia de papéis • Árvore invertida • Separação de responsabilidades • Conflitos entre autorizações • Ativação automática de papéis • CABP transparente para o usuário final Recife, 6 de agosto de 2004

  13. Modelo de autorização contextual – MACA • Contexto • Qualquer informação usada para caracterizar uma entidade considerada relevante para interação entre um usuário e uma aplicação • Tipos • Variáveis  valores atômicos • usuárioCtx.registro_profissional, dtCtx.dia_semana • Conjuntos  coleção de valores determinados e diferenciáveis • dtCtx.dias_úteis, pacCtx.pacientes_internados • Funções  estabelece relações entre entidades e novos valores • pacCtx.assistido_por(umCodPac, usuárioCtx.registro_profissional) • Expressam entidades e relacionamentos do ambiente e da cultura organizacionais Recife, 6 de agosto de 2004

  14. Modelo de autorização contextual – MACA • Regras de autorização • Relacionam contextos em expressões lógicas para especificar uma política de acesso • Valores booleanos, inteiros, textos, conjuntos,  • Operadores aritméticos, de conjunto, relacionais, booleanos  • Novos valores e operadores definidos em contextos • Regras parametrizadas • Exemplo de política de acesso • Enfermeiros e seus auxiliares somente podem acessar prescrições de pacientes internados quando estão em seu turno de trabalho Recife, 6 de agosto de 2004

  15. Modelo de autorização contextual – MACA • Regras de autorização Auxiliar de Enfermagem,exp-abs(umCodPac) {umCodPac inpacCtx.pacientes_internados &usuárioCtx.está_no_turno_de_trabalho}, VerPrescrição, PEP, fraca Recife, 6 de agosto de 2004

  16. Profissional de Saúde – PS Médico , VerLaudo, PEP, forte , VerLaudo, PEP, fraca , VerLaudo, PEP, fraca , VerLaudo, PEP, fraca , VerLaudo, PEP, fraca , VerLaudo, PEP, forte , VerLaudo, PEP, fraca , VerLaudo, PEP, forte , VerLaudo, PEP, fraca , VerLaudo, PEP, forte , VerLaudo, PEP, fraca , VerLaudo, PEP, fraca +, VerLaudo, PEP, fraca +, VerLaudo, PEP, fraca +, VerLaudo, PEP, fraca +, VerLaudo, PEP, fraca +, VerLaudo, PEP, fraca +, VerLaudo, PEP, fraca +, VerLaudo, PEP, fraca , VerLaudo, PEP, fraca , VerLaudo, PEP, fraca , VerLaudo, PEP, fraca , VerLaudo, PEP, fraca Médico Assistente Cirurgião Clínico Médico Auditor Paramédico Auxiliar de Enfermagem Enfermeiro Nutricionista Pesquisador Clínico Modelo de autorização contextual – MACA • Hierarquia de papéis • Estrutura de árvore invertida • Herança de autorizações • Adição de conceitos • Revogação de autorizações • Mecanismos • Sobreposição de autorizações • Definição de autorizações fortes • Disciplinado pelo tipo da autorização • Forte  irrevogável • Fraca  revogável • Autorizações válidas • Autorizações associadas direta ou indiretamente a um papel e que não estão revogadas • Únicas usadas para decidir um acesso Recife, 6 de agosto de 2004

  17. Modelo de autorização contextual – MACA • Separação de responsabilidades • Particiona compulsoriamente a responsabilidade e a autoridade para realizar ações em que há conflitos de interesses • Baseadas em conflitos entre autorizações • Fortes  denotam conflitos de interesses • Médico Assistente, +, Prescrever, PEP, forteMédico Auditor, —, Prescrever, PEP, forte • Fracos  representam diferentes necessidades funcionais • Médico Assistente, +, VerDadosIdentificação, PEP, fracaPesquisador Clínico, —, VerDadosIdentificação, PEP, fraca Recife, 6 de agosto de 2004

  18. Modelo de autorização contextual – MACA • Separação de responsabilidades • Política de resolução de conflitos • Conflitos fortes  prevalece a autorização que proíbe o acesso • Visa atender a separação de responsabilidades • Médico Auditor e Médico Assistente • —, Prescrever, PEP, forte • Conflitos fracos  prevalece a autorização que permite o acesso • Visa atender o princípio da necessidade de saber/fazer • Pesquisador Clínico e Médico Assistente • +, VerDadosIdentificação, PEP, fraca Recife, 6 de agosto de 2004

  19. Profissional de Saúde – PS Médico +, Entrar, PEP, fraca; +, VerPrescrição, PEP, fraca;+, VerDadosIdentificação, PEP, fraca sessão, Entrar, PEP, (); sessão, VerDadosIdentificação, PEP, (“2-I”); sessão, Prescrever, PEP, (“123456-H”); , Prescrever, PEP, forte; +, GlosarPrescrição, PEP, forte; , VerDadosIdentificação, PEP, fraca +, Prescrever, PEP, forte; , GlosarPrescrição, PEP, forte; Médico Assistente Cirurgião Clínico Médico Auditor Paramédico ... Enfermeiro Nutricionista Pesquisador Clínico   Modelo de autorização contextual – MACA • Algoritmo de decisão de acesso • Determina se o usuário de uma sessão tem permissão para acessar objetos protegidos a fim de executar uma operação específica • Somente autorizações válidas • Avaliação das regras no contexto da tentativa de acesso • Prioridade das autorizações fortes sobre as fracas • Ativação automática de papéis independente da separação de responsabilidades • Política de resolução de conflitos • Concilia o princípio da necessidade de saber/fazer com a limitação de acessos que resultem em conflitos de interesses Recife, 6 de agosto de 2004

  20. Profissional de Saúde – PS Médico exp-abs(umCodPac, umCodPresc){ pacCtx.plano_saude_presc(umCodPac, umCodPresc) in usuárioCtx.convenios } , VerPrescrição, PEP, fraca , Prescrever, PEP, forte; +, GlosarPrescrição, PEP, forte; +, Prescrever, PEP, forte; , GlosarPrescrição, PEP, forte; +, Entrar, PEP, fraca; +, VerPrescrição, PEP, fraca;+, VerDadosIdentificação, PEP, fraca Médico Assistente Cirurgião Clínico Médico Auditor Paramédico ... Auxiliar de Enfermagem Enfermeiro Nutricionista , VerDadosIdentificação, PEP, fraca Pesquisador Clínico Modelo de autorização contextual – MACA • Contribuições para aplicação ao PEP • Reforça o princípio da necessidade de saber/fazer • Mais privacidade para o paciente • Menos acessos supérfluos • Adaptação ao ambiente e a cultura das org. saúde • Poder expressivo e flexibilidade das regras de autorização • Políticas de acesso ad hoc • Isola a lógica de autorização dos componentes do PEP • Facilidade de uso do PEP • CABP transparente para o usuário final • Administração viável da política de acesso ao PEP • Estruturas organizacionais – autonomia e descentralização Recife, 6 de agosto de 2004

  21. {transiente} pa : Principal : Credentials ado : Access maca ldap : : c : Cliente Authenticator Decision MACAService LDAPServer authenticate(login, pwd, ...) bind(login, pwd ) new Credentials(ldap_conx) addNewSession(creds) {autenticado} get_attributes(...) hasAccess (opr, obj, params, session_ref) access_allowed(obj, opr, session_ref) search(...) {acesso permitido ou negado} destroy( ) closeSession(creds) unbind(...) {sessão ence rrada} x Arquitetura e implementação • Baseada em padrões abertos e distribuídos • Acesso para componentes do PEP em plataformas heterogêneas • Mais interoperabilidade • Políticas de acesso e de autenticação unificadas e coerentes • Cliente/servidor multicamada • Base de informações de gerência da segurança • Servidor de autenticação e de autorização • Aplicações clientes componentes do PEP Arquitetura de Software para integração do MACA Recife, 6 de agosto de 2004

  22. dn: cn=Médico,cn=Profissional de Saúde,cn=usuario,cn=Papeis,ou=Groups,dc=incor,dc=usp,dc=brobjectClass: topobjectClass: incorroleobjectClass: incorgroupcn: Profissional de Saúdedescription: representa as funções e responsabilidades dos médicos.member: uid=maria.augusta,ou=people,dc=incor,dc=usp,dc=brmember: uid=josé.antônio,ou=people,dc=incor,dc=usp,dc=br dn: cn=autorização 1,ou=usuario,ou=Authorizations,dc=incor,dc=usp,dc=brobjectClass: topobjectClass: incorauthorizationincorprivilegetype: -incorprivilege: lerincorresourcedn: cn=Prescrição,cn=Serviço de Prescrição Médica,cn=PEP,ou=Resources,dc=incor,...incorauthorizationtype: weakincorroledn: cn=Usuario,cn=Papeis,ou=groups,dc=incor,dc=usp,dc=brcn: autorização 1 Arquitetura e implementação Representação do MACA no LDAP: árvore de informações Recife, 6 de agosto de 2004

  23. OpenLDAP 2.1.17 LDAP/TLS Arquitetura e implementação • Servidor de Segurança • Autenticação e autorização • Implementação • Java 2 SE 1.4 • API JNDI • Manuais • MACA: Guia de Instalação e Configuração • MACA Cliente: Guia do Programador • MACA Administrativo: Manual do Usuário • Disponível como software livre • Licença GNU GPL – http://maca.sourceforge.net/ • ORB JacORB 1.4 • IIOP/TLS Recife, 6 de agosto de 2004

  24. Arquitetura e implementação Autenticação de usuário Recife, 6 de agosto de 2004

  25. Arquitetura e implementação PrincipalAuthenticator - IDL para autenticação de usuário Recife, 6 de agosto de 2004

  26. Arquitetura e implementação PrincipalAuthenticator - uso em Java Recife, 6 de agosto de 2004

  27. Arquitetura e implementação PrincipalAuthenticator – uso em Delphi Recife, 6 de agosto de 2004

  28. Arquitetura e implementação Decisão e Controle de Acesso com o Resource Access Decision (RAD) Facility Recife, 6 de agosto de 2004

  29. Arquitetura e implementação AccessDecision – IDL para decisão de acesso Recife, 6 de agosto de 2004

  30. Arquitetura e implementação AccessDecision – uso em Java Recife, 6 de agosto de 2004

  31. Arquitetura e implementação • Servidor de Segurança • Contextos implementados via CORBA IDL • Relaciona informações de plataformas distribuídas e heterogêneas module Contexts {interface Context { Any getValue (instring index);boolean inEvaluation(in Any element,inAny aSet); Any functionApplication(instring functionName, in Vector argumentList); }; }; Recife, 6 de agosto de 2004

  32. Resultados • Disponibilidade do MACA • Avaliação de desempenho • Tempo médio de resposta (TMR) para autorização e autenticação • Observar a variação do TMR com o aumento da carga no servidor de autorização e autenticação • 0 a 700 usuários simultâneos, com a entrada progressiva de 60 agentes simulando usuários a cada 5’ • TMR de 100 solicitações aferidos cada 50 novos usuários • Servidor • 2Pentium III 1,3GHz, 1GBytes MP, 100 Mbits/s, Linux Suse 8.0 • Clientes • 4 Pentium III 500MHz, 196 MBytes MP, 100 Mbits/s, Win/2000 • Estação de medição • 1 Pentium III 800MHz, 326 MBytes MP, 100 Mbits/s, Win/2000 TMR aumentou 3,6 vezes no intervalo [50-700] Carga média aumentou 8,7 vezes no intervalo [50-700] Recife, 6 de agosto de 2004

  33. Resultados • Aplicação ao PEP InCor-HC.FMUSP • Dados de configuração • 2.036 contas – média de 1,3 papéis associados • 66 papéis – média de 30,3 usuários vinculados – média de 3,1 autorizações diretamente associadas • 205 autorizações – 79% positivas, 3% negativas, 18% regras, 99% fracas e 1% fortes • 83 objetos – 47 PEP • Java/JSP, Magic/Delphi e Oracle/Java • Dados de utilização do MACA • Média mensal de 442.368 solicitações de autorização – 10,2/min • Média mensal de 42.768 solicitações de autenticação – 0,9/min •  1000 estações de trabalho 247 Recife, 6 de agosto de 2004

  34. Conclusão • Modelo de autorização contextual para CABP • Considera as exigências de controle de acesso ao PEP • Concilia permissão de acesso ao PEP motivada pela necessidade de cuidado ao paciente com proibição e situações indevidas • Regras baseadas em contextos programáveis • Controle de acesso preciso, de acordo com o direito e a necessidade de um usuário realizar uma tarefa • Utilização rotineira no PEP InCor-HC.FMUSP • Exeqüibilidade do MACA, de sua implementação e de sua aplicação prática em casos reais Recife, 6 de agosto de 2004

  35. Conclusão • Contribuições • Extensão do modelo referência para CABP do NIST • Regras de autorização e contextos implementados como interfaces CORBA • Políticas de acesso para o PEP e administrativas capazes de se adaptar ao ambiente e a cultura das organizações de saúde • Ativação automática de papéis independente da SR • CABP transparente para o usuário do PEP  facilidade de uso • Conciliação do princípio da necessidade de saber/fazer com a SR na política de resolução de conflitos • Distinção entre conflitos de interesses e conflitos casuais Recife, 6 de agosto de 2004

  36. Conclusão • Contribuições • Disponibilidade da implementação do MACA • Produto estável e com bom desempenho • Soluções in-house para CABP demandam investimento de aprox. US$ 453,77 por usuário nos EUA • Integrado a uma arquitetura de padrões abertos e distribuída • Disponibilidade de serviços para os componentes do PEP a partir de plataformas heterogêneas • Capacidade de administrar e de impor políticas de acesso e de autenticação de modo unificado e coerente Recife, 6 de agosto de 2004

More Related