UNIVERSIDADE DO RIO GRANDE DO NORTEFEDERAL
UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE
CENTRO DE TECNOLOGIA
PROGRAMA DE PÓS-GRADUAÇÃO EM
ENGENHARIA ELÉTRICA E DE COMPUTAÇÃO
Superando os Riscos da Segurança Baseada em Perímetro
Uma Abordagem com Identificação Federada através de
Certificados Digitais A3/ICP-Brasil e SAML
Wellington Silva de Souza
Orientador: Prof. D. Sc. Sergio Vianna Fialho
Dissertação de Mestrado apresentada ao
Programa de Pós-Graduação em Engenharia
Elétrica e de Computação da UFRN (área de
concentração: Engenharia de Computação)
como parte dos requisitos para obtenção do
título de Mestre em Ciências.
Natal/RN, fevereiro de 2013
UFRN / Biblioteca Central Zila Mamede
Catalogação da Publicação na Fonte
Souza, Wellington Silva de.
Superando os riscos da segurança baseada em perímetro uma abordagem
com identificação federada através de certificados digitais A3/ICP-Brasil e
SAML. / Wellington Silva de Souza. – Natal, RN, 2013.
85 f.: il.
Orientador: Prof. D. Sc. Sergio Vianna Fialho
Dissertação (Mestrado) - Universidade Federal do Rio Grande do Norte.
Centro de Tecnologia. Programa de Pós-Graduação em Engenharia Elétrica
e de Computação.
1. Redes de computação - Segurança. 2. Deperimetrização - Dissertação.
3. Cartões inteligentes – Redes de computação - Dissertação. 4. SAML -
Dissertação. 4. ICP-Brasil - Dissertação. I. Vianna Fialho, Sergio. II.
Universidade Federal do Rio Grande do Norte. III. Título.
RN/UF/BCZM CDU 004.7
Superando os Riscos da Segurança Baseada em Perímetro
Uma Abordagem com Identificação Federada através de
Certificados Digitais A3/ICP-Brasil e SAML
Wellington Silva de Souza
Dissertação de Mestrado aprovada em 18 de fevereiro de 2013 pela banca examinadora
composta pelos seguintes membros:
Prof. Dr. Sergio Vianna Fialho (orientador) . . . . . . . . . . . . . . . . . . . . DCA/UFRN
Prof. Dr. José de Ribamar Silva Oliveira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IFRN
Prof. Dr. Marcos Cesar Madruga Alves Pinheiro . . . . . . . . . . . . . DIMAP/UFRN
Prof. Dr. Luiz Affonso Henderson Guedes de Oliveira . . . . . . . . . . DCA/UFRN

Aos meus pais, Antônio e Fátima,
pelo amor com o qual fui criado e a
Diana Ferreira, minha esposa, pela
paciência e incentivo durante a
realização deste trabalho.

Agradecimentos
Ao meu orientador, professor Dr. Sergio Vianna Fialho, sou grato pela orientação e in-
centivo para concluir este trabalho.
À toda equipe do PoP-RN, pelo apoio durante o estágio docente.
Aos professores do PPgEEC, pelos conhecimentos transmitidos.
À minha família, pelo apoio incondicional durante esta jornada.
Sobretudo a Deus, pelo dom da vida e da perseverança na busca dos meus objetivos.

Todos os dias quando acordo,
Não tenho mais o tempo que passou.
Mas tenho muito tempo,
Temos todo o tempo do mundo.
Todos os dias antes de dormir,
Lembro e esqueço como foi o dia.
Sempre em frente,
Não temos tempo a perder.
(Renato Russo)
A ignorância sobre o que não
conhecemos nos dá a falsa sensação
de segurança, o que é muito pior do
que ter a noção real de que estamos
inseguros.
(Bruce Schneier)

Resumo
A visão tradicional de segurança em redes de computadores, baseada em perímetro
(modelo do “castelo e fosso”), além de entravar a evolução dos sistemas corporativos,
cria, tanto em administradores quanto usuários, a falsa ilusão de proteção. Para lidar com
a nova gama de ameaças, um novo paradigma orientado à segurança intrínseca dos dados,
chamado “deperimetrização”, começou a ser estudado na última década. Um dos requi-
sitos para a implantação do modelo deperimetrizado de segurança é a definição de um
mecanismo seguro e eficaz de identificação federada. Este trabalho busca preencher essa
lacuna, apresentando a especificação, modelagem e implementação de um mecanismo de
identificação federada, baseado na conjunção do protocolo SAML e certificados digitais
X.509 armazenados em cartões-inteligentes, padrão A3/ICP-Brasil.
Palavras-chave: deperimetrização, segurança de redes, cartões-inteligentes, SAML,
ICP-Brasil.

Abstract
The traditional perimeter-based approach for computer network security (the “castle
and the moat” model) hinders the progress of enterprise systems and promotes, both in
administrators and users, the delusion that systems are protected. To deal with the new
range of threats, a new data-safety oriented paradigm, called “de-perimeterisation”, began
to be studied in the last decade. One of the requirements for the implementation of the
de-perimeterised model of security is the definition of a safe and effective mechanism for
federated identity. This work seeks to fill this gap by presenting the specification, model-
ling and implementation of a mechanism for federated identity, based on the combination
of SAML and X.509 digital certificates stored in smart-cards, following the A3 standard
of ICP-Brasil (Brazilian official certificate authority and PKI).
Keywords: de-perimeterisation, network security, smart-cards, SAML, PKI.

Sumário
Sumário i
Lista de Figuras v
Lista de Tabelas vii
Lista de Símbolos e Abreviaturas ix
1 Introdução 1
1.1 Contexto, justificativa e objetivos . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Descrição do documento . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Perímetro x Segurança 5
2.1 O castelo e o fosso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Riscos da segurança baseada em perímetro . . . . . . . . . . . . . . . . . 6
2.3 Deperimetrização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Literatura relacionada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1 “What is Deperimeterization?” . . . . . . . . . . . . . . . . . . . 9
2.4.2 “No Borders – De-perimeterization and life after the firewall” . . 10
2.4.3 “’Deperimeterization’ demands new approach to security” . . . . 13
2.4.4 “Deperimeterization without endpoint control?” . . . . . . . . . . 13
2.4.5 “Between the Lines / Deperimeterization” . . . . . . . . . . . . . 14
2.4.6 “Security in a world without borders” . . . . . . . . . . . . . . . 15
2.4.7 “The Deperimeter Problem” . . . . . . . . . . . . . . . . . . . . 17
2.4.8 “Informação Segura / Deperimetrização” . . . . . . . . . . . . . 19
2.4.9 “Deperimetrização e Externalização” . . . . . . . . . . . . . . . 20
2.4.10 “Deperimetrização e Externalização, será?” . . . . . . . . . . . . 21
2.4.11 Deperimetrização e computação em nuvem . . . . . . . . . . . . 21
2.4.12 Conclusões sobre os trabalhos analisados . . . . . . . . . . . . . 22
2.5 Identificação federada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5.1 SAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.2 Soluções de identificação federada existentes . . . . . . . . . . . 24
3 Modelagem do Autenticador ICP/SAML 29
3.1 Definição da proposta de mecanismo de identificação federada . . . . . . 29
3.2 Identificação e modelagem dos casos de uso . . . . . . . . . . . . . . . . 30
i
3.2.1 Autenticador . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.2 Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 Diagramas de sequência. . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.1 O processo de Single-Sign-On SAML . . . . . . . . . . . . . . . 37
3.3.2 O processo de logon com cartão inteligente . . . . . . . . . . . . 37
3.4 Considerações finais sobre a etapa de modelagem . . . . . . . . . . . . . 41
4 Implementação do Autenticador ICP/SAML 43
4.1 Ferramentas de desenvolvimento utilizadas . . . . . . . . . . . . . . . . 43
4.1.1 Linguagem de programação . . . . . . . . . . . . . . . . . . . . 43
4.1.2 Applet x Aplicação Desktop . . . . . . . . . . . . . . . . . . . . 44
4.1.3 Applet x Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.1.4 Container de aplicação . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.5 OpenSAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.6 Demais ferramentas utilizadas . . . . . . . . . . . . . . . . . . . 45
4.2 Codificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.1 Módulo Applet . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.2 Módulo Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.3 Integração dos módulos . . . . . . . . . . . . . . . . . . . . . . 49
4.3 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3.1 SimpleSAMLphp . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3.2 TestShib Two . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4 Conclusões sobre as etapas de implementação e testes . . . . . . . . . . . 55
5 Estudo de Caso: Rede da Justiça Eleitoral 57
5.1 A infraestrutura de rede da Justiça Eleitoral . . . . . . . . . . . . . . . . 57
5.1.1 Conexão à Internet . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.1.2 Backbone Principal - TSE/TREs . . . . . . . . . . . . . . . . . . 58
5.1.3 Backbones Secundários - TRE/ZEs . . . . . . . . . . . . . . . . 59
5.1.4 O perímetro da Justiça Eleitoral . . . . . . . . . . . . . . . . . . 60
5.2 Classificação dos sistemas da Justiça Eleitoral . . . . . . . . . . . . . . . 61
5.2.1 Sistemas eleitorais e de apoio à eleição . . . . . . . . . . . . . . 61
5.2.2 Sistemas administrativos . . . . . . . . . . . . . . . . . . . . . . 61
5.2.3 Sistemas judiciais . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2.4 Sistemas de TIC . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.3 Deperimetrização aplicada à Justiça Eleitoral . . . . . . . . . . . . . . . 64
5.3.1 Aplicações do mecanismo desenvolvido . . . . . . . . . . . . . . 64
5.3.2 Identidade funcional digital . . . . . . . . . . . . . . . . . . . . 65
6 Considerações finais e trabalhos futuros 67
Referências bibliográficas 69
A Exemplos de elementos SAML 75
A.1 AuthnRequest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
A.2 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
A.3 Metadados do IdP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
B Identidade Funcional Digital 81

Lista de Figuras
2.1 Castelo Bodiam, Inglaterra. . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 O Aríete em Combate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Modelos de segurança: convencional e deperimetrizado. . . . . . . . . . 11
2.4 Externalização do acesso à rede corporativa. . . . . . . . . . . . . . . . . 20
2.5 Diagrama de mensagens do Shibboleth . . . . . . . . . . . . . . . . . . . 24
2.6 Diagrama de funcionamento do OpenID . . . . . . . . . . . . . . . . . . 26
3.1 O novo Registro de Identidade Civil. . . . . . . . . . . . . . . . . . . . . 30
3.2 Interação entre “Aplicação” e “Autenticador”. . . . . . . . . . . . . . . . 31
3.3 Diagramas de casos de uso. . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 Diagramas de sequência . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.1 Diagrama de classes do Applet. . . . . . . . . . . . . . . . . . . . . . . . 48
4.2 Diagrama de classes do Servlet. . . . . . . . . . . . . . . . . . . . . . . 50
4.3 Diagrama de classes do pacote de utilitários. . . . . . . . . . . . . . . . . 52
4.4 Seleção do IdP - SimpleSAMLphp. . . . . . . . . . . . . . . . . . . . . . 53
4.5 Requisição SAML capturada pelo SAMLTracer. . . . . . . . . . . . . . . 53
4.6 Tela de login do Applet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.7 Autenticação com sucesso - SimpleSAMLphp. . . . . . . . . . . . . . . 54
4.8 Tela de carregamento dos metadados do IdP - ShibTestTwo. . . . . . . . . 55
4.9 Autenticação com sucesso - ShibTestTwo. . . . . . . . . . . . . . . . . . 56
5.1 Rede da Justiça Eleitoral. . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2 Backbones Principal e Secundário. . . . . . . . . . . . . . . . . . . . . . 59
5.3 Ligação direta à Internet / Backbone deperimetrizado. . . . . . . . . . . . 59
5.4 Geração de contrasenha para estação com SIS. . . . . . . . . . . . . . . . 62
v

Lista de Tabelas
2.1 “Mandamentos” do Jericho Forum . . . . . . . . . . . . . . . . . . . . . 12
3.1 Caso de Uso: Gerar Assertiva SAML. . . . . . . . . . . . . . . . . . . . 33
3.2 Caso de Uso: Autenticar Usuário. . . . . . . . . . . . . . . . . . . . . . 33
3.3 Caso de Uso: Solicitar Certificado Digital e PIN. . . . . . . . . . . . . . 34
3.4 Caso de Uso: Acessar Aplicação. . . . . . . . . . . . . . . . . . . . . . . 35
3.5 Caso de Uso: Solicitar Assertiva SAML. . . . . . . . . . . . . . . . . . . 35
3.6 Caso de Uso: Consumir Assertiva SAML. . . . . . . . . . . . . . . . . . 36
3.7 Caso de Uso: Gerar Token SSO. . . . . . . . . . . . . . . . . . . . . . . 36
3.8 Mensagens do Processo de SSO SAML. . . . . . . . . . . . . . . . . . . 39
3.9 Mensagens do Processo Logon com Cartão Inteligente. . . . . . . . . . . 40
4.1 Atributos de usuário em um certificado A3 ICP-Brasil. . . . . . . . . . . 47
vii

Lista de Símbolos e Abreviaturas
ACL Access Control List
CA Central de Atendimento
CAFe Comunidade Acadêmica Federada
CSP Cryptographic Service Provider
DOS Denial of Service
DRM Data Rights Management
IaaS Infrastructure as a Service
ICP Infraestrutura de Chaves Públicas
IDS Intrusion Detection System
IPS Intrusion Prevention System
J2EE Java2 Platform Enterprise Edition
JE Justiça Eleitoral
MPLS Multiprotocol Label Switching
OID Object Identifier
P2P Peer-to-Peer
PaaS Platform as a Service
PDA Personal Digital Assistant
RIC Registro de Identidade Civil
RNP Rede Nacional de Ensino e Pesquisa
SaaS Software as a Service
SAML Security Assertion Markup Language
SGI Sistema de Gerenciamento de Identidade
ix
SIS Subsistema de Instalação e Segurança
TCO Total Cost of Ownership
TIC Tecnologia da Informação e Comunicação
TSE Tribunal Superior Eleitoral
URI Uniform Resource Identifier
URL Universal Resource Locator
VPN Virtual Private Network - Rede Virtual Privada
ZE Zona Eleitoral
Capítulo 1
Introdução
O desenvolvimento das redes de computadores ao longo das últimas décadas permitiu
à humanidade atingir um novo patamar de interatividade econômica e social. Seja em
nossos lares ou no ambiente empresarial e corporativo, o acesso à Internet nos é, hoje, tão
familiar como a água encanada e a energia elétrica. Segundo [Werthein 2000], a difusão
da Internet nos países industrializados deu suporte ao sonho de integração mundial dos
povos por meio de infovias globais. Nessa nova sociedade, a informação é a principal
mercadoria, o principal meio de geração e acumulação de valor.
Outrora considerada utopia, a ubiquidade tecnológica e de comunicação vivenciada
nas últimas décadas afeta sobremaneira as relações humanas, incluindo nesse rol as rela-
ções corporativas. Qualquer empresa ou instituição na atualidade possui alguma presença
na rede mundial de computadores: sítio na Web, redes sociais, interação com sistemas
computacionais de terceiros (bancos, governo, fornecedores, clientes), processos de ne-
gócios, pesquisa científica, ensino e aprendizagem.
No entanto, a mesma revolução trazida pela Tecnologia da Informação e Comunicação
(TIC) carrega em seu bojo um conjunto de novas ameaças para as quais as redes corpora-
tivas não estão preparadas. Observa-se que a velocidade de adoção de novas tecnologias
de computação e comunicação é superior à capacidade de compreensão e adequação aos
riscos envolvidos no processo. No ambiente corporativo, onde a preocupação com a se-
gurança da informação é (ou deveria ser) maior, é comum a resistência à adoção de novas
tecnologias. Exemplos disso temos no Wi-Fi, Peer-to-Peer (P2P), computação em nu-
vem, outsourcing e teletrabalho; tecnologias que são vistas com ceticismo por diversas
empresas e instituições.
Tal resistência encontra fundamento na visão tradicional de segurança adotada no
mundo corporativo. Nela, a proteção da informação é “garantida” por meio de um perí-
metro físico/lógico que separa a rede corporativa (rede interna) da Internet (rede externa).
Este modelo de segurança, baseado em perímetro, remonta à década de 90, quando se co-
meçou a pensar em segurança para a Internet. Nesta época temos o surgimento de diversas
ferramentas destinadas à proteção das redes de computadores: firewall, proxy, Intrusion
Detection System (IDS), Intrusion Prevention System (IPS).
Por mais que estas ferramentas ainda tenham sua utilidade no controle do tráfego
das redes, a evolução das tecnologias de comunicação permitem facilmente burlá-las,
conforme é mostrado neste trabalho.
2 CAPÍTULO 1. INTRODUÇÃO
Observa-se, assim, que as redes corporativas de empresas e instituições se mostram
completamente despreparadas ao lidar com ameaças advindas de novas tecnologias de
comunicação, comportamento de risco de usuários, interoperabilidade com sistemas de
terceiros e outsourcing.
Por hora, basta ao leitor refletir:
• De que adianta bloquear o funcionamento de aplicações e restringir acesso a sítios
se o usuário estabelecer uma conexão com uma Virtual Private Network (VPN) fora
dos limites do perímetro?
• De que adianta um conjunto de regras de firewall para bloquear o tráfego de en-
trada na rede se um usuário, ligado à rede corporativa, utilizar um acesso móvel à
Internet(modem 3G/4G) em sua estação de trabalho?
1.1 Contexto, justificativa e objetivos
Conforme mostrado no trabalho, ocorre atualmente, no ambiente corporativo, um en-
trave no desenvolvimento de sistemas e de processos de negócios diante das incertezas
decorrentes da falta de maturidade em segurança da informação, impedindo a exploração
de novas tecnologias computacionais e de comunicação
Este trabalho insere-se, assim, na discussão a respeito da segurança em redes corpo-
rativas - redes de computadores de empresas, indústrias, instituições, órgãos públicos,
universidades, entre outras de natureza similar. Em especial, contextualiza-se na análise
das deficiências do modelo de segurança adotado destas redes, baseado em perímetro.
Justifica-se o presente estudo tendo em vista permitir uma reavaliação do modelo de
segurança atualmente adotado nas redes de computadores em ambientes corporativos, o
qual se encontra defasado tecnologicamente, não atendendo as atuais necessidades de
comunicação de empresas e instituições em um mundo onde a Internet, a cada dia, se
torna mais presente (ubíqua) e fundamental para nosso modo de vida.
É apresentado um novo paradigma, denominado “deperimetrização”, cujo foco é li-
dar com os problemas de segurança da atualidade, não adequadamente abordados pelo
modelo atual, baseado em perímetro. Mostra-se também que o modelo de segurança de-
perimetrizado carece de algumas ferramentas tecnológicas para que possa ser utilizado
em sua plenitude. O objetivo deste trabalho é analisar estas carências, dando enfoque à
necessidade de um mecanismo eficaz e seguro para identificação federada.
Ao longo do desenvolvimento da dissertação é apresentada uma proposta de uma fer-
ramenta voltada à identificação federada, utilizando certificados digitais padrão A3 - ICP-
Brasil, consistindo na principal contribuição deste trabalho acerca do tema.
1.2 Descrição do documento
A dissertação está organizada em capítulos, segmentando os diversos conceitos pes-
quisados, analisados e desenvolvidos. O capítulo 2 apresenta os conceitos de segurança
1.2. DESCRIÇÃO DO DOCUMENTO 3
baseada em perímetro, bem como suas vulnerabilidades. Para lidar com estas, é apresen-
tado um novo paradigma, baseado no conceito de deperimetrização. Faz-se uma revisão
bibliográfica sobre o tema, acrescentando um levantamento sobre mecanismos de identi-
ficação federada existentes, permitindo assim a elaboração da proposta desenvolvida nos
capítulos subsequentes.
A seguir, o capítulo 3 aborda o levantamento de requisitos e modelagem da solução
de identificação federada proposta. Tal mapeamento é fundamental para estabelecer o
escopo do sistema desenvolvido, definindo as diretrizes seguidas no capítulo seguinte.
Dando continuidade, o capítulo 4 mostra a metodologia e ferramentas utilizadas para
codificar o modelo de aplicação definido no capítulo 3. São realizados testes com ferra-
mentas de referência de terceiros de modo a validar o produto implementado, ratificando
a eficácia do mesmo para utilização em ambiente de produção.
Por fim, o capítulo 5 traz um estudo de caso de um ambiente perimetrizado: a rede da
Justiça Eleitoral brasileira. É analisada a eficácia do modelo atual, baseado em perímetro,
utilizando como parâmetro os requisitos de segurança inerentes às atividades desenvol-
vidas. Com base nos estudos realizados nos capítulos anteriores, mostra-se as vantagens
que este ambiente obteria adotando o modelo de segurança deperimetrizada, sugerindo
algumas aplicações da ferramenta desenvolvida.

Capítulo 2
Perímetro x Segurança
Neste capítulo é efetuada uma abordagem sobre a eficácia do perímetro enquanto
mecanismo de segurança das redes de computadores - modelo conhecido como “o castelo
e o fosso”. Nessa avaliação, são mostrados os riscos em potencial da utilização do modelo
de segurança perimetrizado, o qual se baseia no critério dualista de classificação das redes
(interna x externa).
Apresenta-se, em seguida, um novo paradigma de segurança para redes de compu-
tadores, denominado “deperimetrização”, voltado à solução do problema, mostrando as
lacunas técnicas que devem ser preenchidas para que este possa ser utilizado. Uma delas,
o mecanismo seguro e eficaz de identidade federada, é escolhida para ser abordada neste
trabalho. Faz-se a seguir um levantamento das soluções existentes para tal propósito, de
modo a embasar a proposta desenvolvida nos demais capítulos.
2.1 O castelo e o fosso
Castelos, construções tradicionalmente associadas à Idade Média mas com origens
que remontam à Idade da Pedra, eram fortificações utilizadas para acomodação de milícias
e posteriormente nobres, chegando a abrigar e proteger cidades inteiras de ataques exter-
nos. Especialmente na Europa medieval, diante do constante estado de guerra, os castelos
tornaram-se a residência fortificada dos senhores feudais e das cortes reais. Além de
centro administrativo local, também eram utilizados para guarda de riquezas (geralmente
despojos de guerra) e arsenais.
Os principais mecanismos de defesa dos castelos eram a muralha (espessas paredes
constituídas principalmente a partir de blocos de pedra) e o fosso (geralmente inundado
ou repleto de estacas pontiagudas). Segundo [OneLinea 2010], é por esta razão que a ex-
pressão “castelo e o fosso” é comumente usada em analogia à descrição dos mecanismos
de defesa de um sistema baseado em firewall nas redes de computadores.
A muralha de um castelo, assim como um firewall, visa definir um perímetro de de-
fesa que mantém os atacantes o mais afastados quanto possível. No castelo, o conjunto de
defesas (muralha, fosso, arqueiros, piche ou água fervente) se concentra na linha que se-
para o ambiente externo e hostil do ambiente interno. Este último, dotado de benfeitorias
(praças, fontes, mercado público) e pessoas (nobres, plebeus e militares), era o bem que
deveria ser protegido. Em TIC o conjunto de defesas (firewall, proxy, IDS, IPS) também
6 CAPÍTULO 2. PERÍMETRO X SEGURANÇA
Figura 2.1: Castelo Bodiam, Inglaterra.
se concentra no limiar entres as redes interna (acreditada como confiável) e externa - In-
ternet - considerada extremamente insegura, um território virtual hostil. Os bens a serem
protegidos são análogos: benfeitorias (infraestrutura de rede, sistemas de informação e,
sobretudo, os dados) e pessoas (diretores, empregados/servidores, profissionais de TIC).
2.2 Riscos da segurança baseada em perímetro
De acordo com [HSW 2011], após o século 16, os castelos entraram em decadên-
cia como forma de defesa, principalmente devido à invenção e ao desenvolvimento de
pesados canhões e morteiros. A artilharia poderia lançar pesadas bolas de canhões com
tamanha força, que nem muros muito fortes resistiam. Outras ferramentas, como o aríete
(Figura 2.2), também eram capazes de romper as muralhas e os portões das fortificações.
Da mesma sorte, sistemas baseados em perímetro enfrentam hoje novas ameaças de se-
gurança para os quais não estão preparados.
Nesse aspecto, não se trata apenas de melhorar os algoritmos de filtragem ou criar
novas heurísticas de análise de tráfego. O modelo de segurança baseado em perímetro é
incapaz de fornecer segurança adequada diante de novas formas de ataque. Além disso,
mesmo ataques clássicos podem ser bem sucedidos quando executados dentro do períme-
tro:
• Acesso móvel à Internet: Smartphones e modems 3G/4G estão se tornando itens
comuns do cotidiano. Nada impede que um funcionário os conecte à sua estação de
trabalho e acesse conteúdo bloqueado pela política de segurança da empresa.
• Conectividade Wi-Fi: Caso não exista proteção de rede no nível de enlace (802.1X
[Jeffree et al. 2010], por exemplo) pontos de acesso Wi-Fi podem ser conectados
2.2. RISCOS DA SEGURANÇA BASEADA EM PERÍMETRO 7
Figura 2.2: O Aríete em Combate
[Cellarius 1645].
de forma não autorizada à rede corporativa, provendo a atacantes nas imediações
acesso à rede interna. O mesmo ocorre caso seja utilizado um método de autentica-
ção ou criptografia inadequados, como WEP (mecanismo baseado no uso de chave
privada de pequeno tamanho, o que facilita sua descoberta) ou WPA no modo ‘per-
sonal’ (no caso de “vazamento” da chave compartilhada).
• Perímetro em uma rede de grande porte: As redes de grandes companhias ou or-
ganizações (um campus universitário, por exemplo), apesar de classificadas como
“locais”, são inerentemente hostis - ataques internos são frequentes. Num ambi-
ente com centenas ou milhares de computadores e usuários uma defesa baseada em
perímetro não faz muito sentido.
• Utilização de VPN para burlar a política de segurança: Aplicativos como o
OpenVPN [OpenVPN 2012] permitem ao usuário comum estabelecer uma conexão
com um ponto remoto fora do perímetro da rede, podendo assim acessar qualquer
conteúdo bloqueado pela política de segurança. Além disso, tais aplicativos podem
encriptar o tráfego, mascarando-o como uma conexão HTTPS regular.
• Mascaramento de URL através de registros de DNS alternativos: É comum a
restrição de acesso a determinados tipos de conteúdos Web no ambiente corpora-
tivo, por exemplo: música, vídeo, jogos, redes sociais, webmail de terceiros, dentre
outros. Tendo em vista que geralmente esta restrição se dá com base em URL, basta
ao usuário criar entradas DNS alternativas em um servidor próprio ou de terceiros,
como o NoIP [NoIP 2012].
• Malware: Malware também podem criptografar e encapsular tráfego sobre HTTP,
8 CAPÍTULO 2. PERÍMETRO X SEGURANÇA
ocultando sua presença na rede. Mesmo que haja filtragem de conteúdo e antivírus
na borda de rede, um pen-drive ou notebook infectado externamente pode dissemi-
nar um malware na rede interna. Nessa situação, o atacante pode ter controle total
sobre uma estação e, a partir dela, disparar ataques a sistemas internos ao perímetro.
• Mobilidade da informação: Mesmo que o perímetro fosse perfeito, seu modelo
presume que todos os ativos (equipamentos, pessoas, informação) estão em seu
interior. Contudo, com a utilização de notebooks, pen-drives e smartphones, infor-
mação valiosa entra e sai da organização a todo tempo, burlando tanto o perímetro
físico como o lógico.
Dualismo: as “redes boas” e as “redes más”
É fato que administradores de rede tendem a criar uma concepção dualista na avaliação
das redes de computadores, definindo-as como “boas” e “más”. De um lado temos a
rede interna, LAN, considerada “boa”, segura. Do outro a rede externa, WAN, a rede
“má”, perigosa, onde residem todas as ameaças, que devem ser combatidas a todo custo.
Nessa concepção, todos os investimentos em mecanismos de segurança (equipamentos,
software, contratação de pessoal e treinamento) visam proteger a rede interna dos perigos
advindos da rede externa.
É interessante observar que este paradigma está tão arraigado na visão de segurança
de profissionais e empresas de TIC, que sistemas operacionais e mesmo dispositivos em-
barcados voltados à proteção da informação adotam definições dualistas na configuração
de seus sistemas e equipamentos. Ao definirmos, por exemplo, que determinada interface
de rede do sistema pertence à WAN, diversas regras de firewall extremamente restritivas
são ativadas per default, restringido ao máximo o tráfego permitido naquela interface. Por
outro lado, os dados trafegados numa interface associada à LAN geralmente são liberados
por padrão, ou passam por critérios de avaliação extremamente relaxados se comparados
aos da WAN.
O problema dessa abordagem reside no fato de ignorar por completo uma fonte com
enorme potencial de perigo à segurança da informação. Estando a interface LAN de um
sistema aberta a qualquer tráfego de forma indiscriminada, qualquer atacante dentro da
rede interna tem grandes chances de sucesso no ataque a algum serviço daquele sistema.
Outro risco seria o atacante se utilizar de artifícios para ter acesso a alguma estação co-
nectada à LAN e, a partir desta estação, disparar o ataque a algum sistema disponibilizado
na rede interna.
Além disso, e ainda mais grave, tal abordagem fomenta nos profissionais de TIC,
em especial naqueles ligados à segurança da informação, uma falsa sensação de que os
sistemas corporativos estão protegidos de ameaças, uma vez que tais sistemas, estando
dentro do perímetro, estão imunes ou com superfície de ataque mínima às investidas de
hackers, crackers, malware, entre outros, pois (acredita-se que) estes residem (somente)
na rede externa.
2.3. DEPERIMETRIZAÇÃO 9
2.3 Deperimetrização
De modo a contornar os riscos apresentados pela segurança baseada em perímetro,
uma nova abordagem começou a ser pesquisada na última década. Nessa abordagem a
segurança é trazida próxima aos dados, pois estes são, em última instância, o que se deseja
proteger.
O termo “deperimetrização” teve sua origem num artigo de Jon Measham [Simmonds
& Seccombe 2009], o qual se tornou referência para criação do Jericho Forum [JerichoForum
2009]. Tal fórum é o principal palco no qual são discutidos assuntos relativos ao tema e
do qual fazem parte diversas companhias, universidades, instituições de pesquisa e pro-
fissionais diversos ligados às áreas de TIC, e segurança da informação.
O mesmo artigo informa que a grafia correta, em língua inglesa, é hifenizada e com
“s”: de-perimeterisation, sendo, no entanto, frequentemente usadas variantes não hifeni-
zadas ou com “z” - deperimeterisation, deperimeterization, de-perimeterization – apesar
de serem categoricamente consideradas incorretas pelo Jericho Forum.
Para o presente trabalho, optou-se por adotar o neologismo “deperimetrização”, o
qual, além de ser a derivação mais adequada conforme os ditames da língua portuguesa,
é também a expressão mais corrente nos textos em português sobre o tema.
Procedeu-se então a uma revisão bibliográfica do assunto. São relatados os artigos
analisados, fornecendo um resumo acrescido de comentários e entendimentos. Tal análise
leva em conta principalmente as contribuições do texto em questão para a compreensão
do tema geral, bem como sua aplicação em um ambiente real (estudo de caso mostrado
no capítulo 5), definindo os elementos teóricos necessários à elaboração da proposta apre-
sentada ao final deste capítulo.
2.4 Literatura relacionada
Após definição do tema principal, procedeu-se uma busca por artigos e textos rele-
vantes ao mesmo. Nota-se que quase a totalidade caracteriza-se por artigos informais,
não-acadêmicos, disponíveis em sítios na Internet. A seguir, apresenta-se um resumo dos
diversos materiais encontrados, acrescidos de comentários e interpretações obtidas.
2.4.1 “What is Deperimeterization?”
O artigo [SearchSecurity 2007] define deperimetrização como uma estratégia multi-
nível de proteção que se utiliza de encriptação e autenticação dinâmica no nível de dados.
Utiliza a analogia de um castelo para mostrar como a segurança é tratada atualmente:
colocam-se os dispositivos de rede por trás de um firewall e todos os esforços são dire-
cionados a deixar invasores do lado de fora. Indaga a praticidade do modelo tradicional
diante do advento dos WebServices e da força de trabalho móvel: teletrabalho, smartpho-
nes, dentre outros.
Também dá um exemplo de como a deperimetrização poderia facilitar a expansão dos
negócios de uma empresa ao tentar abrir uma filial de vendas. No modelo tradicional,
seriam gastos de 1 a 6 meses com negociação de contratos de linha dedicada, ramais
10 CAPÍTULO 2. PERÍMETRO X SEGURANÇA
telefônicos, rede local e VPN. No modelo deperimetrizado bastaria conectar os micro-
computadores e telefones VoIP à Internet, uma vez que toda a infraestrutura de rede da
companhia estaria segura, mediante tráfego criptografado, autenticação de usuários e au-
torização de acesso.
2.4.2 “No Borders – De-perimeterization and life after the firewall”
A introdução do artigo [Fritsch 2008] salienta as mudanças que vêm ocorrendo atual-
mente nas redes de empresas e organizações. A percepção de segurança, outrora fornecida
por um perímetro baseado em um firewall, começa a perder sentido na esteira da chegada
de novas tecnologias como VPN, e-commerce, WebServices e Web 2.0.
Os firewalls, tidos como objetos de orgulho de qualquer departamento de segurança,
eram projetados de modo a proteger a rede interna ao acesso externo, principalmente
através do bloqueio de portas. O acesso aos serviços, porém, eram disponibilizados a
qualquer um que estivesse do lado de dentro do perímetro – LAN. No entanto, a visão
tradicional “preto-e-branco”, na qual temos a distinção entre a “segura” rede interna e a
“perigosa” rede externa, nunca foi realmente simples como parecia. De fato, especialistas
em segurança enfrentam, hoje, grande dificuldade em segregar o que está “dentro” do
que está de “fora” nas redes de computadores. O acesso remoto através de Personal
Digital Assistant (PDA), telefones celulares, notebooks e VPN faz surgir novas bordas do
perímetro em todo lugar a todo tempo. Além disso, no passado, cada serviço tinha uma
porta claramente definida e associada, a qual era facilmente controlada pelo firewall. Mas
hoje, a maioria dos serviços, baseados no modelo WebService, enfatiza a utilização do
protocolo HTTP/HTTPS (portas 80 e 443), dificultando assim a distinção entre estes no
escopo do perímetro da rede.
O que pode ser visto como um verdadeiro problema – adaptar o tradicional conceito de
firewall à nova realidade – é encarado por alguns especialistas como uma oportunidade do
surgimento de uma mudança de paradigma, a qual contemple a complexidade das redes
atuais.
É nesse escopo que surge, a partir de estudos do Jericho Forum, uma nova visão em
segurança de redes. E o cerne dessa nova visão está no conceito da deperimetrização:
transpassar a visão tradicional de rede como um espaço finito, com interior, exterior e
um perímetro que os separa. De acordo ainda com o Jericho Forum, as redes de com-
putadores, hoje, enfrentam uma variedade tão ampla de ameaças, que a única estratégia
de segurança confiável é a proteção da própria informação, em detrimento à rede ou ao
restante da infraestrutura de TI da organização. Nessa linha de pensamento, a segurança
de uma rede qualquer não deve ser baseada em um suposto perímetro.
A figura 2.3 esboça um comparativo entre o modelo convencional de segurança, de-
nominado “Anéis de Confiança” e o novo paradigma, deperimetrizado. No modelo con-
vencional, os dados necessitam de sucessivos encapsulamentos para serem manipulados e
a segurança da informação é provida pelas camadas superiores. Cada anel estabelece um
perímetro que protege seu interior do que está à sua volta, provendo comunicação do lado
“seguro” para o “inseguro”. Já no modelo deperimetrizado, os dados são considerados in-
dependentes de contexto (escopo de rede local ou Internet) e não dependem de aplicação,
2.4. LITERATURA RELACIONADA 11
Figura 2.3: Modelos de segurança: convencional e deperimetrizado.
sistema operacional ou da rede para permanecerem seguros.
A proteção da informação deve contemplar muito além da simples restrição de acesso
ao equipamento onde a mesma se encontra. Além disso, deve-se levar em conta a premissa
que nenhuma rede é efetivamente segura. Sendo assim, cada dispositivo deve, também,
ser capaz de resguardar sua própria segurança, mesmo quando colocado diretamente e de
forma aberta sob a Internet. De fato, a importância de uma rede local deve diminuir ou
mesmo desaparecer nos próximos anos, especialmente quando se leva em consideração
tecnologias como IPv6 e computação em nuvem.
A solução ideal seria aquela na qual a própria informação possuísse atributos que as-
segurassem que o acesso à visualização ou alteração de conteúdo fosse restrito somente
àqueles aos quais ela se destina. Tal abordagem, conhecida como Data Rights Mana-
gement (DRM), vai muito além da simples criptografia dos dados, pois envolve também
a autenticação e autorização diretamente no nível de dados. De fato, existem esforços
de diversas empresas de software - entre elas Microsoft, Oracle e RSA – no desenvolvi-
mento de arcabouços para o modelo DRM. No entanto, as soluções existentes não levam
em consideração o fato que a deperimetrização visa facilitar o fluxo das informações, o
qual só ocorreria através da padronização e adoção, pela indústria, de um modelo aberto,
independente de fabricante.
Outra lacuna é a segurança dos dispositivos. Nenhum sistema operacional, hoje, é
suficientemente seguro para os padrões que a deperimetrização preconiza, tampouco as
aplicações. Basta observar a quantidade de falhas de segurança descobertas a cada dia
para confirmar essa premissa. A segurança inerente aos dispositivos não dever ser susce-
tível a erros simplórios de programação, e nesse aspecto ainda há muito a ser trabalhado.
A visão de uma rede segura sem bordas é definida num documento do Jericho Forum
denominado “Mandamentos” [JerichoForum 2007], como pode ser observado na tabela
2.1. Trata-se na realidade de um conjunto de princípios, alguns bem conhecidos na área
de segurança de redes, outros realmente radicais e inovadores. Em resumo, os manda-
mentos recaem basicamente em 4 áreas: criptografia, segurança de protocolos, segurança
de sistemas e autenticação/autorização no nível dos dados.
12 CAPÍTULO 2. PERÍMETRO X SEGURANÇA
Tabela 2.1: “Mandamentos” do Jericho Forum
[JerichoForum 2007].
Fundamentos
1. O escopo e o nível de proteção devem ser específicos e apropriados para
o bem em risco.
• Os negócios exigem que a segurança permita agilidade e seja custo-
efetiva.
• Mesmo que firewalls de borda ainda continuem fornecendo proteção de
rede básica, sistemas individuais e dados terão de ser capazes de proteger
a si mesmos.
• Geralmente, quanto mais próxima do bem mais fácil é a tarefa de aplica-
ção da segurança sobre o mesmo.
2. Mecanismos de segurança devem ser genéricos, simples, escalonáveis e
fáceis de gerenciar.
• A complexidade desnecessária é uma ameaça à boa segurança.
• Princípios de segurança coerentes são necessários para abranger todos os
níveis da arquitetura.
• Os mecanismos de segurança devem ser escalonáveis, abrangendo desde
pequenos a grandes objetos.
• Para serem ao mesmo tempo simples e escalonáveis, os “blocos de cons-
trução” de segurança interoperáveis devem de ser capazes de serem com-
binados de modo a fornecer os mecanismos de segurança necessários.
3. Considere os riscos do contexto.
• As soluções de segurança projetadas para atuar em um determinado am-
biente não podem ser transferidas para atuar em outro. Dessa forma, é
importante compreender as limitações de qualquer solução de segurança.
• Problemas, limitações e riscos podem vir de uma variedade de fontes, in-
cluindo geográfica, jurídica, técnica, aceitabilidade do risco, etc
Sobrevivência em um mundo hostil
4. Dispositivos e aplicações devem se comunicar usando protocolos seguros
e abertos.
• Segurança através da obscuridade é uma falsa presunção - protocolos se-
guros exigem abertura à revisão pelas partes de modo a fornecer uma
avaliação robusta e, assim, amplo uso e aceitação.
• Os requisitos de segurança de confidencialidade, integridade, disponibili-
dade e confiabilidade devem ser avaliados e construídos dentro dos proto-
colos, não fornecidos como um acréscimo a estes.
• O encapsulamento do tráfego de dados de forma criptografada não resolve
todos os problemas e deve ser utilizado somente quando necessário.
5. Todos os dispositivos devem ser capazes de manter sua política de segu-
rança quando em uma rede não-confiável.
• A “política de segurança” define as regras no que diz respeito à proteção
do bem.
• As regras devem ser completas no que diz respeito a um contexto arbitrá-
rio.
• Qualquer aplicação deve ser capaz de sobreviver na Internet bruta, isto é,
não “quebrar” em qualquer entrada de dados.
A necessidade de confiança
6. Para o estabelecimento de qualquer transação, todas as pessoas, processos
e tecnologias precisam ter níveis de confiança declarados e transparentes.
• Confiança, neste contexto, é estabelecer um entendimento entre as partes
contratantes de modo a conduzir uma transação e definir as obrigações de
cada parte.
• Modelos de confiança devem abranger pessoas/organizações e
dispositivos/infra-estrutura.
• Os níveis de confiança podem variar de acordo com o tipo e risco da tran-
sação, localização e o papel do usuário.
7. Níveis de garantia de confiança mútua devem ser determináveis.
• Dispositivos e usuários devem ser capazes de estabelecer níveis adequa-
dos de mútua autenticação para acessar sistemas e dados.
• Estruturas de autenticação e autorização devem suportar o modelo de con-
fiança.
Gerenciamento, Identidade e Federação
8. Os mecanismos de autenticação, autorização e auditoria devem ser capa-
zes de interoperar / interagir fora do seu local / área de controle.
• Pessoas / sistemas devem ser capazes de gerenciar direitos e permissões
de acesso a recursos de usuários que não estejam sob seu controle.
• Deve haver capacidade de se confiar em uma organização, a qual pode
autenticar indivíduos ou grupos, eliminando assim a necessidade de criar
identidades separadas.
• A princípio, apenas uma instância da pessoa/sistema/identidade deveria
existir, mas requisitos de privacidade podem exigir o suporte a várias ins-
tâncias, ou uma instância com múltiplas facetas.
• Os sistemas devem ser capazes de repassar assertivas e credenciais de se-
gurança.
• Deve haver suporte a múltiplas áreas de controle.
Acesso aos dados
9. O acesso aos dados deve ser controlado por atributos de segurança dos
dados em si.
• Atributos podem ser guardados dentro dos dados (metadados/DRM) ou
podem residir num sistema separado.
• Acesso/segurança pode ser implementado por criptografia.
• Alguns dados podem ter atributos “públicos, não-confidenciais”.
• O acesso e os direitos de acesso têm um componente temporal.
10. Privacidade de dados (e segurança de qualquer bem de valor suficiente-
mente elevado) requer uma segregação de funções / privilégios.
• Permissões, chaves, privilégios, etc. devem, em última análise, residir em
um mecanismos de controle independente, ou haverá sempre um elo mais
fraco no topo da cadeia de confiança.
• O acesso de administrador também deve estar sujeito a estes controles.
11. Por padrão, os dados devem ser adequadamente protegido quando arma-
zenados, em trânsito, e em uso.
• Retirar o padrão deve ser um ato consciente.
• Segurança elevada não deve ser aplicada para tudo; o termo “adequado”
implica em vários níveis de proteção, com possibilidade para que alguns
dados fiquem completamente inseguros.
2.4. LITERATURA RELACIONADA 13
2.4.3 “’Deperimeterization’ demands new approach to security”
O artigo [OrangeBusiness 2008] atenta para um fato curioso, observado na publicação
“2008 – Security Survey” do Computer Security Institute (CSI) [Richardson 2008]: os
gastos médios das organizações decorrentes de falhas de segurança pararam de diminuir
nos últimos anos. Observando uma retrospectiva destes gastos na década, percebe-se que
eles diminuíam ano após ano, de modo não linear, chegando no nível mais baixo em 2006.
A causa para essa estagnação, segundo o artigo, é a maneira como as redes são protegidas
atualmente: “cercar e vigiar”.
Por “cercar e vigiar” entenda-se as abordagens tradicionais adotadas, as quais são
projetadas de modo a proteger as fronteiras da rede, tais como firewalls. Nesse modelo,
protege-se o perímetro, onde ocorre a troca de tráfego de dados com o mundo exterior,
deixando os sistemas relativamente vulneráveis na rede local. Pode-se caracterizar a pro-
blemática atual como uma conjuntura de fatores: fronteiras amorfas, mudança de práti-
cas de trabalho e técnicas inovadores de ataque. Como exemplos, são citados: acesso
à intranet através de uma rede externa (extranet, VPN, entre outros); funcionários que
contaminam notebooks com vírus fora da empresa e depois voltam a conectá-los à rede
corporativa; e ataques de engenharia social, persuadindo funcionários a visitar sites mali-
ciosos. Chega-se à conclusão clara que o perímetro, hoje, é repleto de “buracos”.
Segundo especialistas, ao invés de proteger apenas as bordas da rede, usando técnicas
simples como bloqueio de portas e varredura de e-mails, as companhias devem buscar
uma abordagem deperimetrizada, baseada em papéis e identidades. Nela, assumimos que
a rede definitivamente não é confiável, por mais que se tente protegê-la. Portanto, torna-se
necessária uma “defesa em profundidade”, na qual múltiplas camadas de tecnologia são
adotadas com o fim maior de proteção dos bens mais preciosos – os dados. A respeito
destes últimos, torna-se fundamental conhecer seu ciclo de vida dentro da organização –
onde estão e como são usados – de modo a propiciar-lhes a proteção necessária.
Para que isso ocorra, é necessário aumentar a sinergia entre a gerência de negócios e
a gerência de TIC dentro das organizações. Históricamente, a segurança de TIC é tratada
como uma função isolada, por vezes compreendendo um departamento distinto. Para
o modelo deperimetrizado, o que devemos observar no futuro é uma “convergência de
segurança”, na qual haverá total integração entre a gerência de segurança de TIC e a
gerência de processos de negócio.
Tendo essas considerações em mente, vê-se que a segurança deve ir muito além do
perímetro, adentrando na rede, chegando aos endpoints (nós da rede: computadores, ser-
vidores, sistemas, ativos de rede, entre outros).
2.4.4 “Deperimeterization without endpoint control?”
Neste artigo [de Barros 2009], temos um discurso informal do tema “deperimetri-
zação”. Caracteriza o problema chave do novo paradigma no “controle dos endpoints”.
Basicamente, se o esforço de defesa é trazido ao nível dos endpoints, é vital ter con-
trole sobre eles. Permitir a endpoints, sobre os quais não se tem controle, acesso a dados
restritos de sua companhia implica em dizer que os dados deixam de ser restritos.
14 CAPÍTULO 2. PERÍMETRO X SEGURANÇA
O artigo justifica o posicionamento, chamando a uma reflexão de como uma visão de
segurança centrada nos dados funcionaria. Seria algo semelhante a agentes embarcados
em cada endpoint ou mesmo carregados junto aos dados, encapsulando-os. Independente
da metodologia aplicada, os agentes de segurança seriam executados diretamente no end-
point. Dessa forma, um usuário com poderes administrativos sobre aquele dispositivo
poderia modificar o agente de modo a burlar os mecanismos de segurança e fazer com
que este realize tarefas não previstas, até mesmo as que se propunha a prevenir.
Como, então, evitar que usuários tenham acesso administrativo aos seus próprios dis-
positivos? Simplesmente não é possível, não com a tecnologia utilizada na atualidade.
Um solução seria a adoção em larga escada do Trusted Platform Module – TPM, o qual
enfrenta diversas dificuldades de emplacar no mercado, dado a resistência dos usuários e
de sociedades de proteção das liberdades individuais [Stephan & Vogel 2011].
Como alternativa, o artigo é taxativo: permanecer com o que se tem hoje. Sempre
será necessário ter total controle sobre a rede e seu ambiente físico, além de colocar
restrições sobre quais dispositivos podem ser utilizados. O controle de acesso – escolher
cuidadosamente “quem acessa o que” e sob quais condições – nunca deixará de existir.
Apesar de notadamente cético, o artigo levanta questões importantes sobre a temática
em questão. Deve-se levar em conta uma série de problemas que podem advir da utiliza-
ção de um novo paradigma de segurança que não se baseia em perímetro. Em especial,
está a questão das relações de confiança entre os entes (pessoas, sistemas, dispositivos)
da infraestutura deperimetrizada. Sobre isso se manifesta o Jericho Forum, conforme
mostrado na tabela 2.1:
“6. Todas as pessoas, processos e tecnologias precisam ter transparentes e
declarados níveis de confiança para o estabelecimento de qualquer transação.
. . . Os níveis de confiança podem variar de acordo com a localização, tipo e
risco da transação e o papel do usuário.”
A questão volta-se, então, não mais para o controle do endpoint e sim no nível de
confiança assumido para o mesmo. Um modelo de segurança deperimetrizado deve, pois,
presumir que dispositivos, sistemas e usuários tenham capacidade de autenticação e auto-
rização mútua, de maneira transparente e determinável. Tais características devem expli-
citamente fazer parte do framework/modelo adotado. Necessitam, também, ser adequadas
às características da organização e ao nível de proteção que se deseja obter no nível de
dados. A caracterização dos dados faz-se então necessária, pois apenas aqueles que repre-
sentam algum bem informacional valioso e privativo necessitam de requintes de proteção
elevada. A maioria, no entanto, por representar um risco transacional menor, pode reque-
rer níveis de confiança menos exigentes - reduzidos ou mesmo nulos.
2.4.5 “Between the Lines / Deperimeterization”
De acordo com Gordon Eubanks, CEO da Oblix (empresa que comercializa soluções
de gerenciamento de identidade), “hoje, assim como no passado, as companhias erguem
em torno de si espessas paredes de castelo e um fosso ao redor. O novo modelo é um
2.4. LITERATURA RELACIONADA 15
ambiente mais poroso, o qual facilitará a conexão de pessoas e organizações” [Farber
2004].
Tal representação, do “castelo e fosso”, é frequentemente utilizada para representar a
forma como a segurança da informação é tratada hoje, assim como foi no passado. As
paredes podem ser tidas como o perímetro, mais precisamente o firewall das organizações.
O fosso, a separação entre a rede interna e a externa. Por fim, os portões e a ponte levadiça
seriam as regras que permitem que o tráfego, baseado em portas e/ou comportamento (no
caso de firewalls stateful). É uma representação clássica para esse modelo de proteção,
especialmente utilizada em artigos da área por sua praticidade didática.
Por ambiente poroso, pode-se entender como aquele no qual as fronteiras entre o
mundo interior e exterior das organizações são flexíveis, adaptáveis às necessidades ine-
rentemente mutáveis dos processos de negócio. À trajetória rumo a essa mudança de
contexto dá-se o nome de deperimetrização.
Companhias com negócios e interesses em comum buscam mecanismos para estabe-
lecimento de redes federadas e distribuídas, mas esbarram em barreiras como criação de
políticas comuns de acesso, tratamento de questões legais e regulatórias, gerenciamento
de riscos e resolução de disputas. Outro ponto nebuloso é a gerência de identidades, o qual
requer algum tratamento centralizado. Deperimetrização não equivale à descentralização.
Numa rede deperimetrizada, papéis como ações e políticas de acesso são distribuídos.
Descentralizar não significa que não haja um centro e sim saber o que está no centro e o
que está nos nós.
A busca pelo “ambiente poroso” pode encontrar nos WebServices uma alternativa no
tratamento das questões ora levantadas.
2.4.6 “Security in a world without borders”
“Encare, você já foi deperimetrizado. A questão agora é o que você vai fazer so-
bre isso.” Com essa epígrafe, o artigo [Cummings 2004] atenta para uma tomada de
consciência imediata sobre diversas questões atuais relacionadas à segurança de rede, es-
pecialmente em se tratando da proteção fornecida pelo perímetro.
As organizações já perceberam que à medida que se torna necessário permitir acesso
de rede a parceiros, clientes e fornecedores, também aumenta a abertura dentro de sis-
temas de proteção de borda, como firewalls e IDS. De fato, tais sistemas hoje possuem
tantos “buracos” que a efetiva proteção fornecida é mínima. Paul Simmonds, co-fundador
do Jericho Forum, afirma que as bordas de rede são tão ineficazes que devem ser conside-
radas mais como peneiras, afastando script kiddies e ataques básicos de Denial-of-Service
(DOS), deixando passar diversas ameaças que temos de encarar hoje em dia.
Uma prova cabal dessa afirmação está nos vírus e worms comuns da Internet (Blaster e
Sasser, a título de ilustração), que adentram nas redes corporativas através do acesso a sites
maliciosos. Técnicas diversas de engenharia social (phishing, por exemplo) permitem
que malware passem despercebidos pelas fronteiras da rede, causando grande impacto
internamente.
Diante desse quadro, muitos especialistas sugerem a necessidade de reforçar a segu-
rança das redes, uma vez que o perímetro agora é menos eficaz que outrora. Alguns,
16 CAPÍTULO 2. PERÍMETRO X SEGURANÇA
inclusive, defendem o combate à deperimetrização, especialmente através da defesa em
profundidade. Nessa linha de pensamento, incrementa-se a segurança através da aplica-
ção de refinadas camadas de proteção no interior da rede, trazendo o perímetro, assim,
mais próximo aos dados.
O Jericho Forum, no entanto, aponta justamente na direção oposta: não lutar contra a
deperimetrização e sim abraçá-la. Dado o despertar de consciência de que os perímetros
são obsoletos, pode-se economizar o tempo e os recursos gastos neles, e dar foco ao apri-
moramento da segurança interna. Organizações que tenham esse pensamento progressista
começarão a aproximar suas aplicações das pessoas que necessitam delas e que se encon-
tram do lado de fora do perímetro. Com isso ganha-se agilidade de mercado, celeridade
no desenvolvimento de novas soluções e menor necessidade de hardware. O perímetro
acabará em algum momento por se dissolver, reduzindo custos operacionais e tornando o
e-business muito mais eficiente.
O artigo informa que, de acordo com o Jericho Forum, todas as organizações deverão
passar por quatro fases para alcançar o ponto no qual poderão desenvolver seus processos
de negócio seguramente em um ambiente completamente deperimetrizado:
• Fase 1: Começar a sair do perímetro. O primeiro passo da deperimetrização é fa-
zer com que aplicações deixem a fronteira da rede corporativa, aproximando-se das
pessoas que as utilizarão. Assim, cria-se um canal de comunicação baseado na In-
ternet com consumidores, fornecedores e parceiros de negócio, sem a preocupação
de tratar da segurança das transações no perímetro da rede.
• Fase 2: Relaxar o perímetro. Nesta etapa, abandona-se a pretensão de reforçar
cada vez mais o perímetro, direcionando o foco das atenções na disponibilização
do transporte criptografado de dados e acesso autenticado aos dados internos da
organização.
• Fase 3: O perímetro deixa de existir. Neste ponto, a criptografia já terá chegado no
nível dos dados, bem como já estará em funcionamento um mecanismo de autenti-
cação no nível de conexão – elimina-se assim a necessidade do perímetro.
• Fase 4: Comunicação sem fronteiras. Os processos de negócio já operam em um
ambiente totalmente deperimetrizado. Os dados são dotados de propriedades de
segurança globais, tratadas diretamente nos endpoints. Mecanismos de gerencia-
mento de identidade, autenticação e autorização são distribuídos através de uma
rede de confiança federada.
Apesar do perceptível chamariz presente nessa proposta, o próprio Jericho Forum re-
conhece que a maioria das peças necessárias às quatro fases da deperimetrização ainda não
existe, em especial mecanismos de autenticação no nível de dados e gerenciamento fede-
rado de identidades, os quais ainda se encontram no universo conceitual. É nesse ponto
que o Jericho Forum apresenta sua maior contribuição: produzir respostas e estimular
fornecedores de tecnologia a produzir algo concreto e interoperável. Nesse meio-tempo,
as organizações são obrigadas a procurar soluções provisórias, que atacam apenas partes
do problema.
2.4. LITERATURA RELACIONADA 17
Nessa linha, temos como exemplo a adoção de firewalls e antivírus pessoais direta-
mente nas estações dos usuários. Outra solução, um software denominado Integrity, é
voltado ao problema do controle do endpoint, o qual foi discutido anteriormente. Nele,
quando o PC é conectado à rede, somente é liberado acesso ao servidor do Integrity, o
qual verifica se o equipamento está de acordo com as políticas de segurança da empresa,
incluindo antivírus e firewall atualizados. Caso falhe em qualquer dessas checagens, não
obtém acesso ao restante da rede.
Outra aposta vem de fabricantes de switches, como Cisco e Enterasys Networks. Em
geral, são soluções baseadas no protocolo 802.1X, provendo autenticação no nível de
enlace. Algumas mais sofisticadas, como a Secure Networking da Enterasys, incluem
IDS/IPS, podendo detectar e reagir diante de tráfego malicioso.
Na área de gerenciamento de identidade, a empresa Trusted Network Tecnologies
desenvolveu um software denominado Identity, o qual se integra diretamente aos serviços
do Microsoft Active Directory, trazendo autenticação, assinatura digital e gerenciamento
de direitos diretamente no nível dos pacotes TCP/IP.
Da mesma maneira, diversas outras companhias buscam soluções equivalentes. En-
quanto isso, as organizações se preparam com o que se dispõe hoje – basicamente solu-
ções para defesa em profundidade. Ao menos, a consciência da fragilidade da segurança
baseada em perímetro já foi despertada.
2.4.7 “The Deperimeter Problem”
Segundo o artigo [Garfinkel 2005], o tradicional modelo de segurança de redes é
extremamente semelhante ao da segurança física: coloque seus bens em um local seguro,
construa uma muro de proteção ao redor e utilize um portão para controlar quem entra
e sai. Este modelo de perímetro, “castelo e fosso”, é considerado por muitos obsoleto.
Alguns inclusive defendem a remoção completa do perímetro das redes de computadores.
No entanto, existe um longo caminho a ser percorrido até que sistemas como firewalls,
IDS e IPS possam ser de fato abolidos.
A defesa baseada em perímetro é, em essência, correta. Funcionou muito bem nas
cidades muradas da antiguidade, assim como também o foi nas redes de computadores
na década de 90. Faz muito mais sentido deter invasores e atacantes através de defe-
sas externas reforçadas do que deixá-los entrar e lutar diretamente com os civis – este é
um trabalho para os soldados, que ficam na linha de frente, no perímetro. Obviamente,
nenhuma defesa baseada em perímetro é perfeita. De fato, os troianos aprenderam essa li-
ção há mais de 3.000 anos, quando permitiram a entrada de um imenso cavalo de madeira
recheado de soldados gregos – uma vez dentro, as paredes se tornam irrelevantes.
Há anos, especialistas de segurança alertam sobre os perigos de subestimar as ameaças
internas. Concentrar os esforços de defesa no perímetro invariavelmente leva a organiza-
ção a relaxar a defesa interna, devido a uma falsa sensação de segurança. Para ilustrar, há
empresas que investem tanto na segurança do perímetro que hesitam em despender recur-
sos com atualizações e patchs de computadores internos. Deve-se lembrar que existem
inúmeras ameaças externas que possuem meios furtivos de driblar o melhor dos períme-
tros, como vírus e worms.
18 CAPÍTULO 2. PERÍMETRO X SEGURANÇA
Além disso, existem comportamentos de risco que põe abaixo o conceito de fronteira
da rede: um funcionário pode simplesmente conectar um notebook ou smartphone con-
taminado à rede corporativa; um ponto de acesso sem-fio não autorizado pode ser, com
propósitos escusos ou simplesmente por desconhecimento dos riscos, conectado à rede
local, permitindo acesso externo via Wi-Fi a wardrivers. A ubiqüidade também é uma
ameaça: o que impede a um funcionário conectar na porta USB um modem 3G que aca-
bou de comprar, para acessar em seu computador conteúdo bloqueado pela política de
segurança da instituição?
Mesmo que o perímetro fosse perfeito, ele assume que todos os bens estão sob sua
circunvizinhança, considerando o modelo de Anéis de Confiança, conforme mostrado
na figura 2.3. No entanto, com a utilização de notebooks, smartphones e pen-drives,
informação valiosa entre e sai da organização de forma totalmente desprotegida a todo
tempo, burlando tanto o perímetro físico como o eletrônico. Confiar no perímetro, nesse
caso, seria o equivalente a utilizar um alarme na residência para proteger as crianças de
rapto, deixando-as, no entanto, irem à escola sozinhas.
Seguindo outra direção, o Jericho Forum orienta as organizações a adotar a idéia da
deperimetrização: encarar que o perímetro está “morto” e desenvolver um novo para-
digma de segurança baseado em autenticação mútua e criptografia forte. Tal modelo
dever ser cuidadosamente projetado através de um modelo aberto e de modo a garantir
interoperabilidade.
A questão da deperimetrização torna-se mais contundente em grandes companhias
e organizações (um campus universitário, por exemplo). Quando se leva em conta um
quadro funcional de milhares de empregados e um parque de milhares de computadores,
uma defesa orientada a proteger esse perímetro não faz tanto sentido.
Esses ambientes, apesar de encerrarem uma rede interna, são inerentemente hostis –
ataques internos são freqüentes. Podem ser criados perímetros internos adicionais, usando
firewalls para proteger setores estratégicos, por exemplo. O problema, nesse caso, é de-
finir a granularidade de proteção necessária. De acordo com o Jericho Forum, podem
ser usados perímetros tão pequenos quanto possível – um firewall por computador, por
exemplo.
Os maiores “buracos” em firewalls corporativos são advindos de decisões de negócio.
Quando duas empresas formam algum tipo de parceria, uma das primeiras atitudes é abrir
as respectivas bordas, de modo que os sistemas corporativos de ambas possam interagir. O
problema é que, mesmo depois de encerrada a parceria, tais buracos continuam a existir,
especialmente por receio da equipe de segurança de TI em desativar algo importante.
A situação se agrava após mudanças de pessoal no departamento de segurança. Com o
tempo, nenhum funcionário saberá que existe essa “sutura” pendente.
Apesar de levar as instituições a uma falsa sensação de segurança, o perímetro tende
a trazer mais vantagens que prejuízos. O que as organizações realmente necessitam são
mecanismos de avaliação da eficácia de seus perímetros (sejam internos ou externos),
servindo assim de apoio à decisão de onde são necessários maiores investimentos de pro-
teção. A defesa em profundidade surge assim como alternativa promissora.
Justamente nesse ponto é que surge um problema fundamental na deperimetrização
visionada pelo Jericho Forum: ela simplesmente ignora a doutrina de defesa em pro-
2.4. LITERATURA RELACIONADA 19
fundidade. No lugar, prega a filosofia que os endpoints devem ser capazes de se auto-
protegerem. Mesmo sob esse ponto de vista, existem vantagens em se adicionar uma
camada extra de defesa através de um firewall. Quando uma nova falha de segurança é
descoberta, é muito mais rápido bloquear o ataque com uma nova regra de firewall do que
programar cada host para se atualizar.
Outro problema é que a visão do Jericho Forum propõe uma mudança radical de para-
digma, através de uma arquitetura de segurança totalmente nova (ao invés de modificações
incrementais num modelo pré-existente). A Internet foi um sucesso justamente devido ao
seu modelo de aperfeiçoamento incremental.
Em tempo, qual gestor de segurança da informação seria capaz de desativar um fi-
rewall em produção? E caso surgisse um ataque que pudesse ser evitado diretamente
no perímetro? Abraçar a deperimetrização tal qual idealizada pelo Jericho Forum passa
necessariamente por reflexões como estas.
2.4.8 “Informação Segura / Deperimetrização”
O artigo [InfoSegura 2008] mostra principalmente os riscos oriundos da própria rede
interna das organizações. Com a chegada da tecnologia 3G, nada impede que um funci-
onário, bem ou mal intencionado, conecte um modem a seu computador para acessar e
compartilhar conexão à Internet, conseguindo acesso a serviços e sítios bloqueados pela
política de segurança da empresa.
Poderia ser sugerido algum tipo de inspeção na entrada e saída de funcionários im-
pedindo a entrada de qualquer dispositivo que comprometesse a segurança do perímetro.
Mas essa atitude com certeza geraria uma onda de protestos, além de processos por vio-
lação da liberdade individual e privacidade.
Eis então que surge a proposta da deperimetrização. Ao invés de se preocupar com
a rede, o foco da proteção passa a ser nos dados. A segurança então, segundo o artigo,
seria feita apenas no host servidor (nesse ponto o artigo diverge do conceito principal
de deperimetrização encontrado no demais artigos). Com isso, não importa se os dados
vão chegar ao usuário via rede interna, ADSL ou mesmo um modem 3G. Acaba-se assim
com a necessidade de uma intranet corporativa, levando a uma diminuição do parque
computacional das empresas e conseqüente redução de custos. Uma estrutura menos
complexa acaba também por diminuir o consumo de energia elétrica, contribuindo para
uma nova tendência – a TI verde.
Segundo o artigo, já é possível implementar esse novo conceito, conforme mostrado
na figura 2.4, através de ferramentas desenvolvidas pela Microsoft: Active Directory, Sys-
tem Center Configuration Manager e Network Access Protection, disponíveis a partir do
Windows Vista. Com a velocidade dos links domésticos aumentando a cada dia, a neces-
sidade de uma rede local acaba diminuindo, permitindo assim que funcionários possam
trabalhar de qualquer lugar, especialmente em casa – o que se convencionou chamar home
office ou teletrabalho.
20 CAPÍTULO 2. PERÍMETRO X SEGURANÇA
Figura 2.4: Externalização do acesso à rede corporativa.
2.4.9 “Deperimetrização e Externalização”
O artigo [Cima 2007] relata as soluções da Microsoft destinadas à deperimetrização.
Inicia informando que é freqüente a discussão entre especialistas sobre a validade do
atual modelo de segurança, especialmente em eventos de segurança. Alguns inclusive
reiteram: “O firewall está morto”. As causas são diversas: notebooks que, contaminados
externamente, são conectados à rede corporativa, acesso remoto de parceiros, entre outras.
O que a maioria das análises sobre o tema não leva em consideração e que realmente
representará o fim do perímetro é o simples fato de que a rede interna das organizações,
tal como é conhecida hoje, irá desaparecer num futuro próximo. A computação ubíqua,
com acesso à grande rede em todo lugar, acabará por fazer dispensar a necessidade de
manter uma infraestrutura de rede própria, protegida por um perímetro. Essa mudança de
estratégia virá acompanhada da necessidade de não mais focar a segurança na rede e sim
no host. Essa é a proposta do Jericho Forum. Mais que isso, ele desafia o mercado de TI
a buscar e criar soluções para ambientes deperimetrizados.
Alguns membros do fórum decidiram partir para a ação. É o caso da BP – British Pe-
troleum, que iniciou um programa onde 18 mil de seus funcionários recebem uma verba
anual para comprar e manter um notebook particular, o qual se conecta diretamente à In-
ternet, mesmo dentro dos escritórios da BP. Num futuro próximo, o que se verá será a
externalização da rede corporativa das organizações: os usuários acessando os sistemas
diretamente através da conexão doméstica; pequenas filiais ou escritórios usando algum
tipo de conexão banda larga ou acesso sem-fio, e para empresas maiores, servidores man-
tidos em datacenters próprios ou utilizando serviços de hosting de terceiros (computação
em nuvem).
A partir do desafio do Jericho Forum, a Microsoft adotou um posicionamento de de-
senvolver produtos que permitam às organizações aproveitarem a ubiqüidade e transfor-
mar a visão de um paradigma sem perímetros numa realidade. Dentro dessa esfera, produ-
tos como Windows Firewall, Read-Only Domain Controller, Terminal Services Gateway,
2.4. LITERATURA RELACIONADA 21
dentre diversos outros permitem aplicação de conceitos de gerenciamento de identidade,
autenticação e autorização. Outros serviços como distribuição de software e gerência de
conformidade de políticas de segurança de hosts também estão disponíveis.
O artigo finaliza dizendo que não se trata de resistir à deperimetrização e sim se pre-
parar para um futuro no qual ela, inevitavelmente, fará parte da realidade.
2.4.10 “Deperimetrização e Externalização, será?”
Segundo [Elias 2007], ao mesmo tempo em que a deperimetrização/externalização
resolverá diversos problemas que temos hoje decorrentes da obsolescência do firewall,
outros serão advindos. Sobre isso, faz referência a uma analogia feita por Bruce Schneier:
“Considere dois problemas de segurança diferentes. No primeiro deles,
você guarda seus pertences num cofre no seu porão. As ameaças são os la-
drões, claro. Mas o cofre é seu e a casa é sua, provavelmente. Você controla
o acesso ao cofre e provavelmente tem um sistema de alarme.
O segundo problema é parecido, mas você guarda os seus pertences no
cofre de outra pessoa. Pior ainda, no cofre de quem você não confia. Ele não
sabe a senha, mas controla quem acessa o cofre. Ele pode tentar quebrá-la no
seu tempo livre. Ele também pode transportar o cofre para onde ele quiser.
Ele pode usar qualquer ferramenta que precisar.
No primeiro exemplo, o cofre precisa ser protegido, mas ainda é somente
parte da segurança da casa. No segundo caso, o cofre é o único dispositivo
que você tem. Este segundo problema de segurança parece ser teórico, mas
ele acontece com freqüência na nossa sociedade da informação: dados con-
trolados por uma pessoa são armazenados em dispositivos controlados por
outra pessoa.”
Nota-se então que os custos decorridos da deperimetrização podem ser iguais ou mai-
ores que os atuais. O que então fará a diferença será a eficácia no controle da segurança.
2.4.11 Deperimetrização e computação em nuvem
Em empresas de médio e grande porte é nítida a tendência à terceirização (outsour-
cing) de recursos e sistemas de TIC. O que antes era mantido dentro do datacenter da
instituição, hoje está em transição para a nuvem, em modelos de software-como-serviço
(SaaS), infraestrutura-como-serviço (IaaS) e plataforma-como-serviço (PaaS).
Empresas como Amazon, Ubuntu, UOL, dentre diversas outras, fornecem serviços de
hospedagem de servidores virtualizados na nuvem. Em tempos de TI verde e outsourcing,
a computação em nuvem se mostra como uma boa solução para redução do Total Cost of
Ownership (TCO). É com esse objetivo que cerca de 49% das empresas no Brasil usam
ou estudam adotar serviços de computação em nuvem [Callegari 2011].
A analogia do cofre de Bruce Schneier é bem adequada à análise de segurança dos
sistemas de computação em nuvem disponíveis na atualidade. De fato, ao migrarmos o
22 CAPÍTULO 2. PERÍMETRO X SEGURANÇA
datacenter para a nuvem, os dados sob controle do seu proprietário passam a ser armaze-
nados em dispositivos controlados por outras pessoas.
Nos ambientes de nuvem terceirizados, não há como se adotar o conceito dualista
de classificação das redes de computadores: toda a infraestrutura já está na rede “má” -
Internet. Logo, o conceito de segurança baseada em perímetro pouco ou nenhum sentido
faz. Nestes, não há como se pensar em segurança da informação sem trazê-la o mais
próximo possível dos dados.
2.4.12 Conclusões sobre os trabalhos analisados
Em linhas gerais, os artigos analisados demonstram a inaptidão da segurança baseada
em perímetro nas redes de computadores da atualidade, especialmente considerando as
mudanças no comportamento dos usuários, as novas estratégias de negócio de empresas
e instituições e os riscos trazidos pelas novas tecnologias de comunicação.
Verifica-se que, se por um lado existe um consenso sobre a ineficácia na atualidade
do perímetro de rede enquanto medida de segurança, por outro lado os artigos analisados
divergem:
• Sobre a permanência do perímetro: se ele deve ser eliminado ou adentrar na rede
(defesa em profundidade);
• Sobre a metodologia de eliminação do perímetro: imediata ou gradativa.
Tendo em vista o ambiente corporativo, tradicionalmente resistente a mudanças de
paradigma, faz mais sentido adotar uma estratégia de eliminação progressiva do perímetro
ao mesmo tempo em que se aplica gradualmente a defesa em profundidade.
Conforme visto em 2.4.6, o Jericho Forum [JerichoForum 2009] - referência no as-
sunto - preconiza que a eliminação do perímetro em qualquer organização é gradual,
seguindo um sequenciamento em fases. Salienta, no entanto, que a maioria das peças
necessárias às quatro fases da deperimetrização ainda não existe.
As fases “1” (começar a sair do perímetro) e “2” (relaxar o perímetro) poderiam ser
aplicadas de imediato, desde que os sistemas fossem dotados de uma ferramenta de va-
lidação de identidade eficaz. Este é um dos itens presentes na fase “4” (comunicação
sem fronteiras), o qual prevê a necessidade de mecanismos de identidade, autenticação
e autorização federados. É mais adequado, portanto, alterar a distribuição de requisitos,
realocando estes mecanismos para a fase 2. A partir de então a fase “3” (o perímetro deixa
de existir) poderia ter início.
Conclui-se, portanto, que o caminho para a deperimetrização passa, necessariamente,
pela adoção de um mecanismo seguro e eficaz de identificação federada. O estabeleci-
mento de uma proposta para este último, bem como seu desenvolvimento, são os princi-
pais elementos abordados neste trabalho.
2.5 Identificação federada
Segundo [Wangham et al. 2010], a identificação federada consiste na distribuição da
tarefa de autenticação dos usuários por múltiplos provedores de identidades, estando es-
2.5. IDENTIFICAÇÃO FEDERADA 23
tes dispostos em diferentes domínios administrativos. Um domínio administrativo pode
representar uma empresa, uma universidade, entre outros, e é composto por usuários, di-
versos provedores de serviços e um único provedor de identidades. Acordos estabelecidos
entre provedores de identidades garantem que identidades emitidas em um domínio sejam
reconhecidas por provedores de serviços de outros domínios e o conceito de autenticação
única é garantido mesmo diante de diferentes domínios.
Dessa forma, o modelo de identidades federadas consegue oferecer facilidades para os
usuários, pois evita que estes tenham que lidar com diversas identidades e passar diversas
vezes pelo processo de autenticação.
2.5.1 SAML
O Security Assertion Markup Language (SAML) [Ragouzis et al. 2008] é um arca-
bouço designado para prover mecanismos de autenticação e autorização através de men-
sagens XML. Ele define um formato de dados aberto, voltado à criação e troca on-line de
informações de segurança entre entidades. É também uma das especificações recomenda-
dos no e-PING [Correia et al. 2011], o padrão oficial brasileiro para governo eletrônico.
Na abordagem tradicional de desenvolvimento de sistemas, o mecanismo de auten-
ticação é parte integrante da aplicação, cabendo ao desenvolvedor elaborar a estratégia
de checagem das credenciais do usuário, geralmente através de consulta em uma base
de dados ou validação em algum mecanismo de diretório, como LDAP [Zeilenga 2006].
No SAML, diferentemente, há a separação entre o processo de autenticação e o acesso
ao serviço, de modo que a aplicação não incorpora em si o mecanismo de autenticação,
delegando esta tarefa a um agente externo. Este, por sua vez, deve ser capaz de realizar o
processo de autenticação e prover informações sobre o usuário (assertivas).
Verifica-se, assim, que o SAML define três participantes envolvidos no processo de
autenticação/autorização:
• Sujeito: a entidade a ser autenticada, podendo ser uma pessoa, um computador,
uma organização, entre outros. Também conhecido como “Principal” ou “Utiliza-
dor”;
• IdP: o “Provedor de Identidade” (Identity Provider), o qual realiza a autenticação
e geração de assertivas a respeito do “principal”. Também conhecido como “ente
declarativo”.
• SP: o “Provedor de Serviço” (Service Provider). É o sistema ao qual o “principal”
deseja acessar. No contexto SAML ele atua como o “ente confiante”, consumindo
assertivas geradas pelo IdP. Um SP pode estabelecer relações de confiança com
diversos e independentes IdPs, criando assim uma rede de identidade federada em
torno daquele serviço.
A utilização do SAML permite a criação do Single-Sign-On (SSO), ou seja, a au-
tenticação do usuário é realizada apenas uma vez num determinado período de tempo,
tornando-se válida para acesso a múltiplos serviços e sistemas, através do intercâmbio
24 CAPÍTULO 2. PERÍMETRO X SEGURANÇA
de informações de credenciais de acesso. Sob este aspecto, pode-se visualizar o SAML
como um WebService voltado ao provimento de identificação federada.
O processo de SSO do SAML é detalhado na subseção 3.3.1.
2.5.2 Soluções de identificação federada existentes
Tendo em vista que o foco da dissertação é o estabelecimento de um mecanismo se-
guro e eficaz de identidade federada, foi realizada uma pesquisa bibliográfica adicional a
respeito das principais ferramentas existentes no mercado voltadas a esse propósito.
Shibboleth
Segundo [Wangham et al. 2010], o projeto Shibboleth foi iniciado em 2000 pelo con-
sórcio Internet2 e resultou na criação de uma arquitetura e implementação, em código
aberto, de um Sistema de Gerenciamento de Identidade (SGI) voltado à identificação e
autorização federados.
O projeto Shibboleth é um dos principais SGI destinados à criação de federações,
sendo voltado especialmente ao âmbito acadêmico, com destaque para sua utilização
na Comunidade Acadêmica Federada (CAFe/RNP) e na federação InCommon, norte-
americana, mantida pelo consórcio Internet2. Nos últimos anos, passou a ser amplamente
adotado também no ambiente corporativo.
Figura 2.5: Diagrama de mensagens do Shibboleth
[Seabra 2009].
A característica principal do Shibboleth é a utilização do SAML, implementando no-
tadamente o perfil Web Single-Sign-On deste protocolo. De acordo com [Seabra 2009], o
funcionamento do Shibboleth segue o diagrama de sequência mostrado na figura 2.5:
2.5. IDENTIFICAÇÃO FEDERADA 25
1. O Utilizador tenta acessar o recurso disponibilizado pelo Provedor de Serviço.
2. Uma vez que o Utilizador não se encontra autenticado, o Provedor de Serviço o re-
direciona para o WAYF Server (Where Are You From Server), que tem como função
apresentar uma lista de Provedores de Identidades suportados por aquele Provedor
de Serviços.
3. O Utilizador, no WAYF Server, escolhe o seu Provedor de Identidade, a partir da
lista disponibilizada por esse servidor.
4. O Utilizador é redirecionado para o seu Provedor de Identidade.
5. No Provedor de Identidade, é pedido ao Utilizador que se autentique.
6. O Utilizador autentica-se, é criado um identificador para ele e é redirecionado para
o Provedor de Serviço que aloja o recurso que o Utilizador pretende acessar. O
navegador do utilizador recebe um cookie para permitir o Single-Sign-On.
7. O Provedor de Serviço recebe o identificador.
8. O Provedor de Serviço vai usar o identificador para pedir diretamente ao Provedor
de Identidade os atributos que necessita para poder tomar uma decisão de autoriza-
ção.
9. O Provedor de Serviço recebe os atributos e toma então a decisão de permitir ou
negar o acesso a esse o recurso ao Utilizador.
Kantara Initiative
Surgiu com o nome de Projeto Liberty Alliance (consórcio de mais de 160 organiza-
ções privadas e governamentais). É composto por três componentes principais: Identity
Federation Framework (ID-FF), Identity Web Services Framework (ID-WSF) e Identity
Services Interface Specifications (ID-SIS). O funcionamento dos componentes é seme-
lhante ao Shibboleth, provendo as mesmas funcionalidades.
Segundo [Wangham et al. 2010], um dos principais pontos positivos do projeto é sua
influência em padrões como o SAML, cujas extensões propostas pela Liberty Alliance
são hoje parte da versão 2.0 do SAML.
OpenID
De acordo com [Wangham et al. 2010], o OpenID surgiu em maio de 2005 como
um projeto pessoal do desenvolvedor Brad Fitzpatrick, voltado à eliminar o problema de
spams em seu blog, o LiveJournal. Implementa sob o mesmo nome um protocolo e um
serviço.
O usuário tem a liberdade de efetuar seu cadastro em qualquer servidor OpenID. Ao
acessar algum serviço, o usuário é redirecionado ao servidor OpenID. Após efetuar logon
com suas credenciais, o usuário é redirecionado de volta à página do serviço. Toda a
26 CAPÍTULO 2. PERÍMETRO X SEGURANÇA
comunicação entre o servidor OpenID e o serviço é criptografada com chave assimétrica
e realizada de forma indireta, através da URL do navegador do usuário.
O funcionamento do OpenID é explicitado na figura 2.6 (adaptado de [Seabra 2009]):
1. O Utilizador inicia a autenticação no Web Site (relying party) enviando o seu Uni-
form Resource Identifier (URI), usando para isso o seu User-Agent (informado pelo
navegador);
2. O site normaliza o URI (caso seja necessário) e processa o HTML do OpenID do
Utilizador. Em seguida, estabelece um segredo compartilhado com o Provedor;
3. O navegador do Utilizador é redirecionado para o Provedor, onde o Utilizador pode
efetuar a autenticação;
4. O Provedor redireciona o browser do Utilizador para o site, enviando uma resposta;
5. O site verifica a assinatura da resposta e dá acesso ao Utilizador.
Figura 2.6: Diagrama de funcionamento do OpenID
[Seabra 2009].
O OpenID já é utilizado em vários sítios da Internet, destacando-se Google, Yahoo,
4Shared, entre outros.
OpenAM
O projeto OpenAM, de código aberto, foi inicialmente desenvolvido pela Sun Mi-
crosystems sob o nome de OpenSSO. Após a aquisição desta pela Oracle Corporation,
o projeto foi descontinuado e um fork, sob o nome de OpenAM, passou a ser mantido
pela empresa ForgeRock [ForgeRock 2012], como uma plataforma de gerenciamento de
acesso e federação.
2.5. IDENTIFICAÇÃO FEDERADA 27
Totalmente desenvolvido em Java, possui grande aceitação no mercado corporativo.
Possui uma grande quantidade de plugins, permitindo compatibilidade com diversos pro-
tocolos de autenticação (como LDAP e Microsoft Active Directory) e federação (SAML
e OpenID).
Conclusões sobre os soluções de identidade federada
Todos os mecanismos analisados possuem funcionamento semelhante, empregando as
figuras do Provedor de Identidade (IdP) e do Provedor de Serviço (SP). Os mais utilizados
atualmente são o Shibboleth (baseado em SAML) e o OpenID.
Pela análise realizada, percebe-se que nenhuma das soluções implementa diretamente
um mecanismo de autenticação forte (dois ou três fatores de autenticação), utilizando
geralmente o mecanismo tradicional de par de credenciais (usuário e senha), provendo
autenticação de um fator (“algo que você saiba”).
Conquanto estes mecanismos implementem de forma eficaz a identificação federada,
não atendem aos requisitos de segurança necessários à implementação das fases da depe-
rimetrização, conforme analisado nas subseções 2.4.6 e 2.4.12. Para este objetivo se faz
necessário o uso da identidade federada através de um mecanismo de autenticação forte,
o qual é tratado no próximo capítulo.

Capítulo 3
Modelagem do Autenticador
ICP/SAML
Este capítulo aborda as fases de definição da proposta, levantamento de requisitos e
modelagem de software de um mecanismo para autenticação federada através de certifica-
dos digitais ICP-Brasil. Para esta etapa do projeto optou-se pela utilização da UML [OMG
2011], que é a linguagem de modelagem de software padrão de facto do mercado.
3.1 Definição da proposta de mecanismo de identificação
federada
Para definição da proposta, é necessário sobretudo definir o mecanismo de autenti-
cação e o protocolo de identidade federada utilizado. Numa comparação entre diversos
mecanismos de autenticação para sistemas de internet banking [Guimarães 2006], os cer-
tificados digitais embarcados em smart-cards tiveram a mais alta avaliação no quesito
’segurança’ (juntamente com chips SIM, usados em celulares GSM).
No contexto nacional, a Infraestrutura de Chaves Públicas Brasileira (ICP-Brasil)[ITI
2012] é a cadeia hierárquica e de confiança que viabiliza a emissão de certificados digitais
para identificação virtual do cidadão brasileiro. Por força da Medida Provisória n.o 2.200-
2/2001 (que instituiu a ICP-Brasil), documentos assinados digitalmente com certificados
ICP-Brasil tem validade jurídica.
Sendo assim, a utilização de um mecanismo de autenticação baseado em certificados
digitais A3 (certificados ICP-Brasil com par de chaves gerado e armazenado em mídia
criptográfica, i.e., smart-cards ou tokens USB) provê segurança técnica e jurídica. Pelos
motivos citados, este é o sistema de validação de credenciais escolhido para o presente
trabalho, sendo o principal diferencial em relação às soluções de identificação federadas
existentes.
Salienta-se que essa escolha vislumbra também uma tendência dentro do Governo Fe-
deral da adoção massiva dos certificados digitais fornecidos pela Autoridade Certificadora
Brasileira como mecanismo oficial de fé pública em documentos. Prova disso é a substi-
tuição da atual carteira de identidade pelo Registro de Identidade Civil - RIC (figura 3.1),
definido por um smartcard contendo um certificado digital emitido pelo ICP-Brasil em
nome do titular.
30 CAPÍTULO 3. MODELAGEM DO AUTENTICADOR ICP/SAML
Figura 3.1: O novo Registro de Identidade Civil.
Nos próximos anos, todo cidadão portará um RIC em substituição ao atual RG. A
ferramenta proposta neste trabalho permitirá, assim, a identificação federada segura, efi-
caz e juridicamente válida do usuário na Internet, através de um objeto portado por este
naturalmente (autenticação por “algo que você possua”).
Com relação ao protocolo de identidade federada, a escolha recai sobre o SAML, por
ser um protocolo aberto e de grande utilização no meio acadêmico e corporativo. Além
disso, é o protocolo de federação oficialmente adotado pelo Governo Federal nos Padrões
de Interoperabilidade de Governo Eletrônico - e-PING [Correia et al. 2011].
Define-se, portanto, a proposta deste trabalho: o desenvolvimento de um mecanismo
de identificação federada baseado em certificados digitais padrão A3/ICP-Brasil armaze-
nados em smart-cards, e no protocolo SAML.
3.2 Identificação e modelagem dos casos de uso
Na UML, os “casos de uso” permitem capturar os requisitos funcionais do sistema, a
partir de elementos visuais (diagramas) e textuais (narrativa dos diagramas). Eles propor-
cionam uma visão final do sistema - como ele deverá se comportar quando concluído.
A análise de requisitos serve para definir as capacidades e condições que um sistema
deve possuir para que sua finalidade seja alcançada. Para o presente trabalho, este le-
vantamento permite definir as funcionalidades necessárias para que a peça de software
em questão (autenticador ICP-Brasil/SAML) atinja os pré-requisitos de deperimetrização
estabelecidos na seção 2.4.12.
Basicamente, a definição dos requisitos deve levar em consideração a interação entre
as entidades fundamentais num modelo de identidade federada: “Usuário” (geralmente
em conjunto com um navegador Web), “IdP (Autenticador)” e “SP” (Aplicação). A figura
3.2 mostra a relação entre estas entidades no processo de autenticação.
3.2. IDENTIFICAÇÃO E MODELAGEM DOS CASOS DE USO 31
Figura 3.2: Interação entre “Aplicação” e “Autenticador”.
3.2.1 Autenticador
Especificar e modelar um autenticador ICP-Brasil/SAML é o objetivo principal deste
capítulo. É fundamental, portanto, que seja realizada uma definição concisa do produto
a ser entregue: um mecanismo de autenticação de identidade federada, capaz de atuar
como provedor de identificação (IdP) a aplicações e serviços compatíveis com o protocolo
SAML (SP), validando o utilizador através da comprovação de sua posse da chave privada
do certificado A3/ICP-Brasil apresentado por esse ao sistema.
Com base na definição apresentada, pode-se agora determinar os casos de uso do
sistema autenticador, de acordo com o mostrado na figura 3.3a.
3.2.2 Aplicação
Apesar de não ser o objetivo do presente trabalho, faz-se necessária a modelagem
das funcionalidades de autenticação e acesso federado de um serviço/aplicação, especial-
mente para validar a proposta do autenticador apresentada.
Não se trata, contudo, de especificar e modelar os recursos providos por serviços ou
aplicações, tendo em vista que estes podem ser os mais diversos possíveis. O que se
busca é estabelecer um conjunto mínimo de requisitos suficientes para permitir a criação
ou integração de aplicações com os mecanismos SAML de autenticação federada.
Tendo esse foco em mente, é estabelecido o conjunto de casos de uso voltados ao de-
senvolvimento ou adaptação de aplicações e serviços ao contexto de identidade federada
e deperimetrizada, conforme mostrado na figura 3.3b.
32 CAPÍTULO 3. MODELAGEM DO AUTENTICADOR ICP/SAML
(a)Provedorde
Identidade
(IdP).
(b)A
plicação
(SP).
Figura
3.3:D
iagram
as
de
casos
de
uso.
3.2. IDENTIFICAÇÃO E MODELAGEM DOS CASOS DE USO 33
Tabela 3.1: Caso de Uso: Gerar Assertiva SAML.
Caso de Uso: Gerar Assertiva SAML
Atores: Navegador
Descrição: Entrega ao navegador a assertiva SAML após o logon.
Pré-Condições: As mesmas do caso de uso extendido (Autenticar Usuário).
Fluxo de Evento
Primário:
As mesmas do caso de uso extendido (Autenticar Usuário).
Fluxo de Evento
Secundário:
Caso o usuário já tenha efetuado logon com sucesso há me-
nos de 6h, o sistema dispensará o processo de logon e en-
tregará a assertiva SAML armazenada em cache.
Pós-Condições
Redirecionamento do navegador ao provedor de serviço so-
licitante, carregando a assertiva SAML.
Pontos de Extensão
Casos de Uso
Incluídos:
Tabela 3.2: Caso de Uso: Autenticar Usuário.
Caso de Uso: Autenticar Usuário
Atores: Navegador
Descrição: Realizar a autenticação do usuário
Pré-Condições:
A solicitação de autenticação deve surgir a partir de um “re-
direct” de uma aplicação (SP) compatível com SAML.
Fluxo de Evento
Primário:
• Uma tela de apresentação do sistema é exibida.
• Caso de uso Solicitar Certificado Digital e PIN.
• O navegador é notificado sobre o status da autenticação.
Fluxo de Evento
Secundário:
Pós-Condições Resultado da autenticação.
Pontos de Extensão Gerar Assertiva SAML.
Casos de Uso
Incluídos:
Solicitar Certificado Digital e PIN
34 CAPÍTULO 3. MODELAGEM DO AUTENTICADOR ICP/SAML
Tabela 3.3: Caso de Uso: Solicitar Certificado Digital e PIN.
Caso de Uso: Solicitar Certificado Digital e PIN
Atores: Usuário e Navegador
Descrição:
Realiza as tarefas de ICP, solicitando e validando o certifi-
cado do usuário e realizando a verificação da posse da chave
privada do certificado.
Pré-Condições: Chamada a partir do caso de uso ’Autenticar Usuário’.
Fluxo de Evento
Primário:
• O sistema solicita ao usuário a inserção do cartão inteli-
gente.
• Após a inserção, é apresentada uma caixa de seleção onde
são listados os certificados presentes na mídia.
• O sistema realiza a validação do certificado selecionado.
• O sistema gera um desafio com base na chave pública do
certificado.
• O navegador solicita ao usuário que digite o PIN do cer-
tificado para liberar o funcionamento da chave privada
• O navegador solicita à API do cartão inteligente que re-
solva o desafio.
• O navegador retorna ao caso de uso Autenticar Usuário.
Fluxo de Evento
Secundário:
Cartão sem certificados válidos:
• Solicita ao usuário que insira um cartão com certificados
válidos.
PIN incorreto:
• Informa ao usuário que o PIN digitado está incorreto.
• Solicita ao usuário que digite novamente o PIN do certi-
ficado selecionado.
Pós-Condições
Retorna ao caso de uso Autenticar Usuário, com o certifi-
cado digital e o PIN do usuário
Pontos de Extensão
Casos de Uso
Incluídos:
3.2. IDENTIFICAÇÃO E MODELAGEM DOS CASOS DE USO 35
Tabela 3.4: Caso de Uso: Acessar Aplicação.
Caso de Uso: Acessar Aplicação
Atores: Usuário
Descrição: Permite ao usuário acessar a aplicação
Pré-Condições:
Fluxo de Evento
Primário:
• A aplicação valida o Token SSO.
• O acesso à aplicação é concedido.
Fluxo de Evento
Secundário:
Caso o usuário não possua um Token SSO válido, o caso de
uso Solicitar Assertiva SAML entra em ação.
Pós-Condições
Acesso à aplicação ou acionamento do caso de uso Solicitar
Assertiva SAML
Pontos de Extensão Solicitar Assertiva SAML
Casos de Uso
Incluídos:
Tabela 3.5: Caso de Uso: Solicitar Assertiva SAML.
Caso de Uso: Solicitar Assertiva SAML
Atores: Navegador
Descrição:
Carrega o navegador com os parâmetros do SP e redireciona
para o IdP.
Pré-Condições: Tentativa de acesso à aplicação sem o Token SSO
Fluxo de Evento
Primário:
Aplicação carrega o navegador com os parâmetros SAML e
o redireciona para o IdP.
Fluxo de Evento
Secundário:
Pós-Condições Redirecionamento do navegador para o IdP
Pontos de Extensão
Casos de Uso
Incluídos:
36 CAPÍTULO 3. MODELAGEM DO AUTENTICADOR ICP/SAML
Tabela 3.6: Caso de Uso: Consumir Assertiva SAML.
Caso de Uso: Consumir Assertiva SAML
Atores: Navegador
Descrição: Processa a assertiva SAML carregada pelo navegador.
Pré-Condições: Navegador com carga de assertiva SAML recebida pelo IdP.
Fluxo de Evento
Primário:
• O sistema recebe a assertiva SAML e efetua a validação.
• O sistema retorna a confirmação de assertiva consumida.
Fluxo de Evento
Secundário:
Pós-Condições Assertiva consumida
Pontos de Extensão
Casos de Uso
Incluídos:
Tabela 3.7: Caso de Uso: Gerar Token SSO.
Caso de Uso: Gerar Token SSO
Atores: Navegador
Descrição: Entrega ao navegador o Token SSO para acesso à aplicação.
Pré-Condições: Navegador retorna do IdP com assertiva SAML.
Fluxo de Evento
Primário:
• Navegador entrega ao sistema a assertiva SAML.
• Sistema inicia o caso de uso Consumir Assertiva SAML
para efetuar a validação.
• Sistema entrega ao navegador o Token SSO.
Fluxo de Evento
Secundário:
Pós-Condições Navegador com Token SSO para acesso à aplicação
Pontos de Extensão
Casos de Uso
Incluídos:
Consumir Assertiva SAML
3.3. DIAGRAMAS DE SEQUÊNCIA. 37
3.3 Diagramas de sequência.
Os “diagramas de sequência” da UML permitem modelar o comportamento dinâmico
dos processos definidos nos casos de uso. Eles também possibilitam determinar a or-
dem dos eventos para utilização de determinada funcionalidade da aplicação, os métodos
envolvidos e as trocas de mensagens realizadas entre objetos.
Analisando os comportamentos esperados do sistema de autenticação federado SAML
/ ICP-Brasil e uma típica aplicação compatível com SAML, pode-se definir os diagramas
de sequência de dois processos básicos do sistema: o Single-Sign-On SAML e o Logon a
partir de cartão inteligente, os quais são detalhados a seguir.
3.3.1 O processo de Single-Sign-On SAML
Este é o principal processo da solução de autenticação proposta e fornece uma visão
macro da execução de uma sessão de autenticação federada. Nele estão envolvidos os dois
atores relacionados nos casos de uso, “usuário” e “navegador”, e os sistemas modelados,
“Aplicação (SP)” e “Autenticador (IdP)”.
Apesar dos atores apresentados atuarem de forma distinta, eles foram agrupados para
facilitar o entendimento da sequência de eventos registrada. Note que não há prejuízo
algum do ponto de vista dos sistemas, pois o usuário não interage diretamente com o
sistema - toda a comunicação com o usuário se dá através do navegador e é com este que
que o sistema troca mensagens.
Na figura 3.4a é apresentado o diagrama de sequência para o processo de Single-
Sign-On do protocolo de autenticação federada SAML. Na tabela 3.8 são detalhadas as
mensagens trocadas no diagrama.
3.3.2 O processo de logon com cartão inteligente
Este processo ocorre a partir da interação entre o usuário, navegador e o autenticador
(IdP). Para este diagrama, opta-se por separar os atores, usuário e navegador, para enfati-
zar as ações tomadas pelo usuário no momento da autenticação com seu cartão inteligente.
O processo de logon consiste, basicamente, na validação das credenciais de acesso
do usuário por meio do seu certificado digital A3, padrão ICP-Brasil. O usuário deverá
apresentar o certificado digital ao sistema por meio do navegador, onde será solicitado o
PIN para liberação das funcionalidades da chave privada do certificado, armazenada no
cartão inteligente.
O sistema gera um “desafio”, cifrando o hash de um valor gerado aleatoriamente com
a chave pública presente no certificado apresentado pelo usuário. Caso o usuário tenha
apresentado o PIN correto, o hash criptografado é decifrado pela chave privada associada,
retornando o hash original. Assim, o usuário prova sua identidade por meio de 2 fatores:
a posse da mídia que contém o certificado digital e o conhecimento do PIN de acesso às
funcionalidades da chave privada.
O processo de logon com cartão inteligente é mostrado na figura 3.4b. Na tabela 3.9
são detalhadas as mensagens trocadas no diagrama.
38 CAPÍTULO 3. MODELAGEM DO AUTENTICADOR ICP/SAML
(a)SSO
SA
M
L
.
(b)Processo
de
Logon.
Figura
3.4:D
iagram
as
de
sequência
3.3. DIAGRAMAS DE SEQUÊNCIA. 39
Tabela 3.8: Mensagens do Processo de SSO SAML.
Mensagem Descrição
1 - Acesso à Aplicação Requisição que ocorre quando o usuário acessa o sítio
(HTTP-GET) que contém a aplicação/serviço.
2 - Redirecione para o IdP Caso o usuário não esteja com uma sessão de logon
ativa (realizada nas últimas 6h), a aplicação carrega o
navegador com os parâmetros de sessão SAML e o re-
direciona para o autenticador. Se o navegador possuir
o token SSO, redireciona para o passo 8.
3 - Autenticação Após o redirecionamento, o navegador solicitar ao au-
tenticador para abrir uma sessão de validação do usuá-
rio
4 - Logon Processo de logon com cartão inteligente, detalhado
na subseção 3.3.2.
5 - Assertiva SAML O autenticador retorna ao navegador a assertiva
SAML e o redireciona de volta à aplicação.
6 - Consumir Asserção A aplicação recebe do navegador a assertiva SAML,
efetuando a seguir a validação desta.
7 - Token SSO Após a validação com sucesso da assertiva SAML, a
aplicação entrega ao navegador um token de Single-
Sign-On para conceder o acesso durante as próximas
6h sem necessidade de nova autenticação.
8 - Acessar Aplicação com
Token SSO
O navegador apresenta à aplicação o token SSO rece-
bido anteriomente.
9 - Aplicação Após validação do token SSO, o acesso à aplicação é
concedido
40 CAPÍTULO 3. MODELAGEM DO AUTENTICADOR ICP/SAML
Tabela 3.9: Mensagens do Processo Logon com Cartão Inteligente.
Mensagem Descrição
1 - Cartão Inteligente O autenticador solicita o cartão inteligente ao navega-
dor, que por sua o vez solicita ao usuário.
2 - Cartão Inserido O usuário insere o cartão inteligente na leitora. O
navegador notifica ao autenticador que o cartão está
pronto para leitura.
3 - Certificado Digital O autenticador solicita ao navegador o fornecimento
do certificado digital desejado para o processo de au-
tenticação.
4 - Selecionar Certificado O navegador lê os certificados digitais existentes no
cartão inteligente e solicita ao usuário que selecione
aquele desejado para o processo de logon.
5 - Certificado Selecionado O usuário informa ao navegador o certificado dese-
jado.
6 - Certificado ICP-Brasil O navegador retorna ao autenticador o certificado di-
gital ICP-Brasil selecionado pelo usuário.
7 - Responder Desafio O autenticador gera o desafio de autenticação com
base na chave pública do certificado aplicada ao hash
de um número aleatoriamente gerado, encaminhando-
o ao navegador para que seja respondido.
8 - PIN (requisição) O navegador solicita ao usuário que entre com o PIN
de desbloqueio das funcionalidades de chave privada
do certificado armazenado no cartão inteligente.
9 - PIN (resposta) O usuário entra com o PIN do cartão inteligente.
10 - Resposta ao Desafio O cartão inteligente decifra o desafio com a chave pri-
vada do certificado. A seguir o navegador entrega a
resposta do desafio (hash original) ao autenticador.
11 - Assertiva SAML O autenticador valida a resposta ao desafio e entrega
a assertiva SAML ao navegador.
3.4. CONSIDERAÇÕES FINAIS SOBRE A ETAPA DE MODELAGEM 41
3.4 Considerações finais sobre a etapa de modelagem
Utilizando algumas estruturas da linguagem UML foi possível modelar o sistema de
autenticação SAML / ICP-Brasil proposto com um bom nível de detalhes, simplificando
as etapas subsequentes de codificação e testes, além de propiciar documentação adequada
para uma boa compreensão da solução e futuras manutenções desta.
Os diagramas de casos de uso representaram a etapa inicial de levantamento de re-
quisitos, tomando por base as diretrizes de deperimetrização determinadas no capítulo 2.
Estes diagramas permitiram determinar a existência de dois atores - usuário e navega-
dor - que, apesar de atuarem em conjunto, executam interações distintas com os sistemas
“autenticador” e “aplicação”.
Já os diagramas de sequência possibilitaram determinar o conjunto de interações (mé-
todos e mensagens) entre os atores e o sistema, as quais haviam sido parcialmente in-
dicadas pelos casos de uso. Além disso, ratificaram a necessidade da modelagem das
funcionalidades de autenticação SAML de uma aplicação, uma vez que não seria possível
validar o sistema autenticador sem uma aplicação compatível com SAML.

Capítulo 4
Implementação do Autenticador
ICP/SAML
Concluídos o levantamento de requisitos e modelagem descritos no capítulo 3, as eta-
pas seguintes de desenvolvimento envolvem a codificação e a realização dos testes. Estas
fases são abordadas neste capítulo, concluindo o desenvolvimento da solução proposta de
software de autenticação federada, através de certificados ICP-Brasil.
4.1 Ferramentas de desenvolvimento utilizadas
A etapa de codificação leva em conta a definição da linguagem de programação, arqui-
tetura de software (middleware, frameworks, containers de aplicação, entre outros com-
ponentes) e ferramentas de apoio ao desenvolvimento, necessárias à transformação dos
requisitos e modelo de software definidos no capítulo 3 em código fonte. Esta etapa en-
volve ainda a configuração de ambiente onde o sistema será executado.
Este conjunto de tecnologias deve ser adequado ao desenvolvimento da solução pro-
posta, levando em consideração seus requisitos. O software em questão é um mecanismo
de autenticação federado cujo cerne é:
1. autenticação e captura de atributos do usuário através de certificados digitais A3/ICP-
Brasil em smart-cards;
2. transmissão dos atributos à aplicação de destino, através de assertivas do protocolo
SAML.
Logo, a escolha das ferramentas de desenvolvimento leva em consideração a adequa-
ção das mesmas para os dois atributos fundamentais definidos: interação com smart-cards
e com o protocolo SAML.
4.1.1 Linguagem de programação
Tendo em vista a necessidade de interação com smart-cards e o protocolo HTTP, sob
o qual o SAML é executado, optou-se pela utilização da linguagem Java. A escolha
44 CAPÍTULO 4. IMPLEMENTAÇÃO DO AUTENTICADOR ICP/SAML
justifica-se pelo fato de que existe um grande apoio da indústria de smart-cards à utili-
zação de seus produtos através de Java. Todos os cartões fornecidos no Brasil visando
a certificação digital ICP-Brasil são dotados de CSP - Cryptographic Service Provider
(provedor de serviços criptográficos - biblioteca que dá acesso às funções criptográficas
do dispositivo) compatível com a implementação Java do Public-Key Cryptography Stan-
dards - PKCS #11 (especificação voltada à comunicação com dispositivos criptográficos
em hardware).
Nesse sentido é importante notar que, independente da linguagem escolhida, existe a
necessidade de interação com o CSP do smart-card, o que, em linhas gerais, significa di-
zer que a parte do software responsável pela autenticação do usuário e captura dos atribu-
tos de seu certificado digital deverá interagir com uma biblioteca - arquivo .dll (Windows)
ou .so (Linux/MacOS) - presente no sistema de arquivos do computador do usuário.
4.1.2 Applet x Aplicação Desktop
Considerando a linguagem Java, a interação com uma biblioteca local do computa-
dor do usuário requer que ao menos parte do código do sistema proposto seja executado
localmente, podendo ser implementado através de uma das seguintes abordagens:
Aplicação Desktop: A aplicação é executada a partir do sistema de arquivos do compu-
tador do usuário, necessitando assim de instalação prévia;
Applet: O código objeto Java é encapsulado num arquivo JAR e carregado a partir de
um documento HTML no navegador do usuário. Requer que o código seja assinado
digitalmente para interagir com o CSP.
Tendo em vista o contexto Web do protocolo SAML, a escolha pela implementação
através de Applet é a mais adequada, permitindo que a aplicação seja carregada direta-
mente a partir de uma página, sem necessidade de instalação prévia.
4.1.3 Applet x Servlet
Numa primeira análise, seria possível considerar que toda a solução de autenticação
federada com smart-cards poderia ser implementada em Applet. Existem, no entanto,
alguns problemas no uso dessa abordagem:
1. O sistema é executado inteiramente na estação do usuário, o que requer um conjunto
maior de instruções incorporadas ao Applet, tornando-o maior e de carregamento e
execução mais demorados;
2. As bibliotecas necessárias à implementação do protocolo SAML devem ser carre-
gadas juntamente ao Applet, extendendo ainda mais o tempo de carregamento;
3. Tendo em vista que as mensagens SAML devem ser assinadas, o certificado digital
do IdP, sua chave privada e respectivas senhas precisam ser incorporados ao Applet.
Um atacante pode usar engenharia reversa para recuperar esses dados e utilizá-los
num ataque, se fazendo passar pelo IdP.
4.1. FERRAMENTAS DE DESENVOLVIMENTO UTILIZADAS 45
Dessa forma, percebe-se que parte do código (especialmente a geração de mensagens
SAML) não deve incorporar o Applet e sim ser executada em um Servlet (código Java
executado em contexto Web num servidor). Assim, é possível reduzir o Applet ao mínimo
necessário para interagir com o usuário e seu smart-card, tornando-o mais leve e o seu
carregamento mais rápido, deixando o processamento do protocolo SAML a cargo do
Servlet.
Considerando a modelagem realizada no capítulo 3, os casos de uso “Autenticar Usuá-
rio” e “Solicitar Certificado Digital e PIN” deverão ser implementados pelo Applet, en-
quanto o caso de uso “Gerar Assertiva SAML” será codificado no Servlet.
4.1.4 Container de aplicação
Tendo em vista a utilização de Servlet para implementação das funcionalidades do
protocolo SAML, um container de aplicação J2EE deve ser utilizado. Optou-se pela utili-
zação do Apache Tomcat [Apache 2012a], tendo em vista se tratar de uma implementação
em código aberto, largamente utilizada pela comunidade acadêmica e corporativa.
Para o presente trabalho, foi utilizada a versão 7.0.33 do referido software.
4.1.5 OpenSAML
O protocolo SAML consiste basicamente de mensagens XML codificadas em schemas
XML específicos. A utilização da biblioteca OpenSAML [Shibboleth 2012] permite ao
desenvolvedor concentrar-se na lógica do protocolo, abstraindo aspectos de baixo nível
como construção de strings XML e o tratamento (através de parser) de mensagens de
texto.
A biblioteca é disponibilizada para as linguagens Java e C++, nas versões 1.0 e 2.0
do protocolo SAML . Optou-se pela utilização da versão 2.0, tendo em vista ser a mais
recente.
4.1.6 Demais ferramentas utilizadas
Eclipse
O Eclipse [Eclipse 2012] é uma interface de desenvolvimento (IDE) compatível com
diversas linguagens de programação, especialmente adequada ao desenvolvimento Java.
Sua escolha se deu especialmente pela sua integração com o Apache Tomcat, permitindo
execução e depuração de código em tempo de execução do Servlet.
SAMLTracer
O SAMLTracer [Morken 2012] é um plugin disponível para o navegador Mozilla Fi-
refox. Permite o acompanhamento das interações HTTP, em especial a visualização das
mensagens SAML trocadas entre o IdP e o SP.
46 CAPÍTULO 4. IMPLEMENTAÇÃO DO AUTENTICADOR ICP/SAML
4.2 Codificação
O projeto de codificação foi dividido em 3 etapas:
• implementação dos casos de uso voltados ao Applet;
• implementação dos casos de uso voltados ao Servlet;
• integração entre o Applet e o Servlet através de JavaScript e HTML Forms.
As etapas de codificação são detalhadas a seguir.
4.2.1 Módulo Applet
O módulo Applet é o responsável pela interface com o usuário e acesso ao smart-card.
Ele é carregado através da página do IdP, após um redirecionamento realizado pelo SP.
Durante o redirecionamento, o SP carrega o navegador do usuário com uma instrução
HTTP-GET contendo os seguintes parâmetros na URL:
SAMLRequest: Contém uma string comprimida (deflated) e codificada em Base64 de
um elemento <samlp:AuthnRequest>.
RelayState: Representa algum valor de estado do SP (um id de seção, por exemplo).
Esta informação só tem significado para o SP - o IdP apenas recebe este parâme-
tro e o devolve ao SP sem nenhuma modificação, sendo, portanto, um mecanismo
adicional do protocolo SAML para associar requisições a respostas.
No apêndice A.1 é mostrado um exemplo de elemento <samlp:AuthnRequest> resul-
tante da decodificação e descompressão do parâmetro SAMLRequestURL de um redire-
cionamento do SP para o IdP.
Tendo em vista que o Applet não processa o protocolo SAML, durante o carregamento
inicial ele apenas captura os parâmetros SAMLRequest e RelayState para repassá-los ao
Servlet, juntamente com os atributos do usuário presentes em seu certificado, após o logon
com sucesso.
Concluída a inicialização, o Applet carrega as bibliotecas CSP presentes no sistema
de arquivos, solicitando ao usuário a digitação do código PIN do smart-card inserido.
Após a validação da credencial, os atributos do tipo Alternative Names são lidos, inter-
pretados e decodificados (codificação ASN1). A tabela 4.1 mostra os atributos de usuário
recuperados a partir da leitura dos identificadores de objeto (OID) do certificado digital.
Em seguida, o Applet deve repassar ao Servlet os parâmetros SAMLRequest e Re-
layState (obtidos da URL de redirecionamento do SP), além dos atributos do usuário.
Foram implementadas duas estratégias para a comunicação entre o Applet e o Servlet:
• Através do método “onSendData”, o Applet se comunica diretamente com o Servlet
através de conexão HTTP com Content-Type “application/x-java-serialized-object”,
encaminhando um objeto ICPSAMLContainer, o qual contém SAMLRequest, Re-
layState e atributos do usuário. Recebe do Servlet uma resposta com outro ICP-
SAMLContainer contendo os mesmos valores com exceção do SAMLRequest, cujo
4.2. CODIFICAÇÃO 47
Tabela 4.1: Atributos de usuário em um certificado A3 ICP-Brasil.
OID Atributo Descrição
2.16.76.1.3.1
DT_NASCIMENTO Data de nascimento
CPF Número do CPF
NIS Número de Identificação Social
RG Número do RG
RG_EXPEDIDOR Órgão expedidor do RG
RG_UF Estado onde foi emitido o RG
2.16.76.1.3.5
TE Título de Eleitor
TE_ZE Zona Eleitoral
TE_SECAO Seção Eleitoral
TE_CIDADE Cidade do eleitor
TE_UF Estado do eleitor
2.16.76.1.3.6 CEI Cadastro Específico do INSS
1.3.6.1.4.1.311.20.2.3 MSAD_UPN Login para rede Microsoft
conteúdo é substituído por um elemento <samlp:Response>. A seguir, o Applet
aciona o método “postRedirectToSP”, que envia os parâmetros SAMLResponse
(contendo o elemento <samlp:Response>) e RelayState através de uma requisição
HTTP-POST para a URL consumidora de asserções do SP (obtida a partir do ele-
mento <samlp:AuthnRequest>).
• Utilizando o método “postRedirectToIdPServlet”, o Applet preenche um formulário
oculto na página de autenticação, contendo os parâmetros SAMLRequest, RelayS-
tate e os atributos do usuário. A seguir, efetua um redirecionamento para o Servlet,
enviando os parâmetros através da requisição HTTP-POST, deixando a cargo do
Servlet o envio da resposta ao SP.
O diagrama de classes do Applet que implementa a funcionalidade descrita é mostrado
na figura 4.1.
4.2.2 Módulo Servlet
Ao Servlet são destinadas as funções de tratamento de mensagens (requisições e res-
postas) do protocolo SAML, Ele deve ser executado em um container de aplicação J2EE.
Sua principais funções são:
• Implementar o perfil Web Single-Sign-On do protocolo SAML;
• Gerar o XML de Metadados do IdP.
Web Single-Sign-On
A função de SSO do Servlet inicia com o recebimento dos parâmetros SAMLRequest,
RelayState e atributos do usuário. Tendo em vista que o Applet implementa duas meto-
dologias para envio dessas informações, o Servlet também codifica as duas modalidades
48 CAPÍTULO 4. IMPLEMENTAÇÃO DO AUTENTICADOR ICP/SAML
Figura
4.1:D
iagram
a
de
classes
do
A
pplet.
4.2. CODIFICAÇÃO 49
de comunicação, checando o Content-Type da requisição para determinar o tratamento
correto:
• Caso seja do tipo “application/x-java-serialized-object”, a conexão com o Applet é
direta, e a requisição é recebida através de um objeto ICPSAMLContainer.
• Caso seja do tipo “html/text”, os parâmetros foram enviados através de HTTP-
POST, por meio de um formulário oculto. O Servet lê os dados do formulário e
cria um ICPSAMLContainer a partir dos dados recebidos.
O container é então processado, sendo extraído o elemento <samlp:AuthnRequest>.
Em seguida, é criada uma asserção (<samlp:Assertion>) com base nos atributos do usuá-
rio <samlp:AttributeStatement>. A asserção é assinada digitalmente utilizando o certifi-
cado digital do IdP e encapsulada num elemento <samlp:Response>, o qual referencia a
requisição à qual se relaciona (campo “InResponseTo”) e o endereço consumidor de asser-
ções do SP (campo “AssertionConsumerServiceURL”). O elemento <samlp:Response>
é, finalmente, assinado com o certificado digital do IdP. No apêndice A.2 é mostrado um
exemplo de elemento <samlp:Response>, o qual é a resposta para o <samlp:AuthnRequest>
mostrado em A.1.
Caso a requisição tenha sido recebida por conexão direta, a resposta ao Applet será
através de um objeto ICPSAMLContainer, conforme já informado. Caberá ao Applet
efetuar o redirecionamento ao SP. Por outro lado, se a requisição tiver ocorrido por meio
de formulário oculto em HTTP-POST, o Servlet montará um novo formulário oculto, ge-
rando os parâmetros SAMLResponse (contendo o elemento <samlp:response> codificado
em Base64) e RelayState (copiado da requisição). O redirecionamento será realizado, en-
tão, para o endereço consumidor de asserções do SP.
Geração de Metadados do IdP
Alguns SP podem carregar as informações do IdP de forma automática a partir de
um descritor XML. Este descritor contém, além do identificador do IdP, os certificados
digitais utilizados na assinatura mensagens e os endereços de recebimento das requisições.
No apêndice A.3 é mostrado um exemplo de elemento XML contendo metadados do IdP.
O diagrama de classes do Servlet é mostrado na figura 4.2.
4.2.3 Integração dos módulos
Para realizar a integração das funcionalidades do Applet e do Servlet, foi criado um
pacote de utilitários de uso comum a ambos. Este pacote é constituído de 3 classes:
ICPSAMLConstants: Define as constantes (endereços estáticos, nomenclatura de pa-
râmetros, campos de formulário, entre outros) utilizadas em todo o projeto;
ICPSAMLContainer: Classe que armazena uma informação SAML (requisição ou
resposta), o RelayState do SP e os atributos do usuário. É utilizada quando a co-
municação entre o Applet e o Servlet se dá através do Content-Type “application/x-
java-serialized-object”.
50 CAPÍTULO 4. IMPLEMENTAÇÃO DO AUTENTICADOR ICP/SAML
Figura
4.2:D
iagram
a
de
classes
do
Servlet.
4.3. TESTES 51
ICPSAMLUtils: Conjunto de métodos para tratamento de mensagens SAML, especi-
almente decodificação e descompressão.
O diagrama de classes do pacote de utilitários é mostrado na figura 4.3.
Quando a comunicação entre o Applet e o Servlet se der através de redirecionamento
HTTP-POST (Content-Type “html/text”), um formulário oculto na página que carrega
o primeiro é utilizado. Este formulário é preenchido através de uma função JavaScript
presente na página, a qual é chamada pelo Applet.
4.3 Testes
Para realização dos testes de funcionamento do mecanismo de autenticação federada,
foi criado um sítio “Deperimetrização.com.br” [Souza 2012], executado a partir do con-
tainer de aplicação Apache Tomcat.
A metodologia adotada para realização dos testes foi a utilização de SP de terceiros
reconhecidos pela implementação adequada do protocolo SAML. Garante-se, assim, que
os testes são isentos de erros de programação ou de conter apenas algumas amostras de
resultados viciados, contando apenas requisições e respostas moldadas ao sistema desen-
volvido (e vice-versa), fato que ocorre geralmente quando o desenvolvedor é também o
testador da aplicação.
Procedeu-se a uma sequência de testes, de modo a validar a modelagem e implemen-
tação realizadas. Os resultados encontrados são mostrados a seguir.
4.3.1 SimpleSAMLphp
O SimpleSAMLphp [UNINETT 2012] é uma implementação de referência do proto-
colo SAML, podendo atuar como IdP ou SP. Uma vantagem adicional de utilizá-lo é o
fato de que, por ser escrito em linguagem PHP, mostra que o protocolo SAML (e o auten-
ticador desenvolvido) é independente de linguagem de programação (SP escrito em PHP,
trocando mensagens em XML com um IdP escrito em Java).
Foi utilizada a configuração SP do aplicativo, sendo instalado num servidor Apache
[Apache 2012b] dentro do sítio “Deperimetrizacao.com.br”. O teste é realizado através
da opção “Test authentication sources”, para a qual é mostrada uma tela de seleção do IdP
desejado, conforme mostrado na figura 4.4.
Escolhido o IdP do sítio “Deperimetrizacao.com.br”, o navegador do usuário é redi-
recionado para que o usuário efetue sua autenticação. Na URL de redirecionamento são
incluídos os parâmetros SAMLRequest e RelayState. Na figura 4.5 é mostrada a requisi-
ção SAML através do plugin SAMLTracer.
Dentro do IdP, a página contendo o Applet é carregada, capturando os parâmetros
SAML e solicitando o usuário a inserção do seu smart-card e o fornecimento do PIN de
liberação das funções criptográficas do cartão, conforme mostrado na figura 4.6.
O Applet recupera os atributos do usuário a partir do seu certificado digital ICP-Brasil,
encaminhando-os ao IdP. O IdP processa o elemento <samlp:AuthnRequest> e os atribu-
tos do usuário, gerando a resposta <samlp:AuthnResponse>, a qual é encaminhada à URL
52 CAPÍTULO 4. IMPLEMENTAÇÃO DO AUTENTICADOR ICP/SAML
Figura
4.3:D
iagram
a
de
classes
do
pacote
de
utilitários.
4.3. TESTES 53
Figura 4.4: Seleção do IdP - SimpleSAMLphp.
Figura 4.5: Requisição SAML capturada pelo SAMLTracer.
54 CAPÍTULO 4. IMPLEMENTAÇÃO DO AUTENTICADOR ICP/SAML
Figura 4.6: Tela de login do Applet.
de consumo de asserções do SP. O SP valida a resposta e registra o acesso do usuário (fi-
gura 4.7.
Figura 4.7: Autenticação com sucesso - SimpleSAMLphp.
4.3.2 TestShib Two
O “TestShib Two” [Internet2 2012] é um sítio criado pelos desenvolvedores do Shib-
boleth e voltado ao teste de instalações deste por parte dos usuários. No entanto, por ser
baseado em SAML, é compatível com qualquer implementação deste protocolo. Assim
como o SimpleSAMLphp, o “TestShibTwo” pode atuar como IdP ou SP. O sistema não
requer nenhuma instalação e deve ser executado diretamente de seu sítio. Outra vantagem
é que ele necessita do arquivo de metadados do IdP, fazendo sua validação e permitindo,
assim, testar a função de geração de metadados do autenticador.
O primeiro passo para sua utilização é a inclusão dos dados do IdP na base de dados.
Isso é realizado através da opção “Register”. O sistema irá solicitar o fornecimento do ar-
4.4. CONCLUSÕES SOBRE AS ETAPAS DE IMPLEMENTAÇÃO E TESTES 55
quivo XML contendo os metadados do IdP. Através do endereço de geração de metadados
- http://idp.deperimetrizacao.com.br:8080/Metadata - é obtido o arquivo XML do auten-
ticador desenvolvido. Submetendo este arquivo ao TestShib Two é obtida a validação do
mesmo e a inclusão em sua base de dados, conforme mostrado na figura 4.8.
Figura 4.8: Tela de carregamento dos metadados do IdP - ShibTestTwo.
O passo seguinte é acessar a opção “Test”, escolhendo o teste do serviço de IdP através
do SP. Deve ser fornecido o “EntityID” do IdP registrado.
O navegador do usuário é redirecionado ao IdP, onde o usuário efetua a autenticação
com seu certificado A3/ICP-Brasil, conforme mostrado anteriormente. É gerada a res-
posta de autenticação, encapsulada no parâmetro “SAMLResponse”, devolvida ao SP. O
resultado da autenticação é mostrado na figura 4.9.
4.4 Conclusões sobre as etapas de implementação e testes
A etapa de implementação foi executada de modo a implementar as funcionalidades
propostas do autenticador de identidade federada baseado em certificados A3/ICP-Brasil.
A separação das funcionalidades da ferramenta em dois módulos, Applet e Servlet, se
mostrou adequada tanto em termos de segurança como de desempenho.
Os diagrama de classes apresentados consolidaram as informações dos diagramas de
casos de uso e de sequência (alto nível de abstração) num conjunto de informações volta-
das à codificação diretamente em linguagem de programação (baixo nível de abstração),
utilizando orientação a objetos.
Os testes, utilizando SP de terceiros, mostraram que o autenticador implementa ade-
quadamente o perfil Web Single Sign-On do SAML, podendo assim ser utilizado para au-
tenticação do usuário na Internet com qualquer SP compatível com SAML. Além disso,
56 CAPÍTULO 4. IMPLEMENTAÇÃO DO AUTENTICADOR ICP/SAML
Figura 4.9: Autenticação com sucesso - ShibTestTwo.
a geração de metadados foi validada, permitindo que a ferramenta possa ser utilizada
também com SP que os exijam.
Capítulo 5
Estudo de Caso: Rede da Justiça
Eleitoral
Neste capítulo é analisada a rede da Justiça Eleitoral (JE), tanto nos aspectos relativos
à infraestrutura quanto aos sistemas, no que diz respeito à segurança da informação, dando
enfoque especial nos benefícios advindos da aplicação de uma estrutura deperimetrizada.
Esta rede foi selecionada para o estudo de caso deste trabalho tendo em vista que
o autor é servidor da JE, atuando no setor de gerência de infraestrutura de rede de seu
órgão, permitindo uma melhor compreensão do funcionamento da rede de computadores,
especialmente no tocante à segurança da informação.
5.1 A infraestrutura de rede da Justiça Eleitoral
A JE adota uma topologia de infraestrutura de rede hierárquica, isto é, uma divisão
dos segmentos de rede organizada de acordo com a relevância em relação ao todo. Tal
divisão segue o modelo de árvore, no qual o nó raiz é o topo da hierarquia e a partir do
qual surgem derivações (ramos e sub-ramos) até os nós-folha da estrutura.
Nesse modelo de hierarquia baseado em árvore, conforme mostrado na figura 5.1, a
raiz do sistema é a próprio Tribunal Superior Eleitoral (TSE), a partir do qual se origina
toda a rede da JE, sendo, a princípio, o único ponto da rede com conectividade à Internet.
5.1.1 Conexão à Internet
É no TSE que se encontra a conexão de toda a rede da JE com a Internet. Todo
o tráfego que entra ou sai da rede da JE passa pelo TSE. Mesmo o acesso de usuários
externos aos sítios dos Tribunais Regionais Eleitorais (TRE) - como em http://www.tre-
rn.gov.br, por exemplo - se dá através dos links de Internet do TSE, ou seja, ocorrendo
assim grande competição entre diversos tipos de tráfego de entrada e saída.
Assim, é interessante verificar que a capacidade desses links deve ser suficiente para
atender a toda demanda de acesso à Internet do TSE, TREs, Zonas Eleitorais (ZE) e
Centrais de Atendimento (CA) de todo o país. Além disso, a indisponibilidade desta
conexão implica na perda de conectividade à Internet de toda a JE, caracterizando assim
um único ponto de vulnerabilidade à falha.
58 CAPÍTULO 5. ESTUDO DE CASO: REDE DA JUSTIÇA ELEITORAL
Figura 5.1: Rede da Justiça Eleitoral.
5.1.2 Backbone Principal - TSE/TREs
Cada TRE, por sua vez, se conecta ao TSE (raiz da árvore) através de um link dedicado
contratado junto à alguma operadora de telecomunicação. A tecnologia adotada é, em
geral, “Frame Relay” ou MPLS. Eventualmente, links via satélite são utilizados. À essa
infraestrutura básica de conexão TSE/TREs se dá o nome de backbone principal da rede
da JE.
Através do backbone principal trafegam os dados relativos ao acesso à Internet, por
parte dos TREs. Além disso e, principalmente, são transportados nessa malha de rede
os dados relativos aos sistemas eleitorais, especialmente aqueles relativos à totalização
das eleições. Qualquer falha afetando este backbone implica na perda total de comunica-
ção entre determinado TRE e o TSE, ocasionando assim a indisponibilidade de diversos
sistemas administrativos e eleitorais.
A capacidade de tráfego de cada enlace do backbone principal varia de um TRE para
outro, levando em conta fatores como eleitorado e quantidade de ZEs (Zonas Eleitorais).
Os custos para manter essa infraestrutura são elevados, tendo em vista que são ligações
ponto-a-ponto de milhares de kilômetros fornecidos por empresas de telecomunicação.
Dado que o tráfego de Internet dos TREs também passa pelo backbone primário, uma
primeira forma de reduzir significativamente estes valores seria delegar a cada TRE seu
próprio acesso à Internet, conforme mostrado na figura 5.3. Considerando que o trá-
fego dos sistemas eleitorais corresponde a apenas uma pequena fração do tráfego total, a
velocidade dos links do backbone principal poderia ser bastante reduzida - e consequen-
temente os custos.
Na abordagem deperimetrizada sequer haveria necessidade de manutenção de um
backbone, uma vez que toda a comunicação entre TSE, TREs, ZEs e CAs se daria de
5.1. A INFRAESTRUTURA DE REDE DA JUSTIÇA ELEITORAL 59
Figura 5.2: Backbones Principal e Secundário.
forma segura através da Internet, representando assim uma considerável economia aos
cofres públicos.
Figura 5.3: Ligação direta à Internet / Backbone deperimetrizado.
5.1.3 Backbones Secundários - TRE/ZEs
Cada TRE em si é a raiz de uma árvore menor, formada pela secretaria do tribunal,
escritórios remotos, ZEs e CAs (centrais de atendimento). A estrutura de comunicação
é equivalente ao backbone principal: links ponto-a-ponto (Frame-Relay, MPLS, satélite)
interligando os nós-folha a um ponto central, geralmente localizado no prédio sede de
cada TRE.
Pode-se visualizar os backbones secundários como versões reduzidas do backbone
60 CAPÍTULO 5. ESTUDO DE CASO: REDE DA JUSTIÇA ELEITORAL
principal. De fato, os mesmo problemas e solucões aplicáveis neste acabam sendo herda-
dos para aqueles.
5.1.4 O perímetro da Justiça Eleitoral
Para o escopo deste trabalho o mais importante é perceber que o TSE é o limiar da rede
da JE, o perímetro propriamente dito. É no TSE que toda a logística de segurança peri-
metrizada é implementada através de regras de firewall extremamente restritivas (camada
de rede) e regras ACL para acesso via proxy HTTP (camada de aplicação).
O acesso à Internet a partir dos TREs se dá unicamente através de proxy HTTP/FTP
nas portas 21 (FTP), 80 (HTTP) e 443 (HTTPS). Em decorrência disso, aplicações que
usam outras portas e/ou não são adaptadas a encapsular tráfego sobre HTTP tem seu funci-
onamento impedido. Neste rol podemos citar: P2P, vídeo e áudio conferência, VoIP, men-
sageiros instantâneos, vídeo ao-vivo ou sob demanda, dentre diversas outras. O proxy,
concentrado no TSE, além de armazenar em cache os sítios visitados, efetua principal-
mente a filtragem de acesso baseada em Listas de Controle de Acesso (ACL), especial-
mente se valendo de palavras-chave contidas no Universal Resource Locator (URL) da
conexão. Neste caso, acrescenta-se um novo ponto de falha que é o próprio serviço de
proxy.
O que se busca com este tipo de abordagem de segurança é restringir as aplicações
que podem ser utilizadas dentro da rede, limitando a utilização apenas às que conseguem
trabalhar sobre proxy HTTP, mais notadamente navegadores web. Mesmo estes tem sua
funcionalidade limitada à filtragem efetuada pelo proxy. Esta filtragem, que pode ser
tanto através de palavras-chave na URL ou avaliação heurística de conteúdo, incorre com
frequência em falsos positivos, prejudicando a experiência do usuário e aumentando o
esforço administrativo (revisão frequente de ACLs, inclusão de URLs em listas de exces-
são).
Assim, é possível concluir que o resultado alcançado não é efetivamente o incremento
da segurança da informação, mas sim a diminuição da utilização da banda de rede de-
corrente da indisponibilidade de alguns tipos acesso. Por exemplo, temos que a conexão
a sítios de maior utilização de banda de rede (repositórios de vídeo, redes sociais, entre
outros) é vedada. De fato, considerando a estrutura adotada para o backbone principal,
o limite de utilização de tráfego acaba sendo necessário, de modo a permitir o funcio-
namento adequado dos sistemas eleitorais em detrimento de uma adequada utilização da
Internet.
Numa abordagem deperimetrizada essa metodologia não seria necessária, uma vez
que todo o tráfego destinado à Internet fluiria diretamente a partir dos TREs, sem passar
pelo TSE. Seria viável, inclusive, a contratação de dois enlaces: um exclusivo para o
tráfego de Internet e outro para o tráfego de dados dos sistemas eleitorais.
Nota-se, no entanto, que a metodologia baseada em perímetro só tem relativa eficácia
quanto ao usuário comum. O usuário avançado pode se valer de métodos diversos para
acessar qualquer conteúdo desejado: mascaramento de URL através de registros de DNS
alternativos, proxy transparente externo, tunelamento, entre outros. Além disso, verifica-
se que os riscos à segurança da informação elencados na seção 2.2 aplicam-se a este caso
5.2. CLASSIFICAÇÃO DOS SISTEMAS DA JUSTIÇA ELEITORAL 61
concreto.
5.2 Classificação dos sistemas da Justiça Eleitoral
Além da infraestrutura, a rede da JE é composta por diversos sistemas baseados em
software. Podemos classificá-los de acordo com a finalidade a que se propõem: eleitorais
(e de apoio à eleição), administrativos, judiciais e de infraestrutura.
5.2.1 Sistemas eleitorais e de apoio à eleição
Os sistemas eleitorais e de apoio à eleição compreendem todos os sistemas relaciona-
dos diretamente à atividade fim da JE: as eleições. Tais sistemas são responsáveis pelo
alistamento eleitoral, filiação partidária, revisão de eleitorado, geração de mídia das ur-
nas eletrônicas, totalização de votos e divulgação de resultados do pleito. São sistemas
críticos para o funcionamento da JE, tendo toda sua administração centralizada no TSE,
especialmente as bases de dados de eleitores, candidatos e partidos políticos.
A manipulação dos dados destes sistemas é realizada através de aplicativos dispo-
nibilizados num ambiente Microsoft Windows modificado. Tal modificação consiste na
aplicação de uma camada adicional de segurança denominada Subsistema de Instalação
e Segurança - SIS [Unicamp 2002]. A principal mudança que o SIS traz ao ambiente
Windows é a substituição de algumas bibliotecas de autenticação do sistema, levando a
um reforço das políticas de segurança para auditoria e logon de usuários. Assim, usuá-
rios com perfil administrativo do sistema necessitam de credenciais adicionais de acesso,
geradas através de sistema de contra-senha (figura 5.4).
A nomenclatura das estações de trabalho segue uma formação bem definida, contendo
informações como número da ZE ou CA, tipo da autenticação (local ou Active Directory)
e número sequencial da estação. Após o logon com sucesso, o acesso aos aplicativos é
feito diretamente sem autenticação adicional, utilizando o nome de usuário e da estação
de trabalho. De fato, todos os requisitos de identidade e acesso dos aplicativos da JE
baseiam-se nessas duas informações, sendo os requisitos de autenticação delegados ao
Windows: usuário e senha. Os sistemas eleitorais também se valem do fato de que seu
acesso é privativo à Intranet da JE, sendo bloqueados externamente. É possível, assim, re-
sumir os requisitos de acesso aos sistemas eleitorais: usuário válido e estação de trabalho
com nomenclatura adequada acessando a partir da rede da JE.
5.2.2 Sistemas administrativos
Assim como outros órgãos da administração direta, os TREs e TSE possuem diver-
sos sistemas voltados ao controle das atividades administrativas. Podem ser destacados
alguns, tais como:
Processo Administrativo Eletrônico - protocolo e trâmite de documentos entre as se-
ções do Tribunal;
62 CAPÍTULO 5. ESTUDO DE CASO: REDE DA JUSTIÇA ELEITORAL
Figura 5.4: Geração de contrasenha para estação com SIS.
Gerência de Recursos Humanos - controle de férias, folgas, viagens a serviço, contra-
cheques, lotação, entre outros;
Patrimônio e Almoxarifado - inventários de bens, registro de compras, aquisição e en-
trega de material de expediente.
Dada a autonomia administrativa, alguns destes sistemas são desenvolvidos pelo pró-
prio órgão, enquanto outros, desenvolvidos pelo TSE, são incorporados. As bases de
dados são centralizadas no próprio TRE e os mecanismos de autenticação variam de um
sistema para outro: Active Directory, Oracle, autenticação própria da aplicação. Neste ce-
nário surge um sério risco à segurança da informação: é impossível aplicar uma política
de segurança de senhas uniforme. Em resumo, os usuários precisam memorizar (ou ano-
tar) diversas credenciais de acesso. Aumenta também o esforço de administração destes
sistemas diante de bloqueios de conta por tentativas inválidas de acesso (usuário entrando
com credenciais de outro sistema) e manutenção das diversas bases de autenticação.
Além disso, um atacante pode obter mais facilmente dados de acesso a partir de bases
de autenticação menos seguras e efetuar mais facilmente ataques a sistemas de autentica-
ção mais forte. Tendo isso em conta, faz-se importante o desenvolvimento e implantação
de um mecanismo de autenticação forte e unificado, provendo serviços de logon e audito-
ria de acesso a diversas aplicações.
Os riscos de acesso indevido a sistemas administrativos vão desde a quebra da con-
fidencialidade (acesso a um contracheque, informações privilegiadas sobre um pregão
eletrônico, entre outros), integridade (alteração de folgas ou férias gozadas, remunera-
ção), disponibilidade (modificação de perfis de acesso de aplicações, alteração de senha
5.2. CLASSIFICAÇÃO DOS SISTEMAS DA JUSTIÇA ELEITORAL 63
de acesso) e não-repúdio (substituição de um pedido de folga por um de exoneração de
servidor, por exemplo). Os efeitos e sanções chegam a ultrapassar a esfera do direito
administrativo.
5.2.3 Sistemas judiciais
Sistemas judiciais destinam-se ao apoio das atividades plenárias de advogados, pro-
motores, juízes e assessores. Tais sistemas permitem o fornecimento de informações e
registro por texto, áudio e vídeo dos julgamentos e decisões realizadas pelos magistra-
dos. Falhas desses sistemas podem acarretar a perturbação das sessões plenárias (num
julgamento, por exemplo), ocasionando atrasos em julgamentos, além do desgaste moral
da instituição, uma vez que estas seções são, inclusive, transmitidas ao vivo à população
pela Internet.
5.2.4 Sistemas de TIC
Sistemas de TIC são aqueles fornecidos ou diretamente relacionados às atividade de
tecnologia da informação e comunicação. Compreendem desde subsistemas básicos de
acesso à rede (comutadores, roteadores, pontos de acesso sem fio) a serviços de autenti-
cação de usuários. A seguir são listados alguns destes sistemas:
sistemas de comunicação - e-mail, bate-papo, fax corporativo;
armazenamento de arquivos - áreas compartilhadas para acesso a arquivos da rede via
protocolos SMB e NFS;
serviço de autenticação - kerberos, ldap, Active Directory, Oracle, radius - usados por
aplicações e dispositivos para validação de credenciais de acesso;
sistemas de gerenciamento de bancos de dados - Oracle, MySQL, PostgreSQL, SQL-
Server;
infraestrutura de rede e dados - ativos de rede (comutadores, roteadores), Storage Area
Network - SAN e Network Attached Storage - NAS (tecnologias de armazenamento
e recuperação de dados em rede), unidades de fita;
sistemas de gerenciamento de infraestrutura - serviços de atualização de estações (WSUS)
e antivírus, inventário de software (Cacic, System Center Configuration Manager),
monitoramento de ativos (SNMP, Zabbix)
Os sistemas de TIC são vitais ao funcionamento do Tribunal, uma vez que deles de-
pendem os demais sistemas. Por exemplo, se os serviços de autenticação falharem, diver-
sas aplicações como processo administrativo eletrônico e e-mail tornam-se indisponíveis
aos usuários. Um ataque a um roteador ou comutador pode impactar um segmento inteiro
da rede. Uma corrupção de dados em um banco de dados ou dispositivo de armazena-
mento (storage) pode levar à perda de informações críticas em todos os sistemas.
64 CAPÍTULO 5. ESTUDO DE CASO: REDE DA JUSTIÇA ELEITORAL
5.3 Deperimetrização aplicada à Justiça Eleitoral
Pelo exposto, verifica-se que a rede da JE adota o modelo de segurança baseado em
perímetro. Conforme mostrado no capítulo 2, essa abordagem é ineficaz no contexto das
redes de computadores da atualidade, especialmente quando se leva em consideração os
riscos à segurança da informação elencados na seção 2.2.
A concepção dualista das redes de computadores acabou levando à criação de uma
intranet em nível nacional, interligada pelos enlaces dos backbones primário e secundá-
rio, com custo elevado aos cofres públicos. Numa rede deperimetrizada, não haveria a
necessidade de contratação de enlaces dedicados de centenas e milhares de quilômetros
- toda a comunicação trafegaria de forma segura na Internet, representando significativa
economia ao erário.
A utilização da Internet em substituição a um backbone estaticamente definido per-
mitiria também uma flexibilização da topologia da rede, ajustando-a de forma dinâmica
conforme necessário. Em particular, ações temporárias de atendimento ao eleitor, como
a “Justiça Itinerante” e o recadastramento biométrico, seriam extremamente facilitadas.
Para estas ações, geralmente montadas em praças e eventos, bastaria a disponibilização
de acesso à Internet (através de um modem 3G/4G, por exemplo) para que os sistemas
eleitorais pudessem ser utilizados.
5.3.1 Aplicações do mecanismo desenvolvido
Outro aspecto observado é o fato de que diversas aplicações possuem acesso restrito à
intranet da JE, também em decorrência da concepção dualista. A utilização do modelo de
segurança baseado em perímetro acaba, assim, acarretando situações inusitadas. No caso
específico do TRE-RN, podemos citar alguns exemplos: o e-mail corporativo e o sistema
de processo administrativo eletrônico.
Pessoas vinculadas à JE só podem acessar suas caixas postais corporativas a partir da
rede da JE. Da mesma forma, o acesso a diversos serviços de e-mail de terceiros é blo-
queado na rede interna. Com frequência, estas pessoas acabam necessitando encaminhar
mensagens de suas caixas postais externas para o e-mail corporativo e vice-versa. Mesmo
o webmail corporativo é limitado ao escopo da intranet.
Apesar de contar com um moderno sistema web de Processo Administrativo Eletrô-
nico - PAE, os servidores do TRE-RN só podem acessá-lo a partir da intranet corporativa.
Em situações de afastamento (férias, licença maternidade, cessão a outro órgão da admi-
nistração pública, entre outros), o servidor fica impossibilitado de utilizar o sistema para
consultar o andamento dos processos em tramitação ou protocolar algum documento (um
requerimento pessoal, por exemplo). Nessa situação, a única alternativa é comparecer
presencialmente ao TRE-RN (o próprio interessado ou um procurador nomeado) e entre-
gar a cópia impressa do documento na seção de protocolo, onde este será digitalizado e
protocolado no sistema PAE.
Em ambos os casos, a permanência do modelo de segurança perimetrizado impede a
utilização adequada dos sistemas corporativos, devido à restrição de utilização apenas na
intranet. Nesse sentido, a fase 1 do processo de deperimetrização prevê que o primeiro
5.3. DEPERIMETRIZAÇÃO APLICADA À JUSTIÇA ELEITORAL 65
passo rumo à uma rede sem fronteiras é a externalização das aplicações web corporativas.
Dado o receio de acesso indevido a tais sistemas a partir da Internet, a solução seria a
adoção de um mecanismo seguro de identificação, como o apresentado nesta dissertação.
Além de aproximar as aplicações mencionadas (bem como diversas outras) das pes-
soas que as utilizam, a adoção do mecanismo também permitiria a expansão das funcio-
nalidades do PAE. Levando em consideração o recurso de identificação federada, pessoas
externas ao TRE-RN poderiam utilizar a aplicação sem a necessidade de cadastro prévio
nos sistemas de autenticação da instituição. O PAE poderia, assim, ser adaptado para o
trâmite de processos judiciais eleitorais - um advogado de um partido político poderia,
por exemplo, protocolar uma petição e acompanhar o processo diretamente a partir da
Internet.
Teletrabalho
Estendendo este entendimento, a abordagem deperimetrizada possibilitaria também a
implantação do teletrabalho. Como uma tendência natural da sociedade da informação,
o teletrabalho já é uma realidade na iniciativa privada e se encontra em processo de im-
plantação também no funcionalismo público. Dada a legislação existente [TST 2012],
a restrição à sua utilização se deve a questões técnicas (acesso seguro) e administrativas
(definição das atividades que podem ser desempenhadas remotamente).
Se os sistemas utilizados no TRE-RN (judiciais, administrativos, eleitorais e de TIC),
bem como em outros órgãos públicos, fossem externalizados e houvesse um mecanismo
seguro e eficaz de identificação, como o desenvolvido neste trabalho, não haveria impe-
dimento técnico para que parte considerável dos servidores pudesse desempenhar suas
atividades remotamente, restando apenas a análise na esfera administrativa.
Com a adoção do teletrabalho, seriam reduzidas diversas despesas decorrentes da pre-
sença física do servidor nas dependências do órgão, como: mobiliário, microcomputador,
telefone, ar-condicionado, acesso à Internet, energia elétrica, limpeza, entre outros. Além
disso, o teletrabalho permitiria um melhor aproveitamento dos servidores, em razão da di-
minuição de afastamentos decorrentes de licença para acompanhamento de cônjuge (Art.
84), participação em programa de pós-graduação stricto sensu no país (Art. 96-A) ou no
exterior (Art. 96-A, §7o), previstos na Lei 8.112/90. Nestes casos, mesmo afastado geo-
graficamente, o servidor poderia continuar exercendo as atividades relativas ao seu cargo
público.
5.3.2 Identidade funcional digital
Tendo em vista que o mecanismo de identificação federada proposto depende da uti-
lização de smart-cards, foi proposto ao TRE-RN um projeto visando a substituição das
atuais identidades funcionais e crachás de identificação por seus equivalentes digitais. A
principal vantagem obtida com a substituição é o incremento dos níveis de segurança (fí-
sica e lógica) da instituição. O projeto prevê a utilização de cartões híbridos, dotados de
duas interfaces:
• Interface com contato: voltada à utilização de certificados digitais A3 ICP-Brasil,
66 CAPÍTULO 5. ESTUDO DE CASO: REDE DA JUSTIÇA ELEITORAL
sendo compatível com o mecanismo de identificação federada proposto neste tra-
balho. Esta interface permite recursos de autenticação de dois fatores e assinatura
digital. É utilizada a partir de uma leitora, conectada ao computador pela porta
USB, na qual o cartão é inserido.
• Interface sem contato: destinada ao controle eletrônico do acesso físico (também
fundamental à segurança da informação), especialmente em locais críticos como
sala de servidores, centrais elétrica e telefônica, entre outros. A interface sem con-
tato funciona por meio de radiofrequência, a partir de um leitor de proximidade
instalado próximo à porta de acesso. O leitor é capaz de validar os dados do cartão
junto a um sistema de autenticação e autorização, o qual determina a liberação ou
não do acesso ao local.
A utilização das identidades funcionais digitais possibilitará ao TRE-RN avançar nas
fases 1 e 2 do processo de deperimetrização. A minuta do projeto foi anexada ao presente
trabalho, no apêndice B.
Capítulo 6
Considerações finais e trabalhos futuros
Neste trabalho foram explorados os problemas da manutenção da visão tradicional
de segurança da informação - modelo do “castelo e fosso” - no ambiente corporativo.
Foram elencados diversos riscos aos quais empresas e instituições estão sujeitas diante da
permanência num modelo de segurança que não mais atende às necessidades das redes de
computadores da atualidade.
De modo a lidar com as ameaças à segurança da informação não adequadamente trata-
das no modelo atual, um novo paradigma começou a ser estudado na última década. Este
paradigma, denominado deperimetrização, foi apresentado no capítulo 2, a partir de uma
revisão bibliográfica sobre o tema. Foi mostrado, no entanto, que o modelo deperime-
trizado de segurança carece de algumas ferramentas tecnológicas ainda inexistentes para
que possa ser plenamente implantado em uma rede corporativa. Dentre elas, escolheu-
se o mecanismo seguro e eficaz de identificação federada para ser o principal objeto de
estudo e contribuição deste trabalho.
Foram pesquisadas as ferramentas de identificação federada existentes, onde foi verifi-
cado que nenhuma delas cumpria com os requisitos de segurança exigidos pelo paradigma
da deperimetrização. Para tal finalidade, determinou-se que uma escolha adequada seria
a criação de um mecanismo de identificação compatível com o protocolo SAML (para
cumprir com os requisitos de identidade federada), capaz de realizar a autenticação forte
do usuário (dois ou três fatores de autenticação), a partir da utilização de smart-cards
contendo um certificado digital A3 ICP/Brasil.
No capítulo 3 foram apresentados o levantamento de requisitos do mecanismo e a
modelagem da solução proposta, a partir de diagramas de casos de uso e sequência da
linguagem UML. Em seguida, no capítulo 4, é descrita a implementação do modelo de
software definido anteriormente, realizada a partir de um conjunto formado por um Applet
e um Servlet, ambos codificados em linguagem Java. Testes com aplicativos de terceiros
mostraram que a solução foi desenvolvida adequadamente, estando apta à utilização na
Internet.
Finalmente, no capítulo 5, foi descrito um estudo de caso sobre a segurança da rede da
Justiça Eleitoral, o qual tomou por base os conteúdos estudados neste trabalho. Verificou-
se que a rede em questão adotava o modelo de segurança baseado em perímetro, estando
sujeita aos riscos à segurança da informação levantados no capítulo 2. Foram analisados
os tipos de sistemas informatizados utilizados e os impactos decorrentes de falhas relaci-
68 CAPÍTULO 6. CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS
onadas à segurança da informação. Foram mostrados casos concretos onde a segurança
baseada em perímetro impacta também no entrave da evolução de soluções corporativas:
webmail, processo administrativo eletrônico e teletrabalho. Para lidar com estes casos, foi
sugerida a utilização de um mecanismo de identificação federada, como o desenvolvido
nesta dissertação.
Os estudos realizados durante a elaboração deste trabalho permitiram, também, a re-
dação de artigos científicos, submetidos e aceitos para publicação em eventos voltados à
segurança da informação:
• “Reaching De-Perimeterisation through a SAML and Smart-Card based Federated
Identification Mechanism”, submetido ao “The Twelfth International Conference
on Networks - ICN 2013”, Sevilha, Espanha;
• “Overcoming the Risks of the Perimeter-based Security with Strong Federated Iden-
tification Mechanisms - An Analysis applied to the Brazilian Electoral Justice”,
submetido ao “The Fourth International Conference on Technical and Legal As-
pects of the e-Society - CYBERLAWS 2013”, Nice, França;
• “Deperimetrização aplicada à Justiça Eleitoral - Uma abordagem através de certifi-
cados ICP-Brasil e SAML”, submetido ao “10o CertForum - Forum de Certificação
Digital - etapa Florianópolis - 2012”.
As principais contribuições deste trabalho foram:
• Desenvolvimento de uma proposta de mecanismo seguro e eficaz de identifica-
ção federada, utilizando certificados A3 ICP-Brasil e compatível com o protocolo
SAML, preenchendo assim uma das lacunas existentes no modelo de segurança
deperimetrizado;
• Estabelecimento da relação existente entre os temas deperimetrização, identidade
federada e certificação digital;
• Levantamento dos riscos da manutenção do paradigma de segurança baseado em
perímetro e os benefícios da adoção da deperimetrização em ambientes corporati-
vos.
Como trabalhos futuros pretende-se expandir o sítio Deperimetrizacao.com.br, desen-
volvido no decorrer deste trabalho, de modo a torná-lo um local para discussão de assuntos
relacionados à deperimetrização, certificação digital e identificação federada. Pretende-
se também analisar uma metodologia de aplicação da solução proposta em smartphones
e tablets, utilizando as capacidades criptográficas dos SIM-chips. Almeja-se, ainda, es-
tudar, juntamente à administração do TRE-RN, a implantação da solução desenvolvida
em ambiente real da Justiça Eleitoral, propiciando, assim, o início da deperimetrização
daquela rede, em especial o cumprimento das fases ‘1’ e ‘2’ do processo.
Referências Bibliográficas
[Apache 2012a]
Apache (2012a), Apache - Tomcat, Página na internet, The Apache Software
Foundation.
URL: http://tomcat.apache.org
[Apache 2012b]
Apache (2012b), Welcome to the Apache Software Foundation!, Página na internet,
The Apache Software Foundation.
URL: http://www.apache.org
[Callegari 2011]
Callegari, Lucas (2011), Cloud: 49% das empresas no Brasil usam ou estudam
adotar modelo, Boletim técnico, Computer World.
URL: http://computerworld.uol.com.br/tecnologia/2011/09/15/
cloud-49-das-empresas-no-brasil-usam-ou-estudam-adotar-modelo/
[Cellarius 1645]
Cellarius, Andreas (1645), Architectura Militaris, Jodocus Janssonius, Amsterdã.
URL: http://echo.mpiwg-berlin.mpg.de/ECHOdocuView?url=/mpiwg/
online/permanent/library/ZF06GTU1
[Cima 2007]
Cima, Fernando (2007), Deperimetrização e Externalização, Página na internet,
Microsoft Technet / Segurança na Microsoft.
URL: http://blogs.technet.com/fcima/archive/2007/06/09/
deperimetriza-o-e-externaliza-o.aspx
[Correia, Rodrigues & da Costa 2011]
Correia, Hermógenes, Jorilson Rodrigues & Paulo Maia da Costa (2011), e-PING -
Padrões de Interoperabilidade de Governo Eletrônico, Comitê Executivo de
Governo Eletrônico.
69
70 REFERÊNCIAS BIBLIOGRÁFICAS
[Cummings 2004]
Cummings, Joanne (2004), Security in a world without borders, Página na internet,
Network World.
URL:
http://www.networkworld.com/buzz/2004/092704perimeter.html
[de Barros 2009]
de Barros, Augusto Quadros Paes (2009), Deperimeterization without endpoint
control?, Página na internet, Security Balance.
URL: http://www.securitybalance.com/2009/01/
deperimeterization-without-endpoint-control
[Eclipse 2012]
Eclipse (2012), Eclipse - The Eclipse Foundation open source community website,
Página na internet, The Eclipse Foundation.
URL: http://www.eclipse.org
[Elias 2007]
Elias, Wagner (2007), Deperimetrização e Externalização, será?, Página na
internet, Think Security First.
URL: http://wagnerelias.com/2007/06/17/
deperimetrizacao-e-externalizacao-sera
[Farber 2004]
Farber, Dan (2004), Deperimeterization, Página na internet, Between the
Lines/ZDNet.
URL: http://blogs.zdnet.com/BTL/?p=68
[ForgeRock 2012]
ForgeRock (2012), OpenAM - ForgeRock, Página na internet.
URL:
https://wiki.shibboleth.net/confluence/display/OpenSAML/Home
[Fritsch 2008]
Fritsch, Jörg (2008), ‘No Borders - De-perimeterization and life after the firewall’,
Linux Magazine 89(1), 60–63.
[Garfinkel 2005]
Garfinkel, Simson (2005), The Deperimeter Problem, Página na internet, CSO
Online.
URL: http:
//www.csoonline.com/article/220675/The_Deperimeter_Problem
REFERÊNCIAS BIBLIOGRÁFICAS 71
[Guimarães 2006]
Guimarães, Rudnei Santos (2006), Análise comparativa de sistemas de
autenticação utilizados em Internetbanking, Dissertação de mestrado, Instituto de
Pesquisas Tecnológicas do Estado de São Paulo, São Paulo, SP.
[HSW 2011]
HSW (2011), How Stuff Works - O declínio dos castelos, Boletim técnico, HSW
International, Inc.
URL: http://pessoas.hsw.uol.com.br/castelo7.htm
[InfoSegura 2008]
InfoSegura (2008), Deperimetrização, Página na internet, Informação Segura.
URL:
http://infosegura.wordpress.com/2008/10/22/deperimetrizacao
[Internet2 2012]
Internet2 (2012), TestShib Two, Página na internet, Internet2.
URL: https://www.testshib.org
[ITI 2012]
ITI (2012), ICP-Brasil, Página na internet, Instituto Nacional de Tecnologia da
Informação.
URL: http://www.iti.gov.br/icp-brasil
[Jeffree, Congdon & Seaman 2010]
Jeffree, Tony, Paul Congdon & Mick Seaman (2010), 802.1X - Port-Based Network
Access Control, IEEE-SA Standards Board, 3 Park Avenue, New York, NY
10016-5997, USA.
[JerichoForum 2007]
JerichoForum (2007), Jericho Forum Commandments, Version 1.2, Jericho forum
commandments, Jericho Forum.
URL: http://www.jerichoforum.org/
[JerichoForum 2009]
JerichoForum (2009), Jericho Forum’s homepage, Página na internet, The Open
Group.
URL: http://www.opengroup.org/jericho
72 REFERÊNCIAS BIBLIOGRÁFICAS
[Morken 2012]
Morken, Olav (2012), SAML tracer :: complementos para o Firefox, Página na
internet.
URL:
https://addons.mozilla.org/pt-BR/firefox/addon/saml-tracer
[NoIP 2012]
NoIP (2012), Free Dynamic DNS, Página na internet, No-IP.com.
URL: http://www.no-ip.com
[OMG 2011]
OMG (2011), OMG Unified Modeling Language - TM (OMG UML),
Superstructure - Version 2.4.1, Object Management Group, Needham, EUA.
[OneLinea 2010]
OneLinea (2010), O que é um firewall?, Boletim técnico, One Linea Telecom.
URL: http://www.onelinea.com.br/pdfs/bto-firewall.pdf
[OpenVPN 2012]
OpenVPN (2012), OpenVPN - Open Source VPN, Página na internet, OpenVPN
Technologies, Inc.
URL: http://openvpn.net
[OrangeBusiness 2008]
OrangeBusiness (2008), ’deperimeterization’ demands new approach to security,
Página na internet, Orange Business / Industry Watch.
URL: http://www.orange-business.com/en/mnc2/footer/news/
enterprise_briefing/december2008/industry_watch.html
[Ragouzis, Hughes, Philpott, Maler, Lockhart, Wisniewski, Cantor & Mishra 2008]
Ragouzis, Nick, John Hughes, Rob Philpott, Eve Maler, Hal Lockhart, Thomas
Wisniewski, Scott Cantor & Prateek Mishra (2008), Security Assertion Markup
Language (SAML) V2.0 Technical Overview, OASIS Committee Draft.
[Richardson 2008]
Richardson, Robert (2008), ‘CSI Computer Crime and Security Survey’, CSI
Computer Crime and Security Survey 13(1).
[Seabra 2009]
Seabra, Eduardo Manuel Moreira (2009), Gestão de Identidades e privacidade em
redes de próxima geração, Dissertação de mestrado, Universidade de Aveiro,
Aveiro, PT.
REFERÊNCIAS BIBLIOGRÁFICAS 73
[SearchSecurity 2007]
SearchSecurity (2007), What is deperimeterization?, Página na internet, Search
Security.
URL: http://searchsecurity.techtarget.com/sDefinition/0,
,sid14_gci1022899,00
[Shibboleth 2012]
Shibboleth (2012), Home - OpenSAML 2.x - Confluence, Página na internet,
Shibboleth Consortium.
URL:
https://wiki.shibboleth.net/confluence/display/OpenSAML/Home
[Simmonds & Seccombe 2009]
Simmonds, Paul & Adrian Seccombe (2009), Jericho forum - report back, Boletim
técnico, Jericho Forum.
URL: https:
//collaboration.opengroup.org/jericho/Webinar_Dec09_d4.pdf
[Souza 2012]
Souza, Wellington (2012), Deperimetrizacao.com.br, Página na internet.
URL: http://www.deperimetrizacao.com.br
[Stephan & Vogel 2011]
Stephan, Benjamin & Lutz Vogel (2011), Trusted Computing, Animação,
LAFKON Publishing.
URL: http://www.lafkon.net/tc
[TST 2012]
TST (2012), ‘Resolução Administrativa no 1499, de 1o de fevereiro de 2012 -
Regulamenta o teletrabalho no âmbito do Tribunal Superior do Trabalho e dá outras
providências’.
[Unicamp 2002]
Unicamp (2002), Avaliação do Sistema Informatizado de Eleições, Boletim
técnico, Unicamp.
[UNINETT 2012]
UNINETT (2012), SimpleSAMLphp, Página na internet.
URL: http://simplesamlphp.org
74 REFERÊNCIAS BIBLIOGRÁFICAS
[Wangham, de Mello, da Silva Böger, Guerios & da Silva Fraga 2010]
Wangham, Michelle S., Emerson Ribeiro de Mello, Davi da Silva Böger, Marlon
Guerios & Joni da Silva Fraga (2010), Gerenciamento de Identidades Federadas,
Univali.
[Werthein 2000]
Werthein, Jorge (2000), A sociedade da informação e seus desafios, Ci. Inf.,
Brasília.
[Zeilenga 2006]
Zeilenga, Kurt (2006), ‘Lightweight Directory Access Protocol (LDAP): Technical
Specification Road Map’, Internet RFC 4510, ISSN 2070-1721 .
URL: http://tools.ietf.org/html/rfc4510
Apêndice A
Exemplos de elementos SAML
76 APÊNDICE A. EXEMPLOS DE ELEMENTOS SAML
A.1 AuthnRequest
1 <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
2 xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
3 ID="_a91e3502138fe773b8a33312a73898a7eb1d33c4a8"
4 Version="2.0"
5 IssueInstant="2013-01-11T13:13:00Z"
6 Destination="http://idp.deperimetrizacao.com.br:8080/icpsaml/IdP"
7 AssertionConsumerServiceURL="http://www.deperimetrizacao.com.br/
simplesaml/module.php/saml/sp/saml2-acs.php/default-sp"
8 ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
9 >
10 <saml:Issuer>http://www.deperimetrizacao.com.br/simplesaml/module.php/saml/sp/
metadata.php/default-sp</saml:Issuer>
11 <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
12 AllowCreate="true"
13 />
14 </samlp:AuthnRequest>
A.2 Response
1 <saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
2 Destination="http://www.deperimetrizacao.com.br/simplesaml/module.php/saml/
sp/saml2-acs.php/default-sp"
3 ID="_e0a65256fd38e726b05f5f16d6885b1a"
4 InResponseTo="_a91e3502138fe773b8a33312a73898a7eb1d33c4a8"
5 IssueInstant="2013-01-11T13:19:26.206Z"
6 Version="2.0"
7 >
8 <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">idp.
deperimetrizacao.com.br</saml2:Issuer>
9 <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
10 <ds:SignedInfo>
11 <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"
/>
12 <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
13 <ds:Reference URI="#_e0a65256fd38e726b05f5f16d6885b1a">
14 <ds:Transforms>
15 <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-
signature" />
16 <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
17 </ds:Transforms>
18 <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
19 <ds:DigestValue>sJKOrRfThgCjQG+D9u9unUsdkc0=</ds:DigestValue>
20 </ds:Reference>
21 </ds:SignedInfo>
22 <ds:SignatureValue>
23 SDuVNv/KVxUVTyblqlTjXCMNjgnkd58FynpqFdsSAYADCuZB5rg5kJr7QFUNHfFyHFCAY/YjFy1Q
24 UPeBoinv+qpk64d82XKviUVFTpm7SZCj6w8Gl3VNT0iOtZYX1vl5nbnE7yVYDZy51o6auMz2uaru
25 rQiZTKf2I72JvAypxliLs9BFY/lC/lKFCLQIHJxwU2s9NCXm09rvOUV3zyHtVYA1wdSUc9lFt9KX
26 A1W65J7RVj09mToiQn6EZBr37n0Ib1R9AxD6nod8ZZ4N+X93Ozb4iPzbwYqDX5NJL3UYPtAy3NrJ
27 qS4t59/mkIIxaxUNAn+C2yTtnIoleTTwc6WSeQ==
28 </ds:SignatureValue>
29 <ds:KeyInfo>
30 <ds:X509Data>
31 <ds:X509Certificate>
32 MIIFGTCCBAGgAwIBAgIBATANBgkqhkiG9w0BAQUFADCBmjELMAkGA1UEBhMCQlIxCzAJBgNVBAgT
33 AlJOMQ4wDAYDVQQHEwVOYXRhbDEgMB4GA1UEChMXZGVwZXJpbWV0cml6YWNhby5jb20uYnIxLjAs
34 BgkqhkiG9w0BCQEWH2NvbnRhdG9AZGVwZXJpbWV0cml6YWNhby5jb20uYnIxHDAaBgNVBAMTE2Rl
35 cGVyaW1ldHJpemFjYW8tY2EwHhcNMTMwMTAxMTcyNjQyWhcNMjIxMjMwMTcyNjQyWjCBnjELMAkG
36 A1UEBhMCQlIxCzAJBgNVBAgTAlJOMQ4wDAYDVQQHEwVOYXRhbDEcMBoGA1UEChMTRGVwZXJpbWV0
37 cml6YWNhbyBCUjEuMCwGCSqGSIb3DQEJARYfY29udGF0b0BkZXBlcmltZXRyaXphY2FvLmNvbS5i
A.2. RESPONSE 77
38 cjEkMCIGA1UEAxMbaWRwLmRlcGVyaW1ldHJpemFjYW8uY29tLmJyMIIBIjANBgkqhkiG9w0BAQEF
39 AAOCAQ8AMIIBCgKCAQEA3riBwLJbdS2+gggV7khUEAWGDQWCWOo781mtdMkO5ktYYqMgQN2VOjIo
40 odkhhpVlPcTEc4zo1qRVOVrGbwr45jIBY9l7yh2l4rHJY7AR/Sp8j05prsOMYfvXZ5ftevUZ1rSn
41 zHm7xArNrw1hgPvBsYPVFSPlVR2wMjhDFtSsOx+cxTPvGXjyc8eAAX1R9qnb7Cl0Hjs0KuuX6c32
42 KCF9nhbmNvtM4fGfn2eRFu1IwuOUdwBW8yes4x5Ll24u9eHZDYPwkyFIcqCdtxmM8UJNg2NM9QGh
43 I1g7CiL9I61PNfQ+oVIWVRRDyFaj+0KRmnx2h7nihz3U+N+gVzprXCjsjwIDAQABo4IBYjCCAV4w
44 CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBkAwMwYJYIZIAYb4QgENBCYWJE9wZW5TU0wgR2Vu
45 ZXJhdGVkIFNlcnZlciBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUcCfMdi06dT6b+qwwda8GOYfei60w
46 gccGA1UdIwSBvzCBvIAUgx49+I9dQwtxATNKXvlbno6AweehgaCkgZ0wgZoxCzAJBgNVBAYTAkJS
47 MQswCQYDVQQIEwJSTjEOMAwGA1UEBxMFTmF0YWwxIDAeBgNVBAoTF2RlcGVyaW1ldHJpemFjYW8u
48 Y29tLmJyMS4wLAYJKoZIhvcNAQkBFh9jb250YXRvQGRlcGVyaW1ldHJpemFjYW8uY29tLmJyMRww
49 GgYDVQQDExNkZXBlcmltZXRyaXphY2FvLWNhggEAMBMGA1UdJQQMMAoGCCsGAQUFBwMBMAsGA1Ud
50 DwQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAQEAdWkGK1QSXg7QgHjJxS8yL4qID5fZKrZ5EriTSoNc
51 DRLLV2wSMujSHO88XXmvLb/4MUcpJfpjUo57XjfHSQ7S9bcy0t8AI2MKp/EKtH+IWf6XRiUacqDr
52 eyZ5yGAMFosmPMlrWdpm4fARzvCdAZMxHHG4Mm+z/qzJkep8ttqVsiKCIcBlx33u1CR8J9iMoxlO
53 hA/ilkuM5J5ivUivlj5twE/OmYdn4OQBkyFFzobTqgibBkBKbfBlKbfdcFGvWDHCI5Y+cfCCVwK1
54 FIWrNi2OxQX/YWwQVBPh5lGHlVNzlfAu5cZbPzR96SPiTFqHM92eKSEW+mk1Rqz2nJC7QM3PDA==
55 </ds:X509Certificate>
56 </ds:X509Data>
57 </ds:KeyInfo>
58 </ds:Signature>
59 <saml2p:Status>
60 <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
61 </saml2p:Status>
62 <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
63 ID="_44273747999120ff71c1100024fef430"
64 IssueInstant="2013-01-11T13:19:26.206Z"
65 Version="2.0"
66 >
67 <saml2:Issuer>idp.deperimetrizacao.com.br</saml2:Issuer>
68 <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
69 <ds:SignedInfo>
70 <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n
#" />
71 <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /
>
72 <ds:Reference URI="#_44273747999120ff71c1100024fef430">
73 <ds:Transforms>
74 <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-
signature" />
75 <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
76 </ds:Transforms>
77 <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
78 <ds:DigestValue>H0dMSwLhO7E+MzRxiP9Osf8YpJ8=</ds:DigestValue>
79 </ds:Reference>
80 </ds:SignedInfo>
81 <ds:SignatureValue>
82 IZux+eNpYtFCxDkGp4iwr90ejt/mPTdeOZJ8DRkrY5+Ie6kCthQPkCeMOgNRtRLxmahg+hZk9dQ4
83 fODttjKv9J4HfFdbra2kzHuKHuWsK25kVP67lOH6pD/xo7GkGMbjbmYQdNSMujr5CLyFwAGtYuIa
84 dJspZ4rBDxTIrMnQe2Vp8qglw/+tQI2ADXj6d/1powosgWjMJzSiOkbo2Npgc+Or4/8J3lnKD1Ha
85 yo8l/cW/DKX0cy19HfC7GQiCxrbm6eDL94MJLpPpmvmwYnlKEOaskCaouwuA7kIkkhFZj4npHO9+
86 DO5pbsd1Xqy9vyntP8UwTG0jLtZoOsmNMOdDiQ==
87 </ds:SignatureValue>
88 <ds:KeyInfo>
89 <ds:X509Data>
90 <ds:X509Certificate>
91 MIIFGTCCBAGgAwIBAgIBATANBgkqhkiG9w0BAQUFADCBmjELMAkGA1UEBhMCQlIxCzAJBgNVBAgT
92 AlJOMQ4wDAYDVQQHEwVOYXRhbDEgMB4GA1UEChMXZGVwZXJpbWV0cml6YWNhby5jb20uYnIxLjAs
93 BgkqhkiG9w0BCQEWH2NvbnRhdG9AZGVwZXJpbWV0cml6YWNhby5jb20uYnIxHDAaBgNVBAMTE2Rl
94 cGVyaW1ldHJpemFjYW8tY2EwHhcNMTMwMTAxMTcyNjQyWhcNMjIxMjMwMTcyNjQyWjCBnjELMAkG
95 A1UEBhMCQlIxCzAJBgNVBAgTAlJOMQ4wDAYDVQQHEwVOYXRhbDEcMBoGA1UEChMTRGVwZXJpbWV0
96 cml6YWNhbyBCUjEuMCwGCSqGSIb3DQEJARYfY29udGF0b0BkZXBlcmltZXRyaXphY2FvLmNvbS5i
97 cjEkMCIGA1UEAxMbaWRwLmRlcGVyaW1ldHJpemFjYW8uY29tLmJyMIIBIjANBgkqhkiG9w0BAQEF
98 AAOCAQ8AMIIBCgKCAQEA3riBwLJbdS2+gggV7khUEAWGDQWCWOo781mtdMkO5ktYYqMgQN2VOjIo
99 odkhhpVlPcTEc4zo1qRVOVrGbwr45jIBY9l7yh2l4rHJY7AR/Sp8j05prsOMYfvXZ5ftevUZ1rSn
100 zHm7xArNrw1hgPvBsYPVFSPlVR2wMjhDFtSsOx+cxTPvGXjyc8eAAX1R9qnb7Cl0Hjs0KuuX6c32
101 KCF9nhbmNvtM4fGfn2eRFu1IwuOUdwBW8yes4x5Ll24u9eHZDYPwkyFIcqCdtxmM8UJNg2NM9QGh
78 APÊNDICE A. EXEMPLOS DE ELEMENTOS SAML
102 I1g7CiL9I61PNfQ+oVIWVRRDyFaj+0KRmnx2h7nihz3U+N+gVzprXCjsjwIDAQABo4IBYjCCAV4w
103 CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBkAwMwYJYIZIAYb4QgENBCYWJE9wZW5TU0wgR2Vu
104 ZXJhdGVkIFNlcnZlciBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUcCfMdi06dT6b+qwwda8GOYfei60w
105 gccGA1UdIwSBvzCBvIAUgx49+I9dQwtxATNKXvlbno6AweehgaCkgZ0wgZoxCzAJBgNVBAYTAkJS
106 MQswCQYDVQQIEwJSTjEOMAwGA1UEBxMFTmF0YWwxIDAeBgNVBAoTF2RlcGVyaW1ldHJpemFjYW8u
107 Y29tLmJyMS4wLAYJKoZIhvcNAQkBFh9jb250YXRvQGRlcGVyaW1ldHJpemFjYW8uY29tLmJyMRww
108 GgYDVQQDExNkZXBlcmltZXRyaXphY2FvLWNhggEAMBMGA1UdJQQMMAoGCCsGAQUFBwMBMAsGA1Ud
109 DwQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAQEAdWkGK1QSXg7QgHjJxS8yL4qID5fZKrZ5EriTSoNc
110 DRLLV2wSMujSHO88XXmvLb/4MUcpJfpjUo57XjfHSQ7S9bcy0t8AI2MKp/EKtH+IWf6XRiUacqDr
111 eyZ5yGAMFosmPMlrWdpm4fARzvCdAZMxHHG4Mm+z/qzJkep8ttqVsiKCIcBlx33u1CR8J9iMoxlO
112 hA/ilkuM5J5ivUivlj5twE/OmYdn4OQBkyFFzobTqgibBkBKbfBlKbfdcFGvWDHCI5Y+cfCCVwK1
113 FIWrNi2OxQX/YWwQVBPh5lGHlVNzlfAu5cZbPzR96SPiTFqHM92eKSEW+mk1Rqz2nJC7QM3PDA==
114 </ds:X509Certificate>
115 </ds:X509Data>
116 </ds:KeyInfo>
117 </ds:Signature>
118 <saml2:Subject>
119 <saml2:NameID Format="urn:icmpsaml:deperimetrizacao.com.br:services:br.com.
deperimetrizacao.www"
120 SPNameQualifier="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
121 >Wellington</saml2:NameID>
122 <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
123 <saml2:SubjectConfirmationData InResponseTo="
_a91e3502138fe773b8a33312a73898a7eb1d33c4a8"
124 NotOnOrAfter="2013-01-11T19:19:26.206Z"
125 Recipient="http://www.deperimetrizacao.com.br/
simplesaml/module.php/saml/sp/saml2-acs.php/
default-sp"
126 />
127 </saml2:SubjectConfirmation>
128 </saml2:Subject>
129 <saml2:Conditions NotBefore="2013-01-11T13:19:26.206Z"
130 NotOnOrAfter="2013-01-11T19:19:26.206Z"
131 >
132 <saml2:AudienceRestriction>
133 <saml2:Audience>http://www.deperimetrizacao.com.br/simplesaml/module.php/
saml/sp/metadata.php/default-sp</saml2:Audience>
134 </saml2:AudienceRestriction>
135 </saml2:Conditions>
136 <saml2:AuthnStatement AuthnInstant="2013-01-11T13:19:26.206Z"
137 SessionIndex="_c7f979be6635f0de84f2b1c2589822f3"
138 >
139 <saml2:AuthnContext>
140 <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:
SmartcardPKI</saml2:AuthnContextClassRef>
141 </saml2:AuthnContext>
142 </saml2:AuthnStatement>
143 <saml2:AttributeStatement>
144 <saml2:Attribute Name="TE_UF">
145 <saml2:AttributeValue>XX</saml2:AttributeValue>
146 </saml2:Attribute>
147 <saml2:Attribute Name="MSAD_UPN">
148 <saml2:AttributeValue>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</saml2:AttributeValue>
149 </saml2:Attribute>
150 <saml2:Attribute Name="TE">
151 <saml2:AttributeValue>XXXXXXXXXXXX</saml2:AttributeValue>
152 </saml2:Attribute>
153 <saml2:Attribute Name="RG">
154 <saml2:AttributeValue>XXXXXXX</saml2:AttributeValue>
155 </saml2:Attribute>
156 <saml2:Attribute Name="RG_UF">
157 <saml2:AttributeValue>XX</saml2:AttributeValue>
158 </saml2:Attribute>
159 <saml2:Attribute Name="DT_NASCIMENTO">
160 <saml2:AttributeValue>XXXXXXXX</saml2:AttributeValue>
161 </saml2:Attribute>
162 <saml2:Attribute Name="CPF">
A.3. METADADOS DO IDP 79
163 <saml2:AttributeValue>XXXXXXXXXXX</saml2:AttributeValue>
164 </saml2:Attribute>
165 <saml2:Attribute Name="TE_SECAO">
166 <saml2:AttributeValue>XXXX</saml2:AttributeValue>
167 </saml2:Attribute>
168 <saml2:Attribute Name="TE_CIDADE">
169 <saml2:AttributeValue>XXXXXXXXXX</saml2:AttributeValue>
170 </saml2:Attribute>
171 <saml2:Attribute Name="CEI">
172 <saml2:AttributeValue>XXXXXXXXXXXX</saml2:AttributeValue>
173 </saml2:Attribute>
174 <saml2:Attribute Name="TE_ZE">
175 <saml2:AttributeValue>XXX</saml2:AttributeValue>
176 </saml2:Attribute>
177 <saml2:Attribute Name="RG_EXPEDIDOR">
178 <saml2:AttributeValue>XXX</saml2:AttributeValue>
179 </saml2:Attribute>
180 <saml2:Attribute Name="NIS">
181 <saml2:AttributeValue>XXXXXXXXXXX</saml2:AttributeValue>
182 </saml2:Attribute>
183 </saml2:AttributeStatement>
184 </saml2:Assertion>
185 </saml2p:Response>
A.3 Metadados do IdP
1 <?xml version="1.0" encoding="UTF-8" standalone="no"?><md:EntityDescriptor xmlns:md="urn
:oasis:names:tc:SAML:2.0:metadata" entityID="idp.deperimetrizacao.com.br"><md:
IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:
oasis:names:tc:SAML:2.0:protocol"><md:KeyDescriptor use="encryption"><ds:KeyInfo
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><ds:X509Certificate>
2 MIIFGTCCBAGgAwIBAgIBATANBgkqhkiG9w0BAQUFADCBmjELMAkGA1UEBhMCQlIxCzAJBgNVBAgT
3 AlJOMQ4wDAYDVQQHEwVOYXRhbDEgMB4GA1UEChMXZGVwZXJpbWV0cml6YWNhby5jb20uYnIxLjAs
4 BgkqhkiG9w0BCQEWH2NvbnRhdG9AZGVwZXJpbWV0cml6YWNhby5jb20uYnIxHDAaBgNVBAMTE2Rl
5 cGVyaW1ldHJpemFjYW8tY2EwHhcNMTMwMTAxMTcyNjQyWhcNMjIxMjMwMTcyNjQyWjCBnjELMAkG
6 A1UEBhMCQlIxCzAJBgNVBAgTAlJOMQ4wDAYDVQQHEwVOYXRhbDEcMBoGA1UEChMTRGVwZXJpbWV0
7 cml6YWNhbyBCUjEuMCwGCSqGSIb3DQEJARYfY29udGF0b0BkZXBlcmltZXRyaXphY2FvLmNvbS5i
8 cjEkMCIGA1UEAxMbaWRwLmRlcGVyaW1ldHJpemFjYW8uY29tLmJyMIIBIjANBgkqhkiG9w0BAQEF
9 AAOCAQ8AMIIBCgKCAQEA3riBwLJbdS2+gggV7khUEAWGDQWCWOo781mtdMkO5ktYYqMgQN2VOjIo
10 odkhhpVlPcTEc4zo1qRVOVrGbwr45jIBY9l7yh2l4rHJY7AR/Sp8j05prsOMYfvXZ5ftevUZ1rSn
11 zHm7xArNrw1hgPvBsYPVFSPlVR2wMjhDFtSsOx+cxTPvGXjyc8eAAX1R9qnb7Cl0Hjs0KuuX6c32
12 KCF9nhbmNvtM4fGfn2eRFu1IwuOUdwBW8yes4x5Ll24u9eHZDYPwkyFIcqCdtxmM8UJNg2NM9QGh
13 I1g7CiL9I61PNfQ+oVIWVRRDyFaj+0KRmnx2h7nihz3U+N+gVzprXCjsjwIDAQABo4IBYjCCAV4w
14 CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBkAwMwYJYIZIAYb4QgENBCYWJE9wZW5TU0wgR2Vu
15 ZXJhdGVkIFNlcnZlciBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUcCfMdi06dT6b+qwwda8GOYfei60w
16 gccGA1UdIwSBvzCBvIAUgx49+I9dQwtxATNKXvlbno6AweehgaCkgZ0wgZoxCzAJBgNVBAYTAkJS
17 MQswCQYDVQQIEwJSTjEOMAwGA1UEBxMFTmF0YWwxIDAeBgNVBAoTF2RlcGVyaW1ldHJpemFjYW8u
18 Y29tLmJyMS4wLAYJKoZIhvcNAQkBFh9jb250YXRvQGRlcGVyaW1ldHJpemFjYW8uY29tLmJyMRww
19 GgYDVQQDExNkZXBlcmltZXRyaXphY2FvLWNhggEAMBMGA1UdJQQMMAoGCCsGAQUFBwMBMAsGA1Ud
20 DwQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAQEAdWkGK1QSXg7QgHjJxS8yL4qID5fZKrZ5EriTSoNc
21 DRLLV2wSMujSHO88XXmvLb/4MUcpJfpjUo57XjfHSQ7S9bcy0t8AI2MKp/EKtH+IWf6XRiUacqDr
22 eyZ5yGAMFosmPMlrWdpm4fARzvCdAZMxHHG4Mm+z/qzJkep8ttqVsiKCIcBlx33u1CR8J9iMoxlO
23 hA/ilkuM5J5ivUivlj5twE/OmYdn4OQBkyFFzobTqgibBkBKbfBlKbfdcFGvWDHCI5Y+cfCCVwK1
24 FIWrNi2OxQX/YWwQVBPh5lGHlVNzlfAu5cZbPzR96SPiTFqHM92eKSEW+mk1Rqz2nJC7QM3PDA==
25 </ds:X509Certificate></ds:X509Data></ds:KeyInfo></md:KeyDescriptor><md:KeyDescriptor use
="signing"><ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><
ds:X509Certificate>
26 MIIFGTCCBAGgAwIBAgIBATANBgkqhkiG9w0BAQUFADCBmjELMAkGA1UEBhMCQlIxCzAJBgNVBAgT
27 AlJOMQ4wDAYDVQQHEwVOYXRhbDEgMB4GA1UEChMXZGVwZXJpbWV0cml6YWNhby5jb20uYnIxLjAs
28 BgkqhkiG9w0BCQEWH2NvbnRhdG9AZGVwZXJpbWV0cml6YWNhby5jb20uYnIxHDAaBgNVBAMTE2Rl
29 cGVyaW1ldHJpemFjYW8tY2EwHhcNMTMwMTAxMTcyNjQyWhcNMjIxMjMwMTcyNjQyWjCBnjELMAkG
30 A1UEBhMCQlIxCzAJBgNVBAgTAlJOMQ4wDAYDVQQHEwVOYXRhbDEcMBoGA1UEChMTRGVwZXJpbWV0
31 cml6YWNhbyBCUjEuMCwGCSqGSIb3DQEJARYfY29udGF0b0BkZXBlcmltZXRyaXphY2FvLmNvbS5i
80 APÊNDICE A. EXEMPLOS DE ELEMENTOS SAML
32 cjEkMCIGA1UEAxMbaWRwLmRlcGVyaW1ldHJpemFjYW8uY29tLmJyMIIBIjANBgkqhkiG9w0BAQEF
33 AAOCAQ8AMIIBCgKCAQEA3riBwLJbdS2+gggV7khUEAWGDQWCWOo781mtdMkO5ktYYqMgQN2VOjIo
34 odkhhpVlPcTEc4zo1qRVOVrGbwr45jIBY9l7yh2l4rHJY7AR/Sp8j05prsOMYfvXZ5ftevUZ1rSn
35 zHm7xArNrw1hgPvBsYPVFSPlVR2wMjhDFtSsOx+cxTPvGXjyc8eAAX1R9qnb7Cl0Hjs0KuuX6c32
36 KCF9nhbmNvtM4fGfn2eRFu1IwuOUdwBW8yes4x5Ll24u9eHZDYPwkyFIcqCdtxmM8UJNg2NM9QGh
37 I1g7CiL9I61PNfQ+oVIWVRRDyFaj+0KRmnx2h7nihz3U+N+gVzprXCjsjwIDAQABo4IBYjCCAV4w
38 CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBkAwMwYJYIZIAYb4QgENBCYWJE9wZW5TU0wgR2Vu
39 ZXJhdGVkIFNlcnZlciBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUcCfMdi06dT6b+qwwda8GOYfei60w
40 gccGA1UdIwSBvzCBvIAUgx49+I9dQwtxATNKXvlbno6AweehgaCkgZ0wgZoxCzAJBgNVBAYTAkJS
41 MQswCQYDVQQIEwJSTjEOMAwGA1UEBxMFTmF0YWwxIDAeBgNVBAoTF2RlcGVyaW1ldHJpemFjYW8u
42 Y29tLmJyMS4wLAYJKoZIhvcNAQkBFh9jb250YXRvQGRlcGVyaW1ldHJpemFjYW8uY29tLmJyMRww
43 GgYDVQQDExNkZXBlcmltZXRyaXphY2FvLWNhggEAMBMGA1UdJQQMMAoGCCsGAQUFBwMBMAsGA1Ud
44 DwQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAQEAdWkGK1QSXg7QgHjJxS8yL4qID5fZKrZ5EriTSoNc
45 DRLLV2wSMujSHO88XXmvLb/4MUcpJfpjUo57XjfHSQ7S9bcy0t8AI2MKp/EKtH+IWf6XRiUacqDr
46 eyZ5yGAMFosmPMlrWdpm4fARzvCdAZMxHHG4Mm+z/qzJkep8ttqVsiKCIcBlx33u1CR8J9iMoxlO
47 hA/ilkuM5J5ivUivlj5twE/OmYdn4OQBkyFFzobTqgibBkBKbfBlKbfdcFGvWDHCI5Y+cfCCVwK1
48 FIWrNi2OxQX/YWwQVBPh5lGHlVNzlfAu5cZbPzR96SPiTFqHM92eKSEW+mk1Rqz2nJC7QM3PDA==
49 </ds:X509Certificate></ds:X509Data></ds:KeyInfo></md:KeyDescriptor><md:
SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="http://idp.deperimetrizacao.com.br:8080/icpsaml/SLOService"/><md:
NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><
md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="http://idp.deperimetrizacao.com.br:8080/icpsaml/IdP"/><md:
AssertionIDRequestService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-
Redirect" Location="http://idp.deperimetrizacao.com.br:8080/SSOService"/></md:
IDPSSODescriptor></md:EntityDescriptor>
Apêndice B
Identidade Funcional Digital
Identidade Funcional Digital / Crachá Digital
PROJETO
IDENTIDADE FUNCIONAL DIGITAL / CRACHÁ DIGITAL
Apresentação
Este  projeto  visa  dotar  o  TRE-RN  de  uma  ferramenta  de  identificação  pessoal 
tecnologicamente  segura,  provendo  comodidade  e  segurança  no  acesso  físico  e  lógico  às 
dependências do Tribunal e à rede de computadores e sistemas da Justiça Eleitoral. Tal ferramenta 
se traduz em dois elementos: identidade funcional digital e crachá digital.
Para  alcançar  este  propósito,  a  ferramenta  de  identificação  deve  possuir  versatilidade 
tecnológica  adequada  para  atuação  em duas  frentes:  controle  de acesso  físico e  controle  de 
acesso lógico.
Em termos de acesso físico,  tanto a identidade funcional  digital  como o crachá digital 
deverão contar com interface sem contato, capaz de liberar ou bloquear (conforme previamente 
definido) fechaduras, catracas e portões com a simples aproximação do cartão. Garante-se assim o 
controle e registro de acesso, especialmente a locais críticos (CPD, centrais elétricas e de telefonia, 
etc.)
Para o controle de acesso lógico, as identidades funcionais digitais também serão dotadas 
de interface de contato, equivalente aos cartões bancários modernos. Os chips embarcados nesses 
cartões     representam  o  estado-da-arte  em  termos  de  autenticação  e  assinatura  digital,  
permitindo o armazenamento seguro de certificados digitais do padrão ICP-Brasil, tal qual já é 
feito  nas  identidades  funcionais  da  OAB  e  CRCs.  Tais  certificados  permitirão  ao  TRE-RN 
implementar mecanismos de  logon seguro nas estações de trabalho,  single-sign-on, assinatura 
digital de documentos (PAE, PAE nacional, DJe) e autenticação avançada (Intranet, Webmail, entre 
outros).
Arte: SEP/CGI/SJ
Identidade Funcional Digital / Crachá Digital
Objetivo
O objetivo do projeto é substituir as atuais identidades funcionais dos servidores e crachás 
de identificação de autoridades, advogados e visitantes por cartões inteligentes (smartcards).
Justificativa
O TRE-RN necessita aprimorar os mecanismos de identificação de servidores, autoridades e 
visitantes,  tanto do ponto de vista físico como lógico,  de modo a resguardar a segurança da 
instituição  em seus  diversos  aspectos.  O  controle  de  acesso  eficiente  é  premissa  básica  de 
qualquer plano de segurança institucional.
Benefícios diretos e indiretos
O  maior  benefício  direto  resultante  do  projeto  é  o  aumento  drástico  nos  níveis  de 
segurança  da  informação  e  da  instituição,  contemplando  o  controle  de  acesso  físico  às 
dependências do Tribunal  e controle de acesso lógico à rede de computadores e sistemas da 
Justiça Eleitoral.
Como  benefício  indireto  temos  o  reforço  da  identidade  visual  do  TRE-RN  enquanto 
instituição, estampada nos crachás e identidades funcionais dos servidores. Reforça-se também, 
tanto  em  termos  visuais  como  técnicos,  a  consagrada  imagem  de  segurança,  inovação  e 
modernidade da Justiça Eleitoral.
Considerações ambientais
(fornecidas pela SEP/CGI/SJ)
A escolha do material de base
O policloreto de polivinila ou PVC (do inglês PolyVinyl Chloride) é um termoplástico que em 
sua composição química contém 57% de cloro, derivado da eletrólise do sal comum e 43% de 
etileno (derivado do refino de petróleo). Por meio de uma reação de polimerização, o etileno e o 
cloro convertem-se de monômeros em polímeros de vinil ou simplesmente vinil ou PVC. Existem 
basicamente dois tipos de PVCs: o PVC flexível e o PVC rígido.
A diferença do rígido para o flexível é que este último pode ser encontrado em grande 
variedade de cores e de acabamentos. Ambos admitem impressões serigráficas e de alto relevo e 
por outros meios de impressão por contato e podem ser utilizados na confecção de produtos os 
mais diversos. O PVC rígido é um dos suportes de maior disponibilidade e de uso extenso. Sua 
forma rígida oferece resistência mecânica contra rasgos e cortes e é útil  para a fabricação de 
convites,  carteiras  e  crachás de identificação,  cartões de crédito  e em outros  documentos de 
grande manuseio. Oferece a possibilidade de obter-se cores e acabamentos variados, além de 
praticamente todo e qualquer processo de impressão, molde e corte.
Seu ciclo de vida varia de 2 a 100 anos, dependendo do uso que se faz dele. Ao final do 
ciclo  é  perfeitamente  reciclável,  mesmo após  a  impressão  em cores,  e  permite  a  reciclagem 
mecânica,  química  e  energética.  Portanto,  o  PVC,  ao  final  de  seu  ciclo  de  vida  permite  sua  
recuperação e reinserção em todos os setores industriais em que é utilizado. Seus usos mais  
comuns são embalagens para água mineral, óleos comestíveis, maioneses e sucos, mangueiras, 
Identidade Funcional Digital / Crachá Digital
tubulações  elétricas  e  hidráulicas,  forros  e  pisos,  perfis  de  janelas  e  portas,  embalagens  de 
remédios e brinquedos,  bolsas,  carteiras e crachás,  materiais  escolares,  bolsas para coleta de 
sangue hospitalar, frascos de soro, tubos para transfusão e hemodiálise, material cirúrgico, móveis 
para áreas externas, revestimento de piscinas, perfis de computadores e máquina fotográficas, 
cobertura de paredes, etc.
Atualmente, na reciclagem dos termoplásticos, são três os processos reconhecidos para o 
aproveitamento  desses  resíduos:  reciclagem  química,  mecânica  e  energética.  A  reciclagem 
química, reprocessa plásticos transformando-os em monômeros ou na mistura de hidrocarbonetos 
que servem como matéria-prima para a obtenção de outros produtos. Com a reciclagem química 
recupera-se componentes químicos individuais para a obtenção de novos produtos termoplásticos 
ou para a reutilização como produtos químicos.  A reciclagem mecânica consiste em converter  
descartes de termoplásticos de consumo pós-industrial ou pós-consumo em grânulos que podem 
ser reutilizados na produção de novos produtos como sacos de lixo, solados de sapatos, pisos, 
conduítes, componentes de automóveis, embalagens não-alimentícias, fibras, entre outros. Mas 
para isso é necessário a coleta, a separação de plásticos de mesmo grupo, limpeza e revalorização 
do material  para  destinação à  reciclagem.  Por  fim,  a  reciclagem energética  transforma o  lixo 
urbano  em  energia  elétrica  ou  térmica  que  aproveita  o  alto  poder  calorífico  contidos  nos 
termoplásticos para essa produção, mas não é tecnologia disponível no Brasil1.
Segundo o Plastivida - Instituto Socioambiental dos Plásticos (http://www.plastivida.org), 
foram  reciclados  no  Brasil,  em  2007,  aproximadamente  963.000  toneladas  de  plástico.  Este 
número significa cerca de 19,5% do consumo de resinas termoplásticas e nele se insere o PVC. 
Atualmente, o índice de reciclagem dos termoplásticos pós-consumo no Brasil passou de 15,1% 
em 2010 para 22,3% em 2011, representando um volume de 25.302 toneladas. Portanto, o PVC 
rígido é material viável para a confecção de carteiras e crachás de identificação no âmbito deste 
regional,  pois  agrega  valores  gráficos  como  maneabilidade,  cores,  possibilidade  de  formas  e 
acabamentos diversos, leveza (1,4 g/cm3), resistência a ação de fungos e bactérias, resistência a 
choques,  não  propagação  de  chamas,  baixo  custo  de  impressão  e  portabilidade,  a  valores 
ambientais como alto índice de reciclagem e reaproveitamento total de seus resíduos ao final de 
seu ciclo de vida, além de ser fabricado com baixo consumo de energia. No caso da carteira de 
identificação, o ciclo de vida do produto está condicionado ao seu uso continuado pelo usuário  
que, salvo mudanças de layout e mal conservação devido a desgastes que comprometam sua alta
resistência mecânica, permite seu uso por muito tempo.
Custos
Para o presente projeto estima-se um custo de R$ 25.000,00
Considerações para Termo de Referência
(fornecidas pela SST/CSG/SAO)
Obrigações da Contratada
 1. Fornecer amostra do produto no prazo de 15 dias, contados do recebimento da Nota de 
Empenho.
 2. Fornecer os produtos, no prazo de 30 dias corridos, seguindo as condições e especificações 
1 Para informações sobre a reciclagem térmica visite http://www.wte.org/energy e outras informações sobre o PVC 
visite http://www.institutdopvc.org/public
Identidade Funcional Digital / Crachá Digital
estipuladas em sua proposta, que deverá estar de acordo com este Termo de Referência, a 
contar da aprovação da amostra.
 3. O fornecedor terá o prazo de 30 dias para retirada dos materiais recusados e/ou amostras, 
ao final do qual será dado o destino que a Administração entender adequado;
 4. Manter durante a execução do Contrato todas as condições de habilitação e qualificação 
exigidas na licitação;
 5. Entregar  os  produtos  na  Seção  de  Registros  Funcionais,  situada  na  Praça  André  de 
Albuquerque 534, Cidade Alta, Natal-RN, das 12h às 18h, de segunda à quinta-feira e das 
8h  às  15h  às  sextas-feiras,  sem que  isso  implique  acréscimo  no  preço  constante  da 
proposta; 
 5.1.Caberá à Seção de Registros Funcionais/CP/SGP do TRE/RN receber provisoriamente 
os produtos, no ato da entrega, devendo, no prazo de 05 (cinco) dias úteis:
 a) emitir o recebimento definitivo, atestando a regularidade do fornecimento,  ou
 b) solicitar ao(s) licitante(s) vencedor(es) a substituição dos produtos fornecidos em 
desconformidade com as condições, especificações e quantitativos constantes deste 
projeto básico.
Obrigações do Contratante
 1. Fornecer  à CONTRATADA todas as informações relacionadas ao objeto deste termo de 
referência.
 2. Designar  servidores  (titular  e  substituto)  do  seu  quadro  de  pessoal,  para  exercer  a 
fiscalização dos serviços contratados e atestá-los;
 3. Notificar,  expressamente,  a  CONTRATADA  a  respeito  de  quaisquer  irregularidades 
constatadas na prestação dos serviços;
 4. Efetuar os pagamentos devidos num prazo de até 15(quinze) dias úteis a contar da data de  
recebimento da nota fiscal, o material atenda as especificações deste Termo de Referência.
Wellington Silva de Souza
Técnico Judiciário – SIELE/CE/STI
Outubro/2011