Gustavo Motta Departamento de Informática-UFPB

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

description

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 - PowerPoint PPT Presentation

Transcript of Gustavo Motta Departamento de Informática-UFPB

Page 1: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004Recife, 6 de agosto de 2004 11

MACA: uma solução para autenticação de MACA: uma solução para autenticação de usuários e autorização de acesso em usuários e autorização de acesso em

ambientes abertos e distribuídosambientes abertos e distribuídos

Gustavo MottaGustavo Motta

Departamento de Informática-UFPBDepartamento de Informática-UFPB

Page 2: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 2

SumárioSumário

► IntroduçãoIntrodução

► Conceitos de controle de acessoConceitos de controle de acesso

► Modelo de autorização contextual - Modelo de autorização contextual - MACAMACA

► Arquitetura e implementaçãoArquitetura e implementação

► ResultadosResultados

► ConclusãoConclusão

Page 3: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 3

IntroduçãoIntrodução

► Prontuário Eletrônico do Paciente - PEPProntuário Eletrônico do Paciente - PEP Avanços nas tecnologias de computação e Avanços nas tecnologias de computação e

comunicaçãocomunicação► PEP distribuídoPEP distribuído► Maior potencial de acesso à informações clínicasMaior potencial de acesso à informações clínicas

Benefícios para o pacienteBenefícios para o paciente Ameaças à privacidade e à confidencialidadeAmeaças à privacidade e à confidencialidade

DesafioDesafio► O controle de acesso ao PEP não pode prejudicar o O controle de acesso ao PEP não pode prejudicar o

atendimento ao paciente, tampouco deve facilitar a atendimento ao paciente, tampouco deve facilitar a violação de sua privacidadeviolação de sua privacidade

DilemaDilema► PermissividadePermissividade SeveridadeSeveridade► Quais políticas adotar?Quais políticas adotar?

Page 4: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 4

IntroduçãoIntrodução

► Aspectos computacionais do acesso ao PEPAspectos computacionais do acesso ao PEP Confidencialidade e a privacidade do pacienteConfidencialidade e a privacidade do paciente

► Responsabilidade também compartilhada pelos SIHsResponsabilidade também compartilhada pelos SIHs

Desafios para aplicação no PEP distribuídoDesafios para aplicação no PEP distribuído► Como implementar Como implementar políticas de acesso políticas de acesso ad hocad hoc

Formuladas com o único objetivo de atender as Formuladas com o único objetivo de atender as necessidades de controle de acesso de uma organização, necessidades de controle de acesso de uma organização, levando em conta o seu levando em conta o seu ambienteambiente e a sua e a sua culturacultura

► Administrar políticas de autenticação, de autorização e Administrar políticas de autenticação, de autorização e impor o controle de acessoimpor o controle de acesso

PEP composto por segmentos distribuídosPEP composto por segmentos distribuídos► Bases de dados Bases de dados distintasdistintas► MúltiplasMúltiplas aplicações aplicações► Plataformas Plataformas heterogêneasheterogêneas► Serviços de segurançaServiços de segurança estanquesestanques

SoluçãSoluçãoo

Controle de acessoControle de acesso► Centrado em papéis – autoridade e Centrado em papéis – autoridade e

responsabilidaderesponsabilidade

► Perspectiva do modelo organizacionalPerspectiva do modelo organizacional

► Autorizações contextuaisAutorizações contextuais

Arquitetura Arquitetura abertaaberta e e distribuídadistribuída ► Administrar políticas de autenticação, autorização Administrar políticas de autenticação, autorização

e impor a autenticação e o controle de acesso de e impor a autenticação e o controle de acesso de

modo modo unificadounificado e e coerentecoerente

► Acesso Acesso padronizadopadronizado a partir de sistemas a partir de sistemas

distintos em plataformas e linguagens de distintos em plataformas e linguagens de

programação heterogêneasprogramação heterogêneas

Page 5: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 5

IntroduçãoIntrodução

► ObjetivoObjetivo Apresentar o Apresentar o MACAMACA - - MiddlewareMiddleware de Autenticação de Autenticação

e Controle de Acessoe Controle de Acesso► Modelo de autorização contextualModelo de autorização contextual

► Controle de Acesso Baseado em Papéis - CABP/NISTControle de Acesso Baseado em Papéis - CABP/NIST

► Arquitetura de softwareArquitetura de software

LDALDAPP

Security Services

Page 6: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 6

Conceitos de controle de acessoConceitos de controle de acesso

Autenticação, autorização, controle de acesso e auditoria

Banco de Dados

de Autorizações

Monitor de

Referência

Autenticação Controle de Acesso

Usuário Objetos

Administrador

de Segurança

Auditoria

Política de Acesso

Page 7: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 7

Conceitos de controle de acessoConceitos de controle de acesso

► Controle de acesso baseado em papéisControle de acesso baseado em papéis Acesso regulado segundo os papéis exercidosAcesso regulado segundo os papéis exercidos

► Um papel denota uma função organizacional Um papel denota uma função organizacional

Autoridade e ResponsabilidadeAutoridade e Responsabilidade

► Adequado para aplicação ao PEP em organizações de Adequado para aplicação ao PEP em organizações de

saúdesaúde

Processos de negócio complexosProcessos de negócio complexos

Equipes multiprofissionais Equipes multiprofissionais

Suporta o princípio da necessidade de saber/fazerSuporta o princípio da necessidade de saber/fazer► Um usuário somente deve ter os privilégios Um usuário somente deve ter os privilégios necessáriosnecessários

para desempenhar suas funçõespara desempenhar suas funções

Politicamente neutroPoliticamente neutro

Page 8: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 8

Conceitos de controle de acessoConceitos de controle de acesso

► Controle de acesso baseado em papéisControle de acesso baseado em papéis

Separação de responsabilidadesSeparação de responsabilidades

► Distribui tarefas críticas por múltiplos usuáriosDistribui tarefas críticas por múltiplos usuários

► Minimiza conflitos de interessesMinimiza conflitos de interesses

Favorece a administração da política de acessoFavorece a administração da política de acesso

► Visão organizacionalVisão organizacional

► Facilita procedimentos de Facilita procedimentos de

Admissão/demissão Admissão/demissão

Realocação funcionalRealocação funcional

► Reduz o tempo para gerenciar contas e Reduz o tempo para gerenciar contas e

atribuição/revogação de privilégiosatribuição/revogação de privilégios Para uma empresa com 100.000 empregados, produz um Para uma empresa com 100.000 empregados, produz um

benefício estimado da ordem de US$934.321,00/anobenefício estimado da ordem de US$934.321,00/ano

► Reduz ociosidade entre a contração de um Reduz ociosidade entre a contração de um

empregado e a concessão de seus privilégios empregado e a concessão de seus privilégios Para uma empresa com 100.000 empregados, produz um Para uma empresa com 100.000 empregados, produz um

benefício estimado da ordem de US$3.436.966,00/ano; benefício estimado da ordem de US$3.436.966,00/ano;

► Reduz a gravidade e a freqüência das violações de Reduz a gravidade e a freqüência das violações de

segurança nas organizações, particularmente a segurança nas organizações, particularmente a

fraude financeira com a definição de políticas de fraude financeira com a definição de políticas de

separação de responsabilidadesseparação de responsabilidades

Fonte: NIST Fonte: NIST

Page 9: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 9

Usuário

Administrador Profissional de Saúde

Médico Paramédico Auxiliar de

Registro de Saúde Diretor

Analista de Registro de Saúde Auxiliar de Enfermagem Diretor Clínico

Hierarquia geral

Relação Relação papa

Médico, Prescrever, PEP;

Diretor Clínico, VerLogAuditoria, PEP;

Auxiliar de Enfermagem, VerPrescrição, PEP;

usuários

papéis

autorizações

Restrições de SR hp

Hierarquia de Papéis

pa

up

sessões

usuário

papéis

ops Operações

obs Objetos

Relacionamento n para m

Relacionamento 1 para m

SR estática SR dinâmica

Modelos de controle de acessoModelos de controle de acesso

Esquema do modelo de referência para o CABP do NIST

Page 10: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 10

Modelo de autorização contextual – Modelo de autorização contextual – MACAMACA

► MotivaçãoMotivação

Políticas de acesso Políticas de acesso ad hocad hoc para o PEP para o PEP Enfermeiras somente podem ver registros de pacientes internados Enfermeiras somente podem ver registros de pacientes internados

em sua enfermaria ou que lá estiveram nos últimos 30 diasem sua enfermaria ou que lá estiveram nos últimos 30 dias

Médicos que são membros de uma equipe somente podem ver Médicos que são membros de uma equipe somente podem ver

registros de pacientes sob os cuidados de algum membro da equiperegistros de pacientes sob os cuidados de algum membro da equipe

► Necessárias para estabelecimentos de saúde com atendimentos Necessárias para estabelecimentos de saúde com atendimentos

em níveis secundário e terciárioem níveis secundário e terciário

Paciente cuidado por equipes multiprofissionais e multidisciplinaresPaciente cuidado por equipes multiprofissionais e multidisciplinares

► Inviáveis nos modelos tradicionais de controle de acesso e no Inviáveis nos modelos tradicionais de controle de acesso e no

modelo de referência para CABP NISTmodelo de referência para CABP NIST

Page 11: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 11

Modelo de autorização contextual – Modelo de autorização contextual – MACAMACA

► Estende o CABP do NISTEstende o CABP do NIST

Autorizações contextuaisAutorizações contextuais

► Incorporam Incorporam regrasregras relacionando informações do relacionando informações do

contextocontexto relevantes para decisão de permitir ou proibir relevantes para decisão de permitir ou proibir

o acessoo acesso

► Positivas ou negativasPositivas ou negativas

ConflitosConflitos

► Fortes ou fracasFortes ou fracas

Fortes Fortes políticas estritas políticas estritas

Fracas Fracas políticas permissivas políticas permissivas

+, VerLaudo, PEP, fraca

, VerLaudo, PEP, fraca

Page 12: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 12

Modelo de autorização contextual – Modelo de autorização contextual – MACAMACA

► Hierarquia de papéisHierarquia de papéis

Árvore invertidaÁrvore invertida

► Separação de responsabilidadesSeparação de responsabilidades

Conflitos entre autorizaçõesConflitos entre autorizações

► Ativação automática de papéisAtivação automática de papéis

CABP transparente para o usuário finalCABP transparente para o usuário final

Page 13: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 13

Modelo de autorização contextual – Modelo de autorização contextual – MACAMACA

► ContextoContexto Qualquer informação usada para caracterizar uma Qualquer informação usada para caracterizar uma

entidade considerada relevante para interação entre entidade considerada relevante para interação entre um usuário e uma aplicaçãoum usuário e uma aplicação

TiposTipos► Variáveis Variáveis valores atômicos valores atômicos

usuárioCtx.registro_profissionalusuárioCtx.registro_profissional, , dtCtx.dia_semanadtCtx.dia_semana

► Conjuntos Conjuntos coleção de valores determinados e coleção de valores determinados e diferenciáveisdiferenciáveis

dtCtx.dias_úteisdtCtx.dias_úteis, , pacCtx.pacientes_internadospacCtx.pacientes_internados

► Funções Funções estabelece relações entre entidades e novos estabelece relações entre entidades e novos valoresvalores

pacCtx.assistido_por(umCodPac,pacCtx.assistido_por(umCodPac, usuárioCtx.registro_profissional) usuárioCtx.registro_profissional)

Expressam entidades e relacionamentos do ambiente Expressam entidades e relacionamentos do ambiente e da cultura organizacionaise da cultura organizacionais

Page 14: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 14

Modelo de autorização contextual – Modelo de autorização contextual – MACAMACA

► Regras de autorizaçãoRegras de autorização Relacionam contextos em expressões lógicas para Relacionam contextos em expressões lógicas para

especificar uma política de acessoespecificar uma política de acesso► Valores booleanos, inteiros, textos, conjuntos, Valores booleanos, inteiros, textos, conjuntos,

► Operadores aritméticos, de conjunto, relacionais, booleanos Operadores aritméticos, de conjunto, relacionais, booleanos

► Novos valoresNovos valores e operadores definidos em contextos e operadores definidos em contextos

► Regras parametrizadasRegras parametrizadas

Exemplo de política de acessoExemplo de política de acesso► Enfermeiros e seus auxiliares somente podem acessar Enfermeiros e seus auxiliares somente podem acessar

prescrições de pacientes internados quando estão em seu prescrições de pacientes internados quando estão em seu

turno de trabalhoturno de trabalho

Page 15: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 15

Auxiliar de Enfermagem,Auxiliar de Enfermagem, exp-absexp-abs(umCodPac) (umCodPac) {{

umCodPac umCodPac inin pacCtx.pacientes_internados pacCtx.pacientes_internados &&

usuárioCtx.está_no_turno_de_trabalhousuárioCtx.está_no_turno_de_trabalho

}}, VerPrescrição, PEP, , VerPrescrição, PEP, fracafraca

Modelo de autorização contextual – Modelo de autorização contextual – MACAMACA

► Regras de autorizaçãoRegras de autorização

Page 16: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 16

► Hierarquia de papéisHierarquia de papéis Estrutura de árvore invertidaEstrutura de árvore invertida

► Herança de autorizaçõesHerança de autorizações Adição de conceitosAdição de conceitos

► RevogaçãoRevogação de autorizações de autorizações MecanismosMecanismos

► Sobreposição de autorizaçõesSobreposição de autorizações

► Definição de autorizações fortesDefinição de autorizações fortes Disciplinado pelo tipo da autorizaçãoDisciplinado pelo tipo da autorização

► Forte Forte irrevogável irrevogável

► Fraca Fraca revogável revogável

► Autorizações válidasAutorizações válidas Autorizações associadas direta ou indiretamente a um papel e Autorizações associadas direta ou indiretamente a um papel e

que não estão revogadasque não estão revogadas

Únicas usadas para decidir um acessoÚnicas usadas para decidir um acesso

Modelo de autorização contextual – Modelo de autorização contextual – MACAMACA

Profissional de Saúde – PS

Médico

Médico Assistente

Pesquisador Clínico

Paramédico

Auxiliar de Enfermagem

Nutricionista

Enfermeiro

Cirurgião

Médico Auditor

Clínico

, 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

+, VerLaudo, PEP, fraca

+, VerLaudo, PEP, fraca

+, VerLaudo, PEP, fraca

+, VerLaudo, PEP, fraca

, VerLaudo, PEP, fraca, VerLaudo, PEP, forte

, VerLaudo, PEP, fraca

, VerLaudo, PEP, forte

, VerLaudo, PEP, forte

, VerLaudo, PEP, forte

Page 17: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 17

► Separação de responsabilidades Separação de responsabilidades

Particiona compulsoriamente a responsabilidade e a autoridade Particiona compulsoriamente a responsabilidade e a autoridade

para realizar ações em que há conflitos de interessespara realizar ações em que há conflitos de interesses

Baseadas em conflitos entre autorizaçõesBaseadas em conflitos entre autorizações

► Fortes Fortes denotam conflitos de interesses denotam conflitos de interesses

Médico Assistente, Médico Assistente, +, Prescrever, PEP, +, Prescrever, PEP, forteforte

Médico Auditor, Médico Auditor, ——, Prescrever, PEP, , Prescrever, PEP, forteforte

► Fracos Fracos representam diferentes necessidades funcionais representam diferentes necessidades funcionais

Médico Assistente, Médico Assistente, +, VerDadosIdentificação, PEP, +, VerDadosIdentificação, PEP, fracafraca

Pesquisador Clínico, Pesquisador Clínico, ——, VerDadosIdentificação, PEP, , VerDadosIdentificação, PEP, fracafraca

Modelo de autorização contextual – Modelo de autorização contextual – MACAMACA

Page 18: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 18

► Separação de responsabilidades Separação de responsabilidades

Política de resolução de conflitosPolítica de resolução de conflitos

► Conflitos fortes Conflitos fortes prevalece a autorização que prevalece a autorização que proíbeproíbe o acesso o acesso

Visa atender a Visa atender a separação de responsabilidadesseparação de responsabilidades

► Médico AuditorMédico Auditor e e Médico AssistenteMédico Assistente

► ——, Prescrever, PEP, , Prescrever, PEP, forteforte

► Conflitos fracos Conflitos fracos prevalece a autorização que prevalece a autorização que permitepermite o acesso o acesso

Visa atender o Visa atender o princípio da necessidade de saber/fazerprincípio da necessidade de saber/fazer

► Pesquisador ClínicoPesquisador Clínico e e Médico AssistenteMédico Assistente

► +, VerDadosIdentificação, PEP, +, VerDadosIdentificação, PEP, fracafraca

Modelo de autorização contextual – Modelo de autorização contextual – MACAMACA

Page 19: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 19

sessão, Entrar, PEP, ();sessão, VerDadosIdentificação, PEP, (“2-I”);sessão, Prescrever, PEP, (“123456-H”);

► Algoritmo de decisão de acessoAlgoritmo de decisão de acesso

Determina se o usuário de uma sessão tem permissão para Determina se o usuário de uma sessão tem permissão para

acessar objetos protegidos a fim de executar uma operação acessar objetos protegidos a fim de executar uma operação

específicaespecífica

► Somente autorizações válidasSomente autorizações válidas

► Avaliação das regras no contexto da tentativa de acessoAvaliação das regras no contexto da tentativa de acesso

► Prioridade das autorizações fortes sobre as fracasPrioridade das autorizações fortes sobre as fracas

► Ativação automática de papéis Ativação automática de papéis independenteindependente da separação de da separação de

responsabilidadesresponsabilidades

Política de resolução de conflitosPolítica de resolução de conflitos

► Concilia o princípio da necessidade de saber/fazer com a limitação Concilia o princípio da necessidade de saber/fazer com a limitação

de acessos que resultem em conflitos de interesses de acessos que resultem em conflitos de interesses

Profissional de Saúde – PS

Médico

Médico Assistente

Pesquisador Clínico

Paramédico

...

Nutricionista

Enfermeiro

Cirurgião

Médico Auditor

Clínico

Modelo de autorização contextual – Modelo de autorização contextual – MACAMACA

+, Entrar, PEP, fraca; +, VerPrescrição, PEP, fraca;+, VerDadosIdentificação, PEP, fraca

, VerDadosIdentificação, PEP, fraca

+, Prescrever, PEP, forte; , GlosarPrescrição, PEP, forte;

, Prescrever, PEP, forte; +, GlosarPrescrição, PEP, forte;

Page 20: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 20

► Contribuições para aplicação ao PEPContribuições para aplicação ao PEP Reforça o princípio da necessidade de saber/fazerReforça o princípio da necessidade de saber/fazer

► Mais privacidade para o pacienteMais privacidade para o paciente

► Menos acessos supérfluosMenos acessos supérfluos

Adaptação ao ambiente e a cultura das org. saúdeAdaptação ao ambiente e a cultura das org. saúde► Poder expressivo e flexibilidade das regras de autorizaçãoPoder expressivo e flexibilidade das regras de autorização

► Políticas de acesso Políticas de acesso ad hocad hoc

► Isola a lógica de autorização dos componentes do PEPIsola a lógica de autorização dos componentes do PEP

Facilidade de uso do PEPFacilidade de uso do PEP► CABP transparente para o usuário finalCABP transparente para o usuário final

Administração viável da política de acesso ao PEPAdministração viável da política de acesso ao PEP► Estruturas organizacionais – autonomia e descentralizaçãoEstruturas organizacionais – autonomia e descentralização

Modelo de autorização contextual – Modelo de autorização contextual – MACAMACA

Profissional de Saúde – PS

Médico

Médico Assistente

Pesquisador Clínico

Paramédico

Auxiliar de Enfermagem

Nutricionista

Enfermeiro

Cirurgião

Médico Auditor

Clínico

+, Entrar, PEP, fraca; +, VerPrescrição, PEP, fraca;+, VerDadosIdentificação, PEP, fraca

, VerDadosIdentificação, PEP, fraca

+, Prescrever, PEP, forte; , GlosarPrescrição, PEP, forte;

, Prescrever, PEP, forte; +, GlosarPrescrição, PEP, forte;

......

exp-abs(umCodPac, umCodPresc){ pacCtx.plano_saude_presc(umCodPac, umCodPresc) in

usuárioCtx.convenios

} , VerPrescrição, PEP, fraca

Hospital de Clínicas

Instituto doCoração

Instituto deNeurologia

Divisão de ClínicaCardiológica

Divisão de CirurgiaCardiovascular

Divisão de ClínicaNeurológica

Divisão deNeurocirurgia

Serviço deHemodinâmica

Serviço deEletrocardiografia

Serviço deNeuroanatomia

Serviço deNeuropediatria

Page 21: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 21

► Baseada em padrões abertos e distribuídosBaseada em padrões abertos e distribuídos Acesso para componentes do PEP em Acesso para componentes do PEP em

plataformas heterogêneasplataformas heterogêneas

Mais interoperabilidadeMais interoperabilidade

Políticas de acesso e de autenticação unificadas Políticas de acesso e de autenticação unificadas

e coerentese coerentes

► Cliente/servidor multicamadaCliente/servidor multicamada Base de informações de gerência da segurançaBase de informações de gerência da segurança

Servidor de autenticação e de autorizaçãoServidor de autenticação e de autorização

Aplicações clientes componentes do PEPAplicações clientes componentes do PEP

Arquitetura e implementaçãoArquitetura e implementação

Arquitetura de Software para integração do MACA

c : Cliente pa : Principal

Authenticator ado : Access Decision

maca : MACAService

ldap : LDAPServer

: Credentials

authenticate(login, pwd, ...) bind(login, pwd)

{transiente}

new Credentials(ldap_conx)

get_attributes(...)

addNewSession(creds)

access_allowed(obj, opr, session_ref) hasAccess (opr, obj, params, session_ref) search(...)

destroy( ) closeSession(creds) unbind(...)

{autenticado}

{sessão encerrada}

{acesso permitido ou negado}

Page 22: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 22

dc=incor,dc=usp,dc=br (nó raiz)

... ...

cn=papéis

cn=usuário

cn=Profissional de Saúde

cn=médico

cn=PEP

cn=Serviço de Prescrição Médica

cn=Prescrição

cn=MACA

cn=Usuário

...

ou=usuario

ou=Profissional de Saúde

ou=médico

cn=autorização 1

cn=autorização 2

cn=autorização 1

...

ou=people ou=groups ou=resources ou=authorizations

uid=josé.antônio

uid=maria.augusta

uid=luis.gustavo

Arquitetura e implementaçãoArquitetura e implementação

Representação do MACA no LDAP: árvore de informações

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

Page 23: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 23

► Servidor de SegurançaServidor de Segurança Autenticação e autorizaçãoAutenticação e autorização

ImplementaçãoImplementação► Java 2 SE 1.4Java 2 SE 1.4

API JNDIAPI JNDI

ManuaisManuais► MACA: Guia de Instalação e ConfiguraçãoMACA: Guia de Instalação e Configuração

► MACA Cliente: Guia do ProgramadorMACA Cliente: Guia do Programador

► MACA Administrativo: Manual do UsuárioMACA Administrativo: Manual do Usuário

Disponível como software livreDisponível como software livre► Licença GNU GPL – Licença GNU GPL – http://maca.sourceforge.net/http://maca.sourceforge.net/

Arquitetura e implementaçãoArquitetura e implementação

► OpenLDAP 2.1.17OpenLDAP 2.1.17

LDAP/TLSLDAP/TLS

► ORB JacORB 1.4ORB JacORB 1.4

IIOP/TLSIIOP/TLS

Page 24: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 24

Arquitetura e implementaçãoArquitetura e implementação

Autenticação de usuárioAutenticação de usuário

Page 25: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 25

Arquitetura e implementaçãoArquitetura e implementação

PrincipalAuthenticator - IDL para autenticação de - IDL para autenticação de usuáriousuário

Page 26: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 26

Arquitetura e implementaçãoArquitetura e implementação

PrincipalAuthenticator - uso em Java - uso em Java

Page 27: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 27

Arquitetura e implementaçãoArquitetura e implementação

PrincipalAuthenticator – uso em Delphi – uso em Delphi

Page 28: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 28

Arquitetura e implementaçãoArquitetura e implementação

Decisão e Controle de Acesso com o Decisão e Controle de Acesso com o Resource Access Decision (RAD) FacilityResource Access Decision (RAD) Facility

Page 29: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 29

Arquitetura e implementaçãoArquitetura e implementação

AccessDecision – IDL para decisão de acesso – IDL para decisão de acesso

Page 30: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 30

Arquitetura e implementaçãoArquitetura e implementação

AccessDecision – uso em Java – uso em Java

Page 31: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 31

Arquitetura e implementaçãoArquitetura e implementação

► Servidor de SegurançaServidor de Segurança Contextos implementados via CORBA IDLContextos implementados via CORBA IDL

► Relaciona informações de plataformas distribuídas e Relaciona informações de plataformas distribuídas e heterogêneasheterogêneas

modulemodule Contexts { Contexts {

interfaceinterface Context { Context {

Any getValue ( Any getValue (inin stringstring index); index);

booleanboolean inEvaluation inEvaluation(inin Any element, Any element, inin AnyAny aSet); aSet);

Any functionApplication( Any functionApplication(inin stringstring functionName, functionName, inin Vector argumentList); Vector argumentList);

}; }; };};

Page 32: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 32

► Disponibilidade do MACADisponibilidade do MACA

Avaliação de desempenhoAvaliação de desempenho► Tempo médio de resposta (TMR) para autorização e Tempo médio de resposta (TMR) para autorização e

autenticaçãoautenticação Observar a variação do TMR com o aumento da carga no servidor Observar a variação do TMR com o aumento da carga no servidor

de autorização e autenticaçãode autorização e autenticação► 0 a 700 usuários simultâneos, com a entrada progressiva de 0 a 700 usuários simultâneos, com a entrada progressiva de

60 agentes simulando usuários a cada 5’60 agentes simulando usuários a cada 5’► TMR de 100 solicitações aferidos cada 50 novos usuáriosTMR de 100 solicitações aferidos cada 50 novos usuários

ServidorServidor► 22Pentium III 1,3GHz, 1GBytes MP, 100 Mbits/s, Linux Suse 8.0Pentium III 1,3GHz, 1GBytes MP, 100 Mbits/s, Linux Suse 8.0

ClientesClientes► 4 Pentium III 500MHz, 196 MBytes MP, 100 Mbits/s, Win/20004 Pentium III 500MHz, 196 MBytes MP, 100 Mbits/s, Win/2000

Estação de mediçãoEstação de medição► 1 Pentium III 800MHz, 326 MBytes MP, 100 Mbits/s, Win/20001 Pentium III 800MHz, 326 MBytes MP, 100 Mbits/s, Win/2000

ResultadosResultados

0

20

40

60

80

100

0 50 100 150 200 250 300 350 400 450 500 550 600 650 700

Usuários simultâneos

Tem

po m

édio

de

resp

osta

(m

s)

Exp. 1 - com cache e com IIOP/TLS

0

200

400

600

800

1000

1200

1400

1600

0 50 100 150 200 250 300 350 400 450 500 550 600 650 700

Usuários simultâneos

Méd

ia d

e so

licita

ções

por

min

. Exp. 1 - autenticação com cache e com IIOP/TLS

Exp. 1 - autorização com cache e com IIOP/TLS

TMR aumentou 3,6 vezes TMR aumentou 3,6 vezes

no intervalo [50-700]no intervalo [50-700]

Carga média aumentou 8,7 Carga média aumentou 8,7

vezes no intervalo [50-700]vezes no intervalo [50-700]

Page 33: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 33

ResultadosResultados

► Aplicação ao PEP InCor-HC.FMUSPAplicação ao PEP InCor-HC.FMUSP► Dados de configuraçãoDados de configuração

2.036 contas – média de 1,3 papéis associados2.036 contas – média de 1,3 papéis associados

66 papéis – média de 30,3 usuários vinculados66 papéis – média de 30,3 usuários vinculados

– média de 3,1 autorizações diretamente associadas – média de 3,1 autorizações diretamente associadas

205 autorizações – 79% positivas, 3% negativas, 18% regras, 205 autorizações – 79% positivas, 3% negativas, 18% regras,

99% fracas e 1% fortes 99% fracas e 1% fortes

83 objetos – 47 PEP83 objetos – 47 PEP

► Java/JSP, Magic/Delphi e Oracle/JavaJava/JSP, Magic/Delphi e Oracle/Java

► Dados de utilização do Dados de utilização do MACAMACA

Média mensal de 442.368 solicitações de autorização – Média mensal de 442.368 solicitações de autorização – 10,2/min10,2/min

Média mensal de 42.768 solicitações de autenticação – 0,9/minMédia mensal de 42.768 solicitações de autenticação – 0,9/min

1000 estações de trabalho 241000 estações de trabalho 2477

Page 34: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 34

ConclusãoConclusão

Modelo de autorização contextual para CABPModelo de autorização contextual para CABP► Considera as exigências de controle de acesso ao PEPConsidera as exigências de controle de acesso ao PEP

Concilia permissão de acesso ao PEP motivada pela Concilia permissão de acesso ao PEP motivada pela

necessidade de cuidado ao paciente com proibição e necessidade de cuidado ao paciente com proibição e

situações indevidassituações indevidas

► Regras baseadas em contextos programáveisRegras baseadas em contextos programáveis

Controle de acesso preciso, de acordo com o direito e a Controle de acesso preciso, de acordo com o direito e a

necessidade de um usuário realizar uma tarefanecessidade de um usuário realizar uma tarefa

Utilização rotineira no PEP InCor-HC.FMUSPUtilização rotineira no PEP InCor-HC.FMUSP► Exeqüibilidade do Exeqüibilidade do MACAMACA, de sua implementação e de , de sua implementação e de

sua aplicação prática em casos reaissua aplicação prática em casos reais

Page 35: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 35

ConclusãoConclusão

► ContribuiçõesContribuições Extensão do modelo referência para CABP do NISTExtensão do modelo referência para CABP do NIST

► Regras de autorização e contextos implementados como Regras de autorização e contextos implementados como

interfaces CORBAinterfaces CORBA

Políticas de acesso para o PEP e administrativas capazes de se Políticas de acesso para o PEP e administrativas capazes de se

adaptar ao adaptar ao ambienteambiente e a e a culturacultura das organizações de saúde das organizações de saúde

Ativação automática de papéis independente da SRAtivação automática de papéis independente da SR► CABP transparente para o usuário do PEP CABP transparente para o usuário do PEP facilidade de uso facilidade de uso

Conciliação do princípio da necessidade de saber/fazer Conciliação do princípio da necessidade de saber/fazer

com a SR na política de resolução de conflitoscom a SR na política de resolução de conflitos► Distinção entre Distinção entre conflitos de interessesconflitos de interesses e conflitos casuais e conflitos casuais

Page 36: Gustavo Motta Departamento de Informática-UFPB

Recife, 6 de agosto de 2004 36

ConclusãoConclusão

► ContribuiçõesContribuições

Disponibilidade da implementação do Disponibilidade da implementação do MACAMACA

► Produto estável e com bom desempenhoProduto estável e com bom desempenho

SoluçõesSoluções in-house in-house para CABP demandam investimento de para CABP demandam investimento de

aprox. US$ 453,77 por usuário nos EUAaprox. US$ 453,77 por usuário nos EUA

► Integrado a uma arquitetura de padrões abertos e Integrado a uma arquitetura de padrões abertos e

distribuídadistribuída

Disponibilidade de serviços para os componentes do PEP a Disponibilidade de serviços para os componentes do PEP a

partir de plataformas heterogêneaspartir de plataformas heterogêneas

Capacidade de administrar e de impor políticas de acesso e Capacidade de administrar e de impor políticas de acesso e

de autenticação de modo de autenticação de modo unificadounificado e e coerentecoerente