View a markdown version of this page

Identity-based exemplos de políticas para verificação de prontidão no ARC - Amazon Application Recovery Controller (ARC)

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Identity-based exemplos de políticas para verificação de prontidão no ARC

Por padrão, usuários e perfis não têm permissão para criar ou modificar recursos do ARC. Para conceder permissão aos usuários para executar ações nos recursos que eles precisam, um administrador do IAM pode criar políticas do IAM.

Para aprender a criar uma política baseada em identidade do IAM ao usar esses documentos de política em JSON de exemplo, consulte Criar políticas do IAM (console) no Guia do usuário do IAM.

Para obter detalhes sobre ações e tipos de recurso definidos pelo ARC, por exemplo, o formato dos ARNs para cada um dos tipos de recurso, consulte Ações, recursos e chaves de condição para o Controlador de Recuperação de Aplicações (ARC) da Amazon na Referência de autorização de serviço.

Práticas recomendadas de política

Identity-based as políticas determinam se alguém pode criar, acessar ou excluir recursos do ARC em sua conta. Essas ações podem incorrer em custos para sua Conta da AWS. Ao criar ou editar políticas baseadas em identidade, siga estas diretrizes e recomendações:

  • Comece com políticas AWS gerenciadas e avance para permissões com privilégios mínimos — Para começar a conceder permissões a seus usuários e cargas de trabalho, use as políticas AWS gerenciadas que concedem permissões para muitos casos de uso comuns. Eles estão disponíveis em seu Conta da AWS. Recomendamos que você reduza ainda mais as permissões definindo políticas gerenciadas pelo AWS cliente que sejam específicas para seus casos de uso. Para saber mais, consulte Políticas gerenciadas pela AWS ou Políticas gerenciadas pela AWS para funções de trabalho no Guia do usuário do IAM.

  • Aplique permissões de privilégio mínimo: ao definir permissões com as políticas do IAM, conceda apenas as permissões necessárias para executar uma tarefa. Você faz isso definindo as ações que podem ser executadas em recursos específicos sob condições específicas, também conhecidas como permissões de privilégio mínimo. Para saber mais sobre como usar o IAM para aplicar permissões, consulte Políticas e permissões no IAM no Guia do usuário do IAM.

  • Use condições nas políticas do IAM para restringir ainda mais o acesso: é possível adicionar uma condição às políticas para limitar o acesso a ações e recursos. Por exemplo, é possível escrever uma condição de política para especificar que todas as solicitações devem ser enviadas usando SSL. Você também pode usar as condições para conceder acesso às ações de serviço se elas forem usadas por meio de um específico AWS service (Serviço da AWS), como CloudFormation. Para saber mais, consulte Elementos da política JSON do IAM: condição no Guia do usuário do IAM.

  • Use o IAM Access Analyzer para validar suas políticas do IAM a fim de garantir permissões seguras e funcionais: o IAM Access Analyzer valida as políticas novas e existentes para que elas sigam a linguagem de política do IAM (JSON) e as práticas recomendadas do IAM. O IAM Access Analyzer oferece mais de cem verificações de política e recomendações práticas para ajudar a criar políticas seguras e funcionais. Para saber mais, consulte Validação de políticas do IAM Access Analyzer no Guia do Usuário do IAM.

  • Exigir autenticação multifator (MFA) — Se você tiver um cenário que exija usuários do IAM ou um usuário raiz no seu Conta da AWS, ative o MFA para obter mais segurança. Para exigir MFA quando as operações de API forem chamadas, adicione condições de MFA às suas políticas. Para saber mais, consulte Configuração de acesso à API protegido por MFA no Guia do Usuário do IAM.

Para saber mais sobre as práticas recomendadas do IAM, consulte Práticas recomendadas de segurança no IAM no Guia do usuário do IAM.

Exemplo: Acesso ao console de verificação de prontidão

Para acessar o console do Controlador de Recuperação de Aplicações (ARC) da Amazon, você deve ter um conjunto mínimo de permissões. Essas permissões devem permitir que você liste e visualize detalhes sobre os recursos do ARC em seu Conta da AWS. Caso crie uma política baseada em identidade mais restritiva que as permissões mínimas necessárias, o console não funcionará como pretendido para entidades (usuários ou perfis) com essa política.

Você não precisa permitir permissões mínimas de console para usuários que estão fazendo chamadas somente para a API AWS CLI ou para a AWS API. Em vez disso, permita o acesso somente a ações que correspondam à operação de API que estiverem tentando executar.

Para garantir que usuários e funções ainda possam usar o console de verificação de prontidão ao permitir o acesso somente a operações específicas da API, anexe também uma política ReadOnly AWS gerenciada para verificação de prontidão às entidades. Para saber mais, consulte a Página de políticas gerenciadas de verificação de prontidão ou Adicionar permissões a um usuário no Guia do usuário do IAM.

Para realizar algumas tarefas, os usuários devem ter permissão para criar o perfil vinculado a serviço associado à verificação de prontidão no ARC. Para saber mais, consulte Usando a função vinculada ao serviço para verificação de prontidão no ARC.

Para conceder acesso total aos usuários para uso dos atributos de verificação de prontidão por meio do console, anexe uma política semelhante à seguinte ao usuário:

JSON
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "route53-recovery-readiness:CreateCell", "route53-recovery-readiness:CreateCrossAccountAuthorization", "route53-recovery-readiness:CreateReadinessCheck", "route53-recovery-readiness:CreateRecoveryGroup", "route53-recovery-readiness:CreateResourceSet", "route53-recovery-readiness:DeleteCell", "route53-recovery-readiness:DeleteCrossAccountAuthorization", "route53-recovery-readiness:DeleteReadinessCheck", "route53-recovery-readiness:DeleteRecoveryGroup", "route53-recovery-readiness:DeleteResourceSet", "route53-recovery-readiness:GetArchitectureRecommendations", "route53-recovery-readiness:GetCell", "route53-recovery-readiness:GetCellReadinessSummary", "route53-recovery-readiness:GetReadinessCheck", "route53-recovery-readiness:GetReadinessCheckResourceStatus", "route53-recovery-readiness:GetReadinessCheckStatus", "route53-recovery-readiness:GetRecoveryGroup", "route53-recovery-readiness:GetRecoveryGroupReadinessSummary", "route53-recovery-readiness:GetResourceSet", "route53-recovery-readiness:ListCells", "route53-recovery-readiness:ListCrossAccountAuthorizations", "route53-recovery-readiness:ListReadinessChecks", "route53-recovery-readiness:ListRecoveryGroups", "route53-recovery-readiness:ListResourceSets", "route53-recovery-readiness:ListRules", "route53-recovery-readiness:UpdateCell", "route53-recovery-readiness:UpdateReadinessCheck", "route53-recovery-readiness:UpdateRecoveryGroup", "route53-recovery-readiness:UpdateResourceSet" ], "Resource": "*" } ] }

Exemplos: ações da API de verificação de prontidão para verificação de prontidão

Para garantir que um usuário possa usar as ações de API do ARC para trabalhar com o ambiente de gerenciamento de verificação de prontidão do ARC (por exemplo, criar grupos de recuperação, conjuntos de recursos e verificações de prontidão), anexe uma política que corresponda às operações de API com as quais o usuário precisa trabalhar, conforme descrito abaixo.

Para realizar algumas tarefas, os usuários devem ter permissão para criar o perfil vinculado a serviço associado à verificação de prontidão no ARC. Para saber mais, consulte Usando a função vinculada ao serviço para verificação de prontidão no ARC.

Para trabalhar com as operações de API para verificação de prontidão, anexe uma política semelhante à seguinte ao usuário:

JSON
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "route53-recovery-readiness:CreateCell", "route53-recovery-readiness:CreateCrossAccountAuthorization", "route53-recovery-readiness:CreateReadinessCheck", "route53-recovery-readiness:CreateRecoveryGroup", "route53-recovery-readiness:CreateResourceSet", "route53-recovery-readiness:DeleteCell", "route53-recovery-readiness:DeleteCrossAccountAuthorization", "route53-recovery-readiness:DeleteReadinessCheck", "route53-recovery-readiness:DeleteRecoveryGroup", "route53-recovery-readiness:DeleteResourceSet", "route53-recovery-readiness:GetArchitectureRecommendations", "route53-recovery-readiness:GetCell", "route53-recovery-readiness:GetCellReadinessSummary", "route53-recovery-readiness:GetReadinessCheck", "route53-recovery-readiness:GetReadinessCheckResourceStatus", "route53-recovery-readiness:GetReadinessCheckStatus", "route53-recovery-readiness:GetRecoveryGroup", "route53-recovery-readiness:GetRecoveryGroupReadinessSummary", "route53-recovery-readiness:GetResourceSet", "route53-recovery-readiness:ListCells", "route53-recovery-readiness:ListCrossAccountAuthorizations", "route53-recovery-readiness:ListReadinessChecks", "route53-recovery-readiness:ListRecoveryGroups", "route53-recovery-readiness:ListResourceSets", "route53-recovery-readiness:ListRules", "route53-recovery-readiness:ListTagsForResources", "route53-recovery-readiness:UpdateCell", "route53-recovery-readiness:UpdateReadinessCheck", "route53-recovery-readiness:UpdateRecoveryGroup", "route53-recovery-readiness:UpdateResourceSet", "route53-recovery-readiness:TagResource", "route53-recovery-readiness:UntagResource" ], "Resource": "*" } ] }