ESPECIFICAÇÕES DO OBJETO
ESPECIFICAÇÕES DO OBJETO
1. OBJETO
1.1. Contratação de empresa especializada para o fornecimento de solução de equipamentos de segurança de perímetro (UTM) e solução de balanceamento de aplicações em modelo de aquisição (compra) contemplando fornecimento hardware, software, licenças e garantia de 36 (trinta e seis) meses, implantação bem como consultoria no ambiente implementado através de analista especialista certificado e com experiência mínima de 5 anos na solução ofertada.
Contratação de empresa especializada em monitoramento e suporte na solução de segurança UTM, contemplando o atendimento de segunda à sexta-feira das 19h até as 07h e aos finais de semana e feriados 0h ate 24h;
2. JUSTIFICATIVA
2.1. A aquisição de infraestrutua de rede e Firewall de perímetro tem por objetivo, viabilizar a infraestrutura de segurança, para atender com eficácia aos mais de dois mil dispositivos conectados à rede do ECP (Esporte Clube Pinheiros), otimizar e controlar todo o tráfego de dados e comunicação do ambiente interno e externo (tanto o ponto de vista de entrada e saída, quanto dos pacotes que passam por ele), mitigando os riscos e ameaças e apto a propiciar pronta resposta a eventuais incidentes ocorridos nas áreas de interesse operacional.
2.2. A solução será utilizada para identificar e controlar aplicações em qualquer porta, possuir controle de aplicações, prevenir vírus e malwares em aplicações corpoativas no ambiente, ter controle sobre o tráfego desconhecido a partir de políticas de segurança, identificar e controlar aplicativos que possuam a mesma conexão, permitir a mesma visibilidade de aplicações e controles para usuários locais e remotos, tornar a segurança de rede mais simples e não mais complexa, com a adição de controles de aplicações e oferecer o mesmo throughput e performance com o controle ativo das aplicações.
3. QUADRO RESUMO
3.1. Contratação sob demanda de empresa especializada para o fornecimento de solução de equipamentos de segurança de perímetro (UTM) appliance e virtual em modelo de aquisição (compra) de equipamento contemplando fornecimento hardware, software, licenças, garantia, implantação, suporte e horas de consultoria especialista.
3.2. Abaixo descrito os itens para efeito de registro de preços para o ECP
item | Descrição | Quantidade |
1 | Solução de Segurança de perímetro (UTM) | 02 |
2 | Solução de Segurança de perímetro firewall virtual | 01 |
3 | 10 GE SFP+ transceiver | 04 |
4 | Solução de gerenciamento de logs e relatórios | 01 |
5 | Solução de Balanceamento de Aplicaçoes (entrada/saída) | 01 |
6 | Serviços de Implantação das soluções | 01 |
4. CARACTERÍSTICAS MÍNIMAS OBRIGATÓRIAS
4.1. Solução de Segurança de perímetro (UTM) e virtual.
Caracteristicas Gerais
4.1.1.1. A solução deve consistir em plataforma de proteção de rede baseada em appliance com funcionalidades de Next Generation Firewall (NGFW), e console de gerência e monitoração;
4.1.1.2. Por funcionalidades de NGFW entende-se: reconhecimento de aplicações, prevenção de ameaças, identificação de usuários e controle granular de permissões;
4.1.1.3. As funcionalidades de proteção de rede que compõe a plataforma de segurança, podem funcionar em múltiplos appliances desde que obedeçam a todos os requisitos desta especificação;
4.1.1.4. A plataforma deve ser otimizada para análise de conteúdo de aplicações em camada 7;
4.1.1.5. Todos os equipamentos fornecidos devem ser próprios para montagem em rack 19”, incluindo kit tipo trilho para adaptação se necessário e cabos de alimentação;
4.1.1.6. A gestão do equipamento deve ser compatível através da interface de gestão Web no mesmo dispositivo de protecção da rede;
4.1.1.7. Suportar Throughput de, no mínimo, 35 Gbps com a funcionalidade de firewall habilitada para tráfego IPv4 e IPv6, independente do tamanho do pacote
4.1.1.8. Suporte a, no mínimo, 7 (milhões) conexões simultâneas
4.1.1.9. Suporte a, no mínimo, 400.000 (mil) novas conexões por segundo
4.1.1.10. Suportar Throughput de, no mínimo, 20 Gbps de VPN IPSec
4.1.1.11. Suportar no mínimo 9.5 Gbps de throughput de IPS
4.1.1.12. Suportar Throughput de, no mínimo, 6 Gbps com as seguintes funcionalidades habilitadas simultaneamente para todas as assinaturas que a plataforma de segurança possuir devidamente ativadas e atuantes: controle de aplicação, IPS, Antivírus e Antispyware. Caso o fabricante divulgue múltiplos números de desempenho para qualquer uma destas funcionalidades, somente o de menor valor será aceito;
4.1.1.13. Possuir ao menos 02 interfaces 10Gbps SFP/SFP+.
4.1.1.14. Deve ser entregue ao menos 04 Trasceivers SFP/SFP+ de 10Gbps.
4.1.1.15. Possuir ao menos 8 interfaces 1Gbps RJ45.
4.1.1.16. Possuir ao menos 08 interfaces 1Gbps SFP/SFP+.
4.1.1.17. Se a solução permitir sistema virtualizados o proponente deverá garantir licenciamento e suporte para cada appliance operar com no mínimo, 10 sistemas virtuais lógicos (Contextos) por appliance
4.1.1.18. Os dispositivos de proteção de rede devem possuir suporte a 4094 VLAN Tags 802.1q;
4.1.1.19. Os dispositivos de proteção de rede devem possuir suporte a agregação de links 802.3ad e LACP;
4.1.1.20. Os dispositivos de proteção de rede devem possuir suporte a Policy based routing ou policy based forwarding;
4.1.1.21. Os dispositivos de proteção de rede devem possuir suporte a roteamento multicast (PIM- SM e PIM-DM);
4.1.1.22. Os dispositivos de proteção de rede devem possuir suporte a DHCP Relay;
4.1.1.23. Os dispositivos de proteção de rede devem possuir suporte a DHCP Server;
4.1.1.24. Os dispositivos de proteção de rede devem possuir suporte a Jumbo Frames;
4.1.1.25. Os dispositivos de proteção de rede devem suportar sub-interfaces ethernet logicas;
4.1.1.26. Deve suportar NAT dinâmico (Many-to-1);
4.1.1.27. Deve suportar NAT dinâmico (Many-to-Many);
4.1.1.28. Deve suportar NAT estático (1-to-1);
4.1.1.29. Deve suportar NAT estático (Many-to-Many);
4.1.1.30. Deve suportar NAT estático bidirecional 1-to-1;
4.1.1.31. Deve suportar Tradução de porta (PAT);
4.1.1.32. Deve suportar NAT de Origem;
4.1.1.33. Deve suportar NAT de Destino;
4.1.1.34. Deve suportar NAT de Origem e NAT de Destino simultaneamente;
4.1.1.35. Deve poder combinar NAT de origem e NAT de destino na mesma politica
4.1.1.36. Deve implementar Network Prefix Translation (NPTv6) ou NAT66, prevenindo problemas de roteamento assimétrico;
4.1.1.37. Deve suportar NAT64 e NAT46;
4.1.1.38. Deve implementar o protocolo ECMP;
4.1.1.39. Deve implementar balanceamento de link por hash do IP de origem;
4.1.1.40. Deve implementar balanceamento de link por hash do IP de origem e destino;
4.1.1.41. Deve implementar balanceamento de link por peso. Nesta opção deve ser possível definir o percentual de tráfego que será escoado por cada um dos links. Deve suportar o balanceamento de, no mínimo, três links;
4.1.1.42. Deve implementar balanceamento de links sem a necessidade de criação de zonas ou uso de instâncias virtuais;
4.1.1.43. Deve permitir monitorar via SNMP falhas de hardware, uso de recursos por número elevado de sessões, conexões por segundo, número de túneis estabelecidos na VPN, CPU, memória, status do cluster, ataques e estatísticas de uso das interfaces de rede;
4.1.1.44. Enviar log para sistemas de monitoração externos, simultaneamente;
4.1.1.45. Deve haver a opção de enviar logs para os sistemas de monitoração externos via protocolo TCP e SSL;
4.1.1.46. Implementar Proteção anti-spoofing;
4.1.1.47. Implementar otimização do tráfego entre dois equipamentos;
4.1.1.48. Para IPv4, deve suportar roteamento estático e dinâmico (RIPv2, BGP e OSPFv2);
4.1.1.49. Para IPv6, deve suportar roteamento estático e dinâmico (OSPFv3);
4.1.1.50. Suportar OSPF graceful restart;
4.1.1.51. Os dispositivos de proteção devem ter a capacidade de operar de forma simultânea em uma única instância de firewall, mediante o uso de suas interfaces físicas nos seguintes modos: Modo sniffer (monitoramento e análise do tráfego de rede), camada 2 (L2) e camada 3 (L3);
4.1.1.52. Deve suportar Modo Sniffer, para inspeção via porta espelhada do tráfego de dados da rede;
4.1.1.53. Deve suportar Modo Camada – 2 (L2), para inspeção de dados em linha e visibilidade do tráfego;
4.1.1.54. Deve suportar Modo Camada – 3 (L3), para inspeção de dados em linha e visibilidade do tráfego;
4.1.1.55. Deve suportar Modo misto de trabalho Sniffer, L2 e L3 em diferentes interfaces físicas;
4.1.1.56. Suporte a configuração de alta disponibilidade Ativo/Passivo e Ativo/Ativo: Em modo transparente;
4.1.1.57. Suporte a configuração de alta disponibilidade Ativo/Passivo e Ativo/Ativo: Em layer 3;
4.1.1.58. Suporte a configuração de alta disponibilidade Ativo/Passivo e Ativo/Ativo: Em layer 3 e com no mínimo 3 equipamentos no cluster;
4.1.1.59. A configuração em alta disponibilidade deve sincronizar: Sessões;
4.1.1.60. A configuração em alta disponibilidade deve sincronizar: Configurações, incluindo, mas não limitado as políticas de Firewall, NAT, QOS e objetos de rede;
4.1.1.61. A configuração em alta disponibilidade deve sincronizar: Associações de Segurança das VPNs;
4.1.1.62. A configuração em alta disponibilidade deve sincronizar: Tabelas FIB;
4.1.1.63. O HA (modo de Alta-Disponibilidade) deve possibilitar monitoração de falha de link;
4.1.1.64. Será fator diferencial possuir suporte a criação de sistemas virtuais no mesmo appliance;
4.1.1.65. Em alta disponibilidade, deve ser possível o uso de clusters virtuais, seja ativo-ativo ou ativo-passivo, permitindo a distribuição de carga entre diferentes contextos;
4.1.1.66. Deve permitir a criação de administradores independentes, para cada um dos sistemas virtuais existentes, de maneira a possibilitar a criação de contextos virtuais que podem ser administrados por equipes distintas;
4.1.1.67. Controle, inspeção e descriptografia de SSL para tráfego de entrada (Inbound) e Saída (Outbound), sendo que deve suportar o controle dos certificados individualmente dentro de cada sistema
virtual, ou seja, isolamento das operações de adição, remoção e utilização dos certificados diretamente nos sistemas virtuais (contextos);
4.1.1.68. Deverá suportar controles por zona de segurança;
4.1.1.69. Controles de políticas por porta e protocolo;
4.1.1.70. Controle de políticas por aplicações, grupos estáticos de aplicações, grupos dinâmicos de aplicações (baseados em características e comportamento das aplicações) e categorias de aplicações;
4.1.1.71. Controle de políticas por usuários, grupos de usuários, IPs, redes e zonas de segurança;
4.1.1.72. Firewall deve ser capaz de aplicar a inspeção UTM (Application Control e Webfiltering no mínimo) diretamente às políticas de segurança versus via perfis;
4.1.1.73. Além dos endereços e serviços de destino, objetos de serviços de Internet devem poder ser adicionados directamente às políticas de firewall;
4.1.1.74. Deve suportar o armazenamento de logs em tempo real tanto para o ambiente de nuvem quanto o ambiente local (on-premise);
4.1.1.75. Deve suportar o padrão de indústria 'syslog' protocol para armanazemento usando o formato Common Event Format (CEF);
4.1.1.76. Deve suportar o protocolo padrão da indústria VXLAN;
4.1.1.77. Permitir identificar e opcionalmente prevenir a transferência de vários tipos de arquivos (MS Office, PDF, etc) identificados sobre aplicações (HTTP, FTP, SMTP, etc);
4.1.1.78. Suportar identificação de arquivos compactados ou a aplicação de políticas sobre o conteúdo desses tipos de arquivos;
4.1.1.79. Suportar a identificação de arquivos criptografados e a aplicação de políticas sobre o conteúdo desses tipos de arquivos;
4.1.1.80. Suportar a criação de políticas por geo-localização, permitindo o trafego de determinado Pais/Países sejam bloqueados;
4.1.1.81. Deve possibilitar a visualização dos países de origem e destino nos logs dos acessos;
4.1.1.82. Deve possibilitar a criação de regiões geográficas pela interface gráfica e criar políticas utilizando as mesmas;
4.1.1.83. A Solução virtual deve ser compatível com Microsoft Hyper-V;
4.1.1.84. A Solução deve estar entre os lideres do quadrante magico Gatner 2019 para UTM;
4.1.1.85. A solução poderá ser virtualizada dentro do appliance não sendo aplicave o item 4.1.1.85
Controle de Aplicações
4.1.1.86. Os dispositivos de proteção de rede deverão possuir a capacidade de reconhecer aplicações, independente de porta e protocolo;
4.1.1.87. Deve ser possível a liberação e bloqueio somente de aplicações sem a necessidade de liberação de portas e protocolos;
4.1.1.88. Reconhecer pelo menos 1700 aplicações diferentes, incluindo, mas não limitado a: tráfego relacionado a peer-to-peer, redes sociais, acesso remoto, update de software, protocolos de rede, voip, áudio, vídeo, proxy, mensageiros instantâneos, compartilhamento de arquivos, e-mail;
4.1.1.89. Reconhecer pelo menos as seguintes aplicações: bittorrent, gnutella, skype, facebook, linked-in, twitter, citrix, logmein, teamviewer, ms-rdp, vnc, gmail, youtube, http-proxy, http-tunnel, facebook chat, gmail chat, whatsapp, 4shared, dropbox, google drive, skydrive, db2, mysql, oracle, active directory, kerberos, ldap, radius, itunes, dhcp, ftp, dns, wins, msrpc, ntp, snmp, rpc over http, gotomeeting, webex, evernote, google-docs;
4.1.1.90. Deve inspecionar o payload de pacote de dados com o objetivo de detectar assinaturas de aplicações conhecidas pelo fabricante independente de porta e protocolo;
4.1.1.91. Deve detectar aplicações através de análise comportamental do tráfego observado, incluindo, mas não limitado a Bittorrent e aplicações VOIP que utilizam criptografia proprietária;
4.1.1.92. Identificar o uso de táticas evasivas, ou seja, deve ter a capacidade de visualizar e controlar as aplicações e os ataques que utilizam táticas evasivas via comunicações criptografadas, tais como Skype e utilização da rede Tor;
4.1.1.93. Para tráfego criptografado SSL, deve de-criptografar pacotes a fim de possibilitar a leitura de payload para checagem de assinaturas de aplicações conhecidas pelo fabricante;
4.1.1.94. Deve realizar decodificação de protocolos com o objetivo de detectar aplicações encapsuladas dentro do protocolo e validar se o tráfego corresponde com a especificação do protocolo,
incluindo, mas não limitado a Yahoo Instant Messenger usando HTTP. A decodificação de protocolo também deve identificar funcionalidades especificas dentro de uma aplicação, incluindo, mas não limitado a compartilhamento de arquivo dentro do Webex;
4.1.1.95. Identificar o uso de táticas evasivas via comunicações criptografadas;
4.1.1.96. Atualizar a base de assinaturas de aplicações automaticamente;
4.1.1.97. Limitar a banda (download/upload) usada por aplicações (traffic shaping), baseado no IP de origem, usuários e grupos;
4.1.1.98. Os dispositivos de proteção de rede devem possuir a capacidade de identificar o usuário de rede com integração ao Microsoft Active Directory, sem a necessidade de instalação de agente no Domain Controller, nem nas estações dos usuários;
4.1.1.99. Deve ser possível adicionar controle de aplicações em múltiplas regras de segurança do dispositivo, ou seja, não se limitando somente a possibilidade de habilitar controle de aplicações em algumas regras;
4.1.1.100. Deve suportar múltiplos métodos de identificação e classificação das aplicações, por pelo menos checagem de assinaturas e decodificação de protocolos;
4.1.1.101. Para manter a segurança da rede eficiente, deve suportar o controle sobre aplicações desconhecidas e não somente sobre aplicações conhecidas;
4.1.1.102. Permitir nativamente a criação de assinaturas personalizadas para reconhecimento de aplicações proprietárias na própria interface gráfica da solução, sem a necessidade de ação do fabricante;
4.1.1.103. A criação de assinaturas personalizadas deve permitir o uso de expressões regulares, contexto (sessões ou transações), usando posição no payload dos pacotes TCP e UDP e usando decoders de pelo menos os seguintes protocolos: HTTP, FTP, NBSS, DCE RPC, SMTP, Telnet, SSH, MS-SQL, IMAP, DNS, LDAP, RTSP e SSL;
4.1.1.104. O fabricante deve permitir a solicitação de inclusão de aplicações na base de assinaturas de aplicações;
4.1.1.105. Deve alertar o usuário quando uma aplicação for bloqueada;
4.1.1.106. Deve possibilitar a diferenciação de tráfegos Peer2Peer (Bittorrent, emule, etc) possuindo granularidade de controle/políticas para os mesmos;
4.1.1.107. Deve possibilitar a diferenciação de tráfegos de Instant Messaging (AIM, Hangouts, Facebook Chat, etc) possuindo granularidade de controle/políticas para os mesmos;
4.1.1.108. Deve possibilitar a diferenciação e controle de partes das aplicações como por exemplo permitir o Hangouts chat e bloquear a chamada de vídeo;
4.1.1.109. Deve possibilitar a diferenciação de aplicações Proxies (psiphon, freegate, etc) possuindo granularidade de controle/políticas para os mesmos;
4.1.1.110. Deve ser possível a criação de grupos dinâmicos de aplicações baseados em características das aplicações como: Tecnologia utilizada nas aplicações (Client-Server, Browse Based, Network Protocol, etc);
4.1.1.111. Deve ser possível a criação de grupos dinâmicos de aplicações baseados em características das aplicações como: Nível de risco da aplicação;
4.1.1.112. Deve ser possível a criação de grupos estáticos de aplicações baseados em características das aplicações como: Categoria da aplicação;
Prevenção de Ameaças
4.1.1.113. Para proteção do ambiente contra-ataques, os dispositivos de proteção devem possuir módulo de IPS, Antivírus e Anti-Spyware integrados no próprio appliance de firewall;
4.1.1.114. Deve incluir assinaturas de prevenção de intrusão (IPS) e bloqueio de arquivos maliciosos (Antivírus e Anti-Spyware);
4.1.1.115. As funcionalidades de IPS, Antivírus e Anti-Spyware devem operar em caráter permanente, podendo ser utilizadas por tempo indeterminado, mesmo que não subsista o direito de receber atualizações ou que não haja contrato de garantia de software com o fabricante;
4.1.1.116. Deve sincronizar as assinaturas de IPS, Antivírus, Anti-Spyware quando implementado em alta disponibilidade;
4.1.1.117. Deve implementar os seguintes tipos de ações para ameaças detectadas pelo IPS: permitir, permitir e gerar log, bloquear, bloquear IP do atacante por um intervalo de tempo e enviar tcp- reset;
4.1.1.118. As assinaturas devem poder ser ativadas ou desativadas, ou ainda habilitadas apenas em modo de monitoração;
4.1.1.119. Deve ser possível a criação de políticas por usuários, grupos de usuários, IPs, redes ou zonas de segurança;
4.1.1.120. Exceções por IP de origem ou de destino devem ser possíveis nas regras ou assinatura a assinatura;
4.1.1.121. Deve suportar granularidade nas políticas de IPS, Antivírus e Anti-Spyware, possibilitando a criação de diferentes politicas por zona de segurança, endereço de origem, endereço de destino, serviço e a combinação de todos esses itens;
4.1.1.122. Deve permitir o bloqueio de vulnerabilidades;
4.1.1.123. Deve permitir o bloqueio de exploits conhecidos;
4.1.1.124. Deve incluir proteção contra-ataques de negação de serviços;
4.1.1.125. Deverá possuir os seguintes mecanismos de inspeção de IPS: 4.1.1.125.1. Análise de padrões de estado de conexões;
4.1.1.125.2. Análise de decodificação de protocolo; 4.1.1.125.3. Análise para detecção de anomalias de protocolo; 4.1.1.125.4. Análise heurística;
4.1.1.125.5. IP Defragmentation;
4.1.1.125.6. Remontagem de pacotes de TCP; 4.1.1.125.7. Bloqueio de pacotes malformados;
4.1.1.126. Ser imune e capaz de impedir ataques básicos como: Syn flood, ICMP flood, UDP flood;
4.1.1.127. Detectar e bloquear a origem de portscans;
4.1.1.128. Bloquear ataques efetuados por worms conhecidos;
4.1.1.129. Possuir assinaturas específicas para a mitigação de ataques DoS e DDoS;
4.1.1.130. Possuir assinaturas para bloqueio de ataques de buffer overflow;
4.1.1.131. Deverá possibilitar a criação de assinaturas customizadas pela interface gráfica;
4.1.1.132. Deve permitir usar operadores de negação na criação de assinaturas customizadas de IPS ou anti-spyware, permitindo a criação de exceções com granularidade nas configurações;
4.1.1.133. Permitir o bloqueio de vírus e spywares em, pelo menos, os seguintes protocolos: HTTP, FTP, SMB, SMTP e POP3;
4.1.1.134. Identificar e bloquear comunicação com botnets;
4.1.1.135. Registrar na console de monitoração as seguintes informações sobre ameaças identificadas: O nome da assinatura ou do ataque, aplicação, usuário, origem e o destino da comunicação, além da ação tomada pelo dispositivo;
4.1.1.136. Deve suportar a captura de pacotes (PCAP), por assinatura de IPS ou controle de aplicação;
4.1.1.137. Deve permitir que na captura de pacotes por assinaturas de IPS seja definido o número de pacotes a serem capturados ou permitir capturar o pacote que deu origem ao alerta assim como seu contexto, facilitando a análise forense e identificação de falsos positivos;
4.1.1.138. Deve possuir a função de proteção a resolução de endereços via DNS, identificando requisições de resolução de nome para domínios maliciosos de botnets conhecidas;
4.1.1.139. Os eventos devem identificar o país de onde partiu a ameaça;
4.1.1.140. Deve incluir proteção contra vírus em conteúdo HTML e javascript, software espião (spyware) e worms;
4.1.1.141. Possuir proteção contra downloads involuntários usando HTTP de arquivos executáveis e maliciosos;
4.1.1.142. Deve ser possível a configuração de diferentes políticas de controle de ameaças e ataques baseada em políticas do firewall considerando Usuários, Grupos de usuários, origem, destino, zonas de segurança, etc, ou seja, cada política de firewall poderá ter uma configuração diferentes de IPS, sendo essas políticas por Usuários, Grupos de usuário, origem, destino, zonas de segurança;
4.1.1.143. Fornecer proteção contra-ataques de dia zero por meio de estreita integração com os componentes Sandbox (on-premise e nuvem);
Filtro de URL
4.1.1.144. Permite especificar política por tempo, ou seja, a definição de regras para um determinado horário ou período (dia, mês, ano, dia da semana e hora);
4.1.1.145. Deve ser possível a criação de políticas por usuários, grupos de usuários, IPs, redes ou zonas de segurança;
4.1.1.146. Deve possuir a capacidade de criação de políticas baseadas na visibilidade e controle de quem está utilizando quais URLs através da integração com serviços de diretório, Active Directory e base de dados local em modo de proxy transparente e explícito;
4.1.1.147. Suportar a capacidade de criação de políticas baseadas no controle por URL e categoria de URL;
4.1.1.148. Deve possuir base ou cache de URLs local no appliance ou em nuvem do próprio fabricante, evitando delay de comunicação/validação das URLs;
4.1.1.149. Possuir pelo menos 60 categorias de URLs;
4.1.1.150. Deve possuir a função de exclusão de URLs do bloqueio, por categoria;
4.1.1.151. Permitir a customização de página de bloqueio;
4.1.1.152. Permitir o bloqueio e continuação (possibilitando que o usuário acesse um site potencialmente bloqueado informando o mesmo na tela de bloqueio e possibilitando a utilização de um botão Continuar para permitir o usuário continuar acessando o site);
4.1.1.153. Além do Explicit Web Proxy, suportar proxy Web transparente;
Identificação de Usuários
4.1.1.154. Deve incluir a capacidade de criação de políticas baseadas na visibilidade e controle de quem está utilizando quais aplicações através da integração com serviços de diretório, autenticação via LDAP, Active Directory, E-directory e base de dados local;
4.1.1.155. Deve possuir integração com Microsoft Active Directory para identificação de usuários e grupos permitindo granularidade de controle/politicas baseadas em usuários e grupos de usuários;
4.1.1.156. Deve possuir integração e suporte a Microsoft Active Directory para os seguintes sistemas operacionais: Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 e Windows Server 2012 R2;
4.1.1.157. Deve possuir integração com Microsoft Active Directory para identificação de usuários e grupos permitindo granularidade de controle/politicas baseadas em usuários e grupos de usuários, suportando single sign-on. Essa funcionalidade não deve possuir limites licenciados de usuários ou qualquer tipo de restrição de uso como, mas não limitado à, utilização de sistemas virtuais, segmentos de rede, etc;
4.1.1.158. Deve possuir integração com Radius para identificação de usuários e grupos permitindo granularidade de controle/politicas baseadas em usuários e grupos de usuários;
4.1.1.159. Deve possuir integração com LDAP para identificação de usuários e grupos permitindo granularidade de controle/politicas baseadas em Usuários e Grupos de usuários;
4.1.1.160. Deve permitir o controle, sem instalação de cliente de software, em equipamentos que solicitem saída a internet para que antes de iniciar a navegação, expanda-se um portal de autenticação residente no firewall (Captive Portal);
4.1.1.161. Deve possuir suporte a identificação de múltiplos usuários conectados em um mesmo endereço IP em ambientes Citrix e Microsoft Terminal Server, permitindo visibilidade e controle granular por usuário sobre o uso das aplicações que estão nestes serviços;
4.1.1.162. Deve implementar a criação de grupos customizados de usuários no firewall, baseado em atributos do LDAP/AD;
QoS e Traffic Shaping
4.1.1.163. Com a finalidade de controlar aplicações e tráfego cujo consumo possa ser excessivo, (como Youtube, Ustream, etc) e ter um alto consumo de largura de banda, se requer que a solução, além de poder permitir ou negar esse tipo de aplicações, deve ter a capacidade de controlá-las por políticas de máxima largura de banda quando forem solicitadas por diferentes usuários ou aplicações, tanto de áudio como de vídeo streaming;
4.1.1.164. Suportar a criação de políticas de QoS e Traffic Shaping por endereço de origem;
4.1.1.165. Suportar a criação de políticas de QoS e Traffic Shaping por endereço de destino;
4.1.1.166. Suportar a criação de políticas de QoS e Traffic Shaping por usuário e grupo;
4.1.1.167. Suportar a criação de políticas de QoS e Traffic Shaping por aplicações, incluindo, mas não limitado a Skype, Bittorrent, YouTube;
4.1.1.168. Suportar a criação de políticas de QoS e Traffic Shaping por porta;
4.1.1.169. Possibilitar a definição de tráfego com banda garantida;
4.1.1.170. Possibilitar a definição de tráfego com banda máxima;
4.1.1.171. Possibilitar a definição de fila de prioridade;
4.1.1.172. Suportar priorização em tempo real de protocolos de voz (VOIP) como H.323, SIP, SCCP, MGCP e aplicações como Skype;
4.1.1.173. Suportar marcação de pacotes Diffserv, inclusive por aplicação;
4.1.1.174. Disponibilizar estatísticas em tempo real para classes de QoS ou Traffic Shaping;
4.1.1.175. Deve suportar QOS (traffic-shapping), em interface agregadas ou redundantes; 4.1.1.176.
VPN
4.1.1.177. Suportar VPN Site-to-Site e Cliente-To-Site;
4.1.1.178. Suportar IPSec VPN e VPN SSL de forma simultãnea;
4.1.1.179. A VPN IPSEc deve suportar 3DES;
4.1.1.180. A VPN IPSEc deve suportar Autenticação MD5 e SHA-1;
4.1.1.181. A VPN IPSEc deve suportar Diffie-Hellman Group 1, Group 2, Group 5 e Group 14;
4.1.1.182. A VPN IPSEc deve suportar Algoritmo Internet Key Exchange (IKEv1 e v2);
4.1.1.183. A VPN IPSEc deve suportar AES 128, 192 e 256 (Advanced Encryption Standard);
4.1.1.184. A VPN IPSEc deve suportar Autenticação via certificado IKE PKI;
4.1.1.185. Deve permitir habilitar e desabilitar túneis de VPN IPSEC a partir da interface gráfica da solução, facilitando o processo de throubleshooting;
4.1.1.186. A VPN SSL deve suportar o usuário realizar a conexão por meio de cliente instalado no sistema operacional do equipamento ou por meio de interface WEB;
4.1.1.187. A funcionalidades de VPN SSL devem ser atendidas com ou sem o uso de agente;
4.1.1.188. Deve permitir que todo o tráfego dos usuários remotos de VPN seja escoado para dentro do túnel de VPN, impedindo comunicação direta com dispositivos locais como proxies;
4.1.1.189. Atribuição de DNS nos clientes remotos de VPN;
4.1.1.190. Dever permitir criar políticas de controle de aplicações, IPS, Antivírus, Antipyware e filtro de URL para tráfego dos clientes remotos conectados na VPN SSL;
4.1.1.191. Suportar autenticação via AD/LDAP, Secure id, certificado e base de usuários local;
4.1.1.192. Suportar leitura e verificação de CRL (certificate revocation list);
4.1.1.193. Permitir a aplicação de políticas de segurança e visibilidade para as aplicações que circulam dentro dos túneis SSL;
4.1.1.194. Deve permitir que a conexão com a VPN seja estabelecida das seguintes formas: 4.1.1.194.1. Antes do usuário autenticar na estação;
4.1.1.194.2. Após autenticação do usuário na estação; 4.1.1.194.3. Sob demanda do usuário;
4.1.1.195. Deverá manter uma conexão segura com o portal durante a sessão;
4.1.1.196. O agente de VPN SSL ou IPSEC client-to-site deve ser compatível com pelo menos: Windows 7 (32 e 64 bit), Windows 8 (32 e 64 bit), Windows 10 (32 e 64 bit) e Mac OS X (v10.10 ou superior);
CARACTERÍSTICAS SD-WAN
4.1.1.197. Suportar para vários tipos de Links de transporte (IP Internet, ADSL, MPLS)
4.1.1.198. Suportar para os algoritmos de criptografia seguros
4.1.1.199. Suportar alta taxa de transferência para trefego IPSec
4.1.1.200. Suportar vários algoritmos do controlador de caminho WAN para utilização eficaz da WAN
4.1.1.201. Suportar Roteamento dinâmico baseado em medições de qualidade de link
4.1.1.202. Suportar manter alta disponibilidade de aplicativos essenciais aos negócios
4.1.1.203. Suportar Melhor esforço para aplicações de baixa prioridade através de links de baixo custo
4.1.1.204. Suporar a vários servidores para verificações de integridade
4.1.1.205. Suportar Grupos de serviços da Internet para opçoes de balanceamento de links
4.1.1.206. Suportar Opções de largura de banda nas regras de acesso
4.1.1.207. Suportar modificação de valores DSCP para o Diffserv;
4.1.1.208. Suportar Marcação DSCP de pacotes encaminhados nas regras de acesso
Solução de gerenciamento de logs e relatórios
4.1.2. Na data da proposta, nenhum dos modelos ofertados poderão estar listados no site do fabricante em listas de end-of-life e end-of-sale;
4.1.3. Os logs deverão ser mantidos por no mínimo 60 dias;
4.1.4. O gerenciamento da solução deve suportar acesso via SSH, cliente ou WEB (HTTPS) e API aberta;
4.1.5. Permitir acesso concorrente de administradores;
4.1.6. Permitir a configuração de alertas e relatorios para envio automático via Email;
4.1.7. Deve suportar backup/restore de todas as configurações da solução de gerência, permitindo ao administrador agendar backups da configuração em um determinado dia e hora.
4.1.8. Deve registrar as ações efetuadas por quaisquer usuários
4.1.9. Devem ser fornecidos manuais de instalação, configuração e operação de toda a solução, na língua portuguesa ou inglesa, com apresentação de boa qualidade.
4.1.10. Geração de relatórios em tempo real, para a visualização de tráfego observado, nos formatos: mapas geográficos e tabela;
4.1.11. Possuir mecanismo para que logs antigos sejam removidos automaticamente
4.1.12. Permitir a importação e exportação de relatórios
4.1.13. Deve possuir a capacidade de criar relatórios nos formatos PDF
4.1.14. Deve ser possível exportar os logs em CSV
4.1.15. Geração de logs de auditoria detalhados, informando a configuração realizada, o administrador que a realizou e o horário da alteração
4.1.16. Os logs gerados pelos appliances devem ser centralizados nos servidores de gerência, mas a solução deve oferecer também a possibilidade de utilização de um syslog externo ou similar.
4.1.17. A solução deve possuir relatórios pré-definidos
4.1.18. Possuir envio automático de logs para um servidor FTP externo a solução
4.1.19. Possibilitar a duplicação de relatórios existentes e edita-los logo após
4.1.20. Possuir a capacidade de personalização de capas para os relatórios
4.1.21. Permitir de forma centralizada visualizar os logs recebidos por um ou vários dispositivos externos incluindo a capacidade de uso de filtros nas pesquisas deste log
4.1.22. Logs de auditoria para configurações de regras e objetos devem ser visualizados em uma lista diferente da que exibe os logs relacionados a tráfego de dados.
4.1.23. Possuir a capacidade de personalização de gráficos como barra, linha e tabela para inserção aos relatórios
4.1.24. Deve possuir mecanismo "Drill-Down" para navegação nos relatórios em realtime;
4.1.25. Dever ser possível fazer download dos arquivos de logs recebidos
4.1.26. Deve possuir agendamento para gerar e enviar automaticamente relatórios
4.1.27. Permitir customização de quaisquer relatórios fornecidos pela solução, exclusivamente pelo administrador, adaptando-o às suas necessidades.
4.1.28. Permitir o envio de maneira automática de relatórios por email
4.1.29. Deve permitir a escolha do email a ser enviado para cada relatório escolhido
4.1.30. Permitir programar a geração de relatórios, conforme calendário definido pelo administrador
4.1.31. Deve ser possível definir filtros nos relatórios
4.1.32. Deve ser capaz de definir o layout do relatório, incluir gráficos, inserir textos e imagens, alinhamento, quebras de páginas, definir fontes, cores, entre outros
4.1.33. Gerar alertas automáticos via Email, SNMP e Syslog baseados em eventos como ocorrência como log, severidade de log, entre outros
4.1.34. Deve ser capaz de criar consultas SQL ou semelhante para uso nos gráficos e tabelas de relatórios
4.1.35. Ter a capacidade de visualizar na GUI da solução de relatórios informações do sistema como licenças, memória, disco, uso de CPU, taxa de logs por segundo recebidos, total de logs diários recebidos, alertas gerados entre outros
4.1.36. Deve permitir ver em tempo real os log recebidos
4.1.37. Deve permitir a criação de Dashboards customizados para visibilidades do tráfego de aplicativos, categorias de URL, ameaças, serviços, países, origem e destino;
4.1.38. Deve possuir relatório de VPN
4.1.39. Deve possuir relatório de Sistemas de prevenção de intrusão (IPS)
4.1.40. Deve possuir relatório de reputação do cliente
4.1.41. Deve possuir relatório de análise de segurança do usuário
4.1.42. Deve pussuir relatório de avaliação da ameaça cibernética
Solução de Balanceamento de Aplicacões
4.2.1. Deve oferecer suporte à criação de contas de administrador com diferentes perfis e direitos de acesso baseado em função (RBAC);
4.2.2. O perfil dos administradores deve ser definido com base nos direitos das diferentes funções do sistema;
4.2.3. Os direitos de acesso devem ser: leitura, gravação (e leitura) e sem acesso;
4.2.4. O sistema deve ter pelo menos as seguintes unidades funcionais para fins de acesso de administrador: sistema (configuração geral do computador), roteamento, firewall, balanceamento de carga do servidor (SLB), carga de link Balnaceo (LLB), segurança (Web Application Firewall), relatórios e logs.
4.2.5. A solução deve conter um ambiente de gestão nas línguas inglesa, espanhola e portuguesa;
4.2.6. Deve suportar balanceamento de camada 7 para os seguintes HTTP, HTTPs, TurboHTTPS, RADIUS, RDP, SIP, TCPs, DNS, SMTP, RTMP, RTSP, protocolos MySQL;
4.2.7. Deve equilibrar o tráfego entre servidores reais usando nossos próprios algoritmos e informações de saúde usadas dos servidores;
4.2.8. Deve permitir a configuração de perfis que determinam a criptografia de tráfego entre o computador (ADC) e os servidores reais;
4.2.9. Quando a comunicação criptografada existe, ela deve ser controlada por protocolos SSL/TLS e os protocolos de criptografia de lista;
4.2.10. Deve suportar protocolo SSL (V2 e v3) e TLS (v 1.0, v 1.1, v 1.2);
4.2.11. Deve suportar pelo menos os seguintes conjuntos de codificação: ECDHE-RSA-AES256-GCM- SHA384, ECDHE-RSA-AES256-SHA384, AES256-GCM-SHA384, AES256-SHA, ECDHE-RSA- AES128-GCM-SHA256, AES128-SHA, RC4-SHA;
4.2.12. Deve ser capaz de reutilizar sessões SSL;
4.2.13. Para cada um dos servidores que participam do algoritmo de balanceamento, deve ser possível configurar: peso (preferencialmente para fins de controle de envio de tráfego), o número máximo de conexões suportadas por esse servidor, o número máximo de novas conexões por segundo que este servidor suporta, diferentes métodos de verificação de saúde, o perfil de encriptação entre o sistema e o servidor (SSL/TLS e encriptação) e o estabelecimento para o atraso de envio de ligações a este servidor, caso tenha sido reinic a porcentagem máxima de novas conexões durante o intervalo após a reinicialização, o cookie do servidor (para fins de identificação de conexão) e ser capaz de indicar se este servidor é de outro backup (s);
4.2.14. Deve ser capaz de equilibrar novas sessões, mas preservando as sessões existentes no mesmo servidor, usando a persistência de sessão dos seguintes tipos: endereço de origem, endereço de origem, hash, hashing baseado em endereço e Porta TCP/UDP, hash baseado em cookie fornecido pelo servidor real, ID de sessão SSL, o hash de uma palavra específica encontrada no cabeçalho
HTTP da solicitação do cliente, hash de parâmetro de URL encontrado na solicitação HTTP que vem do cliente , Atributo RADIUS;
4.2.15. Deve suportar pelo menos as seguintes regras de persistência com base em: endereço de origem, endereço de origem, hash, hash baseado em endereço e porta TCP/UDP, hash baseado em cookie fornecido pelo servidor real, ID de sessão SSL, hash de um pa Labra específico encontrado no cabeçalho HTTP da solicitação do cliente, hash de parâmetro de URL encontrado na solicitação HTTP que vem do cliente, atributo RADIUS;
4.2.16. Deve ser capaz de reescrever o cookie do servidor real para uso em regras de persistência;
4.2.17. Deve poder configurar timeouts de conexão sobre as persistências
4.2.18. O sistema deve permitir a seleção do servidor real com base em informações de cabeçalho de pacote TCP/IP e HTTP;
4.2.19. Deve permitir a seleção do servidor real com base no valor do campo de cabeçalho HTTP que inclui pelo menos o conteúdo do host HTTP, Referer HTTP, URL de solicitação HTTP e SNI (indicador de nome do servidor);
4.2.20. Selecionar campos de cabeçalho HTTP para fins de roteamento deve ser feito por meio de expressões regulares ou correspondência completa;
4.2.21. O sistema deve permitir a re-Write de solicitação HTTP, repsonse HTTP e mensagens de cabeçalho HTTP;
4.2.22. O sistema deve pedir que você reescreva o parâmetro Location da resposta HTTP condicionada ao uso de Strings ou expressões regulares para identificar padrões nos campos: host HTTP, localização HTTP, Referer HTTP, solicitação HTTP uro endereço IP de origem;
4.2.23. O sistema deve permitir reescrita, redirecionar ou proibir solicitações HTTP. Deve permitir acolhimento parâmetros re-escrita, URL e cabeçalho HTTP Referer. Estas operações são condicionados a usar cordas ou expressões regulares para identificar padrões nos campos: HTTP do host, localização HTTP, HTTP referência, pedido HTTP URL e IP fonte endereço;
4.2.24. O sistema deve permitir a compressão de dados, incluindo: aplicações (Java Script, XML, SOAP, X-Javascript, XML) e texto (CSS, HTML, JavaScript, Plano, XML);
4.2.25. Suporte cache de conteúdo HTTP, permitindo que os objetos sejam armazenados em pedidos de memória e HTTP são respondidas diretamente pela solução que está cache: A fim de controlar os recursos, deve ser possível controlar: o tamanho máximo de objetos o tamanho máximo de cache do sistema, o número máximo de entradas de cache, as regras máximas de exceção cache;
4.2.26. O sistema deve ter pré perfis configurados para uso em um tráfego do servidor real. Pelo menos os seguintes perfis de serviços / servidores devem ser pré-configurado: FTP, TCP, UDP, HTTP / s (com TLS / SSL offload), RADIUS, TCP segura (TLS / SSL offload);
4.2.27. Além dos perfis pré-configurados, o sistema deve permitir a personalização de perfis podendo bloquear ou permitir que o endereço IP de origem, com base na localização por país (TCP, UDP, HTTP, FTP, HTTP) permite reputação da endereço de origem (TCP, UDP, HTTP, FTP, HTTP) mantido pelo fabricante da solução, compressão de dados (HTTP), cache de dados (HTTP);
4.2.28. O sistema deve permitir a personalização das páginas de erro enviados aos clientes em caso de falha nos servidores. Estas páginas podem ser editadas em HTML;
4.2.29. Deve ser possível implementar NAT, NAT64 e NAT46;
4.2.30. Ele deve implementar o esquema de autenticação básica (RFC 2617);
4.2.31. Você deve ter algoritmos pré-configurados de balanceamento de carga, incluindo, pelo menos: Round Robin , a seleção servidor com menos conexões, servidor com melhor disponibilidade, com base em hash URI (cabeçalho HTTP) com base no nome do host (pedido HTTP), a seleção baseada no hash do endereço IP de destino;
4.2.32. Balanceador deve ter mecanismos de vários links de comunicação.
4.2.33. Deve permitir equilibrar o tráfego de entrada (WAN para LAN) e de saída (LAN para WAN) usando vários links WAN e métodos diferentes;
4.2.34. O balanceaamento de tráfego deve ser selecionado através de: o endereço (ou grupo de endereços) IP de origem e destino, serviço TCP ou UDP, com base na data (hora, dia, mês, ano) e bloqueia direccionesde Fornecedores de Serviços de Internet;
4.2.35. Deve ter mecanismos de persistência de tráfego para ignorar os algoritmos de balanceamento de tráfego;
4.2.36. Deve possuir mecanismos de persistência e deve ser possível estabelecer com base nos endereços IP de destino e de origem;
4.2.37. Deve ter mecanismos de seleção de rota com base no tráfego de latência para o destino, este medido pelo ICMP ou TCP echo.
4.2.38. Para um determinado grupo de links de comunicação utilizados para equilibrar o tráfego os algoritmos de distribuição deve usar pelo menos os seguintes parâmetros: número geridos por cada link conexões, a taxa de novas conexões que foram gerados por conexão, menor link de entrada do tráfego, a menor quantidade de tráfego do link, soma do tráfego de entrada e saída do link, a utilização do link (entrada e saída) ou configuração por peso;
4.2.39. Você deve ser capaz de estabelecer túneis virtuais com equipamentos do mesmo fabricante para envio tráfego entre eles.
4.2.40. É necessário apoiar a criação de túneis usando GRE encapsulamento (Generic Routing Encapsulation);
4.2.41. Você deve equilibrar o tráfego entre esses links virtuais com base nos pesos atribuídos à função de links ou hash para o cálculo dos origem e de destino endereços IP.
4.2.42. Você deve ser capaz de monitorar o status dos links ISP e links virtuais
4.2.43. Deve ser possível estabelecer uma conexão (virtual ou real) como um link de backup (isto será utilizado somente quando o link principal não está disponível)
4.2.44. Interfaces de rede deve suportar o protocolo Ethernet com, pelo menos, as seguintes velocidades: 10 Mbps (half e full duplex), 100 Mbps (half e full duplex), 1000 Mbps (half e full duplex) e auto- negociação;
4.2.45. Deve ser compatível com PPPoE;
4.2.46. Deve suportar o protocolo IEEE 802.3ad para equilibrar o tráfego entre portos;
4.2.47. VLAN devem apoiar e ser compatíveis com o protocolo IEEE 802.1Q;
4.2.48. Deve permitir o roteamento entre VLAN diferente;
4.2.49. Deve suportar a configuração de rotas estáticas incluindo distância administrativa daí decidir por roteamento de pacotes.
4.2.50. Deve ser possível configurar políticas de roteamento baseadas em endereços IP de origem e / ou destino;
4.2.51. Deve ser compatível com OSPF v2 - RFC 2328;
4.2.52. Deve ser possível implementar NAT (Network Address Translation), dos seguintes tipos: Source NAT (alterar o endereço IP de origem), mapeando 1-1 e transferência de portas (TCP ou UDP);
4.2.53. As políticas devem alocar largura de banda, dado o endereço de origem, destino e serviço (portas TCP e UDP);
4.2.54. O equipamento oferecido deve ser capaz de abrir um número limitado de conexões TCP para o servidor real e inserir os pacotes gerados pelo cliente para essas conexões, reduzindo a necessidade de estabelecer novas conexões para os servidores e aumentar o desempenho do serviço.
4.2.55. Deve funionar em modo proxy reverso com caching, para garantir que a resposta a um fornecedor através do mesmo caminho cliente usado para o mesmo pacote;
4.2.56. É necessário suportar a sua implantação no modo tranparente, atuando como uma ponte L2.
4.2.57. Deve implementar verificação de 'Disponibilidade' em serviços remotos através de, pelo menos, os seguintes protocolos: ICMP, TCP eco, TCP, HTTP, HTTPS, DNS, RADIUS, SMTP, POP3, IMAP4, RADIUS, FTP, TCP Half, Open SSL TCP, SNMP, SSH, detecção L2, UDP, ARP e NDP (IPv6);
4.2.58. Deve fornecer um servidor DNS com base na versão BIND protegida 9;
4.2.59. Deve oferecer serviços como DNS Autoritário
4.2.60. Deve permitir o balanceamento de tráfego entre vários locais remotos baseados em DNS e tendo como parâmetros, pelo menos, a localização, a saúde do servidor, status do link e tempo de resposta de aplicações em IPv4 e IPv6;
4.2.61. Deve suportar DNSSEC com o algoritmo RSASHA1;
4.2.62. Deve apoiar DNS64 para permitir a comunicação entre clientes IPv4 com servidores IPv6 no contexto de equilibrar Carga mundial
4.2.63. Ele deve permitir o estabelecimento de sítios com base na localização geográfica de configuração (países) e, no caso das províncias e provedores de acesso à Internet na China. O banco de dados que associa endereços IP países deve ser desenvolvido e gerido pelo fabricante;
4.2.64. Deve suportar mecanismos para verificar a Disponibilidade em serviços remotos através de, pelo menos, os seguintes protocolos: ICMP, TCP eco, TCP, HTTP, HTTPS, DNS, RADIUS, SMTP, POP3, IMAP4, Contabilidade RADIUS, FTP, TCP Metade, Open SSL TCP, SNMP, SSH, detecção L2, UDP, ARP e NDP (IPv6);
4.2.65. Deve permitir que a disponibilidade de serviços por meio de analise de disponibilidade em vários protocolos com base em expressões usando AND e OR;
4.2.66. Deve suportar a criação de políticas de DNS. Isso significa que as políticas de DNS como Balancer interpreta e responde a uma solicitação DNS, tendo em conta os seguintes parâmetros: proximidade geográfica, proximidade e aplicações algoritmo de distribuição de tempo;
4.2.67. Mecanismo de implementação proximidade geográfica deve ter o endereço IP de origem (país) e endereço de destino (país). A associação entre endereços IP e os países devem ser implementados e gerenciados pelo fabricante e incluídos no sistema;
4.2.68. O mecanismo deve ser baseado na proximidade de tempo e / ou TCP ICMP;
4.2.69. Deve ser possivel atribuir peso nas respostas do DNS com base nos locais remotos;
4.2.70. Quando implementado como servidor autoritário DNS, você deve permitir-lhe definir o número máximo de respostas fornecidas por segundo;
4.2.71. Você deve ter uma funcionalidade de firewall stateful incluindo IPv4 e IPv6;
4.2.72. Permitir a ativação e definição de política de firewall (ou bloquenado permitindo o tráfego) com base em interfaces de entrada, interfaces de saída, o endereço (ou endereço de grupo) IP de origem e de destino e serviço (ou grupo de TCP e UDP serviços);
4.2.73. Deve permitir políticas de firewall implementar (bloquear ou permitir novas conexões) com base em limites de conexão que generanpor endereço (ou grupo de endereços) IP de origem e serviço de destino (ou grupo de UDP e serviço TCP) e têm conexões (limites);
4.2.74. O limite superior de conexões deve basear-se no número máximo de conexões ou o número máximo de conexões para um único host. Neste caso, deve ser possível especificar se o servidor é a origem ou o destino da conexão;
4.2.75. Deve implementar a funcionalidade de bloqueio com base na reputação, que são mantidos e atualizados pelo fabricante da solução;
4.2.76. Deve ter um mecanismo para classificar a gravidade de conexões bloqueadas pela reputação (baixa, média e alta) e gravar seus logs.
4.2.77. Deve ser capaz de bloquear o tráfego por país de origem da conexão. O banco de dados que atribui o endereço IP para país deve ser mantido e atualizado regularmente pelo fabricante da solução;
4.2.78. Deve ter um mecanismo para classificar a gravidade de conexões bloqueadas com base no país (baixa, média e alta) e gravar seus logs.
4.2.79. Deve ter um firewall de aplicativo da Web (WAF), com base na análise de pedidos e respostas HTTP com assinaturas de ataques, métodos dos ataques;
4.2.80. Deve ser possível aplicar políticas de aplicação Web deve tomar a decisão de permitir, bloquear o tráfego ou alerta (via registros) com base na análise das solicitações HTTP ou respostas;
4.2.81. Deve ser possível aplicar exceções a inspeçãode tráfego através da aplicação web política de firewall.
4.2.82. Deve ser possível aplicar políticas baseadas na identificação de assinaturas com base em HTTP, HTTP Request Body cabeçalhos ataques e Body Request HTTP;
4.2.83. As assinaturas devem ser atualizadas pelo fabricante automaticamente, sem a necessidade de intervenção do administrador da solução;
4.2.84. As empresas devem ter níveis de gravidade com base em OWASP (OWASP) Metodologia Classificação de Risco
4.2.85. As assinaturas devem ser organizadas em categorias e subcategorias;
4.2.86. Deve ser possível implementar políticas de proteção de URL para permitir a detecção de padrões ou sequências nas extensões URI ou arquivo;
4.2.87. Políticas de proteção de URL deve tomar medidas para bloquear ou de alerta (ativar e registrar) e deve permitir a classificação das severidades (alta, média e baixa);
4.2.88. Dever permitir configurar URLs e extensões para bloquear arquivos através de expressões regulares ou strings;
4.2.89. Deve permitir, através de políticas de HTTP, controle: parâmetros e métodos de solicitação HTTP e códigos de HTTP Request;
4.2.90. Deve permitir controle do administrador: comprimento máximo de URI, verificação de hostname, verificação de versão de protocolo HTTP, número máximo de cabeçalho de cookies HTTP, o número máximo de cabeçalhos em uma solicitação HTTP, HTTP cabeçalho limite de tamanho, o número máximo de caracteres em um parâmetro de URL, tamanho máximo do corpo da mensagem HTTP;
4.2.91. Devem ser configurável administrador métodos HTTP: permitir ou bloquear o método HTTP, atribuir uma gravidade (pelo menos três níveis), os seguintes métodos: Connect, Excluir, GET, HEAD, Opções, POST, PUT e Trace);
4.2.92. O administrador tem de ser capaz de controlar a gama de códigos de resposta HTTP, bloqueando ou alertando (capacidade para gerar log), e para determinar a gravidade de pelo menos três níveis para fins de manutenção de registos;
4.2.93. Deve ter políticas para identificar e bloquear ataques Cross Site Scripting (XSS) e de injeção de SQL;
4.2.94. Deve identificar ataques Cross Site Scripting através de análise de conteúdo da URL, o conteúdo do cabeçalho HTTP Refere-se o conteúdo do cabeçalho HTTP de cookies e conteúdo do corpo da mensagem de pedido HTTP;
4.2.95. Deve identificar ataques de injeção SQL através da análise do conteúdo da URL, o conteúdo do cabeçalho HTTP Refere-se, o conteúdo do cabeçalho HTTP de cookies e conteúdo do corpo da mensagem de pedido HTTP;
4.2.96. Deve identificar o tráfego com injeção SQL e XSS e administrador deve ser capaz de definir políticas para: bloquear o tráfego ou alertalo e definir o grau de severidade em pelo menos três níveis para fins de manutenção de registros;
4.2.97. Deve permitir a configuração de hosts ou padrões de URL que não estão sujeitos ao tratamento pelo firewall do tráfego HTTP. Deve apoiar a definição do anfitrião e URLs usando expressões regulares;
4.2.98. Deve possuir um mecanismo para prevenir ataques de inundação SYN;
4.2.99. Deve permitir conexão via HTTP, HTTPS, portas de Telnet e SSH para fins de acesso remoto pela equipe de administração;
4.2.100. Deve suportar a sincronização de hora via NTP;
4.2.101. Deve fornecer pelo menos dois tipos de backup: Um backup simples de configuração gerada pela linha de comando e um segundo que complementa a primeira com os arquivos de configuração do sistema (páginas de erro, scripts e arquivos de blocos de endereços IP associados com fabricante);
4.2.102. Deve permiir atualização através da linha de comando ou GUI;
4.2.103. Deve permitir atualização em partições diferentes;
4.2.104. Deve permitir a atualização do banco de dados de assinatura de firewall de aplicação web, reputação e IP endereços IP com base na localização, tudo isso separadamente e sem reiniciar o sistema;
4.2.105. Deve permitir atualização agendada do banco de dados de assinatura, nos dias da semana e horas pré configurados;
4.2.106. Deve permitir a configuração de um servidor SMTP para enviar alertas de e-mail;
4.2.107. Deve ter SNMP v1, v2c e 3 agente (RFC 3414);
4.2.108. Deve permitir que os eventos de configuração SNMP, no minimo dos itens CPU, memória e disco;
4.2.109. Deve ser compatível com o uso de certificados para a conexão do cliente incluindo estes, pelo menos: Extensão TLS Nome do Servidor Indicator (SNI), o armazenamento local de certificados (chaves privadas X.509 v3 usado por servidores), armazenamento e uso de certificados gerados a partir de um certo CA, OCSP (certificado on-line Estado Protocol), CRL (lista de certificados revogados) e a solicitação de certificado a uma CA através SCEP (certificado simples Enrollment Protocol);
4.2.110. O sistema deve ter um dashboard, por meio da interface gráfica que permite que o administrador possa exibir informações sobre o sistema, incluindo, pelo menos: o estado do sistema (versão do firmware, uso de CPU, uso de memória, uso de disco, o número de conexões atuais, a conexão média número, de entrada e largura de banda de saída usado, os últimos registos), o balanceamento de carga (servidores reais, balanceamento de carga global, entrada de largura de banda, de saída, o número de ligações);
4.2.111. Deve ter, através da interface gráfica do usuário um painel que exibe os logs de eventos, segurança e tráfego de dados, incluindo actividades e administradores de sistemas;
4.2.112. Deve ter filtros que permitem a exibição de eventos de configuração: indicar alterações na configuração do sistema, o usuário que fez a alteração, a ação (edição, adição ou eliminação), configuração que foi alterado;
4.2.113. Deve ter filtros que permitem a exibição de gerenciamento de eventos: ações tomadas pelos administradores;
4.2.114. Deve ter filtros que permitem a visualização de eventos do sistema, que indiquem informações relevantes à operação, alertas e erros gerados pelo sistema;
4.2.115. Deve ter filtros que permitem exibir eventos do usuário: indica as atividades de autenticação de usuário, incluindo informações como nome de usuário, política de grupo e de autenticação usado;
4.2.116. Deve ter filtros que permitem visualizar o estado do sistema: resultados da verificação indica o estado do certificado, nome ou identificador do servidor real, verificar o status;
4.2.117. Deve ter filtros que permitam a visualização de eventos dos servidores: indicando que ele atingiu o número máximo de conexões; identificador de servidor real, a política relacionada ao evento;
4.2.118. Deve ter filtros que permitem a visualização de eventos de balancemaneto de links: indincando que atingiu o limite de largura de banda; política relacionada ao evento;
4.2.119. Deve ter filtros que permitem a visualização de eventos balanceamento de carga global: indicando o servidor real, a política relacionada ao evento;
4.2.120. Deve ter filtros que permitem a visualização de eventos Firewalls e a política relacionada ao evento.
4.2.121. Deve ter filtros que permitem a visualização do evento segurança - Reputação IP: indica o protocolo utilizado, endereços IP e portas de origem e destino, países de origem e de trânsito de destino, o nome da política e acção tomada pela política de segurança;
4.2.122. Deve ter filtros que permitem a visualização de eventos de segurança - DoS (Denial of Service), indicando o protocolo utilizado, endereços IP e portas de origem e destino, países de origem e de trânsito de destino, o nome do governar e as medidas tomadas pela política;
4.2.123. Deve ter filtros que permitem a visualização de eventos de segurança - firewall de aplicativo da Web: inidicando o protocolo utilizado, endereços IP e portas de origem e destino, países de origem e de trânsito de destino, o nome da regra e ação Poresta levado módulo de firewall e aplicativos da web relacionadas com a segurança (assinatura, acesso à URL não permitidos, cross site scripting / SQL Injection), o URL eo conteúdo do cabeçalho da mensagem HTTP;
4.2.124. Deve ter filtros que permitem a visualização de eventos de segurança - Geolocaliação: mostra o protocolo utilizado, endereços IP e portas de origem e destino, países de origem e de trânsito de destino, o nome da regra e as medidas tomadas pela política de segurança;
4.2.125. Deve ter filtros que permitem a visualização de eventos de balanceamento de carga de tráfego na camada 4 de protocolo, bytes de entrada/saida, endereços IP e portas de origem e destino, países de origem e de trânsito de destino,
4.2.126. Deve ter filtros que permitem a visualização do evento tráfego de balanceamento de carga Layer 7: Entrada Protocolo Bytes, bytes de saída, endereços IP e portas de origem e destino, países de origem e de destino tráfego, o método HTTP, HTTP retorno URL base de código, nome do cookie, nome de usuário, nome do grupo e status de autenticação (se aplicável)
4.2.127. Deve ter filtros que permitem que os eventos de mudança de balanceamento de carga global: o protocolo, a quantidade de bytes de entrada de slaida, endereços IP e portas de origem e destino, países de origem e de trânsito de destino, FQDN solictado, endereço nome DNS solictado, a política utilizada;
4.2.128. Para cada um dos eventos (logs de eventos, segurança e tráfego) deve ser data de registo obrigatório, hora, nível de log, ID de mensagem;
4.2.129. Deve ser possível armazenar os registros no próprio sistema
4.2.130. Deve permitir a seleção nível de log é armazenado localmente (alerta de emergência, crítico, erro, aviso, notificação, informação e depuração);
4.2.131. Você deve permitir selecionar o tipo de registro para ser armazenado localmente (Evento de Segurança de Tráfego) para evitar o uso do disco excessiva;
4.2.132. Deve ser possível enviar notificações e logs para um servidor syslog;
4.2.133. Você deve permitir seleccionar o menor nível de log para ser enviado para o servidor syslog (emergência, alerta, crítico, erro, aviso, notificação, informação e depuração);
4.2.134. Para permitir o envio de registros para o servidor syslog em formato CSV;
4.2.135. Você deve permitir selecionar o tipo de registro a ser enviado para o servidor syslog;
4.2.136. A solução deve suportar o envio de alertas por e-mails, estes alertas podem ser configurados de acordo com o tipo de níveis de evento ou de gravidade.
4.2.137. Deve suportar o envio de alertas através de e-mails relacionados de pelo menos so seguintes eventos: alta disponibilidade, gerenciamento, configuração, monitoramento de integridade, validade disco do certificado;
4.2.138. Deve permitir e gerar relatórios sob demanda ou programados;
4.2.139. Deve permitir configurar um endereço para correspondência de relatórios programados em formato PDF;
4.2.140. Deve possuir os seguintes relatórios mininos disponíveis no sistema: servidores de tráfego: políticas mais utilizado e número de bytes associados, Top origens e bytes parceiros e as fontes mais ativos por país e número de bytes, hisotorico de bytes ; Para equilibrar as ligações de tráfego: links mais utilizados e associados bytes, bytes históricos; Reputação IP: a maioria dos destinos frequentes e contando, as origens mais frequentes e contando, as fontes mais frequentes com contagem e geografia associado; Dois: a maioria dos destinos frequentes e contagem; Geografias: a maioria dos destinos frequentes e contando, as origens mais frecuentesy sua contagem, fontes mais frequentes e de contagem e do país; firewall de aplicação web: destinos mais frequentes e contando,
4.2.141. Deve ter redundância e alta disponibilidade no mesmo modelo no modo activo-passivo e activo-activo
4.2.142. A formação de cluster deve pemritir versão OS sincronização e configuração entre os participantes;
4.2.143. Você deve ter mecanismos para monitorar o estado de interface para permitir que o estado membro do cluster mudança de ativo para passivo, em caso de falha.
4.2.144. Os participantes do cluster devem ser do mesmo modelo e ter a mesma versão do sistema operacional;
4.2.145. Pelo menos as seguintes informações devem ser sincronizados entre os membros do cluster: Configurações principais (linha de comando), certificados X.509, arquivos de solicitação de assinatura de certificado (arquivos de solicitação de assinatura de certificado (CSR)), chaves
privadas, arquivos relacionados mensagens de erro, indica o nível de conexões X0, X0 persistência e L7;
4.2.146. No cluster ativo-passivo apenas um dos nós deve enviar tráfego, basta enviar responsabilidade tráfego em caso de falha do ativo.
4.2.147. Na configuração activo-passivo deve manter a sincronização do sistema de operação e configuração, e minimizar o impacto em caso de falha do activo. Neste caso, a transição deve ser automática, sem intervenção externa do cluster;
4.2.148. Na configuração activa-activo todos os membros do cluster devem encaminhar o tráfego;
4.2.149. Na configuração activa-activo, do cluster tem de ser capaz de conter dois ou mais membros da mesma família. Permitindo que até 8 nós
4.2.150. Deve permitir configuração de parâmetros que permitem a seleção do sistema primário no cluster (sistema primário é aquele em que os ajustes são feitos e enviados para outros membros) dentro do mesmo grupo;
4.2.151. Se necessário, você pode aplicar configurações em qualquer membro do cluster, independentemente se este é primário ou secundário.
4.2.152. A sincronização da configuração de cluster pode ser reliazada através da porta dedicada.
4.2.153. O sistema deve permitir o uso de scripts em linguagem LUA para lidar com solicitações e respostas HTTP e selecione o caminho com base no conteúdo da informação do cabeçalho HTTP;
4.2.154. No caso de aparelhos que você deve suportar a configuração de várias instâncias do sistema;
4.2.155. Você deve permitir que o provisionamento de diferentes gestores para cada instância do sistema;
4.2.156. A solução deve permitir a encriptação/desencriptação de sessões SSL em vez de deixar essa função para servidores reais (um processo conhecido como SSL Offload);
4.2.157. Ao realizar SSL Offload, a solução deve agir como um servidor proxy para fins de processamento SSL, usando certificados e chaves para servidores: autenticar-se aos servidores clientes, criptografar e descriptografar as respostas de solicitação para os clientes;
4.2.158. Deve ser possível implementar a solução como um proxy SSL, neste caso, desempenha o papel de proxy em ambos os lados da conexão (cliente e servidor);
4.2.159. Deve suportar no minomo as criptografias: RSA, PFS, ECDHE e eNull para SSL Offload;
4.2.160. Deve permitir as configurações de criptografia SSL Offload
4.3. LOCAL E PRAZO DE ENTREGA
4.3.1. Os equipamentos deverão ser entregues no máximo em 30 (TRINTA) dias após a formalização do pedido.
4.3.2. No xxxxx xxxxxx xx 00 (XXXXXX) dias emissão do pedido, a PROPONENTE deverá entregar a ECP o Plano de Implantação da Solução, contendo todo o planejamento necessário para torná-la operacional no ambiente, explicitando também as ações de migração do ambiente atual para a nova disposição e os testes de aceitação
4.3.3. Todo o serviço de implantação deverá ser executado, no xxxxx xxxxxx xx 00 (XXXXXX) dias após a entrega dos equipamentos e elaboração do plano de implantação,
Nota: Caso ocorrá o atraso na entrega dos equipamentos, a PROPONENTE devera considerar em sua proposta a instalação der equipamento similiar para implantar no ambiente do ECP enquanto o novo equipamento não for entregue
4.4. SERVIÇOS DE IMPLANTAÇÃO
4.4.1. Após a formalização do pedido, a PROPONENTE será convocada para a reunião inicial a ser realizada no edifício sede do ECP, tendo está como objetivo o alinhamento entre as equipes para o início e execução das atividades.
4.4.2. Seguindo o prazo estipulado em LOCAL E PRAZO DE ENTREGA a PROPONENTE deverá entregar a ECP o Projeto de Implantação da Solução, contendo todo o planejamento necessário para torná-la operacional no ambiente, explicitando também as ações de migração do ambiente atual para a nova disposição e os testes de aceitação.
4.4.3. O projeto deverá conter o levantamento dos requisitos técnico/funcionais (assessment), o qual deverá abordar todas as funcionalidades requeridas neste termo de referência.
4.4.4. Com base no Levantamento dos requisitos técnico/funcionais, deverá ser definido:
4.4.5. Documento de especificações funcionais;
4.4.5.1. Documento de padronização das configurações;
4.4.5.2. Documento de pré-requisitos técnicos de infraestrutura e operacionais;
4.4.5.3. Documento com a topologia da rede e serviços;
4.4.5.4. Cronograma de implantação e janelas operacionais;
4.4.5.5. Controle de Issues;
4.4.5.6. Mapa de riscos para o projeto e para o ambiente operacional de TI do ECP;
4.4.5.7. Plano de comunicação;
4.4.5.8. Mapa de atribuições e responsabilidades.
4.4.6. Após a aprovação, pelo ECP, o Projeto de Implantação da Solução, a PROPONENTE deverá iniciar a fase da implantação, bem como gerenciar o referido projeto, de modo que toda a documentação seja mantida atualizada.
4.4.7. De acordo com as necessidades do ECP será realizada uma reunião para acompanhamento e gestão da Implantação, onde a PROPONENTE deverá apresentar o relatório de status do projeto.
4.4.8. A ECP ficará responsável por disponibilizar o rack a ser utilizado, bem como os pontos de rede e de energia elétrica necessários para a execução dos trabalhos, pela PROPONENTE.
4.4.9. A PROPONENTE deverá realizar a instalação fisica do firewall e equipamentos de rede no rack disponibilizado pelo ECP, correspondendo a sua fixação, energização e conexão dos pontos de rede.
4.4.10. Após a instalação física, a PROPONENTE deverá realizar, com o acompanhamento da Unidade de Tecnologia da Informação do ECP, a configuração lógica do firewall seguindo o padrão de rede, a ser informado na reunião inicial para alinhamento das equipes que participarão da execução dos trabalhos até que o ambiente fique estável e o ECP aceite o termino do acompanhamento.
4.4.11. Faz parte da implantação o fornecimento, a instalação e configuração dos hardwares e softwares, bem como ações necessárias para migração do ambiente atual para a nova disposição e operação da solução do ambiente, sem qualquer impacto para as atividades do ECP.
4.4.12. A PROPONENTE deverá efetuar a instalação e a configuração dos componentes na última versão e nível de correção, publicados pelo fabricante e compatível com a infraestrutura de TI do ECP.
4.4.13. Após a configuração do (s) equipamento (s) e validação pela Unidade Tecnologia da Informação do ECP, a PROPONENTE deverá apresentar os seguintes documentos para cada equipamento:
4.4.13.1. Documentação da configuração executada (em arquivo digital);
4.4.13.2. O arquivo exportado pelo equipamento contendo as configurações lógica (arquivo digital)
4.4.13.3. A topologia de sua implantação (em arquivo digital).
4.4.14. Caso seja necessário a utilização de usuário administrador e senha para a configuração e/ou gerenciamento dos equipamentos, os mesmos deverão ser informados ao ECP.
4.5. SERVIÇOS DE GARANTIA
4.5.1. GARANTIA DE SOFTWARE
4.5.1.1. Os produtos deverão ser entregues em sua versão mais atual. Em caso de mudança de nomenclatura deverá estar especificado na proposta técnica o nome anterior e o atual;
4.5.1.2. O software deverá ser fornecido com garantia do fabricante para manutenção e atualização tecnológica (upgrade) mínima de 36 (trinta e seis) meses.
4.5.1.3. O proponente e/ou o fabricante representado pelo mesmo, deverá disponibilizar uma linha telefônica, Hotline de Suporte Técnico, que deverá estar disponível no regime de 24 x 7 (24horas para os 7 dias da semana), durante todo o período do contrato de 36 meses.
4.5.1.4. Atualizações de software e correções deverão estar disponíveis via Web, sem custo adicional durante o período de garantia.
4.5.2. GARANTIA DE HARDWARE
4.5.2.1. Os produtos deverão ser entregues em sua versão mais atual. Em caso de mudança de nomenclatura deverá estar especificado na proposta técnica o nome anterior e o atual;
4.5.2.2. O hardware e acessórios componentes da solução deverão ser fornecidos com garantia mínima do fabricante, mínima de 36 (trinta e seis) meses, com atendimento on-site, com substituição do equipamento no próximo dia útil (NBD-Next Business Day), após comprovação do defeito junto ao fabricante.
4.5.2.3. O proponente e/ou o fabricante representado pelo mesmo, deverá disponibilizar uma linha telefônica, Hotline de Suporte Técnico, que deverá estar disponível no regime de 24 x 7 (24horas para os 7 dias da semana), durante todo os 36 meses de contrato de garantia. O primeiro atendimento à qualquer falha da rede para detecção do problema não deverá exceder 4 (quatro) horas da abertura do chamado.
4.5.2.4. Atualizações de firmware e correções deverão estar disponíveis via Web, sem custo adicional durante o período de garantia.
5. OBRIGAÇÕES DA PROPONENTE
5.3. Designar um profissional da PROPONENTE (gerente de conta ou de relacionamento) que seja responsável pelo relacionamento estratégico com o ECP, com autonomia para tomar decisões que impactem no bom andamento dos serviços.
5.4. Providenciar as exigências previstas neste instrumento no prazo máximo de 5 (cinco) dias úteis, a partir da formalização do pedido, sendo certo que este prazo não se confunde com a execução do contrato.
5.5. Manter, durante a execução do contrato, todas as condições de habilitação exigidas na licitação que deu origem ao contrato.
5.6. Cumprir todas as exigências descritas neste instrumento e realizar, com seus próprios recursos, todos os serviços relacionados com o objeto deste instrumento, de acordo com as especificações ora estipuladas.
5.7. Responsabilizar-se por todas as despesas com materiais, mão-de-obra, transportes, equipamentos, máquinas, seguros, taxas, tributos, incidências fiscais, trabalhistas, previdenciárias, salários, custos diretos e indiretos, encargos sociais e contribuições de qualquer natureza ou espécie, necessários à perfeita execução do objeto.
5.8. Responsabilizar-se pelos custos de alimentação, hospedagem, deslocamentos, durante a execução dos serviços, de seus funcionários ou prestadores de serviços.
5.9. Atender às determinações da fiscalização do ECP.
5.10. Manter sigilo acerca de todos os dados e informações a que tiver acesso por ocasião da contratação.
5.11. Guardar todas as informações confidenciais em local seguro, de forma que estejam adequadamente protegidas contra roubo, dano, perda ou acesso não autorizado, de acordo com padrões que sejam, no mínimo, equivalentes àqueles aplicados às informações confidenciais da PROPONENTE.
5.12. Só divulgar informações acerca da prestação dos serviços objeto deste contrato que envolvam o nome do ECP mediante sua prévia e expressa autorização.
5.13. Manter por si, por seus prepostos e contratados, irrestrito e total sigilo sobre quaisquer dados que lhe sejam fornecidos em decorrência deste contrato, sobretudo quanto à estratégia de atuação do ECP.
5.14. Não utilizar a marca ECP ou qualquer material desenvolvido pelo ECP, assim como os dados dos clientes a que tenha acesso no decorrer das atividades inerentes a este contrato, em ações desenvolvidas pela PROPONENTE fora do âmbito de atuação deste contrato.
5.15. Tratar todas as informações a que tenha acesso em função do presente contrato em caráter de estrita confidencialidade, agindo com diligência para evitar sua divulgação verbal ou escrita, ou permitir o acesso, seja por ação ou omissão, a qualquer terceiro.
5.16. Prestar esclarecimentos ao ECP sobre eventuais atos ou fatos noticiados que envolvam a PROPONENTE, independentemente de solicitação.
5.17. Cumprir todas as leis e imposições federais, estaduais e municipais pertinentes e responsabilizar- se por todos os prejuízos decorrentes de infrações a que houver dado causa.
5.18. Cumprir a legislação trabalhista e previdenciárias com relação a seus funcionários, e não sendo aceito a contratação de terceiros para execução dos serviços prestados pela PROPONENTE.
5.19. Em reclamações trabalhistas, eventualmente propostas por seus empregados, prepostos ou ex- funcionários envolvendo o ECP, a PROPONENTE responsabilizar-se-á pela defesa, inclusive por custos, despesas e honorários advocatícios, bem como pelo cumprimento das decisões judiciais, isentando ainda o ECP de quaisquer responsabilidades e/ou ônus decorrentes direta ou indiretamente dos referidos processos judiciais.
5.20. A assinatura do contrato não implicará ao ECP, vínculo ou obrigação trabalhista, direta ou indireta, de qualquer natureza, obrigando-se ainda a PROPONENTE a manter o ECP a salvo de qualquer litígio, assumindo todas as obrigações fiscais, trabalhistas e previdenciárias referentes ao pessoal alocado para o cumprimento do presente objeto.
5.21. Orientar seus funcionários no sentido de portarem crachás e exibirem seus documentos de identificação quando se apresentarem para a realização de qualquer serviço no estabelecimento do ECP.
5.22. Substituir de imediato, sempre que exigido pelo ECP, e independentemente de justificativa por parte deste, qualquer empregado ou contratado cuja atuação, permanência ou comportamento sejam julgados inconvenientes ou insatisfatórios ao interesse do ECP.
5.23. Comprovar, a qualquer momento, o pagamento dos tributos que incidirem sobre a execução dos serviços prestados.
5.24. Responsabilizar-se por recolhimentos indevidos ou pela omissão total ou parcial nos recolhimentos de tributos que incidam ou venham a incidir sobre os serviços contratados.
5.25. Responsabilizar-se pelos danos causados ao ECP ou a terceiros, decorrentes de sua culpa ou dolo na execução dos serviços.
5.26. Responder civil ou criminalmente, por eventuais danos ou delitos causados por seus empregados, prepostos e/ou contratados ao ECP ou a terceiros, devendo indenizar todos os prejuízos ocasionados.
5.27. Responsabilizar-se por quaisquer acidentes de que possam ser vítimas seus empregados e prepostos, quando nas dependências do ECP, ou em qualquer outro local onde estejam prestando os serviços, devendo adotar as providências que, a respeito, exigir a legislação em vigor.
5.28. Manter comunicação frequente com o ECP oferecendo-lhe informações acerca do andamento dos serviços e da evolução dos processos, permitindo, assim, eventuais adequações e ajustes que se façam necessários.
5.29. Informar ao ECP todos os acontecimentos inerentes às atividades objeto deste instrumento.
5.30. Manter entendimento com o ECP, objetivando evitar interrupções ou paralisações na execução dos serviços.
5.31. Solucionar todos os eventuais problemas pertinentes ou relacionados com a execução dos serviços, mesmo que para isso outra solução não prevista tenha que ser apresentada, para aprovação e implementação, sem ônus adicionais para o ECP.
5.32. Registrar em relatórios de atendimento todas as reuniões de serviço entre o ECP e PROPONENTE, com o objetivo de tornar transparentes os entendimentos havidos e também para que ambas as partes tomem as providências necessárias ao desempenho de suas tarefas e responsabilidades.
5.33. Esses relatórios deverão ser enviados pela PROPONENTE ao ECP até o prazo máximo de 2 (dois) dias úteis após a realização do contato e/ou reunião.
5.34. Se houver incorreção no registro dos assuntos tratados, o ECP solicitará a necessária correção, no prazo máximo de 2 (dois) dias úteis, a contar da data do recebimento do respectivo relatório.
5.35. Responder, perante o ECP e terceiros, por eventuais prejuízos e danos decorrentes de sua demora ou de sua omissão, na condição dos serviços de sua responsabilidade, ou por erro seu na execução dos serviços.
5.36. A PROPONENTE, em nenhuma hipótese, poderá subcontratar a totalidade dos serviços.
5.37. Será admitida a subcontratação de serviços específicos fora do escopo deste objeto, às expensas e riscos da parte da PROPONENTE, condicionada, entretanto, à prévia e expressa autorização escrita do ECP.
5.38. A PROPONENTE deverá obter autorização prévia e por escrito, do ECP, para subcontratar qualquer parte dos serviços fora do escopo deste objeto. A substituição de qualquer sub PROPONENTE sujeitar-se-á igualmente à prévia aprovação do ECP.
5.39. Não será permitido subcontratação dos serviços de implantação por parte da PROPONETE.
5.40. É vedada a subcontratação de empresa que tenha participado do procedimento licitatório.
5.41. Nenhum encargo trabalhista, inclusive de acidente de trabalho, previdenciário, tributário ou responsabilidade civil de qualquer natureza, decorrente da subcontratação, será imputada ou se comunicará ao ECP.
5.42. Aplicar treinamento técnico para equipe de especialistas do ECP.
6. OBRIGAÇÕES DA ECP
6.3. Designar um funcionário como gestor do contrato e que servirá de contato junto à PROPONENTE para gestão, acompanhamento e esclarecimentos que porventura se fizerem necessários durante a vigência contratual.
6.4. Xxxxxxxx e colocar à disposição da PROPONENTE todos os elementos e informações que se fizerem necessários à execução dos serviços.
6.5. Acompanhar, fiscalizar e auditar a execução dos serviços prestados, nos aspectos técnicos, de segurança, de confiabilidade e quaisquer outros de seu interesse, através de pessoal próprio ou de terceiros designados para este fim.
6.6. Avaliar a qualidade dos serviços, podendo rejeitá-los no todo ou em parte, caso estejam em desacordo com o constante neste instrumento, reservando-se ao direito de suspender o pagamento da PROPONENTE até que os serviços sejam executados em conformidade com o contratado.
6.7. Notificar, formal e tempestivamente, a PROPONENTE sobre as irregularidades observadas no cumprimento do contrato.
6.8. Fica assegurado a ECP o direito de exigir e obter imediatamente a substituição de qualquer empregado e/ou preposto da PROPONENTE, notadamente quando verificada a falta de qualificação, zelo e dedicação na execução das tarefas, ou outros comportamentos que prejudiquem as atividades e resultados, objeto deste instrumento.
7. PAGAMENTO
7.3. O pagamento será efetuado em até 30 (trinta) dias, após a entrega dos equipamentos, a execução de serviços de implantação e suporte pos garantia serão pagos após 30 dias ao aceite formal dos serviços
7.4. A PROPONETE deverá descrever de forma detalhada os valores a serem pagos e os respectivos cpnjs que deverão fazer parte da proposta técnica.
7.5. A PROPOSTA deverá incluir todos os impostos federais, estaduais e municipais.
8. VIGÊNCIA DO CONTRATO
8.3. O prazo de vigência deste fornecimento será de 36 (trinta e seis) meses, contados da data de sua assinatura, podendo ser prorrogado, a critério do ECP, de acordo com os permissivos do Regulamento de Licitações e de Contratos do Sistema ECP.
9. DA APRESENTAÇÃO DE CATALOGOS
9.3. O PROPONENTE deverá incluir junto da proposta o datasheet dos equipamentos ofertados, com o propósito de informar as características dos equipamentos ofertados, oferecendo subsídios ao ECP para aferição da compatibilidade de suas especificações com relação àquelas constantes deste instrumento.
9.4. Os itens desprovidos dos documentos relacionados nos subitens anteriores, serão passíveis de diligência, podendo, para tanto, o ECP se valer de todos os meios possíveis, tais como consulta a site diversos, ligações a fabricantes ou exigência de documentos complementares, dentre outros.
10. HABILITAÇÃO TÉCNICA
10.3. O Proponente deverá apresentar a seguinte documentação:
10.3.1. Comprovação de que o PROPONENTE fornece ou forneceu bens e serviços iguais ou similares ao objeto do presente edital. A comprovação será feita por meio de apresentação de atestado (s) de capacidade técnica, fornecido (s) por órgão(s) da administração pública ou entidade privada que possua, no mínimo, 60% (sessenta por cento), devidamente assinado(s), carimbado(s) e em papel timbrado da empresa ou órgão tomador, compatível com o objeto desta licitação.
10.3.2. Apresentação de comprovação de que PROPONENTE possui um centro de operações de rede e segurança operando em regime 24x7. Esta comprovação deverá ser feita através fornecido (s) por órgão(s) da administração pública ou entidade privada que possua, no mínimo, 60% (sessenta por cento), devidamente assinado(s), carimbado(s) e em papel timbrado da empresa ou órgão tomador, compatível com o objeto desta licitação;
10.3.3. Apresentação de, no mínimo, 01 (um) profissional pertencente ao quadro permanente do PROPONENTE, com certificação técnica emitida pela instituição competente, indicando sua habilitação técnica na tecnologia ofertada, devendo estar em papel timbrado.
10.3.4. Declaração do fabricante, esclarecendo que o licitante é revenda técnica autorizada, e que está capacitado tecnicamente para atender ao objeto ora licitado, devendo ser emitida dentro de 90 dias do processo licitatório.
10.3.5. Para comprovar que os profissionais certificados apresentados pertencem ao quadro permanente da empresa, o PROPONENTE deverá apresentar prova de registro em carteira, no caso de funcionários, ou contrato social da empresa, no caso de sócios.
10.3.6. As declarações e atestados emitidos pelas empresas, sejam fabricantes ou clientes, exigidos para comprovação da qualificação da empresa, devem estar em papel timbrado, com a devida identificação e assinatura do responsável, devendo possuir ainda os contatos do emissor