Embed Size (px)
Citation preview
Controle de Acesso� “Tripple A”
� Autenticação� “Quem é”
� Autorização� ”Pode fazer”
� Auditoria� “O que fez”
Autenticação
� Identificação única do usuário
� Autenticação baseada em:� O que o usuário sabe (senha, PIN);
� O que o usuário possui (crachá, smart card, token);
� O que o usuário é (impressão digital, voz, retina, íris);
� Onde o usuário está (antes ou depois do firewall).
Autorização
� Define o que é ou o que não é permitido;
� Permissões;
� Analogia a um Sistema Operacional:� Permissão de Leitura, Escrita e Execução.
Auditoria
� Registrar operações e atividades realizadas;
� Deve associar a ação a um usuário;
� Logs, evidências, Assinatura Digital;
SSL - certificação digital� Protocolo SSL (Secure Socket Layer)
� Certificado Digital do Servidor� Garante identidade do servidor
� Clientes têm certeza que estão acessando o site desejado
Problemas SSL “simples”� Apenas um lado (servidor) foi “autenticado”
� Falta autenticar o cliente
� Webmails, Internet Banking:� Usuário/senha
� Autenticação muito fraca
� Fraudes eletrônicas
Exemplo do problemaExemplo do problema
� Bob quer acessar seu site do banco
� Digita https://www.weaksecuritybank.com
� Problemas:◦ Bob mal sabe o que é um certificado digital;
◦ E se alguém roubar seu usuário/senha?
Solução: SSL “duplo”� Cliente apresenta seu Certificado Digital
� SSL com autenticação cliente
� Autenticação é mais forte:� Cliente sabe algo (PIN)
� Cliente possui algo (smart card, token)
� Cliente é ele mesmo (certificado digital)
Controle de Acesso com
Certificação Digital
Autenticação:
• Autenticar Certificado Digital do Cliente
Autorização:
• Verificar se Cliente possui permissão ao serviço desejado
Auditoria:
• Registrar operação executada: assinatura digital
ExemploExemplo
Bob possui seu certificado digitalBob possui seu certificado digital
Acessa https://www.strongsecuritybank.comAcessa https://www.strongsecuritybank.com
Bob se autentica com seu certificado digitalBob se autentica com seu certificado digital
Bob é autorizado a movimentar sua contaBob é autorizado a movimentar sua conta
Bob assina digitalmente cada movimentaçãoBob assina digitalmente cada movimentação
Cadeias de Confiança
Como funciona: Servidor
Deve confiar na cadeia de certificados do Cliente
Certificado com extensão Server Authentication
Como Funciona: Cliente
Deve confiar na cadeia de certificados do Servidor;
Certificado com extensão de Client Authentication
Configurar SSL no Servidor� Possuir um certificado digital para o servidor
� Configurar o repositório de certificados confiáveis:� Truststore
� Lista das cadeias que o servidor confia
� Define quais certificados clientes poderão fechar SSL com o servidor
� Habilitar serviço HTPS com Cliente Authentication
Exemplo: Tomcat� Gerar certificado de servidor de testes:keytool -genkey -alias tomcat -keyalg RSA
–sigalg SHA1WithRSA -keystore tomcat.jks
-dname "C=BR, O=TESTE, OU=RIKO, CN=riko-sony“
-validity 365
� Criar Truststore com certificados confiáveis:keytool -import -trustcacerts -alias iti
-file certificadoACRaiz.crt
-keystore tomcat-truststore.jks
Exemplo: Tomcat� Configurar serviço HTTPS com Client Authentication
� Editar o arquivo conf/server.xml
� Iniciar o Tomcat� Acessar https://localhost:8443/� Será pedido o certificado digital do cliente cuja raiz seja da
ICP-Brasil
<Connector port="8443" protocol="HTTP/1.1" SSLEnable d="true“maxThreads="150" scheme="https" secure="true“keystoreFile="D:\riko\java\apache-tomcat6.0.14\conf \tomcat.jks“keystorePass="tomcat“truststoreFile="D:\riko\java\apache-tomcat-6.0.14\c onf\tomcat-truststore.jks“ truststorePass="tomcat“ clientAuth="true" sslProtocol="TLS" />
Aplicação Web - SSL com client
authentication� Criar controle de acesso baseado no certificado digital
do Cliente;
� Modelo:� Associar ao certificado digital um conjunto de
permissões que o Cliente pode executar;
� Permissões pré-cadastradas no sistema;
� Arquitetura do Controle de Acesso:� Aplicação Web: Java Servlets + Servlet Filters
� Autenticar, autorizar e auditar
Manipular Certificados Digitais� JCE – Java Cryptography Extension
� API para Criptografia
Dados do Certificado Digital
Autenticação - SSL
A autenticação SSL é feita entre o Cliente e o Servidor
O serviço SSL do Servidor é responsável em fechar ou não o SSL com o Cliente
A implementação do “SSL handshake” fica a cargo do
serviço SSL do Servidor
A aplicação web aguarda o Servlet Container repassar o HTTP REQUEST contendo o certificado digital do Cliente
Autorização� Após a autenticação feita entre o Cliente e o Servidor, a
aplicação web é chamada repassando o HTTP REQUEST;
� O HTTP REQUEST é encapsulado pela classe javax.servlet.http.HttpServletRequest ;
� Para extrair do HTTP REQUEST o Certificado Digital do Cliente:
final String CLIENT_CERT = "javax.servlet.request.X509Certificate";X509Certificate[] certs = (X509Certificate[]) req.getAttribute(CLIENT_CERT);
Autorização� Duas etapas:
1. Analisar o certificado digital do cliente;
2. Autorizar ou não o acesso ao sistema
� Como identificar o cliente?� Com o Certificado Digital do Cliente, é preciso saber
quem ele é no sistema;
� Mapear o Certificado Digital a um “username” ou ID;
� Verificar se esse “username” está autorizado a executar a operação desejada no sistema;
Autorização� Certificado Digital do Cliente:
� AKI – Authority Key Identifier� Serial Number
AKI SN
Auditoria� Criar evidências da ação executada;
� Associar a ação ao usuário:� Usar Assinatura Digital;
� Realizar a Assinatura Digital no Browser;� APIs específicas do Sistema Operacional;
� Applet;
� Submeter a Assinatura Digital e salvar como evidência;
Certificados ICP-Brasil� Autoridades Certificadoras (ACs) no Brasil devem
seguir as normas da ICP-Brasil;
� Definem regras para toda PKI (Public KeyInfrastructure) de uma AC;
� Além disso, definem o CONTEÚDO de cada certificado;
� Vantagem:� Aplicações conseguem obter dados de forma mais
confiável, como o CPF, CNPJ, data de nascimento etc;
Subject Alternative Name (SAN)� Política de Certificado é
publicada pelas Acs;
� Definem o conteúdo de cada extensão do certificado;
� SAN: campos OtherName com dados do dono do certificado (exemplo CPF)
PC de um e-CPF“7.1.2.3. Subject Alternative NameA ICP-Brasil define como obrigatória a extensão "Subject Alternative Name", não crítica, e com os seguintesformatos:a) para Certificados de Pessoa Física (e-CPF)a.1) 3 (três) campos otherName, obrigatórios, contendo, nesta ordem:i. OID = 2.16.76.1.3.1 e conteúdo = nas primeiras 8 (oito) posições, a data de nascimento do titular, noformato ddmmaaaa; nas 11 (onze) posições subseqüentes, o Cadastro de Pessoa Física (CPF) do titular;nas 11 (onze) posições subseqüentes, o número de Identificação Social - NIS (PIS, PASEP ou CI); nas15 (quinze) posições subseqüentes, o número do Registro Geral - RG do titular; nas 6 (seis) posiçõessubseqüentes, as siglas do órgão expedidor do RG e respectiva UF.ii. OID = 2.16.76.1.3.6 e conteúdo = nas 12 (doze) posições o número do Cadastro Especifico do INSS(CEI) da pessoa física titular do certificado.iii. OID = 2.16.76.1.3.5 e conteúdo = nas primeiras 12 (onze) posições, o número de inscrição do Título deEleitor; nas 3 (três) posições subseqüentes, a Zona Eleitoral; nas 4 (quatro) posições seguintes, a: Seção;nas 22 (vinte e duas) posições subseqüentes, o município e a UF do Título de Eleitor.”
Fonte: http://publicacao.certificadodigital.com.br/repositorio/pc/politica-srf-a3.pdf
SAN - extrair OIDsClasse java.security.cert.X509Certificate
JCE - limitações
Saída do programa teste*************************Valor inteiro=00?`L 6 4209011977260401198021248876740000000020868209 0SSPSP*************************Valor inteiro=00)+‚7 [email protected]*************************Valor [email protected]*************************Valor inteiro=00+`L " 2702790801322590470SAO PAULOSP*************************Valor inteiro=00`L 219051737000
Conclusão� Controle de Acesso com Certificado Digital Cliente
� Estrutura da Certificação Digital não é trivial
� ICP-Brasil e APIs do Java
OBRIGADO!
