Atestação C5: prepare as evidências de garantia na cloud

Um cliente de cloud quer saber que proteções o fornecedor opera e quais continuam a ser da sua própria responsabilidade. O Serviço Federal Alemão para a Segurança da Informação (BSI) publica o Cloud Computing Compliance Criteria Catalogue, C5, como base estruturada para examinar essa garantia. Para um CTO, a preparação significa tornar verificáveis a fronteira do serviço, a implementação dos controlos e os registos operacionais, e não apenas reunir políticas.

O C5 é um catálogo de critérios utilizado para atestação independente, não uma certificação ao estilo ISO. A documentação do BSI sobre o C5 é a referência principal. Comece por acordar com o auditor independente a edição aplicável, o objetivo de garantia e o âmbito do exame.

Defina exatamente que serviço o relatório vai abranger

Descreva o serviço de cloud, as localizações de operação, as fronteiras organizacionais e as dependências. Um relatório que abrange um serviço não abrange automaticamente todos os produtos sob a mesma marca. Identifique os componentes de produção, as interfaces de gestão, as operações de suporte e os serviços externos que podem afetar as afirmações de garantia.

A descrição do sistema deve permitir a alguém de fora compreender como os dados dos clientes entram no serviço, circulam nele e saem dele. Inclua os percursos de administração, os processos de implementação, a monitorização de segurança, as cópias de segurança e a divisão de responsabilidades entre equipas. Explique as características do serviço e as condições de funcionamento relevantes, em vez de substituir a narrativa por diagramas de arquitetura.

Resolva estas questões de âmbito antes de recolher evidências:

• Que produtos, regiões e ambientes estão incluídos?
• Que equipas administram a produção ou podem aceder a informação dos clientes?
• Que fornecedores subjacentes suportam o serviço e como são tratados os seus controlos?
• Que configurações e tarefas de segurança ficam a cargo dos clientes?
• Que alterações materiais ocorreram, ou estão planeadas, durante o período de exame?

Dê às exclusões uma fundamentação explícita. Se uma implementação legada for excluída, assegure que as declarações dirigidas aos clientes não sugerem que está abrangida. O resultado é uma descrição do sistema versionada, sustentada por registos de arquitetura, dependências e responsabilidades.

Escolha o tipo de relatório antes de definir o calendário de evidências

A garantia C5 é geralmente expressa através de um relatório de atestação de um auditor. O Tipo 1 aborda o desenho e a implementação dos controlos num determinado momento. O Tipo 2 examina, além disso, a eficácia operacional ao longo de um período especificado.

O Tipo 1 pode ser um marco útil ao estabelecer um ambiente de controlo, mas não responde à mesma pergunta que o Tipo 2. Confirme o que os clientes exigem realmente antes de escolher um relatório intercalar.

Acorde com o auditor o período e as expectativas quanto às evidências. Não presuma uma duração de observação universal. Um procedimento redigido perto do fim de um período não consegue estabelecer que o controlo funcionou antes. Do mesmo modo, um teste atual bem-sucedido não apaga uma falha histórica.

Construa as evidências em torno da responsabilidade e da execução

Como método prático de preparação, construa um registo de evidências que ligue cada critério aplicável ao controlo implementado, ao responsável, à fronteira do serviço, à fonte das evidências, à frequência de revisão e às lacunas por resolver. Registe as decisões de aplicabilidade e a respetiva fundamentação; evite assinalar um critério como irrelevante só porque a implementação seria difícil.

Separe três perguntas: o que deve acontecer, o que está implementado e o que aconteceu de facto. Uma política responde à primeira. Os registos de configuração podem sustentar a segunda. Tickets, registos, aprovações e resultados de testes sustentam a terceira.

Estes são exemplos práticos, não uma lista de verificação C5 completa. Utilize o catálogo e o âmbito acordados para determinar a cobertura exigida, incluindo os controlos organizacionais, de pessoal, físicos e técnicos.

Torne as evidências reproduzíveis

Para cada exportação ou captura de ecrã, conserve o sistema de origem, a data de recolha, o período relevante, os filtros e quem a recolheu. Explique se representa a população completa ou um elemento selecionado. Os auditores precisam de compreender a população a partir da qual selecionam as amostras; uma pasta que contenha apenas exemplos bem-sucedidos não é suficiente.

Prefira registos que conservem o ator, a marca temporal, a ação e o resultado. Proteja as evidências contra alterações não autorizadas e evite expor desnecessariamente dados de clientes. Quando for necessário ocultar informação, preserve contexto suficiente para que o revisor compreenda o que o registo prova.

Separe os controlos herdados dos deveres que se mantêm

A garantia de um fornecedor de infraestrutura pode sustentar a segurança física ou os controlos da plataforma subjacente. Não estabelece que a autorização de tenants da sua aplicação funciona. Documente a dependência, o âmbito relevante do relatório, o período, as exceções e as responsabilidades que a sua equipa continua a ter de cumprir.

Os controlos complementares dos clientes também precisam de uma redação prática. “O cliente é responsável pela segurança” é demasiado amplo. Especifique tarefas como administrar os utilizadores do tenant, configurar a federação de identidades ou rever as políticas de acesso controladas pelo cliente. Mantenha estas responsabilidades coerentes entre a descrição do sistema, a documentação do serviço e os acordos contratuais.

Conduza a preparação como um programa de engenharia

Comece com uma avaliação de lacunas face aos critérios acordados. Distinga a implementação em falta das evidências em falta: exigem soluções diferentes. Uma revisão não documentada pode exigir melhores registos; uma revisão de acessos que nunca aconteceu exige um controlo operacional.

Atribua a cada lacuna um responsável, uma ação de correção, as dependências e uma data-alvo. Dê prioridade às questões que afetam a separação entre tenants, os acessos privilegiados, as alterações em produção, a resposta a incidentes e a recuperabilidade, de acordo com os riscos do serviço, e não apenas às tarefas de documentação mais fáceis.

Antes do período do Tipo 2, verifique se os controlos recorrentes têm calendários exequíveis e registos duradouros. Confirme quem os executa em caso de ausência ou rotação de pessoal. Para os controlos desencadeados por eventos, como a cessação de contas, assegure que a população que os desencadeia pode ser identificada.

Faça um percurso de verificação da preparação com evidências representativas. Siga uma alteração desde o pedido até à implementação, um administrador que sai até à revogação e um exercício de recuperação até à ação corretiva. Isto expõe passagens de testemunho falhadas que uma revisão de políticas pode não detetar.

Durante o exame, mantenha um registo de pedidos com responsáveis e estado de resposta. Mantenha os registos originais disponíveis, explique abertamente as discrepâncias e acompanhe a correção separadamente das evidências históricas. Não reescreva registos antigos para os fazer parecer conformes. É o auditor quem determina como as constatações afetam os testes e a opinião.

Exemplo prático: uma aplicação gerida sobre infraestrutura externa

Suponha, a título ilustrativo, que um fornecedor opera uma aplicação multi-tenant numa região, utiliza um fornecedor de infraestrutura externo e procura uma garantia de Tipo 2. A sua equipa controla os lançamentos da aplicação, as permissões dos tenants, a administração de produção e os procedimentos de recuperação.

A descrição do âmbito identifica a aplicação, a base de dados, o plano de gestão, as ferramentas de suporte e a dependência de infraestrutura. Explica que controlos subjacentes são herdados e quais continuam a cargo do fornecedor da aplicação.

Para o isolamento entre tenants, a equipa regista o desenho da autorização, os testes negativos automatizados, as constatações dos testes de segurança e as aprovações dos lançamentos. Conserva também registos de alterações que mostram quando a lógica de autorização mudou. O relatório da infraestrutura é uma evidência de suporte da dependência, não uma prova do isolamento da aplicação.

Para os acessos privilegiados, a equipa conserva a população de administradores, as aprovações de concessão, as decisões de revisão e os registos de remoção. Suponha que uma revisão descobre uma conta de suporte não utilizada. A equipa regista a descoberta, a revogação, a avaliação da exposição e a ação preventiva. Isso é mais credível do que submeter apenas a lista de contas já limpa.

Para a recuperação, conserva um resultado de teste de reposição que mostra o que foi recuperado, o tempo decorrido, as verificações de integridade dos dados e as limitações por resolver. Uma tarefa de backup configurada, por si só, não demonstra a recuperabilidade. Cada conjunto de evidências tem um responsável e um período definido, para que o auditor possa ligar os registos ao controlo em exame.

Reutilize o trabalho de garantia sem alegar equivalência

A ISO/IEC 27001 diz respeito a um sistema de gestão da segurança da informação com âmbito definido. O SOC 2 é um relatório de atestação com critérios e contexto de relato próprios. O C5 centra-se na garantia de serviços de cloud segundo o catálogo do BSI.

As avaliações de riscos, os controlos de acesso, os procedimentos de incidentes e os registos operacionais existentes podem apoiar mais do que um programa. Reutilize-os através de mapeamentos específicos de cada versão e âmbito e verifique depois as diferenças de requisitos ou de relato. Um controlo partilhado não é uma equivalência automática entre referenciais.

Escolha o portefólio de garantia a partir dos requisitos reais dos clientes e dos riscos do serviço. O C5 não é universalmente obrigatório para todos os fornecedores de cloud; os requisitos de concursos, contratuais ou setoriais aplicáveis precisam de uma análise separada. Nem um relatório C5 nem outro documento de garantia estabelecem, por si só, a conformidade com o RGPD ou com a NIS2.

Prepare o relatório para as decisões dos clientes

Os clientes precisam da descrição do sistema, da data ou do período, da opinião efetiva, das exceções e das fronteiras de responsabilidade, e não apenas do rótulo do relatório. Ao partilhar relatórios, respeite a confidencialidade contratual e forneça contexto para a avaliação do cliente.

Explique o estado das correções sem sugerir que as correções posteriores alteram a opinião histórica. Se o período do relatório for anterior a uma alteração arquitetural importante, identifique essa limitação. Acorde exames recorrentes em função das expectativas dos clientes e das alterações operacionais, em vez de tratar a atestação como uma credencial intemporal.

A Secani ajuda as equipas a ligar a implementação dos controlos e as evidências a requisitos revistos. Modele o serviço e as dependências, atribua responsáveis e revisores, associe os registos de suporte e transforme as lacunas de evidências em tarefas. Mantenha explícita a aprovação humana dos mapeamentos e das conclusões. O modelo de preparação para auditorias ajuda a preservar o âmbito e a responsabilidade subjacentes a cada afirmação.

Questões a resolver antes do primeiro exame

É o BSI que emite o relatório?

O BSI publica o catálogo. Um auditor independente realiza o exame e emite o relatório de atestação; confirme com esse auditor o referencial de garantia aplicável e as condições do trabalho.

E se não tiver ocorrido nenhum incidente real?

Não invente um registo de incidente. Conserve evidências de que o processo foi implementado e, quando adequado, exercitado. Acorde com o auditor a forma como a ausência de eventos afeta os testes.

O que deve a equipa fazer a seguir?

Escolha um serviço de produção representativo e prepare a respetiva descrição do âmbito, a matriz de responsabilidades e o registo de evidências. Reveja estes três resultados com o potencial auditor antes de reunir um grande pacote de evidências.