Cases e Blog

O problema

Uma empresa de saúde com 500 colaboradores operava sobre servidores on-premise defasados. O risco não era só de performance: o ambiente já não conseguia cumprir os requisitos de segurança da informação exigidos pelos órgãos reguladores do setor e pela LGPD.

Havia duas pressões ao mesmo tempo. Uma técnica: o parque precisava ser renovado. E outra regulatória: a conformidade não podia esperar. A pergunta que a empresa não conseguia responder era: quanto custa, de fato, cada caminho?

Como resolvemos

A Altvia começou pelo que sustenta qualquer decisão de infraestrutura: números. Levantamos todos os custos envolvidos em regularizar a situação no modelo atual e comparamos com os cenários alternativos. A recomendação técnica foi uma infraestrutura híbrida, com predominância em nuvem, o desenho que melhor acompanhava a visão de futuro das soluções tecnológicas da empresa.

O estudo, porém, foi detalhado o suficiente para que a empresa enxergasse mais longe do que a própria recomendação. Com clareza sobre custos, riscos e ganhos, a decisão foi migrar 100% para a nuvem. A jornada durou 4 meses e cobriu o ambiente inteiro, sem deixar pontas soltas:

• Sistemas web
• Aplicativos
• Sistemas legados
• Arquitetura cliente-servidor
• Integrações com sistemas externos

Antes de migrar, a equipe fez a pergunta que ouvimos em praticamente todo projeto de nuvem: "Como o sistema pode ficar mais rápido pela internet do que rodando aqui dentro, do lado do usuário? E a latência?" É uma dúvida legítima. E o resultado costuma surpreender.

O problema

Sexta-feira, véspera de feriado. O telefone tocou no início de um fim de semana prolongado. Do outro lado, um parceiro da Altvia: um cliente dele havia sido atingido por ransomware. Aplicações e bancos de dados, todos criptografados. A empresa não era cliente da Altvia.

Quando entramos no primeiro contato, a organização já havia montado uma war room. Fornecedores, times internos e diretoria estavam sendo acionados. Por ser vinculada a um órgão regulador próprio, a empresa também recebeu especialistas em cibersegurança e um red team enviados pela entidade. O quadro técnico era o pior possível:

• Toda a infraestrutura era on-premise e estava comprometida
• Não havia infraestrutura de contingência
• Não havia plano de Disaster Recovery
• O time forense determinou que 100% do ambiente precisava ser preservado para captura de evidências, perícia e tentativa de recuperação de dados

Ou seja: nada do que existia podia ser tocado. E a empresa precisava abrir na segunda-feira.

Como resolvemos

A Altvia entrou com seus especialistas em Segurança da Informação e Infraestrutura e propôs o único caminho compatível com as duas exigências, preservar o ambiente comprometido e voltar a operar: iniciar imediatamente a recuperação do desastre na nuvem da Altvia, construindo um ambiente novo em paralelo, sem interferir na cena que a perícia precisava analisar.

A operação foi governada pelo nosso time em conjunto com o cliente e os demais fornecedores, em regime contínuo ao longo do fim de semana.

O ponto de partida

Nem todo projeto de segurança começa com um problema. Este começou com uma empresa que já fazia muita coisa certa.

Em uma prospecção comercial, encontramos uma organização de saúde bem estruturada, com um time de TI experiente e competente. O plano diretor de TI da empresa estabelece uma política clara: priorizar soluções open source consolidadas no mercado enterprise, recorrendo a produtos licenciados apenas onde a análise técnica mostra que essa é a melhor escolha. E essa análise é feita com critério.

Não havia um incêndio para apagar. Havia uma pergunta legítima: onde ainda dá para evoluir?

Como resolvemos

O time de Segurança da Informação da Altvia realizou um levantamento sem custo, tomando como referência os controles da ISO 27001. O resultado foi uma lista objetiva de oportunidades de melhoria, classificadas por severidade: um mapa que permitiu à empresa enxergar suas lacunas com clareza e decidir onde investir primeiro.

O princípio que guiou a execução foi o respeito ao ritmo da organização. Segurança da informação não se resolve com um pacote de ferramentas instalado de uma vez. Ela evolui na medida em que a empresa consegue absorver: em processos, em tecnologia e, principalmente, em pessoas. Em menos de 6 meses, foram implementados:

• SIEM para monitoramento e correlação de eventos
• Campanhas de phishing para conscientização e medição de risco humano
• Gestão de senhas corporativa
• Aprimoramento dos controles de acesso
• Outras melhorias priorizadas pelo diagnóstico

Tudo isso mantendo a política de open source enterprise da empresa, que foi tratada como premissa do projeto, não como obstáculo.

O problema

Quando essa empresa chegou à Altvia, era uma startup com 30 clientes e um produto SaaS no mercado. Do ponto de vista de negócio, tudo estava no lugar: processos comerciais bem estruturados, marketing afiado e um time de tecnologia capaz. A limitação estava na arquitetura: a primeira versão da plataforma rodava em uma única máquina virtual, com aplicação e banco de dados no mesmo lugar.

É uma escolha comum e, no início, correta. O problema é que ela tem um teto. O crescimento veio rápido: ao longo do primeiro ano, a base saltou para 500 clientes, e ficou evidente que o modelo não caberia mais.

Como resolvemos

Com esforço do time de desenvolvimento da startup e apoio do time de DevSecOps da Altvia, a aplicação foi preparada para rodar em containers, com o banco de dados separado da camada de aplicação. Foi o primeiro passo estrutural. Mas não era o suficiente para o que vinha.

Em reunião com o CEO, a Altvia mapeou o potencial de crescimento do negócio para os anos seguintes e fez uma recomendação: migrar para Kubernetes. Na época, mesmo considerando um crescimento expressivo, a proposta parecia superdimensionada. Era mais arquitetura do que o momento exigia.

A Altvia aplicou condições comerciais para viabilizar o projeto, porque acreditávamos na tese de crescimento da empresa tanto quanto ela.

O problema

Uma indústria com operação em dois continentes enfrentava uma falha silenciosa na cadeia produtiva. Os produtos fabricados na unidade chinesa e nas fábricas de parceiros locais passavam por inspeção na origem. Mas os erros só apareciam quando a mercadoria chegava ao Brasil.

O intervalo entre a falha e a descoberta da falha era um oceano inteiro. Cada divergência identificada em solo brasileiro significava custo já incorrido: produção, embalagem, frete internacional, tempo. Nada disso volta atrás. E a decisão que restava era sempre entre duas opções ruins: absorver o problema ou refazer o ciclo.

Como resolvemos

Não existia produto de mercado desenhado para esse cenário. Então ele foi construído. Os engenheiros de software da Altvia trabalharam junto com os colaboradores da empresa, que conhecem o processo de inspeção na prática, para desenhar um sistema específico para a realidade das fábricas.

O projeto foi estruturado em escopo aberto: em vez de entregar uma solução fechada e encerrar o ciclo, nossos times de desenvolvimento evoluem a plataforma mensalmente, em cadência contínua com o time de produto do cliente. Isso importa porque processo industrial não é estático. A cada mês, o sistema aprende algo novo sobre a operação que ele automatiza.

O problema

Um cliente da Altvia mantém sua solução SaaS hospedada em nossa nuvem. Como a aplicação trata um volume considerável de dados pessoais, os clientes dele exigem continuamente certificações da hospedagem, e 100% dessas exigências são atendidas pela infraestrutura da Altvia. Mas a cobrança não parava aí: os clientes do nosso cliente também exigiam pentest com validade dentro do ano.

Dois problemas se acumulavam. O primeiro era o custo: pentest recorrente é caro. O segundo era mais grave: o pentest entregava uma lista de vulnerabilidades para corrigir em produção. Ou seja, o código vulnerável já estava no ar, já havia sido exposto, e a correção acontecia depois, sob pressão de prazo e com risco acumulado. O teste apontava o problema, mas não impedia que ele chegasse lá.

Como resolvemos

A orientação da Altvia foi direta: o pentest continua sendo válido e necessário, mas ele não pode ser a primeira linha de defesa. O que faltava era um mecanismo que impedisse código com vulnerabilidade severa de entrar em produção.

Implantamos SAST e DAST na pipeline do projeto: análise estática do código durante o desenvolvimento e análise dinâmica da aplicação em execução. Na primeira execução, foram identificadas mais de 200 vulnerabilidades, um número que não é alto para o porte da aplicação, mas 10 delas eram de severidade alta.

O passo decisivo veio em seguida: configuramos o bloqueio na pipeline. Sem aplicar as correções de segurança, o desenvolvedor não sobe a aplicação. Não é recomendação, é barreira.