A Orion Retail armazena credenciais de banco de dados no AWS Secrets Manager na Conta B, criptografadas com uma chave KMS gerenciada pelo cliente na Conta B. Um microsserviço em execução na Conta A (função: arn:aws:iam::111111111111:role/OrdersAppRole) precisa de acesso somente leitura ao segredo. A equipe adicionou uma política do IAM à função permitindo secretsmanager:GetSecretValue no ARN do segredo, mas ainda recebe erros de AccessDenied do KMS. O que a equipe de segurança deve fazer para conceder acesso entre contas com privilégio mínimo?

Para acesso entre contas a um segredo criptografado com uma chave KMS gerenciada pelo cliente, são necessárias permissões em três pontos: a política de identidade do IAM na Conta A, a política baseada em recurso do Secrets Manager na Conta B e a política de chaves do KMS na Conta B. A política de identidade do IAM já permite secretsmanager:GetSecretValue. A política baseada em recurso do segredo deve ser atualizada para permitir que o OrdersAppRole da Conta A acesse o segredo. Além disso, a política de chaves do KMS na Conta B deve permitir que o OrdersAppRole execute kms:Decrypt na chave, pois o segredo está criptografado com ela. Replicar o segredo para a Conta A não é uma solução de privilégio mínimo e introduz complexidade e potencial para inconsistência. Criar endpoints de interface da VPC não resolve o problema de permissões de acesso ao KMS ou Secrets Manager. Apenas atualizar a política do IAM do OrdersAppRole não é suficiente, pois a política de chaves do KMS e a política baseada em recurso do segredo também precisam ser atualizadas para permitir o acesso entre contas.