Contratar uma plataforma de nuvem não encerra as decisões sobre segurança, disponibilidade e controle dos sistemas. A organização continua definindo quem acessa suas informações, como utiliza os serviços e quais evidências precisa manter para acompanhar operações e apurar ocorrências.
Um provedor pode oferecer infraestrutura robusta, enquanto uma configuração específica do cliente permite compartilhamentos inadequados ou impede a recuperação de registros importantes. A avaliação precisa considerar o ambiente efetivamente utilizado, suas integrações e as responsabilidades de quem o administra.
A Auditoria de Sistemas em nuvem examina essa relação entre necessidades, recursos contratados, configurações e operação. Seu propósito é identificar fragilidades e avaliar controles com base em evidências, dentro de um escopo definido.
A responsabilidade depende do serviço contratado
Os modelos de serviço ajudam a compreender a distribuição das atividades. Em IaaS, infraestrutura como serviço, o cliente normalmente administra sistemas operacionais e aplicações sobre recursos disponibilizados pelo provedor. Em PaaS, plataforma como serviço, parte dessa administração é assumida pela plataforma. Em SaaS, software como serviço, o cliente utiliza uma aplicação pronta, mantendo decisões sobre seu uso e as configurações disponíveis.
A Microsoft descreve essa distribuição e destaca responsabilidades do cliente sobre dados, identidades e componentes sob seu controle. A classificação do serviço orienta a análise, mas deve ser confrontada com suas características concretas. Microsoft — Responsabilidade compartilhada na nuvem.
A AWS também distingue a proteção da infraestrutura que sustenta a nuvem das atividades que cabem ao cliente no uso dos serviços. Ressalta que a distribuição varia conforme os serviços selecionados. AWS — Modelo de responsabilidade compartilhada.
Na prática da auditoria, uma pergunta deve acompanhar cada controle: quem o configura, quem acompanha seu funcionamento e quem atua quando ele falha? Se houver uma empresa contratada para administrar o ambiente, sua participação precisa estar identificada junto às atribuições da equipe interna e do provedor.
O escopo começa pelo ambiente real
Antes de examinar configurações, é necessário delimitar quais serviços sustentam os processos avaliados. O inventário deve permitir relacionar contas, assinaturas, ambientes, aplicações e dados aos respectivos responsáveis.
Essa etapa pode revelar recursos de testes ainda ativos, serviços contratados por áreas distintas ou integrações ausentes da documentação principal. Cada ocorrência deve ser analisada conforme seu uso e sua relevância, evitando tratar todos os recursos como igualmente críticos.
Para orientar o levantamento, convém esclarecer:
- Quais processos dependem dos serviços incluídos na avaliação.
- Onde estão os dados e por quais integrações eles transitam.
- Quem administra o ambiente e aprova alterações.
- Quais serviços dependem de infraestrutura local ou de outros fornecedores.
- Quais requisitos de acesso, disponibilidade e recuperação foram definidos.
O resultado esperado é um escopo rastreável, que permita compreender o que foi examinado e quais dependências permaneceram fora da avaliação.
Configurações devem ser relacionadas ao uso
Uma configuração precisa ser avaliada diante da finalidade do recurso. Um repositório público pode ser adequado para materiais de divulgação e inadequado para documentos internos. A simples identificação de acesso externo não permite concluir, isoladamente, que existe uma irregularidade.
A análise deve confrontar a exposição observada com a classificação da informação, a autorização existente e os mecanismos de acompanhamento. Também importa verificar se a configuração aprovada permanece válida após mudanças no conteúdo ou na finalidade do serviço.
Entre as verificações possíveis estão permissões administrativas, compartilhamentos, segregação entre produção e testes, proteção de credenciais de integração e tratamento de exceções. Esses exames precisam considerar permissões efetivas, incluindo aquelas obtidas por grupos ou por aplicações conectadas.
Relatórios automáticos de postura de segurança ajudam a selecionar pontos de atenção. Seus resultados exigem interpretação: a pontuação de uma ferramenta não substitui a análise do impacto sobre o processo sustentado pelo sistema.
Evidências: o que foi registrado e por quanto tempo?
Na nuvem, parte relevante da observação depende dos registros disponibilizados pelos serviços. Por isso, a auditoria deve identificar quais eventos são coletados, quais recursos estão abrangidos e se o período disponível atende à necessidade de análise.
Um exemplo mostra por que essa verificação precisa ser específica. O histórico de eventos do AWS CloudTrail apresenta os últimos 90 dias de eventos de gerenciamento por região, mas não inclui eventos de dados. A existência desse histórico, portanto, não demonstra que todas as operações sobre o conteúdo armazenado estejam registradas. AWS — Histórico de eventos do CloudTrail.
A avaliação pode incluir a exportação de amostras, a identificação da origem e do horário dos eventos e a comparação entre operações conhecidas e registros encontrados. Capturas de tela podem complementar o trabalho, mas precisam de contexto: recurso, conta, momento da consulta e filtros utilizados.
Quando os registros são insuficientes, a conclusão deve explicitar a limitação. A ausência de evidência de uma operação não equivale, automaticamente, à demonstração de que ela não ocorreu.
Exemplo: compartilhamento e lacuna de rastreabilidade
Considere uma situação hipotética: uma equipe cria um repositório para trocar documentos com um fornecedor. O acesso é autorizado durante o projeto, mas não há responsável definido para revisar as permissões após seu encerramento.
Meses depois, a auditoria identifica que o compartilhamento continua ativo e que novos documentos internos foram adicionados ao mesmo local. Os registros disponíveis permitem verificar a configuração atual, mas não esclarecer todos os acessos ao conteúdo durante o período anterior.
Nesse caso, há duas questões distintas. A primeira é a permanência do acesso além da finalidade inicialmente aprovada. A segunda é a limitação das evidências para reconstruir o uso desse acesso.
A constatação deve separar o que foi comprovado do que permanece incerto. As recomendações podem abranger a revisão das permissões, a definição de responsáveis e a adequação da coleta e retenção dos eventos relevantes. Não seria tecnicamente correto afirmar que houve extração de documentos sem evidências que sustentem essa conclusão.
Disponibilidade, recuperação e dependência do fornecedor
A auditoria também precisa relacionar as características contratadas às necessidades operacionais. Convém verificar como a organização detecta interrupções, aciona suporte, recupera informações e valida o retorno de suas atividades.
Uma pergunta útil é o que aconteceria se o serviço permanecesse operacional, mas a organização perdesse o acesso administrativo. Esse cenário direciona a análise para dependências de identidade, responsáveis alternativos e procedimentos de recuperação de acesso.
Outro ponto é a possibilidade de saída do serviço. A avaliação pode examinar se os dados necessários são exportáveis, se o formato é utilizável e se a exportação preserva os elementos indispensáveis ao processo. A existência de um botão de download não comprova, por si só, a viabilidade de uma migração.
Essas verificações devem ser proporcionais ao risco e realizadas por procedimentos autorizados, com cuidado para não interferir na operação.
Referências e documentação do provedor
A Cloud Security Alliance oferece a Cloud Controls Matrix e orientações de auditoria para organizar avaliações de controles em nuvem. Essas referências podem ajudar a estruturar critérios e procedimentos, observadas a versão e a aplicabilidade ao escopo. CSA — Orientações de auditoria da CCM.
Certificações e relatórios do provedor também devem ser lidos em seu contexto. A análise precisa identificar os serviços abrangidos, o período examinado, as limitações e os controles que dependem do cliente. Uma avaliação da infraestrutura do fornecedor não demonstra, automaticamente, a adequação das permissões e configurações de uma organização específica.
O que o resultado deve oferecer à gestão
Um relatório útil relaciona cada constatação ao recurso examinado, ao critério utilizado, à evidência e ao possível impacto. Também distingue falhas observadas, limitações de informação e melhorias propostas.
As prioridades devem considerar a criticidade do processo e a extensão da exposição. Recomendações precisam indicar ações verificáveis, como revisar determinado conjunto de permissões, ampliar a cobertura de registros ou testar um procedimento de recuperação.
A Auditoria de Sistemas em nuvem contribui, assim, para avaliar se o ambiente contratado e administrado oferece condições compatíveis com as necessidades da organização, deixando claras as bases e os limites dessa conclusão.
Auditoria de Sistemas na IBPTECH
A avaliação de ambientes em nuvem integra o campo da Auditoria de Sistemas, uma das áreas de atuação da IBPTECH. Este portal é dedicado à Divisão de Auditoria de Sistemas e apresenta conteúdos e serviços relacionados a esse domínio.
Conheça os serviços da Divisão de Auditoria de Sistemas para discutir o escopo de avaliação dos serviços, controles e evidências do seu ambiente.