Juliana Jenny Kolb
Home > Arquitetura de Computadores > e-Ping
e-Ping: Parte II – Especificação Técnica dos Componentes da ePING
1. Interconexão
1.1. Especificações Técnicas
A = Adotado
R = Recomendado
T = Em Transição
E = Em Estudo
| Componente | Especificação | SIT |
| Endereços de caixa postal eletrônica |
As regras para definição dos nomes das caixas postais de correio eletrônico deverão seguir ao estabelecido no documento “Padrão de Formação de Endereços de Correio Eletrônico – Caixas Postais Individuais” |
A |
| Transporte de mensagem eletrônica |
Utilizar produtos de mensageria eletrônica que suportam interfaces em conformidade com SMTP/MIME para transferência de mensagens. RFC correlacionadas: RFC 5321, RFC 5322, RFC 2045, RFC 2046, RFC 3676, RFC 2047, RFC 2231 (atualização das RFC 2045, 2047 e 2183), RFC 2183, RFC 4288, RFC 4289, RFC 3023 e RFC 2049. |
A |
| Acesso à caixa postal | Post Office Protocol – POP3 para acesso remoto a caixa postal. RFC correlacionada: RFC 1939 (atualizada pela RFC 1957 e RFC 2449). |
T |
| Internet Message Access Protocol –IMAP para acesso remoto à caixa postal. RFCs correlacionadas: RFC 2342 (atualizada pela RFC 4466), RFC 2910 (atualizada pela RFC 3380, RFC 3381, RFC 3382, RFC 3510 e RFC 3995), RFC 2971, RFC 3501, RFC 3502 e RFC 3503. |
A |
| Mensageria em Tempo Rea |
O modelo e requisitos para Instant Messaging and Presence Protocol (IMPP) são definidos pela RFC 2778 e RFC 2779. |
T |
| O modelo e requisitos para Extensible Messaging and Presence Protocol (XMPP) são definidos pela RFC 6120 e atualizada pela RFC 6122. |
A |
| AntiSpam – Gerenciamento da Porta 25 |
Implementar submissão de e-mail via porta 587/TCP com autenticação, reservando a porta 25/TCP apenas para transporte entre servidores SMTP, conforme recomendação CGI / Cert.br http://www.cert.br/ |
R |
| Protocolo de transferência de hipertexto |
Utilizar HTTP/1.1 (RFC 2616, atualizada pelas RFCs 2817, 5785, 6266 e 6585). |
A |
| Protocolos de transferência de arquivos |
FTP (com re-inicialização e recuperação) conforme RFC 959 (atualizada pela RFC 2228, RFC 2640, RFC 2773, RFC 3659 e RFC 5797) e HTTP conforme RFC 2616 (atualizada pelas RFCs 2817, 5785, 6266 e 6585) para transferência de arquivos. SFTP (Secure File Transfer Protocol) conforme RFC 913 |
A |
| Diretório | LDAP v3 deverá ser utilizado para acesso geral ao diretório OpenLDAP, conforme RFC 4510. |
A |
| Sincronismo de tempo |
RFC 5905 IETF – Network Time Protocol – NTP version 4.0. |
A |
| Serviços de Nomeação de Domínio |
O DNS deve ser utilizado para resolução de nomes de domínios Internet, conforme a RFC 1035 (atualizada pela RFC 1183, RFC 1348, RFC 1876, RFC 1982, RFC 1995, RFC 1996, RFC 2065, RFC 2136, RFC 2181, RFC 2137, RFC 2308, RFC 2535, RFC 1101, RFC 3425, RFC 3658, RFC 4033, RFC 4034, RFC 4035, RFC 4343, RFC 5936 e RFC 5966). Por sua vez, as diretivas de nomeação de domínio do governo brasileiro são encontradas na Resolução nº 7 do Comitê Executivo do Governo Eletrônico, no endereço eletrônico https://www.planalto.gov.br/ccivil_03/Resolução/2002 /RES07-02web.htm Além dessas diretivas, por decisão do Comitê Gestor da Internet no Brasil, a nomeação de domínios obedece às orientações do Ministério do Planejamento, Orçamento e Gestão, a quem compete gerenciar os domínios .GOV.BR. As particularidades de outros níveis de governo, como por exemplo, os domínios dos governos das Unidades da Federação, que incluem a sigla da UF na composição dos endereços, são abordadas no endereço eletrônico http://registro.br/faq/faq1.html#12 |
A |
| Protocolos de sinalização |
Uso do Protocolo de Inicialização de Sessão (SIP), definido pela RFC 3261 (atualizada pela RFC , RFC3265, RFC4320, RFC4916, RFC5393, RFC5621, RFC5626, RFC5630, RFC5922, RFC5954 e RFC6026), como protocolo de controle na camada de aplicação (sinalização) para criar, modificar e terminar sessões com um ou mais participantes. |
A |
| Uso do protocolo H.323 em sistemas de comunicação multimídia baseado em pacotes, definido pela ITU-T (International Telecommunication Union Telecommunication Standardization sector) |
T |
| Protocolos de gerenciamento de rede |
Uso do protocolo SNMP, definido pelas RFC 3411 (atualizada pela RFC 5343 e RFC 5590) e 3418, como protocolo de gerência de rede. |
T – versão 2
R – versão 3 |
| Protocolo de troca de informações estruturadas em plataforma descentralizada e/ou distribuída |
Vide Tabela 17 – Especificações para Áreas de Integração para Governo Eletrônico – Web Services |
| Protocolo de análise de tráfego de rede |
IPFix (RFC 5101, RFC 5102 e RFC 5103) | E |
| Protocolo de Rede Definida por Software |
Software-Defined Networking | E |
| Infraestrutura como Serviço – (serviços em nuvem) |
Serviço em nuvem prestado por provedor compreendendo processamento, armazenamento (storage), rede e outros recursos computacionais, nos quais o órgão contratante pode implementar e executar softwares ou aplicações. O serviço é realizado mediante responsabilidade compartilhada, entre provedor e contratante do serviço. Cabe, por exemplo, ao provedor do serviço gerenciar a infraestrutura do serviço em nuvem, e ao contratante gerenciar sistemas operacionais. Referência: NIST Definition of Cloud Computing – Special Publication 800-145 |
E |
| Software como Serviço (serviços em nuvem) |
Serviço de consumo de aplicação ou software executados por um provedor. As aplicações são acessíveis por navegador web ou por interfaces web – Software as a Service (SaaS). O serviço é realizado mediante responsabilidade compartilhada, entre provedor e contratante do serviço. Cabe, por exemplo, ao provedor do serviço gerenciar a infraestrutura do serviço em nuvem, e ao contratante gerenciar as configurações do software/aplicação relacionadas aos usuários. Referência: NIST Definition of Cloud Computing – Special Publication 800-145 |
E |
| Serviços em Nuvem | Nuvem Privada – A infraestrutura do serviço em nuvem é provida para uso exclusivo de uma única organização, a qual pode ter múltiplos usuários. Pode ser da própria organização ou operada por terceiros, ou uma combinação. Referência: NIST Definition of Cloud Computing – Special Publication 800-145 |
E |
| Nuvem Pública – A infraestrutura do serviço em nuvem é provida para uso do público em geral. Pode ser da própria organização ou operada por terceiros, ou uma combinação. Referência: NIST Definition of Cloud Computing – Special Publication 800-145 |
E |
| Nuvem Híbrida – A infraestrutura do serviço em nuvem é composta de duas ou mais estruturas de nuvem distintas, mas estão unidas por tecnologia padronizada ou proprietária que permite portabilidade dos dados e aplicações. Referência: NIST Definition of Cloud Computing – Special Publication 800-145 |
E |
| Interface de gerenciamento de dados em nuvem |
Interface para gerenciamento de dados em nuvem. Referência: utilizar CDMI (RFC 6208) |
E |
| Portabilidade e Interoperabilidade de perfis em nuvem |
Guia IEEE para Portabilidade e Interoperabilidade de perfis em nuvem (CPIP). Referência: IEEE P2301 (rascunho) |
E |
| Interface aberta para computação em nuvem |
Interface aberta para computação em nuvem (OCCI). Referência: GFD.P-R.184 |
E |
| Formato Aberto de Virtualização |
Formato Aberto de Virtualização. Referência: ISO/IEC 17203:2011 https://openvirtualizationalliance.org/ |
E |
Tabela 2 Rede/Transporte
| Componente | Especificação | SIT |
| Componente | A = Adotado R = Recomendado T = Em Transição E = Em Estudo |
SIT |
| Transporte | TCP (RFC 793) | A |
| UDP (RFC 768) quando necessário, sujeito às limitações de segurança. | A |
| Intercomunicação LAN/WAN |
IPv6 conforme RFC 2460 (atualizada pela RFC 5095, RFC 5722 e RFC 5871). |
A |
| IPv4 conforme RFC 791 (atualizada pela RFC 1349). | T |
| Comutação por Label |
Quando necessário, o tráfego de rede pode ser otimizado pelo uso do MPLS (RFC 3031), devendo este possuir, no mínimo, quatro classes de serviço. No caso de interconexão com a rede pública com comutação por Label, não haverá troca de Label entre a rede privada do governo e a rede pública. Neste caso deve-se adotar interface NNI (Option A) entre a rede do governo e a rede pública. |
A |
| Qualidade de serviço |
Adoção de uma arquitetura para serviços diferenciados pelo uso do Diffserv (RFC 2475, atualizada pela RFC 3260). |
A |
2. Segurança
2.1. Políticas Técnicas
7.1.1 Os dados, informações e sistemas de informação do governo devem ser protegidos contra ameaças, de forma a reduzir riscos e garantir a integridade, confidencialidade, disponibilidade e autenticidade, observando-se as normas do governo federal referentes a Política de Segurança da Informação e Comunicações, favorecendo assim, a interoperabilidade.
7.1.2 Os dados e informações devem ser mantidos com o mesmo nível de proteção, independentemente do meio em que estejam sendo processados, armazenados ou trafegando.
7.1.3 As informações classificadas e sensíveis que trafegam em redes inseguras, incluindo as sem fio, devem ser criptografadas de modo adequado, conforme os componentes de segurança especificados neste documento.
7.1.4 Os requisitos de segurança da informação dos serviços e de infraestrutura devem ser identificados e tratados de acordo com a classificação da informação, níveis de serviço definidos e com o resultado da análise de riscos.
7.1.5 A segurança deve ser tratada de forma preventiva. Para os sistemas que apoiam processos críticos, devem ser elaborados planos de continuidade, nos quais serão tratados os riscos residuais, visando atender aos níveis mínimos de produção.
7.1.6 A segurança é um processo que deve estar inserido em todas as etapas do ciclo de desenvolvimento de um sistema.
7.1.7 Os sistemas devem possuir registros históricos (logs) para permitir auditorias e provas materiais, sendo imprescindível a adoção de um sistema de sincronismo de tempo centralizado, bem como a utilização de mecanismos que garantam a autenticidade dos registros armazenados,
se possível, com assinatura digital.
7.1.8 Nas redes sem fio metropolitanas recomenda-se a adoção de valores aleatórios nas associações de segurança, diferentes identificadores para cada serviço e a limitação do tempo de vida das chaves de autorização.
7.1.9 O uso de criptografia e certificação digital, para a proteção do tráfego, armazenamento de dados, controle de acesso, assinatura digital e assinatura de código deve estar em conformidade com as regras da ICP-Brasil.
7.1.10 A documentação dos sistemas, dos controles de segurança e das topologias dos ambientes deve ser mantida atualizada e protegida, mantendo-se grau de sigilo compatível.
7.1.11 Os usuários devem conhecer suas responsabilidades com relação à segurança e devem estar capacitados para a realização de suas tarefas e utilização correta dos meios de acesso.
7.1.12 Os órgãos da APF, visando a melhoria da segurança, devem ter como referência:
Decreto nº 3.505/2000; Decreto nº 7.845/2002;
a Instrução Normativa nº 01/2008 – GSI/PR e suas Normas Complementares; a Instrução Normativa nº 02/2013 – GSI/PR;
a Instrução Normativa nº 3/2013 – GSI/PR;
e as normas NBR ISO/IEC 27001:2006 – sistemas de gestão de segurança da informação;
NBR ISO/IEC 27002:2005 – código de prática para a gestão da segurança da informação;
NBR ISO/IEC 27003:2011 – diretrizes para implantação de um sistema de gestão da segurança da informação – versão corrigida 2015;
NBR ISO/IEC 27004:2010 – medição ;
NBR ISO/IEC 27005:2008 – Gestão de riscos de segurança da informação NBR ISO/IEC 27011:2008 – diretrizes para gestão da segurança da informação para organizações de telecomunicações baseadas na ABNT NBR ISO/IEC 27002;
e NBR ABNT NBR ISO 22313:2015 – Segurança da sociedade – Sistemas de gestão de continuidade de negócios – Orientações e ABNT NBR ISO 22301:2013 – sistema de gestão de continuidade de negócios – Requisitos.
7.1.13 Para especificações sobre cartões inteligentes e tokens, deverão ser adotados os requisitos contidos nos normativos que tratam da homologação de equipamentos e sistemas no âmbito da Infraestrutura de Chaves Públicas Brasileira – ICP-Brasil (http://www.iti.gov.br). Estes requisitos, observados por produtos homologados na ICP-Brasil, tais como mídias que armazenam os certificados digitais e respectivas leitoras, além dos sistemas e equipamentos necessários à realização da certificação digital, estabelecem padrões e especificações técnicas mínimas, a fim de garantir a sua interoperabilidade e a confiabilidade dos recursos de segurança da informação por eles utilizados. É importante observar que não deve haver impedimento de acesso a dado
armazenado em um cartão, como possíveis restrições impostas por licenciamento de uso de interface de software (middleware) para que seja garantida a interoperabilidade.
https://www.governoeletronico.gov.br/documentos-e-arquivos/e-PING_v2016_26022016.pdf