Aquisição de solução de Proteção do Contexto das Aplicações (Balanceamento de Cargas), com serviços básicos e especializados e transferência de conhecimento, em atendimento às necessidades do Ministério da Gestão e da Inovação em Serviços Públicos (MGI), na forma da Portaria SGD/MGI nº 5.950, de 26 de outubro de 2023, em conformidade com o Decreto nº 11.837, de 21 de dezembro de 2023 (ColaboraGov), nos termos da tabela abaixo, conforme condições e exigências estabelecidas neste instrumento.

Detalhamento das especificações técnicas

1.             Item 1  Solução de balanceador de carga

1.1.        Características Gerais:

1.1.1.  A solução poderá ser ofertada na forma de appliances físicos ou de appliances virtuais;

1.1.2.  Em caso de oferta da solução de balanceador de carga na forma de appliance virtual, esta deverá ser compatível com sistemas de virtualização VMware ESXi 7 ou superior, e poderá ser instalada em ambiente interno ou em nuvem privada contratada pelo Colaboragov;

1.1.3.  Em caso de oferta de solução de balanceador de carga na forma de appliances físicos, os equipamentos deverão conter, no mínimo, 4 (quatro) interfaces 10Gbps com seus respectivos transceivers ópticos SFP+ short range com conectores LC;

1.1.4.  Também será aceita uma composição mista entre os ambientes, se respeitadas as especificações de cada tipo de solução, bem como a soma de suas capacidades;

1.1.5.  No caso de uma composição de appliances, estes deverão operar conjuntamente em até 8 (oito) unidades e deverão responder como uma ÚNICA solução de proteção de contexto das aplicações. Isto é, todos os appliances deverão manter as configurações sincronizadas, conforme necessidade.

1.1.6.  A solução deverá estar licenciada e ter garantia do fabricante para, no mínimo, 60 (sessenta) meses;

1.1.7.  A Contratada deverá possuir uma Central de Serviços com o objetivo de atender os chamados de garantia da solução;

1.1.8.  Os chamados poderão ser abertos via telefone, e-mail e portal Web;

1.1.9.  A Central de Serviços deverá realizar os atendimentos para a abertura de chamados no regime de 365x24x7(vinte e quatro horas por dia, sete dias na semana, todos os dias do ano), para esclarecimento de dúvidas relacionadas à prestação dos serviços, políticas e regras implementadas, funcionalidades já implementadas e não implementadas, além de indisponibilidade total ou parcial da solução;

1.1.10.    Em situações de indisponibilidade da solução, o atendimento deverá ser imediato; com prazo de até 6 (seis) horas a partir da abertura do chamado para problemas de configuração ou bugs de software e prazo de até 24 (vinte e quatro) horas para falhas de hardware;

1.1.11.    A Contratada será responsável por intermediar a comunicação com a equipe técnica do fabricante, seja na língua portuguesa ou inglesa;

1.1.12.    A plataforma de atendimento da CONTRATADA deverá permitir o registro e classificação das requisições de serviços para as demandas de Banco de Horas, que deverão ser utilizadas para aplicação de novas funcionalidades e projetos da Contratante, descritos no item Hora de consultoria especializada;

1.1.13.    Os chamados abertos só poderão ser fechados após autorização pela Contratante e deverão aguardar um prazo mínimo de 2 (dois) dias para a aprovação por parte da Contratante, no entanto, podendo, a seu critério, reabrir o chamado.

1.1.14.    A Contratante informará as pessoas autorizadas a abrir e fechar chamados junto à Contratada, bem como o meio pelo qual a autorização de fechamento será formalizada.

1.1.15.    Todas as atividades relacionadas ao período de garantia técnica da solução ocorrerão sob a responsabilidade da Contratada, sem nenhum ônus ao Contratante;

1.1.16.    Os serviços de garantia da solução ofertados pelo fabricante devem ser gerenciados pela Contratada e prestados por sua equipe técnica, fabricante ou rede autorizada de serviços, nos locais onde a solução ofertada estiver instalada na modalidade on-site, incluindo o fornecimento de peças originais de reposição e demais reparos necessários, acionados pela garantia;

1.1.17.    Os Serviços Continuados 24x7 têm como o objetivo o acionamento do suporte do fabricante da solução e garantias. As demandas de configuração de novas funcionalidades e/ou projetos serão classificadas como atividades de Horas Técnicas/Banco de Horas.

1.2.        Capacidades e performance

1.2.1.  Serão requisitados os quantitativos por múltiplos unitários das capacidades listadas nesta seção;

1.2.2.  A solução deve ter capacidade de operar de forma escalar, sem interrupção das conexões, conforme conceito definido por solução agrupada;

1.2.3.  Processar 8 (oito) Gbps de throughput em Camada 7

1.2.4.  Possuir 10 (dez) Gbps de throughput em Camada 4

1.2.5.  Possuir capacidade de compressão de 3,8 Gbps (três gigas e oitocentos megas bits por segundo);

1.2.6.  Capacidade de processar 3 (três) Gbps de throughput de tráfego SSL com chaves RSA de 2048 bits;

1.2.7.  Manter, no mínimo, 9.000.000 (nove milhões) conexões simultâneas na camada 4.

1.2.8.  Ter capacidade de receber 130.000 (cento e trinta mil) conexões em camada 4 por segundo;

1.2.9.  Processar 4.600 (quatro mil e seiscentas) transações por segundo de tráfego SSL com ECC (curva elíptica).

1.3.        Redes e protocolos:

1.3.1.  Deve ser possível configurar LACP em modo ativo e passivo;

1.3.2.  Deve ser capaz de transportar múltiplas VLANS utilizando o protocolo 802.1q em uma única porta ou uma agregação de portas;

1.3.3.  Deve ser capaz de suportar simultaneamente 1000 VLANS;

1.3.4.  Deve possuir suporte a protocolos Spanning-Tree (802.1D), Rapid Spanning-Tree (802.1w,802.1t) e Múltiplo Spanning-tree (802.1S);

1.3.5.  Deve suportar distribuição de carga em direção a aplicação, com a resposta da aplicação diretamente ao requisitante;

1.3.6.  Deve ser possível a utilização dos protocolos HTTP/1.0, HTTP/1.1, HTTP/2 e HTTP/3;

1.3.7.  Deve ser possível o espelhamento de conexões HTTP, FTP, Telnet, SSL e UDP;

1.3.8.  Deve ser capaz de realizar o DHCP relay para requisições de IP;

1.3.9.  Deve possuir o recurso de ECMP (Equal Cost Multipath);

1.3.10.    Deve possuir capacidade de operar os protocolos BGP, OSPF e RIP seja em IPV4 ou IPv6 para cada domínio de roteamento;

1.3.11.    Deve possuir o recurso de BFD (Bidirectional Forward Detection);

1.3.12.    Deve ser possível a criação de IPs virtuais com endereço IPv4 para servidores reais com endereço em IPv6;

1.3.13.    Ser capaz de possuir múltiplas tabelas de roteamento em IPv4 e IPv6;

1.3.14.    Deve ser capaz de realizar Network Address Translation (NAT);

1.3.15.    Possuir suporte à funcionalidade de VXLAN, essencial para integração com o ambiente de virtualização SDN (Software Defined Network);

1.3.16.    Ser capaz de realizar o protocolo LLDP (Link Layer Discover Protocol) utilizando as seguintes informações:

1.3.16.1.         Port ID;

1.3.16.2.         TTL;

1.3.16.3.         Port Description;

1.3.16.4.         System Name;

1.3.16.5.         System Description;

1.3.16.6.         Management Address;

1.3.16.7.         Port VLAN ID;

1.3.16.8.         Port and Protocol VLAN ID;

1.3.16.9.         VLAN Name;

1.3.16.10.     Protocol Identity;

1.3.16.11.     Link Aggregation;

1.3.16.12.     Maximum Frame Size;

1.3.16.13.     Ser capaz de realizar sFlow;

1.3.16.14.     Ser capaz de realizar DNS64;

1.3.16.15.     Ser capaz de suportar Policy Based Routing ou Policy Based Forwarding;

1.3.16.16.     Ser capaz de realizar Port Mirroring;

1.3.16.17.     Ser capaz de realizar Flow Tracking;

1.3.16.18.     Ser capaz de realizar IEEE 802.3x Flow Control;

1.3.16.19.     Ser capaz de realizar IEEE 802.1p Packet Priority, deve incluir todas as oito (8) classes de serviços;

1.3.17.    Possuir recursos para suportar Jumbo Frames.

1.4.        Recursos de Tráfego:

1.4.1.  Deverá ser capaz de enviar uma cópia do tráfego para um elemento de segurança adicional, como por exemplo um grupo de IDS ou Sniffer, para fins de análise de tráfego de rede ou mesmo para identificação de padrões de acesso não permitidos ou indicações de atividade maliciosas ou ataques de rede;

1.4.2.  Deve ser capaz de realizar o encapsulamento, em camada 3, do tráfego entre o distribuidor de tráfego e o servidor para tráfego IPv4 e IPv6, quando a distribuição é realizada apenas em direção ao servidor, onde a resposta do servidor real é enviada diretamente ao cliente;

1.4.3.  Deve ser capaz de distribuir o tráfego das requisições para os servidores independente de tipo de aplicação, sistema operacional ou plataforma;

1.4.4.  Deve ser possível definir um grupo de distribuição de tráfego prioritário, onde seja possível especificar a prioridade de cada grupo e a quantidade mínima de servidores que deve estar disponível em cada grupo;

1.4.5.  Caso ocorra de a quantidade mínima de servidores para um grupo ficar indisponível, o tráfego deve ser distribuído automaticamente para o próximo grupo em ordem de prioridade;

1.4.6.  Caso o grupo com maior ordem de prioridade volte a ter a quantidade mínima de servidores disponível, a solução deve retorná-lo como grupo ativo a receber tráfego, sem afetar o serviço;

1.4.7.  O tráfego com destino a determinado servidor deve poder ser contido de forma gradual, onde apenas as sessões que já foram estabelecidas e possuem persistência poderão estabelecer nova conexão;

1.4.8.  O tráfego com destino a determinado servidor deve poder ser contido de forma real, onde não seja possível abrir novas conexões para este servidor;

1.4.9.  Deve ser capaz de aumentar a performance do serviço com o recurso de abertura de algumas conexões com o servidor de destino onde seja possível inserir as requisições HTTP de clientes nestas conexões, reduzindo a necessidade de estabelecimento de conexões nos servidores;

1.4.10.    Os seguintes métodos de distribuição de tráfego devem ser implantados:

1.4.10.1.         Round Robin;

1.4.10.2.         Por peso;

1.4.10.3.         Por número de conexões;

1.4.10.4.         Pelo servidor ou equipamento com resposta mais rápida baseado no tráfego real;

1.4.10.5.         Dinâmico, baseado em parâmetros de um determinado servidor ou equipamento, coletados via SNMP ou WMI;

1.4.10.6.         Deve ser possível distribuir tráfego das novas sessões preservando as sessões existentes no mesmo servidor, implementando persistência de sessão dos seguintes tipos:

1.4.10.7.         Através da análise da URL acessada;

1.4.10.8.         Através da análise de qualquer parâmetro no header HTTP;

1.4.10.9.         Através da análise do MS Terminal Services Session (MSRDP);

1.4.10.10.     Através da análise do SIP Call ID ou Source IP;

1.4.10.11.     Por cookie: inserção de um novo cookie na sessão;

1.4.10.12.     Por cookie: utilização do valor do cookie da aplicação, sem adição de cookie;

1.4.10.13.     Por endereço IP destino;

1.4.10.14.     Endereço IP origem;

1.4.10.15.     Por sessão SSL;

1.4.10.16.     Através da análise de qualquer informação da porção de dados (camada 7 OSI);

1.4.10.17.     Deve ser possível a configuração das aplicações através de um framework unificado;

1.4.10.18.     Deve possuir recursos para monitoração de aplicações, através de monitores predefinidos, que utilizem, pelo menos, os seguintes protocolos:

1.4.10.19.     ICMP, HTTP, HTTPS, FTP, SASP, SMB, RADIUS, LDAP, IMAP, SMTP, POP3, SIP, MSSQL, NNTP, SOAP, SNMP, WMI, ORACLE, RPC, Real Server;

1.4.10.20.     Conexões TCP e UDP pela respectiva porta no servidor;

1.4.10.21.     Deve ser possível distribuição de tráfego para servidores SIP em VOIP;

1.4.10.22.     Deve ser possível a limitação da quantidade de sessões estabelecidas para cada IP virtual (VIP);

1.4.10.23.     Deve ser possível a limitação da quantidade de sessões estabelecidas para cada servidor real;

1.4.10.24.     Deve ser possível a limitação da quantidade de sessões estabelecidas com cada grupo de servidores;

1.4.10.25.     A solução deve oferecer a possibilidade de redirecionamento do tráfego HTTP para HTTPs nas requisições;

1.4.10.26.     Deve possuir suporte a algoritmo de HASH via CARP (Cache Array Routing Protocol);

1.4.10.27.     Ser capaz de enviar tráfego para dispositivos passivos, como DLPs;

1.4.11.    Ser capaz de classificar o tráfego utilizando, pelo menos, os seguintes parâmetros:

1.4.11.1.         Reputação IP;

1.4.11.2.         Protocolo;

1.4.11.3.         Categoria URL;

1.4.11.4.         Geolocalização;

1.4.11.5.         IP origem;

1.4.11.6.         IP destino;

1.4.11.7.         Porta origem;

1.4.11.8.         Porta destino;

1.4.11.9.         Após a classificação deve ser capaz de determinar qual ação será realizada, sendo pelo menos:

1.4.11.10.     Bloqueado;

1.4.11.11.     Descriptografado e enviado para um serviço;

1.4.11.12.     Realizar o by-pass desse tipo de tráfego direto para Internet;

1.4.11.13.     Ser capaz de realizar controle granular sobre mudanças no cabeçalho HTTP e suporte a traduções de porta que permitem aos dispositivos de segurança identificarem um tráfego em texto claro (ex: HTTP) para a devida inspeção;

1.4.12.    Ser capaz de enviar o tráfego descriptografado para análise de diversos dispositivos de segurança, pelo menos:

1.4.12.1.         Firewalls;

1.4.12.2.         ICAP;

1.4.12.3.         Proxy Web;

1.4.12.4.         DLP;

1.4.12.5.         anti-malware;

1.4.12.6.         IPS;

1.4.12.7.         IDS;

1.4.12.8.         ferramentas forenses;

1.4.12.9.         Deve ser capaz de definir qual tráfego será tunelado por VPN através da segmentação baseada em subrede;

1.4.12.10.     Ser capaz de permitir que determinado tráfego de entrada seja priorizado para certas aplicações;

1.4.12.11.     Deve ser possível a priorização para determinados usuários em detrimento de outros através da restrição de largura de banda e priorização de tráfego;

1.4.12.12.     Deve ser possível o controle de banda por domínio de roteamento;

1.4.12.13.     Deve ser possível o controle de banda de forma dinâmica para conjuntos de aplicações e rede;

1.4.12.14.     Deve ser possível o controle de banda de forma estática para conjuntos de aplicações e rede;

1.4.12.15.     Ser capaz de lidar com clientes IPv6 quando as aplicações atendem apenas com IPv4 (requests AAAA ou A6);

1.4.12.16.     Ser capaz de realizar balanceamento global com IPv6 para distribuição de tráfego entre datacenters;

1.4.12.17.     Ser capaz de tratar informações das camadas L4-L7 (FTP, SMTP, URL, HTTP Header, TCP e UDP) para a tomada de decisão de encaminhamento a servidor real, em IPv4 e IPv6;

1.4.13.    Possuir, pelo menos, os seguintes algoritmos de balanceamento do DNS:

1.4.13.1.         Disponibilidade da Aplicação;

1.4.13.2.         Global Availability;

1.4.13.3.         Round Robin;

1.4.13.4.         Ratio;

1.4.13.5.         LDNS Persist;

1.4.13.6.         Round trip time;

1.4.13.7.         Packet Completion Rate;

1.4.13.8.         Geografia;

1.4.13.9.         Capacidade do VIP;

1.4.13.10.     Least Connections;

1.4.13.11.     Pacotes por segundo;

1.4.13.12.     Hops;

1.4.13.13.     QoS definido pelo usuário;

1.4.13.14.     Kilobytes per Second;

1.5.        Recursos de Proteção do Contexto das aplicações:

1.5.1.  A solução deve possuir suporte à proteção dos cookies da aplicação através do recurso de criptografia;

1.5.2.Deve ser possível controlar a resposta ICMP por IP virtual (VIP);

1.5.3.  Deve ser capaz de proteger as aplicações WEB do ambiente contra ataques e comportamentos maliciosos em L7 (camada de aplicação);

1.5.4.  Deve possuir política de segurança de aplicações web pré-configurada na solução;

1.5.5.  Deve ser capaz de criar políticas de segurança a partir de integração com ferramentas de análise de vulnerabilidades como: IBM AppScan, HP Webinspect, Qualys, WhiteHat;

1.5.6.  Deve possuir a granularidade de oferecer diferentes políticas para diferentes aplicações;

1.5.7.  Deve ser capaz de atribuir políticas diferenciadas por URL e por aplicação, de forma que cada URL ou cada aplicação tenha determinada política de proteção;

1.5.8.  Deve ser possível a criação de assinaturas personalizadas utilizando linguagem aberta para customizar e promover a proteção de ataques mais recentes;

1.5.9.  Deve ser capaz de inspecionar upload de arquivos para servidores de aplicação através de integração via ICAP;

1.5.10.    Deve possuir integração com software de Antivírus para inspeção de arquivos deve ser possível para diversos fornecedores diferentes;

1.5.11.    Deve ser possível a integração com soluções terceiras que recebam os logs e tratem os eventos de segurança;

1.5.12.    Deve ser possível configurar granularmente, por aplicação protegida, restrições de métodos HTTP permitidos, tipos ou versões de protocolos, tipos de caracteres e versões utilizadas de cookies;

1.5.13.    Deve ser capaz de proteger contra o vazamento de informações sensíveis entregues pelo servidor, bloqueando a página ou mascarando os dados que serão apresentados ao usuário;

1.5.14.    Deve ser capaz de criar políticas de segurança de forma automática de acordo com o tráfego que é recebido pela aplicação;

1.5.15.    Deve ser possível editar esta política criada automaticamente;

1.5.16.    Deve possuir assinaturas que identifiquem e bloqueiem atividades maliciosas e que sejam atualizadas através de uma base do fabricante com uma determinada frequência;

1.5.17.    Deve possuir aderência ao modelo de segurança de aplicações OWASP de 2021 ou posterior, com os 10 principais itens estabelecidos, através de um framework que reflita nas políticas de segurança;

1.5.18.    Deve possuir a capacidade de avaliar a aderência de cada política ao modelo top 10 OWASP em determinado momento para cada aplicação;

1.5.19.    Deve ser possível a utilização do recurso de X-Forwarded-For no cabeçalho HTTP do tráfego;

1.5.20.    Deve ser possível a atribuição de tipos de clientes inválidos através da checagem do cabeçalho "user-agent";

1.5.21.    Deve ser possível a proteção contra ataques do tipo Cross Site Request Forgery (CSRF), onde possa ser possível definir as URLs que serão protegidas para tal;

1.5.22.    Para maior praticidade na administração de políticas deve ser possível a criação de perfis hierarquizados para serem reaproveitados;

1.5.23.    Deve ser possível a criação de regras que validem o endereço IP de origem de acordo com a região geográfica, permitindo a identificação do País e estado do IP de origem.

1.5.24.    A base de dados de IPs deve ser guardada na solução e atualizada periodicamente sem custos adicionais durante a vigência do contrato;

1.5.25.    Deve possuir capacidade de "ofuscar" a URI promovendo através da realização de proxy reverso com a finalidade de prover o acesso seguro as aplicações web internas;

1.5.26.    Deve possuir recursos de TLS 1.2, TLS 1.3, SHA 256 HASH e SHA 2 Cipher;

1.5.27.    Deve possuir recurso de DTLS 1.2;

1.5.28.    Deve possuir o recurso de SNI (Server Name Indication) para o TLS (Transport Layer Security);

1.5.29.    Possuir recursos de criptografia SSL/TLS envolvendo proteção, aceleração e inspeção de tráfego que devem estar disponíveis quando a conexão for estabelecida utilizando:

1.5.30.    Ao ser realizada inspeção, proteção, OffLoad e aceleração de tráfego criptografado através de SSL/TLS;

1.5.31.    Encaminhar ao servidor real via cabeçalho HTTP ou de forma transparente, todo o certificado digital utilizado pelo lado cliente para se autenticar perante o servidor durante o processo de estabelecimento do túnel SSL/TLS;

1.5.32.    Autenticação do cliente por parte do servidor, através da solicitação e verificação da validade do certificado digital fornecido pelo cliente durante o processo de estabelecimento do túnel SSL/TLS;

1.5.33.    Autenticação do servidor por parte do cliente, através da verificação da validade do certificado digital fornecido pelo lado servidor durante o processo de estabelecimento do túnel SSL/TLS;

1.5.34.    Ambas as autenticações acima mencionadas ocorrendo de forma simultânea;

1.5.35.    Possuir recursos de monitoração HTTP/HTTPS com autenticação NTLM embutida, que permita verificar se o HTTP/HTTPS está operando assim como a plataforma de autenticação;

1.5.36.    Deve ser possível a utilização da modalidade de SSL Forward Proxy;

1.5.37.    Possuir recurso de SCTP (Stream Control Transmission Protocol);

1.5.38.    Ser capaz de realizar compressão da resposta do servidor, para reduzir a quantidade de informações que são entregues ao cliente quando ele realiza requisições HTTP/HTTPS;

1.5.39.    Ser capaz de escolher qual tipo de compressão será habilitada (deflate, gzip1 a gzip9);

1.5.40.    Ser capaz de definir quais tipos de objetos específicos sofrerão compressão;

1.5.41.    Deve possuir suporte ao recurso de aceleração SSL, utilizando os certificados digitais instalados na solução e encaminhando as requisições HTTP sem criptografia para os servidores;

1.5.42.    Deve possuir recursos relacionados à criptografia com o objetivo de otimizar a performance das aplicações. Dentre esses recursos, deve ser possível configurar os seguintes parâmetros:

1.5.42.1.         OCSP (Online Certificate Status Protocol) Stapling;

1.5.42.2.         Perfect Forward Secrecy;

1.5.42.3.         SSL session cache Timeout;

1.5.42.4.         Session Ticket;

1.5.42.5.         Dynamic Record Sizing;

1.5.42.6.         ALPN (Application Layer Protocol Negotiation);

1.5.43.    Deve possuir capacidade de importação dos certificados e chaves criptográficas, para transações seguras entre cliente/servidor, podendo assim operar em modo ?man in the middle?, ou seja, descriptografar, otimizar e re-criptografar o tráfego SSL sem comprometer a segurança da conexão SSL estabelecida previamente entre cliente/servidor. Caso haja falha na leitura da conexão SSL, esta deverá, se assim definido, prosseguir em regime de passthrough;

1.5.44.    Deve ser capaz de recriptografar a requisição em SSL ao enviá-la para o servidor, onde as demais otimizações são realizadas em ambiente totalmente criptografado;

1.5.45.    Ser capaz de otimizar a infraestrutura SSL/TLS, provendo visibilidade para variados dispositivos de segurança sobre o tráfego SSL/TLS;

1.5.46.    Ser capaz de centralizar as operações de criptografia/descriptografia, provendo a mais moderna tecnologia de encriptação SSL/TLS com grande variedade de cifras e protocolos;

1.5.47.    Ser capaz de possibilitar a redução da latência de inspeção SSL atual que é realizada em diversos dispositivos de segurança, centralizando essa operação de criptografia/descriptografia num dispositivo único;

1.5.48.    Ser capaz de prover visibilidade SSL/TLS tanto para o tráfego de entrada (Datacenter) quanto para o tráfego de saída (usuários), permitindo que uma solução em appliance centralizada seja responsável por orquestrar e distribuir dinamicamente o tráfego entre os dispositivos de segurança na camada de inspeção;

1.5.49.    Ser capaz de permitir que múltiplos dispositivos de segurança de diversos fabricantes tenham visibilidade tanto do tráfego de saída quanto entrada, fazendo que eles continuem realizando suas inspeções procurando por malwares e exfiltração de dados;

1.5.50.    Ser capaz de evitar a topologia tradicional de "ligação em cascata" dos dispositivos de segurança, em que o tráfego precisa necessariamente passar por todos os dispositivos de segurança sempre;

1.5.51.    Ser capaz de trabalhar com direcionamento de tráfego inteligente e dinâmico baseado em políticas de contexto, permitindo o gerenciamento de fluxo inteligente entre os dispositivos de segurança e garantindo a disponibilidade de acesso;

1.5.52.    Ser capaz de utilizar os dispositivos de segurança com maior eficiência através da política de contextualização de tráfego;

1.5.53.    Ser capaz de monitorar cada dispositivo de segurança independentemente, permitindo realizar o bypass ou não caso ele esteja com problemas;

1.5.54.    Possuir recurso para permitir a escalabilidade independente de cada dispositivo de segurança. Caso seja necessário inserir mais um dispositivo de segurança na zona de inspeção, a solução deve ser configurada para redistribuir o tráfego considerando os dispositivos ativos;

1.5.55.    Possuir recursos para permitir escalar os dispositivos de segurança com alta disponibilidade, usando a monitoração de saúde para identificar o estado de cada dispositivo de segurança;

1.5.56.    Ser capaz de tomar decisões inteligentes de acordo com o contexto de tráfego, enviando o tráfego somente para a cadeia de dispositivos de segurança que precisam visualizar esse contexto de tráfego;

1.5.57.    Ser capaz de realizar manipulação de tráfego com base em seu conteúdo;

1.5.58.    Ser capaz de realizar descriptografia de SSL/TLS independente da porta TCP;

1.5.59.    Ser capaz de suportar, pelo menos, as seguintes cifras e protocolos:

1.5.59.1.         TLS1;

1.5.59.2.         TLS1.1;

1.5.59.3.         TLS1.2;

1.5.59.4.         SHA;

1.5.59.5.         SHA2;

1.5.59.6.         AES-GCM;

1.5.59.7.         AES;

1.5.59.8.         Ser capaz de suportar ECDHE, RSA e DHE com suporte a Forward Secrecy;

1.5.59.9.         Ser capaz de implementar SSL offload, ou seja, realizar a encriptação e decriptação das sessões SSL;

1.5.59.10.     Ser capaz de dar opção de ações caso o certificado original do servidor expire;

1.5.59.11.     Ser capaz de dar a opção de ações caso o certificado original do servidor não seja confiável;

1.5.59.12.     Ser capaz de dar a opção de fazer o bypass do tráfego caso falhe o TLS handshake;

1.5.60.    Possuir recursos para suportar, no mínimo, as seguintes formas de implementação na rede da CONTRATANTE:

1.5.60.1.         Outbound camada 2;

1.5.60.2.         Outbound camada 3 (proxy transparente);

1.5.60.3.         Outbound camada 3 (proxy explicito);

1.5.60.4.         Inbound camada 3 (proxy reverso);

1.5.60.5.         Inbound camada 2;

1.5.61.    Possuir recursos para suportar o envio de tráfego para dispositivos em linha em camada 2 ou 3, conectando-se diretamente ao dispositivo de descriptografia e através de um switch. Desacoplando o dispositivo de segurança da interface física, porta ou VLAN;

1.5.62.    Ser capaz de realizar Dynamic Domain Bypass;

1.5.63.    Ser capaz de fazer bypass da inspeção com base em categoria ou URL;

1.5.64.    Possuir recurso para realizar o envio de tráfego ICAP para dispositivos;

1.5.65.    Ser capaz de suportar proxy web de diversos fabricantes dentro da camada de inspeção;

1.5.66.    Ser capaz de suportar dispositivos de segurança de diversos fabricantes;

1.5.67.    Possuir recursos para integração com Network HSM;

1.5.68.    Possuir recursos de proteção contra Syn flood;

1.5.69.    Ser capaz de proteger contra os seguintes ataques:

1.5.69.1.         Cross Site Request Forgery (CSRF);

1.5.69.2.         XML bombs/DoS;

1.5.69.3.         Cross-Site Scripting (XSS);

1.5.69.4.         Server Side Request Forgery (SSRF);

1.5.69.5.         SQL Injection;

1.5.69.6.         Buffer Overflow;

1.5.69.7.         Directory Traversal;

1.5.69.8.         Forceful Browsing;

1.5.69.9.         Web Scraping;

1.5.69.10.     Web server software and operating system attacks;

1.5.69.11.     Web Services (XML) attacks;

1.5.69.12.     Manipulação de campos escondidos;

1.5.69.13.     Manipulação de cookies;

1.5.69.14.     HTTP Denial of Service;

1.5.69.15.     HTTP Request Smuggling;

1.5.69.16.     HTTP Response Splitting;

1.5.69.17.     Acesso por Força Bruta;

1.5.69.18.     Ameaças Web AJAX/JSON;

1.5.69.19.     DoS e DDoS camada 7 (OSI);

1.5.69.20.     Parameter tampering;

1.5.69.21.     Cookie poisoning;

1.5.69.22.     Roubo de sessão através de manipulação de cookies;

1.5.69.23.     Sequestro de sessão;

1.5.69.24.     Força bruta no browser;

1.5.69.25.     Malicious Robots;

1.5.69.26.     Remote File Inclusion Attacks;

1.5.69.27.     A Identificação de ataques deve ser baseada em:

1.5.69.28.     Assinaturas;

1.5.69.29.     Regras;

1.5.69.30.     Perfis de utilização;

1.5.69.31.     Deve ser capaz de utilizar, pelo menos, os seguintes critérios de decisão para bloquear ou gerar alerta, sendo que uma política pode conter um ou mais critérios simultaneamente:

1.5.69.32.     Conteúdo da cookie;

1.5.69.33.     Conteúdo do cabeçalho;

1.5.69.34.     Conteúdo do payload;

1.5.69.35.     Código de response;

1.5.69.36.     Hostname;

1.5.69.37.     Método HTTP;

1.5.69.38.     Assinatura de ataque;

1.5.69.39.     IPs de atacantes conhecidos;

1.5.69.40.     Parâmetro;

1.5.69.41.     User-agent (navegador);

1.5.69.42.     Número de ocorrências em determinado intervalo de tempo;

1.5.69.43.     Possuir recursos para proteger contra ataques, disponibilizando acesso a base de assinaturas e com atualizações periódicas até o fim do contrato;

1.5.69.44.     Ser capaz de realizar a checagem de consistência de formulários;

1.5.69.45.     Deve ser capaz de realizar restrições de acesso para endereços IP de origem de acordo com o País, de forma que determinado(s) paíse(s) de origem seja(m) bloqueado(s).

1.5.70.    Deve ser capaz de limitar a quantidade de requisições e de conexões por endereço IP de origem em cada VIP (Virtual IP) de destino;

1.5.71.    Deve ser capaz de criar listas de exceção para liberação de endereços IP de origem, faixa de sub-rede e geolocalização que tenham gerado eventos que caracterizem ataque;

1.5.72.    Deve ser capaz de constituir de forma automática uma blacklist com endereços IP de origem que ultrapasse o limite estabelecido em um determinado período;

1.5.73.    Possuir recursos para especificar quais tipos de arquivo serão bloqueados em uma política específica;

1.5.74.    Deve ser possível a configuração de páginas de login para aplicações do tipo AJAX/JSON de forma automática ou manual como forma de proteção de acesso à aplicação;

1.5.75.    Deve possuir proteção contra ataques conhecidos dentro dos protocolos HTTP e HTTPS (modelo de segurança negativo) e também mecanismos de defesa considerando o modelo positivo de segurança;

1.5.76.    Deve possuir mecanismo de aprendizado automatizado capaz de identificar os conteúdos das aplicações, com pelo menos:

1.5.76.1.         URLs;

1.5.76.2.         Parâmetros URLs;

1.5.76.3.         Campos de formulários, o que se espera de cada campo (tipo de dado, tamanho de caracteres, se é um campo obrigatório);

1.5.76.4.         Cookies;

1.5.76.5.         Ações SOAP;

1.5.76.6.         Elementos XML;

1.5.76.7.         Identificar e criar perfil de utilização dos aplicativos, inclusive desenvolvidos em Javascript, CGI, ASP e PHP;

1.5.77.    Deve ser capaz de realizar mitigação de DDoS em camada 7 baseado em análise comportamental, usando o aprendizado;

1.5.78.    Deve ser capaz de aprender a comportamento natural de uma aplicação e aplicar mitigação a ataques de DDoS em camada 7 que fujam a esse padrão, com base no aprendizado;

1.5.79.    Não deve haver a necessidade de intervenção de usuário para configurar thresholds DoS pois esses valores devem ser autoajustáveis e adaptativos de acordo com mudanças;

1.5.80.    Deve ser capaz de detectar DDoS através de análise de dados recebidos e machine learning, o estado do servidor que hospeda a aplicação e o comportamento natural do tráfego em condições normais ou não;

1.5.81.    Deve ser capaz de realizar bloqueio de ataques DoS na camada 7 (OSI), possuindo também a opção de apenas registrar o ataque, sem tomar nenhuma ação de bloqueio;

1.5.82.    Possuir, pelo menos, os seguintes métodos de detecção para ataques de DDoS:

1.5.83.    Quantidade de requisições por segundo recebidos de um IP de origem;

1.5.84.    Quantidade de requisições por segundo recebidos para uma URL específica;

1.5.85.    Quantidade máxima de transações por segundo (TPS) de um IP de origem;

1.5.86.    Aumento percentual na quantidade de transações por segundo (TPS);

1.5.87.    Aumento no tempo de resposta (latência da aplicação) de determinada URL da aplicação;

1.5.88.    Detecção através de código executado no cliente com o objetivo de detectar interação humana ou comportamento de robôs (bots);

1.5.89.    Possuir, pelo menos, os recursos para mitigação a ataques em camada 7:

1.5.89.1.         CAPTCHA para aqueles que ultrapassarem determinados limites;

1.5.89.2.         Mecanismo proativo de defesa contra bot através de Javascript ou injeção de desafio no browser do cliente;

1.5.89.3.         Bloqueio das requisições de determinado IP ou País de origem.

1.5.90.    Possuir, pelo menos, os seguintes recursos para detecção de ataques de força bruta:

1.5.90.1.         Quantidade de tentativas malsucedidas de login de acesso;

1.5.90.2.         Utilização de ferramenta automatizada para login;

1.5.90.3.         Quantidade de requisições para o mesmo recurso;

1.5.90.4.         Possuir recurso para automaticamente capturar tráfego no formato TCP Dump relativos aos ataques DoS L7, Web Scraping e força bruta permitindo uma análise mais aprofundada por parte do administrador;

1.5.90.5.         Dispor de base de inteligência de ameaças relacionadas a campanhas e ataques a aplicações web, compatíveis com a solução de proteção de aplicações Web e API, correlacionando diversas fontes de inteligência e ameaças encontradas diariamente no mundo real;

1.5.90.6.         Deve ter um sistema de reputação de endereços IP públicos conhecidos como fontes de ataques divididos em pelo menos os seguintes grupos: Windows Exploits, Web Attacks, Botnets, Scanners, Denial of Service, Reputation, Phishing, Proxy;

1.5.90.7.         Tal sistema deve ser atualizado automaticamente;

1.5.90.8.         Possuir recursos para detectar e mitigar ataques força bruta em páginas de login;

1.5.90.9.         Deve ser capaz de encriptar dados e credenciais na camada de aplicação, sem ter a necessidade de atualizar a aplicação. Essas informações devem ser encriptadas para proteger o login e as credenciais dos usuários e com isso os dados da aplicação;

1.5.90.10.     Deve ser capaz de proteger informações sensíveis e confidenciais da interceptação por terceiros, através da criptografia de dados quando ainda no browser do usuário. Deve proteger esses dados criptografados de malwares e keyloggers;

1.5.90.11.     Possuir recursos para ofuscar o nome de um parâmetro sensível da aplicação em caracteres randômicos. Esse nome de parâmetro deve ser mudado constantemente pela ferramenta para dificultar ataques direcionados;

1.5.90.12.     Possuir recursos para ao detectar uma condição de DDoS, assinaturas dinâmicas deverão ser automaticamente criadas e implementadas em tempo real para proteção da aplicação;

1.5.90.13.     Ser capaz de realizar o bloqueio de bots que acessam a aplicação através de detecção automática, não dependendo de cadastros manuais;

1.5.90.14.     Robôs conhecidos do mercado, como Google, Yahoo e Microsoft Bing deverão ser liberados por padrão;

1.5.90.15.     Possuir recursos para realizar o bloqueio de determinados endereços IPs que ultrapassarem um número máximo de violações por minuto;

1.5.90.16.     O período de bloqueio deverá ser configurável e durante este período todas as requisições do cliente serão bloqueadas automaticamente;

1.5.90.17.     Ser capaz de permitir o cadastro de robôs que podem acessar a aplicação;

1.5.90.18.     Ser capaz de proteger contra-ataques automatizados, incluindo bots e web scraping, identificando comportamento não humano, navegadores operados por scripts ou qualquer outra forma que não operados por humanos;

1.5.91.    Ser capaz de proteger o protocolo FTP com pelo menos os seguintes métodos:

1.5.91.1.         Determinar os comandos FTP permitidos;

1.5.91.2.         Requests FTP anônimos;

1.5.92.    Ser capaz de identificar e armazenar o ataque acontecido com detalhes, com as seguintes informações:

1.5.92.1.         Endereços IP que originaram os ataques;

1.5.92.2.         Horário do ataque;

1.5.92.3.         Nome do ataque;

1.5.92.4.         Qual campo foi atacado;

1.5.92.5.         Quantas vezes esse ataque foi realizado;

1.5.92.6.         Possuir recurso para implementar proteção ao JSON (JavaScript Object Notation);

1.5.92.7.         Possuir recurso para implementar firewall XML integrado, realizando, no mínimo:

1.5.92.8.         Filtro de funções XML;

1.5.92.9.         Validação de funções XML específicas da aplicação;

1.5.92.10.     Possuir recurso para implementar a proteção do tráfego de protocolo WebSocket;

1.5.93.    Possuir recurso para implementar a segurança de web services, através dos seguintes métodos:

1.5.93.1.         Criptografar/Decriptografar partes das mensagens SOAP;

1.5.93.2.         Assinar digitalmente partes das mensagens SOAP;

1.5.93.3.         Verificação de partes das mensagens SOAP;

1.5.93.4.         Deve possuir linguagem de programação open-source que permita a manipulação do tráfego de entrada e saída, viabilizando assim a alteração de parâmetros no cabeçalho e no corpo das mensagens;

1.5.93.5.         Ser capaz de permitir a importação de pacotes, garantindo assim que a agilidade e flexibilidade no compartilhamento dos scripts;

1.5.93.6.         Possuir recurso para a criação de políticas através de interface gráfica web para manipulação de tráfego através de lógica para pelo menos os seguintes operadores: GEOIP, http-basic-auth, http-cookie, http-header, http-host, http-method, http-referer, http-set-cookie, http-status, http-uri e http-version;

1.5.94.    Deve ser possível tomar as seguintes ações através dessas políticas:

1.5.94.1.         Bloqueio de tráfego;

1.5.94.2.         Reescrita e manipulação de URL;

1.5.94.3.         Registro de tráfego (log);

1.5.94.4.         Adição de informação no cabeçalho HTTP;

1.5.94.5.         Redirecionamento do tráfego para um membro específico;

1.5.94.6.         Selecionar uma política específica para aplicação Web;

1.5.94.7.         Possuir recursos para analisar a performance de aplicações web;

1.5.94.8.         Ser capaz de prover, pelo menos, as seguintes métricas:

1.5.94.9.         Latência da resposta do servidor;

1.5.94.10.     Throughput de requisições;

1.5.94.11.     Respostas e sessões;

1.5.94.12.     Transações por segundo (TPS);

1.5.95.    Possuir recursos para suportar, pelo menos, os seguintes tipos de requisição DNS:

1.5.95.1.         HINFO;

1.5.95.2.         SOA;

1.5.95.3.         PTR;

1.5.95.4.         DNAME;

1.5.95.5.         A;

1.5.95.6.         AAAA;

1.5.95.7.         CNAME;

1.5.95.8.         MX;

1.5.95.9.         TXT;

1.5.95.10.     NS;

1.5.95.11.     SRV;

1.5.95.12.     Ser capaz de realizar IP Anycast;

1.5.95.13.     A Alta disponibilidade não deve depender de BGP ou outro protocolo de roteamento;

1.5.95.14.     Ser capaz de operar em modo inline com a estrutura de DNS existente e transparente sem requerer grandes mudanças na infraestrutura;

1.5.95.15.     Ser capaz de realizar DNSSec, independente da estrutura dos servidores DNS em uso;

1.5.96.    Ser capaz de realizar comunicação segura entre os DNS servers e utilizar chave criptográfica TSIG, utilizando, no mínimo, os padrões:

1.5.96.1.         HMAC MD5;

1.5.96.2.         HMAC SHA-1;

1.5.96.3.         HMAC SHA-256;

1.5.96.4.         Ser capaz de realizar alta disponibilidade baseada em respostas a requisições DNS.

1.5.97.    A resposta a requisições DNS deve conter apenas endereços que estejam disponíveis no momento, e balanceadas por usuário, de acordo com as políticas definidas;

1.5.98.    Ser capaz de ajustar quantos endereços são enviados em uma única resposta DNS;

1.5.98.1.         Ser capaz de operar, no mínimo, nas seguintes formas:

1.5.98.2.         Balanceando DNS Servers;

1.5.98.3.         DNS secundário, realizando o offload dos servidores de DNS;

1.5.98.4.         DNSSec;

1.5.98.5.         DNS cache;

1.5.98.6.         DNS autoritativo;

1.5.98.7.         DNS resolver;

1.5.99.    Ser capaz de servir as respostas às requisições onde o DNS é o autoritativo a partir da memória RAM;

1.5.100.    Ser capaz de realizar stateful inspection;

1.5.101.    Ser capaz de realizar proteções contra ataques DNS, no mínimo:

1.5.101.1.     Inspeção de protocolo;

1.5.101.2.     Cache Poisoning;

1.5.101.3.     Ataque ICMP;

1.5.101.4.     Validação de protocolo;

1.5.101.5.     Pacotes mal formados;

1.5.101.6.     Ataque thwarting teardrop;

1.5.101.7.     Reflexão DNS;

1.5.101.8.     UDP flood;

1.5.101.9.     Amplificação DNS;

1.5.102.    Ser capaz de realizar o controle de grupos de aplicações, e permitir que um usuário seja redirecionado para outro datacenter quando houver falha em qualquer das aplicações de um mesmo grupo;

1.5.103.    Possuir recursos para que a contingência seja automática, mas que o retorno seja manual;

1.5.104.    Ser capaz de responder as requisições DNS com base no país, continente e endereço IP da origem da requisição;

1.5.105.    Ser capaz de realizar Geolocalização por endereço IP;

1.5.106.    Ser capaz de realizar persistência da conexão do usuário entre aplicações ou data centers;

1.5.107.    Ser capaz de bloquear pacotes inválidos, incluindo:

1.5.107.1.     DNS malformed;

1.5.107.2.     Bad ICMP Frame;

1.5.107.3.     Bad ICMP Checksum;

1.5.107.4.     ICMP Frame too Large;

1.5.107.5.     Bad IGMP Frame;

1.5.107.6.     Bad IP TTL Value;

1.5.107.7.     Bad IP Version;

1.5.107.8.     Header Length Too Short;

1.5.107.9.     Bad Source;

1.5.107.10.  Bad IPV6 Hop Count;

1.5.107.11.  Bad IPV6 Version;

1.5.107.12.  Bad TCP Checksum;

1.5.107.13.  Bad TCP Flags;

1.5.107.14.  SYN && FIN Set;

1.5.107.15.  Bad UDP Checksum;

1.5.107.16.  ARP Flood;

1.5.107.17.  ICMPv4 Flood;

1.5.107.18.  ICMPv6 Flood;

1.5.107.19.  IGMP Flood;

1.5.107.20.  IGMP Fragment Flood;

1.5.107.21.  TCP RST Flood;

1.5.107.22.  TCP SYN ACK Flood;

1.5.107.23.  TCP SYN Flood;

1.5.107.24.  UDP Flood;

1.5.107.25.  SIP ACK Method;

1.5.107.26.  SIP Malformed;

1.5.107.27.  Single Endpoint Flood;

1.5.107.28.  Single Endpoint Sweep

1.5.108.    Possuir o recurso para permitir o upload de arquivo de descrição OpenAPI, e bloquear as solicitações que não correspondam às definições do arquivo;

1.5.108.1.     Ser capaz de proteger APIs baseadas em OpenAPI 2.0;

1.5.108.2.     Ser capaz de proteger APIs baseadas em OpenAPI 3.0;

1.5.108.3.     Ser capaz de realizar as funções de API gateway:

1.5.108.4.     Verificação de chave API;

1.5.108.5.     Controle de acesso API;

1.5.108.6.     Controle de limite de taxa;

1.5.109.    Permitir definir usuários de API para restringir o acesso a APIs com base em chaves de API;

1.5.110.    Permitir a restrição baseada em endereçamento IP;

1.5.111.    Deve ser capaz de proteger GraphQL APIs limitando a quantidade de queries dentro de uma requisição HTTP;

1.5.112.    Deve ser capaz de proteger GraphQL APIs com pelos menos os seguintes parâmetros: tamanho total, tamanho de cada parâmetro;

1.6.        Usuários e Perfis

1.6.1.  Deve ser possível a utilização de, pelo menos, bases de dados Active Directory, LDAP, Radius e TACACS+ para autenticação dos usuários;

1.6.2.  Ser capaz de realizar autenticação de múltiplos fatores, sendo possível a utilização de tokens de hardware ou software nesse contexto;

1.6.3.  Ser capaz de realizar o Single Sign-On (SSO) com, pelo menos, as seguintes funções:

1.6.4.  Realizar cache das credenciais do usuário e fornecer a credencial adequada para cada aplicação envolvida;

1.6.5.  Uma vez solicitadas e fornecidas as credenciais de acesso do usuário, ele deve estar autenticado automaticamente para as demais aplicações que exigem autenticação;

1.6.6.  Devera´ ser capaz de implementar Single Sign-On (SSO) mesmo quando conectado via modo ?Network?, quando o usuário chama o portal digitando o site diretamente no browser;

1.6.7.  Deve ser capaz de validar os recursos na máquina utilizada pelo usuário acessando a aplicação e, a depender do estado de cada recurso, deve ser possível configurar uma determinada ação;

1.6.8.  Deve ser capaz de avaliar os seguintes itens na máquina do usuário:

1.6.8.1.  Processos sendo executados;

1.6.8.2.  Presença de antivírus;

1.6.8.3.  Versão do antivírus instalado;

1.6.8.4.  Presença de Firewall de máquina;

1.6.8.5.  Versão do Sistema Operacional;

1.6.8.6.  Certificados digitais instalados;

1.6.9.  Deve ser capaz de definir o tempo de ociosidade até terminar a sessão de um usuário;

1.6.10.    Deve ser capaz de definir o tempo máximo de sessão de um usuário;

1.6.11.    Possuir recursos para definir número máximo de sessões para cada usuário;

1.6.12.    Deve possuir a flexibilidade para definir os recursos de NTP, DNS e WINS;

1.6.13.    Deve ser capaz de definir as funcionalidades a serem utilizadas em AAA;

1.6.14.    Deve ser capaz de encerrar a sessão após um determinado número de tentativas erradas de um usuário;

1.6.15.    Deve possuir recursos para possibilitar a troca de senha que esteja expirada para determinado usuário;

1.6.16.    Deve haver possibilidade de personalização visual da página de login/logout para determinados usuários e grupos de usuários;

1.6.17.    Deve possuir recursos para possibilitar a utilização de toda e qualquer variável de sessão do usuário para o Single Sign-On (SSO) de determinada aplicação;

1.6.18.    Possuir recursos para estabelecer o endereçamento IP a ser entregue para os clientes de VPN para o acesso à rede;

1.6.19.    Ser capaz de comprimir o tráfego de VPN cliente com a tecnologia GZIP;

1.6.20.    Possuir recursos para acesso remoto para usuários através de VPN SSL para Microsoft Windows, Linux, dispositivos baseados em MAC OSX, Android e iOS;

1.6.21.    Ser capaz de definir que todo o tráfego do cliente seja direcionado para o túnel VPN;

1.6.22.    Ser capaz de oferecer a possibilidade de controle de acessos através de ACLs estáticas e dinâmicas;

1.6.23.    Deve ser capaz de designar acesso a determinados recursos pelos devidos usuários ou grupos de usuários;

1.6.24.    Possuir recursos para que as aplicações internas da organização possam ser acessadas através de túnel de aplicações;

1.6.25.    Deve suportar acesso a serviços de terminais através de:

1.6.25.1.         Microsoft RDP;

1.6.25.2.         Citrix XenApp;

1.6.25.3.         Citrix XenDesktop;

2.             Item 2 - Solução de gerência da proteção do contexto das aplicações

2.1.        Características técnicas da solução de centralização das informações do contexto de acesso as aplicações:

2.1.1.  Deve ser capaz de gerenciar até 20 (vinte) agrupamentos da unidade de medida do Item 1: ?Soluções de balanceador de carga?.

2.1.2.  Deve ser capaz enviar, receber informações bem como gerenciar a solução de proteção do contexto das aplicações sendo utilizada em appliances físicos, virtuais e ambientes de nuvem;

2.1.3.  Possuir recursos para gerenciar ambientes de solução de proteção do contexto das aplicações no Datacenter local e no ambiente de nuvem;

2.1.4.  Deve ser capaz de gerenciar solução de proteção do contexto das aplicações com funcionalidades de segurança L3-L7;

2.1.5.  Possuir recursos para monitorar a saúde, desempenho e segurança das aplicações através de painéis de controle;

2.1.6.  Deve ser capaz de simplificar o gerenciamento, garantir a conformidade nas características necessárias para entregar, otimizar e garantir a segurança das aplicações de forma eficiente da solução de proteção do contexto das aplicações;

2.1.7.  Deve ser capaz de gerenciar e possuir dados analíticos das aplicações através de um painel;

2.1.8.  Não deve possuir limitações com relação ao máximo de aplicações suportadas, portanto a solução deve estar licenciada para o máximo de aplicações suportado para a solução de proteção do contexto das aplicações;

2.1.9.  Deve ser capaz de gerenciar centralmente licenças, políticas, certificados SSL, imagens de software e configurações da solução de proteção do contexto das aplicações;

2.1.10.    Deve ser capaz de gerenciar certificados gerados pelo Let´s encrypt;

2.1.11.    Possuir recursos para gerenciar os seguintes serviços do contexto das aplicações: distribuição de carga, mitigação de DDoS, Controle de Acesso, otimização de tráfego SSL/TLS, DNS, proteção de DNS, proteção das aplicações Web, proteção contra ataques de força bruta;

2.1.12.    Deve ser capaz de controlar o acesso dos usuários a solução através de base local de usuário e através de integração com Radius e LDAP;

2.1.13.    Possuir recursos para criação de perfis de acesso diferenciado a solução, esses perfis podem ser baseados em informações do Active Diretrory (AD), TACACS+, Radius e do LDAP, como por exemplo grupo;

2.1.14.    Deve possuir perfis de acesso pré-definidos e a possibilidade de criar perfis de acesso customizados para gerenciar, segmentado os usuários em, pelo menos: leitura, escrita;

2.1.15.    Deve ser capaz de gerenciar as licenças de forma centralizada;

2.1.16.    Possuir recursos para elaborar relatórios centralizados;

2.1.17.    Deve ser capaz de gerar alertas com relação a disponibilidade, segurança e performance das aplicações;

2.1.18.    Deve ser capaz de auxiliar no processo de troubleshooting de aplicações através de painel com informações que permitam drill-down para filtrar e identificar o problema;

2.1.19.    Para auxiliar no processo de troubleshooting de aplicações, a solução deve, no mínimo, prover: Métricas de sessões, throughput, latência e transações por segundo;

2.1.20.    Deve ser capaz de disponibilizar painéis diferentes para cada equipe, com no mínimo TRÊS níveis de visualização;

2.1.21.    Deve ser capaz de realizar e agendar a execução de configuração, backup e restauração da solução de proteção do contexto das aplicações;

2.1.22.    Deve possuir catálogo de aplicações no modelo self-service para permitir o rápido deploy e replicação de aplicações;

2.1.23.    Possuir recursos para que o acesso ao catálogo de aplicações seja controlado por usuário e grupo;

2.1.24.    Deve ser capaz de garantir consistência do contexto de proteção das aplicações, não importando onde a aplicação residir (nuvem ou datacenter);

2.1.25.    Possuir recursos para automatizar o deploy de aplicações;

2.1.26.    Possuir recursos para recebimento dos logs seja realizado em servidores específicos para essa finalidade;

2.1.27.    Deve ser capaz de ver e comparar políticas de proteção do contexto das aplicações;

2.1.28.    Deve ser capaz de correlacionar eventos de segurança entre os dispositivos sendo gerenciados;

2.1.29.    Deve ser capaz de implementar e realizar roll-back de políticas de distribuição de carga entre Sites;

2.1.30.    Deve ser capaz de visualizar estatísticas de DNS em tempo real e históricos;

2.1.31.    Deve ser capaz de utilizar APIs para configurar a solução de centralização das informações do contexto de acesso as aplicações;

2.1.32.    Deve ser capaz de restringir o acesso a uma única aplicação, assim um grupo ou pessoa somente conseguirá realizar alterações na solução de proteção do contexto de uma aplicação;

2.1.33.    Deve ser capaz de realizar análise pro-ativa, indicando como corrigir, da solução de proteção do contexto das aplicações, considerando, pelo menos:

2.1.33.1.         Vulnerabilidades existentes

2.1.33.2.         Espaço em disco

2.1.33.3.         Erros de configuração;

2.1.34.    Deve ser capaz de gerar relatórios de todos os eventos de segurança nos formatos PDF, HTML ou CSV;

2.1.35.    Possuir relatórios nativos que podem ser editados e reaproveitados para outros relatórios;

2.1.36.    Deve possuir modelos prontos de relatórios e ter a opção de criar relatórios personalizados;

2.1.37.    Possuir recursos para agendar relatórios de forma manual ou automática em intervalos diários, semanais ou mensais;

2.1.38.    Os relatórios e dashboards devem ser criados exclusivamente via interface gráfica sem o requisito de criação de scripts;

2.1.39.    Deve ser possível utilizar, pelo menos, os seguintes filtros para geração de relatório:

2.1.39.1.         IP de origem;

2.1.39.2.         Tipo de ataque;

2.1.39.3.         Usuário envolvido;

2.1.39.4.         Hora envolvida;

2.1.40.    Possuir recursos para oferecer a opção de visualizar as informações de forma tabular e correlacionada utilizando todos os filtros;

2.1.41.    Deve ser possível a escolha da informação nos relatórios, com a opção de selecionar os itens;

2.1.42.    Deve ser possível enviar automaticamente os relatórios via e-mail para os devidos destinatários de forma agendada;

2.1.43.    Deve ser possível a definição de permissão de usuários para as ações de edição nos modelos de relatório;

2.1.44.    Ser capaz de gerar relatórios em tempo real das aplicações, mostrando pelo menos os seguintes gráficos:

2.1.44.1.         Latência;

2.1.44.2.         Conexões para conjunto de servidores, servidores individuais;

2.1.44.3.         Por URL;

2.1.44.4.         Tempo de resposta da aplicação;

2.1.44.5.         Os seguintes filtros devem estar presentes na geração de gráficos:

2.1.44.6.         Servidores balanceados;

2.1.44.7.         URLs;

2.1.44.8.         Dispositivos de origem do cliente (user agent);

2.1.44.9.         Servidores virtuais;

2.1.44.10.     Países de origem, baseados em geolocalização (GEOIP);

2.1.45.    Ser capaz de fornecer relatórios consolidados de alertas/ataques com pelo menos os seguintes dados:

2.1.45.1.         Quantidade de eventos;

2.1.45.2.         IP e porta de origem;

2.1.45.3.         IP e porta de destino;

2.1.45.4.         País de origem;

2.1.45.5.         Tipo do evento (Assinatura, Perfil, Firewall, Política Customizada etc.);

2.1.45.6.         Host Header requisitado;

2.1.45.7.         Aplicação afetada;

2.1.45.8.         Violações;

2.1.45.9.         Utilização de CPU, memória RAM e espaço em disco;

2.1.45.10.     Data e horário do evento;

2.1.45.11.     Resumo geral com as políticas ativas, ataques, anomalias e estatísticas de tráfego;

2.1.45.12.     Detalhamento dos ataques com determinação de endereço de IP origem, destino, porta destino, tipo do ataque, data e horário;

2.1.45.13.     Distribuição de violações de segurança que ocorrem em cada aplicação Web em relação a totalidade das aplicações Web;

2.1.45.14.     As dez origens de conexões mais bloqueadas, seus destinos e serviços;

2.1.45.15.     Os dez ataques à segurança mais detectados pelo WAF e determinação das suas principais fontes e os destinos;

2.1.45.16.     Identificador único do alerta/ataque;

2.1.45.17.     Severidade;

2.1.45.18.     Descrição do alerta/ataque; 

2.1.46.    Possuir recursos para gerar informações para permitir análises históricas e auxiliar nos processos de manutenções preventivas, de troubleshooting, de planejamento de capacidade e de análise da experiência dos usuários finais no acesso das aplicações;

2.1.47.    As informações coletadas deverão permitir a análise dos dados por aplicações, por URL?s, por clientes e por servidores, permitindo assim a identificação mais precisa dos eventuais ofensores;

2.1.48.    Ser capaz de gerar informações estatísticas de acesso identificando, para cada aplicação, os métodos de acesso HTTP (Get e Post), o tipo de sistema operacional utilizado pelos clientes, e os navegadores utilizados;

2.1.49.    A geração de informações históricas deverá permitir:

2.1.49.1.         O detalhamento do tempo de resposta total de carregamento de uma URL e ou página;

2.1.49.2.         Permitir a correlação de métricas de uso de rede com o comportamento das aplicações;

2.1.49.3.         Possuir recurso para a definição da quantidade de CPU e memória que será alocada para cada tipo de funcionalidade quando habilitado para mais de uma função (distribuição de carga, proteção de aplicações, etc);

2.1.49.4.         Possuir recurso para utilização de memória RAM como cache de objetos HTTP, para responder às requisições dos usuários sem utilizar recursos dos servidores;

2.1.49.5.         Possuir capacidade, no uso do recurso de cache, para definir quais tipos de objeto serão armazenados em cache e quais nunca devem ser cacheados;

2.1.49.6.         Ser capaz de ajustar quanta memória será utilizada para armazenar objetos quando recurso de cache estivem em uso;

2.1.49.7.         Possuir recursos para otimização do protocolo TCP nas conexões clientes e servidor;

2.1.49.8.         Deve ser capaz de colocar em fila as requisições TCP que excedam a capacidade de conexões do grupo de servidores ou de um servidor. As filas poderão ser configuradas considerando:

2.1.49.9.         O tempo máximo de permanência na fila;

2.1.49.10.     O tamanho máximo da fila;

2.1.49.11.     Possuir recursos para que o gerenciamento da solução seja realizado via interface gráfica utilizando HTTPS;

2.1.49.12.     Possuir recursos para que o gerenciamento da solução seja realizado via SSH;

2.1.49.13.     Possuir recursos para que os comandos de CLI sejam autocompletados;

2.1.49.14.     Possuir recursos para que seja possível reinicializar via interface gráfica;

2.1.49.15.     Possuir recursos para que seja possível reinicializar via linha de comando;

2.1.49.16.     Possuir recursos para que a configuração de endereço IP na interface de gerência seja feita de forma estática ou dinâmica (DHCP/BOOTP);

2.1.49.17.     Possuir recursos para que os arquivos de configuração e sistema operacional possam ser transferidos via SCP ou HTTPS para outros destinos;

2.1.49.18.     Ser capaz de definir os níveis de permissão dos usuários da gerência através de base RADIUS, TACACS+ e LDAP;

2.1.49.19.     Ser capaz de permitir via interface gráfica (GUI) a atualização do sistema operacional e a instalação de patches ou Hotfixes sem o uso da linha de comando;

2.1.49.20.     Ser capaz de permitir via interface gráfica (GUI) a escolha de qual partição será utilizada para inicialização do sistema;

2.1.49.21.     Ser capaz de permitir via linha de comando (CLI) a visualização do tráfego passante nas interfaces (bps e pps);

2.1.49.22.     Ser capaz de permitir realizar o rollback da imagem e das configurações do sistema;

2.1.49.23.     Possuir e fornecer MIBs compiláveis na plataforma de gerenciamento via SNMP;

2.1.49.24.     Deve ser possível a criação de MIBs customizadas para o monitoramento;

2.1.49.25.     Ser capaz de enviar mensagens de syslog para múltiplos servidores;

2.1.49.26.     Possuir recurso para monitoração via SNMP e possuir suporte a SNMPv1, SNMPv2c e SNMPV3;

2.1.49.27.     Possuir recurso para gerar traps SNMP;

2.1.50.    Possuir recurso para monitoração utilizando RMON através de, pelo menos, os seguintes grupos:

2.1.50.1.         Statistics;

2.1.50.2.         History;

2.1.50.3.         Alarms

2.1.50.4.         Events;

2.1.51.    Ser capaz de armazenar os logs que são gerados internamente ao sistema ou enviar a um servidor externo;

2.1.52.    Ser capaz de implementar Debugging através da CLI via console e SSH;

2.1.53.    Ser capaz de realizar a monitoração de estado de saúde de servidores, serviços e links de conexão a provedor de serviço, garantindo a disponibilidade do serviço oferecido;

2.1.54.    Ser capaz de gerar estatísticas sobre consultas de DNS por:

2.1.55.    Aplicação;

2.1.56.    Nome da query;

2.1.57.    Tipo da query;

2.1.58.    Endereço IP do cliente;

2.1.59.    Deve ser capaz de gerar relatório identificando atividades de um usuário dentro da solução de proteção do contexto das aplicações, indicando, pelo menos:

2.1.59.1.         A localização geográfica;

2.1.59.2.         Total de sessões;

2.1.59.3.         Total de sessões negadas;

2.1.59.4.         Duração total de sessões;

2.1.59.5.         Falhas na autenticação;

2.1.59.6.         Dispositivos utilizados pelo usuário ao realizar login;

2.1.59.7.         Aplicações mais acessadas;

2.1.59.8.         URLs mais acessadas;

2.1.59.9.         Tentativas falhas de login e motivos das falhas;

2.1.60.    Deve ser capaz de gerar relatório identificando como uma aplicação foi acessada dentro da solução de proteção do contexto das aplicações, indicando, pelo menos:

2.1.60.1.         Histórico de acesso;

2.1.60.2.         Usuários que mais acessaram;

2.1.60.3.         Localização geográfica dos usuários que a acessaram;

2.1.60.4.         Deve ser capaz de gerar relatório sobre os acessos ao DNS, contendo pelo menos:

2.1.60.5.         Quantidade total de requisições;

2.1.60.6.         Quantidade total de requisições ao DNS autoritativo;

2.1.60.7.         Quantidade total de requisições ao DNS recursivo;

2.1.60.8.         Quantidade de ataques ao DNS;

2.1.60.9.         Tipos de respostas DNS realizadas;

2.1.60.10.     Quantidade de requisições por países;

2.1.60.11.     Quantidade de requisições por segundo;

2.1.60.12.     URL mais atacadas;

2.1.60.13.     Maiores atacantes;

3.             Item 3   Serviços de instalação e configuração

3.1.        A Contratada deverá providenciar um profissional com função de Gerente de Projetos para garantir o comprometimento e dedicação da Contratada e os interesses da Contratante em relação aos objetivos do projeto para:

3.1.1.  Coordenar e acompanhar o projeto em conjunto da Contratante;

3.1.2.  Estabelecer relacionamento da equipe do projeto com as áreas funcionais;

3.1.3.  Participar das reuniões de revisão do projeto;

3.1.4.  Participar ativamente nas avaliações de resultados;

3.1.5.  Participar da elaboração dos planos;

3.1.6.  Participar na elaboração de documentos finais;

3.1.7.  Identificar eventuais problemas críticos e a necessidade de recursos adicionais;

3.1.8.  Gerenciar possíveis mudanças de escopo durante a fase de planejamento.

3.1.9.  Durante a fase de planejamento:

3.1.9.1.  Validar objetivos e premissas do Projeto com equipe designada pela Contratante;

3.1.9.2.  Validar e homologar o escopo do Projeto com equipe designada pela Contratante;

3.1.9.3.  Efetuar o levantamento de informações sobre o ambiente atual, em vista do conjunto de informações apresentado nesta especificação técnica;

3.1.9.4.  Efetuar o gerenciamento de mudanças, contemplando análise de riscos de implementação do sistema;

3.1.9.5.  Apresentar os riscos envolvidos na migração para a nova solução a ser implantada.

3.1.9.6.  Definir os parâmetros de configuração básicos e avançados a serem implementados;

3.1.9.7.  Apresentar a topologia de rede a ser implementada;

3.1.9.8.  Apresentar o cronograma do projeto com os prazos e responsabilidades;

3.1.9.9.  Definição e confecção de documentação da topologia Física e Logica para os recursos a serem configurados na solução conforme definidos em reunião;

3.1.10.    Durante a fase de implementação:

3.1.10.1.         A instalação consiste no posicionamento da solução contratada em plena operação, de acordo com o que está descrito nesta especificação técnica, no Edital e seus Anexos e em perfeitas condições de funcionamento e deve contemplar, no mínimo, os seguintes itens:

3.1.10.2.         A Contratada deverá efetuar a instalação da solução na infraestrutura indicada pelo Contratante, e a configuração realizada deverá estar em conformidade com as recomendações do fabricante;

3.1.10.3.         A instalação física (se aplicável) e lógica da solução, incluindo todos os componentes, acessórios e cabos de conexão, sendo realizada pela Contratada, com acompanhamento de uma equipe destacada pela Contratante.

3.1.10.4.         Deverão ser realizados por conta da Contratada o armazenamento, a embalagem, o transporte, a entrega e a instalação de todo e qualquer item do objeto do edital, de tal maneira que a Contratada será responsável pela remessa de todos os equipamentos para os endereços informados no Edital, nos quais a solução de segurança será efetivamente implantada.

3.1.10.5.         Aplicação das licenças necessárias à solução entregue;

3.1.10.6.         Atualização de softwares, firmwares e drivers que compõem a solução para a versão recomendada pelo fabricante;

3.1.10.7.         A Contratada deverá entregar a documentação final do ambiente configurado e instalado.

3.1.10.8.         A CONTRATADA deverá entregar os testes de validação da solução, incluindo conectividade, visibilidade e inspeção dos sistemas abordados;

3.1.10.9.         Todas as informações necessárias à implantação, como topologia de rede, VLANs e segmentações de rede, definição de sub-redes e endereçamento IP, portas de Switches, o agrupamento das unidades da solução, sistemas protegidos pela solução e outras informações necessárias à perfeita configuração, interligação e funcionamento da solução serão fornecidas pelo Contratante;

3.1.10.10.     A instalação, configuração e testes do equipamento deverão ser feitos com o acompanhamento de técnicos da CONTRATANTE, visando o repasse de conhecimento e observados os padrões de gerenciamento de manutenção e segurança da Contratante;

3.1.10.11.     A solução, deverá ser entregue com todas os recursos de software e licenciamento necessários ao seu pleno funcionamento.

3.1.10.12.     A contratada deverá providenciar um profissional certificado pelo fabricante da solução para garantir a conformidade da instalação e a configuração dos equipamentos e softwares que compõem a solução.

3.1.10.13.     Deverão ser configuradas as features de otimização que melhorem a performance de utilização das aplicações pelos usuários; facilitem a gestão de certificados; desonere a utilização dos servidores;

3.1.10.14.     Deverão ser habilitadas e configuradas as features de segurança com maturidade suficiente para proteger os dados e os acessos dos usuários aos sistemas;

3.1.10.15.     Disponibilizar portal da ferramenta que autentique o usuário e reúna ícones de acesso para um determinado conjunto de sistemas;

3.1.10.16.     Deverão ser criados usuários para fins de operação e usuários para fins de administração do sistema.

3.1.10.17.     Configuração de eventos que possam gerar alarmes e notificações de forma automatizada sendo enviadas via protocolos SNMP e/ou SMTP, de forma a serem integrados com outras soluções da Contratante.

4.             Item 4    Treinamento Oficial

4.1.        Características dos serviços de treinamento da solução de centralização das informações do contexto de acesso as aplicações:

4.1.1.   Trata-se do serviço de treinamento oficial do fabricante da solução, na modalidade de fornecimento de vouchers para treinamento, cujo a ementa cubra conceitos de configuração, operação, administração, gerência, otimização, resolução de problemas e gestão de todos os componentes da solução de forma que o(s) servidor(es) capacitado(s) possam colocar os equipamentos e softwares em produção, bem como planejar mudanças de configuração no ambiente.

4.1.2.  O treinamento deverá oferecer carga horária total de no mínimo 24 (vinte e quatro) horas;

4.1.3.  Serão aceitos apenas treinamentos nas modalidades presencial ou virtual ao vivo (EAD), em plataforma a ser aceita pela Contratada;

4.1.4.  Caso a Contratada opte pelo treinamento de forma virtual, a Contrante poderá realizar gravações das sessões para fins didáticos, sem distribuições externas;

4.1.5.  A Contratada deve prover capacitação técnica em turmas com no mínimo 5 (cinco) e no máximo 8 (oito) participantes.

4.1.6.  Se o treinamento for ofertado na modalidade EAD, deverá respeitar o limite de 4 (quatro) horas por dia.

4.1.7.  Se o treinamento for ofertado na modalidade presencial, deverá ser ministrado em local fornecido pela Contratada, de segunda a sexta-feira, das 8:00 às 12:00, das 14:00 às 18:00 ou das 8:00 às 18:00. (08:00 às 18:00), e deverá respeitar o limite de 8 (oito) horas por dia.

4.1.8.  As despesas decorrentes do serviço de treinamento (instrutores, confecção do material didático, licenciamento de plataforma de videoconferência etc.) serão de exclusiva responsabilidade da Contratada.

4.1.9.  O treinamento poderá ser composto de mais de 1(um) módulo, que deverão ser discriminados na proposta da licitante.

4.1.10.    A licitante proponente deverá entregar, na fase de habilitação, uma declaração afirmando que oferta o treinamento oficial do fabricante da solução e que a ementa e todo o material oferecido é aprovado pelo fabricante, bem como, indicar na proposta o calendário contendo as datas e as localidades de realização do Treinamento.

4.1.11.    A licitante deverá anexar a grade de treinamentos do fabricante, com a ementa do(s) curso(s), para comprovar que o(s) treinamento(s) ofertados atendem os requisitos indicados no item.

4.1.12.    É facultado à Contratante a realização de diligências e verificação da autenticidade da declaração e demais documentos comprobatórios.

4.1.13.    O Contratante poderá planejar e escolher qualquer das datas, ou períodos, dos eventos de capacitação no prazo de validade da ata de registro de preços, a contar da entrega do calendário.

4.1.14.    O treinamento deverá ser ministrado em data oportuna a ser informada à fiscalização após ou antes da instalação dos equipamentos, ficando a critério da administração e baseando-se no calendário a ser fornecido pela Contratada.

4.1.15.    É permitido à Contratada terceirizar o treinamento a outra que preste serviços de treinamento da solução ofertada, ou ao próprio fabricante, desde que mantidas as demais condições deste documento e permanecendo ela a única responsável pelo atendimento do contratado para todos os fins.

4.1.16.    O treinamento deverá ser ministrado por profissionais certificados pelo fabricante, cuja comprovação deverá ser encaminhada na assinatura do Contrato.

4.1.17.    A contratada deverá fornecer material didático individual que abranja todo o conteúdo do(s) curso(s). Todo o material didático oferecido pela Contratada para realização do treinamento oficial do fabricante deverá ser oficial do fabricante da solução, ser de primeiro uso, atualizado e poderá estar em inglês ou português.

4.1.18.    O treinamento deve ser ministrado em português do Brasil. O material do treinamento deve ser, preferencialmente, impresso e em português. Caso não exista material oficial do produto em língua portuguesa e impresso, será aceito material em inglês e na modalidade digital.

4.1.19.    O treinamento deverá ocorrer em centro especializado para este fim, com acesso ao laboratório prático virtual, fornecido pela contratada, para configuração e execução de exercícios práticos.

4.1.20.    No ambiente de treinamento, os servidores indicados pela Contratante devem ter acesso em ambiente de laboratório a todos os produtos ofertados (ou similares) para realização da capacitação.

4.1.21.    O certificado de conclusão do curso deverá ser emitido pelo fabricante ou pela empresa a ser contratada, ou ainda pela responsável legal pelo treinamento se terceirizado.

4.1.22.    A ausência do servidor ao treinamento é de responsabilidade do Tribunal, cabendo a contratada informar no certificado a carga horária e assiduidade do servidor.

4.1.23.    A Contratada deverá aplicar o Formulário de Satisfação. No Formulário, será utilizada escala de até 5 (cinco) pontos para o treinamento. No mínimo 70% dos participantes deverão atribuir grau igual ou superior a 3 (três), para o tópico avaliado ser considerado proveitoso.

4.1.24.    O resultado da Avaliação de Instrutor/Tutor será utilizado como critério de aceitação do treinamento oficial do fabricante, devendo ser considerado pela amostra de participantes como ?proveitoso? para no mínimo 70% dos tópicos avaliados;

4.1.25.    Caso o resultado da Avaliação de Instrutor/Tutor seja considerado ?não proveitoso?, o treinamento oficial do fabricante fornecido será considerado não aceito;

4.1.26.    Na hipótese de não aceitação, a CONTRATADA deve oferecer outro treinamento oficial do fabricante, com a mesma carga horária, com outro instrutor, sem qualquer ônus para a Contratante:

4.1.27.    Na hipótese de o resultado do segundo treinamento oficial do fabricante ser ?não proveitoso?, o objeto será considerado não aceito, aplicando-se as sanções previstas contratualmente.

5.             Item 5   Horas de serviços especializados

5.1.        Características dos serviços de consultoria especializada:

5.1.1.  A Contratante poderá solicitar a ativação de novas funcionalidades e/ou escalar funcionalidades já implantadas através da contratação de Horas de Consultoria Especializada;

5.1.2.  A descrição das atividades a serem desempenhadas nas horas contratadas devem ser estabelecidas previamente ao início de qualquer atividade de implantação. O descritivo das funcionalidades que serão abordadas bem como a quantidade de sistemas envolvidos deve ser estabelecido em comum acordo entre as partes;

5.1.3.  A contratação dos serviços deve ser feita em blocos de horas, onde cada bloco caracteriza uma quantidade de horas a ser previamente designado;

5.1.4.  A quantidade de horas contratadas deve ser acordada entre as partes de forma a assegurar que as funcionalidades e atividades envolvidas sejam devidamente contempladas pelo objeto contratado;

5.1.5.  As novas funcionalidades ativadas não podem impactar de maneira alguma o pleno funcionamento dos sistemas que já estão em operação na solução, bem como aqueles que ainda não estão inseridos;

5.1.6.  Deverá ser elaborado um cronograma de implementação contendo todas as etapas da entrega, detalhando todo o Objeto da implantação e deverá ser validado pelo Gestor da CONTRATANTE;

5.1.7.  A CONTRATADA deve apresentar documento que descreva os benefícios e os pré-requisitos envolvidos em cada uma das funcionalidades que estarão envolvidas nas atividades.

5.1.8.  O início das atividades deve ocorrer em até 5 dias úteis após a aprovação do cronograma e documento de "Benefícios e pré-requisitos das Funcionalidades" pelo gestor da contratante;

5.1.9.  As atividades executadas devem ser acompanhadas por um profissional designado da CONTRATANTE;

5.1.10.    Todos os procedimentos devem ser realizados por profissional técnico comprovadamente certificado em nível profissional do fabricante;

5.1.11.    Poderão ser solicitadas as ativações/configurações de funcionalidades não descritas na Especificação Técnica deste edital, desde que não exijam um licenciamento ou módulo extras não especificados;

5.1.12.    A CONTRATADA poderá analisar a solução, sua condição atual de funcionamento, seus logs de sistema e sugerir ou não mudanças para melhor prática de utilização da solução. A equipe técnica do cliente decidirá sobre a aplicação ou não das recomendações apresentadas;

5.1.13.    A Contratante deverá emitir aceite das funcionalidades implantadas através da validação de testes de acesso aos sistemas envolvidos, bem como visualização do tráfego na solução e documentação de entrega fornecida pela CONTRATADA;

5.1.14.    Poderão ser utilizados blocos de horas para amenizar incidentes de alta complexidade e de alto impacto, de forma concorrente ao suporte já garantido pela contratada e pelo fabricante pela garantia da solução.