e-Ping: Parte II – Especificação Técnica dos Componentes da ePING

Juliana Jenny Kolb

teste seu conhecimento

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

Deixe uma resposta