Objetivos do Documento
Objetivos do Documento
Este documento consiste em Estudos Preliminares necessários para assegurar a viabilidade da contratação, mensurar os riscos, determinar uma estratégia para a contratação, fornecer subsídios para a elaboração do Termo de Referência, bem como definir um plano de sustentação para a solução contratada.
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
Controle de Revisão
Data | Versão | Descrição | Autor |
05/09/2020 | 0.1 | Versão inicial SGPI | Joáz Praxedes |
08/09/2020 | 0.2 | Realização do Estudo | Xxxxxxxx Xxxxxxxxx |
27/10/2020 | 0.3 | Ajustes do ETP | Xxxx Xxxxxxxx |
03/11/2020 | 0.4 | Ajustes XXXX | Xxxxx Xxxxxxxx |
Processos administrativos relacionados
Nº | Assunto | Observação |
Aquisição de licenças de uso para Sistema de Virtualização e Gerência Centralizada de Infraestrutura Virtualizada. | Primeira contratação da solução VMware. | |
Contratação de suporte técnico e atualização para plataforma de virtualização. | Primeira renovação do suporte. | |
Registro de preços para aquisição de licenças e serviço de suporte técnico de produtos VMWARE. Ata PE-066/2017-B. COMPWIRE INFORMÁTICA S/A (Itens 2 ao 8). | Contratação das licenças atuais do ambiente de virtualização. | |
Contratação de serviço de suporte técnico e atualização de licenças para a plataforma de virtualização de servidores. | Renovação do suporte para as licenças atuais do ambiente de virtualização. |
1. Solução de TI a ser contratada/adquirida
1.1 Aquisição de solução com garantia de suporte e direito de atualização para virtualização de rede e segurança integrada com solução de gestão, análise e diagnóstico do ambiente virtual do TST.
2. Análise de Viabilidade da Contratação
2.1 Necessidade / Motivação da contratação
O TST utiliza para suportar suas aplicações uma estrutura de virtualização de servidores do fabricante VMware. Esse fabricante é o atual líder de mercado. Essa estrutura suporta tanto as aplicações legadas quanto as baseadas em micro serviços.
A exigência na velocidade de entrega e qualidade nas soluções de TI oferecidos pela SETIN cria a necessidade de novas arquiteturas de aplicações que são radicalmente diferentes das do passado. A maioria dos aplicativos são baseados no modelo de 3 camadas (web, servidor de aplicação e banco de dados), implantados no ambiente do TST em máquinas virtuais e desenvolvido em plataformas que estão em uso há anos. Essa arquitetura não é escalável e, para as demandas dos dias atuais, não consegue entregar sistemas com a velocidade e qualidades necessárias para atender as demandas do TST e da sociedade.
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
Para que seja possível atender à atual demanda e o rápido ritmo de desenvolvimento e implantação dos aplicativos, a SETIN desenvolveu uma arquitetura de aplicativos baseada em micros serviços, implantados em contêineres e desenvolvidos em plataformas nativas em nuvem. No TST, a plataforma de gerenciamento de containers é baseada em Kubernetes, o OKD, que é a versão da comunidade do OpenShift da Red Hat.
Embora essa nova arquitetura permita o desenvolvimento mais rápido de aplicativos, oferecendo maior qualidade, entrega contínua de novas funcionalidades com o mínimo de indisponibilidade com aplicativos desenvolvidos utilizando os preceitos de nuvem, os desafios de redes e segurança aumentaram. Desenvolvedores precisam deixar os aplicativos rodando tão rápido quanto possível, mas isso gera dificuldade para a infraestrutura acompanhar o ritmo com o qual os aplicativos são desenvolvidos, implementados e entregues. O problema cresce do fato de que a configuração tradicional de rede e segurança ainda é um processo manual, muitas vezes no hardware da infraestrutura. Adicionalmente, por causa dos serviços limitados em rede e segurança nas próprias plataformas nativas em nuvem, provisionar esses serviços na arquitetura tradicional das redes pode significar mais dias ou até semanas no ciclo de desenvolvimento, comprometendo os prazos de entrega e gerando gaps de segurança que podem ser aproveitados por invasores mal intencionados.
Essa nova arquitetura de aplicações demanda também balanceamento de carga baseado em IP, para, assim, garantir a máxima escalabilidade das aplicações com o crescimento dos containers. A estrutura atual do OKD oferece esse recurso, mas é limitado é não é capaz de lidar com aplicações fora dos containers e nem possui mecanismos de identificação de problemas de rede. De 2017 até 2020, ocorreram 6 eventos de indisponibilidade no ambiente do OKD/OpenShift e todos foram relacionados com a estrutura de rede virtual dessa solução.
O TST possui mais de 1200 máquinas virtuais e, no momento, mais de 200 containers que executam os sistemas informatizados e o crescimento é exponencial, especialmente os containers para a arquitetura de micro serviço. A atual visibilidade da rede para o ambiente virtual é limitada, não permitindo, por exemplo, avaliar a comunicação entre máquinas virtuais em um mesmo host, pois não trafegam na rede física (switches).
A gestão desse ambiente, considerando tanto a quantidade atual quanto o fato de já existir duas arquiteturas, legada e em containers, é complexa de se administrar manualmente, favorecendo falhas de segurança, demora na entrega de serviços e dificultando a análise de problemas de rede e a identificação na interdependência dos serviços. Ademais, ainda que as aplicações já estejam sendo desenvolvidas utilizando preceitos de nuvem, a infraestrutura de rede não está preparada para permitir que cargas de trabalho locais sejam direcionadas para nuvem pública e vice-versa.
Para sanar esses problemas, existe o conceito de rede virtual. Redes virtuais são para a rede o que o ambiente de virtualização tradicional é para servidores físicos. Ele é capaz de abstrair a camada
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
de rede física e criar uma topologia de rede virtual independe do hardware físico, conforme figura 2.1-1.
<.. image(Diagrama Descrição gerada automaticamente) removed ..>
Figura 2.1-1: Comparativo entre a estrutura de rede virtualizada com a estrutura de servidores virtualizados.
A virtualização de rede e segurança irá permitir que se atinja todo o potencial dos aplicativos nativos em nuvem e trazer muitos benefícios. Essa estrutura habilita redes de conexão avançadas e segurança através de qualquer estrutura de aplicativos, ajuda a agilizar a entrega de aplicativos ao remover gargalos nos fluxos de trabalho dos times de desenvolvimento e infraestrutura, habilita micros segmentação ao nível dos micros serviço e aumenta monitoramento e análise da rede.
Com a infraestrutura de rede virtualizada é possível habilitar micro segmentação para máquinas virtuais e contêineres, assim como monitoramento e detecção de problemas para aplicativos tradicionais e nativos em nuvem. A tecnologia integra com ferramentas existentes no datacenter e nuvem pública.
As funções de rede, como switch, roteamento e firewall, são incorporadas ao hypervisor e distribuídas em todo o ambiente. Isso cria, efetivamente, um “hypervisor de rede” que funciona como uma plataforma para sistemas de redes virtuais e serviços de segurança. De maneira semelhante ao modelo operacional de máquinas virtuais, as redes virtuais são provisionadas programaticamente e gerenciadas sem depender do hardware subjacente. Ela reproduz todo o modelo de rede no software, permitindo que qualquer topologia de rede (de redes simples a complexas com diversas camadas) seja criada e provisionada em segundos. É possível criar várias redes virtuais com diversos requisitos, aproveitando uma combinação de serviços nativos para esse tipo de solução, fornecendo ambientes inerentemente mais seguros.
Como a estrutura de rede virtualizada (Software Defined Network ou SDN) cria redes no software, a equipe de infraestrutura do datacenter pode atingir níveis de agilidade, segurança e economia que não são possíveis com as redes físicas. A SDN oferece um conjunto completo de serviços e elementos lógicos de sistema de rede que incluem switch, roteamento, firewall, balanceamento de carga, VPN, qualidade de serviço (QoS, Quality of Service) e monitoramento lógicos. Esses serviços são provisionados em redes virtuais por qualquer plataforma de
gerenciamento de nuvem que utiliza as interfaces de programação compatível. As redes virtuais são implementadas continuamente em qualquer hardware de sistema de rede existente.
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
Outro desafio a ser vencido é o uso da rede no datacenter de contingência no TCU. Atualmente, as configurações da rede do TCU precisam ser configuradas manualmente nos equipamentos hospedados naquela datacenter e, em caso de desastre no datacenter do TST, um técnico da infraestrutura precisará ir ao TCU configurar, também manualmente, as conexões de rede para restabelecer a conectividade. Quando a rede é virtualizada, a camada física passa a ser abstraída, conforme explicitado, e assim a configuração da topologia de roteamento de rede no datacenter do TCU passa a ser a mesma do datacenter do TST, sem a necessidade de intervenção manual. Isso também é valido para as regras de segurança, que serão aplicadas independe do sistema estar sendo executada no TST ou no site de contingência, em caso de desastre.
Dessa maneira, para que a infraestrutura do TST possa acompanhar a agilidade necessária no desenvolvimento e entrega de novas soluções de TI para o Tribunal e, ao mesmo tempo, garantir a segurança das aplicações, a padronização na configuração de rede para centenas de containers e máquinas virtuais e o monitoramento e análise das comunicações de rede em um ambiente misto entre legado e aplicações desenvolvidas com preceitos de nuvem e, no futuro, utilizar de forma transparente nuvem híbrida (pública e privada), faz-se necessário evoluir a estrutura de rede, hoje física, para uma rede baseada em software.
Para tanto, a solução a ser adquirida precisa ser aderente a nossa infraestrutura física e virtual e atender aos requisitos mínimos de funcionalidades para suprir à necessidade em questão. São eles:
● Totalmente compatível e integrado com a estrutura virtual atual, VMware vCloud Standard;
● Totalmente compatível com equipamentos de rede Cisco Nexus 9000;
● Permitir a criação de regras de segurança e topologia de rede para máquinas e containers
Kubernetes;
● Permitir a automação na aplicação de regras específicas para determinado sistema informatizado, independente se esteja sendo executadas em máquinas virtuais ou containers e independe da rede que se encontre (interna, DMZ, internet ou nuvem pública);
● Capacidade avançada de monitoramento e análise de rede, permitindo visualizar a conexão entre todos os serviços e o tipo de dados trafegado;
● Garantir a segurança entre tráfego de perímetro (ou Norte/Sul) e tráfego Leste/Oeste, inclusive entre as máquinas virtuais e containers dentro de uma mesma rede e host físico;
● Permitir o uso de balanceadores de carga por IP;
● Permitir a micro segmentação da rede, tanto para containers quanto para máquinas virtuais;
● Possuir mecanismos de distribuição de carga e aplicação de regras e configurações entre
datacenters distintos (do TST e do site de contingência no TCU);
● Permitir a gestão através de APIs;
● Possuir integração com as soluções de automação utilizadas na infraestrutura: VMware Orquestrador e Ansible.
2.2 Objetivos a serem alcançados
São eles:
● Aprimorar a segurança das aplicações;
● Garantir conformidade das configurações de rede entre todas as VMs e containers;
● Aumentar a capacidade de monitoramento e análise da comunicação;
● Garantir a agilidade necessária para entrega de novos serviços de rede para as aplicações desenvolvidas nos preceitos de nuvem;
● Criar o alicerce necessário para o uso futuro de nuvem pública sem comprometer a segurança e a agilidade na entrega dos sistemas informatizados do TST.
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
2.3 Benefícios diretos e indiretos resultantes da contratação
Como benefícios diretos e indiretos, destacamos os seguintes:
● Micro segmentação e segurança detalhada fornecidas à carga de trabalho individual;
● Monitoramento avançado da rede com análise da conexão entre os componentes das aplicações;
● Redução do tempo de aprovisionamento de rede de dias para segundos e eficiência operacional aprimorada por meio da automação;
● Mobilidade de carga de trabalho independente da topologia da rede física em todos os
datacenters; e
● Segurança aprimorada e serviços avançados de sistema em um ecossistema de fornecedores externos líderes do setor.
2.4 Alinhamento com o Plano de Contratações de STIC para o exercício e a previsão orçamentária
Consta no Plano de Contratações de STIC 2020 a Ação Orçamentária 2020-AO-032, valor estimado de R$ 5.864.447,40.
2.5 Alinhamento entre a contratação e os planos estratégicos do TST e planos estratégicos de Tecnologia da Informação
A contratação em questão está alinhada com o Planejamento Estratégico do TST 2015 a 2020 na perspectiva “Recursos”, Objetivo “Garantir a infraestrutura e o orçamento” e também com o Plano Estratégico de Tecnologia da Informação e Comunicação do TST (PETIC 2015 a 2020) na perspectiva “Pessoas e Infraestrutura”, Objetivo Estratégico “Garantir a infraestrutura de TIC”.
2.6 Requisitos da contratação/aquisição
Requisitos Tecnológicos (hardware e software) | |
ID | Descrição |
R.HS01 | A solução de virtualização de redes deve possuir gerenciador/controlador centralizado para as funcionalidades de rede implementadas, fornecendo um ponto único de gerenciamento de toda a rede. |
R.HS02 | A solução de virtualização de redes deverá ser totalmente baseada em software. |
R.HS03 | Deverá ser suportada em qualquer underlay físico de rede, independente da topologia, (core-distribuição-acess), spine/leaf, suportando a agregação de enlaces em interfaces físicas com uso de LACP. |
R.HS04 | Deverá possuir a capacidade de suportar múltiplos tenants de rede, suportando sobreposição de endereçamento IP nos tenants. |
R.HS05 | Deverá permitir a criação de tabelas de roteamento isoladas por meio de VRF para segregação em ambientes multi tenant. |
R.HS06 | Os planos de gerenciamento, controle e encaminhamento devem ser separados. |
R.HS07 | A gerenciamento centralizado deve ser realizado tanto por interface gráfica (GUI) quanto por meio de APIs REST. |
R.HS08 | O gerenciador/controlador centralizado deve permitir ser instalado em arquitetura de alta disponibilidade. |
R.HS09 | Em ambientes com múltiplos datacenters, cada um com seu gerenciador/controlador centralizado, deve implementar uma camada de gestão global que permita um gerenciamento centralizado, a partir do qual as configurações são distribuídas para os gerenciadores/controladores em cada datacenter. |
R.HS10 | Em ambientes com múltiplos datacenters, cada um com seu gerenciador/controlador centralizado, deve ser possível criar políticas de segurança globais e estender redes entre datacenters. |
R.HS11 | O gerenciador/controlador centralizado deve permitir a criação de backups de configuração automáticos. |
R.HS12 | O plano de dados dos seguintes componentes deverá ser distribuído e implementado no kernel do hypervisor: switching lógico, roteamento lógico e firewall lógico. |
R.HS13 | Deve suportar a implementação de componentes em bare-metal. |
R.HS14 | Deve suportar tecnologia Intel DPDK para permitir alta capacidade de comutação de pacotes. |
R.HS15 | Deve implementar upgrade centralizado para todos os componentes da solução através da console única de gerenciamento; |
R.HS16 | Deve permitir a criação de switches, roteadores e firewalls lógicos. |
R.HS17 | Deve permitir a criação de balanceadores de carga lógicos. |
R.HS18 | Deve implementar funcionalidades de virtualização sendo compatível com hypervisor VMware ESXi 6.7 e superior, KVM e servidores bare- metal. |
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
R.HS19 | Deve implementar funcionalidades de virtualização sendo compatível com soluções de orquestração de containers: Kubernetes e OpenShift. |
R.HS20 | A integração com soluções de containers deve realizar o provisionamento automático da infraestrutura virtual, com a criação e configuração dinâmica de switches e roteadores virtuais, balanceadores de carga, e firewall distribuído. |
R.HS21 | Deve suportar a integração com as nuvens públicas, no mínimo Microsoft Azure e Amazon AWS, com o uso do mesmo controlador/gerenciador centralizado. |
R.HS22 | Deve permitir a automação da rede virtual por meio de integração nativa com Openstack e Vmware vRealize Automation. |
R.HS23 | Deve possuir módulos Ansible para automação da infraestrutura de rede virtual. |
R.HS24 | As redes lógicas devem ser implementadas no modelo de overlay, implementando a tecnologia VxLAN ou GENEVE para a criação das redes virtuais sobre uma rede camada 3. |
R.HS25 | Deve permitir a criação de switches lógicos suportados por VLAN (sem overlay). |
R.HS26 | Deve permitir a comunicação em camada 2 entre máquinas virtuais que estejam em hipervisores diferentes. |
R.HS27 | Deve permitir a comunicação em camada 2 entre pods que estejam em hipervisores diferentes. |
R.HS28 | As redes lógicas devem implementar a funcionalidade de DHCP relay em IPv4. |
R.HS29 | As redes lógicas devem implementar a funcionalidade de DHCP relay em IPv6. |
R.HS30 | Deve implementar DHCP snooping e ARP snooping nas redes virtuais. |
R.HS31 | Deve implementar DHCPv6 snooping e Neighbor Discovery snooping nas redes virtuais IPv6. |
R.HS32 | Deve implementar mecanismo de proteção contra spoofing de endereços IP e MAC dos endpoints conectados às redes virtuais e Dynamic ARP Inspection. |
R.HS33 | Deve implementar qualidade de serviço no switch virtual, com funcionalidades que permitem confiar ou não na marcação do endpoint, suporte a DSCP e CoS e funções de limitação de tráfego de entrada e de saída. |
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
R.HS34 | Deve ser possível limitar a banda por tenant por meio da função de rate limiting nos roteadores dos tenants. |
R.HS35 | Deve possuir mecanismos de segurança para as redes virtuais, permitindo configurar: filtragem de BPDU, filtragem de DHCP. |
R.HS36 | Deve possuir mecanismos de segurança para as redes virtuais, permitindo configurar: filtragem de DHCPv6 e filtragem de pacotes IPv6 RA (Router Advertisement). |
R.HS37 | Deve possuir funcionalidade que permite a limitação de tráfego broadcast e multicast nas redes virtuais. |
R.HS38 | Deve possuir funcionalidade que permite a limitação da quantidade de endereços MAC nas redes virtuais. |
R.HS39 | Deve implementar o protocolo LLDP. |
R.HS40 | Deve permitir a conexão com servidores físicos através da funcionalidade “bridge”, de forma que um workload em uma rede virtual (overlay) possa estar na mesma subrede L2 de uma máquina física. |
R.HS41 | A solução deverá implementar o roteamento entre as redes virtuais (overlays). |
R.HS42 | Deve implementar o roteamento entre workloads (máquina virtual e container) conectados a redes virtuais distintas. Caso os workloads estejam no mesmo servidor físico o tráfego entre eles deve permanecer dentro do servidor sem a necessidade de appliance virtual para esta função. |
R.HS43 | A solução deverá permitir o roteamento entre VLANs e Redes Virtuais; |
R.HS44 | Deve haver mecanismo de alta disponibilidade para a estrutura de roteamento virtual nos modos ativo-ativo e ativo-standby. |
R.HS45 | Deve implementar roteamento estático em IPv4. |
R.HS46 | Deve implementar roteamento estático em IPv6. |
R.HS47 | Deve implementar o roteamento multicast com PIM Sparse Mode. |
R.HS48 | Deve implementar o protocolo IGMPv2. |
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
R.HS49 | Deve permitir a configuração de um endereço virtual para implementação de alta disponibilidade entre roteadores físicos e virtuais. |
R.HS50 | Deve implementar roteamento dinâmico iBGP e eBGP em IPv4. |
R.HS51 | Deve implementar roteamento dinâmico BGP em IPv6. |
R.HS52 | Deve permitir a customização dos timers BGP por vizinho. |
R.HS53 | Deve permitir a proteção da vizinhança BGP por meio de senha para autenticação MD5. |
R.HS54 | Deve permitir a manipulação de rotas com base nos seguintes atributos ou características: ● IP Prefix; ● Route Maps; ● Route Redistribution; ● BGP Multipath AS-path relax; e ● BGP Allow-AS in. |
R.HS55 | Deve implementar o protocolo BFD para detecção rápida de falhas na adjacência BGP. |
R.HS56 | Deve permitir a manipulação de rotas, configurando filtros baseados listas de prefixo. |
R.HS57 | Deve permitir a manipulação avançada de rotas BGP, possibilitando realizar as seguintes funções: AS Path Preprend e manipulação de MED, Weight, Comunidades e Local Preference. |
R.HS58 | Deve permitir o controle de redistribuição de rotas em IPv4. |
X.XX00 | Deve permitir o controle de redistribuição de rotas em IPv6. |
R.HS60 | Deve implementar Source NAT e Destination NAT. |
R.HS61 | Deve implementar NAT64. |
R.HS62 | Deve implementar encaminhamento ECMP (“Equal Cost Multi-Path“) para balancear o tráfego de dados entre diversos caminhos. |
R.HS63 | Deve implementar o protocolo MP-BGP EVPN com o protocolo de overlay VxLAN. |
R.HS64 | Deve implementar DHCP Server. |
R.HS65 | Deve implementar ferramenta de IPAM para a gestão de blocos de endereçamento IP. |
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
R.HS66 | Deve possuir visualização gráfica da topologia de rede virtual. |
R.HS67 | Deve permitir que a comunicação entre rede física e pods kubernetes seja feita tanto por meio de NAT quando por roteamento. |
R.HS68 | No caso de comunicação entre rede física e pods kubernetes ser feita por NAT, a configuração do NAT deve ser realizada de forma automática. |
R.HS69 | No caso de comunicação entre rede física e pods kubernetes ser feita por NAT, deve permitir que o tráfego de determinado namespace ou de determinados pods (serviço) de um namespace seja identificado na rede física. |
R.HS70 | Deve permitir que workloads em redes físicas (VLANs) sejam diretamente conectadas à rede virtual com seu default gateway implementado no roteador virtual. |
R.HS71 | Deve permitir a implementação em sites distintos, com a extensão das redes virtuais e para mais de um datacenter. |
R.HS72 | Deve implementar solução para extensão do mesmo segmento de rede entre distintos sites sem a necessidade de o site de origem fazer parte do fabric de rede virtual. |
R.HS73 | Deve possuir a capacidade de migrar máquinas virtuais entre sites, sem a necessidade de alteração de endereço IP, sendo possível a migração de máquinas em paralelo e por meio de vMotion sem a interrupção de serviço. |
R.HS74 | Deve ser possível agendar a migração de máquinas virtuais, auxiliando em atividades de DR programado. |
R.HS75 | Deve possuir mecanismos de otimização do tráfego na migração de máquinas virtuais. |
R.HS76 | Deve possuir firewall que mantém estado da negociação dos pacotes (firewall stateful). |
R.HS77 | Deve permitir a criação de regras sem controle de estado de conexão (stateless). |
R.HS78 | O firewall deve possuir a capacidade de restringir o alcance das regras, indicando a aplicabilidade das regras de segurança, podendo, inclusive, criar regras de negação explícita por sessões de firewall e assim criar políticas específicas por ambiente/aplicação, zona ou tenant. |
R.HS79 | Deve permitir aplicar políticas de segurança com baseadas em horário (time-based), com a customização de horários e dias da semana que as regras serão aplicadas. Esta funcionalidade deve estar disponível tanto no |
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
firewall distribuído quanto no firewall de perímetro. | |
R.HS80 | Deve manter a tabela de estados baseando-se não somente em portas estáticas, mas também em portas dinâmicas utilizadas em certas aplicações (ex. FTP – porta de controle 21 e porta de dados 20). |
R.HS81 | Deve permitir a configuração de firewall distribuído, ou seja, implementado individualmente para cada workload (máquina virtual e pod kubernetes) conectado à rede virtual com gerenciamento centralizado. |
R.HS82 | As regras de firewall distribuído devem acompanhar o workload durante sua movimentação dentro do domínio de Firewall Distribuído. |
R.HS83 | Deve permitir a implementação de políticas de segurança em servidores bare-metal com sistemas operacionais Linux (CentOS, RHEL, OEL, SUSE e Ubuntu) e Windows Server. |
R.HS84 | Deve permitir a configuração do firewall nos elementos de roteamento da solução (firewall de perímetro). |
R.HS85 | O firewall de perímetro deve possuir categorização das políticas de segurança. |
R.HS86 | Deve ser possível configurar regras de firewall de perímetro que se apliquem a todos os gateways, facilitando a gestão de regras de uso global. |
R.HS87 | O firewall distribuído deve ser implementado diretamente no host, não dependendo do uso de máquinas virtuais de filtragem de tráfego para o seu funcionamento. |
R.HS88 | O firewall distribuído deve possuir a capacidade de segmentar o tráfego de cargas de trabalho que se encontram no mesmo segmento de rede lógico (L2) seja ele baseado em VLAN ou Overlay. |
R.HS89 | O firewall distribuído deverá permitir a categorização de políticas de segurança. |
R.HS90 | Cada regra de firewall deverá possuir como opções as ações “Permitir o tráfego”, “Descartar o tráfego” e “Rejeitar o tráfego”. Por “Rejeitar o Tráfego” entende-se que o Firewall Distribuído deve encaminhar uma mensagem à origem do tráfego não permitido sinalizando essa condição. |
R.HS91 | Deve permitir habilitar logging para as regras de firewall tanto para regras que permitem o tráfego quanto para as de bloqueio. |
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
R.HS92 | Deve ser possível a construção de regras de firewall abstraindo endereçamento IP e permitindo o uso dos seguintes objetos e parâmetros: a. Endereço IPv4 e IPv6; b. MAC – origem/destino; c. Portas – origem/destino; d. Protocolo / tipo (TCP ou UDP); e. Rede virtual (switch lógico); f. Interface Lógica de Rede (vNIC); g. Grupo de segurança; h. Tags (etiquetas); i. Nome da máquina virtual; j. Grupo de Active Directory; e k. Sistema Operacional. |
R.HS93 | Deve permitir a utilização de grupos de endpoints para facilitar o gerenciamento do firewall. |
R.HS94 | As regras de firewall devem possuir informações que apoiam na gestão e troubleshooting possuindo, para cada regra: contador de hit, contador de pacotes, contador de sessões, contador de bytes e índice de popularidade. |
R.HS95 | Deve possuir integração com soluções de terceiros para prover serviços de Anti-Virus/Anti-Malware e IPS (Intrusion Prevention System). |
R.HS96 | Deve suportar a inserção de soluções de terceiros no nível da rede tanto para tráfego Norte/Sul quanto para o tráfego Leste/Oeste. |
R.HS97 | Deve permitir a aplicação de micro segmentação para ambiente Kubernetes com a criação automatizada de regras no firewall distribuído a partir da especificação Network Policy do Kubernetes. |
R.HS98 | Deve permitir a aplicação de micro segmentação para ambiente Kubernetes com a criação de regras baseadas em labels aplicados aos pods. |
R.HS99 | Deve permitir o uso de firewall de identidade para grupos do Active Directory da Microsoft em ambientes VDI/RSDH. |
X.XX000 | O firewall de identidade deverá poder ser habilitado sob demanda por cluster ou nó. |
R.HS101 | O firewall deve implementar funcionalidades camada 7, permitindo a criação de regras com base em aplicações, independente de porta TCP/UDP utilizada, tanto no firewall distribuído quanto no firewall de perímetro. |
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
R.HS102 | Deverá possuir a capacidade de realizar a análise das URLs acessadas através dos roteadores/gateways virtuais, permitindo observar de maneira gráfica a classificação e reputação das URLs acessadas pelas cargas de trabalho conectadas à rede virtual. |
R.HS103 | Deve permitir a criação de regras baseada em URL / FQDN. |
R.HS104 | O firewall distribuído deve implementar a funcionalidade de rascunho (draft), permitindo a configuração de regras para posterior aplicação, visualização de histórico de alterações e facilitando rollback para versões anteriores. |
R.HS105 | O firewall deve permitir a customização dos parâmetros de timers de sessões TCP, UDP e ICMP. |
R.HS106 | Deve ser possível configurar e customizar parâmetros para proteção anti- DDoS. |
R.HS107 | O firewall deve permitir a separação em seções de forma a facilitar o gerenciamento e possuir mecanismo para bloqueio de seção, de forma a evitar que dois administradores editem a mesma regra de forma simultânea. |
R.HS108 | Deve implementar a funcionalidade de L2VPN, permitindo a extensão camada dois entre datacenters. |
R.HS109 | A funcionalidade de L2VPN deve permitir interligar redes virtuais (overlay) a redes físicas (VLAN) bem como interligação entre duas redes virtuais e entre duas redes físicas. |
R.HS110 | Deve implementar a funcionalidade de VPN IPSEC. |
R.HS111 | Deve implementar VPN baseada em políticas e baseada em roteamento (Policy Based e Route Based). |
R.HS112 | Deve ser possível autenticação VPN com chaves pré-compartilhadas e com base em certificados. |
R.HS113 | Deve suportar túneis VPN em ambiente com NAT. |
R.HS114 | Deve implementar a capacidade de estabelecimento de túneis redundantes. |
R.HS115 | Deve implementar os protocolos IKEv1 e IKEv2. |
R.HS116 | Deve implementar, no mínimo, os algoritmos criptográficos AES128, AES256, AES-GCM-128 e AES-GCM-256. |
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
R.HS117 | Deve implementar, no mínimo, os algoritmos de hash SHA1, SHA2-256 e SHA2-512. |
R.HS118 | Deve implementar, no mínimo, os grupos Diffie-Hellman Grupo 2, Grupo 14, Grupo 19, Grupo 20 e Grupo 21. |
R.HS119 | Deve implementar Balanceamento de Carga para tráfego TCP, UDP, HTTP e HTTPS por meio do uso de IPs virtuais (VIPs). |
R.HS120 | Deve implementar persistência de sessões, mantendo a conexão de um determinado cliente com um mesmo servidor durante a mesma sessão. |
R.HS121 | Deve permitir a configuração de persistência de sessão por meio de endereço IP de origem e inserção de cookie. |
R.HS122 | Deve permitir a criação de Health Check (monitor) dos servidores com base em ICMP, TCP, UDP, HTTP e HTTPS. |
R.HS123 | Para monitores baseados em HTTP/HTTPS deve ser possível customizá- lo com os parâmetros método HTTP, Request URL, Response Code, Request Body e Response Body. |
R.HS124 | Deve ser possível customizar os monitores com relação ao intervalo entre probes e tempo de timeout. |
R.HS125 | Deve implementar monitor passivo dos serviços, utilizando o próprio tráfego de clientes para detecção do status do serviço. |
R.HS126 | Deve permitir o uso em topologias do tipo one-armed e inline. |
R.HS127 | Deve permitir a configuração de forma transparente, em que o endereço IP de origem é mantido na conexão ao servidor do pool. |
R.HS128 | Deve implementar a inserção e modificação do endereço IP de origem no cabeçalho HTTP com o uso de X-Forwarded For. |
R.HS129 | Deve permitir a definição estática e dinâmica do pool de servidores. |
R.HS130 | Deve permitir o balanceamento de carga tanto para servidores conectados à rede virtual quanto para servidores conectados à rede física. |
R.HS131 | Os pools de servidores devem implementar, no mínimo, os seguintes algoritmos de balanceamento: Round Robin, Weighted Round Robin, Hash, Least Connections e Weighted Least Connections. |
R.HS132 | Deve implementar a funcionalidade de multiplexação TCP. |
R.HS133 | Deve implementar SSL Passthrough, SSL-Offload e SSL fim-a-fim, podendo utilizar perfis SSLs diferentes entre Cliente/Balanceador e Balanceador/Servidor. |
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
R.HS134 | Deve permitir a criação de certificados SSL auto assinados e a importação de certificados SSL externos. |
R.HS135 | Deve permitir a criação de regras de balanceamento camada 7, sendo possível o uso de expressões regulares para identificar parâmetros no cabeçalho HTTP, no certificado e em endereço/porta IP/TCP. |
R.HS136 | O balanceador de carga deve suportar a customização de regras de balanceamento de carga com base em campos do protocolo HTTP. |
R.HS137 | Deve implementar a função de re-write, manipulando campos HTTP e selecionando pools específicos de servidores conforme as condições definidas. |
R.HS138 | Na integração com Kubernetes um novo VIP deve ser criado de forma automática, com a configuração dinâmica do pool de servidores a partir da criação de serviços do tipo load-balancer. |
R.HS139 | Na integração com Kubernetes um VIP existente deve ser utilizado com a configuração dinâmica do pool de servidores por meio de regras de encaminhamento camada 7 a partir da criação de serviços do ingress. |
R.HS140 | Na integração com Kubernetes deve ser possível o uso de secret kubernetes para balanceamento de tráfego SSL com a importação automática do certificado definido pelo secret para o balanceador. |
R.HS141 | Deve permitir que os pods de uma determinada aplicação sejam automaticamente incluídos e excluídos no pool de balanceamento de carga. |
R.HS142 | Deve suportar múltiplas instâncias de vCenter Server com a função de obter o inventário de objetos a serem utilizados na plataforma. |
R.HS143 | Deve possuir elementos que permitam monitorar a saúde da plataforma e o uso dos recursos. |
R.HS144 | Deve suportar o padrão OpenAPI. |
R.HS145 | Deve permitir a criação de objetos por meio de um modelo declarativo (outcome driven networking), simplificando e reduzindo a quantidade de chamadas API. |
R.HS146 | Deve implementar mecanismos de comunicação segura por meio de certificados TLS em todos os elementos da solução: gerenciamento, controle, plano de dados e API. |
R.HS147 | Deve possuir funcionalidade do tipo RBAC – Role Based Access Control integrada a uma base de usuários externa. |
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
R.HS148 | Deverá permitir a autenticação dos usuários utilizando diretórios externos, suportando Active Directory. Deve ser possível definir o nível de acesso (role) para usuários externos. |
R.HS149 | Deve possuir mecanismo para exportação/análise de tráfego baseado em Netflow/IPFIX para coletar tráfego de informações IP e enviar para ferramenta de análise. |
R.HS150 | Deve ser possível configurar, no mínimo, 4 coletores Netflow/IPFIX, que devem poder ser tanto com IPv4 quanto com IPv6. |
R.HS151 | Deve implementar SPAN (espelhamento do tráfego local), RSPAN (espelhamento do tráfego para análise remota através do encapsulamento em uma VLAN) e ERSPAN (espelhamento do tráfego para análise remota através do encapsulamento em um pacote IP). |
R.HS152 | Deve permitir a visualização da comunicação entre workloads (máquinas virtuais e pods) conectados à rede virtual com funcionalidade de traçar o caminho entre endpoints. |
R.HS153 | Ao visualizar o caminho entre dois endpoints deve ser possível especificar qual o tipo de pacote a ser utilizado, permitindo o uso de pacotes IPv4 e IPv6 e a customização do tipo de pacote, com definição de protocolo (ICMP, UDP e TCP) e porta. |
R.HS154 | Ao visualizar o caminho entre dois endpoints devem ser mostrados todos os elementos de rede virtuais do caminho e a regra utilizada para permitir ou bloquear o tráfego. |
R.HS155 | Deve possuir visualização dos elementos conectados à rede virtual, fornecendo mecanismo de busca avançado que permita buscar por, no mínimo: endereço IPv4, endereço IPv6, nome da máquina virtual, nome do pod e tag ou labels aplicados. |
R.HS156 | Deve ser possível monitorar os elementos de rede virtual por meio do protocolo SNMP nas versões 2 e 3. |
R.HS157 | Deve implementar monitoramento por meio de syslog, de acordo com a RFC 5424 ou RFC 3164. |
R.HS158 | Deve ser possível exportar mensagens syslog para mais de um destino. |
R.HS159 | Deve permitir o envio de mensagens syslog para um servidor externo de forma segura utilizando o protocolo TLS. |
R.HS160 | As interfaces dos switches virtuais devem possuir contadores e estatísticas de tráfego. |
R.HS161 | A solução deve possuir dashboards operacionais que contenham, no mínimo, status dos elementos que compõem o fabric de rede virtual e uso |
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
da capacidade total do sistema. | |
R.HS162 | A solução deve possuir ferramenta para armazenamento e indexação de logs com dashboards pré-configurados para gerenciamento e monitoramento da infraestrutura de rede virtual. |
R.HS163 | A ferramenta de logs deve permitir a agregação bem como a busca contextual para filtragem e busca. |
R.HS164 | A solução deve possuir ferramenta de visibilidade e analytics de rede que agregue todo o inventário da rede os fluxos de tráfego sem amostragem para criação de topologia de aplicações. |
R.HS165 | Deve permitir a visualização gráfica da comunicação entre máquinas virtuais conectadas à rede, com a informação dos fluxos protegidos ou não pelo firewall da solução. |
R.HS166 | A solução deve fornecer a recomendação das políticas de segurança com base nas comunicações observadas. |
R.HS167 | Deve ser possível customizar a visualização das comunicações utilizando filtros e grupos. |
R.HS168 | Deve ser possível publicar as regras recomendadas a partir das recomendações, sem necessidade de configurá-las manualmente. |
R.HS169 | Deve possuir a capacidade de consumir informações sobre switches, balanceadores e firewalls físicos bem como da infraestrutura de rede virtual, por meio de protocolos como SSH, HTTPS, SNMP. |
R.HS170 | Deve possuir a capacidade de obter informações sobre os provedores de nuvem pública, no mínimo Amazon AWS e Microsoft Azure. |
R.HS171 | Deve possuir a capacidade de obter informações sobre ambientes Kubernetes e Openshift. |
R.HS172 | Deve permitir a extração de estatísticas de tráfego com a recepção de fluxos das redes virtuais por meio da coleta IPFIX. |
R.HS173 | Deve permitir a extração de estatísticas de tráfego com a recepção de fluxos das redes físicas por meio da coleta Netflow e sFlow. |
R.HS174 | Deve agregar os fluxos recebidos e exibi-los de forma gráfica com a indicação do sentido do fluxo (entrante, sainte ou bidirecional), permitindo customizar a forma de agrupar a visualização dos fluxos. Deve ser possível realizar tal agrupamento por meio da informação da rede (VLAN/VXLAN), subrede, aplicação e máquina virtual. |
R.HS175 | Deve ser possível coletar flows em ambientes de nuvem pública, no mínimo Amazon AWS e Microsoft Azure, permitindo entender o tráfego |
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
e realizar o planejamento de segurança. | |
R.HS176 | Deve permitir filtrar a visão gráfica dos fluxos agregados de forma a mostrar tráfego da rede virtual, física e Internet. |
R.HS177 | Deve ser possível exibir os flows permitidos, bloqueados, protegidos pelo firewall da solução de virtualização e desprotegidos. |
R.HS178 | Deve possuir a capacidade de recomendar regras de firewall a serem aplicadas conforme a análise dos fluxos recebidos. |
R.HS179 | Deve ser possível exportar as regras de micro segmentação sugeridas em formato xml. |
R.HS180 | Deve possuir Dashboard Analítico exibindo as informações mais relevantes do perfil de tráfego do Datacenter. |
R.HS181 | Deve ser compatível com Hyperisores vSphere ESXi versão 6.7 ou superior e seu respectivo Switch Distribuído. |
R.HS182 | Para uma determinada VxLAN exibir quais são as VMs conectadas e em quais hosts físicos estão hospedadas. |
R.HS183 | Para uma determinada VLAN exibir quais são as VMs conectadas e em quais hosts físicos estão hospedadas. |
R.HS184 | Para uma determinada VM deve exibir a topologia de sua comunicação com a Internet. |
R.HS185 | Deve exibir a topologia utilizada para a comunicação entre duas VM’s, incluindo elementos de camada 2, camada 3 e inclusive topologias de ECMP caso existam. |
R.HS186 | Deve exibir a topologia utilizada para a comunicação entre dois pods kubernetes, dois serviços kubernetes e entre um serviço e um pod kubernetes, incluindo elementos de camada 2 e camada 3. |
R.HS187 | Deve exibir a topologia utilizada para a comunicação entre máquinas virtuais no datacenter on-premises e na nuvem pública, entre VMs em um mesmo VPC e entre VMs em VPC distintos. |
R.HS188 | Para um determinado Host Físico deve exibir sua conexão com a rede física além das VMs ali hospedadas. |
R.HS189 | Deve ser possível exibir as regras de NAT aplicadas na comunicação entre duas VM’s e a topologia utilizada. |
R.HS190 | Deve ser possível exibir os Grupos de Segurança criados na solução de virtualização de redes. |
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
X.XX000 | Deve exibir a hierarquia entre os Grupos de Segurança, exibindo grupos de segurança “pais” e “filhos”. |
R.HS192 | Deve ser possível mapear um flow físico à sua entrada DNS. |
R.HS193 | Deve ser possível integrar com DNS externo para permitir o mapeamento de nomes DNS aos IPs de dispositivos físicos. |
R.HS194 | Deve ser possível mapear uma subnet da rede física à uma VLAN. |
R.HS195 | Deve utilizar automaticamente a RFC 1918 para identificar quais são os IPs públicos e privados do perfil de tráfego do Datacenter. |
R.HS196 | Deve permitir a customização dos endereços IP públicos e privados, definindo quais são os ranges de endereços externos e internos ao Data- Center. |
R.HS197 | Deve permitir a autenticação de usuários utilizando uma fonte interna. |
R.HS198 | Deve permitir a autenticação de usuários utilizando o Active Directory como servidor LDAP. |
R.HS199 | Deve possuir pelo menos três níveis de permissão de usuários, sendo possível mapear usuários locais e usuários LDAP aos diferentes níveis. |
R.HS200 | O Dashboard Analítico deve permitir a visualização de “Top Talkers”, exibindo pelo menos as 10 principais comunicações entre pares de VMs, Clusters, Redes de Camada 2 e Subnets. |
R.HS201 | A visualização de Top Talkers do Dashboard Analitico deve exibir as métricas de análise por volume de tráfego, por taxa de comunicação, por quantidade de sessões e por quantidade de flows. |
R.HS202 | Deve ser possível visualizar os Top Talkers em um ambiente Kubernetes, com informações dos Clusters e Namespaces com maior tráfego. |
R.HS203 | O Dashboard Analítico deve possuir um painel de novidades, exibindo quais foram as últimas mudanças do ambiente como novas VM’s com acesso à internet, novos serviços disponíveis na Internet, novos serviços disponíveis internamente, novos serviços que foram bloqueados pelo Firewall Distribuído da Ferramenta de Virtualização e Novas Regras de Firewall utilizadas. |
R.HS204 | O Dashboard Analítico deve exibir os flows que consomem maior banda em poucas sessões e os flows que possuem muitas sessões com baixo consumo de banda. |
R.HS205 | Deve possuir a capacidade de detectar flows com anomalia baseado no TCP RTT para fluxos dentro de um mesmo host e entre hosts. |
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
R.HS206 | Deve possuir a capacidade de identificar máquinas virtuais com padrão de tráfego anômalo com base na comparação de máquinas virtuais de um mesmo grupo. |
R.HS207 | Deve ser possível criar limiares estáticos e dinâmicos de métricas como a taxa de dados de máquinas virtuais e aplicações que, se ultrapassados, devem gerar alertas por e-mail e trap SNMP. Os limiares dinâmicos devem ser baseados no perfil histórico de comportamento. |
R.HS208 | Deve possuir mecanismo de busca contextual com sugestão automática de texto. |
R.HS209 | O mecanismo de busca deve permitir a procura por entidades do ambiente virtual como nome da VM, Host Físico, VLAN, VxLAN e Grupos de Segurança. |
R.HS210 | O mecanismo de busca deve permitir a procura por entidades de ambientes Kubernetes como Namespace, Pod, Serviço e Nó. |
R.HS211 | O mecanismo de busca deve permitir a procura por entidades de ambientes de nuvem pública Amazon AWS como Subnet, VPC, Conexão VPN e VPC Peering. |
R.HS212 | O mecanismo de busca deve permitir a procura por entidades de ambientes de nuvem pública Microsoft Azure como Application Security Group, Regra NSG, Subrede, Máquina Virtual e Virtual Network. |
R.HS213 | O mecanismo de busca deve permitir a pesquisa avançada utilizando operadores lógicos como “e”, “ou” e “não” além de filtros comparativos como “=” e “!=”. |
R.HS214 | O mecanismo de busca deve permitir que o resultado da busca seja exibido em ordem ascendente e descendente além de permitir o agrupamento de resultados similares. |
R.HS215 | O mecanismo de busca deve permitir que a procura seja realizada em um período especificado, permitindo a identificação de comportamentos ocorridos no passado. |
R.HS216 | Deve ser possível configurar o tempo de retenção dos dados na plataforma. |
R.HS217 | Atuar como correlacionador de eventos apresentando os problemas das entidades monitoradas pela ferramenta. |
R.HS218 | Deve permitir configurar notificações dos eventos por meio de e-mail e trap SNMP. |
R.HS219 | A ferramenta deve possuir eventos pré-configurados com as severidades Crítico, Moderado, Atenção e Informação. |
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
R.HS220 | Deve ser possível definir eventos customizados baseados no resultado de uma busca. |
R.HS221 | Deve ser possível definir endereços de e-mail para o envio da notificação de eventos específicos e customizar a frequência de envio. |
R.HS222 | Deve ser possível desabilitar a notificação de eventos específicos. |
R.HS223 | Deve possuir API pública REST para automação das tarefas da plataforma. |
R.HS224 | Deve possuir log de auditoria das configurações realizadas com as informações de data e horário, usuário, IP de origem e a atividade executada. Deve ser possível exportar o log de auditoria por meio de syslog. |
R.HS225 | Deve permitir o envio de eventos para um servidor remoto de syslog. |
R.HS226 | Deve criar um mapa interativo com a topologia da rede incluindo dispositivos físicos e virtuais. |
R.HS227 | Deve possuir verificações de saúde da rede que permitam identificar os seguintes tipos de problemas: a) Endereço IP e MAC duplicado; b) Duplex mismatch; e c) MTU mismatch. |
R.HS228 | Deve ser possível visualizar os flows em ambientes Kubernetes, agrupando-os por Cluster, Serviço, Namespace ou Nó. |
R.HS229 | Deve ser possível exportar as regras de micro segmentação sugeridas para o ambiente Kubernetes no formato YAML de forma que estas possam ser aplicadas como Kubernetes Network Policies. |
R.HS230 | Deve ser possível modelar aplicações, definindo máquinas virtuais e endereços IP que formam cada um de seus tiers (camadas). |
R.HS231 | Deve ser possível modelar aplicações, definindo serviços Kubernetes. |
R.HS232 | Deve possuir mecanismo que permita a descoberta automática das aplicações com base em tags e nome das máquinas virtuais. |
R.HS233 | Deve possuir dashboard específico para aplicações, contendo a topologia da aplicação, seus fluxos de tráfego, métricas de seus membros e eventos relacionados à aplicação. |
R.HS234 | Para compor a solução pretendida, é permitido à licitante oferecer mais de uma licença de software. |
R.HS235 | Todas as licenças da solução ofertada devem ser perpétuas. |
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
Requisitos de Treinamento (Capacitação) | |
ID | Descrição |
R.T01 | Não se aplica. Trata-se de aquisição de licença perpétua com suporte e direito de atualização de software em garantia. A equipe técnica decidiu não adquirir treinamento desta solução neste primeiro momento. Caso seja verificado que é preciso um treinamento, será adquirido via trâmite normal do Plano de Capacitação. |
Requisitos Legais, Sociais e Ambientais | |
ID | Descrição |
R.LSA01 | A empresa deverá estar habilitada juridicamente (art. 28 da Lei n.º 8.666/93) e em regularidade fiscal e trabalhista (art. 29 da Lei n.º 8.666/93). |
R.LSA02 | Decreto Nº 2.271 de 7 de julho de 1997, que dispõe sobre a contratação de serviços pela Administração Pública Federal direta, autárquica e fundacional e dá outras providências |
R.LSA03 | Resolução CNJ nº 182/2013, que dispõe sobre diretrizes para as contratações de Solução de Tecnologia da Informação e Comunicação pelos órgãos submetidos ao controle administrativo e financeiro do Conselho Nacional de Justiça. |
R.LSA04 | Decreto-lei N.º 5.452, de 1º de Maio de 1943, que define a Consolidação das Lei do Trabalho. |
R.LSA05 | Súmula nº 269 do TCU que estabelece que nas contratações para a prestação de serviços de Tecnologia da Informação, a remuneração deve estar vinculada a resultados ou ao atendimento de níveis mínimos de serviço. |
R.LSA06 | Cumprir o disposto no inciso XXXIII do art. 7.º da Constituição Federal de 1988, quanto ao emprego de menores. |
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
R.LSA07 | Promover a correta destinação dos resíduos resultantes da prestação do serviço, tais como peças substituídas, embalagens, entre outros, observando a legislação e princípios de responsabilidade socioambiental como a Política Nacional de Resíduos Sólidos (Lei n.º 12.305/2010) e o Guia de Contratações Sustentáveis da Justiça do Trabalho (Resolução n.º 103/2012 do Conselho Superior da Justiça do Trabalho). |
R.LSA08 | Prever a destinação ambiental adequada das pilhas e baterias usadas ou inservíveis, segundo disposto na Resolução CONAMA nº 257, de 30 de junho de 1999. |
Requisitos de Garantia da Solução | |
ID | Descrição |
R.M01 | O serviço de suporte técnico em garantia deverá ser prestado diretamente pelo fabricante da solução, na modalidade 24x7 para correções de falhas, defeitos e atualizações diversas para todos os produtos adquiridos. |
R.M02 | O suporte em garantia deverá ser prestado durante as 24 horas do dia na eventualidade da ocorrência de problemas em dias úteis, finais de semana, feriados e recessos, seja por telefone ou Web. |
R.M03 | No momento da abertura do chamado, será informada a severidade que o caso requer, podendo ser: ● Severidade 1: este nível de severidade é aplicado quando o ambiente está indisponível; ● Severidade 2: este nível de severidade é aplicado quando funcionalidades principais estão severamente prejudicadas, e o ambiente funciona com restrições significativas; ● Severidade 3: este nível de severidade é aplicado quando há perdas de funcionalidades não críticas, e o ambiente funciona com restrições de menor impacto; e ● Severidade 4: este nível de severidade é aplicado quando há questões de caráter geral. |
R.M04 | A abertura de chamados será efetuada por correio eletrônico e por telefone 0800 ou com número de DDD igual ao da localidade do contratante. Em ambos os casos, o atendimento deve ser efetuado em Língua Portuguesa. |
R.M05 | Na abertura do chamado, deverá ser fornecido um número de registro para acompanhamento de cada equipamento. |
R.M06 | O início de atendimento e da resolução do serviço de suporte técnico e atualização será a hora da comunicação feita pelo Contratante à Contratada, conforme sistema de registro do próprio do solicitante. |
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
Requisitos de Prazo | |
ID | Descrição |
R.P01 | Os tempos de resposta devem seguir os seguintes níveis de serviço: ● Severidade 1: deverá ser iniciado em até 30 minutos; ● Severidade 2: iniciado em até 4 (quatro) horas; ● Severidade 3: iniciado em até 8 (oito) horas; ● Severidade 4: iniciado em até 12 (doze) horas. |
Requisitos de Segurança da Informação | |
ID | Descrição |
R.SI01 | A Contratada deverá substituir imediatamente aquele profissional que seja considerado inconveniente à boa ordem ou que venha a transgredir as normas disciplinares do TST. |
R.SI02 | Os profissionais deverão utilizar a conta que lhe for atribuída, de forma controlada e intransferível, mantendo secreta a sua respectiva senha, pois todas as ações efetuadas através desta, serão de responsabilidade do profissional da Contratada. |
R.SI03 | A Contratada deverá garantir a segurança das informações do TST e se comprometer em não divulgar ou fornecer a terceiros quaisquer dados e informações que tenha recebido do TST no curso da prestação dos serviços, a menos que autorizado formalmente e por escrito para tal. |
R.SI04 | A Contratada deve divulgar aos seus profissionais a Política de Segurança da Informação do TST, PSI-TST, e assegurar-se de sua observação e cumprimento no curso da prestação de serviços no Tribunal. A PSI-TST está formalizada no ATO 764/XXXXXX.XX de 27/11/2012 e pode ser consultada no endereço eletrônico: xxxxx://xxxxxxxxxx.xxx.xxx.xx/xxxxxx/00.000.00000/00000 |
R.SI05 | A contratada e seus profissionais devem manter sigilo absoluto sobre documentos elaborados e informações obtidas dentro do TST. |
Requisitos de Garantia | |
ID | Descrição |
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
R.G01 | Não se aplica, em virtude de a contratação se resumir a aquisição de suporte e garantia de atualização de solução de virtualização de redes. |
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
2.7 Relação entre a demanda prevista e a quantidade de cada item
O TST possui 60 licenças ativas do VMware vCloud Standard e 1 licença do VMware vCenter. Essas licenças são a base do ambiente virtual. O primeiro é licenciado por CPU e o segundo por instância.
Além das licenças, compõem o ambiente virtual 30 máquinas servidores, cada uma com 2 CPUs. Eis a razão de 60 licenças do VMware vCloud Standard, uma para cada CPU dos servidores.
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
Para a solução de virtualização de rede, a quantidade de licenças necessárias tem que ser equivalente a dos VMware vCloud que o TST possui, portanto, a solução ofertada deve estar licenciada para o uso em 60 CPUs.
Quanto à garantia, os fabricantes costumam oferecer o modelo de 12, 26 e 60 meses, onde o modelo de 36 meses possui um custo anual menor que o de 12 e do de 60 um custo anual menor que os de 12 e 36. Considerando que o ambiente virtual do TST, do fabricante VMware, é utilizado no Tribunal desde 2011, que não há qualquer previsão de descontinuidade ou mudança no fabricante, que o custo anual no contrato de 60 meses é o menor e que há disponibilidade financeira no exercício de 2020, uma realidade que pode não se repetir próximos anos, optou-se pela aquisição da garantia de 60 meses.
A tabela abaixo descreve o objeto pretendido com o quantitativo necessário:
Objeto | Quantidade (solução) |
Aquisição de solução de virtualização e segurança de rede, com garantia de 60 meses prestada pelo fabricante para o ambiente virtual VMware utilizando no TST. | 1 |
2.8 Soluções similares disponíveis em outros órgãos e no Portal do Software Público Brasileiro Não existe solução similar disponível através do portal do Software Público Brasileiro ou disponibilizada através de outros órgãos, sem custos para o TST ou a ser utilizada de forma livre.
2.9 Levantamento de mercado
A infraestrutura de virtualização de servidores do TST é do fabricante VMware.
De maneira geral, há no mercado diversos fabricantes que oferecem soluções de virtualização de rede, chamadas de Redes Definidas por Software, ou SDN da sigla em inglês.
Existem 3 escopos distintos para a solução de rede em um datacenter: rede apenas física, rede virtualizada apenas para ambiente virtual e rede virtualizada que abrange ambiente virtual e físico. Os fabricantes que oferecem apenas rede física não são o escopo deste estudo. Estão entre os fabricantes que oferecem rede virtual e/ou hardware, segundo o Gartner Group:
● Arista Networks;
● Cisco;
● Cumulus Networks;
● Dell EMC;
● Extreme;
● H3C;
● HPE (Aruba);
● Huawei;
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
● Juniper Networks;
● NVIDIA-Mellanox Technologies;
● VMware.
Entre esses fabricantes, o único que oferece rede apenas virtual é a VMware, não possuindo hardware de rede em seu portfólio. Os demais fabricantes oferecem a estrutura de SDN associado aos seus próprios equipamentos físicos e a de terceiros em alguns casos, mas todos oferecem também hardware, diferentemente da VMware. No entanto, para que os seus softwares de SDN possam oferecer funcionalidades de rede e segurança para o ambiente virtual VMware, é necessário que o ambiente virtual tenha entre seus componentes os softwares de rede Virtual da VMware, denominado NSX. Ou seja, para o uso de qualquer plataforma de SDN que seja integrado com o ambiente virtual da VMware é necessário adquirir, também, licenças de uso do VMware NSX.
O ambiente de servidores do TST é praticamente 100% virtualizado. Apenas os bancos de dados de produção ainda se encontram em máquinas físicas. Até mesmo os bancos de dados de desenvolvimento e homologação já estão no ambiente virtual e há planos para migrar até o ambiente de banco de dados de produção. Assim, todo o tráfego de rede dos sistemas informatizados do TST trafega, necessariamente, pelo ambiente virtual, sejam eles hospedados em VMs ou containers.
Se para a integração com o ambiente virtual VMware é necessário possuir licenças para o SDN da VMware e praticamente toda a carga de trabalho se encontra no ambiente virtual, para atender à necessidade o TST basta as licenças do VMware NSX.
Apesar do exposto, considerando a velocidade com que novos produtos e soluções de TI são lançadas diariamente pelos mais diversos fabricantes, podem haver no mercado soluções que atendam às necessidades do TST e se integrem com a solução de virtualização da VMware sem a necessidade de licenças do NSX, ou então que use a versão mais simples e barata do NSX e ofereça as demais funcionalidades através de outro software, mais barato que a versão do NSX que atenderia plenamente as necessidades do TST.
Desconhecendo se a única solução é realmente o NSX da VMware e considerando a possibilidade de um fabricante atender a necessidade do TST entregando juntamente com a sua solução licença de alguma versão básica do NSX e, assim, alcançar preços mais competitivos, não é razoável nomearmos a solução para o VMware NSX.
2.10 Justificativas da escolha do tipo de solução a contratar
A virtualização da rede por software é o que irá permitir a agilidade, flexibilidade e segurança para as novas aplicações desenvolvidas no modelo de nuvem ao mesmo tempo garantir a segurança para o legado. Também criará os alicerces que permitirão o uso de nuvem híbrida (pública e privada), onde as cargas de trabalho poderão usufruir, quando necessário, do poder computacional da nuvem pública de maneira transparente para os usuários, sem perda de agilidade, segurança e de forma automatizada.
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
É premissa que a solução ofertada seja integrada com a solução de virtualização do fabricante VMware e que é amplamente utilizada na infraestrutura de TI do TST. O processo 501.248/2020 tratou da renovação da garantia e suporte do ambiente atual. Em seus estudos preliminares, foi realizado ampla comparação técnica e de custo da solução atual e as demais existentes no mercado, onde chegou-se à conclusão que a melhor escolha, técnica e econômica, é renovar a solução de virtualização atual. Assim, juntamente com o já exposto sobre o percentual de uso do ambiente virtual pelos sistemas do TST, definiu-se a premissa que a solução de SDN a ser adquirida precisa, necessariamente, se integrar com a solução da VMware utilizado no TST.
Assim, para atender a demanda de agilidade da rede, melhoria na segurança e no monitoramento para máquinas virtuais e contêineres e cumpra os requisitos de integração com o ambiente atual, foram definidos requisitos que poderão ser atendidos pela VMware, com a gama de produtos e licenças que compõem o seu SDN, ou por outros eventuais fabricantes, desde que mantida a integração desejada.
Segundo o fabricante VMware, para atender os requisitos levantados para a solução de SDN é necessário licença combinada do NSX em sua versão Datacenter Enterprise Plus com outro produto denominado vRealize Network Insight ou vRNI. Assim, para cada CPU utilizada no ambiente dentro da solução da VMware é necessária uma licença do NSX Data Center Enterprise Plus e uma licença complementar denominada “vRealize Network Insight 6 Enterprise Add-on to VMware NSX Data Center”.
Reiteramos que, conforme pesquisa de mercado em conversas com fornecedores e fabricantes, qualquer solução de virtualização de rede para o ambiente VMware requer, necessariamente, o NSX, e que o único fabricante, até a presente data (27/10/2020), que atende aos requisitos presentes neste estudo, especialmente a integração e compatibilidade com o ambiente de virtualização atual, é também a VMware com as licenças citadas. No entanto, a equipe de planejamento da contratação não entendeu necessário a nomeação para a VMware, pois como exposto, podem existir fabricantes que atendam a necessidade do TST e que, dentro da proposta ofertada, ofereçam uma licença mais barata do NSX e as demais funcionalidades serem atendidas por seu próprio software. Essa é a razão das especificações terem sido detalhadas, ainda que, até onde nos é de conhecimento, só o produto da VMware às atende.
Assim, entendemos que essa abordagem trata o risco de existir mais de uma solução que eventualmente atenda a necessidade do TST e ela ser descartada por estarmos nomeando a licitação para um fabricante específico.
2.11 Estimativas preliminares dos preços
Diante da necessidade apresentada, foram realizados pedidos de cotação para as seguintes empresas:
● ITWare - contato: Fabrício Carpanez xxxxxxxx@xxxxxx.xxx.xx ;
● PPN - contato: Xxxxx Xxxxx xxxxx.xxxxx@xxxxxxxxxxxxx.xxx.xx ;
● Compwire - contato Xxxxxxx Xxxxx xxxxxxx.xxxxx@xxxxxxxx.xxx.xx ;
Também encontramos no site comprasnet 3 pregões com aquisição de licenças do VMWare NSX em sua versão Enterprise Plus. São eles:
● TSE - Pregão 65/2019 - UASG 70001 - Item 12;
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
● Ministério da Previdência Social - Pregão 579/2018 - UASG 238014 - Item 1;
● XXX xx 0x Xxxxxx - Xxxxxx 36/2017 - Itens 12 e 13 - UASG 90031.
As licenças da VMware são dolarizadas, ou seja, seu preço em moeda nacional varia conforme o valor do dólar. Considerando a significativa variação do dólar nos últimos meses e que os pregões possuem até 3 anos de diferença para a estimativa de licitação do TST, para a análise de preços é necessário considerar a cotação do dólar no dia do pregão e compará-los com os valores atuais. Será considerado como valor atual do dólar a cotação em 27/10/2020, cujo valor de compra encerrou em R$ 5,64 segundo o site do Banco Central.
Outro fator a ser considerado é que nos pregões citados não há a licença para o vRNI, apenas nas propostas. No entanto, a solução a ser adquirida é atendida através desses dois produtos combinados. Como solicitamos as propostas com os valores discriminados de cada licença que compõem a solução e suas respectivas garantias em 3 modelos distintos, 12, 36 e 60 meses, nos é possível comparar os preços das propostas com os valores das licitações e avaliar se as propostas estão em acordo com os preços praticados no mercado. Reforçando que a comparação só pode ser equânime se considerado a variação de cotação do dólar. A tabela abaixo contém a data de realização de cada pregão e a cotação do dólar no dia, conforme informação retirada do site do Banco Central, comparado com o dólar atual:
Preço Público | Data | Dólar na data do pregão | Ajuste para trazer preço para dólar atual |
TSE | 28/11/2019 | R$ 4,24 | +33,02% |
Ministério da Previdência Social | 04/06/2018 | R$ 3,74 | +50,80% |
TRF5 | 12/09/2017 | R$ 3,11 | +81,35% |
O valor do ajuste foi calculado da utilizando a seguinte fórmula:
(Dólar Atual / Dólar na data do pregão) -1
A 4º coluna, “Ajuste para trazer preço para dólar atual”, representa o acréscimo necessário que se deve fazer no preço do dos pregões para a comparação ser válida.
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
A comparação entre os valores da solução nas propostas e os valores públicos considerou soluções semelhantes, do mesmo fabricante, e teve como base o valor unitário de licença por CPU.
A primeira comparação a ser feita é com relação ao custo anual conforme período de garantia. A tabela abaixo mostra o custo em cada um dos modelos conforme cada proposta e o custo comparativo com o item 13 do pregão do TRF5, único encontrado com preço do suporte separado da licença:
Item
12 meses
36 meses
Anual 36
Desconto 36 60 meses Anual 60 Desconto 60 DIFF TRF5 36
PPN - NSX
R$ 10.576,00 R$ 31.299,35 R$ 10.433,12 -1,37%
R$ R$
51.086,38 10.217,28 -3,51%
-10,09%
PPN - vRNI
R$ 1.182,00
R$ 3.500,23 R$ 1.166,74 -1,31%
R$ R$
5.713,02 1.142,60 -3,45%
ITware - NSX
R$ 10.990,00 R$ 31.198,00 R$ 10.399,33 -5,68%
R$ R$
49.999,00 9.999,80 -9,90%
-10,44%
ITware - vRNI
R$ 1.198,00
R$ 3.486,00 R$ 1.162,00 -3,10%
R$ R$
5.480,00 1.096,00 -9,31%
Compwire - NSX R$ 11.123,00 R$ 32.213,00 R$ 10.737,67 -3,59%
R$ R$
51.342,00 10.268,40 -8,32%
-6,96%
Compwire - vRNI R$ 1.545,00
R$ 3.812,00 R$ 1.270,67 -21,59%
R$
6.100,00
R$
1.220,00 -26,64%
TRF5 - NSX 36 meses com valor do dólar atual R$ 34.456,50
O valor absoluto da garantia de 36 meses no pregão do TRF5 é de R$ 19.000,00. No entanto, aplicado o ajuste para o dólar, acréscimo de 81,35%, o valor relativo com o dólar atual é de R$ 34.456,50, sugerindo que o valor do suporte das propostas está em acordo com o preço praticado no mercado, já que são cerca de 10% menores que o praticado no pregão do TRF5.
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
Outro dado relevante é a comparação entre os valores de desconto da garantia em 12, 36 e 60 meses para a licença de NSX e vRNI. Observa-se que os percentuais são relativamente próximos entre eles, demonstrando consistência no valor apresentado, mesmo sem um preço público para comparação. O valor que destoa é o da proposta da Compwire, no entanto, mostra que há margem para um maior desconto.
Com relação ao desconto na aquisição da garantia de 60 meses comparado com a de 12 meses, entendemos que ele é menos significativo do que imaginávamos, sendo mais relevante apenas na proposta da ITware com pouco mais de 9%. No entanto, no montante total o desconto representa uma economia significativa, pois na proposta com maior desconto, ITware, os 60 meses de garantia adquiridos através de 5 “planos” de 12 meses possui um custo total (NSX e vRNI) de R$ 60.940,00 por licença em 5 anos, totalizando R$ 3.656.400,00 para as 60 licenças. Já o custo da aquisição com a garantia de 60 meses e nas mesmas condições possui um custo por licença de R$ 55.479,00, totalizando R$ 3.328.740,00, uma diferença de R$ 327.660,00.
O pregão do TSE e do Ministério da Previdência Social possuem garantia e licença em um mesmo item, com 36 meses no primeiro e 60 meses no segundo. O pregão do TRF5 separou em itens distintos a licença da garantia, assim como as propostas. Para ser possível comparar preços nos casos onde a garantia e licença estão separadas, ambas precisam ser somadas.
No pregão do Ministério da Previdência Social, não consta na ATA do pregão o valor unitário das licenças, essa informação está no Edital. Foram adquiridas neste pregão 1320 unidades de licenças do software VMware NSX Enteprise Plus, licenciado por CPU.
Para realizar o comparativo entre as propostas e os preços públicos, é necessário desconsiderar das propostas as licenças e garantia do vRNI, pois ainda que ele fará parte da solução, não encontramos preços públicos da versão da licença necessária (Enterprise) do vRNI a fim de para compará-lo.
Os preços absolutos das licenças já considerando a garantia são:
Origem da estimativa | Item | Garantia | Preço licença com garantia |
TSE | 12 | 36 | R$ 57.000,00 |
Ministério da Previdência Social | 1 | 60 | R$ 64.772,52* |
TRF5 | 12 e 13 | 36 | R$ 43.000,00 |
ITWare - 36 meses | - | 36 | R$ 77.178,00 |
ITWare - 60 meses | - | 60 | R$ 95.979,00 |
PPN - 36 meses | - | 36 | R$ 77.741,52 |
PPN - 60 meses | - | 60 | R$ 97.528,55 |
Compwire - 36 meses | - | 36 | R$ 81.100,00 |
Compwire - 60 meses | - | 60 | R$ 100.229,00 |
*: o valor R$ 64.772,52 é alcançado dividindo o valor final do pregão (Ata de Realização do Pregão Eletrônico nº 00579/2018) para o item 1, que é de R$ 85.499.731,20 por 1320 CPUs. Assim, o valor informa o custo por CPU.
Considerando os valores ajustados ao dólar atual, os preços relativos seriam:
Licença com garantia | MPS | TSE | TRF5 | ITWare | Diferença | PPN | Diferença | Compwire | Diferença |
Suporte de 36 meses com dólar atual | - | R$ 75.820,75 | R$ 77.980,71 | R$ 77.178,00 | 1,79% | R$ 77.741,52 | 2,53% | R$ 81.100,00 | 6,96% |
Suporte de 60 meses com dólar atual | R$ 97.678,35 | - | - | R$ 95.979,00 | -1,74% | R$ 97.528,55 | -0,15% | R$ 100.229,00 | 2,61% |
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
Considerando os ajustes na cotação do dólar, a diferença entre os preços públicos e os valores das propostas é irrisória, sendo 6,96% no maior valor com suporte de 36 meses e até 1,74% menor se comparado com garantia em 60 meses.
Com base nesses dados, é possível concluir que os preços ofertados nas propostas estão dentro dos valores praticados no mercado e, assim, a pesquisa de preços pode considerar as propostas recebidas como preços válidos como balizador da licitação, destacando que para 60 meses de garantia, não encontramos preço público mais barato que uma das propostas recebidas pelo TST, mesmo que o pregão do Ministério da Previdência Social tenha tido um quantitativo de licenças mais de 20 vezes maior que o do TST (1320 licenças contra 60 do TST).
Proposta da ITware para a garantia de 60 meses:
XXxxxx- 00 meses | |||
Produto | Quantidade | Valor unitário | Valor total |
NX-DC-EPL-C | 60 | R$ 45.980,00 | R$ 2.758.800,00 |
VMware NSX Data Center Enterprise Plus per Processor | |||
NX-DC-EPL-P-SSS-C (5 anos) | 60 | R$ 49.999,00 | R$ 2.999.940,00 |
Garantia NX-DC-EPL-C | |||
VRNI6-ENTAD-NXEPLP-C | 60 | R$ 4.993,00 | R$ 299.580,00 |
VMWare vRealize Network Insight 6 Enterprise Add-on to VMware NSX Data Center Enterprise Plus (Per Processor) | |||
VRNI6-ENTAD-NXEPLP-P-SSS-C (5 anos) | 60 | R$ 5.480,00 | R$ 328.800,00 |
Garantia VRNI6-ENTAD-NXEPLP-C | |||
R$ 106.452,00 | R$ 6.387.120,00 | ||
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
Proposta da PPN para a garantia de 60 meses:
PPN - 60 meses | |||
Produto | Quantidade | Valor unitário | Valor total |
NX-DC-EPL-C | 60 | R$ 46.442,17 | R$ 2.786.530,20 |
VMware NSX Data Center Enterprise Plus per Processor | |||
NX-DC-EPL-P-SSS-C (5 anos) | 60 | R$ 51.086,38 | R$ 3.065.182,80 |
Garantia NX-DC-EPL-C | |||
VRNI6-ENTAD-NXEPLP-C | 60 | R$ 5.193,65 | R$ 311.619,00 |
VMWare vRealize Network Insight 6 Enterprise Add- on to VMware NSX Data Center Enterprise Plus (Per Processor) | |||
VRNI6-ENTAD-NXEPLP-P-SSS-C (5 anos) | 60 | R$ 5.713,02 | R$ 342.781,20 |
Garantia VRNI6-ENTAD-NXEPLP-C | |||
R$ 108.435,22 | R$ 6.506.113,20 | ||
Proposta da Compwire para a garantia de 60 meses:
Compwire - 60 meses | |||
Produto | Quantidade | Valor unitário | Valor total |
NX-DC-EPL-C | 60 | R$ 48.887,00 | R$ 2.933.220,00 |
VMware NSX Data Center Enterprise Plus per Processor | |||
NX-DC-EPL-P-SSS-C (5 anos) | 60 | R$ 51.342,00 | R$ 3.080.520,00 |
Garantia NX-DC-EPL-C | |||
VRNI6-ENTAD-NXEPLP-C | 60 | R$ 5.120,00 | R$ 307.200,00 |
VMWare vRealize Network Insight 6 Enterprise Add- on to VMware NSX Data Center Enterprise Plus (Per Processor) | |||
VRNI6-ENTAD-NXEPLP-P-SSS-C (5 anos) | 60 | R$ 6.100,00 | R$ 366.000,00 |
Garantia VRNI6-ENTAD-NXEPLP-C | |||
R$ 111.449,00 | R$ 6.686.940,00 | ||
Para compor o preço da solução com a garantia de 60 meses, é preciso considerar a soma individual de cada item nas propostas. Considerando o menor preço em cada item (destacado de verde nas tabelas), entendemos que o preço máximo unitário a ser considerado para a solução deva ser de R$ 106.452,00, totalizando R$ 6.387.120,00 para a aquisição de 60 licenças.
Esse valor é 8,91% superior à estimativa orçamentária de R$ 5.864.447,40. Considerando que há uma esperada redução no preço durante o processo de licitação, acreditamos que o valor total se aproxime do valor orçamentário estimado, podendo ficar inferior.
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
2.12 Descrição da solução de TI como um todo
Trata-se da aquisição de solução de software de virtualização e segurança de rede, com garantia de 60 meses prestada pelo fabricante para o ambiente virtual VMware utilizando no TST.
2.13 Resultados pretendidos
Os resultados pretendidos são:
● Aprimorar a segurança das aplicações;
● Aumentar a capacidade de monitoramento e análise da comunicação;
● Garantir a agilidade necessária para entrega de novos serviços de rede;
● Criar o alicerce necessário para o uso futuro de nuvem pública sem comprometer a segurança e a agilidade na entrega dos sistemas informatizados do TST.
2.14 Providências para adequação do ambiente do órgão
Trata o Estudo Técnico da aquisição de solução de software de virtualização e segurança de rede. Não há adequação a ser realizada neste cenário, uma vez que a mudança se dará apenas virtualmente.
2.15 Plano de implantação
Trata o Estudo Técnico de aquisição de solução de software de virtualização e segurança de rede. A implantação será realizada pela equipe técnica da área de infraestrutura de TI do TST.
3. Sustentação do Contrato
3.1 Recursos necessários para continuidade de negócio durante e após a contratação Considerando que a solução sugerida por este Estudo Técnico trata de aquisição de garantia de suporte técnico e atualização de virtualização de rede e segurança, ao fato das licenças adquiridas serem perpétuas e também ao fato da própria equipe técnica de TI do TST é que ficará responsável pela gestão das redes virtuais, os recursos humanos e recursos materiais necessários à continuidade do objeto contratado/adquirido estarão no TST mesmo após a contratação.
3.2 Elementos necessários à continuidade do fornecimento da solução
É uma aquisição de solução de software com garantia de 60 meses, por pagamento único. Portanto, teremos a garantia do fabricante para o funcionamento do software por esse período.
3.3 Transição contratual ou encerramento do contrato
No caso, quando da transição contratual deverá ser realizada a migração no caso de outra solução vir a substituir a atual. No caso do encerramento sem prorrogação, a nossa licença é perpétua e podemos utilizá-la sem atualizações ou suporte técnico com o fabricante.
3.3.1 Entrega de produtos finais
A solução com garantia de 60 meses serão consideradas entregues quando as licenças estiverem presentes na conta do TST vinculada ao fabricante. Caso o TST não possua conta com o fabricante, ela deverá ser previamente criada. Será mandatório que esteja discriminado na conta o quantitativo de licenças e o período de garantia, com data de início e fim.
3.3.2 Transferência de conhecimentos
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
Todo aceso de terceiro com vista a prestação de serviço de garantia por parte do fabricante da solução de software terá seu conhecimento repassado aos técnicos responsáveis pela infraestrutura de virtualização de redes do Tribunal.
3.3.3 Devolução de recursos materiais
Por se tratar de aquisição de solução de software com garantia de 60 meses, este item não se aplica.
3.3.4 Revogação de perfis de acessos
Qualquer acesso fornecido para acesso de terceiros com vista a prestação de serviço de garantia da solução de software será revogado tão logo a solução seja dada pelo fabricante.
3.3.5 Direitos de propriedade intelectual
Por se tratar de aquisição de solução de software com garantia de 60 meses, este item não se aplica.
4. Estratégia para Contratação
4.1 Natureza do objeto a ser contratado
Trata-se da aquisição de solução de software de virtualização de rede e segurança para a infraestrutura de TI do TST. A garantia serve para permitir atualizações e suporte do fabricante. Seus padrões de desempenho e qualidade podem ser objetivamente definidos pelo edital, por meio de especificações usuais no mercado. Portanto, a natureza do objeto a ser contratado é de bem/serviço comum.
4.2 Justificativas para o parcelamento ou não da solução
Considerando que trata de licença de software com garantia vinculada ao próprio, o parcelamento da solução não apresenta qualquer benefício.
4.3 Adjudicação do objeto
Conforme determina a legislação e os posicionamentos do Tribunal de Contas da União, o objeto está fracionado em suas menores partes e podem ser adjudicados a diversas empresas, não estando agrupados para fins de adjudicação.
4.4 Modalidade e tipo de licitação
Propomos a realização de pregão eletrônico.
4.5 Adequação orçamentária
Consta no Plano de Contratações de STIC 2020 a Ação Orçamentária 2020-AO-032, valor estimado de R$ 5.864.447,40.
4.6 Vigência
O contrato terá vigência de 60 (sessenta) meses, a contar do recebimento definitivo do objeto.
4.7 Equipe de Gestão da Contratação
A Equipe de Gestão da Contratação será designada pela Coordenadoria de Material e Logística quando da assinatura do contrato, uma vez que a fase de gestão e fiscalização do contrato se inicia com a assinatura do contrato e visa acompanhar e garantir a adequada prestação dos serviços e/ou o fornecimento dos bens durante o período de execução do contrato.
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
5. Análise de Riscos da Contratação
O contexto aplicado à contratação seguirá o contexto geral especificado no Plano de Gestão de Riscos definido no Ato XXXX.XXXX.XX Nº 131, de 13 de março de 2015, que dispõe sobre a Política de Gestão de Riscos.
Complementarmente ao contexto geral, também serão considerados como parâmetros aqueles definidos na Resolução CNJ Nº 182, de 17 de outubro de 2013:
i) riscos que possam vir a comprometer o sucesso da contratação; e
ii) riscos que emergirão caso a contratação não seja realizada.
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
5.1 Riscos que podem comprometer o sucesso da contratação
N º | Descrição do Risco | Probabilidad e de Ocorrência | Impacto | Ações de mitigação ou contingência | Responsáveis pelas ações | Período de execução das ações |
1 | Contingenciamento orçamentário | Baixa | Alto | Verificar possibilidade de adequação orçamentária de outras fontes | Administração do TST | Quando da ocorrência |
2 | Não aprovação dos artefatos do planejamento da contratação | Média | Médio | Realização de novo processo licitatório | Equipe de Planejamento da Contratação | Quando da ocorrência |
3 | Atraso no processo ou suspensão do certame licitatório em face de impugnações | Média | Médio | Antecipar-se a possíveis questionamentos de licitantes | Equipe de Planejamento da Contratação | Planejamento da contratação |
4 | Licitação deserta | Baixa | Alto | Ser claro na especificação do objeto e submeter o Termo de Referência a especialista do mercado a fim de observar se não há itens inexequíveis na especificação | Equipe de Planejamento da Contratação | Planejamento da contratação |
5 | Incapacidade de execução do contrato | Baixa | Alto | Definição de níveis de serviços baseados em contratações anteriores, em conformidade com a necessidade do TST | Equipe de Planejamento da Contratação | Planejamento da contratação |
6 | Tempo para atendimento de resolução de incidentes insatisfatório | Baixa | Alto | Necessidade do Tribunal | SGSB | Planejamento da contratação |
7 | Inobservância dos procedimentos formais previstos na Res. CNJ nº 182/2013 e outras leis | Baixa | Alto | Revisões dos artefatos de contratação por diversos setores do Tribunal | Equipe de Planejamento da Contratação | Planejamento da contratação |
8 | Limitar a concorrência a um único fabricante sem a certeza absoluta que há apenas uma solução de mercado que atende a necessidade | Baixa | Alto | Realizar a licitação com base nos requisitos | Equipe de Planejamento da Contratação | Planejamento da contratação |
9 | Aquisição de solução não compatível com o ambiente do TST | Baixa | Alto | Especificar claramente a necessidade de compatibilidade com ambiente VMware e exigir a comprovação dos requisitos do vencedor. | CITEC | Imediata |
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
5.2 Riscos caso a contratação não seja realizada
Nº | Descrição do Risco | Probabilidad e de Ocorrência | Impacto | Ações de mitigação ou contingência | Responsáveis pelas ações | Período de execução das ações |
1 | Aumento nos gaps de segurança a medida que o ambiente de VMs e containers crescem. | Alta | Alto | Providenciar contratação de solução de SDN | CITEC | Imediata |
2 | Aumento da incapacidade de responder rapidamente a problemas de rede no ambiente de virtualização e contêineres, a medida que esse ambiente cresce. | Alta | Alto | Providenciar contratação de solução de SDN | CITEC | Imediata |
3 | Aumento na dificuldade na governança dos recursos virtuais de rede a medida que o ambiente cresce | Xxxxx | Xxxxx | Providenciar contratação de solução de SDN | CITEC | Imediata |
4 | Tempo para entrada de novas aplicações em produção aumenta conforme cresce o ambiente virtual. | Xxxxx | Xxxxx | Providenciar contratação de solução de SDN | CITEC | Imediata |
6. Equipe de Planejamento e Apoio à Contratação
Este documento pode ser acessado no endereço eletrônico xxxx://xxx.xxx.xxx.xx/xxxxxxxxx sob código A502029200017YB41B
O presente Estudo Técnico Preliminar foi elaborado pela Equipe de Planejamento e Apoio à Contratação e os aspectos administrativos da contratação foram devidamente verificados pelo integrante administrativo, sendo aprovado pela área demandante e área administrativa.
10/11/2020 | Integrante Técnico Xxxxxxx Xxxxxxxx xx Xxxxx Xxxxxxxx cód.: Matrícula: 39337 | Xxxxxxx Xxxxxxxx de forma digital por Xxxxxxx Xxxxxxxx xx Xxxxx Xxxxxxxx Xxxxxxxx da DN: cn=Xxxxxxx Xxxxxxxx xx Xxxxx Xxxxxxxx, o=Tribunal Superior do Trabalho, ou=SETIN, Xxxxx Xxxxxxxx Xxxxx: 2020.11.11 12:42:54 -03'00' xxxxxxxxxxxxx.xxxxxxxx@xxx.xxx.xx, c=<n Assinatura |
10/11/2020 | Integrante Requisitante Xxxxxxxx Xxxx Xxxxxxxxx cód.: 42780 | Xxxxxxxx Xxxxxxxx de forma digital por Xxxxxxxx Xxxx Xxxxxxxxx DN: cn=Xxxxxxxx Xxxx Xxxxxxxxx, Lobo Pulcineli o=Tribunal Superior do Trabalho, ou=TST, xxxxxxxxxxxxxx.xxxxxxxxx@xxx.xxx.xx, c=BR Dados: 2020.11.10 17:11:30 -03'00' Assinatura |
10/11/2020 | Integrante Administrativo Xxxxxxx Xxxxxx Xxxxxxxx cód.: 31268 | Assinado de forma digital por Xxxxxxx Xxxxxxx Xxxxxx DN: cn=Xxxxxxx Xxxxxx Xxxxxxxx, Xxxxxx Xxxxxxxx o=Tribunal Superior do Trabalho, Xxxxxxxx ou=CLCON/SRPAQ, xxxxxxxxxxxxx.xxxxxxxx@xxx.xxx.xx, c=BR Dados: 2020.11.11 11:30:57 -03'00' Assinatura |