DAS QUANTIDADES, ESPECIFICAÇÕES E GARANTIAS DOS EQUIPAMENTOS
1. QUANTIDADES
ITEM
EQUIPAMENTO DE
SEGURANÇA
MULTIFUNÇÃO
TIPO 1
QTD
GARANTIA
DESTINAÇÃO
4
48 meses
2 para firewall externo para o MJ em Brasília-DF;
2 para firewall interno para o MJ em Brasília-DF;.
EQUIPAMENTO DE
SEGURANÇA
MULTIFUNÇÃO
TIPO 2
16
48 meses
2 para o DRCI em Brasília-DF;
2 para o CCBB em Brasília-DF;
2 para o Arquivo Central em Brasília-DF;
2 para a Força Nacional em Brasília-DF;
2 para a Penitenciaria Federal de Catanduvas-PR;
2 para a Penitenciaria Federal de Campo Grande-MS;
2 para a Penitenciaria Federal de Porto Velho-RO;
2 para a Penitenciaria Federal de Mossoró-RN.
EQUIPAMENTO DE
GERÊNCIA
CENTRALIZADA
2
48 meses
2 Gerências Centralizadas em Brasília-DF;
2. ESPECIFICAÇÕES
2.1. CARACTERÍSTICAS
MULTIFUNÇÃO:
COMUNS
2.1.1. Características gerais
AOS
EQUIPAMENTOS
DE
SEGURANÇA
2.1.1.1.
Equipamento do tipo “appliance”, dedicado a firewall,
terminação de túneis IPSEC e com suporte à terminação de
conexões SSL-VPN (modelos “clientless” e “client-based”);
2.1.1.2.
Deve ser montável em rack de 19 polegadas (devem ser
fornecidos os kits de fixação necessários). A altura máxima dos
equipamentos fornecidos deve ser de duas unidades de rack (2
RUs).
2.1.1.3.
Deve ser fornecido com fontes redundantes internas ao
equipamento.
2.1.1.4.
Deve possuir porta serial para acesso console ao equipamento.
2.1.1.5.
Deverá permitir integração com solução de gerência centralizada
de forma a permitir a visualização de eventos.
2.1.1.6.
A solução deve permitir exportar os relatórios para pelo menos
dois dos seguintes formatos HTML, MHTML, DOC, XLS, PDF
e TXT.
2.1.1.7.
Deve ser gerenciável por meio dos protocolos HTTPS e SSH.
2.1.1.8.
Deve suportar protocolo AAA para controle de acesso
administrativo aos equipamentos. Deve ser possível especificar
conjuntos de comandos acessíveis a cada grupo de usuários
administrativos e cada comando deve ser autorizado
individualmente no servidor AAA. Todos os comandos
executados bem como todas as tentativas não autorizadas de
execução de comandos devem ser enviados ao servidor AAA.
2.1.2. Características de Firewall
2.1.2.1.
Deve suportar funcionalidade de Stateful Firewall. Não deve
haver restrição de número de usuários simultâneos através do
equipamento para a licença de software fornecida para a
funcionalidade de Stateful Firewall;
2.1.2.2.
Deve suportar a definição de VLAN trunking conforme padrão
IEEE 802.1q. Deve ser possível criar as interfaces lógicas (L3)
associadas às VLANs e estabelecer regras de filtragem (Stateful
Firewall) entre estas;
2.1.2.3.
Deve construir registro de fluxos de dados relativos a cada
sessão iniciada, armazenando para cada uma destas sessões
informações tais como endereços de origem e destino dos
pacotes, portas TCP (e UDP) de origem e destino, bem como
números de sequência dos pacotes TCP, status dos flags “ACK”,
“SYN” e “FIN”;
2.1.2.4.
O equipamento deve permitir a “randomização” do número de
sequência TCP, ou seja, funcionar como um “proxy” de número
de sequência TCP de modo a garantir que um host situado em
uma interface considerada “externa” (insegura), sob o ponto de
vista de política de segurança do firewall, nunca tenha acesso ao
número de sequência TCP real do host seguro (interno ao
firewall) em uma sessão estabelecida entre os referidos hosts;
2.1.2.5.
Deve ser fornecido com todos os acessórios e licenças para
funcionamento em cluster;
2.1.2.6.
Possuir suporte a filtragem “stateful” para pelo menos os
seguintes protocolos de aplicação: Oracle SQL*Net Access,
Remote Shell, FTP, HTTP, SMTP, H.323, H.323 v2, ILS
(Internet Locator Service), LDAP e ESMTP.
2.1.2.7.
Deve implementar remontagem virtual de fragmentos (“Virtual
Fragment Reassembly”) em conjunto com o processo de
inspeção stateful. Deve ser possível estabelecer o número
máximo de fragmentos por pacotes e timeouts de remontagem.
2.1.2.8.
Deve prover proteção contra IP spoofing (por interface), sem
necessidade de configuração de listas de controle de acesso.
2.1.2.9.
Deve suportar operação stateful em modo transparente (bridge
mode).
2.1.2.10. Deve proteger aplicações de VoIP suportando os protocolos de
sinalização H323, SIP, MGCP e SCCP. Devem ser suportadas,
no mínimo, as seguintes funcionalidades:
 Criação e terminação dinâmica das conexões de
sinalização assim como abertura/fechamento das portas
de mídia (RTP/RTCP) negociadas dentro da sessão de
sinalização.
 Filtragem stateful dos protocolos de Telefonia IP
citados em ambientes com NAT e PAT (NAT hide).
 Logging das conexões dinâmicas criadas e visualização
das conexões criadas (sinalização e mídia) em
ambientes com e sem NAT.
2.1.2.11. Possuir capacidade de limitar o número de conexões TCP
simultâneas para um endereço de destino especificado.
2.1.2.12. Possuir capacidade de limitar o número de conexões TCP
incompletas (‘half-open’) simultâneas para um endereço de
destino especificado.
2.1.2.13. Possuir capacidade de limitar o número de conexões TCP
simultâneas para cada IP de origem (sem necessidade de
especificar tal endereço IP).
2.1.2.14. Possuir capacidade de limitar o número de conexões TCP
incompletas (‘half-open’) simultâneas para cada IP de origem
(sem necessidade de especificar tal endereço IP).
2.1.2.15. Possibilitar o registro de toda a comunicação realizada através
do firewall e de todas as tentativas de abertura de sessões e
conexões que por ele forem recusadas.
2.1.2.16. Deve suportar agrupamento lógico de objetos (“object
grouping”) para criação de regras de filtragem. Deve ser
possível criar grupos de pelo menos os seguintes tipos de
objetos: hosts, redes IP, serviços. Deve ser possível verificar a
utilização (“hit counts”) de cada regra de filtragem (“Access
Control Entry”) individualmente, independentemente do fato de
a configuração da política ter utilizado o conceito de
agrupamento lógico de objetos.
2.1.2.17. Deve suportar regras de filtragem L3/L4 (listas de controle de
acesso) aplicáveis de forma global (válidas para todas as
interfaces simultaneamente) e regras que sejam válidas apenas
para uma interface lógica específica
2.1.2.18. Deve suportar a tradução do endereço IP carregado em uma
mensagem DNS Reply (NAT na camada de aplicação)
juntamente com a tradução do endereço IP presente no
cabeçalho L3.
2.1.2.19. Implementar políticas de controle de acesso baseadas em
informações de horário (“time-based access control”);
2.1.2.20. Devem ser implementadas políticas de firewall por usuário. O
firewall deve ser capaz de obter as credenciais do usuário
através de um prompt padrão HTTP/HTPPS e, após validação
das credenciais em um servidor RADIUS, aplicar as listas de
controle de acesso (“downloadable ACLs”) informadas pelo
servidor RADIUS e que especificam o tráfego permitido para o
usuário autenticado.
2.1.2.21. Devem ser implementadas políticas de acesso por usuário
obtidas a partir da integração com servidor Active Directory
(AD). Caso tal integração requeira agentes externos, estes
deverão ser fornecidos.
2.1.2.22. Deve suportar a operação stateful em ambientes IPv6,
atendendo, no mínimo os seguintes requisitos:

Deve suportar a criação simultânea de regras IPv4 e
IPv6.

Deve suportar roteamento estático de pacotes IPv6.

Deve suportar anti-spoofing (sem necessidade de
configuração de ACLs) para endereços IPv6.

Deve implementar randomização do número de
sequência TCP para conexões TCP que trafegam sobre
IPv6.

Deve suportar agrupamento lógico de objetos IPv6
(redes, hosts, serviços) e criação de regras (ACLs)
usando tais objetos.

Deve suportar gerenciamento sobre IPv6. Devem ser
suportados pelo menos os seguintes protocolos de
gerência: SSH e HTTPS.

Deve suportar stateful failover de conexões IPv6
2.1.2.23. Possuir suporte a tecnologia de Firewall Virtual, sendo
fornecido com, pelo menos, duas instâncias totalmente isoladas
entre si. Dentro de cada instância de Firewall deve ser possível
definir regras independentes de filtragem, regras de NAT, rotas
e VLANs alocadas.

Dentro de cada instância de Firewall deve ser possível
alocar no mínimo os seguintes tipos de recursos: número
conexões simultâneas, número de endereços IP
traduzidos, número de sessões de gerenciamento
simultâneas, número de endereços MAC.

Dentro de cada instância de Firewall deve ser possível
limitar (promover “rate limiting”) os seguintes recursos:
taxa de estabelecimento de novas conexões, taxa de
inspeção de aplicações, taxa de transmissão de
mensagens Syslog.

A exaustão dos recursos alocados para uma dada
instância de Firewall não deve ter influência sobre a
operação das demais instâncias.
2.1.3. Características de IPS
2.1.3.1. Deve analisar cada um dos pacotes que trafegam pela rede a que
está conectado e também a relação de tais pacotes com os
adjacentes a ele no fluxo de dados da rede (análise de contexto);
2.1.3.2.
Deve utilizar assinaturas construídas com base em informações
de vulnerabilidade e não somente em “exploits” específicos;
2.1.3.3.
Deve suportar a modificação de assinaturas, isto é, permitir a
edição de assinaturas existentes na base de dados, ajustando-se
ao perfil de tráfego de rede;
2.1.3.4.
Deve suportar a criação de assinaturas, isto é, permitir que se
possam criar novas assinaturas e anexá-las à base de dados
existente, adaptando-se as reais necessidades de tráfego de rede
(na criação das novas assinaturas deve ser permitida a utilização
de parâmetros de nível 2 a nível 7 do modelo OSI);
2.1.3.5.
Deve ser possível criar assinaturas do tipo “string-match” e
associá-las a qualquer porta TCP para verificação da ocorrência
de conjunto de caracteres definidos pelo administrador de
política de segurança no conteúdo dos pacotes IP que trafegam
pela rede.
2.1.3.6.
Deve suportar “Protocol Anomaly Detection” como método de
análise de tráfego;
2.1.3.7.
Deve suportar verificação de adequação dos protocolos que
trafegam na rede às definições destes constantes nas RFCs
(análise de “RFC compliance”);
2.1.3.8.
Deve suportar análise “stateful” de pacotes para garantir maior
acurácia de detecção;
2.1.3.9.
Deve detectar ataques associados a protocolos que não estejam
usando as portas canônicas de serviço (portas padrão reservadas
para os protocolos de aplicação);
2.1.3.10. Deve promover reordenação e remontagem de fragmentos IP
antes de efetuar análise;
2.1.3.11. Deve possuir estrutura de “normalização” de tráfego para que
possam combater as técnicas de evasão;
2.1.3.12. Devem ser suportados no mínimo os seguintes tipos de reação
(configuráveis por assinatura de ataque): geração de alerta, gerar
trap SNMP, fazer “logging” dos pacotes gerados pelo sistema
“vítima”, fazer “logging” dos pacotes gerados pelo sistema que
está efetuando o ataque, promover “reset” da conexão TCP,
bloquear o pedido de conexão, bloquear o endereço que está
gerando o ataque de conexão, negar “in-line” os pacotes
associados ao ataque;
2.1.3.13. Deve suportar “logging” de sessão via IP (“IP session logging”).
Os logs devem ser compatíveis com formato “TCPDump”;
2.1.3.14. Deve suportar filtragem de assinaturas por endereço IP de
origem/destino (possibilidade de definir que uma dada
assinatura de ataque deverá ser disparada somente quando
estiver associada a endereços IP origem/destino específicos);
2.1.3.15. Deve possuir capacidade de bloquear tráfego de pelo menos os
seguintes protocolos “peer-to-peer” (kazaa, gnutella, soulseek e
bittorrent);
2.1.3.16. Deve possuir capacidade de bloquear tráfego de “instant
messagers”;
2.1.3.17. Deve ser capaz de detectar pelo menos os seguintes tipos de
ataques: Simplex-Mode TCP hijacking, E-mail Spam,
BackOriffice 2000 StealthMode, Unicode Decodes, IIS Unicode
exploit, cross-site scripting, directory traversal, command
injection, SQL Injection, Header Spoofing;
2.1.3.18. Deve ser capaz de detectar atividade de Port Scanning (“Full
connect”, “SYN Stealth”, “FIN Stealth”, UDP);
2.1.3.19. Deverá ter uma base de assinaturas com descrição da utilização
de cada uma delas e tipos de ataques detectados. Deverá ser
possível a atualização de assinaturas em caso de detecção de
novas vulnerabilidades durante o período de vigência do
contrato de suporte e atualizações da licença adquirida.
2.1.4. Características de VPN
2.1.4.1.
Deve implementar a criação de VPNs IPSEC com criptografia
56-bit DES, 168-bit 3DES, 128-bit AES e 256-bit AES . Deve
possuir desempenho de no mínimo 300 Mbps para tratamento de
conexões IPSEC (padrões AES e 3DES). A criptografia deve ser
realizada em hardware;
2.1.4.2.
Deve ser suportada a criação de VPNs IPSec usando os padrões
IKEv1 e IKEv2.
2.1.4.3.
Deve suportar a terminação de SSL VPN. Inicialmente será
necessário o fornecimento de licença de software para
terminação de apenas 200 (duzentas) sessões simultâneas SSLVPN;
2.1.4.4.
Devem ser suportados os seguintes modos de terminação SSL
VPN:

SSL VPN sem cliente (modo portal)

SSL VPN com cliente com transporte TCP

SSL VPN com cliente com transporte UDP (Nesse modo
o trafego do cliente SSL VPN é tunelado através do
protocolo DTLS, RFC 4748)
2.1.4.5.
Deve suportar a terminação simultânea de conexões IPSEC
VPN e SSL VPN;
2.1.4.6.
Deve suportar o uso de certificados digitais emitidos pela
autoridade certificadora ICP Brasil para autenticação das VPNs
IPSec e SSL;
2.1.4.7.
Características específicas de SSL-VPN:

Devem ser suportadas no modo clientless, no mínimo as
seguintes aplicações transportadas sobre conexões SSL:
HTTP, POP3, IMAP4, SMTP, Telnet, SSH, FTP,
Windows Terminal Services, VNC, Outlook/Outlook
Express.

Deve ser possível especificar as URLs acessíveis através
de conexões SSL VPN.

Deve ser possível criar diferentes grupos de usuários
SSL VPN, com definição por grupo, do tipo de serviço
permitido sobre as conexões SSL para o concentrador
(WEB, e-mail, sistemas de arquivos).

Deve ser possível realizar verificação de parâmetros na
máquina do usuário antes da apresentação das
credenciais de identificação ("pre-login"). Deverá ser
possível verificar pelo menos os seguintes atributos:
Chaves de Registro, Arquivos, e a Versão do Sistema
Operacional.

Deve ser possível a criação de regras para verificação da
conformidade da máquina com a política de segurança.
Dever ser possível verificar no mínimo os seguintes
elementos: a instalação, habilitação e atualização do
software antivírus e anti-spyware e existência de
personal firewall habilitado.

Deve suportar autenticação SSL-VPN através de teclado
virtual apresentado ao usuário.

Deve ser possível a criação de políticas de SSL VPN
dinâmicas baseadas pelo menos nos seguintes
parâmetros:




Sistema Operacional Utilizado;
Anti-vírus;
Anti-spyware;
Chave de Registro (existência e valor específico
a ela atribuído);
 Arquivos do sistema;
 Atributos LDAP.
2.2. CARACTERÍSTICAS DO GERENCIAMENTO DA SOLUÇÃO DE SEGURANÇA
2.2.1. Funcionalidades gerais
2.2.1.1. Equipamento do tipo “appliance”, ou solução de hardware e
software, dedicado à solução de gerenciamento centralizado.
Deve ser fornecido com todos os acessórios e licenças para
funcionamento;
2.2.1.2.
A solução de gerenciamento de segurança deve ser baseada em
técnicas de aplicação e gerenciamento de políticas de forma
centralizada, as quais podem ser organizadas de forma
hierárquica e distribuídas para grupos de dispositivos de
segurança ou para todos os dispositivos de segurança já
existentes da rede;
2.2.1.3.
A solução deve implementar uma tabela única de políticas de
segurança, a qual deverá ser utilizada para a distribuição das
políticas por todo o ambiente administrado;
2.2.1.4.
A solução deve possuir ferramenta de análise de tráfego (Flow);
2.2.1.5.
As políticas de segurança dever ser automaticamente adaptadas
de acordo com o dispositivo para o qual ela está sendo enviada;
2.2.1.6.
A solução deve implementar funcionalidade de agrupamento de
políticas que façam referência a um objeto específico a ser
analisado de forma a transformar esse grupo de políticas em
uma única regra que desempenhará o mesmo papel na política
de segurança proposta por um conjunto de regras;
2.2.1.7.
A solução deve possuir ferramenta de análise das regras,
permitindo que sejam analisadas as regras que estão se
sobrepondo ou entrando em conflito com outras regras já
existentes;
2.2.1.8.
A solução deve implementar a contabilidade das regras que
foram atingidas ou entraram em conformidade com o tráfego
que está passando pela rede;
2.2.1.9.
A solução deve permitir a verificação de qual parte da rede,
origem, destino, serviço ou wildcard, está sendo atingido por
determinada regra;
2.2.1.10. A solução deve permitir a detecção de alteração e/ou tentativas
de alteração nos dispositivos por meio de interfaces out-of-band
e avisar ao administrador;
2.2.1.11. A solução deve permitir o gerenciamento de serviços de
segurança integrados, entre os quais QoS em VPN, roteamento e
Controle de Acesso a Rede;
2.2.1.12. A solução deve permitir o agrupamento de dispositivos, de
acordo com a funcionalidade e/ou localização física dos
mesmos, com a finalidade de gerenciar todos os dispositivos de
uma só vez;
2.2.1.13. A solução deve permitir que um dado equipamento possa
pertencer a mais de um grupo simultaneamente;
2.2.1.14. A solução deve permitir a reutilização de objetos a serem
analisados e/ou monitorados em um dispositivo por outros
dispositivos que vierem a fazer parte do ambiente, sem a
necessidade da criação das mesmas políticas novamente;
2.2.1.15. A solução deve permitir o retorno às configurações anteriores
dos dispositivos, para a necessidade de recuperação de falhas;
2.2.1.16. A solução deve permitir o gerenciamento operacional da rede
monitorada, realizando funções de distribuição de softwares,
relatório de inventário de dispositivos.
2.2.1.17. A solução deve ser capaz de testar a conectividade de
equipamentos já foram ou estão sendo adicionados;
2.2.1.18. A solução deve permitir a configuração de servidores de Syslog
e NTP nos equipamentos suportados;
2.2.1.19. A solução deve suportar configuração de alta-disponibilidade
dos equipamentos;
2.2.1.20. A solução deve oferecer a opção de se apresentar uma tela com
a topologia dos firewalls, para fins de monitoramento.
2.2.2. Funcionalidades para VPN
2.2.2.1. A solução deve ser capaz de descobrir configurações existentes
de VPN site-to-site e acesso remoto;
2.2.3.
2.2.2.2.
A solução deve permitir as configurações de VPN nas seguintes
modalidades: site-to-site, hub-and-spoke, full-mesh e extranet;
2.2.2.3.
A solução deve permitir que as VPNs possam ser configuradas
remotamente;
2.2.2.4.
A solução deve permitir a configuração de dispositivos de VPN
com suporte a failover automático e balanceamento de carga.
Funcionalidades para IPS
2.2.3.1.
A solução deve permitir que múltiplas VLANs sejam
configuradas para uma única interface do IPS;
2.2.3.2.
A solução deve implementar a configuração de rate limiting
nos IPSs de forma a impedir que certos tipos de tráfego passem
a consumir banda em excesso;
2.2.3.3.
A solução deve implementar atualização automática das
assinaturas, patches e de outras releases nos IPSs monitorados
2.2.3.4.
A solução deve permitir a cópia das configurações
específicas de cada assinatura de um dispositivo para vários
outros;
2.2.3.5. A solução deve suportar a configuração de:
 Sensores virtuais;
 Detecção de anomalias;
 Reconhecimento de Sistemas Operacionais;
 Criação de assinaturas customizadas;
 Assistente para atualização de assinaturas, pré-visualização e
ajustes de novas assinaturas;
 Gerência de licenças para assinaturas.
2.2.4.
Escalabilidade
2.2.4.1.
Suportar pelo menos 5.000 (cinco mil) equipamentos
(virtuais ou físicos);
2.2.4.2.
Suportar pelo menos 1.600.000 (um milhão e seiscentas mil)
de entradas de controle de acessos (ACEs);
2.2.4.3.
Suportar pelo menos 50.000 (cinquenta mil) ACEs por regra
de firewall;
2.2.4.4.
Suportar pelo menos 20 (vinte) usuários simultâneos com
acesso somente-leitura;
2.2.4.5.
Suportar pelo menos 10 (dez) usuários simultâneos com
acesso privilegiado;
2.2.4.6.
Suportar a configuração de VPN full-mesh de pelo menos
400 (quatrocentos) ativos;
2.2.4.7.
A solução deve suportar operar em modo de “workflow”,
quando é necessária uma aprovação para a distribuição de
configurações;
2.2.4.8.
A solução deve suportar acesso baseado em perfil de usuário
com as permissões de visualizar, modificar, aprovar e distribuir
por tipo de objeto e política;
2.2.4.9.
O acesso aos equipamentos devem ser também ser separados
por perfil de usuário.
2.3. EQUIPAMENTO DE SEGURANÇA MULTIFUNÇÃO TIPO 1
2.3.1. CARACTERÍSTICAS ESPECÍFICAS DO EQUIPAMENTO
MULTIFUNÇÃO TIPO 1 – QUANTIDADE: 4 (QUATRO)
DE
SEGURANÇA
2.3.1.1.
Deve ser fornecido com fontes redundantes internas ao
equipamento;
2.3.1.2.
Deve ser fornecido com pelo menos 02 interfaces
10/100/1000 auto-sense e 04 (quatro) interfaces 10 Gigabit
Ethernet;
2.3.1.3.
Deve suportar o acréscimo de pelo menos 4 (quatro)
interfaces 10 Gigabit Ethernet (10GE);
2.3.1.4.
Deve suportar o acréscimo de pelo menos 8 (oito) interfaces
Gigabit Ethernet 10/100/1000;
2.3.1.5.
Deve permitir a criação de no mínimo 1000 interfaces VLAN
2.3.1.6.
Deve suportar, no mínimo, 2.000.000 (dois milhões) de
conexões simultâneas de firewall em sua tabela de estados;
2.3.1.7.
Deve suportar a criação de pelo menos 200.000 (duzentas
mil) novas conexões TCP por segundo.
2.3.1.8.
Os valores de desempenho especificados nos itens 2.3.1.6 e
2.3.1.7 devem ser fornecidos de forma centralizada. Não serão
aceitas soluções baseadas em combinação de módulos de
firewalls em um chassi.
2.3.1.9.
Deve suportar funcionalidade de Stateful Firewall com
desempenho mínimo de 20 Gbps.
2.3.1.10.
Deve possuir throughput de IPS de pelo menos 2 Gbps;
2.3.1.11.
Deve possuir throughput de VPN de 2 Gbps (com algoritmos
criptográficos 3DES e AES);
2.3.1.12.
Deve suportar o encaminhamento de pelo menos 4.000.000
(quatro milhões) de pacotes por segundo;
2.3.1.13.
Deve implementar pelo menos 4.000 (quatro mil) peers VPN
(túneis IPSec) simultâneos. As licenças de software cliente para
operação nos modelos IKEv1 e IKEv2 devem ser fornecidas
para tal quantidade de usuários.
2.3.1.14.
Deve suportar pelo menos 2.000 (dois mil) peers SSL-VPN
(qualquer combinação dos modelos clientless e client-based).
2.3.1.15.
Deve suportar a adição de novas instâncias virtuais de
Firewall através de licenças de software. Devem ser suportados
um total de pelo menos 100 licenças virtuais, conforme descrito
no item 2.1.2.23
2.4. Equipamento de Segurança Multifunção Tipo 2
2.4.1. CARACTERÍSTICAS ESPECÍFICAS DO EQUIPAMENTO
MULTIFUNÇÃO TIPO 2 – QUANTIDADE: 16 (DEZESSEIS)
2.4.1.1.
2.4.1.2.
DE
SEGURANÇA
Deve possuir pelo menos 05 (cinco) interfaces UTP
10/100/1000;
Deve permitir a criação de no mínimo 200 interfaces VLAN;
2.4.1.3.
Deve suportar, no mínimo, 300.000 (trezentas mil) conexões
simultâneas de firewall em sua tabela de estados;
2.4.1.4.
Deve suportar a criação de pelo menos 25.000 (vinte e cinco
mil) novas conexões TCP por segundo;
2.4.1.5.
Os valores de desempenho especificados nos itens 2.4.1.3 e
2.4.1.4 devem ser fornecidos de forma centralizada. Não serão
aceitas soluções baseadas em combinação de módulos de
firewalls em um chassi.
2.4.1.6.
Deve suportar funcionalidade de Stateful Firewall com
desempenho mínimo de 600 Mbps.
2.4.1.7.
Deve suportar o encaminhamento de pelo menos 400.000
(quatrocentos mil) pacotes por segundo;
2.4.1.8.
Deve possuir throughput de IPS de pelo menos 600 Mbps;
2.4.1.9.
Deve possuir throughput de VPN de 300 Mbps (com
algoritmos criptográficos 3DES e AES);
2.4.1.10.
Deve implementar pelo menos 1.000 (mil) peers VPN (túneis
IPSec) simultâneos. As licenças de software cliente para
operação nos modelos IKEv1 e IKEv2 devem ser fornecidas
para tal quantidade de usuários.
2.4.1.11.
Deve suportar pelo menos 500 (quinhentos) peers SSL-VPN
(qualquer combinação dos modelos clientless e client-based).
2.4.1.12.
Deve suportar a adição de novas instâncias virtuais de
Firewall através de licenças de software. Devem ser suportados
um total de pelo menos 10 (dez) licenças virtuais, conforme
descrito no item 2.1.2.23.
3. DA GARANTIA, ASSISTÊNCIA TÉCNICA E NÍVEIS DE SERVIÇO - SLA
3.1. Os equipamentos deverão ter garantia e assistência técnica, no local onde serão
instalados, por um período mínimo de 48 (quarenta e oito) meses, contado a partir
do recebimento definitivo, sem ônus para o Ministério da Justiça.
3.2. Durante o período de garantia será assegurado o suporte técnico que deverá estar
disponível nas 24 (vinte e quatro) horas, a saber, das 0:00 hs às 24:00 incluindo
sábados, domingos e feriados.
3.3. A abertura de chamado para suporte técnico, sem ônus para o Ministério da
Justiça, deverá ser passível de ser realizado por intermédio de acesso ao suporte no
site do fabricante, telefone, correio eletrônico e/ou fax, para dúvidas e solução de
quaisquer problemas, enquanto estiver vigorando o prazo de garantia da solução,
obrigando-se a contratada iniciar e cumprir os seguintes prazos:
3.3.1. Capitais
3.3.1.1.
Indisponibilidade parcial1 - inicio do atendimento no próximo
dia útil, com período de solução de até 8 horas corridas.
3.3.1.2.
Indisponibilidade total2– reestabelecimento em até 4 horas
corridas.
3.3.1.3.
Serviços de atualização de versão: em até 5 dias, conforme
agendamento definido pelo contratante.
3.3.1.4.
Suporte técnico nível 1 – o suporte via telefone, chat e outros
meios de instant-messenger deverá ser 24x7 (vinte e quatro
horas por dia, sete dias por semana).
3.3.2. Interior
1
3.3.2.1.
Indisponibilidade parcial¹ - inicio do atendimento no próximo
dia útil, com período de solução de até 8 horas corridas.
3.3.2.2.
Indisponibilidade total²– reestabelecimento em até 12 horas
corridas.
3.3.2.3.
Serviços de atualização de versão: em até 5 dias, conforme
agendamento definido pelo contratante.
3.3.2.4.
Suporte técnico nível 1 – o suporte via telefone, chat e outros
meios de instant-messenger deverá ser 24x7 (vinte e quatro
horas por dia, sete dias por semana).
A indisponibilidade parcial compreende desde a impossibilidade de aplicação de uma regra, filtro, atualização
e etc. até a inoperância de um equipamento redundante, deixando a alta disponibilidade comprometida ou
inexistente.
2
A indisponibilidade total compreende a inoperância da solução que pode ser desde o seu gerenciamento,
situação na qual não se consiga aplicar as regras, filtros e atualização, até a inoperância dos equipamentos
redundantes e, por consequência, impossibilidade de acesso aos sistemas e serviços de rede de dados do
contratante.
3.4. A contratada deverá realizar os serviços de suporte técnico a solução, às suas
expensas, obrigando-se a trocar os componentes que apresentarem 3 (três) ou mais
incidentes repetidos ou intercalados no prazo de 60 dias.
3.5. No caso de remoção de algum componente físico da solução para manutenção por
parte da contratada, esta se obriga em colocar um equipamento em atividade com
iguais características, cumprindo todas as características da solução.
3.6. Caso o componente físico original não retorne em 5 dias corridos, a contratada fica
obrigada a fornecer novo componente que se adeque integralmente a solução.
3.7. A falta de solução do problema conforme indicado nos itens anteriores, sem
justificativa aceita pelo MJ, poderá implicar em aplicação de multa no valor
correspondente a 0,02% (zero vírgula zero dois por cento) do valor total da
contratação, por dia de atraso na solução.
3.8. A indisponibilidade do serviço de suporte técnico, assim como da central de
abertura de chamados, poderá implicar em aplicação de multa no valor
correspondente a 0,02% (zero vírgula zero dois por cento) do valor total da
contratação, por dia de indisponibilidade.
3.9. Os chamados abertos somente poderão ser fechados após autorização do MJ.
3.10.
Os chamados deverão ser abertos e fechados somente por pessoal designado
pelo MJ para esse fim.
3.11.
Caso o chamado seja encerrado pela contratada sem que tenha sido
previamente autorizado pelo(s) servidor (es) designado(s), poderá ser aplicada
multa à contratada no valor correspondente a 0,01% (zero vírgula zero um por
cento) do valor total da contratação, por ocorrência.
3.12.
Os preços relativos a deslocamento de técnicos e transporte de componentes e
equipamentos devem estar incluídos no valor do serviço.
3.13.
A contratada apresentará um relatório de assistência técnica para cada
atendimento feito, tenha sido no Ministério da Justiça ou nas instalações da própria
Contratada, contendo data, hora de chamada, início e término do atendimento,
identificação do problema, as providências adotadas e as informações pertinentes,
para acompanhamento e controle da execução do Contrato.
3.14.
Cada relatório de assistência técnica deverá ser assinado por técnico do
Ministério da Justiça, ou por ele indicado, e pelo responsável pelo atendimento da
empresa contratada.
3.15.
Entende-se por início do atendimento a hora da abertura do chamado por
telefone, correio eletrônico ou fax.
3.16.
Entende-se por término do atendimento o momento a partir do qual a solução
estiver disponível e em perfeitas condições de funcionamento.
3.17.
A garantia será dada através da atualização dos softwares em todas as suas
funcionalidades para as novas versões com a disponibilização de arquivos de
correções, assinaturas, atualizações e serviços de execução se solicitados pelo
contratante.
3.18.
As atualizações deverão englobar assinaturas de atualização
funcionalidades do conjunto de softwares, inclusive das assinaturas de filtros.
das