Segurança de dados na cloud: concretizar a responsabilidade partilhada

Um fornecedor de cloud opera parte do ambiente de segurança. A sua equipa continua a ter de determinar que proteções configura, se estas abrangem os dados e os serviços em utilização e como sabe que continuam a ser eficazes.

A segurança de dados na cloud protege a confidencialidade, a integridade e a disponibilidade ao longo do armazenamento, do processamento, da partilha e da recuperação. Inclui bases de dados e armazenamentos de objetos, mas também permissões de aplicações, exportações de SaaS, identidades de serviço, cópias de segurança e os portáteis ou sistemas de automatização que conseguem obter dados.

Na perspetiva de um CTO, a responsabilidade partilhada só se torna útil quando produz decisões de engenharia concretas: quem configura um controlo, quem o monitoriza, que evidência demonstra o seu funcionamento e quem atua quando falha. A declaração de segurança de um fornecedor não pode responder a estas perguntas pela sua implementação.

Estabelecer a fronteira antes de escolher controlos

Os ambientes cloud combinam infraestrutura, plataformas e aplicações fornecidas remotamente. A cloud pública utiliza geralmente infraestrutura operada pelo fornecedor que serve vários clientes; a cloud privada é dedicada a uma organização. Nenhum destes rótulos determina se os seus dados estão adequadamente protegidos. O isolamento, os percursos de acesso, a responsabilidade operacional e os mecanismos de recuperação importam mais do que o rótulo.

Comece por um serviço de negócio e rastreie as suas dependências. Identifique contas ou subscrições cloud, regiões, serviços, armazenamentos de dados, administradores e sistemas de implementação. Inclua os produtos SaaS utilizados pelo suporte, pelas finanças e pela engenharia: uma base de dados de produção pode estar rigorosamente controlada enquanto a respetiva exportação de clientes se encontra num espaço de trabalho amplamente partilhado.

O inventário deve responder a estas perguntas:

• Que informação é armazenada ou processada, e quem é responsável pela finalidade de negócio?
• Onde estão os registos primários, as réplicas, os registos de eventos, as exportações, as caches e as cópias de segurança?
• Que pessoas, cargas de trabalho, fornecedores e destinatários externos lhes podem aceder?
• Que contas, regiões e serviços estão aprovados, e como são descobertos os novos?
• Que requisitos de conservação, apagamento, disponibilidade e contratuais se aplicam?

A escalabilidade e o acesso remoto da cloud podem melhorar as operações, e os serviços geridos podem reduzir a manutenção da infraestrutura. Também facilitam a criação de recursos e cópias mais depressa do que os revisores os conseguem acompanhar. O custo da segurança inclui, por isso, a administração de identidades, a monitorização, a recolha de evidências, os testes de recuperação e a supervisão de fornecedores, e não apenas a fatura de armazenamento.

Classificar a informação onde ela realmente reside

Utilize um esquema de classificação gerível e ligado a ações. Por exemplo, as categorias pública, interna, confidencial e restrita podem determinar regras de partilha, revisões de acessos, registo de eventos e conservação. Defina que categoria abrange identificadores de clientes, segredos de autenticação, registos financeiros, código-fonte e informação pessoal sensível.

A descoberta automatizada pode ajudar a localizar conjuntos de dados esquecidos, mas valide os resultados com os responsáveis pelos dados. Um scanner pode não detetar arquivos comprimidos ou campos específicos de uma aplicação, ao passo que uma cadeia de teste inofensiva pode desencadear um falso positivo. Registe as localizações não analisadas e os limites da amostragem. Para um fluxo de descoberta mais completo, consulte descoberta de dados e privacidade.

Mapear a responsabilidade serviço a serviço

A fronteira de responsabilidade muda com o modelo de serviço e com a implementação do fornecedor. Trate o que se segue como um ponto de partida a confirmar face à documentação do serviço e aos contratos, e não como uma repartição universal.

Para cada proteção importante, registe o contributo do fornecedor, a configuração do cliente, o responsável operacional, o revisor e a fonte da evidência. Evite entradas como «cifragem: fornecedor». Em vez disso, escreva: «O fornecedor disponibiliza cifragem gerida; a equipa de plataforma seleciona a configuração das chaves; a segurança revê as permissões de decifragem; o responsável pelo serviço testa a recuperação.»

Inclua as identidades de serviço e a automatização de implementação a par dos utilizadores humanos. Um pipeline que cria recursos, altera políticas de acesso ou obtém segredos faz parte da fronteira de segurança. Os operadores de serviços geridos e os prestadores de suporte externos também precisam de responsabilidades explícitas, mesmo quando administram infraestrutura por sua conta.

Identifique as falhas nas passagens de testemunho. Se o fornecedor comunicar uma credencial comprometida, quem recebe o aviso fora do horário de trabalho? Se uma base de dados ficar indisponível, quem decide se se restaura, se se faz a comutação para o sistema de reserva ou se se espera? Atribua um único responsável interno a cada resultado do lado do cliente, mesmo que várias equipas executem o trabalho.

Avaliar a garantia do fornecedor sem a sobrevalorizar

Reveja a documentação de segurança do serviço, as comunicações de incidentes, as modalidades de acesso de suporte, os subcontratantes ulteriores, o comportamento de apagamento, as opções de recuperação e os registos de auditoria disponíveis. Verifique se o nível de conta relevante inclui efetivamente as funcionalidades de que a sua arquitetura precisa.

Os documentos de garantia exigem uma revisão do âmbito. Um relatório SOC 2 é um relatório de atestação e não uma certificação. A certificação ISO 27001 diz respeito a um sistema de gestão da segurança da informação com âmbito definido e não prova que o seu tenant está configurado de forma segura. Verifique os serviços abrangidos, o período de reporte, as exceções e os controlos do cliente identificados no relatório.

Quando relevante, o catálogo C5 do BSI fornece critérios de garantia para a cloud. Distinga uma avaliação de Tipo 1, relativa à conceção e implementação num determinado momento, da cobertura de Tipo 2, relativa ao funcionamento ao longo de um período. Nenhuma delas substitui o teste dos seus próprios acessos e fluxos de dados.

Traduzir obrigações em requisitos técnicos

Determine a legislação aplicável e os compromissos com clientes antes de selecionar uma região ou de aceitar os termos do fornecedor. A aplicabilidade depende da informação, dos papéis no tratamento, do setor, das jurisdições e das relações de serviço. Um relatório ou certificado do fornecedor não demonstra a conformidade legal da sua organização.

Para os dados pessoais abrangidos pelo RGPD, o artigo 32.º exige uma segurança adequada ao risco; não é uma obrigação geral de cifrar todos os conjuntos de dados em todas as circunstâncias. Quando o fornecedor atua como subcontratante, avalie os requisitos contratuais do artigo 28.º. As disposições relativas a transferências internacionais exigem uma avaliação separada. A localização dos dados, por si só, não prova soberania nem conformidade com o RGPD, sobretudo quando o acesso de suporte ou os subcontratantes ulteriores criam percursos de acesso adicionais.

Como recomendação prática, traduza cada requisito aplicável numa afirmação testável: regiões de tratamento permitidas, destinatários aprovados, prazos de conservação, restrições de acesso, objetivos de recuperação ou passagens de testemunho para a notificação de incidentes. Peça aos especialistas jurídicos e de privacidade que confirmem a interpretação, enquanto a engenharia estabelece como o requisito será implementado e evidenciado.

Verificar o acesso efetivo e não apenas as permissões pretendidas

Credenciais roubadas, privilégios excessivos, partilha pública e utilização abusiva por pessoas internas são vias comuns de exposição de dados na cloud. Um armazenamento cifrado pode, ainda assim, divulgar registos através de uma conta autorizada ou de uma aplicação que devolve os dados do cliente errado.

Federe as identidades humanas sempre que possível, para que os processos de entrada, mudança e saída de pessoas cheguem aos serviços cloud. Exija autenticação forte para o acesso privilegiado, privilegie a MFA resistente a phishing quando suportada e separe o trabalho de rotina da administração. O acesso de emergência precisa de credenciais controladas, utilização monitorizada e um processo de recuperação testado; não deve tornar-se uma via de contorno permanente.

Para as identidades de cargas de trabalho, prefira credenciais de âmbito restrito e de curta duração quando suportadas. Reveja as relações de confiança: que carga de trabalho pode assumir uma função, em que condições e em que ambiente? Remova segredos embutidos em repositórios e artefactos de implementação, e restrinja o acesso ao próprio serviço de segredos.

Avalie as permissões efetivas através das políticas de identidade, das políticas de recursos, da assunção de funções, da pertença a grupos, das ligações de partilha e das restrições ao nível da organização. «Só de leitura» pode, ainda assim, permitir a extração em grande escala de informação sensível. Uma função que não consegue ler registos, mas consegue alterar a aplicação ou a política de chaves, pode obter acesso de forma indireta.

A evidência de revisão de acessos deve identificar o principal, o recurso, as ações permitidas, a justificação de negócio, o aprovador e a data de remoção, quando aplicável. Teste a saída de pessoas e os acessos temporários expirados, em vez de confiar exclusivamente num procedimento escrito.

Analisar em conjunto a exposição e o comportamento das aplicações

As configurações incorretas combinam frequentemente várias definições individualmente plausíveis. Num armazenamento de objetos, a cifragem por defeito não responde a quem pode ler os objetos nem se uma política de partilha os torna públicos. Examine em conjunto a identidade, as políticas de recursos, o comportamento da aplicação e a monitorização.

Verifique as restrições de acesso público, a entrada de rede, os listeners de bases de dados, a confiança entre contas, o comportamento das ligações assinadas e a partilha externa. Os endpoints privados podem reduzir a exposição, mas não corrigem privilégios excessivos nem uma aplicação vulnerável. Separe os ambientes e restrinja o acesso à produção a partir dos sistemas de desenvolvimento.

As APIs cloud precisam de autenticação e autorização ao nível do objeto e da ação. Um token de utilizador válido não pode permitir a alguém obter os registos de outro tenant alterando um identificador. Teste os endpoints de exportação, as operações administrativas, as consultas em massa e os handlers de carregamento. Os limites de taxa podem reduzir abusos, mas não substituem a autorização.

Utilize a revisão de infraestrutura como código e verificações de políticas para impedir definições inseguras conhecidas e, depois, compare as regras aprovadas com a configuração implementada. Alterações na consola, migrações e correções de emergência podem criar desvios. Registe porque existem exceções, os seus controlos compensatórios e quando expiram. A modelação de ameaças pode ajudar a identificar, antes da implementação, percursos de uma interface exposta até dados sensíveis.

Tratar a cifragem e o acesso às chaves como controlos separados

Proteja os dados em trânsito com protocolos autenticados modernos e uma validação de certificados adequada. Reveja as ligações internas entre aplicações, bem como os endpoints públicos. Para os dados armazenados, determine que serviços, réplicas, exportações, snapshots e cópias de segurança estão cifrados e com que modalidades de chaves.

As chaves geridas pelo fornecedor e as chaves geridas pelo cliente suportam escolhas operacionais diferentes. Selecione com base no modelo de ameaças, nos requisitos contratuais, na separação administrativa e nas necessidades de recuperação. Uma chave gerida pelo cliente não é automaticamente mais segura se o mesmo administrador sem restrições controlar tanto o acesso aos dados como as permissões das chaves.

Documente quem pode cifrar, decifrar, administrar, desativar e eliminar chaves. Reveja as alterações às políticas de chaves e a atividade de decifragem invulgar. Estabeleça processos de rotação, revogação, conservação e recuperação; rodar uma chave não implica necessariamente voltar a cifrar todas as cópias existentes, consoante o serviço.

Os serviços KMS e HSM podem apoiar a proteção das chaves e as operações criptográficas, mas não eliminam as responsabilidades de ciclo de vida. Teste as consequências da indisponibilidade de uma chave antes de aplicar um processo de eliminação ou de revogação. Uma cópia de segurança protegida é inutilizável se a chave necessária não puder ser recuperada. Consulte cifragem e gestão de chaves para as decisões criptográficas de suporte.

Monitorizar a atividade sobre os dados e preservar a capacidade de resposta

O registo de eventos tem de abranger as perguntas a que as equipas de resposta precisam de responder. Os eventos de auditoria administrativa podem mostrar quem alterou uma política sem mostrar quem descarregou um conjunto de dados. Determine onde está disponível o registo de acessos aos dados, se está ativado e que eventos ou serviços permanecem fora da cobertura.

Recolha os eventos relevantes de identidade, do plano de controlo, de acesso aos dados, das aplicações, da gestão de chaves e da partilha. Preserve os identificadores de contas e recursos, a identidade do agente, os registos temporais, as ações e os resultados. Proteja os registos contra alteração e eliminação não autorizada. Evite colocar conteúdos sensíveis ou credenciais reutilizáveis nos registos; os dados de diagnóstico podem tornar-se outra fonte de exposição.

Dê prioridade a cenários de deteção como:

• Um armazenamento restrito que se torna acessível ao público.
• Uma nova relação de confiança externa ou a atribuição de uma função privilegiada.
• Exportações em massa invulgares ou acesso por uma identidade inativa.
• A desativação do registo de eventos ou a alteração do seu destino.
• A eliminação de cópias de segurança ou alterações à administração de chaves.

Defina quem responde e teste os alertas através de um exercício controlado. Uma regra que dispara para uma caixa de correio sem vigilância não é um processo de deteção eficaz. Registe as falhas de recolha, a ingestão atrasada, os recursos recém-criados e as limitações do fornecedor, em vez de apresentar um painel como cobertura completa.

Durante um incidente, preserve a evidência relevante e coordene a contenção entre identidades, aplicações e armazenamento. Revogar um token pode não terminar outras sessões nem parar uma exportação já em curso. Para violações de dados pessoais ao abrigo do RGPD, os subcontratantes notificam os responsáveis pelo tratamento sem demora injustificada. Os responsáveis pelo tratamento notificam a autoridade de controlo sem demora injustificada e, sempre que possível, até 72 horas após terem tido conhecimento, a menos que a violação não seja suscetível de resultar num risco para os direitos e liberdades das pessoas. As violações de risco elevado exigem também a comunicação às pessoas afetadas sem demora injustificada, sem prejuízo das exceções do artigo 34.º. Preserve a fundamentação da notificação ou da não notificação.

Utilizar as ferramentas de segurança para perguntas definidas

As ferramentas de segurança na cloud são mais úteis quando o seu âmbito e a finalidade de decisão são claros:

Comece a aplicação de DLP com testes representativos e a revisão pelos responsáveis pelos dados. Uma regra que bloqueia trabalho legítimo de suporte pode levar os utilizadores a soluções alternativas não controladas. Restrinja os scanners e os agentes de monitorização ao acesso de que precisam; uma ferramenta de descoberta com amplo acesso de leitura torna-se ela própria um componente sensível.

A automatização pode reduzir verificações repetitivas e a recolha de evidências. Não consegue demonstrar que um serviço não suportado é seguro nem que uma interpretação jurídica está correta. Mantenha explícita a revisão humana das conclusões e exceções materiais.

Provar a recuperação independentemente do estado das cópias de segurança

As cópias de segurança só respondem à perda e à corrupção se puderem ser restauradas dentro das necessidades do serviço. Estabeleça com o responsável de negócio os objetivos de ponto de recuperação para a perda de dados tolerável e os objetivos de tempo de recuperação para a interrupção tolerável.

Distinga replicação, controlo de versões, snapshots e cópias de segurança. A replicação pode copiar a corrupção ou o apagamento. Os snapshots podem continuar vulneráveis ao mesmo administrador que controla a produção. Selecione cópias protegidas e uma separação administrativa adequadas ao modelo de ameaças, incluindo resistência ao apagamento quando suportada.

Restaure uma carga de trabalho representativa num ambiente isolado. Verifique a consistência dos dados, as dependências da aplicação, a configuração de identidades, a disponibilidade das chaves e o tempo de recuperação decorrido. A restauração da base de dados, por si só, não demonstra que o serviço de negócio funciona. Registe as falhas e volte a testar após a remediação.

Avalie a recuperação de SaaS separadamente. A recuperação de desastres do fornecedor pode restaurar a plataforma sem reverter o apagamento acidental no seu tenant. Determine a granularidade de restauração disponível, as janelas de conservação, as opções de exportação e quem é responsável por iniciar a recuperação. Aplique também às cópias de segurança as regras de classificação e de conservação.

Exemplo prático: um serviço de exportação para clientes

Considere uma equipa SaaS ilustrativa que utiliza uma base de dados gerida, um armazenamento de objetos para exportações e um processo de trabalho em segundo plano. Suponha que as exportações contêm informação de contacto confidencial de clientes, que os clientes acedem apenas às suas próprias exportações e que os objetivos de recuperação acordados são quatro horas de perda de dados e oito horas de interrupção. Trata-se de pressupostos de exemplo e não de metas universais recomendadas.

O fornecedor opera a infraestrutura gerida. A equipa de plataforma configura as restrições de rede, as identidades, a cifragem e o registo de eventos. Os engenheiros da aplicação são responsáveis pela autorização por tenant e pelo comportamento das ligações de exportação. O responsável pelo serviço aprova a conservação e os objetivos de recuperação; a segurança revê os acessos e as evidências.

O processo de trabalho recebe permissão para ler os registos necessários da base de dados e escrever as exportações no armazenamento designado. Não precisa de permissão para alterar a política de armazenamento nem para eliminar cópias de segurança. As transferências passam pela autorização por tenant; quaisquer ligações temporárias têm validade limitada e são tratadas como credenciais ao portador. Os ficheiros de exportação expiram de acordo com a regra de conservação aprovada.

Os testes incluem um pedido de objeto não autenticado, um cliente a tentar obter a exportação de outro cliente e o processo de trabalho a tentar uma ação administrativa proibida. Os revisores verificam também que o acesso público está bloqueado e que as transferências de teste produzem os eventos de auditoria esperados.

Um exercício de restauração verifica a base de dados e as dependências da aplicação face aos objetivos de recuperação assumidos. As evidências incluem exportações de configuração, resultados dos testes de autorização, eventos de acesso amostrados e o registo da restauração. Se faltar o registo de acessos aos dados numa região, a revisão regista essa lacuna e atribui a remediação; testes bem-sucedidos noutros locais não a encerram.

Preservar o âmbito, as exceções e as decisões de revisão

A evidência deve identificar a conta, o recurso, o momento, o método de recolha e o revisor. Uma exportação de configuração de uma conta não pode demonstrar a postura de todas as contas. Compare os recursos recolhidos com o inventário e registe as recolhas falhadas ou as localizações inacessíveis.

Mantenha um conjunto compacto de evidências para cada serviço: o seu mapa de responsabilidades, a linha de base aprovada, as verificações de configuração atuais, a revisão dos acessos efetivos, a cobertura do registo de eventos, os resultados de recuperação e as exceções em aberto. Cada exceção precisa de um responsável, de uma fundamentação do risco, de controlos compensatórios, de aprovação, de uma data de expiração e de uma condição de novo teste.

Utilize revisões programadas a par de gatilhos baseados em eventos. Alterações materiais de implementação, novas regiões, mudanças de fornecedores, incidentes, classificações de dados alteradas e novos percursos de partilha devem desencadear uma reavaliação. O NIST Cybersecurity Framework fornece uma referência útil de organização através das funções Govern, Identify, Protect, Detect, Respond e Recover; é uma orientação e não prova de que uma implementação cumpre as suas obrigações.

A Secani pode ligar este trabalho a requisitos, objetos-alvo, evidências, responsáveis, tarefas e decisões de revisão. Modele o serviço cloud e as suas dependências, associe as exportações de configuração e os registos de testes aos controlos que sustentam e transforme a cobertura em falta em trabalho atribuído. Mantenha explícitas a aprovação humana e a rastreabilidade das fontes. As ferramentas de segurança na cloud continuam a ser a fonte da configuração técnica e dos alertas; o espaço de trabalho de conformidade preserva o seu âmbito e as ações que sustentam.

Para a próxima revisão de engenharia, selecione um fluxo de dados sensíveis. Rastreie cada cópia e cada percurso de acesso, atribua as responsabilidades do lado do cliente, teste as permissões efetivas e restaure uma carga de trabalho representativa. Alargue o âmbito quando essa revisão produzir evidência fiável e um processo repetível.