4. 3o pilar da Qualidade da Aplicação
Funcionalidade
Performance
Segurança
5. Problemas
Os aplicativos Web são o alvo n° 1 dos hackers que
buscam explorar vulnerabilidades
Os aplicativos são implantados com vulnerabilidades
Configurações de baixa segurança expõem as empresas
à perdas de negócios
Os requisitos regulatórios de PCI exigem a segurança de
aplicativo
80% dos custos de desenvolvimento são gastos na
identificação e correção de defeitos
6. Benefícios
Reduz o risco de interrupção, desfiguração ou roubo de
dados associados com aplicativos Web
Assessora e monitora conformidade da política de
segurança em toda a empresa
Melhora a conformidade com as normas do setor e
exigências regulatórias (por exemplo PCI)
Melhora a capacidade de integrar aplicativos críticos
do negócio
Teste e controle automatizados durante todo o ciclo de
vida do desenvolvimento, reduzindo os custos de
segurança a longo prazo.
7. Motivações e objetivos
Controle de acesso incorporado nas aplicações pode falhar
Impacto no ciclo de desenvolvimento da aplicação
Limitação dos componentes desenvolvido internamente
Custo e prazo de atualização dos componentes
Modelo de autorização relativamente complicado
Falta de auditoria
Usar solução de mercado
Velocidade na colocação de novas aplicações
Aumentar controle de acesso – Diminuir falhas
Transparente para as aplicações
Auditoria de acesso
Gerenciamento unificado das políticas
8. Ciclo de vida da aplicação
Configuração
RAD - LDAP
Desenvolvimento -TAM
Local - WAS7
- Portal
Publicação em Replicação Publicação
homologação/
configurações em teste
produção
11. Modelo de segurança JEE
A segurança das aplicações JEE é implementada usando
papeis de segurança (Role)
Os papeis de segurança são aplicados nos componentes
Web e EJB
– métodos EJB ou URIs Web
A Segurança pode ser especificada de 2 maneiras:
– Declarativa em tempo de configuração, através dos
‘deployment descriptors’
– Programática utilizando as APIS padrões em tempo de
desenvolvimento
A associação dos usuários e dos grupos com os papeis JEE
é geralmente feito no momento da instalação da
aplicação (deploy)
12. Processo
Bob Ligação Papel-Permissão Método
EJB
Método
EJB
Administrador
Ana Método
EJB
Enterprise
Java Bean
Solicitante
Servlet
Corretores
jsp
Atendente gif,
css
Segurados
Role Segurança Componentes
Usuários/Grupos JEE Web
13. Modelo de autorização
baseado em papel
Quais papeis são permitidos? Acesso
-EJB: roles necessários dos autorizado
métodos
- Servlet/jsp: roles necessários
SIM
nas security constraints
Requisição Algum
autenticada igual?
Quais papeis são atribuídos?
- Obter nome do NÃO
usuário/grupo nos credenciais
- Obter os roles atribuídos a Acesso
esse usuário/grupo negado
14. Mapeamento
Grupo Mapeamento Application Deployment Descriptor
usuários
Usuário Recurso Mapeamento Role
Usuário
Usuário
Usuário
Usuário
Metodo EJB
Role
Role
Grupo URI Web
Grupo
Usuário
Role Mapeamento
Principal Definido pelo
programador da aplicação
Definido pelo
instalador da aplicação
15. Mapeamento Processos
(antigo-novo)
Cadastrar
papelRU
2
ETrust Papel RU Papel RA Permissão
Associar 6 5 4
Cadastrar
usuário 1 Papel RU ao Cadastrar permissão
usuário Associar papel Cadastrar papel RA e com descritor da
3 RA e papel RU associar permissão aplicação
Usuário
sincronização
GerenciadorLDAP
Colocar
usuário no
grupo Deploy-script RAD-Security Editor
Grupo RU Role JEE Recurso JEE
17. Segurança EJB declarativa
Implementação de segurança declarativa com Annotation
– Lista de annotations EJB
• @DeclareRoles
• @DenyAll
• @PermitAll
• @RolesAllowed
• @RunAs
18. Segurança EJB declarativa
Implementação de segurança declarativa com Annotation
– Restrigir acesso ao EJB de sessão Donate
import javax.annotation.security.DeclareRoles;
import javax.annotation.security.RolesAllowed;
....
@DeclareRoles( { "DMANAGERS_ROLE", "DUSERS_ROLE" })
public class DonateBean implements DonateBeanInterface, ...... {
@RolesAllowed( { "DMANAGERS_ROLE","DUSERS_ROLE" })
public void donateToFund(Employee employee, Fund fund, int hours) ...
......
@RolesAllowed( { "DMANAGERS_ROLE","DUSERS_ROLE" })
public String donateToFund(int employeeId, String fundName, int hours) {
19. Deployment descriptor EJB
ejb-jar.xml (diretório DonateEJB/ejbModule/META-INF) imediatamente antes do tag
</ejb-jar.xml>
<assembly-descriptor>
<security-role>
<role-name>DMANAGERS_ROLE</role-name>
</security-role>
<security-role>
<role-name>DUSERS_ROLE</role-name>
</security-role>
<method-permission>
<role-name>DUSERS_ROLE</role-name>
<role-name>DMANAGERS_ROLE</role-name>
<method>
<ejb-name>DonateBean</ejb-name>
<method-name>donateToFund</method-name>
</method>
</method-permission>
</assembly-descriptor>
Utilizar o editor de Segurança do RAD para auxilio
20. Segurança Web declarativa
Implementação de segurança declarativa com Annotation
– Lista de annotations Web
• @DeclareRoles
• @RunAs
21. Segurança WEB
Editor de segurança do RAD:
Restringir o acesso a páginas Web com segurança declarativa
22. Informações de segurança
O editor de segurança insere as seguintes informações no
arquivo web.xml:
A restrição de segurança <security-constraint> é o
elemento base que contém:
O elemento <web-resource-collection> define os
privilegios de acesso a um conjunto de recursos. Este
elemento pode especificar padrões de URL e métodos
HTTP.
O elemento <auth-constraint> define quais são os
roles necessários para acessar esse conjunto de recursos
Web.
O elemento <security-role> declare os nomes dos
roles utilizados nos elementos security-constraint.
27. Código para segurança
System.setProperty("com.ibm.SSL.ConfigURL", propDir +"ssl.client.props");
System.setProperty("java.security.auth.login.config", propDir +"wsjaas_client.conf");
System.setProperty("com.ibm.CORBA.ConfigURL",propDir +"sas.client.props");
Definir SSL, JAAS e SAS (Secure Authentication Services)
Propriedades necessárias para acessar o servidor
ctx.lookup("");
Conectar ao Contexto inicial para carregar o Realm default e
carregar as informações necessárias ao Security Server
LoginContext lc = new LoginContext("WSLogin",
new WSCallbackHandlerImpl("DNARMSTRONG", "xxxxxxxx")); o contexto do login,
Criar
lc.login(); fazer o login, e colocar o
final Subject subject = lc.getSubject(); usuário autenticado como
System.out.println("subject=" + subject.toString()); o usuário default para
WSSubject.setRunAsSubject(subject); este thread de execução
36. Introdução a JACC
JACC permite aos servidores de aplicação interagir
com fornecedores de autorização externos
usando interfaces padronizadas para tomar as
decisões de autorização
JACC define as classes de permissão para os
Containers EJB e Web
JACC não específica como atribuir roles aos
principais (grupos e usuários)
38. Adição WebSphere
• WebSphere suporta 2 “principals” especiais para o
mapeamento Role Principal:
– All Authenticated – role mapeado para All
Authenticated é atribuido a qualquer usuário
autenticado
– Everyone – role mapeado para Everyone é atribuido a
qualquer requisitante
39. Integração TAM com WAS
Os componentes do cliente TAM são embutidos
no WebSphere Application Server
TAM é o provedor default JACC para WebSphere
O cliente TAM pode ser configurado usando
scripts ou a console de administração
O servidor TAM pode fornecer função de
autenticação
41. Provedor TAM JACC
Configuração - 2
Aceitar Próximo slide
todos os
Defaults
42. Provedor TAM JACC
Configuração - 3
Servidor
Politicas
Servidor
Porta usado para Autorização
escutar as atualizações
da base de Politicas
Criado durante a
configuração da
Segurança WAS
51. Nomenclatura
Sintaxe
– Papel: RUXXXColaborador, RAYYYAdministrador
• XXX: empresa, diretória, área de negócio
• YYY: identificação do sistema
– Role J2EE: ROLE_YYYAdministrador
– Grupo: RUXXXColaborador
52. Configuração servidores
li412 li450 li413
TAM TAM
Web SEAL Web SEAL
Authorization Server Authorization Server D
m
Catalog Server WAS-Cluster Catalog Server
g
Session Manager WAS-Cluster Session Manager r
Policy Server RHEL-luci Policy Server
TSPM TSPM
TSPM WAS-Cluster TSPM D
m
DB2 DB2-Cluster DB2
g
TIP TIP r
54. Motivos para DataPower
XML é a linguagem de web services e SOA
XML é onipresente – Em alguns anos, XML estará em qualquer aplicação,
equipamento e documento presente nas redes das empresas.
Desafios do XML
– XML é muito ‘falante’
• XML precisa de muito banda.
• Tem um impacto direito sobre a performance do servidor de aplicação.
• O processamento XML precisa de um número significativos de ciclos de
processador e de recursos de memória.
– XML é um texto efetivamente legível por humano
• Não tem mecanismo nativo de segurança.
• Fácil de entender e vulnerável a intercepção.
• A segurança pode ser implementada no servidor de aplicação, mas é um
processamento adicional e aumenta o problema de performance.
– SOA não é somente Web Services e XML
• Empresas precisam integrar sistemas legados, formatos de mensagens e
protocolos numa arquitetura SOA.
• Necessidade de uma habilidade para transformar sistemas legados em
formato XML.
55. O que o DataPower endereça ?
Performance XML
– Como? – transferindo o processamento do XML do servidor de
aplicação para o hardware otimizado do DataPower.
– Por conseqüência, reduzindo o número necessário de
servidores de aplicação
Segurança XML
– Como? – transferindo a segurança XML para o DataPower
– Fornece a segurança padronizada – WS Security
Integração XML e sistemas legados
– Como ? – usando DataPower para transformar XML em
formato e protocolo legados de mensagem:
• XML -> HMTL (renderiza conteúdo HTML para Portal)
• XML <-> Mensagem MQ
Tudo é feito a velocidade de rede
56. Arquitetura com DataPower
Internet DMZ Intranet
Cliente
Applicações
• Ameaças XML • Transformação
• Controle Acesso • Integração
• SLA • Roteamento
Cliente
58. WebSphere DataPower XI50
Crypto XSLT Processor
2 x 160 GB XG3 or XG4
4GB RAM Processor HDD 512MB Flash Memory
Serial Port
4 x 10/100/1000 Ethernet Ports
59. Referência
Portonet: Home > Departamentos > Informática -
Arquitetura de TI > Arquitetura de Software > Documentos
Padrão de Arquitetura de Segurança Java.pdf
Contatos:
jose.cardoso@escalainfo.com.br
philippe.guillaume@portoseguro.com.br