Certificação especializada em segurança que valida a arquitetura de segurança AWS, proteção de dados e conformidade regulatória.
Amazon GuardDuty, Amazon Detective, AWS Security Hub, Amazon EventBridge, Automação de resposta a incidentes, AWS Systems Manager Incident Manager
AWS CloudTrail, Amazon CloudWatch Logs, VPC Flow Logs, AWS Config, Análise de logs com Amazon Athena, Amazon OpenSearch Service
Segurança do Amazon VPC, AWS WAF, AWS Shield, AWS Network Firewall, AWS PrivateLink, Segurança de borda e CloudFront
Políticas IAM da AWS, AWS IAM Identity Center, Amazon Cognito, SCPs do AWS Organizations, Federação e SAML, Limites de permissão
AWS KMS, AWS CloudHSM, AWS Certificate Manager, Amazon Macie, Criptografia e políticas de buckets S3, AWS Secrets Manager
AWS Organizations, AWS Control Tower, AWS Audit Manager, AWS Trusted Advisor, Frameworks de conformidade, AWS Artifact
Experimente questões no estilo do exame do conjunto de amostra gratuito. Cada resposta vem com uma explicação completa.
A equipe de segurança de uma empresa global de serviços financeiros deseja configurar aplicações de múltiplas contas de workload para acessar um bucket S3 em uma conta de dados central dentro de um ambiente AWS Organizations.
As funções IAM nas contas de workload receberam permissões de acesso ao S3, mas erros de acesso estão ocorrendo durante as tentativas de acesso. A equipe de segurança deseja resolver esse problema mantendo o princípio do menor privilégio e minimizando a sobrecarga operacional.
O que DEVE ser configurado adicionalmente para permitir corretamente o acesso S3 entre contas nesta situação?
Resposta: A. Política de bucket S3, permitir Principal entre contas
Para acesso S3 entre contas, a AWS requer Allow explícito tanto na política IAM do lado do solicitante quanto na política de bucket S3 do lado do recurso. Mesmo que a função IAM na conta de workload tenha permissões S3, ocorrerá um erro de acesso se a política de bucket S3 da conta central não permitir explicitamente o Principal da conta de workload. É obrigatório adicionar o Principal entre contas (ARN da função IAM da conta de workload ou ID da conta) à política de bucket S3.
A política de bucket S3 é uma política baseada em recursos. Para que um Principal de outra conta acesse o bucket, deve haver Allow explícito nessa política de bucket. Em um ambiente Organizations, você pode especificar o ID da conta ou ARN da função IAM como Principal em políticas de bucket individuais para manter o menor privilégio.
No exame, erros de S3 entre contas são sempre causados por uma política de bucket ausente. As ACLs do S3 são um mecanismo legado que dificulta o gerenciamento de menor privilégio, as SCPs são para restrições e não concessões, e políticas IAM sozinhas não podem habilitar acesso S3 entre contas.
A equipe de segurança de uma empresa global de energia tem um requisito de segurança para bloquear imediatamente todos os desenvolvedores de um grupo IAM de criar e modificar recursos AWS fora de uma região específica. No entanto, o acesso a serviços classificados globalmente, como IAM, CloudFront e Route 53, deve continuar sendo permitido.
Qual configuração de política IAM MELHOR permite aplicar uma restrição em massa a todo o grupo sem modificar políticas de usuários individuais, enquanto lida com exceções de serviços globais?
Resposta: B. Política de grupo IAM, Deny com aws:RequestedRegion, serviços globais excluídos com NotAction
As duas condições-chave neste cenário são: a restrição deve ser aplicada a todo o grupo IAM de uma só vez, e os serviços globais (IAM, CloudFront, Route 53) devem ser isentos. Usar NotAction com a condição aws:RequestedRegion em uma política de grupo IAM permite bloquear todas as solicitações fora de uma região específica, exceto as ações de serviços globais listadas. Esta é a abordagem mais direta para impor restrições de nível de grupo imediatamente sem tocar nas políticas de usuários individuais.
Em uma instrução Deny de política de grupo IAM, NotAction exclui apenas as ações de serviços globais listadas, aplicando o Deny de condição de região a todas as outras ações. A chave de condição aws:RequestedRegion filtra com base na região AWS para a qual a solicitação é direcionada, e como os serviços globais não têm como alvo uma região específica, a exclusão explícita via NotAction é necessária.
No exame, é fácil confundir SCPs com políticas de grupo IAM. SCPs se aplicam no nível da hierarquia do AWS Organizations e não podem ser diretamente anexadas a grupos IAM, e os Permission Boundaries apenas definem o escopo máximo permitido e não são adequados para bloqueio em massa de grupos.
A equipe de segurança de uma empresa global de software precisa permitir que a equipe de desenvolvimento crie diretamente funções e usuários IAM para pipelines CI/CD, enquanto controla centralmente que os principais IAM criados pela equipe de desenvolvimento não possam exceder o escopo máximo de permissões definido pela equipe de segurança. O objetivo é evitar o escalonamento de privilégios onde a equipe de desenvolvimento poderia criar funções com permissões quase administrativas e atribuí-las a pipelines, mantendo a autonomia da equipe de desenvolvimento.
Qual abordagem de controle de acesso MELHOR permite que a equipe de segurança gerencie centralmente os limites máximos de permissão, ao mesmo tempo permitindo que a equipe de desenvolvimento crie principais IAM?
Resposta: B. IAM permissions boundary, conceder condição para criação de funções pela equipe de desenvolvimento
A equipe de segurança de uma empresa de software precisa controlar centralmente o limite máximo de permissões, garantindo a autonomia da equipe de desenvolvimento na criação de recursos IAM. O IAM permissions boundary define o limite máximo de permissões que um principal IAM pode ter, portanto, mesmo que a equipe de desenvolvimento crie uma função com permissões poderosas, as permissões que excedem o boundary não serão realmente aplicadas. Ao fazer com que a equipe de segurança gerencie centralmente a política de boundary e exigindo que a equipe de desenvolvimento anexe esse boundary ao criar funções, o escalonamento de privilégios pode ser evitado mantendo a autonomia da equipe.
O IAM permissions boundary é aplicado juntamente com políticas baseadas em identidade, e apenas a interseção de ambas as políticas se torna as permissões efetivas. Isso significa que mesmo que a equipe de desenvolvimento anexe políticas de nível AdministratorAccess a uma função, as permissões não incluídas no boundary são automaticamente bloqueadas. Ao contrário dos SCPs, a característica principal é que se aplica no nível individual do principal IAM, em vez de à conta inteira.
Nos exames, SCPs e permissions boundary são fáceis de confundir. Os SCPs se aplicam no nível do AWS Organizations a contas inteiras, enquanto o permissions boundary se aplica a principais IAM individuais. Quando o cenário envolve limitar o escopo de criação de IAM para uma equipe de desenvolvimento específica, escolha permissions boundary; quando restringir o uso de serviços em toda uma conta organizacional, escolha SCP.
A equipe de segurança de uma empresa de consultoria global deve restringir o acesso para que usuários IAM de parceiros externos possam fazer upload de objetos para buckets S3 designados apenas durante um período de contrato específico. O acesso deve ser bloqueado automaticamente quando o período de contrato terminar, e eles querem implementar isso sem que as equipes de operações modifiquem políticas manualmente.
Qual é a abordagem MAIS adequada para permitir S3 PutObject apenas durante um período específico usando condições de tempo em políticas baseadas em identidade IAM?
Resposta: C. Política IAM, Allow de condição aws:CurrentTime
A condição mais crítica neste cenário é o bloqueio automático de acesso usando condições de tempo em políticas baseadas em identidade IAM. Adicionar condições aws:CurrentTime (DateGreaterThan/DateLessThan) a uma política Allow do IAM permite S3 PutObject apenas durante o período especificado, e após o período terminar, a condição não é atendida, resultando em Deny implícito. Essa abordagem é a maneira mais concisa de implementar bloqueio automático sem trabalho operacional separado.
A condição aws:CurrentTime é uma chave de contexto de condição global do IAM que compara datas e horas no formato ISO 8601. Especificar o tempo de início com DateGreaterThan e o tempo de término com DateLessThan permite que apenas solicitações dentro dessa janela passem. Quando essa condição é aplicada a uma instrução Allow, a política não se aplica quando a condição não é atendida, negando acesso a menos que haja outro Allow.
Nos exames, quando aparecer controle de acesso automático baseado em tempo, escolha aws:CurrentTime condição Allow. Aplicar condições a instruções Deny inverte a lógica e complica o gerenciamento, e a expiração de sessão STS é adequada para sessões curtas (até 12 horas), tornando-a inadequada para controle de contrato de longo prazo.
A equipe de desenvolvimento de uma empresa global de mídia está enfrentando um problema onde uploads de arquivos pequenos para um bucket S3 criptografado com SSE-KMS são bem-sucedidos, mas uploads de arquivos grandes falham com erros de permissão. A função de execução da função Lambda tem a permissão kms:GenerateDataKey concedida.
Qual é a causa desse erro e qual permissão KMS adicional é necessária durante o processo de upload multipart para arquivos grandes?
Resposta: A. Permissão kms:Decrypt ausente
A diferença entre uploads de arquivos pequenos e grandes no upload multipart está nos requisitos de permissão do KMS. Uploads únicos PUT de arquivos pequenos podem criptografar usando apenas kms:GenerateDataKey para criar uma chave de dados, mas durante a fase CompleteMultipartUpload de uploads multipart, o S3 requer permissão kms:Decrypt para descriptografar as chaves de dados criptografadas de cada parte. Como o papel de execução do Lambda não tem kms:Decrypt, os uploads de arquivos grandes falham.
O upload multipart SSE-KMS consiste em três fases. Primeiro, CreateMultipartUpload gera a chave de dados, depois cada parte é enviada via UploadPart e, finalmente, CompleteMultipartUpload mescla todas as partes em um único objeto. Nesta fase final, o S3 deve descriptografar as informações de chave de criptografia de cada parte para regenerar a DEK (Data Encryption Key) para o objeto final, o que requer kms:Decrypt.
No exame, quando aparecerem erros de permissão SSE-KMS, distinga entre PUT único vs. upload multipart. Para uploads únicos, kms:GenerateDataKey é suficiente; para multipart, tanto kms:GenerateDataKey quanto kms:Decrypt são necessários.
O exame AWS Certified Security - Specialty (SCS-C03) tem 65 questões e limite de 170 minutos.
A nota de aprovação do exame SCS-C03 é 750 de 1000.
O conjunto de amostra de SCS-C03 (20 questões com explicações completas) é gratuito. O banco completo com mais de 340 questões está disponível com uma assinatura do CloudMasterIT.
A certificação SCS-C03 é válida por 3 anos após a aprovação. Depois disso é necessária a recertificação.