Conversas sobre segurança de dados tendem a se dividir em três tópicos principais:

– Como podemos proteger os dados armazenados em nossa infraestrutura local ou em nuvem?
– Quais estratégias, ferramentas ou plataformas podem fazer backup e restaurar data de forma confiável?
– Quanto nos custaria perder todos esses dados e com que rapidez poderíamos recuperá-los?

Todas são conversas válidas e necessárias para organizações de tecnologia de todos os formatos e tamanhos. Ainda assim, a empresa média utiliza mais de 400 aplicativos SaaS. O mesmo relatório descobriu que 56% dos profissionais de TI não estão cientes de suas responsabilidades de backup de dados. Isso é alarmante, considerando que 84% dos entrevistados afirmaram que pelo menos 30% dos dados críticos de seus negócios estão em aplicativos SaaS.

Dados SaaS não são como dados locais ou em nuvem, pois você não tem propriedade sobre o ambiente operacional e tem muito menos propriedade dos dados em si. Devido a essas restrições, criar backups automatizados, armazená-los em ambientes seguros e ser o proprietário do processo de restauração é uma tarefa de engenharia muito mais complicada.

Essa inflexibilidade leva as organizações a desenvolver soluções alternativas e processos manuais para fazer backup de dados SaaS, deixando-os em ambientes muito menos seguros – uma pena, pois seus backups são quase tão valiosos para os atacantes quanto seus dados de produção. Organizações que tratam os dados SaaS com menos cuidado, mesmo diante do crescimento de dois dígitos no uso de aplicativos SaaS, estão entregando as chaves de seu reino de maneiras mais óbvias do que poderiam esperar. Com a ameaça de perda de dados à espreita, qual é o custo para seu negócio se você não agir rapidamente para construir um plano de recuperação de dados SaaS?

Os segredos valiosos escondidos à vista

Vamos ilustrar um cenário comum: Sua equipe tem uma única organização no GitHub onde toda sua equipe de engenharia colabora em projetos de desenvolvimento e implantação em vários repositórios privados.

Agora, vamos ajustar essa ilustração com uma adição menos comum: você tem backups de todos os seus dados do GitHub, que incluem não apenas o código em cada um desses repositórios, mas também metadados como revisões de solicitações de pull, problemas, gerenciamento de projetos e muito mais.

Neste caso, seus dados de backup do GitHub não conterão senhas ou informações de identificação pessoal (IIP) sobre seus funcionários, além do que eles já tornaram público em seus perfis no GitHub. Isso também não permitiria que um atacante se movimentasse lateralmente para seus servidores ou serviços de produção, pois ainda não encontraram seu vetor de ataque ou ponto de intrusão. Ainda assim, você não está a salvo – backups de todos os tipos contêm informações das quais os atacantes podem aprender, criando uma inferência de como seu ambiente de produção opera.

Cada backup inseguro e clone de seu código privado é muito valioso se o atacante tiver como único objetivo roubar propriedade intelectual (IP) ou vazar informações confidenciais sobre recursos futuros, parcerias ou atividades de fusões e aquisições para concorrentes ou para fraude financeira.

Seus arquivos de configuração de Infraestrutura como Código (IaC) e CI/CD também seriam de particular interesse, pois identificam a topologia de sua infraestrutura, expõem sua infraestrutura de teste e etapas de implantação e revelam todos os provedores de nuvem ou serviços de terceiros nos quais seus serviços de produção dependem. Esses arquivos de configuração dependem de segredos como senhas ou tokens de autenticação. Mesmo se você estiver usando uma ferramenta de gerenciamento de segredos para ofuscar o conteúdo real desses segredos para não ser versionado no GitHub, um atacante será capaz de identificar rapidamente onde procurar a seguir, seja Hashicorp Vault, AWS Secrets Manager, Cloud KMS ou uma das muitas alternativas.

Porque você também está fazendo backup de seus metadados nesta ilustração, uma implementação insegura deixa seus pedidos de pull e comentários de problemas, que você ocultou em seus repositórios privados do GitHub, disponíveis para um atacante explorar. Eles rapidamente aprenderão quem tem privilégios para aprovar e mesclar código em cada repositório e explorarão listas de verificação para implantação ou remediação para identificar vulnerabilidades.

Com essas informações, eles podem elaborar um ataque muito mais direcionado, seja diretamente contra sua infraestrutura ou usando métodos de engenharia social, como pretextagem, em funcionários que agora entendem ter privilégios de nível administrativo.

Por que os backups seguros – especialmente de dados SaaS – são mais críticos do que nunca?

Em resumo, os dados SaaS nunca foram tão críticos para as operações de sua organização hora a hora. Esteja você usando uma plataforma de colaboração de código como o GitHub, ferramentas de produtividade como o Jira ou mesmo aproveitando o Confluence como o provedor principal (e dependência) de uma marca inteira, você está preso a ambientes que não possui, com práticas de gerenciamento de dados que não pode controlar totalmente, apenas para manter as luzes acesas.

Os dados SaaS são exclusivamente vulneráveis porque, ao contrário dos dados locais, há dois interessados: seu provedor e você. Seu provedor pode ter perda de dados, como quando o GitLab perdeu 300 GB de dados do usuário em apenas alguns segundos quando um engenheiro sobrescreveu seu banco de dados de produção. Você poderia cometer um erro honesto, como deletar acidentalmente sua instância ou carregar um CSV que corrompe instantaneamente todos os aspectos de seus dados.

Conscientização é uma grande preocupação. Em um relatório de 2023 da AppOmni, 85% dos especialistas em TI e segurança cibernética que eles pesquisaram afirmaram que não há problema de segurança em torno dos dados SaaS. No entanto, 79% dessas mesmas pessoas admitiram que suas organizações identificaram pelo menos uma ameaça de segurança cibernética baseada em SaaS nos últimos 12 meses. Os incidentes mais comuns foram vulnerabilidades em permissões de usuários, exposição de dados, um ataque cibernético específico e erro humano.

Ao mesmo tempo, um relatório da Oracle e da empresa de análise ESG descobriu que apenas 7% dos diretores de segurança da informação (CISOs) afirmaram entender totalmente o Modelo de Responsabilidade Compartilhada, que coloca a responsabilidade da segurança dos dados no usuário, e não no provedor SaaS. 49% dos respondentes também afirmaram que a confusão em torno desse modelo resultou em perda de dados, acesso não autorizado aos dados e até sistemas comprometidos.

A resposta para qualquer temor sobre a segurança de dados de backup não é ignorar os backups completamente.

O que procurar em um provedor de backup de dados SaaS seguro

Ao explorar o cenário de plataformas que permitem fazer backup e restaurar dados desses aplicativos SaaS críticos, você deve validar cuidadosamente esses itens essenciais:

– Automatização: Nenhum backup seguro envolve processos manuais – o processo de backup deve criar automaticamente backups incrementais diários usando um algoritmo de delta ou diffing. Cada processo manual, como alavancar um script de backup open-source que não foi atualizado há anos, ou até mesmo uma tarefa simples como escrever um cron job para executar um script de backup todas as terças-feiras às 23:59, cria potenciais pontos de falha.

– Abrangência: O exemplo do GitHub é especialmente bom para ilustrar a diferença entre dados (seu código) e metadados (as conversas que seus engenheiros têm em torno do seu código), mas muitos aplicativos SaaS têm hierarquias de dados semelhantes. Se uma solução de backup não pode proteger todos os seus dados, então no caso de um desastre de perda de dados, você terá apenas um plano de recuperação pela metade e muito trabalho manual para se recuperar.

– Criptografia: Insista na criptografia AES-256 bits, em repouso e em trânsito, para todos os backups de dados SaaS. O provedor também deve suportar SSO para que você possa gerenciar usuários e seus privilégios usando um provedor de identidade centralizado.

– Conformidade de dados: Detalhes como relatórios SOC 2 Tipo 2, que detalham os controles de segurança de uma plataforma de backup, podem lhe dar garantias sobre o quão seriamente eles levam a proteção dos dados sensíveis em seus backups. Embora você não precise disso atualmente, recursos como residência de dados demonstram que eles projetaram uma infraestrutura sofisticada com as políticas corretas para várias regiões.

– Observabilidade: Você não pode controlar totalmente o que acontece com os dados de sua organização. O melhor que você pode fazer é saber exatamente quem, quando e o que foi acessado ou alterado em seus dados de backup assim que acontece. Um log de auditoria em tempo real o ajudará a detectar intrusões rapidamente e fazer a remediação correta antes que um ataque tenha tempo de violar seus dados.

As ameaças únicas aos dados SaaS estão se expandindo rapidamente. Até mesmo as ferramentas que pensamos estar projetadas para descobrir ineficiências ou automatizar o trabalho que preferiríamos não fazer, como agentes de IA de terceiros, podem ser incidentes massivos de perda de dados disfarçados – aqueles que certamente ouviremos nos meses e anos futuros.

Quando você dá a uma IA acesso de escrita às suas plataformas SaaS, ela pode corromper inocentemente todos os seus dados críticos à velocidade acelerada por GPU. Quando relatórios dessas situações começarem a surgir em massa, você ficará feliz por ter guardado seus dados SaaS onde ninguém – seja um atacante ou uma IA perdida – possa lê-los. Você ficará ainda mais feliz quando precisar deles com urgência.