← AWS DevOps Engineer Professional: operação e entrega
24 / 24 · 80 MIN

Cobertura de segurança e evidência de conformidade

Distingue recursos avaliados, controlos aplicáveis, resultados atuais e decisões administrativas antes de emitir um parecer.

Começar pelo denominador

Um dashboard sem findings críticos parece uma boa notícia, mas só responde sobre a população efetivamente avaliada. Numa plataforma fictícia com várias contas e Regiões, começa pelo inventário de recursos e operações relevantes. Compara esse conjunto com serviços ativados, tipos suportados, exclusões, cadência e última avaliação. Regista lacunas como lacunas, com dono e próxima ação. Não retires silenciosamente recursos do denominador para melhorar um indicador. O parecer deve separar exposição observada de incerteza por falta de avaliação. Uma exceção pode ser uma decisão de negócio legítima quando tem autoridade, prazo e condições definidos; não transforma um recurso não observado num recurso tecnicamente conforme. O relatório deve permitir reproduzir essa distinção.

Entender o que AWS Config observou

Um aggregator disponibiliza leitura de dados de várias origens, mas não instala regras nessas contas. Confirma o recorder e o âmbito real de tipos de recurso antes de interpretar resultados agregados. A cadência também limita conclusões: registo diário conserva o estado mais recente do período quando há alteração e pode não mostrar transições intermédias. Uma regra NOT_APPLICABLE não demonstrou o requisito para aquele recurso. No pipeline, avaliação proativa fornece um resultado sobre propriedades propostas, mas não bloqueia deployment por si só. O gate deve interpretar o resultado segundo uma política explícita, incluindo erro ou ausência de resposta. Estes contratos distinguem recolher configuração, avaliar uma regra e impedir uma mudança; cada responsabilidade precisa de um mecanismo e evidência próprios.

Separar agregação e configuração central

No Security Hub CSPM, ligar uma Região para agregação não ativa automaticamente o serviço na origem. Confirma ativação antes de inferir segurança a partir de um painel vazio. A configuração central usa políticas criadas na home Region e associadas a contas ou estruturas organizacionais. Essas políticas aplicam-se à home Region e às Regiões ligadas no âmbito definido. Contas geridas centralmente não substituem livremente as definições abrangidas; encaminha a alteração para a autoridade responsável. Uma política que enumera controlos ativados deixa os restantes fora, incluindo novos controlos. Esse comportamento difere de enumerar controlos desativados. Ao rever uma política, explica ao dono do serviço como novos controlos serão adotados e quem vai tratar os resultados.

Interpretar o ciclo de vida dos findings

RESOLVED e SUPPRESSED descrevem tratamento de findings Security Hub CSPM. Uma mudança manual para RESOLVED não corrige a propriedade do recurso. Supressão também não impede novos findings sobre o mesmo problema. Guarda a razão de fecho, a evidência técnica e a decisão de exceção quando aplicável. Em GuardDuty, preferências de ativação automática têm outro contrato: NEW cobre novas contas; NONE não desativa membros já ativos. A configuração é regional e a organização usa o mesmo administrador delegado nas Regiões. Suspender e desativar também não são equivalentes: a suspensão preserva findings existentes, enquanto desativar elimina findings e configuração nessa Região. Malware Protection for S3 tem particularidades próprias e fica fora do exercício de suspensão desta aula.

Confirmar cobertura de vulnerabilidades

Em ECR enhanced scanning, distingue scan on push de continuous scanning. Um resultado recolhido no push não garante reavaliação após surgir uma CVE. Mesmo no modo contínuo, confirma elegibilidade e duração aplicáveis. Quando uma imagem perde cobertura por expiração, o fecho dos findings não demonstra que os pacotes foram corrigidos. Aumentar a duração também não reativa automaticamente imagens já inativas. No EC2 agent-based, investiga integração com Systems Manager, permissões e inventário quando a instância não tem cobertura. Evita transportar conclusões entre imagem e host, ou entre ambientes com versões diferentes. O relatório de correção deve identificar o artefacto avaliado, o estado de cobertura, o resultado relevante e a evidência de que a versão corrigida é a que está em utilização.

Exercício: classificar o resultado disponível

O modelo local recebe uma observação fictícia com âmbito confirmado, cobertura ativa, idade do resultado e número de findings. Usa uma janela interna definida no exercício, não um SLA AWS. Se faltar evidência, a conclusão fica pendente; se a observação estiver desatualizada, pede nova avaliação. Zero findings só permite descrever o resultado observado, não ausência universal de vulnerabilidades. Executa os casos e altera a janela para perceber o efeito da política interna. Depois escreve um parecer curto para o comité de mudança, incluindo recurso, conta, Região, momento da avaliação, limitações e responsável pelo próximo passo. O objetivo é tornar a decisão rastreável e útil para operação e gestão, sem esconder incerteza atrás de um indicador verde.

# Original local review model, not an AWS scanner or proof of absence of vulnerabilities.
def classify(scope_confirmed, active, age_hours, findings, max_age_hours):
    if scope_confirmed is not True or active is not True:
        return "coverage gap"
    if age_hours is None or findings is None:
        return "evidence missing"
    if age_hours < 0 or findings < 0 or max_age_hours <= 0:
        raise ValueError("invalid observation or policy")
    if age_hours > max_age_hours:
        return "reassessment required"
    if findings > 0:
        return "findings require disposition"
    return "no findings in the stated assessed scope"

# Fictional internal policy; not a vendor SLA.
assert classify(True, True, 2, 0, 24) == "no findings in the stated assessed scope"
assert classify(False, True, 2, 0, 24) == "coverage gap"
assert classify(True, False, 2, 0, 24) == "coverage gap"
assert classify(True, True, None, 0, 24) == "evidence missing"
assert classify(True, True, 25, 0, 24) == "reassessment required"
assert classify(True, True, 2, 4, 24) == "findings require disposition"
try:
    classify(True, True, -1, 0, 24)
except ValueError:
    pass
else:
    raise AssertionError("invalid age accepted")
NA PRÁTICA

Exemplo fictício: findings de uma imagem desaparecem do conjunto ativo porque expirou a análise. A tarefa de correção mantém-se aberta até haver avaliação relevante e decisão documentada.

Armadilhas comuns

Armadilhas: usar um aggregator como mecanismo de deployment, tratar NOT_APPLICABLE como aprovação, presumir ativação regional e interpretar expiração como correção de pacotes.

Tópicos relacionados: Recuperação de dados e transição de serviço

Leva esta ideia contigo

Um parecer credível liga o recurso e o âmbito à avaliação atual, à interpretação do resultado e à decisão tomada perante lacunas.

Criar conta

Referência: DOP-C02 security and compliance objectives · DOP-C02

AWS é uma marca comercial da Amazon.com, Inc. ou das suas afiliadas. A dr.pt é uma plataforma de preparação independente e não está afiliada, associada, patrocinada, autorizada nem aprovada por AWS. Os conteúdos e as perguntas são originais, não são perguntas oficiais de exame, e concluir os nossos testes não atribui nem garante qualquer certificação. Os nomes são usados apenas para identificar o tema. Todas as outras marcas pertencem aos respetivos titulares.