EDITAL DE PREGÃO ELETRÔNICO – SEMIT Nº 003/2024 LICITAÇÃO Nº 003/2024
EDITAL DE PREGÃO ELETRÔNICO – SEMIT Nº 003/2024 LICITAÇÃO Nº 003/2024
A Secretaria Municipal de Inovação e Tecnologia – SEMIT, através da Comissão Especial Mista de Licitação – CEML, constituída pelo Decreto nº 37.022/2023, torna público para conhecimento dos interessados que realizará por meio de sistema eletrônico, licitação na modalidade PREGÃO ELETRÔNICO, tipo menor preço, autorizada no processo nº 247521/2023 – SEMIT, e de acordo com as condições estabelecidas neste edital, aprovado pela RPGMS/SEMIT através do Parecer Jurídico à fls. 335/343.
O Pregão será realizado em sessão pública, por meio dos recursos da tecnologia da informação - INTERNET, utilizando-se, para tanto, de métodos de autenticação de acesso e recursos de criptografia, garantindo segurança em todas as fases do certame.
Os trabalhos serão conduzidos por servidor público, denominado PREGOEIRO, mediante a inserção e monitoramento de dados gerados ou transferidos para o sistema eletrônico do Banco do Brasil, sítio xxx.xxxxxxxxxx-x.xxx.xx, bem como pelas disposições constantes deste Edital.
1. REGÊNCIA LEGAL
1.1. Os procedimentos da licitação serão regidos pela Lei Municipal nº 6.148/02, Lei nº 10.520/2002, Lei Complementar nº 123/2006, alterada pela Lei Complementar nº 147/2014 (ME e EPP), Decretos Municipais nºs 13.724/02 (alterado pelo Dec. nº 15.814/2005), 15.611/05 (alterado pelo Dec. nº 20.200/2009), 15.814/05, 15.984/05 e 24.900/2014 (alterado pelo Decreto nº 25.696/14), das normas gerais da Lei nº 8.666/93 (alterada pela Lei n.° 12.440/2011) e Lei Municipal nº 4.484/92, no que couber.
2. OBJETO
2.1. Contratação, na modalidade Registro de Preços, de empresa especializada em Tecnologia da Informação e Comunicação – TIC, para fornecimento de equipamentos de Segurança da Informação, Conectividade de Redes Wired e Wireless e Cibersegurança, englobando o fornecimento do projeto executivo, hardware, software, subscrições, instalações, configurações, suporte técnico local, treinamento e demais insumos necessários para o pleno funcionamento das soluções, para atender a população soteropolitana e as necessidades dos diversos órgãos e entidades da Prefeitura Municipal do Salvador.
3. RECEBIMENTO E ABERTURA DAS PROPOSTAS E DA REFERÊNCIA DE TEMPO
3.1. Site xxx.xxxxxxxxxx-x.xxx.xx.
3.2. Recebimento das propostas a partir das 09:00 horas do dia 04/03/2024.
3.3. Abertura das propostas às 09:30 horas do dia 05/03/2024.
3.4. Início da sessão de disputa de preços às 10:00 horas do dia 05/03/2024.
3.5. O interessado deverá observar, rigorosamente, as datas e os horários limites para o recebimento e a abertura da proposta, atentando, também, para o início da disputa.
3.6. Todas as referências de tempo no Edital, no Aviso e durante a sessão pública, observarão, obrigatoriamente, o horário de Brasília – DF e, dessa forma, serão registradas no sistema eletrônico e na documentação relativa ao certame.
4. DO ÓRGÃO GERENCIADOR E ÓRGÃOS PARTICIPANTES
4.1. O órgão gerenciador será a Secretaria Municipal de Inovação e Tecnologia – SEMIT.
4.2. Serão participantes os órgãos e entidades da Administração Direta da Prefeitura Municipal de Salvador – PMS.
4.3. São participantes os seguintes órgãos:
4.3.1. Secretaria do Governo – SEGOV
4.3.2. Gabinete do Vice-Prefeito – GABVP
4.3.3. Controladoria Geral do Município de Salvador – CGM
4.3.4. Procuradoria Geral do Município do Salvador – PGMS
4.3.5. Casa Civil
4.3.6. Secretaria Municipal da Comunicação – SECOM
4.3.7. Secretaria Municipal de Gestão – SEMGE
4.3.8. Secretaria Municipal de Inovação e Tecnologia – SEMIT
4.3.9. Secretaria Municipal da Fazenda – SEFAZ
4.3.10. Secretaria Municipal de Desenvolvimento Urbano – SEDUR
4.3.11. Secretaria Municipal de Sustentabilidade, Resiliência, Bem estar e Proteção Animal– SECIS
4.3.12. Secretaria Municipal de Cultura e Turismo – SECULT
4.3.13. Secretaria Municipal de Desenvolvimento Econômico, Emprego e Renda – SEMDEC
4.3.14. Secretaria Municipal da Educação – SMED
4.3.15. Secretaria Municipal da Saúde – SMS
4.3.16. Secretaria Municipal de Promoção Social, Combate a Pobreza, Esportes e Lazer – SEMPRE
4.3.17. Secretaria Municipal de Reparação – SEMUR
4.3.18. Secretaria Municipal de Políticas para Mulheres, Infância e Juventude – SPMJ
4.3.19. Secretaria Municipal de Infraestrutura e Obras Públicas – SEINFRA
4.3.20. Secretaria Municipal de Manutenção da Cidade – SEMAN
4.3.21. Secretaria Municipal de Ordem Pública – SEMOP
4.3.22. Secretaria Municipal de Mobilidade – SEMOB
4.3.23. Defesa Civil de Salvador – CODESAL
4.3.24. Fundação Cidade Mãe – FCM
4.3.25. Fundação Xxxxxxxx xx Xxxxx – FGM
4.3.26. Fundação Xxxxx Xxxx Xxxxxxxx – FMLF
4.3.27. Guarda Civil Municipal - GCM
4.3.28. Superintendência de Trânsito de Salvador – TRANSALVADOR
4.3.29. Agência Reguladora e Fiscalizadora dos Serviços Públicos de Salvador – ARSAL
5. DA ADESÃO À ATA DE REGISTRO DE PREÇOS
5.1. Fica facultado ao Município do Salvador, permitir a utilização da Ata de Registro, durante a sua vigência, pelos órgãos e entidades da Administração Pública que não tenham participado do certame licitatório, desde que devidamente justificada a vantagem e com anuência do órgão gerenciador. (Decreto Municipal nº 24.900/2014, alterado pelo Decreto Municipal nº 25.692/2014).
5.2. As aquisições ou contratações adicionais não poderão exceder, por órgão ou entidade, a cem por cento dos quantitativos dos itens do instrumento convocatório e registrados na ata de registro de preços para a SEMIT e órgãos participantes.
5.3. O quantitativo decorrente das adesões à ata de registro de preços não poderá exceder, na totalidade, ao quíntuplo do quantitativo de cada item registrado na ata de registro de preços para a SEMIT e órgãos participantes, independentemente do número de órgãos não participantes que aderirem.
5.4. O órgão gerenciador somente poderá autorizar adesão à ata após a primeira aquisição ou contratação por órgão integrante da ata, exceto quando, justificadamente, não houver previsão no edital para aquisição ou contratação pelo órgão gerenciador.
5.5. Após a autorização do órgão gerenciador, o órgão não participante deverá efetivar a aquisição ou contratação solicitada em até noventa dias, observado o prazo de vigência da ata.
5.6. Compete ao órgão não participante os atos relativos à cobrança do cumprimento pelo fornecedor das obrigações contratualmente assumidas e a aplicação, observada a ampla defesa e o contraditório, de eventuais penalidades decorrentes do descumprimento de cláusulas contratuais, em relação às suas próprias contratações, informando as ocorrências ao órgão gerenciador.
5.7. O órgão gerenciador será a Secretaria Municipal de Inovação e Tecnologia – SEMIT.
6. DOTAÇÃO ORÇAMENTÁRIA
6.1. As despesas decorrentes da execução da presente licitação correrão à conta dos recursos consignados ao orçamento dos órgãos indicados no subitem 4.3 do Edital, do presente exercício, devidamente ajustadas nas dotações do exercício subsequente.
7. CONDIÇÕES DE PARTICIPAÇÃO
7.1. Poderão participar do processo os interessados estabelecidos no país, que atendam a todas as exigências contidas neste edital e seus anexos, e que pertençam ao ramo de atividade pertinente ao objeto licitado.
7.2. As microempresas e empresas de pequeno porte poderão se beneficiar do tratamento diferenciado e favorecido em licitações previsto na Lei Complementar nº 123/06, desde que não se enquadrem em qualquer das exclusões relacionadas no parágrafo quarto do seu artigo terceiro.
7.3. As empresas enquadradas nesta situação deverão apresentar a declaração de ME ou EPP – Anexo VI deste Edital.
7.4. Em relação à cota reservada, somente poderão participar da licitação microempresas e empresas de pequeno porte, nos termos do artigo 48, inciso III, da Lei Complementar n. 123/2006.
7.5. Estarão impedidos de participar de qualquer fase do processo os interessados que se enquadrem em uma ou mais das situações a seguir:
7.5.1. Declarados inidôneos por ato da Administração Pública;
7.5.2. Reunidos sob forma de consórcio;
7.5.3. Estejam cumprindo penalidade de suspensão temporária imposta pela Administração Pública Municipal, ou, ainda, penalidade imposta por qualquer órgão da Administração Pública, nas hipóteses previstas no art. 88 da Lei nº 8.666/93;
7.5.4. Enquadrados nas hipóteses previstas nos incisos I, II e III do artigo 9° da lei n° 8.666/93.
8. CREDENCIAMENTO NO APLICATIVO LICITACOES-E
8.1. As pessoas jurídicas ou firmas individuais deverão credenciar representantes, mediante a apresentação de procuração por instrumento público ou particular, com firma reconhecida, atribuindo poderes para formular lances de preços e praticar todos os demais atos e operações no sistema licitações-e do Banco do Brasil S/A.
8.2. Em sendo sócio, proprietário, dirigente ou assemelhado da empresa proponente, deverá apresentar cópia do respectivo Estatuto ou Contrato Social, no qual estejam expressos seus poderes para exercer direitos e assumir obrigações em decorrência de tal investidura.
8.3. Para acesso ao sistema eletrônico, os interessados em participar do Pregão Eletrônico deverão dispor de chave de identificação, senha pessoal e intransferível, obtidas junto às agências do Banco do Brasil S/A sediadas no País.
8.4. A chave de identificação e a senha terão validade de 01 (um) ano e poderão ser utilizadas em qualquer Pregão Eletrônico, salvo quando canceladas por solicitação do credenciado ou por iniciativa do Banco do Brasil S/A, devidamente justificado.
8.5. É de exclusiva responsabilidade do usuário o sigilo da senha, bem como seu uso em qualquer transação efetuada diretamente ou por seu representante, não cabendo ao Banco do Brasil S/A a responsabilidade por eventuais danos decorrentes de uso indevido da senha, ainda que por terceiros.
8.6. O credenciamento do fornecedor e de seu representante legal junto ao sistema eletrônico implica em responsabilidade legal pelos atos praticados e a presunção de capacidade técnica para realização das transações.
8.7. Em se tratando de microempresas ou empresa de pequeno porte, nos termos da Lei Complementar nº 123/2006 e para que essa possa gozar dos benefícios previstos no capítulo V da referida Lei, é necessário, à época do credenciamento acrescentar a expressão “Empresa de Pequeno Porte” ou sua abreviação “EPP”, à sua firma ou denominação, conforme o caso.
8.7.1. Caso o licitante já esteja cadastrado no Sistema e não constem os dados acima em sua firma ou denominação, deverá providenciar a alteração de seu cadastro no Sistema junto a qualquer agência do Banco do Brasil S/A.
8.8. Informações complementares sobre credenciamento no sistema poderão ser obtidas pelos telefones: 00000000 ou 0000-00000000 (Suporte Técnico).
9. ESCLARECIMENTOS E IMPUGNAÇÃO AO ATO CONVOCATÓRIO
9.1. Até cinco dias úteis antes da data fixada para abertura da sessão pública, qualquer cidadão poderá solicitar da Comissão Permanente de Licitação esclarecimentos, providências ou impugnar o ato convocatório do pregão.
9.2. Até três dias úteis antes da data fixada para abertura da sessão pública, qualquer licitante poderá solicitar da Comissão Especial Mista de Licitação esclarecimentos, providências ou impugnar o ato convocatório do pregão através de petição datada e assinada pelo representante legal da empresa e vir acompanhada de contrato social e procuração se for o caso.
9.3. As solicitações de esclarecimentos e as petições de impugnação deverão ser encaminhados por meio eletrônico, via internet, para o endereço xxxxx.xxxxx@xxxxxxxx.xx.xxx.xx.
9.4. O pregoeiro responderá aos pedidos de esclarecimentos e impugnações no prazo de dois dias úteis, contado da data de recebimento do pedido, e poderá requisitar subsídios formais aos responsáveis pela elaboração do edital e dos anexos.
9.5. As respostas aos pedidos de esclarecimentos e impugnações serão respondidas diretamente no site xxx.xxxxxxxxxx-x.xxx.xx, no campo “mensagens”, no link correspondente a este Edital e vincularão os participantes e a administração.
9.6. A impugnação não possui efeito suspensivo.
9.7. A concessão de efeito suspensivo à impugnação é medida excepcional e deverá ser motivada pelo pregoeiro, nos autos do processo de licitação.
9.8. Acolhida a impugnação contra o edital, será definida e publicada nova data para realização do certame, as modificações do edital serão divulgadas pelo mesmo instrumento de publicação utilizado para divulgação do texto original e o prazo inicialmente estabelecido será reaberto, exceto se, inquestionavelmente, a alteração não afetar a formulação das propostas, resguardado o tratamento isonômico aos licitantes.
9.9. Decairá do direito de impugnar os termos deste edital perante a Administração a licitante que não o fizer até o terceiro dia útil que anteceder a data prevista para a abertura da Sessão Pública, apontando as falhas ou irregularidades que o viciou.
9.10. O pregoeiro poderá solicitar a manifestação dos setores técnicos, a fim de subsidiar a decisão quanto às impugnações, promovendo a oitiva, quando necessário, do órgão legal de assessoramento jurídico.
10. PARTICIPAÇÃO NA LICITAÇÃO
10.1. Caberá à interessada em participar do Pregão, na forma eletrônica, remeter, no prazo estabelecido, exclusivamente por meio eletrônico, via internet, a proposta e, quando for exigido neste edital, também os seus anexos.
10.2. Caberá à licitante acompanhar no sistema eletrônico do Banco do Brasil, todas as fases externas do pregão - da disponibilização até a sua adjudicação, ficando responsável pelo ônus decorrente da perda de negócios diante da inobservância de quaisquer mensagens e atos do Pregoeiro registrados no sistema eletrônico, bem como pela sua desconexão.
10.3. A licitante será responsável por todas as transações que forem efetuadas em seu nome no sistema eletrônico, assumindo como firmes e verdadeiras as propostas e lances.
10.4. No caso de haver desconexão do Pregoeiro com o sistema eletrônico no decorrer da etapa competitiva, o sistema poderá permanecer acessível aos licitantes para o recebimento dos lances, retornando o Pregoeiro, quando possível, à sua atuação no certame, sem prejuízo dos atos realizados.
10.4.1. Persistindo a desconexão por tempo superior a dez minutos, a sessão do Pregão será suspensa, reiniciando somente 24 (vinte quatro) horas após a comunicação expressa aos participantes no sítio do xxx.xxxxxxxxxx-x.xxx.xx.
11. DO ENVIO DE PROPOSTA ELETRÔNICA, DOS DOCUMENTOS DE HABILITAÇÃO E DA FORMULAÇÃO DE LANCES
11.1. A licitante deverá encaminhar proposta com a descrição do objeto ofertado e preço concomitantemente com os documentos de habilitação e outros documentos exigidos neste Edital, exclusivamente por meio do sistema eletrônico, conforme a data e horário marcados para abertura da sessão pública, quando então encerrar-se-á automaticamente a fase de recebimento de propostas e dos documentos de habilitação.
11.1.1. A proposta deverá ser encaminhada em formulário eletrônico específico, mediante a opção “Acesso identificado”, na página inicial do site xxx.xxxxxxxxxx-x.xxx.xx, observado as datas e horários limites estabelecidos no item 3 deste Edital.
11.1.2. A licitante deverá declarar, em campo próprio do sistema eletrônico, que cumpre plenamente os requisitos de habilitação e que sua proposta está em conformidade com as exigências do Edital.
11.1.3. A licitante deverá declarar, em campo próprio do sistema, sob pena de inabilitação, que não emprega menores de dezoito anos em trabalho noturno, perigoso ou insalubre, nem menores de dezesseis anos em qualquer trabalho, salvo na condição de aprendiz, a partir dos quatorze anos.
11.1.4. A licitante enquadrada como microempresa ou empresa de pequeno porte deverá declarar, em campo próprio do Sistema que atender aos requisitos do artigo 3º da LC 123/2006, para fazer jus aos benefícios previstos nessa lei.
11.1.4.1. As licitantes que quiserem usufruir os benefícios concedidos pela Lei Complementar nº 123/2006, ao apresentar sua proposta de preços, deverão registrar, expressamente, em campo próprio do sistema eletrônico sua condição de microempresa ou empresa de pequeno porte.
11.1.5. A declaração falsa relativa ao cumprimento dos requisitos de habilitação, à conformidade da proposta ou ao enquadramento como microempresa ou empresa de pequeno porte sujeitará a licitante às sanções previstas neste Edital.
11.2. As propostas ficarão disponíveis no sistema eletrônico.
11.2.1. A licitante deverá preencher o formulário eletrônico apresentado na tela com os dados pertinentes à sua proposta de preços, vedada a identificação da proponente ou do seu representante legal, sob pena de desclassificação.
11.2.2. Qualquer elemento que possa identificar o licitante através da sua proposta, antes da sessão pública, importará na sua desclassificação.
11.2.3. Até a abertura das propostas, a licitante poderá retirar ou substituir a proposta, os documentos de habilitação anteriormente encaminhados.
11.2.4. O Pregoeiro deverá suspender a sessão pública do pregão quando constatar que a avaliação da conformidade das propostas, de que trata o inciso III e VI do artigo 14 do Decreto Municipal nº32.562/2020, irá perdurar por mais um dia e indicará data e horário do reinício.
11.2.4.1. Se for a hipótese que trata o inciso III do artigo 14 do Decreto Municipal nº32.562/2020, após a suspensão da sessão pública, o Pregoeiro enviará, via chat, mensagens às licitantes informando a data e horário previstos para o início da oferta de lances.
11.3. Da abertura da Sessão Pública
11.3.1. A abertura da Sessão Pública deste Pregão, conduzida pelo Pregoeiro, ocorrerá na data e na hora indicadas no preâmbulo deste Edital, no sítio xxx.xxxxxxxxxx-x.xxx.xx.
11.3.2. O sistema eletrônico disponibilizará campo próprio para troca de mensagens entre o pregoeiro e as licitantes.
11.3.3. Durante a sessão pública, a comunicação entre o Pregoeiro aos licitantes ocorrerá exclusivamente mediante troca de mensagens, em campo próprio do sistema eletrônico.
11.3.4. Cabe à licitante acompanhar as operações no sistema eletrônico durante a sessão pública do Pregão, ficando responsável pelo ônus decorrente da perda de negócios diante da inobservância de qualquer mensagem emitida pelo sistema ou de sua desconexão.
11.3.5. A proposta e os lances formulados deverão indicar preços expressos em moeda nacional (R$), com no máximo duas casas decimais.
11.3.6. A licitante deverá contemplar em seu preço, todos os custos decorrentes da execução contratual, tais como, despesas com impostos, taxas, frete, seguros e quaisquer outros que incidam na contratação do objeto.
11.3.7. Deverão ser observados os preços unitários máximos definidos conforme Anexo IX deste Edital.
11.3.8. Iniciada a sessão pública do pregão eletrônico, não cabe desistência da proposta, salvo motivo justificado e aceito pelo pregoeiro.
11.3.9. Aberta a etapa competitiva, os licitantes poderão encaminhar lances sucessivos, exclusivamente por meio do sistema eletrônico, sendo informados imediatamente do horário e valor consignados no registro de cada lance.
11.3.10. O licitante somente poderá oferecer valor inferior ou maior percentual de desconto ao último lance por ele ofertado e registrado pelo sistema, observado, quando houver, o intervalo mínimo de diferença de valores ou de percentuais entre os lances, que incidirá tanto em relação aos lances intermediários quanto em relação ao lance que cobrir a melhor oferta.
11.3.11. Durante o transcurso da Sessão Pública, os participantes serão informados, em tempo real, do valor do menor lance registrado, vedada a identificação do autor do lance aos demais participantes.
11.3.12. Em caso de empate, prevalecerá o lance recebido e registrado primeiro.
11.3.13. Os lances apresentados e levados em consideração para efeito de julgamento serão de exclusiva e total responsabilidade da licitante, não lhe cabendo o direito de pleitear qualquer alteração.
11.3.14. Durante a fase de lances, o Pregoeiro poderá excluir, justificadamente, lance cujo valor seja manifestamente inexequível.
11.4. Neste pregão, o modo de disputa adotado é o aberto e fechado, assim definido no inciso II artigo 26 do Decreto Municipal nº 32.562/2020.
11.4.1. As licitantes apresentarão lances públicos e sucessivos, com lance final e fechado, conforme o critério de julgamento adotado neste edital;
11.4.2. A etapa de envio de lances da sessão pública terá duração de 15 (quinze) minutos. [art. 24, caput, do Decreto no 19.896/20];
11.4.3. Encerrado o prazo previsto no número 11.4.2, o sistema encaminhará o aviso de fechamento iminente dos lances e, transcorrido o período de até 10 (dez) minutos, aleatoriamente determinado, a recepção de lances será automaticamente encerrada;
11.4.4. Encerrado o prazo de que trata o número 11.4.3, o sistema abrirá a oportunidade para que o autor da oferta de valor mais baixo e os autores das ofertas com valores até 10% (dez por
cento) superior àquela, possam ofertar um lance final e fechado em até 05 (cinco) minutos, que será sigiloso até o encerramento deste prazo. [art. 24, §2o, do Decreto no 19.896/20]
11.4.5. Na ausência de, no mínimo, 03 (três) ofertas nas condições de que trata o número 11.4.4, os autores dos melhores lances subsequentes, na ordem de classificação, até o máximo de 03 (três), poderão oferecer um lance final e fechado em até 05 (cinco) minutos, que será sigiloso até o encerramento do prazo.
11.4.6. Encerrados os prazos estabelecidos, o sistema ordenará os lances em ordem crescente de vantajosidade. [art. 24, §4o, do Decreto no 19.896/20]
11.4.7. Na ausência de lance final e fechado classificado nos termos dos números 11.5.4 e 11.5.5, haverá o reinício da etapa fechada para que os demais licitantes, até o máximo de 03 (três), na ordem de classificação, possam ofertar um lance final e fechado em até 05 (cinco) minutos, que será sigiloso até o encerramento deste prazo, observado, após esta etapa, o disposto no § 4º deste artigo. [art. 24, §5o, do Decreto no 19.896/20]
11.4.8. Na hipótese de não haver licitante classificado na etapa de lance fechado que atenda às exigências para habilitação, o pregoeiro poderá, auxiliado pela equipe de apoio, mediante justificativa, admitir o reinício da etapa fechada, nos termos do disposto na letra “g”. [art. 24, §6o, do Decreto no 19.896/20]
11.4.9. O intervalo de diferença entre os lances deverá ser de, no mínimo, 0,5% (zero virgula cinco por cento) do valor estimado, em relação aos lances intermediários, quanto em relação do lance qual vai cobrir a melhor oferta.
11.5. Da Negociação da Proposta
11.5.1. Encerrada a etapa de envio de lances da sessão pública, o Licitante deverá continuar conectado ao sistema até as considerações finais do Pregoeiro.
11.5.2. O Arrematante deverá continuar vigilante ao chat, na oportunidade que o Pregoeiro encaminhará, pelo sistema eletrônico, contraproposta ao licitante que tenha apresentado o melhor preço, para que seja obtida a melhor proposta, vedada a negociação em condições diferentes das previstas no Edital.
11.5.3. O Arrematante deverá encaminhar no prazo de 4 (quatro) horas a resposta quanto a contraproposta do Pregoeiro, na mesma oportunidade que deverá anexar nova proposta de preços, com os respectivos valores readequados ao valor ofertado e registrado de menor lance nos mesmos termos do item 11.5.2.
11.5.4. Em caso de inconsistência do sistema, deverá incluir a informação quanto a falha técnica em mensagens ao pregoeiro e encaminhar a proposta ajustada através do e-mail xxxxx.xxxxx@xxxxxxxx.xx.xxx.xx.
11.5.5. Na impossibilidade de encaminhar a proposta ajustada por justa motivação no tempo legal, poderá o licitante, solicitar dilação de prazo que ficará a critério do pregoeiro o deferimento do pedido e novo prazo.
11.5.5.1. A negociação será realizada por meio do sistema, podendo ser acompanhada pelas demais licitantes.
11.6. A partir do horário previsto no sistema, terá início a sessão pública do Pregão Eletrônico, com a divulgação das propostas de preço recebidas e em perfeita consonância com as especificações e condições de fornecimento previstas no Edital.
11.7. O Pregoeiro verificará as propostas apresentadas, desclassificando aquelas que não estejam em conformidade com os requisitos estabelecidos no Edital.
11.8. A desclassificação de proposta será sempre fundamentada e registrada no sistema, com acompanhamento em tempo real por todos os licitantes.
11.9. O sistema não aceitará lances do mesmo valor, prevalecendo aquele que for recebido e registrado em primeiro lugar. Entretanto, o licitante poderá encaminhar lance com valor superior ao menor lance registrado, desde que seja inferior ao seu último lance ofertado e diferente de qualquer lance válido para o lote.
11.10. O Sistema registrará o licitante detentor da melhor proposta, imediatamente após o encerramento da etapa de lances.
11.11. Quando for constatado o empate, conforme estabelece os artigos 44 e 45 da Lei Complementar 123/06, o pregoeiro aplicará os critérios para desempate em favor da ME ou EPP. Após o desempate, poderá o pregoeiro ainda negociar um melhor preço caso ela não atinja o valor de referência definido pela administração pública.
11.12. Caso não sejam apresentados lances, será verificada a conformidade entre a proposta de menor preço e o valor estimado para a contratação.
12. PROPOSTA COMERCIAL
12.1. A proposta deverá ser apresentada na forma do Xxxxx XXX deste Edital, redigida em papel timbrado da licitante, por meio mecânico ou informatizado, de forma clara e inequívoca, sem emendas, rasuras ou entrelinhas, em estrita observância às especificações contidas neste Edital, assinada na última folha e rubricada nas demais pelo seu titular ou representante legal, devidamente identificado, nela constando, obrigatoriamente:
12.1.1. Razão Social, CNPJ, endereço, CEP, telefone/fax e pessoa de contato;
12.1.2. Preços de acordo com os praticados no mercado, em algarismo e por extenso, só reajustáveis na forma da lei, para entrega CIF Salvador, com valores expressos em moeda corrente nacional (R$), atualizados conforme lances eventualmente ofertados. Ocorrendo divergência entre o preço em algarismo e o expresso por extenso, será levado em conta este último;
12.1.3. Prazo de validade de proposta 60 (sessenta) dias, a contar da data de sua apresentação, sendo facultado aos proponentes estender tal validade por prazo superior;
12.2. A proposta apresentada e os lances formulados deverão incluir todas e quaisquer despesas necessárias para fornecimento do objeto desta licitação, tais como: tributos, emolumentos, contribuições sociais, fiscais, parafiscais, fretes, seguros e demais despesas inerentes, devendo o preço ofertado corresponder rigorosamente às especificações do objeto licitado, não cabendo quaisquer reivindicações devidas a erros nessa avaliação, para efeito de solicitar revisão de preços por recolhimentos determinados pela autoridade competente.
12.3. Os preços constantes da proposta escrita deverão referir-se ao do lance formulado no Pregão, considerando-se a condição de pagamento à vista, não devendo por isso, considerar qualquer custo financeiro para o período de processamento das faturas.
12.4. Para a correta elaboração da proposta de preços, deverá a licitante examinar todos os documentos exigidos no Edital e atender a todas as condições nele contidas e nos seus anexos.
13. HABILITAÇÃO
13.1. Os documentos necessários à habilitação deverão estar com prazo vigente, à exceção daqueles que, por sua natureza, não contenham validade, e poderão ser apresentados em original, por qualquer processo de cópia autenticada por tabelião de notas ou por servidor da unidade que realizará o Pregão, à vista dos originais, ou publicação em órgãos da imprensa oficial, não sendo aceitos “protocolos” ou “solicitação de documento” em substituição aos documentos requeridos neste Edital.
13.2. Havendo alguma restrição na comprovação da regularidade fiscal exigida no subitem 13.4.2 deste instrumento, será assegurado à ME ou EPP o prazo de 05 (cinco) dias úteis, cujo termo inicial corresponderá ao momento em que for declarada vencedora do certame, prorrogáveis por igual período, a critério da Administração, para regularização da documentação.
13.3. A não regularização da documentação no prazo previsto implicará decadência do direito à contratação, sem prejuízo das sanções previstas neste Edital, sendo facultado à Administração convocar as licitantes remanescentes, na ordem de classificação, para a assinatura do contrato ou revogar a licitação.
13.4. Para habilitação nesta licitação será exigida a seguinte documentação:
13.4.1. Preferencialmente a documentação deverá ser anexada por grupos: Habilitação jurídica, Regularidade fiscal e trabalhista, Qualificação Técnica e Qualificação econômico-financeira e outros documentos.
13.4.2. Habilitação Jurídica
13.4.2.1. Registro Comercial, no caso de empresa individual.
13.4.2.2. Ato constitutivo (estatuto social, contrato social ou requerimento de empresário) em vigor, devidamente inscrito na Junta Comercial e todas as suas alterações. Em caso de Sociedades Comerciais por ações, deverá ser apresentado acompanhado de ata de eleição de seus administradores e, para Sociedade Civis, deve ser acompanhado de prova de diretoria em exercício.
13.4.2.3. Documentos dos Sócios e do Representante Legal.
13.4.2.4. Procuração do respectivo Representante Legal na licitação.
13.4.2.5. Decreto de autorização, em se tratando de empresa ou sociedade estrangeira em funcionamento no país, e ato de registro ou autorização para funcionamento expedido pelo órgão competente, quando a atividade assim o exigir.
13.4.2.6. Certificado de Registro Cadastral – CRC, emitido pelo Município de Salvador.
13.4.2.6.1. O Certificado de Registro Cadastral, expedido pelo Município de Salvador, estando no prazo de validade, poderá substituir os documentos relativos à Habilitação Jurídica, à Regularidade Fiscal, à Qualificação Econômico-Financeira, exceto os concernentes à Declaração de Proteção ao Trabalho do Menor, Qualificação Técnica e a Certidão Negativa de Débitos Trabalhistas (CNDT). Caso o certificado consigne algum documento vencido, o licitante deverá apresentar a versão atualizada do referido documento no envelope de habilitação.
13.4.3. Regularidade Fiscal e Trabalhista
13.4.3.1. Prova de inscrição no Cadastro de Pessoas Físicas (CPF) ou no Cadastro Nacional da Pessoa Jurídica (CNPJ).
13.4.3.2. Prova de inscrição no cadastro de contribuintes estadual ou municipal, se houver, relativo ao domicílio ou sede do licitante, pertinente ao seu ramo de atividade e compatível com o objeto contratual;
13.4.3.3. Prova de regularidade para com a Fazenda Federal, Estadual e Municipal do domicílio ou sede do licitante, ou outra equivalente, na forma da lei.
13.4.3.4. Certidão Conjunta Negativa de Débitos, relativa a tributos federais e à Dívida Ativa da União, abrangendo as contribuições sociais, conforme Portaria Conjunta RFB/PGFN de nº 1.751/2014.
13.4.3.5. Prova de regularidade relativa à Seguridade Social e ao Fundo de Garantia por Tempo de Serviço (FGTS), demonstrando situação regular no cumprimento dos encargos sociais instituídos por lei.
13.4.3.6. Prova de inexistência de débitos inadimplidos perante a Justiça do Trabalho, mediante a apresentação de Certidão Negativa de Débitos Trabalhistas. (Lei nº 12.440/2011).
13.4.3.7. Certidão negativa de débitos do INSS.
13.4.3.8. Certidão Negativa no CADIN/Salvador conforme determina artigo 34 da Lei Municipal n˚ 8.421/2013 e no art. 3˚ do Decreto municipal n˚ 24.419/2013.
13.4.4. Qualificação técnica
13.4.4.1. A PROPONENTE deverá apresentar o atestado de capacidade técnica emitido por empresa pública ou privada comprovando que forneceu soluções e serviços incluindo instalação e configuração e todo suporte devida durante a vigência contratual, com características semelhantes às especificadas no Termo de Referência. Para tanto, exige-se um ou mais atestados cujo a somatório seja no mínimo 30% do quantitativo total estimado.
13.4.4.1.1. Justifica-se este percentual em razão da necessidade de comprovação da capacidade técnico operacional da licitante, diante da complexidade técnica do objeto, quantitativos e suas especificações, onde a potencial LICITANTE deverá comprovar sua aptidão para o desempenho de atividade pertinente e compatível em características, quantidades e prazos, no percentual de, pelo menos, 30% (trinta por cento) referente aos quantitativos constantes do quadro geral dos equipamentos e serviços.
13.4.4.1.2. Os atestados deverão ser impressos em papel timbrado, com nome e telefone de contato dos responsáveis pela informação atestada, não sendo aceitas declarações genéricas de catálogos, manuais de Internet, devendo ainda atestar a satisfação com o serviço ofertado pela PROPONENTE.
13.4.4.1.3. A CONTRATANTE se reserva o direito de conferir as informações prestadas pelas empresas emitentes dos atestados, através de consultas e visitas, bem como a disponibilidade de equipamentos solicitados junto à PROPONENTE.
13.4.4.2. A PROPONENTE deverá apresentar a Declaração de Visita Técnica. Na hipótese de a PROPONENTE não desejar realizar a visita técnica informada, a mesma deverá apresentar declaração de pleno conhecimento de que não serão consideradas alegações posteriores de desconhecimento do objeto, condições e características da contratação, bem como sua gestão e execução.
13.4.4.3. A PROPONENTE Xxxx apresentar os seguintes documentos:
13.4.4.3.1. Indicação de site na WEB para transferência de arquivos de configuração (manuais e atualizações de firmware);
13.4.4.3.2. Declaração de que irá dispor, para cumprimento do contrato, de estrutura técnica adequada (instalações, aparelhamento e corpo técnico) para cumprimento do objeto desta licitação, além de local para execução dos serviços técnicos na cidade de Salvador e ou Grande Salvador – BA.
13.4.4.3.3. Prospecto com as características técnicas de todos os componentes dos equipamentos, incluindo especificação de marca, modelo e outros elementos que, de forma inequívoca, identifiquem e comprovem as configurações cotadas, possíveis expansões e upgrades, através de certificados, manuais técnicos, folders e demais literaturas técnicas editadas pelos fabricantes. Serão aceitas cópias das especificações obtidas em websites dos fabricantes na Internet, em que conste o respectivo endereço eletrônico.
13.4.4.3.4. Indicação exata do modelo de equipamento ofertado na Proposta de Preços, comprovando todos os recursos e funcionalidades mínimas exigidas para os equipamentos que irão integrar as características técnicas solicitadas no Anexo A do Termo de Referência.
13.4.5. Qualificação Econômico-Financeira
13.4.5.1. Certidão Negativa de Falência ou Recuperação Judicial expedida pelo distribuidor da sede do licitante, com data de expedição ou revalidação dos últimos 90 (noventa) dias anteriores à data da realização da licitação, caso o documento não consigne prazo de validade.
13.4.5.2. Balanço Patrimonial e Demonstrações Contábeis do último exercício social, já exigíveis e apresentados na forma da lei, devidamente lançados no Livro Diário registrado na Junta Comercial do domicílio ou sede da Empresa, que comprovem a situação financeira desta, vedada a sua substituição por balancetes ou balanços provisórios, podendo ser atualizado por índices oficiais, quando encerrados há mais de 03 (três) meses da data da apresentação da proposta, vedada a sua substituição por balancetes ou balanços provisórios.
13.4.5.2.1. O Balanço Patrimonial deverá estar acompanhado de cópia do termo de abertura e de encerramento extraídos do livro Diário, devidamente registrado na Junta Comercial.
13.4.5.2.2. Para Sociedades Anônimas e outras Companhias obrigadas à publicação de Balanço, na forma da Lei 6.404/76 c/c a Lei nº 11.638/2007, cópias da publicação de:
a) balanço patrimonial;
b) demonstração do resultado do exercício;
c) demonstração das mutações do Patrimônio Líquido;
d) notas explicativas do balanço.
13.4.5.3. A licitante deverá comprovar que possui Patrimônio Líquido não inferior a 10% (dez por cento) do valor total indicado na proposta apresentada para o lote pertinente, admitida a atualização para a data da apresentação da proposta através de índices oficiais. Caso seja de interesse da licitante concorrer a 2 ou mais lotes, o patrimônio a ser comprovado não poderá ser inferior à soma dos valores exigidos para cada lote.
13.4.5.4. A empresa licitante que ainda não tenha completado seu primeiro ano de exercício fiscal, terá sua capacidade econômico-financeira comprovada por meio da apresentação do Balanço de Abertura, devidamente registrado na Junta Comercial.
13.4.5.5. As certidões extraídas pela internet somente terão validade se confirmadas a autenticidade.
13.4.5.6. Se a licitante for matriz, todos os documentos deverão estar em nome da matriz, e se a licitante for filial, todos os documentos deverão estar em nome da filial, exceto aqueles documentos que, pela própria natureza, comprovadamente, forem emitidos somente em nome da matriz.
14. OUTROS DOCUMENTOS
14.1. Os documentos a seguir mencionados deverão ser apresentados pela licitante juntamente com os demais documentos exigidos neste instrumento. As licitantes também deverão remeter nesta oportunidade, exclusivamente via sistema eletrônico:
14.1.1. Proposta Comercial (Anexo III);
14.1.2. Declaração de Elaboração Independente de Proposta (Anexo IV);
14.1.3. Declaração de Proteção ao Trabalho do Menor (Anexo V);
14.1.4. Termo de declaração de enquadramento de Microempresa ou Empresa de Pequeno Porte; (Anexo VI)
14.1.5. Declaração de Inexistência de fato superveniente à participação no certame (Xxxxx XXX)
14.1.6. Dados do representante legal (nome, RG, CPF) com poderes específicos para assinar o Contrato. (Anexo VIII)
15. CRITÉRIOS DE JULGAMENTO
15.1. O Critério de Julgamento será o de Menor Preço do Lote.
15.2. A classificação das propostas será por ordem crescente, a partir da mais vantajosa, sagrando-se vencedora a licitante que apresentar a proposta em conformidade com este edital e ofertar o menor preço global, para o lote, observado o prazo para fornecimento, as especificações técnicas e demais condições definidas neste Edital.
15.3. Para fins deste certame, considerar-se-á como preço global o valor correspondente ao somatório dos itens que compõem o lote.
15.4. Se a proposta ou o lance de menor valor não for aceitável ou se a licitante desatender às exigências habilitatórias, o Pregoeiro examinará a proposta ou o lance subsequente, verificando a sua compatibilidade, na ordem de classificação, e assim sucessivamente, até a apuração de uma proposta ou lance que atenda ao Edital. O Pregoeiro poderá negociar com o licitante para que seja obtido preço melhor.
15.5. Serão desclassificadas as propostas que:
15.5.1. Não atenderem as condições e exigências deste Edital;
15.5.2. Consignarem preços inexequíveis ou superfaturados, assim considerados aqueles incoerentes com os praticados pelo mercado, para a execução do objeto do contrato;
15.5.3. Incompletas ou divergentes do quanto especificado neste Edital e seus anexos;
15.5.4. Não contemplem todos os itens pertencentes ao lote. A desclassificação da proponente ocorrerá apenas no lote prejudicado.
15.6. Será assegurado, como critério de desempate, preferência de contratação para as microempresas e empresas de pequeno porte, conforme previsto no art. 44 da Lei Complementar 123/2006.
15.6.1. Ocorrerá o empate ficto quando as propostas apresentadas pelas microempresas ou empresas de pequeno porte sejam iguais ou até 5% (cinco por cento) superiores à proposta de menor preço.
15.7. Para efeito do disposto no item 15.5 deste edital, ocorrendo o empate, proceder-se-á da seguinte forma:
15.7.1. A microempresa ou empresa de pequeno porte melhor classificada poderá, no prazo máximo de 5 (cinco) minutos após o encerramento dos lances, sob pena de preclusão do direito, apresentar proposta de preço inferior à primeira classificada, situação em que passará à condição de primeira classificada do certame;
15.7.2. Não ocorrendo interesse da microempresa ou empresa de pequeno porte na forma do item 15.7.1, serão convocadas as remanescentes que porventura se enquadrem na hipótese do item 15.5 deste edital, na ordem classificatória.
15.8. Na hipótese da não contratação nos termos previstos no item 15.6 deste edital, voltará à condição de primeira classificada a empresa autora da proposta de menor preço originariamente apresentada.
15.9. As licitantes que deixarem de apresentar quaisquer dos documentos exigidos na presente licitação ou os apresentarem em desacordo com o estabelecido neste edital, serão desclassificadas e/ou inabilitadas, cabendo ao Pregoeiro examinar a oferta e aceitabilidade da proposta subsequente, na ordem de classificação, e assim sucessivamente, até a apuração de uma proposta que atenda as exigências editalícias.
15.10. É vedada a utilização de sistema robotizado que implique envio automático de lances.
16. RECURSOS ADMINISTRATIVOS
16.1. Declarada à vencedora, qualquer licitante poderá manifestar em até 30 minutos a intenção de recorrer da decisão do Pregoeiro, oportunidade em que deverá expressar a síntese imediata de suas razões, sendo-lhe concedido o prazo de 3 (três) dias úteis para a apresentação das razões do recurso.
16.1.1. O licitante desclassificado antes da fase de disputa também poderá manifestar a sua intenção de interpor recurso naquele momento.
16.2. Manifestada a intenção de recorrer, será concedido o prazo de 03 (três) dias úteis para a apresentação das razões do recurso, ficando os demais licitantes desde logo intimados para apresentarem contra - razões, se quiserem, em igual prazo, cuja contagem terá início no primeiro dia útil subsequente ao do término do prazo do recorrente, momento em que lhes será assegurado vista aos autos para conhecer do recurso apresentado ou, querendo, obter cópia do recurso e demais documentos que entender necessário.
16.2.1. O não oferecimento de razões no prazo previsto no item 16.1 fará deserto o recurso.
16.3. A falta de manifestação imediata, acompanhada da síntese das respectivas razões, ensejará a preclusão do direito de recorrer.
16.4. Não será concedido prazo para recurso sobre assuntos meramente protelatórios ou quando não justificada a intenção de interpor o recurso pelo proponente.
16.5. Os recursos contra decisões do Pregoeiro, em regra, terão efeitos suspensivos, sendo este restrito ao lote objeto das razões oferecidas.
16.6. O exame, a instrução e o encaminhamento dos recursos à autoridade superior do órgão ou entidade promotora da licitação, serão realizados pelo pregoeiro no prazo de até 03 (três) dias úteis.
16.7. As razões e contrarrazões de recurso deverão ser anexadas ao sistema do Banco do Brasil e concomitantemente enviadas para o e-mail xxxxx.xxxxx@xxxxxxxx.xx.xxx.xx.
16.8. O acolhimento de recurso importará a invalidação apenas dos atos insuscetíveis de aproveitamento.
17. ADJUDICAÇÃO E HOMOLOGAÇÃO
17.1. Não havendo manifestação de recurso, o pregoeiro adjudicará o objeto da licitação à proponente vencedora, para posterior homologação do resultado pela Autoridade Superior.
17.2. Decididos os recursos eventualmente interpostos e constatada a regularidade dos atos procedimentais, a autoridade superior adjudicará o objeto licitado ao licitante vencedor homologando em seguida, o procedimento licitatório.
17.3. A homologação e a adjudicação do objeto desta licitação não implicarão direito à contratação.
18. VALIDADE DO REGISTRO DE PREÇOS
18.1. O Registro de Preços terá validade de 01 (um) ano, a contar da data de assinatura do Termo de Compromisso de Fornecimento podendo, a critério da Administração Pública Municipal, ser celebrados tantos contratos quantos necessários, para atendimento aos Órgãos e Entidades municipais.
19. TERMO DE COMPROMISSO DE FORNECIMENTO E ATA DE REGISTRO DE PREÇOS
19.1. Após a homologação do resultado da licitação e adjudicação do objeto pela autoridade competente, será efetuado o registro dos preços mediante Termo de Compromisso de Fornecimento e Ata de Registro de Preços, a serem firmados entre a licitante vencedora e a SEMIT.
19.2. A Ata de Registro de Preços destina-se a subsidiar o acompanhamento dos preços.
19.3. A licitante vencedora será convocada para, no prazo de 05 (cinco) dias úteis, contados da data da convocação, assinar o Termo de Compromisso de Fornecimento e a Ata de Registro de Preços.
19.4. É facultado à Administração, havendo recusa do licitante vencedor em atender a convocação no prazo mencionado no item anterior ou estando em situação irregular, na forma do art. 12, § 2º da Lei Municipal nº 6.148/2002, convocar os licitantes remanescentes, para, após feita a negociação, assinar o Termo de Compromisso de Fornecimento ou revogar a licitação. Contudo, antes de tal convocação, deverão ser examinados os seus documentos habilitatórios, que deverão atender as exigências editalícias.
19.5. São de responsabilidade exclusiva do promitente fornecedor as informações relativas a endereço, telefone e fax, bem como a modificação dos mesmos no período de vigência do Termo de Compromisso de Fornecimento, dando-se por intimada em caso de eventual tentativa frustrada de comunicação.
19.6. A existência de preços registrados não obriga a Administração Municipal a firmar as contratações que deles poderão advir, ficando-lhe facultada a realização de licitações para aquisição de um ou mais itens, hipótese em que, em igualdade de condições, o beneficiário do registro terá preferência, nos termos do § 4º do art. 5 da Lei nº 8.666/93.
19.7. Toda vez que for constatado, através de pesquisa de preços, que os valores registrados no Termo de Compromisso de Fornecimento encontram-se divergentes dos praticados no mercado, a Administração Municipal poderá:
19.7.1. Cancelar os itens com preços registrados cujos valores estejam acima dos preços praticados e o fornecedor não aceite adequá-los ao mercado.
19.7.2. Promover ajustes dos preços registrados na hipótese de restabelecimento do equilíbrio econômico-financeiro do contrato, nos casos previstos no art. 65, inciso II, alínea “d” da Lei nº 8.666/93, mediante comprovação oficial, fundamentada e aceita pela Administração Municipal.
20. INSTRUMENTO CONTRATUAL
20.1. A contratação com o fornecedor registrado, de acordo com a necessidade do órgão, será formalizada por intermédio de instrumento contratual, emissão de nota de empenho de despesa, autorização de compra ou instrumento similar, conforme disposto no artigo 62 da Lei nº 8.666, de 1993.
20.2. O fornecedor registrado poderá ser convocado para assinatura do contrato no prazo de 5 (cinco) dias úteis, a contar do recebimento da convocação. Este prazo poderá ser
prorrogado uma vez, por igual período, quando solicitado pelo proponente vencedor durante o seu transcurso e desde que ocorra motivo justificado, aceito pelo órgão contratante.
20.3. O não atendimento do prazo previsto no subitem anterior ou a recusa em assinar o contrato pelo fornecedor registrado implicará na aplicação das sanções previstas neste Edital.
20.4. É vedada a subcontratação total ou parcial do objeto do contrato sem a prévia anuência da Administração.
20.5. Durante a vigência do contrato, a fiscalização será exercida por um representante da Contratante, ao qual competirá registrar em relatório todas as ocorrências e as deficiências verificadas e dirimir as dúvidas que surgirem no curso da execução contratual, de tudo dando ciência à Administração.
20.6. O contrato poderá ser alterado nos casos previstos no art. 65 da Lei 8.666/93, desde que haja interesse da Administração, com a apresentação das devidas justificativas.
20.7. A contratada deverá efetuar a inscrição da empresa perante o FISCO do Município de Salvador/BA, cuja comprovação deverá ser feita até 30 (trinta) dias úteis após a assinatura do contrato, conforme dispõem os artigos 228 e 323 da Lei Municipal nº 7.186/2006, que trata do Código Tributário e de Rendas do Município de Salvador.
20.8. O fornecedor deverá apresentar Certidão Negativa no CADIN/Salvador conforme determina artigo 34 da Lei Municipal n˚ 8.421/2013 e no art. 3˚ do Decreto municipal n˚ 24.419/2013;
20.9. O prazo da contratação será de 36 (trinta e seis) meses, podendo ser prorrogado, a critério da contratante e concordância da contratada, se atendidos os interesses da Administração Municipal, até o limite máximo previsto no inciso II do art. 57 da Lei 8.666/93.
20.10. No prazo de 10 (dez) dias úteis após a assinatura do contrato, a licitante contratada deverá prestar garantia de 5% (cinco por cento) do valor do contrato, podendo optar por uma das modalidades previstas no art. 56, parágrafo 1º, incisos I, II e III da Lei 8.666/93.
20.11. A contratada obriga-se a aceitar, quando solicitado pela Administração, nas mesmas condições e dentro do prazo contratual estabelecido, os acréscimos ou supressões de até 25% (vinte e cinco por cento) nos serviços licitados e as supressões resultantes de acordos celebrados entre as partes, de acordo com o inciso II, art. 65 da Lei 8.666/93.
20.12. Em caso de rescisão contratual com primeiro colocado, poderá a critério da Administração convocar o segundo colocado para que este, caso aceite os mesmos preços e mesmas condições do primeiro chamado possa assinar contrato com a Administração.
20.13. O contrato poderá ser alterado nos casos previstos no art. 65 da Lei 8.666/93, desde que haja interesse da Administração, com a apresentação das devidas justificativas.
20.14. Os contratos decorrentes da Ata de Registro de Preços poderão ser alterados, desde que justificados, observado o que dispõe o art. 65 da Lei nº 8666/1993.
20.14.1. O percentual a ser utilizado de acréscimo deve recair sobre o contrato desde que esteja vigente, independentemente de a ARP ter expirado o seu prazo de validade, haja vista que a vigência dos contratos celebrados em decorrência da utilização da ARP é desvinculada desta.
21. PROCEDIMENTO DE DISPONIBILIDADE DO OBJETO, FORMA E PRAZO DE ENTREGA
21.1. A CONTRATADA Deve realizar a entrega, instalação e todas as configurações dos equipamentos em até 90 (noventa) dias, contados da data de assinatura do Contrato, iniciando neste momento a prestação dos serviços objetos desta contratação.
22. PAGAMENTO
22.1. O pagamento será realizado pela contratante, através de crédito em conta corrente, obrigatoriamente mantida junto ao Banco Bradesco, consoante determinação do Decreto Municipal n.º 23.856/2013 (arts. 1º a 4º), com observância das exceções ali previstas (art. 5º, parágrafo único), a qual deverá ser indicada na declaração fornecida pelo estabelecimento bancário, na forma do disposto no art. 4º, § 2º do Decreto Municipal 13.991/2002, no prazo de até 20 (vinte) dias úteis, contados da apresentação da Nota Fiscal/Fatura, em conformidade com a legislação vigente, mediante a apresentação dos documentos fiscais exigíveis e declaração de não existência de débitos registrados no CADIN Municipal, conforme Decreto Municipal nº 24.419/2013.
22.2. Nenhum pagamento será efetuado à contratada enquanto pendente de liquidação qualquer obrigação financeira que lhe for imposta, em virtude de penalidade ou inadimplência, sem que isso gere direito a reajustamento de preço ou correção monetária.
22.3. O pagamento da(s) fatura(s) referente ao fornecimento da solução contratada será realizado em parcela única, em até 20 dias, e está condicionado ao “atesto” da nota fiscal pelo responsável.
22.4. O pagamento dos serviços será feito por medição, ou seja, por serviço efetivamente realizado;
22.4.1. Os pagamentos serão mensais inclusas todas as despesas com tributos, emolumentos, contribuições sociais, fiscais, parafiscais e quaisquer outras que forem devidas.
22.5. A CONTRATANTE reserva-se o direito de não efetivar o pagamento se, no ato do “atesto”, o serviço não estiver condizente com especificação requerida, até que seja promovida sua regularização;
22.6. Deverão constar, obrigatoriamente no corpo da Nota Fiscal, as seguintes informações:
22.6.1. Descrição dos serviços/produtos, preço total e data de emissão;
22.6.2. Valor total, com as deduções de impostos devidos;
22.6.3. Número do contrato;
22.6.4. Período dos serviços prestados.
22.7. Os pagamentos ficam condicionados à apresentação da Nota Fiscal ou Fatura emitida, acompanhada das Certidões que comprovem sua regularidade fiscal perante a Fazenda Federal, Estadual, Municipal, Certificado de Regularidade do FGTS – CRF, bem como certidão trabalhista;
22.8. No valor da contratação deverá estar incluso todos os encargos sociais, fiscais, trabalhistas, tributários, estipulados na legislação fiscal e trabalhista, materiais de consumo, equipamentos necessários, despesas com passagens e diárias e outras que se façam necessárias para a realização do objeto contratado.
23. REVISÃO DOS PREÇOS REGISTRADOS
23.1. A revisão dos preços registrados não poderá ultrapassar o preço praticado no mercado, devendo ser mantida a diferença percentual apurada entre o preço originalmente oferecido pelo promitente fornecedor e o preço de mercado vigente à época da licitação.
23.2. O preço registrado poderá ser revisto a qualquer tempo, em decorrência de eventual redução daqueles praticados no mercado, cabendo à Secretaria Municipal de Inovação e Tecnologia convocar os promitentes fornecedores para negociar o novo preço.
23.3. O promitente fornecedor poderá solicitar revisão dos preços registrados, somente para que seja mantido o equilíbrio econômico-financeiro do contrato.
23.3.1. O pedido de revisão, por escrito, deverá ser protocolado na Gerência Central de Material e Patrimônio.
23.4. A cada pedido de revisão de preço deverá o promitente fornecedor comprovar e justificar as alterações havidas na planilha apresentada à época da elaboração da proposta, demonstrando a nova composição do preço.
23.5. No caso do promitente fornecedor ser revendedor ou representante comercial deverá demonstrar de maneira clara a composição do preço constante de sua proposta, com descrição das parcelas relativas ao valor da aquisição do produto com Notas Fiscais de Fábrica/Indústria, encargos em geral, lucro e participação percentual de cada item em relação ao preço final.
23.6. A Administração Pública Municipal poderá exigir do promitente fornecedor as listas de preços expedidas pelos fabricantes, contendo, obrigatoriamente, a data de início de sua vigência e numeração sequencial, para instrução de pedidos de revisão de preços.
23.7. Na análise do pedido de revisão, dentre outros critérios, a Administração Municipal adotará, para verificação dos preços constantes dos demonstrativos que acompanhem o pedido, pesquisa de mercado dentre empresas de reconhecido porte mercantil, produtoras e/ou comercializadoras, a ser realizada pela própria unidade ou por instituto de pesquisa, utilizando-se, também, de índices setoriais ou outros adotados pelo Governo Federal, devendo a deliberação ou deferimento ou indeferimento da alteração solicitada ser instruída com justificativa da escolha do critério e memória dos respectivos cálculos, para decisão da Administração no prazo de 15 (quinze) dias.
23.8. O percentual diferencial entre os preços de mercado vigente à época do julgamento da licitação, devidamente apurado, e os propostos pelo promitente fornecedor será mantido durante toda a vigência do registro. O percentual não poderá ser alterado de forma a configurar reajuste econômico durante a vigência deste registro.
23.9. A Representação da Procuradoria Geral do Município/SEMIT, deverá, obrigatoriamente, emitir parecer sobre a revisão de preços dos itens registrados.
23.10. A revisão do preço, caso deferida, somente terá validade a partir da data da publicação da deliberação no Diário Oficial do Município.
23.11. É vedado ao promitente fornecedor interromper o fornecimento enquanto aguarda o trâmite do processo de revisão de preços, estando, neste caso, sujeita às sanções previstas neste edital.
23.12. Quando a Secretaria Municipal de Inovação e Tecnologia, através de pesquisa trimestral ou impugnação de terceiros, verificar que o valor registrado está acima dos preços praticados no mercado, convocará o promitente fornecedor, através de correspondência oficial, para adequar os preços registrados àqueles oficialmente reconhecidos pelo Município do Salvador, no prazo máximo de 05 (cinco) dias úteis, a partir da notificação do documento.
23.13. Na hipótese de o promitente fornecedor não efetuar a adequação dos preços de mercado, o Município do Salvador, a seu critério poderá resilir, parcial ou totalmente, o Termo de Compromisso de Fornecimento.
23.14. A revisão levará em consideração preponderantemente as normas legais federais, estaduais e municipais, que são soberanas às previstas neste Edital.
24. CANCELAMENTO DO REGISTRO DE PREÇOS
24.1. O Registro de Preços poderá ser cancelado pela Secretaria Municipal de Inovação e Tecnologia quando:
24.1.1. O fornecedor descumprir as exigências do edital que deu origem ao Registro de Preços.
24.1.2. O fornecedor se recusar a assinar o contrato decorrente do Registro de Preços ou não retirar o instrumento equivalente no prazo estabelecido, sem justificativa aceita pela Administração Municipal.
24.1.3. Em qualquer das hipóteses de inexecução total ou parcial do contrato, decorrente do Termo de Compromisso de Fornecimento firmado.
24.1.4. Os preços registrados apresentarem variações superiores aos praticados no mercado e o fornecedor se recusar a adequá-los na forma prevista neste Edital.
24.1.5. Em razões de interesse público, devidamente justificado.
24.2. A comunicação do cancelamento do preço registrado, nos casos previstos no item 24.1 será feita por correspondência, com aviso de recebimento, juntando-se o comprovante aos autos que deram origem ao Registro de Preços.
24.2.1. No caso de ser inacessível ou ignorado o endereço do promitente fornecedor, a comunicação será feita mediante publicação no Diário Oficial do Município, ou ainda pela internet, na página eletrônica, como forma adicional de divulgação, por uma vez, e afixado no quadro de aviso de amplo acesso, considerando-se cancelado o registro na data da publicação oficial.
24.3. O Registro de Preços poderá ser cancelado pelo promitente fornecedor, quando, mediante solicitação por escrito, comprovar estar impossibilitado de cumprir as exigências do edital e seus anexos que deram origem ao Registro de Preços.
24.3.1. A solicitação de que trata o item acima deverá ser formulada com antecedência mínima de 30 (trinta) dias, sendo assegurada defesa prévia e facultada à Administração Municipal a aplicação das sanções previstas no edital e na legislação vigente.
25. PENALIDADES ADMINISTRATIVAS
25.1. O fornecedor sujeitar-se-á, no caso de cometimento de infrações ou inadimplemento de suas obrigações, às penalidades previstas na Lei Municipal nº 6.148/02, Decreto Municipal nº 15.984/05, aplicando-se subsidiariamente, no que couberem, as disposições contidas na Lei nº 8.666/93 na sua atual redação e Lei Municipal nº 4.484/92, sem prejuízo das demais cominações legais.
26. DISPOSIÇÕES FINAIS
26.1. Ao participar desta licitação, a licitante declara sob as penalidades da Lei, da inexistência de qualquer vínculo de natureza técnica, comercial, econômica, financeira ou trabalhista, entre si e os responsáveis pela licitação, quer direta ou indiretamente.
26.2. A apresentação de proposta a esta licitação implica na aceitação integral e irretratável dos termos deste edital e seus anexos.
26.3. O valor máximo estimado da presente licitação é de R$ 39.260.698,16 (trinta e nove milhões, duzentos e sessenta mil, seiscentos e noventa e oito reais e dezesseis centavos), resultante de pesquisa de mercado efetuada pela Administração, que será considerado valor máximo admissível para a contratação.
26.4. Com base na pesquisa supracitada a licitante deverá observar os preços unitários máximos dos itens que compõem o lote, conforme indicados a seguir:
ITEM | DESCRITIVO | UNID | QTD | VALOR UNITARIO |
01 | Solução De Segurança Cibernética Distribuída NGFW – Tipo I | UN | 04 | R$ 387.190,05 |
02 | Solução De Segurança Cibernética Distribuída NGFW – Tipo II | UN | 04 | R$ 231.801,79 |
03 | Solução De Segurança Cibernética Distribuída NGFW – Tipo III | UN | 50 | R$ 47.142,33 |
04 | Solução De Segurança Cibernética Distribuída NGFW – Tipo IV | UN | 50 | R$ 16.723,41 |
05 | Ativo de Rede Wireless – TIPO I | UN | 700 | R$ 7.765,99 |
06 | Ativo de Rede Wireless – TIPO II | UN | 150 | R$ 18.474,95 |
07 | Ativo de Rede Wired – TIPO I | UN | 200 | R$ 7.558,20 |
08 | Ativo de Rede Wired – TIPO II | UN | 100 | R$ 12.004,20 |
09 | Ativo de Rede Wired – TIPO III | UN | 10 | R$ 29.665,00 |
10 | Ativo de Rede Wired – TIPO IV | UN | 06 | R$ 176.288,97 |
11 | Ativo de Rede Wired – TIPO V | UN | 06 | R$ 185.640,00 |
12 | Ativo de Rede Wired POE – TIPO I | UN | 100 | R$ 13.713,44 |
13 | Ativo de Rede Wired POE – TIPO II | UN | 50 | R$ 20.540,52 |
14 | Solução de Segurança de Aplicações Web - WAF | UN | 02 | R$ 629.646,36 |
15 | Solução de Segurança de Endpoint - EDR | UN | 02 | R$ 478.226,67 |
16 | Upgrade Solução de Segurança de Endpoint - EDR | UN | 20 | R$ 27.000,00 |
17 | Solução de Segurança de Endpoint - EPP Tipo I | UN | 08 | R$ 175.593,60 |
18 | Solução de Segurança de Endpoint - EPP Tipo II | UN | 100 | R$ 11.079,12 |
19 | Solução para duplo Fator de Autenticação - Token Mobile TIPO I | UN | 100 | R$ 1.851,20 |
20 | Solução para duplo Fator de Autenticação - Token Mobile TIPO II | UN | 08 | R$ 26.006,93 |
21 | Solução de Segurança Decoy/Honeypot | UN | 02 | R$ 161.221,67 |
22 | Solução de Segurança Sandbox | UN | 02 | R$ 232.154,00 |
23 | Solução de Detecção e Resposta de Rede (NDR) | UN | 01 | R$ 1.452.750,00 |
24 | Solução de Proteção de Risco Digital (DRPS) | UN | 02 | R$ 1.196.000,00 |
25 | Solução Controladora de Entrega de Aplicações em Cluster (ADC) | UN | 02 | R$ 994.832,07 |
26 | Modulo Transciver – TIPO I | UN | 30 | R$ 637,87 |
27 | Modulo Transciver – TIPO II | UN | 30 | R$ 1.305,63 |
28 | Modulo Transciver – TIPO III | UN | 100 | R$ 1.040,52 |
29 | Modulo Transciver – TIPO IV | UN | 30 | R$ 1.927,06 |
30 | Modulo Transciver – TIPO V | UN | 20 | R$ 6.799,00 |
31 | Modulo Transciver – TIPO VI | UN | 10 | R$ 22.777,12 |
32 | Modulo Transciver – TIPO VII | UN | 20 | R$ 12.707,50 |
33 | Modulo Transciver – TIPO VII | UN | 10 | R$ 43.453,67 |
34 | Serviços Profissionais – Unidade de Serviços Técnicos | UN | 5000 | R$ 850,00 |
26.5. A presente licitação não importa necessariamente em contratação, podendo a SEMIT revogá-la, no todo ou em parte, por razões de interesse público derivadas de fato superveniente, comprovado ou anulá-lo por ilegalidade, de ofício ou por provocação mediante ato escrito e fundamentado disponibilizado no sistema para conhecimento dos participantes da licitação.
26.6. Atestamos, para os devidos fins licitatórios, que as especificações técnicas contidas no Edital não restringem a competitividade, conforme os pressupostos legais.
26.7. É facultado ao Pregoeiro ou à autoridade a ele superior, em qualquer fase da licitação, promover diligências com vistas a esclarecer ou a complementar a instrução do processo, vedada a inclusão posterior de informação ou de documentos que deveriam constar originariamente da proposta ou da documentação.
26.7.1. Os proponentes intimados para prestar quaisquer esclarecimentos adicionais deverão fazê- lo no prazo determinado pelo Pregoeiro, sob pena de desclassificação/inabilitação.
26.8. É facultado ao Pregoeiro analisar as propostas apresentadas em conjunto com prepostos do órgão solicitante ou de outros órgãos do Município com capacidade técnica para tal, devendo estes emitir parecer próprio sobre o objeto ofertado pelas licitantes.
26.9. As normas que disciplinam este Pregão serão sempre interpretadas em favor da ampliação da disputa entre os proponentes, desde que não comprometam o interesse da Administração, a finalidade e a segurança da contratação.
26.10. As decisões referentes a este processo licitatório poderão ser comunicadas aos proponentes por qualquer meio de comunicação que comprove o recebimento ou, ainda, mediante publicação no Diário Oficial do Município.
26.11. São de responsabilidade exclusiva da licitante as informações relativas a endereço, telefone e e-mail, bem como a modificação dos mesmos no curso da licitação, dando-se por intimada em caso de eventual tentativa frustrada de comunicação.
26.12. A falsidade de qualquer documento apresentado ou a inverdade das informações nele contidas implicará a imediata desclassificação do proponente que o tiver apresentado, ou, caso tenha sido o vencedor, a rescisão do contrato ou do pedido de compra, sem prejuízo das demais sanções cabíveis.
26.13. Na contagem dos prazos estabelecidos neste edital, exclui-se o dia do início e inclui-se o do vencimento, observando-se que só se iniciam e vencem prazos em dia de expediente normal na SEMIT, exceto quando for explicitamente disposto em contrário.
26.14. No caso de alteração deste edital no curso do prazo estabelecido para a realização do pregão, este prazo será reaberto, exceto quando, inquestionavelmente, a alteração não afetar a formulação das propostas.
26.15. O expediente da Secretaria Municipal de Inovação e Tecnologia é das 08:00h às 17:00h a modo de contagem de dia útil.
26.16. Os casos omissos no presente Edital serão resolvidos pela Comissão Permanente de Licitação com base na legislação vigente.
26.17. Declaramos que não existem, neste Edital e seus anexos, especificações que, por excessivas, irrelevantes ou desnecessárias, limitem ou frustrem a competição ou realização do fornecimento (art. 7º, inciso I, Lei Municipal nº 6.148/02; art. 3º, inciso II, Lei Federal nº 10.520/02; art. 3º, § 1º, inciso I, Lei Federal nº 8.666/93).
26.18. Fica designado o foro da Cidade do Salvador, Capital do Estado da Bahia – Brasil, para julgamento de quaisquer questões judiciais resultante deste Edital, renunciando as partes a qualquer outro por mais privilegiado que seja.
27. Anexos do Edital
Anexo I - Termo de Referência; Anexo II – Minuta do contrato; Anexo III - Proposta Comercial;
Anexo IV - Declaração de elaboração independente de proposta; Anexo V - Declaração de Proteção ao Trabalho do Menor;
Anexo VI - Termo de declaração de Microempresa e Empresa de Pequeno Porte;
Anexo VII - Declaração de inexistência de fato superveniente à participação do certame; Xxxxx XXXX - Dados do representante legal (nome, RG, CPF) com poderes específicos para assinar o Contrato;
Anexo IX -Termo de Compromisso de Fornecimento; Anexo X – Ata de Registro de Preços
EDITAL DE PREGÃO ELETRÔNICO – SEMIT Nº 003/2024 LICITAÇÃO Nº 003/2024
ANEXO I TERMO DE REFERÊNCIA
1. OBJETO
1.1. Contratação, na modalidade Registro de Preços, de empresa especializada em Tecnologia da Informação e Comunicação – TIC, para fornecimento de equipamentos de Segurança da Informação, Conectividade de Redes Wired e Wireless e Cibersegurança, englobando o fornecimento do projeto executivo, hardware, software, subscrições, instalações, configurações, suporte técnico local, treinamento e demais insumos necessários para o pleno funcionamento das soluções, para atender a população soteropolitana e as necessidades dos diversos órgãos e entidades da Prefeitura Municipal do Salvador, conforme especificações constantes neste Termo de Referência.
2. JUSTIFICATIVA
2.1. A Tecnologia da Informação é um dos principais agentes de mudanças organizacionais. Sua utilização deve atentar-se para as questões estratégicas de apoio à integração operacional, organizacional e funcional. A correta utilização dos recursos da tecnologia contribui para um ambiente institucional moderno, integrando as ações de todos os setores, fazendo da informatização um fator crítico de sucesso institucional.
2.2. Com o avanço cada vez mais expressivo das técnicas de exploração de vulnerabilidade utilizada, entende-se a necessidade de ampliação das camadas de proteção de cyber segurança neste ambiente, visando a ampliação da maturidade das soluções de segurança que permitam evitar possíveis ataques, sobretudo em períodos de guerra cibernética.
2.3. A Secretaria Municipal de Inovação e Tecnologia – SEMIT tem entre as suas competências, viabilizar o acesso seguro, controlado e ágil às informações, através da infraestrutura de Tecnologia da Informação e Comunicação – TIC para todos os órgãos e entidades da Prefeitura Municipal do Salvador – PMS.
2.4. Com o dinamismo no surgimento de novas tecnologias e a crescente demanda, o projeto surgiu em 2015, como resposta às necessidades permanentes em manter-se alta disponibilidade, alto desempenho, segurança e controle para que todos os usuários, das redes dependentes direta ou indiretamente da Secretaria Municipal de Inovação e Tecnologia – SEMIT, possam exercer suas atividades de rotina, proporcionando melhor qualidade nas ações corporativas da PMS.
2.5. Ocorreram os Pregões Eletrônicos PE-SEMGE 090/2016, em 2016 e PE-SEMGE 220/2018, PE-SEMIT 004/2021, PE-SEMIT 008/2021, PE-SEMIT 004/2022 e PE-SEMIT 002/2023 que geraram Atas de Registro de Preço e Termo de Compromisso que atendeu e vem atendendo a diversos órgãos e entidades da Administração Direta e/ou Indireta do Município do Salvador.
2.6. A crescente demanda por infraestrutura de tecnologia, bem como a constante necessidade da Administração Municipal em possuir o acesso às informações e Internet, controlado, ágil e seguro, torna indispensável a continuidade dos processos PE-SEMGE 090/2016, em 2016 e PE-SEMGE 220/2018, PE-SEMIT 004/2021, PE-SEMIT 008/2021, PE-SEMIT 004/2022 e PE-SEMIT 002/2023.
2.7. Esta nova Ata de Registro de Preço visa a continuidade das adoções de providências necessárias para agilizar a tomada de decisões que independem de rigores formais, mas que exigem celeridade, otimizando as ações da máquina administrativa Municipal.
2.8. Pode-se elencar abaixo os pontos de destaque aos benefícios projetados:
2.8.1. Convergência tecnológica desejada e necessária à implementação de todos os eixos e estratégias da Administração Municipal.
2.8.2. Continuidade do projeto em andamento, derivado dos processos PE-SEMGE 090/2016, em 2016 e PE-SEMGE 220/2018, PE-SEMIT 004/2021, PE-SEMIT 008/2021, PE-SEMIT 004/2022 e PE-SEMIT 002/2023;
2.8.3. Alinhamento estratégico de planejamento, orientados pela Secretaria Municipal de Inovação e Tecnologia – SEMIT;
2.8.4. Maior qualidade da infraestrutura e dos serviços de TIC da PMS e da Secretaria Municipal de Inovação e Tecnologia – SEMIT;
2.8.5. Gerenciamento eficiente e proativo da infraestrutura e dos serviços de TIC da PMS e da Secretaria Municipal de Inovação e Tecnologia – SEMIT;
2.8.6. Monitoração contínua e efetiva da infraestrutura e dos serviços de TIC da PMS e da Secretaria Municipal de Inovação e Tecnologia – SEMIT;
2.8.7. Aumento do grau de satisfação dos usuários com os serviços de TIC da PMS;
2.8.8. Ampliar a visibilidade e o controle do uso da Infraestrutura e dispositivos aderente ao Plano Estratégico orientada à Governança e Políticas de Acesso;
2.8.9. Proteção dos dados do Município de Salvador;
2.8.10. Proteção dos dados dos munícipes que estão sob a guarda da Administração Municipal.
2.8.11. Aderência e atendimento à legislação vigente, Marco Civil da Internet e Lei Geral de Proteção de dados, LGPD.
3. ESCOPO DOS SERVIÇOS
3.1. Os serviços deverão prever todos os equipamentos, componentes e subcomponentes, objetivando garantir a total conectividade e interoperabilidade, que deverão resultar no perfeito funcionamento do conjunto, com níveis de desempenho adequados aos fins a que se destinam no contexto de melhorias nos Serviços de TIC da PMS.
3.2. Correrá por conta exclusiva da CONTRATADA a responsabilidade pelo deslocamento dos seus técnicos ao local da instalação e da manutenção dos equipamentos, seja para retirada e/ou entrega, incluindo todas as despesas de transporte, frete e seguro correspondentes.
3.3. Caso a LICITANTE necessite fornecer hardwares e/ou softwares adicionais não especificados nominalmente neste Termo de Referência, mas necessários para atender as funcionalidades exigidas, o custo desses deverão estar inseridos no preço total ofertado.
3.4. Todos os componentes e subcomponentes objetos deste Termo de Referência deverão ser novos, de primeiro uso, sem previsão de descontinuidade anunciada, não se admitindo peças já usadas, reparadas, entre outros, com tecnologia atualizada e avançada, em linha de produção atendendo às características técnicas presentes nos anexos deste Termo de Referência.
4. EXIGÊNCIAS TÉCNICAS E OPERACIONAIS
4.1. A LICITANTE Deve prever os seguintes Níveis de Serviços:
4.1.1. Plantão técnico de suporte de atendimento: 24 x 7 x 365;
4.1.2. Plantão técnico de suporte on-site: 24 x 7 x 365;
4.1.3. Atendimento técnico emergencial local para indisponibilidade dos serviços em até 02 (duas) horas;
4.1.4. Atendimento técnico emergencial local para indisponibilidade parcial ou degradação dos tempos de acesso e resposta dos serviços em até 04 (quatro) horas;
4.1.5. Atendimento técnico para análises, alterações de parâmetros, consulta e suporte geral em até 24 (vinte e quatro) horas.
4.2. A CONTRATADA Deve disponibilizar à CONTRATANTE o serviço de um gestor responsável pelo Contrato de Xxxxxxx. Este Deve ser o ponto focal de todas as necessidades de suporte da CONTRATANTE para casos de escalonamentos ou problemas de atendimento do Suporte Técnico.
4.3. A LICITANTE não poderá transferir a outrem os compromissos assumidos, no todo ou em parte dos serviços objeto desta contratação.
4.4. A LICITANTE Deve apresentar documentos de domínio público que comprovem todos os recursos e funcionalidades mínimas exigidas para os equipamentos que irão integrar as características técnicas solicitadas no Anexo A.
4.5. Todos os componentes e acessórios deverão ser entregues instalados e funcionando perfeitamente.
4.6. Sempre antes de qualquer serviço, a CONTRATADA Deve efetuar vistoria técnica no local para análise dos detalhes técnicos para execução dos serviços solicitados e, ocorrendo dúvidas, a Secretaria Municipal de Inovação e Tecnologia – SEMIT Deve ser acionada para os devidos esclarecimentos.
4.7. A vistoria técnica referida no item anterior Deve ser agendada previamente pela CONTRATADA, com, no mínimo, 24 (vinte e quatro) horas de antecedência junto ao responsável da unidade da PMS. A Secretaria Municipal de Inovação e Tecnologia – SEMIT Deve ser informada desse agendamento.
4.8. Ao final de cada intervenção, a CONTRATADA Deve entrar em contato com a Secretaria Municipal de Inovação e Tecnologia – SEMIT para que esta proceda com a homologação dos serviços realizados.
4.9. Os serviços de instalação e manutenção não deverão obstruir o andamento das rotinas de trabalho dos ambientes objetos de intervenção. Quando da intervenção nestes ambientes, será de responsabilidade da CONTRATADA, a recomposição total dos mesmos, deixando os locais totalmente limpos e arrumados, inclusive com relação a algum dano a eles causado quando da execução dos serviços.
4.10. Quando da execução dos serviços, os locais de trabalho deverão ser mantidos desobstruídos e bem-sinalizados, quando for o caso, de maneira a não comprometer a segurança daqueles que ali trafegam.
4.11. Após a execução dos serviços, as áreas deverão ser mantidas limpas, retirando-se toda e qualquer impureza e sobras de materiais.
4.12. Para facilitar os procedimentos da Secretaria Municipal de Inovação e Tecnologia – SEMIT, a CONTRATADA Deve apresentar planilhas específicas, para cada local que foi objeto de intervenção, constando relação detalhada dos produtos efetivamente instalados, dos desempenhos esperados e especificação dos procedimentos técnicos e, se couber, dos instrumentos usualmente adotados para se efetuar os testes.
4.13. A recusa da aceitação dos serviços Deve ser feita por escrito e conterá os elementos que motivaram a sua determinação. Assim, elencará os produtos ou serviços que estão em desacordo com as especificações e/ou os defeitos apresentados. Diante disso, a CONTRATADA se disporá a consertar, ajustar, substituir os produtos ou fazer os serviços apontados na correspondência da Secretaria Municipal de Inovação e Tecnologia – SEMIT e no término, reapresentará o resultado à SEMIT.
4.14. Fica estabelecido que não ocorrendo nenhum comunicado da Secretaria Municipal de Inovação e Tecnologia – SEMIT, conforme consta no item anterior, os serviços serão considerados automaticamente aceitos. Ressalva-se que fica reservado à SEMIT o direito de exigir, a qualquer tempo, durante a garantia do fornecimento do serviço contratado, a substituição de qualquer acessório, componente ou produto requerido e instalado, que não apresentar as características de desempenho e funcionalidade exigidas, ou venha a apresentar falhas intermitentes não sanadas pela CONTRATADA.
5. GARANTIA, SUPORTE E TESTES
5.1. A CONTRATADA deverá disponibilizar, para efeito de instalação da solução proposta, sua garantia e prestação dos serviços, incluindo manutenção corretiva, preventiva, atendimento on-site e treinamento de acordo com os demais itens deste Termo de Referência, uma equipe com perfil técnico adequado às atividades previstas, com técnicos treinados pelo fabricante para a operação e configuração de todos os componentes ofertados.
5.2. A garantia dos itens referidos deve atender as especificações:
5.2.1. Os materiais transcivers devem possuir garantia de 12 (doze) meses.
5.2.2. Para os demais itens, a garantia deverá ser de, no mínimo, 36 (trinta e seis) meses.
5.3. Os chamados de suporte deverão ser abertos diretamente na contratada, gerenciados pelo mesmo, através de número telefônico 0800 ou equivalente a ligação local e também por ambiente WEB, fornecendo, neste momento, o número, data e hora de abertura do chamado. Este será considerado o início para contagem dos prazos estabelecidos.
5.4. Durante todo o período de garantia contratado, o serviço de suporte deve ser suprido 24 (vinte e quatro) horas, 07 (sete)dias por semana.
5.5. A CONTRATADA deve disponibilizar acesso ao ambiente WEB do fabricante para download de arquivos e drivers.
5.6. Todo serviço de suporte deve ser realizado por profissional certificado pelo fabricante.
5.7. O serviço de suporte deve proporcionar a interação com a equipe técnica da Secretaria Municipal de Inovação e Tecnologia – SEMIT, fornecendo apoio na resolução de incidentes que envolvam os componentes da solução, garantindo seu pronto reestabelecimento.
5.8. Ao final da execução dos serviços pela CONTRATADA, deverão ser realizados todos os testes necessários para comprovar que as instalações estão em condição de funcionar corretamente e de acordo com as especificações e normas.
6. EQUIPAMENTOS INTEGRANTES
ITEM | COD. DO PRODUTO | DESCRITIVO | QUANTIDADE | |
01 | 100006152 | Solução De Segurança Cibernética Distribuída NGFW – Tipo I | UN | 04 |
02 | 100006153 | Solução De Segurança Cibernética Distribuída NGFW – Tipo II | UN | 04 |
03 | 100006154 | Solução De Segurança Cibernética Distribuída NGFW – Tipo III | UN | 50 |
04 | 100006155 | Solução De Segurança Cibernética Distribuída NGFW – Tipo IV | UN | 50 |
05 | 100006163 | Ativo de Rede Wireless – TIPO I | UN | 700 |
06 | 100006164 | Ativo de Rede Wireless – TIPO II | UN | 150 |
07 | 100006166 | Ativo de Rede Wired – TIPO I | UN | 200 |
08 | 100006167 | Ativo de Rede Wired – TIPO II | UN | 100 |
09 | 100006168 | Ativo de Rede Wired – TIPO III | UN | 10 |
10 | 100006169 | Ativo de Rede Wired – TIPO IV | UN | 06 |
11 | 100006170 | Ativo de Rede Wired – TIPO V | UN | 04 |
12 | 100006171 | Ativo de Rede Wired POE – TIPO I | UN | 100 |
13 | 100006172 | Ativo de Rede Wired POE – TIPO II | UN | 50 |
14 | 100000000 | Solução de Segurança de Aplicações Web - WAF | UN | 02 |
15 | 300005642 | Solução de Segurança de Endpoint - EDR | UN | 02 |
16 | 300005648 | Upgrade Solução de Segurança de Endpoint - EDR | UN | 20 |
17 | 300005643 | Solução de Segurança de Endpoint - EPP Tipo I | UN | 08 |
18 | 300005644 | Solução de Segurança de Endpoint - EPP Tipo II | UN | 100 |
19 | 300005645 | Solução para duplo Fator de Autenticação - Token Mobile TIPO I | UN | 100 |
00 | 000000000 | Solução para duplo Fator de Autenticação - Token Mobile TIPO II | UN | 08 |
00 | 000000000 | Solução de Segurança Decoy/Honeypot | UN | 02 |
22 | 300000000 | Solução de Segurança Sandbox | UN | 02 |
23 | 300000000 | Solução de Detecção e Resposta de Rede (NDR) | UN | 01 |
24 | 300000000 | Solução de Proteção de Risco Digital (DRPS) | UN | 02 |
25 | 100006156 | Solução Controladora de Entrega de Aplicações em Cluster (ADC) | UN | 02 |
26 | 100006175 | Modulo Transciver – TIPO I | UN | 30 |
27 | 100006176 | Modulo Transciver – TIPO II | UN | 30 |
28 | 100006177 | Modulo Transciver – TIPO III | UN | 100 |
29 | 100006178 | Modulo Transciver – TIPO IV | UN | 30 |
30 | 100006179 | Modulo Transciver – TIPO V | UN | 20 |
31 | 100000000 | Modulo Transciver – TIPO VI | UN | 10 |
32 | 100000000 | Modulo Transciver – TIPO VII | UN | 20 |
33 | 100000000 | Modulo Transciver – TIPO VII | UN | 10 |
34 | 300005649 | Serviços Profissionais – Unidade de Serviços Técnicos | UN | 5000 |
7. OBRIGAÇÕES DA CONTRATADA
7.1. Assegurar a correta integração e funcionalidade dos serviços, em função do projeto e das especificações técnicas constantes neste Termo de Referência.
7.2. Apresentar a relação do pessoal que permanecerá nas dependências da unidade da PMS onde serão executados os serviços.
7.3. Efetuar inspeção/vistoria do local onde ocorrerá a prestação do serviço, conforme indicação da SEMIT, para verificar os detalhes técnicos de execução, antes de elaborar o projeto.
7.4. Apresentar, ao final do serviço, o relatório de conclusão do projeto, contendo os seguintes documentos:
7.4.1. Memorial descritivo de todo o serviço e produtos utilizados;
7.4.2. Relação de garantias dos equipamentos e serviços.
7.5. Não transferir a outrem, no todo ou em parte, o objeto do presente Termo de Referência, sem prévia e expressa anuência da SEMIT.
7.6. Manter toda estrutura de pessoal e ferramental necessários para execução dos serviços, independentemente da demanda definida pela CONTRATANTE.
7.7. Responsabilizar-se por toda a logística (transporte e comunicação) necessária à execução dos serviços propostos, em todo o Município do Salvador, para atendimento imediato às solicitações da SEMIT, conforme a demanda.
7.8. Responsabilizar-se por todos os serviços como cortes, furos e arremates em forros, vidros, esquadrias, revestimentos e gesso, necessários em função da execução das instalações.
7.9. Arcar com todas as despesas provenientes da limpeza dos locais de instalações e adequações necessárias.
7.10. Manter preposto para representá-la durante a execução dos serviços ora tratados, desde que aceito pela SEMIT.
7.11. Empregar, na execução dos serviços, a equipe técnica, no mínimo, 04 (quatro) profissionais técnicos, sócio e/ou funcionário e/ou prestadores de serviços qualificados, que poderá ser alterada mediante solicitação de autorização à CONTRATANTE, devidamente treinados pelo fabricante para instalar, configurar e manter os itens da solução a ser ofertada, devendo estes treinamentos técnicos serem comprovados por certificados de qualificação técnica vigentes.
7.12. Responder por quaisquer danos que venha a causar à União, Estado, Município ou a terceiros, em função do objeto do contrato firmado, bem como por todos os danos e prejuízos decorrentes de paralisações na execução dos serviços, salvo na ocorrência de motivo de força maior, apurados na forma da legislação vigente, e desde que comunicados à CONTRATANTE no prazo de 48 (quarenta e oito) horas do fato, ou da ordem expressa e escrita da CONTRATANTE.
7.13. Arcar com todas as despesas, diretas ou indiretas, decorrente do cumprimento das obrigações assumidas sem qualquer ônus à CONTRATANTE.
7.14. Arcar integralmente com todas as despesas inerentes à execução dos serviços, tais como, combustíveis, manutenção, seguros, taxas, impostos, tributos e salários.
7.15. Manter, durante toda a execução do Contrato, as mesmas condições da habilitação e qualificação exigidas nesta Licitação.
7.16. Efetuar pontualmente o pagamento de todas as taxas e impostos que incidam ou venham a incidir
sobre as suas atividades e/ou sobre a execução do objeto do presente Contrato, bem como observar e respeitar as legislações Federal, Estadual e Municipal relativas ao objeto do Contrato.
7.17. Manter, sob sua exclusiva responsabilidade, toda a supervisão, direção e mão de obra para execução dos serviços.
7.18. Reparar, corrigir, remover, reconstruir ou substituir, total ou parcialmente, às suas expensas, os serviços objeto deste Contrato em que se verifiquem vícios, defeitos ou incorreções, resultantes de execução irregular, do emprego de materiais ou equipamentos inadequados, se for o caso, ou não correspondentes ao serviço.
7.19. Apresentar composição de preços detalhada durante a execução do Contrato, quando solicitado, para aprovação ou não da CONTRATANTE, caso seja verificada a necessidade de serviço eventual não previsto nas planilhas do Anexo B.
7.20. Acatar as normas e condições deste Termo de Referência e seus anexos, independente de transcrição.
7.21. Disponibilizar um profissional que acompanhará as ações junto à SEMIT para recebimento de Ordens de Serviço, informações, contato com os técnicos responsáveis pelos serviços, coordenação, administração e supervisão do seu pessoal, bem como de qualquer comunicação junto à CONTRATANTE.
7.22. Permitir e facilitar a atuação de auditores e inspetores de qualquer natureza, sempre que necessário.
7.23. Arcar com indenização pecuniária decorrente dos danos morais ou materiais causados por seus empregados em bens patrimoniais da CONTRATANTE, bem como por desaparecimento de quaisquer objetos e valores encontrados em suas dependências, de quem quer que seja, desde que comprovado dolo ou culpa, do empregado da CONTRATADA.
7.24. Afastar ou substituir dentro de 24 (vinte e quatro) horas, sem ônus para a CONTRATANTE, qualquer funcionário que, por solicitação justificada da Fiscalização, não tenha condição de continuar a participar da execução dos serviços.
7.25. Realizar regularmente os exames de saúde dos seus empregados, na forma da lei, assim como arcar com todas as despesas decorrentes de transporte, alimentação, inclusive seguro de vida contra os riscos de acidentes de trabalho e outras especificadas nos dissídios ou convenções coletivas.
7.26. A CONTRATADA deverá cumprir e obedecer à Política de Segurança da Informação da Prefeitura Municipal de Salvador.
7.27. Cada prestador de serviço Deve apresentar-se uniformizado, com fardamento padrão fornecido pela CONTRATADA, e portando crachá de identificação.
7.28. Manter, sob sua exclusiva responsabilidade, toda a supervisão, direção e recursos humanos para execução completa e eficiente dos serviços objeto deste Contrato.
7.29. Responder perante à CONTRATANTE pela conduta, frequência, pontualidade e assiduidade de seus empregados e efetuar as substituições daqueles que venham a se ausentar do serviço, por motivo justificado ou não, sem nenhum ônus para a CONTRATANTE, bem como comunicar à SEMIT, antecipadamente, todo e qualquer afastamento, substituição ou inclusão de qualquer um dos seus empregados vinculados à execução do presente Contrato.
7.30. Zelar pela boa e completa execução dos serviços e facilitar, por todos os meios ao seu alcance, a ampla ação fiscalizadora dos prepostos designados pela SEMIT, atendendo prontamente às observações e exigências que lhe forem solicitadas.
7.31. Não efetuar despesa, celebrar acordos, fazer declarações ou prestar informações em nome da SEMIT.
7.32. Comunicar imediatamente ocorrências de qualquer natureza que impeçam o bom andamento do serviço.
8. OBRIGAÇÕES DA CONTRATANTE
8.1. Proporcionar à CONTRATADA todas as facilidades para que possa desempenhar o objeto da Licitação de forma satisfatória.
8.2. Designar uma equipe técnica para fiscalizar e acompanhar a execução dos serviços prestados.
8.3. Elaborar a Ordem de Serviço (OS) com o detalhamento dos serviços a serem realizados.
8.4. Avaliar e aprovar a execução dos serviços e a qualidade dos materiais aplicados, solicitando por escrito à CONTRATADA a correção das não conformidades, sem que haja ônus para a CONTRATANTE.
8.5. Promover o acesso às unidades dos órgãos e entidades da PMS das equipes da CONTRATADA que executarão os serviços.
8.6. Prestar as informações e os esclarecimentos que venham a ser solicitados pelos responsáveis da CONTRATADA.
8.7. Dar ciência à CONTRATADA de quaisquer modificações que venham a ocorrer.
8.8. Atestar as notas fiscais/faturas, por servidor/comissão competente, emitidas pela CONTRATADA, recusando-as quando inexatas ou incorretas, efetuando todos os pagamentos nas condições pactuadas.
9. PAGAMENTO
9.1. O pagamento será realizado pela CONTRATANTE, através de crédito em conta corrente, obrigatoriamente mantida junto ao Banco Bradesco, consoante determinação do Decreto Municipal n.º 23.856/2013 (arts. 1º a 4º), com observância das exceções ali previstas (art. 5º, parágrafo único), a qual deverá ser indicada na declaração fornecida pelo estabelecimento bancário, na forma do disposto no art. 4º, § 2º do Decreto Municipal 13.991/2002, no prazo de até 20 (vinte) dias úteis, contados da apresentação da Nota Fiscal/Fatura, em conformidade com a legislação vigente, mediante a apresentação dos documentos fiscais exigíveis e declaração de não existência de débitos registrados no CADIN Municipal, conforme Decreto Municipal nº 24.419/2013.
9.2. Nenhum pagamento será efetuado à contratada enquanto pendente de liquidação qualquer obrigação financeira que lhe for imposta, em virtude de penalidade ou inadimplência, sem que isso gere direito a reajustamento de preço ou correção monetária.
9.3. O pagamento da(s) fatura(s) referente ao fornecimento da solução contratada será realizado em parcela única, em até 20 dias, e está condicionado ao “atesto” da nota fiscal pelo responsável.
9.4. O pagamento dos serviços será feito por medição, ou seja, por serviço efetivamente realizado;
9.4.1. Os pagamentos serão mensais inclusas todas as despesas com tributos, emolumentos, contribuições sociais, fiscais, parafiscais e quaisquer outras que forem devidas.
9.5. A CONTRATANTE reserva-se o direito de não efetivar o pagamento se, no ato do “atesto”, o serviço não estiver condizente com especificação requerida, até que seja promovida sua regularização;
9.6. Deverão constar, obrigatoriamente no corpo da Nota Fiscal, as seguintes informações:
9.6.1. Descrição dos serviços/produtos, preço total e data de emissão;
9.6.2. Valor total, com as deduções de impostos devidos;
9.6.3. Número do contrato;
9.6.4. Período dos serviços prestados.
9.7. Os pagamentos ficam condicionados à apresentação da Nota Fiscal ou Fatura emitida, acompanhada das Certidões que comprovem sua regularidade fiscal perante a Fazenda Federal, Estadual, Municipal, Certificado de Regularidade do FGTS – CRF, bem como certidão trabalhista;
9.8. No valor da contratação deverá estar incluso todos os encargos sociais, fiscais, trabalhistas, tributários, estipulados na legislação fiscal e trabalhista, materiais de consumo, equipamentos necessários, despesas com passagens e diárias e outras que se façam necessárias para a realização do objeto contratado.
10. FISCALIZAÇÃO
10.1. A SEMIT fica investida dos mais amplos poderes para fiscalizar toda a execução do objeto, impugnando quaisquer erros ou omissões que considere em desacordo com as obrigações da CONTRATADA.
11. VISTORIA TÉCNICA
11.1. Os componentes e subcomponentes objetos da proposta deverão possuir integração e compatibilidade com os Sistemas de Segurança, Sistemas de Gerência, Repositório de Logs, Sistema de Gerenciamento de Identidade e demais equipamentos utilizados pela SEMIT/COGEL e outras unidades da PMS.
11.2. Fica facultado à LICITANTE interessada, realizar visita técnica no DATACENTER da SEMIT/COGEL para tirar todas as dúvidas e tomar conhecimento pleno das condições ambientais e técnicas para a efetiva realização da entrega do solicitado. Não serão aceitas alegações posteriores de desconhecimento das condições necessárias e requerimentos de compatibilidade à execução dos serviços. Caso seja de interesse da LICITANTE, a visita técnica deverá ser agendada pelo telefone
(00) 0000-0000/0000-0000 na pessoa do Coordenador Administrativo da SEMIT, até́ 72 (setenta e
duas) horas antes da data do certame.
11.3. A comprovação da visitação será feita através da emissão, pela SEMIT, de Declaração de Visita Técnica.
12. HABILITAÇÃO TÉCNICA
12.1. A PROPONENTE deverá apresentar o atestado de capacidade técnica emitido por empresa pública ou privada comprovando que forneceu soluções e serviços incluindo instalação e configuração e todo suporte devida durante a vigência contratual, com características semelhantes às especificadas neste Termo de Referência. Para tanto, exige-se um ou mais atestados cujo a somatório seja no mínimo 30% do quantitativo total estimado.
12.1.1. Justifica-se este percentual em razão da necessidade de comprovação da capacidade técnico operacional da licitante, diante da complexidade técnica do objeto, quantitativos e suas especificações, onde a potencial LICITANTE deverá comprovar sua aptidão para o desempenho de atividade pertinente e compatível em características, quantidades e prazos, no percentual de, pelo menos, 30% (trinta por cento) referente aos quantitativos constantes do quadro geral dos equipamentos e serviços.
12.1.2. Os atestados deverão ser impressos em papel timbrado, com nome e telefone de contato dos responsáveis pela informação atestada, não sendo aceitas declarações genéricas de catálogos, manuais de Internet, devendo ainda atestar a satisfação com o serviço ofertado pela PROPONENTE.
12.1.3. A CONTRATANTE se reserva o direito de conferir as informações prestadas pelas empresas emitentes dos atestados, através de consultas e visitas, bem como a disponibilidade de equipamentos solicitados junto à PROPONENTE.
12.2. A PROPONENTE deverá apresentar a Declaração de Visita Técnica. Na hipótese de a PROPONENTE não desejar realizar a visita técnica informada, a mesma deverá apresentar declaração de pleno conhecimento de que não serão consideradas alegações posteriores de desconhecimento do objeto, condições e características da contratação, bem como sua gestão e execução.
12.3. A PROPONENTE Xxxx apresentar os seguintes documentos:
12.3.1. Indicação de site na WEB para transferência de arquivos de configuração (manuais e atualizações de firmware);
12.3.2. Declaração de que irá dispor, para cumprimento do contrato, de estrutura técnica adequada (instalações, aparelhamento e corpo técnico) para cumprimento do objeto desta licitação, além de local para execução dos serviços técnicos na cidade de Salvador e ou Grande Salvador – BA.
12.3.3. Prospecto com as características técnicas de todos os componentes dos equipamentos, incluindo especificação de marca, modelo e outros elementos que, de forma inequívoca, identifiquem e comprovem as configurações cotadas, possíveis expansões e upgrades, através de certificados, manuais técnicos, folders e demais literaturas técnicas editadas pelos fabricantes. Serão aceitas cópias das especificações obtidas em websites dos fabricantes na Internet, em que conste o respectivo endereço eletrônico;
12.3.4. Indicação exata do modelo de equipamento ofertado na Proposta de Preços, comprovando todos os recursos e funcionalidades mínimas exigidas para os equipamentos que irão integrar as características técnicas solicitadas no Anexo A.
13. SIGILO DE INFORMAÇÕES CADASTRAIS
13.1. Todas as informações relativas à CONTRATANTE e constantes do cadastro da CONTRATADA deverão ser tratadas como confidenciais e somente poderão ser fornecidas quando solicitadas:
13.1.1. Pela CONTRATANTE;
13.1.2. Em decorrência de determinação judicial.
13.2. Os conhecimentos, dados e informações de propriedade do Município, relativos a aspectos econômico-financeiros, tecnológicos e administrativos, tais como produtos, sistemas, técnicas, estratégias, métodos de operação e todos e quaisquer outros, repassados por força do objeto do presente Termo de Referência, constituem informação privilegiada e como tal, tem caráter de confidencialidade, só podendo ser utilizados, exclusivamente, no cumprimento e execução das condições estabelecidas neste Contrato, sendo expressamente vedado à CONTRATADA:
13.2.1. Utilizá-los para fins outros, não previstos neste Instrumento;
13.2.2. Repassá-los a terceiros e empregados não vinculados diretamente ao objeto proposto.
14. VIGÊNCIA DO CONTRATO
14.1. O prazo do contrato será de 36 (trinta e seis) meses, contados a partir da data da sua assinatura, podendo ser prorrogado, a critério da CONTRATANTE e da CONTRATADA, por iguais e sucessivos períodos, até o limite definido no inciso IV do art. 57 da Lei 8.666/93.
14.2. A decisão de estabelecer um contrato de 36 (trinta e seis) meses visa otimizar os recursos financeiros da Administração Pública, abrindo espaço para uma disputa entre os licitantes que resultem em menores custos devido à extensão da duração contratual. Esta escolha é fundamentada na importância crítica dos produtos a serem adquiridos, assegurando assim a consistência e a continuidade das estratégias de segurança da informação da PMS, além disso, proporciona uma cobertura de garantia estendida ao longo da maior parte do período operacional dos produtos, garantindo a integridade e desempenho ao longo do tempo.
15. PRAZO DE ENTREGA DOS SERVIÇOS E MATERIAIS
15.1. A CONTRATADA Deve realizar a entrega, instalação e todas as configurações dos equipamentos em até 90 (noventa) dias, contados da data de assinatura do Contrato, iniciando neste momento a prestação dos serviços objetos desta contratação.
16. AMPLA CONCORRÊNCIA
16.1. Todos os interessados em contratar com a Administração Pública deverão competir em igualdade de condições.
17. REUNIÃO DE ALINHAMENTO
17.1. Todo trabalho deverá ser previamente planejado pela CONTRATADA e sua equipe, para em seguida ser apresentado e aprovado pelo Gestor do Contrato. Todo esforço de planejamento, execução e
monitoramento deverá ser realizado sob a condução de um responsável técnico da CONTRATADA.
17.2. A reunião de alinhamento deverá ocorrer em até 05 (cinco) dias corridos após a assinatura do Contrato. Na oportunidade, a CONTRATADA deverá apresentar o PREPOSTO e o RESPONSÁVEL TÉCNICO de todo o projeto.
17.3. A omissão de algum produto ou serviço no projeto de trabalho não exclui a responsabilidade da CONTRATADA em fornecer o produto e prestar os serviços de acordo com o que estabelece este Termo de Referência.
18. CONDIÇÕES GERAIS
18.1. O atendimento para executar os serviços se dará mediante emissão da OS (Ordem de Serviço) datada e assinada pela SEMIT.
18.2. A SEMIT Deve ser convocada para emitir parecer de homologação de todo serviço executado.
18.3. Atestamos, para os devidos fins licitatórios, que as especificações técnicas contidas neste Termo de Referência não restringem a competitividade, conforme os pressupostos legais e normativas aplicáveis e com interesse e conveniência da Administração, afastando-se as características, cláusulas e condições que direcionem, comprometam, restrinjam ou frustrem o caráter competitivo da Licitação.
18.4. Afiança-se, ainda, que as especificações técnicas fornecidas são suficientes para elaboração das propostas pelos interessados em contratar com a Administração Municipal.
18.5. Declaramos que não existem, neste Termo de Referência e seus anexos, especificações que, por excessivas, irrelevantes ou desnecessárias, limitem ou frustrem a competição ou realização do fornecimento (art. 7º, inciso I, Lei Municipal nº 6.148/02; art. 3º, inciso II, Lei Federal nº 10.520/02; art. 3º, § 1º, inciso I, Lei Federal nº 8.666/93).
18.6. As especificações técnicas das soluções e serviços a serem prestados encontram-se detalhadas no Anexo A.
18.7. O vencedor da Licitação será a empresa que apresentar a proposta com o menor valor global, conforme a planilha constante do Anexo B.
18.8. As propostas de preço deverão ser suportadas de informações e documentações detalhadas.
18.9. Todas as informações relativas à CONTRATANTE e constantes do cadastro da CONTRATADA deverão ser tratadas como confidenciais e somente poderão ser fornecidas quando solicitadas.
18.10. Os conhecimentos, dados e informações de propriedade do Município do Salvador, relativos a aspectos econômico-financeiros, tecnológicos e administrativos, tais como produtos, sistemas, técnicas, estratégias, métodos e de operação e todos e quaisquer outros, repassados por força do objeto do presente Termo de Referência e seus Anexos, constituem informação privilegiada e como tal, tem caráter de confidencialidade, só podendo ser utilizados, exclusivamente, no cumprimento e execução das condições estabelecidas neste Documento, sendo expressamente vedado à CONTRATANTE.
ANEXO A DO TERMO DE REFERÊNCIA
ESPECIFICAÇÕES TÉCNICAS
1. ITEM 01 - SOLUÇÃO DE SEGURANÇA CIBERNÉTICA DISTRIBUÍDA NGFW – TIPO I
1.1. Solução baseada em appliance. Para maior segurança, não serão aceitos equipamentos de propósito genérico (PCs ou servidores) sobre os quais poderiam instalar-se e/ou executar um sistema operacional regular como Microsoft Windows, FreeBSD, SUN Solaris, Apple OS-X ou GNU/Linux.
1.2. A solução poderá ser composta por mais de um equipamento para atender as funcionalidades exigidas, desde que todos os itens sejam do mesmo fabricante garantindo total compatibilidade e integração, desde que ocupem até 4U, no máximo.
1.3. Deve possuir e estar licenciado durante a vigência contratual de 36 (trinta e seis meses), minimamente com as seguintes funcionalidades: Firewall, Traffic Shapping, QoS, recursos de SD- WAN, Filtro de Conteúdo Web, Antivírus, AntiSpam, Detecção e Prevenção de Intrusos (IPS), VPN IPSec e SSL, Controle de Aplicações, e contextos virtuais.
1.4. Deve possuir fonte de alimentação redundante hot swappable com chaveamento automático 110/220V. A fonte fornecida deve suportar sozinha a operação da unidade com todos os módulos de interface ativos.
1.5. Deve possuir firewall com capacidade mínima de processamento de 70 (setenta) Gbps.
1.6. Deve possuir IPS com capacidade mínima de processamento de 12 (doze) Gbps.
1.7. Proteção contra ameaças avançadas (Threat Protection) com capacidade mínima de processamento de 10 (dez) Gbps, contemplando as funções de Firewall, IPS, controle de aplicação e proteção contra Malware/Antivírus ativadas de maneira simultâneas.
1.8. Deve possuir Inspeção SSL Throughput com capacidade mínima de processamento de 8 (oito) Gbps.
1.9. Deve possuir VPN com capacidade de, pelo menos, 50 (cinquenta) Gbps de tráfego IPSec.
1.10. Deve suportar 7.000.000 (sete milhões) conexões simultâneas.
1.11. Deverão ser licenciados para suportar, pelo menos, 9000 (nove mil e quinhentos) usuários de VPN SSL.
1.12. Deve suportar, pelo menos, 500.000 (quinhentas mil) novas conexões por segundo.
1.13. Deve suportar, pelo menos, 1.500 (mil e quinhentos) túneis de VPN Site-Site.
1.14. Deve suportar, pelo menos, 40.000 (quarenta mil) túneis de VPN Client-Site.
1.15. Deve possuir, pelo menos, 04 (quatro) interfaces SFP28+ 25GE.
1.16. Deve possuir, pelo menos, 02 (dois) interfaces SFP+ 10GE.
1.17. Deve possuir, pelo menos, 06 (seis) interfaces SFP 1GE.
1.18. Deve possuir, pelo menos, 14 (quatorze) interfaces RJ 45.
1.19. Deve incluir licença para a funcionalidade de VPN SSL.
1.20. Todos os equipamentos que acompanharem a solução devem suportar o modo de alta disponibilidade e estar licenciados para operar desta forma.
1.21. Deve ser capaz de gerenciar, via funcionalidade de Controladora Switch, ao menos, 90(noventa) equipamentos.
1.22. Deve ser capaz de gerenciar, via funcionalidade de Controladora Wireless, ao menos, 500(quinhentos) equipamentos.
1.23. Deve ser fornecida Solução de Gerência Centralizada de Equipamentos, caso compatível poderá ser utilizada atual solução existente na SEMIT/PMS, Marca Fortinet, Modelo FMG-3000G.
1.24. Deve ser fornecida Solução Centralizada de Armazenamento de Logs e Relatórios, caso compatível poderá ser utilizada atual solução existente na SEMIT/PMS, Marca Fortinet, Modelo FAZ-3700G.
1.25. deve possuir licença para atualização de firmware e atualização automática de bases de dados de todas as funcionalidades de segurança durante a vigência contratual.
1.26. Deve ser fornecida toda documentação técnica em formato digital, através de acesso a URL oficial do fabricante, em português do Brasil ou em inglês.
2. ITEM 02 - SOLUÇÃO DE SEGURANÇA CIBERNÉTICA DISTRIBUÍDA NGFW – TIPO II
2.1. Solução baseada em appliance. Para maior segurança, não serão aceitos equipamentos de propósito genérico (PCs ou servidores) sobre os quais poderiam instalar-se e/ou executar um sistema operacional regular como Microsoft Windows, FreeBSD, SUN Solaris, Apple OS-X ou GNU/Linux.
2.2. A solução poderá ser composta por mais de um equipamento para atender as funcionalidades exigidas, desde que todos os itens sejam do mesmo fabricante garantindo total compatibilidade e integração, desde que ocupem até 4U, no máximo.
2.3. Deve possuir e estar licenciado durante a vigência contratual de 36 (trinta e seis meses), minimamente com as seguintes funcionalidades: Firewall, Traffic Shapping, QoS, recursos de SD- WAN, Filtro de Conteúdo Web, Antivírus, AntiSpam, Detecção e Prevenção de Intrusos (IPS), VPN IPSec e SSL, Controle de Aplicações e contextos virtuais.
2.4. Deve possuir fonte de alimentação redundante hot swappable com chaveamento automático 110/220V. A fonte fornecida deve suportar sozinha a operação da unidade com todos os módulos de interface ativos.
2.5. Deve possuir firewall com capacidade mínima de processamento de 50 (cinquenta) Gbps.
2.6. Deve possuir IPS com capacidade mínima de processamento de 10 (dez) Gbps.
2.7. Proteção contra ameaças avançadas (Threat Protection) com capacidade mínima de processamento de 8,5 (oito e meio) Gbps, contemplando as funções de Firewall, IPS, controle de aplicação e proteção contra Malware/Antivírus ativadas de maneira simultâneas.
2.8. Deve possuir Inspeção SSL Throughput com capacidade mínima de processamento de 7 (sete) Gbps.
2.9. Deve possuir VPN com capacidade de, pelo menos, 50 (cinquenta) Gbps de tráfego IPSec.
2.10. Deve suportar 7.000.000 (sete milhões) conexões simultâneas.
2.11. Deverão ser licenciados para suportar, pelo menos, 4500 (quatro mil e quinhentos) usuários de VPN SSL.
2.12. Deve suportar, pelo menos, 400.000 (quatrocentos mil) novas conexões por segundo.
2.13. Deve suportar, pelo menos, 1.500 (mil e quinhentos) túneis de VPN Site-Site.
2.14. Deve suportar, pelo menos, 40.000 (quarenta mil) túneis de VPN Client-Site.
2.15. Deve possuir, pelo menos, 06 (seis) interfaces SFP+ 10GE.
2.16. Deve possuir, pelo menos, 06 (seis) interfaces SFP 1GE.
2.17. Deve possuir, pelo menos, 14 (quatorze) interfaces RJ 45.
2.18. Deve incluir licença para a funcionalidade de VPN SSL.
2.19. Todos os equipamentos que acompanharem a solução devem suportar o modo de alta disponibilidade e estar licenciados para operar desta forma.
2.20. Deve ser capaz de gerenciar, via funcionalidade de Controladora Switch, ao menos, 70(setenta) equipamentos.
2.21. Deve ser capaz de gerenciar, via funcionalidade de Controladora Wireless, ao menos, 250(duzentos e cinquenta) equipamentos.
2.22. Deve ser fornecida Solução de Gerência Centralizada de Equipamentos, caso compatível poderá ser utilizada atual solução existente na SEMIT/PMS, Marca Fortinet, Modelo FMG-3000G.
2.23. Deve ser fornecida Solução Centralizada de Armazenamento de Logs e Relatórios, caso compatível poderá ser utilizada atual solução existente na SEMIT/PMS, Marca Fortinet, Modelo FAZ-3700G.
2.24. deve possuir licença para atualização de firmware e atualização automática de bases de dados de todas as funcionalidades de segurança durante a vigência contratual.
2.25. Deve ser fornecida toda documentação técnica em formato digital, através de acesso a URL oficial do fabricante, em português do Brasil ou em inglês.
3. ITEM 03 - SOLUÇÃO DE SEGURANÇA CIBERNÉTICA DISTRIBUÍDA NGFW – TIPO III
3.1. Solução baseada em appliance. Para maior segurança, não serão aceitos equipamentos de propósito genérico (PCs ou servidores) sobre os quais poderiam instalar-se e/ou executar um sistema operacional regular como Microsoft Windows, FreeBSD, SUN Solaris, Apple OS-X ou GNU/Linux.
3.2. A solução poderá ser composta por mais de um equipamento para atender as funcionalidades exigidas, desde que todos os itens sejam do mesmo fabricante garantindo total compatibilidade e integração, desde que ocupem até 4U, no máximo.
3.3. Deve possuir e estar licenciado durante a vigência contratual de 36 (trinta e seis meses), minimamente com as seguintes funcionalidades: Firewall, Traffic Shapping, QoS, recursos de SD- WAN, Filtro de Conteúdo Web, Antivírus, AntiSpam, Detecção e Prevenção de Intrusos (IPS), VPN IPSec e SSL, Controle de Aplicações e contextos virtuais.
3.4. Deve possuir fonte de alimentação com chaveamento automático 110/220V.
3.5. Deve possuir firewall com capacidade mínima de processamento de 06 (seis) Gbps.
3.6. Deve possuir IPS com capacidade mínima de processamento de 1 (um) Gbps.
3.7. Proteção contra ameaças avançadas (Threat Protection) com capacidade mínima de processamento de 900 (novecentos) Mbps contemplando as funções de Firewall, IPS, controle de aplicação e proteção contra Malware/Antivírus ativadas de maneira simultâneas.
3.8. Deve possuir Inspeção SSL Throughput com capacidade mínima de processamento de 700 (setecentos) Mbps.
3.9. Deve possuir VPN com capacidade de, pelo menos, 06 (seis) Gbps de tráfego IPSec.
3.10. Deve suportar 1.000.000 (um milhão) conexões simultâneas.
3.11. Deverão ser licenciados para suportar, pelo menos, 150 (cento e cinquenta) usuários de VPN SSL.
3.12. Deve suportar, pelo menos, 40.000 (quarenta mil) novas conexões por segundo.
3.13. Deve suportar, pelo menos, 150 (cento e cinquenta) túneis de VPN Site-Site.
3.14. Deve suportar, pelo menos, 1.000(mil) túneis de VPN Client-Site.
3.15. Deve possuir, pelo menos, 02 (duas) interfaces SFP 1GE.
3.16. Deve possuir, pelo menos, 06 (seis) interfaces RJ 45.
3.17. Deve incluir licença para a funcionalidade de VPN SSL.
3.18. Todos os equipamentos que acompanharem a solução devem suportar o modo de alta disponibilidade e estar licenciados para operar desta forma.
3.19. Deve ser capaz de gerenciar, via funcionalidade de Controladora Switch, ao menos, 20(vinte) equipamentos.
3.20. Deve ser capaz de gerenciar, via funcionalidade de Controladora Wireless, ao menos, 40(quarenta) equipamentos.
3.21. Deve ser fornecida Solução de Gerência Centralizada de Equipamentos, caso compatível poderá ser utilizada atual solução existente na SEMIT/PMS, Marca Fortinet, Modelo FMG-3000G.
3.22. Deve ser fornecida Solução Centralizada de Armazenamento de Logs e Relatórios, caso compatível poderá ser utilizada atual solução existente na SEMIT/PMS, Marca Fortinet, Modelo FAZ-3700G.
3.23. deve possuir licença para atualização de firmware e atualização automática de bases de dados de todas as funcionalidades de segurança durante a vigência contratual.
3.24. Deve ser fornecida toda documentação técnica em formato digital, através de acesso a URL oficial do fabricante, em português do Brasil ou em inglês.
4. ITEM 04 - SOLUÇÃO DE SEGURANÇA CIBERNÉTICA DISTRIBUÍDA NGFW – TIPO IV
4.1. Solução baseada em appliance. Para maior segurança, não serão aceitos equipamentos de propósito genérico (PCs ou servidores) sobre os quais poderiam instalar-se e/ou executar um sistema operacional regular como Microsoft Windows, FreeBSD, SUN Solaris, Apple OS-X ou GNU/Linux.
4.2. A solução poderá ser composta por mais de um equipamento para atender as funcionalidades exigidas, desde que todos os itens sejam do mesmo fabricante garantindo total compatibilidade e integração, desde que ocupem até 4U, no máximo.
4.3. Deve possuir e estar licenciado durante a vigência contratual de 36 (trinta e seis meses), minimamente com as seguintes funcionalidades: Firewall, Traffic Shapping, QoS, recursos de SD- WAN, Filtro de Conteúdo Web, Antivírus, AntiSpam, Detecção e Prevenção de Intrusos (IPS), VPN IPSec e SSL, Controle de Aplicações e contextos virtuais.
4.4. Deve possuir fonte de alimentação com chaveamento automático 110/220V.
4.5. Deve possuir firewall com capacidade mínima de processamento de 6 (seis) Gbps.
4.6. Deve possuir IPS com capacidade mínima de processamento de 1 (um) Gbps.
4.7. Proteção contra ameaças avançadas (Threat Protection) com capacidade mínima de processamento de 600 (seiscentos) Mbps, contemplando as funções de Firewall, IPS, controle de aplicação e proteção contra Malware/Antivírus ativadas de maneira simultâneas.
4.8. Deve possuir Inspeção SSL Throughput com capacidade mínima de processamento de 600 (seiscentos) Mbps.
4.9. Deve possuir VPN com capacidade de, pelo menos, 06 (seis) Gbps de tráfego IPSec.
4.10. Deve suportar 600.000 (seiscentos mil) conexões simultâneas.
4.11. Deverão ser licenciados para suportar, pelo menos, 200 (duzentos) usuários de VPN SSL.
4.12. Deve suportar, pelo menos, 30.000 (trinta mil) novas conexões por segundo.
4.13. Deve suportar, pelo menos, 200 (duzentos) túneis de VPN Site-Site.
4.14. Deve suportar, pelo menos, 200 (duzentos) túneis de VPN Client-Site.
4.15. Deve possuir, pelo menos, 08 (oito) interfaces RJ 45.
4.16. Deve incluir licença para a funcionalidade de VPN SSL.
4.17. Todos os equipamentos que acompanharem a solução devem suportar o modo de alta disponibilidade e estar licenciados para operar desta forma.
4.18. Deve ser capaz de gerenciar, via funcionalidade de Controladora Switch, ao menos, 15(quinze) equipamentos.
4.19. Deve ser capaz de gerenciar, via funcionalidade de Controladora Wireless, ao menos, 30(trinta) equipamentos.
4.20. Deve ser fornecida Solução de Gerência Centralizada de Equipamentos, caso compatível poderá ser utilizada atual solução existente na SEMIT/PMS, Marca Fortinet, Modelo FMG-3000G.
4.21. Deve ser fornecida Solução Centralizada de Armazenamento de Logs e Relatórios, caso compatível poderá ser utilizada atual solução existente na SEMIT/PMS, Marca Fortinet, Modelo FAZ-3700G.
4.22. deve possuir licença para atualização de firmware e atualização automática de bases de dados de todas as funcionalidades de segurança durante a vigência contratual.
4.23. Deve ser fornecida toda documentação técnica em formato digital, através de acesso a URL oficial do fabricante, em português do Brasil ou em inglês.
5. REQUISITOS GERAIS DE FUNCIONALIDADES E LICENCIAMENTOS COMUNS A TODOS OS MODELOS ACIMA (SOLUÇÕES DE SEGURANÇA CIBERNÉTICA DISTRIBUÍDA - NGFW TIPO “I”, “II”, “III” E “IV”)
5.1. FUNCIONALIDADE DE FIREWALL
5.1.1. Deve possuir controle de acesso à internet por endereço IP de origem e destino;
5.1.2. Deve possuir controle de acesso à internet por sub rede;
5.1.3. Deve suportar tags de VLAN (802.1q);
5.1.4. Deve possuir ferramenta de diagnóstico do tipo tcpdump;
5.1.5. Deve possuir integração com servidores de autenticação RADIUS, LDAP e Microsoft Active Directory;
5.1.6. Deve possuir integração com tokens para autenticação de 02 (dois) fatores;
5.1.7. Deve suportar single-sign-on para Active Directory, RADIUS;
5.1.8. Deve possuir métodos de autenticação de usuários para qualquer aplicação que se execute sob os protocolos TCP (HTTP, HTTPS, FTP e Telnet);
5.1.9. Deve possuir a funcionalidade de tradução de endereços estáticos – NAT (Network Address Translation), um para um, vários para um, NAT64, NAT46, PAT, STUN e Full Cone NAT;
5.1.10. Deve permitir controle de acesso à internet por períodos do dia, permitindo a aplicação de políticas por horários e por dia da semana;
5.1.11. Deve permitir controle de acesso à internet por domínio, por exemplo: xxx.xx, xxx.xx, xxx.xx;
5.1.12. Deve possuir a funcionalidade de fazer tradução de endereços dinâmicos, muitos para um, PAT;
5.1.13. Deve suportar roteamento estático e dinâmico RIP V1, V2, OSPF, ISIS e BGPv4;
5.1.14. Deve possuir funcionalidades de DHCP Cliente, Servidor e Relay;
5.1.15. Deve suportar aplicações multimídia, como: X.323 e SIP;
5.1.16. Deve possuir tecnologia de firewall do tipo Statefull;
5.1.17. Deve suportar alta disponibilidade (HA), trabalhando no esquema de redundância do tipo Ativo- Passivo e também Ativo-Ativo, com divisão de carga, com todas as licenças de software habilitadas
para tal sem perda de conexões;
5.1.18. Deve permitir o funcionamento em modo transparente tipo “bridge” sem alterar o endereço MAC do tráfego;
5.1.19. Deve suportar PBR – Policy Based Routing;
5.1.20. Deve permitir a criação de VLANS no padrão IEEE 802.1q;
5.1.21. Deve possuir conexão entre estação de gerência e appliance criptografada, tanto em interface gráfica, quanto em CLI (linha de comando);
5.1.22. Deve permitir filtro de pacotes sem controle de estado (stateless) para verificação em camada 2;
5.1.23. Deve permitir forwarding de camada 2 para protocolos não IP;
5.1.24. Deve suportar forwarding multicast;
5.1.25. Deve suportar roteamento multicast PIM Sparse Mode e Dense Mode;
5.1.26. Deve permitir criação de serviços por porta ou conjunto de portas dos seguintes protocolos: TCP, UDP, ICMP e IP;
5.1.27. Deve permitir o agrupamento de serviços;
5.1.28. Deve permitir o filtro de pacotes sem a utilização de NAT;
5.1.29. Deve permitir a abertura de novas portas por fluxo de dados para serviços que requerem portas dinâmicas;
5.1.30. Deve possuir mecanismo de anti-spoofing;
5.1.31. Deve permitir criação de regras definidas pelo usuário;
5.1.32. Deve permitir o serviço de autenticação para tráfego HTTP e FTP;
5.1.33. Deve permitir IP/MAC binding, permitindo que cada endereço IP possa ser associado a um endereço MAC, gerando maior controle dos endereços internos e impedindo o IP spoofing;
5.1.34. Deve possuir a funcionalidade de balanceamento e contingência de links;
5.1.35. Deve suportar sFlow;
5.1.36. O dispositivo deve ter técnicas de detecção de programas de compartilhamento de arquivos (peer- to-peer) e de mensagens instantâneas.
5.1.37. Deve ter a capacidade de criar e aplicar políticas de reputação de cliente para registrar e pontuar as seguintes atividades: tentativas de conexões más, pacotes bloqueados por política, detecção de ataques de intrusão, detecção de ataques de malware, atividades Web em categorias de risco, proteção de aplicação, locais geográficos que os clientes estão tentando se comunicar;
5.1.38. Deve permitir autenticação de usuários em base local, servidor LDAP, RADIUS e TACACS;
5.1.39. Deve permitir a criação de regras baseada em usuário, grupo de usuários, endereço IP, FQDN, tipo de dispositivo, horário, protocolo e aplicação;
5.1.40. Deve suportar certificados X.509, SCEP, Certificate Signing Request (CSR) e OCSP;
5.1.41. Deve permitir funcionamento em modo bridge, router, proxy explícito, sniffer e/ou VLAN-tagged;
5.1.42. Deve possuir mecanismo de tratamento (session-helpers ou ALGs) para os protocolos ou aplicações dcerpc, dns-tcp, dns-udp, ftp, H.245 I, H.245 0, H.323, MGCP, MMS, PMAP, PPTP, RAS, RSH, SIP, TFTP, TNS;
5.1.43. Deve suportar SIP, X.323 e SCCP NAT Traversal;
5.1.44. Deve permitir a criação de objetos e agrupamento de objetos de usuários, redes, FQDN, protocolos e serviços para facilitar a criação de regras;
5.1.45. Deve possuir porta de comunicação serial ou USB para testes e configuração do equipamento, com
acesso protegido por usuário e senha.
5.2. FUNCIONALIDADE DE TRAFFIC SHAPING E PRIORIZAÇÃO DE TRÁFEGO
5.2.1. Deve permitir o controle e a priorização do tráfego, priorizando e garantindo banda para as aplicações (inbound/outbound), através da classificação dos pacotes (Shaping), criação de filas de prioridade, gerência de congestionamento e QoS;
5.2.2. Deve permitir modificação de valores DSCP para o DiffServ;
5.2.3. Deve permitir priorização de tráfego e suportar ToS;
5.2.4. Deve limitar individualmente a banda utilizada por programas, tais como: peer-to-peer, streaming, chat, VoIP e Web;
5.2.5. Deve integrar-se ao serviço de diretório padrão LDAP, inclusive o Microsoft Active Directory, reconhecendo grupos de usuários cadastrados;
5.2.6. Deve prover funcionalidade de identificação transparente de usuários cadastrados no Microsoft Active Directory e LDAP;
5.2.7. Deve controlar (limitar ou expandir) individualmente a banda utilizada por grupo de usuários do Microsoft Active Directory e LDAP;
5.2.8. Deve permitir definir banda máxima e banda garantida para um usuário, IP, grupo de IPs, protocolo e aplicação;
5.2.9. Deve controlar (limitar ou expandir) individualmente a banda utilizada por subrede de origem e destino;
5.2.10. Deve controlar (limitar ou expandir) individualmente a banda utilizada por endereço IP de origem e destino;
5.3. FUNCIONALIDADE DE ANTI-SPAM DE GATEWAY
5.3.1. Deve permitir, na funcionalidade de anti-spam, verificação do cabeçalho SMTP do tipo MIME;
5.3.2. Deve possuir filtragem de e-mail por palavras chaves;
5.3.3. Deve permitir adicionar rótulo ao assunto da mensagem quando classificado como SPAM;
5.3.4. Deve possuir, para a funcionalidade de anti-spam, o recurso de RBL;
5.3.5. Deve permitir a checagem de reputação da URL no corpo mensagem de correio eletrônico;
5.4. FUNCIONALIDADE DE FILTRO DE CONTEÚDO WEB
5.4.1. Deve possuir solução de filtro de conteúdo Web integrado à solução de segurança;
5.4.2. Deve possuir, pelo menos, 70 (setenta) categorias para classificação de sites Web;
5.4.3. Deve possuir base mínima contendo 100.000.000 (cem milhões) de sites internet Web já registrados e classificados;
5.4.4. Deve possuir a funcionalidade de cota de tempo de utilização por categoria;
5.4.5. Deve possuir categoria exclusiva, no mínimo, para os seguintes tipos de sites Web, como:
5.4.5.1. Proxy anônimo;
5.4.5.2. Webmail;
5.4.5.3. Instituições de saúde;
5.4.5.4. Notícias;
5.4.5.5. Phishing;
5.4.5.6. Hackers;
5.4.5.7. Pornografia;
5.4.5.8. Racismo;
5.4.5.9. Websites pessoais;
5.4.5.10. Compras;
5.4.6. Deve permitir a monitoração do tráfego internet sem bloqueio de acesso aos usuários;
5.4.7. Deve permitir a criação de, pelo menos, 07 (sete) categorias personalizadas;
5.4.8. Deve permitir a reclassificação de sites Web, tanto por URL, quanto por endereço IP;
5.4.9. Deve prover Termo de Responsabilidade on-line, podendo ser customizável, aceitando idioma português, para aceite pelo usuário, a ser apresentado toda vez que quando houver tentativa de acesso a determinado serviço permitido ou bloqueado;
5.4.10. Deve integrar-se ao serviço de diretório padrão LDAP, inclusive o Microsoft Active Directory, reconhecendo contas e grupos de usuários cadastrados;
5.4.11. Deve prover funcionalidade de identificação transparente de usuários cadastrados no Microsoft Active Directory;
5.4.12. Deve possuir integração com tokens para autenticação de 02 (dois) fatores;
5.4.13. Deve exibir mensagem de bloqueio customizável pelos Administradores para resposta aos usuários na tentativa de acesso a recursos proibidos pela política de segurança;
5.4.14. Deve permitir a filtragem de todo o conteúdo do tráfego WEB de URLs conhecidas como fonte de material impróprio e códigos (programas/scripts) maliciosos em applets Java e cookies, através de base de URL própria atualizável;
5.4.15. Deve permitir o bloqueio de páginas Web através da construção de filtros específicos com mecanismo de busca textual;
5.4.16. Deve permitir a criação de listas personalizadas de URLs permitidas (lista branca) e bloqueadas (lista negra);
5.4.17. Deve permitir o bloqueio de URLs inválidas, cujo campo CN do certificado SSL não contenha um domínio válido;
5.4.18. Deve filtrar o conteúdo baseado em categorias em tempo real;
5.4.19. Deve garantir que as atualizações regulares do produto sejam realizadas sem interromper a execução dos serviços de filtragem de conteúdo Web;
5.4.20. Deve permitir a criação de regras para acesso/bloqueio por grupo de usuários do serviço de diretório LDAP;
5.4.21. Deve permitir a criação de regras para acesso/bloqueio por endereço IP de origem;
5.4.22. Deve permitir a criação de regras para acesso/bloqueio por sub rede de origem;
5.4.23. Deve ser capaz de categorizar a página Web, tanto pela sua URL, como pelo seu endereço IP;
5.4.24. Deve permitir o bloqueio de redirecionamento HTTP;
5.4.25. Deve permitir o bloqueio de páginas Web por classificação como páginas que facilitem a busca de áudio, vídeo e URLs originadas de spams;
5.4.26. Deve possuir Proxy Explícito e Transparente;
5.4.27. Deve implementar roteamento WCCP e ICAP;
5.5. FUNCIONALIDADE DE DETECÇÃO DE INTRUSÃO
5.5.1. Deve permitir que seja definido, através de regra por IP origem, IP destino, protocolo e porta, qual tráfego será inspecionado pelo sistema de detecção de intrusão;
5.5.2. Deve possuir base de assinaturas de IPS com, pelo menos, 3.500 (três mil e quinhentas) ameaças
conhecidas;
5.5.3. Deve estar orientado à proteção de redes;
5.5.4. Deve permitir funcionar em modo transparente, sniffer e router;
5.5.5. Deve possuir tecnologia de detecção baseada em assinaturas que sejam atualizadas automaticamente;
5.5.6. Deve permitir a criação de padrões de ataque manualmente;
5.5.7. Deve possuir integração à plataforma de segurança;
5.5.8. Deve possuir capacidade de remontagem de pacotes para identificação de ataques;
5.5.9. Deve possuir capacidade de agrupar assinaturas para um determinado tipo de ataque. Exemplo: agrupar todas as assinaturas relacionadas a web-server, para que seja usado para proteção específica de Servidores Web;
5.5.10. Deve possuir capacidade de análise de tráfego para a detecção e bloqueio de anomalias, como Denial of Service (DoS) do tipo Flood, Scan, Session e Sweep;
5.5.11. Deve possuir mecanismos de detecção/proteção de ataques;
5.5.12. Deve possuir reconhecimento de padrões;
5.5.13. Deve possuir análise de protocolos;
5.5.14. Deve possuir detecção de anomalias;
5.5.15. Deve possuir detecção de ataques de RPC (Remote Procedure Call);
5.5.16. Deve possuir proteção contra-ataques de Windows ou NetBios;
5.5.17. Deve possuir proteção contra-ataques de SMTP (Simple Message Transfer Protocol), IMAP (Internet Message Access Protocol), Sendmail ou POP (Post Office Protocol);
5.5.18. Deve possuir proteção contra-ataques DNS (Domain Name System);
5.5.19. Deve possuir proteção contra-ataques a FTP, SSH, Telnet e rlogin;
5.5.20. Deve possuir proteção contra-ataques de ICMP (Internet Control Message Protocol);
5.5.21. Deve possuir métodos de notificação de detecção de ataques;
5.5.22. Deve possuir alarmes na console de administração;
5.5.23. Deve possuir alertas via correio eletrônico;
5.5.24. Deve possuir monitoração do comportamento do appliance, mediante SNMP. O dispositivo deve ser capaz de enviar traps de SNMP quando ocorrer um evento relevante para a correta operação da rede;
5.5.25. Deve ter a capacidade de resposta/logs ativa a ataques;
5.5.26. Deve prover a terminação de sessões via TCP resets;
5.5.27. Deve armazenar os logs de sessões;
5.5.28. Deve atualizar automaticamente as assinaturas para o sistema de detecção de intrusos;
5.5.29. Deve mitigar os efeitos dos ataques de negação de serviços;
5.5.30. Deve permitir a criação de assinaturas personalizadas;
5.5.31. Deve possuir filtros de ataques por anomalias;
5.5.32. Deve permitir filtros de anomalias de tráfego estatístico de: flooding, scan, source e destination session limit;
5.5.33. Deve permitir filtros de anomalias de protocolos;
5.5.34. Deve suportar reconhecimento de ataques de DoS, reconnaissance, exploits e evasion;
5.5.35. Deve suportar verificação de ataque na camada de aplicação;
5.5.36. Deve suportar verificação de tráfego em tempo real, via aceleração de hardware;
5.5.37. Deve possuir as seguintes estratégias de bloqueio: pass, drop e reset.
5.6. FUNCIONALIDADE DE VPN
5.6.1. Deve possuir algoritmos de criptografia para túneis VPN: AES, DES, 3DES;
5.6.2. Deve possuir suporte a certificados PKI X.509 para construção de VPNs;
5.6.3. Deve possuir suporte a VPNs IPSeC Site-to-Site e VPNs IPSec Client-to-Site;
5.6.4. Deve possuir suporte a VPN SSL;
5.6.5. Deve possuir capacidade de realizar SSL VPNs utilizando certificados digitais;
5.6.6. Deve possuir hardware acelerador criptográfico para incrementar o desempenho da VPN;
5.6.7. A VPN SSL deve suportar cliente para plataforma Windows, Linux e Mac OS X;
5.6.8. Deve permitir a arquitetura de VPN hub and spoke;
5.6.9. Deve possuir suporte à inclusão em autoridades certificadoras (enrollment), mediante SCEP (Simple Certificate Enrollment Protocol) e mediante arquivos.
5.7. FUNCIONALIDADE DE CONTROLE DE APLICAÇÕES
5.7.1. Deve reconhecer, no mínimo, 2.000 (duas mil) aplicações;
5.7.2. Deve possuir, pelo menos, 10 (dez) categorias para classificação de aplicações;
5.7.3. Deve possuir categoria exclusiva, no mínimo, para os seguintes tipos de aplicações, como:
5.7.3.1. P2P
5.7.3.2. Instant Messaging;
5.7.3.3. Web client;
5.7.3.4. Transferência de arquivos;
5.7.3.5. VoIP;
5.7.4. Deve permitir a monitoração do tráfego de aplicações sem bloqueio de acesso aos usuários;
5.7.5. Deve ser capaz de controlar aplicações independente do protocolo e porta utilizados, identificando-as apenas pelo comportamento de tráfego da mesma;
5.7.6. Deve integrar-se ao serviço de diretório padrão LDAP, inclusive o Microsoft Active Directory, reconhecendo grupos de usuários cadastrados;
5.7.7. Deve prover funcionalidade de identificação transparente de usuários cadastrados no Microsoft Active Directory;
5.7.8. Deve permitir a criação de regras para acesso/bloqueio de aplicações por grupo de usuários do Microsoft Active Directory;
5.7.9. Deve permitir a criação de regras para acesso/bloqueio de aplicações por grupo de usuários do serviço de diretório LDAP;
5.7.10. Deve permitir a criação de regras para acesso/bloqueio por endereço IP de origem;
5.7.11. Deve possuir integração com tokens para autenticação de 02 (dois) fatores;
5.7.12. Deve permitir a criação de regras para acesso/bloqueio por subrede de origem e destino;
5.7.13. Deve permitir a inspeção/bloqueio de códigos maliciosos para, no mínimo, as seguintes categorias: Instant Messaging e transferência de arquivos;
5.7.14. Deve garantir que as atualizações regulares do produto sejam realizadas sem interromper a execução dos serviços de controle de aplicações;
5.7.15. Deve permitir criação de padrões de aplicação manualmente;
5.8. FUNCIONALIDADE DE BALANCEAMENTO DE CARGA
5.8.1. Deve permitir a criação de endereços IPs virtuais;
5.8.2. Deve permitir balanceamento de carga entre, pelo menos, 04 (quatro) servidores reais;
5.8.3. Deve suportar balanceamento, ao menos, para os seguintes serviços: HTTP, HTTPS, TCP e UDP;
5.8.4. Deve permitir balanceamento, ao menos, com os seguintes métodos: Hash do endereço IP de origem, Static, Round Robin, Weighted, First Alive e HTTP host, Least Session, Least RTT;
5.8.5. Deve permitir persistência de sessão por cookie HTTP ou SSL session ID;
5.8.6. Deve permitir que seja mantido o IP de origem;
5.8.7. Deve suportar SSL offloading nos equipamentos que suportem, pelo menos, 200 (duzentos) usuários;
5.8.8. Deve ter a capacidade de identificar, através de health checks, quais os servidores que estejam ativos, removendo automaticamente o tráfego dos servidores que não estejam;
5.8.9. Deve permitir que o health check seja feito, ao menos, via ICMP, TCP em porta configurável e HTTP em URL configurável.
5.9. FUNCIONALIDADE DE VIRTUALIZAÇÃO
5.9.1. Deve suportar a criação de, ao menos, 10 (dez) instâncias virtuais no mesmo hardware;
5.9.2. Deve permitir a criação de administradores independentes para cada uma das instâncias virtuais;
5.9.3. Deve permitir a criação de um administrador global que tenha acesso a todas as configurações das instâncias virtuais criadas.
5.10. FUNCIONALIDADE DE CONTROLADORA WIRELESS E WI-FI
5.10.1. Deverá ser capaz de gerenciar, de forma centralizada, outros Pontos de Acesso do mesmo fabricante;
5.10.2. Deverá suportar o serviço de servidor DHCP por SSID para prover endereçamento IP automático para os clientes wireless;
5.10.3. Deverá suportar monitoração e supressão de Ponto de Acesso indevido;
5.10.4. Deverá prover autenticação para a rede wireless através de bases externas, como: LDAP, RADIUS ou TACACS+;
5.10.5. Deverá permitir a visualização dos clientes conectados;
5.10.6. Deverá prover suporte a Fast Roaming;
5.10.7. Deverá ajustar automaticamente os canais de modo a otimizar a cobertura de rede e mudar as condições de RF;
5.10.8. A solução deve implementar recursos de análise de espectro que possibilitem a identificação de interferências provenientes de equipamentos não-WiFi e que operem nas frequências de 2.4GHz ou 5GHz. A solução deve ainda apresentar o resultado dessas análises de maneira gráfica na interface de gerência;
5.10.9. Deverá possuir Captive Portal por SSID;
5.10.10. Deverá permitir configurar o bloqueio de tráfego entre SSIDs;
5.10.11. Deverá suportar Wi-Fi Protected Access (WPA), WPA2 ou WPA3 por SSID, utilizando-se de AES e/ou TKIP;
5.10.12. Deverá suportar os seguintes métodos de autenticação EAP:
5.10.12.1. EAP-TLS, EAP-TTLS, EAP-PEAP, EAP-SIM, EAP-AKA;
5.10.13. Deverá suportar 802.1x através de RADIUS;
5.10.14. Deverá suportar filtro baseado em endereço MAC por SSID;
5.10.15. Deverá permitir configurar parâmetros de rádio, como: banda e canal;
5.10.16. Deverá possuir método de descoberta de novos Pontos de Acesso baseados em Broadcast ou Multicast;
5.10.17. Deverá possuir mecanismo de identificação e controle de Rogue APs, suportando supressão automática e bloqueio por endereço MAC de APs;
5.10.18. Deverá possuir lista contendo Pontos de Acesso Aceitos e Pontos de Acesso Indevidos (Rogue);
5.10.19. Deverá possuir WIDS com, ao menos, os seguintes perfis:
5.10.19.1. Rogue/Interfering AP Detection;
5.10.19.2. Ad-hoc Network Detection;
5.10.19.3. Wireless Bridge Detection;
5.10.19.4. Weak WEP Detection;
5.10.19.5. MAC OUI Checking;
5.10.20. Deverá permitir o uso de voz e dados sobre um mesmo SSID;
5.10.21. A solução deverá detectar Receiver Start of Packet (RX-SOP) em pacotes wireless e ser capaz de ignorar os pacotes que estejam abaixo de determinado limiar especificado em dBm;
5.10.22. A controladora deverá oferecer Firewall integrado, baseado em identidade do usuário;
5.10.23. Deverá possuir controle baseado em política de firewall para acesso entre as WLANs;
5.10.24. Deverá permitir a criação de políticas de traffic shaping;
5.10.25. Deverá permitir a criação de políticas de firewall baseadas em horário;
5.10.26. Deverá permitir NAT nas políticas de firewall;
5.10.27. Deverá possibilitar definir número de clientes por SSID;
5.10.28. Deverá permitir e/ou bloquear o tráfego entre SSIDs;
5.10.29. Deverá possuir mecanismo de criação automática de usuários visitantes e senhas autogeradas e/ou manual, que possam ser enviadas por e-mail ou SMS aos usuários, e com capacidade de definição de horário da expiração da senha;
5.10.30. A comunicação entre o Access Point e a Controladora Wireless deverá poder ser efetuada de forma criptografada;
5.10.31. Deverá possuir mecanismo de ajuste de potência do sinal, de forma a reduzir interferência entre canais entre 02 (dois) Access Points gerenciados;
5.10.32. Deverá possuir mecanismo de balanceamento de tráfego/usuários entre Access Points;
5.10.33. Deverá possuir mecanismo de balanceamento de tráfego/usuários entre frequências e/ou
5.10.34. rádios;
5.10.35. Toda a configuração do Ponto de Acesso deverá ser executada através da Controladora Wireless;
5.10.36. Deverá permitir a identificação de APs com firmware desatualizado e efetuar o upgrade via interface gráfica;
5.10.37. Deverá possuir console de monitoramento dos usuários conectados, indicando em que Access
Point, em que rádio, em que canal, endereço IP do usuário, tipo de dispositivo e sistema operacional, uso de banda, potência do sinal e relação sinal/ruído;
5.10.38. O encaminhamento de tráfego dos dispositivos conectados à rede sem fio deve ocorrer de forma centralizada através de túnel estabelecido entre o ponto de acesso e controlador wireless. Neste modo todos os pacotes trafegados em um determinado SSID devem ser encaminhados dentro do túnel até o controlador wireless. Caso o controlador wireless não seja capaz de operar gerenciando os pontos de acesso e concentrando o tráfego tunelado simultaneamente, então a solução ofertada deve ser composta com elemento adicional do próprio fabricante para suportar a conexão dos túneis originados dos pontos de acesso;
5.10.39. A Controladora deverá oferecer Firewall integrado, baseado em identidade do usuário, entre todas as redes cujo tráfego seja tunelado até a Controladora;
5.10.40. Deverá possuir controle baseado em política de firewall para acesso entre as WLANs cujo tráfego seja tunelado até a Controladora;
5.10.41. Deverá permitir a criação de políticas de traffic shaping entre todas as redes cujo tráfego seja tunelado até a Controladora;
5.10.42. Deverá permitir aplicar políticas de filtro de conteúdo Web, que seja baseado em categorias de sites automaticamente atualizadas, para todas as redes cujo tráfego seja tunelado até a Controladora;
5.10.43. Deverá permitir aplicar políticas de antivírus, com detecção e bloqueio de malwares e redes botnet, entre todas as redes cujo tráfego seja tunelado até a Controladora;
5.10.44. Deverá permitir aplicar políticas de IPS, bloqueando e/ou monitorando tentativas de ataques, com base de assinatura de ataques atualizada automaticamente, entre todas as redes cujo tráfego seja tunelado até a Controladora;
5.10.45. Deverá permitir aplicar políticas de controle AntiSpam para todas as redes cujo tráfego seja tunelado até a Controladora;
5.10.46. Deverá permitir controlar, identificar e bloquear tráfego de aplicações do tipo P2P, IM, Chat, Redes Sociais, Skype, Proxies Anônimos, streamings de áudio e vídeo, jogos entre outros, e que seja baseado no padrão de comunicação de tais aplicações, entre todas as redes cujo tráfego seja tunelado até a Controladora;
5.10.47. A solução deve implementar recurso de controle de acesso à rede (NAC - Network Access Control), identificando automaticamente o tipo de equipamento conectado (profiling) e atribuindo de maneira automática a política de acesso à rede;
5.11. FUNCIONALIDADE DE SD-WAN
5.11.1. A solução SD-WAN deve ser viabilizada com recursos de segurança integrados de: Firewall, VPN, Antivírus, IPS e Filtro de Segurança Web.
5.11.2. A solução SD-WAN deve suportar NAT em contexto de saída (Nat Outbound) para um pool de IPs públicos.
5.11.3. A solução SD-WAN deve suportar segmentação de tráfego onde seja possível aplicar políticas de IPS e Antivírus entre segmentos de LAN.
5.11.4. A solução SD-WAN deve prover capacidade de inspeção SSL para a inspeção de tráfego https nas filiais, no contexto: bloqueio de malwares e reconhecimento em camada 7 de aplicações.
5.11.5. Solução deve ser capaz de prover Zero Touch provisioning.
5.11.6. A solução de Zero Touch provisioning deve ser capaz de suportar endereçamento estáticos e dinâmicos, e que seja suportado múltiplos links WAN.
5.11.7. Solução deve ser capaz de prover uma arquitetura onde em uma comunicação Matriz x Filiais, em que a comunicação de uma Filial A para a Matriz esteja comprometida, possa ser utilizada a comunicação entre Filial B e Matriz, em que através deste circuito, a Filial A alcance a Matriz.
5.11.8. A solução deve ser capaz de criar VPN "Full-Mesh" em interface gráfica ou CLI, de forma automática, e sem que o administrador precise configurar site por site.
5.11.9. A configuração VPN IPSEC deve oferecer suporte para DH Group: 14 e 15.
5.11.10. Reconhecimento em camada 7 totalmente segregado da camada 4.
5.11.11. Deve de forma alternativa, contar com um banco de Dados interno, onde seja possível atrelar uma aplicação à um determinado IP/ range de IPs de destino.
5.11.12. O reconhecimento de aplicações deve ser realizado independente de porta e protocolo, inspecionando o payload de pacote de dados;
5.11.13. Ainda sobre o reconhecimento de Aplicações, a solução deve fornecer o reconhecimento default em camada 7, de pelo menos mais de 2000 aplicações largamente utilizadas em contextos de SaaS, Aplicações na Nuvem, Aplicações Multimídia (Vimeo, YouTube, Facebook, etc)
5.11.14. A solução de SD-WAN deve suportar Roteamento dinâmico BGP com suporte a IPv6
5.11.15. A solução deve ser capaz de refletir, de forma manual ou automatizada, suas políticas de SD-WAN em condições onde a largura de banda é modificada.
5.11.16. A solução deve ser capaz de medir o Status de Saúde do Link baseando-se em critérios mínimos de: Latência, Jitter e Packet Loss, onde seja possível configurar um valor de Theshold para cada um destes itens, onde será utilizado como fator de decisão nas regras de SD-WAN.
5.11.17. A solução deve permitir a configuração de regras onde o Failback (retorno à condição inicial) apenas ocorrerá quando o link principal recuperado seja X% (com X variando de 10 à 50) do seu valor de saúde melhor que o link atual.
5.11.18. A solução deve permitir a configuração de regras onde o Failback (retorno à condição inicial) apenas ocorra dentro de um espaço de tempo de X segundos, configurável pelo administrador do sistema.
5.11.19. A solução deve permitir a configuração de políticas de QoS em camada 7, associadas percentualmente à largura de banda da Interface SD-WAN.
6. ITEM 05 - ATIVO DE REDE WIRELESS TIPO “I”
6.1. Deve possuir garantia e suporte do fabricante pelo período de 36 (trinta e seis) meses
6.2. Deve possuir, ao menos, 02 (duas) interfaces de rede 10/100/1000 Base-T RJ-45.
6.3. Deve possuir, ao menos, 01 (uma) interface de console RS-232 RJ-45.
6.4. Deve possuir, ao menos 01 rádio BLE (Bluetooth Low Energy) integrado e interno ao equipamento.
6.5. Deve suportar, ao menos, 16 (dezesseis) SSIDs simultâneos por Ponto de Acesso, sendo, pelo menos, 08 (oito) por rádio.
6.6. Deve possuir potência de transmissão de, ao menos, 21 dBm.
6.7. Deve possuir antenas internas e integradas com padrão de irradiação omnidirecional compatíveis com as frequências de rádio dos padrões IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, IEEE 802.11n, IEEE 802.11ac e IEEE 802.11ax com ganhos de, no mínimo, 3 dBi para 5GHz.
6.8. Deve suportar operação na temperatura de 0 a 40 °C.
6.9. Deve ser fornecido com todos os acessórios necessários para que seja feita sua fixação em teto ou parede.
6.10. Deve suportar os padrões 802.11a/b/g/n/ac/ax.
6.11. Deve possuir capacidade dual-band com rádios 2.4GHz e 5GHz operando simultaneamente, além de permitir configurações independentes para cada rádio;
6.12. O ponto de acesso deve possuir rádio Wi-Fi adicional a aqueles que conectam clientes para funcionar exclusivamente como sensor Wi-Fi com objetivo de identificar interferências e ameaças
de segurança (wIDS/wIPS) em tempo real e com operação 24x7. Caso o ponto de acesso não possua rádio adicional com tal recurso, será aceita composição do ponto de acesso e hardware ou ponto de acesso adicional do mesmo fabricante para funcionamento dedicado para tal operação;
6.13. Deve possuir a tecnologia MU-MIMO com operação 2x2.
6.14. Deve suportar taxas de conexão (data rate) de até 1.2 Gbps.
6.15. Deve atender aos padrões IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, IEEE 802.11n, IEEE 802.11ac Wave1/Wave2 e IEEE 802.11ax, com operação nas frequências de 2.4 GHz e 5 GHz de forma simultânea
6.16. Deve possuir PoE (Power over Ethernet), padrão 802.3at, possibilitando seu uso sem a necessidade de fontes de energia externas em qualquer porta Ethernet.
6.17. Deve ser incluso injetor PoE capaz de suportar completa operação do equipamento;
6.18. Deve suportar a criação de redes mesh.
6.19. O encaminhamento de tráfego dos dispositivos conectados à rede sem fio deve ocorrer de forma centralizada através de túnel estabelecido entre o ponto de acesso e controlador wireless. Neste modo todos os pacotes trafegados em um determinado SSID devem ser encaminhados via túnel seguro (com criptografia) até o controlador wireless;
6.20. Deve suportar a criação de enlaces de bridge entre 02 (dois) Access Points.
6.21. Deve suportar associação dinâmica de usuários a VLANs de acordo com parâmetros de autenticação.
6.22. Em conjunto com o controlador wireless, deve implementar recursos de análise de espectro que possibilitem a identificação de interferências provenientes de equipamentos não-WiFi e que operem nas frequências de 2.4GHz ou 5GHz;
6.23. Deve possuir funcionalidade de ajuste de potência automática, de forma a reduzir interferência entre canais.
6.24. Deve implementar UL (uplink) MU-MIMO 802.11ax mode.
6.25. Deve implementar Spectrum Analyzer.
6.26. Deve implementar Spatial Reuse (BSS Coloring).
6.27. Deve suportar recurso de Target Wake Time (TWT) configurado por SSID;
6.28. Deve possuir certificação WiFi Alliance.
6.29. Deve possuir homologação da ANATEL, de acordo com a Resolução número 242.
6.30. Deve ser compatível e gerenciado pelos ITENS 01, 02, 03 e 04 “SOLUÇÃO DE SEGURANÇA CIBERNÉTICA DISTRIBUÍDA NGFW TIPO I, II, III e IV” , caso compatível poderão ser utilizadas atuais controladoras WiFi existentes na SEMIT, Marca Fortinet, Modelos FG1800F/FG1100E/ FG200F/ FG100F, e ou por solução do mesmo fabricante que possua gerência centralizada, devendo atender aos requisitos descritos abaixo:
6.30.1. Deverá ser capaz de gerenciar, de forma centralizada, outros Pontos de Acesso do mesmo fabricante;
6.30.2. Deverá suportar o serviço de servidor DHCP por SSID para prover endereçamento IP automático para os clientes wireless;
6.30.3. Deverá suportar monitoração e supressão de Ponto de Acesso indevido;
6.30.4. Deverá prover autenticação para a rede wireless através de bases externas, como: LDAP, RADIUS ou TACACS+;
6.30.5. Deverá permitir a visualização dos clientes conectados;
6.30.6. Deverá prover suporte a Fast Roaming;
6.30.7. Deverá ajustar automaticamente os canais de modo a otimizar a cobertura de rede e mudar as condições de RF;
6.30.8. A solução deve implementar recursos de análise de espectro que possibilitem a identificação de interferências provenientes de equipamentos não-WiFi e que operem nas frequências de 2.4GHz ou 5GHz. A solução deve ainda apresentar o resultado dessas análises de maneira gráfica na interface de gerência;
6.30.9. Deverá possuir Captive Portal por SSID;
6.30.10. Deverá permitir configurar o bloqueio de tráfego entre SSIDs;
6.30.11. Deverá possuir método de descoberta de novos Pontos de Acesso baseados em Broadcast ou Multicast;
6.30.12. Deverá possuir lista contendo Pontos de Acesso Aceitos e Pontos de Acesso Indevidos (Rogue);
6.30.13. Deverá possuir controle baseado em política de firewall para acesso entre as WLANs cujo tráfego seja tunelado até a Controladora;
6.30.14. Deverá permitir a criação de políticas de traffic shaping entre todas as redes cujo tráfego seja tunelado até a Controladora;
6.30.15. Deverá permitir a criação de políticas de firewall baseadas em horário;
6.30.16. Deverá permitir NAT nas políticas de firewall;
6.30.17. Deverá possibilitar definir número de clientes por SSID;
6.30.18. Deverá permitir e/ou bloquear o tráfego entre SSIDs;
6.30.19. Deverá possuir mecanismo de criação automática de usuários visitantes e senhas autogeradas e/ou manual, que possam ser enviadas por e-mail ou SMS aos usuários, e com capacidade de definição de horário da expiração da senha;
6.30.20. A comunicação entre o Access Point e a Controladora Wireless deverá poder ser efetuada de forma criptografada;
6.30.21. Deverá possuir mecanismo de ajuste de potência do sinal, de forma a reduzir interferência entre canais entre 02 (dois) Access Points gerenciados;
6.30.22. Deverá possuir mecanismo de balanceamento de tráfego/usuários entre Access Points;
6.30.23. Deve possuir mecanismo de balanceamento de tráfego/usuários entre frequências e/ou rádios;
6.30.24. Toda a configuração do Ponto de Acesso deverá ser executada através da Controladora Wireless;
6.30.25. Deverá permitir a identificação de APs com firmware desatualizado e efetuar o upgrade via interface gráfica;
6.30.26. Deverá possuir console de monitoramento dos usuários conectados, indicando em que Access Point, em que rádio, em que canal, endereço IP do usuário, tipo de dispositivo e sistema operacional, uso de banda, potência do sinal e relação sinal/ruído;
6.30.27. Deverá permitir aplicar políticas de IPS, bloqueando e/ou monitorando tentativas de ataques, com base de assinatura de ataques atualizada automaticamente, entre todas as redes cujo tráfego seja tunelado até a Controladora;
6.30.28. Deve suportar Wi-Fi Protected Access (WPA), WPA2 ou WPA3 por SSID, utilizando-se de AES e/ou TKIP;
6.30.29. Deve suportar os seguintes métodos de autenticação EAP:
6.30.29.1. EAP-TLS , EAP-TTLS, EAP-PEAP, EAP-SIM, EAP-AKA;
6.30.30. Deve suportar 802.1x através de RADIUS;
6.30.31. Deve suportar filtro baseado em endereço MAC por SSID;
6.30.32. Deve permitir configurar parâmetros de rádio, como: banda e canal;
6.30.33. Deve possuir método de descoberta de novos Pontos de Acesso baseados em Broadcast ou Multicast;
6.30.34. Deve possuir mecanismo de identificação e controle de Rogue APs, suportando supressão automática e bloqueio por endereço MAC de APs;
6.30.35. Deve possuir lista contendo Pontos de Acesso Aceitos e Pontos de Acesso Indevidos (Rogue);
6.30.36. Deve possuir WIDS com, ao menos, os seguintes perfis:
6.30.36.1. Rogue/Interfering AP Detection;
6.30.36.2. Ad-hoc Network Detection;
6.30.36.3. Wireless Bridge Detection;
6.30.36.4. Weak WEP Detection;
6.30.36.5. MAC OUI Checking;
6.30.37. A solução deve detectar Receiver Start of Packet (RX-SOP) em pacotes wireless e ser capaz de ignorar os pacotes que estejam abaixo de determinado limiar especificado em dBm;
6.30.38. O encaminhamento de tráfego dos dispositivos conectados à rede sem fio deve ocorrer de forma centralizada através de túnel estabelecido entre o ponto de acesso e controlador wireless. Neste modo todos os pacotes trafegados em um determinado SSID devem ser encaminhados dentro do túnel até o controlador wireless. Caso o controlador wireless não seja capaz de operar gerenciando os pontos de acesso e concentrando o tráfego tunelado simultaneamente, então a solução ofertada deve ser composta com elemento adicional do próprio fabricante para suportar a conexão dos túneis originados dos pontos de acesso;
7. ITEM 06 - ATIVO DE REDE WIRELESS TIPO “II”
7.1. Deve possuir garantia e suporte do fabricante pelo período de 36 (trinta e seis) meses
7.2. Deve possuir, ao menos, 01 (uma) interfaces de rede 100/1000/2500 Base-T RJ-45.
7.3. Deve possuir, ao menos, 01 (uma) interfaces de rede 100/100/1000 Base-T RJ-45.
7.4. Deve possuir, ao menos, 01 (uma) interface de console RS-232 RJ-45.
7.5. Deve possuir, ao menos 01 rádio BLE (Bluetooth Low Energy) integrado e interno ao equipamento.
7.6. Deve possuir, ao menos 05 antenas externas.
7.7. Deve suportar, ao menos, 16 (dezesseis) SSIDs simultâneos por Ponto de Acesso, sendo, pelo menos, 08 (oito) por rádio.
7.8. Deve possuir potência de transmissão de, ao menos, 21 dBm.
7.9. Deve possuir antenas externas com padrão de irradiação omnidirecional compatíveis com as frequências de rádio dos padrões IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, IEEE 802.11n, IEEE 802.11ac e IEEE 802.11ax com ganhos de, no mínimo, 3 dBi para 5GHz.
7.10. Deve suportar operação na temperatura de 0 a 60 °C.
7.11. Deve ser fornecido com todos os acessórios necessários para que seja feita sua fixação em teto ou parede.
7.12. Deve suportar os padrões 802.11a/b/g/n/ac/ax.
7.13. Deve possuir capacidade dual-band com rádios 2.4GHz e 5GHz operando simultaneamente, além de permitir configurações independentes para cada rádio;
7.14. O ponto de acesso deve possuir rádio Wi-Fi adicional a aqueles que conectam clientes para funcionar exclusivamente como sensor Wi-Fi com objetivo de identificar interferências e ameaças de segurança (wIDS/wIPS) em tempo real e com operação 24x7. Caso o ponto de acesso não possua
rádio adicional com tal recurso, será aceita composição do ponto de acesso e hardware ou ponto de acesso adicional do mesmo fabricante para funcionamento dedicado para tal operação;
7.15. Deve possuir a tecnologia MU-MIMO com operação 4x4.
7.16. Deve suportar taxas de conexão (data rate) de no mínimo 02 Gbps.
7.17. Deve atender aos padrões IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, IEEE 802.11n, IEEE 802.11ac Wave1/Wave2 e IEEE 802.11ax, com operação nas frequências de 2.4 GHz e 5 GHz de forma simultânea
7.18. Deve possuir PoE (Power over Ethernet), padrão 802.3bt, possibilitando seu uso sem a necessidade de fontes de energia externas em qualquer porta Ethernet.
7.19. Deve ser fornecido injetor POE padrão 802.3bt.
7.20. Deve possuir certificação para ambientes externos IP67.
7.21. Deve suportar a criação de redes mesh.
7.22. O encaminhamento de tráfego dos dispositivos conectados à rede sem fio deve ocorrer de forma centralizada através de túnel estabelecido entre o ponto de acesso e controlador wireless. Neste modo todos os pacotes trafegados em um determinado SSID devem ser encaminhados via túnel seguro (com criptografia) até o controlador wireless;
7.23. Deve suportar a criação de enlaces de bridge entre 02 (dois) Access Points.
7.24. Deve permitir a configuração individual para cada SSID, se o tráfego for tunelado até a Controladora ao qual ele está registrado e/ou se for comutado localmente.
7.25. Deve suportar associação dinâmica de usuários a VLANs de acordo com parâmetros de autenticação.
7.26. Em conjunto com o controlador wireless, deve implementar recursos de análise de espectro que possibilitem a identificação de interferências provenientes de equipamentos não-WiFi e que operem nas frequências de 2.4GHz ou 5GHz;
7.27. Deve possuir funcionalidade de ajuste de potência automática, de forma a reduzir interferência entre canais.
7.28. Deve implementar UL (uplink) MU-MIMO 802.11ax mode.
7.29. Deve implementar Spectrum Analyzer.
7.30. Deve implementar Spatial Reuse (BSS Coloring).
7.31. Deve suportar recurso de Target Wake Time (TWT) configurado por SSID;
7.32. Deve suportar consultas diretamente ao ponto de acesso via SNMP e REST API;
7.33. Deve possuir certificação WiFi Alliance.
7.34. Deve possuir homologação da ANATEL, de acordo com a Resolução número 242.
7.35. Deve ser compatível e gerenciado pelos ITENS 01, 02, 03 e 04 “SOLUÇÃO DE SEGURANÇA CIBERNÉTICA DISTRIBUÍDA NGFW TIPO I, II, III e IV” , caso compatível poderão ser utilizadas atuais controladoras WiFi existentes na SEMIT, Marca Fortinet, Modelos FG1800F/FG1100E/ FG200F/ FG100F, e ou por solução do mesmo fabricante que possua gerência centralizada, devendo atender aos requisitos descritos abaixo:
7.35.1. Deverá ser capaz de gerenciar, de forma centralizada, outros Pontos de Acesso do mesmo fabricante;
7.35.2. Deverá suportar o serviço de servidor DHCP por SSID para prover endereçamento IP automático para os clientes wireless;
7.35.3. Deverá suportar monitoração e supressão de Ponto de Acesso indevido;
7.35.4. Deverá prover autenticação para a rede wireless através de bases externas, como: LDAP, RADIUS ou TACACS+;
7.35.5. Deverá permitir a visualização dos clientes conectados;
7.35.6. Deverá prover suporte a Fast Roaming;
7.35.7. Deverá ajustar automaticamente os canais de modo a otimizar a cobertura de rede e mudar as condições de RF;
7.35.8. A solução deve implementar recursos de análise de espectro que possibilitem a identificação de interferências provenientes de equipamentos não-WiFi e que operem nas frequências de 2.4GHz ou 5GHz. A solução deve ainda apresentar o resultado dessas análises de maneira gráfica na interface de gerência;
7.35.9. Deverá possuir Captive Portal por SSID;
7.35.10. Deverá permitir configurar o bloqueio de tráfego entre SSIDs;
7.35.11. Deverá possuir método de descoberta de novos Pontos de Acesso baseados em Broadcast ou Multicast;
7.35.12. Deverá possuir lista contendo Pontos de Acesso Aceitos e Pontos de Acesso Indevidos (Rogue);
7.35.13. Deverá possuir controle baseado em política de firewall para acesso entre as WLANs cujo tráfego seja tunelado até a Controladora;;
7.35.14. Deverá permitir a criação de políticas de traffic shaping entre todas as redes cujo tráfego seja tunelado até a Controladora;
7.35.15. Deverá permitir a criação de políticas de firewall baseadas em horário;
7.35.16. Deverá permitir NAT nas políticas de firewall;
7.35.17. Deverá possibilitar definir número de clientes por SSID;
7.35.18. Deverá permitir e/ou bloquear o tráfego entre SSIDs;
7.35.19. Deverá possuir mecanismo de criação automática de usuários visitantes e senhas autogeradas e/ou manual, que possam ser enviadas por e-mail ou SMS aos usuários, e com capacidade de definição de horário da expiração da senha;
7.35.20. A comunicação entre o Access Point e a Controladora Wireless deverá poder ser efetuada de forma criptografada;
7.35.21. Deverá possuir mecanismo de ajuste de potência do sinal, de forma a reduzir interferência entre canais entre 02 (dois) Access Points gerenciados;
7.35.22. Deverá possuir mecanismo de balanceamento de tráfego/usuários entre Access Points;
7.35.23. Deve possuir mecanismo de balanceamento de tráfego/usuários entre frequências e/ou rádios;
7.35.24. Toda a configuração do Ponto de Acesso deverá ser executada através da Controladora Wireless;
7.35.25. Deverá permitir a identificação de APs com firmware desatualizado e efetuar o upgrade via interface gráfica;
7.35.26. Deverá possuir console de monitoramento dos usuários conectados, indicando em que Access Point, em que rádio, em que canal, endereço IP do usuário, tipo de dispositivo e sistema operacional, uso de banda, potência do sinal e relação sinal/ruído;
7.35.27. Deverá permitir aplicar políticas de IPS, bloqueando e/ou monitorando tentativas de ataques, com base de assinatura de ataques atualizada automaticamente, entre todas as redes cujo tráfego seja tunelado até a Controladora;
7.35.28. Deve suportar Wi-Fi Protected Access (WPA), WPA2 ou WPA3 por SSID, utilizando-se de AES e/ou TKIP;
7.35.29. Deve suportar os seguintes métodos de autenticação EAP:
7.35.29.1. EAP-TLS , EAP-TTLS, EAP-PEAP, EAP-SIM, EAP-AKA;
7.35.30. Deve suportar 802.1x através de RADIUS;
7.35.31. Deve suportar filtro baseado em endereço MAC por SSID;
7.35.32. Deve permitir configurar parâmetros de rádio, como: banda e canal;
7.35.33. Deve possuir método de descoberta de novos Pontos de Acesso baseados em Broadcast ou Multicast;
7.35.34. Deve possuir mecanismo de identificação e controle de Rogue APs, suportando supressão automática e bloqueio por endereço MAC de APs;
7.35.35. Deve possuir lista contendo Pontos de Acesso Aceitos e Pontos de Acesso Indevidos (Rogue);
7.35.36. Deve possuir WIDS com, ao menos, os seguintes perfis:
7.35.36.1. Rogue/Interfering AP Detection;
7.35.36.2. Ad-hoc Network Detection;
7.35.36.3. Wireless Bridge Detection;
7.35.36.4. Weak WEP Detection;
7.35.36.5. MAC OUI Checking;
7.35.37. A solução deve detectar Receiver Start of Packet (RX-SOP) em pacotes wireless e ser capaz de ignorar os pacotes que estejam abaixo de determinado limiar especificado em dBm;
7.35.38. O encaminhamento de tráfego dos dispositivos conectados à rede sem fio deve ocorrer de forma centralizada através de túnel estabelecido entre o ponto de acesso e controlador wireless. Neste modo todos os pacotes trafegados em um determinado SSID devem ser encaminhados dentro do túnel até o controlador wireless. Caso o controlador wireless não seja capaz de operar gerenciando os pontos de acesso e concentrando o tráfego tunelado simultaneamente, então a solução ofertada deve ser composta com elemento adicional do próprio fabricante para suportar a conexão dos túneis originados dos pontos de acesso;
8. ITEM 07 - ATIVO DE REDE WIRED TIPO “I”
8.1. Deve possuir garantia e suporte do fabricante pelo período de 36 (trinta e seis) meses
8.2. A Equipamento do tipo comutador de rede ethernet com capacidade de operação em camada 2 do modelo OSI;
8.3. A deve possuir 24 (vinte e quatro) interfaces do tipo 1000Base-T para conexão de cabos de par metálico UTP com conector RJ-45. deve implementar a auto-negociação de velocidade e duplex destas interfaces, além de negociar automaticamente a conexão de cabos crossover (MDI/MDI-X);
8.4. Adicionalmente, deve possuir 04 (quatro) slots SFP+ para conexão de fibras ópticas operando em 10GbE. Estas interfaces não devem ser do tipo combo e devem operar simultaneamente em conjunto com as interfaces do item anterior;
8.5. Deve possuir porta console para acesso à interface de linha de comando (CLI) do equipamento através de conexão serial;
8.6. Deve possuir capacidade de comutação de pelo menos 125 Gbps e ser capaz de encaminhar até 180 Mpps (milhões de pacotes por segundo);
8.7. Deve suportar 4000 (quatro mil) VLANs de acordo com o padrão IEEE 802.1Q;
8.8. Deve possuir tabela MAC com suporte a 30.000 endereços;
8.9. Deve implementar Flow Control baseado no padrão IEEE 802.3X;
8.10. Deve permitir a configuração de links agrupados virtualmente (link aggregation) de acordo com o padrão IEEE 802.3ad (Link Aggregation Control Protocol – LACP);
8.11. Deve suportar a comutação de Jumbo Frames;
8.12. Deve identificar automaticamente telefones IP que estejam conectados e associá-los automaticamente a VLAN de voz;
8.13. Deve suportar a criação de rotas estáticas em IPv4 e IPv6;
8.14. Deve implementar serviço de DHCP Relay;
8.15. Deve suportar IGMP snooping para controle de tráfego de multicast, permitindo a criação de pelo menos 500 (quinhentos) entradas na tabela;
8.16. Deve permitir o espelhamento do tráfego de uma porta para outra porta do mesmo switch (port mirroring);
8.17. Deve implementar Spanning Tree conforme os padrões IEEE 802.1w (Rapid Spanning Tree) e IEEE 802.1s (Multiple Spanning Tree).
8.18. Deve implementar pelo menos 15 (quinze) instâncias de Multiple Spanning Tree;
8.19. Deve implementar recurso conhecido como PortFast ou Edge Port para que uma porta de acesso seja colocada imediatamente no status "Forwarding" do Spanning Tree após sua conexão física;
8.20. Deve implementar mecanismo de proteção da “root bridge” do algoritmo Spanning-Tree para prover defesa contra ataques do tipo “Denial of Service” no ambiente nível 2;
8.21. Deve permitir a suspensão de recebimento de BPDUs (Bridge Protocol Data Units) caso a porta esteja colocada no modo “fast forwarding” (conforme previsto no padrão IEEE 802.1w). Sendo recebido um BPDU neste tipo de porta deve ser possível desabilitá-la automaticamente;
8.22. Deve possuir mecanismo conhecido como Loop Guard para identificação de loops na rede. deve desativar a interface e gerar um evento quando um loop for identificado;
8.23. Deve possuir mecanismo para identificar interfaces em constantes mudanças de status de operação (flapping) que podem ocasionar instabilidade na rede. O switch deverá desativar a interface automaticamente caso o número de variações de status esteja acima do limite configurado para o período estabelecido em segundos;
8.24. Deverá possuir controle de broadcast, multicast e unicast nas portas do switch. Quando o limite for excedido, o switch deve descartar os pacotes ou aplicar rate limit;
8.25. Deve suportar a criação de listas de acesso (ACLs) para filtragem de tráfego. Estas devem estar baseadas nos seguintes parâmetros para classificação do tráfego: endereço IP de origem e destino, endereço MAC de origem e destino, campo CoS e VLAN ID;
8.26. Deve suportar a definição de dias e horários que a ACL deverá ser aplicada na rede;
8.27. Deverá implementar priorização de tráfego baseada nos valores de classe de serviço do frame ethernet (IEEE 802.1p CoS);
8.28. Deve possuir ao menos 8 (oito) filas de priorização (QoS) por porta;
8.29. Deverá implementar mecanismo de proteção contra ataques do tipo man-in-the-middle que utilizam o protocolo ARP;
8.30. Deve implementar DHCP Snooping para mitigar problemas com servidores DHCP que não estejam autorizados na rede;
8.31. Deve implementar controle de acesso por porta através do padrão IEEE 802.1X com assinalamento dinâmico de VLAN por usuário com base em atributos recebidos através do protocolo RADIUS;
8.32. Deve suportar a autenticação IEEE 802.1X de múltiplos dispositivos em cada por porta do switch. Apenas o tráfego dos dispositivos autenticados é que devem ser comutados na porta;
8.33. Deve suportar a autenticação simultânea de, no mínimo, 15 (quinze) dispositivos em cada porta através do protocolo IEEE 802.1X;
8.34. Deve suportar MAC Authentication Bypass (MAB);
8.35. Deve implementar RADIUS CoA (Change of Authorization);
8.36. Deve possuir recurso para monitorar a disponibilidade dos servidores RADIUS;
8.37. Em caso de indisponibilidade dos servidores RADIUS, o switch deve provisionar automaticamente uma VLAN para os dispositivos conectados nas interfaces que estejam com 802.1X habilitado de forma a não causar indisponibilidade da rede;
8.38. Deve implementar Guest VLAN para aqueles usuários que não autenticaram nas interfaces em que o IEEE 802.1X estiver habilitado;
8.39. Deve ser capaz de operar em modo de monitoramento para autenticações 802.1X. Desta forma, o switch deve permitir que sejam realizados testes de autenticação nas portas sem tomar ações tal como reconfigurar a interface;
8.40. Deve ser capaz de autenticar um computador via 802.1X mesmo que este esteja conectado através de uma interface do telefone IP;
8.41. Deve suportar RADIUS Authentication e RADIUS Accounting através de IPv6;
8.42. Deve permitir configurar o número máximo de endereços MAC que podem ser aprendidos em uma determinada porta. Caso o número máximo seja excedido, o switch deverá gerar um log de evento para notificar o problema;
8.43. Deve permitir a customização do tempo em segundos em que um determinado MAC Address aprendido dinamicamente ficará armazenado na tabela de endereços MAC (MAC Table);
8.44. Deve ser capaz de gerar log de eventos quando um novo endereço MAC Address for aprendido dinamicamente nas interfaces, quando o MAC Address mover entre interfaces do mesmo switch e quando o MAC Address for removido da interface;
8.45. Deve suportar o protocolo NTP (Network Time Protocol) ou SNTP (Simple Network Time Protocol) para a sincronização do relógio;
8.46. Deve suportar o envio de mensagens de log para servidores externos através de syslog;
8.47. Deve suportar o protocolo SNMP (Simple Network Management Protocol) nas versões v1, v2c e v3;
8.48. deve suportar o protocolo SSH em IPv4 e IPv6 para configuração e administração remota através de CLI (Command Line Interface);
8.49. Deve suportar o protocolo HTTPS para configuração e administração remota através de interface web;
8.50. Deve permitir upload de arquivo e atualização do firmware (software) do switch através da interface web (HTTPS);
8.51. Deve permitir ser gerenciado através de IPv6;
8.52. Deve permitir a criação de perfis de usuários administrativos com diferentes níveis de permissões para administração e configuração do switch;
8.53. Deve suportar autenticação via RADIUS e TACACS+ para controle do acesso administrativo ao equipamento;
8.54. Deverá possuir mecanismo para identificar conflitos de endereços IP na rede. Caso um conflito seja identificado, o switch deverá gerar um log de evento e enviar um SNMP Trap;
8.55. Deve suportar o protocolo LLDP e LLDP-MED para descoberta automática de equipamentos na rede de acordo com o padrão IEEE 802.1ab;
8.56. Deverá ser capaz de executar testes nas interfaces para identificar problemas físicos nos cabos de par trançado (UTP) conectados ao switch;
8.57. Deverá suportar ser configurado e monitorado através de REST API;
8.58. Deve em conjunto com a controladora ser capaz de implementar e orquestrar políticas de segurança de micro segmentação nos switches controlando como os usuários/endpoints se comunicam lateralmente entre si.
8.59. Deve em conjunto com a controladora permitir a criação de automações que executem ações baseado em eventos de rede detectados no ambiente, como quarentenar um dispositivo, isolar um endpoint, implementar e/ou ajustar políticas de segurança dependendo do evento detectado, de forma automatizada.
8.60. Deve suportar temperatura de operação de até 40º Celsius;
8.61. Deve possuir MTBF (Mean Time Between Failures) igual ou superior a 10 (dez) anos;
8.62. Deve ser fornecido com fonte de alimentação interna com capacidade para operar em tensões de 110V e 220V;
8.63. Deve ser compatível e gerenciado pelos ITENS 01, 02, 03 e 04 “SOLUÇÃO DE SEGURANÇA CIBERNÉTICA DISTRIBUÍDA NGFW TIPO I, II, III e IV” , caso compatível poderão ser utilizadas atuais controladoras existentes na SEMIT, Marca Fortinet, Modelos FG1800F/FG1100E/ FG200F/ FG100F, e ou por solução do mesmo fabricante que possua gerência centralizada, devendo atender aos requisitos descritos abaixo:
8.63.1. A solução de gerência centralizada deve suportar operação com elementos redundantes, não havendo disrupção do serviço mediante a falha de um elemento;
8.63.2. Deve operar como ponto central para automação e gerenciamento dos switches;
8.63.3. Deve realizar o gerenciamento de inventário de hardware, software e configuração dos Switches;
8.63.4. Deve possuir interface gráfica para configuração, administração e monitoração dos switches;
8.63.5. Deve apresentar graficamente a topologia da rede com todos os switches administrados para monitoramento, além de ilustrar graficamente status dos uplinks e dos equipamentos para identificação de eventuais problemas na rede;
8.63.6. Deve montar a topologia da rede de maneira automática;
8.63.7. Deve ser capaz de configurar os switches da rede;
8.63.8. Deve através da interface gráfica deve ser capaz de configurar as VLANs da rede e distribui-las automaticamente em todos os switches gerenciados;
8.63.9. Deve através da interface gráfica deve ser capaz de aplicar a VLAN nativa (untagged) e as VLANs permitidas (tagged) nas interfaces dos switches;
8.63.10. Deve através da interface gráfica deve ser capaz de aplicar as políticas de QoS nas interfaces dos switches;
8.63.11. Deve através da interface gráfica deve ser capaz de aplicar as políticas de segurança para autenticação 802.1X nas interfaces dos switches;
8.63.12. Através da interface gráfica deve ser capaz de aplicar ferramentas de segurança, tal como DHCP Snooping, nas interfaces dos switches;
8.63.13. Deve através da interface gráfica deve ser capaz de realizar configurações do protocolo Spanning Tree nas interfaces dos switches, tal como habilitar ou desabilitar os seguintes recursos: Loop Guard, Root Guard e BPDU Guard;
8.63.14. Deve através da interface gráfica deve ser capaz de aplicar políticas de segurança e controle de tráfego para filtrar o tráfego da rede;
8.63.15. A solução de gerência centralizada deve ser capaz de identificar as aplicações acessadas na rede através de análise DPI (Deep Packet Inspection);
8.63.16. Deve ser capaz de configurar parâmetros SNMP dos switches;
8.63.17. A solução de gerência centralizada deve gerenciar as atualizações de firmware (software) dos switches gerenciados, recomendando versões de software para cada switch, além de permitir a atualização dos switches individualmente;
8.63.18. A solução de gerência centralizada deve permitir o envio automático de e-mails de notificação para os administradores da rede em caso de eventos de falhas;
8.63.19. A solução de gerência centralizada deve apresentar graficamente informações sobre erros nas interfaces dos switches;
8.63.20. A solução deve apresentar graficamente informações sobre disponibilidade dos switches;
8.63.21. Deve prover indicadores de saúde dos elementos críticos do ambiente;
8.63.22. Deve registrar eventos para auditoria de todos os acessos e mudanças de configuração realizadas por usuários;
8.63.23. Deve realizar as funções de gerenciamento de falhas e eventos dos switches da rede;
8.63.24. Deve possuir API no formato REST;
9. ITEM 08 - ATIVO DE REDE WIRED TIPO “II”
9.1. Deve possuir garantia e suporte do fabricante pelo período de 36 (trinta e seis) meses
9.2. A CONTRATADA deve realizar a instalação inicial do equipamento que está restrita a entrega do equipamento, conferência de itens e teste inicial de funcionamento.
9.3. A Equipamento do tipo comutador de rede ethernet com capacidade de operação em camada 2 do modelo OSI;
9.4. A deve possuir 48 (quarenta e oito) interfaces do tipo 1000Base-T para conexão de cabos de par metálico UTP com conector RJ-45. deve implementar a auto-negociação de velocidade e duplex destas interfaces, além de negociar automaticamente a conexão de cabos crossover (MDI/MDI-X);
9.5. Adicionalmente, deve possuir 04 (quatro) slots SFP+ para conexão de fibras ópticas operando em 10GbE. Estas interfaces não devem ser do tipo combo e devem operar simultaneamente em conjunto com as interfaces do item anterior;
9.6. Deve possuir porta console para acesso à interface de linha de comando (CLI) do equipamento através de conexão serial;
9.7. Deve possuir capacidade de comutação de pelo menos 170 Gbps e ser capaz de encaminhar até 250 Mpps (milhões de pacotes por segundo);
9.8. Deve suportar 4000 (quatro mil) VLANs de acordo com o padrão IEEE 802.1Q;
9.9. Deve possuir tabela MAC com suporte a 30.000 endereços;
9.10. Deve implementar Flow Control baseado no padrão IEEE 802.3X;
9.11. Deve permitir a configuração de links agrupados virtualmente (link aggregation) de acordo com o padrão IEEE 802.3ad (Link Aggregation Control Protocol – LACP);
9.12. Deve suportar a comutação de Jumbo Frames;
9.13. Deve identificar automaticamente telefones IP que estejam conectados e associá-los automaticamente a VLAN de voz;
9.14. Deve suportar a criação de rotas estáticas em IPv4 e IPv6;
9.15. Deve implementar serviço de DHCP Relay;
9.16. Deve suportar IGMP snooping para controle de tráfego de multicast, permitindo a criação de pelo menos 500 (quinhentos) entradas na tabela;
9.17. Deve permitir o espelhamento do tráfego de uma porta para outra porta do mesmo switch (port mirroring);
9.18. Deve implementar Spanning Tree conforme os padrões IEEE 802.1w (Rapid Spanning Tree) e IEEE 802.1s (Multiple Spanning Tree).
9.19. Deve implementar pelo menos 15 (quinze) instâncias de Multiple Spanning Tree;
9.20. Deve implementar recurso conhecido como PortFast ou Edge Port para que uma porta de acesso seja colocada imediatamente no status "Forwarding" do Spanning Tree após sua conexão física;
9.21. Deve implementar mecanismo de proteção da “root bridge” do algoritmo Spanning-Tree para prover defesa contra ataques do tipo “Denial of Service” no ambiente nível 2;
9.22. Deve permitir a suspensão de recebimento de BPDUs (Bridge Protocol Data Units) caso a porta esteja colocada no modo “fast forwarding” (conforme previsto no padrão IEEE 802.1w). Sendo recebido um BPDU neste tipo de porta deve ser possível desabilitá-la automaticamente;
9.23. Deve possuir mecanismo conhecido como Loop Guard para identificação de loops na rede. deve desativar a interface e gerar um evento quando um loop for identificado;
9.24. Deve possuir mecanismo para identificar interfaces em constantes mudanças de status de operação (flapping) que podem ocasionar instabilidade na rede. O switch deverá desativar a interface automaticamente caso o número de variações de status esteja acima do limite configurado para o período estabelecido em segundos;
9.25. Deverá possuir controle de broadcast, multicast e unicast nas portas do switch. Quando o limite for excedido, o switch deve descartar os pacotes ou aplicar rate limit;
9.26. Deve suportar a criação de listas de acesso (ACLs) para filtragem de tráfego. Estas devem estar baseadas nos seguintes parâmetros para classificação do tráfego: endereço IP de origem e destino, endereço MAC de origem e destino, campo CoS e VLAN ID;
9.27. Deve suportar a definição de dias e horários que a ACL deverá ser aplicada na rede;
9.28. Deverá implementar priorização de tráfego baseada nos valores de classe de serviço do frame ethernet (IEEE 802.1p CoS);
9.29. Deve possuir ao menos 8 (oito) filas de priorização (QoS) por porta;
9.30. Deverá implementar mecanismo de proteção contra ataques do tipo man-in-the-middle que utilizam o protocolo ARP;
9.31. Deve implementar DHCP Snooping para mitigar problemas com servidores DHCP que não estejam autorizados na rede;
9.32. Deve implementar controle de acesso por porta através do padrão IEEE 802.1X com assinalamento dinâmico de VLAN por usuário com base em atributos recebidos através do protocolo RADIUS;
9.33. Deve suportar a autenticação IEEE 802.1X de múltiplos dispositivos em cada por porta do switch. Apenas o tráfego dos dispositivos autenticados é que devem ser comutados na porta;
9.34. Deve suportar a autenticação simultânea de, no mínimo, 15 (quinze) dispositivos em cada porta através do protocolo IEEE 802.1X;
9.35. Deve suportar MAC Authentication Bypass (MAB);
9.36. Deve implementar RADIUS CoA (Change of Authorization);
9.37. Deve possuir recurso para monitorar a disponibilidade dos servidores RADIUS;
9.38. Em caso de indisponibilidade dos servidores RADIUS, o switch deve provisionar automaticamente uma VLAN para os dispositivos conectados nas interfaces que estejam com 802.1X habilitado de forma a não causar indisponibilidade da rede;
9.39. Deve implementar Guest VLAN para aqueles usuários que não autenticaram nas interfaces em que o IEEE 802.1X estiver habilitado;
9.40. Deve ser capaz de operar em modo de monitoramento para autenticações 802.1X. Desta forma, o switch deve permitir que sejam realizados testes de autenticação nas portas sem tomar ações tal
como reconfigurar a interface;
9.41. Deve ser capaz de autenticar um computador via 802.1X mesmo que este esteja conectado através de uma interface do telefone IP;
9.42. Deve suportar RADIUS Authentication e RADIUS Accounting através de IPv6;
9.43. Deve permitir configurar o número máximo de endereços MAC que podem ser aprendidos em uma determinada porta. Caso o número máximo seja excedido, o switch deverá gerar um log de evento para notificar o problema;
9.44. Deve permitir a customização do tempo em segundos em que um determinado MAC Address aprendido dinamicamente ficará armazenado na tabela de endereços MAC (MAC Table);
9.45. Deve ser capaz de gerar log de eventos quando um novo endereço MAC Address for aprendido dinamicamente nas interfaces, quando o MAC Address mover entre interfaces do mesmo switch e quando o MAC Address for removido da interface;
9.46. Deve suportar o protocolo NTP (Network Time Protocol) ou SNTP (Simple Network Time Protocol) para a sincronização do relógio;
9.47. Deve suportar o envio de mensagens de log para servidores externos através de syslog;
9.48. Deve suportar o protocolo SNMP (Simple Network Management Protocol) nas versões v1, v2c e v3;
9.49. deve suportar o protocolo SSH em IPv4 e IPv6 para configuração e administração remota através de CLI (Command Line Interface);
9.50. Deve suportar o protocolo HTTPS para configuração e administração remota através de interface web;
9.51. Deve permitir upload de arquivo e atualização do firmware (software) do switch através da interface web (HTTPS);
9.52. Deve permitir ser gerenciado através de IPv6;
9.53. Deve permitir a criação de perfis de usuários administrativos com diferentes níveis de permissões para administração e configuração do switch;
9.54. Deve suportar autenticação via RADIUS e TACACS+ para controle do acesso administrativo ao equipamento;
9.55. Deverá possuir mecanismo para identificar conflitos de endereços IP na rede. Caso um conflito seja identificado, o switch deverá gerar um log de evento e enviar um SNMP Trap;
9.56. Deve suportar o protocolo LLDP e LLDP-MED para descoberta automática de equipamentos na rede de acordo com o padrão IEEE 802.1ab;
9.57. Deverá ser capaz de executar testes nas interfaces para identificar problemas físicos nos cabos de par trançado (UTP) conectados ao switch;
9.58. Deverá suportar ser configurado e monitorado através de REST API;
9.59. Deve em conjunto com a controladora ser capaz de implementar e orquestrar políticas de segurança de micro segmentação nos switches controlando como os usuários/endpoints se comunicam lateralmente entre si.
9.60. Deve em conjunto com a controladora permitir a criação de automações que executem ações baseado em eventos de rede detectados no ambiente, como quarentenar um dispositivo, isolar um endpoint, implementar e/ou ajustar políticas de segurança dependendo do evento detectado, de forma automatizada.
9.61. Deve suportar temperatura de operação de até 40º Celsius;
9.62. Deve possuir MTBF (Mean Time Between Failures) igual ou superior a 10 (dez) anos;
9.63. Deve ser fornecido com fonte de alimentação interna com capacidade para operar em tensões de 110V e 220V;
9.64. Deve ser compatível e gerenciado pelos ITENS 01, 02, 03 e 04 “SOLUÇÃO DE SEGURANÇA CIBERNÉTICA DISTRIBUÍDA NGFW TIPO I, II, III e IV” , caso compatível poderão ser utilizadas atuais controladoras existentes na SEMIT, Marca Fortinet, Modelos FG1800F/FG1100E/ FG200F/ FG100F, e ou por solução do mesmo fabricante que possua gerência centralizada, devendo atender aos requisitos descritos abaixo:
9.64.1. A solução de gerência centralizada deve suportar operação com elementos redundantes, não havendo disrupção do serviço mediante a falha de um elemento;
9.64.2. Deve operar como ponto central para automação e gerenciamento dos switches;
9.64.3. Deve realizar o gerenciamento de inventário de hardware, software e configuração dos Switches;
9.64.4. Deve possuir interface gráfica para configuração, administração e monitoração dos switches;
9.64.5. Deve apresentar graficamente a topologia da rede com todos os switches administrados para monitoramento, além de ilustrar graficamente status dos uplinks e dos equipamentos para identificação de eventuais problemas na rede;
9.64.6. Deve montar a topologia da rede de maneira automática;
9.64.7. Deve ser capaz de configurar os switches da rede;
9.64.8. Deve através da interface gráfica deve ser capaz de configurar as VLANs da rede e distribui-las automaticamente em todos os switches gerenciados;
9.64.9. Deve através da interface gráfica deve ser capaz de aplicar a VLAN nativa (untagged) e as VLANs permitidas (tagged) nas interfaces dos switches;
9.64.10. Deve através da interface gráfica deve ser capaz de aplicar as políticas de QoS nas interfaces dos switches;
9.64.11. Deve através da interface gráfica deve ser capaz de aplicar as políticas de segurança para autenticação 802.1X nas interfaces dos switches;
9.64.12. Através da interface gráfica deve ser capaz de aplicar ferramentas de segurança, tal como DHCP Snooping, nas interfaces dos switches;
9.64.13. Deve através da interface gráfica deve ser capaz de realizar configurações do protocolo Spanning Tree nas interfaces dos switches, tal como habilitar ou desabilitar os seguintes recursos: Loop Guard, Root Guard e BPDU Guard;
9.64.14. Deve através da interface gráfica deve ser capaz de aplicar políticas de segurança e controle de tráfego para filtrar o tráfego da rede;
9.64.15. A solução de gerência centralizada deve ser capaz de identificar as aplicações acessadas na rede através de análise DPI (Deep Packet Inspection);
9.64.16. Deve ser capaz de configurar parâmetros SNMP dos switches;
9.64.17. A solução de gerência centralizada deve gerenciar as atualizações de firmware (software) dos switches gerenciados, recomendando versões de software para cada switch, além de permitir a atualização dos switches individualmente;
9.64.18. A solução de gerência centralizada deve permitir o envio automático de e-mails de notificação para os administradores da rede em caso de eventos de falhas;
9.64.19. A solução de gerência centralizada deve apresentar graficamente informações sobre erros nas interfaces dos switches;
9.64.20. A solução deve apresentar graficamente informações sobre disponibilidade dos switches;
9.64.21. Deve prover indicadores de saúde dos elementos críticos do ambiente;
9.64.22. Deve registrar eventos para auditoria de todos os acessos e mudanças de configuração realizadas por usuários;
9.64.23. Deve realizar as funções de gerenciamento de falhas e eventos dos switches da rede;
9.64.24. Deve possuir API no formato REST;
10. ITEM 09 - ATIVO DE REDE WIRED TIPO “III”
10.1. Deve possuir garantia e suporte do fabricante pelo período de 36 (trinta e seis) meses
10.2. A CONTRATADA deve realizar a instalação inicial do equipamento que está restrita a entrega do equipamento, conferência de itens e teste inicial de funcionamento.
10.3. Deve possuir 24 (vinte e quatro) slots SFP para conexão de fibras ópticas do tipo 1000Base-X operando em 1GbE;
10.4. Adicionalmente, deve possuir 4 (quatro) slots SFP+ para conexão de fibras ópticas do tipo 10GBase- X operando em 1GbE e 10GbE. Estas interfaces não devem ser do tipo combo e devem operar simultaneamente em conjunto com as interfaces do item anterior;
10.5. Deve possuir porta console para acesso à interface de linha de comando (CLI) do equipamento através de conexão serial.
10.6. Deve possuir 1 (uma) interface USB;
10.7. Deve possuir capacidade de comutação de pelo menos 125 Gbps e ser capaz de encaminhar até 200 Mpps (milhões de pacotes por segundo);
10.8. Deve suportar 4000 (quatro mil) VLANs de acordo com o padrão IEEE 802.1Q;
10.9. Deve possuir tabela MAC com suporte a 32.000 endereços;
10.10. Deve operar com latência igual ou inferior à 1us (microsegundo);
10.11. Deve implementar Flow Control baseado no padrão IEEE 802.3X;
10.12. Em conjunto com o Flow Control (IEEE 802.3x) o switch deverá, ao invés de enviar pause frames, definir um limite de banda que poderá ser recebida na interface quando o buffer estiver cheio. O switch deverá medir o volume de utilização do buffer para que o recebimento seja restaurado à capacidade máxima automaticamente;
10.13. Deve permitir a configuração de links agrupados virtualmente (link aggregation) de acordo com o padrão IEEE 802.3ad (Link Aggregation Control Protocol – LACP);
10.14. Deve suportar Multi-Chassis Link Agregation (MCLAG) ou mecanismo similar para agrupar suas interfaces com interfaces de outro switch de mesmo modelo de tal forma que equipamentos terceiros reconheçam as interfaces de ambos switches como uma única interface lógica;
10.15. Deve suportar a comutação de Jumbo Frames;
10.16. Deve identificar automaticamente telefones IP que estejam conectados e associá-los automaticamente a VLAN de voz;
10.17. Deve implementar roteamento (camada 3 do modelo OSI) entre as VLANs;
10.18. Deve suportar a criação de rotas estáticas em IPv4 e IPv6;
10.19. Deve possuir hardware capaz de suportar roteamento dinâmico através dos protocolos RIPv1, RIPv2, OSPF em IPv4 e OSPF em IPv6. É facultada a entrega de licenças caso o software exiga licenciamento adicional para ativação dos protocolos;
10.20. Deve possuir hardware capaz de suportar o protocolo VRRP ou mecanismo similar de redundância de gateway. É facultada a entrega de licenças caso o software exiga licenciamento adicional para ativação do protocolo;
10.21. Deverá suportar Bidirectional Forwarding Detection (BFD). É facultada a entrega de licenças caso o software exiga licenciamento adicional para ativação do protocolo;
10.22. Deve implementar serviço de DHCP Server e DHCP Relay;
10.23. Deve suportar IGMP snooping para controle de tráfego de multicast, permitindo a criação de pelo menos 1000 (mil) grupos;
10.24. Deve permitir o espelhamento do tráfego de uma porta para outra porta do mesmo switch e outro switch da rede (port mirroring / SPAN);
10.25. Deve permitir o espelhamento de uma porta ou de um grupo de portas para uma porta especificada em outro equipamento através de RSPAN e ERSPAN;
10.26. Deve implementar Spanning Tree conforme os padrões IEEE 802.1w (Rapid Spanning Tree) e IEEE 802.1s (Multiple Spanning Tree). deve implementar pelo menos 15 (quinze) instâncias de Multiple Spanning Tree;
10.27. Deve implementar recurso conhecido como PortFast ou Edge Port para que uma porta de acesso seja colocada imediatamente no status "Forwarding" do Spanning Tree após sua conexão física;
10.28. Deve implementar mecanismo de proteção da “root bridge” do algoritmo Spanning-Tree para prover defesa contra-ataques do tipo “Denial of Service” no ambiente nível 2;
10.29. Deve permitir a suspensão de recebimento de BPDUs (Bridge Protocol Data Units) caso a porta esteja colocada no modo “fast forwarding” (conforme previsto no padrão IEEE 802.1w). Sendo recebido um BPDU neste tipo de porta deve ser possível desabilitá-la automaticamente;
10.30. Deve possuir mecanismo conhecido como Loop Guard para identificação de loops na rede. deve desativar a interface e gerar um evento quando um loop for identificado;
10.31. Deve possuir mecanismo para identificar interfaces em constantes mudanças de status de operação (flapping) que podem ocasionar instabilidade na rede. O switch deverá desativar a interface automaticamente caso o número de variações de status esteja acima do limite configurado para o período estabelecido em segundos;
10.32. Deverá possuir controle de broadcast, multicast e unicast nas portas do switch. Quando o limite for excedido, o switch deve descartar os pacotes ou aplicar rate limit;
10.33. Deve suportar a criação de listas de acesso (ACLs) para filtragem de tráfego. Estas devem estar baseadas nos seguintes parâmetros para classificação do tráfego: endereço IP de origem e destino, endereço MAC de origem e destino, portas TCP e UDP, campo DSCP, campo CoS e VLAN ID;
10.34. Deve permitir a definição de dias e horários que a ACL deverá ser aplicada na rede;
10.35. Deverá implementar classificação, marcação e priorização de tráfego baseada nos valores de classe de serviço do frame ethernet (IEEE 802.1p CoS);
10.36. Deverá implementar classificação, marcação e priorização de tráfego baseada nos valores do campo “Differentiated Services Code Point” (DSCP) do cabeçalho IP, conforme definições do IETF;
10.37. Deverá implementar ao menos 1 (um) dos seguintes mecanismos de prevenção contra congestão de tráfego: Weighted Round Robin (WRR), WRED (Weighted Random Early Detection) ou Weighted Fair Queuing (WFQ);
10.38. Deve possuir ao menos 8 (oito) filas de priorização (QoS) por porta;
10.39. Deve suportar o mecanismo Explicit Congestion Notification (ECN) para notificar o emissor que há uma congestão ocorrendo e com isso evitar que os pacotes sejam descartados;
10.40. Deve implementar mecanismo de proteção contra ataques do tipo spoofing para mensagens de IPv6 Router Advertisement;
10.41. Deverá implementar mecanismo de proteção contra ataques do tipo man-in-the-middle que utilizam o protocolo ARP;
10.42. Deve implementar DHCP Snooping em IPv4 e IPv6 para mitigar problemas com servidores DHCP que não estejam autorizados na rede;
10.43. Deve implementar controle de acesso por porta através do padrão IEEE 802.1X com assinalamento dinâmico de VLAN por usuário com base em atributos recebidos através do protocolo RADIUS;
10.44. Deve suportar a autenticação IEEE 802.1X de múltiplos dispositivos em cada por porta do switch. Apenas o tráfego dos dispositivos autenticados é que devem ser comutados na porta;
10.45. Deve suportar a autenticação simultânea de, no mínimo, 15 (quinze) dispositivos em cada porta através do protocolo IEEE 802.1X;
10.46. Deve suportar MAC Authentication Bypass (MAB);
10.47. Deve implementar RADIUS CoA (Change of Authorization);
10.48. Deve possuir recurso para monitorar a disponibilidade dos servidores RADIUS;
10.49. Em caso de indisponibilidade dos servidores RADIUS, o switch deve provisionar automaticamente uma VLAN para os dispositivos conectados nas interfaces que estejam com 802.1X habilitado de forma a não causar indisponibilidade da rede;
10.50. Deve implementar Guest VLAN para aqueles usuários que não autenticaram nas interfaces em que o IEEE 802.1X estiver habilitado;
10.51. Deve ser capaz de operar em modo de monitoramento para autenticações 802.1X. Desta forma, o switch deve permitir que sejam realizados testes de autenticação nas portas sem tomar ações tal como reconfigurar a interface;
10.52. Deve ser capaz de autenticar um computador via 802.1X mesmo que este esteja conectado através de uma interface do telefone IP;
10.53. Deve suportar RADIUS Authentication e RADIUS Accounting através de IPv6;
10.54. Deve permitir configurar o número máximo de endereços MAC que podem ser aprendidos em uma determinada porta. Caso o número máximo seja excedido, o switch deverá gerar um log de evento para notificar o problema;
10.55. Deve permitir a customização do tempo em segundos em que um determinado MAC Address aprendido dinamicamente ficará armazenado na tabela de endereços MAC (MAC Table);
10.56. Deve ser capaz de gerar log de eventos quando um novo endereço MAC Address for aprendido dinamicamente nas interfaces, quando o MAC Address mover entre interfaces do mesmo switch e quando o MAC Address for removido da interface;
10.57. Deve ser capaz de autorizar a transmissão de pacotes nas interfaces somente para aqueles endereços IP que foram aprendidos dinamicamente através de DHCP Snooping. Os pacotes originados por endereços IP desconhecidos deverão ser descartados;
10.58. Deve suportar o protocolo PTP (Precision Time Protocol);
10.59. Deve implementar Netflow, sFlow ou similar;
10.60. Deve suportar o envio de mensagens de log para servidores externos através de syslog;
10.61. Deve suportar o protocolo SNMP (Simple Network Management Protocol) nas versões v1, v2c e v3;
10.62. deve suportar o protocolo SSH em IPv4 e IPv6 para configuração e administração remota através de CLI (Command Line Interface);
10.63. Deve suportar o protocolo HTTPS para configuração e administração remota através de interface web;
10.64. Deve permitir upload de arquivo e atualização do firmware (software) do switch através da interface web (HTTPS);
10.65. Deve permitir ser gerenciado através de IPv6;
10.66. Deve permitir a criação de perfis de usuários administrativos com diferentes níveis de permissões
para administração e configuração do switch;
10.67. Deve suportar autenticação via RADIUS e TACACS+ para controle do acesso administrativo ao equipamento;
10.68. Deverá possuir mecanismo para identificar conflitos de endereços IP na rede. Caso um conflito seja identificado, o switch deverá gerar um log de evento e enviar um SNMP Trap;
10.69. Deve suportar o protocolo LLDP e LLDP-MED para descoberta automática de equipamentos na rede de acordo com o padrão IEEE 802.1ab;
10.70. Deverá suportar ser configurado e monitorado através de REST API;
10.71. Deve em conjunto com a controladora ser capaz de implementar e orquestrar políticas de segurança de micro segmentação nos switches controlando como os usuários/endpoints se comunicam lateralmente entre si.
10.72. Deve em conjunto com a controladora permitir a criação de automações que executem ações baseado em eventos de rede detectados no ambiente, como quarentenar um dispositivo, isolar um endpoint, implementar e/ou ajustar políticas de segurança dependendo do evento detectado, de forma automatizada.
10.73. Deve possuir ferramenta para captura de pacotes que auxíliarão na identificação de problemas na rede. deve permitir a utilização de filtros para selecionar o tráfego que deverá ser capturado e permitir a exportação dos pacotes através de arquivo .pcap para análise em software Wireshark;
10.74. Deve ser capaz de armazenar no mínimo duas versões de firmware simultaneamente em sua memória flash;
10.75. Deve possuir LEDs que indiquem o status de atividade de cada porta, além de indicar se há alguma falha ou alarme no switch;
10.76. Deve suportar temperatura de operação de até 40º Celsius;
10.77. Deve possuir MTBF (Mean Time Between Failures) igual ou superior a 10 (dez) anos;
10.78. Deve ser fornecido com fontes de alimentação redundantes e internas ao equipamento, com capacidade para operar em tensões de 110V e 220V;
10.79. Deve permitir a sua instalação física em rack padrão 19" com altura máxima de 1U. Todos os acessórios para montagem e fixação deverão ser fornecidos;
10.80. Deve ser compatível e gerenciado pelos ITENS 01, 02, 03 e 04 “SOLUÇÃO DE SEGURANÇA CIBERNÉTICA DISTRIBUÍDA NGFW TIPO I, II, III e IV” , caso compatível poderão ser utilizadas atuais controladoras existentes na SEMIT, Marca Fortinet, Modelos FG1800F/FG1100E/ FG200F/ FG100F, e ou por solução do mesmo fabricante que possua gerência centralizada, devendo atender aos requisitos descritos abaixo:
10.80.1. A solução de gerência centralizada deve suportar operação com elementos redundantes, não havendo disrupção do serviço mediante a falha de um elemento;
10.80.2. Deve operar como ponto central para automação e gerenciamento dos switches;
10.80.3. Deve realizar o gerenciamento de inventário de hardware, software e configuração dos Switches;
10.80.4. Deve possuir interface gráfica para configuração, administração e monitoração dos switches;
10.80.5. Deve apresentar graficamente a topologia da rede com todos os switches administrados para monitoramento, além de ilustrar graficamente status dos uplinks e dos equipamentos para identificação de eventuais problemas na rede;
10.80.6. Deve montar a topologia da rede de maneira automática;
10.80.7. Deve ser capaz de configurar os switches da rede;
10.80.8. Deve através da interface gráfica deve ser capaz de configurar as VLANs da rede e distribui-las automaticamente em todos os switches gerenciados;
10.80.9. Deve através da interface gráfica deve ser capaz de aplicar a VLAN nativa (untagged) e as VLANs permitidas (tagged) nas interfaces dos switches;
10.80.10. Deve através da interface gráfica deve ser capaz de aplicar as políticas de QoS nas interfaces dos switches;
10.80.11. Deve através da interface gráfica deve ser capaz de aplicar as políticas de segurança para autenticação 802.1X nas interfaces dos switches;
10.80.12. Deve através da interface gráfica deve ser capaz de habilitar ou desabilitar o PoE nas interfaces dos switches;
10.80.13. Através da interface gráfica deve ser capaz de aplicar ferramentas de segurança, tal como DHCP Snooping, nas interfaces dos switches;
10.80.14. Deve através da interface gráfica deve ser capaz de realizar configurações do protocolo Spanning Tree nas interfaces dos switches, tal como habilitar ou desabilitar os seguintes recursos: Loop Guard, Root Guard e BPDU Guard;
10.80.15. Deve através da interface gráfica deve ser capaz de aplicar políticas de segurança e controle de tráfego para filtrar o tráfego da rede;
10.80.16. A solução de gerência centralizada deve ser capaz de identificar as aplicações acessadas na rede através de análise DPI (Deep Packet Inspection);
10.80.17. Deve ser capaz de configurar parâmetros SNMP dos switches;
10.80.18. A solução de gerência centralizada deve gerenciar as atualizações de firmware (software) dos switches gerenciados, recomendando versões de software para cada switch, além de permitir a atualização dos switches individualmente;
10.80.19. A solução de gerência centralizada deve permitir o envio automático de e-mails de notificação para os administradores da rede em caso de eventos de falhas;
10.80.20. A solução de gerência centralizada deve apresentar graficamente informações sobre erros nas interfaces dos switches;
10.80.21. A solução deve apresentar graficamente informações sobre disponibilidade dos switches;
10.80.22. Deve prover indicadores de saúde dos elementos críticos do ambiente;
10.80.23. Deve registrar eventos para auditoria de todos os acessos e mudanças de configuração realizadas por usuários;
10.80.24. Deve realizar as funções de gerenciamento de falhas e eventos dos switches da rede;
10.80.25. Deve possuir API no formato REST;
11. ITEM 10 - ATIVO DE REDE WIRED TIPO “IV”
11.1. Deve possuir garantia e suporte do fabricante pelo período de 36 (trinta e seis) meses
11.2. Deve possuir 24 (vinte e quatro) slots SFP+ 10GE para conexão de fibras ópticas do operando em 10GbE;
11.3. Adicionalmente, deve possuir 02 (dois) slots QSFP+/QSFP28 para conexão de fibras ópticas operando em 40G/100G. Estas interfaces não devem ser do tipo combo e devem operar simultaneamente em conjunto com as interfaces do item anterior;
11.4. Deve possuir porta console para acesso à interface de linha de comando (CLI) do equipamento através de conexão serial.
11.5. Deve possuir 1 (uma) interface USB;
11.6. Deve possuir capacidade de comutação de pelo menos 850 Gbps e ser capaz de encaminhar até 1300 Mpps (milhões de pacotes por segundo);
11.7. Deve suportar 4000 (quatro mil) VLANs de acordo com o padrão IEEE 802.1Q;
11.8. Deve possuir tabela MAC com suporte a 60.000 endereços;
11.9. Deve operar com latência igual ou inferior à 1us (microsegundo);
11.10. Deve implementar Flow Control baseado no padrão IEEE 802.3X;
11.11. Em conjunto com o Flow Control (IEEE 802.3x) o switch deverá, ao invés de enviar pause frames, definir um limite de banda que poderá ser recebida na interface quando o buffer estiver cheio. O switch deverá medir o volume de utilização do buffer para que o recebimento seja restaurado à capacidade máxima automaticamente;
11.12. Deve permitir a configuração de links agrupados virtualmente (link aggregation) de acordo com o padrão IEEE 802.3ad (Link Aggregation Control Protocol – LACP);
11.13. Deve suportar Multi-Chassis Link Agregation (MCLAG) ou mecanismo similar para agrupar suas interfaces com interfaces de outro switch de mesmo modelo de tal forma que equipamentos terceiros reconheçam as interfaces de ambos switches como uma única interface lógica;
11.14. Deve suportar a comutação de Jumbo Frames;
11.15. Deve identificar automaticamente telefones IP que estejam conectados e associá-los automaticamente a VLAN de voz;
11.16. Deve implementar roteamento (camada 3 do modelo OSI) entre as VLANs;
11.17. Deve suportar a criação de rotas estáticas em IPv4 e IPv6;
11.18. Deve possuir hardware capaz de suportar roteamento dinâmico através dos protocolos RIP, BGP, OSPF em IPv4 e OSPF em IPv6. É facultada a entrega de licenças caso o software exigia licenciamento adicional para ativação dos protocolos;
11.19. Deve possuir hardware capaz de suportar o protocolo VRRP ou mecanismo similar de redundância de gateway. É facultada a entrega de licenças caso o software exiga licenciamento adicional para ativação do protocolo;
11.20. Deve implementar serviço de DHCP Server e DHCP Relay;
11.21. Deve suportar IGMP snooping para controle de tráfego de multicast, permitindo a criação de pelo menos 1000 (mil) grupos;
11.22. Deve permitir o espelhamento do tráfego de uma porta para outra porta do mesmo switch e outro switch da rede (port mirroring / SPAN);
11.23. Deve permitir o espelhamento de uma porta ou de um grupo de portas para uma porta especificada em outro equipamento através de RSPAN e ERSPAN;
11.24. Deve implementar Spanning Tree conforme os padrões IEEE 802.1w (Rapid Spanning Tree) e IEEE 802.1s (Multiple Spanning Tree). deve implementar pelo menos 15 (quinze) instâncias de Multiple Spanning Tree;
11.25. Deve implementar recurso conhecido como PortFast ou Edge Port para que uma porta de acesso seja colocada imediatamente no status "Forwarding" do Spanning Tree após sua conexão física;
11.26. Deve implementar mecanismo de proteção da “root bridge” do algoritmo Spanning-Tree para prover defesa contra-ataques do tipo “Denial of Service” no ambiente nível 2;
11.27. Deve permitir a suspensão de recebimento de BPDUs (Bridge Protocol Data Units) caso a porta esteja colocada no modo “fast forwarding” (conforme previsto no padrão IEEE 802.1w). Sendo recebido um BPDU neste tipo de porta deve ser possível desabilitá-la automaticamente;
11.28. Deve possuir mecanismo conhecido como Loop Guard para identificação de loops na rede. deve desativar a interface e gerar um evento quando um loop for identificado;
11.29. Deve possuir mecanismo para identificar interfaces em constantes mudanças de status de operação (flapping) que podem ocasionar instabilidade na rede. O switch deverá desativar a interface automaticamente caso o número de variações de status esteja acima do limite
configurado para o período estabelecido em segundos;
11.30. Deverá possuir controle de broadcast, multicast e unicast nas portas do switch. Quando o limite for excedido, o switch deve descartar os pacotes ou aplicar rate limit;
11.31. Deve suportar a criação de listas de acesso (ACLs) para filtragem de tráfego. Estas devem estar baseadas nos seguintes parâmetros para classificação do tráfego: endereço IP de origem e destino, endereço MAC de origem e destino, portas TCP e UDP, campo DSCP, campo CoS e VLAN ID;
11.32. Deve permitir a definição de dias e horários que a ACL deverá ser aplicada na rede;
11.33. Deverá implementar classificação, marcação e priorização de tráfego baseada nos valores de classe de serviço do frame ethernet (IEEE 802.1p CoS);
11.34. Deverá implementar classificação, marcação e priorização de tráfego baseada nos valores do campo “Differentiated Services Code Point” (DSCP) do cabeçalho IP, conforme definições do IETF;
11.35. Deverá implementar ao menos 1 (um) dos seguintes mecanismos de prevenção contra congestão de tráfego: Weighted Round Robin (WRR), WRED (Weighted Random Early Detection) ou Weighted Fair Queuing (WFQ);
11.36. Deve possuir ao menos 8 (oito) filas de priorização (QoS) por porta;
11.37. Deve suportar o mecanismo Explicit Congestion Notification (ECN) para notificar o emissor que há uma congestão ocorrendo e com isso evitar que os pacotes sejam descartados;
11.38. Deve implementar mecanismo de proteção contra ataques do tipo spoofing para mensagens de IPv6 Router Advertisement;
11.39. Deverá implementar mecanismo de proteção contra ataques do tipo man-in-the-middle que utilizam o protocolo ARP;
11.40. Deve implementar DHCP Snooping em IPv4 e IPv6 para mitigar problemas com servidores DHCP que não estejam autorizados na rede;
11.41. Deve implementar controle de acesso por porta através do padrão IEEE 802.1X com assinalamento dinâmico de VLAN por usuário com base em atributos recebidos através do protocolo RADIUS;
11.42. Deve suportar a autenticação IEEE 802.1X de múltiplos dispositivos em cada por porta do switch. Apenas o tráfego dos dispositivos autenticados é que devem ser comutados na porta;
11.43. Deve suportar a autenticação simultânea de, no mínimo, 15 (quinze) dispositivos em cada porta através do protocolo IEEE 802.1X;
11.44. Deve suportar MAC Authentication Bypass (MAB);
11.45. Deve implementar RADIUS CoA (Change of Authorization);
11.46. Deve possuir recurso para monitorar a disponibilidade dos servidores RADIUS;
11.47. Em caso de indisponibilidade dos servidores RADIUS, o switch deve provisionar automaticamente uma VLAN para os dispositivos conectados nas interfaces que estejam com 802.1X habilitado de forma a não causar indisponibilidade da rede;
11.48. Deve implementar Guest VLAN para aqueles usuários que não autenticaram nas interfaces em que o IEEE 802.1X estiver habilitado;
11.49. Deve ser capaz de operar em modo de monitoramento para autenticações 802.1X. Desta forma, o switch deve permitir que sejam realizados testes de autenticação nas portas sem tomar ações tal como reconfigurar a interface;
11.50. Deve ser capaz de autenticar um computador via 802.1X mesmo que este esteja conectado através de uma interface do telefone IP;
11.51. Deve suportar RADIUS Authentication e RADIUS Accounting através de IPv6;
11.52. Deve permitir configurar o número máximo de endereços MAC que podem ser aprendidos em uma
determinada porta. Caso o número máximo seja excedido, o switch deverá gerar um log de evento para notificar o problema;
11.53. Deve permitir a customização do tempo em segundos em que um determinado MAC Address aprendido dinamicamente ficará armazenado na tabela de endereços MAC (MAC Table);
11.54. Deve ser capaz de gerar log de eventos quando um novo endereço MAC Address for aprendido dinamicamente nas interfaces, quando o MAC Address mover entre interfaces do mesmo switch e quando o MAC Address for removido da interface;
11.55. Deve ser capaz de autorizar a transmissão de pacotes nas interfaces somente para aqueles endereços IP que foram aprendidos dinamicamente através de DHCP Snooping. Os pacotes originados por endereços IP desconhecidos deverão ser descartados;
11.56. Deve implementar Netflow, sFlow ou similar;
11.57. Deve suportar o envio de mensagens de log para servidores externos através de syslog;
11.58. Deve suportar o protocolo SNMP (Simple Network Management Protocol) nas versões v1, v2c e v3;
11.59. deve suportar o protocolo SSH em IPv4 e IPv6 para configuração e administração remota através de CLI (Command Line Interface);
11.60. Deve suportar o protocolo HTTPS para configuração e administração remota através de interface web;
11.61. Deve permitir upload de arquivo e atualização do firmware (software) do switch através da interface web (HTTPS);
11.62. Deve permitir ser gerenciado através de IPv6;
11.63. Deve permitir a criação de perfis de usuários administrativos com diferentes níveis de permissões para administração e configuração do switch;
11.64. Deve suportar autenticação via RADIUS e TACACS+ para controle do acesso administrativo ao equipamento;
11.65. Deverá possuir mecanismo para identificar conflitos de endereços IP na rede. Caso um conflito seja identificado, o switch deverá gerar um log de evento e enviar um SNMP Trap;
11.66. Deve suportar o protocolo LLDP e LLDP-MED para descoberta automática de equipamentos na rede de acordo com o padrão IEEE 802.1ab;
11.67. Deverá suportar ser configurado e monitorado através de REST API;
11.68. Deve em conjunto com a controladora ser capaz de implementar e orquestrar políticas de segurança de micro segmentação nos switches controlando como os usuários/endpoints se comunicam lateralmente entre si.
11.69. Deve em conjunto com a controladora permitir a criação de automações que executem ações baseado em eventos de rede detectados no ambiente, como quarentenar um dispositivo, isolar um endpoint, implementar e/ou ajustar políticas de segurança dependendo do evento detectado, de forma automatizada..
11.70. Deve possuir ferramenta para captura de pacotes que auxíliarão na identificação de problemas na rede. deve permitir a utilização de filtros para selecionar o tráfego que deverá ser capturado e permitir a exportação dos pacotes através de arquivo .pcap para análise em software Wireshark;
11.71. Deve ser capaz de armazenar no mínimo duas versões de firmware simultaneamente em sua memória flash;
11.72. Deve possuir LEDs que indiquem o status de atividade de cada porta, além de indicar se há alguma falha ou alarme no switch;
11.73. Deve suportar temperatura de operação de até 40º Celsius;
11.74. Deve possuir MTBF (Mean Time Between Failures) igual ou superior a 10 (dez) anos;
11.75. Deve ser fornecido com fontes de alimentação redundantes hot swappable, com capacidade para operar em tensões de 110V e 220V;
11.76. Deve permitir a sua instalação física em rack padrão 19" com altura máxima de 1U. Todos os acessórios para montagem e fixação deverão ser fornecidos;
11.77. Deve ser compatível e gerenciado pelos ITENS 01, 02, 03 e 04 “SOLUÇÃO DE SEGURANÇA CIBERNÉTICA DISTRIBUÍDA NGFW TIPO I, II, III e IV” , caso compatível poderão ser utilizadas atuais controladoras existentes na SEMIT, Marca Fortinet, Modelos FG1800F/FG1100E/ FG200F/ FG100F, e ou por solução do mesmo fabricante que possua gerência centralizada, devendo atender aos requisitos descritos abaixo:
11.77.1. A solução de gerência centralizada deve suportar operação com elementos redundantes, não havendo disrupção do serviço mediante a falha de um elemento;
11.77.2. Deve operar como ponto central para automação e gerenciamento dos switches;
11.77.3. Deve realizar o gerenciamento de inventário de hardware, software e configuração dos Switches;
11.77.4. Deve possuir interface gráfica para configuração, administração e monitoração dos switches;
11.77.5. Deve apresentar graficamente a topologia da rede com todos os switches administrados para monitoramento, além de ilustrar graficamente status dos uplinks e dos equipamentos para identificação de eventuais problemas na rede;
11.77.6. Deve montar a topologia da rede de maneira automática;
11.77.7. Deve ser capaz de configurar os switches da rede;
11.77.8. Deve através da interface gráfica deve ser capaz de configurar as VLANs da rede e distribui-las automaticamente em todos os switches gerenciados;
11.77.9. Deve através da interface gráfica deve ser capaz de aplicar a VLAN nativa (untagged) e as VLANs permitidas (tagged) nas interfaces dos switches;
11.77.10. Deve através da interface gráfica deve ser capaz de aplicar as políticas de QoS nas interfaces dos switches;
11.77.11. Deve através da interface gráfica deve ser capaz de aplicar as políticas de segurança para autenticação 802.1X nas interfaces dos switches;
11.77.12. Deve através da interface gráfica deve ser capaz de habilitar ou desabilitar o PoE nas interfaces dos switches;
11.77.13. Através da interface gráfica deve ser capaz de aplicar ferramentas de segurança, tal como DHCP Snooping, nas interfaces dos switches;
11.77.14. Deve através da interface gráfica deve ser capaz de realizar configurações do protocolo Spanning Tree nas interfaces dos switches, tal como habilitar ou desabilitar os seguintes recursos: Loop Guard, Root Guard e BPDU Guard;
11.77.15. Deve através da interface gráfica deve ser capaz de aplicar políticas de segurança e controle de tráfego para filtrar o tráfego da rede;
11.77.16. A solução de gerência centralizada deve ser capaz de identificar as aplicações acessadas na rede através de análise DPI (Deep Packet Inspection);
11.77.17. Deve ser capaz de configurar parâmetros SNMP dos switches;
11.77.18. A solução de gerência centralizada deve gerenciar as atualizações de firmware (software) dos switches gerenciados, recomendando versões de software para cada switch, além de permitir a atualização dos switches individualmente;
11.77.19. A solução de gerência centralizada deve permitir o envio automático de e-mails de notificação para os administradores da rede em caso de eventos de falhas;
11.77.20. A solução de gerência centralizada deve apresentar graficamente informações sobre erros nas interfaces dos switches;
11.77.21. A solução deve apresentar graficamente informações sobre disponibilidade dos switches;
11.77.22. Deve prover indicadores de saúde dos elementos críticos do ambiente;
11.77.23. Deve registrar eventos para auditoria de todos os acessos e mudanças de configuração realizadas por usuários;
11.77.24. Deve realizar as funções de gerenciamento de falhas e eventos dos switches da rede;
11.77.25. Deve possuir API no formato REST;
12. ITEM 11 - ATIVO DE REDE WIRED TIPO “V”
12.1. Deve possuir garantia e suporte do fabricante pelo período de 36 (trinta e seis) meses
12.2. A CONTRATADA deve realizar a instalação inicial do equipamento que está restrita a entrega do equipamento, conferência de itens e teste inicial de funcionamento.
12.3. Deve possuir 48 (vinte e quatro) slots SFP+ 10GE para conexão de fibras ópticas do operando em 10GbE;
12.4. Adicionalmente, deve possuir 04 (quatro) slots QSFP+/QSFP28 para conexão de fibras ópticas operando em 40G/100G. Estas interfaces não devem ser do tipo combo e devem operar simultaneamente em conjunto com as interfaces do item anterior;
12.5. Deve possuir porta console para acesso à interface de linha de comando (CLI) do equipamento através de conexão serial.
12.6. Deve possuir 1 (uma) interface USB;
12.7. Deve possuir capacidade de comutação de pelo menos 1600 Gbps e ser capaz de encaminhar até 1500 Mpps (milhões de pacotes por segundo);
12.8. Deve suportar 4000 (quatro mil) VLANs de acordo com o padrão IEEE 802.1Q;
12.9. Deve possuir tabela MAC com suporte a 95.000 endereços;
12.10. Deve operar com latência igual ou inferior à 1us (microsegundo);
12.11. Deve implementar Flow Control baseado no padrão IEEE 802.3X;
12.12. Em conjunto com o Flow Control (IEEE 802.3x) o switch deverá, ao invés de enviar pause frames, definir um limite de banda que poderá ser recebida na interface quando o buffer estiver cheio. O switch deverá medir o volume de utilização do buffer para que o recebimento seja restaurado à capacidade máxima automaticamente;
12.13. Deve permitir a configuração de links agrupados virtualmente (link aggregation) de acordo com o padrão IEEE 802.3ad (Link Aggregation Control Protocol – LACP);
12.14. Deve suportar Multi-Chassis Link Agregation (MCLAG) ou mecanismo similar para agrupar suas interfaces com interfaces de outro switch de mesmo modelo de tal forma que equipamentos terceiros reconheçam as interfaces de ambos switches como uma única interface lógica;
12.15. Deve suportar a comutação de Jumbo Frames;
12.16. Deve identificar automaticamente telefones IP que estejam conectados e associá-los automaticamente a VLAN de voz;
12.17. Deve implementar roteamento (camada 3 do modelo OSI) entre as VLANs;
12.18. Deve suportar a criação de rotas estáticas em IPv4 e IPv6;
12.19. Deve possuir hardware capaz de suportar roteamento dinâmico através dos protocolos RIP, BGP, OSPF em IPv4 e OSPF em IPv6. É facultada a entrega de licenças caso o software exigia licenciamento adicional para ativação dos protocolos;
12.20. Deve possuir hardware capaz de suportar o protocolo VRRP ou mecanismo similar de redundância de gateway. É facultada a entrega de licenças caso o software exiga licenciamento adicional para ativação do protocolo;
12.21. Deve implementar serviço de DHCP Server e DHCP Relay;
12.22. Deve suportar IGMP snooping para controle de tráfego de multicast, permitindo a criação de pelo menos 1000 (mil) grupos;
12.23. Deve permitir o espelhamento do tráfego de uma porta para outra porta do mesmo switch e outro switch da rede (port mirroring / SPAN);
12.24. Deve permitir o espelhamento de uma porta ou de um grupo de portas para uma porta especificada em outro equipamento através de RSPAN e ERSPAN;
12.25. Deve implementar Spanning Tree conforme os padrões IEEE 802.1w (Rapid Spanning Tree) e IEEE 802.1s (Multiple Spanning Tree). deve implementar pelo menos 15 (quinze) instâncias de Multiple Spanning Tree;
12.26. Deve implementar recurso conhecido como PortFast ou Edge Port para que uma porta de acesso seja colocada imediatamente no status "Forwarding" do Spanning Tree após sua conexão física;
12.27. Deve implementar mecanismo de proteção da “root bridge” do algoritmo Spanning-Tree para prover defesa contra-ataques do tipo “Denial of Service” no ambiente nível 2;
12.28. Deve permitir a suspensão de recebimento de BPDUs (Bridge Protocol Data Units) caso a porta esteja colocada no modo “fast forwarding” (conforme previsto no padrão IEEE 802.1w). Sendo recebido um BPDU neste tipo de porta deve ser possível desabilitá-la automaticamente;
12.29. Deve possuir mecanismo conhecido como Loop Guard para identificação de loops na rede. deve desativar a interface e gerar um evento quando um loop for identificado;
12.30. Deve possuir mecanismo para identificar interfaces em constantes mudanças de status de operação (flapping) que podem ocasionar instabilidade na rede. O switch deverá desativar a interface automaticamente caso o número de variações de status esteja acima do limite configurado para o período estabelecido em segundos;
12.31. Deverá possuir controle de broadcast, multicast e unicast nas portas do switch. Quando o limite for excedido, o switch deve descartar os pacotes ou aplicar rate limit;
12.32. Deve suportar a criação de listas de acesso (ACLs) para filtragem de tráfego. Estas devem estar baseadas nos seguintes parâmetros para classificação do tráfego: endereço IP de origem e destino, endereço MAC de origem e destino, portas TCP e UDP, campo DSCP, campo CoS e VLAN ID;
12.33. Deve permitir a definição de dias e horários que a ACL deverá ser aplicada na rede;
12.34. Deverá implementar classificação, marcação e priorização de tráfego baseada nos valores de classe de serviço do frame ethernet (IEEE 802.1p CoS);
12.35. Deverá implementar classificação, marcação e priorização de tráfego baseada nos valores do campo “Differentiated Services Code Point” (DSCP) do cabeçalho IP, conforme definições do IETF;
12.36. Deverá implementar ao menos 1 (um) dos seguintes mecanismos de prevenção contra congestão de tráfego: Weighted Round Robin (WRR), WRED (Weighted Random Early Detection) ou Weighted Fair Queuing (WFQ);
12.37. Deve possuir ao menos 8 (oito) filas de priorização (QoS) por porta;
12.38. Deve suportar o mecanismo Explicit Congestion Notification (ECN) para notificar o emissor que há uma congestão ocorrendo e com isso evitar que os pacotes sejam descartados;
12.39. Deve implementar mecanismo de proteção contra ataques do tipo spoofing para mensagens de IPv6 Router Advertisement;
12.40. Deverá implementar mecanismo de proteção contra ataques do tipo man-in-the-middle que utilizam o protocolo ARP;
12.41. Deve implementar DHCP Snooping em IPv4 e IPv6 para mitigar problemas com servidores DHCP que não estejam autorizados na rede;
12.42. Deve implementar controle de acesso por porta através do padrão IEEE 802.1X com assinalamento dinâmico de VLAN por usuário com base em atributos recebidos através do protocolo RADIUS;
12.43. Deve suportar a autenticação IEEE 802.1X de múltiplos dispositivos em cada por porta do switch. Apenas o tráfego dos dispositivos autenticados é que devem ser comutados na porta;
12.44. Deve suportar a autenticação simultânea de, no mínimo, 15 (quinze) dispositivos em cada porta através do protocolo IEEE 802.1X;
12.45. Deve suportar MAC Authentication Bypass (MAB);
12.46. Deve implementar RADIUS CoA (Change of Authorization);
12.47. Deve possuir recurso para monitorar a disponibilidade dos servidores RADIUS;
12.48. Em caso de indisponibilidade dos servidores RADIUS, o switch deve provisionar automaticamente uma VLAN para os dispositivos conectados nas interfaces que estejam com 802.1X habilitado de forma a não causar indisponibilidade da rede;
12.49. Deve implementar Guest VLAN para aqueles usuários que não autenticaram nas interfaces em que o IEEE 802.1X estiver habilitado;
12.50. Deve ser capaz de operar em modo de monitoramento para autenticações 802.1X. Desta forma, o switch deve permitir que sejam realizados testes de autenticação nas portas sem tomar ações tal como reconfigurar a interface;
12.51. Deve ser capaz de autenticar um computador via 802.1X mesmo que este esteja conectado através de uma interface do telefone IP;
12.52. Deve suportar RADIUS Authentication e RADIUS Accounting através de IPv6;
12.53. Deve permitir configurar o número máximo de endereços MAC que podem ser aprendidos em uma determinada porta. Caso o número máximo seja excedido, o switch deverá gerar um log de evento para notificar o problema;
12.54. Deve permitir a customização do tempo em segundos em que um determinado MAC Address aprendido dinamicamente ficará armazenado na tabela de endereços MAC (MAC Table);
12.55. Deve ser capaz de gerar log de eventos quando um novo endereço MAC Address for aprendido dinamicamente nas interfaces, quando o MAC Address mover entre interfaces do mesmo switch e quando o MAC Address for removido da interface;
12.56. Deve ser capaz de autorizar a transmissão de pacotes nas interfaces somente para aqueles endereços IP que foram aprendidos dinamicamente através de DHCP Snooping. Os pacotes originados por endereços IP desconhecidos deverão ser descartados;
12.57. Deve implementar Netflow, sFlow ou similar;
12.58. Deve suportar o envio de mensagens de log para servidores externos através de syslog;
12.59. Deve suportar o protocolo SNMP (Simple Network Management Protocol) nas versões v1, v2c e v3;
12.60. deve suportar o protocolo SSH em IPv4 e IPv6 para configuração e administração remota através de CLI (Command Line Interface);
12.61. Deve suportar o protocolo HTTPS para configuração e administração remota através de interface web;
12.62. Deve permitir upload de arquivo e atualização do firmware (software) do switch através da interface web (HTTPS);
12.63. Deve permitir ser gerenciado através de IPv6;
12.64. Deve permitir a criação de perfis de usuários administrativos com diferentes níveis de permissões para administração e configuração do switch;
12.65. Deve suportar autenticação via RADIUS e TACACS+ para controle do acesso administrativo ao equipamento;
12.66. Deverá possuir mecanismo para identificar conflitos de endereços IP na rede. Caso um conflito seja identificado, o switch deverá gerar um log de evento e enviar um SNMP Trap;
12.67. Deve suportar o protocolo LLDP e LLDP-MED para descoberta automática de equipamentos na rede de acordo com o padrão IEEE 802.1ab;
12.68. Deverá suportar ser configurado e monitorado através de REST API;
12.69. Deve em conjunto com a controladora ser capaz de implementar e orquestrar políticas de segurança de micro segmentação nos switches controlando como os usuários/endpoints se comunicam lateralmente entre si.
12.70. Deve em conjunto com a controladora permitir a criação de automações que executem ações baseado em eventos de rede detectados no ambiente, como quarentenar um dispositivo, isolar um endpoint, implementar e/ou ajustar políticas de segurança dependendo do evento detectado, de forma automatizada..
12.71. Deve possuir ferramenta para captura de pacotes que auxíliarão na identificação de problemas na rede. deve permitir a utilização de filtros para selecionar o tráfego que deverá ser capturado e permitir a exportação dos pacotes através de arquivo .pcap para análise em software Wireshark;
12.72. Deve ser capaz de armazenar no mínimo duas versões de firmware simultaneamente em sua memória flash;
12.73. Deve possuir LEDs que indiquem o status de atividade de cada porta, além de indicar se há alguma falha ou alarme no switch;
12.74. Deve suportar temperatura de operação de até 40º Celsius;
12.75. Deve possuir MTBF (Mean Time Between Failures) igual ou superior a 10 (dez) anos;
12.76. Deve ser fornecido com fontes de alimentação redundantes hot swappable, com capacidade para operar em tensões de 110V e 220V;
12.77. Deve permitir a sua instalação física em rack padrão 19" com altura máxima de 1U. Todos os acessórios para montagem e fixação deverão ser fornecidos;
12.78. Deve ser compatível e gerenciado pelos ITENS 01, 02, 03 e 04 “SOLUÇÃO DE SEGURANÇA CIBERNÉTICA DISTRIBUÍDA NGFW TIPO I, II, III e IV” , caso compatível poderão ser utilizadas atuais controladoras existentes na SEMIT, Marca Fortinet, Modelos FG1800F/FG1100E/ FG200F/ FG100F, e ou por solução do mesmo fabricante que possua gerência centralizada, devendo atender aos requisitos descritos abaixo:
12.78.1. A solução de gerência centralizada deve suportar operação com elementos redundantes, não havendo disrupção do serviço mediante a falha de um elemento;
12.78.2. Deve operar como ponto central para automação e gerenciamento dos switches;
12.78.3. Deve realizar o gerenciamento de inventário de hardware, software e configuração dos Switches;
12.78.4. Deve possuir interface gráfica para configuração, administração e monitoração dos switches;
12.78.5. Deve apresentar graficamente a topologia da rede com todos os switches administrados para monitoramento, além de ilustrar graficamente status dos uplinks e dos equipamentos para identificação de eventuais problemas na rede;
12.78.6. Deve montar a topologia da rede de maneira automática;
12.78.7. Deve ser capaz de configurar os switches da rede;
12.78.8. Deve através da interface gráfica deve ser capaz de configurar as VLANs da rede e distribui-las
automaticamente em todos os switches gerenciados;
12.78.9. Deve através da interface gráfica deve ser capaz de aplicar a VLAN nativa (untagged) e as VLANs permitidas (tagged) nas interfaces dos switches;
12.78.10. Deve através da interface gráfica deve ser capaz de aplicar as políticas de QoS nas interfaces dos switches;
12.78.11. Deve através da interface gráfica deve ser capaz de aplicar as políticas de segurança para autenticação 802.1X nas interfaces dos switches;
12.78.12. Deve através da interface gráfica deve ser capaz de habilitar ou desabilitar o PoE nas interfaces dos switches;
12.78.13. Através da interface gráfica deve ser capaz de aplicar ferramentas de segurança, tal como DHCP Snooping, nas interfaces dos switches;
12.78.14. Deve através da interface gráfica deve ser capaz de realizar configurações do protocolo Spanning Tree nas interfaces dos switches, tal como habilitar ou desabilitar os seguintes recursos: Loop Guard, Root Guard e BPDU Guard;
12.78.15. Deve através da interface gráfica deve ser capaz de aplicar políticas de segurança e controle de tráfego para filtrar o tráfego da rede;
12.78.16. A solução de gerência centralizada deve ser capaz de identificar as aplicações acessadas na rede através de análise DPI (Deep Packet Inspection);
12.78.17. Deve ser capaz de configurar parâmetros SNMP dos switches;
12.78.18. A solução de gerência centralizada deve gerenciar as atualizações de firmware (software) dos switches gerenciados, recomendando versões de software para cada switch, além de permitir a atualização dos switches individualmente;
12.78.19. A solução de gerência centralizada deve permitir o envio automático de e-mails de notificação para os administradores da rede em caso de eventos de falhas;
12.78.20. A solução de gerência centralizada deve apresentar graficamente informações sobre erros nas interfaces dos switches;
12.78.21. A solução deve apresentar graficamente informações sobre disponibilidade dos switches;
12.78.22. Deve prover indicadores de saúde dos elementos críticos do ambiente;
12.78.23. Deve registrar eventos para auditoria de todos os acessos e mudanças de configuração realizadas por usuários;
12.78.24. Deve realizar as funções de gerenciamento de falhas e eventos dos switches da rede;
12.78.25. Deve possuir API no formato REST;
13. ITEM 12 - ATIVO DE REDE WIRED POE TIPO “I”
13.1. Deve possuir garantia e suporte do fabricante pelo período de 36 (trinta e seis) meses
13.2. A Equipamento do tipo comutador de rede ethernet com capacidade de operação em camada 2 do modelo OSI;
13.3. A deve possuir 24 (vinte e quatro) interfaces do tipo 1000Base-T para conexão de cabos de par metálico UTP com conector RJ-45. deve implementar a auto-negociação de velocidade e duplex destas interfaces, além de negociar automaticamente a conexão de cabos crossover (MDI/MDI-X);
13.4. Adicionalmente, deve possuir 04 (quatro) slots SFP+ para conexão de fibras ópticas operando em 10GbE. Estas interfaces não devem ser do tipo combo e devem operar simultaneamente em conjunto com as interfaces do item anterior;
13.5. Deverá implementar os padrões IEEE 802.3af (Power over Ethernet – PoE) e IEEE 802.3at (Power over Ethernet Plus – PoE+) com PoE budget de 180W;
13.6. Deve possuir porta console para acesso à interface de linha de comando (CLI) do equipamento através de conexão serial;
13.7. Deve possuir capacidade de comutação de pelo menos 125 Gbps e ser capaz de encaminhar até 180 Mpps (milhões de pacotes por segundo);
13.8. Deve suportar 4000 (quatro mil) VLANs de acordo com o padrão IEEE 802.1Q;
13.9. Deve possuir tabela MAC com suporte a 30.000 endereços;
13.10. Deve implementar Flow Control baseado no padrão IEEE 802.3X;
13.11. Deve permitir a configuração de links agrupados virtualmente (link aggregation) de acordo com o padrão IEEE 802.3ad (Link Aggregation Control Protocol – LACP);
13.12. Deve suportar a comutação de Jumbo Frames;
13.13. Deve identificar automaticamente telefones IP que estejam conectados e associá-los automaticamente a VLAN de voz;
13.14. Deve suportar a criação de rotas estáticas em IPv4 e IPv6;
13.15. Deve implementar serviço de DHCP Relay;
13.16. Deve suportar IGMP snooping para controle de tráfego de multicast, permitindo a criação de pelo menos 500 (quinhentos) entradas na tabela;
13.17. Deve permitir o espelhamento do tráfego de uma porta para outra porta do mesmo switch (port mirroring);
13.18. Deve implementar Spanning Tree conforme os padrões IEEE 802.1w (Rapid Spanning Tree) e IEEE 802.1s (Multiple Spanning Tree).
13.19. Deve implementar pelo menos 15 (quinze) instâncias de Multiple Spanning Tree;
13.20. Deve implementar recurso conhecido como PortFast ou Edge Port para que uma porta de acesso seja colocada imediatamente no status "Forwarding" do Spanning Tree após sua conexão física;
13.21. Deve implementar mecanismo de proteção da “root bridge” do algoritmo Spanning-Tree para prover defesa contra ataques do tipo “Denial of Service” no ambiente nível 2;
13.22. Deve permitir a suspensão de recebimento de BPDUs (Bridge Protocol Data Units) caso a porta esteja colocada no modo “fast forwarding” (conforme previsto no padrão IEEE 802.1w). Sendo recebido um BPDU neste tipo de porta deve ser possível desabilitá-la automaticamente;
13.23. Deve possuir mecanismo conhecido como Loop Guard para identificação de loops na rede. deve desativar a interface e gerar um evento quando um loop for identificado;
13.24. Deve possuir mecanismo para identificar interfaces em constantes mudanças de status de operação (flapping) que podem ocasionar instabilidade na rede. O switch deverá desativar a interface automaticamente caso o número de variações de status esteja acima do limite configurado para o período estabelecido em segundos;
13.25. Deverá possuir controle de broadcast, multicast e unicast nas portas do switch. Quando o limite for excedido, o switch deve descartar os pacotes ou aplicar rate limit;
13.26. Deve suportar a criação de listas de acesso (ACLs) para filtragem de tráfego. Estas devem estar baseadas nos seguintes parâmetros para classificação do tráfego: endereço IP de origem e destino, endereço MAC de origem e destino, campo CoS e VLAN ID;
13.27. Deve suportar a definição de dias e horários que a ACL deverá ser aplicada na rede;
13.28. Deverá implementar priorização de tráfego baseada nos valores de classe de serviço do frame ethernet (IEEE 802.1p CoS);
13.29. Deve possuir ao menos 8 (oito) filas de priorização (QoS) por porta;
13.30. Deverá implementar mecanismo de proteção contra ataques do tipo man-in-the-middle que
utilizam o protocolo ARP;
13.31. Deve implementar DHCP Snooping para mitigar problemas com servidores DHCP que não estejam autorizados na rede;
13.32. Deve implementar controle de acesso por porta através do padrão IEEE 802.1X com assinalamento dinâmico de VLAN por usuário com base em atributos recebidos através do protocolo RADIUS;
13.33. Deve suportar a autenticação IEEE 802.1X de múltiplos dispositivos em cada por porta do switch. Apenas o tráfego dos dispositivos autenticados é que devem ser comutados na porta;
13.34. Deve suportar a autenticação simultânea de, no mínimo, 15 (quinze) dispositivos em cada porta através do protocolo IEEE 802.1X;
13.35. Deve suportar MAC Authentication Bypass (MAB);
13.36. Deve implementar RADIUS CoA (Change of Authorization);
13.37. Deve possuir recurso para monitorar a disponibilidade dos servidores RADIUS;
13.38. Em caso de indisponibilidade dos servidores RADIUS, o switch deve provisionar automaticamente uma VLAN para os dispositivos conectados nas interfaces que estejam com 802.1X habilitado de forma a não causar indisponibilidade da rede;
13.39. Deve implementar Guest VLAN para aqueles usuários que não autenticaram nas interfaces em que o IEEE 802.1X estiver habilitado;
13.40. Deve ser capaz de operar em modo de monitoramento para autenticações 802.1X. Desta forma, o switch deve permitir que sejam realizados testes de autenticação nas portas sem tomar ações tal como reconfigurar a interface;
13.41. Deve ser capaz de autenticar um computador via 802.1X mesmo que este esteja conectado através de uma interface do telefone IP;
13.42. Deve suportar RADIUS Authentication e RADIUS Accounting através de IPv6;
13.43. Deve permitir configurar o número máximo de endereços MAC que podem ser aprendidos em uma determinada porta. Caso o número máximo seja excedido, o switch deverá gerar um log de evento para notificar o problema;
13.44. Deve permitir a customização do tempo em segundos em que um determinado MAC Address aprendido dinamicamente ficará armazenado na tabela de endereços MAC (MAC Table);
13.45. Deve ser capaz de gerar log de eventos quando um novo endereço MAC Address for aprendido dinamicamente nas interfaces, quando o MAC Address mover entre interfaces do mesmo switch e quando o MAC Address for removido da interface;
13.46. Deve suportar o protocolo NTP (Network Time Protocol) ou SNTP (Simple Network Time Protocol) para a sincronização do relógio;
13.47. Deve suportar o envio de mensagens de log para servidores externos através de syslog;
13.48. Deve suportar o protocolo SNMP (Simple Network Management Protocol) nas versões v1, v2c e v3;
13.49. deve suportar o protocolo SSH em IPv4 e IPv6 para configuração e administração remota através de CLI (Command Line Interface);
13.50. Deve suportar o protocolo HTTPS para configuração e administração remota através de interface web;
13.51. Deve permitir upload de arquivo e atualização do firmware (software) do switch através da interface web (HTTPS);
13.52. Deve permitir ser gerenciado através de IPv6;
13.53. Deve permitir a criação de perfis de usuários administrativos com diferentes níveis de permissões
para administração e configuração do switch;
13.54. Deve suportar autenticação via RADIUS e TACACS+ para controle do acesso administrativo ao equipamento;
13.55. Deverá possuir mecanismo para identificar conflitos de endereços IP na rede. Caso um conflito seja identificado, o switch deverá gerar um log de evento e enviar um SNMP Trap;
13.56. Deve suportar o protocolo LLDP e LLDP-MED para descoberta automática de equipamentos na rede de acordo com o padrão IEEE 802.1ab;
13.57. Deverá ser capaz de executar testes nas interfaces para identificar problemas físicos nos cabos de par trançado (UTP) conectados ao switch;
13.58. Deverá suportar ser configurado e monitorado através de REST API;
13.59. Deve em conjunto com a controladora ser capaz de implementar e orquestrar políticas de segurança de micro segmentação nos switches controlando como os usuários/endpoints se comunicam lateralmente entre si.
13.60. Deve em conjunto com a controladora permitir a criação de automações que executem ações baseado em eventos de rede detectados no ambiente, como quarentenar um dispositivo, isolar um endpoint, implementar e/ou ajustar políticas de segurança dependendo do evento detectado, de forma automatizada.
13.61. Deve suportar temperatura de operação de até 40º Celsius;
13.62. Deve possuir MTBF (Mean Time Between Failures) igual ou superior a 10 (dez) anos;
13.63. Deve ser fornecido com fonte de alimentação interna com capacidade para operar em tensões de 110V e 220V;
13.64. Deve ser compatível e gerenciado pelos ITENS 01, 02, 03 e 04 “SOLUÇÃO DE SEGURANÇA CIBERNÉTICA DISTRIBUÍDA NGFW TIPO I, II, III e IV” , caso compatível poderão ser utilizadas atuais controladoras existentes na SEMIT, Marca Fortinet, Modelos FG1800F/FG1100E/ FG200F/ FG100F, e ou por solução do mesmo fabricante que possua gerência centralizada, devendo atender aos requisitos descritos abaixo:
13.64.1. A solução de gerência centralizada deve suportar operação com elementos redundantes, não havendo disrupção do serviço mediante a falha de um elemento;
13.64.2. Deve operar como ponto central para automação e gerenciamento dos switches;
13.64.3. Deve realizar o gerenciamento de inventário de hardware, software e configuração dos Switches;
13.64.4. Deve possuir interface gráfica para configuração, administração e monitoração dos switches;
13.64.5. Deve apresentar graficamente a topologia da rede com todos os switches administrados para monitoramento, além de ilustrar graficamente status dos uplinks e dos equipamentos para identificação de eventuais problemas na rede;
13.64.6. Deve montar a topologia da rede de maneira automática;
13.64.7. Deve ser capaz de configurar os switches da rede;
13.64.8. Deve através da interface gráfica deve ser capaz de configurar as VLANs da rede e distribui-las automaticamente em todos os switches gerenciados;
13.64.9. Deve através da interface gráfica deve ser capaz de aplicar a VLAN nativa (untagged) e as VLANs permitidas (tagged) nas interfaces dos switches;
13.64.10. Deve através da interface gráfica deve ser capaz de aplicar as políticas de QoS nas interfaces dos switches;
13.64.11. Deve através da interface gráfica deve ser capaz de aplicar as políticas de segurança para autenticação 802.1X nas interfaces dos switches;
13.64.12. Através da interface gráfica deve ser capaz de aplicar ferramentas de segurança, tal como DHCP Snooping, nas interfaces dos switches;
13.64.13. Deve através da interface gráfica deve ser capaz de realizar configurações do protocolo Spanning Tree nas interfaces dos switches, tal como habilitar ou desabilitar os seguintes recursos: Loop Guard, Root Guard e BPDU Guard;
13.64.14. Deve através da interface gráfica deve ser capaz de aplicar políticas de segurança e controle de tráfego para filtrar o tráfego da rede;
13.64.15. A solução de gerência centralizada deve ser capaz de identificar as aplicações acessadas na rede através de análise DPI (Deep Packet Inspection);
13.64.16. Deve ser capaz de configurar parâmetros SNMP dos switches;
13.64.17. A solução de gerência centralizada deve gerenciar as atualizações de firmware (software) dos switches gerenciados, recomendando versões de software para cada switch, além de permitir a atualização dos switches individualmente;
13.64.18. A solução de gerência centralizada deve permitir o envio automático de e-mails de notificação para os administradores da rede em caso de eventos de falhas;
13.64.19. A solução de gerência centralizada deve apresentar graficamente informações sobre erros nas interfaces dos switches;
13.64.20. A solução deve apresentar graficamente informações sobre disponibilidade dos switches;
13.64.21. Deve prover indicadores de saúde dos elementos críticos do ambiente;
13.64.22. Deve registrar eventos para auditoria de todos os acessos e mudanças de configuração realizadas por usuários;
13.64.23. Deve realizar as funções de gerenciamento de falhas e eventos dos switches da rede;
13.64.24. Deve possuir API no formato REST;
14. ITEM 13 - ATIVO DE REDE WIRED POE TIPO “II”
14.1. Deve possuir garantia e suporte do fabricante pelo período de 36 (trinta e seis) meses
14.2. A Equipamento do tipo comutador de rede ethernet com capacidade de operação em camada 2 do modelo OSI;
14.3. A deve possuir 48 (quarenta e oito) interfaces do tipo 1000Base-T para conexão de cabos de par metálico UTP com conector RJ-45. deve implementar a auto-negociação de velocidade e duplex destas interfaces, além de negociar automaticamente a conexão de cabos crossover (MDI/MDI-X);
14.4. Adicionalmente, deve possuir 04 (quatro) slots SFP+ para conexão de fibras ópticas operando em 10GbE. Estas interfaces não devem ser do tipo combo e devem operar simultaneamente em conjunto com as interfaces do item anterior;
14.5. Deverá implementar os padrões IEEE 802.3af (Power over Ethernet – PoE) e IEEE 802.3at (Power over Ethernet Plus – PoE+) com PoE budget de 350W;
14.6. Deve possuir porta console para acesso à interface de linha de comando (CLI) do equipamento através de conexão serial;
14.7. Deve possuir capacidade de comutação de pelo menos 170 Gbps e ser capaz de encaminhar até 260 Mpps (milhões de pacotes por segundo);
14.8. Deve suportar 4000 (quatro mil) VLANs de acordo com o padrão IEEE 802.1Q;
14.9. Deve possuir tabela MAC com suporte a 30.000 endereços;
14.10. Deve implementar Flow Control baseado no padrão IEEE 802.3X;
14.11. Deve permitir a configuração de links agrupados virtualmente (link aggregation) de acordo com o padrão IEEE 802.3ad (Link Aggregation Control Protocol – LACP);
14.12. Deve suportar a comutação de Jumbo Frames;
14.13. Deve identificar automaticamente telefones IP que estejam conectados e associá-los automaticamente a VLAN de voz;
14.14. Deve suportar a criação de rotas estáticas em IPv4 e IPv6;
14.15. Deve implementar serviço de DHCP Relay;
14.16. Deve suportar IGMP snooping para controle de tráfego de multicast, permitindo a criação de pelo menos 500 (quinhentos) entradas na tabela;
14.17. Deve permitir o espelhamento do tráfego de uma porta para outra porta do mesmo switch (port mirroring);
14.18. Deve implementar Spanning Tree conforme os padrões IEEE 802.1w (Rapid Spanning Tree) e IEEE 802.1s (Multiple Spanning Tree).
14.19. Deve implementar pelo menos 15 (quinze) instâncias de Multiple Spanning Tree;
14.20. Deve implementar recurso conhecido como PortFast ou Edge Port para que uma porta de acesso seja colocada imediatamente no status "Forwarding" do Spanning Tree após sua conexão física;
14.21. Deve implementar mecanismo de proteção da “root bridge” do algoritmo Spanning-Tree para prover defesa contra ataques do tipo “Denial of Service” no ambiente nível 2;
14.22. Deve permitir a suspensão de recebimento de BPDUs (Bridge Protocol Data Units) caso a porta esteja colocada no modo “fast forwarding” (conforme previsto no padrão IEEE 802.1w). Sendo recebido um BPDU neste tipo de porta deve ser possível desabilitá-la automaticamente;
14.23. Deve possuir mecanismo conhecido como Loop Guard para identificação de loops na rede. deve desativar a interface e gerar um evento quando um loop for identificado;
14.24. Deve possuir mecanismo para identificar interfaces em constantes mudanças de status de operação (flapping) que podem ocasionar instabilidade na rede. O switch deverá desativar a interface automaticamente caso o número de variações de status esteja acima do limite configurado para o período estabelecido em segundos;
14.25. Deverá possuir controle de broadcast, multicast e unicast nas portas do switch. Quando o limite for excedido, o switch deve descartar os pacotes ou aplicar rate limit;
14.26. Deve suportar a criação de listas de acesso (ACLs) para filtragem de tráfego. Estas devem estar baseadas nos seguintes parâmetros para classificação do tráfego: endereço IP de origem e destino, endereço MAC de origem e destino, campo CoS e VLAN ID;
14.27. Deve suportar a definição de dias e horários que a ACL deverá ser aplicada na rede;
14.28. Deverá implementar priorização de tráfego baseada nos valores de classe de serviço do frame ethernet (IEEE 802.1p CoS);
14.29. Deve possuir ao menos 8 (oito) filas de priorização (QoS) por porta;
14.30. Deverá implementar mecanismo de proteção contra ataques do tipo man-in-the-middle que utilizam o protocolo ARP;
14.31. Deve implementar DHCP Snooping para mitigar problemas com servidores DHCP que não estejam autorizados na rede;
14.32. Deve implementar controle de acesso por porta através do padrão IEEE 802.1X com assinalamento dinâmico de VLAN por usuário com base em atributos recebidos através do protocolo RADIUS;
14.33. Deve suportar a autenticação IEEE 802.1X de múltiplos dispositivos em cada por porta do switch. Apenas o tráfego dos dispositivos autenticados é que devem ser comutados na porta;
14.34. Deve suportar a autenticação simultânea de, no mínimo, 15 (quinze) dispositivos em cada porta através do protocolo IEEE 802.1X;
14.35. Deve suportar MAC Authentication Bypass (MAB);
14.36. Deve implementar RADIUS CoA (Change of Authorization);
14.37. Deve possuir recurso para monitorar a disponibilidade dos servidores RADIUS;
14.38. Em caso de indisponibilidade dos servidores RADIUS, o switch deve provisionar automaticamente uma VLAN para os dispositivos conectados nas interfaces que estejam com 802.1X habilitado de forma a não causar indisponibilidade da rede;
14.39. Deve implementar Guest VLAN para aqueles usuários que não autenticaram nas interfaces em que o IEEE 802.1X estiver habilitado;
14.40. Deve ser capaz de operar em modo de monitoramento para autenticações 802.1X. Desta forma, o switch deve permitir que sejam realizados testes de autenticação nas portas sem tomar ações tal como reconfigurar a interface;
14.41. Deve ser capaz de autenticar um computador via 802.1X mesmo que este esteja conectado através de uma interface do telefone IP;
14.42. Deve suportar RADIUS Authentication e RADIUS Accounting através de IPv6;
14.43. Deve permitir configurar o número máximo de endereços MAC que podem ser aprendidos em uma determinada porta. Caso o número máximo seja excedido, o switch deverá gerar um log de evento para notificar o problema;
14.44. Deve permitir a customização do tempo em segundos em que um determinado MAC Address aprendido dinamicamente ficará armazenado na tabela de endereços MAC (MAC Table);
14.45. Deve ser capaz de gerar log de eventos quando um novo endereço MAC Address for aprendido dinamicamente nas interfaces, quando o MAC Address mover entre interfaces do mesmo switch e quando o MAC Address for removido da interface;
14.46. Deve suportar o protocolo NTP (Network Time Protocol) ou SNTP (Simple Network Time Protocol) para a sincronização do relógio;
14.47. Deve suportar o envio de mensagens de log para servidores externos através de syslog;
14.48. Deve suportar o protocolo SNMP (Simple Network Management Protocol) nas versões v1, v2c e v3;
14.49. deve suportar o protocolo SSH em IPv4 e IPv6 para configuração e administração remota através de CLI (Command Line Interface);
14.50. Deve suportar o protocolo HTTPS para configuração e administração remota através de interface web;
14.51. Deve permitir upload de arquivo e atualização do firmware (software) do switch através da interface web (HTTPS);
14.52. Deve permitir ser gerenciado através de IPv6;
14.53. Deve permitir a criação de perfis de usuários administrativos com diferentes níveis de permissões para administração e configuração do switch;
14.54. Deve suportar autenticação via RADIUS e TACACS+ para controle do acesso administrativo ao equipamento;
14.55. Deverá possuir mecanismo para identificar conflitos de endereços IP na rede. Caso um conflito seja identificado, o switch deverá gerar um log de evento e enviar um SNMP Trap;
14.56. Deve suportar o protocolo LLDP e LLDP-MED para descoberta automática de equipamentos na rede de acordo com o padrão IEEE 802.1ab;
14.57. Deverá ser capaz de executar testes nas interfaces para identificar problemas físicos nos cabos de par trançado (UTP) conectados ao switch;
14.58. Deverá suportar ser configurado e monitorado através de REST API;
14.59. Deve em conjunto com a controladora ser capaz de implementar e orquestrar políticas de segurança de micro segmentação nos switches controlando como os usuários/endpoints se comunicam lateralmente entre si.
14.60. Deve em conjunto com a controladora permitir a criação de automações que executem ações baseado em eventos de rede detectados no ambiente, como quarentenar um dispositivo, isolar um endpoint, implementar e/ou ajustar políticas de segurança dependendo do evento detectado, de forma automatizada..
14.61. Deve suportar temperatura de operação de até 40º Celsius;
14.62. Deve possuir MTBF (Mean Time Between Failures) igual ou superior a 10 (dez) anos;
14.63. Deve ser fornecido com fonte de alimentação interna com capacidade para operar em tensões de 110V e 220V;
14.64. Deve ser compatível e gerenciado pelos ITENS 01, 02, 03 e 04 “SOLUÇÃO DE SEGURANÇA CIBERNÉTICA DISTRIBUÍDA NGFW TIPO I, II, III e IV” , caso compatível poderão ser utilizadas atuais controladoras existentes na SEMIT, Marca Fortinet, Modelos FG1800F/FG1100E/ FG200F/ FG100F, e ou por solução do mesmo fabricante que possua gerência centralizada, devendo atender aos requisitos descritos abaixo:
14.64.1. A solução de gerência centralizada deve suportar operação com elementos redundantes, não havendo disrupção do serviço mediante a falha de um elemento;
14.64.2. Deve operar como ponto central para automação e gerenciamento dos switches;
14.64.3. Deve realizar o gerenciamento de inventário de hardware, software e configuração dos Switches;
14.64.4. Deve possuir interface gráfica para configuração, administração e monitoração dos switches;
14.64.5. Deve apresentar graficamente a topologia da rede com todos os switches administrados para monitoramento, além de ilustrar graficamente status dos uplinks e dos equipamentos para identificação de eventuais problemas na rede;
14.64.6. Deve montar a topologia da rede de maneira automática;
14.64.7. Deve ser capaz de configurar os switches da rede;
14.64.8. Deve através da interface gráfica deve ser capaz de configurar as VLANs da rede e distribui-las automaticamente em todos os switches gerenciados;
14.64.9. Deve através da interface gráfica deve ser capaz de aplicar a VLAN nativa (untagged) e as VLANs permitidas (tagged) nas interfaces dos switches;
14.64.10. Deve através da interface gráfica deve ser capaz de aplicar as políticas de QoS nas interfaces dos switches;
14.64.11. Deve através da interface gráfica deve ser capaz de aplicar as políticas de segurança para autenticação 802.1X nas interfaces dos switches;
14.64.12. Através da interface gráfica deve ser capaz de aplicar ferramentas de segurança, tal como DHCP Snooping, nas interfaces dos switches;
14.64.13. Deve através da interface gráfica deve ser capaz de realizar configurações do protocolo Spanning Tree nas interfaces dos switches, tal como habilitar ou desabilitar os seguintes recursos: Loop Guard, Root Guard e BPDU Guard;
14.64.14. Deve através da interface gráfica deve ser capaz de aplicar políticas de segurança e controle de tráfego para filtrar o tráfego da rede;
14.64.15. A solução de gerência centralizada deve ser capaz de identificar as aplicações acessadas na rede através de análise DPI (Deep Packet Inspection);
14.64.16. Deve ser capaz de configurar parâmetros SNMP dos switches;
14.64.17. A solução de gerência centralizada deve gerenciar as atualizações de firmware (software) dos switches gerenciados, recomendando versões de software para cada switch, além de permitir a atualização dos switches individualmente;
14.64.18. A solução de gerência centralizada deve permitir o envio automático de e-mails de notificação para os administradores da rede em caso de eventos de falhas;
14.64.19. A solução de gerência centralizada deve apresentar graficamente informações sobre erros nas interfaces dos switches;
14.64.20. A solução deve apresentar graficamente informações sobre disponibilidade dos switches;
14.64.21. Deve prover indicadores de saúde dos elementos críticos do ambiente;
14.64.22. Deve registrar eventos para auditoria de todos os acessos e mudanças de configuração realizadas por usuários;
14.64.23. Deve realizar as funções de gerenciamento de falhas e eventos dos switches da rede;
14.64.24. Deve possuir API no formato REST;
15. ITEM 14 - SOLUÇÃO DE SEGURANÇA DE APLICAÇÕES WEB - WAF
15.1. CARACTERÍSTICAS E FUNCIONALIDADES GERAIS
15.1.1. A solução deve ser entregue em appliance ou no formato de solução virtual, compatível com as plataformas VMware, Microsoft Hyper-V, Citrix XenServer, Open Source Xen, VirtualBox, KVM, no caso de solução virtualizada a responsabilidade pela implantação de servidor/hardware com licenciamento necessário será da CONTRATANTE.
15.1.2. Poderá ser entregue em equipamento único ou com composição de equipamentos do mesmo fabricante, para atender as funcionalidades exigidas.
15.1.3. Deve possuir e estar licenciado durante a vigência contratual de 36 (trinta e seis meses), minimamente com as seguintes funcionalidades: Antivírus, Reputação de IP, Sandbox , Serviço de defesa de preenchimento de credenciais e análise avançada de ameaças
15.1.4. Deve ser fornecida Solução Centralizada de Armazenamento de Logs e Relatórios, caso compatível poderá ser utilizada atual solução existente na SEMIT/PMS, Marca Fortinet, Modelo FAZ-3700G.
15.2. REQUISITOS MÍNIMOS DE PERFORMANCE
15.2.1. Deve possuir throughput mínimo para HTTP de 400(quatrocentos) Mbps;
15.2.2. Deve possuir suportar no mínimo para 04(quatro) vCPU;
15.2.3. Deve suportar quantidade ilimitada de aplicações protegidas;
15.3. FUNCIONALIDADES DE REDE
15.3.1. A solução deve ser capaz de ser implementada no modo Proxy (Transparente e Reverso), Passivo, ou “Sniffer”
15.3.2. (Offline) e Inline Transparente (Bridge).
15.3.3. A solução deve ser capaz de ser implementada com protocolo WCCP.
15.3.4. Suportar VLANs no padrão IEEE 802.1q.
15.3.5. Deve implementar o protocolo de negociação Link Aggregation Control Protocol (LACP) - IEEE 802.3ad.
15.3.6. Suportar endereçamento IPv4 e IPv6 nas interfaces físicas e virtuais (VLANs).
15.3.7. A solução deve suportar roteamento por política (policy route).
15.4. FUNCIONALIDADES DE GERÊNCIA
15.4.1. O sistema operacional / firmware deve suportar interface gráfica web para a configuração das
funções do sistema operacional, utilizando navegadores disponíveis gratuitamente e protocolo HTTPS, e através de CLI (interface de linha de comando), acessando localmente, via porta de console, ou remotamente via SSH.
15.4.2. Deve possuir administração baseada em interface web HTTPS.
15.4.3. Possuir auto-complementação de comandos na CLI.
15.4.4. Possuir ajuda contextual na CLI.
15.4.5. A solução deve possuir Interface Gráfica com informações sobre o sistema Ex: (Informações do Cluster, hostname, número de série, modo de operação, tempo em serviço, versão do firmware).
15.4.6. Deve ser possível visualizar através da interface gráfica de gerência informações de licenças e assinaturas.
15.4.7. Deve prover, na interface de gerência, as seguintes informações do sistema para cada gateway: consumo de CPU e estatísticas das conexões.
15.4.8. Deve ser possível visualizar na interface de gerência as informações de consumo de memória.
15.4.9. Deve ser possível visualizar na interface de gerência ou CLI as informações de utilização de disco de log.
15.4.10. Deve possuir ferramenta, na interface gráfica de gerência (dashboard) que permita visualizar os últimos logs de ataque detectados/bloqueados.
15.4.11. Deve prover as seguintes informações, na interface de gráfica de gerência: estatísticas de throughput HTTP em tempo real, estatísticas dos eventos de ataque detectados/bloqueados, estatísticas de requisições HTTP em tempo real e últimos logs de eventos do sistema.
15.4.12. Possuir na interface gráfica estatísticas de conexões concorrentes e por segundo, de políticas de segurança do sistema.
15.4.13. Possuir um painel de visualização com informações das interfaces de rede do sistema.
15.4.14. A configuração de administração da solução deve possibilitar a utilização de perfis.
15.4.15. Deve ser possível executar e restaurar backup via interface Web (GUI).
15.4.16. Deve ter a opção para criptografar o backup.
15.4.17. Deve ser possível executar e restaurar backup utilizando-se um ou mais dos seguintes protocolos: FTP, SFTP ou TFTP,ou HTTPS
15.4.18. Deve ser possível instalar um firmware alternativo em disco e inicializá-lo manualmente em caso de falha do firmware principal.
15.4.19. Deve ter suporte ao protocolo de monitoração SNMP v1, SNMP v2c e SNMP v3.
15.4.20. Deve ser capaz de realizar notificações de eventos de segurança através de e-mail, traps SNMP e Syslog.
15.4.21. A solução Deve ter a capacidade de armazenar logs localmente em disco e em servidor externo via protocolo SYSLOG.
15.4.22. Ter a capacidade de armazenar logs em appliance remoto.
15.4.23. A solução deve ter a capacidade de adicionar identificadores customizados nos registros syslog antes de envio, como hostname, atrelados a valores fixos ou variáveis.
15.4.24. A solução deve ter a capacidade de enviar alertas por e-mail de eventos baseados em severidades e/ou categorias.
15.4.25. A solução deve possuir dados analíticos contendo localização geográfica dos clientes web.
15.4.26. A solução deve possuir dados analíticos, sendo possível visualizar a contagem total de ataques e percentual de cada país de origem, o volume total de tráfego em bytes e percentual de cada país
de origem e o total de acessos (hits) e percentual de cada país de origem.
15.4.27. Deve ter a capacidade de gerar relatórios detalhados baseados em tráfego/acessos/atividades do usuário.
15.4.28. Deve ter suporte a RESTful API para gerenciamento de configurações.
15.4.29. Deve suportar todas as funcionalidades para comunicação HTTP/2
15.5. FUNCIONALIDADES DE AUTENTICAÇÃO
15.5.1. Os usuários devem ser capazes de autenticar através do cabeçalho de autorização HTTP / HTTPS.
15.5.2. Os usuários devem ser capazes de autenticar através de formulários HTML embutidos.
15.5.3. A solução Deve ser capaz de autenticar usuários através de certificados digitais pessoais.
15.5.4. Deve possuir base local para armazenamento e autenticação contas de usuários.
15.5.5. A solução deve ter a capacidade de autenticar usuários em bases externas/remotas LDAP e RADIUS.
15.5.6. Os usuários devem ser capazes de autenticar através de contas de usuários em base remota NTLM.
15.5.7. A solução deve ser capaz de criar grupos de usuários para acessos semelhantes na autenticação.
15.6. FUNCIONALIDADES DE WEB APPLICATION FIREWALL
15.6.1. Deve ser capaz de identificar e bloquear ataques através de um banco de dados de assinaturas de vírus e IP reputation, atualizado de forma automática.
15.6.2. Deve implementar recursos de Sandbox para análise de malware moderno;
15.6.3. Deve implementar recurso de machine learning, onde será permitido implementar proteção para um servidor ou grupo de servidores de aplicação web, de forma automatizada através da análise da utilização da aplicação, fazendo a descoberta da estrutura e padrões e padrões de uso, buscando separar o comportamento anormal do abusivo, detectando anomalias e tentativas de ataque.
15.6.4. Deve implementar proteção contra a lista de técnicas/ataques listados no OWASP 10 (Open Web Application security Project)
15.6.5. Deve implementar recursos embarcados de antivírus para análise de arquivos, detecção e bloqueio de malwares que possam comprometer os servidores possuindo integração com a nuvem do fabricante para obter atualizações, enviar e receber amostras de malware para análise/verificação.
15.6.6. Ter a capacidade de criação de assinaturas de ataque customizáveis.
15.6.7. Ter a capacidade de proteção para ataques do tipo Adobe Flash binary (AMF) protocol.
15.6.8. Ter a capacidade de proteção para ataques do tipo Botnet.
15.6.9. Ter a capacidade de proteção para ataques do tipo Browser Exploit Against SSL/TLS (BEAST).
15.6.10. A solução Deve possuir funcionalidade de proteção positiva contra ataques como acesso por força bruta.
15.6.11. Deve suportar detecção a ataques de Clickjacking.
15.6.12. Deve suportar detecção a ataques de alteração de cookie.
15.6.13. Deve identificar e prevenir ataques do tipo Credit Card Theft.
15.6.14. Deve identificar e prevenir ataque Cross Site Request Forgery (CSRF).
15.6.15. A solução deve possuir funcionalidade de proteção positiva contra ataques como cross site scripting (XSS).
15.6.16. Deve possuir proteção contra ataques de Denial of Service (DoS).
15.6.17. Deve possuir a capacidade de proteção para ataques do tipo HTTP header overflow.
15.6.18. Deve possuir a capacidade de proteção para ataques do tipo Local File inclusion (FLI).
15.6.19. Deve possuir a capacidade de proteção para ataques do tipo Man-in-the-middle (MITM).
15.6.20. Deve possuir a capacidade de proteção para ataques do tipo Remote File Inclusion (RFI).
15.6.21. Deve possuir a capacidade de proteção para ataques do tipo Server Information Leakage.
15.6.22. Deve possuir proteção contra envios de comandos SQL escondidos nas requisições enviadas a bases de dados (SQL Injection).
15.6.23. Deve possuir a capacidade de proteção para ataques do tipo Malformed XML.
15.6.24. Deve Identificar e prevenir ataques do tipo Low-rate DoS.
15.6.25. Xxxx possuir prevenção contra Slow POST attack.
15.6.26. Deve proteger contra ataques Slowloris.
15.6.27. Deve possuir a capacidade de proteção para ataques do tipo SYN flood.
15.6.28. Deve possuir a capacidade de proteção para ataques do tipo Forms Tampering.
15.6.29. A solução deve possuir funcionalidade de proteção positiva contra ataques de manipulação de campo escondido.
15.6.30. Deve possuir a capacidade de proteção para ataques do tipo Directory Traversal.
15.6.31. Deve possuir a capacidade de proteção do tipo Access Rate Control.
15.6.32. Deve possuir a habilidade de configurar proteção do tipo TCP SYN flood-style para prevenção de DoS para qualquer política, através de Syn Cookie e Half Open Threshold.
15.6.33. Deve permitir configurar regras de bloqueio a métodos HTTP indesejados.
15.6.34. Deve permitir que sejam configuradas regras de limite de upload por tamanho de arquivo.
15.6.35. Deve permitir que o administrador bloqueie o tráfego de entrada e/ou tráfego de saída com base nos países, sem a necessidade de gerir manualmente os ranges de endereços IP correspondentes a cada país.
15.6.36. Deve permitir configurar listas negras de bloqueio e listas brancas de confiança, baseadas em endereço IP de origem.
15.6.37. Deve permitir a liberação temporária ou definitiva (whitelist) de endereços IP bloqueados por terem originados ataques detectados pela solução.
15.6.38. Deve permitir adicionar, automaticamente ou manualmente, em uma lista de bloqueio, os endereços IP de origem, de acordo com a base de IP Reputation.
15.6.39. Deve possuir a capacidade de Prevenção ao Vazamento de Informações (DLP), bloqueando o vazamento de informações de cabeçalho HTTP.
15.6.40. Deve possuir a funcionalidade de proteger o website contra ações de desfiguração (defacement), com restauração automática e rápida do site caso ocorra à falha.
15.6.41. Deve possuir a funcionalidade de antivírus para inspeção de tráfego e arquivos.
15.6.42. Xxxx possuir a capacidade de investigar e analisar todo o tráfego HTTP para atestar se está em conformidade com a respectiva RFC, bloqueando ataques e tráfego em não-conformidade.
15.6.43. Deve ser capaz de fazer aceleração de SSL, onde os certificados digitais são instalados na solução e as requisições HTTP são enviadas aos servidores sem criptografia.
15.6.44. A solução deve ser capaz de funcionar como Terminador de sessões SSL para a aceleração de tráfego.
15.6.45. Deve para SSL/TLS offload suportar no mínimo TLS 1.0, 1.1, 1.2 e 1.3.
15.6.46. A solução deve ter a capacidade de armazenar certificados digitais de CA's.
15.6.47. A solução deve ser capaz de gerar CSR para ser assinado por uma CA.
15.6.48. A solução deve ser capaz de validar os certificados que são válidos e não foram revogados por uma lista de certificados revogados (CRL).
15.6.49. A solução deve conter as assinaturas de robôs conhecidos como link checkers, indexadores de web, search engines, spiders e web crawlers que podem ser colocados nos perfis de controle de acesso, bem como resetar tais conexões.
15.6.50. A solução deve ter um sistema de reputação de endereços IP públicos conhecidos como fontes de ataques DDoS, botnets, spammers, etc. Tal sistema deve ser atualizado automaticamente.
15.6.51. A solução Deve ser capaz de limitar o total de conexões permitidas para cada servidor real de um pool de servidores.
15.6.52. A solução deve permitir a customização ou redirecionar solicitações e respostas HTTP no HTTP Host, Request URL HTTP, HTTP Referer, HTTP Body e HTTP Location.
15.6.53. A solução deve permitir criar regras definindo a ordem em que as páginas devem ser acessadas para prevenir ataques como cross-site request forgery (CSRF).
15.6.54. A solução deve ter a capacidade de definir restrições a métodos HTTP.
15.6.55. A solução deve ter a capacidade de proteger contra a detecção de campos ocultos.
15.6.56. Deve permitir que sejam criadas assinaturas customizadas de ataques e DLP, através de expressões regulares.
15.6.57. A solução deve incluir capacidade de atuar como um scanner de vulnerabilidades ou permitir a integração com scanners de vulnerabilidade de terceiros para diagnóstico e identificação de ameaças nos servidores web, software desatualizado e potenciais buffers overflows,
15.6.58. Deve gerar perfil de proteção automaticamente a partir de relatório em formato XML gerado por scanner de vulnerabilidade de terceiros.
15.6.59. A solução deve gerar um relatório da análise de vulnerabilidades no formato HTML.
15.6.60. A solução deve permitir a exclusão de URLs na análise de vulnerabilidades.
15.6.61. Deve ser capaz de fazer compressão de conteúdo HTTP, para reduzir a quantidade de informações enviadas ao cliente.
15.6.62. Deve suportar redireção e reescrita de requisições e respostas HTTP.
15.6.63. Deve permitir redirecionar requisições HTTP para HTTPS.
15.6.64. Deve permitir reescrever a linha URL no cabeçalho de uma requisição HTTP.
15.6.65. Deve permitir reescrever o campo "Host:" no cabeçalho de uma requisição HTTP.
15.6.66. Deve permitir reescrever o campo "Referer:" no cabeçalho de uma requisição HTTP.
15.6.67. Deve permitir redirecionar requisições para outro web site.
15.6.68. Permitir enviar resposta HTTP 403 Forbidden para requisições HTTP.
15.6.69. Deve permitir reescrever o parâmetro "Location:" no cabeçalho HTTP de uma resposta de redireção HTTP de um servidor web.
15.6.70. Deve permitir reescrever o corpo ("body") de uma resposta HTTP de um servidor web.
15.6.71. Deve permitir adicionar o campo X-Forwarded-For para identificação do endereço real do cliente quando no modo de proxy reverso.
15.6.72. A solução deve suportar regras para definir se as solicitações HTTP serão aceitas com base na URL e a origem do pedido e, se necessário, aplicar uma taxa específica de transferência (rate limit).
15.6.73. A solução deve suportar o mecanismo de combinação de controle de acesso e autenticação utilizando mecanismos como HTML Form, Basic e Suporte a SSO, métodos como LDAP e RADIUS para consultas e integração dos usuários da aplicação.
15.6.74. Possuir capacidade de caching para aceleração web.
15.6.75. Deve permitir ao Administrador a criação de novas assinaturas e/ou alteração de assinaturas já existentes.
15.6.76. Deve suportar no mínimo 500 regras de reescrita URL distintas
15.6.77. Deve suportar no mínimo 250 políticas de assinatura distintas
15.6.78. Deve suportar no mínimo 500 grupos ou pools de servidores, e cada pool deve suportar no mínimo 1000 membros
15.6.79. Deve suportar no mínimo 1000 IPs virtuais configurados e ativos simultaneamente
15.6.80. Deve ser capaz de restringir acesso quando as requisições não tiverem um cabeçalho HTTP específico pré-configurado.
15.6.81. Deve ser capaz de limitar o número de usuários/origens simultâneos acessando a mesma conta/sessão/login.
15.6.82. Deve ser capaz de criptografar URLs para prevenir acesso forçado e garantir que a estrutura de diretórios interna da aplicação web não seja revelada aos usuários.
15.6.83. Deve ser capaz de adicionar múltiplos servidores ADFS em um pool de servidores
15.6.84. Deve implementar recursos de proteção de API (Application Programming Interface) através de Machine learning, implementando a análise dinâmica das chamadas de API para detecção de anomalias e bloqueando ataques direcionados a aplicações baseadas em microserviços.
15.7. FUNCIONALIDADES BALANCEAMENTO DE CARGA
15.7.1. A solução deve incluir funcionalidade de balanceamento de carga entre servidores web.
15.7.2. Deve possuir a habilidade de configurar portas não-padrão para aplicação web HTTP e HTTPS.
15.7.3. Deve possuir a capacidade de balancear/distribuir tráfego e rotear o conteúdo através de vários servidores web.
15.7.4. A solução deve permitir criar grupos de servidores (Server Farm / Pool) para distribuir as conexões dos usuários.
15.7.5. Deve suportar algoritmo Round Robin para balanceamento de carga de servidores.
15.7.6. Deve suportar algoritmo Weighted Round Robin para balanceamento de carga de servidores.
15.7.7. Deve suportar algoritmo Least Connections para balanceamento de carga de servidores.
15.7.8. A solução deve ser capaz de criar servidores virtuais que definem a interface de rede/bridge e endereço IP por onde o tráfego destinado ao Server Pool é recebido.
15.7.9. Os servidores virtuais devem entregar o tráfego à um único servidor web e também possuir a opção de distribuir as sessões/conexões entre os servidores web do Server Pool.
15.7.10. Deve ser possível especificar o número máximo de conexões TCP simultâneas para um determinado servidor membro do Server Pool.
15.7.11. Deve permitir teste de disponibilidade de servidor web através do método TCP.
15.7.12. Deve permitir teste de disponibilidade de servidor web através do método ICMP ECHO_REQUEST (ping).
15.7.13. Deve permitir teste de disponibilidade de servidor web através do método TCP Half Open.
15.7.14. Deve permitir teste de disponibilidade de servidor web através do método TCP SSL.
15.7.15. Deve permitir teste de disponibilidade de servidor web através do método HTTP.
15.7.16. Deve permitir teste de disponibilidade de servidor web através do método HTTPS.
15.7.17. Nos testes de disponibilidade HTTP e HTTPS, permitir indicar a URL exata a ser testada.
15.7.18. Nos testes de disponibilidade HTTP e HTTPS, permitir escolher entre os métodos HEAD, GET e POST.
15.7.19. Nos testes de disponibilidade HTTP e HTTPS, permitir indicar o nome do campo HTTP "host" a ser testado.
15.7.20. Suportar roteamento das requisições dos clientes web baseado em conteúdo HTTP, através de “Host”.
15.7.21. Suportar roteamento das requisições dos clientes web baseado em conteúdo HTTP, através de “URL”.
15.7.22. Suportar roteamento das requisições dos clientes web baseado em conteúdo HTTP, através de “Parâmetro HTTP”.
15.7.23. Suportar roteamento das requisições dos clientes web baseado em conteúdo HTTP, através de “Referer”.
15.7.24. Suportar roteamento das requisições dos clientes web baseado em conteúdo HTTP, através de “Endereço IP de Origem”.
15.7.25. Suportar roteamento das requisições dos clientes web baseado em conteúdo HTTP, através de “Cabeçalho”.
15.7.26. Suportar roteamento das requisições dos clientes web baseado em conteúdo HTTP, através de “Cookie”.
15.7.27. Suportar roteamento das requisições dos clientes web baseado em conteúdo HTTP, através de “Valor de campo
15.7.28. do Certificado X509”.
15.7.29. Deve implementar Cache de Conteúdo para HTTP, permitindo que objetos sejam armazenados e requisições HTTP sejam respondidas diretamente pela solução.
15.7.30. A solução deve ser capaz de balancear as sessões novas, mas preservar sessões existentes no mesmo servidor, implementando persistência por endereço IP de origem.
15.7.31. A solução deve ser capaz de balancear as sessões novas, mas preservar sessões existentes no mesmo servidor, implementando persistência analisando parâmetros do header HTTP.
15.7.32. A solução deve ser capaz de balancear as sessões novas, mas preservar sessões existentes no mesmo servidor, implementando persistência analisando a URL acessada.
15.7.33. A solução deve ser capaz de balancear as sessões novas, mas preservar sessões existentes no mesmo servidor, implementando persistência por cookie – método cookie insert e cookie rewrite.
15.7.34. A solução deve ser capaz de balancear as sessões novas, mas preservar sessões existentes no mesmo servidor, implementando persistência por embedded cookie (cookie original mais porção randômica).
15.7.35. A solução deve ser capaz de balancear as sessões novas, mas preservar sessões existentes no mesmo servidor, implementando persistência baseada em Reescrita de Cookie.
15.7.36. A solução deve ser capaz de balancear as sessões novas, mas preservar sessões existentes no mesmo servidor, implementando persistência baseada em Cookie Persistente.
15.7.37. A solução ser capaz de balancear as sessões novas, mas preservar sessões existentes no mesmo servidor, implementando persistência baseada em ASP Session ID.
15.7.38. A solução deve ser capaz de balancear as sessões novas, mas preservar sessões existentes no
mesmo servidor, implementando persistência baseada em PHP Session ID.
15.7.39. A solução deve ser capaz de balancear as sessões novas, mas preservar sessões existentes no mesmo servidor, implementando persistência baseada em JSP Session ID.
15.7.40. A solução deve ser capaz de balancear as sessões novas, mas preservar sessões existentes no mesmo servidor, implementando persistência por sessão SSL.
15.7.41. A solução deve ser capaz de enviar código de erro 503 caso o helth-check dos servidores estiver desabilitado e/ou o servidor/serviço de retaguarda não estiver responsivo.
15.7.42. Deve suportar FWMARK (marcação de tráfego).
16. ITEM 15 - SOLUÇÃO DE SEGURANÇA DE ENDPOINT - EDR
16.1. Deverá permitir a instalação, gerencia e atualizações das funcionalidades de 500 (quinhentos) endpoints, durante toda vigência contratual 36 (trinta e seis) meses.
16.2. Requisitos do Agente:
16.2.1. A solução proposta deve ser compatível com os seguintes sistemas operacionais: Windows (versões 32 e 64 bits) XP SP2 / SP3, 7, 8, 8.1 e 10
16.2.2. A solução proposta deve ser compatível com os seguintes sistemas operacionais: Windows Server 2003 R2 SP2, 2008 R1 SP2, 2008 R2, 2012, 2012 R2, 2016 e 2019
16.2.3. A solução proposta deve ser compatível com os seguintes sistemas operacionais: versões macOS: Yosemite (10.10), El Capitan (10.11), Sierra (10.12), High Sierra (10.13), Mojave (10.14) e Catalina (10.15)
16.2.4. "A solução proposta deve ser compatível com os seguintes sistemas operacionais: Versões do Linux: RedHat Enterprise Linux e CentOS 6.8, 6.9, 6.10, 7.2, 7.3, 7.4, 7.5, 7.6 e 7.7 e Ubuntu LTS 16.04.5, 16.04.6,
16.2.5. § servidor 18.04.1 e 18.04.2, 64 bits"
16.2.6. A solução proposta deve ser compatível com os seguintes sistemas operacionais: Ambientes de Virtual Desktop Infrastructure (VDI) em VMware E Citrix. VMware Horizons 6 e 7 e Citrix XenDesktop 7
16.2.7. A solução proposta deve ser compatível com os seguintes sistemas operacionais: Oracle Linux OL (antigo OEL)
16.2.8. A solução proposta deve ter um consumo máximo de 120 MB de memória RAM
16.2.9. A solução proposta deve ter um consumo médio de menos de 2% do uso da CPU
16.2.10. A solução proposta deve consumir menos de 20 MB de espaço em disco
16.2.11. A solução proposta deve oferecer suporte à implantação em massa por meio de ferramentas como MS System Center, JAMF e Satellite.
16.2.12. A solução proposta deve ter a capacidade de atualizar o terminal sem interação do usuário e sem exigir uma reinicialização.
16.2.13. A solução proposta deve ter proteção "Anti-adulteração" no Agente
16.2.14. A solução proposta deve funcionar sem depender de assinaturas hash locais conhecidas para a detecção de arquivos maliciosos.
16.2.15. A solução proposta deve ser capaz de registrar em tempo real informações do processo e informações adicionais, como o conhecimento do usuário associado aos eventos
16.2.16. A solução proposta deve ter a opção de definir a senha para desinstalar o agente no terminal
16.2.17. A solução proposta deve ser capaz de gerar um instalador Windows pré-configurado. Esta configuração deve permitir a instalação sem a necessidade de interação ou configuração do usuário.
16.2.18. O coletor que será instalado nos terminais da solução proposta deve ser capaz de trabalhar por trás de um proxy.
16.3. Requisito - Detecção de malware
16.3.1. A solução proposta deve ser capaz de funcionar no modo "offline" sem que o Agente esteja conectado à rede corporativa
16.3.2. A solução proposta deve ser capaz de detectar processos em execução, inícios de processos, paradas de processos e interações entre processos.
16.3.3. A solução proposta deve ser capaz de detectar, eliminar e retornar ao seu valor inicial as alterações feitas por processos maliciosos no registro do PC.
16.3.4. A solução proposta deve ser capaz de detectar as solicitações de DNS enviadas do dispositivo.
16.3.5. A solução proposta deve ser capaz de detectar conexões de rede a partir do dispositivo.
16.3.6. A solução proposta deve ser capaz de detectar atividades suspeitas associadas a arquivos DLL.
16.3.7. A solução proposta deve ser capaz de incorporar inteligência de ameaças ao esquema de detecção.
16.3.8. A solução proposta deve ser capaz de incorporar as técnicas MITER ATT & CK no esquema de detecção e mostrar quais dessas técnicas foram utilizadas.
16.3.9. A solução proposta deve ter a capacidade de pesquisar ameaças nas estações do Windows usando indicadores de comprometimento (IOC), como: nome do arquivo e hash do arquivo, etc.
16.3.10. A solução proposta deve ter a capacidade de pesquisar ameaças em estações Windows usando indicadores de comprometimento (IOC), como ações relacionadas a arquivos (Criação, Exclusão, Renomear).
16.3.11. A solução proposta deve ter a capacidade de pesquisar ameaças em estações Windows usando indicadores de comprometimento (IOC), como ações relacionadas a processos (Terminação de Processo, Criação de Processo, Carregamento de Executáveis)
16.3.12. A solução proposta deve ter a capacidade de pesquisar ameaças em estações Windows usando indicadores de comprometimento (IOC), como ações relacionadas ao uso da rede (Socket Connect, Socket Close, Socket Brind)
16.3.13. A solução proposta deve ter a capacidade de pesquisar ameaças em estações Windows usando indicadores de comprometimento (IOC), como ações relacionadas aos logs do Windows (Log de eventos).
16.3.14. A solução proposta deve ter a capacidade de pesquisar ameaças nas estações do Windows usando indicadores de comprometimento (IOC), como ações relacionadas ao registro do Windows (criação de chave, exclusão de chave, conjunto de valores)
16.3.15. A solução proposta deve ter a capacidade de realizar consultas de texto livre para filtrar as informações disponíveis para a caça de ameaças.
16.3.16. A solução proposta deve ter a capacidade de armazenar pesquisas realizadas para serem reutilizadas no futuro
16.3.17. A solução proposta deve ter a capacidade de agendar pesquisas armazenadas
16.3.18. A solução proposta deve identificar atividades maliciosas conhecidas
16.3.19. A solução proposta deve ter a capacidade de receber atualizações diárias de inteligência
16.3.20. A solução proposta deve ter a capacidade de categorizar os eventos detectados em diferentes categorias (Ex: Malicioso, Suspeito, Inconclusivo, Provavelmente Seguro)
16.3.21. A solução proposta deve ter a capacidade de coexistir com outras soluções de segurança de endpoint do tipo de antivírus tradicional ou de nova geração.
16.3.22. Requisito - Prevenção de malware
16.3.23. A solução proposta deve ter a capacidade de prevenir a execução de arquivos maliciosos
16.3.24. A solução proposta deve incorporar um mecanismo antivírus de última geração (NGAV) baseado no kernel com capacidade de "Aprendizado de Máquina".
16.3.25. A solução proposta deve ter a capacidade de controlar dispositivos USB
16.3.26. A solução proposta deve ter a capacidade de criar exceções para dispositivos USB com base no nome do dispositivo
16.3.27. A solução proposta deve ter a capacidade de criar exceções para dispositivos USB com base no fornecedor do dispositivo
16.3.28. A solução proposta deve ter a capacidade de criar exceções para dispositivos USB com base no número de série do dispositivo.
16.3.29. A solução proposta deve ter a capacidade de criar exceções para dispositivos USB com base em uma combinação de: nome do dispositivo, fornecedor, número de série
16.3.30. A solução proposta deve ser capaz de bloquear o tráfego malicioso de exfiltração de dados
16.3.31. A solução proposta deve ser capaz de bloquear o tráfego de comunicação malicioso para C&C (Comando e Controle)
16.3.32. A solução proposta deve ser capaz de impedir violações de segurança e tentativas de ransomware em tempo real
16.3.33. A solução proposta deve ser capaz de evitar a criptografia de disco causada por ransomware e modificação de arquivos ou registro de dispositivos
16.3.34. A solução proposta deve permitir que as políticas nela contidas sejam modificadas permitindo vários estados tais como: Ativo, Desativado ou apenas criar "logs" para as regras de segurança contidas nestes
16.3.35. A solução proposta deve ser capaz de ser configurada em modo de simulação onde nenhum bloqueio é feito, mas todas as atividades maliciosas são registradas.
16.3.36. A solução proposta deve ser capaz de permitir a modificação das regras de detecção de eventos maliciosos de forma que essas regras apenas armazenem um registro ou fiquem em modo de bloqueio
16.3.37. A solução proposta deve ser capaz de permitir verificações periódicas dos arquivos contidos nos dispositivos com o Agente instalado.
16.4. Requisito - Difusão (Pós-infecção)
16.4.1. A solução proposta deve permitir o isolamento automático do tráfego de rede de um dispositivo onde foi encontrada uma atividade causada por malware.
16.4.2. A solução proposta deve permitir alterar as políticas atribuídas de um dispositivo onde uma atividade causada por malware foi encontrada
16.4.3. A solução proposta deve permitir o bloqueio de atividades realizadas por arquivos maliciosos
16.4.4. A solução proposta deve ter a capacidade de criar exceções para processos com base na localização do arquivo (Caminho do Arquivo)
16.4.5. A solução proposta deve ter a capacidade de criar exceções para processos com base no destino do tráfego gerado pelo processo.
16.4.6. A solução proposta deve ter a capacidade de criar exceções para os processos baseados no usuário que o processo executou
16.4.7. A solução proposta deve ter a capacidade de criar exceções manualmente para falsos positivos para marcar a atividade como um falso positivo e evitar a ocorrência de falhas futuras
16.4.8. A solução proposta deve ter a capacidade de reclassificar automaticamente a atividade como um
falso positivo e evitar a ocorrência de detecções semelhantes.
16.4.9. A solução proposta deve permitir a criação de exceções de eventos com base em endereços IP, aplicações e protocolos
16.5. Requisito - Resposta ao Incidente
16.5.1. A solução proposta deve permitir um histórico dos eventos por no mínimo 6 meses
16.5.2. A solução proposta deve armazenar metadados gerados pelos dispositivos para que possam ser usados em investigações forenses.
16.5.3. A solução proposta deve permitir a integração com plataformas SIEMs (Security Information and Event Management) através de um syslog
16.5.4. A solução proposta deve ter a capacidade de obter instantâneos de memória ou "dumps" de memória que permitam a realização de processos forenses.
16.5.5. A solução proposta deve ter a capacidade de abrir tickets em plataformas de gerenciamento como ServiceNow e JIRA
16.5.6. A solução proposta deve permitir a integração através de API onde tem a capacidade de entregar informações geradas em um evento como: endereço IP, nome do host, usuário, data / hora ocorrida, atividade suspeita, etc.) para permitir a integração via API
16.5.7. A solução proposta deve ter a capacidade de encerrar um processo com base em sua classificação
16.5.8. A solução proposta deve ter a capacidade de excluir um arquivo com base em sua classificação
16.5.9. A solução proposta deve ser a capacidade de restaurar as configurações de registro básicas com base na classificação de atividade predefinida
16.5.10. A solução proposta deve ter a capacidade de isolar os dispositivos infectados da rede.
16.5.11. A solução proposta deve ter a capacidade de restringir automaticamente o acesso do dispositivo à rede de acordo com a classificação (Malicioso, Suspeito, etc.) do processo detectado
16.5.12. A solução proposta deve obter visibilidade total da cadeia de ataques e alterações maliciosas
16.5.13. A solução proposta deve permitir a limpeza automática do dispositivo e reverter alterações maliciosas, mantendo o tempo de atividade do dispositivo.
16.5.14. A solução proposta deve permitir a assinatura de serviços opcionais de detecção e resposta a incidentes (Ex: serviços gerenciados de detecção e resposta)
16.5.15. A solução proposta deve permitir o envio de executáveis para análise em um sandbox, a fim de determinar se são maliciosos ou inofensivos.
16.5.16. A solução proposta deve fornecer vários mecanismos de proteção, incluindo o encerramento de um processo, a exclusão de um arquivo malicioso, o bloqueio de uma conexão de rede
16.6. Requisito - Controle de Vulnerabilidade e Comunicação
16.6.1. A solução proposta deve ter a capacidade de descobrir aplicativos que estão se comunicando através da rede e que representam risco para o terminal
16.6.2. A solução proposta deve ter capacidade para realizar um patch virtual, através da restrição de acessos de comunicação nas aplicações vulneráveis.
16.6.3. A solução proposta deve permitir a redução das superfícies de ataque utilizando políticas de comunicação proativas baseadas no risco de acordo com o CVE e a qualificação ou reputação que uma aplicação possa ter.
16.6.4. A solução proposta deve ter a capacidade de impedir que aplicativos não autorizados se comuniquem pela rede.
16.6.5. A solução proposta deve ter a capacidade de criar políticas que tenham a capacidade de impedir a comunicação de aplicativos de acordo com a versão do aplicativo instalado.
16.6.6. A solução proposta deve ser capaz de detectar e identificar todas as aplicações nos dispositivos que se comunicam na rede.
16.6.7. A solução proposta deve ser capaz de fornecer informações sobre o uso de aplicativos de rede mostrando, por exemplo, quais dispositivos geram tráfego para um aplicativo.
16.6.8. A solução proposta deve ser capaz de visualizar e entregar informações sobre o uso dos aplicativos de rede mostrando informações como os destinos IP do tráfego gerado pelo aplicativo.
16.7. Requisito - Cenários de Ataque
16.7.1. A solução proposta deve identificar e prevenir tentativas de perseguição de privilégios
16.7.2. A solução proposta deve bloquear ataques de ransomware conhecidos
16.7.3. A solução proposta deve detectar malware desconhecido como RAT (Trojan de acesso remoto) por meio das atividades do malware e não de uma assinatura
16.7.4. A solução proposta deve proteger contra scripts Powershell maliciosos
16.7.5. A solução proposta deve proteger contra scripts CScript maliciosos
16.7.6. A solução proposta deve proteger contra macros maliciosas do Office
16.7.7. A solução proposta deve ter controle sobre dispositivos USB
16.8. Requisito - IOT
16.8.1. A solução proposta deve ter a capacidade de descobrir dispositivos IOT não gerenciados na rede
16.8.2. A solução proposta deve ter a capacidade de detectar dispositivos não gerenciados e protegidos pela solução com sistemas operacionais macOS / Linux / Windows
16.9. Requisito - Console de Administração
16.9.1. A solução proposta deve estar em conformidade com os padrões de segurança de dados da indústria de cartões de pagamento (PCI DSS)
16.9.2. A solução proposta deve estar em conformidade com o padrão HIPAA
16.9.3. A solução proposta deve estar em conformidade com o padrão GDPR
16.9.4. O console de gerenciamento da solução proposta deve permitir a integração com o "Active Directory" para garantir o cumprimento dos requisitos da política de senhas da empresa.
16.9.5. O console de administração da solução proposta deve permitir o uso de autenticação de dois fatores (2FA) para acessá-la.
16.9.6. O console de administração da solução proposta deve permitir a integração com SAML para autenticação do usuário no console de gerenciamento
16.9.7. O console de administração da solução proposta deve permitir o uso de funções granulares para administradores
16.9.8. O console de administração da solução proposta deve permitir o gerenciamento de ambientes multilocatários.
16.9.9. O console de administração da solução proposta deve permitir o gerenciamento por meio da API Full Restful
16.9.10. A solução proposta deve ser capaz de ser totalmente gerenciada na nuvem sem a necessidade de serviços locais
16.9.11. A solução proposta deve ser capaz de ser gerenciada em uma arquitetura híbrida usando serviços locais complementados com outros na nuvem.
16.9.12. O console de administração da solução proposta deve permitir a visualização dos eventos registrados nos dispositivos que requerem atenção.
16.9.13. O console de administração da solução proposta deve permitir a visualização da saúde dos Agentes instalados
16.9.14. O console de administração da solução proposta deve permitir a desinstalação remota do Agente instalado nos dispositivos
16.9.15. O console de administração da solução proposta deve permitir a desativação / ativação remota do Agente instalado nos dispositivos
16.9.16. O console de administração da solução proposta deve permitir a atualização remota do Agente instalado nos dispositivos
16.9.17. O console de administração da solução proposta deve permitir a criação de relatórios executivos contendo um resumo que descreva os eventos de segurança e o status do sistema.
16.9.18. O console de administração da solução proposta deve permitir a criação de grupos organizacionais de dispositivos nos quais cada grupo possa ter regras de proteção independentes dos demais.
16.9.19. O console de administração da solução proposta deve permitir a exportação dos logs locais gerados pelos Agentes a partir do mesmo console
16.9.20. O console de administração da solução proposta deve permitir a criação de relatórios de inventário dos Agentes implantados contendo informações como: Endereço IP, Nome do Host, Sistema Operacional, Endereço MAC, Versão do Agente instalado, Status do Agente, Último dia visto pelo console
16.9.21. O console de gerenciamento da solução proposta deve ter a visibilidade dos eventos gerados pelos dispositivos ou eventos de acordo com o processo executado.
16.9.22. O console de administração da solução proposta deve permitir a integração de um SMTP externo para envio de alertas por e-mail.
16.9.23. O console de administração da solução proposta deve permitir auditorias de alterações feitas por administradores / operadores. Essas auditorias também devem ser baixadas em formato CSV
16.9.24. A solução proposta deve exigir que uma senha seja desabilitada por um aplicativo de terceiros
16.9.25. A solução proposta deve permitir o isolamento de um dispositivo através da integração de um NAC de acordo com a categoria do evento detectado.
16.9.26. A solução proposta deve permitir adicionar endereços IP maliciosos detectados em um ou mais firewalls remotos integrados.
16.9.27. A solução proposta deve permitir a configuração de perfis nas informações coletadas para a função de caça a ameaças.
16.9.28. A solução proposta deve permitir exclusões de informações que não serão coletadas na função de caça a ameaças.
16.9.29. A solução proposta deve ser certificada pela Microsoft como uma solução antivírus e ser capaz de se integrar com o Windows Security Center
16.9.30. A solução proposta deve entregar informações geradas pelos serviços de inteligência para a tomada de decisão na nuvem sobre o evento detectado.
16.9.31. A solução proposta deve permitir que os serviços em nuvem recategorizem uma classificação de evento
16.9.32. A solução proposta deve permitir que os administradores desabilitem as notificações para um evento de descoberta
16.9.33. A solução proposta deve permitir que as funções de filtragem da web sejam realizadas bloqueando o acesso a páginas da web categorizadas como maliciosas.
17. ITEM 16 - UPGRADE SOLUÇÃO DE SEGURANÇA DE ENDPOINT - EDR
17.1. Deverá permitir o upgrade do “ITEM 16 - SOLUÇÃO DE SEGURANÇA DE ENDPOINT” – EDR para a
instalação, gerencia e atualizações das funcionalidades de 25 (vinte e cinco) endpoints adicionais, durante toda vigência contratual do item “ITEM 16 - SOLUÇÃO DE SEGURANÇA DE ENDPOINT – EDR.”
17.2. Requisitos do Agente:
17.2.1. A solução proposta deve ser compatível com os seguintes sistemas operacionais: Windows (versões 32 e 64 bits) XP SP2 / SP3, 7, 8, 8.1 e 10
17.2.2. A solução proposta deve ser compatível com os seguintes sistemas operacionais: Windows Server 2003 R2 SP2, 2008 R1 SP2, 2008 R2, 2012, 2012 R2, 2016 e 2019
17.2.3. A solução proposta deve ser compatível com os seguintes sistemas operacionais: versões macOS: Yosemite (10.10), El Capitan (10.11), Sierra (10.12), High Sierra (10.13), Mojave (10.14) e Catalina (10.15)
17.2.4. "A solução proposta deve ser compatível com os seguintes sistemas operacionais: Versões do Linux: RedHat Enterprise Linux e CentOS 6.8, 6.9, 6.10, 7.2, 7.3, 7.4, 7.5, 7.6 e 7.7 e Ubuntu LTS 16.04.5, 16.04.6,
17.2.5. § servidor 18.04.1 e 18.04.2, 64 bits"
17.2.6. A solução proposta deve ser compatível com os seguintes sistemas operacionais: Ambientes de Virtual Desktop Infrastructure (VDI) em VMware E Citrix. VMware Horizons 6 e 7 e Citrix XenDesktop 7
17.2.7. A solução proposta deve ser compatível com os seguintes sistemas operacionais: Oracle Linux OL (antigo OEL)
17.2.8. A solução proposta deve ter um consumo máximo de 120 MB de memória RAM
17.2.9. A solução proposta deve ter um consumo médio de menos de 2% do uso da CPU
17.2.10. A solução proposta deve consumir menos de 20 MB de espaço em disco
17.2.11. A solução proposta deve oferecer suporte à implantação em massa por meio de ferramentas como MS System Center, JAMF e Satellite.
17.2.12. A solução proposta deve ter a capacidade de atualizar o terminal sem interação do usuário e sem exigir uma reinicialização.
17.2.13. A solução proposta deve ter proteção "Anti-adulteração" no Agente
17.2.14. A solução proposta deve funcionar sem depender de assinaturas hash locais conhecidas para a detecção de arquivos maliciosos.
17.2.15. A solução proposta deve ser capaz de registrar em tempo real informações do processo e informações adicionais, como o conhecimento do usuário associado aos eventos
17.2.16. A solução proposta deve ter a opção de definir a senha para desinstalar o agente no terminal
17.2.17. A solução proposta deve ser capaz de gerar um instalador Windows pré-configurado. Esta configuração deve permitir a instalação sem a necessidade de interação ou configuração do usuário.
17.2.18. O coletor que será instalado nos terminais da solução proposta deve ser capaz de trabalhar por trás de um proxy.
17.3. Requisito - Detecção de malware
17.3.1. A solução proposta deve ser capaz de funcionar no modo "offline" sem que o Agente esteja conectado à rede corporativa
17.3.2. A solução proposta deve ser capaz de detectar processos em execução, inícios de processos, paradas de processos e interações entre processos.
17.3.3. A solução proposta deve ser capaz de detectar, eliminar e retornar ao seu valor inicial as alterações
feitas por processos maliciosos no registro do PC.
17.3.4. A solução proposta deve ser capaz de detectar as solicitações de DNS enviadas do dispositivo.
17.3.5. A solução proposta deve ser capaz de detectar conexões de rede a partir do dispositivo.
17.3.6. A solução proposta deve ser capaz de detectar atividades suspeitas associadas a arquivos DLL.
17.3.7. A solução proposta deve ser capaz de incorporar inteligência de ameaças ao esquema de detecção.
17.3.8. A solução proposta deve ser capaz de incorporar as técnicas MITER ATT & CK no esquema de detecção e mostrar quais dessas técnicas foram utilizadas.
17.3.9. A solução proposta deve ter a capacidade de pesquisar ameaças nas estações do Windows usando indicadores de comprometimento (IOC), como: nome do arquivo e hash do arquivo, etc.
17.3.10. A solução proposta deve ter a capacidade de pesquisar ameaças em estações Windows usando indicadores de comprometimento (IOC), como ações relacionadas a arquivos (Criação, Exclusão, Renomear).
17.3.11. A solução proposta deve ter a capacidade de pesquisar ameaças em estações Windows usando indicadores de comprometimento (IOC), como ações relacionadas a processos (Terminação de Processo, Criação de Processo, Carregamento de Executáveis)
17.3.12. A solução proposta deve ter a capacidade de pesquisar ameaças em estações Windows usando indicadores de comprometimento (IOC), como ações relacionadas ao uso da rede (Socket Connect, Socket Close, Socket Brind)
17.3.13. A solução proposta deve ter a capacidade de pesquisar ameaças em estações Windows usando indicadores de comprometimento (IOC), como ações relacionadas aos logs do Windows (Log de eventos).
17.3.14. A solução proposta deve ter a capacidade de pesquisar ameaças nas estações do Windows usando indicadores de comprometimento (IOC), como ações relacionadas ao registro do Windows (criação de chave, exclusão de chave, conjunto de valores)
17.3.15. A solução proposta deve ter a capacidade de realizar consultas de texto livre para filtrar as informações disponíveis para a caça de ameaças.
17.3.16. A solução proposta deve ter a capacidade de armazenar pesquisas realizadas para serem reutilizadas no futuro
17.3.17. A solução proposta deve ter a capacidade de agendar pesquisas armazenadas
17.3.18. A solução proposta deve identificar atividades maliciosas conhecidas
17.3.19. A solução proposta deve ter a capacidade de receber atualizações diárias de inteligência
17.3.20. A solução proposta deve ter a capacidade de categorizar os eventos detectados em diferentes categorias (Ex: Malicioso, Suspeito, Inconclusivo, Provavelmente Seguro)
17.3.21. A solução proposta deve ter a capacidade de coexistir com outras soluções de segurança de endpoint do tipo de antivírus tradicional ou de nova geração.
17.3.22. Requisito - Prevenção de malware
17.3.23. A solução proposta deve ter a capacidade de prevenir a execução de arquivos maliciosos
17.3.24. A solução proposta deve incorporar um mecanismo antivírus de última geração (NGAV) baseado no kernel com capacidade de "Aprendizado de Máquina".
17.3.25. A solução proposta deve ter a capacidade de controlar dispositivos USB
17.3.26. A solução proposta deve ter a capacidade de criar exceções para dispositivos USB com base no nome do dispositivo
17.3.27. A solução proposta deve ter a capacidade de criar exceções para dispositivos USB com base no fornecedor do dispositivo
17.3.28. A solução proposta deve ter a capacidade de criar exceções para dispositivos USB com base no número de série do dispositivo.
17.3.29. A solução proposta deve ter a capacidade de criar exceções para dispositivos USB com base em uma combinação de: nome do dispositivo, fornecedor, número de série
17.3.30. A solução proposta deve ser capaz de bloquear o tráfego malicioso de exfiltração de dados
17.3.31. A solução proposta deve ser capaz de bloquear o tráfego de comunicação malicioso para C&C (Comando e Controle)
17.3.32. A solução proposta deve ser capaz de impedir violações de segurança e tentativas de ransomware em tempo real
17.3.33. A solução proposta deve ser capaz de evitar a criptografia de disco causada por ransomware e modificação de arquivos ou registro de dispositivos
17.3.34. A solução proposta deve permitir que as políticas nela contidas sejam modificadas permitindo vários estados tais como: Ativo, Desativado ou apenas criar "logs" para as regras de segurança contidas nestes
17.3.35. A solução proposta deve ser capaz de ser configurada em modo de simulação onde nenhum bloqueio é feito, mas todas as atividades maliciosas são registradas.
17.3.36. A solução proposta deve ser capaz de permitir a modificação das regras de detecção de eventos maliciosos de forma que essas regras apenas armazenem um registro ou fiquem em modo de bloqueio
17.3.37. A solução proposta deve ser capaz de permitir verificações periódicas dos arquivos contidos nos dispositivos com o Agente instalado.
17.4. Requisito - Difusão (Pós-infecção)
17.4.1. A solução proposta deve permitir o isolamento automático do tráfego de rede de um dispositivo onde foi encontrada uma atividade causada por malware.
17.4.2. A solução proposta deve permitir alterar as políticas atribuídas de um dispositivo onde uma atividade causada por malware foi encontrada
17.4.3. A solução proposta deve permitir o bloqueio de atividades realizadas por arquivos maliciosos
17.4.4. A solução proposta deve ter a capacidade de criar exceções para processos com base na localização do arquivo (Caminho do Arquivo)
17.4.5. A solução proposta deve ter a capacidade de criar exceções para processos com base no destino do tráfego gerado pelo processo.
17.4.6. A solução proposta deve ter a capacidade de criar exceções para os processos baseados no usuário que o processo executou
17.4.7. A solução proposta deve ter a capacidade de criar exceções manualmente para falsos positivos para marcar a atividade como um falso positivo e evitar a ocorrência de falhas futuras
17.4.8. A solução proposta deve ter a capacidade de reclassificar automaticamente a atividade como um falso positivo e evitar a ocorrência de detecções semelhantes.
17.4.9. A solução proposta deve permitir a criação de exceções de eventos com base em endereços IP, aplicações e protocolos
17.5. Requisito - Resposta ao Incidente
17.5.1. A solução proposta deve permitir um histórico dos eventos por no mínimo 6 meses
17.5.2. A solução proposta deve armazenar metadados gerados pelos dispositivos para que possam ser usados em investigações forenses.
17.5.3. A solução proposta deve permitir a integração com plataformas SIEMs (Security Information and
Event Management) através de um syslog
17.5.4. A solução proposta deve ter a capacidade de obter instantâneos de memória ou "dumps" de memória que permitam a realização de processos forenses.
17.5.5. A solução proposta deve ter a capacidade de abrir tickets em plataformas de gerenciamento como ServiceNow e JIRA
17.5.6. A solução proposta deve permitir a integração através de API onde tem a capacidade de entregar informações geradas em um evento como: endereço IP, nome do host, usuário, data / hora ocorrida, atividade suspeita, etc.) para permitir a integração via API
17.5.7. A solução proposta deve ter a capacidade de encerrar um processo com base em sua classificação
17.5.8. A solução proposta deve ter a capacidade de excluir um arquivo com base em sua classificação
17.5.9. A solução proposta deve ser a capacidade de restaurar as configurações de registro básicas com base na classificação de atividade predefinida
17.5.10. A solução proposta deve ter a capacidade de isolar os dispositivos infectados da rede.
17.5.11. A solução proposta deve ter a capacidade de restringir automaticamente o acesso do dispositivo à rede de acordo com a classificação (Malicioso, Suspeito, etc.) do processo detectado
17.5.12. A solução proposta deve obter visibilidade total da cadeia de ataques e alterações maliciosas
17.5.13. A solução proposta deve permitir a limpeza automática do dispositivo e reverter alterações maliciosas, mantendo o tempo de atividade do dispositivo.
17.5.14. A solução proposta deve permitir a assinatura de serviços opcionais de detecção e resposta a incidentes (Ex: serviços gerenciados de detecção e resposta)
17.5.15. A solução proposta deve permitir o envio de executáveis para análise em um sandbox, a fim de determinar se são maliciosos ou inofensivos.
17.5.16. A solução proposta deve fornecer vários mecanismos de proteção, incluindo o encerramento de um processo, a exclusão de um arquivo malicioso, o bloqueio de uma conexão de rede
17.6. Requisito - Controle de Vulnerabilidade e Comunicação
17.6.1. A solução proposta deve ter a capacidade de descobrir aplicativos que estão se comunicando através da rede e que representam risco para o terminal
17.6.2. A solução proposta deve ter capacidade para realizar um patch virtual, através da restrição de acessos de comunicação nas aplicações vulneráveis.
17.6.3. A solução proposta deve permitir a redução das superfícies de ataque utilizando políticas de comunicação proativas baseadas no risco de acordo com o CVE e a qualificação ou reputação que uma aplicação possa ter.
17.6.4. A solução proposta deve ter a capacidade de impedir que aplicativos não autorizados se comuniquem pela rede.
17.6.5. A solução proposta deve ter a capacidade de criar políticas que tenham a capacidade de impedir a comunicação de aplicativos de acordo com a versão do aplicativo instalado.
17.6.6. A solução proposta deve ser capaz de detectar e identificar todas as aplicações nos dispositivos que se comunicam na rede.
17.6.7. A solução proposta deve ser capaz de fornecer informações sobre o uso de aplicativos de rede mostrando, por exemplo, quais dispositivos geram tráfego para um aplicativo.
17.6.8. A solução proposta deve ser capaz de visualizar e entregar informações sobre o uso dos aplicativos de rede mostrando informações como os destinos IP do tráfego gerado pelo aplicativo.
17.7. Requisito - Cenários de Ataque
17.7.1. A solução proposta deve identificar e prevenir tentativas de perseguição de privilégios
17.7.2. A solução proposta deve bloquear ataques de ransomware conhecidos
17.7.3. A solução proposta deve detectar malware desconhecido como RAT (Trojan de acesso remoto) por meio das atividades do malware e não de uma assinatura
17.7.4. A solução proposta deve proteger contra scripts Powershell maliciosos
17.7.5. A solução proposta deve proteger contra scripts CScript maliciosos
17.7.6. A solução proposta deve proteger contra macros maliciosas do Office
17.7.7. A solução proposta deve ter controle sobre dispositivos USB
17.8. Requisito - IOT
17.8.1. A solução proposta deve ter a capacidade de descobrir dispositivos IOT não gerenciados na rede
17.8.2. A solução proposta deve ter a capacidade de detectar dispositivos não gerenciados e protegidos pela solução com sistemas operacionais macOS / Linux / Windows
17.9. Requisito - Console de Administração
17.9.1. A solução proposta deve estar em conformidade com os padrões de segurança de dados da indústria de cartões de pagamento (PCI DSS)
17.9.2. A solução proposta deve estar em conformidade com o padrão HIPAA
17.9.3. A solução proposta deve estar em conformidade com o padrão GDPR
17.9.4. O console de gerenciamento da solução proposta deve permitir a integração com o "Active Directory" para garantir o cumprimento dos requisitos da política de senhas da empresa.
17.9.5. O console de administração da solução proposta deve permitir o uso de autenticação de dois fatores (2FA) para acessá-la.
17.9.6. O console de administração da solução proposta deve permitir a integração com SAML para autenticação do usuário no console de gerenciamento
17.9.7. O console de administração da solução proposta deve permitir o uso de funções granulares para administradores
17.9.8. O console de administração da solução proposta deve permitir o gerenciamento de ambientes multilocatários.
17.9.9. O console de administração da solução proposta deve permitir o gerenciamento por meio da API Full Restful
17.9.10. A solução proposta deve ser capaz de ser totalmente gerenciada na nuvem sem a necessidade de serviços locais
17.9.11. A solução proposta deve ser capaz de ser gerenciada em uma arquitetura híbrida usando serviços locais complementados com outros na nuvem.
17.9.12. O console de administração da solução proposta deve permitir a visualização dos eventos registrados nos dispositivos que requerem atenção.
17.9.13. O console de administração da solução proposta deve permitir a visualização da saúde dos Agentes instalados
17.9.14. O console de administração da solução proposta deve permitir a desinstalação remota do Agente instalado nos dispositivos
17.9.15. O console de administração da solução proposta deve permitir a desativação / ativação remota do Agente instalado nos dispositivos
17.9.16. O console de administração da solução proposta deve permitir a atualização remota do Agente instalado nos dispositivos
17.9.17. O console de administração da solução proposta deve permitir a criação de relatórios executivos