ANEXO II TERMO DE REFERÊNCIA

I - OBJETO - REGISTRO DE PREÇOS para eventual contratação de empresa para fornecimento de licenças de uso de plataforma tecnológica em cloud computing (PaaS) com recursos de gestão, controle e cyber segurança e conectividade móvel, além da locação de modens Wi-Fi portáteis, de forma a viabilizar o acesso de alunos e professores às ferramentas de ensino remoto disponibilizadas pela Secretaria Municipal de Educação do Município de Nova Lima.

2 – DA JUSTIFICATIVA PARA CONTRATAÇÃO DO OBJETO

A COVID-19 passou a exigir dos setores público e privado a necessidade de implementação de infraestrutura e ferramentas para viabilização de um modelo de educação remota. Para suprir essa demanda, além do esforço e comprometimento de alunos, professores e servidores, em contrapartida a Secretaria da Educação do município vem implementando diversas medidas para enfrentar essa nova realidade e, nesse contexto vem realizando esforços para disponibilizar uma infraestrutura que comporte a transmissão, acompanhamento e gestão do conteúdo transmitido.

Para permitir o acesso à educação remota é necessário disponibilizar aos alunos e professores o acesso (via Internet) a conteúdos públicos ou a servidores de conteúdo digital utilizados pela Secretaria da Educação ou ainda a ambientes disponibilizados por instituições terceiras, como o Ministério da Educação, fundações ou ao ambiente digital WEB de empresas contratadas pela administração pública.

Além disso, cabe à Secretaria de Educação a gestão dos acessos feitos pelos usuários aos conteúdos e a gestão do uso/consumo do pacote Internet disponibilizado, como forma de assegurar que o recurso cedido seja utilizado exclusivamente para fins educacionais. Desta forma, haverá a garantia da correta e eficaz aplicação dos recursos financeiros destinados nesta ação.

Um grande passo para se obter sucesso em medidas de gestão, especialmente em se tratando da rede pública de ensino, ampla e complexa, é estar amparado por ferramentas de suporte e de informação, ou seja, os gestores deverão contar com uma plataforma tecnológica onde possam ter informações sobre a aplicação e utilização dos acessos à internet pelos usuários (alunos e professores) contemplados com o recurso.

A necessidade de visualização de dados e de medição de desempenho na utilização da infraestrutura disponibilizada aos alunos e professores é parte da gestão escolar. Os sistemas de informação subsidiam gestores em suas decisões e escolhas, permitindo uma melhor tomada de decisão e auxílio em políticas educacionais. A exigência cada vez maior em aperfeiçoar os níveis dos resultados educacionais, bem como gerar e fortalecer mecanismos de transparência e responsabilização para os cidadãos e partes

interessadas geram a necessidade da administração pública em implantar plataformas tecnológicas informacionais que permitam desenvolver e implementar indicadores de desempenho.

Neste sentido, é necessário a disponibilização de plataforma tecnológica composta de hardwares, softwares e serviços técnicos especializados para a realização efetiva do monitoramento e da gestão da conectividade de alunos e professores, além da locação de modens Wi-Fi portáteis. O escopo especificado permitirá à Secretaria de Educação a gestão da utilização de recursos pelos alunos, professores e colaboradores da Secretaria de Educação envolvidos no processo.

3. OBJETIVOS

A contratação da solução definida neste Termo de Referência tem como foco alcançar os seguintes objetivos:

• Garantir que os recursos financeiros da Educação sejam aplicados exclusivamente para fins educacionais;

• Prover ferramentas tecnológicas e conectividade aos alunos da rede escolar, garantindo acesso aos recursos de educação remota implementados e estabelecidos pela secretaria de educação por meio de sua área pedagógica e de tecnologia educacional;

• Garantir a correta utilização dos recursos de acesso à Internet por parte dos alunos e professores;

• Garantir que apenas conteúdos e ferramentas autorizadas pela Secretaria de Educação possam ser acessados pelos alunos e professores (usuários);

• Monitorar o tipo e o volume do tráfego de dados realizado dentro da infraestrutura de educação disponibilizada, permitindo ajustes e melhorias constantes. Monitoramento e a avaliação contínuas permitirão o aperfeiçoamento desta nova e recente iniciativa acelerada bruscamente pela pandemia do COVID-19.

• Permitir a gestão e monitoramento dos equipamentos e dos recursos oferecidos aos usuários envolvidos no processo de educação remota;

• Minimizar o problema da falta de cobertura e ausência de conectividade em localidades específicas e remotas, contando com redes alternativas que somam duas áreas de cobertura para melhor atendimento dos usuários nas localidades com mais restrições de infraestrutura de acesso;

• Disponibilizar um mecanismo de acesso que viabilize acesso a conteúdos digitais por diversos canais, tais como: navegadores web, aplicativos mobiles, e-mails, mensagens instantâneas, dentre outras modalidades que possam surgir com a evolução tecnológica;

4. TOPOLOGIA DA SOLUÇÃO

A CONTRATADA será responsável por toda a infraestrutura tecnológica desde o fornecimento dos dispositivos de acesso, os meios de acesso ao conteúdo, filtros de

acesso e as infraestruturas técnicas de processamento, de segurança e de privacidade dos usuários.

Todo o tráfego de dados demandados pelos usuários deverá ser direcionado e processado pela Plataforma Tecnológica de Gestão e Controle dos Acessos e Conectividade da CONTRATADA, neste documento chamada de PLATAFORMA. Esta PLATAFORMA realizará os filtros de conteúdo ou restrições de acesso aplicáveis a cada perfil de usuário, (aluno por série, professor ou servidor administrativo), de acordo com as autorizações definidas pela equipe da Secretaria no momento do cadastro de cada usuário envolvido ou contemplado.

O dispositivo de acesso, componente que irá viabilizar a identificação dos usuários e o acesso à PLATAFORMA, permitindo que o aluno ou professor tenha acesso às ferramentas, conteúdo e Internet de qualquer local, desde que esteja sob área de cobertura de uma das redes de conectividade habilitadas pela CONTRATADA. Por meio do dispositivo de acesso o aluno terá acesso restrito e controlado às ferramentas de conteúdo e educação remota e à Internet, sempre seguindo as regras de acesso definidas pela CONTRATANTE.

A PLATAFORMA fornecida pela CONTRATADA realizará toda a checagem de autorização permitindo o acesso dos usuários apenas aos conteúdos online autorizados ou aos servidores de conteúdo digital adotados pela Secretaria de Educação. Toda política de acesso será definida pela CONTRATANTE e implementada pela CONTRATADA.

A PLATAFORMA deve estar munida de equipamentos (hardwares) e softwares capazes de processar todo o tráfego demandado pelos usuários da CONTRATANTE, gerir todos os filtros e armazenar todos os logs para posterior criação de dashboards e relatórios como demonstrado na Figura 1, e para isso deve ser composta pelos componentes especificados no ANEXO I do termo de referência.

ALUNOS TABLETS / SMARTPHONES MODEM WI-FI PORTÁTIL

Figura 1: Topologia da solução.

A CONTRATADA deverá ainda prover a locação de modens Wi-Fi portáteis para atendimento aos professores, de forma que tais profissionais possam dispor de uma rede Wi-Fi para conexão dos dispositivos utilizados durante o processo educacional. A rede Wi-Fi oferecida deverá seguir os padrões técnicos de mercado, ter a mobilidade e a portabilidade necessária para viabilizar a conectividade dos diversos dispositivos utilizados pelos professores (notebooks, chromebooks, smart TVs, smartphones, dentre outros). Nos modens Wi-Fi portáteis serão incluídos os dispositivos de acesso contratados para atendimento aos professores, de forma que a conectividade gerenciada e controlada possa ser acessada dos diversos dispositivos utilizados pelo professor.

5. DESCRIÇÃO DOS SERVIÇOS E DA PLATAFORMA TECNOLÓGICA

5.1 A PLATAFORMA é fruto de uma integração e composta por dispositivos de hardware, softwares e serviços técnicos especializados com o objetivo de permitir o acesso aos recursos de educação remota, fornecidos pela Secretaria de Educação do município para alunos e servidores.

5.2 A PLATAFORMA compreende uma solução tecnológica, resultado da integração de diversas ferramentas e tecnologias, com operação em nuvem (cloud computing), e está classificada em órgãos a exemplo da ANATEL como um SVA – Serviço de Valor Adicionado, de forma que não é requerido às Licitantes as homologações, autorizações ou certificações para exploração de serviços específicos de telecomunicações.

5.3 Este certame licitatório tem como objetivo a contratação, em lote, por critério de seleção de menor valor global para os seguintes itens:

LOTE

ITEM

DESCRIÇÃO

UNIDADE

QUANT.

PRAZO

LICENÇAS DE USO DE PLATAFORMA TECNOLÓGICA EM CLOUD COMPUTING (PAAS) COM RECURSOS GESTÃO, CONTROLE, CONECTIVIDADE MÓVEL E CYBER

SEGURANÇA PARA VIABILIZAR O ACESSO DE

ALUNOS ÀS FERRAMENTAS

LICENÇA DE USO ANUAL (SUBSCRIÇÃO)

10.000

N/A

O T E 1		DE ENSINO REMOTO. LICENÇA COM CAPACIDADE DE PROCESSAMENTO DE 60 GB/ANO.
O T E 1	2	LICENÇAS DE USO DE PLATAFORMA TECNOLÓGICA EM CLOUD COMPUTING (PAAS) COM RECURSOS GESTÃO, CONTROLE, CONECTIVIDADE MÓVEL E CYBER SEGURANÇA PARA VIABILIZAR O ACESSO DE PROFESSORES ÀS FERRAMENTAS DE ENSINO REMOTO. LICENÇA COM CAPACIDADE DE PROCESSAMENTO DE 120 GB/ANO.	LICENÇA DE USO ANUAL (SUBSCRIÇÃO)	1.000	N/A
LOTE 2	3	MODEM WI-FI PORTÁTIL	LOCAÇÃO MENSAL	750	12
LOTE 3	3.1	MODEM WI-FI PORTÁTIL	LOCAÇÃO MENSAL	250	12

5.4 Não faz parte da PLATAFORMA a ser oferecida pela CONTRATADA a aquisição de equipamentos como notebooks, tablets, smartphones, que poderão ser objeto de processo licitatório distinto.

5.5 Plataforma de Gestão e Controle dos Acessos e Conectividade (PLATAFORMA):

5.5.1 A PLATAFORMA é uma solução composta por hardware, software e serviços técnicos especializados que devem ser fornecidos pela CONTRATADA em infraestrutura própria sem necessidade de qualquer tipo de contratação de infraestrutura por parte da CONTRATANTE.

5.5.2 A PLATAFORMA deve permitir a criação de perfis de usuários em acordo com a necessidade da CONTRATANTE, onde estarão todas as parametrizações e eventuais customizações necessárias para acesso ao conteúdo por parte dos alunos, professores e colaboradores da Secretaria de Educação.

5.5.3 Os Perfis de usuários deverão possuir lista de liberação de acesso (whitelist) específicos. Cada série/ano da educação básica deverá possuir um respectivo Perfil válido para todos os alunos desta série.

5.5.4 Os Professores deverão possuir Perfil específico, com acesso gerenciado e controlado a partir de uma lista de endereços bloqueados (blacklist).

5.5.5 A PLATAFORMA fornecido pela CONTRATADA deverá disponibilizar um ambiente WEB com possibilidade de inclusão e visualização de, no mínimo, os seguintes campos de para cadastramento de dados:

5.5.5.1 Das escolas: Nome da escola, Endereço completo da escola, Gestor da escola, E- mail do gestor da escola e Diretor da escola;

5.5.5.2 Das turmas: Nome da escola, Série/Ano e Número da turma;

5.5.5.3 Dos alunos: Nome da escola, Série, Ano letivo, Número da turma, Nome do aluno, Matrícula, Ano de nascimento e Endereço.

5.5.6 A PLATAFORMA deve possuir sistema de varredura e auditoria de inconsistências nos dados fornecidos pela CONTRATANTE, apresentando:

5.5.6.1 Relatório de cadastros duplicados ou aluno com mais de um cadastro.

5.5.6.2 Relatório de cadastros incompletos.

5.5.6.3 Relatório de duplicidade em turmas e escolas.

5.5.6.4 Para o caso de duplicidade ou inconsistência nos cadastros o sistema deve apresentar alarme informando o erro, para que medidas cabíveis possam ser tomadas.

5.5.7 A CONTRATADA deve possuir equipe técnica especializada na parametrização da PLATAFORMA que será responsável por incluir o Banco de Dados disponibilizado e exportado pela CONTRATANTE.

5.5.8 Os requisitos técnicos mínimos da PLATAFORMA estão especificados no ANEXO I do termo de referência e as funcionalidades básicas estão detalhadas neste item.

5.5.9 A PLATAFORMA deve possuir integrado à sua infraestrutura e aos bancos de dados um aplicativo ou ambiente web para que a equipe da CONTRATANTE realize a ativação dos dispositivos de acesso.

5.5.10 Características Gerais da PLATAFORMA:

5.5.10.1 Deve possuir mecanismos de gerenciamento de senhas, expiração, bloqueio, alteração, reset, histórico dos colaboradores, alunos e professores da secretaria de educação.

5.5.10.2 Deve permitir mecanismos de extração, transformação e carga de dados.

5.5.10.3 Todas as aplicações e infraestrutura tecnológica necessária para o pleno funcionamento da PLATAFORMA devem estar instaladas em Data Center com

certificação TIER III disponibilizado pela CONTRATADA conforme especificado no ANEXO I do termo de referência.

5.5.10.4 A PLATAFORMA deve possuir 4 tipos de Perfis de Utilização: Administrador, Professor, Aluno e Cadastrador Detalhados a seguir:

5.5.10.4.1 O Perfil de Utilização Administrador será utilizado pela CONTRATADA para realizar criação e parametrização dos usuários no módulo de Gerenciamento de acordo com os Perfis de Utilização definidos.

5.5.10.4.2 O Perfil de Utilização Professor será utilizado pela CONTRATANTE e deve permitir a visualização dos endereços de acesso (urls e aplicativos) ao conteúdo e materiais definidos pela Secretaria de Educação e visualização dos conteúdos de todas as turmas de responsabilidade do professor.

5.5.10.4.3 O Perfil de Utilização Aluno deve permitir a visualização do conteúdo definido para sua respectiva turma e matéria.

5.5.10.4.4 O Perfil de Utilização Cadastrador terá apenas acesso ao APP ou ambiente WEB e seus menus suspensos que possuirão as informações pré-definidas por meio das parametrizações dos bancos de dados fornecidos pela CONTRATANTE.

5.5.10.5 A PLATAFORMA deve permitir aos gestores da CONTRATANTE realizar manutenção do cadastro a qualquer momento pós-implantação da solução, permitindo editar todos os itens referentes às etapas dos cadastramentos, essas manutenções deverão ser executadas pelo Service Desk da CONTRATADA.

5.5.10.6 A PLATAFORMA é responsável por garantir a conectividade ao conteúdo acessado pelos alunos seja o definido pelas regras de segurança da Secretaria de Educação.

5.5.10.7 A PLATAFORMA deve monitorar os Dispositivos de Acesso.

5.5.10.8 A PLATAFORMA deve permitir a inserção, retirada e edição dos endereços de conteúdo a serem disponibilizados aos alunos, de acordo com os Perfis de Utilização pré-definidos pela CONTRATANTE. Essas retiradas e edições devem ser executadas pelo Service Desk da CONTRATADA por meio de Ordem de Serviço aberta pela CONTRATANTE.

5.5.10.9 A PLATAFORMA deve registrar todas as alterações realizadas na lista de conteúdo, registrando quem fez a alteração, a data, o horário e qual conteúdo foi adicionado, retirado ou atualizado.

5.5.10.10 A PLATAFORMA deve permitir inserir os dias da semana e horários em que o conteúdo estará liberado para acesso dos alunos.

5.5.10.11 A definição dos dias e horários só deve ser permitida para a lista de conteúdos de forma única, não sendo possível atribuir dias e horários diferentes para as diversas opções da lista.

5.5.10.12 Deve conter filtros na tela de acesso com o intuito de facilitar a pesquisa e visualização dos conteúdos.

5.5.10.13 Deve possuir aplicação instalada no dispositivo de acesso a fim de garantir o encaminhamento do tráfego de acordo com as regras pré-estabelecidas, com isso o aluno só deve ter acesso ao conteúdo pré-definido em perfil.

5.5.10.14 Todos os dados de status, localização e nível de utilização do dispositivo de acesso e do volume de consumo de internet devem ser consolidadas em relatórios diários, semanais e mensais.

5.5.10.15 A plataforma deve permitir a geração de mapa de calor exibindo a concentração de Dispositivos de Acesso de acordo com a última localização para cada Dispositivo de Acesso.

5.5.10.16 O mapa de calor gerado deve possibilitar a aproximação e distanciamento na sua visualização, e possuir escala de cores para concentração dos Dispositivo de Acesso.

5.5.10.17 Deve gerar alarmes de usuários com utilização fora do compliance definido, permitindo ações da CONTRATANTE seja com alunos, professores ou servidores da Secretaria de Educação.

5.5.10.18 Deve possibilitar a restrição de forma automática do uso do Dispositivo de Acesso sempre que ferir regras do compliance ou a pedido da CONTRATANTE.

5.5.10.19 A Plataforma deve possuir menu no dashboard com no mínimo as seguintes opções, relacionadas ao gerenciamento dos Dispositivos de Acesso:

5.5.10.19.1 Bloquear Dispositivo de Acesso. 5.5.10.19.2 Reativar Dispositivo de Acesso. 5.5.10.19.3 Suspender Dispositivo de Acesso. 5.5.10.19.4 Cancelar Dispositivo de Acesso. 5.5.10.19.5 Troca de ICCID.

5.5.10.19.6 Substituir Dispositivo de Acesso.

5.5.10.19.7 Migrar proprietário do Dispositivo de Acesso. 5.5.10.19.8 Informações do cliente.

5.5.10.19.9 Manutenção de quarentena.

5.5.11 Do aplicativo ou ambiente web fornecido pela CONTRATADA

5.5.11.1 Deve consultar o banco de dados parametrizado na etapa de implantação trazendo automaticamente em formato de menu suspenso as informações de escola, turma e aluno, e devem possuir as seguintes funcionalidades:

5.5.11.1.1 No caso de APP ser compatível com os sistemas operacionais Android e iOS.

5.5.11.1.2 No caso de Web ser compatível com os principais navegadores de mercado.

5.5.11.1.3 Permitir a identificação e preenchimento automáticos dos dados dos Dispositivos de Acesso através da leitura dos seus códigos de barras ou QR Code.

5.5.11.1.4 Possuir campos digitáveis para inserção dos códigos de forma manual, quando necessário.

5.5.11.1.5 Deve exigir credenciais de acesso aos cadastradores e liberar a vinculação apenas dos alunos cujas turmas foram definidas para o mesmo.

5.5.11.1.6 Trazer as opções de escola, séries/ano, turmas e nome do aluno.

5.5.12 Implantação e Ativação da PLATAFORMA:

5.5.12.1 A implantação e ativação da PLATAFORMA é um serviço realizado pela CONTRATADA no início do projeto composto por parametrização e preparação do ambiente de TI (CLOUD). Trata-se de um serviço realizado unicamente, no início da prestação dos serviços do Contrato.

5.5.12.2 A implantação e ativação da PLATAFORMA é o serviço responsável por viabilizar tecnicamente o cadastramento de todos os alunos, professores e dos componentes que permitem a conexão ao ambiente tecnológico de educação remota.

5.5.12.3 Para o serviço de implantação e ativação da PLATAFORMA a CONTRATADA deverá:

5.5.12.3.1 Levantar e parametrizar os requisitos de segurança e acesso dos alunos, professores e demais colaboradores da CONTRATANTE;

5.5.12.3.2 Levantar e parametrizar escolas, matérias, séries, turmas, alunos, gestores, diretores e professores que participarão da educação remota, criando um perfil específico para cada série da educação básica contemplada com os dispositivos.

5.5.12.3.3 Para a parametrização da solução a CONTRATANTE disponibilizará à CONTRATADA um banco de dados e/ou planilha eletrônica ou arquivo .csv com informações de escolas, séries, turmas, alunos, professores e demais servidores que serão contemplados com os Dispositivos de Acesso.

5.6 Dispositivo de Acesso (chip):

O Dispositivo de Acesso é o instrumento por meio do qual o aluno terá acesso à PLATAFORMA. Estes serão disponibilizados pela CONTRATADA aos alunos e professores da rede municipal, que poderão inseri-lo nos equipamentos/dispositivos móveis, tais como, tablets, smartphones ou modens portáteis.

5.6.1 O Dispositivo de Acesso fornecido pela CONTRATADA deve realizar a conexão à PLATAFORMA por meio das redes de telefonia móveis (3G ou 4G) de, pelo menos, 02 das operadoras de telefonia móvel atuantes nacionalmente e nas localidades, priorizando sempre a operadora com melhor infraestrutura de conectividade (sinal de cobertura).

5.6.2 O Dispositivo de Acesso fornecido deve conectar o tablet ou smartphone dos usuários (alunos ou professores) à PLATAFORMA, que processará as demandas de acesso via Internet e conectará o aluno ao conteúdo digital desejado e autorizado. O acesso dos usuários à rede educacional deve ser direto e restrito ao perfil definido pela Secretaria de Educação do Município.

5.6.3 O Dispositivo de Acesso deverá ser ativado por equipe da CONTRATADA, após recebimento de solicitação formal enviada pela equipe da CONTRATANTE habilitada para tal.

5.6.4 Da Ativação do Dispositivo de Acesso:

5.6.4.1 A CONTRATADA deve realizar treinamento com equipe definida pela CONTRATANTE demonstrando por meio de videoaulas e presencialmente, quando necessário, os passos para cadastramento dos alunos por meio do aplicativo ou ambiente web da PLATAFORMA.

5.6.5 O Dispositivo de Acesso deve ser disponibilizado lacrado e configurado para permitir conectividade limitada aos usuários, permitindo acesso apenas a conteúdos contidos na política de segurança da Secretaria de Educação.

5.6.6 O Dispositivo de Acesso será distribuído aos alunos e professores pela CONTRATANTE por meio das escolas da rede.

5.7 A PLATAFORMA deverá manter a conectividade de alunos e professores dentro de níveis de serviços estabelecidos neste documento e será prestado pelo período de 12 meses após a ativação do serviço, prazo de validade da licença de uso de PaaS em questão.

5.8 A licença de subscrição é um item de vigência e duração anual (12 meses) após ativação oficial junto à CONTRATADA, composto por mão de obra técnica especializada para o suporte e manutenção da PLATAFORMA fornecida pela CONTRATADA e atualização e manutenção do cadastro dos alunos e professores.

5.8.1 A Contratada deverá garantir que a PLATAFORMA tenha capacidade de processamento 60 GB por ano para cada dispositivo de acesso ativado para alunos e capacidade de processamento 120 GB por ano para cada dispositivo de acesso ativado para professores e, além de oferecer a possibilidade de configuração/parametrização das regras de distribuição mensal destas capacidades contratadas ao longo dos meses de vigência da licença de uso (12 meses).

5.8.2 A CONTRATADA deve identificar a operadora de telefonia móvel que melhor atenda a localidade onde os usuários irão utilizar o serviço DA PLATAFORMA e habilitar o dispositivo de acesso com a melhor qualidade de sinal possível.

5.8.3 A PLATAFORMA deve permitir a gestão de utilização dos pacotes de dados disponibilizados aos usuários via os dispositivos de acesso.

5.8.4 A PLATAFORMA deve permitir a realização da mudança do provedor de conectividade ou da operadora de telefonia móvel de forma remota (sem troca do chip/dispositivo móvel), a partir de um comando eletrônico da central de monitoramento da CONTRATADA.

5.8.5 Os comandos à distância para execução da substituição remota dos provedores de conectividade ou da operadora de telefonia móvel deverão seguir um protocolo definido e aprovado pela CONTRATANTE na fase de implantação da PLATAFORMA;

5.8.6 Para troca de operadora a CONTRATADA deve seguir critérios de melhor cobertura em cada localidade onde o aluno ou professor estiver acessando a plataforma educacional da Secretaria.

5.8.7 A CONTRATADA deve considerar, para efeito de dimensionamento e precificação de sua proposta comercial, um volume anual total de substituição do provedor de conectividade ou da operadora móvel a ser realizada pela CONTRATADA, o limite de até 15% do total de dispositivos de acesso ativados pela CONTRATANTE.

5.8.8 O serviço da CONTRATADA deve possuir Service Desk para atendimento aos colaboradores da Secretaria da Educação envolvidos no projeto. O Service Desk deve tirar dúvidas e auxiliar o colaborador em processos relacionados ao serviço contratado.

5.8.9 O Service Desk não fará atendimento a alunos e professores, trata-se de um canal de comunicação exclusivo entre a CONTRATADA e os colaboradores definidos pela Secretaria da Educação para gestão da PLATAFORMA.

5.8.10 A CONTRATADA deverá manter durante toda vigência do contrato um profissional devidamente treinado na PLATAFORMA e capaz de auxiliar e suportar os colaboradores da CONTRATANTE no que for necessário para a melhor utilização da PLATAFORMA.

6 DO MODEM WI-FI PORTÁTIL

6.1 O Modem Wi-Fi Portátil disponibilizado pela CONTRATADA deve realizar a conexão à internet por meio das redes móveis (3G ou 4G) de todas as operadoras disponíveis nas localidades, priorizando sempre a operadora com melhor conectividade.

6.2 O Modem Wi-Fi Portátil deve conectar o tablet, notebook ou smartphone do professor à internet por meio de uma rede Wi-Fi gerada pelo equipamento.

6.3 A modalidade de contratação para este item será de Locação Mensal, de forma que a manutenção e suporte para os equipamentos deverão ser realizadas pela

CONTRATADA, exceto nos casos de furto ou danos por mau uso. Nestes casos excepcionais, a CONTRATANTE deverá indenizar a CONTRATADA por meio de processo administrativo específico e valor de mercado do equipamento, considerando uma taxa de depreciação de 20% do valor para cada ano de uso.

6.4 A especificação técnica do equipamento está descrita no Anexo I deste Termo de Referência.

7 DETALHAMENTO DOS SERVIÇOS

7.1 A CONTRATADA deve possuir equipe para realizar o monitoramento dos Dispositivos de Acesso e spare parts para realizar troca de itens sempre que defeitos de fabricação forem identificados. Além disso, deve manter em estoque mínimo de 5% do total de dispositivos de acesso ativados para trocas exigidas pelo projeto.

7.2 A CONTRATADA será responsável pela conexão LAN TO LAN entre as estruturas das operadoras de telefonia móvel e o Data Center onde a PLATAFORMA for instalada.

7.3 A conexão LAN TO LAN deve estar adequada à necessidade de acessos simultâneos totais por turno manhã, tarde e noite.

7.4 É de responsabilidade da CONTRATADA possuir equipe capacitada para desenvolver, parametrizar, customizar e manter a PLATAFORMA e toda infraestrutura funcional dentro dos padrões e níveis de serviço exigidos neste Termo de Referência e seus anexos.

7.5 A CONTRATADA deve disponibilizar gestor de projetos responsável por coordenar e supervisionar a implantação da solução, e acompanhar o projeto após sua implantação até o fim do contrato.

7.6 Quando do fornecimento dos aplicativos móveis e aplicações a serem utilizados pelos usuários colaboradores da CONTRATANTE no processo de educação remota, a instalação destas ferramentas será de responsabilidade da CONTRATANTE.

7.7 A CONTRATANTE ficará responsável pela definição da lista de sites/links (urls), aplicativos ou portais de conteúdos a serem liberados para acesso pelos usuários contemplados.

7.8 É de responsabilidade da CONTRATADA a realização de assistência técnica corretiva de todos os componentes da PLATAFORMA.

7.9 A CONTRATADA deve disponibilizar acesso online aos relatórios de atendimentos corretivos.

7.10 É de responsabilidade da CONTRATADA executar atividades de programação, manutenção preventiva e corretiva da PLATAFORMA, garantindo o cumprimento das normas e níveis de serviços. Tais atividades são:

7.10.1 Identificar e corrigir falhas na PLATAFORMA;

7.10.2 Executar alterações de configurações;

7.10.3 Instalar, configurar e manter softwares da solução;

7.10.4 Monitorar os serviços, infraestrutura de TI e demais sistemas e aplicações que compõem a PLATAFORMA;

7.10.5 Fazer backup das configurações da PLATAFORMA;

7.10.6 Verificar redundância e failover dos componentes da PLATAFORMA;

7.10.7 Fazer checklist diário do funcionamento da PLATAFORMA;

7.10.8 Executar rotina de testes;

7.10.9 Verificar logs;

7.10.10 Testar conexões;

7.10.11 Avaliar interfaces dos Dispositivos de Acesso;

7.10.12 Avaliar as condições de funcionamento da PLATAFORMA.

7.11 A CONTRATADA deve comprovar proficiência da equipe de analistas de administração e suporte da PLATAFORMA a ser gerenciada e mantida.

7.12 A CONTRATADA deve disponibilizar atendimento em conformidade com o nível de serviço informado neste Termo de Referência.

7.13 Durante o período de implantação e ativação da PLATAFORMA, a CONTRATADA deve fornecer apoio à ativação disponibilizando:

7.13.1 01 profissional alocado integralmente no local indicado pela CONTRATANTE com conhecimento na PLATAFORMA e no processo de ativação e implantação;

7.13.2 Service Desk com atendimento via telefone, e-mail e/ou chat em horário compatível com funcionamento das escolas, regionais e diretorias da CONTRATANTE.

7.13.3 Quanto à locação dos Modens Wi-Fi Portáteis, a CONTRATADA deverá dispor de parque de spare parts equivalente a 3% do total de equipamentos locados pela CONTRATANTE, como forma de atingir a celeridade necessária para atendimento das manutenções demandas pelos usuários e pela fiscalização do contrato.

7.13.4 O Service Desk da CONTRATADA deverá atender as demandas de manutenção dos Modens Wi-Fi Portáteis, abrindo o referido chamado técnico e iniciando o processo de atendimento em conformidade com as melhores práticas previstas nas metodologias ITIL e ITSM.

8 ACORDO DO NÍVEL DE SERVIÇO

8.1 Todo o cronograma de implantação deve ser apresentado a Secretaria de Educação, com antecedência mínima de 05 (cinco) dias úteis, para análise e aprovação antes do início da implantação.

8.2 A execução dos serviços não deve exceder os prazos descritos:

8.2.1 Emissão do “Termo de Subscrição” ou “Licença de Uso” com declaração de emissão das licenças em nome da CONTRATANTE: até 10 (dez) dias após Ordem de Fornecimento das Licenças de Uso;

8.2.2 Entrega dos dispositivos de acesso (chips) contendo a licença de uso para acesso à PLATAFORMA: até 60 (sessenta) dias após emissão da Ordem de Fornecimento;

8.2.3 Implantação e Ativação da PLATAFORMA: até 60 (sessenta) dias corridos da ordem de fornecimento.

8.2.4 Ativação dos dispositivos: até 30 (trinta) dias corridos após fornecimento dos Dispositivos de Acesso e da Implantação e Ativação da PLATAFORMA.

8.2.5 Entrega e disponibilização dos Modens Wi-Fi Portáteis solicitados em até 60 (sessenta) dias após o Ordem de Serviço formalizada e assinada pela CONTRATANTE.

8.3 Em relação aos serviços prestados pela CONTRATADA, a mesma deve atender aos prazos de atendimento de acordo com 03 (três) níveis de criticidade:

8.3.1 Alta: Mais de 10% de todos os recursos ou data center inoperante, usuários sem acesso à PLATAFORMA;

8.3.2 Média: Menos de 10% dos recursos inoperantes e/ou funções importantes indisponíveis;

8.3.3 Baixa: Situações que afetem apenas usuários específicos/isolados, nunca superando 2% dos usuários ativados com os serviços.

8.4 O serviço objeto desta contratação deve ser prestado 24 (vinte e quatro) horas por dia, 07 (sete) dias por semana, durante todo o período de vigência do contrato, exceto nos casos de interrupções programadas.

8.5 O serviço deve ser realizado de forma ininterrupta, com disponibilidade geral anual mínima em 98% (noventa e oito por cento) do tempo contratado, calculado a partir da média de todos os dispositivos de acesso.

8.6 A CONTRATADA deve prestar imediatamente as informações e os esclarecimentos que xxxxxx a ser solicitados pela CONTRATANTE, salvo quando

implicarem em indagações de caráter técnico, hipótese em que serão respondidas no prazo de 24 (vinte e quatro) horas.

9 DO SUPORTE TÉCNICO

9.1 A CONTRATADA deve prestar serviços de suporte técnico especializado de forma contínua durante toda a vigência do contrato, objetivando a orientação da Secretaria de Educação quanto às ações necessárias para o uso dos recursos oferecidos pela PLATAFORMA.

9.2 Deve ser disponibilizada pela CONTRATADA um serviço de abertura de chamados técnicos (Service Desk) através da WEB, 0800 ou número local. Estes serviços são para uso exclusivo dos responsáveis da CONTRATANTE e deverão estar disponíveis de segunda à sexta-feira das 8h às 18h, exceto feriados.

9.3 Ambas as opções fornecidas no serviço de abertura de chamados devem permitir o registro da data e hora da solicitação, o usuário, a descrição do problema e uma numeração de controle.

9.3.1 Ao final de cada atendimento realizado, deve ser mantido registro com no mínimo as seguintes opções:

9.4.1 Número do chamado;

9.4.2 Data e hora no início do atendimento;

9.4.3 Data e hora no término do atendimento;

9.4.4 Identificação do problema;

9.4.5 Solução aplicada.

9.5 As atividades mínimas contempladas no serviço do atendimento e do analista de suporte são:

9.5.1 Abrir e acompanhar o encerramento dos chamados técnicos;

9.5.2 Realizar atendimento das requisições;

9.5.3 Classificar as requisições;

9.5.4 Identificar prioridades;

9.5.5 Acionar equipe técnica;

9.5.6 Monitorar e garantir nível de serviço contratado;

9.5.7 Realizar manutenção corretiva e preventiva da PLATAFORMA;

9.5.8 Gerenciar mudanças no projeto;

9.5.9 Realizar a programação e configuração da solução;

9.5.10 Instalar e configurar aplicativos relacionados ao gerenciamento da PLATAFORMA;

9.5.11 Executar rotinas de testes;

9.5.12 Verificar logs;

9.5.13 Elaborar relatórios gerenciais;

9.5.14 Mapear problemas potenciais.

9.6 O sistema de chamados deve permitir a geração de relatórios referentes a:

9.6.1 Números de chamados abertos em um determinado período;

9.6.2 Número de chamados finalizados em um determinado período;

9.6.3 Tempo médio de finalização de chamados;

9.6.4 Tempo médio de finalização de chamados por tipo de serviço;

9.6.5 Ranking de chamados abertos por usuários.

10 DO TREINAMENTO PARA UTILIZAÇÃO DO SISTEMA

10.1 Iniciada a implantação da PLATAFORMA, a CONTRATADA deve realizar treinamento inicial para os gestores que forem indicados pela Secretaria de Educação.

10.2 O treinamento inicial tem como objetivo introduzir as funcionalidades da PLATAFORMA, apresentando o fluxo de navegação e tutoriais com informações necessárias para a utilização das funções liberadas para os gestores da secretaria.

10.3 Treinamento será feito de forma remota, em salas de videoconferência em horário comercial.

10.4 Todos os recursos das salas de videoconferência para realização do treinamento são de responsabilidade da CONTRATADA.

10.5 Para melhor aproveitamento e agilidade dos treinamentos, será permitido à formação de turmas com no máximo 10 (dez) pessoas.

10.6 Todos os treinamentos deverão ser ministrados por profissionais da CONTRATADA habilitados tecnicamente e capacitados hábeis à transmissão de conhecimento.

10.7 Cada representante escolhido pela CONTRATANTE para realizar o treinamento deve receber explicações teóricas e demonstrações práticas.

10.8 O treinamento deve ser realizado em até 8 horas-aula e a CONTRATADA devem manter plataforma EAD com os cursos disponíveis aos colaboradores da CONTRATANTE.

10.9 O treinamento deverá ser gravado pela CONTRATADA, e o arquivo com a comprovação deste evento deve ser repassado à gestão contratual da CONTRATANTE;

10.10 Deve ser fornecido material didático digital pela CONTRATANTE.

11 DAS OBRIGAÇÕES

11.1 Obrigações da CONTRATANTE

11.1.1 A CONTRATANTE deve ser responsável pela definição da lista de conteúdos que farão parte da lista de endereços web liberados.

11.1.2 Solicitar a execução do objeto à CONTRATADA através da emissão de Ordem de Serviço.

11.1.3 Tomar todas as providências necessárias ao fiel cumprimento das cláusulas deste Termo de Referência.

11.1.4 Franquear à CONTRATADA o acesso livre à sua instalação sempre que necessário à prestação do serviço.

11.1.5 Facilitar por todos os meios o cumprimento da execução do contrato, dando acesso e promovendo o bom entendimento entre seus funcionários e colaboradores da CONTRATADA, cumprindo com as obrigações pré-estabelecidas.

11.1.6 Prestar as informações e os esclarecimentos que xxxxxx a ser solicitados pela CONTRATADA.

11.1.7 Notificar a CONTRATADA de qualquer irregularidade decorrente da execução do objeto contratual.

11.1.8 Efetuar os pagamentos devidos à CONTRATADA nas condições estabelecidas neste Termo.

11.1.9 Fornecer à CONTRATADA, informações e especificações indispensáveis para a realização dos trabalhos.

11.1.10 Viabilizar a capacitação de pessoal para assegurar o melhor uso das ferramentas.

11.1.11 Analisar as questões relacionadas com o desenvolvimento e operacionalização dos serviços prestados identificando eventuais problemas, diagnosticando-os e propondo medidas preventivas e corretivas.

11.1.12 Nomear através de portaria um Gestor de Contrato com conhecimento em TI para as etapas de verificação e aceitação das amostras dos produtos ofertados.

12.1 Obrigações da CONTRATADA

12.1.1 A CONTRATADA será a responsável pelo fornecimento de todos os serviços e recursos especificados nos itens e subitens do Termo de Referência e seus anexos, a qual será devidamente formalizada a partir de instrumentos contratuais específicos, conforme Edital e seus anexo.

12.1.2 Atender a todas as condições de habilitação e qualificação exigidas na licitação.

12.1.3 Dar suporte à CONTRATANTE na realização de todas as fases de implementação do serviço.

12.1.4 Dimensionar e alocar, as suas expensas, os recursos materiais e humanos necessários para prestação do serviço.

12.1.5 Responsabilizar-se pelos serviços previstos nesse instrumento.

12.1.6 Prestar serviço de manutenção corretiva, que consistirá no fornecimento de novas versões para correção de erros e bugs, e para adaptações em decorrência de evoluções tecnológicas.

12.1.7 Cumprir os prazos e condições dispostos no Acordo de Nível de Serviço e nos prazos estabelecidos nesse instrumento.

13 PRAZOS E VIGÊNCIA DO CONTRATO

13.1 A licitante vencedora terá o prazo máximo de 05 (cinco) dias úteis, a contar do recebimento da convocação da CONTRATANTE, para assinatura da Ata de Registro de Preços;

13.2 A empresa detentora da ata de registro de preços terá o xxxxx xxxxxx xx 00 (xxxxx) xxxx xxxxx, x xxxxxx xx xxxxxxxxxxx xx xxxxxxxxxx xx xxxxx CONTRATANTE, para assinatura do contrato;

13.3 A CONTRATADA deverá prestar os serviços pelo prazo de 12 (doze) meses após ativação dos dispositivos de acesso. O contrato poderá ser prorrogado anualmente até o limite de 48 (quarenta e oito) meses em conformidade com a Lei Federal 8.666/93, de 21/06/1993.

13.4 Os preços previstos para a contratação do objeto deste Contrato permanecerão fixos e irreajustáveis pelo período de 12 (doze) meses. Decorrido esse prazo, os preços poderão ser reajustados com base na variação do Índice Nacional de Preços ao Consumidor Amplo – IPCA, do Instituto Brasileiro de Geografia e Estatística – IBGE, sendo aplicado o índice do mês anterior ao reajuste;

13.5 A CONTRATANTE terá o prazo de até 60 (sessenta) dias após o recebimento físico dos Dispositivos de Acesso (chips) para proceder com a ativação dos mesmos. Prazo necessário para que a CONTRATANTE providencie a logística de distribuição para os usuários (alunos e professores). Após a ativação dos dispositivos de acesso, o serviço deverá ser prestado pelo período de 12 (doze) meses.

13.6 Quando o participante vencedor não assinar a Ata de Registro de Preços, é facultada a CONTRATANTE convocar os participantes remanescentes, na ordem de classificação, para fazê-lo em igual prazo e nas mesmas condições, ou revogar a licitação, sem prejuízo das sanções previstas neste Termo de Referência e no art. 7º da Lei Federal 10.520/2002, observada a ampla defesa e o contraditório;

13.7 A Ata de Registro de Preços resultante deste certame terá vigência de 12 (doze) meses contados a partir de sua publicação oficial, obrigando-se a CONTRATADA a garantir o objeto e os preços ajustados;

13.8 Os preços serão fixos durante a vigência da Ata de Registro de preços;

13.9 Fica assegurado o restabelecimento do equilíbrio econômico-financeiro inicial do contrato, na ocorrência de fato superveniente que implique a inviabilidade de sua execução.

14 DA FORMA DE PAGAMENTO

14.1 O pagamento pelos serviços prestados será efetuado em moeda brasileira (real) através de depósito bancário, em conta corrente da empresa contratada, em até 30 (trinta) dias dos efetivos serviços prestados (recebimento do termo de licenciamento e dos dispositivos de acesso fisicamente), mediante atesto da nota fiscal pelo departamento responsável pela fiscalização dos serviços.

14.2 Devendo estar inclusos nos preços, todos e quaisquer tributos, sejam eles fiscais, sociais, trabalhistas, previdenciários, comerciais ou de qualquer outra natureza resultantes da execução do contrato.

14.3 A contratante reserva-se o direito de suspender o pagamento se os serviços prestados se configurarem em desacordo com as condições e especificações constantes neste Termo de Referência, no edital e seus anexos.

14.4 O pagamento fica condicionado a comprovação de que a contratada se encontra adimplente com a fazenda pública federal, estadual e municipal, FGTS e débitos trabalhistas. A nota fiscal deverá ser preenchida com a indicação do banco, agência e conta corrente para o respectivo deposito.

14.5 DO PAGAMENTO DAS LICENÇAS

14.5.1 Para os itens cuja natureza seja de subscrição (licença de uso), o pagamento será realizado seguindo o cronograma a seguir:

14.5.2 Em relação as licenças, o pagamento deverá ocorrer, de acordo com o quantitativo solicitado e efetivamente disponibilizado à Administração, após o recebimento físico dos chips que contém a licença de uso instalada para viabilizar o acesso à plataforma, sujeitando-se ao aceite do servidor responsável pela fiscalização da ARP. O pagamento se refere à licença durante o período de 12 (doze) meses.

14.5.3 Para os itens cuja natureza seja de subscrição (licença de uso), a Nota Fiscal de Serviços a ser emitida pela CONTRATADA deverá prever a correta classificação do serviço relacionado a Licença de Uso de Software relacionada a Processamento remoto de dados em ambiente remoto de infraestrutura de TI (Data Center ou Centro de Processamento de Dados).

14.6 Para o item de LOCAÇÃO do equipamento Modem Wi-Fi Portátil, a CONTRATADA deverá apresentar mensalmente um Boletim de Medição contendo o relatório com a lista dos equipamentos locados, bem como o valor pró-rata dia para aqueles itens que forem entregues ao longo do mês de apuração. As faturas deverão ser acompanhadas de Recibo de Locação de Equipamentos Móveis. A fiscalização do contrato irá avaliar, solicitar correção e atestar mensalmente o Boletim de Medição considerado correto.

ANEXO I DO TERMO DE REFERÊNCIA

REQUISITOS DA PLATAFORMA DE GESTÃO E CONTROLE DOS ACESSOS E CONECTIVIDADE

A Plataforma de Gestão e Controle dos Acessos e Conectividade (PLATAFORMA) fornecida na modalidade PaaS (Plataform as a Service) pela CONTRATADA deve possuir capacidade para processar todos os dispositivos de acesso simultaneamente, o que representa 100% dos usuários conectados simultaneamente aos servidores de conteúdo disponibilizados pela Secretaria de Educação para a educação remota.

A PLATAFORMA deve atender integralmente os seguintes requisitos e funcionalidades:

1. Ter a capacidade de gerenciar os eUICCs através de plataforma eSIM Management compatíveis com a especificação GSMA SGP.02 v3.2.

2. Possuir capacidade de gerenciamento fim a fim, possuindo SM-DP e SM-SR e fornecimento dos chips eUICCs.

3. Plataforma hospedada em pelo menos 2 DataCenters certificados GSMA SAS-SM Accredited Sites em diferentes continentes, incluindo Ásia e América.

4. Possuir capacidade de interoperabilidade com diferentes fabricantes de dispositivos e eSIM cards.

5. Para atender a todas as necessidades e funcionalidades apontadas no Termo de Referência e respeitar a Lei Geral de Proteção de Dados a plataforma deve possuir no mínimo as soluções abaixo:

• Solução de Firewall de Próxima Geração

• Solução de Balanceamento de Carga

• Solução de Armazenamento de Logs e Relatórios

As especificações mínimas de cada solução são descritas abaixo:

Solução de Firewall

5.1 A Solução de Firewall instalado no Data Center da CONTRATADA deve ser composto por hardware e software.

5.2 A Solução de Firewall deve monitorar o tráfego de rede de entrada e saída e decidir permitir ou bloquear tráfegos específicos de acordo com um conjunto definido de regras de segurança.

5.3 A solução deve consistir em plataforma de proteção de rede baseada em appliance com funcionalidades de Next Generation Firewall (NGFW), e console de gerência e monitoração.

5.4 Por funcionalidades de NGFW entende-se: reconhecimento de aplicações, prevenção de ameaças, identificação de usuários e controle granular de permissões;

5.5 As funcionalidades de proteção de rede que compõe a plataforma de segurança, podem funcionar em múltiplos appliances desde que obedeçam a todos os requisitos desta especificação.

5.6 A plataforma deve ser otimizada para análise de conteúdo de aplicações em camada

5.7 A Solução de Firewall deve possuir no mínimo as seguintes características:

5.7.1 Throughput de, no mínimo, 140 Gbps com a funcionalidade de firewall habilitada, independentemente do tamanho do pacote.

5.7.2 Suporte a, no mínimo, 12.000.000 conexões simultâneas.

5.7.3 Suporte a, no mínimo, 700.000 novas conexões por segundo.

5.7.4 Throughput de, no mínimo, 50 Gbps de VPN IPSec.

5.7.5 Deve estar licenciado para, ou suportar sem o uso de licença, 15.000 túneis de VPN IPSEC Site-to-Site simultâneos.

5.7.6 Deve estar licenciado para, ou suportar sem o uso de licença, 80.000 túneis de clientes VPN IPSEC simultâneos.

5.7.7 Throughput de, no mínimo, 10 Gbps de VPN SSL.

5.7.8 Suporte a, no mínimo, 5000 clientes de VPN SSL simultâneos.

5.7.9 Suportar no mínimo 12 Gbps de throughput de IPS.

5.7.10 Suporte a, no mínimo, 30 Gbps de throughput de Application Control.

5.7.11 Suportar no mínimo 15 Gbps de throughput de Inspeção SSL.

5.7.12 Throughput de, no mínimo 9 Gbps com as seguintes funcionalidades habilitadas simultaneamente para todas as assinaturas que a plataforma de segurança possuir devidamente ativadas e atuantes: controle de aplicação, IPS, Antivírus e Antispyware.

5.7.13 Caso o fabricante escolhido pela CONTRATADA divulgue múltiplos números de desempenho para qualquer uma destas funcionalidades, somente o de menor valor será aceito.

5.7.14 Deve possuir ao menos 2 interfaces 10 GE SFP+.

5.7.15 Deve possuir ao menos 16 interfaces 1 GE RJ-45.

5.7.16 Deve possuir ao menos 8 interfaces 1 GE SFP.

5.7.17 Deve possuir ao menos 12 interfaces 25GE SFP28.

5.7.18 Deve possuir ao memos 4 interfaces 40GE QSFP+.

5.7.19 Estar licenciado e/ou ter incluído sem custo adicional, no mínimo, 10 sistemas virtuais lógicos (Contextos) por appliance.

5.8 O equipamento de firewall deve possuir alimentação Dual / tensão de 100-240 VAC.

5.9 O equipamento de firewall deve possuir alimentação Dual / frequência de 50/60 Hz.

5.10 O equipamento de firewall deve possuir deve possuir fonte de alimentação redundante que permitam troca a quente e caso de defeito.

5.11 O equipamento de firewall deve possuir temperatura - faixa de operação de 0º a 40º C.

5.12 O gerenciamento da solução deve suportar acesso via SSH, cliente ou WEB (HTTPS) e API aberta.

5.13 Os dispositivos de proteção de rede devem possuir:

5.13.1 suporte a 4094 VLAN Tags 802.1q.

5.13.2 suporte a Policy based routing ou policy-based forwarding.

5.13.3 suporte a roteamento multicast (PIM-SM e PIM-DM).

5.13.4 suporte a DHCP Relay.

5.13.5 suporte a DHCP Server.

5.13.6 suporte a Jumbo Frames.

5.14 Os dispositivos de proteção de rede devem suportar:

5.14.1 sub-interfaces ethernet logicas.

5.14.2 NAT dinâmico (Many-to-Many).

5.14.3 NAT estático (1-to-1).

5.14.4 NAT estático bidirecional 1-to-1.

5.14.5 Tradução de porta (PAT).

5.14.6 NAT de Origem.

5.14.7 NAT de Destino.

5.14.8 NAT de Origem e NAT de Destino simultaneamente.

5.15 Deve implementar Network Prefix Translation (NPTv6) ou NAT66, prevenindo problemas de roteamento assimétrico.

5.16 Deve suportar NAT64 e NAT46.

5.17 Deve implementar o protocolo ECMP.

5.18 Deve implementar balanceamento de link por hash do IP de origem.

5.19 Deve implementar balanceamento de link por hash do IP de origem e destino.

5.20 Deve implementar balanceamento de link por peso. Nesta opção deve ser possível definir o percentual de tráfego que será escoado por cada um dos links. Deve suportar o balanceamento de, no mínimo, três links.

5.21 Deve implementar balanceamento de links sem a necessidade de criação de zonas ou uso de instâncias virtuais.

5.22 A solução deve prover recursos de roteamento inteligente, definindo, mediante regras pré-estabelecidas, o melhor caminho a ser tomado para uma aplicação.

5.23 A solução deverá ser capaz de monitorar e identificar falhas mediante a associação de health check, permitindo testes de resposta por ping, http, tcp/udp echo e twamp.

5.24 Deve permitir a criação de políticas de roteamento com base nos seguintes critérios: latência, jitter, perda de pacote, banda ocupada ou todos ao mesmo tempo.

5.25 Diversas formas de escolha do link devem estar presentes, incluindo: melhor link, menor custo e definição de níveis máximos de qualidade a serem aceitos para que tais links possam ser utilizados em um determinado roteamento de aplicação.

5.26 A solução deve prover estatísticas em tempo real a respeito da ocupação de banda (upload e download) e performance do health check (packet loss, jitter e latência).

5.27 Além de possibilitar a definição de banda máxima e garantida por aplicação, deve também suportar o match em categorias de URL, IPs de origem e destino, logins e portas.

5.28 Deve possibilitar roteamento distinto a depender do grupo de usuário selecionado na regra de roteamento.

5.29 Deve permitir monitorar via SNMP falhas de hardware, monitoramento de CPU e memória, de segurança e interface.

5.30 Deve enviar log para sistemas de monitoração externos, simultaneamente.

5.31 Deve haver a opção de enviar logs para os sistemas de monitoração externos via protocolo TCP e SSL.

5.32 Deve possuir proteção anti-spoofing.

5.33 Para IPv4, deve suportar roteamento estático e dinâmico (RIPv2, BGP e OSPFv2).

5.34 Para IPv6, deve suportar roteamento estático e dinâmico (OSPFv3).

5.35 Deve suportar OSPF graceful restart.

5.36 Deve suportar Xxxx Xxxxxxx, para inspeção via porta espelhada do tráfego de dados da rede.

5.37 Deve suportar Modo Camada 2 (L2), para inspeção de dados em linha e visibilidade do tráfego.

5.38 Deve suportar Modo Camada 3 (L3), para inspeção de dados em linha visibilidade do tráfego.

5.39 Deve suportar a configuração de alta disponibilidade Ativo/Passivo e Ativo/Ativo: Em modo transparente.

5.40 Deve suporte a configuração de alta disponibilidade Ativo/Passivo e Ativo/Ativo: Em layer 3.

5.41 Deve suporte a configuração de alta disponibilidade Ativo/Passivo e Ativo/Ativo: Em layer 3 e com no mínimo 3 equipamentos no cluster.

5.42 Deve realizar configuração em alta disponibilidade deve sincronizar: Sessões.

5.43 A configuração em alta disponibilidade deve sincronizar: Configurações, incluindo, mas não limitado as políticas de Firewall, NAT, QOS e objetos de rede.

5.44 A configuração em alta disponibilidade deve sincronizar: Associações de Segurança das VPNs.

5.45 A configuração em alta disponibilidade deve sincronizar:Tabelas FIB.

5.46 O HA (modo de Alta-Disponibilidade) deve possibilitar monitoração de falha de link.

5.47 Deve possuir suporte a criação de sistemas virtuais no mesmo appliance.

5.48 Em alta disponibilidade, deve ser possível o uso de clusters virtuais, seja ativo- ativo ou ativo-passivo, permitindo a distribuição de carga entre diferentes contextos.

5.49 Deve permitir a criação de administradores independentes, para cada um dos sistemas virtuais existentes, de maneira a possibilitar a criação de contextos virtuais que podem ser administrados por equipes distintas.

5.50 Controle, inspeção e descriptografia de SSL para tráfego de entrada (Inbound) e Saída (Outbound), sendo que deve suportar o controle dos certificados individualmente dentro de cada sistema virtual, ou seja, isolamento das operações de adição, remoção e utilização dos certificados diretamente nos sistemas virtuais (contextos).

5.51 Controle por Política de Firewall.

5.52 Deve suportar controles por zona de segurança.

5.53 Deve possuir controles de políticas por porta e protocolo.

5.54 Deve possuir controle de políticas por aplicações, grupos estáticos de aplicações, grupos dinâmicos de aplicações (baseados em características e comportamento das aplicações) e categorias de aplicações.

5.55 Deve possuir controle de políticas por usuários, grupos de usuários, IPs, redes e zonas de segurança.

5.56 Deve possuir controle de políticas por código de País (Por exemplo: BR, USA, UK, RUS).

5.57 Deve possuir controle, inspeção e de-criptografia de SSL por política para tráfego de entrada (Inbound) e Saída (Outbound).

5.58 Deve suportar offload de certificado em inspeção de conexões SSL de entrada (Inbound).

5.59 Deve descriptografar tráfego Inbound e Outbound em conexões negociadas com TLS 1.2.

5.60 Deve possuir controle de inspeção e descriptografia de SSH por política.

5.61 Deve permitir o bloqueio de arquivo por sua extensão e possibilitar a correta identificação do arquivo por seu tipo mesmo quando sua extensão for renomeada.

5.62 Traffic shaping QoS baseado em Políticas (Prioridade, Garantia e Máximo).

5.63 QoS baseado em políticas para marcação de pacotes (diffserv marking), inclusive por aplicações.

5.64 Deve ter suporte a objetos e regras IPV6.

5.65 Deve ter suporte a objetos e regras multicast.

5.66 Deve suportar no mínimo dois tipos de resposta nas políticas de firewall: Drop sem notificação do bloqueio ao usuário, Drop com notificação do bloqueio ao usuário, Drop com opção de envio de ICMP Unreachable para máquina de origem do tráfego, TCP-Reset para o client, TCP-Reset para o server ou para os dois lados da conexão.

5.67 Deve suportar atribuição de agendamento das políticas com o objetivo de habilitar e desabilitar políticas em horários pré-definidos automaticamente.

5.68 Os dispositivos de proteção de rede deverão possuir a capacidade de reconhecer aplicações, independente de porta e protocolo.

5.69 Deve ser possível a liberação e bloqueio somente de aplicações sem a necessidade de liberação de portas e protocolos.

5.70 Reconhecer pelo menos 1700 aplicações diferentes, incluindo, mas não limitado: a tráfego relacionado a peer-to-peer, redes sociais, acesso remoto, update de software, protocolos de rede, voip, áudio, vídeo, proxy, mensageiros instantâneos, compartilhamento de arquivos, e-mail.

5.71 Reconhecer pelo menos as seguintes aplicações: bittorrent, gnutella, skype, facebook, linked-in, twitter, citrix, logmein, teamviewer, ms-rdp, vnc, gmail, youtube, http-proxy, http-tunnel, facebook chat, gmail chat, whatsapp, 4shared, dropbox, google drive, skydrive, db2, mysql, oracle, active directory, kerberos, ldap, radius, itunes, dhcp, ftp, dns, wins, msrpc, ntp, snmp, rpc over http, gotomeeting, webex, evernote, google- docs.

5.72 Deve inspecionar o payload de pacote de dados com o objetivo de detectar assinaturas de aplicações conhecidas pelo fabricante independente de porta e protocolo.

5.73 Identificar o uso de táticas evasivas, ou seja, deve ter a capacidade de visualizar e controlar as aplicações e os ataques que utilizam táticas evasivas via comunicações criptografadas, tais como Skype e utilização da rede Tor.

5.74 Para tráfego criptografado SSL, deve de-criptografar pacotes a fim de possibilitar a leitura de payload para checagem de assinaturas de aplicações conhecidas pelo fabricante.

5.75 Deve realizar decodificação de protocolos com o objetivo de detectar aplicações encapsuladas dentro do protocolo e validar se o tráfego corresponde com a especificação do protocolo, incluindo, mas não limitado a Yahoo Instant Messenger usando HTTP. A decodificação de protocolo também deve identificar funcionalidades especificas dentro de uma aplicação, incluindo, mas não limitado a compartilhamento de arquivo dentro do Webex.

5.76 Deve identificar o uso de táticas evasivas via comunicações criptografadas.

5.77 Atualizar a base de assinaturas de aplicações automaticamente.

5.78 Deve permitir a limitação da banda (download/upload) usada por aplicações (traffic shaping), baseado no IP de origem, usuários e grupos.

5.79 Os dispositivos de proteção de rede devem possuir a capacidade de identificar o usuário de rede com integração ao Microsoft Active Directory, sem a necessidade de instalação de agente no Domain Controller, nem nas estações dos usuários.

5.80 Deve ser possível adicionar controle de aplicações em múltiplas regras de segurança do dispositivo, ou seja, não se limitando somente a possibilidade de habilitar controle de aplicações em algumas regras.

5.81 Deve suportar múltiplos métodos de identificação e classificação das aplicações, por pelo menos checagem de assinaturas e decodificação de protocolos.

5.82 Para manter a segurança da rede eficiente, deve suportar o controle sobre aplicações desconhecidas e não somente sobre aplicações conhecidas.

5.83 Permitir nativamente a criação de assinaturas personalizadas para reconhecimento de aplicações proprietárias na própria interface gráfica da solução, sem a necessidade de ação do fabricante.

5.84 A criação de assinaturas personalizadas deve permitir o uso de expressões regulares, contexto (sessões ou transações), usando posição no payload dos pacotes TCP e UDP e usando decoders de pelo menos os seguintes protocolos: HTTP, FTP, NBSS, DCE RPC, SMTP, Telnet, SSH, MS-SQL, IMAP, DNS, LDAP, RTSP e SSL.

5.85 A solução utilizada pela CONTRATADA deve permitir a solicitação de inclusão de aplicações na base de assinaturas de aplicações.

5.86 Deve alertar o usuário quando uma aplicação for bloqueada.

5.87 Deve possibilitar a diferenciação de tráfegos Peer2Peer (Bittorrent, emule, etc) possuindo granularidade de controle/políticas para os mesmos.

5.88 Deve possibilitar a diferenciação de tráfegos de Instant Messaging (AIM, Hangouts, Facebook Chat, etc) possuindo granularidade de controle/políticas para os mesmos.

5.89 Deve possibilitar a diferenciação e controle de partes das aplicações como por exemplo permitir o Hangouts chat e bloquear a chamada de vídeo.

5.90 Deve possibilitar a diferenciação de aplicações Proxies (psiphon, freegate, etc) possuindo granularidade de controle/políticas para os mesmos.

5.91 Deve ser possível a criação de grupos dinâmicos de aplicações baseados em características das aplicações como: Tecnologia utilizada nas aplicações (Client-Server, Browse Based, Network Protocol, etc).

5.92 Deve ser possível a criação de grupos dinâmicos de aplicações baseados em características das aplicações como: Nível de risco da aplicação.

5.93 Deve ser possível a criação de grupos estáticos de aplicações baseados em características das aplicações como: Categoria da aplicação.

5.94 Para proteção do ambiente contra-ataques, os dispositivos de proteção devem possuir módulo de IPS, Antivírus e Anti-Spyware integrados no próprio appliance de firewall.

5.95 Deve incluir assinaturas de prevenção de intrusão (IPS) e bloqueio de arquivos maliciosos (Antivírus e Anti-Spyware).

5.96 As funcionalidades de IPS, Antivírus e Anti-Spyware devem operar em caráter permanente, podendo ser utilizadas por tempo indeterminado, mesmo que não subsista o direito de receber atualizações ou que não haja contrato de garantia de software com

o fabricante.

5.97 Deve sincronizar as assinaturas de IPS, Antivírus, Anti-Spyware quando implementado em alta disponibilidade.

5.98 Deve implementar os seguintes tipos de ações para ameaças detectadas pelo IPS: permitir, permitir e gerar log, bloquear, bloquear IP do atacante por um intervalo de tempo e enviar tcp-reset.

5.99 As assinaturas devem poder ser ativadas ou desativadas, ou ainda habilitadas apenas em modo de monitoração.

5.100 Deve ser possível a criação de políticas por usuários, grupos de usuários, IPs, redes ou zonas de segurança.

5.101 Exceções por IP de origem ou de destino devem ser possíveis nas regras ou assinatura a assinatura.

5.102 Deve suportar granularidade nas políticas de IPS, Antivírus e Anti-Spyware, possibilitando a criação de diferentes politicas por zona de segurança, endereço de origem, endereço de destino, serviço e a combinação de todos esses itens.

5.103 Deve permitir o bloqueio de vulnerabilidades.

5.104 Deve permitir o bloqueio de exploits conhecidos.

5.105 Deve incluir proteção contra-ataques de negação de serviços.

5.106 Deve possuir o seguinte mecanismo de inspeção de IPS:

5.106.1 Análise de padrões de estado de conexões.

5.106.2 Análise de decodificação de protocolo.

5.106.3 Análise para detecção de anomalias de protocolo.

5.106.4 Análise heurística.

5.106.5 IP Defragmentation.

5.106.6 Remontagem de pacotes de TCP.

5.106.7 Bloqueio de pacotes mal formados.

5.107 Ser imune e capaz de impedir ataques básicos como: Syn flood, ICMP flood, UDP flood, etc.

5.108 Deve detectar e bloquear a origem de portscans.

5.109 Deve bloquear ataques efetuados por worms conhecidos.

5.110 Deve possuir assinaturas específicas para a mitigação de ataques DoS e DDoS.

5.111 Deve possuir assinaturas para bloqueio de ataques de buffer overflow.

5.112 Deve possibilitar a criação de assinaturas customizadas pela interface gráfica do produto.

5.113 Deve permitir usar operadores de negação na criação de assinaturas customizadas de IPS ou anti-spyware, permitindo a criação de exceções com granularidade nas configurações.

5.114 Deve permitir o bloqueio de vírus e spywares em, pelo menos, os seguintes protocolos: HTTP, FTP, SMB, SMTP e POP3.

5.115 Deve identificar e bloquear comunicação com botnets.

5.116 Deve registrar na console de monitoração as seguintes informações sobre ameaças identificadas: O nome da assinatura ou do ataque, aplicação, usuário, origem e o destino da comunicação, além da ação tomada pelo dispositivo.

5.117 Deve suportar a captura de pacotes (PCAP), por assinatura de IPS ou por filtro pré-definido.

5.118 Deve possuir a função de proteção a resolução de endereços via DNS, identificando requisições de resolução de nome para domínios maliciosos de botnets conhecidas.

5.119 Os eventos devem identificar o país de onde partiu a ameaça.

5.120 Deve incluir proteção contra vírus em conteúdo HTML e javascript, software espião (spyware) e worms.

5.121 Deve possuir proteção contra downloads involuntários usando HTTP de arquivos executáveis e maliciosos.

5.122 Deve ser possível a configuração de diferentes políticas de controle de ameaças e ataques baseado em políticas do firewall considerando Usuários, Grupos de usuários, origem, destino, zonas de segurança, etc, ou seja, cada política de firewall poderá ter uma configuração diferentes de IPS, sendo essas políticas por Usuários, Grupos de usuário, origem, destino, zonas de segurança.

5.123 Deve permitir especificar política por tempo, ou seja, a definição de regras para um determinado horário ou período (dia, mês, ano, dia da semana e hora).

5.124 Deve ser possível a criação de políticas por usuários, grupos de usuários, IPs, redes ou zonas de segurança.

5.125 Deve possuir a capacidade de criação de políticas baseadas na visibilidade e controle de quem está utilizando quais URLs através da integração com serviços de diretório, Active Directory e base de dados local.

5.126 Deve suportar a capacidade de criação de políticas baseadas no controle por URL e categoria de URL.

5.127 Deve possuir pelo menos 60 categorias de URLs.

5.128 Deve possuir a função de exclusão de URLs do bloqueio, por categoria.

5.129 Deve permitir a customização de página de bloqueio.

5.130 Permitir o bloqueio e continuação (possibilitando que o usuário acesse um site potencialmente bloqueado informando o mesmo na tela de bloqueio e possibilitando a utilização de um botão Continuar para permitir o usuário continuar acessando o site).

5.131 Deve incluir a capacidade de criação de políticas baseadas na visibilidade e controle de quem está utilizando quais aplicações através da integração com serviços de diretório, autenticação via LDAP, Active Directory, E-directory e base de dados local.

5.132 Deve possuir integração com Microsoft Active Directory para identificação de usuários e grupos permitindo granularidade de controle/politicas baseadas em usuários e grupos de usuários.

5.133 Deve possuir integração e suporte a Microsoft Active Directory para os seguintes sistemas operacionais: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 e Windows Server 2012 R2.

5.134 Deve possuir integração com Microsoft Active Directory para identificação de usuários e grupos permitindo granularidade de controle/políticas baseadas em usuários e grupos de usuários, suportando single sign-on. Essa funcionalidade não deve possuir limites licenciados de usuários ou qualquer tipo de restrição de uso como, mas não limitado à utilização de sistemas virtuais, segmentos de rede, etc.

5.135 Deve possuir integração com Radius para identificação de usuários e grupos permitindo granularidade de controle/políticas baseadas em usuários e grupos de usuários.

5.136 Deve possuir integração com LDAP para identificação de usuários e grupos permitindo granularidade de controle/políticas baseadas em Usuários e Grupos de usuários.

5.137 Deve permitir o controle, sem instalação de cliente de software, em equipamentos que solicitem saída a internet para que antes de iniciar a navegação, expanda-se um portal de autenticação residente no firewall (Captive Portal).

5.138 Deve possuir suporte a identificação de múltiplos usuários conectados em um mesmo endereço IP em ambientes Citrix e Microsoft Terminal Server, permitindo visibilidade e controle granular por usuário sobre o uso das aplicações que estão nestes serviços.

5.139 Deve implementar a criação de grupos customizados de usuários no firewall, baseado em atributos do LDAP/AD.

5.140 Deve permitir integração com tokens para autenticação dos usuários, incluindo, mas não limitado a acesso a internet e gerenciamento da solução.

5.141 Deve prover no mínimo um token nativamente, possibilitando autenticação de duplo fator.

5.142 Com a finalidade de controlar aplicações e tráfego cujo consumo possa ser excessivo, (como youtube, ustream, etc) e ter um alto consumo de largura de banda, se requer que a solução, além de poder permitir ou negar esse tipo de aplicações, deve ter a capacidade de controlá-las por políticas de máximo de largura de banda quando forem solicitadas por diferentes usuários ou aplicações, tanto de áudio como de vídeo streaming.

5.143 Deve suportar a criação de políticas de QoS e Traffic Shaping por endereço de origem.

5.144 Deve suportar a criação de políticas de QoS e Traffic Shaping por endereço de destino.

5.145 Deve suportar a criação de políticas de QoS e Traffic Shaping por usuário e grupo.

5.146 Deve suportar a criação de políticas de QoS e Traffic Shaping por aplicações.

5.147 Deve suportar a criação de políticas de QoS e Traffic Shaping por porta.

5.148 O QoS deve possibilitar a definição de tráfego com banda garantida.

5.149 O QoS deve possibilitar a definição de tráfego com banda máxima.

5.150 O QoS deve possibilitar a definição de fila de prioridade.

5.151 Suportar priorização em tempo real de protocolos de voz (VOIP) como H.323, SIP, SCCP, MGCP e aplicações como Skype.

5.152 Suportar marcação de pacotes Diffserv, inclusive por aplicação.

5.153 Disponibilizar estatísticas em tempo real para classes de QoS ou Traffic Shaping.

5.154 Deve suportar identificar e opcionalmente prevenir a transferência de vários tipos de arquivos (MS Office, PDF, etc) identificados sobre aplicações (HTTP, FTP, SMTP, etc).

5.155 Deve suportar identificação de arquivos compactados ou a aplicação de políticas sobre o conteúdo desses tipos de arquivos.

5.156 Deve suportar a identificação de arquivos criptografados e a aplicação de políticas sobre o conteúdo desses tipos de arquivos.

5.157 Deve permitir identificar e opcionalmente prevenir a transferência de informações sensíveis, incluindo, mas não limitado a número de cartão de crédito, possibilitando a criação de novos tipos de dados via expressão regular.

5.158 Deve suportar a criação de políticas por geolocalização, permitindo o trafego de determinado País/Países sejam bloqueados.

5.159 Deve possibilitar a visualização dos países de origem e destino nos logs dos acessos.

5.160 Deve possibilitar a criação de regiões geográficas pela interface gráfica e criar políticas utilizando as mesmas.

5.161 Deve suportar VPN Site-to-Site e Cliente-To-Site.

5.162 Deve suportar IPSec VPN.

5.163 Deve suportar SSL VPN.

5.164 A VPN IPSEc deve suportar 3DES.

5.165 A VPN IPSEc deve suportar Autenticação MD5 e SHA-1.

5.166 A VPN IPSEc deve suportar Diffie-Hellman Group 1, Group 2, Group 5 e Group 14.

5.167 A VPN IPSEc deve suportar Algoritmo Internet Key Exchange (IKEv1 e v2).

5.168 A VPN IPSEc deve suportar AES 128, 192 e 256 (Advanced Encryption Standard).

5.169 A VPN IPSEc deve suportar Autenticação via certificado IKE PKI.

5.170 Deve possuir interoperabilidade com os seguintes fabricantes: Cisco, Check Point, Juniper, Palo Alto Networks, Fortinet, SonicWall.

5.171 Deve permitir habilitar e desabilitar túneis de VPN IPSEC a partir da interface gráfica da solução, facilitando o processo de throubleshooting.

5.172 A VPN SSL deve suportar o usuário realizar a conexão por meio de cliente instalado no sistema operacional do equipamento ou por meio de interface WEB.

5.173 A funcionalidades de VPN SSL devem ser atendidas com ou sem o uso de agente.

5.174 Deve permitir que todo o tráfego dos usuários remotos de VPN seja escoado para dentro do túnel de VPN, impedindo comunicação direta com dispositivos locais como proxies.

5.175 Atribuição de DNS nos clientes remotos de VPN.

5.176 Dever permitir criar políticas de controle de aplicações, IPS, Antivírus, Antipyware e filtro de URL para tráfego dos clientes remotos conectados na VPN SSL.

5.177 Deve suportar autenticação via AD/LDAP, Secure id, certificado e base de usuários local.

5.178 Deve suportar leitura e verificação de CRL (certificate revocation list).

5.179 Deve permitir a aplicação de políticas de segurança e visibilidade para as aplicações que circulam dentro dos túneis SSL.

5.180 Deve permitir que a conexão com a VPN seja estabelecida das seguintes formas: Antes do usuário autenticar na estação.

5.181 Deve permitir que a conexão com a VPN seja estabelecida das seguintes formas: Após autenticação do usuário na estação.

5.182 Deve permitir que a conexão com a VPN seja estabelecida das seguintes formas: Sob demanda do usuário.

5.183 Deverá manter uma conexão segura com o portal durante a sessão;

5.184 O agente de VPN SSL ou IPSEC client-to-site deve ser compatível com pelo menos: Windows 7 (32 e 64 bit), Windows 8 (32 e 64 bit), Windows 10 (32 e 64 bit) e Mac OS X (v10.10 ou superior).

5.185 Durante a vigência do contrato a CONTRATADA deve manter os softwares sempre atualizados na versão mais recente sem nenhum custo adicional.

6 Solução de Balanceamento de Carga

6.1 Devido a grande quantidade de acessos simultâneos na plataforma a CONTRATADA deve possuir dentro da solução e Data Center Tier III ou similar sistema de balanceamento de carga com as seguintes características:

6.1.1 Throughput mínimo de camada 4 de 40 Gbps.

6.1.2 Throughput mínimo de camada 7 de 25 Gbps.

6.1.3 Deve suportar no mínimo 35 milhões de conexões concorrentes.

6.1.4 Deve possuir aceleração de SSL baseada em hardware.

6.1.5 Deve estar licenciado para no mínimo 30 instâncias virtuais.

6.1.6 Deve possuir ao menos 128 GB de disco.

6.1.7 Deve possuir ao menos 6 interfaces gigabit ethernet RJ-45.

6.1.8 Deve possuir ao menos 6 interfaces gigabit ethernet SFP.

6.1.9 Deve possuir ao menos 4 interfaces 10 gigabit ethernet.

6.2 Deve suportar a criação de contas de administradores com diferentes perfis de acesso e direitos (Role based).

6.3 A solução deve permitir balancear em camada 7 os seguintes protocolos: HTTP, HTTPs, TurboHTTPS, RADIUS, RDP, SIP, TCPs, DNS, SMTP, RTMP, RTSP, MySQL.

6.4 Deve balancear tráfego entre servidores reais usando algoritmos próprios e usado informação de saúde de servidores reais.

6.5 Deve permitir a configuração de perfis que determinem a criptografia do tráfego entre o equipamento e os servidores reais.

6.6 Quando houver comunicação encriptada esta deverá ser controlada por protocolos SSL/TLS e lista de ciphers.

6.7 Deve suportar os protocolos SSL (v2 e v3) e TLS (v1.0, v1.1, v1.2).

6.8 Deve suportar ao menos os seguintes ciphers: ECDHE-RSA-AES256-GCM- SHA384, ECDHE-RSA-AES256-SHA384, AES256-GCM-SHA384, AES256-SHA, ECDHE-RSA- AES128-GCM-SHA256, AES128-SHA, RC4-SHA.

6.9 Deve ser capaz de reutilizar sessões SSL.

6.10 Para cada um dos servidores que participarão do algoritmo de balanceamento deve ser possivel configurar: peso (para fins de controle de preferencia de encaminhamento de tráfego), o número máximo de conexões suportadas por aquele servidor, o limite máximo de novas conexões por segundo que aquele servidor suporta, diferentes métodos de verificação de saúde, perfil de encriptação entre o sistema e este servidor (SSL/TLS e cipher) e configuração de atraso para encaminhamento de conexões ao servidor caso este tenha sido reiniciado, taxa máxima de novas conexões durante o intervalo de tempo seguinte a reinicialização do servidor, cookie (para fins de identificação de conexões) e indicação se este servidor é backup de outro(s).

6.11 O equipamento oferecido deverá ser capaz de balancear as sessões novas, mas preservar sessões existentes no mesmo servidor, implementando persistência de sessão dos seguintes tipos: endereço de origem, hash de endereço de origem, hash que inclui endereço e porta TCP/UDP, hash baseado em cookie provido pelo servidor real, identificação de sessão SSL, hash de um palavra específica encontrada no cabelho de requisição HTTP do cliente, hash de parametro de URL encontrado em requisição HTTP vinda do cliente, atributo de RADIUS.

6.12 Deve ter capacidade de re-escrever o cookie vindo do servidor real para uso em regras de persistência.

6.13 Deve suportar a configuração de timeouts de conexão submetidas a persistência.

6.14 O sistema deve permitir a seleção do servidor real baseado em informação de cabeçalho de pacotes TCP/IP e HTTP.

6.15 Deve possiblitar a seleção de servidor real baseado em valor de campos de cabeçalho HTTP incluindo pelo menos os conteúdos de HTTP Host, HTTP Referer, HTTP Request URL e SNI (server Name Indicator).

6.16 A seleção por campos de cabeçalho HTTP para fins de roteamento deverá ser feita através de expressões regulares ou match completo.

6.17 O sistema deve permitir a reescrita de mensagens de HTTP request, HTTP Response e de cabeçalho HTTP.

6.18 O sistema deve possibilitar reescrita do parâmetro Location de resposta HTTP condicionado ao uso de strings ou expressões regulares para identificar padrões sobre

os campos: HTTP host, HTTP location, HTTP Referer, HTTP Request URL e endereço de IP de origem.

6.19 O sistema deve possibilitar reescrita, redirecionamento, ou proibir requests HTTP. Deve possibilitar a reescrita dos parâmetros host, URL e Referer do cabeçalho HTTP. Estas operações devem estar condicionadas ao uso de strings ou expressões regulares para identificar padrões sobre os campos: HTTP host, HTTP location, HTTP Referer, HTTP Request URL e endereço de IP de origem.

6.20 O sistema deve possibilitar compressão de dados incluindo: aplicações (java script, SOAP XML, X-javascript, XML) e Texto (CSS, HTML, JavaScript, Plain, XML).

6.21 O sistema deve implementar cache de conteúdo para HTTP, permitindo que objetos sejam armazenados em memória e requisições HTTP sejam respondidas diretamente pela solução, e que este cache:

6.21.1 Para fins de controle de uso de recursos deve ser possível controlar: tamanho máximo de objeto, tamanho máximo de cache do sistema, número máximo de entradas de cache, tempo máximo de cache, regras de exceção.

6.22 O sistema deve possuir perfis de tráfego pre configurados para uso em grupo de servidores reais. Pelo menos os seguintes perfís de serviços/servidores devem estar pre configurados: FTP, TCP, UDP, HTTP Seguro (com offload de TLS/SSL), RADIUS, TCP Seguro (com offload de TLS/SSL).

6.23 Além dos perfís pre configurados o sistema deve permitir a customização dos perfís baseado em bloqueio ou permissão de endereço IP de origem baseado na localização por país (TCP, UDP, HTTP, FTP, HTTP), reputação de endereço de origem (TCP, UDP, HTTP, FTP, HTTP) mantida pelo fabricante, compressão de dados (HTTP), cache de dados (HTTP).

6.24 O sistema deve permitir a personalização de páginas de erro enviadas aos clientes em caso de falha nos servidores. Estas páginas devem ser editadas em HTML;

6.25 Deve implementar NAT, NAT64 e NAT46 (os dois últimos para permitir NAT incluindo IPv4 e IPv6 entre clientes e servidores).

6.26 Deve implementar esquema de autenticação Basic (RFC 2617).

6.27 Deve ter algoritmos de balanceamento de carga pré configurados incluindo pelo menos: Round Robin (seleciona o próximo servidor de uma série pré-configurada), seleção do servidor com menor número de conexões correntes, servidor com a melhor

´saúde´, seleção baseada no hash da URI (cabeçalho HTTP), seleção baseada no hostname (HTTP request), seleção baseada no hash do endereço IP de destino.

6.28 Deve possuir mecanismos de balanceamento de tráfego através de vários enlaces de comunicação.

6.29 Deve possibilitar o balanceamento de tráfego inbound (da WAN para a LAN) e outbound (de LAN para a WAN) usando múltiplos enlaces WAN.

6.30 O tráfego a ser balaceado deve ser selecionado através: de endereços (ou grupo de endereços) IP de origem e de destino, serviços TCP ou UDP, em função do horário (hora, dia, mês, ano), e blocos de endereços de Internet Service Providers.

6.31 Deve possuir mecanismos de persistência de tráfego que ignore algoritmos de balanceamento de tráfego.

6.32 Os mecanismos de persistência devem ser estabelecidos em função de endereços IP destino e origem.

6.33 Deve possuir mecanismos de seleção de rotas em função de latência de tráfego ao destino medido através de ICMP ou TCP echo.

6.34 Para um dado grupo de enlaces de comunicação usados para balanceamento de tráfego, os algoritmos de distribuição de tráfego devem fazer uso de, pelo menos, os seguintes parâmetros: número de conexões sendo tratadas pelo enlace, taxa de novas conexões sendo abertas no enlace, menor quantidade de tráfego entrante do enlace, menor quantidade de tráfego sainte do enlace, soma de tráfego entrante e sainte do enlace, utilização de enlaces (entrada e saída) ou peso dado ao enlace.

6.35 Deve ser capaz de estabelecer túneis virtuais com sistemas do mesmo fabricante para transporte de tráfego entre os equipamentos.

6.36 Suporte a estabelecimento de túneis usando encapsulamento GRE (Generic Routing Encapsulation).

6.37 Deve balancear o tráfego entre estes enlaces virtuais baseado em pesos atribuidos aos enlaces ou função de cálculos de hash de endereços IP de origem e destino.

6.38 Suporte a monitoração de estado de saúde de links com ISPs e enlaces virtuais.

6.39 Deve ser possível estabelecer um dos enlaces (virtual ou real) como enlace de backup (usado somente quando primários não estão disponíveis).

6.40 As interfaces de rede devem suportar protocolo Ethernet com pelo menos as seguintes velocidades: 10 Mbps (half e full duplex), 100 Mbps (half e full duplex), 1000 Mbps (half e full duplex) e autonegociação.

6.41 Deve implementar o protocolo IEEE 802.3ad para balanceamento de tráfego entre portas.

6.42 Deve implementar VLANs e ser compatível com o protocolo IEEE 802.1q.

6.43 Deve permitir o roteamento entre diferentes VLANs.

6.44 Deve suportar a configuração de rotas estáticas incluindo a distância administrativa da mesma para fins de decisão de roteamento de pacotes.

6.45 Deve oferecer suporte a políticas de roteamento baseado em endereços IP de origem e/ou destino.

6.46 Deve suportar OSPF v2 - RFC 2328.

6.47 Deve implementar NAT (Network Address Translation) incluindo as seguintes modalidades: Source NAT (mudança do endereço IP de origem), mapeamento 1-1 e encaminhamento de portas (UDP ou TCP).

6.48 Deve fazer alocação de banda passante baseado no trio endereço destino, endereço de origem e serviço (portas TCP e UDP).

6.49 O equipamento oferecido deverá ser capaz de abrir um número reduzido de conexões TCP com o servidor e inserir os pacotes gerado pelos clientes nestas conexões, reduzindo a necessidade de estabelecimento de conexões nos servidores e aumentando a performance do serviço.

6.50 Deve implementar cache de caminho reverso assegurando que a resposta a um cliente seja encaminhada através do mesmo provedor usado no recebimento de pacote do mesmo.

6.51 Deve suportar implementação em modo transparente, atuando como Bridge L2.

6.52 Deve implementar mecanismos de verificação de ´saúde´ em serviços remotos através de, pelo menos, os seguintes protocolos: ICMP, TCP Echo, TCP, HTTP, HTTPS, DNS, RADIUS, SMTP, POP3, IMAP4, RADIUS Accounting, FTP, TCP Half Open, TCP SSL, SNMP, SSH, L2 Detection, UDP, ARP e NDP (IPv6).

6.53 Deve possuir funcionalidades de Global Server Load Balancing.

6.54 Deve implementar servidor DNS baseado em versão protegida de BIND versão 9.

6.55 Deve implementar servidor DNS Autoritativo.

6.56 Deve permitir o balaneceamento de tráfego entre diversos sítios remotos baseado em DNS e tendo como parâmetros, pelo menos, localização, ´saúde´ de servidores e tempo de resposta de aplicações em ambos IPv4 e IPv6.

6.57 Deve suportar DNSSEC com algoritmo RSASHA1.

6.58 Deve implementar DNS64 para permitir comunicação entre client IPv4 com servidores IPv6 no escopo de balanceamento de carga global.

6.59 Deve possibilitar estabelecer a configuração de sítios baseados em localização geográfica (países) e, para caso da China em províncias e provedores de acesso Internet. A base de dados associando endereços IP a países deve ser desenvolvida e gerenciada pelo fabricante.

6.60 Deve implementar mecanismos de verificação de ´saúde´ em serviços remotos através de, pelo menos, os seguintes protocolos: ICMP, TCP Echo, TCP, HTTP, HTTPS,

DNS, RADIUS, SMTP, POP3, IMAP4, RADIUS Accounting, FTP, TCP Half Open, TCP SSL, SNMP, SSH, L2 Detection, UDP, ARP e NDP (IPv6).

6.61 Deve possibilitar a definição de disponibilidade de serviços através de verificação de saúde em vários protocolos baseados em expressões com AND e OR.

6.62 Suportar a criação de políticas de DNS. Entende-se por políticas de DNS a maneira pela qual o balanceador irá interpretar e responder a uma requisição DNS, levando em conta os seguintes parâmetros: proximidade geográfica, proximidade de tempo e algoritmo de distribuição de pedidos.

6.63 A implementação do mecanismo de proximidade geográfica deve levar em conta o endereço de IP de origem (país) e endereço de destino (país). A associação entre endereços IP e países deve ser implementada e gerenciada pelo fabricante e incluida no sistema.

6.64 A implementação do mecanismo de proximidade de tempo deve ser baseada em ICMP e/ou TCP.

6.65 Para cada um dos possíveis sítios remotos deve ser possível atribuir peso aos mesmos para que este parâmetro seja levado em conta na sequência de distribuição de respostas DNS.

6.66 Quando implementado como servidor DNS autoritativo deve permitir a configuração de número máximo de respostas fornecidas por segundo.

6.67 Deve permitir a troca de portas HTTP, HTTPS, Telnet e SSH para fins de acesso remoto ao equipamento por parte do administrador.

6.68 Deve suportar a sincronização de horário via NTP.

6.69 Deve prover pelo menos dois tipos de backup: o primeiro simples gerando uma configuração a nível de linha de comando e um segundo que complementa o primeiro com o backup de arquivos importados para completar a configuração do sistema (páginas de erro, scripts e arquivos de blocos de endereço IP associados a provedores).

6.70 Deve permitir o upgrade através de linha de comendo ou interface gráfica.

6.71 Deve permitir o processo de upgrade em partições distintas.

6.72 Deve suportar o update das bases de dados de assinaturas de firewall de aplicação web, reputação IP e de endereços IP baseados em localização de forma separada e sem a necessidade de reinicialização do sistema.

6.73 Deve suportar o update das bases de dados de assinaturas de forma programada indicando dia da semana e hora do dia.

6.74 Deve suportar a configuração de um servidor de email para o envio de emails de alerta.

6.75 Deve implementar o agente de SNMP v1, V2c e 3 (RFC 3414).

6.76 Deve permitir a configuração de eventos SNMP de, pelo menos, níveis de uso de CPU, memória e disco.

6.77 Deve suportar o uso de certificados para suportar e gerenciar conexão de clientes usando os mesmos incluindo pelo menos: extensão TLS Server Name Indicator (SNI), armazenamento local de certificados (certificados X.509 v3 chaves privadas usadas pelos servidores), armazenamento e uso de certificados gerados de um dado CA, OCSP (Online Certificate Status Protocol), CRL (certificate revocation list) e solicitar certificado a um CA via SCEP (simple certificate enrollment protocol).

6.78 O sistema deve possuir painel, via interface gráfica, que permita ao administrador visualização informações sobre o sistema incluindo pelo menos: estado do sistema (versão de firmware, utilização de CPU, utilização de memória, utilização de disco, número de conexões correntes, número de taxa de conexões, banda de entrada e de saída usada, logs mais recentes), balanceamento de carga (servidores reais, banda de entrada, de saída o número de conexões).

6.79 Deve possuir, via interface gráfica, painel que mostre logs de eventos, de segurança e de tráfego de dados incluindo atividades dos administradores e de sistema.

6.80 Deve implementar filtros que possibilitem a visualização de eventos de Configuração: indicando mudanças na configuração do sistema, usuário que fez a alteração, ação (edição, adição ou exclusão), configuração que foi alterada.

6.81 Deve implementar filtros que possibilitem a visualização de eventos de Administração: indicando ações executadas por administradores.

6.82 Deve implementar filtros que possibilitem a visualização de eventos de Sistema: indicando informações relevantes a operação, avisos e erros gerados pelo sistema.

6.83 Deve implementar filtros que possibilitem a visualização de eventos de Usuário indicando atividades de autenticação de usuários, incluindo informações como: nome do usuário, grupo e política de autenticação usada.

6.84 Deve implementar filtros que possibilitem a visualização de eventos de Verificação de saúde: indicando resultados de verificação de saúde, estado de validação de certificados, nome ou identificador do servidor real, estado da verificação: sucesso ou falha.

6.85 Deve implementar filtros que possibilitem a visualização de eventos de Balanceamento de servidores: indicando que o número de conexões máximo foi atingido; identificador do servidor real, política relacionada ao evento.

6.86 Deve implementar filtros que possibilitem a visualização de eventos de Balanceamento de Enlaces: indicando que limite de banda foi atingido; política relacionada ao evento.

6.87 Deve implementar filtros que possibilitem a visualização de eventos de Balanceamento de Carga Global: identificador do servidor real, política relacionada ao evento.

6.88 Deve implementar filtros que possibilitem a visualização de eventos de Firewall: política relacionada ao evento.

6.89 Deve implementar filtros que possibilitem a visualização de eventos de Segurança - Reputação IP: indicando protocolo usado, endereços IP e portas de origem e destino, países de origem e destino do tráfego, nome da regra de segurança e ação tomada pela política.

6.90 Deve implementar filtros que possibilitem a visualização de eventos de Segurança - DoS (Deny of Service): indicando protocolo usado, endereços IP e portas de origem e destino, países de origem e destino do tráfego, nome da regra de segurança e ação tomada pela política.

6.91 Deve implementar filtros que possibilitem a visualização de eventos de Segurança - Firewall de aplicações web: indicando protocolo usado, endereços IP e portas de origem e destino, países de origem e destino do tráfego, nome da regra de segurança e ação tomada pela política e módulo de segurança de firewall para aplicações web relacionado (assinaturas, acesso a URL não permitidas, Cross Site script

/ Injeção SQL), URL e conteúdo do cabeçalho da mensagem HTTP.

6.92 Deve implementar filtros que possibilitem a visualização de eventos de Segurança - Geo: indicando protocolo usado, endereços IP e portas de origem e destino, países de origem e destino do tráfego, nome da regra de segurança e ação tomada pela política.

6.93 Deve implementar filtros que possibilitem a visualização de eventos de tráfego de balanceamento de carga de camada 4: protocolo, bytes in, bytes out, endereços IP e portas de origem e destino, países de origem e destino do tráfego.

6.94 Deve implementar filtros que possibilitem a visualização de eventos de tráfego de balanceamento de carga de camada 7: protocolo, bytes in, bytes out, endereços IP e portas de origem e destino, países de origem e destino do tráfego, método HTTP, código de retorno HTTP, base URL, nome do cookie, nome do usuário, nome do grupo e estado de autenticação quando aplicável.

6.95 Deve implementar filtros que possibilitem a visualização de eventos de tráfego de balanceamento global: protocolo, bytes in, bytes out, endereços IP e portas de origem e destino, países de origem e destino do tráfego, FQDN solicitado, endereço de resposta do DNS, nome da política usada.

6.96 Para cada um dos eventos (logs de eventos, segurança e de tráfego) devem ser obrigatório indicação de: data, hora, nível de log, identificador da mensagem de log.

6.97 Deve ser capaz de armazenar logs no próprio sistema.

6.98 Deve permitir a seleção do menor nível de log a ser gravado localmente.

6.99 Deve permitir a seleção do tipo de log a ser armazenado localmente (Eventos, Segurança e Tráfego) para evitar uso excessivo do disco.

6.100 Deve ser capaz de enviar notificações de logs a servidor syslog.

6.101 Deve permitir a seleção do menor nível de log a ser enviado para o servidor syslog.

6.102 Deve permitir o envio de logs a servidor syslog no formato CSV.

6.103 Deve permitir a seleção do tipo de log a ser enviado ao servidor syslog.

6.104 A solução deve suportar o envio de alertas através de emails, estes alertas podem ser configurados de acordo com a categoria de eventos ou níveis de severidade.

6.105 Deve suportar o envio de alertas através de emails relacionados a pelo menos eventos de: alta disponibilidade, administração, configuração, disco, verificação de saúde, expiração de certificados.

6.106 Deve permitir e emissão de relatorios sob demanda ou programados.

6.107 Deve suportar o envio via email dos relatórios programados em formato PDF.

6.108 Pelo menos os seguintes relatórios devem estar disponíveis no sistema:

6.108.1 Para balanceamento de tráfego de servidores: políticas mais usadas e bytes associados, origens mais ativas e bytes associados e origens mais ativas por país e bytes associados, histórico de fluxo em bytes.

6.108.2 Para balanceamento de tráfego entre enlaces: enlaces mais usados e bytes associados, histórico de fluxo em bytes; Reputação IP: destinos (alvos) mais frequentes com contagem associada, origens mais frequentes com contagem associada, origens mais frequentes com contagem e geografia associadas.

6.108.3 DoS: destinos (alvos) mais frequentes com contagem associada.

6.108.4 Geografias: destinos (alvos) mais frequentes com contagem associada, origens mais frequentes com contagem associada, origens mais frequentes com contagem associada e país.

6.108.5 Firewall para aplicação web: destinos (alvos) mais frequentes com contagem associada, origens mais frequentes com contagem associada, origens mais frequentes com contagem e geografia associadas.

6.109 Deve implementar características de redundância e alta disponibilidade em cluster do mesmo modelo, nos modos ativo-passivo e ativo-ativo.

6.110 A formação do cluster deve permitir a sincronização de configuração e versão de sistema operacional entre os participantes.

6.111 Possuir mecanismos de monitoração de estado de interface que permita a alteração de estado do membro, de ativo para passivo, em caso de falha.

6.112 Os participantes do cluster dever ser do mesmo modelo e ter a mesma versão de sistema operacional.

6.113 Pelo menos as seguintes informações devem ser sincronizadas entre os membros do cluster: configuração principal (linha de comando), certificados X.509, arquivos de pedido de assinatura de certificados (certificate signing request files -CSR), chaves privadas, arquivos relativos a mensagens de erro, estados das conexões de nível 4, estados de persistência de nível 4 e nível 7.

6.114 Quando em ativo-passivo apenas um dos membros encaminhará tráfego enquanto que o passivo só encaminhará tráfego caso haja falha no ativo.

6.115 Quando em ativo-passivo o cluster ainda deverá manter a sincronização de sistema operacional e de configuração, minimizando impacto em caso de falha do ativo. Neste caso a transição deverá ser automática, sem intervençao externa ao cluster.

6.116 Na configuração ativo-ativo todos os membros do cluster deverão encaminhar tráfego.

6.117 Na configuração ativo-ativo o equipamento deverá ser capaz de compor um cluster com dois ou mais equipamentos da mesma família. Permitindo até 8 equipamentos.

6.118 Deve permitir a configuração de parâmetro relativo a eleição do sistema primário (aquele em que as configurações são feitas e encaminhadas aos outros membros) dentro do mesmo cluster.

6.119 Se necessário, deve permitir aplicar configurações em qualquer membro do cluster, independentemente se este é primário ou secundário.

6.120 A sincronização da configuração do cluster pode ser realizada através de portas agregados.

6.121 Deve possuir funcionalidades de virtualização, deve possibilitar a implementação de várias instâncias de sistema;

6.122 Deve permitir o provisionamento de diferentes administradores para cada uma das instâncias de sistema.

6.123 A solução deve permitir a encriptação/decriptação de sessões SSL no lugar dos servidores (processo conhecido como SSL Offload).

6.124 Quando efetuando SSL Offload, deve agir como proxy dos servidores para fins de processamento SSL, usando certificados e chaves dos servidores para, pelo menos: autenticar os próprios servidores junto aos clientes, de-encriptar pedidos e encriptar respostas aos clientes.

6.125 Deve possibilitar a implementação na rede como proxy SSL, neste caso desempenhando papel de proxy para os dois lados da conexão (clientes e servidores).

6.126 Deve suportar pelo menos ciphers: RSA, PFS, ECDHE e eNull para SSL Offload.

6.127 Deve suportar a configuração de ciphers para SSL Offload.

7 Solução de Armazenamento de Logs e Relatórios

7.1 Deve possuir capacidade de receber ao menos 500 GigaBytes de logs diários.

7.2 Não deve possuir limite de utilização de disco.

7.3 Deve suportar acesso via SSH, WEB (HTTPS) e Telnet para o gerenciamento da solução.

7.4 Deve possuir comunicação cifrada e autenticada com usuário e senha para solução de relatórios, tanto como para a interface gráfica de usuário e console de administração por linha de comandos (SSH).

7.5 Permitir acesso simultâneo de administradores permitindo a criação de ao menos 2 (dois) perfis para administração e monitoração.

7.6 Suportar SNMP versão 2 e versão 3 na solução de relatórios.

7.7 Deve permitir a criação de administradores que acessem todas as instâncias de virtualização da solução de relatórios.

7.8 Deve permitir habilitar e desabilitar, para cada interface de rede da solução de relatórios, permissões de acesso HTTP, HTTPS, SSH, SNMP e Telnet.

7.9 Deve possuir autenticação integrada a servidor Radius.

7.10 Deve permitir a geração de relatórios em tempo real, para a visualização de tráfego observado, nos formatos: mapas geográficos e tabela.

7.11 Deve possuir autenticação integrada ao Microsoft Active Directory.

7.12 Deve possuir definição de perfis de acesso à console com permissões granulares como: acesso de escrita, acesso de leitura, criação de usuários, alteração de configurações.

7.13 Possuir mecanismo para que logs antigos sejam removidos automaticamente.

7.14 Permitir a importação e exportação de relatórios.

7.15 Deve possuir a capacidade de criar relatórios nos formatos PDF.

7.16 Deve ser possível exportar os logs em CSV.

7.17 Deve gerar logs de auditoria detalhados, informando a configuração realizada, o administrador que a realizou e o horário da alteração.

7.18 Os logs gerados pelos appliances devem ser centralizados nos servidores de gerência, mas a solução deve oferecer também a possibilidade de utilização de um syslog externo ou similar.

7.19 A solução deve possuir relatórios pré definidos.

7.20 Possuir envio automático de logs para um servidor FTP externo a solução.

7.21 Permitir de forma centralizada visualizar os logs recebidos por um ou vários dispositivos externos incluindo a capacidade de uso de filtros nas pesquisas deste log.

7.22 Logs de auditoria para configurações de regras e objetos devem ser visualizados em uma lista diferente da que exibe os logs relacionados a tráfego de dados.

7.23 Deve possuir a capacidade de personalização de gráficos como barra, linha e tabela para inserção aos relatórios.

7.24 Deve possuir mecanismo "Drill-Down" para navegação nos relatórios em realtime.

7.25 Dever ser possível fazer download dos arquivos de logs recebidos.

7.26 Deve possuir agendamento para gerar e enviar automaticamente relatórios.

7.27 Deve permitir customização de quaisquer relatórios fornecidos pela solução, exclusivamente pelo administrador, adaptando-o às suas necessidades.

7.28 Permitir o envio de maneira automática de relatórios por email.

7.29 Permitir programar a geração de relatórios, conforme calendário definido pelo administrador.

7.30 Deve ser possível definir filtros nos relatórios

7.31 Deve ser capaz de definir o layout do relatório, incluir gráficos, inserir textos e imagens, alinhamento, quebras de páginas, definir fontes, cores, entre outros.

7.32 Deve gerar alertas automáticos via Email, SNMP e Syslog baseados em eventos como ocorrência como log, severidade de log, entre outros.

7.33 Deve ser capaz de criar consultas SQL ou semelhante para uso nos gráficos e tabelas de relatórios.

7.34 Deve ter a capacidade de visualizar na GUI da solução de relatórios informações do sistema como licenças, memória, disco, uso de CPU, taxa de logs por segundo recebidos, total de logs diários recebidos, alertas gerados entre outros.

7.35 Deve permitir ver em tempo real os logs recebidos

7.36 Deve permitir a criação de Dashboards customizados para visibilidades do tráfego de aplicativos, categorias de URL, ameaças, serviços, países, origem e destino.

7.37 Deve possuir relatório detalhado de prevenção de perda de dados (DLP).

7.38 Deve possuir relatório de VPN.

7.39 Deve possuir relatório de Sistemas de prevenção de intrusão (IPS).

7.40 Deve possuir relatório de reputação do cliente.

7.41 Deve possuir relatório de análise de segurança do usuário.

7.42 Deve possuir relatório de avaliação da ameaça cibernética.

8 Data Center - padrão TIER III

O datacenter onde os componentes servidores da PLATAFORMA serão instalados deverá estar localizado no território nacional e ter uptime superior a 99,749%, redundância parcial de refrigeração e fornecimento de energia e ocorrências de indisponibilidade inferiores a 20 por ano, sendo aceita a comprovação por meio de certificação TIER 3.

O datacenter deve atender no mínimo as seguintes características:

8.1 Deve ser atendido por no mínimo duas empresas de telecomunicações.

8.2 Os cabos das empresas de telecomunicação devem vir por rotas distintas até o Data Center.

8.3 Deve estar em zonas de proteção contra incêndios.

8.4 Possuir sistemas de energia e ar-condicionado distintos.

8.5 As conexões entre as salas devem ser feitas via fibra ou pares metálicos redundantes.

8.6 Prover pelo menos a redundância elétrica N+1.

8.7 Deve possuir disponibilidade mínima de 99,749% e até 72 horas de proteção contra interrupção de energia.

ESPECIFICAÇÃO TÉCNICA DO MODEM WI-FI PORTÁTIL (ITEM 3 e 4)

O MODEM WI-FI PORTÁTIL deve apresentar no mínimo as seguintes características:

1. Especificações básicas

1.1. Possuir suporte à tecnologia e-sim;

1.2. Apresentar compatibilidade com os seguintes requisitos:

1.2.1. Para conectividade o Dispositivo deve suportar:

1.2.1.1. Ao menos uma das tecnologias de rede de acesso definidas pelo 3GPP na seguinte lista não exaustiva:

1.2.1.2. GERAN,

1.2.1.3. UTRAN,

1.2.1.4. E-UTRAN.

1.2.1.5. UDP over IP (sujeito ao suporte correto de tecnologia de rede de acesso)

1.2.1.6. TCP over IP (sujeito ao suporte correto de tecnologia de rede de acesso)

1.2.2. Para controle de conexão de rede, o Dispositivo deve suportar:

1.2.2.1. Detalhes RPLMN (LAC/TAC, NMR).

1.2.2.2. QoS (falhas, duração, energia, localização).

1.2.2.3. Gerenciamento SMS.

1.2.2.4. Nova seleção de rede após atualização do SIM/USIM.

1.2.3. Para reportar a um servidor o Dispositivo deve suportar:

1.2.3.1. SMS-PP MO como definido em e SMS-PP MO como definido ou

1.2.3.2. BIP como definido em DEV4

1.2.4. O Dispositivo deve suportar:

1.2.4.1. USSD

1.2.5. Para Gerenciamento de Perfil e Plataforma o Dispositivo deve suportar:

1.2.5.1. SMS-PP MT como definido em, e SMS-PP MT como definido em ou

1.2.6. BIP (sujeito ao suporte correto de tecnologia de rede de acesso) como definido em incluindo suporte aos comandos:

1.2.6.1. OPEN CHANNEL (UDP e TCP over IP)

1.2.6.2. CLOSE CHANNEL

1.2.6.3. RECEIVE DATA

1.2.6.4. SEND DATA

1.2.6.5. GET CHANNEL STATUS

1.2.6.6. ENVELOPE (EVENT DOWNLOAD – Dados disponíveis)

1.2.6.7. ENVELOPE (EVENT DOWNLOAD – Status do canal)

1.2.7. O Dispositivo deve conter um valor de IMEI (International Mobile Equipment Identity) único compatível com o formato definido na ETSI TS 123 003.

1.2.8. O valor do IMEI deve ser copiado diretamente do TERMINAL RESPONSE do comando Provide Local Information (ver ETSI TS 102 223 e ETSI TS 124 008).

1.2.9. O dispositivo deve suportar, no mínimo, o seguinte conjunto de comandos (além dos comandos BIP), conforme definido em ETSI TS 102 223 e 3GPP TS 31.111.

1.2.10. Comandos SAT básicos (TERMINAL PROFILE, FETCH, TERMINAL RESPONSE).

1.2.11. PROVIDE LOCAL INFORMATION (informações de localização, IMEI, NMR, data e hora, tecnologia de acesso, pelo menos).

1.2.12. SEND SHORT MESSAGE

1.2.13. POLL INTERVAL, POLLING OFF, TIMER MANAGEMENT [pelo menos um cronômetro], ENVELOPE (EXPIRAÇÃO DO TEMPORIZADOR)

1.2.14. SET UP EVENT LIST e ENVELOPE (EVENT DOWNLOAD status de localização, chamada conectada, chamada desconectada, tecnologia de acesso alterada, rejeição de rede)

1.2.15. ENVELOPE (SMS-PP DOWNLOAD).

1.2.16. REFRESH Command (Ao menos modo 4 – “UICC reset”).

1.2.17. O dispositivo deve estar em conformidade com o document GSMA – EICTA “Security Principles Related to Handset Theft”.

1.2.18. O dispositivo pode recuperar o EID definido na seção 2.2.2 desta especificação do eUICC e deve suportar os seguintes comandos, conforme descrito em:

1.2.18.1. AT+CCHO (Canal lógico aberto)

1.2.18.2. AT+CCHC (Fechar Canal Lógico)

1.2.18.3. AT+CGLA (Acesso de canal lógico UICC genérico)

1.2.19. O dispositivo deve suportar os seguintes comandos para todos os fins genéricos:

1.2.19.1. AT+CRSM (Acesso restrito ao SIM)

1.3. Permitir remotamente a troca de operadora;

1.4. Possuir chipset Qualcomm MDM 9307;

1.5. Possuir no mínimo 2 (dois) Slots:

• Um, para SIM 3FF (micro-SIM card);

• E outro, para Micro SD (de até 32 GB).

1.6. Ter memória mínima de 2 Gb;

1.7. Possibilitar no mínimo 10 (dez) dispositivos conectados simultaneamente.

2. Especificações de rádio frequência (RF)

2.1. Possuir no mínimo padrão de redes de comunicação móveis LTE (Long Term Evolution):

• FDD Banda 3/7;

• TDD Banda 38/39/41.

2.2. Fornecer no mínimo as seguintes larguras de banda do canal: 1.4/3/5/10/15/20 MHz

2.3. Fornecer Wi-Fi padrão 802.11b/g/n de 2,4 GHz

2.4. Possuir sistema MIMO: DL 2x2

2.5. Taxa de transferência:

• Possuir LTE categoria 4: 150 Mbps / 50 Mbps;

• Apresentar taxa de transferência de Wi-Fi de 150 Mbps

2.6. Possuir antena LTE modo 1T2R, e Wi-Fi modo 1T1R

3. Deve suportar no mínimo os sistemas operacionais abaixo:

3.1. Linux;

3.2. Mac OS;

3.3. Windows XP/ Windows Vista/ Windows 7/ Windows 8.

4. Compatibilidade / Manutenção

4.1. Permitir configuração de data e hora;

4.2. Permitir opção de reset;

4.3. Permitir restauração das configurações de fábrica;

4.4. Possuir diagnóstico em rede: Ping e trace route.

5. Possuir certificação ISO 9001.

6. Equipamento deve ser homologado na Anatel.

7. Possuir as seguintes funções:

7.1. SMS (Short Message Service - serviço de mensagens curtas);

7.2. Estatísticas de fluxo;

7.3. WPS (Wireless Priority Service – serviço de prioridade sem fio);

7.4. WDS (Wireless Distribution System - Sistema de distribuição sem fio);

7.5. DHCP (Dynamic Host Configuration Protocol - protocolo de configuração dinâmica de hosts);

7.6. DNS (Domain Name System - sistema de nomes de domínio);

7.7. DDNS (DNS dinâmico);

7.8. Encaminhamento de portas;

7.9. uPnP (Plug and Play universal);

7.10. Firewall (política de segurança em rede);

7.11. Wi-Fi storage: Armazenamento de dados da rede Wi-Fi no cartão de memória;

7.12. OTA (Over-the-Air): Utilizado para determinar o desempenho do sistema sem fio nos dispositivos habilitados;

7.13. APK (Android Package): É um arquivo de pacote destinado ao sistema operacional Android.

8. Características físicas e gerais

8.1. Deve acompanhar um cabo USB para que possa carregar a bateria quando conectado à uma porta USB energizada, com 5 V e até 1 A de saída;

8.2. Bateria 3000 mAh;

8.3. Tempo máximo de trabalho: 13 horas;

8.4. Tempo máximo em standby: 500 horas;

8.5. Botão liga/desliga;

8.6. Botão WPS (Wireless Priority Service);

8.7. Uma porta USB 2.0 micro-B;

8.8. Temperatura de operação: -10 ºC ~ 60 ºC;

8.9. Dimensões: 85x68x16 mm;

8.10. Peso aproximado: 150 gramas (com bateria).

8.11. Especificação do e-sim fornecido juntamente com o Dispositivo de Acesso

8.11.1. Deverá ser fornecido no formato triplo corte (2FF, 3FF e 4FF).

8.11.2. Deverá ser compatível com o padrão eUICC estabelecido pela GSMA.

8.11.3. Deverá possuir capacidade mínima de 512Kb.

8.11.4. Arquitetura composta pelos seguintes itens:

8.11.5. eUICC

8.11.6. RAM/RFM/Keys;

8.11.7. SM/Data/Keys;

8.11.8. SMC

8.11.9. MNO1

8.11.10. Applets;

8.11.11. RAM/RFM/Keys;

8.11.12. File System;

8.11.13. NAA Data;

8.11.14. Policies.

8.11.15. MNO 2

8.11.16. Applets;

8.11.17. RAM/RFM/Keys;

8.11.18. File System;

8.11.19. NAA Data;

8.11.20. Policies.

Xxxxx Xxxxxxxx Xxxxxx xx Xxxxxxxx Xxxxxxx Secretário Municipal de Educação

Document Metadata

Table of Contents

ANEXO II TERMO DE REFERÊNCIA

Document Metadata