Guia de Interoperabilidade Cartilha Técnica 2015

Ministrio do Planejamento, Oramento e GestoSecretaria de Logstica e Tecnologia da Informao

Departamento de Governo Eletrnicowww.governoeletronico.gov.br

Padres de Interoperabilidade deGoverno Eletrnico

Guia de InteroperabilidadeCartilha Tcnica

Verso 2015

Este documento parte integrante do Guia de Interoperabilidade do Governo Brasileiro, que compreende aCartilha Tcnica de Interoperabilidade e o Manual de Gesto de Interoperabilidade. Este documento foielaborado pelo Ministrio do Planejamento, Oramento e Gesto com a consultoria da Agncia Espanholade Cooperao para o Desenvolvimento (AECID) e da Fundao Instituto para o Fortalecimento dasCapacidades Institucionais (IFCI).

Brasil. Ministrio do Planejamento, Oramento e Gesto Guia de Interoperabilidade: Cartilha Tcnica / Ministrio do Planejamento, Oramento e Gesto. Braslia: MP, 2015. 90 p.; 30 cm.

Documento tcnico do governo brasileiro.

1. Interoperabilidade 2. Governo eletrnico 3.ePING

Guia de Interoperabilidade: Cartilha Tcnica Pgina 2 de 90

Esta obra est licenciada com uma Licena Creative Commons Atribuio-NoComercial-CompartilhaIgual 4.0 Internacional.http://creativecommons.org/licenses/by-nc-sa/4.0/

Presidente da Repblica

Dilma Rousseff

Ministrio do Planejamento, Oramento e Gesto

Miriam Belchior

Secretaria de Logstica e Tecnologia da Informao SLTI

Loreni F. Foresti

Departamento de Governo Eletrnico DGE

Andrea Thalhofer Ricciardi

Coordenao-Geral de Normas e Padres de Governo Eletrnico- CGPGE

Fernanda Hoffmann Lobato

ePING

Coordenador: Andrea Thalhofer Ricciardi

GT 1: Marcus Vincius Paizante

GT 2: Jorilson da Silva Rodrigues

GT 3: Paulo Maia da Costa

GT 4: Carlos Eduardo Arajo Vieira

GT 5: Marcus Vincius da Costa


Equipe de Elaborao

Ana Paula Pessoa Mello - SLTI/MP

Carlos Eduardo Arajo Vieira - SLTI/MP

Hudson Vincius Mesquita SLTI/MP

Roberto Shayer Lyra - SLTI/MP

Agradecimento aos colaboradores

Carlos E. Jimnez Gmez

Cludia do Socorro F. Mesquita

Daniel Viero SENADO

Emerson Magnus de A. Xavier MD/CEX

Gonalo Teixeira Nunes IFCI/AECID

Jlio Csar dos Santos Nunes SRF/MF

Marcello Alexandre Kill SERPRO

Patrycia Barros de L. Klavdianos IFCI/AECID

Rachel Cristina G. M. Domingos STM

Renata Assuno de Farias SEP/PR

Yuri Fontes de Oliveira SLTI/MP

SUMRIO

1 INTRODUO.............................................................................................................................................. 5

1.1.Assuntos no contemplados.................................................................................................................. 5

2.FUNDAMENTOS DE INTEROPERABILIDADE.............................................................................................7

2.1.Introduo.............................................................................................................................................. 7

2.2.Dimenses da Interoperabilidade..........................................................................................................7

2.3.Interoperabilidade e Conformidade........................................................................................................9

3.Especificao Tcnica dos Componentes da ePING...................................................................................11

3.1.Segmentao....................................................................................................................................... 11

3.1.1.Interconexo Segmento 1..........................................................................................................15

3.1.1.1 Especificaes para Aplicao...........................................................................................15

3.1.1.2 Especificaes para Rede/Transporte................................................................................20

3.1.1.3 Especificaes para Enlace/Fsico.....................................................................................21

3.1.2.Segurana Segmento 2.............................................................................................................25

3.1.2.1 Especificaes para Comunicao de dados.....................................................................25

3.1.2.2 Especificaes para Correio Eletrnico..............................................................................27

3.1.2.3 Especificaes para Criptografia........................................................................................28

3.1.2.4 Especificaes para Desenvolvimento de Sistemas...........................................................30

3.1.2.5 Especificaes para Servios de Rede..............................................................................31

3.1.2.6 Especificaes para Redes Sem Fio..................................................................................31

3.1.2.7 Especificaes para Resposta a Incidentes de Segurana da Informao........................32

3.1.3.Meios de Acesso Segmento 3...................................................................................................33

3.1.3.1 Especificaes para Meios de Publicao..........................................................................33

3.1.3.2 Especificaes para TV Digital...........................................................................................37

3.1.4.Organizao e Intercmbio de Informaes Segmento 4..........................................................39

3.1.4.1 Especificaes para Tratamento e Transferncia de Dados..............................................39

3.1.4.2 Especificaes para Vocabulrios e Ontologias.................................................................52

3.1.5.reas de Integrao para Governo Eletrnico Segmento 5.......................................................61

3.1.5.1 Especificaes para Temas Transversais s reas de Atuao de Governo.....................61

3.1.5.2 Especificaes para Web Services.....................................................................................69

4.Ferramentas de apoio interoperabilidade.................................................................................................81

4.1.Catlogo de Interoperabilidade............................................................................................................81

4.2.Padro de Metadados para o Governo Eletrnico (ePMG).................................................................82

4.3.Vocabulrio Controlado de Governo Eletrnico (VCGE).....................................................................85


1 INTRODUO

A Secretaria de Logstica e Tecnologia da Informao SLTI do Ministrio do Planejamento, Oramento e

Gesto tem, entre suas atribuies, a competncia de planejar, coordenar, supervisionar e orientar,

normativamente, as atividades do Sistema de Administrao de Recursos de Tecnologia da Informao

SISP, propondo polticas e diretrizes de Tecnologia da Informao, no mbito da Administrao Pblica

Federal direta, autrquica e fundacional.

A Arquitetura ePING Padres de Interoperabilidade de Governo Eletrnico define um conjunto de

premissas, polticas e especificaes tcnicas que regulamentam sua utilizao, com o objetivo maior de

possibilitar um nvel adequado de interoperabilidade entre os servios disponibilizados pelo governo

eletrnico, tornando-se o marco referencial para as atividades de TIC (Tecnologia da Informao e

Comunicao) no Governo. A SLTI a responsvel pela institucionalizao e pela definio do formato

jurdico da Coordenao da ePING.

O Guia de Interoperabilidade do Governo apresenta orientaes para o desenvolvimento de solues

de TIC aderentes Arquitetura ePING como forma de incentivar a interoperabilidade no Governo Federal e

deste com os demais entes da Federao. Ele organizado em dois volumes: o Manual do Gestor deInteroperabilidade e a Cartilha Tcnica de Interoperabilidade.

O Manual do Gestor de Interoperabilidade tem como pblico-alvo os gestores de TI (Tecnologia daInformao) dos rgos do Governo. Esse documento possui diretrizes de gesto, assim como indicaes

de aes promovidas em nosso pas com o objetivo de propiciar uma gesto de servios governamentais

direcionada interoperabilidade.

A Cartilha Tcnica de Interoperabilidade, por sua vez, tem como pblico-alvo os profissionaistcnicos que atuam na rea de TI. A Cartilha Tcnica apresenta os requisitos tcnicos e indica melhores

usos de tecnologias de mercado, que proporcionam a melhoria da interoperabilidade governamental, sua

melhor qualidade e abrangncia.

1.1. Assuntos no contemplados

A Cartilha Tcnica de Interoperabilidade no pretende guiar os profissionais de TIC no uso de linguagens de

programao e tcnicas computacionais especficas que envolvam o projeto e a construo de sistemas

informatizados. Alm disso, no objetivo deste documento imputar a utilizao de ferramentas de trabalho

ou de realizar a divulgao de solues prontas de TIC que tratam de interoperabilidade. Por isso,

recomenda-se que os leitores possuam conhecimento adequado dos assuntos tratados em cada um dos

captulos deste documento.


importante salientar, tambm, que este documento discorrer somente sobre o uso dos padres

publicados na ePING como Adotado (A) e Recomendado (R). Isso porque os demais padres ou esto emprocesso de substituio (T Em Transio) ou sero tratados em futuras verses deste documento (E Em Estudo).


2. FUNDAMENTOS DE INTEROPERABILIDADE

2.1. Introduo

O documento de referncia da ePING aborda, inicialmente, a importncia da TIC no contexto

governamental, fornecendo as justificativas para se investir em polticas direcionadas interoperabilidade

governamental.

A ePING surge como documento definidor das polticas e padres de interoperabilidade aplicveis, em

um primeiro momento, no Governo Federal, mas de uso livre e irrestrito por outros poderes e esferas da

Administrao Pblica dos Estados e Municpios.

A ePING o marco principal de interoperabilidade do governo brasileiro, e tem como objetivo

estabelecer as condies de interao do Poder Executivo com os demais Poderes e esferas de governo e

com a sociedade em geral. Para tanto, ela organiza o seu contedo em cinco segmentos: (i) Interconexo,

(ii) Segurana, (iii) Meios de Acesso, (iv) Organizao e Intercmbio de Informaes e (v) reas de

Integrao para Governo Eletrnico.

Entretanto, sendo a ePING um documento de referncia, no est entre seus objetivos fornecer

respostas aos questionamentos tcnicos envolvendo a aplicao dos padres tecnolgicos no contexto de

execuo dos projetos e das atividades de rotina dos setores de TIC do Governo. Por isso, tornou-se

necessrio consolidar e aperfeioar as ferramentas de apoio ePING com o objetivo de dar a ela um

carter mais prtico.

Este o enfoque principal deste documento, que recebeu o nome de Cartilha Tcnica deInteroperabilidade por representar bem o seu objetivo e estrutura interna. Trata-se de uma cartilha queprocura utilizar linguagem facilitada para descrever conceitos e aes pertinentes execuo das polticas e

prticas de interoperabilidade definidas na ePING. tambm um documento tcnico, pois embora faa uso

de uma linguagem facilitada que permite a melhor compreenso dos conceitos, no deixa de tratar as

questes tecnolgicas relacionadas ao tema Interoperabilidade no Governo.

2.2. Dimenses da Interoperabilidade

A interoperabilidade pode ser organizada em trs dimenses que se comunicam e se complementam:

organizacional, semntica e tcnica.


A Figura 1 ilustra essas trs dimenses da interoperabilidade:

Figura 1: Dimenses da Interoperabilidade

A interoperabilidade organizacional diz respeito colaborao entre organizaes que desejamtrocar informaes mantendo diferentes estruturas internas e processos de negcios variados. Mesmo

contando com a padronizao de conceitos, as organizaes possuem distintos modelos de operao, ou

processos de trabalho. Isto quer dizer que elas realizam suas atividades em tempos diferentes e de

maneiras diferentes.

Assim, um desafio da interoperabilidade identificar as vantagens de cada interoperao e em que

momentos estas deveriam acontecer. Para isso, as organizaes envolvidas na interoperao precisam

conhecer mutuamente seus processos de trabalho, e isto s possvel se ambas possurem processos

modelados, e ainda mais, se estes modelos estiverem dentro do mesmo padro.

A interoperabilidade semntica a capacidade de dois ou mais sistemas heterogneos e distribudostrabalharem em conjunto, compartilhando as informaes entre eles com entendimento comum de seu

significado (Buranarach, 2004). A interoperabilidade semntica garante que os dados trocados tenham seu

efetivo significado corretamente interpretado dentro do contexto de uma dada transao ou busca de

informao, dentro da cultura, convenes e terminologias adotadas por cada setor ou organizao e,

assim, compartilhados pelas partes envolvidas.

A interoperabilidade tcnica trata da ligao entre sistemas e servios de computao pela utilizaode padres para apresentao, coleta, troca, processamento e transporte de dados. Esses padres podem

abranger hardware, software, protocolos e processos de negcio. Uma vez que foram estabelecidos

vocabulrios comuns, e que foram identificados os motivos e os momentos adequados para interoperar,

preciso haver tambm um padro para fazer isso, ou seja, para tratar o como fazer.


importante, portanto, que as reas de Tecnologia busquem utilizar padres tecnolgicos comuns

para implementar a interoperabilidade. Alguns destes padres so encontrados na arquitetura ePING

Padres de Interoperabilidade de Governo Eletrnico.

2.3. Interoperabilidade e Conformidade

O termo conformidade est associado ideia de qualidade e tem como objetivo avaliar a semelhana ou

correlao entre as coisas. Assim, quando se diz que um produto est em conformidade com um protocolo,

por exemplo, significa afirmar que esse produto prov um determinado nvel de semelhana aos padres

definidos no protocolo.

No que tange prtica de interoperabilidade no governo brasileiro, a conformidade de produtos e

solues tecnolgicas aos padres definidos na ePING condio sine qua non para se desenvolver as

polticas de e-Gov.

Logo, segundo a viso de conformidade da ePING, os padres tecnolgicos a serem aplicados no

governo passam por quatro nveis, a saber: Adotado (A), Recomendado (R), Em Transio (T) e Em Estudo

(E).

Um padro identificado como Adotado (A) na ePING implica em esforos prioritrios, por parte dosetor de TI dos rgos de governo, no sentido de atender recomendao. Esses padres foram, de fato,

homologados em um processo formal e aprovados pela Coordenao da ePING. Seu uso obrigatrio para

os rgos do Poder Executivo do governo brasileiro.

Um padro tido como Recomendado (R) caracteriza-se por atender s polticas tcnicas da ePING,podendo ser utilizado no mbito das instituies de governo. Entretanto, ainda necessria a sua

homologao e aprovao formais. Geralmente, os padres identificados como Recomendados (R) so

oriundos de prticas de interoperabilidade bem sucedidas e de uso comum, mas que carecem da

formalizao por parte dos membros da ePING.

Os padres Em Transio (T) correspondem aos itens que o governo no recomenda, seja porqueno atendem aos requisitos estabelecidos nas polticas gerais e tcnicas da ePING, ou porque se

encontram em processo de substituio nas instituies de governo, tendendo descontinuao de seu uso

no futuro. possvel que um item Em Transio (T) passe a ser considerado Recomendado (R). Isso

porque as dificuldades em se estabelecer polticas viveis para sua substituio justificariam a sua

permanncia. Entretanto, a ePING recomenda enfaticamente evitar-se o uso dos padres Em Transio (T).

Por fim, os padres Em Estudo (E) so aqueles que ainda esto em avaliao por parte dos membrosda ePING e que, por isso, no podem ser classificados em outros nveis de conformidade.


O Guia de Interoperabilidade de Governo, conforme relatado anteriormente, dar nfase aos padres

Adotado (A) e Recomendado (R), por razes bvias de concordncia com as polticas e interessespblicos do governo discutidos durante as reunies de trabalho da ePING.


3. Especificao Tcnica dos Componentes da ePING

3.1. Segmentao

A arquitetura ePING foi segmentada em cinco partes, com a finalidade de organizar as definies dos

padres. Para cada um dos segmentos, foi criado um grupo de trabalho, composto por profissionaisatuantes em rgos dos governos federal, estadual e municipal, especialistas em cada assunto. Esses

grupos foram responsveis pela elaborao desta verso da arquitetura, base para o estabelecimento dos

padres de interoperabilidade do governo brasileiro.

Interconexo Segmento 1: Estabelece as condies para que os rgos de governo se interconectem, alm de fixar as condies de interoperao entre o governo e a sociedade.

Segurana Segmento 2: Trata dos aspectos de segurana de TIC que o governo federal deve considerar.

Meios de Acesso Segmento 3: So explicitadas as questes relativas aos padres dos dispositivos de acesso aos servios de governo eletrnico.

Organizao e Intercmbio de informaes Segmento 4: Aborda os aspectos relativos ao tratamento e transferncia de informaes nos servios de governo eletrnico. Inclui padro de

vocabulrios controlados, taxonomias, ontologias e outros mtodos de organizao e recuperao

de informaes.

reas de Integrao para Governo Eletrnico Segmento 5: Estabelece a utilizao ou construo de especificaes tcnicas para sustentar o intercmbio de informaes em reas

transversais da atuao governamental, cuja padronizao seja relevante para a interoperabilidade

de servios de Governo Eletrnico, tais como Dados e Processos, Informaes Contbeis,

Geogrficas, Estatsticas e de Desempenho, entre outras.

A Tabela 1 descreve os padres no contexto de cada um dos segmentos mencionados, de modo a fazer

referncia aos componentes identificados como Adotados (A) e Recomendados (R) pelo governo brasileiro.

Inclui-se tambm nessa tabela a referncia s sees da ePING onde se podem localizar os padres

citados.


Tabela 1: Padres por segmento na ePING

Segmentos da ePING Componentes da ePING Referncia na ePING

1 Interconexo

Endereos de caixa postal eletrnica

Tabela 1 Aplicao

Transporte de mensagem eletrnicaAcesso caixa postalMensageria em Tempo RealAntiSpam Gerenciamento da Porta 25Protocolo de transferncia de hipertextoProtocolos de transferncia de arquivosDiretrioSincronismo de tempoServios de Nomeao de DomnioProtocolos de sinalizaoProtocolos de gerenciamento de redeTransporte

Tabela 2 Rede/TransporteIntercomunicao LAN/WANComutao por LabelQualidade de ServioRede local sem fio

Tabela 3 Enlace/FsicoQualidade de Servio 802.1pVirtual LANResilincia Layer2

2 Segurana

Transferncia de dados em redes inseguras

Tabela 4 Comunicao dedados

Algoritmos para troca de chaves de sesso, durante o handshakeAlgoritmos para definio de chave de cifraoCertificado DigitalHipertexto e transferncia de arquivosTransferncia de arquivosSegurana de redes IPv4Segurana de redes IPv4 para protocolos de aplicaoSegurana de redes IPv6 na camada de redeAcesso a caixas postais

Tabela 5 Correio Eletrnico

Contedo de e-mailTransporte de e-mailIdentificao de e-mailAssinaturaTransporte seguro de e-mail Algoritmo de cifrao

Tabela 6 Criptografia

Algoritmos para assinatura/hashingAlgoritmo para transporte de chave criptogrfica de contedo/sessoAlgoritmos criptogrficos baseados em curvas elpticasRequisitos de segurana para mdulos criptogrficosCertificado Digital da AC-raiz para Navegadores e Visualizadores de ArquivosAssinaturas XML

Tabela 7 Desenvolvimentode Sistemas

Cifrao XMLAssinatura e cifrao XMLPrincipais gerenciamentos XML quando um ambiente PKI utilizadoAutenticao e autorizao de acesso XML


Intermediao ou Federao de IdentidadesNavegadoresDiretrio

Tabela 8 Servios de RedeDNSSECCarimbo do tempoLAN sem fio 802.11 Tabela 9 Redes sem fioPreservao de registros

Tabela 10 Resposta aIncidentes de Segurana da

Informao

Gerenciamento de incidentes em redes computacionaisInformtica ForenseServios de tecnologia da informao, conforme definidos no art. 11 da Portaria Interministerial MP/MC/MD n 141 de 02/05/2014

Tabela 11 Auditoria em programas e equipamentos

3 Meios de Acesso

Conjunto de caracteres

Tabela 12 Meios dePublicao

Formato de intercmbio de hipertextoMobileArquivos do tipo documentoArquivos do tipo planilhaArquivos do tipo apresentaoArquivos do tipo banco de dados para estaes de trabalhoIntercmbio de informaes grficas e imagensestticasGrficos vetoriaisAnimaoudioVdeoCompactao de arquivosInformaes georreferenciadasTransmisso

Tabela 13 TV Digital

CodificaoMultiplexaoReceptoresSeguranaMiddlewareCanal de InteratividadeGuia de OperaesAcessibilidade

4 Organizao eIntercmbio de

informaes

Linguagem para intercmbio de dados

Tabela 14 Tratamento etransferncia de Dados

Transformao de dados

Definio dos dados para intercmbioInformaes georreferenciadas catlogo de feiesDescrio de recursos

Tabela 15 Vocabulrios eOntologias

Especificao de vocabulrios para RDF

Sistemas de Organizao do Conhecimento

Linguagem de definio de ontologias na web


5 reas de Integrao paraGoverno Eletrnico

Linguagem para Execuo de Processos

Tabela 16 Temas Transversais

Notao de Modelagem de Processos

Intercmbio de Informaes Financeiras

Legislao, Jurisprudncia e Proposies Legislativas

Integrao de Dados e Processos

Interoperabilidade entre sistemas de informao geogrfica

Infraestrutura de registro

Tabela 17 Web ServicesLinguagem de definio do servio

Protocolo para acesso a Web Service


3.1.1. Interconexo Segmento 1

3.1.1.1 Especificaes para Aplicao

Tabela 2: Aplicao

Componente Especificao Situao

Endereos de caixa postal eletrnica Padro de Formao de Endereos deCorreio Eletrnico - Caixas Postais Individuais A

Transporte de mensagem eletrnica Produtos que suportem interfaces em conformidade com SMTP/MIME A

Acesso caixa postal Internet Message Access Protocol IMAP para acesso remoto caixa postal A

Mensageria em Tempo Real Programas de correio eletrnico em conformidade com XMPP A

AntiSpam Gerenciamento da Porta 25

Implementar submisso de e-mail via porta 587/TCP com autenticao, reservando a porta 25/TCP apenas para transporte entre servidores SMTP, conforme recomendao CGI / Cert.br http://www.cert.br/

R

Protocolo de transferncia de hipertexto Utilizar HTTP/1.1 A

Protocolos de transferncia de arquivos FTP (com reinicializao e recuperao) e HTTP A

Diretrio LDAP v3 A

Sincronismo de tempo RFC 5905 IETF Network Time Protocol NTPverso 4.0. A

Servios de Nomeao de Domnio DNS. RFC 1035 AProtocolos de sinalizao Protocolo de Inicializao de Sesso (SIP) AProtocolos de gerenciamento de rede SNMP v3 R

Os nomes das caixas postais de correio eletrnico devem seguir os padres estabelecidos no

documento Padro de Formao de Endereos de Correio Eletrnico, disponvel no endereo

http://www.eping.e.gov.br. Esse documento estabelece regras para a formao de nomes e composio de

endereos eletrnicos (e-mail) e tm como base de referncia, padres internacionais definidos pela ITU

(International Telecommunications Union).

O protocolo SMTP (Simple Mail Transfer Protocol) deve ser utilizado por servidores de correio

eletrnico e aplicativos de transferncia de mensageria para enviar e receber mensagens, enquanto que os

aplicativos diretamente acionados pelos usurios finais devem utilizar esse protocolo apenas para enviar as

mensagens ao servidor a que estejam diretamente conectados, que ento assume a tarefa de dar

prosseguimento ao trfego dessas mensagens, para que cheguem a seu destino final.

Para receber mensagens, os aplicativos de usurios finais devem usar o protocolo IMAP (Internet

Message Access Protocol), que apresenta inmeras vantagens quando comparado ao protocolo POP3

(Post Office Protocol V. 3), no momento declarado em desuso. Aqui vale lembrar que a ePING restringe a

utilizao de tecnologias proprietrias para acesso s caixas postais de um servidor de correio eletrnico,

embora no vede a utilizao de sistemas proprietrios para esse fim.


Para mensagens instantneas, deve-se utilizar o protocolo XMPP (Extensible Messaging and Presence

Protocol), em substituio ao protocolo IMPP (Instant Messaging and Presence Protocol), hoje em

obsolescncia.

A regulamentao para a troca de mensagens curtas, SMS (Short Message Service), que contenham

no mais que 160 caracteres de competncia da ANATEL (Agncia Nacional de Telecomunicaes),

cabendo ePING fomentar servios governamentais prestados ao cidado utilizando essa tecnologia, hoje

amplamente suportada pelo mercado, e acessvel grande maioria da populao.

A gerncia de porta 25 o nome dado ao conjunto de polticas e tecnologias, implantadas em redes de

usurios finais ou de carter residencial, que procura separar as funcionalidades de submisso de

mensagens, daquelas de transporte de mensagens entre servidores.

A definio do padro para o protocolo de submisso de 1998, sendo sua ltima reviso de 2011, no

documento "RFC 6409: Message Submission for Mail". Este protocolo, chamado de "MessageSubmission", fornece um meio para distinguir uma submisso do transporte de mensagens, permitindo

assim:

a aplicao de polticas diferentes para cada tipo de conexo, impedindo relays no autorizados ou

introduo de e-mails no solicitados;

a implementao de autenticao na submisso, incluindo aquela realizada remotamente por

usurios autorizados;

a possibilidade de implementar, futuramente, melhorias no servio de submisso.

A adoo do protocolo de Message Submission uma boa prtica reforada na RFC 5068 / BCP134: Email Submission Operations: Access and Accountability Requirements e que tem sidorecomendada por diversos fruns de combate ao spam, cabendo destacar as seguintes recomendaes:

Managing Port 25 for Residential or Dynamic IP Space: Benefits of Adoption and Risks of Inaction

Messaging Anti-Abuse Working Group (MAAWG)

Tecnologias e Polticas para Combate ao Spam - Comisso de Trabalho Anti-Spam do CGI.br.

Em seu documento o MAAWG recomenda para redes de carter residencial, alm da adoode Message Submission, as seguintes medidas:

requerer autenticao para a submisso de mensagens, como recomendado na RFC 4954;

configurar o software cliente de e-mail para usar a porta 587/TCP e autenticao;


bloquear acesso de sada para porta 25/TCP a partir de todas as mquinas que no sejam MTAs ou

explicitamente autorizadas.

no interferir no trfego para a porta 587/TCP;

No primeiro draft do SSL v3.0, a Netscape recomendava a utilizao da porta 465/TCP para submisso

de mensagens via SMTPS. O uso desta porta para submisso de mensagens nunca tornou-se um padro.

Atualmente, a comunidade Internet considera o seu status como "deprecated", porm,

alguns softwares clientes de e-mail e alguns servidores de submisso ainda utilizam esta porta.

A porta 465/TCP, segundo registro do IANA, est reservada para o uso do protocolo URD (URLRendesvous Directory for SSM). A lista de portas registradas junto ao IANA pode ser econtrada

em:http://www.iana.org/assignments/port-numbers.

Resoluo CGI.br/RES/2009/001/P Recomendao para a Adoo de Gerncia de Porta 25 em

Redes de Carter Residencial (CGI.br).

Devido a este fato, apesar de no constar explicitamente na recomendao do MAAWG, importante

que tambm no ocorra interferncia no trfego relacionado com outras portas que possam ser utilizadas

para submisso, como a 80/TCP e a 465/TCP.

A figura a seguir ilustra a mudana de cenrio em uma rede de carter residencial, aps a

implementao de gerncia de porta 25, ou seja, aps a adoo de Message Submission pelos provedores

de e-mail dos usurios e o bloqueio de trfego de sada com destino porta 25/TCP por parte das

operadoras de banda larga.


Figura 2: mudana de cenrio em uma rede aps a implementao de gerncia de porta 25

Pode-se ver que o usurio, conectado via uma rede residencial, envia e-mails normalmente via Mail

Submission Port (587/TCP) ou via Webmail (80/TCP). Mas, os spammers, fraudadores e cdigos maliciosos

no conseguem mais fazer a entrega direta dos e-mails para os provedores de destino, pois a sada de

conexes para porta 25/TCP impedida.

Com este novo cenrio os spammers e fraudadores, provavelmente, adaptaro suas ferramentas para

furtar as credenciais do usurio e se autenticar em seu MSAs (Mail Submission Agents) para o envio

despam. Mas, mesmo ocorrendo esta mudana para uso das credenciais do usurio, outro reflexo da

implementao de Message Submission e Gerncia de Porta 25 em redes de perfil residencial que as

mensagens abusivas so mais rastreveis para os provedores de acesso. Pois, alm do provedor poder

implementar polticas de controle de vazo de e-mails, ele poder identificar mais facilmente mquinas

infectadas e usurios abusivos.

O HTTP/1.1 (Hypertext Transfer Protocol V1.1) um protocolo de comunicao utilizado para sistemas

de informao de hipermdia distribudos e colaborativos. Seu uso para viabilizar o compartilhamento de

recursos distribudos a nvel planetrio levou ao estabelecimento e evoluo da rede mundial (World Wide

Web) como hoje a conhecemos. natural ento que esse seja o protocolo adotado pela ePING para a

transferncia de hipertexto.

Para a transferncia de arquivos, a ePING adotou o prprio protocolo HTTP/1.1, que prev

mecanismos de reinicializao do processo de transferncia sem perda dos dados j transmitidos e

recebidos, e tambm de recuperao limitada de dados em caso de erros de comunicao. Tambm


aceito o protocolo FTP (File Transfer Protocol) desde que utilizado com esses recursos de reinicializao e

recuperao.

Para a pesquisa e atualizao de diretrios, a ePING determina a utilizao do protocolo LDAP

(Lightweight Directory Access Protocol), verso 3. O termo diretrio utilizado para definir uma estrutura

que permite o armazenamento sistemtico, para posterior localizao, de informaes sobre organizaes,

pessoas e outros recursos como arquivos e dispositivos em uma rede, seja na Internet pblica ou em uma

intranet corporativa.

Outro servio de rede a ser mencionado o que trata a intercomunicao, em tempo real, entre

computadores em todo o mundo, o que exige um mecanismo de sincronizao de relgios que leve em

conta os fusos horrios, e que possa compensar e corrigir erros de marcao de tempo. Para tanto, foi

criado ainda em 1985 o protocolo NTP (Network Time Protocol). Hoje em sua verso 4, o NTP pode garantir

uma preciso entre relgios da ordem de 10 milissegundos (1/100 s) na rede pblica Internet, podendo

chegar a 200 microssegundos (1/5000 s) em redes locais. Quando uma preciso dessa ordem no se faz

necessria, pode-se utilizar a verso simplificada desse protocolo conhecida com SNTP (Simple Network

Time Protocol), de mais fcil administrao. Os padres NTP v3.0 e SNTP v4.0 so ambos recomendados

pela ePING.

Quanto aos servios de nomeao de domnio, deve-se seguir a RFC 1035, que descreve os detalhes

do sistema de domnio e o respectivo protocolo.

O CGI (Comit Gestor da Internet no Brasil) o responsvel por coordenar e integrar todas as

iniciativas de servios de Internet no pas. No contexto de governo, o CGI definiu o uso das extenses .gov

e .mil para identificar os stios governamentais e militares, respectivamente. Alm disso, ele regulamentou

tambm os procedimentos de registro de domnio sob a raiz .gov.br que, alm de serem isentos do

pagamento de taxas, devem possuir autorizao formal do Ministrio do Planejamento, Oramento e Gesto

para a sua criao (CGI, 2008).

No caso de servios de conferncias multimdia envolvendo muitos participantes, necessrio que se

possa sinalizar o estabelecimento, mudana ou trmino da sesso de maneira independente do tipo de

mdia em utilizao, tais como texto, udio ou vdeo. Alm disso, preciso que seja possvel adicionar ou

remover participantes dinamicamente numa sesso multicast. O SIP (Session Initiation Protocol) foi

desenvolvido e publicado pela IETF (Internet Engineering Task Force) em meados da dcada de 1990 para

atender essas necessidades, em chamadas e conferncias atravs de redes e via protocolo IP. A ePING

determina a adoo do SIP como o protocolo de sinalizao a ser utilizado nesses casos.

importante lembrar tambm que uma rede de computadores precisa ser permanentemente

monitorada para a deteco e correo de problemas que possam dificultar, ou mesmo impossibilitar, a

comunicao entre os vrios pontos que a integram. Com a grande diversidade e heterogeneidade de

elementos de hardware e software hoje encontrados, o estabelecimento de um protocolo padro a ser


seguido pelos programas de gerenciamento de redes essencial para a eficincia e eficcia desse

monitoramento. O SNMP (Simple Network Management Protocol) possibilita o intercmbio de informao

entre os diversos dispositivos de rede, como placas e comutadores, permitindo assim aos administradores

gerenciar o desempenho da rede, encontrar e resolver seus eventuais problemas, e ainda coletar dados em

tempo real que possam ser teis no planejamento de sua expanso. A ePING recomenda a utilizao da

verso 3 desse protocolo.

3.1.1.2 Especificaes para Rede/Transporte

Tabela 3: Rede/Transporte

Componente Especificao SituaoTransporte TCP e UDP AIntercomunicao LAN/WAN IPv6 AComutao por Label MPLS (pelo menos quatro classes de servio) AQualidade de Servio DiffServ A

O TCP (Transmission Control Protocol) e o IP (Internet Protocol) formam o ncleo de uma sute de

protocolos conhecida como TCP/IP. Enquanto o TCP normatiza o servio de troca confivel de dados entre

dois servidores, o IP trata do endereamento e roteamento de mensagens atravs de uma ou mais redes de

comunicao de dados. Com o advento da Internet, que deles faz uso em larga escala, esses protocolos

passaram a fazer parte da rotina dos profissionais e dos setores responsveis pela infraestrutura de TIC.

Praticamente todos os protocolos e aplicativos da Web (pginas web, transferncia de arquivo, correio

eletrnico etc.) utilizam o TCP como mecanismo de transporte subjacente. Nos casos em que o aplicativo

no requeira um servio confivel de fluxo de dados, o protocolo UDP (User Datagram Protocol) pode ser

utilizado. O UDP fornece um servio de datagramas, enfatizando latncia sobre confiabilidade.

O IPv4 (Internet Protocol version 4) ainda hoje a verso mais utilizada da sute de protocolos IP,

embora a verso que a suceder, inicialmente chamada de SIPP (Simple Internet Protocol Plus) e agora

conhecida simplesmente como IPv6 (Internet Protocol version 6), venha ganhando aceitao crescente. A

principal diferena entre essas duas verses dizem respeito estrutura de endereamento utilizada:

endereos de 32 bits no caso do IPv4, e de 128 bits no caso do IPv6.

Devido ao esgotamento da oferta de endereos IPv4 pblicos, os rgos da APF devero planejar sua

futura migrao para IPv6. Novas contrataes e atualizaes de redes interopervies devero implementar

ambos os protocolos IPv4 e IPv6.

No caso de redes de telecomunicao onde se necessita de alto desempenho, a ePING determina o

uso do MPLS (Multiprotocol Label Switching), um mecanismo altamente eficiente e escalvel para

direcionamento e transporte de dados entre duas redes. O MPLS opera com o conceito de CoS (Class of

Service, ou Classe de Servio), utilizado para organizar o trfego de dados em filas de prioridade. A ePING


requer que as implementaes do MPLS trabalhem com pelo menos quatro classes de servio. Por ltimo,

cabe ressaltar que a adoo do MPLS preclui a utilizao das tecnologias alternativas, como ATM

(Asynchronous Transfer Mode, ou Modo de Transferncia Assncrona) e Frame-Relay.

Nos casos em que no h a necessidade de implementao de MPLS (redes locais, por exemplo),

possvel obter Qualidade de Servio (QoS) com a implementao de DiffServ. Este protocolo permite um

melhor aproveitamento do uso das redes atravs da priorizao de pacotes, evitando casos em que uma

simples aplicao ou servio consuma o canal de comunicao e prejudique outros servios oferecidos por

aquela rede.

3.1.1.3 Especificaes para Enlace/Fsico

Tabela 4: Enlace/Fsico


Rede local sem fioIEEE 802.11 g AIEEE 802.11 n R

Qualidade de Servio 802.1p RVirtual LAN VLAN (IEEE 802.1Q) R

Resilincia Layer2 Spanning tree protocol (802.1d,802.1w, 802.1s) R

As WLAN (Wireless Local Area Network, ou Redes Locais Sem Fio) devem seguir o conjunto de

padres conhecido como IEEE 802.11, na verso g, que normatizam a comunicao entre computadores

utilizando a frequncia de 2.4 GHz. O IEEE a sigla do Institute of Electrical and Electronic Engineers, uma

organizao internacional dedicada evoluo e aplicabilidade de tecnologias ligadas eletricidade de

maneira geral, e responsvel pela criao e manuteno de um grande nmero de padres tcnicos.

O padro IEEE 802.11n que foi criado pelo grupo TGn em 2003 teve sua aprovao no segundo

semestre de 2009 e recomendado pela ePING. As metas iniciais do padro eram aumentar as taxas de

transmisso ao nvel das redes locais e assegurar a compatibilidade do novo padro com os padres

antigos. O 802.11n tem como principal caracterstica o uso de um esquema chamado Multiple-Input

Multiple-Output (MIMO), capaz de aumentar consideravelmente as taxas de transferncia de dados por

meio da combinao de vrias vias de transmisso (antenas). Com isso, possvel, por exemplo, usar dois,

trs ou quatro emissores e receptores para o funcionamento da rede.

Para ser aprovado o padro IEEE 802.11n, o TGn definiu modos de operaes para promover

compatibilidade com os padres 802.11 anteriores. Foram divididos em trs modos de operaes: HT, Non-

HT e HT Mixed Mode.

- Um AP 802.11n usando o modo High Throughput (HT) - tambm conhecido como modo de Greenfield

assume que no existem estaes legadas prximas usando a mesma faixa de frequncia. Se estaes

legadas no existem, elas no podem se comunicar com o AP 802.11n. Modo de HT opcional.


- Non-HT (Legacy) Mode - um AP 802.11n usando o modo no-HT envia todos os quadros utilizando o

antigo formato dos padres 802.11a / g para que as estaes legadas possam entend-las. Todos os

produtos tm de suportar este modo a garantir compatibilidade com verses anteriores. Mas usar um AP

802.11n Non-HT no oferece nenhuma melhora de performance com relao 802.11a / g.

O HT mixed mode obrigatrio e ser o mais comum de funcionamento em APs 802.11n. Nesse

modo, melhorias HT podem ser utilizadas simultaneamente com os mecanismos de proteo HT que

permitem comunicao com estaes legadas. HT modo misto fornece compatibilidade com verses

anteriores, mas o padro 802.11n tem perdas significativas na taxa de transferncia em relao ao modo de

Greenfield.

A utilizao das tecnologias IEEE 802.11g e IEEE 802.11n devem tambm seguir as determinaes do

Wi-Fi Alliance, uma associao entre fabricantes de equipamentos de WLANs para certificao de produtos

que atendam um conjunto de requisitos de interoperabilidade definidos por essa associao. Sempre que

aplicveis, as normas da ANATEL e da ANEEL (Agncia Nacional de Energia Eltrica) tambm devem ser

respeitadas.

O protocolo IEEE 802.1p uma tcnica para priorizao de trfego em redes locais, sendo

especificado na norma IEEE 802.1D LAN Bridges. Atravs dessa tcnica, possvel utilizar aplicaes

sensveis a tempo em redes locais (LANs).

A norma IEEE 802.1D inclui as extenses 802.1p e 802.1Q, adicionando 4 bytes ao formato do

cabealho MAC das redes Ethernet e Token Ring. A extenso 802.1Q utiliza dois bytes desse espao,

sendo que 12 bits so reservados para identificao de VLAN (Virtual LAN) e 3 bits so definidos pela

norma IEEE 802.1p a fim de determinar a prioridade no nvel 2 do modelo OSI, conforme mostra a figura a

seguir.

Figura 3: Representao das normas IEEE 802.1D, 802.1p e 802.1Q


Os 3 bits da norma IEEE 802.1p definem 8 classes de trfego, como mostra a tabela a seguir.

Prioridade Nome Caractersticas e exemplos7 Controle da rede Aplicaes crticas (RIP, OSPF, BGP4)6 Voz interativa Sensveis latncia e jitter com baixa banda (Netmeeting, RAT)5 Multimdia interativa Sensveis ao jitter com alta banda (picturetel, indeo)4 Carga controlada Aplicaes sensveis latncia (transaes SNA)3 Esforo excelente Trfego crtico que tolera atrasos (SAP, SQL)2 Melhor esforo Melhor esforo1 Default Default0 Background Insensveis latncia (FTP, backups, pointcast)

Um padro IEEE para provimento de capacidade de LAN virtual em uma rede, usada em conjunto com

protocolos de LAN do IEEE, como Ethernet e Token Ring.

A utilizao de VLAN (Virtual Local Area Network) permite que uma rede fsica seja dividida em vrias

redes lgicas dentro de um Switch. A partir da utilizao de VLANs, uma estao no capaz de

comunicar-se com estaes que no pertencem a mesma VLAN (para isto, necessrio a utilizao de uma

sub-rede por VLAN e que o trfego passe primeiro por um roteador para chegar a outra rede.

A marcao efetuada (chamada de TAG) adiciona aos quadros Ethernet 4 bytes no frame original e

calculam um novo valor de checagem de erro para o campo FCS.

Figura 4: Quadro ethernet com TAG

Dos valores contidos dentro do campo TAG o nmero da VLAN adicionado ao campo VLAN id

permitindo a identificao da VLAN entre os Switches. Esse mecanismo de VLANs bastante flexvel, e

permite organizar os computadores em domnios de broadcast distintos, independentemente de sua

conexo fsica.

O crescimento das redes LANs, associado aos requisitos de qualidade e tolerncia a falhas cada vez

maiores, culminou em solues de rede com topologias cada vez mais robustas, como nos casos de redes

em anel. Tais implementaes, com o intuito de garantir maior disponibilidade para as solues e servios,

acabam por proporcionar redundncia de caminhos de rede e, com isso, a possibilidade de ocorrncia de

looping.


Desse modo, surgiram alguns protocolos com o objetivo de garantir a resilincia na camada 2, alm

de otimizar a comunicao e os tempos de convergncia quando da ocorrncia de falhas:

802.11d

Para prevenir os congestionamentos broadcast e outros efeitos colaterais indesejados das ligaes em

loop, a empresa Digital Equipment Corporation criou o protocolo spanning tree (STP), que foi padronizado

como a especificao 802.1d pelo IEEE - Institute of Electrical and Electronic Engineers. O protocolo

spanning tree utiliza um algoritmo spanning tree (STA), que percebe que o switch tem mais de uma maneira

de se comunicar com um n de destino. Este protocolo determina o melhor caminho e bloqueia os outros

(que ficam como caminho alternativo para o caso de falha no caminho principal), de modo a evitar looping.

802.11w

Em 2001 foi desenvolvido o Rapid Spanning Tree Protocol (RSTP), norma 802.1w, com a finalidade de

acelerar o processo de alterao da rvore de suporte quando h alterao da topologia da rede, de modo

que este processo de convergncia possa acontecer num tempo muito mais curto, na casa dos

milissegundos.

802.11s

O IEEE 802.1s Multiple Spanning Tree Protocol (MSTP), proposto em 2002, uma evoluo do IEEE

802.1d Spanning Tree Protocol (STP). Com o crescente nmero de problemas associados ao aparecimento

constante de esquemas mais complexos para as redes baseadas na camada 2 do modelo de OSI (Open

Systems Interconnection), especialmente referentes redundncia e ao balanceamento de carga, foi

desenvolvido o MSTP, tendo sempre em vista obter o menor impacto possvel em termos de desempenho.

Este novo protocolo veio trazer vrias vantagens, fazendo uso de vrios aspectos de outros protocolos

como o Rapid Spanning Tree Protocol (RSTP) e Per-Vlan Spanning Tree (PVST).

Um exemplo representativo da utilizao das diretrizes e recomendaes da ePING para componentes

de infraestrutura de rede pode ser encontrado no processo de aquisio de comutadores (switches) pelo

Ministrio do Planejamento, Oramento e Gesto, conduzido no stio do Comprasnet, com a publicao de

trs especificaes de referncia para diferentes famlias de dispositivos de comutao (COMPRASNET,

2010).


3.1.2. Segurana Segmento 2

A ePING estabelece que os dados, informaes e sistemas de informao do governo devem ser protegidos

contra ameaas de forma a reduzir riscos e garantir sua integridade, confidencialidade, disponibilidade e

autenticidade. Para tanto, indispensvel que os dados e informaes sejam mantidos com o mesmo nvel

de proteo, independentemente do meio em que estejam sendo processados e armazenados, ou pelos

quais estejam trafegando. Assim, as informaes sensveis que trafegam em redes inseguras, incluindo as

redes sem fio, devem ser criptografadas de modo adequado, conforme os componentes de segurana por

ela especificados.

A poltica de segurana da ePING enfatiza a necessidade de que essa questo seja tratada de forma

preventiva e global. Por ser preventiva, a segurana requer a elaborao de planos de continuidade para

sistemas que apoiam processos crticos, de forma a garantir nveis mnimos de produo. Por ser global, a

segurana deve ser considerada em todas as etapas do ciclo de desenvolvimento de um sistema.

3.1.2.1 Especificaes para Comunicao de dados

Tabela 5: Comunicao de Dados


Transferncia de dados em redes inseguras TLS. Caso seja necessrio, o protocolo TLS v1 pode emular o SSL v3. R

Algoritmos para troca de chaves de sesso, durante o handshake

RSA, Diffie-Hellman RSA, Diffie-Hellman DSS, DHE_DSS, DHE_RSA R

Algoritmos para definio de chave de cifrao RC4, IDEA, 3DES e AES RCertificado Digital X.509 v3 ICP-Brasil, SASL RHipertexto e transferncia de arquivos RFC 2818 (atualizada pela RFC 5785) R

Segurana de redes IPv4 Autenticao IPSec, IKE para permutao dechaves, ESP como requisito para VPN A

Segurana de redes IPv4 para protocolos de aplicao S/MIME v3 A

Segurana de redes IPv6 na camada de rede

As especificaes do IPv6 definiram dois mecanismos de segurana: a autenticao de cabealho AH (Authentication Header) RFC 4302 ou autenticao IP, e a segurana do encapsulamento IP, ESP (Encrypted Security Payload) RFC 4303.

R

Garantir a integridade e confidencialidade dos dados transmitidos por redes de comunicao ,

sobretudo, prevenir que terceiros tenham acesso indevido ou falsifiquem esses dados enquanto em trnsito.

Para dados que trafegam em redes inseguras como a Internet, indispensvel a utilizao de protocolos

criptogrficos. Esses protocolos tipicamente provm a privacidade e a integridade dos dados trafegando

entre duas ou mais aplicaes atravs de dois mecanismos bsicos: (i) autenticao das partes envolvidas,

e (ii) cifrao dos dados transmitidos entre as partes.


A autenticao busca garantir que um agente envolvido em uma interlocuo ou troca de mensagens de fato quem ele diz ser. A cifrao, com o emprego de algoritmos matemticos e parmetros de controlechamados de chaves criptogrficas, busca tornar a mensagem incompreensvel e intil para todos osefeitos, enquanto no for submetida ao processo inverso de decifrao. So dois os mecanismos bsicosde cifrao/decifrao hoje em utilizao: (i) criptografia simtrica (ou de chave secreta), e (ii) criptografiaassimtrica (ou de chave pblica). Os algoritmos simtricos utilizam uma mesma chave tanto na cifraocomo na decifrao, enquanto os algoritmos assimtricos utilizam chaves distintas em cada processo.

O esforo mais bem sucedido de construo de um protocolo criptogrfico para a Internet foi o SSL

(Secure Socket Layer) ou Protocolo Seguro da Camada de Socket, que utiliza PKI (Public Key

Infrastructure) ou ICP (Infraestrutura de Chaves Pblicas), um mtodo assimtrico que emprega pares de

chaves (uma pblica, de acesso universal, e outra privada, de conhecimento exclusivo de seu proprietrio)

para garantir que (i) apenas o destinatrio poder conhecer o contedo da mensagem, e (ii) o destinatrio

estar seguro de que a mensagem originou-se do emitente declarado.

Com as modificaes introduzidas na verso 3.1, o SSL passou a ser chamado de TLS (Transport

Layer Security) ou Segurana da Camada de Transporte. A ePING recomenda a utilizao do TLS v1 com

todos os protocolos de transporte subjacentes que se baseiam no protocolo TCP, tais como HTTP, LDAP,

IMAP, POP3 e Telnet. Uma vantagem do TLS v1, destacada na ePING, sua capacidade de emular o SSL

v3, til em situaes que requeiram esse nvel de compatibilidade.

Quanto aos certificados digitais, a ePING recomenda o padro X.509 v3, um padro internacional para

a Infraestrutura de Chaves Pblicas que garante uma autenticao forte (em outras palavras, uma

vinculao segura entre um certificado, seu emitente e seu destinatrio). Esses certificados devem ser

emitidos por entidades pertencentes rede de entidades certificadoras conhecida como ICP-Brasil.

Quanto aos mecanismos internos inerentes utilizao do TLS v1, a ePING recomenda mltiplas

alternativas de algoritmos, para cada caso: RSA, Diffie-Hellman RSA, Diffie-Hellman DSS, DHE_DSS e

DHE_RSA (definio de chaves de cifrao), RC4, IDEA, 3DES e AES (troca de chaves durante o hand-

shake de uma sesso), SHA-256 ou SHA-512 (implementao de funes de hash).

Para a complementao dos servios oferecidos pelo TLS v1, a ePING recomenda a utilizao do

SASL (Simple Authentication and Security Layer). O SASL possibilita o desacoplamento entre mecanismos

de autenticao e protocolos de aplicao, e tambm viabiliza um procedimento conhecido com proxy

authorization (um usurio assume a identidade de outro, em um contexto de alta confiabilidade).


A ePING especifica que a segurana de redes IPv4 e IPv6 em suas mltiplas camadas deve ser

implementada com os seguintes componentes:

IPSec Authentication Header autenticao de cabealhos IP;

IKE (Internet Key Exchange) negociao entre duas entidades para a troca de material de chaveamento;

ESP (Encapsulating Security Payload) implementao de redes privadas virtuais (VPNs) e autenticao e segurana de encapsulamento de pacotes IP;

S/MIME (Secure/Multipurpose Internet Mail Extensions) cifrao genrica de mensagens MIME com criptografia de chave pblica;

AH (Authenticaton Header) autenticao de cabealho com o protocolo Ipv6.

3.1.2.2 Especificaes para Correio Eletrnico

Tabela 6: Correio Eletrnico


Acesso a caixas postais Cliente especfico com mecanismos de segurana nativos ouHTTPS A

Contedo de e-mail S/MIME v3 ATransporte de e-mail SPF AIdentificao de e-mail DKIM RAssinatura Padro ICP-Brasil ATransporte seguro de e-mail SMTP seguro sobre TLS R

A ePING especifica que o acesso seguro a caixas postais eletrnicas pode ser feito atravs de dois

mecanismos, considerados individualmente ou combinados: (i) utilizao de aplicativos-cliente especficos

que disponham de mecanismos de segurana nativos, e (ii) utilizao do protocolo HTTPS (HyperText

Transfer Protocol Secure). Esse protocolo permite a criao de um canal seguro na Internet pela

combinao dos protocolos HTTP e SSL/TLS, esse ltimo descrito na seo 3.4.1.

As mensagens de correio eletrnico seguro devem ser protegidas atravs do padro S/MIME v3. Esse

padro disponibiliza os seguintes servios de segurana criptogrfica: (i) autenticao, (ii) integridade de

contedo (iii) privacidade e (iv) no-repdio da origem declarada. Esse ltimo e importante servio garante

que o autor de uma mensagem assim protegida no conseguir contestar com sucesso a alegada origem

dessa mensagem, no podendo assim repudiar sua validade.

Para evitar a falsificao da origem de mensagens de correio eletrnico, a ePING recomenda que o

transporte dessas mensagens utilize o sistema de validao conhecido como SPF (Sender Policy

Framework). O objetivo do SPF impedir que domnios da internet enviem mensagens personificando

outros domnios sem a devida autorizao, bloqueando assim uma prtica com enorme potencial para

fraudes.


Para a assinatura de mensagens seguras, a ePING determina a utilizao de certificados digitais no

padro X.509 v3, emitidos por entidades pertencentes rede certificadora ICP-Brasil.

3.1.2.3 Especificaes para Criptografia

Tabela 7: Criptografia

Componente Especificao SituaoAlgoritmo de cifrao 3DES ou AES RAlgoritmo para assinatura/hashing SHA-256 ou SHA-512 RAlgoritmo para transporte de chave criptogrfica de contedo/sesso RSA A

Algoritmos criptogrficos baseados em curvas elpticas

ECDSA 256 e ECDSA 512ECIES 256 e ECIES 512 A

Requisitos de segurana para mdulos criptogrficos

Homologao da ICP-BrasilNSH-2 e NSH-3

FIPS 140-1 e FIPS 140-2R

Certificado Digital da AC-raiz para Navegadores e Visualizadores de Arquivos Padres da ICP Brasil R

A confiabilidade de um procedimento de cifrao depende da qualidade e robustez do algoritmo

utilizado. Para a cifrao de contedo de qualquer natureza, a ePING recomenda a utilizao dos algoritmos

3DES Triple Data Encryption Algorithm, ou DES Triplo) e AES (Advanced Encryption Standard, ou Padro

de Criptografia Avanada).

O 3DES uma variante mais robusta do DES (Data Encryption Standard), um padro institudo pelo

governo americano em 1976. O DES um mecanismo simtrico de cifrao que utiliza chaves de 56 bits,

adequadas ao panorama computacional daquela poca, mas hoje incapazes de resistir a ataques de fora

bruta com os recursos de CPU disponveis at em equipamentos de uso domstico. Para compensar essa

fraqueza, o 3DES usa trs chaves em sequncia: a informao encriptada com a primeira chave,

decriptada com a segunda, e por fim novamente encriptada com a terceira chave.

O AES (Advanced Encryption Standard) foi promulgado como padro criptogrfico do governo

americano em 2002, aps um longo processo conduzido pelo NIST (National Institute of Standards and

Technology), que durou cerca de cinco anos, e onde se procurou selecionar atravs de concurso pblico um

novo algoritmo de chave simtrica para proteger informaes do Governo Federal. O AES considerado

pela maioria dos especialistas o estado da arte em algoritmo criptogrfico. Ele combina com eficincia as

caractersticas de segurana, desempenho, facilidade de implementao, flexibilidade e alta resistncia a

ataques. Alm disso, ele demanda pouca memria e CPU, o que o torna adequado para utilizao em

plataformas de poder computacional relativamente baixo, como smart cards, PDAs e telefones celulares.

Em criptografia, uma funo hash um procedimento determinstico que recebe um bloco de

informao de qualquer comprimento (chamado de mensagem), e retorna uma cadeia de caracteres de

tamanho fixo (chamado de digest). Esse procedimento til para garantir a integridade de uma mensagem,

uma vez que produzir um digest diferente no evento de qualquer mudana, intencional ou acidental, na


mensagem original. As propriedades consideradas essenciais para esse tipo de procedimento so: (i)

facilidade de computao do digest para mensagens de qualquer natureza, (ii) impossibilidade prtica de

obteno de uma mensagem a partir de um digest, (iii) impossibilidade prtica de modificao de uma

mensagem com a manuteno do mesmo digest e (iv) impossibilidade prtica de obteno de duas

mensagens distintas com o mesmo digest.

O SHA-2 (Secure Hash Algorithm, version 2) uma famlia de funes hash desenvolvidas pela

agncia do governo norte-americano NSA (National Security Agency), com quatro variantes: SHA-224,

SHA-256, SHA-384 e SHA-512 (que produzem digests de 224, 256, 384 e 512 bits, respectivamente).

Enquanto todas essas variantes atendem as propriedades arroladas no pargrafo anterior, a ePING

recomenda a utilizao das variantes hoje mais usadas, SHA-256 e SHA-512.

Sistemas de criptografia simtricos, tais como 3DES e AES, so muito mais rpidos do que os

assimtricos. Na prtica, as mensagens so criptadas com um algoritmo simtrico, e as chaves utilizadas,

em geral muito mais curtas do que as mensagens, so criptadas com um algoritmo assimtrico, tornando

seguro o transporte das chaves entre os interlocutores. A ePING determina a utilizao do algoritmo RSA

(sigla construda a partir dos sobrenomes de seus inventores, Ronald Rivest, Adi Shamir e LeonardAdleman) como mecanismo criptogrfico de chaves.

Publicado em 1978, o RSA at hoje o mais bem sucedido mecanismo de criptografia assimtrica, e

a base para a Infraestrutura de Chaves Pblicas. O RSA utiliza pares de chaves de comprimento varivel, e

quanto maior esse comprimento, maior a segurana proporcionada. Com o aumento de poder dos recursos

computacionais disponveis, e concomitante queda nos custos envolvidos, chaves cada vez maiores so

necessrias para o mesmo nvel de segurana. Hoje, o RSA tipicamente utilizado com chaves de

comprimento entre 1024 e 2048 bits, enquanto comprimentos inferiores a 512 bits j so considerados

inseguros.

Em muitas situaes, necessrio que a mesma segurana propiciada por algoritmos como RSA seja

obtido com a utilizao de nmeros bem menores. Para essas situaes, a ePING especifica que: (i) para

assinaturas digitais, deve-se utilizar o ECDSA (Elliptic Curve Digital Signature Algorithm, ou Algoritmo de

Assinatura Digital de Curvas Elpticas), nas variantes ECDSA 256 e ECDSA 512, e (ii) para cifrao e

transporte seguro de chaves criptogrficas, deve-se utilizar o ECIES (Elliptic Curve Integrated Encryption

Scheme, ou Esquema Integrado de Criptao com Curvas Elpticas), nas variantes ECIES 256 e ECIES

512.

O ECDSA uma modificao do algoritmo DSA (Digital Signature Algorithm, ou Algoritmo de

Assinatura Digital), enquanto o ECIES uma variante do IES (Integrated Encryption Scheme, ou Esquema

Integrado de Criptao). Tanto o ECDSA quanto o ECIES notabilizam-se por serem implementaes da

famlia ECC (Elliptic Curve Cryptography, ou Criptografia de Curvas Elpticas), uma rea da criptografia que

hoje desfruta de intenso interesse acadmico e comercial.


A ePING recomenda que os mdulos criptogrficos utilizados, tais como equipamentos e sistemas de

certificao digital, atendam os Nveis de Segurana de Homologao 2 e 3 (NSH-2 e NSH-3) da ICP-Brasil

(ICP-BRASIL, 2009), ou os requisitos de segurana para mdulos criptogrficos publicados pelo National

Institute of Standards and Technology (NIST, 2001).

3.1.2.4 Especificaes para Desenvolvimento de Sistemas

Tabela 8: Desenvolvimento de Sistemas

Componente Especificao SituaoAssinaturas XML XMLsig ACifrao XML XMLenc R

Assinatura e cifrao XML Transformao de decifrao paraassinatura XML R

Principais gerenciamentos XML em ambiente PKI XKMS 2.0 RAutenticao e autorizao de acesso XML SAML R

Intermediao ou Federao de Identidades WS-Security 1.1WS-Trust 1.4 R

Navegadores Cookies apenas com aconcordncia do usurio A

A ePING determina que os seguintes padres de segurana sejam utilizados no desenvolvimento de

sistemas, quando houver envolvimento de componentes XML (Extensible Markup Language) e de

navegadores:

XMLsig (XML Signature) na assinatura de documentos e artefatos XML;

Cookies no controle da interao do usurio com o sistema atravs de navegadores, desde que

obtida sua concordncia.

A ePING recomenda a utilizao dos seguintes padres de segurana na utilizao de documentos e

artefatos XML em sistemas de computao:

XMLenc (XML Encryption) procedimentos a serem observados na criptao de documentos XML;

XKMS 2.0 (XML Key Management Specification) para facilitar a interoperabilidade entre aplicaes que fazem o uso da Infraestrutura de Chaves Pblicas, atravs de dois componentes:

(i) XKISS (XML Key Information Service Specification), que diz respeito gesto da chave pblica,e (ii) XKRSS (XML Key Registration Service Specification), que diz respeito gesto da chave

privada;

SAML (Security Assertion Markup Language) - para a troca de informao sobre autenticao e autorizao entre domnios;

WS-Security 1.1 para o fornecimento de segurana s mensagens SOAP (Simple Object Access Protocol), atravs da utilizao dos padres XMLsig e XMLenc;

WS-Trust 1.3 extenses ao WS-Security para a gesto de relacionamentos confiveis entre os envolvidos na troca de mensagens seguras.


3.1.2.5 Especificaes para Servios de Rede

Tabela 9: Servios de Rede

Componente Especificao SituaoDiretrio LDAP v3 e extenso para TLS RDNSSEC Prticas de Segurana para Administradores de Redes Internet A

Carimbo de tempo TSP e TSAsNormas da ICP-Brasil R

A ePING recomenda que a segurana de diretrios seja implementada com a extenso para TLS do

LDAP v3. Para a transferncia segura de arquivos, a ePING recomenda o protocolo HTTPS, que permite a

criao de um canal seguro na internet pela combinao dos protocolos HTTP e SSL/TLS.

Para a resoluo segura de endereos na internet, a ePING determina aos administradores

implementar o padro DNSSEC (DNS Secure Extensions, ou Extenses de Segurana do DNS), uma

extenso do DNS (Domain Name System, ou Sistema de Nomes de Domnios) que reduz o risco de

manipulao de dados e de utilizao de domnios forjados.

O protocolo TSP (Time-Stamp Protocol, ou Protocolo de Carimbo de Tempo) deve ser utilizado sempre

que houver a necessidade de se garantir que um artefato eletrnico existia antes de, ou em um momento

particular de tempo. Esses carimbos de tempo usam certificados X.509 e a Infraestrutura de Chaves

Pblicas, e devem ser emitidos por TSAs (Time-Stamping Authorities, ou Autoridades Emissoras de

Carimbo de Tempo), segundo procedimentos definidos pelo IETF, responsvel pela manuteno desses

dois padres. Alm disso, devem ser observadas as normas da ICP-Brasil sobre o assunto (ICP-BRASIL,

2008).

3.1.2.6 Especificaes para Redes Sem Fio

Tabela 10: Redes Sem Fio

Componente Especificao SituaoLAN sem fio 802.11 WPA2 R

A ePING recomenda que a segurana de redes sem fio seja implementada com a utilizao do padro

WPA2 (Wi-Fi Protected Access, version 2), uma evoluo do padro anterior WPA. O WPA2 requer testes e

certificao pelos autores do padro, a Wi-Fi Alliance, antes que um dispositivo possa se declarar em

conformidade com ele.


3.1.2.7 Especificaes para Resposta a Incidentes de Segurana da Informao

Tabela 11: Resposta a Incidentes de Segurana da Informao

Componente Especificao SituaoPreservao de registros Guidelines for Evidence Collection and Archiving RGerenciamento de incidentes em redes computacionais

Expectations for Computer Security Incident ResponseNorma Complementar N o. 05/09 A

Informtica Forense Guide to Integrating Forensic Techniques into IncidentResponse A

Os administradores devem estar preparados a dar respostas adequadas aos incidentes de segurana

da informao que possam vir a ocorrer, quaisquer que sejam sua natureza ou origem. Para tanto, a ePING

recomenda que sejam seguidas as orientaes contidas em textos de referncia internacional sobre

preservao de registros (IETF, 2002) e informtica forense (NIST, 2006), bem como em Normas

Complementares especficas editadas pelo Gabinete de Segurana Institucional da Presidncia da

Repblica (PRESIDNCIA DA REPBLICA, 2010). Em particular, so destacadas duas linhas de atuao:

(i) criao de equipes especializadas no tratamento e resposta a incidentes, e (ii) organizao de uma

capacidade fornsica para a identificao, coleta, exame e anlise de dados, mantendo a integridade da

informao e a estrita cadeia de custdia desses dados.


3.1.3. Meios de Acesso Segmento 3

3.1.3.1 Especificaes para Meios de Publicao

Tabela 12: Meios de Publicao

Componentes Especificao SituaoConjunto de caracteres UNICODE, verso 7.0 e UTF-8 R

Formato de intercmbio de hipertextoHTML, verso 5 AXML, verses 1.0 e ou 1.1 A

Mobile

W3C Mobile Web application Best Practices http://www.w3.org/TR/mwabp/ R

W3C Geolocation API Specification http://www.w3.org/TR/mediaont-api-1.0/ R

W3C Mobile Web Application Best Practiceshttp://www.w3.org/TR/geolocation-API/ R

Arquivos do tipo documento/publicao

Texto puro (.txt) AOpen Document (.odt) AODF 1.2 REPUB 3.0.1 RPDF RPDF verso aberta PDF/A R

Arquivos do tipo planilha Open Document (.ods) AODF 1.2 R

Arquivos do tipo apresentaoOpen Document (.odp) AODF 1.2 RHTML (.htm ou .html) R

Arquivos do tipo banco de dados para estaes de trabalho

XML, verses 1.0 ou 1.1 (.xml) RMySQL Database (.myd, .myi) RTexto puro (.txt) ATexto puro (.csv) AArquivo do Base (.odb) R

Intercmbio de informaes grficas e imagens estticas

PNG (.png) ASVG (.svg) RJPEG File Interchange Format (.jpeg, .jpg ou.jfif) R

Grficos vetoriais SVG (.svg) RAnimao SVG (.svg) R

udioOgg Vorbis (.ogg, .oga) ROgg FLAC (.ogg, .oga) RFLAC (.flac) R

Vdeo Ogg Theora (.ogg, .ogv) RMatroska R

Compactao de arquivos de uso geral

ZIP (.zip) RGNU ZIP (.gz) RPacote TAR (.tar) RPacote TAR compactado (.tgz ou .tar.gz) RBZIP2 (.bz2) RPacote TAR compactado com BZIP2 (.tar.bz2) R


Informaes georreferenciadasGML, verso 2 ou superior AShapeFile AGeoTIFF A

3.1.3.1.1 Codificao dos Dados (encoding)

A interoperabilidade semntica para meios de publicao envolve, primeiramente, a definio do padro

para a representao e manipulao dos dados de acordo com a lngua oficial do pas. Neste caso, a

ePING recomenda a adoo do padro UNICODE, em detrimento do padro ASCII (American Standard

Code for Information Interchange), que no mencionado no documento.

O UNICODE, que consiste na definio de pouco mais de 107 mil caracteres, permite a representao

de informaes em qualquer lngua existente no mundo. Alm da padronizao dos caracteres, o UNICODE

define toda uma metodologia para a codificao de caracteres e operaes de teclado, por exemplo,

operaes com as teclas de funes (F1 a F12).

A manuteno do padro UNICODE realizada pelo Unicode Consortium e conta com a participao

da ISO (Organizao Internacional para Padronizao). A ltima verso do UNICODE, verso 5.2.0, pode

ser consultada no stio do Unicode Consortium (UNICODE CONSORTIUM, 2010).

O UNICODE define dois mtodos de mapeamento de caracteres: UCS (Universal Character Set) e UTF

(Unicode Transformation Format). O UCS, conhecido como UCS-2, um sistema de codificao de largura

fixa, suportado apenas em sistemas obsoletos. O UTF, por sua vez, compreende os padres UTF-7, UTF-8,

UTF-16 e UTF-32. Os nmeros (7, 8, 16 e 32) representam a quantidade de bits necessrios para se

codificar uma caracter. No que diz respeito interoperabilidade semntica, importante considerar os

seguintes pontos:

UCS-2 considerado um padro obsoleto, apenas suportado em sistemas legados.

UTF-7 considerado um padro obsoleto, apenas suportado em sistemas legados.

Arquivos codificados em UTF-8 com caracteres ASCII equivalem a arquivos em padro ASCII.

UTF-16 e UTF-32 so incompatveis com arquivos codificados em ASCII.

O UTF-8 a codificao mais utilizada.

Como recomendao de boas prticas quanto ao uso de UNICODE, sugere-se:

Para codificao de mensagens de cabealho de e-mail:Content-Type: text/plain; charset="UTF-8"

ou

Content-Type: text/plain; charset="UTF-16"

Para codificao de pginas HTML:


ou

Para codificao de arquivos XML:

ou

ou

Recomenda-se verificar o tipo de codificao que melhor atenda aos requisitos da informaoque se deseja transmitir ou receber. Verifique a presena de acentuao e de caracteresestrangeiros, pois esse requisito pode significar a necessidade de se utilizar um tipo de UNICODEespecfico.

3.1.3.1.2 Formato de Intercmbio de hipertexto

Outro aspecto relacionado interoperabilidade semntica em meios de publicao envolve a transferncia

de dados em formato de hipertexto. A ePING adota como padro o HTML (verso 5) e o XML (verses 1.0 e

1.1).

3.1.3.1.3 Especificaes para Mobilidade

A ePING entende como um grande desafio para o governo possibilitar sociedade o acesso aos

produtos e servios do governo eletrnico a partir de dispositivos mveis ou portteis. A crescente aceitao

desses dispositivos os torna canais privilegiados de comunicao com o cidado, permitindo que se

impulsione a incluso digital via mobilidade. Entre esses dispositivos destacam-se notebooks, smartphones

e, sobretudo, os telefones celulares.

O conceito fundamental que deve ser aplicado aos servios a serem disponibilizados por meio dos

dispositivos mveis o da web universal: a internet disponvel para todos, em qualquer lugar,

independentemente do dispositivo de acesso. Sob essa perspectiva, a ePING recomenda a aderncia s

melhores prticas de implementao da web mvel definidas pelo Consrcio World Wide Web (W3C, 2008).


3.1.3.1.4 Arquivos do tipo documento/ publicao

A interoperabilidade semntica tambm implica no intercmbio de arquivos nos mais diferentes formatos.

Isso porque a utilizao de formatos pouco conhecidos ou de uso no muito frequente dificulta ou impede

que a informao seja recebida e decifrada adequadamente.

Nesse contexto, para a troca de arquivos do tipo documento, a ePING referencia como padres

Adotados (A), arquivos no formato de texto puro (.txt) e em formato Open Document (.odt). Adicionalmente,

na impossibilidade de utilizao desses dois padres, pode-se optar pelo uso de arquivos XML (verses 1.0

e 1.1), com ou sem formatao baseada em XSL (Extensible Stylesheet Language), arquivos HMTL (verso

4.01) e arquivos no padro PDF (Portable Document Format), onde se deve optar por sua verso aberta,

PDF 1.4, quando necessria a preservao digital de documentos.

Para o intercmbio de planilhas eletrnicas e arquivos de apresentao, a ePING Adota (A),

respectivamente, os formatos Open Document (.ods e .odp).

Visando o recebimento de arquivos gerados por sistemas de banco de dados, a ePING Adota (A) como

padro obrigatrio os formatos de texto puro (.txt e .csv). Outros formatos mencionados como

Recomendados (R) so: XML (verso 1.0 e 1.1), MySQL Database (verso 4.0 ou superior) e Open Office

Base (.odb).

No que diz respeito troca de imagens no setor pblico, deve-se adotar os padres PNG (.png). Na

impossibilidade de uso desses padres, a ePING recomenda o uso dos formatos SVG (.svg) e JPEG (.jpeg,

.jpg ou jfif).

Para o tratamento de grficos vetoriais nenhum padro definido como Adotado (A) na ePING.

Entretanto, h a recomendao pelo uso do formato SVG (.svg). A ePING tambm referencia o formato

SVG (.svg) como Recomendado (R) para a definio de arquivos de animao.

No que tange ao uso de arquivos de udio e vdeo, a ePING ainda no define nenhum formato como

Adotado (A). No entanto, recomenda o uso dos seguintes padres: FLAC, Matroska, Ogg Vorbis - formato

aberto para streaming de udio (.oga) e Theora (.ogv). Os formatos que devem ser evitados, segundo a

ePING, so: Audio-Video Interleaved (.avi) com codificao divX ou Xvid, MPEG-4 e WAVE (.wav).

Para o intercmbio de informaes georreferenciadas, deve-se adotar: GML (verso 2.0 ou superior),

ShapeFile ou GeoTIFF.

Por fim, no que diz respeito compactao de arquivos para envio, recomenda-se todos os principais

formatos atualmente em uso, quais sejam: ZIP (.zip), GNU ZIP (.gz) e pacote TAR (.tar, .tgz).


3.1.3.2 Especificaes para TV Digital

Tabela 13: TV Digital

Componente Especificao SituaoTransmisso Norma ABNT NBR 15601

Parte 1 Sistema de transmissoA

Codificao Norma ABNT NBR 15602Parte 1 Codificao de VdeoParte 2 Codificao de udioParte 3 Sistema de multiplexao de sinais

A

Multiplexao Norma ABNT NBR 15603Parte 1 Servios de informao do sistema de radiodifusoParte 2 Sintaxes e definies da informao bsica de SIParte 3 Sintaxe e definio da informao estendida do SI

A

Receptores Norma ABNT NBR 15604Parte 1 Receptores

A

Segurana Norma ABNT NBR 15605Parte 1 Tpicos de segurana

A

Middleware Norma ABNT NBR 15606Parte 1 Codificao de dadosParte 2 Ginga-NCL para receptores fixos e mveisLinguagem de aplicao XML para codificao de aplicaesParte 3 Especificao de transmisso de dadosParte 5 Ginga-NCL para receptores portteisLinguagem de aplicao XML para codificao de aplicaesParte 6 Java DTV 1.3Parte 7 Ginga-NCL Diretrizes Operacionais paraas ABNT NBR15606-2 e 15606-5

A

Canal de Interatividade

Norma ABNT NBR 15607Parte 1 Protocolos, interfaces fsicas e interfaces de software

A

Guia de Operao

Norma ABNT NBR 15608Parte 1 Sistema de Transmisso Guia para implementao da ABNTNBR 15601Parte 2 Codificao de vdeo, udio e multiplexao Guia para implementao da ABNT NBR 15602Parte 3 Multiplexao e servio de informao (SI)Guia de implementao da ABNT NBR 15603

A

Acessibilidade ABNT NBR 15610Parte 1 Ferramentas de textoParte 2 Funcionalidades sonoras

A

O SBTVD (Sistema Brasileiro de Televiso Digital), ora em implantao e com cobertura nacional

prevista para dezembro de 2016, alm de propiciar som e imagem digitais de superior qualidade tcnica,

permite ao usurio (ou telespectador) interagir com o aparelho de televiso atravs de seu controle remoto.

Isto traz televiso a possibilidade de torn-la meio de acesso a servios como compras, acesso a bancos

e opes diversas de recreao e lazer. Mais importante ainda, isso a transforma em canal de grande

potencial de relacionamento entre governo e sociedade. Atividades como tele-educao, consultas ao

FGTS, ao PIS e a outros programas sociais do governo, dentre outras, faro com que os cidados passem

de uma atividade essencialmente passiva para uma atividade participativa. A ePING adota, s

implementaes de interatividade para a TV digital, a aderncia s normas pertinentes publicadas pela

ABNT (Associao Brasileira de Normas Tcnicas), o rgo responsvel pela normalizao tcnica no pas.


Uma recomendao da ePING na implementao de solues para a TV digital digna de nota a do

Ginga, um middleware aberto para o desenvolvimento de aplicativos para o SBTVD. Ele constitudo por

um conjunto de tecnologias padronizadas e de inovaes brasileiras, sendo organizado em dois

subsistemas: (i) Ginga-J, para aplicaes procedurais no ambiente de desenvolvimento Java, e (ii) Ginga-

NCL, para aplicaes declarativas escritas em NCL (Nested Context Language). O Ginga resultado de

projetos de pesquisa coordenados pelo Laboratrio de Sistemas Multimdia da PUC-Rio, em conjunto com o

Laboratrio de Aplicaes de Vdeo Digital da Universidade Federal da Paraba (GINGA, 2006).


3.1.4. Organizao e Intercmbio de Informaes Segmento 4

3.1.4.1 Especificaes para Tratamento e Transferncia de Dados

Tabela 14: Tratamento e Transferncia de Dados

Componentes Especificao Situao

Linguagem para intercmbio de dadosXML

AJSON

Transformao de dados XSLXSLT A

Definio dos dados para intercmbio XML Schema A

Informaes georreferenciadas catlogo de feies

Estruturao de Dados Geoespaciais Vetoriais (EDGV) como definido pela CONCAR

R

Para a criao da informao que ser enviada a outro sistema ou unidade de processamento

computacional, a ePING adota, como formato padro, o XML. Para a verificao das regras de formao

dos dados, adota-se o padro XML Schema. Finalmente, para a transformao dos dados com o objetivo de

apresentao ao usurio final, adota-se o XLS.

3.1.4.1.1 Linguagem para Intercmbio de Dados (XML)

O uso de XML como linguagem para representao de dados uma pea fundamental no contexto da

interoperabilidade semntica, pois representa tanto os aspectos conceituais quanto tecnolgicos associados

a uma arquitetura de software que se preocupa em organizar a informao, ao mesmo tempo em que

promove o seu intercmbio. Entretanto, lidar com essa tecnologia no tarefa trivial. Pelo contrrio, exige

planejamento e estratgias de projeto elaboradas pela equipe de arquitetos, projetistas e desenvolvedores

de software.

Logo, recomendam-se os seguintes passos para o uso adequado de XML nas instituies pblicas:

Posicione a tecnologia XML no conjunto de componentes da arquitetura de software adotada.

Realize a etapa de modelagem dos arquivos XML.

Defina padres para nomear os elementos do arquivo XML.

Escolha a API correta (DOM, SAX ou Data Binding).

Quanto ao posicionamento da tecnologia XML a uma arquitetura de software definida, sugerem-se

quatro abordagens: (i) utilizar XML para o transporte de informaes dentro da prpria aplicao a ser

desenvolvida; (ii) utilizar XML para o transporte de informaes entre aplicaes; (iii) utilizar XML como

conversor de dados no contexto de uma aplicao; e (iv) utilizar XML como conversor de dados no contexto

de vrias aplicaes (ERL, 2004).


Quando o XML utilizado para o transporte de informaes dentro da prpria aplicao a ser

desenvolvida, importante que se identifique as camadas da aplicao onde a informao ser originada e

onde a informao ser recepcionada. Com isso, verifica-se a consistncia do fluxo de dados dentro da

prpria aplicao e evita-se o excesso de trfego de informaes desnecessrias. A Figura 5 ilustra esse

uso do XML, considerando duas camadas de uma arquitetura MVC (Model-View-Controller).

Figura 5: XML utilizado para transportar dados dentro de uma aplicao.

Quando o XML utilizado para o transporte de informaes entre aplicaes, a ePING adota como

padro o uso da tecnologia de Web Services. Assim, a informao em formato XML transportada atravs

de mensagens SOAP. Para saber mais sobre Web Services, consulte a seo 3.6.4 neste documento, que

trata do assunto sob a tica da interoperabilidade tcnica. A Figura 6 ilustra o processo de transporte de um

arquivo XML, considerando o uso da tecnologia de Web Services.

Figura 6: XML utilizado para transportar dados com a tecnologia de Web Services.

Quando o XML utilizado como conversor de dados no contexto de uma aplicao, devem-se utilizar

ferramentas especficas para realizar a converso. A escolha do conversor mais adequado deve considerar

o uso de APIs (Application Programming Interfaces) especficas para o tratamento de arquivos no formato

XML (DOM, SAX ou Data Binding). A Figura 7 ilustra o processo de utilizao de XML como conversor de

dados no contexto de uma aplicao.


Figura 7: XML utilizado como conversor de dados no contexto de uma aplicao.

Quando o XML utilizado para consolidar informaes de diferentes fontes de dados, uma aplicao

(consumidor) invoca o servio de troca de dados em outra aplicao (provedor) utilizando a tecnologia de

Web Services. A aplicao de destino, por sua vez, processa a requisio utilizando-se de um conversor de

dados XML que pode se comunicar com outras partes do sistema de destino para executar o

processamento. A Figura 8 ilustra esse caso de utilizao de XML.

Figura 8: XML utilizado como conversor de dados no contexto de vrias aplicaes.

Aps o posicionamento da tecnologia XML em relao arquitetura de software utilizada, recomenda-

se a realizao da modelagem dos arquivos XML. Esta , sem dvida, a atividade mais importante para o

projeto de sistemas que interoperam atravs da tecnologia XML, pois atravs dela, que se minimizam as

chances de alterao da estrutura do arquivo XML no futuro. Logo, os profissionais de TI devem

compreender que os arquivos XML so comparveis s estruturas de bases de dados, no sentido de que

tambm mantm as informaes para uso futuro. Isso implica em dizer que, assim como os bancos de

dados necessitam de modelos, a estrutura dos arquivos XML tambm precisa ser modelada. A Figura 9

fornece uma comparao das estruturas de banco de dados com aquelas em formato XML (ERL, 2004).

Como se pode perceber, os esquemas de banco de dados representam o resultado da modelagem de

dados no contexto de um SGBD (Sistema Gerenciador de Banco de Dados). Da mesma maneira, os XML

Schemas representam o resultado da modelagem dos arquivos XML, pois ditam as regras para a validao

da estrutura de dados de acordo com os requisitos de negcio que se pretende atender.


Figura 9: Comparao das tecnologias de Banco de Dados e XML (Modificado de Erl, 2004)

Um ponto de grande importncia a ser observado pelos profissionais de TI durante a modelagem dos

arquivos XML diz respeito nomeao dos elementos que compem esse arquivo propriamente dito. Este

aspecto da modelagem em XML bastante controverso se o considerarmos sob o ponto de vista da

interoperabilidade semntica e dos requisitos tcnicos de desempenho dos sistemas. Por um lado, ter um

nome de elemento XML mais completo e consequentemente maior bom para garantir a compreenso

daquele item de dado, o que atende ao requisito da interoperabilidade semntica. Por outro lado, modelar

elementos XML muito extensos gera arquivos relativamente maiores e que exigem melhor desempenho das

aplicaes para process-los, e tambm maior banda de rede para distribu-los. Assim, essa Cartilha

Tcnica sugere as seguintes prticas para lidar com esse tipo de problema:

Identifique claramente quem sero os consumidores dos arquivos XML a serem modelados. Caso tais

arquivos sejam consumidos apenas por sistemas e no por pessoas, considere reduzir o tamanho dos

arquivos, utilizando nomes menores para os elementos XML.

Para atender aos requisitos de interoperabilidade semntica, faa uso de comentrios sempre que

identificar que alguns elementos foram nomeados de forma muito reduzida.

Utilize nomes genricos, evitando incluir nome de departamentos ou do rgo diretamente no nome dos

elementos XML.

Evite redundncias. Sempre que um elemento XML pertencer a outro elemento-pai, evite repetir o nome

do elemento-pai quando nomear o elemento filho. Por exemplo, um elemento NumCodigoItemNotaFiscal

seria melhor nomeado como NumItem ou CodItem, pois o mesmo j pertence a um elemento-pai que

corresponde aos Itens de uma Nota Fiscal.

Para distribuir arquivos XML extensos pela rede, considere a utilizao de tecnologias de compresso de

dados.

Guia de Interoperabilidade Cartilha Técnica 2015

Documents

Transcript of Guia de Interoperabilidade Cartilha Técnica 2015