Projeto Mercosul Digital 5/26/23

Termo de Referência para a Autoridade Certificadora e Autoridade de Registro Online de Primeiro nível para o

UruguaiConsultor Técnico Mercosul Digital

Acrônimos

Acrônimo Descrição AC Autoridade CertificadoraACL Access Control ListANSI American National Standards InstituteAR Autoridade de RegistroAAP Agente AprovadorAVP Agente de Validação PresencialBCV Business Continuance VolumesBGP Border Gateway ProtocolBICSI Building Industry Consulting Service InternationalCC Common CriteriaCE Comunidade EuropéiaCEN Comité Européen de NormalisationCLI Command Line InterfaceCMC Certificate Management over CMSCMP Certificate management protocolCMS Cryptographic Message SyntaxCSP Cryptographic Service ProviderCSR Certificate Signing RequestCWA CEN Workshop AgreementDAC Discretionary Access ControlDER Distinguished Encoding RulesDES Data Encryption StandardDMZ Demilitarized ZoneDN Distinguished NameDNS Domain name serverDPC Declaração de Práticas de CertificaçãoEAL Evaluation Assurance LevelECDSA Elliptic Curve Digital Signature AlgorithmEIA Electronic Industries AllianceEF Entidade FinalETSI European Telecommunications Standards InstituteDER Distinguished Encoding RulesFATA Fiber Attached Technology AdaptedFC Fiber ChannelFIPS Federal Information Processing Standards

1

GUI Grafic user interfaceHBA Host Bus AdaptersHD Hard DiskHSM Hardware Security ModuleHTTP Hypertext Transfer ProtocolHTTPS Hypertext Transfer Protocol SecureICMP Internet Control Message ProtocolICP Infra-Estrutura de Chaves PúblicasIDS Intrusion Detection SystemIP Internet ProtocolIPS Intrusion Prevension SystemISP Prevedor de Serviços de InternetISO International Organization for StandardizationJCE Java Cryptographic ExtensionLAN Local Area NetworkLCR Lista de Certificados RevogadosLDAP Lightweight Directory Access ProtocolMAC Mandatory Access ControlNAT Network Address TranslationNFS Network file systemNIST National Institute of Standards and TechnologyNTP Network Time ProtocolOCSP On-line Certificate Status ProtocolOSPF Open Shortest Path FirstPCS Parâmetro críticos de SegurançaPED PIN Entry DevicePIN Personal Identification NumberPKCS Public Key Cryptography StandardPMP Project Management ProfessionalQoS Quality of ServiceRAID Redundant Array of Inexpensive DisksRAM Random Access MemoryRBAC Role-Based Access ControlRIP Routing Information ProtocolRSA Rivest Shamir AdlemanSAN Storage Area NetworkSAS Serial Attached SCSISATA Serial Advanced Technology AttachmentSMIME Secure/Multipurpose Internet Mail ExtensionsSGCI Sistema de Gestão de Segurança da InformaçãoSNMP Simple Network Management ProtocolTIA Telecommunications Industry AssociationUDP User Datagram ProtocolVLAN Virtual LANVoIP Voice over Internet ProtocolKVM Keyboard, Video and MouseLUN Logical Unit NumberWAN Wide Area Network

2

Capítulo 1

Informação Geral

1.1 Países BeneficiáriosOs beneficiários da aquisição dos equipamentos e serviços são os Países Argentina, Paraguai e Uruguai, integrantes do grupo do mercado comum (GMC), agência executiva do mercado comum do sul (MERCOSUL).

1.2 Órgão de ContrataçãoO órgão de contratação é a Rede Nacional de Ensino e Pesquisa (RNP) no Brasil. O GMC delegou a execução do projeto à RNP, situada no Rio de Janeiro, Brasil.

1.3 Informação Relevante sobre o MERCOSULO Mercado Comum do Sul (MERCOSUL) foi criado pelo Tratado de Assunção de 26 de março de 1991, subscrito por Argentina, Brasil, Paraguai e Uruguai. O Conselho do Mercado Comum (CMC) é o órgão superior do MERCOSUL, ao qual incumbe a condução política do processo de integração e que toma as decisões para assegurar o cumprimento dos objetivos estabelecidos no Tratado de Assunção. É um órgão com capacidade decisória e de natureza governamental. Está integrado pelos Ministérios de Relações Exteriores e os Ministérios de Economia dos estados membros.

O Grupo Mercado Comum (GMC) é o órgão executivo do MERCOSUL, integrado por quatro membros titulares e quatro membros alternados por país, designados pelos respectivos Governos, entre os quais deverão constar, obrigatoriamente, representantes dos Ministérios de Relações Exteriores, dos de Economia (ou equivalentes) e dos Bancos Centrais.

O GMC é um órgão com capacidade decisória e de natureza intergovernamental. O GMC tem entre suas funções negociar, por delegação expressa do Conselho do Mercado Comum, acordos em nome do MERCOSUL com Países terceiros, grupos de Países e órgãos internacionais. O GMC se pronuncia mediante resoluções que são obrigatórias para os estados membros.

A Reunião Especializada em Ciência e Tecnologia (RECyT) do MERCOSUL foi proposta pelos Presidentes dos estados membros durante a segunda reunião do GMC realizada em junho de 1992, em Las Leñas, Argentina. Sua criação fez-se efetiva na quinta reunião do GMC realizada em Buenos Aires, Argentina. O propósito da RECyT é "O fortalecimento da capacidade científica e tecnológica dos estados membros, estimulando o desenvolvimento de sua competitividade internacional e o fomento da pesquisa. O desenvolvimento destes objetivos promove a cooperação em matéria de pesquisa e desenvolvimento de tecnologia; e a realização de programas de pesquisa e desenvolvimento tecnológico, estabelecendo ações para a difusão dos resultados das pesquisas e para sua utilização". A RECyT está formada por uma equipe de coordenação e 3 comissões: uma Comissão de Apoio ao Desenvolvimento Científico e Tecnológico, uma Comissão da Sociedade da Informação e uma Comissão de Apoio ao Desenvolvimento das Biotecnologias. O presente projeto se

3

vincula diretamente com os propósitos da comissão da Sociedade da Informação da RECyT.

A estratégia central do Projeto é estabelecer um centro de coordenação entre todos os agentes relevantes no campo da Sociedade da Informação (e do SGT-13) nos Países do MERCOSUL. Para isto, serão criados quatro Pólos Tecnológicos, um por país, integrados por representantes das entidades públicas e privadas que desenvolverão atividades nestas áreas dentro do MERCOSUL.

O subgrupo de trabalho n° 13 – Comércio Eletrônico – do MERCOSUL, tem defendido a necessidade de levar adiante negociações para obter mecanismos comuns de reconhecimento de certificados digitais entre os estados membros. Como resultado, dois projetos foram concebidos em Junho de 2006, passaram por consultas internas nos estados membros e foram aprovados pelo Grupo Mercado Comum (GMC):

• MERCOSUL/GMC EXT./RES. Nº 34/06 - Diretrizes para a celebração de acordos de reconhecimento mútuo de assinaturas eletrônicas avançadas no âmbito do MERCOSUL;

• MERCOSUL/GMC EXT./RES. Nº 37/06 - Reconhecimento da eficácia jurídica do documento eletrônico, a assinatura eletrônica e a assinatura eletrônica avançada no âmbito do MERCOSUL.

1.4 Situação Atual do SetorFoi identificado que o bloco MERCOSUL apresenta parâmetros gerais de uso da Sociedade da Informação muito inferiores aos que existem na Europa, América do Norte e certos Países asiáticos: uso das TIC, banda larga, comércio eletrônico, governo eletrônico, transações seguras, assinatura eletrônica, sites Web, etc. Além disso existem grandes diferenciais sociais entre cidadãos e funcionários de empresas que utilizam as TIC em sua vida pessoal e profissional com respeito àqueles que não têm acesso aos mesmos recursos.

No MERCOSUL, não existe uma política comum da sociedade da informação da mesma forma como faz a União Européia. Sem dúvida alguns avanços ocorreram neste sentido. Em 1992, foi criada a "Reunião Especializada de Ciência e Tecnologia" (RECyT) - composta por uma Comissão de "Desenvolvimento da Sociedade da Informação" - e no ano 2000, foi criado o Sub-Grupo de Trabalho 13 (SGT 13) – Comércio Eletrônico. Em maio de 2006, foi realizada a primeira reunião de Ministros e Autoridades em Ciência e Tecnologia do MERCOSUL e Estados Associados na qual se estabeleceu o "Plano de Ação de Buenos Aires".

Entre as atividades definidas neste plano, uma diz respeito ao impulso à capacitação mediante esquemas como uma Escola Virtual para a Sociedade da Informação. Pelo fato de não existir uma política comum da sociedade da informação no MERCOSUL, o tema não é discutido sistematicamente na agenda do bloco. Isto pode ser explicado por três razões principais:

• Falta de compreensão do paradigma da sociedade da informação para o desenvolvimento de estratégias e o estabelecimento de políticas nacionais e regionais. A falta de entendimento faz com que o tema não seja tratado, ou pelo menos, não seja considerado com uma visão articulada, e sim fragmentada. Como resultado, os impactos das ações orientadas à sociedade da informação no MERCOSUL são fracos;

4

• Insuficiência de recursos humanos especializados em TIC para o entendimento e o desenvolvimento de aplicações que favoreçam seu aproveitamento. Não há capital humano suficiente, em quantidade e em níveis de especialização necessários, para liderar o desenvolvimento de aplicações e usos inovadores das TIC. O efeito resultante é que diversas demandas em setores pertinentes a sociedade da informação como Saúde, Educação, Indústria e Comércio, não são atendidas adequadamente; ou então se dificulta o diálogo do MERCOSUL com terceiros em matéria de negociação de TIC;

• A existência de assimetrias entre os Países do MERCOSUL quanto aos recursos disponíveis, normas, infraestrutura e nível de desenvolvimento de aplicações das TIC, impõem obstáculos ao desenvolvimento de empreendimentos conjuntos. A falta de um equilíbrio intraregional – em especial dos marcos reguladores e das ferramentas tecnológicas – tem produzido, como conseqüência, experiências de comércio eletrônico intra-regional praticamente inexistentes; apesar do seu potencial como ferramenta de integração econômica e como parte da luta contra a pobreza e marginalização na região.

A Sociedade da Informação é formada por muitos elementos que os Países do MERCOSUL têm tentado promover: governo eletrônico, e-Saúde, ensino à distância, banda larga, etc. Este projeto não pode desenvolver todos estes elementos simultaneamente; é por isso que, com o fim de aumentar o impacto, ele está orientado ao aumento da capacitação de recursos humanos. O comércio eletrônico também será desenvolvido como elemento que, sem dúvida, tem grande potencial de contribuir e melhorar a integração dos Países do MERCOSUL. O projeto proposto foi inspirado no modelo de desenvolvimento da Sociedade da Informação da União Européia, fundamentado em três pilares: Educação, Infraestrutura e Inovação. Estes pilares se baseiam na iniciativa 2010 da EU – aumentando a sinergia da cooperação entre a Europa e Mercosul. Este projeto toca em dois pilares: Educação e Infraestrutura.

1.5 Objetivos do Projeto

1.5.1 Objetivo Geral do ProjetoPromover políticas e estratégias comuns ao Mercosul na área da Sociedade da Informação e reduzir o desnível digital e as assimetrias, em matéria de Tecnologias da Informação e das Comunicações (TIC) na região.

1.5.2 Objetivos EspecíficosAumentar as competências e o uso das TIC entre as instâncias de decisão dos setores público, privado e da sociedade civil no MERCOSUL, através de ações comuns de capacitação, desenvolvimento das infraestruturas TIC relacionadas com a formação e aplicações de comércio eletrônico ao bloco.

5

Capítulo 2

Objetivos do Contrato2.1 Objetivo GeralEste contrato tem por objetivo geral a contratação de uma autoridade certificadora de primeiro nível online para complementar e fortalecer a infraestrutura de chaves públicas do Uruguai.

2.2 Objetivos EspecíficosOs objetivos do presente contrato são os seguintes:

1. Fornecimento dos componentes e serviços para a implantação da uma Autoridade Certificadora (AC) subordinada online e respectiva Autoridade de Registro (AR) para a Infraestrutura de Chaves Públicas do Uruguai. Os ambientes da AC e AR são compostos por uma instalação P rincipal , uma instalação de C ontingência e um ambiente de H omologação ;

2. Realizar a instalação, configuração, operacionalização e capacitação permitindo que Uruguai consiga de forma independente fornecer o serviço de certificação correspondente;

3. Realizar a auditoria interna correspondente na AC e AR que demonstre sua conformidade com os padrões solicitados pela regulamentação de assinatura digital do país.

2.3 Objeto da compra e alcance da licitaçãoA presente licitação pública internacional se direciona a empresas fornecedoras interessadas na entrega de equipamentos, sistemas e consultoria necessários a implementação de uma Autoridade Certificadora (AC) de primeiro nível (AC Online) no Uruguai, segundo as especificações e condições presentes neste documento.

A Tabela 1 apresenta um resumo dos equipamentos, sistemas e consultorias mínimos desta licitação, podendo ser realizada a aquisição do sistema completo ou de forma separada. Na coluna "Quantidade", são apresentados individualmente os quantitativos dos ambientes de Produção (P), Contingência (C) e de Homologação (H).

A lista de equipamento mínimos da Tabela 1 trata-se de uma lista "mínima" de equipamento, sistemas e serviços, e deverá ser complementada pelo ofertante tanto quanto necessário para viabilizar a implantação da AC de primeiro nível e respectiva AR. A adição de novos componentes deve ser acompanhada de respectiva justificativa técnica.

6

Tabela 1: Equipamentos, Sistemas e Consultoria para a AC Online UruguaiItem Quantidade Descrição Especificação mínima

P C H Total1 2 1 0 3 Servidor Anexo C.32 2 1 1 4 HSM de AC Online Anexo B.23 2 1 1 4 HSM de Aplicação Anexo B.34 1 1 1 3 Sistema de AC e AR Anexo A5 2 1 0 3 Firewall de Borda Anexo C.2.26 4 2 1 7 Switch Ethernet Anexo C.2.17 2 1 0 3 Switch KVM Anexo C.5.18 1 1 1 3 Serviço de instalação, configuração,

manutenção e transferência tecnológica

Capítulo 3

Especificação TécnicaA presente seção descreve os componentes e serviços que devem ser fornecidos para a implantação da uma Autoridade Certificadora (AC) subordinada online e respectiva Autoridade de Registro (AR) para a Infraestrutura de Chaves Públicas do Uruguai.

3.1 Da aquisição e serviços

3.1.1 Descrição geralAs instalações de contingência e de homologação devem possuir o mesmo conjunto de equipamentos exceto em relação a alguns elementos de redundância. A instalação de homologação tem por objetivo a verificação de conformidade das soluções em relação aos requisitos antes de que sejam instalados nos ambientes de produção e contingência. O ambiente de homologação deve conter um número mínimo de equipamentos de forma que seja possível essa verificação de conformidade.

3.1.2 TerminologiaOs termos abaixo, quando encontrados ao longo deste documento grafados em maiúsculas, DEVEM ser interpretados da seguinte forma [8]:

DEVE O uso do termo DEVE, EXIGIDO, PERMITIDO ou OBRIGATÓRIO significa que a definição é um requisito absoluto da especificação;

NÃO DEVE O uso do termo NÃO DEVE ou PROIBIDO significa que a definição é uma proibição absoluta na especificação;

RECOMENDADO O termo RECOMENDADO significa que a definição deveria ser considerada, porém podem existir razões válidas, em circunstâncias particulares, para não considerá-la, sendo que as implicações precisam ser entendidas e ponderadas cuidadosamente antes da escolha;

NÃO RECOMENDADO O termo NÃO RECOMENDADO significa que a

7

definição não deve ser considerada, porém podem existir razões válidas, em circunstâncias particulares, em que o comportamento possa ser aceitável ou útil, mas as implicações completas devem ser entendidas e ponderadas cuidadosamente antes da escolha;

PODE O termo PODE ou OPCIONAL significa que é um item realmente opcional. Um implementador pode optar por incluir o item, enquanto outro pode omitir o mesmo item. Uma aplicação que não inclui uma determinada opção DEVE estar preparada para interoperar com outra aplicação que inclui aquela opção, embora talvez com funcionalidade reduzida. No mesmo espírito, uma aplicação que inclui uma determinada opção DEVE estar preparada para interoperar com outra aplicação que não a inclui (exceto, é claro, para o recurso que a opção oferece).

3.1.3 PremissasO fornecedor deve assumir as seguintes premissas:

1. Os sistemas administrativos e de homologação ficam localizados no ambiente nível 2 de segurança. Supõe-se a existência de infraestrutura adequada para estas atividades, não sendo escopo deste processo o fornecimento infraestrutura física para o nível 2, exceto quando explicitamente determinado;

2. Os sistemas Firewall, os sistemas Web, AR e DNS externo da rede AR, os sistemas básicos de intranet, DNS interno e Log da rede servidores ficam localizados no ambiente nível 3 de segurança. Supõe-se a existência de infraestrutura adequada para estas atividades, não sendo escopo deste processo o fornecimento infraestrutura física para o nível 3, exceto quando explicitamente determinado;

3. O sistema de AC Online da rede sensível, fica localizado no ambiente nível 4 de segurança. Supõe-se a existência de infraestrutura adequada para estas atividades, não sendo escopo deste processo o fornecimento infraestrutura física para o nível 4, exceto quando explicitamente determinado;

4. Não é escopo o fornecimento de sistema de controle ambiental para os ambientes níveis 1, 2, 3 e 4;

5. Não é escopo o fornecimento de sistema de disponibilidade de energia para os ambientes níveis 1, 2, 3 e 4;

6. Em cada instalação predial, existe de dois pontos de rede com interface Ethernet 10/100TX provenientes de enlaces redundantes de acesso à Internet. Este sistema de comunicação de dados com a Internet não faz parte do escopo da aquisição.

7. Os sistemas e soluções para este termo de referência dizem respeito às soluções de tecnologia da informação e comunicação, excluindo-se toda e qualquer sistema ou equipamento de infraestrutura, tais como sistemas de ar refrigerado, de fornecimento de energia e de alarmes. Para tal, supõe-se a existência de infraestrutura adequada para a instalação desses sistemas e soluções.

8. Os treinamentos são somente aqueles necessários para que a equipe local possa acompanhar a instalação e configuração de todos os sistemas fornecidos, exceto quando explicitamente determinado.

8

3.1.4 Prazo de ExecuçãoO prazo de execução estimado para implantação é de 8 meses.

3.1.5 Requisitos gerais

1. Toda a infraestrutura DEVE atender às disposições das Diretrizes para política de Segurança da ICP-Uruguai.

2. Os sistemas DEVEM suportar os perfis de certificados definidos na política de Certificado da ICP-Uruguai.

3. As funcionalidades e uso de sistemas e componentes da estrutura estão resumidamente descritos. Todos os softwares, componentes, interfaces e infraestrutura necessárias para as funcionalidades mencionadas DEVEM ser considerados pelo fornecedor.

4. A CONTRATADA DEVE entregar a solução em condição de operação plena com sistemas e licenças necessários à operação.

5. As licenças de uso devem ser permanentes. Não são admitidas licenças vinculadas à quantidade de uso como, por exemplo, quantidade de certificados emitidos.

6. Todos os equipamentos e componentes DEVEM ser novos. Não são admitidos equipamentos usados ou recondicionados.

7. Todos os equipamentos DEVEM possuir alimentação elétrica multitensão (110/220V; 50/60 Hz).

3.1.6 Consultoria

1. A CONTRATADA DEVE elaborar com a participação da equipe técnica da ICP-Uruguai, os seguintes documentos:

(a) Customização da DPC; (b) Elaboração da política de Segurança; (c) Elaboração do Plano de Continuidade de Negócios; (d) Elaboração da Cerimônia de geração e backup de chaves; (e) Elaboração da Cerimônia de ativação de chave privada; (f) Elaboração da Cerimônia de restauração de backup de chave de HSM; (g) Elaboração da Cerimônia de instalação de chave privada em HSM de

contingência; (h) Elaboração da Cerimônia de destruição de chaves.

3.2 Da equipe técnica do projeto

1. A equipe alocada ao projeto DEVE ser composta por profissionais qualificados, com formação e experiência comprovada em gestão de projetos,

9

segurança da informação, área jurídica, certificação digital, dispositivos criptográficos smartcards, tokens e HSMs e tecnologia da informação e comunicação. A quantidade de profissionais deve ser suficiente para realizar as atividades de instalação, configuração, operação e capacitação da equipe contratante durante todo o período de implantação da solução. O profissional gerente deve permanecer integralmente dedicado as todas as atividades até a conclusão dessas e a aceitação final da contratante.

2. A empresa vencedora deverá prover uma equipe de no mínimo dois profissionais, sendo um deles o coordenador e supervisor das atividades desenvolvidas.

3. Na proposta devem ser especificadas as competências dos profissionais envolvidos no projeto e as atividades que estes desenvolverão junto ao contratante.

4. O fornecedor somente poderá alterar as pessoas designadas para equipe de instalação, configuração, operacionalização e capacitação de mútuo acordo com o contratante e sempre, e quando o substituto tenha competências similares, ou superiores. A aprovação final deverá ser fornecida pelo contratante.

5. Todos os profissionais devem possuir um bom domínio do idioma espanhol e/ou português oral e escrito. Ao menos uma pessoa da equipe deve apresentar total conhecimento da língua espanhola.

6. Os profissionais envolvidos da implantação da infraestrutura devem apresentar experiência prévia de pelo menos 3 anos na implantação de estruturas deste tipo.

3.3 Das Autoridades Certificadoras (AC) e de Registro (AR)

3.3.1 Visão geralA Autoridade Certificadora (AC) e a Autoridade de Registro (AR) são responsáveis pela emissão, expedição, distribuição, renovação, suspensão e revogação de certificados para Entidade Final (EF), segundo as práticas de certificação adotadas para a AC e AR. São também responsáveis pela emissão e distribuição periódica das Listas de Certificados Revogados (LCR).

A Tabela 3.1 apresenta a relação de componentes para aquisição para a infraestrutura da AC e AR.

Tabela 3.1: Relação de componentes para aquisição para a infraestrutura da AC e AR.Grupo Componentes Observação

Sistemas e serviços computacionais

Sistema de AC Inclui software, servidor e HSM

Sistema de AR Inclui software, servidor e HSM

Sistema WEB Inclui software, servidor e HSM

10

Sistema DNS externoSistema de serviços básicos para intranetSistema de gerenciamento de logsSistema de backup de dados

Rede de comunicaçãode dados

FirewallSwitch

Instalações Físicas Racks para os ambientesde produção, contingência e homologação.

Cada nível de segurança deverá ter seu próprio rack.

3.3.2 Sistemas e serviços computacionaisA solução deve possuir os seguintes sistemas e serviços computacionais:

1. Sistema de AC; 2. Sistema de AR; 3. Sistema WEB; 4. Sistema DNS externo; 5. Sistema de serviços básicos para intranet; 6. Sistema de gerenciamento de logs; 7. Sistema de backup de dados;

A Figura 1 apresenta o relacionamento entre os componentes funcionais de uma

Figura 1: Relacionamento entre os componentes funcionais de um Sistema de AC

Infraestrutura de Chaves Públicas definidos na RFC5280 [9]: Sistema de AC, Sistema de AR, Emissor de LCR e Repositório de Certificados e LCRs.

11

3.3.2.1 Sistema de ACO Sistema de Autoridade Certificadora é um sistema online responsável pela emissão, expedição, distribuição, renovação, suspensão e revogação de certificados para Entidade Final (EF), segundo as práticas de certificação adotadas para a AC. Também é responsável pela emissão periódica das Listas de Certificados Revogados (LCR). O Sistema de AC interage com o Sistema de AR, com o Emissor de LCR e com o Repositório de certificados e LCRs. É comum encontrar sistemas de AC que incorporam um ou mais desses sistemas. Por exemplo, O sistema de AC inclui o serviço de emissão de LCRs.

O Sistema de AC é composto pelo seguinte conjunto de componentes:Software de AC online O software de AC online é responsável pela emissão,

renovação, suspensão e revogação de certificados para Entidade Final (EF), fornecendo interfaces e realizando interação com componentes e periféricos. Também é responsável pela emissão periódica das Listas de Certificados Revogados (LCR);

Servidor É o máquina que hospeda o Software de AC. Além disso, ele possui interfaces para a rede local para o sistema de backup e para interação com o HSM;

HSM É o dispositivo criptográfico que gerencia o ciclo de vida das chaves criptográficas das Autoridades Certificadoras instanciadas pelo Software de AC online.

1. O software de AC DEVE atender aos requisitos definidos para "software para Autoridade Certificadora online" do Anexo A.2. O software de AC online é responsável pela emissão, renovação, suspensão e revogação de certificados para Entidade Final (EF), fornecendo interfaces e realizando interação com componentes e periféricos. Também é responsável pela emissão periódica das Listas de Certificados Revogados (LCR)

2. O servidor DEVE atender, no mínimo, aos requisitos definidos para o "Servidor"  do Anexo C.3. Também, DEVE possuir todos os assessórios necessários para operação do Sistema de AC.

3. DEVE ser fornecido um treinamento sobre Software de AC online (instalação, configuração e operação).

4. O HSM DEVE atender aos requisitos definidos para "HSM da Autoridade Certificadora online"  do Anexo B.

5. DEVE ser fornecido um treinamento sobre HSM para AC online (configuração e operação).

6. DEVEM ser fornecidas, no mínimo, as seguintes quantidades de sistemas de AC:

(a) Dois para a instalação principal; (b) Um para a instalação de contingência; (c) Um para o ambiente de homologação.

7. Na instalação principal, o Sistema de AC DEVE operar no modo de alta disponibilidade.

12

8. Todos os componentes do Sistema de AC da instalação principal DEVEM estar instalados em um mesmo compartimento nível 5. O sistema de AC DEVE estar conectado à "rede sensível".

9. Todos os componentes do Sistema de AC da instalação de contingência DEVEM estar instalados em um mesmo compartimento nível 5. O sistema de AC DEVE estar conectado à "rede sensível".

10. Todos os componentes do Sistema de AC do ambiente de homologação DEVEM estar instalados no rack do ambiente de homologação, localizado em ambiente nível 2. O sistema de AC DEVE estar conectado à "rede intranet".

11. O acesso remoto de usuário ao ambiente operacional do "servidor" DEVE ser permitido somente aos usuários autorizados cujo acesso seja proveniente da rede de operadores.

3.3.2.2 Sistema de ARO sistema de Autoridade de Registro (AR) é responsável pelo gerenciamento do processo de pedido de certificados à Autoridade Certificadora (AC), o que inclui o registro da entidade final, a validação presencial e o pedido de emissão do certificado à AC online. Também é responsável por disponibilizar o certificado emitido e sua cadeia de certificação à entidade final. O sistema de AR online também automatiza a emissão online de certificados através de interface WEB.

O sistema de AR é composto pelo seguinte conjunto de componentes:

Software de AR É responsável gerenciamento do processo de pedido de certificados à Autoridade Certificadora (AC), fornecendo interfaces e realizando interação com componentes e periféricos.

Servidor É utilizado para suportar o software de AR. Além disso, deve possuir interfaces para a rede local.

HSM É utilizado para proteção da chave privada da AR.

1. O software de AR DEVE atender aos requisitos definidos para "software para autoridade de registro"  do Anexo A.

2. DEVE ser fornecido um treinamento sobre Software de AR (instalação, configuração e operação).

3. O servidor deve atender, no mínimo, aos requisitos definidos para o Servidor do Anexo C.3. Também, DEVE possuir todos os assessórios necessários para operação do Sistema de AR.

4. O HSM DEVE atender aos requisitos definidos para "HSM para proteção de chave privada de aplicação"  do Anexo B.

5. DEVE ser fornecido um treinamento sobre HSM para sistemas (configuração e operação).

6. DEVEM ser fornecidas, no mínimo, as seguintes quantidades de sistemas de AR:

(a) Dois para a instalação principal;(b) Um para a instalação de contingência;

13

(c) Um para o ambiente de homologação.7. Na instalação principal, o sistema de AR deve operar no modo de alta

disponibilidade.8. Todos os componentes do Sistema de AR da instalação principal DEVEM

estar instalados em um mesmo rack. O sistema de AR DEVE estar conectado à "Rede AR".

9. Todos os componentes do Sistema de AR da instalação de contingência DEVEM estar instalados em um mesmo rack. O sistema de AR DEVE estar conectado à "Rede AR".

10. Todos os componentes do Sistema de AR do ambiente de homologação DEVEM estar instalados no rack do ambiente de homologação, localizado em ambiente nível 2. O sistema de AR DEVE estar conectado à "Rede Intranet".

11. O acesso remoto de usuário ao ambiente operacional do servidor DEVE ser permitido somente aos usuários autorizados cujo acesso seja proveniente da "Rede de Operadores".

12. As requisições às interfaces voltadas aos usuários do sistema (clientes, solicitantes de certificados e agentes) DEVEM ser provenientes do Servidor WEB.

3.3.2.3 Sistema WEBO Sistema WEB suporta o serviço de repositório da AC e a camada de apresentação do sistema AR:

Repositório da AC Repositório da AC onde são disponibilizados os certificados e listas de certificados revogados emitidos por autoridades certificadoras ou sistemas auxiliares delegados, os documentos de Declaração de Práticas de Certificação (DPC), os documento das políticas de Certificados (PC) e demais documentos;

Camada de apresentação do sistema AR Interfaces para requisição de certificados (Certificate Signing Request - CSR), instalação de certificado, revogação de certificado, etc.

O Serviço WEB é composto pelo seguinte conjunto de componentes:

Aplicação servidora WEB A aplicação servidora WEB é responsável gerenciamento e disponibilização das páginas de Internet;

Proxy reverso Aplicação que controle o acesso externo aos serviços Web internos;

Servidor O servidor é utilizado para suportar a aplicação servidora WEB e a aplicação proxy reverso;

HSM Dispositivo criptográfico que gerencia o ciclo de vida das chaves criptográficas dos serviços Web.

1. A aplicação servidora WEB DEVE atender, no mínimo, aos requisitos definidos para "Aplicação Servidora WEB"  do Anexo C.4.5.

14

2. O servidor deve atender, no mínimo, aos requisitos definidos para o "Servidor"  do Anexo C.3.

3. O HSM DEVE atender aos requisitos definidos para "HSM para proteção de chave privada de aplicação"  do Anexo B.

4. DEVEM ser fornecidas, no mínimo, as seguintes quantidades de sistemas WEB:

(a) Dois para a instalação principal; (b) Um para a instalação de contingência; (c) Um para o ambiente de homologação.

5. Todos os componentes do Sistema WEB da instalação principal DEVEM estar instalados no rack de servidores.

6. Todos os componentes do Sistema WEB da instalação de contingência DEVEM estar instalados no rack de servidores.

7. Todos os componentes do Sistema WEB do ambiente de homologação DEVEM estar instalados no rack do ambiente de homologação, localizado em ambiente nível 2. O Sistema WEB estar conectado à "rede intranet".

8. Devido ao posicionamento e exposição destes equipamentos (acesso aberto à Internet), DEVEM possuir configuração de segurança adequada a este ambiente.

3.3.2.4 Sistema DNS ExternoO Sistema DNS Externo provê resolução de nomes para as zonas da AC e AR através de um servidor DNS máster para estas zonas.

O Sistema DNS Externo é composto pelo seguinte conjunto de componentes: 1. Aplicação servidora DNS; e 2. Servidor.

1. A aplicação servidora DNS DEVE atender, no mínimo, aos requisitos definidos para "Aplicação Servidora DNS"  no Anexo C.4.1.

2. O servidor deve atender, no mínimo, aos requisitos definidos para "Servidor"  do Anexo C.3.

3. Devem ser fornecidas, no mínimo, as seguintes quantidades de Sistema DNS Externo:

(a) Dois para a instalação principal; (b) Um para a instalação de contingência.

4. Todos os componentes do Sistema DNS Externo da instalação principal DEVEM estar instalados no rack de servidores.

5. Todos os componentes do Sistema DNS Externo da instalação de contingência DEVEM estar instalados no rack de servidores.

3.3.2.5 Sistema de serviços básicos para intranetO sistema de serviços básicos para intranet implementa os serviços de gestão de identidade de usuários, NTP [34] e o DNS interno.

15

O sistema de serviços básicos de intranet é composto pelos seguintes componentes:

1. Aplicação Servidora LDAP [41]; 2. Aplicação Servidora NTP; 3. Aplicação Servidora DNS Interno; e 4. Servidor.

1. A Aplicação Servidora LDAP é utilizada para a gestão de identidade de usuários do ambiente lógico e DEVE atender, no mínimo, aos requisitos definidos para "Aplicação Servidora LDAP"  do Anexo C.4.4.

2. A Aplicação Servidora NTP é responsável pela disseminação de referência de tempo para os equipamentos internos e DEVE atender, no mínimo, aos requisitos definidos para "Aplicação Servidora NTP"  do Anexo C.4.3.

3. A Aplicação Servidora DNS Interno é responsável pelo atendimento de requisições de resolução de nomes provenientes dos equipamentos internos e DEVE atender, no mínimo, aos requisitos definidos para Aplicação servidora DNS do Anexo C.4.1.

4. O servidor DEVE atender, no mínimo, aos requisitos definidos para o "Servidor"  do Anexo C.3.

5. Devem ser fornecidas, no mínimo, as seguintes quantidades de sistemas para implementação dos serviços básicos de intranet:

(a) Dois para a instalação principal; (b) Um para a instalação de contingência.

6. Todos os componentes do Sistema da instalação principal DEVEM ser instalados no rack de servidores. O Sistema DEVE estar conectado à "rede servidores".

7. Todos os componentes do Sistema da instalação de contingência DEVEM ser instalados no rack de servidores. O Sistema DEVE estar conectado à "rede servidores".

8. O acesso remoto de usuário ao ambiente operacional do servidor DEVE ser permitido somente aos usuários autorizados cujo acesso seja proveniente da "rede de operadores".

9. Na instalação principal, este equipamento deve operar no modo de alta disponibilidade.

3.3.2.6 Sistema de gerenciamento de logsO sistema de gerenciamento de logs permite concentrar os registros (logs) enviados por todos os elementos de rede e servidores para um ponto central. Também dispõe de capacidade para organização e catálogo de logs para consulta.

O sistema de gerenciamento de logs é composto pelo seguinte conjunto de componentes:

1. Aplicação servidora logs; e 2. Servidor.

A Aplicação servidora logs é responsável pela recepção e arquivamento dos logs

16

provenientes dos elementos de rede e dos servidores.

1. A Aplicação servidora logs DEVE atender, no mínimo, aos requisitos definidos para "Aplicação servidora de logs"  do Anexo C.4.2.

2. O servidor DEVE atender, no mínimo, aos requisitos definidos para o "Servidor"  do Anexo C.3.

3. DEVEM ser fornecidas, no mínimo, as seguintes quantidades de sistema de gerenciamento de logs:

(a) Um para a instalação principal; (b) Um para a instalação de contingência.

4. Todos os componentes do "Sistema de Gerenciamento de Logs"  da instalação principal DEVEM ser instalados no rack de servidores. O sistema DEVE estar conectado à "rede de servidores".

5. Todos os componentes do "Sistema de Gerenciamento de Logs"  da instalação de contingência DEVEM ser instalados no rack de servidores. O sistema DEVE estar conectado à "rede de servidores".

3.3.3 Rede de comunicação de dados

3.3.3.1 Rede lógicaA Figura 2 apresenta a visão geral da rede lógica da AC e AR para o ambiente principal.

Figura 2: Rede Lógica do Ambiente Principal

A Figura 3 apresenta a visão geral da rede lógica da AC e AR para o ambiente de contingência.

17

Figura 3: Rede Lógica do Ambiente de Contingência

3.3.3.2 FirewallO Firewall é a primeira e principal barreira de segurança do tráfego de Internet após os roteadores e deve receber uma carga considerável de conexões simultâneas.

O Firewall é utilizado para proteger e segregar as redes e prover acesso através de VPN a usuários remotos, possuindo também funcionalidades de IDS e IPS.

1. DEVEM ser fornecidas, no mínimo, as seguintes quantidades de sistema de Firewall:

(a) Dois para a instalação principal; (b) Um para a instalação de contingência.

2. O Firewall da instalação principal DEVE operar em alta disponibilidade com replicação de estado entre os Firewalls.

3. O Firewall DEVE atender, no mínimo, aos requisitos definidos para o "Firewall de Borda"  do Anexo C.2.2.

4. DEVE ser fornecido um treinamento sobre Firewall (configuração e operação).

5. Os Firewalls da instalação principal DEVEM ser instalados no rack de rede de comunicação.

6. O Firewall da instalação de contingência DEVE ser instalado no rack de rede de comunicação.

3.3.3.3 Switch

1. DEVEM ser fornecidos, no mínimo, 4 switches para a instalação principal, 2

18

switches para a instalação de contingência e 1 switch para o ambiente de homologação. A quantidade de switches e portas devem ser dimensionados de forma que seja ocupado, no máximo, 80% de sua capacidade.

2. DEVEM ser fornecidos, no mínimo, 7 switches para a instalação principal, 4 switches para a instalação de contingência e 1 switch para o ambiente de homologação. A quantidade de switches e portas devem ser dimensionados de forma que seja ocupado, no máximo, 80% de sua capacidade.

3. O switch deve atender, no mínimo, aos requisitos definidos para o "Switch Ethernet"  do Anexo C.2.1.

3.4 Da documentação

1. Os equipamentos e softwares entregues devem apresentar documentação completa e suficiente, para cada um dos equipamentos e sistemas, que permitam instalar, configurar e operar os produtos em língua inglesa ou espanhola. A documentação deve fornecer informação suficiente para que as equipes locais operem os produtos de forma autônoma.

2. Deve ser entregue, pelo menos, uma cópia em papel e uma cópia digital, formato pdf, da documentação.

3.5 Da condição de entrega e aceitação

3.5.1 Do Prazo de Entrega

1. Os produtos devem ser entregues no prazo máximo de 60 dias a partir da assinatura do contrato entre as partes.

3.5.2 Do Local da Entrega e Instalação

1. Os equipamentos devem ser entregues em cada um dos Países aos responsáveis locais, que indicarão o local de instalação.

3.5.3 Da Aceitação

1. Os equipamentos serão considerados aceitos parcialmente a partir do momento que estiverem instalados, configurados e em condições de operação.

2. A aceitação final ocorrerá quando da operacionalização da estrutura, tendo o

19

contratante o prazo de dois meses para fornecer a aceitação final.

3.6 Da garantia técnica

3.6.1 Alcance

1. Todos os equipamentos e sistemas fornecidos deverão ter garantia técnica integral de funcionamento pelo período mínimo de 24 (vinte e quatro) meses, contados do recebimento definitivo, devendo suas eventuais falhas ou avarias ser corrigidas sem ônus de qualquer natureza ao comprador, independentemente da necessidade de substituição de elementos físicos ou lógicos de qualquer natureza. O tempo de garantia se reinicia cada vez que o equipamento for reposto.

2. Esses serviços devem incluir, mas não se limitar a: (a) Diagnóstico e análise da causa de eventuais falhas; (b) Assessoria na instalação de novas versões do sistema; (c) Elaboração de recomendações ou guias que auxiliem no

aproveitamento ótimo e pró-ativo do sistema; (d) Resposta a consultas pontuais;

3. As avarias de natureza grave, decorrentes do uso comum, verificadas quando do recebimento, instalação e operação do equipamento ou sistema, verificadas no curso da garantia técnica deverão implicar na sua recusa ou sua devolução caso seja equipamento e conseqüente obrigação da contratada de substituir integralmente o equipamento ou sistema fornecidos, às suas plenas expensas, devendo o novo equipamento ou sistema ser entregue pela contratada e instalado no prazo improrrogável de 30 (trinta) dias corridos, contados na comunicação e considerado o prazo previsto para a providência. A contratada fica obrigada a fornecer um equipamento para que o serviço disponibilizado não seja interrompido durante o período de substituição do equipamento.

4. O conceito de avaria de natureza grave deverá ser interpretado como aquele que causa risco ao funcionamento regular, preciso e seguro do equipamento ou dos seus periféricos, ou eventuais falhas de natureza estrutural, física ou lógica, possíveis de serem assemelhadas aos vícios do tipo redibitórios.

5. A devolução do equipamento implica suspensão do prazo contratual dedicado à garantia técnica, sendo que este é reiniciado com o recebimento definitivo do equipamento prestado em substituição.

3.6.2 Do Suporte Técnico

1. Compreende-se por suporte técnico as intervenções da contratada no equipamento ou sistema fornecidos, com fins de certificar-se do funcionamento preventivo ou para corrigir eventuais defeitos, falhas ou

20

inconsistências verificadas pelo contratante no curso da utilização.2. A contratada deve desenvolver parceria com empresa local ou instalar

escritório próprio no país que receber o equipamento. A contratada deve apresentar na época da instalação do equipamento documentos comprovando o estabelecimento de parceria com empresa local ou a instalação de escritório próprio.

3. O suporte técnico deverá ser realizado por representante da contratada e por ela expressamente autorizado, cuja intervenção deverá ser registrada na respectiva Ordem de Serviço, devendo ocorrer sempre que solicitado ou em conformidade com as recomendações técnicas preventivas recomendadas pelo fabricante.

4. Os serviços de manutenção DEVEM ser prestados por empresas com experiência mínima e comprovada de 5 anos nesse tipo de atividade.

5. Para tanto a empresa prestadora do serviço DEVE apresentar as credenciais correspondentes emitidas pelo fabricante. Cada fabricante ou empresa local habilitada será responsável pelo serviço de manutenção respectivo. A empresa contratada no país onde os produtos serão instalados será solidariamente responsável pelo serviço em todos os casos, em particular no caso em que o fabricante deixar de prestar o serviço.

6. Em todos os casos, deverá ser apresentado para cada produto, uma carta aval do fabricante que certifique que cumprirá os serviços de manutenção de acordo com o especificado neste documento, assim como a carta de responsabilidade solidária da empresa habilitada.

7. O suporte técnico deverá ser registrado na respectiva Ordem de Serviço, devendo ocorrer sempre que solicitado ou em conformidade com as recomendações técnicas preventivas recomendadas pelo fabricante.

3.6.3 Resposta a Incidentes

1. O suporte será realizado pelo período correspondente à garantia técnica do equipamento, com atendimento telefônico 24 horas por dia e 7 dias da semana.

2. Poderá, em comum acordo entre o fornedor e a contratante, definir-se outras formas de comunicação.

3. O atendimento DEVE ser realizado na língua espanhola.4. Após a comunicação do problema deverá ser realizado o primeiro contato no

prazo máximo de 2 (duas) horas. Os atendimentos presenciais deverão ser prestados pela contratada no prazo máximo de 6 horas, contado da comunicação.

5. A solução do problema deve ser realizada no prazo máximo de 12 horas após a comunicação do mesmo. No caso da impossibilidade de solucionar o problema, no prazo estabelecido, deve ser fornecido um equipamento provisório ou definitivo em substituição ao defeituoso para que o serviço não seja interrompido. O tempo de resposta para substituição de partes de hardware ou software será de no máximo 24 (vinte e quatro) horas.

21

6. O fornecedor deverá colocar seus melhores esforços para que em um prazo razoável se substituam as partes de hardware ou software que foram substituídas provisoriamente.

(a) Para o caso de substituição de hardware, em nenhum caso se admitirá um prazo maior que 60 dias.

(b) Diante da impossibilidade da entrega de qualquer dos produtos oferecidos, o fornecedor se obriga a substituí-lo por outro que reúna as mesmas condições técnicas, ou de versão superior ou um novo produto que cumpra com os requisitos estabelecidos no chamado. Esta situação deverá ser comunicada num prazo máximo de 30 dias e fica sujeita a aprovação da parte contratante.

7. Qualquer alteração, descontinuação ou alterações nas especificações técnicas, relativa aos produtos fornecidos deve ser comunicada aos contratantes no prazo máximo de 30 dias. Todos os fornecedores deverão suportar equipamentos e sistemas durante o período mínimo de 5 anos após o fornecimento, mesmo que estes sejam descontinuados ou deixem de ser fabricados.

8. O fornecedor deve apresentar um sistema de registro e acompanhamento de incidentes compartilhado com os Países que receberam os equipamentos e serviços. Nesse sistema deve constar o responsável pelo serviço de suporte sendo prestado, canal de recebimento dos pedidos de suporte técnico (telefone, e-mail, sítio na web) e pessoas de contato envolvidas na solução do problema.

9. Na eventualidade da necessidade de deslocamento de técnicos da ofertante até o local onde se encontram os equipamentos para solucionar problemas ocorridos, os custos (traslado, alojamento e alimentação) são de responsabilidade da ofertante.

10. Todas as ações decorrentes da prestação de serviço de suporte técnico devem ser documentadas, sendo um relatório mensal disponibilizado aos Países onde os equipamentos estarão instalados.

3.6.4 Atualização tecnológica1. A atualização tecnológica a ser prestada pelo FORNECEDOR tem por

objetivo manter a solução adquirida atualizada e funcional com relação às versões mais recentes dos softwares de ICP, bem como mantê-los rigorosamente adequada 1as soluções lançadas durante a vigência da garantia dos produtos.

2. Nesta atualização inclui-se o fornecimento para os Países onde estiverem instalados os equipamentos de todas as novas versões, correções, fixes, service packs e fixes de segurança dos componentes, garantindo a segurança e a confiabilidade requerida e inerente à solução.

3. Essas atualizações deverão ser repassadas ao país contratante no prazo máximo de 7 (sete) dias úteis a partir do seu lançamento, assim como o fornecimento dos manuais e boletins técnicos com informações que assegurem a sua plena utilização.

4. Na atualização de versões, o fornecedor deverá garantir o apoio técnico necessário para operar com as últimas versões licenciadas, sem ônus adicional

22

para os Países.5. O fornecimento de nova versão não deverá inviabilizar sistemas da solução.

Caberá aos Países a opção de instalação das novas funcionalidades (novas versões, features, releases ou qualquer outro tipo de atualização ou regularização dos sistemas).

3.7 Do treinamento

1. O plano de treinamento da capacitação deve ser apresentado como parte da proposta.

2. Deverá ser prestado pela fornecedora dos equipamentos treinamento específico para 15 (quinze) técnicos indicados pelo comprador. O curso deve ser ministrado de forma continua, a partir da entrega dos equipamentos e sistemas, em data acordada entre a contratada e o contratante.

3. Na capacitação deve constar atividade que permitam utilizar todas as funcionalidades dos sistemas, incluindo a emissão, utilização e revogação de certificados digitais. Os técnicos devem ser capacitados a utilizar uma ferramenta que verifique se um certificado respeita os padrões estabelecidos na RFC 5280 [9]. Ferramenta esta que deve ser entregue juntamente com a solução.

4. O treinamento deverá incluir aspectos teóricos (20%), aspectos ligados à instalação, configuração e aspectos ligados à operação e administração (80%). Ao fim da capacitação, os técnicos indicados devem ser capazes de realizar as seguintes atividades sem a necessidade de suporte técnico externo:

(a) Instalar os equipamentos;(b) Configurar os equipamentos;(c) Operar os equipamentos;(d) Extrair dados dos equipamentos para ações de auditoria;(e) Executar auditorias nos equipamentos.

5. O treinamento e material utilizado no treinamento devem ser fornecidos na língua espanhola.

6. Deve ser oferecido aos participantes do treinamento uma cópia em papel e uma cópia digital em PDF do material utilizado. O material poderá ser utilizado posteriormente pelo país que receber o treinamento sem custos adicionais.

7. A fornecedora deve entregar certificado de participação aos participantes que tenham desenvolvido as atividades do treinamento.

8. A CONTRATADA DEVE fornecer os treinamentos relacionados na Tabela 3.2.

Tabela 3.2: CursosCursos Carga horária

Infraestrutura de chaves públicas 20

23

Cursos Carga horáriaTreinamento em políticas e procedimentos da AC e AR 20

Para todos os equipamentos e sistemas fornecidos tais com Sistema AC Online, HSM, Sistema AR, etc., necessários para a instalação, configuração e operação da solução como um todo.

60

Capítulo 4

Requisitos Gerais4.1 Antecedentes da Empresa

1. O fornecedor deve apresentar documentação comprovando a sua qualificação. Neste sentido deve ser comprovada a instalação de equipamentos similares ou iguais aos fornecidos no país ou em outros Países.

2. O fornecedor deve apresentar no mínimo 5 anos de experiência na área de Tecnologia da Informação e Comunicação, já tendo instalado pelo menos dois ambientes de certificação digital incluindo ACs e ARs.

3. A empresa local deve apresentar experiência mínima de 5 anos em projetos de tecnologia da informação, segurança da informação e suporte e manutenção de equipamentos.

4.2 Da Empresa Local ou Escritório Próprio1. A contratada deve apresentar na proposta documentos comprovando o

estabelecimento de parceria com empresa local ou a instalação de escritório próprio.

Capítulo 5

Sigilo das InformaçõesO fornecedor não poderá revelar a terceiros informações sobre organização, operação dos trabalhos e arquivos de dados, bem como quaisquer informações dos Países das quais vier a tomar conhecimento por força de natureza especial deste objeto de licitação, obrigando-se ainda a proibir que seus empregados ou prepostos o façam, assegurando sempre a necessária proteção ao sigilo destas informações.

O fornecedor deverá concordar em tomar as ações apropriadas para que os empregados e outros profissionais, sob sua direção e controle, que lidarem com as informações em questão, respeitem as restrições de uso determinadas no Termo de Confidencialidade a ser fornecido pela contratante.

24

Capítulo 6

Critério de Avaliação das PropostasO vencedor será aquele que obtiver a maior pontuação seguindo os critérios constantes nas Seções 1 e 2.

O vencedor DEVE, também, atender a todos os requisitos mínimos obrigatórios constantes das especificações técnicas.

6.1 Avaliação TécnicaAs Tabelas 1,  2 e 3 apresentam as pontuações que serão adotadas para a avaliação técnica da proposta. A pontuação total da avaliação técnica é de 80.

Tabela 1: Organização e MetodologiaOrganização do Projeto 5Metodologia de Trabalho 5Calendário de Atividades 5Pontuação Total: Organização e Metodologia

15

Tabela 2: Capacidade Técnica Experiência da Fornecedora 5Experiência da Empresa Local 5Equipe Disponibilizada para Instalação, Configuração e Capacitação

5

Equipe de Suporte e Forma de Prestação do Serviço de Suporte

5

Pontuação Total: Capacidade Técnica 20

Tabela 3: Especificações Técnicas Requisitos Mínimos Obrigatórios 25Requisitos Desejáveis 5Prazo de Entrega do Produto 5Plano de Capacitação 5Proposta de Suporte Técnico 5Pontuação Total: Especificações Técnicas

45

25

6.2 Avaliação EconômicaA Tabela 4 apresenta as pontuações que serão adotadas para a avaliação econômica da proposta. A pontuação total da avaliação econômica é de 20.

Tabela 4: Proposta Econômica Valor total da proposta 20Pontuação Total: Proposta Econômica 20

Capítulo 7

Apresentação da Oferta TécnicaO fornecedor deverá apresentar em sua oferta técnica, no mínimo, as seguintes informações:

1. Informação sobre o ofertante:(a) Informação sobre experiência geral em projetos do mesmo tipo,

indicando o tipo de equipamento vendido e a implantação realizada.(b) Experiência específica da equipe da ofertante.(c) Informação sobre a parceira ou escritório local.

2. Informações constantes da proposta:(a) Informação sobre equipamentos ofertados, acompanhados de

documentação técnica necessária para a análise. No caso de não dispor na oferta da informação necessária para corroborar com o cumprimento de alguns dos requisitos mínimos, este será considerado como Não Cumprido.

(b) Informações adicionais sobre os equipamentos como fotografias, certificados de instituições oficiais encarregadas de controle de qualidade, de reconhecida competência na certificação de conformidade dos produtos e das especificações ou normas vigentes;

(c) Projeto de implantação.(d) Cronograma de entrega e de atividades para operacionalização.(e) Plano de comunicação durante a execução do contrato.(f) Plano detalhado de capacitação apresentando distribuição dos temas,

carga horária dedicada a cada um dos temas e requisitos para a capacitação.

(g) Especificação do Serviço Técnico.

Referencias[1] C. Adams, P. Cain, D. Pinkas, and R. Zuccherato, Internet X.509 Public Key

Infrastructure Time-Stamp Protocol (TSP), RFC 3161 (Proposed Standard), August 2001, Updated by RFC 5816.

[2] C. Adams, S. Farrell, T. Kause, and T. Mononen, Internet X.509 Public Key

26

Infrastructure Certificate Management Protocol (CMP), RFC 4210 (Proposed Standard), September 2005.

[3] ANSI, ANSI X9.31:1998: Digital signatures using reversible public key cryptography for the financial services industry (rDSA), Appendix A, http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI+X9.62:2005, 1998.

[4] ______ , ANSI X9.62:2005: Public key cryptography for the financial services industry, the elliptic curve digital signature algorithm (ECDSA), http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI+X9.62:2005, 2005.

[5] Elaine Barker and John Kelsey, NIST special publication 800-90: Recommendation for random number generation using deterministic random bit generators, http://csrc.nist.gov/publications/nistpubs/800-90/SP800-90revised_March%

2007.pdf, January 2005.[6] L. Bassham, W. Polk, and R. Housley, Algorithms and Identifiers for the

Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC 3279 (Proposed Standard), April 2002, Updated by RFCs 4055, 4491, 5480, 5758.

[7] S. Blake-Wilson, D. Brown, and P. Lambert, Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS), RFC 3278 (Informational), April 2002, Obsoleted by RFC 5753.

[8] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, RFC 2119 (Best Current Practice), March 1997.

[9] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC 5280 (Proposed Standard), May 2008.

[10] Morris Dworkin, NIST special publication 800-38A: Recommendation for block cipher modes of operation: Methods and techniques, http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf, December 2001.

[11] D. Eastlake 3rd, J. Reagle, and D. Solo, (Extensible Markup Language) XML-Signature Syntax and Processing, RFC 3275 (Draft Standard), March 2002.

[12] ETSI, Etsi ts 101 862 v1.3.3: Qualified certificate profile, http://pda.etsi.org/exchangefolder/ts_101862v010303p.pdf, January 2006.

[13] ______ , Etsi ts 101 733 v1.8.1: Electronic signaure and infrastructure (esi); cms advanced electronic signatures (cades), http://pda.etsi.org/exchangefolder/ts_101733v010801p.pdf, Novembro 2009.

[14] ______ , Etsi ts 101 903 v1.4.1: Xml advanced electronic signatures (xades), http://pda.etsi.org/exchangefolder/ts_101903v010401p.pdf, Junho 2009.

[15] ______ , Etsi ts 102 778-4 v1.1.2: Electronic signatures and infrastructures (esi); pdf advanced electronic signature profiles; part 4: Pades long term - pades ltv profile, http://pda.etsi.org/exchangefolder/ts_10277804v010102p.pdf, Dezembro 2009.

27

[16] ______ , Etsi ts 102 778-3 v1.2.1: Electronic signatures and infrastructures (esi); pdf advanced electronic signature profiles; part 3: Pades enhanced - pades-bes and pades-epes profiles, http://pda.etsi.org/exchangefolder/ts_10277803v010201p.pdf, Julho 2010.

[17] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee, Hypertext Transfer Protocol – HTTP/1.1, RFC 2616 (Draft Standard), June 1999, Updated by RFCs 2817, 5785.

[18] FIPS, FIPS PUB 46-3: Data Encryption Standard (DES), http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf, October 1999.

[19] ______ , FIPS PUB 140-2: Security requirements for cryptographic modules, http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf, May 2001.

[20] ______ , FIPS PUB 197: Advanced Encryption Standard (AES), http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf, November 2001.

[21] ______ , FIPS PUB 180-3: Secure Hash Standard (SHS), http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf, October 2008.

[22] R. Gerhards, The Syslog Protocol, RFC 5424 (Proposed Standard), March 2009.[23] R. Housley, Cryptographic Message Syntax (CMS), RFC 5652 (Standard),

September 2009.[24] ISO, ISO 8601:2000. Data elements and interchange formats — Information

interchange — Representation of dates and times, http://www.iso.ch/cate/d26780.html, 2000, p. 29.

[25] ______ , ISO/IEC 15408-2:2009. Information technology - Security techniques - Evaluation criteria for IT security - Part 2: Security functional components , http://standards.iso.org/ittf/PubliclyAvailableStandards/c046414_ISO_IE%C_15408-2_2008.zip, August 2008.

[26] ______ , ISO/IEC 15408-3:2009. Information technology - Security techniques - Evaluation criteria for IT security - Part 3: Security assurance components , http://standards.iso.org/ittf/PubliclyAvailableStandards/c046413_ISO_IE%C_15408-3_2008.zip, August 2008.

[27] ______ , ISO/IEC 15408-1:2009. Information technology - Security techniques - Evaluation criteria for IT security - Part 1: Introduction and general model, http://standards.iso.org/ittf/PubliclyAvailableStandards/c050341_ISO_IE%C_15408-1_2009.zip, December 2009.

[28] ITU-T, Recommendation X.690 (11/2008) - Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf, July 2002.

[29] ______ , Recommendation X.509 information technology - open systems interconnection - the directory: Public-key and attribute certificate frameworks, Tech. report, ITU-T, 2008.

[30] J. Jonsson and B. Kaliski, Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1, RFC 3447 (Informational), February 2003.

28

[31] RSA Laboratories., PKCS #11 v2.20: Cryptographic token interface standard, ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf, May 2004.

[32] ______ , PKCS #10 v1.7: Certification request syntax standard, ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-10/pkcs-10v1_7.pdf, May 2006.

[33] J. Linn, Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures, RFC 1421 (Historic), February 1993.

[34] D. Mills, Network Time Protocol (Version 3) Specification, Implementation and Analysis, RFC 1305 (Draft Standard), March 1992, Obsoleted by RFC 5905.

[35] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP, RFC 2560 (Proposed Standard), June 1999.

[36] M. Nystrom and B. Kaliski, PKCS #10: Certification Request Syntax Specification Version 1.7, RFC 2986 (Informational), November 2000, Updated by RFC 5967.

[37] S. Santesson, M. Nystrom, and T. Polk, Internet X.509 Public Key Infrastructure: Qualified Certificates Profile, RFC 3739 (Proposed Standard), March 2004.

[38] J. Schaad, B. Kaliski, and R. Housley, Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC 4055 (Proposed Standard), June 2005, Updated by RFC 5756.

[39] J. Schaad and M. Myers, Certificate Management over CMS (CMC), RFC 5272 (Proposed Standard), June 2008.

[40] S. Turner, D. Brown, K. Yiu, R. Housley, and T. Polk, Elliptic Curve Cryptography Subject Public Key Information, RFC 5480 (Proposed Standard), March 2009.

[41] K. Zeilenga, Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map, RFC 4510 (Proposed Standard), June 2006.

Capítulo A

SoftwareEsta seção define os requisitos funcionais e não funcionais que DEVEM ser atendidos pelo software de uma Infraestrutura de Chaves Públicas (ICP).

A.1 Requisitos GeraisEsta seção relaciona os requisitos gerais que DEVEM ser atendidos por todos os sistemas.

A.1.1 Padrões e algoritmos criptográficos

29

1. Os sistemas DEVEM, minimamente, adotar os seguintes os padrões e algoritmos criptográficos relacionados no Anexo D:

(a) Algoritmo hash;(b) Algoritmo de criptografia assimétrica;(c) Tamanhos de chaves assimétricas;(d) Suíte de assinatura;(e) Solicitação de certificados (CSR);(f) Formato de certificado;(g) Formato de LCR;(h) Objetos assinados: CAdES ou XAdES.

A.1.2 Documentação

1. Os sistemas DEVEM ter sido desenvolvidos com o apoio documentação formal e esta documentação, minimamente composta por documentos de requisitos funcionais e não funcionais e documentos de casos de uso e DEVEM ser fornecidos em conjunto com o sistema. Para o caso de sistemas procedurais documentos de diagrama de fluxos ou semelhantes também são requeridos. Já para o caso de sistemas construídos através de aplicação dos conceitos de orientação á objetos, documentos de diagramas de classes e de seqüência e outros documentos complementares também são requeridos.

2. A versão entregue dos sistemas DEVEM ser acompanhadas de documentação formal que registre os casos de testes planejados e que evidencie, minimamente, e de forma textual e visual, os resultados dos testes funcionais executados para a versão em questão.

3. A versão entregue dos sistemas DEVEM ser acompanhadas de documentação formal que registre, de forma detalhada, os eventuais modelos de dados, arquivos de configuração e quaisquer outros artefatos que exerçam influência direta ou indireta sobre o funcionamento do sistema.

A.1.3 Usabilidade

1. O software DEVE permitir que as ações administrativas e operacionais no sistema sejam realizadas através de interfaces gráficas (GUI).

2. As interfaces de administração do Software DEVEM ter suporte mínimo aos seguintes idiomas: espanhol e inglês.

3. O conjunto de tópicos de ajuda do Software DEVE ter suporte mínimo aos seguintes idiomas: espanhol e inglês.

30

A.2 Software para Autoridade certificadora online

O Software para Autoridade Certificadora (AC) online é responsável pela emissão, renovação e revogação de certificados para Entidade Final (EF) segundo as práticas de certificação adotadas para a AC online. Também é responsável pela emissão de Listas de Certificados Revogados (LCR).

1. O Software de AC online DEVE, como se espera de uma AC, gerenciar de forma segura todo o ciclo de vida de certificados digitais, segundo o estabelecido na RFC 5280 [9].

A.2.1 Requisitos funcionais

1. O Software de AC online DEVE suportar a manipulação de certificados digitais de acordo com versão 3 do padrão ITU-T X.509 [29] que sejam concordantes com o perfil estabelecido na RFC 5280 [9].

2. O Software de AC offline DEVE suportar a extensão qualified certificate statement (qCStatement) definido na RFC 3739 [37] e as quatro declarações esi4-qcStatement-1, esi4-qcStatement-2, esi4-qcStatement-3 e esi4-qcStatement-4 definidas em ETSI TS 101 862 [12].

3. O Software de AC online DEVE ser capaz de manipular requisições de assinatura de certificados que sejam concordantes com o padrão criptográfico Public Key Cryptography Standard #10 (PKCS #10) [32].

4. O Software de AC online DEVE ser capaz de manipular objetos criptográficos, tais como requisições de emissão de certificados, certificados digitais e listas de certificados revogados, de acordo com os formatos de codificação Distinguished Encoding Rules (DER) [28] e Privacy-Enhanced Mail (PEM) [33].

5. O Software de AC online DEVE prover meios para gerenciar o ciclo de vida de um certificado digital, o que inclui, minimamente, atividades de emissão, renovação e revogação de certificados.

6. O Software de AC online DEVE permitir a criação e a utilização de modelos de certificados que viabilizem a definição de quais campos e atributos do certificado DEVEM ser considerados obrigatórios e opcionais, sempre de acordo com o perfil RFC 5280 [9].

7. O Software de AC online DEVE conter funcionalidades suficientes para permitir o credenciamento e gerenciamento de várias Autoridade de Registro (AR).

8. O Software de AC online DEVE exigir que as requisições de emissão, renovação e revogação de certificados sejam oriundas única e exclusivamente de uma AR credenciada.

9. O Software de AC online DEVE suportar, na interação com a(s) AR(s)

31

credenciadas(s), ao menos um dos seguintes protocolos de gerenciamento de certificados;

(a) Certificate Management Protocol (CMP) [2]; (b) Certificate Management over CMS (CMC) [39].

10. O Software de AC online DEVE assegurar que as requisições de emissão, renovação e revogação de certificados só sejam aceitas se oriundas de uma AR credenciada que tenha assinado digitalmente as mensagens que trafegam através de um dos protocolos de gerenciamento de certificados.

11. O Software de AC online DEVE disponibilizar funcionalidades que permitam definir o período de validade de uma Lista de Certificados Revogados (LCR).

12. O Software de AC online DEVE disponibilizar funcionalidades que permitam definir o intervalo de tempo entre emissões consecutivas de uma LCR.

13. O Software de AC online DEVE disponibilizar funcionalidades que viabilizem emissões antecipadas de uma LCR para situações extraordinárias nas quais não se deseja aguardar o intervalo de tempo entre emissões consecutivas.

14. O Software de AC online DEVE prever que, antes de publicadas, todas as LCRs geradas sejam verificadas quanto à consistência de seu conteúdo, principalmente no que se refere à relação entre o número de série LCR e a data e hora da emissão e à integridade de sua assinatura digital.

15. O Software de AC online DEVE gerar registros de evento para todas as atividades administrativas e operacionais.

16. O Software de AC online DEVE possuir mecanismos de registro de atividades que permita o rastreamento de erros, auditoria e geração de relatórios gerenciais.

17. O Software de AC online DEVE disponibilizar módulo administrativo de visualização de registros de evento.

18. O Software de AC online DEVE possuir um módulo de geração de relatórios administrativos e operacionais.

19. O módulo de geração de relatórios do Software de AC online DEVE ser capaz de exportar os relatórios gerados nos seguintes formatos: CSV, XML e PDF.

20. O Software de AC online DEVE possuir um conjunto de tópicos de ajuda que auxilie os usuários na execução de atividades operacionais e administrativas.

21. O Software de AC online DEVE conter funcionalidades que permitam a realização de cópias de segurança periódicas que englobem todas as informações administrativas e operacionais disponíveis no momento.

22. O Software de AC online DEVE conter funcionalidades que permitam a restauração de seu estado operacional e administrativo a partir das cópias de segurança existentes.

23. Os registros de evento gerados pelo Software de AC online DEVEM incluir, no mínimo, as seguintes informações:

(a) data e horário em que o evento ocorreu (de acordo com formato ISO-8601 [24]);

(b) nível de severidade (por exemplo, níveis de severidade do syslog [22]: ALL, DEBUG, INFO, WARN, ERROR, FATAL);

(c) origem do evento;

32

(d) estado do evento (sucesso ou falha);(e) identificação do usuário (quando aplicável);(f) descrição do evento.

24. (OPCIONAL) o Software de AC offline DEVE possuir mecanismos que garantam a integridade de todos os registros de eventos administrativos e operacionais.

25. (OPCIONAL) o Software de AC online DEVE requerer que as transações relativas à execução de atividades administrativas e operacionais executadas por usuários que desempenhem o papel de Gestor de AC sejam assinadas digitalmente e validadas.

A.2.2 Requisitos não funcionais

A.2.2.1 Tecnologia

1. O Software de AC online ou a instalação do sistema operacional que o abriga DEVE prever sincronismo de relógio com uma fonte de tempo confiável.

2. O Software de AC online DEVE utilizar uma base de dados para armazenar toda informação administrativa e operacional.

3. O Software de AC online DEVE dispor de um sistema de publicação (repositório) que possibilite viabilizar o acesso online pelos usuários da ICP às LCRs emitidas através dos protocolos Hypertext Transfer Protocol (HTTP) [17].

4. O Software de AC online DEVE prever que a geração de seu par de chaves ocorra dentro dos limites físicos de um Hardware Security Module (HSM) concordante com as restrições impostas no Anexo B.

5. O Software de AC online DEVE suportar ao padrão PKCS #11 [31] e, opcionalmente, o modelo OpenSSL engine na interface com o HSM de gestão das chaves da AC de assinatura de certificados e LCRs e autenticação nas comunicações com AR.

A.2.2.2 Segurança

1. O Software de AC online DEVE requerer que todas as atividades administrativas e operacionais executadas por seus usuários sejam precedidas por autenticação com, no mínimo, dois fatores; fator conhecimento e fator posse. O fator de posse deve ser viabilizado através de chaves assimétricas e certificado digital.

2. As interfaces remotas com o usuário devem ser estabelecidas através de canais SSL/TLS.

3. As informações e funcionalidades apresentadas pelo Software de AC online aos seus usuários DEVEM estar de acordo com seus privilégios.

33

4. (OPCIONAL) o Software de AC online DEVE gerar, para toda autenticação de usuário bem sucedida, um registro que assegure a irretratabilidade do evento.

A.2.2.3 Disponibilidade

1. O Software de AC online DEVE suportar mecanismos de redundância que assegurem que, caso ocorra a indisponibilidade em uma instância do software, outra instância seja capaz de atender ao serviço.

A.2.2.4 Administração

1. (OPCIONAL) o Software de AC online DEVE prever a existência de um Gestor de segurança de AC, com privilégio de criar perfis de acesso.

A.2.2.5 Usabilidade

1. (OPCIONAL) o Software de AC online PODE disponibilizar interfaces administrativas e operacionais utilizando a interface WEB, permitindo que o acesso se faça por intermédio de navegadores WEB.

A.3 Software para Autoridade de registroO Software de Autoridade de Registro (AR) é responsável pelo gerenciamento do processo de solicitação de certificados pelas Autoridades Finais à Autoridade Certificadora (AC) vinculada. O processo de solicitação inclui o registro da Entidade final, a validação presencial, a aprovação dos documentos e o encaminhamento da solicitação de emissão do certificado à AR vinculada. Também é responsável por disponibilizar o certificado emitido e sua cadeia de certificação à Entidade final, cumprindo as práticas de certificação definidas para a AC em questão.

1. O Software de AR DEVE, como se espera de uma AR, gerenciar de forma segura todo o ciclo de vida de certificados digitais, segundo o estabelecido na RFC 5280 [9].

A.3.1 Requisitos funcionais

1. O Software de AR DEVE prover meios para gerenciar o ciclo de vida do certificado de Entidade final, o que DEVE incluir, minimamente, as

34

atividades:(a) gerenciamento do certificado (solicitação de emissão, aprovação da

solicitação de emissão, emissão, publicação e revogação);(b) fluxo de aprovação da solicitação de emissão de certificado em dois

níveis de aprovadores;(c) gerenciamento de solicitações pendentes de certificados;(d) busca de Autoridades por critérios definidos pelo Administrador de

AR (nome, estado, certificado associado).2. O Software de AR DEVE disponibilizar interfaces WEB para solicitação de

emissão de certificado para as Autoridades finais. DEVE também disponibilizar componentes que permitam a geração de chaves e instalação de certificado através do browser do usuário.

3. O Software de AR DEVE disponibilizar interfaces WEB para automatizar todo o processo de solicitação de certificado para o usuário final, incluindo a coleta de informações de registro, a ativação do provedor de serviços para geração do par de chaves, a geração da CSR, a consulta do estado da solicitação, a disponibilização e instalação do certificado do usuário final.

4. O Software de AR DEVE ser capaz de manipular solicitações de certificados de acordo com o padrão criptográfico PKCS #10 [32].

5. O Software de AR DEVE disponibilizar aos titulares de certificado interfaces WEB para solicitação de revogação de certificado. Também DEVE disponibilizar interfaces administrativas aos Agentes de Registro autorizados a intermediar solicitações de revogação.

6. O Software de AR DEVE obrigar que toda solicitação de revogação originada da interface WEB pública seja atendida mediante a autenticação positiva do requerente, o que PODE ser realizado, por exemplo, através da apresentação de uma prova de posse adquirida ou prova de conhecimento cadastrada no momento da requisição do certificado.

7. O Software de AR, nas interações com a AC DEVE suportar ao menos um dos seguintes protocolos de gerenciamento de certificados;

(a) Certificate Management Protocol (CMP) [2];(b) Certificate Management over CMS (CMC) [39].

8. Software de AR, nas interações com a AC, DEVE assinar digitalmente as solicitações de emissão, renovação e revogação de certificados digitais.

9. O Software de AR DEVE prever, minimamente, a existência de dois perfis de acesso distintos para seus usuários que atuam com Agentes de Registro. Os perfis de acesso são: o Agente de Validação Presencial (AVP) e o Agente Aprovador (AAP).

10. As transações relativas à execução das etapas do ciclo de vida dos certificados dos AVP e AAP no Software de AR DEVEM ser realizadas através de documentos e mensagens assinadas digitalmente.

11. O Software de AR, a fim de endereçar a solicitação de emissão de certificados digitais para as Autoridades finais, DEVE suportar a configuração de fluxos de emissão que sejam compostos, minimamente, por quatro (4) etapas distintas:

(a) etapa 1, que indica a existência de uma solicitação de emissão para

35

uma Entidade final e a espera pela validação presencial;(b) etapa 2, que indica validação presencial realizada com sucesso e

espera pela etapa 3;(c) etapa 3, que indica validação de documentos realizada com sucesso e

espera pela emissão efetiva do certificado;(d) etapa 4, que indica a emissão bem sucedida do certificado da Entidade

final.12. O Software de AR DEVE disponibilizar interfaces WEB para solicitação de

renovação de certificado.13. O Software de AR DEVE disponibilizar funcionalidade que permita

determinar a validade da assinatura digital das transações referentes à execução das etapas do fluxo de emissão de certificados e ao gerenciamento do ciclo de vida dos certificados.

14. O Software de AR DEVE gerar registros de evento para todas as atividades administrativas e operacionais.

15. O Software de AR DEVE possuir um módulo de geração de relatórios administrativos e operacionais.

16. O Software de AR DEVE disponibilizar módulo administrativo de visualização de registros de evento.

17. O módulo de geração de relatórios do Software de AR DEVE ser capaz de exportar os relatórios gerados nos seguintes formatos: CSV, XML e PDF.

18. O Software de AR DEVE possuir um conjunto de tópicos de ajuda que auxilie os usuários na execução de atividades operacionais e administrativas.

19. O Software de AR DEVE conter funcionalidades que permitam a realização de cópias de segurança periódicas que englobem todas as informações administrativas e operacionais disponíveis no momento.

20. O Software de AR DEVE conter funcionalidades que permitam a restauração de seu estado operacional e administrativo a partir das cópias de segurança existentes.

21. O Software de AR DEVE possuir módulo que permita gerenciar toda a documentação dos solicitantes e titulares de certificados, controlando o recebimento, o armazenamento, a digitalização, assinatura digital e a indexação (para fins de pesquisa) da documentação fornecida pelas Autoridades finais no momento da validação presencial.

22. Os registros de evento gerados pelo Software de AR DEVEM incluir, no mínimo, as seguintes informações:

(a) data e horário em que o evento ocorreu (de acordo com formato ISO-8601 [24]);

(b) nível de severidade (por exemplo, níveis de severidade do syslog [22]: ALL, DEBUG, INFO, WARN, ERROR, FATAL);

(c) origem do evento;(d) estado do evento (sucesso ou falha);(e) identificação do usuário (quando aplicável);(f) descrição do evento.

36

A.3.2 Requisitos não funcionais

A.3.2.1 Tecnologia

1. O Software de AR ou a instalação do sistema operacional que o abriga DEVE prever sincronismo de relógio com uma fonte de tempo confiável.

2. O Software de AR DEVE utilizar uma base de dados para armazenar toda informação administrativa e operacional.

3. módulo do Software de AR que viabiliza às Autoridades finais a emissão online de certificados DEVE suportar a emissão utilizando o navegador WEB Internet Explorer, a partir da versão 6.0 - inclusive - para todas as versões de sistema operacional Microsoft Windows a partir da versão Windows XP Professional.

4. módulo do Software de AR que viabiliza às Autoridades finais a emissão online de certificados DEVE suportar a emissão utilizando o navegador WEB Mozilla Firefox, a partir da versão 3.0.19 - inclusive - para todas as versões de sistema operacional Microsoft Windows a partir da versão Windows XP Professional e para os seguintes sistemas operacionais baseado em Linux: RedHat, a partir da versão 5; e SUSE a partir da versão 11.0.

5. módulo do Software de AR que viabiliza às Autoridades finais a emissão online de certificados DEVE suportar a emissão utilizando o navegador WEB Safari, a partir da versão 4 - inclusive - para todas as versões do sistema operacional MAC OS, a partir da versão 10.0.

A.3.2.2 Segurança

1. O Software de AR DEVE fazer uso de Hardware Security Module (HSM) para proteção da sua chave privada utilizada nos protocolos de gerenciamento de certificados entre a AR e a AC e nas comunicações entre as Autoridades finais e a AR.

2. O Software de AR DEVE suportar, obrigatoriamente, o padrão PKCS #11 [31] na interface com o HSM que protege a chave privada da AR. Opcionalmente, pode suportar e utilizar o modelo OpenSSL engine, o modelo Cryptographic Service Provider (CSP) da Microsoft ou o modelo Java Cryptographic Extension (JCE) nesta interface.

3. O Software de AR DEVE requerer que todas as atividades administrativas e operacionais executadas por seus usuários sejam precedidas por autenticação com, no mínimo, dois fatores; fator conhecimento e fator posse.

4. As interfaces remotas com o usuário devem ser estabelecidas através de canais SSL/TLS.

5. As informações e funcionalidades apresentadas pelo Software de AR aos seus usuários DEVEM estar de acordo com seus privilégios.

37

6. O Software de AR DEVE gerar, para toda autenticação de usuário bem sucedida, um registro que assegure a irretratabilidade do evento.

A.3.2.3 Disponibilidade

1. O Software de AR DEVE suportar mecanismos de redundância que assegurem que, caso ocorra a indisponibilidade em uma instância do software, outra instância seja capaz de atender ao serviço.

A.3.2.4 Usabilidade

1. As interfaces administrativas do Software de AR DEVEM ser do tipo WEB, ou seja, toda ação administrativa DEVE ser viável de ser realizada através de interfaces cujo acesso se faça por intermédio de navegadores WEB e canais seguros SSL/TLS.

Capítulo B

HSMEsta seção relaciona os requisitos funcionais e não funcionais que devem ser atendidos pelos equipamentos tipo Hardware Security Module (HSM) a serem utilizados em infraestruturas de chaves públicas (ICP).

B.1 Requisitos Gerais

B.1.1 Documentação

1. O HSM DEVE possuir, no mínimo, os seguintes documentos:(a) Manual de Instalação;(b) Manual de Configuração;(c) Manual de Operação.

2. A documentação DEVE incluir o detalhamento das atividades autorizadas para cada papel de usuário do HSM.

B.2 HSM da Autoridade Certificadora OnlineEsta seção relaciona os requisitos que devem ser atendidos pelos equipamentos HSM para Autoridade Certificadora online.

38

B.2.1 Requisitos Funcionais

B.2.1.1 Ciclo de vida de chaves criptográficas

1. O HSM DEVE permitir o gerenciamento seguro do ciclo de chaves assimétricas (geração, associação a certificado, replicação, backup, ativação de uso e destruição) para uma Autoridade Certificadora subordinada online

B.2.1.2 Papeis de usuários

1. O HSM DEVE suportar, no mínimo, os seguintes papéis de usuários:Administrador (ou oficial de segurança) papel designado para a

execução de operações de iniciação do HSM, criação de usuários e geração de chaves criptográficas;

Operador (ou gestor de chaves ou custodiante de chaves) papel designado para a autorização de uso de chaves criptográficas;

2. (OPCIONAL) O HSM DEVE suportar o papel de auditor, que possibilite somente realizar a consulta de registros (logs).

B.2.1.3 Registros de auditoria (logs)

1. O HSM DEVE gerar registros de auditoria, no mínimo, dos seguintes eventos:(a) Iniciação; (b) Encerramento (shutdown); (c) Criação de usuários; (d) Remoção de usuários.

2. (OPCIONAL) O HSM DEVE gerar registros de auditoria de todas as operações realizadas, incluindo o uso das chaves privadas. Estes registros DEVEM ser possíveis de auditoria.

B.2.1.4 Operação

1. O HSM DEVE permitir a atualização de firmware. Esta atualização DEVE possuir mecanismos de verificação de integridade dos dados de atualização.

2. O HSM DEVE realizar auto-testes documentados com o objetivo de identificar eventual comprometimento do sistema. No mínimo, o auto-teste DEVE ocorrer a cada iniciação do HSM.

39

B.2.2 Requisitos não funcionais

B.2.2.1 Tecnologia

1. O HSM DEVE suportar uma das seguintes interfaces abertas para interação com a aplicação:

(a) PKCS #11;(b) Engine OpenSSL;

B.2.2.2 Segurança

1. O HSM DEVE ser compatível com a certificação, no mínimo, FIPS 140-2 nível 3 [19], CC EAL 4 [27, 25, 26] ou equivalente.

2. O HSM DEVE permitir a configuração de autenticação utilizando esquema de segredo compartilhado entre usuários para ativação do uso das chaves criptográficas ou na iniciação do HSM.

3. (OPCIONAL) O HSM DEVE suportar segregação de repositórios de chaves. Deve ser possível configurar a gestão independente, pelos operadores (gestores de chaves), de cada repositório de chaves.

4. O HSM DEVE suportar a configuração de autenticação de usuário baseada em dois fatores:

(a) Conhecimento (senha, PIN, etc.);(b) Posse de dispositivo.

5. (OPCIONAL) O HSM DEVE possuir um teclado ou PED específico para a digitação segura de senhas ou PINs.

6. (OPCIONAL) O HSM DEVE possuir interfaces de comunicação segregadas para as atividades de gestão (administração, operação e auditoria) e uso da chave privada.

7. O HSM DEVE possuir controles que garantam a integridade no momento de seu recebimento, devendo estar selado dentro de pacotes que evidenciem a violação, a fim de prevenir acesso não autorizado ao dispositivo e seus componentes.

8. Caso o HSM possua uma senha padronizada de autenticação inicial, esta DEVE ser passível de alteração na primeira autenticação.

B.2.2.3 Desempenho

1. O HSM DEVE oferecer o desempenho de, no mínimo, 25 assinaturas por segundo RSA com tamanho de chave 2048 bits.

40

B.2.2.4 Suporte a algoritmos criptográficos

1. O HSM DEVE suportar, no mínimo, os algoritmos de criptografia assimétrica, algoritmos de geração de chave assimétrica e tamanhos de chave relacionados no Anexo D.

2. O provedor criptográfico associado ao HSM DEVE suportar, no mínimo, os algoritmos criptográficos de hash relacionados no Anexo D.

3. O HSM e o seu provedor criptográfico DEVEM suportar, no mínimo, as suítes de assinatura relacionadas no Anexo D.

4. O HSM DEVE possuir o gerador de números pseudo-aleatórios conforme o documento ANSI X9.31 [3], SP 800-90 [5] ou outro documento publicado por uma entidade de padronização reconhecida, como o NIST, ETSI ou CEN.

B.2.2.5 Replicação de chaves criptográficas

1. O HSM DEVE possuir controles que permitam a replicação de suas chaves criptográficas em outros HSMs autorizados. A replicação DEVE ser possível de ser realizada somente nos HSMs autorizados. A replicação DEVE ser possível de ser realizada somente após autorização via autenticação utilizando esquema de segredo compartilhado entre usuários.

2. (OPCIONAL) O transporte de chaves criptográficas no processo de replicação DEVE ser realizado através de um dispositivo de nível de segurança, no mínimo, FIPS 140-2 nível 3 [19], CC EAL 4 [27, 25, 26] ou equivalente.

3. Caso a replicação de chaves criptográficas não seja realizada através de um dispositivo de nível de segurança, no mínimo, FIPS 140-2 nível 3 [19], CC EAL 4 [27, 25, 26] ou equivalente, DEVE ser realizada utilizando um dos algoritmos de criptografia simétrica e tamanhos de chave relacionado no Anexo D.

B.2.2.6 Backup de chaves criptográficas

1. O HSM DEVE permitir o backup de segurança de chaves criptográficas e parâmetros críticos de segurança (PCS) mediante autorização utilizando esquema de segredo compartilhado entre usuários.

2. (OPCIONAL) O backup de segurança de chaves criptográficas e parâmetros críticos de segurança (PCS) DEVEM ser armazenados em um dispositivo de nível de segurança, no mínimo, FIPS 140-2 nível 3 [19], CC EAL 4 [27, 25, 26] ou equivalente.

3. Caso o backup de chaves criptográficas não seja realizado através de um dispositivo de nível de segurança, no mínimo, FIPS 140-2 nível 3 [19], CC EAL 4 [27, 25, 26] ou equivalente, DEVE ser realizado utilizando um dos algoritmos de criptografia simétrica relacionados no Anexo D.

41

4. (OPCIONAL) O HSM DEVE possuir controles que permitam que a recuperação de uma chave em backup possa ser realizada somente em HSMs autorizados;

5. A rotina de restauração do backup de chaves criptográficas no HSM DEVE possuir mecanismo de verificação de integridade do backup.

B.2.2.7 Características físicas

1. O HSM DEVE ser portátil, possuindo dimensões inferiores a 48 cm (19 polegadas) de largura, 30 cm de profundidade e 20 cm de altura, de forma a permitir sua montagem em armário rack de largura de 19 polegadas.

2. O HSM DEVE ser um equipamento independente. Não é permitido o uso de placas criptográficas.

3. O equipamento DEVE possuir indicadores visuais sobre seu estado operacional.

4. O HSM DEVE ser portátil, possuindo dimensões inferiores a 30 cm de largura, 30 cm de profundidade e 20 cm de altura.

B.3 HSM para proteção de chave privada de aplicação

Esta seção relaciona os requisitos que DEVEM ser atendidos pelos equipamentos HSM para proteção de chave privada de aplicação.

B.3.1 Requisitos funcionais

B.3.1.1 Ciclo de vida de chaves criptográficas

1. O HSM DEVE permitir o gerenciamento seguro do ciclo de chaves assimétricas (geração, replicação, backup, ativação de uso e destruição).

B.3.1.2 Papeis de usuários

1. O HSM DEVE suportar, no mínimo, os seguintes papéis de usuários:Administrador (ou oficial de segurança) papel designado para a

execução de operações de iniciação do HSM, criação de usuários e geração de chaves criptográficas;

Operador (ou gestor de chaves ou custodiante de chaves) papel designado para a autorização de uso de chaves criptográficas;

42

B.3.1.3 Registros de auditoria (logs)

1. (OPCIONAL) O HSM DEVE gerar registros de auditoria, no mínimo, dos seguintes eventos:

(a) Iniciação;(b) Encerramento (shutdown);(c) Criação de usuários;(d) Remoção de usuários;

B.3.1.4 Operação

1. O HSM DEVE permitir a atualização de firmware. Esta atualização DEVE possuir mecanismo de verificação de integridade dos dados de atualização.

2. O HSM DEVE realizar auto-testes documentados com o objetivo de identificar eventual comprometimento do sistema. No mínimo, o auto-teste DEVE ocorrer a cada iniciação do HSM.

B.3.2 Requisitos não funcionais

B.3.2.1 Tecnologia

1. O HSM PODE ser um equipamento independente ou uma placa criptográfica.2. Caso seja um equipamento independente, DEVE possuir indicadores visuais

sobre seu estado operacional.3. O HSM DEVE suportar a interface PKCS #11 para interação com a aplicação

e, opcionalmente, as interfaces Engine OpenSSL, Microsoft CSP/CryptoAPI e JCE.

B.3.2.2 Segurança

1. O HSM DEVE ser compatível com a certificação, no mínimo, FIPS 140-2 nível 3 [19], CC EAL 4 [27, 25, 26] ou equivalente.

2. O HSM DEVE possuir controles que garantam a integridade no momento de seu recebimento, devendo estar selado dentro de pacotes que evidenciem a violação, a fim de prevenir acesso não autorizado ao dispositivo e seus componentes.

3. Caso o HSM possua uma senha padronizada de autenticação inicial, esta DEVE ser passível de alteração na primeira autenticação.

43

B.3.2.3 Desempenho

1. O HSM para aplicação DEVE oferecer o desempenho de, no mínimo, 100 assinaturas por segundo de criptografia RSA com tamanho de chave 1024 bits.

B.3.2.4 Suporte a algoritmos criptográficos

1. O HSM para aplicação DEVE suportar, no mínimo, os seguintes algoritmos de criptografia assimétrica:

Algorítmo de Criptografia Assimétrica ReferênciasRSA 1024 bits 3*RFC 3447 [30]RSA 2048 bitsRSA 4096 bits

2. O provedor criptográfico associado ao HSM para aplicação DEVE suportar,

no mínimo, os algoritmos criptográficos de hash relacionados no Anexo D.3. O HSM para aplicação e o seu provedor criptográfico DEVEM suportar, no

mínimo, as seguintes suítes de assinatura:

Suite de assinatura Descrição ReferênciasSHA1 com RSA sha1WithRSAEncryption

(id-sha1 com padding emsa-pkcs1- v1.5 ou emsa-pkcs1- v2.1 e rsaEncryption)

RFC 3279 [6]

SHA256 com RSA sha256WithRSAEncryption (id-sha256 com padding emsa-pkcs1-v1.5 e rsaEncryption)

RFC 3447 [30]

4. O HSM DEVE possuir o gerador de números pseudoaleatórios conforme o documento ANSI X9.31 [3], SP 800-90 [5] ou outro documento publicado por uma entidade de padronização reconhecida, como o NIST, ETSI ou CEN.

B.3.2.5 Replicação de chaves criptográficas

1. O HSM DEVE possuir controles que permitam a replicação de suas chaves criptográficas em outros HSMs.

44

B.3.2.6 Backup de chaves criptográficas

1. O HSM DEVE permitir o backup de segurança de chaves criptográficas e parâmetros críticos de segurança (PCS).

2. O backup de segurança de chaves criptográficas e parâmetros críticos de segurança (PCS) DEVEM ser armazenados em um dispositivo de nível de segurança, no mínimo, FIPS 140-2 nível 3 [19], CC EAL 4 [27, 25, 26] ou equivalente ou armazenado em uma mídia utilizando um dos algoritmos de criptografia simétrica, algoritmos de geração de chaves e tamanhos de chave relacionados no Anexo D.

B.3.2.7 Características físicas

1. O HSM DEVE permitir sua montagem em armário tipo rack, com dimensões de largura de 19".

Capítulo C

Infraestrutura de TICC.1 IntroduçãoEste documento define os requisitos mínimos para os equipamentos e componentes da infraestrutura de Tecnologia da Informação e Comunicação (TIC) para o ambiente operacional da instalação principal, da instalação de contingência e do ambiente de homologação de uma ICP, incluindo:

• Equipamentos de rede; • Computadores e servidores; • Softwares e aplicativos; • Outros equipamentos.

C.2 Equipamentos de Rede

C.2.1 Switch Ethernet

1. O switch Ethernet DEVE atender aos seguintes requisitos:(a) Possuir uma interface serial RS232 para console local;(b) Possuir minimamente 24 portas autosense 10/100 Ethernet;

45

(c) Possuir minimamente 2 portas 10/100/1000 Ethernet;(d) Oferecer suporte à VLANs por porta;(e) Suportar a configuração de minimamente 10 VLANs;(f) Permitir desabilitação de portas;(g) Oferecer suporte à IEEE 802.1D Spanning-Tree Protocol;(h) Encaminhar minimamente 6,5 milhões de pacotes por segundo

(tamanho de pacote de 64bytes);(i) Permitir autenticação IEEE 802.1x;(j) Montável em rack 19";(k) Ser fornecido acompanhado de kit de suporte específico para

montagem em rack de 19";(l) Gerenciamento via Web;(m)Permitir gerência de tráfego e QoS e CoS (IEEE 802.1p);(n) Ser compatível com protocolo de gerenciamento SNMP v3.

C.2.2 Firewall de Borda

1. O firewall de borda DEVE atender aos seguintes requisitos físicos:(a) Montável em rack de 19";(b) Vir acompanhado de kit de suporte específico para montagem em rack

de 19";(c) Possuir minimamente 6 portas 10/100/1000 Ethernet compatíveis com

conectores RJ-45;(d) Possuir um sistema de gerência que permita configuração das

funcionalidades e regras de proteção, gerenciamento de eventos, visualização de eventos em tempo real;

(e) Disponibilizar informações de logs de forma consolidada e centralizada;

(f) Ser compatível com protocolo de gerenciamento SNMP V3;(g) Suportar tradução de endereçamento (NAT) estático e dinâmico;(h) Permitir a definição de regras que tenham endereços IP como origem

ou destino;(i) Permitir a definição de regras para bloqueio da saída de dados de

endereços IP Específicos;(j) Suportar os protocolos de rede virtual privada OpenVPN, PPTP e

IPSEC;(k) Suportar os algoritmos de criptografia DES, 3DES, AES-128 e AES-

256 para conexões site-to-site e client-to-site;(l) Possuir capacidade de 40.000 conexões/segundo;(m)Possuir vazão (throughput) simultânea mínima de 2,3 Gbps;(n) Possuir capacidade de processamento mínimo de 1.000 regras;

46

(o) Mecanismos de proteção contra ataques DoS e DDoS;

C.3 Servidores

1. O servidor DEVE atender aos seguintes requisitos gerais:

(a) Possuir no mínimo 2 processadores com quatro núcleos cada um;(b) Cada processador deve possuir minimamente 2.13GHz;(c) Possuir no mínimo 8 GBytes de memória RAM DDR-3;(d) Possuir no mínimo 1,5TB de espaço de armazenamento em discos

rígidos hot-swap, do tipo SATA II;(e) Os discos rígidos devem ter capacidade mínima de 500GBytes e

possuir velocidade mínima de 7.200RPM;(f) Controlador RAID com suporte a RAID 0 e RAID 1;(g) Possuir minimamente 4 interfaces de rede 10/100/1000 Ethernet com

conectores RJ 45;(h) Possuir fonte redundante;(i) Montável em rack 19";(j) Incluir trilhos deslizantes para rack padrão 19";(k) Gabinete do tipo rack;(l) Possuir leitor de DVD+/-RW;(m)Possuir alguma interface de comunicação rápida como o sistema de

backup, tal como SAS;(n) Possuir sistema operacional e respectiva licença compatível com todas

as aplicações que nele executarão.

C.4 Softwares e aplicativos

C.4.1 Aplicação servidora DNS

1. A aplicação servidora DNS DEVE ser baseada no servidor Bind (ISC) ou Microsoft DNS Server.

C.4.2 Aplicação servidora de logs

1. A aplicação de gerenciamento de logs DEVE atender aos seguintes requisitos gerais:

(a) Possibilitar recebimento de logs de múltiplas aplicações organizando os logs em base de dados;

47

(b) Possuir uma interface de visualização e consolidação de logs com funcionalidade e apresentar últimos logs acima de um determinado nível de severidade;

(c) Possuir software de gerência de logs;(d) Permitir recebimento de logs UDP port 514 no formato Syslog.

2. O servidor que executa a aplicação de gerenciamento de logs deve possuir todos os serviços não pertinentes à coleta e gerência de logs desabilitados ou desativados.

C.4.3 Aplicação servidora NTP

1. A aplicação servidora NTP DEVE atender aos seguintes requisitos gerais:(a) Suportar o protocolo NTP [34]; (b) Possibilitar sincronização com minimamente três fontes de NTPs

externos através de apontamento por URL ou IP; (c) Possibilitar configuração de hierarquia de servidores; (d) Permitir ajustes de DST local; (e) compatível com sincronização com precisão de, no mínimo, 100 ms.

C.4.4 Aplicação servidora LDAP

1. A aplicação servidora LDAP DEVE possibilitar a manutenção de dados sobre a identidade do usuário e dados para autenticação do usuário.

2. A aplicação servidora LDAP deve ser baseada em um dos seguintes sistemas: Active Diretory (MS Windows) ou compatível com X.500.

C.4.5 Aplicação servidora WEB

1. A aplicação servidora WEB DEVE ser baseada em um dos seguintes softwares servidor WEB: IIS. Apache ou Tom Cat.

C.5 Outros Equipamentos

C.5.1 Switch KVM

1. O Keyboard Video Mouse (KVM) DEVE atender aos seguintes requisitos:(a) Montável em rack de 19";

48

(b) Ser acompanhado de kit de suporte específico para montagem em rack de 19";

(c) Possuir altura máxima de 2Us;(d) Permitir o controle de no mínimo 8 servidores;(e) As conexões de vídeo devem ser compatíveis com VGA ou DVI;(f) As conexões com teclado e mouse devem ser compatíveis com USB

ou PS2;(g) Ser acompanhado dos cabos necessários para conexão aos servidores;(h) Permitir o chaveamento entre portas através de botões na parte frontal

do chaveador.

C.5.2 Sistema de Backup

1. O sistema de backup DEVE incluir software e hardware de backup com as seguintes características:

(a) Hardware de backup:(b) Gabinete para montagem em rack;(c) Gabinete com indicação do estado operacional;(d) Conexão com o computador através de interface SAS (Serial Attached

SCSI) caso se adota esta interface. Se for adotado outra forma de comunicação, esta deve ser especificada;

(e) Suporte a minimamente 1 cartucho de fita LTO-4;(f) Leitor de código de barras para identificação do cartucho de fita;(g) Cabos e acessórios necessários para interconexão e operação;(h) Gerenciamento remoto via WEB através de interface 10/100 baseT

Ethernet;(i) Suporte a cartucho de fita de limpeza(j) Software de backup:(k) Software de gerenciamento e automação de backup;(l) Suporte a backup de sistemas Windows Unix e Linux;(m)Agentes para sistemas operacionais com capacidade de realizar backup

de snapshot de sistema de arquivos, backup de diretórios e backup bases de dados de todos os sistemas e equipamentos ofertados.

(n) Suporte aos sistemas operacionais utilizados em todos os equipamentos ofertados;

(o) Suporte a backup com compressão;(p) Suporte a backup com criptografia;(q) Para cada sistema de backup DEVEM ser fornecidos os seguintes

itens: i. 16 cartuchos de fita LTO-4; ii. 16 códigos de barra para cartuchos de fita

49

iii. 2 cartuchos de fita de limpeza; iv. 2 códigos de barra para fita de limpeza.

Capítulo D

Padrões e Algoritmos CriptográficosD.1 IntroduçãoEsta seção descreve os algoritmos criptográficos, tamanhos de chaves e padrões de formatos que DEVEM ser suportados pelos equipamentos e sistemas.

Tabela 1: Algorítmos Criptográficos Objeto Algorítmo Identificador Referência

Algorítmos de hash

SHA-1 id-sha1 FIPS PUB 180-3 [21] e RFC 3279 [6]

SHA256 id-sha256 FIPS PUB 180-3 [21] e RFC 4055 [38]

SHA512 id-sha512 FIPS PUB 180-3 [21] e RFC 4055 [38]

Algorítmos de criptografia simétrica

3DES (TDES) de 112 bits

– FIPS PUB 46-3 [18]

3DES (TDES) de 168 bits

– FIPS PUB 46-3 [18]

AES 128, 192 ou 256 bits

– FIPS PUB 197 [20]

Modo de operação para criptografia simétrica

CBC – NIST SP 800-38A [10]

Algorítmos de criptografia assimétrica

RSA rsaEncryption RFC 3447 [30] e RFC 3279 [6]

ECDSA (ecdsa-fp ou ecdsa-F2m)

id-ecPublicKey ANSI X9.62 [4] e RFC 3278 [7]

Algoritmos de geração de chaves assimétricas

RSA: rsagen1 – –

ECDSA-Fp: ecgen1

– ANSI X9.62 [4]

ECDSA-F2m: ecgen2

– ANSI X9.62 [4]

Suite de assinatura

SHA-1 com RSA sha1WithRSAEncryption (id-sha1 com padding emsa-pkcs1- v1.5 ou emsa-pkcs1- v2.1 e rsaEncryption)

RFC 3279 [6]

SHA256 com RSA

sha256WithRSAEncryption (id-

RFC 3447 [30] e RFC 4055 [38]

50

sha256 com padding emsa-pkcs1-v1.5 e rsaEncryption)

SHA256 com ECDSA

ecdsa-with-SHA256 (id-sha256 sem padding com ecdsa com curva secp256r1)

ANSI X9.62 [4] e RFC 5480 [40]

SHA512 com ECDSA

ecdsa-with-SHA512 (id-sha512 sem padding com ecdsa com curva secp521r1)

ANSI X9.62 [4] e RFC 5480 [40]

D.2 Tamanhos de chaves criptográficasA Tabela 2 apresenta os tamanhos de chaves criptográficas que DEVEM ser suportados pelos equipamentos e sistemas.

Tabela 2: Tamanhos de chaves criptográficas

Objeto Algorítmo Tamanhos de chave permitidos

2*Chave assimétrica da entidade certificadora

RSA 1024, 2048 e 4096

ECDSA 256 e 512 2*Chave assimétrica da entidade final

RSA 1024, 2048 e 4096

ECDSA 256 e 512 2*Chave assimétrica da Entidade de serviço OCSP

RSA 1024, 2048 e 4096

ECDSA 256 e 512

D.3 Padrões de formatosA Tabela D.3 apresenta os padrões de formatos que DEVEM ser suportados pelos equipamentos e sistemas.

Tabela 3: Padrões de formatosObjeto Padrão Referência

Solicitação de certificados (CSR)

Formato PKCS #10 RFC 2986 [36]

CodificaçãoNativo DER ITU-T [28]

PEM sobre nativo DER PEM [33]

Expedição de certificados

Formato CMS SignedData RFC 5652 [23]Codificação Nativo BER / DER ITU-T [28]

PEM sobre BER / PEM [33]

51

DER

Certificado

Sintaxe X.509 v3 RFC 5280 [9]

CodificaçãoNativo DER ITU-T [28]

PEM sobre nativo DER PEM [33]

Chave pública distribuìda

Ver Algoritmos de Criptografia Assimétrica 

–

Suíte de assinatura do certificado

Ver Suite de Assinatura  –

Lista de Certificados Revogados

Sintaxe X.509 v2 RFC 5280 [9]Codificação Nativo DER ITU-T [28]

PEM sobre nativo DER PEM [33]

Suíte de assinatura do certificado

Ver Suite de Assinatura  –

OCSP

Sintaxe da Requisição OCSP Request RFC 2560 [35]Sintaxe da Resposta OCSP Response RFC 2560 [35]Algoritmos de hash utilizados no campo

CertID

Ver algorítmos de hash  –

Suíte de Assinatura da Resposta

Ver Suite de Assinatura  –

Carimbo do Tempo

Sintaxe da Requisição TimeStampReq RFC 3161 [1]Sintaxe da Resposta TimeStampResp RFC 3161 [1]

CMS do TimeStampResp contendo atributo

assinado ESSCertIDv2

RFC 3161 [1]

Algoritmo de hash utilizado no campo

MessageImprint

Ver algorítmos de hash  –

Suíte de Assinatura da Resposta

Ver Suite de Assinatura  –

Demais objetos assinados

CMS Perfis CAdES CAdES [13] e CMS [23]

XMLDSig Perfis XAdES XAdES [14] e XMLDSig [11]

PDF PAdES Enhanced e PAdDES LTV Profile

PAdES Enhanced [16] e PAdES LTV

Profile [15]

Capítulo E

GlossárioAutoridade Certificadora (AC) Entidade que emite, renova ou revoga

certificados digitais de outras ACs ou de titulares finais. Além disso, emite e publica LCR.

Autoridade de Registro (AR) Entidade que verifica e registrar as informações

52

de um requerente de certificado digital. Após a verificação, avisa a Autoridade Certificadora que ela pode emitir o certificado correspondente.

Backplane Painel traseiro. Este termo é normalmente associado ao barramento de comunicação interno ao equipamento.

Backup Do inglês: cópia de segurança. Cópia de dados de um dispositivo de armazenamento, geralmente para que os dados possam ser restaurados em caso da perda dos dados originais por apagamentos acidentais ou corrupção de dados.

Bits Unidade de medida de dados binários. Do inglês, BInary digiT.Firmware Programa ou conjunto de instruções operacionais programadas

diretamente no hardware de um equipamento eletrônico. É armazenado permanentemente num circuito integrado (chip) de memória de hardware, como uma ROM, PROM, EPROM ou ainda EEPROM e memória flash, no momento da fabricação do componente. Alguns sistemas permitem a atualização do firmware.

HSM Hardware Security Module. Equipamento que permite o armazenamento de conteúdos sensíveis, como chaves privadas, de forma segura.

KVM Chaveador de monitor, mouse e teclado (Keyboard, Video and Mouse). Permite que vários computadores possam ser controlados a partir de um único conjunto de monitor, mouse e teclado.

LOG Conjunto de registros que lista as atividades realizadas por uma máquina ou usuário específico. Um único registro é conhecido como ’registro de log’. Em termos de segurança, os logs são usados para identificar e investigar as atividades suspeitas e estudar as tentativas (ou os sucessos) dos ataques, para conhecimento dos mecanismos usados e aprimoramento do nível de eficiência da segurança.

LUN Logical unit number é o identificador da interface SCSI.mídia Material físico onde podem ser armazenados dados.Rack Estrutura para a montagem de equipamentos com dimensões padronizadas.Rede AR Rede lógica dos serviços de AR.Rede de Operadores Rede lógica usada pelos operadores dos serviços internos

da AC.Rede Intranet Rede lógica localizada no nível de segurança 2.Rede OCSP Rede lógica dos serviços de OCSP.Rede sensível Rede lógica localizada no nível de segurança 4 usada

exclusivamente para acesso aos serviços da AC e desta para publicar os dados.Segredo compartilhado Também denominado esquema MxN. Refere-se ao

método de distribuição de segredo entre os participantes, sendo que cada participante possui uma partição do segredo. O segredo pode ser reconstruído somente quando uma quantidade suficiente de partições for combinada.

WEB Do inglês: teia. Relacionado a World Wide Web (que em português significa: "Rede de alcance mundial"; também conhecida como WWW) é um sistema de documentos em hipermídia que são relacionados entre si na Internet.

53