← AWS Security Specialty: segurança com evidência
15 / 25 · 80 MIN

Perímetros de dados: caminhos e autorização

Diagnostica os controlos que realmente participam num pedido direto, delegado ou feito por um access point.

1. Descrever o pedido que falhou

Antes de editar políticas, regista a identidade, ação, recurso, caminho de rede e serviço que devolveu a negação. Num processamento de fundos, GetObject pode ser autorizado e a etapa de desencriptação continuar negada. Em FAS, o serviço a jusante também avalia as permissões do principal original. Desenha a cadeia para tornar visíveis as duas autorizações. Não uses o sucesso de uma chamada como prova de todas as chamadas necessárias. O gestor técnico deve pedir uma hipótese testável, o âmbito da alteração proposta e a evidência de que o fluxo legítimo recuperou. Um Allow mais amplo não resolve uma negação explícita aplicável e pode acrescentar exposição noutros caminhos sem corrigir o incidente.

2. Distinguir pedido direto e pedido delegado

Uma chamada por VPC endpoint tem contexto de rede que não é transportado da mesma forma para uma FAS posterior. Se a política exige SourceVpce em todas as etapas, uma integração legítima pode falhar. ViaAWSService identifica FAS; PrincipalIsAWSService distingue um service principal direto e não tem o mesmo significado. Para restringir intermediários, CalledVia permite testar presença na cadeia. Quando a posição importa, First e Last delimitam os extremos; verificar presença não impõe ordem. No exercício abaixo, os registos sintéticos são classificados como candidatos a uma exceção de perímetro ou a revisão. O resultado não é autorização IAM: faltam ações, recursos, políticas e condições que um motor real teria de avaliar.

3. Usar identificadores do âmbito pretendido

Duas VPCs podem usar o mesmo CIDR privado. Um filtro VpcSourceIp isolado não as distingue; combina-o com uma identidade de VPC ou endpoint suportada. No caminho por endpoint, SourceIp não substitui VpcSourceIp. Confirma também o tipo de identificador: SourceVpce espera um ID de endpoint, não o ID da VPC nem o ARN do bucket. Numa integração S3 para SNS, SourceArn identifica o bucket que desencadeou a notificação, não a role do operador que configurou o evento. Estas distinções ajudam a diagnosticar uma condição que parece correta por conter um identificador válido, mas compara propriedades diferentes. Mantém no registo de mudança uma amostra de contexto sem credenciais ou valores sensíveis.

4. Rever todas as interfaces de acesso

A política do endpoint é uma camada adicional e não substitui IAM nem políticas do recurso. O default permite acesso ao endpoint; isso não significa autorização universal sobre os dados. Para gateway endpoints, Principal deve ser *, com a identidade delimitada através de PrincipalArn quando necessário. Um access point S3 também precisa de autorização no bucket subjacente. As restrições do access point aplicam-se aos pedidos que o utilizam e não revogam automaticamente acessos diretos já existentes. Num projeto de segregação, inventaria os caminhos antigos e novos. Um teste negativo na interface nova é insuficiente quando a role ainda consegue ler pelo bucket. A aceitação deve acompanhar o requisito de acesso, não apenas a instalação de uma interface.

5. Compatibilizar clientes e políticas de segredos

Um cliente antigo pode enviar uma ACL incompatível com Bucket owner enforced. O erro AccessControlListNotSupported pede revisão do pedido e do modelo de autorização; acrescentar PutObjectAcl não altera o suporte da configuração. Para ler um segredo noutra conta, coordena identity policy, resource policy e a chave KMS. A chave AWS managed aws/secretsmanager não serve esse acesso entre contas; o desenho precisa de uma customer managed key autorizada. BlockPublicPolicy ajuda a controlar a resource policy do segredo, mas não demonstra sozinho todo o acesso efetivo. Mantém uma lista das políticas associadas, respetivos responsáveis e evidências de teste. Assim, uma equipa não encerra a sua parte deixando uma dependência de outra equipa presumida.

6. Aceitar o perímetro com testes representativos

Prepara casos de acesso legítimo e de acesso que deve ser negado. Inclui o caminho direto, a cadeia delegada, a origem de contingência e as interfaces antigas relevantes. Num fecho diário, uma correção urgente deve ter âmbito, aprovação e condição de reversão claros. Atribui um responsável ao rollback e repete o teste de acesso proibido depois da reversão, para detetar regressões de segregação. A exceção FAS deve representar a integração necessária, sem transformar qualquer chamada mediada por serviço numa autorização ampla. Entrega a RUN a localização da evidência, o owner de cada política e os sintomas que justificam escalada. Resume a decisão em termos observáveis: qual pedido passou, qual foi negado, sob que identidade e com que versão da política. O objetivo é preservar o requisito durante a recuperação e conseguir demonstrá-lo depois da janela.

# Original synthetic context classifier, not IAM policy evaluation.
# No credentials, network calls, or AWS changes.
def classify(row):
    if row.get("source_endpoint") == "vpce-approved":
        return "direct-candidate"
    if row.get("fas") and "s3.amazonaws.com" in row.get("via", []):
        return "delegated-candidate"
    return "review-path"
assert classify({"source_endpoint": "vpce-approved"}) == "direct-candidate"
assert classify({"source_endpoint": "vpce-other"}) == "review-path"
assert classify({"fas": True, "via": ["s3.amazonaws.com"]}) == "delegated-candidate"
assert classify({"fas": True, "via": ["other.example"]}) == "review-path"
assert classify({"service_principal": True}) == "review-path"
assert classify({}) == "review-path"
print("six request-context cases passed; candidates are not authorized requests")
NA PRÁTICA

Um teste direto passa, mas uma FAS falha por falta de SourceVpce; a equipa corrige a condição do caminho delegado e testa também pedidos proibidos.

Armadilhas comuns

Conectividade como permissão; service principal como FAS; CIDR como identidade única; interface nova como revogação de acessos antigos.

Tópicos relacionados: Federação e autorização KMS · Caminhos de infraestrutura e governação

Leva esta ideia contigo

O diagnóstico de acesso precisa de reconstruir o pedido e todas as camadas que o autorizam ou negam.

Criar conta

Referência: Forward access sessions · SCS-C03

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.