APRENDER. PRATICAR. EVOLUIR.1. Separar concessão de acesso e limite organizacional
Uma organização fictícia separa desenvolvimento e produção em contas membro. Um role IAM comum recebe uma permissão para uma ação, mas uma SCP aplicável nega essa ação. A permissão do role não ultrapassa a negação. Uma SCP estabelece limites para as identidades abrangidas e não concede acesso por si só. Mesmo que permita um serviço, ainda são necessárias concessões adequadas. Para Cloud Practitioner, interessa compreender esta diferença e reconhecer que podem existir várias camadas de controlo; não é necessário construir uma política complexa neste exercício. A documentação distingue ainda a conta de gestão e roles ligados a serviços, pelo que não generalizes o exemplo a todas as identidades sem verificar o contexto.
2. Proteger a identidade mais privilegiada
Numa conta autónoma, usar root para consultas diárias aproxima uma identidade muito privilegiada de tarefas rotineiras. Reserva-a para operações que a exigem, protege o acesso com MFA e mantém mecanismos de recuperação adequados. Para pessoas e aplicações, define acesso apropriado ao trabalho, preferindo credenciais temporárias quando aplicável. Não distribuas access keys root para facilitar scripts. Em organizações com várias contas, existem capacidades específicas de gestão central de acesso root que exigem análise própria; o exemplo de conta autónoma não descreve todas essas configurações. Uma reunião de projeto deve identificar quem gere identidades, como é revisto o acesso e como a equipa de suporte atua sem depender de uma credencial partilhada excessiva.
3. Pedir a evidência que responde à pergunta
Uma auditoria pode fazer perguntas diferentes: que relatórios disponibiliza o fornecedor, que configuração existia num recurso ou que identidade executou uma chamada API? AWS Artifact permite aceder a documentação de conformidade; AWS Config regista configurações e relações dos recursos abrangidos; CloudTrail apoia a análise de atividade API dentro da cobertura disponível. CloudWatch serve necessidades de observabilidade, como métricas e alarmes. Nenhuma destas ferramentas substitui automaticamente as restantes. Define a pergunta, o período e a cobertura necessária antes de aceitar um gráfico ou documento como resposta. Se um serviço de gravação não estava ativo ou não abrangia o recurso, a existência atual da ferramenta não cria retroativamente a evidência que falta.
4. Reconhecer o que continua a pertencer ao cliente
Mover uma base de dados de EC2 para um serviço gerido compatível pode reduzir tarefas de infraestrutura. Essa mudança não elimina decisões sobre acesso aos dados, comportamento da aplicação ou adequação da configuração. A divisão de responsabilidades varia com o serviço: a equipa deve rever o que a AWS opera e o que o cliente continua a configurar e controlar. Um relatório do fornecedor obtido no Artifact ajuda a avaliar controlos do fornecedor, mas não certifica a aplicação nem a forma como foi utilizada. Num exemplo bancário fictício, relaciona cada requisito com responsável e evidência. A discussão deve resultar numa atribuição compreensível de tarefas, em vez de concluir que a palavra gerido transfere todas as obrigações.
5. Escolher famílias de serviços com critérios claros
Uma necessidade de base de dados relacional aponta para uma família diferente de uma necessidade NoSQL por chaves e documentos. DynamoDB é uma opção gerida dessa segunda categoria, mas os padrões de acesso precisam de avaliação. DMS apoia a migração de dados; não se torna o motor permanente da aplicação nem garante equivalência entre motores diferentes. Uma equipa deve avaliar compatibilidade, conversão de schema quando necessária e validação do produto. Para recriar infraestrutura, CloudFormation permite descrevê-la em templates; isso apoia repetição e revisão sem dispensar permissões e validação. Mantém a pergunta ligada à necessidade concreta: armazenar dados, migrá-los, observar comportamento e criar recursos são trabalhos distintos que podem envolver vários serviços.
6. Exercício de reunião de transição
Prepara uma atualização para um projeto fictício que migra uma aplicação de relatórios. O suporte precisa de métricas de latência; a auditoria pede histórico de configuração; o responsável financeiro quer separar custos da aplicação. Escreve uma pergunta concreta para cada necessidade e identifica o serviço relevante, a cobertura a confirmar e a pessoa responsável. Acrescenta um acesso bloqueado por uma SCP numa conta membro e explica por que dar AdministratorAccess ao role não resolve essa negação. O objetivo é praticar linguagem clara entre gestão, segurança e operação. Não é um laboratório de implementação nem um procedimento interno de um banco. Termina a atualização distinguindo o que já está demonstrado, o que falta confirmar e quem acompanha a decisão.
Exemplo fictício: o role de produção tem um Allow, mas uma SCP nega a ação pedida. A equipa trata a exceção com a autoridade adequada; mudar da consola para CLI ou adicionar AdministratorAccess não remove o limite.
Armadilhas comuns
Confundir SCP com concessão de acesso, usar root no quotidiano, tratar um relatório do fornecedor como prova da aplicação e escolher serviços apenas por palavras semelhantes.
Tópicos relacionados: Identidade e menor privilégio · Custos, observabilidade e auditoria
Limites, permissões, responsabilidades e evidência devem ser identificados separadamente. Escolhe o serviço pela pergunta concreta e confirma a cobertura antes de concluir.
Referência: Service control policies · CLF-C02