[GTER] Bloqueios constantes do CADSUS
Douglas Fischer
fischerdouglas at gmail.com
Tue Sep 3 14:26:59 -03 2019
TLDR -> Culpa = Negociação Contrato Fortinet(ou outro vendor)
@Damito... Já tomei muita surra com essas questões.
Essa dificuldade de se chegar nas pessoas certas é por conta de processos
de suporte mal desenhados! Não contemplando outros agentes de informação
além do próprio usuário do sistema de saúde.
Acredito que isso tenha começado assim por limitação de escopo inicial, a
fim de viabilizar o início do projeto. Mas acredito também que HÁ MUITO
TEMPO ELES JÁ SAIBAM dessa falha e "esqueçam" de corrigir, para não ter que
lidar com essa bronca...
Minha sugestão nesse caso é fazermos uma movimentação INTENSA pelos canais
como essa mailing list, a ponto de fazer com que essa informação seja
repassada de forma a by-passar engavetadores de problemas[1], e virar um
tema de perigo vexatório nas reuniões de tomadores de decisão dessas
instituições.
@Rogerio Mariano <rogermariano.cala at yahoo.com>
O Problema na verdade é outro!
Eu não tenho certeza absoluta que o caso do Datasus é dos Fortinet...
Mas teve uma grande quantidade de empresas públicas em 2014-2015 que
compraram solução de firewall da Fortinet com 36 meses de serviço da
Forticloud. Há uns 2 anos esses contratos de serviços terminaram, e com
isso as atualizações de informações de Geolocalização pararam de ser
enviadas para as caixas de Firewall.
Desde então, mesmo que as informações nos RIRs estejam corretas, mesmo que
se atualize as informações de Geolocalização... Essas informações vão para
a base centralizada da Fortinet, mas não chegam às caixas de firewall
porque essas estão sem licença de atualização.
Obs. 1: Isso não é algo que acontece só com a Fortinet!
Eu mesmo já tive esse mesmo problema com caixa da Palo Alto de também da
Cisco.
P.S.: Aliás, nem tenho certeza que o Datasus use mesmo Fortinet.
Salvo engano, a incidência de Fortinet como Firewall em órgãos Federais é
maior porque naquele tempo houveram muitas compras desse fabricante
decorrente de "caronas" de edital, aonde não se faz uma nova licitação,
apenas se replica a compra do objeto do edital através da mesma licitação.
Obs. 2: Deixo claro que NÃO ESTOU CRITICANDO TECNICAMENTE FORTINET.
Tecnicamente é uma ferramenta excelente! Melhor, em alguns aspectos, que os
seus concorrentes.
Também não os estou criticando comercialmente, pois esse é o modelo adotado
por praticamente todos os vendors.
A crítica é explicitamente a quem não viabilizou recursos financeiros[1],
dentro das respectivas instituições, para a renovação da contratação dos
serviços de atualização.
@Danton Nunes <danton.nunes at inexo.com.br>
IPv6 em sites de órgãos do Governo Federal é um sonho! Uma ilusão de Alice!
Só quem já fez uma ativação de IPv6 em algum serviço Web que foi desenhado
em v4 only sabe o "descascar de abacaxi" que é fazer essa implementação. Ao
contrário do que os "otimistões" podem pensar... Não é apenas subir o
socket v6 do Apache/Varnish/Tomcat/IIS/Etc...
Principalmente quando se fala de operações que impactam financeiramente a
vida do indivíduo, é imprescindível o rastreamento de IP do indivíduo,
cruzamento de Geolocalização, e etc...
Já peguei por exemplo uma impossibilidade de migrar para v6 porque o
sistema de LOGs de acesso e operações não estava modelado para suportar
endereços IPv6 nos campos da tabela do banco de dados. Basicamente tiveram
que reescrever todas as funções do sistema para suportar o IPv6.
Uma boa metodologia de um órgão público começar a implementar o suporte a
v6 em seus sites é colocar um Web Proxy Reverso com suporte a v6, e tratar
nele os hosts e rotas html que suportam ou não o IPv6.
P.S.: Tá aí uma coisa para a galera do IPv6.BR tomar com foco de atenção em
suas ações doravante.
Alô @Antonio M. Moreiras <moreiras at nic.br>.
@andredias at hexanetworks.com.br e @Damito
O Lance das "liberações ultra pontuais" (somente aquele único IP) que esses
caras fazem é provavelmente porque em algum momento essa implementação foi
feita por alguém(que não está mais alcançável), e a galera da equipe está
com medo de por a mão nas configurações da caixa que está sem suporte.
De fato, se as atualizações das caixas de firewall estivessem em dia, uma
Lista branca de Países(baseado em geolocalização) é algo realmente efetivo
para ajudar a proteger a integridade das informações dos usuários.
Mas com a desatualização de assinaturas e outras informações, isso acaba
virando nesse problema que estamos discutindo.
Eu mesmo já ajudei um amigo de um órgão público nessa mesma situação a
mudar de lista-branca(só Brasil) para lista-negra(tudo menos
EUA/China/Russia). O que acabou ajudando bem ele com esse problema.
Em qui, 29 de ago de 2019 às 17:52, Daniel Damito <
daniel.damito at sagenetworks.com.br> escreveu:
> Boa tarde, pessoal.
>
> Percebemos que diversos provedores atendidos por nós, sobretudo aos que
> possuem blocos de IPv4 no range 45.0.0.0/8, não conseguem acessar à alguns
> sistemas hospedados no AS28291 - Dep. de Informática do SUS - DATASUS.
>
> Sempre que entramos em contato com eles através do e-mail
> suporte.rede at saude.gov.br, explicamos que estamos representando um
> provedor
> de Internet com milhares de assinantes, e não apenas um usuário específico.
> Ainda assim, sempre recebemos uma resposta padrão pedindo dados que não
> fazem sentido para nós, operadores de rede, como CNS e CNES.
>
> Após muita insistência e desgastes com os assinantes, nós precisamos pedir
> a colaboração de algum assinante ou unidade de saúde para nos passar estes
> dados pedidos pelo CADSUS. Estes dados não são passados facilmente pelo
> assinante ou pelas unidades de saúde. Eles costumam achar que o problema
> está sendo causado pelo ISP e que pedir estes dados é uma burocratização
> proposital de nossa parte.
>
> Até que consigamos passar por todas estas etapas e resolver o problema, os
> provedores perdem alguns clientes que cancelam o contrato e ouvimos queixas
> de pessoas que são prejudicadas pela falta deste acesso. No final, a
> resposta é sempre a mesma: "O acesso ao site/sistema é permitido apenas a
> partir do Brasil". Ainda que tenhamos a geolocalização atualizada na
> Maxmind, cadastro no PeeringDB com nossa localização geográfica, alocação
> correta no nosso NIR (Nic.br), IRR e domínio .br, eles insistem que nossa
> geolocalização consta como errada para eles e precisam fazer uma correção
> manual recorrente, demorada e desgastante para os provedores.
>
>
> Sendo assim, eu gostaria de saber da parte de vocês se este problema
> acontece também com os provedores administrados por vocês e com outros ISPs
> conhecidos também. Caso sim, vocês têm alguma sugestão de como podemos
> fazer com que eles mantenham seus filtros de geolocalização atualizados,
> por gentileza?
>
>
> --
> *Daniel Damito *
> Network Specialist
>
> +55 (19) 98265-6429
> +55 (19) 3307-0529
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
--
Douglas Fernando Fischer
Engº de Controle e Automação
More information about the gter
mailing list