Segurança, identidade e conformidade na nuvem

A segurança na nuvem divide o trabalho entre o provedor e o cliente. Atribua tarefas conforme a camada que cada parte opera, incluindo as configurações escolhidas pelo cliente.

Separe a infraestrutura das escolhas do cliente

A AWS chama a proteção da infraestrutura de segurança da nuvem. Ela abrange instalações, servidores físicos, armazenamento, equipamentos de rede e o hipervisor que separa as máquinas virtuais em um host. Os clientes cuidam da segurança na nuvem: seus dados, identidades e configurações. Azure e Google Cloud usam a mesma divisão básica. A abordagem de destino compartilhado do Google acrescenta padrões seguros, orientações e ferramentas para ajudar os clientes a proteger sua parte.

Os provedores controlam a entrada física, a energia, a refrigeração, a manutenção do hardware e a retirada segura de unidades de armazenamento. Auditores independentes examinam essas camadas; os clientes usam seus relatórios para avaliar controles que não operam diretamente.

Mantenha as responsabilidades do cliente atribuídas

Em todos os modelos de serviço, o cliente mantém a responsabilidade por:

• Dados: classificação, acesso, decisões de proteção e retenção.
• Contas: criação, manutenção e remoção de identidades.
• Gerenciamento de acesso: funções, MFA e políticas de logon.
• Dispositivos clientes: proteção dos notebooks e celulares usados para se conectar.

As configurações escolhidas pelo cliente continuam sendo seu trabalho. Um bucket público, uma regra que expõe um banco de dados à internet ou uma conta de administrador abandonada podem expor uma carga de trabalho mesmo quando os controles de infraestrutura do provedor funcionam corretamente.

Alguns controles são compartilhados porque cada parte os executa em suas próprias camadas. O provedor aplica correções à infraestrutura; os clientes aplicam correções aos sistemas operacionais e aplicações que gerenciam. Cada parte configura seus próprios sistemas e treina sua própria equipe. Atribua as duas partes de um controle compartilhado para que nenhuma seja esquecida.

Aplique a divisão ao armazenamento de faturas

Uma empresa armazena faturas em um bucket na nuvem. O provedor aplica correções ao serviço de armazenamento, substitui unidades com falha e retira discos de uso com segurança. A empresa torna o bucket privado, concede à sua função de faturamento o acesso de leitura necessário e exige MFA desses usuários. Ela também seleciona as configurações de criptografia, ativa os registros de acesso necessários e escolhe por quanto tempo as faturas são mantidas.

Se um funcionário tornar o bucket público, o cliente deverá corrigir a permissão e investigar a exposição. O serviço de armazenamento pode retornar conteúdo legível a uma requisição permitida pelo cliente; a proteção física não pode desfazer essa concessão de acesso.

A infraestrutura em nuvem e as ferramentas especializadas de segurança podem dar a uma equipe pequena proteções que ela não conseguiria criar sozinha. Os recursos opcionais ainda precisam de um responsável por configurá-los e revisar seus resultados. Consulte as orientações de responsabilidade de cada serviço ao atribuir essas tarefas.

Serviços mais gerenciados transferem mais trabalho operacional para o provedor. As escolhas do cliente sobre identidades, dados e configurações continuam necessárias apesar dessas mudanças.

Compare as camadas

As responsabilidades por aplicações e rede podem ser compartilhadas em PaaS. Os clientes de SaaS configuram recursos da aplicação, embora o provedor opere o serviço; o gerenciamento de dispositivos também pode ser compartilhado. Consulte cada serviço e recurso para conhecer a divisão exata.

Analise os serviços

Para um servidor web no Amazon EC2, Azure Virtual Machines ou Google Compute Engine, o cliente instala atualizações de segurança do sistema operacional convidado e mantém o servidor web. Ele restringe a administração remota com grupos de segurança da AWS, grupos de segurança de rede do Azure ou regras de firewall do Google Cloud e escolhe a proteção de disco e as cópias de segurança.

Com Amazon RDS, Azure SQL Database ou Google Cloud SQL, o provedor mantém o sistema operacional subjacente e o mecanismo gerenciado. O cliente ainda seleciona os caminhos de rede permitidos, usuários, permissões, configurações de criptografia, retenção das cópias de segurança e janelas de manutenção disponíveis. A capacidade de fazer cópias de segurança automatizadas não decide por quanto tempo a empresa precisa de seus registros.

Para AWS Lambda, Azure Functions ou Google Cloud Run functions, ambientes de execução gerenciados pelo provedor retiram da lista do cliente a aplicação de correções aos servidores e ao ambiente de execução. Os clientes ainda atualizam as dependências incluídas, validam entradas, protegem segredos e restringem permissões de execução e invocação. Ambientes de execução personalizados ou contêineres trazem responsabilidades adicionais de manutenção.

No Microsoft 365 ou Google Workspace, o provedor aplica correções à aplicação de escritório. Os clientes removem funcionários que saíram, controlam o compartilhamento externo e definem a retenção. Algumas organizações também mantêm suas próprias cópias de segurança de SaaS.

Atribua uma tarefa desconhecida

Identifique a camada e o modelo de serviço e consulte a divisão documentada. Um disco físico com falha é responsabilidade do provedor em todos os modelos. Uma atualização do sistema operacional convidado de uma VM é trabalho do cliente; uma atualização do sistema operacional subjacente a um banco de dados gerenciado é trabalho do provedor. A permissão de um usuário do banco de dados continua sendo uma escolha do cliente. Mantenha uma lista de tarefas por serviço quando uma organização usar vários modelos em conjunto.

O acesso à nuvem começa pela identificação de uma pessoa ou aplicação. Em seguida, verifica as permissões dessa identidade. Manter essas decisões separadas ajuda a explicar por que um logon bem-sucedido ainda pode resultar em uma mensagem de acesso negado.

Comprove a identidade e verifique a permissão

A autenticação estabelece quem ou o que está fazendo uma requisição. A autorização decide se essa identidade pode executar a ação solicitada. A auditoria registra o que aconteceu. Uma senha mais MFA pode autenticar um usuário; uma função ainda pode negar a esse usuário permissão para excluir um banco de dados.

No Azure e no Google Cloud, atribuições de função vinculam pessoas, grupos ou cargas de trabalho a permissões. Na AWS, assumir uma função do IAM gera credenciais temporárias de sessão. Uma carga de trabalho deve usar esse mecanismo de identidade compatível em vez da senha de uma pessoa copiada para um arquivo de configuração.

Reconheça os nomes dos provedores

O AWS IAM fornece usuários, grupos e funções. O IAM Identity Center oferece acesso a funcionários em várias contas da AWS. O Microsoft Entra ID, anteriormente Azure Active Directory, é o diretório em nuvem do Azure, com usuários, grupos, entidades de serviço e identidades gerenciadas. O Google Cloud usa contas e grupos no Cloud Identity ou no Google Workspace, além de contas de serviço para cargas de trabalho.

Uma instância EC2 pode receber uma função do IAM, um recurso do Azure pode receber uma identidade gerenciada, e uma VM do Google Cloud pode receber uma conta de serviço associada. A plataforma fornece credenciais de curta duração para os acessos compatíveis, evitando uma senha de longa duração armazenada.

O usuário raiz da AWS tem controle sobre toda a conta. O Azure e o Google Cloud distribuem o acesso com privilégios elevados por meio de funções como Global Administrator do Entra, Owner da assinatura e Owner do projeto. Essas funções têm escopos diferentes: a função de administrador de diretório não é intercambiável com a de administrador de recursos.

Faça logon de forma centralizada

O logon único (SSO) permite que uma pessoa use um único logon em várias aplicações. A federação é a relação de confiança que permite a uma nuvem ou aplicação aceitar informações de identidade de outro provedor de identidade, geralmente por meio de SAML 2.0 ou OpenID Connect.

Uma empresa usa o Entra ID para 200 funcionários e federa o acesso à AWS e ao Google Cloud. Quando uma pessoa da equipe de engenharia sai, desativar a conta central impede novos logons. A empresa também deve revogar sessões ativas e remover contas locais independentes e chaves de acesso. Esses meios podem continuar funcionando sem um novo logon central.

Parceiros podem usar identidades externas: acesso de convidado do Entra B2B, uma função entre contas da AWS ou funções do Google Cloud concedidas a entidades externas. O empregador deles gerencia sua identidade de origem; sua organização controla o acesso deles aos seus recursos.

Aplicações antigas podem precisar de ingresso no domínio, Kerberos, NTLM ou LDAP. As ofertas de diretórios gerenciados incluem Entra Domain Services, AWS Directory Service e Google Cloud Managed Service for Microsoft Active Directory. Elas atendem a necessidades de aplicações diferentes das atendidas apenas por um logon moderno na nuvem.

Uma permissão relaciona uma ação a um recurso. “Ler objetos neste bucket” é mais preciso que “usar armazenamento”. Os provedores agrupam permissões em funções ou instruções de política e as associam a identidades ou recursos.

Associe quem, o quê e onde

O controle de acesso baseado em função (RBAC) atribui permissões por meio de funções de trabalho. Uma atribuição de função do Azure tem três partes: a entidade de segurança, a definição de função e o escopo. Os escopos vão de grupo de gerenciamento a assinatura, grupo de recursos e recurso individual. As atribuições são herdadas pelos recursos dentro de seu escopo.

Priya tem Reader na assinatura Prod e Contributor no grupo de recursos web-rg dessa assinatura. Ela pode visualizar recursos em toda a Prod e alterar recursos em web-rg. Ela não pode alterar db-rg nem conceder acesso a outra pessoa por meio de Contributor. As permissões do Azure são somadas entre atribuições; recursos compatíveis do Azure podem criar atribuições de negação que bloqueiam ações que seriam permitidas.

As políticas de permissão do Google Cloud vinculam entidades a funções nos recursos. O acesso é herdado pela organização, pastas, projetos e recursos. As funções básicas abrangentes Owner, Editor e Viewer devem dar lugar a funções predefinidas específicas de serviço ou personalizadas adequadas. Editar a política de permissão de um nível inferior não remove o acesso concedido no nível superior. Altere a concessão no nível superior ou aplique uma política de negação compatível quando apropriado.

Avalie uma requisição da AWS

Uma política do AWS IAM é um documento JSON com instruções que contêm um Effect, uma Action, um ARN de Resource e condições opcionais. Políticas podem ser associadas a identidades; uma política de recurso, como uma política de bucket, é associada ao recurso. As políticas gerenciadas pela AWS são mantidas pelo provedor, as políticas gerenciadas pelo cliente são documentos reutilizáveis do cliente, e as políticas em linha pertencem a uma identidade.

Para uma decisão básica sobre uma requisição:

1. Comece com a negação implícita: ainda não há permissão.
2. Encontre uma permissão explícita aplicável e verifique todos os limites de permissão aplicáveis.
3. Aplique qualquer negação explícita: ela prevalece sobre as permissões.

Uma política de controle de serviço (SCP) do AWS Organizations limita as permissões máximas disponíveis. Ela não concede permissões por si só. Uma requisição fora do limite permitido pela SCP falha mesmo quando uma política de identidade a permite.

O grupo de Lena pode ler sales-reports/*, e nenhum controle de proteção restringe essa leitura. Um download é permitido. Um upload falha porque não há permissão para s3:PutObject. Uma política separada nega explicitamente a exclusão; adicionar s3:* posteriormente ainda não permite autorizar a exclusão. A leitura de um bucket não relacionado também não tem permissão.

Separe o gerenciamento de recursos do acesso a dados

Um administrador pode gerenciar uma conta de armazenamento pelo plano de controle sem receber uma função de dados do Entra para ler seus blobs pelo plano de dados. Para essa leitura, é necessária uma função como Storage Blob Data Reader. Verifique a ação e o escopo em vez de presumir que um título com amplos privilégios de gerenciamento de recursos resolve todas as questões de acesso a dados.

O privilégio mínimo concede a uma identidade as ações, os recursos e o tempo necessários à sua tarefa. Ele reduz o raio de impacto: a quantidade de danos que um erro ou uma credencial roubada pode causar.

Crie uma concessão específica

Primeiro liste o trabalho, escolha uma função ou política restrita, defina o menor escopo útil e gerencie pessoas por meio de grupos ou funções. Limite a duração do acesso privilegiado e revise-o regularmente. Um prestador de serviços que envia registros para um bucket durante 30 dias precisa de acesso de envio nesse bucket, não de acesso de leitura a todo o armazenamento ou de uma identidade permanente de administrador.

O acesso just-in-time limita quando alguém pode obter permissões elevadas. O Entra Privileged Identity Management pode exigir aprovação e MFA para ativação por tempo limitado. O Google Privileged Access Manager fornece concessões temporárias de funções mediante solicitação. As funções da AWS emitem credenciais com prazo limitado por meio do Security Token Service, mas um direito permanente de assumir uma função de administrador permite novas sessões repetidas. Credenciais de curta duração, por si só, não eliminam o privilégio permanente.

A segregação de funções dá a pessoas diferentes o controle de partes sensíveis de um processo. Quem solicita uma mudança e quem a aprova devem ser pessoas diferentes; a administração de chaves e a leitura de dados também devem ser separadas.

Proteja identidades com privilégios elevados

Ative a MFA no usuário raiz da AWS, atribua a ele uma senha forte e exclusiva e não crie chaves de acesso raiz. Use-o apenas para tarefas que exijam o usuário raiz. Exemplos incluem alterar seu próprio e-mail ou senha, encerrar uma conta independente, recuperar o acesso após o bloqueio de um administrador do IAM, ativar o acesso do IAM ao faturamento, registrar-se como vendedor no EC2 Reserved Instance Marketplace e ativar a exclusão com MFA no S3. As organizações podem remover centralmente as credenciais raiz de contas-membro.

Mantenha as funções de alto privilégio do Entra e do Google Cloud rigorosamente limitadas. A Microsoft recomenda menos de cinco Global Administrators. Os administradores precisam de identidades separadas para uso diário e privilegiado e de MFA resistente a phishing. O planejamento de acesso de emergência do Entra usa duas contas de emergência armazenadas com segurança e monitoradas, para que uma falha no logon normal não impeça o acesso de todos; o projeto dessas contas segue as próprias orientações do provedor.

Prefira acesso de curta duração e segredos gerenciados

Chaves de acesso de longa duração permanecem utilizáveis até serem desativadas ou excluídas. Prefira identidades de cargas de trabalho, funções e SSO. Faça a rotação das chaves inevitáveis e mantenha-as fora do código-fonte. Se uma chave vazar, revogue seu acesso; excluir um trecho visível de código não revoga a credencial.

Armazene senhas de banco de dados, chaves de API e certificados no AWS Secrets Manager ou no Systems Manager Parameter Store, no Azure Key Vault ou no Google Cloud Secret Manager. As aplicações obtêm os segredos necessários durante a execução por meio de identidades de cargas de trabalho. Configure a coleta para auditoria quando necessário, como nas configurações de diagnóstico do Azure Key Vault.

Para as senhas ainda utilizadas, a orientação do NIST de 2025 exige pelo menos 15 caracteres para uso como fator único, ou pelo menos 8 como parte da MFA, e suporte a pelo menos 64 caracteres. Ela pede verificações contra senhas comuns e comprometidas, rejeita combinações obrigatórias de caracteres e alterações periódicas de rotina e exige a alteração após suspeita de comprometimento.

Use evidências para reduzir o acesso: AWS IAM Access Analyzer, relatórios de credenciais e dados de último acesso; revisões de acesso do Entra; e recomendações de funções do Google IAM. Se uma função permite 40 serviços, mas usou apenas 3 em 90 dias, revise as permissões dos outros 37 serviços. Verifique as próximas tarefas legítimas antes de removê-las; a inatividade identifica candidatas, não fornece um retrato completo das necessidades de negócio.

A autenticação multifator (MFA) exige pelo menos duas categorias diferentes de fatores: algo que a pessoa sabe, possui ou é. Uma senha e uma resposta de segurança são fatores de conhecimento e continuam sendo autenticação de fator único.

Compare métodos de autenticação

O NIST restringe o envio pela rede telefônica. Uma configuração comum de TOTP usa seis dígitos que mudam a cada 30 segundos: um milhão de valores possíveis dão a um único palpite aleatório uma chance em um milhão. As implementações podem usar outros comprimentos ou intervalos.

Uma página de phishing pode encaminhar uma senha e um código recente ao site real antes que expirem. A prova de uma chave de acesso vinculada ao domínio não pode ser reutilizada pelo domínio falso no serviço real. O Windows Hello for Business e métodos compatíveis baseados em certificado também oferecem opções resistentes a phishing.

Um ataque de fadiga de MFA envia solicitações push repetidamente na esperança de que alguém aceite. A correspondência de números vincula a aprovação a uma tela de logon, reduzindo a aceitação acidental; ela não oferece a mesma vinculação ao domínio de um método resistente a phishing.

Verifique os fatores no logon sem senha

O método sem senha elimina a senha. Uma credencial mantida em um dispositivo e desbloqueada por um PIN ou dado biométrico verificado combina posse com um segundo fator. O PIN é verificado localmente, não é enviado ao serviço. Verifique quais fatores o método usado realmente confirma antes de classificá-lo como MFA. O Google chama seu serviço de MFA de verificação em 2 etapas.

Os provedores exigem MFA para alguns acessos administrativos, incluindo o usuário raiz da AWS e o logon no portal do Azure. Os clientes ainda definem requisitos para seus próprios usuários e aplicações, com os métodos mais fortes para acesso privilegiado.

Aplique o contexto e proteja a recuperação

O Entra Conditional Access avalia o usuário, a aplicação, a integridade do dispositivo, a localização e o risco do logon. Ele pode permitir, exigir autenticação mais forte ou um dispositivo em conformidade, ou bloquear. Para a folha de pagamento, exija um dispositivo gerenciado e autenticação resistente a phishing; bloqueie logons de alto risco. As condições do AWS IAM e o acesso sensível ao contexto do Google oferecem controles relacionados, com comportamentos diferentes conforme o serviço.

Proteja a recuperação de conta com cuidado semelhante: um caminho fraco de recuperação pode substituir um autenticador forte. Recuse solicitações de aprovação inesperadas e comunique-as pelo processo da organização. O privilégio mínimo e o monitoramento ainda limitam o risco se uma sessão autenticada for roubada.

A criptografia transforma texto claro legível em texto cifrado usando uma chave. A chave correta permite decifrá-lo. Ela protege a confidencialidade; a criptografia autenticada também detecta alterações indevidas. Ela não impede uma exclusão autorizada nem mantém uma aplicação com falha em funcionamento.

Diferencie três transformações

Um texto em Base64 como “aGVsbG8=” pode ser decodificado como “hello” por qualquer pessoa. Ele não oferece confidencialidade. O armazenamento de senhas precisa de uma função de hash para senhas com um valor aleatório adicional, deliberadamente lenta, como Argon2, bcrypt, scrypt ou PBKDF2. Um único hash SHA-256 rápido é inadequado para essa tarefa.

A criptografia simétrica usa a mesma chave para criptografar e decifrar. AES-256 é comum para grandes volumes de dados na nuvem. A criptografia assimétrica usa um par de chaves pública e privada para operações como troca de chaves e assinaturas digitais; as operações compatíveis dependem do algoritmo. A criptografia com chave pública permite que quem envia proteja dados para um destinatário cuja chave privada os decifra. Uma assinatura digital permite que outras pessoas verifiquem uma assinatura feita com a chave privada.

Uma chave simétrica de 256 bits tem $2^{256}\approx \mathrm{1,16}\times {10}^{77}$ valores possíveis. Mesmo com ${10}^{18}$ tentativas por segundo, verificar todos leva cerca de $\mathrm{3,7}\times {10}^{51}$ anos. Na prática, proteger o acesso às chaves é muito mais importante do que planejar vencer esse espaço de busca.

Aplique criptografia aos dados armazenados

Dados em repouso incluem objetos, discos, bancos de dados, cópias de segurança e instantâneos. A criptografia protege o conteúdo bruto armazenado se alguém obtiver uma unidade ou copiar o armazenamento sem a chave necessária. A criptografia do lado do servidor ocorre dentro do serviço antes da gravação dos dados. A criptografia do lado do cliente ocorre antes do envio, deixando o provedor apenas com texto cifrado. Perder uma chave insubstituível do cliente torna o conteúdo ilegível.

As configurações padrão variam conforme o serviço. O Amazon S3 criptografa por padrão todos os novos objetos enviados desde 5 de janeiro de 2023. O Azure Storage criptografa dados armazenados, e isso não pode ser desativado. O Google Cloud criptografa por padrão os dados dos clientes em repouso. A criptografia padrão do Amazon EBS é uma configuração de conta ativada pelo cliente em cada região.

Acompanhe uma leitura permitida

Um objeto de fatura é criptografado no disco. Um usuário o solicita pelo serviço de armazenamento. O serviço verifica as permissões, decifra o objeto por meio do mecanismo de chave configurado e retorna conteúdo legível ao usuário autorizado. Se o cliente conceder leitura pública, esse processo também poderá atender a pessoas externas.

A criptografia em repouso, portanto, atua junto com configurações de acesso privado e registro de atividades. Comece com a classificação de dados: públicos, internos, confidenciais ou restritos. A classificação orienta quem pode ler o conteúdo, os requisitos de controle de chaves e a retenção. As cópias de segurança precisam da mesma atenção, pois um banco de dados protegido ainda pode ter uma cópia exposta.

Um registro pode estar criptografado no armazenamento e ainda ser exposto enquanto atravessa uma rede ou é processado. Acompanhe seu caminho para identificar onde cada proteção é necessária.

Criptografe dados em trânsito com TLS

Dados em trânsito trafegam entre navegadores, aplicações, bancos de dados, escritórios ou regiões. A segurança da camada de transporte (TLS) protege uma conexão contra leitura e alteração e autentica o servidor por meio de um certificado. HTTPS é HTTP transportado sobre TLS, geralmente na porta 443. Use configurações compatíveis de TLS 1.2 ou 1.3; SSL e TLS 1.0 e 1.1 estão obsoletos.

Um certificado digital associa um domínio a uma chave pública. Uma autoridade certificadora confiável o assina para que o navegador possa verificar a associação. Os serviços de certificados incluem AWS Certificate Manager, recursos de certificado do Azure Key Vault ou App Service e Google Cloud Certificate Manager. A renovação gerenciada reduz o risco de expiração quando disponível e configurada. Um certificado expirado pode interromper conexões e um serviço.

Uma conexão HTTPS válida confirma a proteção da conexão com aquele domínio. Um site de phishing também pode ter um certificado válido para seu próprio domínio, portanto, o cadeado sozinho não indica se aquela empresa ou página merece confiança.

Acompanhe uma requisição do navegador

1. O navegador estabelece uma conexão HTTPS com um balanceador de carga e verifica seu certificado.
2. O balanceador de carga termina essa conexão TLS e vê a requisição em texto claro.
3. Uma conexão TLS separada protege o trecho seguinte até um servidor da aplicação.
4. A aplicação usa uma conexão criptografada com o banco de dados, que está configurado para exigi-la.

O HTTPS na entrada protege apenas sua própria conexão. Verifique cada trecho posterior. Uma política do S3 pode negar requisições quando aws:SecureTransport é falso; o Azure Storage oferece uma configuração que exige transferência segura; o Cloud SQL pode exigir TLS. Redes internas também precisam de proteção de tráfego, pois um invasor pode já ter chegado a elas.

Separe um caminho privado da criptografia

Uma VPN IPsec entre sites criptografa o tráfego entre uma rede de escritório e uma rede de nuvem pela internet. Os serviços incluem AWS Site-to-Site VPN, Azure VPN Gateway e Google Cloud VPN.

Conexões dedicadas, como AWS Direct Connect, Azure ExpressRoute e Google Cloud Interconnect, não passam pela internet pública, mas seu caminho privado, por si só, não fornece criptografia de ponta a ponta por padrão. Use proteção TLS, IPsec ou MACsec compatível, conforme necessário. O MACsec protege o trecho de conexão compatível; verifique também a proteção de todo o caminho da aplicação.

Proteja dados durante o processamento

Dados em uso estão sendo processados, frequentemente em memória decifrada. A computação confidencial acrescenta isolamento baseado em hardware, com criptografia de memória nas tecnologias compatíveis. As VMs confidenciais do Azure e do Google criptografam a memória usando chaves mantidas no processador. O AWS Nitro Enclaves isola memória e CPUs da instância de origem e de seus administradores.

Para o prontuário de um paciente, a criptografia do banco de dados protege o armazenamento, a TLS protege sua entrega a um médico, e uma VM confidencial pode proteger uma tarefa de análise sensível durante a execução. Esses controles cobrem exposições diferentes. A aplicação ainda precisa de permissão para processar o prontuário e continua responsável pelo que produz.

A responsabilidade pelas chaves afeta tanto o controle de segurança quanto o risco operacional. Um cliente que ganha o poder de desativar uma chave também passa a poder interromper todos os serviços que dependem dela.

Compare as opções de controle

Serviços de chaves na nuvem incluem AWS KMS, Azure Key Vault e Google Cloud KMS. Eles controlam operações criptográficas e podem registrar o uso de chaves. Ative os registros necessários, incluindo as configurações de diagnóstico do Azure e o registro de auditoria de Data Access do Google Cloud KMS.

Exemplos de chaves fornecidas pelo cliente incluem fluxos compatíveis do Amazon S3 SSE-C e do Google CSEK. Opções externas incluem AWS KMS external key stores e Google Cloud External Key Manager. Esses recursos são específicos de cada serviço; o serviço de dados escolhido deve ser compatível com a opção.

Um módulo de segurança de hardware (HSM) protege chaves em hardware especializado. AWS CloudHSM, Azure Managed HSM e Google Cloud HSM oferecem proteção por hardware. HSM descreve como as chaves são protegidas; o controle pelo provedor, cliente ou parte externa descreve quem governa seu uso. São escolhas diferentes.

Entenda a criptografia de envelope

O armazenamento em nuvem frequentemente criptografa grandes volumes de conteúdo com uma chave de dados. Em seguida, criptografa essa chave menor com uma chave de criptografia de chaves mantida em um serviço de chaves. A chave de dados protegida pode ser armazenada ao lado do texto cifrado. Isso é criptografia de envelope: não é necessário enviar grandes volumes de dados ao KMS para cada operação criptográfica.

Para ler o conteúdo, o serviço precisa de permissão para decifrar a chave de dados. Desativar a chave que a protege bloqueia esse caminho. A destruição permanente da chave pode tornar ilegíveis todos os dados que dependem dela, incluindo cópias de segurança antigas.

Analise a escolha de um hospital

Um hospital escolhe uma chave do AWS KMS gerenciada pelo cliente para exames de imagem. A função da aplicação pode decifrar; a equipe de segurança administra a chave sem permissão rotineira para ler os exames. Isso separa o uso dos dados da administração da chave. As evidências de auditoria devem mostrar as permissões pretendidas e o uso da chave.

A chave passa por rotação anual. A rotação fornece novo material para criptografias futuras e mantém as versões anteriores necessárias para ler o conteúdo existente. Isso não significa que todos os exames antigos sejam imediatamente criptografados novamente.

Ao fim do serviço, o hospital verifica todos os dados restantes e as dependências de cópias de segurança antes de programar a exclusão da chave. O AWS KMS usa um período de espera de 7 a 30 dias. Após a exclusão, o texto cifrado dependente não pode ser recuperado por meio dessa chave. Destruir o acesso por meio da destruição da chave é eliminação criptográfica.

Associe o controle a um requisito

Escolha chaves gerenciadas pelo cliente ou externas quando um contrato, regulamento, requisito de revogação, requisito de auditoria ou segregação de funções exigir esse controle. O mesmo algoritmo de criptografia pode proteger dados em qualquer um desses modelos de gerenciamento. O controle adicional da chave muda a responsabilidade, o planejamento de disponibilidade e as evidências; ele não torna o AES matematicamente mais forte.

A defesa em profundidade combina controles independentes. Se um falhar, outro poderá bloquear a próxima ação, limitar seus danos ou revelar o ataque.

Organize os controles em camadas

A visão de sete camadas da Microsoft vai da segurança física à identidade e acesso, perímetro, rede, computação e aplicação, até os dados no centro.

A atribuição de responsabilidades segue o modelo de responsabilidade compartilhada. Os provedores operam controles físicos; os clientes controlam identidades e dados. Quem mantém a computação depende de ela ser uma VM do cliente ou uma plataforma gerenciada.

Acompanhe uma tomada de conta

Um invasor obtém a senha de uma pessoa desenvolvedora de uma loja. A MFA pode bloquear um novo logon. Suponha que o invasor roube uma sessão já autenticada. Os controles seguintes devem tratar do que essa sessão pode fazer.

A função da pessoa desenvolvedora permite a leitura de registros, mas não consultas ao banco de dados, então a autorização nega uma requisição direta de dados de clientes. Regras de rede restringem separadamente as conexões ao banco de dados ao caminho permitido da aplicação. O monitoramento pode sinalizar atividades incomuns. Cópias de segurança protegidas preservam a capacidade de recuperação se um invasor obtiver acesso que permita ações destrutivas posteriormente.

A criptografia de disco protege o armazenamento bruto sem a chave. Ela não bloquearia conteúdo legível retornado a uma identidade comprometida com permissão legítima de leitura e decifragem. Avalie o caminho real antes de atribuir a um controle a capacidade de interrompê-lo.

Combine bloqueio com detecção

Um controle preventivo impede uma requisição, como a criação de armazenamento público. Um controle detectivo informa um evento ou condição, como atividade incomum ou acesso excessivo. Atribua uma resposta que investigue, contenha e corrija o que for encontrado.

Dois firewalls com a mesma regra incorreta podem falhar juntos. Uma verificação de identidade separada, validação da aplicação e uma função de dados restrita tratam de etapas diferentes do ataque. Acompanhe uma requisição do usuário até os dados, identifique os controles ao longo desse caminho e atribua responsáveis por suas configurações e alertas.

A confiança zero não concede aprovação automática com base na localização na rede. Um endereço interno não estabelece permissão para usar uma aplicação ou ler seus dados.

Aplique três princípios

Verifique explicitamente: avalie a identidade e o contexto, incluindo a integridade do dispositivo, a localização, o serviço solicitado, a sensibilidade dos dados e comportamentos incomuns.

Use privilégio mínimo: conceda apenas o acesso suficiente para a tarefa, com elevação por tempo limitado quando necessário. Um usuário autenticado ainda precisa de permissão para a ação.

Pressuponha a violação: restrinja a movimentação, criptografe o tráfego e monitore a atividade para que uma identidade ou dispositivo comprometido não possa acessar tudo livremente.

O NIST SP 800-207 descreve a abordagem de arquitetura. A Microsoft a expressa por meio desses três princípios. As organizações implementam a estratégia por meio de controles coordenados e podem adotá-la passo a passo.

Mude a fronteira de acesso

Um modelo de perímetro tradicional tende a confiar nos dispositivos depois que entram na rede. Uma conexão VPN abrangente pode então permitir que um notebook infectado acesse muitos sistemas. O trabalho remoto, o SaaS e a multinuvem tornam a localização, por si só, uma fronteira de acesso inadequada.

Um proxy com reconhecimento de identidade avalia o acesso a uma aplicação específica. O Google Identity-Aware Proxy, o AWS Verified Access e o Microsoft Entra Private Access oferecem recursos relacionados. A abordagem BeyondCorp do Google é um exemplo de substituição da confiança automática na rede interna por acesso avaliado.

A segmentação e os firewalls continuam limitando o alcance após a falha de outro controle. Criptografe também as conexões internas: um invasor pode já estar dentro do ambiente.

Avalie a requisição de uma pessoa da equipe de enfermagem

Uma pessoa da equipe de enfermagem solicita de casa acesso ao aplicativo de escala de funcionários. Um serviço de acesso verifica a identidade com autenticação resistente a phishing, verifica se o notebook é gerenciado e está atualizado e confirma a função de escala. Ele concede uma sessão para essa aplicação.

Uma requisição à folha de pagamento exige sua própria decisão de permissão. A sessão de escala não concede acesso à folha de pagamento. Se o monitoramento sinalizar posteriormente que o notebook está infectado, a política poderá bloquear ou revogar o acesso afetado. A autenticação pela manhã não resolve a questão da integridade do dispositivo à tarde.

Os serviços de identidade estabelecem quem está solicitando; as verificações de dispositivos e o acesso condicional avaliam o contexto. As funções restringem ações, proxies e segmentos restringem o alcance, e a TLS protege as conexões. O monitoramento fornece novas evidências para decisões posteriores. Comprar um produto ainda deixa para a organização a definição dessas regras de acesso e decisões de resposta.

Comece pela tarefa que o controle deve executar. Os principais provedores oferecem categorias de segurança sobrepostas, e um único produto pode fornecer vários tipos de resultado. Uma fraqueza de software detectada exige uma resposta diferente de uma inundação de tráfego.

Bloqueie inundações e ataques web

A proteção contra DDoS combate o tráfego destinado a sobrecarregar um serviço. O AWS Shield Standard fornece proteção básica automática; o Shield Advanced acrescenta recursos pagos e suporte de resposta. O Azure oferece proteção padrão de infraestrutura com camadas pagas do Azure DDoS Protection. O Google Cloud Armor protege aplicações compatíveis atrás de balanceadores de carga.

Um firewall de aplicações web (WAF) inspeciona requisições web em busca de ataques como injeção de SQL, scripts entre sites e bots abusivos. O AWS WAF, o Azure Web Application Firewall e as políticas de segurança do Cloud Armor oferecem essa categoria de proteção. Eles podem filtrar requisições de aplicações ou limitar suas taxas. Um firewall de rede controla o tráfego de rede em outro nível: AWS Network Firewall, Azure Firewall e Google Cloud Next Generation Firewall são exemplos. O AWS Firewall Manager ajuda a aplicar proteções compatíveis em várias contas.

Detecte ameaças e fraquezas conhecidas

A detecção de ameaças examina atividades em busca de sinais de comprometimento. Uma VM que entra em contato com um serviço conhecido de mineração é um alerta comportamental. O GuardDuty analisa fontes que incluem informações de API, fluxo de rede e DNS. Um SIEM, como Microsoft Sentinel ou Google Security Operations, reúne eventos de segurança de várias fontes para análise e investigação.

O gerenciamento de vulnerabilidades identifica fraquezas conhecidas em software ou imagens instalados. O Inspector avalia cargas de trabalho compatíveis do EC2, de contêineres e do Lambda. Um pacote vulnerável pode existir antes de qualquer atividade observada de um invasor; encontrá-lo deve levar a uma atualização ou a outra medida de mitigação adequada.

O gerenciamento da postura de segurança na nuvem (CSPM) verifica a configuração em relação a práticas e padrões. Um recurso de armazenamento acessível publicamente é um problema de postura mesmo que nenhum acesso malicioso tenha sido detectado. O AWS Security Hub reúne resultados; o Security Hub CSPM fornece controles de configuração. O Defender for Cloud e o Security Command Center também oferecem avaliação de postura.

Encontre dados sensíveis e aja sobre os resultados

O Macie pode localizar conteúdo sensível no S3. O Purview descobre, classifica e rotula dados organizacionais. O Google Sensitive Data Protection pode descobrir, classificar e desidentificar conteúdo sensível. Encontrar números de passaporte em uma exportação esquecida mostra à equipe onde são necessários controles mais fortes de acesso ou retenção; a descoberta, por si só, não altera todas as permissões.

Para um serviço on-line, associe o sintoma à categoria. Use proteção contra DDoS para uma inundação, um WAF para entradas web maliciosas, avaliação de vulnerabilidades para uma biblioteca desatualizada, detecção de ameaças para atividade suspeita durante a execução e CSPM para configurações arriscadas de recursos. Várias delas podem ser necessárias ao mesmo tempo.

O AWS Trusted Advisor, o Azure Advisor e o Google Recommender fornecem recomendações adicionais; as verificações disponíveis e os planos pagos variam. Os marketplaces dos provedores oferecem produtos de terceiros. Documentação oficial de segurança, centros de resposta, blogs e boletins ajudam as equipes a acompanhar as mudanças. Atribua responsáveis pelos resultados e ative os planos de serviço relevantes: um painel cheio de alertas não revisados deixa a exposição subjacente sem tratamento.

Os registros respondem a perguntas sobre eventos; o monitoramento transforma observações em ações. Boas evidências dependem de coletar os eventos certos com antecedência, retê-los por tempo suficiente e protegê-los contra alterações.

Escolha a evidência para cada pergunta

Registros de auditoria ou atividade mostram quem executou ações no console ou na API. O histórico de configuração mostra como as configurações de um recurso mudaram. Métricas medem integridade e desempenho. Registros de acesso a dados registram acessos relevantes ao conteúdo, e registros de fluxo de rede descrevem fluxos de tráfego.

O histórico de eventos do CloudTrail retém os 90 dias mais recentes de eventos de gerenciamento por região. Crie uma trilha para enviar registros ao S3 para retenção mais longa e, opcionalmente, também ao CloudWatch Logs. As métricas de desempenho do CloudWatch são evidências diferentes do registro do CloudTrail sobre quem alterou uma política.

O registro de atividades do Azure também mantém 90 dias por padrão. Configurações de diagnóstico podem enviar registros para armazenamento, Log Analytics ou Event Hubs. Os registros Admin Activity do Google estão sempre ativados e não podem ser desativados. Os registros Data Access precisam ser ativados para a maioria dos serviços; o BigQuery tem configurações padrão importantes que são diferentes. Os registros de acesso do Key Vault e a atividade de dados do Google KMS também precisam das configurações de coleta relevantes.

Preserve evidências antes que uma investigação precise delas

Um bucket torna-se público em 2 de março de 2026. A investigação começa em 1º de julho, 121 dias depois. O evento está fora da janela padrão de 90 dias. Uma exportação configurada anteriormente pode preservar quem alterou a configuração, quando e de qual endereço IP; ativar uma exportação agora não pode recriar um registro expirado.

O histórico de configuração pode mostrar a configuração antes e depois do evento. Use ambos os registros para entender a mudança, reverter a exposição e investigar o acesso aos dados por meio dos registros adequados que estiverem ativados. Um evento de gerenciamento, por si só, não é uma lista completa dos arquivos lidos.

Previna mudanças e detecte exceções

Controles preventivos bloqueiam uma ação não permitida: Azure Policy Deny, restrições compatíveis de SCP e restrições de organização do Google são exemplos. Controles detectivos identificam uma condição após sua ocorrência: regras do AWS Config, Azure Policy Audit e resultados de postura.

Uma política de localização pode bloquear novos recursos em regiões não permitidas. Uma verificação de configuração pode informar recursos que violam uma regra. Esta última exige uma resposta e não desfaz uma mudança apenas por emitir um resultado.

Restrinja o acesso aos registros, colete evidências em uma conta ou projeto separado e use controles de integridade ou imutabilidade quando necessário. A validação de arquivos de registro do CloudTrail pode revelar arquivos entregues que foram alterados. Defina a retenção conforme o requisito aplicável; o PCI DSS exige pelo menos 12 meses de histórico de auditoria, com os 3 meses mais recentes prontamente disponíveis. Configure alertas para eventos como logons do usuário raiz ou alterações em funções com privilégios elevados e atribua alguém para responder.

Conformidade significa atender aos requisitos aplicáveis e apresentar evidências. Os controles auditados de um provedor de nuvem podem apoiar suas obrigações, mas sua organização também deve executar e documentar os controles sob sua responsabilidade.

Identifique o tipo de requisito

A ISO/IEC 27001 trata de um sistema de gestão de segurança da informação, ou SGSI. Organismos de certificação acreditados emitem certificados, normalmente em um ciclo de três anos com auditorias de acompanhamento. A ISO/IEC 27017 acrescenta controles de segurança em nuvem. A ISO/IEC 27018 trata da proteção de dados pessoais por operadores em nuvens públicas; sua edição atual é de 2025.

Escolha o relatório SOC para a pergunta

O SOC 1 trata de controles relevantes para os relatórios financeiros dos clientes. O SOC 2 aborda os Critérios de Serviços de Confiança aplicáveis: segurança, disponibilidade, integridade do processamento, confidencialidade e privacidade. É um relatório detalhado, geralmente compartilhado sob condições de confidencialidade. O SOC 3 é um relatório de uso geral adequado para distribuição pública.

Um relatório Tipo 1 avalia o desenho dos controles em um momento específico. Um relatório Tipo 2 também testa a eficácia de seu funcionamento durante um período determinado. Para obter evidências de que os controles relevantes de um fornecedor funcionaram ao longo de meses, solicite um relatório SOC 2 Tipo 2 atual e examine seu escopo real. O SOC 2 é uma asseguração, não uma certificação.

Reconheça necessidades do setor e do governo

O PCI DSS aplica-se a organizações que armazenam, processam ou transmitem dados de titulares de cartão. O escopo do serviço de nuvem é importante junto com o projeto de pagamentos e os controles do cliente.

A HIPAA protege as PHI dentro de seu escopo: organizações de saúde abrangidas e seus associados comerciais. Um provedor que mantém PHI eletrônicas em nome de uma entidade abrangida é um associado comercial, inclusive quando armazena dados criptografados sem a chave. Um acordo de associado comercial (BAA) deve estar em vigor. Não existe certificação oficial de HIPAA que substitua essas obrigações.

O FedRAMP trata da avaliação e supervisão contínua de serviços em nuvem para uso por agências federais dos Estados Unidos dentro do escopo. Os casos de uso e as exclusões das agências são importantes; vender software instalável a uma agência, por si só, não gera essa exigência. Outros programas de asseguração incluem o C5 da Alemanha, o ENS da Espanha, o IRAP da Austrália e o ISMAP do Japão. O CSA STAR publica autoavaliações de nuvem e informações de asseguração independente.

Verifique o escopo do serviço antes de se basear em evidências

Uma clínica verifica tanto seu BAA quanto a lista de serviços elegíveis do provedor antes de colocar PHI eletrônicas em um serviço. Um varejista que processa dados de titulares de cartão verifica os requisitos do PCI DSS e também pode ter obrigações de GDPR para dados pessoais. Uma obrigação não substitui a outra.

Um certificado ou relatório define um limite: serviços, locais e datas de avaliação. Registre quais controles do provedor sua carga de trabalho herda e depois implemente suas próprias permissões, configurações, procedimentos e evidências. Um selo corporativo abrangente do provedor não responde se um novo serviço ou uma região específica está incluído.

As evidências de conformidade são úteis quando correspondem ao serviço, local e período dos quais você depende. Baixar um documento inicia a revisão; seu conteúdo determina em qual asseguração você pode se basear.

Encontre os documentos do provedor

Relatórios SOC detalhados frequentemente exigem a aceitação de termos de confidencialidade ou de um acordo de confidencialidade. Relatórios SOC 3 de uso geral e muitos certificados são públicos. Páginas públicas de conformidade ajudam a identificar os programas disponíveis e os serviços no escopo.

Leia um relatório SOC 2 Tipo 2 em ordem

1. Leia a opinião do auditor. Uma opinião sem ressalvas fornece asseguração favorável dentro do escopo declarado; uma opinião com ressalvas identifica uma ressalva que precisa ser entendida.
2. Relacione a descrição e o escopo do sistema aos serviços e locais escolhidos.
3. Verifique o período do relatório e há quanto tempo ele terminou.
4. Leia os controles testados e as exceções, incluindo como afetam seu uso.
5. Identifique os controles complementares da entidade usuária (CUECs): controles que sua organização deve executar.
6. Revise o papel e o tratamento das organizações subcontratadas das quais o provedor depende.

Um relatório pode ser favorável e ainda exigir que sua organização gerencie o acesso de usuários, revise registros ou defina uma configuração. Inclua essas obrigações em seu próprio plano de controles e atribua responsáveis.

Em 15 de março de 2026, uma equipe revisa um relatório que abrange de 1º de outubro de 2024 a 30 de setembro de 2025. O período de teste de doze meses terminou 166 dias antes. Uma carta de continuidade apresenta a declaração do provedor sobre mudanças relevantes desde essa data de término. Ela não é uma nova auditoria independente de cada dia da lacuna. Obtenha o próximo relatório quando estiver disponível.

Mantenha os contratos junto às evidências

O GDPR exige um contrato adequado entre controlador e operador, geralmente fornecido como acordo ou aditivo de tratamento de dados. Exemplos dos provedores incluem o aditivo GDPR da AWS, o Products and Services Data Protection Addendum da Microsoft e o Cloud Data Processing Addendum do Google. Relações com associados comerciais sujeitas à HIPAA exigem um BAA.

Um relatório descreve controles avaliados. Um acordo cria os compromissos contratuais relevantes. Um documento não pode cumprir o papel do outro. Mantenha aceitos e atualizados os acordos aplicáveis aos serviços em uso.

Acompanhe também os controles do cliente

Registre os controles do provedor como herdados e depois reúna suas próprias revisões de acesso, resultados de configuração, registros, políticas e registros de treinamento, conforme aplicável. Os pacotes de conformidade do AWS Config agrupam verificações técnicas de configuração; eles não avaliam todas as políticas ou procedimentos da equipe. O Purview Compliance Manager fornece ações de melhoria e uma pontuação de conformidade. O Google Assured Workloads aplica controles compatíveis para cargas de trabalho regulamentadas, incluindo restrições de localização e acesso.

Trate pontuações e resultados como uma lista de trabalho com evidências a examinar. Resolva lacunas de escopo ou datas antes de apresentar os documentos a um comprador ou auditor e verifique se um serviço ou região recém-adotado exige uma nova revisão.

A proteção de dados combina decisões sobre finalidade, acesso, localização e direitos das pessoas. Mover registros para uma região escolhida resolve apenas a parte da localização.

Conheça os papéis e as obrigações

O GDPR, aplicável desde 25 de maio de 2018, rege o tratamento de dados pessoais dentro de seu escopo na UE e no EEE. Ele também alcança organizações fora da UE que oferecem bens ou serviços a pessoas na UE ou monitoram seu comportamento nesse território. Ele não se limita a cidadãos da UE.

O controlador de dados decide as finalidades e os meios do tratamento. O operador de dados age em nome do controlador. Para registros hospedados do cliente, o cliente costuma ser o controlador e o provedor de nuvem, seu operador. O Artigo 28 exige um contrato escrito de tratamento. Os papéis dependem da relação real de tratamento, não apenas da designação da empresa na nuvem.

As obrigações relevantes para a nuvem incluem uma base legal, coleta apenas dos dados necessários (minimização de dados), segurança adequada ao risco, direitos das pessoas de acesso e exclusão e notificação de violações quando aplicável. O Artigo 32 cita criptografia e pseudonimização como exemplos de medidas de segurança.

De acordo com o Artigo 33, um controlador comunica uma violação de dados pessoais à sua autoridade supervisora sem demora injustificada e, quando possível, em até 72 horas após tomar conhecimento dela, a menos que seja improvável que ela cause risco aos direitos e liberdades das pessoas. Um operador informa seu controlador sem demora injustificada. Se o conhecimento ocorrer na segunda-feira às 09:00, as 72 horas terminam na quinta-feira às 09:00; isso não é uma permissão para esperar quando uma notificação mais cedo for possível. Uma notificação tardia à autoridade deve explicar o atraso.

A faixa superior do Artigo 83 permite um máximo de € 20 milhões ou 4% do faturamento anual mundial do ano anterior, o que for maior. Para um faturamento de € 1,5 bilhão, 4% são € 60 milhões; para € 300 milhões, são € 12 milhões, então o limite de € 20 milhões é maior. As penalidades efetivas dependem da infração e da avaliação.

Diferencie os requisitos de localização

Verifique os compromissos de localização de um serviço, as cópias de segurança, as réplicas e o acesso do suporte. A escolha de uma região não é uma garantia geral para todos os recursos do serviço. Ofertas governamentais e soberanas, como AWS GovCloud (US), Azure Government e opções soberanas europeias, atendem a requisitos específicos com elegibilidade e escopo definidos.

Transferências para fora do EEE precisam de um mecanismo legal aplicável, como adequação, cláusulas contratuais padrão ou normas corporativas vinculantes. O mecanismo de adequação do Quadro de Privacidade de Dados UE–EUA aplica-se a transferências abrangidas para organizações participantes certificadas. O acesso por funcionários em outro país também pode exigir análise de transferência, mesmo quando o armazenamento permanece em uma região da UE.

Uma seguradora que mantém sinistros na UE seleciona regiões da UE para armazenamento e cópias de segurança, aplica controles de proteção de localização compatíveis, controla o acesso às chaves e revisa seu DPA e os termos de transferência. Chaves gerenciadas pelo cliente, por si só, não resolvem as obrigações de residência ou transferência.

Dados pessoais criptografados continuam sendo dados pessoais para uma parte capaz de decifrá-los. A criptografia eficaz pode eliminar a obrigação de notificar as pessoas afetadas conforme o Artigo 34 quando suas condições são atendidas; a notificação à autoridade tem seus próprios critérios. Outras leis, incluindo a CCPA da Califórnia alterada pela CPRA e a LGPD do Brasil, têm seus próprios escopos e obrigações.