editaltrem.trensurb.gov.br/paginas/upload/files/edital consulta...translate this pageedital consulta...

Empresa de Trens Urbanos de Porto Alegre S.A.

Av. Ernesto Neugebauer, 1985 - Porto Alegre/RS. CEP 90.250-140 – Tel.: (51) 3363-8000

1

EDITAL

CONSULTA PÚBLICA Nº 001/2017

A Empresa de Trens Urbanos de Porto Alegre S/A - TRENSURB,

sociedade de economia mista, vinculada ao Ministério das Cidades, representada pela

Comissão de Licitação constituída pela Resolução da Presidência – REP 0346/2016

torna pública, para conhecimento das interessadas a presente Consulta Pública,

destinada à contratação do objeto citado no subitem 3.1 deste Edital.

1. INTRODUÇÃO

1.1. A TRENSURB, tendo em vista a necessidade de conhecer o mercado específico

e verificar a adequação das Especificações Técnicas, por meio desta Consulta Pública,

coloca à disposição dos interessados as especificações do objeto que pretende contratar,

para apresentação de questionamentos, comentários e sugestões.

1.2. A presente Consulta Pública tem como finalidade dar ampla divulgação e

transparência do processo de contratação e garantir as melhores condições/exigências

possíveis e existentes no mercado para a execução eficiente do objeto pretendido,

verificando a existência de empresas interessadas na licitação e propiciar melhorias nas

especificações técnicas do Projeto Básico que instrui o processo eletrônico nº

1079/2017.

2. DA PARTICIPAÇÃO NA CONSULTA PÚBLICA

2.1. As dúvidas, questionamentos, comentários, esclarecimentos, quaisquer

contribuições, deverão ser encaminhadas para o e-mail [email protected], através

do formulário modelo apresentado nos Anexos deste edital, devendo ser informado no

campo “assunto” do e-mail a expressão “Consulta Pública nº 01/2017”, até a data limite

descrita no item 4 deste Edital, ou poderão ser protocoladas no Protocolo Geral da

TRENSURB no Prédio de Apoio no endereço Av. Ernesto Neugebauer, nº 1985 – Porto

Alegre/RS e endereçadas à Comissão Permanente de Licitações – COPEL, através do

formulário modelo apresentado nos Anexos deste edital.

2.2. O Edital deste procedimento, Processo nº 1079/2017 encontra-se à disposição

para exame com a COMISSÃO DE LICITAÇÃO, localizada no 6º andar do Prédio

Administrativo, Av. Ernesto Neugebauer, nº 1985, Bairro Humaitá, Porto Alegre/RS,

CEP 90250-140, telefone (51) 3363.8195 - FAX (51) 3363.8166, e-mail,

[email protected], de segunda à sexta-feira, em horário administrativo. O edital

Edital Consulta Pública nº 001/2017



2

contendo o termo de referência poderá ser retirado no endereço eletrônico

www.trensurb.gov.br, link licitações.

3. DO OBJETO

3.1. Contratação de empresa especializada para prestação de serviço de

implementação, fornecimento de equipamentos, customização, operações

financeiras, atendimento ao usuário, publicidade, migração de dados, suporte,

treinamento, manutenção, objetivando atender às necessidades da TRENSURB

para modernização e atualização do processo de bilhetagem eletrônica que

constitui o Sistema Integrado Metropolitano (SIM), conforme especificações

contidas no Termo de Referência em anexo a este Edital.

4. DO ENCERRAMENTO DA CONSULTA

DATA: 27/09/2017

HORÁRIO: 17h00min (horário de Brasília – DF)

As contribuições recebidas fora do prazo, ou que não forem enviadas por meio do

Formulário modelo em anexo, não serão consideradas para efeito de elaboração do texto

final do ato.

5. SOLICITAÇÕES DE DEMONSTRAÇÃO DO SERVIÇO

Os fornecedores interessados em realizar demonstração deverão encaminhar,

dentro do prazo previsto acima, solicitação para o e-mail [email protected].

6. DOS TERMOS E CONDIÇÕES DA CONSULTA PÚBLICA

6.1. Este Edital não constitui compromisso de contratação ou aquisição de quaisquer

bens ou serviços entre a TRENSURB e o interessado.

6.2. O recebimento de informações não compromete a TRENSURB com a

adjudicação a qualquer fornecedor, nem limita o direito de contratação ou negociação

com qualquer interessado.

6.3. O fornecedor não deve cobrar qualquer valor, mesmo que a título de

compensação de despesas, pela prestação de informação ou conteúdo ou demonstrações

ou por qualquer outro motivo decorrente desta Consulta.

6.4. O fornecedor é responsável por todo e qualquer custo ou despesa decorrentes do

cumprimento desta Consulta.

6.5. As contribuições recebidas não serão objeto de resposta, ficando arquivadas

para uso interno da TRENSURB.




3

7. DAS DISPOSIÇÕES COMPLEMENTARES

7.1. As informações apresentadas a partir desta Consulta Pública serão meramente

referenciais, ficando a critério da TRENSURB o uso dos termos na sua integralidade ou

a verificação da aderência, compatibilidade e pertinência das mesmas contribuições

advindas deste procedimento, podendo ser adotadas quaisquer formas previstas na

legislação pertinente.

7.2. Constituem anexos deste edital:

I. TERMO DE REFERÊNCIA

II. MODELO DO FORMULÁRIO

Porto Alegre/RS, 18 de Setembro de 2017.

DAVID BORILLE

Diretor Presidente

(documento com assinatura eletrônica – processo SEI 1079/2017)




4

ANEXO I

TERMO DE REFERÊNCIA

1. Objeto

Contratação de empresa especializada para prestação de serviço de

implementação, fornecimento de equipamentos, customização, operações

financeiras, atendimento ao usuário, publicidade, migração de dados, suporte,

treinamento, manutenção, objetivando atender às necessidades da Trensurb para

modernização e atualização do processo de bilhetagem eletrônica que constitui o

Sistema Integrado Metropolitano (SIM).

2. Finalidade

Oferecer à Trensurb estrutura de serviço de bilhetagem eletrônica a fim de

parametrizá-la com outras empresas do ramo, no tocante às inovações tecnológicas

existentes no mercado, com a finalidade de proporcionar ao usuário de metrô, um

serviço ágil, seguro e de qualidade.

3. Justificativa

Constitui informação de uso interno da Administração.

4. Especificações

Para entrar em vigor, respeitando os prazos estabelecidos através dos estudos

prévios e ter bom êxito em sua premissa básica de aprimorar o processo de bilhetagem

eletrônica, o novo projeto em tela deverá ser implementado de forma gradual, valendo-

se de três fases, cujos prazos para vigorar seguirão a ordem de importância dos serviços,

com referência nas necessidades mais imediatas, baseando-se nas imposições da

operação e, mormente na forma menos traumática para uma eventual migração dos

usuários ao novo sistema, emulando-se em cases de sucesso de metrôs referenciais,

localizados em cidades com conurbação semelhante à região metropolitana de Porto

Alegre, a qual a Trensurb está inserida.

Em linhas gerais, a primeira fase se dará pela implementação do novo passe

unitário, cartão de passe antecipado (ao portador ou identificado), cartão de idoso, vale

transporte, cartão para permissionário e cartão funcional. Esta etapa é mais urgente e

demandará um trabalho sinérgico entre as áreas envolvidas, pois a mudança será

sistemática e mesmo sendo feita paulatinamente, interessa-nos que o redirecionamento

da tecnologia seja administrado de forma a não causar prejuízos e contratempos aos




5

usuários. Para tanto, apoiar-nos-emos no know-how da área responsável pela

publicidade, afim de que sejam feitas campanhas que elucidem aos clientes da empresa,

as melhorias advindas dessas mudanças. Estaremos alicerçados, também, no emprenho

da área operacional para colocarmos em prática os novos métodos de trabalho,

garantindo que essas modificações sejam percebidas de forma positiva pela opinião

pública, para, sobretudo, angariarmos o apoio da população que se utiliza dos nossos

serviços.

A segunda fase terá caráter modernizador, pois é nela que serão implementadas

as vendas de crédito de passe antecipado pela internet, um modelo em voga em metrôs

de diversos países, e que, comprovadamente, tem grande adesão dos usuários pela

facilidade em adquirir os passes, sem precisar ficar em filas ou levar dinheiro consigo,

pois todo o trâmite é feito com cartão de crédito em sítio seguro da web. Outra

facilidade será a inauguração das vendas de passagens através de caixas automáticos de

autoatendimento, localizadas em locais estratégicos, com a finalidade de dirimir as filas

para aquisição de bilhetes e educar os usuários a adquirirem previamente suas

passagens.

A terceira fase trará a evolução do processo tecnológico implementada na

segunda fase. Serão habilitadas as formas de aquisição de créditos antecipados através

de aplicativo próprio para smartphone, uma tendência que costuma ter imediata filiação

por parte dos consumidores, pois está alinhada à tecnologia presente em diversas searas

da vida moderna, trazendo facilidades e economia de tempo para o usuário e diminuição

da demanda de compradores nos postos de vendas de bilhete. O funcionário da

operação, ajudado por essa tecnologia, restará menos implicado com o trabalho

mecanizado de venda de cartões e mais comprometido com o acompanhamento das

rotinas da estação, com o auxílio ao usuário e com a resolução de tarefas atinentes ao

seu cargo que, hoje quedam negligenciadas pela falta de empregados e estrutura.

4.1 Fase1 – Modernização do Sistema Atual - Especificações e premissas

4.1.1. Passe unitário:

4.1.1.1. O passe unitário deverá ser uma mídia descartável, tendo como referência

a tecnologia QRCode, de baixo custo e com a possibilidade de ser

carregada com um passe e validade a ser definido e alterado pela Trensurb,

quando esta julgar necessário.

4.1.1.2. A mídia de passe unitário deverá trazer identificada em seu corpo, de

forma facilmente visualizável pelo usuário, o valor do passe, data, hora,

estação, ponto de venda que foi efetuada a compra e conter observações

sobre sua conservação, após impressão, obrigatoriamente realizada no ato

da compra;

4.1.1.3. A velocidade de impressão e autenticação das mídias de passe

unitário não deverá ser superior a 4 segundos, sendo que a

velocidade de liberação dos bloqueios, no uso da mídia de passe

unitário, não poderá superar 1,5 segundo.




6

4.1.2. Bloqueio e validadores:

4.1.2.1. A Contratada deverá instalar os validadores do novo sistema de

bilhetagem nos 143 bloqueios de entrada, devidamente instalados, nas 23

estações de passageiros da Trensurb, conforme o Quadro A;

4.1.2.2. A contratada deverá instalar contador eletrônico de público nos 48

bloqueios de saída, de forma, que possa ter em tempo real, o controle de

saída dos usuários por bloqueio, por estação, por grupo de estações, por

grupo de bloqueios, ou outros arranjos que a Trensurb julgar necessário

para geração de relatórios gerenciais e estatísticos, para tanto, essas

informações devem ser armazenadas em banco de dados, cuja

periodicidade e tempo de armazenamento serão definidos pela Trensurb;

4.1.2.3. Para implantação do controle de saída, a contratada poderá utilizar os

recursos da placa de comunicação dos bloqueios e/ou implementar

hardware adicional;

4.1.2.4. Nos bloqueios de entrada, deverá ter a possibilidade de inversão de fluxo

assumindo a função de saída, nesses casos, deve ter a possibilidade de

controle de fluxo de saída nas mesmas características dos bloqueios que

são exclusivamente de saída.

4.1.2.5. O controle de saída e entrada de usuários deverá possibilitar o

acompanhamento em tempo real através de computadores, telões ou

integrado com monitores do sistema de CFTV a ser definido pela

Trensurb;




7

4.1.2.6. Os validadores do novo do sistema deverão ser compartilhados com outros

validadores, dos sistemas TRI e TEU, ou seja, dois validadores devem ser

instalados no mesmo bloqueio, conforme distribuição no Quadro A;

4.1.2.7. Os validadores do novo sistema de bilhetagem, adaptados nos bloqueios,

devem respeitar as condições de fluxo de usuários de forma que não gere

problemas com passagem de malas e objetos, devendo ter uma altura

máxima de 20 cm em relação à tampa superior do bloqueio;

4.1.2.8. A solução e a execução da infraestrutura de cabeamento lógico e elétrico,

para adaptação dos novos validadores, serão de exclusiva responsabilidade

da contratada, cuja solução, deverá respeitar todas as normas técnicas

vigentes, bem como as normas operacionais da Trensurb;

4.1.2.9. Na infraestrutura também deverão estar incluídas todas as conexões de

lógica e elétrica com o data center a ser instalado nas dependências da

Trensurb;

4.1.2.10. O software de operação do novo sistema de bilhetagem, além de

armazenar os registros de usos dos vários produtos, deverá possibilitar o




8

gerenciamento físico do bloqueio, tais como: abertura, fechamento,

inversão (entrada e saída), status de funcionamento e outras informações

necessárias para o perfeito funcionamento do sistema. Essas informações

devem estar disponíveis em tempo real, em um ou mais painéis de controle

a serem instalados em local a ser definido pela Trensurb;

4.1.2.11. O software de operação do novo sistema de bilhetagem deve ser instalado

em Domínio exclusivo, com controle de acesso para cada tipo de

aplicação, através de usuário e senha, integrados ao serviço Active

Directory da Trensurb;

4.1.2.12. A equipe técnica da Trensurb acompanhará todas as adaptações que dizem

respeito ao data center, à infraestrutura de instalação, ao sistema

operacional, às licenças de uso, aos bancos de dados, aos painéis de

controle e demais necessidades, para que haja o correto funcionamento da

nova fase operacional, bem como todos os outros acessórios necessários

para a boa performance das adequações, que serão de inteira

responsabilidade da contratada;

4.1.2.13. Faz-se imprescindível a total liberdade de acesso por parte da Trensurb a

todos os equipamentos, banco de dados e aplicações, seja para consulta,

gestão ou auditoria. Os tipos de informações que devem constar nos

bancos de dados, para a correta geração dos relatórios de usuários e receita

são, dentre outros, o número do cartão, hora, data, bloqueio, estação, tipo

de cartão, tipo de tarifa, formato de validação, erros, liberação de créditos,

contabilidade, operações financeiras, etc. Da mesma maneira que o acesso

ao Know-how do sistema num todo no tocante à manutenção, sendo

indispensável o repasse das informações concernentes ao software e

hardware para que a Trensurb tenha ciência das medidas a serem tomadas

em caso de eventual emergência, situação degradada ou superveniente

ocorrência em que tenha que agir unilateralmente para dirimir momentos

de crise.




9

4.1.3. Ponto de venda (POS)

4.1.3.1. Os pontos de vendas (POS) deverão ser instalados nas bilheterias,

conforme quantitativos abaixo:

Quadro B

4.1.3.2. Os POS’s deverão atender a todas as normas de ergonomia, garantindo a

saúde do operador, fomentando a boa postura da coluna, o alcance das

mãos e minimizando o esforço repetitivo, levando em conta o layout das

bilheterias;




10

4.1.3.3. Os POS’s deverão possibilitar a venda de passes unitários e/ou múltiplos

e recarga em cartões PA-SIM ao portador e identificado, com emissão do

recibo de recarga;

4.1.3.4. Os POS’s deverão possibilitar a consulta e impressão de extrato de

utilização do passe unitário, contendo dia, hora, bloqueio e estação de

uso. Essa aplicação deverá também ser transferida às ATM’s e

aplicativos para smartphones quando estes forem disponibilizados.

4.1.3.5. Deverá haver um computador na sala de conferência de cada uma das

estações, CCE e SEMERC, habilitado para gerenciamento do controle de

estoque (fundo fixo e cascos dos cartões).

4.1.3.6. O sistema embarcado nos POS’s deverá possibilitar o cadastramento do

CPF no caso de PA-SIM Identificado. Esse cadastramento possibilitará

ao usuário, em caso de perda ou extravio, solicitar a transferência dos

valores para a 2ª via do cartão;

4.1.3.7. Os POS’s deverão estar conectados através da rede da Trensurb ao data

center localizado nas dependências da Trensurb, através de um domínio,

que permitirá diretivas de segurança com maior nível de abrangência. O

sistema deverá armazenar todas as informações referentes às transações

financeiras, propiciando o fechamento em tempo real do caixa de cada

bilheteria;

4.1.3.8. O sistema de venda dos POS´s deve conter todas as informações

necessárias para fechamento do caixa, valores de entrada, troco, número

de cascos de cartões PA-SIM fornecidos para abertura do caixa. O

processo de fechamento deve ser de fácil operação, sem a necessidade de

uso de sistemas auxiliares;

4.1.3.9. O sistema de venda deve estar disponível em tempo real, com

informações de venda por tipo de produto, por cidade, por estação, por

bilheteria e total de vendas no dia. Essas informações poderão ser

acessadas em computadores com permissão de acesso a ser definido pela

Trensurb.

4.1.3.10. Para a perfeita gestão do novo sistema de bilhetagem eletrônica, será

necessário a cedência de diversos relatórios que serão definidos

posteriormente pela Trensurb, devendo a mesma ter total liberdade ao

acesso às informações, bem como à solicitação de dados que possam ser

parametrizados ou customizados de acordo com os anseios das áreas

interessadas da Trensurb.

4.1.4. Cartão PA SIM – Passe Antecipado

Trata-se de uma mídia com padrão de leitura QRCode ou similar quanto a sua

performance e baixo custo de aquisição. Devendo permitir o controle de créditos, bem

como o controle de utilização, em tempo real, e sendo, ainda, totalmente imune a

falsificações, valendo-se de tecnologia ou dispositivo que garanta a inviolabilidade dos

dados, replicações ou quaisquer outros artifícios ilegais que possam ser utilizados para




11

comprometer a segurança financeira e de dados no processo de bilhetagem eletrônica.

Possibilitando ao usuário carregar antecipadamente valores mais expressivos,

conferindo-lhe a utilização do sistema por período mais prolongado. O Passe

Antecipado SIM deverá ser confeccionado em mídia mais resistente, com vida útil não

inferior a um ano, salvo mau uso e deverá ter duas versões: identificado e ao portador.

4.1.4.1. Os cartões deverão ter identidade visual distintas, cujos signos

identificarão a modalidade a qual se referem. Os layouts serão fornecidos

pela Trensurb;

4.1.4.2. A contratada deverá fornecer a quantidade necessária desses cartões para o

atendimento da demanda, repondo-os quando houver necessidade,

antecipando-se ao esgotamento, porquanto a falta deste material comina

empecilhos à operação e aos usuários;

4.1.4.3. Com o intuito de aprimorar a gestão e maximizar o controle das transações

financeiras referentes ao PA-SIM, no fechamento de caixa das bilheterias,

através do Sistema de Vendas (POS), deve constar todas as transações,

tanto da modalidade identificado quanto ao portador; cobrança dos cascos;

recargas realizadas; número dos cartões utilizados e sobrantes, bem como

toda e qualquer informação necessária, ficando a contratada adstrita

àquelas informações concernentes ao bojo de sua atuação;

4.1.4.4. O sistema de vendas (POS) deve permitir que cada cartão seja rastreável,

desde a entrega na Trensurb, estoque central, distribuição nas estações,

distribuição nas bilheterias, entrega ao usuário, controle de usos, recargas e

em caso de perda, a eliminação total do mesmo no sistema.

4.1.4. 5. Cartão de Passe Antecipado - SIM Identificado:

Trata-se de uma mídia com padrão de leitura QRCode ou similar quanto a

sua performance e baixo custo de aquisição. Devendo permitir o controle de

créditos, bem como o controle de utilização, em tempo real, e sendo, ainda,

totalmente imune a falsificações, valendo-se de tecnologia ou dispositivo que

garanta a inviolabilidade dos dados, replicações ou quaisquer outros artifícios

ilegais que possam ser utilizados para comprometer a segurança financeira e de

dados no processo de bilhetagem eletrônica. Faculta ao usuário a fazer recargas

periódicas, dirimindo filas nas bilheterias, evitando assim, atrasos e eventuais

aborrecimentos. Esta mídia, conquanto o usuário deva fornecer documentação

para sua confecção, aduzi, como maior benefício, a possibilidade de requisição de

uma 2ª via em caso de perda ou roubo, cancelando o cartão anterior, e transferindo

automaticamente os créditos referentes àquele CPF.

4.1.4.5.1. Para requerer a confecção do cartão, o usuário deverá se

encaminhar a uma estação e apresentar seu CPF ao agente

metroviário em serviço na bilheteria;

4.1.4.5.2. A solicitação do cartão poderá ser feita em qualquer bilheteria

da Trensurb;




12

4.1.4.5.3. Para que haja maior controle por parte da Trensurb, o Sistema

de vendas (POS) deverá armazenar o cadastro do CPF do

usuário, armazenando-o em banco de dados próprio, do qual a

Trensurb tenha total acesso;

4.1.4.5.4. O cartão será entregue ao usuário no ato contínuo à sua

solicitação. O sistema emitirá um recibo de entrega do Cartão

de Passe Antecipado – SIM Identificado, contendo o valor de

recarga, CPF do usuário e orientações para eventuais

procedimentos de cancelamento, bem como, solicitação de 2ª

via e transferência de créditos;

4.1.4.5.5. Para recarregar o Cartão de Passe Antecipado – SIM

Identificado, o usuário deverá comparecer a uma das

bilheterias, em qualquer estação da Trensurb. O montante

mínimo de recarga será o valor equivalente a um (1) passe e a

carga máxima será no valor equivalente até trezentos (300)

passes. Emitir-se-á um recibo com os dados da recarga;

4.1.4.5.6. O sistema de vendas (POS) deverá associar o número de

identificação física do cartão ao CPF do usuário e armazenar

no banco de dados;

4.1.4.5.7. O sistema de vendas (POS) deve ser programado de modo que

não permita o cadastramento repetido, com CPF idêntico para

mais de um cartão, salvo quando haja cancelamento e

confecção de novo cartão, seja por dissentimento nas

informações, roubo, ou extravio;

4.1.4.5.8. O sistema de Vendas (POS) deverá habilitar a cobrança da 2ª

via do Cartão, nessa conformidade, o registro dessa receita

deverá compor o documento de fechamento de caixa;

4.1.4.5.9. Deverá ser outorgado à Trensurb, por parte da contratada, a

irrestrita possibilidade de consulta, em tempo real, do

quantitativo de usuário, dos valores de recarga, dos históricos

de recargas, tanto para um usuário ou um grupo de usuários,

quanto para todos os usuários cadastrados.

4.1.4.6. Cartão de Passe Antecipado ao Portador:

Terá as mesmas características físicas do Cartão PA-SIM Identificado,

trata-se de uma mídia com padrão de leitura QRCode ou similar quanto a sua

performance e baixo custo de aquisição. Devendo permitir o controle de créditos,

bem como o controle de utilização, em tempo real, e sendo, ainda, totalmente

imune a falsificações, valendo-se de tecnologia ou dispositivo que garanta a

inviolabilidade dos dados, replicações ou quaisquer outros artifícios ilegais que

possam ser utilizados para comprometer a segurança financeira e de dados no

processo de bilhetagem eletrônica e operacionalidade, porém não terá cadastrada

em seu bojo quaisquer informações acerca do usuário.




13

4.1.4.6.1. Em virtude da facilidade de preparação e entrega desta

modalidade, esse cartão será destinado aos usuários frequentes

da Trensurb. Com carga mínima de 02 passes unitários,

podendo ser alterado pela Trensurb, quando esta julgar

necessário. E entregue mediante pagamento do valor do casco,

que poderá ser reembolsado ao usuário que quiser devolver o

cartão após o uso, estando o mesmo zerado. Ele representará

um considerável desafogo nas bilheterias em horários de pico.

O referido casco deverá ser devolvido em perfeito estado de

conservação e apto a ser utilizado outras vezes. Essas regras

poderão ser alteradas a qualquer tempo por iniciativa da

Trensurb;

4.1.4.6.2. O usuário poderá solicitar o cartão em qualquer bilheteria da

Trensurb e poderá fazer recargas periódicas, respeitando a

primeira carga mínima no valor referente à dois passes, sem

preocupar-se com o prazo de validade da carga depositada,

pois não haverá tempo predeterminado para utilização dos

bônus. Essa regra poderá ser alterada a qualquer tempo por

iniciativa da Trensurb;

4.1.4.6.3. O usuário receberá o cartão no ato da solicitação e o sistema

emitirá o recibo de entrega do Cartão de Passe Antecipado –

SIM ao portador, contendo o valor de recarga e/ou número de

passes;

4.1.4.6.4. As recargas posteriores serão feitas nas bilheterias de todas as

estações e o valor mínimo será referente a dois passes

unitários, e o máximo de trezentos (300) passes unitários, onde

será emitido recibo da recarga. Esse cartão não permite

cancelamento, e por ser da modalidade “ao portador”, os

créditos nele depositados são de inteira responsabilidade do

usuário, devendo, então, a contratada, fazer constar no verso da

mídia, alertas sobre os riscos de perda de créditos em virtude

de extravio e roubo do cartão;

4.1.4.6.5. O sistema de vendas (POS) deverá habilitar o agente

metroviário destacado na bilheteria a selecionar a opção de

recarregar o Cartão PA-SIM ao portador, ato contínuo à

solicitação do usuário, registrando a transação e armazenando-

a no banco de dados;

4.1.4.6.6. O sistema de vendas (POS) deverá prever a cobrança do casco

do Cartão PA-SIM ao portador, devendo essa informação ser

armazenada no banco de dados e constar no procedimento de

fechamento de caixa, tanto na venda quanto na recompra;

4.1.4.6.7. Deverá ser outorgada à Trensurb, por parte da contratada, a


quantitativo de cartões, dos valores de recarga, dos históricos

de recargas, tanto para um cartão ou um grupo de cartões,

quanto para todos os cartões solicitados.




14

4.1.5. Cartão de Vale Transporte – SIM:

O cartão terá características físicas semelhantes ao Cartão PA-SIM, trata-se de

uma mídia com padrão de leitura QRCode ou similar quanto a sua performance e baixo

custo de aquisição. Devendo permitir o controle de créditos, bem como o controle de

utilização, em tempo real, e sendo, ainda, totalmente imune a falsificações, valendo-se

de tecnologia ou dispositivo que garanta a inviolabilidade dos dados, replicações ou

quaisquer outros artifícios ilegais que possam ser utilizados para comprometer a

segurança financeira e de dados no processo de bilhetagem eletrônica, porém com

identidade visual diferenciada, respeitando a reestruturação da marca, dentro de

um layout a ser definido pela área da Trensurb responsável pela publicidade.

4.1.5.1. A forma de aquisição será pelo site da Trensurb ou através da

Central de Atendimento ao Usuário;

4.1.5.2. O cartão de Vale Transporte – SIM só poderá ser adquirido por

empresas mediante seu cadastro prévio, tal como dos empregados

beneficiados;

4.1.5.3. Os depósitos, referentes aos valores concedidos para o benefício de

Vale transporte, deverão ser pagos em agências bancárias

cadastradas;

4.1.5.4. Deverá ser possível a recarga de valores de passe antecipado de Vale

Transporte, num mesmo cartão, sendo possível obter extratos

individualizados de cada operação;

4.1.5.5. As recargas serão transferidas para o cartão do usuário quando a

mídia entrar em contato com o validador do bloqueio, somente após

a confirmação de depósito bancário o sistema estará habilitado para

efetuar estas operações;

4.1.5.6. A totalidade do processo será de responsabilidade exclusiva da

contratada, no tocante a cadastramento, créditos, operações bancárias

e o que mais resultar deste processamento;

4.1.5.7. Deverá ser outorgada à Trensurb, por parte da contratada, a irrestrita

possibilidade de consulta, em tempo real, do quantitativo de usuário,

dos valores de recarga, dos históricos de recargas, tanto para um

usuário ou um grupo de usuários, quanto para todos os usuários

cadastrados;

4.1.5.8. A venda de créditos do vale transporte será realizada através de

Central de Atendimento, sendo este serviço fornecido pela própria

contratada e devendo esta prover estrutura adequada ao atendimento

do público;

4.1.5.9. O crédito da venda do vale transporte deverá ocorrer na conta da

própria contratada;

4.1.5.10. Será fornecido pela contratada relatório por período (diário,

mensal, anual, etc.) das vendas efetuadas, vendas efetivadas,

vendas canceladas e vendas em processamento realizadas pelo

ponto de venda;




15

4.1.5.11. O valor referente à venda deverá ser depositado pela contratada

para a contratante por meio de Guia de Recolhimento da União

(GRU) em até 02 (dois) dias úteis após a sua efetivação;

4.1.5.12. Os custos das operações financeiros decorrentes de vendas por

cartão de crédito/débito ou pagamento com documento bancário e

Guia de Recolhimento da União (GRU) serão de responsabilidade

da contratada;

4.1.6. Isenções:

Referem-se a todos os acessos gratuitos ao sistema, cujos beneficiários são

licenciados por força de lei ou por arbitramento do poder concedente. São divididos nas

seguintes categorias: idosos com 65 anos ou mais, portadores de necessidades especiais

–PPNEs, policiais da Brigada Militar, oficiais de justiça, crianças de até 5 anos,

visitantes (desde que autorizados pela UO responsável), permissionários, metroviários

aposentados e funcional.

Dessas categorias, apenas idosos, permissionários, metroviários aposentados e

funcionais possuem cartão identificado com nome e foto, através de cadastro prévio.

Para as categorias que não possuem cartão de identificação, a contratada deverá elaborar

projeto para eficiente processo de controle de qualificação e quantificação desses

usuários, quando do acesso à linha de bloqueios, de modo a facilitar a contabilidade e

regulamentar o acesso destes outros grupos;

4.1.6.1. O sistema de vendas (POS) deverá prever a cobrança da 2ª Via dos

Cartões de Isenção, no caso de idosos e permissionários, devendo essa

informação ser armazenada no banco de dados e constar no

procedimento de fechamento de caixa.

4.1.6.2. A Trensurb poderá consultar, em tempo real, o quantitativo de usuários

por categoria de isenção, histórico de acessos para 01 usuário, para

grupo de usuários e/ou para todos os usuários isentos.

4.1.6.3. Idosos com 65 anos ou mais:

4.1.6.3.1. O cartão terá características físicas semelhantes ao Cartão PA-

SIM, trata-se de uma mídia com padrão de leitura QRCode ou

similar quanto a sua performance e baixo custo de aquisição.

Devendo permitir o controle de utilização, em tempo real, e

sendo, ainda, totalmente imune a falsificações, valendo-se de

tecnologia ou dispositivo que garanta a inviolabilidade dos

dados, replicações ou quaisquer outros artifícios ilegais que

possam ser utilizados para comprometer a segurança financeira

e de dados no processo de bilhetagem eletrônica, porém com

layout diferenciado a ser definido pela Trensurb;




16

4.1.6.3.2. O local para cadastramento será a Central de Atendimento ao

Usuário, que deverá ser instalada em local a ser definido pela

Trensurb.

4.1.6.3.3. O cadastro deve ser realizado por intermédio de computadores

conectados ao data center da Trensurb, através de um domínio

que permita diretivas de segurança com maior nível de

abrangência;

4.1.6.3.4. Os servidores deverão armazenar todas as informações

referentes às isenções, aos cadastros, aos acessos, às 2ª vias, às

fraudes de uso e outras informações necessárias à operação e

gestão das isenções;

4.1.6.3.5. O Sistema que controla o acesso dos usuários através dos

bloqueios deverá prever, valendo-se de ferramentas que

agreguem segurança antifraude, um processo de

reconhecimento facial ou método similar, contanto que seja

automatizado para a identificação da fraude ou uso indevido;

4.1.6.3.6. O sistema de vendas (POS) deverá prever a cobrança da 2ª Via

dos Cartões de isenção, devendo essa informação ser

armazenada no banco de dados e constar no procedimento de

fechamento de caixa;

4.1.6.3.7. Deverá ser outorgada à Trensurb, por parte da contratada, a


quantitativo de usuário, dos valores de recarga, dos históricos

de recargas, tanto para um usuário ou um grupo de usuários,

quanto para todos os usuários cadastrados.

4.1.6.3.8. Os cartões de isenção, exceto de empregados do SEOPE

permitirão o passe somente a cada 15 minutos.

4.1.6.4. Permissionários:

4.1.6.4.1. Será elaborado um cartão com características físicas e

operacionais semelhantes ao Cartão PA-SIM, porém com

layout diferenciado a ser definido pela Trensurb;

4.1.6.4.2. O cartão permissionário terá características de aquisição,

controle e operacional semelhantes ao cartão de idoso, porém,

somente será válido para acesso na estação em que o

permissionário possuir concessão.

4.1.6.5. Metroviário Aposentado:

4.1.6.5.1. Todo o metroviário aposentado poderá adquirir o cartão, cujas

características físicas e operacionais são iguais ao cartão de

idoso, porém com layout diferenciado, a ser definido pela

Trensurb.




17

4.1.6.6. Funcional:

4.1.6.6.1. O cartão funcional terá características físicas e operacionais

semelhantes ao cartão do metroviário aposentado;

4.1.6.6.2. A contratada deverá fazer o cadastramento e a emissão do

cartão funcional de todos empregados mediante solicitação da

Trensurb;

4.1.6.6.3. O cartão funcional dos empregados do Setor de Operações,

além de possibilitar acesso à linha de bloqueios como os

demais empregados, deverá ter prerrogativas para liberações de

outras isenções, (o cartão funcional dos supervisores terá,

também, a autorização para abertura e fechamento de caixa),

acesso ao Sistema de vendas (POS) e demais funções de

gestão, como configuração de bloqueios controle e supervisão

específicas da área de Operações, a serem definidas pela

Trensurb.

4.1.7. Data Center

A contratada deverá montar uma infraestrutura de servidores, storages, backups,

com data center dualizados independentes, de forma que garantam o pleno

funcionamento do sistema de bilhetagem com alta disponibilidade. A contratada poderá

utilizar toda a infraestrutura de fibra óptica, cabeamento UTP e wireless da Trensurb.

Outra infraestrutura que se fizer necessário será de responsabilidade da contratada.

Considerando que a Trensurb mantém um convênio com a PROCEMPA – Companhia

de Processamento de dados de Porto Alegre, a contratada poderá utilizar a infraestrutura

da PROCEMPA para instalação do data center redundante. As tratativas e projetos

deverão ser acordados em outro momento.

4.1.7.1. Um dos data centers deverá estar dentro das dependências da

Trensurb, com as seguintes características:

4.1.7.1.1. Deve possuir No-Breks redundantes (Conforme descrito neste

edital);

4.1.7.1.2. Deve possuir climatização redundante, Ares condicionados de

precisão, que suportem toda a solução na temperatura inferior a

18o graus;

4.1.7.1.3. Deve estar dentro das normais de Data centers nos Níveis 1 e

2;

4.1.7.1.4. Devem suportar duas entradas de energia diferentes, com

sistema de comutação automática;




18

4.1.7.1.5. Deve possuir sistema de contra incêndio;

4.1.7.1.6. Deve possuir câmeras de segurança para registrar todos os

acessos ao data center;

4.1.7.1.7. Deve possuir Nível de proteção IP20;

4.1.7.1.8. Deve possuir sistema de alarmes e Gerenciamento com as

seguintes características:

4.1.7.1.9. Detecção de falha e alarme de qualquer um dos componentes

ou Data Center;

4.1.7.1.10. Detecção de Fogo;

4.1.7.1.11. Detecção de fumaça;

4.1.7.1.12. Detecção de falhas de ar Condicionado;

4.1.7.1.13. Detecção de Alagamentos;

4.1.7.1.14. Detecção de falhas de No-Breks;

4.1.7.1.15. Detecção de interrupção do fornecimento de energia elétrica;

4.1.7.1.16. Deve possuir a função de rodizio de Ares Condicionados,

sendo o ciclo programado pelo próprio usuário.

4.1.7.1.17. Deverá a administração ter pleno e Gestão de todo o sistema.

4.1.7.1.18. A solução de armazenamento deve ser constituída por 02

(duas) controladoras de discos, operando na modalidade de

cluster com operação Ativo/Ativo sem ponto único de falha,

de modo a implementar total e plena disponibilidade,

realizando “failover” automático;

4.1.7.1.19. A solução de armazenamento ofertada deverá ser nova, estar

atualmente em linha de produção e constar no catálogo mais

recente do fabricante. Não serão aceitos equipamentos

usados, remanufaturados, de demonstração, gateways,

versões anteriores aos modelos mais recentes ou composições

feitas única e exclusivamente para o presente certame,

durante a vigência do contrato;

4.1.7.1.20. Deverá suportar os seguintes protocolos: ISCSI, CIFS e NFS.

Esses protocolos devem estar habilitados para uso nativo e de

forma simultânea, sem adição de equipamentos ou módulos

adicionais, para a solução de armazenamento oferecida;

4.1.7.1.21. Deverá ser constituído de, pelo menos, um par de

controladoras ou módulos configurados em alta

disponibilidade, sem ponto único de falha, de modo a

disponibilizar aos sistemas clientes total e pleno acesso a toda

a área de armazenamento da solução sem prejuízo de

funcionalidade, mesmo em situação de falha de qualquer um

dos seguintes componentes da controladora: CPU, memória

cache, barramento de dados, fonte de alimentação, sistema de




19

refrigeração ou interfaces de comunicação Ethernet ou Fiber

Channel;

4.1.7.1.22. Deverá possuir barramentos de alta velocidade entre as

controladoras, dedicados para espelhamento dos dados de

escrita com a função de garantir que, mesmo na falha de uma

controladora, todos os dados gravados estejam protegidos na

outra controladora;

4.1.7.1.23. Em caso de falha de alguma controladora ou componente do

sistema de armazenamento de dados, um componente

redundante equivalente deverá assumir automaticamente

(failover automático) as funções e as respostas às requisições

encaminhadas pelos sistemas clientes;

4.1.7.1.24. As controladoras devem funcionar de modo ATIVO /

ATIVO, ou seja, devem estar em uso simultâneo,

independente da rede de armazenamento SAN ou NAS,

gravando e fornecendo dados.

4.1.7.1.25. A Solução de Armazenamento deverá possuir, no mínimo,

32GB (trinta e dois gigabytes) de memória cache total e

ativo, para ser atendido por todos os protocolos SAN (ISCSI)

e NAS (CIFS e NFS), sendo no mínimo 4GB (quatro

gigabytes) de memória não volátil (NVRAM);

4.1.7.1.26. A memória cache solicitada deverá ser apresentada de

maneira global, ser do tipo DRAM com proteção ECC (Error

Correction Code) ou similar, de modo que não serão aceitos,

para a composição de memória cache solicitada, a utilização

de tecnologias Flash Card ou Discos SSD;

4.1.7.1.27. A memória cache e a memória não volátil devem estar

igualmente distribuídas entre o par de controladoras, ou seja,

no mínimo 16GB (dezesseis e dois gigabytes) de memória

cache e no mínimo 2GB (dois gigabytes) de memória não

volátil (NVRAM) por controladora.

4.1.7.1.28. Não serão aceitos equipamentos que dependam de

dispositivos intermediários como gateways, roteadores,

switches ou quaisquer elementos semelhantes;

4.1.7.1.29. Deverá possuir a seguinte composição de portas de front-end

ativas e igualmente distribuídas entre as controladoras:

4.1.7.1.29.1. 04 (quatro) portas Ethernet Fibra com conectores

SFP+ para formar a rede dedicada e redundante do

cluster;

4.1.7.1.29.2. 04 (quatro) portas 10GbE - Dez Gigabit Ethernet UTP

para acesso NFS, CIFS e ISCSI;

4.1.7.30. Deverá possuir, no mínimo, 4 (quatro) portas SAS para Back-End

operando a uma taxa de transferência mínima de 6Gbps,

implementar arquitetura com quádruplo transporte de dados por

cada canal (SAS Wide 2.0) ou arquitetura semelhante, de modo que




20

seja implementada total redundância e alta taxa de transferência no

conjunto de backend.

4.1.7.31. Deverá permitir o crescimento vertical (scale-up), ou seja, a

expansão da capacidade de armazenamento de dados, somente com

a instalação de novas gavetas de discos, e no mínimo 144 (Cento e

quarenta e quatro) discos físicos.

4.1.7.32. Deverá permitir o crescimento horizontal (scale-out) com

equipamentos do mesmo fabricante, mesmo que de modelos

diferentes, dentro de uma mesma solução em modalidade cluster

com, no mínimo, as seguintes funcionalidades:

4.1.7.32.1. Entende-se por nó do cluster, um conjunto autônomo

contendo: CPUs, interfaces de comunicação, memória,

memória não volátil, controladora de discos e discos, de

modo a permitir crescimento próximo a linear da capacidade

de processamento, throughput, área de armazenamento de

dados;

4.1.7.32.2. Cada nó deve ser autônomo, contendo internamente todos os

componentes descritos acima. Não serão aceitas soluções que

contenham nós intermediários ou que possuam funções

específicas de acesso ou armazenamento no cluster.

4.1.7.32.3. A solução deve ainda garantir a perda completa de qualquer

componente do nó ou o nó em sua totalidade sem qualquer

perda de dados ou indisponibilidade, ainda que parcial da

solução.

4.1.7.33. A rede interna de comunicação, que proporciona a sincronização do

trabalho entre os nós do cluster, deverá ser dedicada e redundante,

especialmente desenhada e implantada separadamente da rede de

serviços de compartilhamento de áreas de armazenamento (front-

end);

4.1.7.34. A rede de comunicação entre os nós do storage deverá ser

implantada por rede de dados, com velocidade mínima de 10 Gbps

(dez gigabits por segundo) por nó;

4.1.7.35. Permitir a expansão para, no mínimo, 08 (oito) nós de cluster SAN

e NAS;

4.1.7.36. Permitir a criação de global namespace para os protocolos CIFS e

NFS;

4.1.7.37. Suportar a movimentação de volumes e luns entre os equipamentos

de forma não disruptiva;

4.1.7.38. O equipamento ofertado deverá ser entregue preparado para

suportar a adição de futuros nós ao ambiente. Isso implica que a

solução entregue não deve ter necessidade de atualizações de

Sistema Operacional que necessitem parada no serviço, no

momento de adição de futuros nós ao cluster;




21

4.1.7.39. Deverá permitir a criação de um único volume/namespace com até

5 (cinco) petabytes, distribuído em até 08 (oito) nós do cluster;

4.1.7.40. Deverá suportar a instalação e utilização de discos dos seguintes

tipos:

4.1.7.40.1. SSD (Solid State Disk) eMLC ou SLC;

4.1.7.40.2. SAS (Serial Attached SCSI), 2.5 polegadas de tamanho, com

mínimo de 10.000 (dez mil) RPM;

4.1.7.40.3. NL-SAS (NearLine SAS) com mínimo de 7.200 (sete mil e

duzentas) RPM;

4.1.7.41. Deverá suportar proteção física de discos através da tecnologia

RAID, para Paridade Simples (RAID-4 ou RAID-5) e Paridade

Dupla (RAID-6 ou RAID-DP).

4.1.7.42. Deverá permitir a troca ou instalação de discos de modo

transparente (hotswap). Os discos de reserva (spare disk) devem ser

globais para cada controladora da solução de armazenamento.

Quando da falha de qualquer disco, a sua substituição lógica por

um disco de reserva deverá ser automática sem necessidade de

intervenção manual, por um disco de reserva, e sem que seja

necessário, posteriormente, qualquer nova movimentação ou cópia

de dados. Após essa substituição, o disco de reserva passará a ser

reconhecido definitivamente como disco de dados ou redundância.

Não será aceita solução que necessite de re-cópia ou re-

movimentação dos dados para um novo disco (No Copy Back);

4.1.7.43. Deverá possuir função de "call-home” por meio de linha telefônica

comum, email ou VPN (“Virtual Private network”) para

diagnóstico remoto em caso de erros/defeitos.

4.1.7.44. Deverá vir montado em rack padrão 19” do mesmo fabricante do

subsistema de armazenamento de dados.

4.1.7.45. Todos os cabos, racks, conexões de energia e quaisquer outros

materiais necessários para efetuar a ligação e operacionalização do

equipamento deverão ser fornecidos sem nenhum custo além da

proposta.

4 1.7.2. Funcionalidades da Solução

4.1.7.2.1. Deverá ser fornecido com licenciamento de software e

funcionalidades para a capacidade máxima possível da solução

de armazenamento oferecida neste termo, independente da

capacidade de armazenamento solicitada no instante inicial;

4.1.7.2.2. Deverá suportar o provisionamento virtual da capacidade

(virtual ou thin provisioning) de volumes ou partições lógicas,

devendo funcionar para qualquer tipo de dado disponível na

solução de armazenamento. Deverá estar ativado para uso em




22

toda solução de armazenamento, podendo ser possível habilitar

e desabilitar esta funcionalidade de forma não disruptiva e

imediata na granularidade de volumes lógicos;

4.1.7.2.3. Deverá permitir o redimensionamento (aumento e/ou

diminuição) imediato do tamanho dos volumes/LUNs

acessados pelos sistemas clientes ligados à solução de

armazenamento sem impacto ou reconfiguração para os

clientes;

4.1.7.2.4. Deverá permitir a alocação da área de armazenamento, a

critério do administrador da solução de armazenamento, em

qualquer proporção entre as arquiteturas solicitadas, SAN e

NAS; isto é, podemos ir de 100% (cem por cento) SAN a

100% (cem por cento) NAS, passando por todas as

combinações possíveis em passos de 1% (um por cento);

4.1.7.2.5. A solução de armazenamento deve ter capacidade para

transferência automática de dados com granularidade em nível

de bloco ou sub-LUN entre pelo menos 2 (duas) camadas/tipos

de discos de armazenamento, sendo no mínimo SAS com SSD

e NLSAS/SATA com SSD, conforme perfil de acesso aos

dados (Auto Data Tiering). A funcionalidade deverá ser

licenciada para a capacidade total de armazenamento suportada

pelo equipamento;

4.1.7.2.6. Deverá permitir, com adição de discos SSD, funcionalidade de

extensão de memória cache em discos SSD ou dispositivos de

memória Flash para operações de leitura (“fast cache”, “flash

cache” ou similar) devidamente licenciada e instalada na

capacidade de no mínimo de 1TB (um terabytes) brutos,

distribuídos igualmente entre as controladoras;

4.1.7.2.7. Deverá possuir recursos para gerenciamento e proteção de

dados que permita a gravação de Backups Disk-to-Disk-to-

Tape, devidamente licenciada para sua capacidade máxima de

armazenamento e pronta para ser utilizada;

4.1.7.2.8. Deverá ter a capacidade de ser integrado ao protocolo

Kerberos para o serviço de autenticação para o Microsoft

Windows Active Directory Service para Windows 2003, 2008

e 2012;

4.1.7.2.9. Deverá ter a capacidade de ser integrado ao protocolo LDAP;

4.1.7.2.10. Deverá suportar, para o ambiente NAS, o controle de quotas

por usuários e pastas, implementado nativamente no sistema,

sem necessidade de instalar nenhum outro produto adicional;

4.1.7.2.11. Deverá ser fornecido com suporte e licença para os

protocolos NFS versões 3 e 4, e CIFS/SMB versões 1.0 e 2.0,

2.1 e 3.0. Estes protocolos deverão estar licenciados e

ativados para toda a solução;




23

4.1.7.2.12. Deverá permitir executar a função de servidor de arquivos,

diretamente do sistema de armazenamento de dados, para

clientes NAS sem necessidade de instalação de outros

servidores ou quaisquer equipamentos ou controladoras

adicionais;

4.1.7.2.13. Deverá utilizar mecanismos de file-locking seguro entre os

clientes usando protocolos CIFS e NFS, controlando o acesso

simultâneo aos dados pelos usuários/aplicações;

4.1.7.2.14. Deverá implementar ABE (Access-Based Enumeration) para

compartilhamentos CIFS, não permitindo visibilidade ou

acesso ao compartilhamento ou arquivos abaixo da pasta de

compartilhamento para usuários que não têm permissão para

isso;

4.1.7.2.15. Deverá implementar o protocolo ISCSI para os ambientes

operacionais com VMware ESX, Red Hat Linux, SuSE Linux

e Microsoft Windows via Microsoft-Logo Certified,

constando na HCL da Microsoft;

4.1.7.2.16. Deverá implementar o protocolo FCP para os ambientes

operacionais com VMware ESX, Red Hat Linux, SuSE Linux

e Microsoft Windows via Microsoft-Logo Certified,

constando na HCL da Microsoft;

4.1.7.2.17. A solução de armazenamento deverá suportar, no mínimo,

4.096 volumes lógicos (LUNs);

4.1.7.2.18. Deverá incluir mecanismo de LUN Masking, permitindo que

volumes lógicos sejam acessados somente por

servidores/clientes devidamente autorizados;

4.1.7.2.19. Deverá ser fornecido com a funcionalidade de “snapshot”, ou

“point-in-time backup”, de quaisquer áreas de dados

(volume/LUN) da solução, deverá ser implementado através

de administração de ponteiros aos blocos de dados, com

capacidade de armazenar, no mínimo, 250 (duzentas e

cinquenta) versões por cada volume/LUN existente na

solução de armazenamento. Esta funcionalidade deverá ser

executada internamente à solução de armazenamento, sem

consumir ciclo de CPU dos sistemas clientes conectados e

sem gerar movimentação de dados de nenhum tipo.

4.1.7.2.20. Deverá ser fornecido com a capacidade de recuperação de

dados completa de áreas usadas de snapshot, através da

administração de ponteiros aos blocos de dados, sem

movimentação ou cópia de dados, por comando

administrativo na solução de armazenamento. Deverá ser

fornecido o licenciamento desta funcionalidade considerando

a capacidade máxima de crescimento possível do sistema de

armazenamento de dados oferecido;




24

4.1.7.2.21. Deverá ser fornecido com a funcionalidade de criar cópias

“clone”, com gerenciamento totalmente independente dos

dados originais, para qualquer volume lógico configurado na

solução de armazenamento. Deverá ser possível transformar

qualquer cópia clone em um novo volume lógico

independente a qualquer momento. O clone deverá ser criado

a partir de administração de ponteiros aos blocos de dados

originais, não sendo necessária movimentação de dados para

sua criação ou existência. Deverá ser possível a criação de

clones a partir de clones existentes. Deverá ser fornecido o

licenciamento desta funcionalidade considerando a

capacidade máxima de crescimento possível do sistema de

armazenamento de dados oferecido;

4.1.7.2.22. Deverá suportar a capacidade de replicação remota de

volumes entre os sistemas de armazenamento de dados, para

modelos iguais e diferentes de equipamentos do mesmo

fabricante. Será usado para criação de ambiente de DR

(Disaster Recovery) de forma bidirecional, sobre rede

baseada em protocolo IP, de forma assíncrona. Esta

funcionalidade deve ser gerenciável e configurável através da

interface de gerência própria da solução de armazenamento.

Deverá possuir a capacidade de controle de banda de rede

usada para a replicação. Esta funcionalidade deverá ser

executada internamente ao sistema de armazenamento de

dados, para qualquer tipo de dado armazenado, sem a

necessidade de incluir nenhum equipamento adicional e sem

consumir ciclo de CPU dos sistemas dos clientes conectados

ao sistema de armazenamento de dados, devendo estar

licenciado sem limitação do volume de dados a serem

replicados;

4.1.7.2.23. Deverá ser fornecido com a capacidade nativa do

equipamento para desduplicar os blocos dados gravados no

sistema de armazenamento de dados, eliminando dos

volumes os blocos de dados iguais. A desduplicação deverá

funcionar para qualquer tipo de dado disponível na solução

de armazenamento, tanto para dados disponibilizados através

da rede SAN, quanto através da rede NAS;

4.1.7.2.24. Deverá permitir monitoramento por meio do protocolo

SNMP versões v1, v2c e v3 com acesso às MIBS de

descrição dos objetos e traps SNMP da solução de

armazenamento. Deverá ter suporte a IPv4 e IPv6;

4.1.7.2.25. Deverá ter suporte nativo ao protocolo IPv6, com suporte

simultâneo a IPv4, devendo estar devidamente licenciado

para toda a solução de armazenamento;

4.1.7.2.26. Deverá suportar agregação de interfaces de rede no sistema

de armazenamento de dados, permitindo aumento de

resiliência, disponibilidade e balanceamento de carga. Deverá




25

permitir agregação estática, compatível com o padrão IEEE

802.3ad e LACP (Link Aggregation Control Protocol,

compatível com o padrão IEEE 802.3 AD (802.1 AX);

4.1.7.2.27. Deverá ter suporte nativo a VLAN (Virtual Local Area

Network) para segmentação das redes ao criar domínios de

broadcast separados. Deverá ser compatível com o padrão

IEEE 802.1Q;

4.1.7.2.28. Deverá ser fornecido com a capacidade nativa para a

compressão dos dados gravados no sistema de

armazenamento de dados, comprimindo os dados antes de

serem armazenados nos discos. A compressão deverá

funcionar para qualquer tipo de dado disponível na solução

de armazenamento, tanto para dados disponibilizados através

de rede SAN, quanto através de rede NAS;

4.1.7.2.29. Deverá possuir suporte nativo para VMware vSphere API for

Array Integration (VAAI), VMware vStorage APIs for

Storage Awareness (VASA) e VMware vCenter Site

Recovery Manager (SRM);

4.1.7.2.30. Deverá integrar com servidor de antivírus da Trensurb,

conectados via rede ao sistema de armazenamento de dados.

A funcionalidade deve permitir selecionar os tipos de

arquivos que devem ser verificados pelo servidor de

antivírus. Se for detectado que o arquivo está infectado, a

funcionalidade deve permitir a configuração de uma limpeza

automática. Deverá suportar e ser compatível pelo menos

com os seguintes fornecedores de software de antivírus:

McAfee, Symantec e TrendMicro;

4.1.7.2.31. Deverá contemplar a funcionalidade que permita a replicação

interna de volumes entre ás áreas de disco SAS e NL-

SAS/SATA de forma manual. Tal funcionalidade deverá

estar licenciada na modalidade ilimitada, ou seja, não deverá

ser relicenciada no caso de expansão da capacidade de

armazenamento;

4.1.7.2.32. Deverá permitir gerenciamento de qualidade de serviço

(QoS) para definir o limite de IOPs (I/O por segundo) ou

MB/s (Megabytes por segundo) que será utilizado em nível

de volumes e LUNs;

4.1.7.2.33. Deverá contemplar a funcionalidade de volumes flexíveis,

isto é, permitir ao administrador do sistema a flexibilidade de

aumentar e diminuir dinamicamente, on-line e de forma

transparente, o tamanho de um volume NAS;

4.1.7.2.34. Deverá suportar a redução de volumes Microsoft Windows

Server 2008. Essa redução deve ser executada on-line e sem

nenhum impacto para as aplicações.




26

4.1.7.3 Características de Redundância

4.1.7.3.1. Deverão ser fornecidos todos os componentes internos

(incluindo controladoras de discos, ACPs, Disk Adapters, etc),

de maneira a garantir o máximo aproveitamento da capacidade

de I/O do conjunto de discos tomando como base a capacidade

de expansão máxima do equipamento;

4.1.7.3.2. Permitir manutenção, reparo, substituição e acréscimo de

componentes incluindo discos, fontes e ventiladores com o

sistema em operação, ou seja, os componentes devem ser “Hot

Swappable”;

4.1.7.3.3. Deverá possuir fontes de alimentação elétrica 220 VAC

redundantes.

4.1.7.4 Integração com Aplicações

4.1.7.4.1. Deverá possuir as seguintes funcionalidades para VMware:

4.1.7.4.2. Permitir a geração, por interface gráfica, de snapshots íntegros,

restore e espelhamento de máquinas virtuais;

4.1.7.4.3. Permitir o backup e restore com granularidade em nível de

máquina virtual;

4.1.7.4.4. Tais funcionalidades deverão ser nativas do subsistema de

armazenamento de dados, devendo estar licenciadas para

utilização ilimitada de servidores VMWare.

4.1.7.4.5. Deverá possuir as seguintes funcionalidades para Microsoft

Exchange:

4.1.7.4.5.1. Permitir a utilização por interface gráfica de

recursos de backup e restore das bases de dados do

Exchange;

4.1.7.4.5.2. Possuir ferramenta para permitir a restauração de

um objeto do exchange, como uma mensagem de email

por exemplo;

4.1.7.4.5.3. Permitir a validação dos snapshots utilizando a

ferramenta da Microsoft Eseutil;

4.1.7.4.5.4. Suportar as versões Microsoft Exchange 2007,

2010 e 2013;

4.1.7.4.5.5. A solução deverá suportar licenciamento para

utilização ilimitada de servidores Exchange.

4.1.7.5. Software de Gerenciamento




27

4.1.7.5.1. Possuir software de gerenciamento

centralizado com as seguintes funcionalidades:

4.1.7.5.1.1. Definição de áreas de acesso para os clientes,

análise de performance, determinação de problemas,

monitoração do uso e desempenho do sistema de

entrada/saída e utilização dos demais recursos do servidor

de armazenamento;

4.1.7.5.1.2. Controle e análise de capacidade e configuração

dos parâmetros físicos e lógicos do subsistema de

armazenamento;

4.1.7.5.1.3. Alocação dinâmica dos volumes lógicos das

unidades entre os servidores;

4.1.7.5.1.4. Correlação de eventos e diagnóstico de

performance;

4.1.7.5.1.5. Interface de gerenciamento gráfica e/ou Web, com

controle de acesso seguro via HTTPS e SSH;

4.1.7.5.1.6. Notificação de eventos críticos e mudanças,

possibilitando uma administração pró-ativa;

4.1.7.5.1.7. Gerenciamento dos “RAID GROUPS” em diversas

plataformas;

4.1.7.5.1.8. Monitoramento pró-ativo que permita a detecção e

isolamento de falhas até mesmo antes que elas ocorram.

Tal função abrangerá desde a automonitoração e geração

de log de erros, detecção e isolamento de erros de

memória, detecção e isolamento de erros no disco,

inclusive acionamento automático de disco de spare;

4.1.7.5.1.9. Permitir o gerenciamento com provisionamento de

crescimento do subsistema.

4.1.7.6. Compatibilidades:

4.1.7.6.1. Deverá ser compatível com:

4.1.7.6.1.1. Sistemas Operacionais: Microsoft Windows Server

2008 e 2012 e Linux Red Hat Enteprise versão 5 e 6 ou

superior;

4.1.7.6.1.2. Software de virtualização VMware ESX ou ESXi 5

ou superior;

4.1.7.6.1.3. Servidor de e-mail Exchange 2010 ou superior,

mesmo quando estes forem instalados em ambientes

clusterizados;

4.1.7.6.2. Não serão permitidas soluções de virtualização de storages.

4.1.7.6.3. O equipamento deve ser compatível com as normas

estabelecidas pela SNIA (Storage Networking Industry




28

Association) e prover interface de gerenciamento de acordo

com o padrão SMI-S (Storage Management Initiative

Specification) versão 1.4 ou superior, para gerenciamento do

ambiente através de ferramentas de gerência de infraestrutura

de armazenamento que utilizem esse padrão. A conformidade

será verificada através de consulta ao site oficial do SNIA

http://www.snia.org/ctp/conformingprovidersarchive/index.ht

ml ou através de documentação oficial e publicada no site do

fabricante.

4.1.7.7. Rack padrão 19” – 42U.

4.1.7.7.1. Deverá vir completo, com sistema de PDUs, réguas

distribuição, sistemas de ventilação e demais acessórios

necessários para perfeita instalação dos demais itens

solicitados;

4.1.7.7.2. Deverá possuir porta com sistema de segurança para proteção

dos equipamentos;

4.1.7.8. Servidor de Arquivos/Aplicações

4.1.7.8.1. Deverão ser fornecidas 04 (quatro) unidades conforme as

especificações abaixo:

4.1.7.8.2. Processadores - mínimo instalado de 02 (dois) processadores

4.1.7.8.3. Projetados especificamente para utilização em servidores

4.1.7.8.4. Suportar no mínimo 8 (oito) cores cada;

4.1.7.8.5. Clock de no mínimo 2 GHz;

4.1.7.8.6. Mínimo de 20 MB de memória cache;

4.1.7.8.7. Tecnologia de aumento e controle da frequência de clock e

tensão de acordo com a utilização dos núcleos do processador;

4.1.7.8.8. Suportar virtualização;

4.1.7.8.9. Possuir recurso de hyper threading.

4.1.7.8.10. Memória:

4.1.7.8.10.1. Padrão DDR4 ou superior;

4.1.7.8.10.2. 64 GB de memória RAM já instalados e possibilidade de

expansão para no mínimo 512 GB;

4.1.7.8.10.3. Suportar tecnologia para detecção e correção de falhas de

chip.

4.1.7.8.11. Armazenamento em disco:

4.1.7.8.11.1. 2 (dois) discos SAS, redundantes, com no mínimo

300Gb;

4.1.7.8.11.2. Controladora RAID por hardware.




29

4.1.7.8.12. Interfaces de rede:

4.1.7.8.12.1. 4 (quatro) interfaces Ethernet 1/100/1000Gb (conexão

rede local);

4.1.7.8.12.2. 2 (duas) interfaces Ethernet 10Gb (conexão rede de

armazenamento);

4.1.7.8.12.3. Virtual LANs (IEEE 802.1q), Link Aggregation Control

Protocol (LACP) e Flow Control (IEEE 802.3x);

4.1.7.8.12.4. Jumbo frame, IPv4 e IPv6.

4.1.7.9. Características Gerais

4.1.7.9.1. Projetado para utilização em rack;

4.1.7.9.2. Incluir todos os itens necessários para sua instalação, como

trilhos para rack, cabos de alimentação, conexão ao KVM,

etc;

4.1.7.9.3. Informação do número de série do equipamento na BIOS e

um campo editável para inserção de identificação

customizada. As duas informações devem ser passíveis de

consulta via software de gerenciamento;

4.1.7.9.4. Possuir software de gerenciamento, o qual deverá monitorar o

equipamento e fornecer notificações no mínimo por ¬e-mail

notificando problemas em alguma peça ou parte do

equipamento;

4.1.7.9.5. Monitorar no mínimo: temperatura, discos, memórias, fontes,

VRM e processadores.

4.1.7.9.6. Possuir painel de notificação frontal indicando situação do

equipamento de normalidade ou eventual problema/falha;

4.1.7.9.7. O modelo do servidor deve estar certificado para utilização

nos sistemas operacionais MS Windows Server 2008 R2 x64,

2012 R2 x64 e 2016 x64, Red Hat Enterprise Linux, VMware

e XenServer, nas suas suas versões mais recentes. A

comprovação deve ser realizada através do respectivo

documento disponibilizado por cada fabricante de sistema

operacional;

4.1.7.9.8. Garantia de 60 (sessenta) meses, 24x7, incluindo serviço no

local de substituição das peças defeituosas, provida pelo

fabricante, não sendo aceita garantia fornecida por terceiros.

O fabricante deverá oferecer atendimento no Brasil via

telefone, bem como website contendo drivers e demais

softwares associados aos produtos, bem como registro da

garantia e atendimentos realizados.

4.1.7.10. Fonte de Alimentação

4.1.7.10.1. Redundante, com troca à quente (hot swap);




30

4.1.7.10.2. Fonte de alimentação com certificação 80plus no mínimo

Gold.

4.1.7.11. Servidor de Gerência / Backup

4.1.7.11.1. Deverá ser fornecido 01 (uma) unidade conforme as


4.1.7.11.1.1. Processadores - mínimo instalado de 02 (dois)

processadores

4.1.7.11.1.2. Projetados especificamente para utilização em

servidores;

4.1.7.11.1.3. Suportar no mínimo 8 (oito) cores cada;

4.1.7.11.1.4. Clock de no mínimo 2 GHz;

4.1.7.11.1.5. Mínimo de 20 MB de memória cache;

4.1.7.11.1.6. Tecnologia de aumento e controle da frequência de

clock e tensão de acordo com a utilização dos núcleos do

processador;

4.1.7.11.1.7. Suportar virtualização;

4.1.7.11.1.8. Possuir recurso de hyper threading.

4.1.7.11.2. Memória:

4.1.7.11.2.1. Padrão DDR4 ou superior;

4.1.7.11.2.2. 32 GB de memória RAM já instalados e

possibilidade de expansão para no mínimo 512 GB;

4.1.7.11.2.3. Suportar tecnologia para detecção e correção de

falhas de chip.

4.1.7.11.3. Armazenamento em disco:

4.1.7.11.3.1. 2 (dois) discos SAS, redundantes, com no mínimo

300Gb;

4.1.7.11.3.2. 4 (quatro) discos NLSAS, redundantes, com no

mínimo 2TB;

4.1.7.11.3.3. Controladora RAID por hardware.

4.1.7.11.4. Interfaces de rede:

4.1.7.11.4.1. 4 (quatro) interfaces Ethernet 1/100/1000Gb

(conexão rede local);

4.1.7.11.4.2. 2 (duas) interfaces Ethernet 10Gb (conexão rede de

armazenamento);

4.1.7.11.4.3. 2 (duas) interfaces FC 8Gb (conexão tape library);

4.1.7.11.4.4. Virtual LANs (IEEE 802.1q), Link Aggregation

Control Protocol (LACP) e Flow Control (IEEE 802.3x);

4.1.7.11.4.5. Jumbo frame, IPv4 e IPv6.

4.1.7.11.5. Características Gerais:

4.1.7.11.5.1. Projetado para utilização em rack;

4.1.7.11.5.2. Incluir todos os itens necessários para sua

instalação, como trilhos para rack, cabos de alimentação,

conexão ao KVM, etc;

4.1.7.11.5.3. Informação do número de série do equipamento na

BIOS e um campo editável para inserção de identificação




31

customizada. As duas informações devem ser passíveis

de consulta via software de gerenciamento;

4.1.7.11.5.4. Possuir software de gerenciamento, o qual deverá

monitorar o equipamento e fornecer notificações no

mínimo por ¬e-mail notificando problemas em alguma

peça ou parte do equipamento;

4.1.7.11.5.5. Monitorar no mínimo: temperatura, discos,

memórias, fontes, VRM e processadores.

4.1.7.11.5.6. Possuir painel de notificação frontal indicando

situação do equipamento de normalidade ou eventual

problema/falha;

4.1.7.11.5.7. O modelo do servidor deve estar certificado para

utilização nos sistemas operacionais MS Windows

Server 2008 R2 x64, 2012 R2 x64 e 2016 x64, Red Hat

Enterprise Linux, VMware e XenServer, nas suas suas

versões mais recentes. A comprovação deve ser realizada

através do respectivo documento disponibilizado por

cada fabricante de sistema operacional;

4.1.7.11.5.8. Garantia de 60 (sessenta) meses, 24x7, incluindo

serviço no local de substituição das peças defeituosas,

provida pelo fabricante, não sendo aceita garantia

fornecida por terceiros. O fabricante deverá oferecer

atendimento no Brasil via telefone, bem como website

contendo drivers e demais softwares associados aos

produtos, bem como registro da garantia e atendimentos

realizados.

4.1.7.11.6. Fonte de Alimentação:

4.1.7.11.6.1. Redundante, com troca à quente (hot swap);

4.1.7.11.6.2. Fonte de alimentação com certificação 80plus no

mínimo Gold;

4.1.7.12. Licenciamento Virtualização / Backup

4.1.7.12.1. Deverá ser fornecido licenciamento de VMware vCenter

para gerenciamento e VMware vSphere 6 para todos

servidores de produção disponibilizados;

4.1.7.12.1.1. Possuir recurso de H.A. (High Availability);

4.1.7.12.1.2. Possuir recurso de vMotion e Cross Switch

vMotion;

4.1.7.12.1.3. Possuir recurso de Data Protection;

4.1.7.12.1.4. Possuir recurso de Replicação;

4.1.7.12.2. Deve possuir suporte 24x7 e direito a atualizações durante a

vigência do contrato, não sendo aceito licenciamento em

regime de OEM.




32

4.1.7.12.3. Deverá ser fornecido licenciamento de software de backup

para todo ambiente, contendo, no mínimo, as seguintes

características:

4.1.7.12.3.1. Ser homologado para hypervisor VMware;

4.1.7.12.3.2. Possibilitar a recuperação granular de arquivos;

4.1.7.12.3.3. Permitir configuração de replicação das máquinas

virtuais;

4.1.7.12.3.4. Caso o licenciamento seja por capacidade, deve ser

considerada a capacidade máxima da biblioteca de fitas

disponibilizada na solução;

4.1.7.12.3.5. Possibilitar a recuperação de máquinas virtuais em

janela inferior a 10 (dez) minutos;

4.1.7.12.3.6. Deve possuir suporte 24x7 e direito a atualizações

durante a vigência do contrato direto pelo fabricante da

solução, não sendo aceito licenciamento em regime de

OEM;

4.1.7.13. Robô de backup automatizado

4.1.7.13.1. Deverá ser entregue biblioteca de fitas interligada no

servidor de backup. Esta deve ser no padrão rack para

operação da solução de backup, possuindo os requisitos

mínimos de:

4.1.7.13.1.1. Suportar, no mínimo, 2 (dois) drive half-height

com a tecnologia LTO6;

4.1.7.13.1.2. Possuir, no mínimo, 24 (vinte e quatro) slots de

fitas de dados;

4.1.7.13.1.3. Padrão para instalação em rack de 19” de largura;

4.1.7.13.1.4. Possuir fontes de alimentação com tensão de

entrada de 110/220 V e frequência de 60 Hz;

4.1.7.13.1.5. Possuir leitor de código de barras com o objetivo

de identificar os cartuchos através das etiquetas;

4.1.7.13.1.6. Possuir drives com padrão de conexão FC;

4.1.7.13.1.7. A unidade de backup deve possuir capacidade de

ler, no mínimo, duas gerações anteriores e gravar em

uma geração anterior, ou seja, ler LTO5 e LTO4 e gravar

em LTO5;

4.1.7.13.1.8. Deverá ser entregue 20 (vinte) cartuchos padrão

ultrium LTO6 e 02 (dois) de cartuchos de limpeza;

4.1.7.13.1.9. Suportar gerenciamento via SNMP;

4.1.7.13.1.10. Suportar gerenciamento da unidade de backup

remotamente através de um web-browser, incluindo as




33

principais funções de operação e monitoração local da

Biblioteca;

4.1.7.13.1.11. Possuir gerenciamento de erros e status de logs;

4.1.7.13.1.12. Suportar os protocolos de rede IPv6 e IPv4;

4.1.7.13.1.13. A unidade de backup deve ser capaz de monitorar a

utilização dos drives e cartuchos;

4.1.7.13.1.14. Reportar informações através de notificação do status

do hardware como saúde e vida útil;

4.1.7.14. Conjunto de Switches LAN 10Gbps .

4.1.7.14.1. Deverão ser fornecidas duas unidades conforme as


4.1.7.14.1.1. Deve possuir, no mínimo, 12 portas

100Mb/1Gb/10GBASE-T;

4.1.7.14.1.2. Deve possuir, no mínimo, 04 portas

1Gb/10GBASE-X SFP+;

4.1.7.14.1.3. Deve possuir uma porta serial console RJ-45;

4.1.7.14.1.4. Deve possuir uma porta de gerenciamento

10/100/1000BASE-T out-of-band;

4.1.7.14.1.5. Deve possuir fontes de alimentação internas

redundantes;

4.1.7.14.1.6. Deve possuir ventilação front-to-back;

4.1.7.14.1.7. Deve possuir capacidade de switching de 320Gbps;

4.1.7.14.1.8. Deve possuir buffer de pacotes de, no mínimo,

2Mb;

4.1.7.14.1.9. Deve suportar 16000 endereços MAC;

4.1.7.14.1.10. Deve possuir latência máximo de 2,4 microsegundos;

4.1.7.14.1.11. Deve suportar o protocolo Data Center Bridging

(802.1Qaz & 802.1Qbb)

4.1.7.15. Sistema de alimentação elétrica ininterrupta (UPS)

4.1.7.15.1. Deverão ser fornecidas duas unidades conforme as


4.1.7.15.1.1. Possuir montagem padrão de rack 19” (compatível

com o rack fornecido na solução);

4.1.7.15.1.2. Possuir tensão de entrada 110V ou 220V e tensão

de saída 110V ou 220V;

4.1.7.15.1.3. Suportar tecnologia de dupla conversão de forma

on-line;

4.1.7.15.1.4. Possibilitar expansões futuras de outros bancos de

baterias do mesmo fabricante;




34

4.1.7.15.1.5. Baterias livres de manutenção;

4.1.7.15.1.6. Deverá ser capaz de suportar toda solução

disponibilizada, em seu pleno funcionamento, por

período não inferior a 30 (trinta) minutos;

4.1.7.15.1.7. Capacidade inicial não inferior a 3kVA;

4.1.7.15.1.8. Fator de eficiência mínimo de 92%;

4.1.7.15.1.9. Possuir interface para gerenciamento e

monitoração;

4.1.7.16. FIREWALL

A plataforma de segurança deve possuir a capacidade e as características

abaixo, por equipamento:

4.1.7.16.1. A plataforma de segurança deve possuir a capacidade e as

características abaixo, por equipamento:

4.1.7.16.2. Throughput de 1.8 Gbps com a funcionalidade de controle de

aplicação habilitada para todas as assinaturas que o fabricante

possuir;

4.1.7.16.3. Throughput de 750 Mbps com as seguintes funcionalidades

habilitadas simultaneamente para todas as assinaturas que a

plataforma de segurança possuir devidamente ativadas e

atuantes: controle de aplicação IPS, Antivírus e Antispyware.

Caso o fabricante divulgue múltiplos números de desempenho

para qualquer uma destas funcionalidades, somente o de menor

valor será aceito;

4.1.7.16.4. Os throughputs devem ser comprovados por documento de

domínio público do fabricante. A ausência de tais documentos

comprobatórios reservará ao órgão o direito de aferir a

performance dos equipamentos em bancada, assim como

atendimento de todas as funcionalidades especificadas neste

edital. Caso seja comprovado o não atendimento das

especificações mínimas nos testes de bancada, serão

considerados inabilitados e sujeitos as sanções previstas em lei;

4.1.7.16.5. Os documentos públicos devem comprovar os throughputs

aferidos com tráfego HTTP ou blend de protocolos definidos

pelo fabricante como tráfego real (real-word traffic blend);

4.1.7.16.6. Não será aceito aceleração de pacotes na placa de rede

limitando a análise somente até camada 4.

4.1.7.16.7. Suporte a, no mínimo, 180.000 conexões simultâneas;

4.1.7.16.8. Suporte a, no mínimo, 6.000 novas conexões por segundo;

4.1.7.16.9. Fonte 120/240 AC ou DC, redundante;

4.1.7.16.10. Disco Solid State Drive (SSD), no mínimo, 240 GB.




35

4.1.7.16.11. No mínimo, 04 (quatro) interfaces de rede 10/100/1000 base-

TX;

4.1.7.16.12. No mínimo, 04 (quatro) interfaces de rede 1 Gbps SFP;

4.1.7.16.13. No mínimo, 04 (quatro) interfaces de rede 10 Gbps SFP+;

4.1.7.16.14. 1 (uma) interface de rede 1 Gbps dedicada para

gerenciamento;

4.1.7.16.15. 1 (uma) interface do tipo console ou similar;

4.1.7.16.16. Suporte a, no mínimo, 30 (trinta) zonas de segurança;

4.1.7.16.17. Estar licenciada para ou suportar sem o uso de licença, 800

(oitocentos) clientes de VPN SSL simultâneos;

4.1.7.16.18. Estar licenciada para ou suportar sem o uso de licença, 200

(duzentos) túneis de VPN IPSEC simultâneos;

4.1.7.16.19. Por cada equipamento que compõe a plataforma de

segurança, entende-se o hardware e as licenças de softwares

necessárias para o seu funcionamento;

4.1.7.16.20. Por console de gerência e monitoração, entende-se as licenças

de software necessárias para as duas funcionalidades, bem

como hardware dedicado para o funcionamento das mesmas;

4.1.7.16.21. A console de gerência e monitoração podem residir no

mesmo appliance de proteção de rede, desde que possuam

recurso de CPU, memória, interface de rede e sistema

operacional dedicados para esta função;

4.1.7.16.22. Na data da proposta, nenhum dos modelos ofertados poderão

estar listados no site do fabricante em listas de end-of-life e

end-of-sale.

4.1.7.17. CARACTERÍSTICAS GERAIS DA SOLUÇÃO DE FIREWALL

4.1.7.17.1. A solução deve consistir de appliance de proteção de rede

com funcionalidades de Next Generation Firewall (NGFW), e

console de gerência e monitoração;

4.1.7.17.2. Por funcionalidades de NGFW entende-se: reconhecimento

de aplicações, prevenção de ameaças, identificação de

usuários e controle granular de permissões;

4.1.7.17.3. As funcionalidades de proteção de rede que compõe a

plataforma de segurança, podem funcionar em múltiplos

appliances desde que obedeçam a todos os requisitos desta

especificação;

4.1.7.17.4. A plataforma deve ser otimizada para análise de conteúdo de

aplicações em camada 7;

4.1.7.17.5. O hardware e software que executem as funcionalidades de

proteção de rede, bem como a console de gerência e




36

monitoração, devem ser do tipo appliance. Não serão aceitos

equipamentos servidores e sistema operacional de uso

genérico;

4.1.7.17.6. Todos os equipamentos fornecidos devem ser próprios para

montagem em rack 19”, incluindo kit tipo trilho para

adaptação se necessário e cabos de alimentação;

4.1.7.17.7. O software deverá ser fornecido em sua versão mais

atualizada;

4.1.7.17.8. Os dispositivos de proteção de rede devem possuir pelo

menos as seguintes funcionalidades:

4.1.7.17.8.1. Suporte a 4094 VLAN Tags 802.1q;

4.1.7.17.8.2. Agregação de links 802.3ad e LACP;

4.1.7.17.8.3. Policy based routing ou policy based forwarding;

4.1.7.17.8.4. Roteamento multicast (PIM-SM);

4.1.7.17.8.5. DHCP Relay;

4.1.7.17.8.6. DHCP Server;

4.1.7.17.8.7. Suporte a criação de objetos de rede que possam

ser utilizados como endereço IP de interfaces L3;

4.1.7.17.8.8. Suportar sub-interfaces ethernet logicas.

4.1.7.17.8.9. Suporte a, no mínimo, 4 (quatro) roteadores

virtuais na mesma instância de firewall;

4.1.7.17.9. O firewall deve ter a capacidade de testar o funcionamento de

rotas estáticas e rota default com a definição de um endereço

IP de destino que deve estar comunicável através de uma

rota. Caso haja falha na comunicação o firewall deve ter

a capacidade de usar rota alternativa para estabelecer

a comunicação;

4.1.7.17.10. Deve suportar os seguintes tipos de NAT:

4.1.7.17.10.1. Nat dinâmico (Many-to-1);

4.1.7.17.10.2. Nat dinâmico (Many-to-Many);

4.1.7.17.10.3. Nat estático (1-to-1);

4.1.7.17.10.4. NAT estático (Many-to-Many);

4.1.7.17.10.5. Nat estático bidirecional 1-to-1;

4.1.7.17.10.6. Tradução de porta (PAT);

4.1.7.17.10.7. NAT de Origem;

4.1.7.17.10.8. NAT de Destino;

4.1.7.17.10.9. Suportar NAT de Origem e NAT de Destino

simultaneamente;




37

4.1.7.17.10.10. Deve implementar Network Prefix Translation

(NPTv6), prevenindo problemas de roteamento

assimétrico;

4.1.7.17.10.11. Deve implementar o protocolo ECMP;

4.1.7.17.10.12. Deve implementar balanceamento de link por hash do

IP de origem;

4.1.7.17.10.13. Deve implementar balanceamento de link por hash do

IP de origem e destino;

4.1.7.17.10.14. Deve implementar balanceamento de link através do

método round-robin;

4.1.7.17.10.15. Deve implementar balanceamento de link por peso.

Nesta opção deve ser possível definir o percentual de

tráfego que será escoado por cada um dos links. Deve

suportar o balanceamento de, no mínimo, quarto links;

4.1.7.17.10.16. Deve implementar balanceamento de link através de

políticas por usuário e grupos de usuários do

LDAP/AD;

4.1.7.17.10.17. Deve implementar balanceamento de link através de

políticas por aplicação e porta de destino;

4.1.7.17.10.18. Deve implementar o protocolo Link Layer Dicovery

(LLDP), permitindo que o appliance e outros ativos da

rede se comuniquem para identificação da topologia da

rede em que estão conectados e a função dos mesmos

facilitando o processo de throubleshooting. As

informações aprendidas e armazenadas pelo appliance

devem ser acessíveis via SNMP;

4.1.7.17.10.19. Enviar log para sistemas de monitoração externos,

simultaneamente;

4.1.7.17.10.20. Deve haver a opção de enviar logs para os sistemas de

monitoração externos via protocolo TCP e SSL;

4.1.7.17.10.21. Deve permitir configurar certificado caso necessário

para autenticação no sistema de monitoração externo de

logs;

4.1.7.17.10.22. Proteção contra anti-spoofing;

4.1.7.17.10.23. Deve permitir bloquear sessoes TCP que usarem

variações do 3-way hand-shake, como 4 way e 5 way

split hand-shake, prevenindo desta forma possíveis

tráfegos maliciosos;

4.1.7.17.10.24. Dever permitir bloquear conexões que contenham

dados no payload de pacotes TCP-SYN e SYN-ACK

durante o three-way handshake;




38

4.1.7.17.10.25. Deve exibir nos logs de tráfego o motivo para o

término da sessão no firewall, incluindo sessões

finalizadas onde houver de-criptografia de SSL e SSH;

4.1.7.17.10.26. Para IPv4, deve suportar roteamento estático e

dinâmico (RIPv2, BGP e OSPFv2);

4.1.7.17.10.27. Para IPv6, deve suportar roteamento estático e

dinâmico (OSPFv3);

4.1.7.17.10.28. Suportar a OSPF graceful restart;

4.1.7.17.10.29. Deve suportar o protocolo MP-BGP (Multiprotocol

BGP) permitindo que o firewall possa anunciar rotas

multicast para IPv4 e rotas unicast para IPv6;

4.1.7.17.10.30. Suportar no mínimo as seguintes funcionalidades em

IPv6: SLAAC (address auto configuration), NAT64,

Identificação de usuários a partir do LDAP/AD,

Captive Portal, IPv6 over IPv4 IPSec, Regras de

proteção contra DoS (Denial of Service), De-

criptografia SSL e SSH, PBF (Policy Based

Forwarding), QoS, DHCPv6 Relay, IPSEc, VPN SSL,

Ativo/Ativo, Ativo/Passivo, SNMP, NTP, SYSLOG,

DNS, Neighbor Discovery (ND), Recursive DNS

Server (RDNSS), DNS Search List (DNSSL) e controle

de aplicação;

4.1.7.17.10.31. Os dispositivos de proteção devem ter a capacidade de

operar de forma simultânea em uma única instância de

firewall, mediante o uso de suas interfaces físicas nos

seguintes modos: Modo sniffer (monitoramento e

análise do tráfego de rede), camada 2 (l2) e camada 3

(l3);

4.1.7.17.10.32. Modo Sniffer, para inspeção via porta espelhada do

tráfego de dados da rede;

4.1.7.17.10.33. Modo Camada – 2 (L2), para inspeção de dados em

linha e ter visibilidade e controle do tráfego em nível de

aplicação;

4.1.7.17.10.34. Modo Camada – 3 (L3), para inspeção de dados em

linha e ter visibilidade e controle do tráfego em nível de

aplicação operando como default gateway das redes

protegidas;

4.1.7.17.10.35. Modo misto de trabalho Sniffer, L2 e L3 em diferentes

interfaces físicas;

4.1.7.17.11. Suporte a configuração de alta disponibilidade Ativo/Passivo

e Ativo/Ativo:

4.1.7.17.11.1. Em modo transparente;

4.1.7.17.11.2. Em layer 3;




39

4.1.7.17.11.3. A configuração em alta disponibilidade deve

sincronizar:

4.1.7.17.11.4. Sessões;

4.1.7.17.11.5. Configurações, incluindo, mas não limitado a políticas

de Firewall, NAT, QOS e objetos de rede;

4.1.7.17.11.6. Certificados de-criptografados;

4.1.7.17.11.7. Associações de Segurança das VPNs;

4.1.7.17.11.8. Tabelas FIB;

4.1.7.17.11.9. HA (modo de Alta-Disponibilidade) deve possibilitar

monitoração de falha de link.

4.1.7.17.11.10. As funcionalidades de controle de aplicações, VPN

IPSec e SSL, QOS, SSL e SSH Decryption e protocolos

de roteamento dinâmico devem operar em caráter

permanente, podendo ser utilizadas por tempo

indeterminado, mesmo que não subsista o direito de

receber atualizações ou que não haja contrato de

garantia de software com o fabricante.

4.1.7.18. CONTROLE POR POLÍTICA DE FIREWALL

4.1.7.18.1. Deverá suportar controles por zona de segurança.

4.1.7.18.2. Controles de políticas por porta e protocolo.

4.1.7.18.3. Controle de políticas por aplicações grupos estáticos de

aplicações, grupos dinâmicos de aplicações (baseados em

características e comportamento das aplicações) e categorias

de aplicações.

4.1.7.18.4. Controle de políticas por usuários, grupos de usuários, IPs,

redes e zonas de segurança;

4.1.7.18.5. Deve suportar a consulta a fontes externas de endereços IP,

domínios e URLs podendo ser adicionados nas políticas de

firewall para bloqueio ou permissão do tráfego;

4.1.7.18.6. Deve permitir autenticação segura através de certificado nas

fontes externas de endereços IP, domínios e URLs;

4.1.7.18.7. Deve permitir consultar e criar exceção para objetos das listas

externas a partir da interface de gerência do próprio firewall;

4.1.7.18.8. Controle de políticas por código de País (Por exemplo: BR,

USA, UK, RUS).

4.1.7.18.9. Controle, inspeção e de-criptografia de SSL por política para

tráfego de entrada (Inbound) e Saída (Outbound).

4.1.7.18.10. Deve de-criptografar tráfego Inbound e Outbound em

conexões negociadas com TLS 1.2;




40

4.1.7.18.11. Deve de-criptografar sites e aplicações que utilizam

certificados ECC, incluindo Elliptical Curve Digital

Signature Algorithm (ECDSA);

4.1.7.18.12. Controle de inspeção e de-criptografia de SSH por política;

4.1.7.18.13. A de-criptografia de SSH deve possibilitar a identificação e

bloqueio de tráfego caso o protocolo esteja sendo usado para

tunelar aplicações como técnica evasiva para burlar os

controles de segurança;

4.1.7.18.14. Bloqueios dos seguintes tipos de arquivos: bat, cab, dll, exe,

pif, e reg

4.1.7.18.15. Traffic shaping QoS baseado em Políticas (Prioridade,

Garantia e Máximo)

4.1.7.18.16. QoS baseado em políticas para marcação de pacotes (diffserv

marking), inclusive por aplicações.

4.1.7.18.17. Suporte a objetos e regras IPV6.

4.1.7.18.18. Suporte a objetos e regras multicast.

4.1.7.18.19. Deve suportar no mínino três tipos de negação de tráfego nas

políticas de firewall: Drop sem notificação do bloqueio ao

usuário, Drop com opção de envio de ICMP Unreachable

para máquina de origem do tráfego, TCP-Reset para o client,

TCP-Reset para o server ou para os dois lados da conexão;

4.1.7.18.20. Suportar a atribuição de agendamento as políticas com o

objetivo de habilitar e desabilitar políticas em horários pré-

definidos automaticamente.

4.1.7.19. CONTROLE DE APLICAÇÕES DO FIREWALL

Os dispositivos de proteção de rede deverão possuir a capacidade de reconhecer

aplicações, independente de porta e protocolo, com as seguintes funcionalidades:

4.1.7.19.1. Deve ser possível a liberação e bloqueio somente de

aplicações sem a necessidade de liberação de portas e

protocolos.

4.1.7.19.2. Reconhecer pelo menos 1700 aplicações diferentes,

incluindo, mas não limitado: a tráfego relacionado a peer-to-

peer, redes sociais, acesso remoto, update de software,

protocolos de rede, voip, áudio, vídeo, proxy, mensageiros

instantâneos, compartilhamento de arquivos, e-mail;

4.1.7.19.3. Reconhecer pelo menos as seguintes aplicações: bittorrent,

gnutella, skype, facebook, linked-in, twitter, citrix, logmein,

teamviewer, ms-rdp, vnc, gmail, youtube, http-proxy, http-

tunnel, facebook chat, gmail chat, whatsapp, 4shared,

dropbox, google drive, skydrive, db2, mysql, oracle, active




41

directory, kerberos, ldap, radius, itunes, dhcp, ftp, dns, wins,

msrpc, ntp, snmp, rpc over http, gotomeeting, webex,

evernote, google-docs, etc;

4.1.7.19.4. Deve inspecionar o payload de pacote de dados com o

objetivo de detectar através de expressões regulares

assinaturas de aplicações conhecidas pelo fabricante

independente de porta e protocolo. A checagem de

assinaturas também deve determinar se uma aplicação está

utilizando a porta default ou não, incluindo, mas não limitado

a RDP na porta 80 ao invés de 389;

4.1.7.19.5. Deve aplicar heurística a fim de detectar aplicações através

de análise comportamental do tráfego observado, incluindo,

mas não limitado a Encrypted Bittorrent e aplicações VOIP

que utilizam criptografia proprietária;

4.1.7.19.6. Identificar o uso de táticas evasivas, ou seja, deve ter a

capacidade de visualizar e controlar as aplicações e os

ataques que utilizam táticas evasivas via comunicações

criptografadas, tais como Skype e ataques mediante a porta

443.

4.1.7.19.7. Para tráfego criptografado SSL, deve de-criptografar pacotes

a fim de possibilitar a leitura de payload para checagem de

assinaturas de aplicações conhecidas pelo fabricante;

4.1.7.19.8. Deve realizar decodificação de protocolos com o objetivo de

detectar aplicações encapsuladas dentro do protocolo e

validar se o tráfego corresponde com a especificação do

protocolo, incluindo, mas não limitado a Yahoo Instant

Messenger usando HTTP. A decodificação de protocolo

também deve identificar funcionalidades especificas dentro

de uma aplicação, incluindo, mas não limitado a

compartilhamento de arquivo dentro do Webex. Além de

detectar arquivos e outros conteúdos que devem ser

inspecionados de acordo as regras de segurança

implementadas;

4.1.7.19.9. Deve permitir a utilização de aplicativos para um

determinado grupo de usuário e bloquear para o restante,

incluindo, mas não limitado a Skype. Deve permitir também

a criação de políticas de exceção concedendo o acesso a

aplicativos como Skype apenas para alguns usuários;

4.1.7.19.10. Identificar o uso de táticas evasivas via comunicações

criptografadas;

4.1.7.19.11. Atualizar a base de assinaturas de aplicações

automaticamente;

4.1.7.19.12. Reconhecer aplicações em IPv6;




42

4.1.7.19.13. Limitar a banda (download/upload) usada por aplicações

(traffic shaping), baseado no IP de origem, usuários e grupos

do LDAP/AD;

4.1.7.19.14. Os dispositivos de proteção de rede devem possuir a

capacidade de identificar o usuário de rede com integração ao

Microsoft Active Directory, sem a necessidade de instalação

de agente no Domain Controller, nem nas estações dos

usuários;

4.1.7.19.15. Deve ser possível adicionar controle de aplicações em todas

as regras de segurança do dispositivo, ou seja, não se

limitando somente a possibilidade de habilitar controle de

aplicações em algumas regras;

4.1.7.19.16. Deve suportar múltiplos métodos de identificação e

classificação das aplicações, por pelo menos checagem de

assinaturas, decodificação de protocolos e análise heurística;

4.1.7.19.17. Para manter a segurança da rede eficiente, deve suportar o

controle sobre aplicações desconhecidas e não somente sobre

aplicações conhecidas;

4.1.7.19.18. Permitir nativamente a criação de assinaturas personalizadas

para reconhecimento de aplicações proprietárias na própria

interface gráfica da solução, sem a necessidade de ação do

fabricante, mantendo a confidencialidade das aplicações do

órgão;

4.1.7.19.19. A criação de assinaturas personalizadas deve permitir o uso

de expressões regulares, contexto (sessões ou transações),

usando posição no payload dos pacotes TCP e UDP e usando

decoders de pelo menos os seguintes protocolos:

4.1.7.19.20. HTTP, FTP, SMB, SMTP, Telnet, SSH, MS-SQL, IMAP,

IMAP, MS-RPC, RTSP e File body.

4.1.7.19.21. O fabricante deve permitir a solicitação de inclusão de

aplicações na base de assinaturas de aplicações;

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

4.1.7.19.23. Deve possibilitar que o controle de portas seja aplicado para

todas as aplicações;

4.1.7.19.24. Deve possibilitar a diferenciação de tráfegos Peer2Peer

(Bittorrent, emule, neonet, etc.) possuindo granularidade de

controle/politicas para os mesmos;

4.1.7.19.25. Deve possibilitar a diferenciação de tráfegos de Instant

Messaging (AIM, Gtalk, Facebook Chat, etc.) possuindo

granularidade de controle/politicas para os mesmos;

4.1.7.19.26. Deve possibilitar a diferenciação e controle de partes das

aplicações como por exemplo permitir o Gtalk chat e

bloquear a transferência de arquivos;




43

4.1.7.19.27. Deve possibilitar a diferenciação de aplicações Proxies

(ghostsurf, freegate, etc.) possuindo granularidade de

controle/politicas para os mesmos;

4.1.7.19.28. Deve ser possível a criação de grupos estáticos de aplicações

e grupos dinâmicos de aplicações baseados em características

das aplicações como:

4.1.7.19.29. Tecnologia utilizada na aplicações (Client-Server, Browse

Based, Network Protocol, etc).

4.1.7.19.30. Nível de risco da aplicação.

4.1.7.19.31. Categoria e sub-categoria de aplicações.

4.1.7.19.32. Aplicações que usem técnicas evasivas, utilizadas por

malwares, como transferência de arquivos e/ou uso excessivo

de banda, etc.

4.1.7.20. PREVENÇÃO DE AMEAÇAS DO FIREWALL

4.1.7.20.1. Para proteção do ambiente contra ataques, os dispositivos de

proteção devem possuir módulo de IPS, Antivírus e Anti-

Spyware integrados no próprio appliance de Firewall ou

entregue através de composição com outro equipamento ou

fabricante.

4.1.7.20.2. Deve incluir assinaturas de prevenção de intrusão (IPS) e

bloqueio de arquivos maliciosos (Antivírus e Anti-Spyware);

4.1.7.20.3. As funcionalidades de IPS, Antivírus e Anti-Spyware devem

operar em caráter permanente, podendo ser utilizadas por

tempo indeterminado, mesmo que não subsista o direito de

receber atualizações ou que não haja contrato de garantia de

software com o fabricante.

4.1.7.20.4. Deve sincronizar as assinaturas de IPS, Antivírus, Anti-

Spyware quando implementado em alta disponibilidade

ativo/ativo e ativo/passivo;

4.1.7.20.5. Deve implementar os seguintes tipos de ações para ameaças

detectadas pelo IPS, Antipyware e Antivirus: permitir,

permitir e gerar log, bloquear, bloquear IP do atacante por um

intervalo de tempo e enviar tcp-reset;

4.1.7.20.6. As assinaturas devem poder ser ativadas ou desativadas, ou

ainda habilitadas apenas em modo de monitoração;

4.1.7.20.7. Exceções por IP de origem ou de destino devem ser possíveis

nas regras, de forma geral e assinatura a assinatura;

4.1.7.20.8. Deve suportar granularidade nas politicas de IPS Antivírus e

Anti-Spyware , possibilitando a criação de diferentes

politicas por zona de segurança, endereço de origem,

endereço de destino, serviço e a combinação de todos esses

itens.




44

4.1.7.20.9. Deve permitir o bloqueio de vulnerabilidades.

4.1.7.20.10. Deve permitir o bloqueio de exploits conhecidos.

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

4.1.7.20.12. Deve suportar a inspeção e criação de regras de proteção de

DOS e QOS para o conteúdo de tráfego tunelado

pelo protocolo GRE;

4.1.7.20.13. Deverá possuir os seguintes mecanismos de inspeção de IPS:

4.1.7.20.13.1. Análise de padrões de estado de conexões;

4.1.7.20.13.2. Análise de decodificação de protocolo;

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

4.1.7.20.13.4. Análise heurística;

4.1.7.20.13.5. IP Defragmentation;

4.1.7.20.13.6. Remontagem de pacotes de TCP;

4.1.7.20.13.7. Bloqueio de pacotes malformados.

4.1.7.20.13.8. Ser imune e capaz de impedir ataques básicos como:

Synflood, ICMPflood, UDPfloof, etc;

4.1.7.20.13.9. Detectar e bloquear a origem de portscans com

possibilidade de criar exceções para endereços IPs de

ferramentas de monitoramento da organização;

4.1.7.20.13.10. Bloquear ataques efetuados por worms conhecidos,

permitindo ao administrador acrescentar novos padrões;

4.1.7.20.13.11. Suportar os seguintes mecanismos de inspeção contra

ameaças de rede: análise de padrões de estado de

conexões, análise de decodificação de protocolo,

análise para detecção de anomalias de protocolo,

análise heurística, IP Defragmentation, remontagem de

pacotes de TCP e bloqueio de pacotes malformados;

4.1.7.20.13.12. Possuir assinaturas específicas para a mitigação de

ataques DoS e DDoS;

4.1.7.20.13.13. Possuir assinaturas para bloqueio de ataques de buffer

overflow;

4.1.7.20.13.14. Deverá possibilitar a criação de assinaturas

customizadas pela interface gráfica do produto;

4.1.7.20.13.15. Deve permitir usar operadores de negação na criação de

assinaturas customizadas de IPS e anti-spyware,

permitindo a criação de exceções com granularidade

nas configurações;

4.1.7.20.13.16. Permitir o bloqueio de vírus e spywares em, pelo

menos, os seguintes protocolos: HTTP, FTP, SMB,

SMTP e POP3;




45

4.1.7.20.13.17. É permitido uso de appliance externo (antivírus de

rede), para o bloqueio de vírus e spywares em protocolo

SMB de forma a conter malwares se espalhando

horizontalmente pela rede;

4.1.7.20.13.18. Suportar bloqueio de arquivos por tipo;

4.1.7.20.13.19. Identificar e bloquear comunicação com botnets;

4.1.7.20.13.20. Deve suportar varias técnicas de prevenção, incluindo

Drop e tcp-rst (Cliente, Servidor e ambos);

4.1.7.20.13.21. Deve suportar referencia cruzada com CVE;

4.1.7.20.13.22. Registrar na console de monitoração as seguintes

informações sobre ameaças identificadas:

4.1.7.20.13.23. O nome da assinatura ou do ataque, aplicação, usuário,

origem e o destino da comunicação, além da ação

tomada pelo dispositivo;

4.1.7.20.13.24. Deve suportar a captura de pacotes (PCAP), por

assinatura de IPS e Antyspyware;

4.1.7.20.13.25. Deve permitir que na captura de pacotes por assinaturas

de IPS e Antispyware seja definido o número de

pacotes a serem capturados. Esta captura deve permitir

selecionar, no mínimo, 50 pacotes;

4.1.7.20.13.26. Deve possuir a função resolução de endereços via DNS,

para que conexões com destino a domínios maliciosos

sejam resolvidas pelo Firewall com endereços (IPv4 e

IPv6), previamente definidos;

4.1.7.20.13.27. Permitir o bloqueio de vírus, pelo menos, nos seguintes

protocolos: HTTP, FTP, SMB, SMTP e POP3;

4.1.7.20.13.28. Os eventos devem identificar o país de onde partiu a

ameaça;

4.1.7.20.13.29. Deve incluir proteção contra vírus em conteúdo HTML

e javascript, software espião (spyware) e worms.

4.1.7.20.13.30. Proteção contra downloads involuntários usando HTTP

de arquivos executáveis. maliciosos.

4.1.7.20.13.31. Rastreamento de vírus em PDF.

4.1.7.20.13.32. Deve permitir a inspeção em arquivos comprimidos que

utilizam o algoritmo deflate (zip, gzip, etc.)

4.1.7.20.13.33. Deve ser possível a configuração de diferentes políticas

de controle de ameaças e ataques baseado em politicas

do firewall considerando Usuários, Grupos de usuários,

origem, destino, zonas de segurança, etc, ou seja, cada

politica de firewall poderá ter uma configuração

diferentes de IPS, sendo essas politicas por Usuários,




46

Grupos de usuário, origem, destino, zonas de

segurança.

4.1.7.20.14. ANÁLISE DE MALWARES MODERNOS

4.1.7.20.14.1. Devido aos Malwares hoje em dia serem muito

dinâmicos e um antivírus comum reativo não ser capaz

de detectar os mesmos com a mesma velocidade que

suas variações são criadas, a solução ofertada dever

possuir funcionalidades para análise de Malwares não

conhecidos incluídas na própria ferramenta ou entregue

com composição com outro fabricante;

4.1.7.20.14.2. O dispositivo de proteção deve ser capaz de enviar

arquivos trafegados de forma automática para análise

"In Cloud" ou local, onde o arquivo será executado e

simulado em ambiente controlado;

4.1.7.20.14.3. Selecionar através de políticas granulares quais tipos de

arquivos sofrerão esta análise incluindo, mas não

limitado a: endereço IP de origem/destino,

usuário/grupo do AD/LDAP, aplicação, porta,

URL/categoria de URL de destino, tipo de arquivo e

todas estas opções simultaneamente;

4.1.7.20.14.4. Deve possuir a capacidade de diferenciar arquivos

analisados em pelo menos três categorias: malicioso,

não malicioso e arquivos não maliciosos, mas com

características indesejáveis como softwares que deixa o

sistema operacional lento, que alteram parâmetros do

sistema, etc.;

4.1.7.20.14.5. Suportar a análise com pelo menos 100 (cem) tipos de

comportamentos maliciosos para a análise da ameaça

não conhecida;

4.1.7.20.14.6. Suportar a análise de arquivos maliciosos em ambiente

controlado com, no mínimo, sistema operacional

Windows XP, Windows 7 (32 bits) e Windows 7 (64

bits);

4.1.7.20.14.7. Deve suportar a monitoração de arquivos trafegados na

internet (HTTPs, FTP, HTTP, SMTP) como também

arquivos trafegados internamente entre servidores de

arquivos usando SMB em todos os modos de

implementação: sniffer, transparente e L3;

4.1.7.20.14.8. A solução deve possuir a capacidade de analisar em

sand-box links (http e https) presentes no corpo de e-

mails trafegados em SMTP e POP3. Deve ser gerado

um relatório caso a abertura do link pela sand-box o

identifique como site hospedeiro de exploits;




47

4.1.7.20.14.9. A análise de links em sand-box deve deve ser capaz de

classificar sites falsos na categoria de phishing e

atualizar a base de filtro de URL da solução;

4.1.7.20.14.10. Para ameaças trafegadas em protocolo SMTP e POP3, a

solução deve ter a capacidade de mostrar nos relatórios

o remetente, destinatário e assunto dos e-mails

permitindo identificação ágil do usuário vítima do

ataque;

4.1.7.20.14.11. O sistema de análise “In Cloud” ou local deve prover

informações sobre as ações do Malware na máquina

infectada, informações sobre quais aplicações são

utilizadas para causar/propagar a infecção, detectar

aplicações não confiáveis utilizadas pelo Malware,

gerar assinaturas de Antivírus e Anti-spyware

automaticamente, definir URLs não confiáveis

utilizadas pelo novo Malware e prover informações

sobre o usuário infectado (seu endereço ip e seu login

de rede);

4.1.7.20.14.12. O sistema automático de analise "In Cloud" ou local

deve emitir relatório com identificação de quais

soluções de antivírus existentes no mercado possuem

assinaturas para bloquear o malware;

4.1.7.20.14.13. Deve permitir exportar o resultado das análises de

malwares de dia Zero em PDF e CSV a partir da

própria interface de gerência;

4.1.7.20.14.14. Deve permitir o download dos malwares identificados a

partir da própria interface de gerência;

4.1.7.20.14.15. Deve permitir visualizar o resultados das análises de

malwares de dia zero nos diferentes sistemas

operacionais suportados;

4.1.7.20.14.16. Deve permitir informar ao fabricante quanto a suspeita

de ocorrências de falso-positivo e falso-negativo na

análise de malwares de dia Zero a partir da própria

interface de gerência.

4.1.7.20.14.17. Caso a solução seja fornecida em appliance local, deve

possuir, no mínimo, 28 ambientes controlados (sand-

box) independentes para execução simultânea de

arquivos suspeitos;

4.1.7.20.14.18. Caso seja necessário licenças de sistemas operacional e

softwares para execução de arquivos no ambiente

controlado (sand-box), as mesmas devem ser fornecidas

em sua totalidade, sem custos adicionais para a

contratante;

4.1.7.20.14.19. Suportar a análise de arquivos executáveis, DLLs, ZIP

e criptografados em SSL no ambiente controlado;




48

4.1.7.20.14.20. Suportar a análise de arquivos do pacote office (.doc,

.docx, .xls, .xlsx, .ppt, .pptx), arquivos java (.jar e

class), Android APKs MacOS (mach-O, DMG e PKG)

no ambiente de sandbox;

4.1.7.20.14.21. Deve atualizar a base com assinaturas para bloqueio

dos malwares identificados em sand-box com

frequência de, pelo menos, 5 minutos:

4.1.7.20.14.22. Permitir o envio de arquivos e links para análise no

ambiente controlado via de forma automática via API.

4.1.7.20.14.23. Deve permitir o envio para análise em sand-box de

malwares bloqueados pelo antivírus da solução;

4.1.7.20.15. FILTRO DE URL

4.1.7.20.15.1. A plataforma de segurança deve possuir as seguintes

funcionalidades de filtro de URL:

4.1.7.20.15.2. Permite especificar política por tempo, ou seja, a

definição de regras para um determinado horário ou

período (dia, mês, ano, dia da semana e hora);

4.1.7.20.15.3. Deve ser possível a criação de politicas por Usuários,

Grupos de Usuários, Ips, Redes e Zonas de segurança:

4.1.7.20.15.4. Deverá incluir a capacidade de criação de políticas

baseadas na visibilidade e controle de quem está

utilizando quais URLs através da integração com

serviços de diretório, autenticação via ldap, Active

Directory, E-directory e base de dados local.

4.1.7.20.15.5. Permite popular todos os logs de URL com as

informações dos usuários conforme descrito na

integração com serviços de diretório;

4.1.7.20.15.6. Suporta a capacidade de criação de políticas baseadas

no controle por URL e Categoria de URL;

4.1.7.20.15.7. Deve bloquear o acesso a sites de busca (Google, Bing

e Yahoo), caso a opção Safe Search esteja desabilitada.

Deve ainda exibir página de bloqueio fornecendo

instruções ao usuário de como habilitar a função;

4.1.7.20.15.8. Suporta base ou cache de URLs local no appliance,

evitando delay de comunicação/validação das URLs;

4.1.7.20.15.9. Possui pelo menos 60 categorias de URLs;

4.1.7.20.15.10. A categorização de URL deve analisar toda a URL e

não somente até o nível de diretório;

4.1.7.20.15.11. Suporta a criação categorias de URLs customizadas;

4.1.7.20.15.12. Suporta a exclusão de URLs do bloqueio, por categoria;




49

4.1.7.20.15.13. Permite a customização de página de bloqueio;

4.1.7.20.15.14. Deve proteger contra o roubo de credenciais, usuários e

senhas identificadas através da integração com Active

Directory submetidos em sites não corporativos. Deve

ainda permitir criação de regra onde usuários do Active

Directory só possam enviar informações de login para

sites autorizados na solução;

4.1.7.20.15.15. Deve permitir bloquear o acesso do usuário caso o

mesmo tente fazer o envio de suas credencias em sites

classificados como phishing pelo filtro de URL

da solução;

4.1.7.20.15.16. Permite o bloqueio e continuação (possibilitando que o

usuário acesse um site potencialmente bloqueado

informando o mesmo na tela de bloqueio e

possibilitando a utilização de um botão "Continuar"

para permitir o usuário continuar acessando o site);

4.1.7.20.15.17. Suporta a inclusão nos logs do produto de informações

das atividades dos usuários;

4.1.7.20.15.18. Deve salvar nos logs as informações dos seguintes

campos do cabeçalho HTTP nos acessos a URLs:

UserAgent, Referer, e X-Forwarded For;

4.1.7.20.16. IDENTIFICAÇÃO DE USUÁRIOS

4.1.7.20.16.1. Deve incluir a capacidade de criação de políticas

baseadas na visibilidade e controle de quem está

utilizando quais aplicações através da integração com

serviços de diretório, autenticação via ldap, Active

Directory, E-directory e base de dados local;

4.1.7.20.16.2. Deve possuir integração com Microsoft Active

Directory para identificação de usuários e grupos

permitindo granularidade de controle/politicas baseadas

em usuários e grupos de usuários;

4.1.7.20.16.3. Deve possuir integração com Radius para identificação

de usuários e grupos permitindo granularidade de

controle/politicas baseadas em usuários e grupos de

usuários;

4.1.7.20.16.4. Deve implementar a criação de políticas de segurança

baseada em atributos específicos do Radius, incluindo

mas não limitado a: baseado no sistema operacional do

usuário remoto exigir autenticação padrão Windows e

on-time password (OTP) para usuários Android;

4.1.7.20.16.5. Deve possuir integração com Ldap para identificação

de usuários e grupos permitindo granularidade de




50

controle/politicas baseadas em Usuários e Grupos de

usuários;

4.1.7.20.16.6. Deve suportar o recebimento eventos de autenticação

de controladoras wireless, dispositivos 802.1x e

soluções NAC via syslog, para a identificação de

endereços IP e usuários;

4.1.7.20.16.7. Deve permitir o controle, sem instalação de cliente de

software, em equipamentos que solicitem saída a

internet para que antes de iniciar a navegação, expanda-

se um portal de autenticação residente no firewall

(Captive Portal);

4.1.7.20.16.8. Suporte a autenticação Kerberos;

4.1.7.20.16.9. Deve suportar autenticação via Kerberos para

administradores da plataforma de segurança, captive

Portal e usuário de VPN SSL;

4.1.7.20.16.10. Deve possuir suporte a identificação de múltiplos

usuários conectados em um mesmo endereço IP em

ambientes Citrix e Microsoft Terminal Server,

permitindo visibilidade e controle granular por usuário

sobre o uso das aplicações que estão nestes serviços;

4.1.7.20.16.11. Deve identificar usuários através de leitura do campo x-

fowarded-for, populando nos logs do firewall o

endereço IP, bem como o usuário de rede responsável

pelo acesso;

4.1.7.20.16.12. Deve permitir a criação de políticas de segurança

baseadas em usuários de rede com reconhecimento dos

mesmos através de leitura do campo x-fowarded-for;

4.1.7.20.16.13. Deve implementar a criação de grupos customizados de

usuários no firewall, baseado em atributos do

LDAP/AD;

4.1.7.20.16.14. Deve possuir suporte a identificação de múltiplos

usuários conectados em um mesmo endereço IP em

servidores acessados remotamente, mesmo que não

sejam servidores Windows.

4.1.7.20.17. QOS

4.1.7.20.17.1. Com a finalidade de controlar aplicações e tráfego cujo

consumo possa ser excessivo, (como youtube, ustream,

etc) e ter um alto consumo de largura de banda, se

requer que a solução, além de poder permitir ou negar

esse tipo de aplicações, deve ter a capacidade de

controlá-las por políticas de máximo de largura de

banda quando forem solicitadas por diferentes usuários

ou aplicações, tanto de áudio como de vídeo streaming.

4.1.7.20.17.2. Suportar a criação de políticas de QoS por:




51

4.1.7.20.17.3. Endereço de origem

4.1.7.20.17.4. Endereço de destino

4.1.7.20.17.5. Por usuário e grupo do LDAP/AD.

4.1.7.20.17.6. Por aplicações, incluindo, mas não limitado a Skype,

Bittorrent, YouTube e Azureus;

4.1.7.20.17.7. Por porta;

4.1.7.20.17.8. O QoS deve possibilitar a definição de classes por:

4.1.7.20.17.9. Banda Garantida

4.1.7.20.17.10. Banda Máxima

4.1.7.20.17.11. Fila de Prioridade.

4.1.7.20.17.12. Suportar priorização RealTime de protocolos de voz

(VOIP) como H.323, SIP, SCCP, MGCP e aplicações

como Skype.

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

aplicação;

4.1.7.20.17.14. Deve implemetar QOS (traffic-shapping), para pacotes

marcados por outros ativos na rede (DSCP). A

priorização e limitação do tráfego deve ser efetuada nos

dois sentidos da conexão (inboud e outbound);

4.1.7.20.17.15. Disponibilizar estatísticas RealTime para classes de

QoS.

4.1.7.20.17.16. Deverá permitir o monitoramento do uso que as

aplicações fazem por bytes, sessões e por usuário.

4.1.7.20.18. FILTRO DE DADOS

4.1.7.20.18.1. Permite a criação de filtros para arquivos e dados pré-

definidos;

4.1.7.20.18.2. Os arquivos devem ser identificados por extensão e

assinaturas;

4.1.7.20.18.3. Permite identificar e opcionalmente prevenir a

transferência de vários tipos de arquivos (MS Office,

PDF, etc) identificados sobre aplicações (P2P,

InstantMessaging, SMB, etc);

4.1.7.20.18.4. Suportar identificação de arquivos compactados e a

aplicação de politicas sobre o conteúdo desses tipos de

arquivos;

4.1.7.20.18.5. Permitir identificar e opcionalmente prevenir a

transferência de informações sensíveis, incluindo, mas

não limitado a número de cartão de crédito,

possibilitando a criação de novos tipos de dados via

expressão regular;




52

4.1.7.20.18.6. Permitir listar o número de aplicações suportadas para

controle de dados;

4.1.7.20.18.7. Permitir listar o número de tipos de arquivos

suportados para controle de dados;

4.1.7.20.19. GEO-LOCALIZAÇÃO

4.1.7.20.19.1. Suportar a criação de politicas por Geo Localização,

permitindo o trafego de determinado Pais/Países sejam

bloqueados.

4.1.7.20.19.2. Deve possibilitar a visualização dos países de origem e

destino nos logs dos acessos.

4.1.7.20.19.3. Deve possibilitar a criação de regiões geográficas pela

interface gráfica e criar politicas utilizando as mesmas.

4.1.7.20.20. VPN

4.1.7.20.20.1. Suportar VPN Site-to-Site e Cliente-To-Site;

4.1.7.20.20.2. Suportar IPSec VPN;

4.1.7.20.20.3. Suportar SSL VPN;

4.1.7.20.20.4. A VPN IPSEc deve suportar:

4.1.7.20.20.5. DES e 3DES;

4.1.7.20.20.6. Autenticação MD5 e SHA-1;

4.1.7.20.20.7. Diffie-Hellman Group 1 , Group 2, Group 5 e Group

14;

4.1.7.20.20.8. Algoritmo Internet Key Exchange (IKEv1 e v2);

4.1.7.20.20.9. AES 128, 192 e 256 (Advanced Encryption Standard)

4.1.7.20.20.10. Autenticação via certificado IKE PKI.

4.1.7.20.20.11. Deve possuir interoperabilidade com os seguintes

fabricantes:

• Cisco;

• Checkpoint;

• Juniper;

• Palo Alto Networks;

• Fortinet;

• Sonic Wall;

4.1.7.20.20.12. Deve permitir habilitar, desabilitar, reiniciar e

atualizar IKE gateways e túneis de VPN IPSEc a

partir da interface gráfica da solução, facilitando o

processo de throubleshooting;




53

4.1.7.20.20.13. A VPN SSL deve suportar:

• O usuário realizar a conexão por meio de cliente

instalado no sistema operacional do equipamento ou

por meio de interface WEB;

• A funcionalidades de VPN SSL devem ser atendidas

com ou sem o uso de agente;

• Atribuição de endereço IP nos clientes remotos de

VPN SSL;

4.1.7.20.20.14. Deve permitir a atribuição de IPs fixos nos usuários

remotos de VPN SSL;

4.1.7.20.20.15. Deve permitir a criação de rotas de acesso e faixas de

endereços IP atribuídas a clientes remotos de VPN de

forma customizada por usuário AD/LDAP e grupo de

usuário AD/LDAP;

4.1.7.20.20.16. Deve permitir que todo o tráfego dos usuários remotos

de VPN seja escoado para dentro do túnel de VPN,

impedindo comunicação direta com dispositivos

locais como proxies;

4.1.7.20.20.17. Atribuição de DNS nos clientes remotos de VPN;

4.1.7.20.20.18. Deve permitir que seja definido métodos de

autenticação distintos por sistema operacional do

dispositivo remoto de VPN (Android, IOS, Mac,

Windows e Chrome OS);

4.1.7.20.20.19. A solução de VPN deve verificar se o client que está

conectando é o mesmo para o qual o certificado foi

emitido inicialmente. O acesso deve ser bloqueado

caso o dispositivo não seja o correto;

4.1.7.20.20.20. Deve possuir lista de bloqueio para dispositivos que

forem reportados com roubado ou perdido pelo

usuário;

4.1.7.20.20.21. Deve haver a opção de ocultar o agente de VPN

instalado no cliente remoto, tornando o mesmo

invisível para o usuário;

4.1.7.20.20.22. Deve exibir mensagens de notificação customizada

toda vez que um usuário remoto se conectar a VPN.

Deve permitir que o usuário desabilite a exibição da

mensagem nas conexões seguintes;

4.1.7.20.20.23. Deve avisar ao usuário remoto de VPN quanto a

proximidade da expiração de senha LDAP. Deve

permitir também a customização da mensagem com

informações relevantes para o usuário;

4.1.7.20.20.24. Dever permitir criar políticas de controle de

aplicações, IPS, Antivírus, Antipyware e filtro de




54

URL para tráfego dos clientes remotos conectados na

VPN SSL;

4.1.7.20.20.25. A VPN SSL deve suportar proxy arp e uso de

interfaces PPPOE;

4.1.7.20.20.26. Suportar autenticação via AD/LDAP, OTP (One Time

Password), certificado e base de usuários local;

4.1.7.20.20.27. Deve permitir a distribuição de certificado para o

usuário de remoto através do portal de VPN de forma

automatizada;

4.1.7.20.20.28. Deve possuir lista de bloqueio para dispositivos em

casos quando, por exemplo, o usuário reportar que o

dispositivo foi perdido ou roubado;

4.1.7.20.20.29. Permite estabelecer um túnel VPN client-to-site do

cliente a plataforma de segurança, fornecendo uma

solução de single-sign-on aos usuários, integrando-se

com as ferramentas de Windows-logon;

4.1.7.20.20.30. Suporta leitura e verificação de CRL (certificate

revocation list);

4.1.7.20.20.31. Permite a aplicação de políticas de segurança e

visibilidade para as aplicações que circulam dentro

dos túneis SSL;

4.1.7.20.20.32. O agente de VPN a ser instalado nos equipamentos

desktop e laptops, dever ser capaz de ser distribuído

de maneira automática via Microsoft SMS, Active

Directory e ser descarregado diretamente desde o seu

próprio portal, o qual residirá no centralizador de

VPN;

4.1.7.20.20.33. O agente deverá comunicar-se com o portal para

determinar as políticas de segurança do usuário;

4.1.7.20.20.34. Deve permitir que a conexão com a VPN SSL seja

estabelecida das seguintes formas:

• Antes do usuário autenticar na estação;

• Após autenticação do usuário na estação;

• Sob demanda do usuário;

4.1.7.20.20.35. Deverá Manter uma conexão segura com o portal

durante a sessão.

4.1.7.20.20.36. O agente de VPN SSL client-to-site deve ser

compatível com pelo menos: Windows XP, Vista

Windows 7, Windows 8, Mac OSx e Chrome OS;

4.1.7.20.20.37. O portal de VPN deve enviar ao cliente remoto, a lista

de gateways de VPN ativos para estabelecimento da




55

conexão, os quais devem poder ser administrados

centralmente;

4.1.7.20.20.38. Deve haver a opção do cliente remoto escolher

manualmente o gateway de VPN e de forma

automática através da melhor rota entre os gateways

disponíveis com base no tempo de resposta mais

rápido;

4.1.7.20.20.39. Deve possuir a capacidade de identificar se a origem

da conexão de VPN é externa ou interna;

4.1.7.20.21. CONSOLE DE GERÊNCIA E MONITORAÇÃO

4.1.7.20.21.1. Centralizar a administração de regras e políticas do

cluster, usando uma única interface de gerenciamento;

4.1.7.20.21.2. O gerenciamento da solução deve suportar acesso via

SSH, cliente ou WEB (HTTPS) e API aberta;

4.1.7.20.21.3. Deve permitir substituir o certificado de fábrica

no acesso HTTPS a gerência do firewall

como possibilidade de uso de certificado criado

localmente na própria solução ou importado de fonte

externa;

4.1.7.20.21.4. Caso haja a necessidade de instalação de cliente para

administração da solução o mesmo deve ser

compatível com sistemas operacionais Windows e

Linux;

4.1.7.20.21.5. O gerenciamento deve permitir/possuir:

• Criação e administração de políticas de firewall e

controle de aplicação;

• Criação e administração de políticas de IPS, Antivírus

e Anti-Spyware;

• Criação e administração de políticas de Filtro de

URL;

• Monitoração de logs;

• Ferramentas de investigação de logs;

• Debugging;

• Captura de pacotes.

• Acesso concorrente de administradores;

4.1.7.20.21.6. Deve permitir que administradores concorrentes

façam modificações, valide configurações e reverta

configurações do firewall simultaneamente e que cada

administrador consiga aplicar apenas as suas




56

alterações de forma independente das realizadas por

outro administrador;

4.1.7.20.21.7. Deve mostrar ao administrador do firewall a hora e

data do último login e tentativas de login com falha

para acessos a partir da interface gráfica e CLI.

4.1.7.20.21.8. Deve possuir mecanismo busca global na solução

onde possa se consultar por uma string tais como:

nome de objetos, ID ou nome de ameaças, nome de

aplicações, nome de políticas, endereços IPs,

permitindo a localização e uso dos mesmo na

configuração do dispositivo;

4.1.7.20.21.9. Deve possuir um mecanismo de busca por comandos

no gerenciamento via SSH, facilitando a localização

de comandos;

4.1.7.20.21.10. Deve permitir usar palavras chaves e cores para

facilitar identificação de regras;

4.1.7.20.21.11. Deve permitir monitorar via SNMP falhas de

hardware, inserção ou remoção de fontes, discos e

coolers, uso de recursos por número elevado de

sessões, número de túneis estabelecidos na VPN

cliente-to-site, porcentagem de utilização em

referência ao número total suportado/licenciado e

número de sessões estabelecidas, estatísticas/taxa de

logs, uso de disco, período de retenção dos logs e

status do envio de logs para soluções externas;

4.1.7.20.21.12. Deve suportar também o monitoramento dos seguintes

recursos via SNMP: IP fragmentation, TCP state e

dropped packets;

4.1.7.20.21.13. Bloqueio de alterações, no caso acesso simultâneo de

dois ou mais administradores;

4.1.7.20.21.14. Definição de perfis de acesso à console com

permissões granulares como: acesso de escrita, acesso

de leitura, criação de usuários, alteração de

configurações;

4.1.7.20.21.15. Autenticação integrada ao Microsoft Active Directory

e servidor Radius;

4.1.7.20.21.16. Localização de em quais regras um endereço IP, IP

Range, subnet ou objetos estão sendo utilizados;

4.1.7.20.21.17. Deve atribuir sequencialmente um número a cada

regra de firewall, NAT, QOS e regras de DOS;

4.1.7.20.21.18. Criação de regras que fiquem ativas em horário

definido;

4.1.7.20.21.19. Criação de regras com data de expiração;




57

4.1.7.20.21.20. Backup das configurações e rollback de configuração

para a última configuração salva;

4.1.7.20.21.21. Suportar Rollback de Sistema Operacional para a

ultima versão local;

4.1.7.20.21.22. Habilidade de upgrade via SCP, TFTP e interface de

gerenciamento;

4.1.7.20.21.23. Deve possuir mecanismo de análise de impacto na

política de segurança antes de atualizar a base com

novas aplicações disponibilizadas pelo fabricante;

4.1.7.20.21.24. Validação de regras antes da aplicação;

4.1.7.20.21.25. Deve implementar mecanismo de validação de

configurações antes da aplicação das mesmas

permitindo identificar erros, tais como: rota de destino

inválida, regras em shadowing etc;

4.1.7.20.21.26. É permitido o uso de appliance externo para permitir a

validação de regras antes da aplicação;

4.1.7.20.21.27. Validação das políticas, avisando quando houver

regras que, ofusquem ou conflitem com outras

(shadowing);

4.1.7.20.21.28. É permitido o uso de appliance externo para permitir a

validação de políticas, avisando quando houver regras

que, ofusquem ou conflitem com outras (shadowing);

4.1.7.20.21.29. Deve possibilitar a visualização e comparação de

configurações Atuais, configuração anterior e

configurações antigas;

4.1.7.20.21.30. Deve possibilitar a integração com outras soluções de

SIEM de mercado (third-party SIEM vendors);

4.1.7.20.21.31. Geração de logs de auditoria detalhados, informando a

configuração realizada, o administrador que a realizou

e o horário da alteração;

4.1.7.20.21.32. Deverá ter a capacidade de gerar um relatório gráfico

que permita visualizar as mudanças na utilização de

aplicações na rede no que se refere a um período de

tempo anterior, para permitir comparar os diferentes

consumos realizados pelas aplicações no tempo

presente com relação ao passado;

4.1.7.20.21.33. Geração de relatórios com mapas geográficos gerados

em tempo real para a visualização de origens e

destinos do tráfego gerado na instituição;

4.1.7.20.21.34. Deve prover relatórios com visão correlacionada de

aplicações, ameaças (IPS, Antivírus e Anti-Spware),

URLs e filtro de arquivos, para melhor diagnóstico e

resposta a incidentes;




58

4.1.7.20.21.35. Deve permitir a criação de Dash-Boards customizados

para visibilidades do tráfego de aplicativos, usuários,

categorias de URL, ameaças identificadas pelo IPS,

antivírus, anti-spyware, malwares "Zero

Day"detectados em sand-box e tráfego bloqueado;

4.1.7.20.21.36. O gerenciamento da solução deve possibilitar a coleta

de estatísticas de todo o tráfego que passar pelos

dispositivos de segurança;

4.1.7.20.21.37. Dever permitir a visualização dos logs de malwares

modernos, tráfego (IP de origem, destino, usuário e

porta), aplicação, IPS, antivírus, anti-spyware, Filtro

de URL e filtro de arquivos em uma única tela;

4.1.7.20.21.38. Deve possuir relatórios de utilização dos recursos por

aplicações, URL, ameaças (IPS, Antivírus e Anti-

Spware), etc;

4.1.7.20.21.39. Prover uma visualização sumarizada de todas as

aplicações, ameaças (IPS, Antivírus e Anti-Spware),

e URLs que passaram pela solução;

4.1.7.20.21.40. Deve possuir mecanismo "Drill-Down" para

navegação nos relatórios em RealTime;

4.1.7.20.21.41. Nas opções de "Drill-Down", ser possível identificar o

usuário que fez determinado acesso;

4.1.7.20.21.42. Deve possuir relatório de visibilidade e uso sobre

aplicativos (SaaS). O relatório também deve mostrar

os riscos para a segurança do ambiente, tais como a

entrega de malwares através de aplicativos SaaS com

a informação do usuário responsável pelo acesso;

4.1.7.20.21.43. Os relatórios de visibilidade e uso sobre aplicativos

(SaaS) devem poder ser extraídos por grupo de

usuários apresentando o uso e consumo de aplicações

por grupo de usuário;

4.1.7.20.21.44. Deve ser possível exportar os logs em CSV;

4.1.7.20.21.45. Deverá ser possível acessar o equipamento a aplicar

configurações durante momentos onde o trafego é

muito alto e a CPU e memória do equipamento estiver

totalmente utilizada;

4.1.7.20.21.46. Rotação do log;

4.1.7.20.21.47. Deve permitir que os logs e relatórios sejam

rotacionados automaticamente baseado no tempo em

que estão armazenados na solução, assim como no

espaço em disco usado;

4.1.7.20.21.48. Deve permitir fazer o envio de logs para soluções

externas de forma granular podendo selecionar quais




59

campos dos logs serão enviados incluindo, mas não

limitado a: tipo de ameaça, usuário, aplicação, etc;

4.1.7.20.21.49. Exibição das seguintes informações, de forma

histórica e em tempo real (atualizado de forma

automática e contínua a cada 1 minuto):

• Situação do dispositivo e do cluster;

• Principais aplicações;

• Principais aplicações por risco;

• Administradores autenticados na gerência da

plataforma de segurança;

• Número de sessões simultâneas;

• Status das interfaces;

• Uso de CPU;

4.1.7.20.21.50. Geração de relatórios. No mínimo os seguintes

relatórios devem ser gerados:

• Resumo gráfico de aplicações utilizadas;

• Principais aplicações por utilização de largura de

banda de entrada e saída;

• Principais aplicações por taxa de transferência de

bytes;

• Principais hosts por número de ameaças identificadas;

4.1.7.20.21.51. Atividades de um usuário específico e grupo de

usuários do AD/LDAP, incluindo aplicações

acessadas, categorias de URL, URL/tempo de

utilização e ameaças (IPS, Antivírus e Anti-Spware),

de rede vinculadas a este tráfego;

4.1.7.20.21.52. Deve permitir a criação de relatórios personalizados;

4.1.7.20.21.53. Em cada critério de pesquisa do log deve ser possível

incluir múltiplas entradas (ex. 10 redes e IP’s

distintos; serviços HTTP, HTTPS e SMTP), exceto no

campo horário, onde deve ser possível definir um

faixa de tempo como critério de pesquisa;

4.1.7.20.21.54. Gerar alertas automáticos via:

• Email;

• SNMP;

• Syslog;

4.1.7.20.21.55. A plataforma de segurança deve permitir através de

API-XML (Application Program Interface) a

integração com sistemas existentes no ambiente da




60

contratante de forma a possibilitar que aplicações

desenvolvidas na contratante possam interagir em

RealTime com a solução possibilitando assim que

regras e políticas de segurança de possam ser

modificadas por estas aplicações com a utilização de

scripts em linguagens de programação como Perl ou

PHP.

4.1.7.21. Transferência de conhecimento

4.1.7.21.1. A CONTRATADA deverá fazer a transferência de

conhecimento relativo à instalação, gerenciamento,

operacionalização, manuseio, configuração e utilização dos

equipamentos fornecidos e seus componentes;

4.1.7.21.2. CONTRATADA deverá fornecer ambiente para realização da

transferência de conhecimento, com infraestrutura adequada

para ministração e material didático oficial do fabricante.

Poderão ser utilizados os equipamentos a serem fornecidos (se

necessário);

4.1.7.21.3. A transferência de conhecimento deverá abordar, no mínimo,

os seguintes temas:

• Instalação física, gerenciamento e monitoração;

• Utilização do software ou interface de gerenciamento;

• Verificação e isolamento de erros;

• Reconfiguração do sistema;

• Procedimento de recuperação em caso de falha de

componentes;

• Atualização dos componentes de software e de firmware do

sistema;

• Configuração para uso de luns nos sistemas operacionais

Linux e Windows;

• Configuração de alta disponibilidade;

• Configuração de réplicas;

• Configuração para operações de desastre e recuperação.




61

4.1.8. Serviço de atendimento ao cliente:

É premissa para o atendimento satisfatório aos usuários a constituição de um

espaço físico em que haja relacionamento presencial com o público. Este ambiente

deverá ser colocado à disposição pela contratada, denominando-o Serviço de

Atendimento ao Cliente, em local a ser definido pela Trensurb, ficando a cargo da

contratada o dimensionamento da equipe para atendimento das atividades operadas,

obrigatoriamente, por pessoal vinculado à ela, mas amplamente supervisionado pela

Trensurb, assim como, a elaboração do layout, mobiliário e equipamentos, desde que,

cumpra plenamente com a finalidade de acolher os anseios do usuário inerentes ao:

4.1.8.1. Cadastramento e a confecção de crachás de isenções, vale transporte,

permissionários, Funcional e Cartão PA-SIM identificado;

4.1.8.2. Distribuição dos crachás confeccionados nas estações;

4.1.8.3. Distribuição de material publicitário;

4.1.8.4. Orientação ao usuário, resposta de cartas reclamações/sugestões;

4.1.8.5. Emissão de documento para pagamento de vale transporte;

4.1.8.6. Efetuar, auxiliar e/ou disponibilizar equipamentos para o cadastramento

de empresas que queiram adquirir o Vale Transporte;

4.1.8.7. Para atender de forma eficiente e pôr em prática essas funcionalidades,

a contratada deverá instalar e disponibilizar todos os equipamentos e

mobiliários necessários;

4.1.8.8. A Trensurb disponibilizará o espaço físico, a rede lógica e a alimentação

elétrica;

4.1.8.9. O horário de atendimento deverá ser das 10h às 20h, de 2ª a 6ª-Feira,

podendo sofrer alterações a critério da Trensurb;

4.1.8.10. O dimensionamento da equipe para atendimento das atividades da

central será de responsabilidade da contratada.

4.1.9. Manutenção:

Todos os equipamentos necessários para o funcionamento do sistema deverão

ser fornecidos pela contratada, de modo que a Trensurb se habilite a direcionar o

predomínio de sua capacidade de trabalho em prol dos interesses do usuário, delegando

a maior parte da responsabilidade de manutenção à contratada, assim como a assistência

e o suporte técnico.

4.1.9.1. Excetuam-se, quanto à obrigatoriedade de fornecimento de

equipamentos, os bloqueios e a rede lógica, que serão fornecidos pela

Trensurb;




62

4.1.9.2. Em relação aos bloqueios, a responsabilidade de manutenção da

Trensurb refere-se à parte mecânica, chassis, conjunto tripé, fonte,

interface de comunicação e pictogramas;

4.1.9.3. Em relação aos equipamentos, cuja instalação nos bloqueios seja

essencial, como por exemplo: validadores, CPU’s e outros dos quais o

funcionamento seja intrínseco ao bom desempenho da operacionalidade,

são de exclusiva responsabilidade da contratada;

4.1.9.4. É fundamental a solicitação à Gerência de Informática, GEINF, por parte

da contratada quando a ação versar sobre a necessidade de conexão à

rede lógica, criação de VLAN’s e integração de domínios;

4.1.9.5. Fica como encargo da Trensurb, a correção de eventuais falhas na

alimentação da energia.

4.1.10 Níveis de atendimento e procedimentos de manutenção:

4.1.10.1 Bloqueios:

4.1.10.1.1. Quando as falhas consistirem em irregularidades relacionadas aos

bloqueios, o atendimento imediato ficará a cargo do Setor de

Sinalização – SESIN. Se a falha advier dos equipamentos

embarcados nos bloqueios pela Contratada, para antecipar-se a uma

eventual situação degradada, a contratada comprometer-se-á em

manter um estoque mínimo de peças para reposição, em posse da

área implicada com a manutenção;

4.1.10.1.2. Após a eventual troca desses equipamentos, os mesmos deverão ser

recolhidos pela contratada, que terá a incumbência de repor o

estoque. Essa reposição deverá ser feita em um prazo máximo de 24

horas;

4.1.10.1.3. Caso a falha não se limite apenas à substituição de equipamento e

haja um contratempo que complique a remediação da mesma, a

contratada avocará para si a responsabilidade da solução do

problema, cujo prazo máximo será de 4 horas.

4.1.10.2 POS:

4.1.10.2.1. Toda falha relacionada ao POS será de inteira responsabilidade da

contratada, devendo a mesma atendê-la com presteza e solucioná-la

com celeridade, levando um período máximo de duas horas para

deixá-lo em conformidade para a realização de sua finalidade, pois,

por mais exíguo que seja o tempo de reparo, a inoperabilidade

momentânea do sistema gera evasão de receita para a Trensurb.

Considerando, então, essa característica que se apresenta como um

recorrente empecilho, o Sistema de vendas (POS) deverá permitir o




63

fechamento da sessão de vendas em que ocorreu a referida falha,

habilitando o agente de estação responsável pela bilheteria para esta

ação, através do terminal do POS na bilheteria justaposta ou fazê-lo

de forma remota. Tais procedimentos não devem superar 10

minutos.

4.1.10.2.2. O procedimento de fechamento forçado de caixa por motivos de

falha não deve causar qualquer transtorno quando da formalização

do encerramento, devendo este expediente constar no registro

documental;

4.1.10.2.3. Quando houver pane generalizada envolvendo rede lógica, servidor

ou sistema elétrico, o Sistema de vendas (POS) deverá habilitar ao

operador o recurso da venda off-line do cartão unitário, bem como

fomentar outras formas de procedimentos de vendas que atentem

para situações de emergência operacional, de forma que o controle

de gestão de venda não seja afetado. E em casos de operação

degradada, que consiste na ocorrência de falha em que os usuários

necessitam evadirem-se do trem em destino diverso do que fora sua

intenção a priori, deverá a contratada encontrar solução para a

restituição desses passes unitários, indenizando os usuários

afetados por esta situação e outras afins. A identificação e os

valores restituídos devem restar demonstrados e contabilizados no

Sistema de vendas (POS), assim que o caixa seja encerrado. Este

ticket específico para situações degradadas somente poderá ser

gerado no POS quando habilitado remotamente por um controlador

de estações ou outro empregado a ser definido pela Trensurb;

4.1.10.2.4. O dimensionamento da equipe de manutenção para cumprimento

dos Níveis de Serviço é de responsabilidade da contratada. O

pessoal residente na Trensurb deverá ter vínculo empregatício com

a contratada, e a mesma deverá estar em dia com todas as

obrigações trabalhistas. Caso a contratada prefira manter uma

equipe permanente de manutenção nas dependências da Trensurb,

será disponibilizada uma sala com ramal telefônico e internet, no

entanto, mobiliário e demais equipamentos necessários são de

responsabilidade da contratada.

4.1.11. Treinamento:

A contratada deverá fornecer treinamento, contemplando todas as nuances do

novo sistema de bilhetagem, considerando as diversas possibilidades deste processo,

entregando aos funcionários os resultados de suas elucubrações, desde os prolegômenos

deste novo procedimento às ações práticas atinentes a todas as áreas envolvidas.

Alertando sobre eventuais vicissitudes ou mesmo contratempos que possam ocasionar

alterações no status quo do sistema. Este treinamento deverá ser organizado pela

contratada de modo que todos os funcionários do setor de operação, levando em conta

as diferentes escalas, possam simular prática e teoricamente as mudanças que trará esta

nova metodologia. O treinamento deverá se estender a todos os funcionários cujas




64

atribuições estejam adstritas à nova bilhetagem. Com o apoio e a orientação do Setor de

Treinamento da Trensurb, a contratada deverá organizar o cronograma de treinamento,

carga horária e conteúdo pragmático, para aproximadamente 250 empregados nos

diversos módulos do novo sistema de bilhetagem.

Para o total entendimento dos envolvidos e para que haja consociação entre as

instruções teóricas e a sintetização da prática, o treinamento deverá abranger:

4.1.11.1. O Sistema de venda (POS), a venda de Passe Unitário, as recargas de

Passe Antecipado, a abertura e o fechamento de caixa, estoque,

processos de supervisão e controle;

4.1.11.2. O Sistema de bloqueios, no tocante a funcionamento, liberações e

inversões;

4.1.11.3. A contratada deverá organizar um treinamento específico para o Setor

de Sinalização – SESIN, fornecendo uma giga de testes montada em um

bloqueio a ser fornecido pela Trensurb, conjecturando sobre

especificações técnicas, esquemas elétricos dos validadores e demais

componentes que serão embarcados nos bloqueios;

4.1.11.4. A contratada deverá organizar um treinamento específico para a

Gerência de Informática – GEINF, para conhecimento do data center,

estrutura de banco de dados, relatórios e aplicações;

4.1.11.5. A contrata deverá organizar um treinamento específico para os Setores

Financeiro, de Mobilidade Urbana e Bilhetagem Eletrônica, para as

questões relacionadas à gestão, controle financeiro, relatórios, cadastros

e controles, etc...

4.1.12. Publicidade:

Para que possamos legar ao público os benefícios da troca do atual sistema de

bilhetagem para o moderno processo que está sendo implementado, faz-se mister a

utilização de diversas ferramentas de promoção. Não obstante os conceitos da nova

operação serem semelhantes ao atual, haverá a necessidade de uma publicidade

intensiva, em que sejam informadas suas múltiplas vantagens para que obtenhamos a

plena aceitação do usuário, persuadindo-o e estimulando-o a participar da transição,

motivando-o a correlacionar a mudança de cultura à uma melhoria em sua experiência

de viagem. Far-se-á, para tanto, o uso das técnicas de mercadologia que fomentem a

promoção e efetivem a plena comunicação relacionadas aos nossos produtos e ideias,

direcionando ao maior número de pessoas e incutindo, de forma coletiva, os princípios

que constituem nossa reputação. Para que esta transição tome corpo, será necessário

que:

4.1.12.1. A contratada seja responsável por toda publicidade relativa ao novo

processo de bilhetagem durante as três fases do projeto, pelo custo de

criação e produção de material gráfico; assim como o custo de inserção

nos veículos de comunicação;




65

4.1.12.2. As mídias utilizadas sejam: rádio, jornal, televisão, redes sociais,

estações, interior do trem e a abordagem direta ao usuário;

4.1.12.3. Todo material de publicidade deverá ser elaborado, instalado,

substituído e/ou removido pela contratada com aprovação e orientação

da Gerência de Comunicação e Gerência Comercial da Trensurb ,

incluindo as peças a serem divulgadas nos veículos de comunicação;

4.1.12.4. No caso da difusão de ideias envolvendo abordagem direta ao usuário, a

contratada será responsável pela contratação temporária de pessoal,

treinamento, indumentária e outras necessidades que se fizerem

necessárias para o êxito da publicidade. Toda campanha de abordagem

direta terá supervisão e acompanhamento de pessoal designado pela

Trensurb.




66

4.2.Fase 2 – Máquinas de Auto atendimento e Serviços pela Internet -

Especificações e premissas

A fase 2 terá caráter modernizador, pois é nela que serão implementadas as

vendas de crédito de passe antecipado pela internet, um modelo em voga em metrôs de

diversos países, e que, comprovadamente, tem grande adesão dos usuários pela

facilidade em adquirir os passes, sem precisar ficar em filas ou levar dinheiro consigo,

pois todo o trâmite é feito com cartão de crédito/débito em sítio seguro da web. Outra

facilidade será a inauguração das vendas de Passes Unitários e recargas de Passe

Antecipado através de caixas automáticos de autoatendimento, localizadas nas estações

da Trensurb, com a finalidade de dirimir as filas e educar os usuários a adquirir

previamente suas passagens.

4.2.1. Serviços pela internet: Essa implementação consiste na possibilidade do

usuário, através de um sítio seguro na web, fazer as recargas de seu cartão PA –SIM

Identificado via internet, solicitar um Cartão PA-SIM Identificado, complementar o

cadastro no caso de já possuir o cartão, informar perda do cartão ou transformar um

Cartão PA-SIM ao portador em Identificado;

4.2.1.4. No site da Trensurb deverá constar um link que instruirá e

direcionará o usuário para a colocação de crédito e para a

solicitação de Cartão PA-SIM Identificado;

4.2.1.5. Nessa aplicação o usuário que escolher a opção recarga de

créditos, deverá informar o CPF, valor de recarga e a forma de

pagamento: crédito, débito ou boleto. No caso de crédito ou débito

a recarga ocorre automaticamente no cartão do usuário. No caso de

pagamento por boleto, o crédito ocorrerá no momento da

confirmação do pagamento pelo banco. A carga do crédito no

cartão se dará no momento que usuário aproximar o cartão do

validador do bloqueio;

4.2.1.6. Na opção “solicitar um cartão”, o usuário deverá informar o CPF,

nome, endereço, data de nascimento, telefone para contato e em

qual estação da Trensurb deseja retirar o cartão. O usuário poderá

fazer uma recarga logo após a confirmação do cadastro. Na retirada

do cartão, o agente de estação da Trensurb fará a entrega do mesmo

via sistema e a carga do crédito no cartão se dará no momento que

usuário aproximar o cartão do validador do bloqueio;

4.2.1.7. Na opção “atualizar cadastrado”, o usuário informa o CPF,

devendo abrir uma tela para complementação do cadastro, exceto a

informação de qual estação deseja retirar o cartão;

4.2.1.8. No caso da escolha da opção ”Informar perda ou cancelamento de

cartão ”, o usuário deve informar o CPF, confirmar os dados do

cadastro e informar se quer a 2ª via e em qual estação deseja retirar.

O sistema deve prever o pagamento da 2ª via do cartão, que pode

ser feita na bilheteria da estação ou via internet e deve informar o

usuário, via mensagem por celular ou email, referente ao

cancelamento do cartão;




67

4.2.1.9. Na opção “transformar um cartão ao portador em cartão

identificado”, o usuário deve informar o número que consta no

layout do cartão e os demais dados do cadastro necessários para a

transição para cartão identificado;

4.2.1.10. A contratada será responsável pelo desenvolvimento,

manutenção e atualizações dessa aplicação na web, assim como de

toda infraestrutura necessária, tais como: equipamentos, servidores,

contratos com bancos e operadoras de cartão de crédito, pessoal e

todo o necessário para implementação desse produto;

4.2.1.11. A central de atendimento ao usuário, prevista na Fase1, poderá

ser utilizada para concentrar as ações desse produto, incluindo a

confecção e inutilização dos cartões gerados por essa aplicação;

4.2.1.12. Os resultados financeiros dessa aplicação devem constar nos

relatórios financeiros, discriminados de forma clara e objetiva,

identificando de forma separada os créditos gerados por esta

aplicação. A Trensurb deverá ter acesso a toda base original de

aplicação, tanto em relação a cadastro, créditos e quaisquer outras

informações que julgar necessária.

4.2.2. Máquinas de autoatendimento: As máquinas de autoatendimento são

equipamentos instalados nas estações nos quais o usuário poderá comprar Passes

Unitários ou fazer recargas em Cartões PA-SIM Identificados e ao portador, bem como

consultar saldos e gerar demonstrativo de utilização de ticket unitário que estiver de

posse.

4.2.2.1. Em cada estação, duas máquinas, no mínimo, deverão ficar

posicionadas à disposição do usuário, durante todo o horário

comercial e em local estratégico a ser definido pela Trensurb;

4.2.2.2. Devem pesar no máximo 300 Kg/m²;

4.2.2.3. Devem aceitar somente cartões de débito ou crédito;

4.2.2.4. Devem emitir passes unitários na mídia prevista na Fase 1;

4.2.2.5. Devem possibilitar recargas em cartões de PA-SIM nas mídias

previstas na Fase 1;

4.2.2.6. A contrata deverá fornecer, instalar e manter as máquinas de

autoatendimento;

4.2.2.7. Toda a infraestrutura para instalação e operação das máquinas será

de responsabilidade da contratada, assim como os contratos com

bancos e operadoras de cartão de crédito;

4.2.2.8. O status de cada máquina de autoatendimento deverá estar

disponível para controle da Trensurb, bem como o que concerne às




68

falhas, máquinas com defeito operacional, falta de papel e outras

situações consoantes à boa manutenção dos equipamentos. Este

controle deve ser projetado em tempo real, através de

computadores a serem definidos pela Trensurb;

4.2.2.9. A Trensurb deverá ter acesso em tempo real às operações

financeiras das máquinas de autoatendimento;

4.2.2.10. As operações financeiras deverão constar nos relatórios contábeis

de forma discriminada, com os valores dos produtos, Passe

Unitário, recarga de PA;

4.2.2.11. O abastecimento de insumos, como por exemplo: papel para

geração de passes unitários, toner e outros de reposição periódica

é de responsabilidade da contratada;

4.2.2.12. A contratada deverá organizar treinamento, conforme formato e

critérios definido na Fase 1;

4.2.2.13. Toda a estrutura de operação e controle dessa fase deve estar

conectada ao data center previsto na Fase1;

4.2.2.14. As vendas de créditos do passe antecipado ou unitário, realizadas

através das máquinas de autoatendimento, pagos por meio dos

cartões de débito e crédito, deverão constar em relatório de venda

por período (diário, mensal, anual, etc.), por local e por

equipamento;

4.2.2.15. A contratada deverá firmar contrato com as operadoras de cartões

que atuam em nível nacional e regional, sendo que o custo desse

contrato será de responsabilidade da contratada;

4.2.2.16. O crédito da venda do passe antecipado e do unitário deverá

ocorrer na conta da própria contratada;

4.2.2.17. O valor referente à venda efetuada deverá ser depositado pela

contratada para a contratante por meio de Guia de Recolhimento

da União (GRU) em até 02 (dois) dias úteis após a sua venda;

4.2.2.18. Os custos das operações financeiros decorrentes de vendas por

cartão de crédito/débito ou pagamento com documento bancário e

Guia de Recolhimento da União (GRU) serão de responsabilidade

da contratada;

4.2.2.19. A contratada deverá oferecer condições de integração das

informações de venda com os sistemas utilizados pela Trensurb.

4.3.Fase 3 – Serviços por celular - Especificações e Premissas




69

A terceira fase trará a evolução do processo tecnológico implementada na

segunda fase. Serão habilitadas as formas de aquisição de créditos antecipados através

de aplicativo próprio para smartphone, uma tendência que costuma ter imediata filiação

por parte dos consumidores, pois está alinhada à tecnologia presente em diversas searas

da vida moderna, trazendo facilidades e economia de tempo para o usuário e diminuição

da demanda de compradores nos postos de vendas de bilhete.

4.3.1. Através da aplicação “Serviços pela Internet” no site da Trensurb, o

usuário poderá comprar Passes Unitários, utilizando como forma de

pagamento o cartão de crédito ou de débito;

4.3.2. Na aplicação, o usuário informa o número do celular, e a forma de

pagamento;

4.3.3. Após a confirmação do pagamento, o Passe Unitário é transferido para o

celular, que poderá ser lido pelo bloqueio, diretamente da tela do aparelho;

4.3.4. A compra poderá ser de um ou mais passes, sendo que o limite máximo

será definido posteriormente;

4.3.5. A contratada deverá desenvolver, implantar e manter essa aplicação;

4.3.6. Toda a infraestrutura necessária para implantação dessa aplicação, como

servidores, links adicionais de internet, equipamentos, pessoal e demais

necessidades é de responsabilidade da contratada;

4.3.7. A Trensurb deverá ter acesso total e em tempo real às transações

financeiras, quantitativas e qualitativas dessa aplicação.

4.3.8. As vendas de créditos do passe antecipado ou unitário, realizadas através

das máquinas de autoatendimento, pagos por meio dos cartões de débito e

crédito, deverão constar em relatório de venda por período (diário, mensal,

anual, etc.), por local e por equipamento;

4.3.9. A contratada deverá firmar contrato com as operadoras de cartões que

atuam em nível nacional e regional, sendo que o custo desse contrato será

de responsabilidade da contratada;

4.3.10. O crédito da venda do passe antecipado e do unitário deverá ocorrer na

conta da própria contratada;

4.3.11. O valor referente à venda efetuada deverá ser depositado pela contratada

para a contratante por meio de Guia de Recolhimento da União (GRU) em

até 02 (dois) dias úteis após a sua venda;

4.3.12. Os custos das operações financeiros decorrentes de vendas por cartão de

crédito/débito ou pagamento com documento bancário e Guia de

Recolhimento da União (GRU) serão de responsabilidade da contratada;

4.3.13. A contratada deverá oferecer condições de integração das informações de

venda com os sistemas utilizados pela Trensurb.




70

5. Características da Prestadora de Serviços e Exigências para habilitação na

futura licitação

Empresa ou consórcio de empresas, com estrutura para acompanhamento e

diagnóstico referente a demandas técnicas e apta a garantir perene modernização no

processo de bilhetagem eletrônica, garantindo a efetivação dos itens elencados e dentro

dos prazos estabelecidos neste projeto.

À prestadora do serviço, sendo ela empresa ou consórcio de empresas, ficará a

atribuição do desenvolvimento do projeto executivo, do fornecimento de equipamentos,

infraestrutura, recursos técnicos e humanos necessários para a execução dos serviços,

bem como pela garantia da continuidade dos serviços para atendimento das demandas

que compõem o objeto do presente documento.

Como condição prévia ao exame da documentação de habilitação do proponente

será verificada eventual descumprimento das condições de participação, especialmente

quanto à existência de sanção que impeça a participação no certame ou a futura

contratação, mediante a consulta aos seguintes cadastros enviados pelo proponente:

5.1. Cadastro Nacional de Empresas Inidôneas e Suspensas – CEIS, mantido pela

Controladoria-Geral da União (www.portaldatransparencia.gov.br/ceis);

5.2. Cadastro Nacional de Condenações Cíveis por Atos de Improbidade

Administrativa, mantido pelo Conselho Nacional de Justiça

(www.cnj.jus.br/improbidade_adm/consultar_requerido.php);

5.3. Lista de Inidôneos, mantida pelo Tribunal de Contas da União – TCU.

5.4. Para habilitação jurídica, fiscal e trabalhista, as proponentes deverão

demonstrar mediante a apresentação dos seguintes documentos:

5.4.1. Cédula de identidade;

5.4.2. Ato constitutivo, estatuto ou contrato social em vigor, devidamente

registrado, em se tratando de sociedades comerciais, e, no caso de

sociedades por ações, acompanhado de documentos de eleição de seus

administradores;

5.4.3. Inscrição do ato constitutivo, no caso de sociedades civis, acompanhada

de prova de diretoria em exercício;

5.4.4. Prova de inscrição no Cadastro Nacional de Pessoas Jurídicas;

5.4.5. Prova de regularidade fiscal perante a Fazenda Nacional, mediante

apresentação de certidão expedida conjuntamente pela Secretaria da

Receita Federal do Brasil (RFB) e pela Procuradoria-Geral da Fazenda

Nacional (PGFN), referente a todos os créditos tributários federais e à

Dívida Ativa da União (DAU) por elas administrados, inclusive aqueles

relativos à Seguridade Social, nos termos da Portaria Conjunta nº 1.751,

de 02/10/2014, do Secretário da Receita Federal do Brasil e da

Procuradora-Geral da Fazenda Nacional;

5.4.5.1. Será aceita a certidão expedida pela Receita Federal do Brasil e

Procuradoria-Geral da Fazenda Nacional obtida através da Internet,

respeitado o prazo de validade da mesma;

http://www.portaldatransparencia.gov.br/ceis

http://www.cnj.jus.br/improbidade_adm/consultar_requerido.php




71

5.4.6. Prova de regularidade com o Fundo de Garantia do Tempo de Serviço

(FGTS);

5.4.7. Prova de inexistência de débitos inadimplidos perante a Justiça do

Trabalho, mediante a apresentação de certidão negativa ou positiva com

efeito de negativa, nos termos do Título VII-A da Consolidação das Leis

do Trabalho, aprovada pelo Decreto-Lei nº 5.452, de 1º de maio de 1943;

5.4.8. 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;

5.4.9. Certidão Negativa de Débitos ESTADUAIS (ICMS) emitida pela

Secretaria da Fazenda Estadual;

5.4.10. Certidão Negativa de Débitos MUNICIPAIS emitida pela Secretaria da

Fazenda Municipal;

5.4.11. Apresentação do Balanço patrimonial e demonstrações contábeis do

último exercício social;

5.4.11.1. Para as empresas que escrituram o Livro Diário Digital na forma

prevista na IN DNRC n.107, de 23/05/2008, deverão ser apresentados,

o Balanço Patrimonial e as Demonstrações Contábeis dele extraídas,

Termos de Abertura e Encerramento do Livro Diário Digital e Recibo

de Entrega de Livro Digital emitidos pelo Programa Validador e

Assinador (PVA), que comprova a autenticação, conforme previsto no

Decreto n º 8.683/2016;

5.4.11.2. Para as empresas que não escrituram o Livro Diário Digital na

forma prevista na IN DNRC n.107, de 23/05/2008, deverão apresentar

cópia autenticada dos Termos de Abertura e Encerramento do Livro

Diário, registrado na Junta Comercial da sede ou domicílio da

licitante e/ou em outro órgão equivalente, onde foi transcrito o

Balanço Patrimonial e Demonstrações Contábeis, vedada a sua

substituição por balancetes ou balanços provisórios, podendo ser

atualizados por índices oficiais quando encerrados há mais de três

meses da data de apresentação da proposta;

5.4.11.3. Na comprovação da boa situação financeira da empresa serão

considerados os índices de Liquidez Geral (LG), Solvência Geral

(SG) e Liquidez Corrente (LC), igual ou maiores que 1,0 (um vírgula

zero). As licitantes que apresentarem índices inferiores a 1,00 (um

inteiro) poderão comprovar possuir Capital Social mínimo, totalmente

integralizado, cujo valor individual seja equivalente a no mínimo 10%

(dez por cento) do valor total estimado para a contratação;

5.4.12. Certidão negativa de falência ou recuperação judicial, ou liquidação

judicial, ou de execução patrimonial, conforme o caso, expedida pelo

distribuidor da sede do licitante, ou de seu domicílio, dentro do prazo de

validade previsto na própria certidão, ou, na omissão desta, expedida a

menos de 180 (cento e oitenta) dias contados da data da sua

apresentação;




72

5.4.13. Atestado de qualificação técnica fornecido por pessoa jurídica de direito

público ou privado, que demonstre aptidão para desempenho de atividade

pertinente e compatível em características, quantidades e prazos com o

objeto da licitação, de acordo com o item 5.6 deste Termo de Referência;

5.4.14. Declaração de que não emprega menor de 18 anos em trabalho noturno,

perigoso ou insalubre e não emprega menor de 16 anos, salvo na

condição de aprendiz a partir de 14 anos. Declaração emitida pela

licitante, sob as penas da Lei, de que está cumprindo o disposto no inciso

XXXIII do art. 7º da Constituição Federal, conforme Decreto nº 4.358,

de 5 de setembro de 2002, nos termos do modelo anexo;

5.4.15. Declaração de inexistência de fato superveniente impeditivo à sua

habilitação, que impeça sua contratação, nos termos do modelo anexo.

5.4.16. Declaração de conhecimento do Código de Ética da TRENSURB.

5.5. Condições para composição de Consórcio:

5.5.1. Empresas brasileiras e estrangeiras;

5.5.2. Constituição de pessoas jurídicas devidamente constituídas;

5.5.3. Os consórcios entre empresa brasileira e estrangeira, a liderança caberá à

empresa brasileira;

5.5.4. O consórcio entre empresas brasileiras caberá à liderança a aquela que

comprovar deter maior conhecimento técnico, conforme características

definidas para a qualificação técnica.

5.5.5. A empresa líder do consórcio a representará junto à TRENSURB em

todos os atos, comunicações e avisos relacionados com a presente

licitação ou com o contrato dela decorrente;

5.5.6. É vedada à participação de empresa consorciada em mais de um

consórcio ou isoladamente;

5.5.7. O prazo de duração do consórcio deve, no mínimo, coincidir com o prazo

de conclusão do objeto da licitação, até a emissão do Termo de

Recebimento Definitivo do Contrato;

5.5.8. O licitante vencedor fica obrigado a promover, até 03 (três) dias antes da

celebração do contrato, a constituição e o registro do consórcio. O termo

de constituição do consórcio, assinado pelos representantes legais das

empresas consorciadas, indicados nos respectivos contratos ou estatutos

sociais, deverá observar, além dos dispositivos legais, as cláusulas deste

Edital, especialmente as constantes deste subitem;

5.5.9. Os Consórcios deverão apresentar os documentos individualmente pelas

empresas que o constituem;

5.5.10. Apresentar a comprovação do compromisso público ou particular de

constituição, subscrito pelos consorciados não podendo ser singelo

documento despido das regras básicas que conformarão o futuro

consórcio. Deverá prever:

5.5.10.1. O nome, duração e endereço do consórcio;




73

5.5.10.2. As licitantes e a respectiva empresa líder obediente à legislação;

5.5.10.3. As obrigações e responsabilidades a serem assumidas pelo futuro

consórcio e por cada uma das consorciadas;

5.5.10.4. As condições de liderança da licitante responsável pelo consórcio:

ter poderes expressos para receber citação, responder judicialmente

pelas demais consorciadas e representar o consórcio em todas as

fases do presente procedimento licitatório, podendo inclusive,

interpor e desistir de recursos, firmar o contrato e praticar todos os

atos necessários;

5.5.10.5. A pessoa jurídica ou consórcio deverá assumir inteira

responsabilidade pela existência de fatos que possam comprometer

sua habilitação na presente licitação e, ainda, pela autenticidade de

todos os documentos que forem apresentados.

5.5.10.6. Compromisso de que não alterarão a constituição ou composição

do consórcio, visando manter válidas as premissas que asseguram a

sua habilitação, salvo anuência prévia e expressa da TRENSURB.

5.5.10.7. Declaração expressa, firmada pelos representantes legais das

licitantes componentes do Consórcio de que, se vencedor da

presente licitação, levarão a registro na competente Junta

Comercial o termo de compromisso de Constituição de Consórcio,

na forma estabelecida na Lei Federal nº 6.404/76 e alterações

observadas às disposições da Instrução Normativa RFB nº 1.005 de

08/02/2010, quanto à obrigatoriedade de inscrição no Cadastro

Nacional da Pessoa Jurídica do Ministério da Fazenda (CNPJ/MF);

5.5.10.8. A forma de administração do consórcio;

5.5.10.9. A repartição das futuras despesas e resultados;

5.5.10.10. A representatividade social de cada uma das licitantes, constando

o percentual de cada consorciada;

5.5.10.11. Procuração da consorciada outorgando à licitante líder poderes

para representá-la junto à TRENSURB, em juízo ou fora dele;

5.5.10.12. A indicação da pessoa jurídica responsável pelo consórcio, que

deverá atender às condições de liderança fixadas neste instrumento

convocatório;

5.5.10.13. A ciência do impedimento de participação de consorciado, na

mesma licitação, em mais de um consórcio ou isoladamente, bem

como de profissional, em mais de uma empresa, ou em mais de um

consórcio;

5.5.11. É obrigatório constar a responsabilidade solidária;

5.5.12. No compromisso de constituição de consórcio a ser firmado pelos

licitantes; e, no contrato a ser celebrado pelo consórcio vencedor.

5.5.13. O foro competente para dirimir eventuais litígios entre as partes

consorciadas será o da sede do CONTRATANTE.

5.6. Qualificação Técnica




74

5.6.1. Para o hardware apresentado na data center será exigida a apresentação

de declaração do fabricante atestando que a licitante está autorizada a

comercializar os seus equipamentos e capacitada a prestar o suporte técnico

necessário. Em caso de consórcios, a declaração poderá ser emitida em

nome da empresa participante responsável por esta(s) parcela(s).

5.6.2. Projeto executivo

5.6.2.1. A licitante deverá apresentar junto com a documentação de

qualificação técnica o Projeto executivo de toda solução proposta

para Fase 1 desse edital;

5.6.2.2. Devem constar no Projeto executivo, todas as soluções,

procedimentos e processos que envolvem a proposta apresentada e o

cronograma de implantação de cada processo;

5.6.2.3. Composição do data center, conexões com a rede da Trensurb,

rotinas de segurança;

5.6.2.4. Soluções de conexões de rede, criação de domínios, hardware,

softwares e rotinas de armazenamento e backup de dados;

5.6.2.5. Integração nos bloqueios dos validadores da solução proposta com

os validadores existentes na Trensub de tecnologia Prodata e

tecnologia Tacom;

5.6.2.6. Sistemas de vendas, hardware, software, rotinas, processos,

segurança, tratamento de falhas, relatórios, controle em tempo real;

5.6.2.7. A licitante que deixar de apresentar o Projeto Executivo será

sumariamente desclassificada.

5.6.3. Homologação da Solução

5.6.2.8. A licitante vencedora terá o prazo de 10 dias consecutivos, após o

resultado da licitação, para montar um piloto com base no Projeto

Executivo apresentado;

5.6.2.9. Nesse piloto deve constar a instalação de 02 (dois) validadores

com a solução proposta numa estação a ser definido pela Trensub,

um validador integrado com a tecnologia Prodata e o outro

validador integrado com a tecnologia Tacom com câmera para

leitura facial em ambos;

5.6.2.10. Deve ser instalado um ponto de venda em uma bilheteria na

mesma estação escolhida para o piloto dos bloqueios, que deverá

promover vendas de passes unitários, geração e recargas de

Cartão Passe Antecipado não identificado;

5.6.2.11. Na mesma estação deve ser instalado um equipamento para teste

do cadastramento de cartões, onde deverão ser criados cartões

funcionais com perfil operacional para liberação das gratuidades

nessa estação;

5.6.2.12. Deve ser instalado um servidor, na sala de equipamentos da

estação, que armazene todas as transações de bloqueios, pontos de

vendas e cadastramento de cartões e imagens de usuários de




75

isenções, possibilitando o acompanhamento em tempo real das

transações e também a emissão de relatório de usos, vendas,

recargas e cadastros efetuados.

5.6.2.13. A homoloção do piloto terá duração de 05 (cinco) dias

consecutivos no horário das 08:00h até as 20:00h;

5.6.2.14. Ao final do período será avaliado o atendimento aos tempos de

duração dos processos de vendas de passes unitários, e liberação

de bloqueios, conforme exigido no item 4.1.1;

5.6.2.15. Nos bloqueios será avaliado também o desempenho da solução,

onde o numero de falhas deverá chegar no máximo a 2% dos

números de acessos em cada bloqueio, exemplo: 100 acessos,

número máximo de falhas 2;

5.6.2.16. Os relatórios em relação aos pontos de vendas deverá permitir

listar em tempo real:

A estação

O ponto de venda

O bilheteiro que está operando o sistema

Data, hora de início e hora de término

Quantidade Passes e/ou recargas efetivadas

Valor total de vendas até o momento da listagem

5.6.2.17. Os relatórios de bloqueios devem permitir listar em tempo real:

A estação

O bloqueio

Selecionar data, hora de início e hora de término

Categoria de passes

Quantidade de passes de cada categoria

Total de passes, por período, por categoria e por data, por hora,

por bloqueio e por estação

5.6.2.18. A Trensurb colocará uma equipe para acompanhar, dar suporte e

logística para implantação da homologação durante todo o

período do piloto;

5.6.2.19. Após o término do prazo da homologação, uma equipe fará

avaliação dos resultados, conforme as premissas previstas;

5.6.2.20. A licitante que não atender a qualquer um dos itens previstos na

homologação, terá 48hs para corrigir o problema. Findo esse

prazo será feito novo teste, caso não seja atendido, a licitante será

desclassificada.

5.6.2.21. O prazo fixado de 10 dias consecutivos após o resultado da

licitação para a licitante vencedora apresentar o plano piloto para




76

homologação, poderá ser prorrogado uma única vez. O

descumprimento ensejará a sumaria desclassificação.

5.6.4. Visita Técnica

5.6.4.1. As empresas interessadas deverão realizar Visita Técnica às

instalações da TRENSURB, a fim de conhecerem in loco as

peculiaridades do sistema, regulamentos, normas técnicas e

administrativas, condições do local de entrega, montagem, testes,

treinamentos e demais informações pertinentes.

5.6.4.2. Para agendamento da Visita Técnica, contatar com antecedência a

data estabelecida para o certame, com o Valdinei Nascimento ou

José Luiz Brandão pelos telefones (51) 3363-8137, (51) 3363-8290,

de segunda à sexta-feira no horário administrativo das 08:00h as

17:00h. ou pelos e-mails [email protected] ou

[email protected];

5.6.4.3. Por ocasião da realização da visita, será fornecido o Atestado de

Visita Técnica, cuja realização é de caráter indispensável à

participação nesta licitação, não cabendo qualquer alegação futura

referente a desconhecimento de dificuldades para o cumprimento

de suas obrigações contratuais.

5.7. Na futura licitação será adotada a modalidade de licitação Pregão Eletrônico do

tipo menor preço, com fundamento na Lei nº 10.520 e princípios da Lei Geral

de Licitações.

6. Caberá à CONTRATADA dentre outras atividades inerentes à natureza da

prestação de serviço contratado

6.1. Em até 10 (dez) dias após a assinatura do contrato, prestar garantia contratual;

6.2. Recuperar, repor ou substituir, sob suas expensas, qualquer defeito ou dano que

tenha causado aos espaços disponibilizados nas dependências e equipamentos

da Trensurb (bloqueios, bilheterias, estações, sala de equipamentos, etc.) por

consequência dos serviços realizados conforme o objeto desta licitação;

6.3. Executar o projeto executivo em conformidade com o estabelecido na proposta

técnica vencedora do certame, a qual prevê o formato da manutenção periódica

e de emergência a ser executada pela contratada nos equipamentos instalados

para a efetivação do processo de bilhetagem eletrônica;

6.4. Ser a responsável pela elaboração dos projetos, preparação dos locais onde

serão instalados equipamentos ou realizadas benfeitorias (obras civis, elétricas,

etc.) Assim como a execução, fornecimento de materiais e equipamentos, para

a perfeita execução do contrato;

6.5. Remeter à Trensurb, mensalmente, cópias impressas ou imagens digitalizadas

de todos os instrumentos contratuais, notas fiscais, distrato, renovações,

aditamentos ou quaisquer outros expedientes firmados pelo consórcio com

terceiros, que digam respeito ao objeto deste projeto básico;

mailto:[email protected]




77

6.6. Desenvolver um sistema eletrônico, com funcionamento via internet, de livre

acesso à Trensurb para fins de controle/auditoria, que possibilite a consulta de

todas as informações atinentes ao processo de bilhetagem eletrônica;

6.7. Responsabilizar-se por qualquer compromisso assumido perante terceiros

relativos ao objeto desta licitação, bem como por danos causados aos mesmos,

e pelas indenizações, custos e despesas que estes vierem a ter direito em

decorrência de atos de seus empregados, prepostos ou subordinados;

6.8. Manter sempre suas equipes de trabalho devidamente uniformizadas e

identificadas com crachá para ingressar nas dependências da Trensurb, assim

como disponibilizar todos os equipamentos de segurança necessários para a

perfeita execução dos serviços, respeitando todas as normas da Trensurb;

6.9. Arcar por quaisquer responsabilidades decorrentes de ações judiciais, inclusive

trabalhistas que lhe venham a ser atribuídas por força de lei, relacionados com

o cumprimento do presente projeto básico e do contrato que vier a ser assinado;

6.10. Executar, conforme a melhor técnica, os serviços contratados, estabelecendo,

com os prepostos da Trensurb, os prazos e horários para sua execução, de

forma a não prejudicar a operação do sistema metroviário;

6.11. Manter na execução dos trabalhos, nas dependências da Trensurb, um

responsável nomeado e identificado;

6.12. Fora do horário comercial da administração da Trensurb das 8 (oito) horas às

17 (dezessete) horas, solicitar diretamente ao centro de controle operacional

(cco) o acesso às dependências da Trensurb quando da necessidade de realizar

trabalhos de extrema urgência;

6.13. Requerer acompanhamento de responsável técnico da Trensurb quando da

instalação de equipamentos que possam colocar em risco a segurança e o

funcionamento dos serviços da Trensurb;

6.14. Acatar as determinações de fiscalização e controle da contratante,

providenciando, de imediato, as correções e ajustes que se fizerem necessários;

6.15. Não caucionar ou utilizar o contrato resultante da presente licitação para

qualquer operação financeira sem prévia e expressa autorização da Trensurb;

6.16. Somente optar pela subcontratação de outras empresas para a execução de

serviços de apoio ao objeto de que trata este documento, mediante anuência

prévia, por escrito, da Trensurb, ressaltando-se que a contratada permanecerá

com todas as suas responsabilidades contratuais perante a Trensurb;

6.17. Manter, durante toda a execução do contrato, em compatibilidade com as

obrigações assumidas, todas as condições de habilitação e qualificação exigidas

no certame, devendo, portanto, reapresentar documentos atualizados à medida

que os prazos de validade forem expirando;

6.18. Recolher, sob sua responsabilidade exclusiva, os valores devidos a título de

INSS, FGTS, IRPJ, IRPF, salários, etc do pessoal alocado para executar as

atividades atinentes ao objeto deste projeto básico;

6.19. Colocar-se à disposição para a realização de auditorias por parte da contratante

ou por prepostos, pessoas físicas ou jurídicas, por ela indicados ou

autorizados;




78

6.20. Observar e cumprir as disposições contidas na lei nº. 8.078/90 (lei de defesa do

consumidor);

6.21. Atender o decreto federal nº. 5.940/2006, separando o lixo orgânico e o

reciclável remanescente ou descartado das atividades relativas à execução do

objeto deste edital em embalagens distintas e descartá-los nas lixeiras

apropriadas;

6.22. Manter a sede ou filial, com instalações adequadas, dotadas de recursos

materiais (acesso à internet, equipamentos de informática, impressoras,

escaners, etc.);

6.23. Indicar e manter gestor contratual através do qual fluirá toda a comunicação

entre as partes, seja física ou eletrônica;

6.24. Realizar reuniões periódicas com a contratante, com vistas a discutir e

acompanhar a execução do contrato e solucionar eventuais falhas e

dificuldades decorrentes da prestação dos serviços e estabelecimento de

estratégias;

6.25. Garantir permanente sistema de comunicação com a contratante, por meio

telefônico, internet e meio físico;

6.26. Facultar à contratante, a qualquer momento, visita em seu escritório, para

verificação das condições estruturais da prestação de serviços;

6.27. Ao final do contrato ou no seu encerramento por qualquer outra forma,

transferir à Trensurb ou quem a mesma venha indicar, todos os documentos e

informações pertinentes às ações objeto deste contrato, de modo a não gerar

qualquer prejuízo à continuidade de representação nos feitos, sob pena de

responder pelos mesmos;

6.28. Manter estrutura física e material compatível com a atividade desenvolvida,

dispondo de equipamentos, sistemas, acesso à rede mundial de computadores,

quantidade de pessoal auxiliar e instalações adequadas;

6.29. Facilitar e fornecer todos os dados necessários à auditoria da Trensurb ou de

órgãos externos;

6.30. Ter como referência, na prestação dos serviços, o código de ética da Trensurb;

6.31. Toda a infraestrutura necessária para implantação dessa aplicação, como

servidores, links adicionais de internet, equipamentos, pessoal e demais

necessidades é de responsabilidade contratada;

6.32. Manter, durante a vigência contratual, todas as condições da contratação;

6.33. Cumprir, dentro do prazo contratual, todas as obrigações assumidas;

6.34. A Trensurb deverá ter acesso total e em tempo real às transações financeiras,

quantitativas e qualitativas dessa aplicação;

6.35. Todas as informações referentes às receitas da nossa tarifa (com e sem

desconto) Vale Transporte, segundas vias de cartões de isenções, repasses a

receber e uso de estudantes (se for valor diferente e do uso comum) devem ser

determinadas em relatório a receita de cada município, inclusive por estação e

com quantidades e valores que fechem exatamente com o que será faturado e

declarado ao fisco;




79

6.36. Deverá ser disponibilizada à contratante, em tempo hábil (até, no máximo, o

segundo dia útil do mês seguinte ao fechamento), o relatório da receita da

Trensurb que atenda os aspectos fiscais e legais para fins de comprovação junto

aos órgãos fiscalizadores municipais, estaduais e federais. Esse relatório deve

conter numerações diárias e sequenciais, além da identificação em quantidade e

valores da receita em cada município e por estação cuja utilização foi

efetivada. Os valores demonstrados deverão ser finais e deverão coincidir,

necessariamente, com os relatórios de fechamento totais que servirão para o

nosso faturamento da receita. Não serão admitidos valores que não respeitem

essa padronização de relatório, como valores não identificados de qualquer

espécie, mesmo testes, sob pena de responsabilização formal da empresa

contratada e aplicação de multa (ou glosa) por incidência e/ou reincidência, a

ser definida em cláusula específica;

6.37. Os relatórios com as informações de repasses deverão ser disponibilizados por

fechamentos semanais e mensais, até o segundo dia útil da semana e do mês

seguinte. Já os relatórios de eventuais vendas de produtos da Trensurb (por

exemplo: ValeTransporte e convênios com as outras operadoras de transporte

ATP, ATM e outras), também deverão ter fechamento mensal até o segundo

dia útil do mês seguinte;

6.38. Deverá, a contratada, apresentar os demonstrativos de todas as isenções

(idosos, autoridades, etc.);

6.39. Quanto aos relatórios operacionais e de arrecadação, deverá a contratada

formular relatórios para apurar a arrecadação diária nas estações – resumo por

estação, por produto (Passe Unitário, Passe Antecipado, Isenções, 2ª vias de

cartões de isenções), relatório detalhado de venda por estação e por usuário,

etc. Demonstrativo de fechamento dos caixas – detalhes de vendas, agrupados

por estação e terminal (com ao menos o nome e registro do operador, data e

horário de abertura e fechamento do caixa, além de todas as suas transações

com todos os produtos possíveis - unitários, Passe Unitário, Passe Antecipado,

Isenções, 2ª vias de cartões de isenções, trocas, devoluções e cancelamentos),

incluindo um totalizador de todas essas transações por produto, além do total

da venda geral do operador. Deverá ser possível também a consulta direta do

resumo das vendas de produtos e transações efetuadas por local, operador e

terminal, sem os detalhes de todas as operações, mas com o totalizador dos

valores, para agilizar a consulta;

6.40. Os relatórios operacionais e de arrecadação (vendas de créditos) devem estar

sempre atualizados em tempo real para a conferência da arrecadação das

bilheterias;

6.41. Eventuais dúvidas a respeito dos relatórios devem ser atendidas e resolvidas no

máximo no segundo dia útil após o questionamento, exceto nos períodos de

fechamento da Trensurb, cujo prazo para resolução deverá ser, no máximo, até

o próximo dia útil após o dia do questionamento;

6.42. Nos relatórios não poderão existir nomenclaturas ou códigos estranhos às

informações que necessitamos. Eventuais cálculos internos devem estar

demonstrados e integrais no relatório, sem necessidade de outra fonte de

informação. Não poderá haver resíduos de passagens que não completem o

valor financeiro de uma passagem;




80

6.43. Deverá ser disponibilizado pela contratada um número livre para a definição da

contratante de logins para acesso aos relatórios, e os mesmos deverão ser

relatórios por data de operação e por data de processamento. Esses relatórios e

suas informações devem ser passíveis de exportação/importação para outros

sistemas da Trensurb (como o Dynamics AX ou outros que venham a ser

implantados), bem como serem gerados nas extensões mais comuns (.TXT;

.XLS; .XLSX; .XML; .HTML; .PDF);

6.44. A contratada deverá se comprometer a disponibilizar todos os logs ou arquivos

necessários para a integração das informações da operacionalização da venda

dos créditos nas bilheterias com o sistema de ERP financeiro e operacional

existente na Trensurb (atualmente, Microsoft Dynamics AX ou outro que o

substituir) em tempo real ou, se for provado que essa solicitação é inviável

tecnicamente, o mesmo deve ocorrer até o momento dos fechamentos dos

caixas da bilheteria;

6.45. Permitir o acesso a todos os dados referentes às vendas de Vales Transportes,

tanto em relação aos usos como os créditos em eventuais cargas não efetivadas,

além da quantidade de Vales Transportes ativa no sistema e suas

movimentações no mês (cancelamentos e novos clientes);

6.46. Os valores referentes à comercialização de passes deverão ser depositados

através de GRU (guia de recolhimento da união) dentro do mês de competência

dos créditos devidos. O descumprimento dessa regra de negócio por parte da

contratada poderá representar a incidência de pena de multa (glosa) a ser

definida em cláusula específica;

6.47. Deverá ser disponibilizado à contratante, um acesso à base de dados original da

contratada, mesmo que em modo de consulta, para eventuais auditagens da

própria contratante ou de órgãos de controle e auditoria externa que venham a

nos demandar tal procedimento;

6.48. Fica acordado entre as partes contratantes que todo recurso proveniente das

vendas de créditos enquanto estiver sob a responsabilidade de qualquer uma

das partes, poderá ser utilizado para qualquer fim (como pagamentos e

aplicações financeiras), desde que não comprometa os prazos definidos nesse

contrato para os pagamentos e repasses devidos.

7. Caberá à TRENSURB:

7.1. Designar gestor contratual e indicar prepostos através dos quais se operará a

administração do contrato e providências inerentes ao mesmo;

7.2. Informar à contratada os correios eletrônicos através dos quais deverão

transitar as comunicações com a contratante, assim como os telefones

adequados para realização de contatos;

7.3. Realizar os pagamentos ordinários da prestação dos serviços à contratada;

7.4. Estabelecer as normas de ocupação dos espaços;

7.5. Avaliar, propor ajustes quando necessário e aprovar o plano de ocupação de

espaços/plano de operação, para instalação dos equipamentos;




81

7.6. Analisar, emitir autorizações e justificar negativas em relação aos projetos que

a contratada vir a apresentar relativos à execução do objeto deste projeto

básico;

7.7. Definir as regras do negócio que não estejam contempladas neste edital e no

contrato que vier a ser firmado;

7.8. Informar a contratada das normas de acesso às dependências e equipamentos;

7.9. Facilitar as ações operacionais da contratada, visando à perfeita execução do

objeto do contrato, estabelecendo os horários e locais de acesso às

dependências e equipamentos para a realização dos serviços;

7.10. Informar a contratada sobre qualquer irregularidade que possa ser constatada

na realização dos serviços motivada pela sua equipe de trabalho;

7.11. Designar, expressamente, os prepostos responsáveis pelo acompanhamento das

atividades da contratada.

8. Prazos

O escopo do projeto da bilhetagem eletrônica consiste na prestação de serviço. Para que

exista coerência na efetuação deste trabalho, o prazo para execução será dividido em

duas partes:

8.1. Prazo de Implantação: Cada fase do projeto terá um prazo para implantação,

que consiste na instalação de equipamentos, ajustes, desenvolvimento de

aplicações, treinamento e testes, cujas descrições estão apresentadas nos

cronogramas de cada fase no item 4. A fase 1 terá prazo de implantação de 120

dias corridos a contar da ordem de serviço. A fase 2 terá prazo de 30 dias

corridos após a conclusão da fase 1 e emissão da ordem de serviço. A fase 3

terá o prazo de 30 dias corridos após a conclusão da fase 2 e após a emissão da

ordem de serviço.

8.2. Prazo de prestação dos serviços: Após a implantação e aceite de cada fase,

passa a entrar em vigor o prazo para prestações de serviços, que passará a ser

contado da perfeita finalização da implantação, em que haverá o início da

remuneração correspondente, conforme apresentado na tabela de valores de

referência (item 9).

8.3. Vigência contratual: O prazo de vigência do termo de contrato será de 60

meses. A Trensurb poderá avaliar o contrato a cada 12 meses, sob os pontos de

vista econômico e de qualidade dos serviços

8.4. Após a assinatura do contrato, a publicação no diário oficial e a formalização do

gestor do contrato por parte da TRENSURB, será emitida a Ordem de Início de

Serviço (OIS) para o primeiro pedido de equipamentos, conforme a coluna

Previsão Inicial - item 1 deste Termo de Referência;

8.5. A contratada deverá encaminhar carta formalizando o preposto do contrato e

dados de contato como: telefone fixo, celular, e-mail, central de atendimento,

site web para registro de chamados e para comunicação com a contratante;

8.6. Novas solicitações de equipamentos serão encaminhadas por comunicação

externa (CE) e terão OIS específicas, conforme prazos definidos;




82

9.Valores de Referência

Os valores de referência são relativos à prestação de serviços pagos mensalmente,

cabendo a Trensurb adimplir com os valores, desde que seja cumprido o que apregoam

as cláusulas contratuais.

10. Critérios de Julgamento

Para julgamento será adotado o critério de MENOR PREÇO GLOBAL,

observados os prazos para fornecimento, as especificações técnicas, parâmetros

mínimos de desempenho e de qualidade e demais condições definidas neste Projeto.

Será desclassificada a proposta da empresa que descumprir o prazo estabelecido na

correspondência externa previamente enviada para as participantes deste certame, sendo

facultado a TRENSURB convocar a empresa remanescente, obedecida a ordem de

classificação.




83

11. Local para Entrega de Documentos

EMPRESA DE TRENS URBANOS DE PORTO ALEGRE S.A.

Av. Ernesto Neugebauer, 1985 – Bairro Humaitá

Porto Alegre, RS CEP 90250-140

SETOR DE APOIO – SEAPO (PROTOCOLO GERAL)

Horário de funcionamento: Das 8hs às 12hs e das 13hs às 17hs.

Em virtude de todas as estações da TRENSURB serem alvo das modificações,

implantações e manutenções referidas no presente documento, a totalidade das

estações será destino destes serviços.

12. Forma de Pagamento

12.1. Os pagamentos serão creditados em nome da contratada e serão devidos

mensalmente, conforme a conclusão de cada Fase, cujo prazo está

especificado no item 8. Entende-se por conclusão a entrada em operação

comercial das aplicações e/ou produtos que compõe cada fase, devendo o

primeiro pagamento ser efetuado após o findar dos 30 dias referentes à

implementação da cada fase que compõem o cronograma constante neste

documento.

12.2. Os pagamentos serão creditados em nome da contratada, mediante ordem

bancária em conta corrente por ela indicada, uma vez satisfeitas às condições

estabelecidas neste edital, até o 30º (trigésimo) dia após o recebimento, ou da

Nota Fiscal Eletrônica e Arquivo Digital, ou da Nota Fiscal de Serviço de

acordo com a legislação vigente no município da empresa prestadora de

serviço, no seu Protocolo ou SEMAT (Setor de Materiais da Trensurb), o que

estará adstrito ao Atestado de Recebimento e ou Inspeção do Material emitido

pela área requisitante ou Gestor do Contratante.

12.3. O prazo para pagamento da nota fiscal estará condicionado à correta emissão,

caso não esteja será contado novo prazo a partir da data de entrega da nova

nota fiscal corrigida. Será suspenso o pagamento da nota fiscal, cujo

fornecedor de Serviço ou Material, que estejam enquadrados no Artigo 4º não

tenha apresentado a cada pagamento a Declaração que trata o Artigo 6º da IN

1234/2012 da RFB.

12.4. Para que não ocorra atraso no pagamento, devem observar todas as exigências

e informações, pois a, ausência ou incorreções de dados poderá atrasar o

reconhecimento do vínculo de débito e consequentemente retardar o depósito

em conta bancária. Estando a documentação completa para encaminhamento,

a CONTRATADA apresentará a fatura no Protocolo da CONTRATANTE,

que a encaminhará ao Setor de Administração e Contratos - SEACO, para as

providências cabíveis.




84

12.5. Os serviços serão pagos mediante a apresentação das faturas, recibos ou notas

de serviço que espelharão medições devidamente atestadas pela fiscalização,

desde que acompanhados de cópia dos comprovantes de recolhimento do

FGTS do mês anterior a sua aprovação e atender ao disposto na IN RFB Nº

971/2009 e suas Alterações.

12.6. A Trensurb, como Substituto Tributário, está obrigada a fazer a Retenção de

ISSQN para as Prefeituras de acordo com a legislação de cada município

onde o serviço está sendo prestado. Todas as Notas Fiscais deverão ser

emitidas com o mesmo CNPJ do Pedido de Compras ou Contrato, uma vez

que a Nota de Empenho da despesa foi com base no mesmo.

12.7. Ressalva-se a Contratante o direito de devolução da Nota Fiscal, quando o

CNPJ divergir do contrato. Para emissão de Nota Fiscal Eletrônica (NF-e), na

forma da legislação tributária pertinente referente ao fornecimento de

materiais, a mesma deverá ser encaminhada ao endereço eletrônico nf-

[email protected], quando se referir a operações sujeitas ao ICMS.

Materiais sujeitos a Substituição Tributária, oriundos de outros Estados, o

fornecedor não está isento das Obrigações Legais e para tanto será

considerado pelo Licitante incluso no Preço o valor do ICMS da Substituição

Tributária referente ao Diferencial de Alíquota, o qual deverá estar destacado

na nota fiscal e ICMS recolhido pelo contratado com cópia da GNRE quitada

em anexo ao DANFE.

12.8. Notas Fiscais com mercadorias sujeitas à substituição tributária, que não

constar o devido destaque na NF-e, e não estiver anexa a GNRE quitada, será

rejeitada a nota fiscal e a mercadoria. Serão rejeitados os materiais, referidos

na NF-e, que não tenham sido previamente recebidos pela Trensurb, o

arquivo “.xml” e o DANFE em “.PDF” no endereço de e-mail previamente

indicado. Deverá ainda observar a correta descrição do material e seu código

de NCM correspondente, pertinente ao Pedido de Compra ou Contrato.

12.9. O Recebimento da NF-e está condicionada a correta emissão da mesma,

conforme legislação pertinente, sendo desta forma, passivo de Multa

contratual, devido ao fato que os erros impedem a utilização do material e em

casos de extrema necessidade pela Trensurb, podendo até ser cancelada a

contratação.

12.10. Deverá ser informado nos dados adicionais da nota fiscal, o destaque dos

impostos a serem retidos de acordo com a Legislação Tributária Vigente. Não

será aceita a nota fiscal que tenha sido emitida há tempo superior ao

considerado pelo fisco, isto é, tempo necessário para o transporte

(deslocamento do emitente até o destinatário).

12.11. Para emissão de Nota Fiscal de Serviço Eletrônica (NFS-e), na forma da

legislação tributária pertinente ao fornecimento de prestação de serviços, a

mesma deverá ser encaminhada ao endereço eletrônico nf-

[email protected]. Salvo, se o município da contratada não previr

em sua legislação a emissão de Nota Fiscal de Serviço Eletrônica. Neste caso

será aceita nota fiscal de prestação de serviço de uso comum do município, de

acordo com a Lei municipal. Não será aceita nota fiscal que tenha sido

emitida em desacordo com a Legislação vigente.




85

12.12. Na emissão da nota fiscal, a empresa deverá destacar as retenções tributárias

federais, previdenciárias e municipais a serem efetuadas pela TRENSURB na

condição de substituto tributário.Com base no artigo 34 da Lei nº 10.833 de

29 de Dezembro de 2003, e Instrução Normativa nº 1234/2012, a Trensurb

está obrigada a fazer as Retenções de Tributos e Contribuições Federais,

quando efetuar pagamentos a pessoas jurídicas pelo fornecimento de bens ou

prestação de serviços em geral, inclusive obras, dos seguintes Tributos: IRPJ,

CSLL, COFINS, PIS/PASEP.

12.13. Obrigação da contratada: Informar no documento fiscal o valor do Imposto de

Renda e das Contribuições a serem retidos na operação (artigo 2º, § 6.º da IN

SRF1.234/12).

12.14. As empresas enquadradas como: OPTANTES DO SIMPLES, AMPARADAS

POR ISENÇÃO, NÃO INCIDÊNCIA ou ALÍQUOTA ZERO:

12.14.1. Deverão destacar no documento fiscal a condição de optante, e

inclusive o Enquadramento Legal conforme previsto na Lei

Complementar 123/2006 e suas alterações. OBS: Não havendo o

destaque se sujeitaram à Retenção do Imposto de Renda e das

Contribuições, conforme art. 2º, § 5º da IN SRF 1.234/12.

12.14.2. Apresentar Declaração, em 02 (duas) vias, conforme arts. 3º e 4º e

Anexos da INRFB 1.234/12, deverá ser anexada a cada Documento

Fiscal esta Declaração.

12.15. A Trensurb com base na Instrução Normativa RFB 971/2009 está obrigada a

fazer a Retenção de 11%, sobre os Serviços relacionados conforme Artigos

115 e 116.

12.16. Obrigatoriedade da Contratada: Destacar na Nota Fiscal o "Valor da

Retenção" e com o título "RETENÇÃO PARA A PREVIDÊNCIA SOCIAL",

conforme Artigo 126 da IN, caso aplicável. OBS: Sempre que houver

material e serviço previsto no mesmo contrato, deverá ser destacado na nota

fiscal o percentual de cada, ou ainda, uma nota para material e outra para

serviço. Se não houver referência no contrato à representatividade detalhada

de material e/ou serviço, será tributado para fins de INSS, pela regra geral

conforme legislação.

12.17. Destacar na Nota Fiscal a alíquota e o valor INSS a ser retido.

12.18. A Trensurb, na condição de Substituto Tributário, está obrigada a fazer a

Retenção de ISSQN para o município onde está sendo executada a prestação

de serviço, conforme o caso e na forma da legislação de cada município. As

empresas enquadradas no Simples Nacional devem mencionar na nota fiscal a

alíquota de ISS de acordo com o seu enquadramento na tabela de

recolhimento, conforme §4º do Art. 21 da Lei Complementar 123/2006.

13. Garantia Contratual

A CONTRATADA deverá prestar garantia contratual equivalente a 1% (um por

cento) do valor total do contrato estimado para 60 (sessenta) meses, com vigência dentre




86

as modalidades em lei permitidas (caução em dinheiro, seguro-fiança ou fiança

bancária) e mantê-la durante toda a vigência contratual;

A respectiva garantia será liberada em até 90 (noventa) dias após o término

contratual.

14. Rescisão Contratual

O contrato poderá ser rescindido unilateralmente pela TRENSURB por razões

administrativas ou atendendo ao interesse público, bem como, de pleno direito, na

hipótese de inadimplemento de qualquer das cláusulas contratuais e em especial aos

termos do art. 77 e seguintes da lei nº 8.666/93, consolidada.

Poderá ainda ser rescindido o Contrato pelos seguintes motivos:

14.1. No caso da Contratada falir, entrar em concordata, ou entrar em processo de

extinção por qualquer forma;

14.2. No caso da Contratada transferir no todo ou em parte, sem prévia autorização

da TRENSURB, os serviços objeto firmado.

14.3. Poderão ainda as partes, rescindir o pacto contratual, a qualquer tempo, de

comum acordo, mediante termo específico, com notificação expressa de 60

(sessenta) dias.

15. Penalidades

15.1. Será aplicada uma multa contratual de 5% sobre o valor mensal, caso a

contratada deixe de cumprir com quaisquer obrigações contratuais. No caso de

falhas de bloqueios que geram evasão de receita, será acrescido ao valor da

multa o valor equivalente ao quantitativo de usuários liberados por ocasião da

falha. A quantidade de usuários será medida através do contador analógico

existente nos bloqueios. Em caso de reincidência de descumprimento

contratual no mesmo item, haverá cobrança em dobro, já no mês em referência.

15.2. Aquele que, convocado dentro do prazo de validade da sua proposta, não

entregar amostra no prazo estipulado e nas especificações solicitadas, não

assinar o contrato, não aceitar e/ou não confirmar o recebimento do

instrumento de contratação, não celebrar o contrato, não mantiver a proposta

e/ou suas condições habilitatórias, deixar de entregar documentação exigida no

edital, apresentar documentação falsa, ensejar o retardamento da execução do

contrato, falhar ou fraudar na execução do contrato, entregar material diverso

ao registrado na ata, comportar-se de modo inidôneo, fizer declaração falsa ou

cometer fraude fiscal, poderá ficar impedido de contratar e licitar com União,

pelo prazo de até 5 (cinco) anos, nos termos do artigo 7°da Lei 10.520/02, sem

prejuízo da aplicação da multa de 20% (vinte por cento) sobre o valor total do

contrato e das demais cominações legais.

15.3. No atraso da prestação do objeto desta licitação, ainda que a TRENSURB

aceite receber o objeto, poderá ser aplicada à CONTRATADA multa moratória

de 5% (cinco por cento) do valor contratado do item no primeiro dia de atraso e

0,5% (zero vírgula cinco por cento) do valor contratado do item por dia

subsequente ao primeiro, limitada a 10%, cabendo a defesa prévia.




87

15.4. No caso de reincidente atraso no fornecimento ou prestação do(s) objeto(s)

contratado(s) pela Administração, a Contratada ficará sujeita as demais sanções

administrativas previstas neste Edital. O atraso será contado em dias corridos.

15.5. A multa moratória é automaticamente aplicável.

15.6. A ocorrência de qualquer atraso na execução do objeto desta licitação poderá

ensejar a exclusivo critério e conveniência da TRENSURB, o cancelamento da

contratação caracterizando uma inexecução contratual.

15.7. Pela reprovação do objeto contratado nesta licitação, amostra ou lote, poderá

ser aplicada à CONTRATADA multa administrativa de 5% (cinco por cento)

sobre o valor contratado, o qual será cobrado concomitantemente com a multa

de atraso ou inexecução.

15.8. O valor da multa (moratória ou administrativa), apurada após regular processo

administrativo, será descontado dos pagamentos eventualmente devidos pela

TRENSURB, ser cobrados administrativamente através de Guia de

Recolhimento da União (GRU). Se a cobrança da multa for feita

administrativamente e a CONTRATADA não recolher o valor da multa até o

prazo de vencimento da GRU, serão acrescidos juros moratórios de 1% ao mês,

sem prejuízo das cominações judiciais legais para a cobrança do débito.

15.9. A multa administrativa ou a reincidência de cobrança de multa moratória

poderá ser aplicada cumulativamente com as demais sanções previstas neste

edital, bem como não terá caráter compensatório e a sua cobrança não isentará

o contratado da reparação dos eventuais danos, perdas ou prejuízos que em

decorrência de seu ato venha causar à Administração. Poderá ainda ser aplicada

pela autoridade competente, depois de garantida a ampla defesa e em virtude

da gravidade do ilícito cometido pela CONTRATADA, à declaração de

inidoneidade para licitar ou contratar com a Administração Pública enquanto

perdurarem os motivos determinantes da punição ou até que seja promovida a

reabilitação perante a própria autoridade que aplicou a penalidade, hipótese que

será concedida sempre que o contratado ressarcir a Administração pelos

prejuízos resultantes e após decorrido o prazo de 2 (dois) anos.

15.10. Nenhuma sanção será aplicada sem o devido processo administrativo,

garantida vistas do mesmo. Na aplicação das penalidades previstas neste item

a autoridade competente poderá se valer dos princípios da proporcionalidade,

da razoabilidade e da prevalência e indisponibilidade do interesse público, em

decorrência de circunstâncias fundamentadas para em fatos reais e

comprovados. Das decisões administrativas cabe recurso à CONTRATADA,

em face das razões de legalidade e mérito, nos prazos e condições definidos

na legislação.

16. Valor Estimado

O valor global estimado para contratação da execução da implantação,

acompanhamento, manutenção e demais obrigações constantes neste Termo de

Referência para a vigência contratual de 60 meses, é de R$ xxxxxxxxx

(xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx).




88

17. Do Reajuste

Os valores do contrato poderão ser reajustados com base no IPCA/IBGE,

mediante solicitação da contratada, depois de decorrido o interregno mínimo de 1 (um

ano) da emissão da OIS, apurando-se o índice pelo período de 12 (doze) meses contados

da data da apresentação da proposta.

18. Fonte de recursos

Tesouro Nacional.

19. Área demandante

Superintendência de Desenvolvimento Comercial – SUDEC.




89

ANEXO II

FORMULÁRIO DA CONSULTA PÚBLICA Nº 001/2017

Apresentação e orientações

Para o adequado preenchimento do Formulário observe as instruções abaixo:

Após o preenchimento, o Formulário deverá ser enviado à TRENSURB através do

e-mail [email protected] ou ao Protocolo Geral da TRENSURB no endereço

indicado no Edital.

Preencha todos os campos do Formulário e envie seus comentários durante o

período em que a Consulta Pública estiver aberta ao recebimento de contribuições.

As contribuições recebidas fora do prazo, ou que não forem enviadas por meio de

Formulário, não serão consideradas para efeito de elaboração do texto final do ato.

A insuficiência ou imprecisão das informações prestadas neste Formulário poderá

prejudicar a sua utilização.

As contribuições recebidas não serão objeto de resposta, ficando arquivadas para

uso interno.

A sua participação é muito importante para a transparência do processo decisório e

auxiliará a TRENSURB na elaboração do texto final do ato proposto.




90

Consulta Pública TRENSURB: nº ___ /____

I. Identificação do participante

Nome Completo da Entidade/Empresa:

CNPJ:

Endereço:

Cidade: UF:

Telefones: ( ) E-mail:

II. Contribuições para a Consulta Pública TRENSURB nº _________ / 2017.

Dispositivo da Minuta Texto Proposto para o dispositivo

Justificativa para a solução proposta:








91



III. Há interesse na participação da licitação? ______________

IV. Considerações finais para a Consulta Pública TRENSURB nº _______ / 2017.

[descrever se houver]

Local e Data

Atenciosamente,

____________________________________________

RAZÃO SOCIAL DA EMPRESA

IDENTIFICAÇÃO E ASSINATURA DO REPRESENTANTE LEGAL

editaltrem.trensurb.gov.br/paginas/upload/files/edital consulta...translate this pageedital consulta...

Documents