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
Recife, 6 de agosto de 2004
1
Sumário
► Introdução
► Conceitos
► Modelo
de controle de acesso
de autorização contextual - MACA
► Arquitetura
e implementação
► Resultados
► Conclusão
Recife, 6 de agosto de 2004
2
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
► Quais
 Severidade
políticas adotar?
Recife, 6 de agosto de 2004
3
Introdução
 Controle
de acesso
► Aspectos
computacionais
do acesso ao PEP
► Centrado em papéis
– autoridadedo
e responsabilidade
 Confidencialidade
e a privacidade
paciente
► Responsabilidade
► Perspectiva dotambém
modelocompartilhada
organizacionalpelos
SIHs
 Desafios
para aplicação
no PEP distribuído
► Autorizações
contextuais
Solução
► Como
implementar políticas de acesso ad hoc
 Arquitetura
aberta e distribuída
 Formuladas com o único objetivo de atender as necessidades de
de acesso
de uma
organização, levando
em conta
o seu
► controle
Administrar
políticas
de autenticação,
autorização
e impor
ambiente e a sua cultura
a autenticação e o controle de acesso de modo
► Administrar políticas de autenticação, de autorização e impor
unificado
e coerente
o controle
de acesso
► PEP
composto
por segmentos
distribuídos
Acesso
padronizado
a partir
de sistemas distintos em
► Bases de dados distintas
plataformas
e linguagens de programação heterogêneas
► Múltiplas aplicações
► Plataformas heterogêneas
► Serviços de segurança estanques
Recife, 6 de agosto de 2004
4
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
Security Services
Recife, 6 de agosto de 2004
5
Conceitos de controle de acesso
Política de Acesso
Banco de Dados
de Autorizações
Administrador
Autenticação
Controle de Acesso
de Segurança
Monitor de
Referência
Usuário
Objetos
Auditoria
Autenticação, autorização, controle de acesso e auditoria
Recife, 6 de agosto de 2004
6
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
7
Conceitos de controle de acesso
Reduz o tempo para gerenciar contas e
► Controle
de acesso de
baseado
em papéis
atribuição/revogação
privilégios
►
Para uma empresa
com 100.000 empregados, produz um
 Separação
de responsabilidades
benefício estimado da ordem de US$934.321,00/ano
► Distribui tarefas críticas por múltiplos usuários
►
Reduz
ociosidade entre a contração de um empregado e a
► Minimiza conflitos de interesses
concessão de seus privilégios
 Favorece
a administração da política de acesso
Para uma empresa com 100.000 empregados, produz um
benefício
estimado da ordem de US$3.436.966,00/ano;
► Visão organizacional
►
► Facilita
procedimentos
de
Reduz
a gravidade
e a freqüência
das violações de
 Admissão/demissão
segurança
nas organizações, particularmente a fraude
financeira
com a definição
 Realocação
funcional de políticas de separação de
responsabilidades
Fonte: NIST
Recife, 6 de agosto de 2004
8
Modelos de controle de acesso
Usuário
Restrições de SR
SR estática
SR dinâmica
Administrador
hp
Hierarquia
de PapéisProfissional de Saúde
Relação pa
up
Médico,
PEP;
AuxiliarPrescrever,
de
usuários
Diretorpapéis
Registro de Saúde
pa
ops
Operações
obs
Paramédico
Médico
Objetos
Diretor Clínico, VerLogAuditoria, PEP;
sessões
Auxiliar
de Enfermagem, VerPrescrição, PEP;
Analista de
Diretor Clínico
Registro de Saúde
usuário
papéis
Hierarquia geral
autorizações
Auxiliar de Enfermagem
Relacionamento n para m
Relacionamento 1 para m
Esquema do modelo de referência para o CABP do NIST
Recife, 6 de agosto de 2004
9
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
10
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
+, VerLaudo, PEP, fraca
, VerLaudo, PEP, fraca
 Fracas  políticas permissivas
Recife, 6 de agosto de 2004
11
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
12
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
13
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
► Novos
aritméticos, de conjunto, relacionais, booleanos 
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
14
Modelo de autorização contextual – MACA
► Regras
de autorização
Auxiliar de Enfermagem,
exp-abs(umCodPac) {
umCodPac in pacCtx.pacientes_internados &
usuárioCtx.está_no_turno_de_trabalho
}, VerPrescrição, PEP, fraca
Recife, 6 de agosto de 2004
15
Modelo de autorização contextual – MACA
► Hierarquia
de papéis
 Profissional
Estrutura
de árvore invertida
de Saúde – PS , VerLaudo,
► Herança
Médico
de autorizações
PEP, fraca
, VerLaudo, PEP, fraca
+,
 Adição de conceitos
Médico Assistente
► Revogação
, VerLaudo, PEP, fraca
+,
de autorizações
Cirurgião
 Mecanismos
, VerLaudo, PEP, fraca
+,
Clínico
, VerLaudo, PEP, fraca
+,
Sobreposição de autorizações
Médico
Auditor +,
,
VerLaudo, fortes
PEP, fraca
► Definição
de autorizações
►
 Disciplinado pelo tipo da autorização
fraca
, VerLaudo, PEP, forte
► Forte  irrevogável
forte
Auxiliar de Enfermagem , VerLaudo, PEP, fraca
► Fraca  revogável
, VerLaudo, PEP, fraca
forte
Enfermeiro +,
Paramédico
► Autorizações
válidas
fraca
Nutricionista , VerLaudo, PEP, forte
 Autorizações associadas direta ou indiretamente a um papel e que não
estão Clínico
revogadas
Pesquisador
, VerLaudo, PEP, fraca
+,
 Únicas usadas para decidir um acesso
Recife, 6 de agosto de 2004
16
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
17
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
18
Modelo de autorização contextual – MACA
► Algoritmo
de decisão de acesso


sessão, Prescrever,
Entrar, PEP,PEP,
VerDadosIdentificação,
(); (“123456-H”);
PEP, (“2-I”);
Profissional
Determina
se o usuário de uma sessão tem permissão para acessar
de Saúde – PS
+, Entrar, PEP, fraca; +, VerPrescrição, PEP, fraca;
+, VerDadosIdentificação, PEP, fraca
Médico protegidos a fim de executar uma operação específica
objetos
Médico Assistente +, Prescrever, PEP, forte;
► Somente
autorizações válidas
, GlosarPrescrição, PEP, forte;
► Avaliação
Cirurgião
das regras no contexto da tentativa de acesso
Clínico
► Prioridade
das autorizações
fortesPEP,
sobre
as fracas
Médico Auditor
, Prescrever,
forte;
►Paramédico
Ativação
+, GlosarPrescrição, PEP, forte;
automática de papéis independente da separação de
responsabilidades
...
 PolíticaEnfermeiro
de resolução de conflitos
Nutricionista
► Concilia
o princípio da necessidade de saber/fazer com a limitação de
VerDadosIdentificação,
PEP, fraca
Pesquisador Clínico
acessos,
que
resultem em conflitos de interesses
Recife, 6 de agosto de 2004
19
Modelo de autorização contextual – MACA
► Contribuições
de Clínicas
para Hospital
aplicação
ao PEP
– PS +, Entrar, PEP, fraca; +, VerPrescrição, PEP,
 Profissional
Reforçade Saúde
o princípio
da necessidade de saber/fazer
+, VerDadosIdentificação, PEP, fraca
Médico
► Mais
privacidade
Instituto
do
fraca;
para o paciente
Instituto de
+,
Prescrever,
PEP,
forte;
Médico Assistente
Coração
Neurologia
► Menos acessos supérfluos
, GlosarPrescrição, PEP, forte;
Cirurgião
 Adaptação ao
ambiente e a cultura das org. saúde
Clínico
Divisão de Clínica
Divisão ,
de
Divisão
Clínica de autorização
Divisão de
Auditor
Prescrever,
PEP,
► PoderMédico
expressivo
e Cirurgia
flexibilidade
dasdeforte;
regras
Cardiológica
Cardiovascular
Neurológica
Neurocirurgia
+, GlosarPrescrição,
PEP, forte;
► Políticas
Paramédicode
acesso
ad hoc
exp-abs(umCodPac,
umCodPresc){
► Isola aAuxiliar
lógica
depacCtx.plano_saude_presc(umCodPac,
autorização dos componentes umCodPresc)
do PEP in
de Enfermagem
usuárioCtx.convenios
Serviço de
Serviço de
} , VerPrescrição, PEP,
fraca
...
Eletrocardiografia
Neuropediatria
Enfermeiro
 Facilidade de uso do PEP
► CABP
Nutricionista
transparente para o usuário final
PEP,
Pesquisador Clínico , VerDadosIdentificação,
Serviço de
Serviço
de fraca
Hemodinâmica
Neuroanatomia
 Administração viável da política de acesso ao PEP
► Estruturas
organizacionais
– autonomia e descentralização
Recife, 6 de agosto de 2004
20
Arquitetura e implementação
► Baseada
c : Cliente
em padrões abertos e distribuídos
{transiente}
pa : Principal
Authenticator
: Credentials
ado : Access
Decision
maca:
MACAService
 Acesso para componentes do PEP em plataformas
authenticate(login, pwd, ...)
bind(login, pwd
new Credentials(ldap_conx)
heterogêneas
addNewSession(creds)
ldap :
LDAPServer
)
 Mais
interoperabilidade
{autenticado}
 Políticas de acesso e de autenticação unificadas e
get_attributes(...)
coerentes
access_allowed(obj, opr, session_ref)
► Cliente/servidor
multicamada
hasAccess (opr, obj, params, session_ref)
search(...)
{acesso permitido ou negado}
 Base de informações de gerência da segurança
destroy( )
 Servidor
de autenticação e de autorização
closeSession(creds)
unbind(...)
 {sessão
Aplicações
clientes
componentes
do PEPdo MACA
encerrada}
Arquitetura
de Software
para
integração
x
Recife, 6 de agosto de 2004
21
Arquitetura e implementação
dc=incor,dc=usp,dc=br (nó raiz)
dn: cn=autorização 1,ou=usuario,ou=Authorizations,dc=incor,dc=usp,dc=br
objectClass: top
objectClass: incorauthorization
incorprivilegetype: dn: cn=Médico,cn=Profissional de Saúde,cn=usuario,cn=Papeis,ou=Groups,dc=incor,dc=usp,dc=br
incorprivilege: ler
objectClass: top
incorresourcedn: cn=Prescrição,cn=Serviço de Prescrição Médica,cn=PEP,ou=Resources,dc=incor,...
objectClass: incorrole
incorauthorizationtype:ou=groups
weak
ou=people
ou=resources
ou=authorizations
objectClass: incorgroup
incorroledn: cn=Usuario,cn=Papeis,ou=groups,dc=incor,dc=usp,dc=br
cn: Profissional de Saúde cn=papéis
cn=PEP
ou=usuario
cn: autorização 1
uid=josé.antônio
description: representa as funções e responsabilidades dos médicos.
cn=Serviço de Prescrição
cn=autorização 1
cn=usuário
member: uid=maria.augusta,ou=people,dc=incor,dc=usp,dc=br
Médica
cn=autorização 2
cn=Profissional de
member: uid=josé.antônio,ou=people,dc=incor,dc=usp,dc=br
uid=maria.augusta
cn=Prescrição
Saúde
cn=médico
ou=Profissional de
Saúde
cn=MACA
uid=luis.gustavo
cn=autorização 1
cn=Usuário
ou=médico
...
...
...
...
Representação do MACA no LDAP: árvore de informações
Recife, 6 de agosto de 2004
22
Arquitetura e implementação
► Servidor
de Segurança
 Autenticação e autorização
 Implementação
► Java
2 SE 1.4
 API JNDI
► OpenLDAP
2.1.17
► ORB
 LDAP/TLS
JacORB 1.4
 IIOP/TLS
 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/
Recife, 6 de agosto de 2004
23
Arquitetura e implementação
Autenticação de usuário
Recife, 6 de agosto de 2004
24
Arquitetura e implementação
PrincipalAuthenticator - IDL para autenticação de usuário
Recife, 6 de agosto de 2004
25
Arquitetura e implementação
PrincipalAuthenticator - uso em Java
Recife, 6 de agosto de 2004
26
Arquitetura e implementação
PrincipalAuthenticator – uso em Delphi
Recife, 6 de agosto de 2004
27
Arquitetura e implementação
Decisão e Controle de Acesso com o
Resource Access
Recife, Decision
6 de agosto de 2004 (RAD) Facility
28
Arquitetura e implementação
AccessDecision – IDL para decisão de acesso
Recife, 6 de agosto de 2004
29
Arquitetura e implementação
AccessDecision – uso em Java
Recife, 6 de agosto de 2004
30
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 (in string index);
boolean inEvaluation(in Any element, in Any aSet);
Any functionApplication(in string functionName,
in Vector argumentList);
};
};
Recife, 6 de agosto de 2004
31
Resultados
Tempo médio de resposta (ms)
► Disponibilidade
 Avaliação de desempenho
100
Exp. 1 - com cache e com IIOP/TLS
► Tempo
80
60
médio de resposta (TMR) para autorização e autenticação
TMR aumentou 3,6 vezes no
 Observar a variação do TMR com o aumento da carga no servidor de
intervalo [50-700]
autorização e autenticação
40
20
►0
0
0
50
100 150
a 700 usuários simultâneos, com a entrada progressiva de 60
200 250 300 350 400 450 500 550 600 650 700
agentes
simulando usuários a cada 5’
Usuários simultâneos
► TMR
1600
Média de solicitações por min.
do MACA
de 100 solicitações aferidos cada 50 novos usuários
 Servidor
Exp. 1 - autenticação com cache e com IIOP/TLS
1400
1200
Exp. 1 - autorização com cache e com IIOP/TLS
► 2xPentium
1000
III 1,3GHz, 1GBytes MP, 100 Mbits/s, Linux Suse 8.0
Carga média aumentou 8,7
 Clientes
800
600
►4
400
200
vezes
[50-700]
Pentium III 500MHz, 196 MBytes
MP, no
100intervalo
Mbits/s, Win/2000
 Estação de medição
0
0
50
100
150
200
►1
250
300
350
400
450
500
550
600
650
700
Pentium
III 800MHz, 326 MBytes MP, 100 Mbits/s, Win/2000
Usuários simultâneos
Recife, 6 de agosto de 2004
32
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,
► Dados
Magic/Delphi e Oracle/Java
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 24x7
Recife, 6 de agosto de 2004
33
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
34
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
35
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
36