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 and Access Management (IAM) no Amazon EMR Sem Servidor AWS Identity and Access Management (IAM) é uma ferramenta AWS service (Serviço da AWS) que ajuda o administrador a controlar com segurança o acesso aos AWS recursos. Os administradores do IAM controlam quem pode ser *autenticado* (conectado) e *autorizado* (ter permissões) para utilizar os recursos do Amazon EMR Sem Servidor. O IAM é um AWS service (Serviço da AWS) que você pode usar sem custo adicional. **Topics** + [Público](#security_iam_audience) + [Autenticação com identidades](#security_iam_authentication) + [Gerenciar o acesso usando políticas](#security_iam_access-manage) + [Como o EMR Sem Servidor funciona com o IAM](security-iam-serverless.md) + [Uso de perfis vinculados ao serviço para o EMR Sem Servidor](using-service-linked-roles.md) + [Perfis de runtime do trabalho para o Amazon EMR Sem Servidor](security-iam-runtime-role.md) + [Exemplos de políticas de acesso de usuários do EMR Sem Servidor](security-iam-user-access-policies.md) + [Políticas para controle de acesso baseado em etiquetas](security-iam-TBAC.md) + [Exemplos de políticas baseadas em identidade do EMR Sem Servidor](security-iam-id-based-policy-examples.md) + [Atualizações sem servidor do Amazon EMR para políticas gerenciadas AWS](#security-iam-awsmanpol-updates) + [Solução de problemas de identidade e acesso da Amazon EMR Sem Servidor](security_iam_troubleshoot.md) ## Público A forma como você usa AWS Identity and Access Management (IAM) difere com base na sua função: + **Usuário do serviço**: solicite permissões ao seu administrador se você não conseguir acessar os atributos (consulte [Solução de problemas de identidade e acesso da Amazon EMR Sem Servidor](security_iam_troubleshoot.md)). + **Administrador do serviço**: determine o acesso do usuário e envie solicitações de permissão (consulte [Identity and Access Management (IAM) no Amazon EMR Sem Servidor](#security_iam_service-with-iam)) + **Administrador do IAM**: escreva políticas para gerenciar o acesso (consulte [Exemplos de políticas baseadas em identidade para o EMR Sem Servidor](security-iam-serverless.md#security_iam_id-based-policy-examples)) ## Autenticação com identidades A autenticação é a forma como você faz login AWS usando suas credenciais de identidade. Você deve estar autenticado como usuário do IAM ou assumindo uma função do IAM. Usuário raiz da conta da AWS Você pode fazer login como uma identidade federada usando credenciais de uma fonte de identidade como Centro de Identidade do AWS IAM (IAM Identity Center), autenticação de login único ou credenciais. Google/Facebook Para ter mais informações sobre como fazer login, consulte [Como fazer login em sua Conta da AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) no *Guia do usuário do Início de Sessão da AWS *. Para acesso programático, AWS fornece um SDK e uma CLI para assinar solicitações criptograficamente. Para ter mais informações, consulte [AWS Signature Version 4 para solicitações de API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) no *Guia do usuário do IAM*. ### Conta da AWS usuário root Ao criar um Conta da AWS, você começa com uma identidade de login chamada *usuário Conta da AWS raiz* que tem acesso completo a todos Serviços da AWS os recursos. É altamente recomendável não usar o usuário-raiz em tarefas diárias. Consulte as tarefas que exigem credenciais de usuário-raiz em [Tarefas que exigem credenciais de usuário-raiz](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) no *Guia do usuário do IAM*. ### Identidade federada Como prática recomendada, exija que os usuários humanos usem a federação com um provedor de identidade para acessar Serviços da AWS usando credenciais temporárias. Uma *identidade federada* é um usuário do seu diretório corporativo, provedor de identidade da web ou Directory Service que acessa Serviços da AWS usando credenciais de uma fonte de identidade. As identidades federadas assumem funções que oferecem credenciais temporárias. Para o gerenciamento de acesso centralizado, recomendamos Centro de Identidade do AWS IAM. Para saber mais, consulte [O que é o IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) no *Guia do usuário do Centro de Identidade do AWS IAM *. ### Usuários e grupos do IAM Um *[usuário do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* é uma identidade com permissões específicas para uma única pessoa ou aplicação. É recomendável usar credenciais temporárias, em vez de usuários do IAM com credenciais de longo prazo. Para obter mais informações, consulte [Exigir que usuários humanos usem a federação com um provedor de identidade para acessar AWS usando credenciais temporárias](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) no *Guia do usuário do IAM*. Um [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) especifica um conjunto de usuários do IAM e facilita o gerenciamento de permissões para grandes conjuntos de usuários. Para ter mais informações, consulte [Casos de uso de usuários do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) no *Guia do usuário do IAM*. ### Perfis do IAM Uma *[perfil do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* é uma identidade com permissões específicas que oferece credenciais temporárias. Você pode assumir uma função [mudando de um usuário para uma função do IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) ou chamando uma operação de AWS API AWS CLI ou. Para saber mais, consulte [Métodos para assumir um perfil](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) no *Manual do usuário do IAM*. Os perfis do IAM são úteis para acesso de usuário federado, permissões de usuário do IAM temporárias, acesso entre contas, acesso entre serviços e aplicações em execução no Amazon EC2. Consulte mais informações em [Acesso a recursos entre contas no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) no *Guia do usuário do IAM*. ## Gerenciar o acesso usando políticas Você controla o acesso AWS criando políticas e anexando-as a AWS identidades ou recursos. Uma política define permissões quando associada a uma identidade ou recurso. AWS avalia essas políticas quando um diretor faz uma solicitação. A maioria das políticas é armazenada AWS como documentos JSON. Para ter mais informações sobre documentos de política JSON, consulte [Visão geral das políticas JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) no *Guia do usuário do IAM*. Por meio de políticas, os administradores especificam quem tem acesso a que, definindo qual **entidade principal** pode realizar **ações** em quais **recursos** e sob quais **condições**. Por padrão, usuários e perfis não têm permissões. Um administrador do IAM cria políticas do IAM e as adiciona aos perfis, os quais os usuários podem então assumir. As políticas do IAM definem permissões, independentemente do método usado para realizar a operação. ### Políticas baseadas em identidade As políticas baseadas em identidade são documentos de políticas de permissão JSON que você anexa a uma identidade (usuário, grupo ou perfil). Essas políticas controlam quais ações as identidades podem realizar, em quais recursos e sob quais condições. Para saber como criar uma política baseada em identidade, consulte [Definir permissões personalizadas do IAM com as políticas gerenciadas pelo cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) no *Guia do Usuário do IAM*. As políticas baseadas em identidade podem ser políticas *em linha* (incorporadas diretamente em uma única identidade) ou *políticas gerenciadas* (políticas autônomas anexadas a várias identidades). Para saber como escolher entre uma política gerenciada e políticas em linha, consulte [Escolher entre políticas gerenciadas e políticas em linha](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) no *Guia do usuário do IAM*. ### Políticas baseadas em recursos Políticas baseadas em recursos são documentos de políticas JSON que você anexa a um recurso. Entre os exemplos estão *políticas de confiança de perfil* do IAM e *políticas de bucket* do Amazon S3. Em serviços compatíveis com políticas baseadas em recursos, os administradores de serviço podem usá-las para controlar o acesso a um recurso específico. É necessário [especificar uma entidade principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) em uma política baseada em recursos. Políticas baseadas em recursos são políticas em linha localizadas nesse serviço. Você não pode usar políticas AWS gerenciadas do IAM em uma política baseada em recursos. ### Outros tipos de política AWS oferece suporte a tipos de políticas adicionais que podem definir o máximo de permissões concedidas por tipos de políticas mais comuns: + **Limites de permissões**: definem o número máximo de permissões que uma política baseada em identidade pode conceder a uma entidade do IAM. Para saber mais sobre limites de permissões, consulte [Limites de permissões para identidades do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) no *Guia do usuário do IAM*. + **Políticas de controle de serviço (SCPs)** — Especifique as permissões máximas para uma organização ou unidade organizacional em AWS Organizations. Para saber mais, consulte [Políticas de controle de serviço](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) no *Guia do usuário do AWS Organizations *. + **Políticas de controle de recursos (RCPs)** — Defina o máximo de permissões disponíveis para recursos em suas contas. Para obter mais informações, consulte [Políticas de controle de recursos (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) no *Guia AWS Organizations do usuário*. + **Políticas de sessão**: políticas avançadas transmitidas como um parâmetro durante a criação de uma sessão temporária para um perfil ou um usuário federado. Para saber mais, consulte [Políticas de sessão](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) no *Guia do usuário do IAM*. ### Vários tipos de política Quando vários tipos de política são aplicáveis a uma solicitação, é mais complicado compreender as permissões resultantes. Para saber como AWS determinar se uma solicitação deve ser permitida quando vários tipos de políticas estão envolvidos, consulte [Lógica de avaliação de políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) no *Guia do usuário do IAM*. # Como o EMR Sem Servidor funciona com o IAM Antes de usar o IAM para gerenciar o acesso ao Amazon EMR Sem Servidor, entenda que recursos do IAM estão disponíveis para uso com o Amazon EMR Sem Servidor. **Recursos do IAM que você pode usar com o EMR Sem Servidor** | Recurso do IAM | Suporte do Amazon EMR Sem Servidor | | --- | --- | | [Políticas baseadas em identidade](#security-iam-id-based-policies) | Sim | | [Políticas baseadas em recurso](#security-iam-resource-based-policies) | Não | | [Ações de políticas](#security-iam-id-based-policies-actions) | Sim | | [Recursos de políticas](#security-iam-id-based-policies-resources) | Sim | | [Chaves de condição de políticas](#security-iam-id-based-policies-conditionkeys) | Não | | [ACLs](#security-iam-acls) | Não | | [ABAC (tags em políticas)](#security-iam-tags) | Sim | | [Credenciais temporárias](#security-iam-roles-tempcreds) | Sim | | [Permissões de entidade principal](#security-iam-principal-permissions) | Sim | | [Perfis de serviço](#security-iam-roles-service) | Não | | [Perfis vinculados ao serviço](#security-iam-roles-service-linked) | Sim | *Para obter uma visão de alto nível de como o EMR Serverless e AWS outros serviços funcionam com a maioria dos recursos do IAM, consulte os [serviços que funcionam com AWS o](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) IAM no Guia do usuário do IAM.* ## Políticas baseadas em identidade do EMR Sem Servidor **Compatível com políticas baseadas em identidade:** sim As políticas baseadas em identidade são documentos de políticas de permissões JSON que podem ser anexados a uma identidade, como usuário do IAM, grupo de usuários ou perfil. Essas políticas controlam quais ações os usuários e perfis podem realizar, em quais recursos e em que condições. Para saber como criar uma política baseada em identidade, consulte [Definir permissões personalizadas do IAM com as políticas gerenciadas pelo cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) no *Guia do Usuário do IAM*. Com as políticas baseadas em identidade do IAM, é possível especificar ações e recursos permitidos ou negados, assim como as condições sob as quais as ações são permitidas ou negadas. Para saber mais sobre todos os elementos que podem ser usados em uma política JSON, consulte [Referência de elemento de política JSON do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) no *Guia do usuário do IAM*. ### Exemplos de políticas baseadas em identidade para o EMR Sem Servidor Para acessar exemplos de políticas baseadas em identidade do Amazon EMR Sem Servidor, consulte [Exemplos de políticas baseadas em identidade do EMR Sem Servidor](security-iam-id-based-policy-examples.md). ## Políticas baseadas em recursos no EMR Sem Servidor **Compatibilidade com políticas baseadas em recursos:** não Políticas baseadas em recursos são documentos de políticas JSON que você anexa a um recurso. São exemplos de políticas baseadas em recursos as *políticas de confiança de perfil* do IAM e as *políticas de bucket* do Amazon S3. Em serviços compatíveis com políticas baseadas em recursos, os administradores de serviço podem usá-las para controlar o acesso a um recurso específico. Para o atributo ao qual a política está anexada, a política define quais ações uma entidade principal especificado pode executar nesse atributo e em que condições. É necessário [especificar uma entidade principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) em uma política baseada em recursos. Os diretores podem incluir contas, usuários, funções, usuários federados ou. Serviços da AWS Para permitir o acesso entre contas, é possível especificar uma conta inteira ou as entidades do IAM em outra conta como a entidade principal em uma política baseada em recursos. Consulte mais informações em [Acesso a recursos entre contas no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) no *Guia do usuário do IAM*. ## Ações de políticas do EMR Sem Servidor **Compatível com ações de políticas:** sim Os administradores podem usar políticas AWS JSON para especificar quem tem acesso ao quê. Ou seja, qual **entidade principal** pode executar **ações** em quais **recursos** e em que **condições**. O elemento `Action` de uma política JSON descreve as ações que podem ser usadas para permitir ou negar acesso em uma política. Incluem ações em uma política para conceder permissões para executar a operação associada. Para ver uma lista de ações do EMR Sem Servidor, consulte [Ações, recursos e chaves de condição para o Amazon EMR Sem Servidor](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonemrserverless.html) na *Referência de autorização do serviço*. As ações de políticas no EMR Sem Servidor usam o prefixo a seguir antes da ação. ``` emr-serverless ``` Para especificar várias ações em uma única declaração, separe-as com vírgulas. ``` "Action": [ "emr-serverless:action1", "emr-serverless:action2" ] ``` Para acessar exemplos de políticas baseadas em identidade do Amazon EMR Sem Servidor, consulte [Exemplos de políticas baseadas em identidade do EMR Sem Servidor](security-iam-id-based-policy-examples.md). ## Recursos de políticas do EMR Sem Servidor **Compatível com recursos de políticas:** sim Os administradores podem usar políticas AWS JSON para especificar quem tem acesso ao quê. Ou seja, qual **entidade principal** pode executar **ações** em quais **recursos** e em que **condições**. O elemento de política JSON `Resource` especifica o objeto ou os objetos aos quais a ação se aplica. Como prática recomendada, especifique um recurso usando seu [nome do recurso da Amazon (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Para ações que não oferecem compatibilidade com permissões em nível de recurso, use um curinga (\$1) para indicar que a instrução se aplica a todos os recursos. ``` "Resource": "*" ``` *Para consultar uma lista dos tipos de recursos sem servidor do Amazon EMR e seus ARNs, consulte Recursos [definidos pelo Amazon EMR Serverless](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticmapreduce.html#amazonelasticmapreduce-resources-for-iam-policies) na Referência de autorização de serviço.* Para saber com quais ações especificar o ARN de cada recurso, consulte [Ações, recursos e chaves de condição para Amazon EMR Sem Servidor](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonemrserverless.html). Para acessar exemplos de políticas baseadas em identidade do Amazon EMR Sem Servidor, consulte [Exemplos de políticas baseadas em identidade do EMR Sem Servidor](security-iam-id-based-policy-examples.md). ## Chaves de condição de política do EMR Sem Servidor **Suporte para chaves de condições de política** | | | | --- |--- | | Suporta chaves de condição de política específicas de serviço | Não | Os administradores podem usar políticas AWS JSON para especificar quem tem acesso ao quê. Ou seja, qual **entidade principal** pode executar **ações** em quais **recursos** e em que **condições**. O elemento `Condition` especifica quando as instruções são executadas com base em critérios definidos. É possível criar expressões condicionais que usem [agentes de condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), como “igual a” ou “menor que”, para fazer a condição da política corresponder aos valores na solicitação. Para ver todas as chaves de condição AWS globais, consulte as [chaves de contexto de condição AWS global](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) no *Guia do usuário do IAM*. Para obter uma lista de chaves de condição do Amazon EMR Sem Servidor, das ações e dos recursos que você pode usar, consulte [Actions, resources, and condition keys for Amazon EMR Sem Servidor](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonemrserverless.html) na *Referência de autorização do serviço*. Todas as ações do Amazon EC2 oferecem suporte às chaves de condição `aws:RequestedRegion` e `ec2:Region`. Para obter mais informações, consulte [Exemplo: Restringir o acesso a uma região específica](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-region). ## Listas de controle de acesso (ACLs) no EMR Serverless **Suportes ACLs:** Não As listas de controle de acesso (ACLs) controlam quais diretores (membros da conta, usuários ou funções) têm permissões para acessar um recurso. ACLs são semelhantes às políticas baseadas em recursos, embora não usem o formato de documento de política JSON. ## Controle de acesso por atributo (ABAC) com o EMR Sem Servidor **Suporte ao controle de acesso por atributo (ABAC)** | | | | --- |--- | | Oferece compatibilidade com ABAC (tags em políticas) | Sim | O controle de acesso por atributo (ABAC) é uma estratégia de autorização que define permissões com base em atributos chamados de tags. Você pode anexar tags a entidades e AWS recursos do IAM e, em seguida, criar políticas ABAC para permitir operações quando a tag do diretor corresponder à tag no recurso. Para controlar o acesso baseado em tags, forneça informações sobre as tags no [elemento de condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) de uma política usando as `aws:ResourceTag/key-name`, `aws:RequestTag/key-name` ou chaves de condição `aws:TagKeys`. Se um serviço for compatível com as três chaves de condição para cada tipo de recurso, o valor será **Sim** para o serviço. Se um serviço for compatível com as três chaves de condição somente para alguns tipos de recursos, o valor será **Parcial** Para saber mais sobre o ABAC, consulte [Definir permissões com autorização do ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) no *Guia do usuário do IAM*. Para visualizar um tutorial com etapas para configurar o ABAC, consulte [Usar controle de acesso por atributo (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) no *Guia do usuário do IAM*. ## Uso de credenciais temporárias com o EMR Sem Servidor **Compatível com credenciais temporárias:** sim As credenciais temporárias fornecem acesso de curto prazo aos AWS recursos e são criadas automaticamente quando você usa a federação ou troca de funções. AWS recomenda que você gere credenciais temporárias dinamicamente em vez de usar chaves de acesso de longo prazo. Para ter mais informações, consulte [Credenciais de segurança temporárias no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) e [Serviços da Serviços da AWS que funcionam com o IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) no *Guia do usuário do IAM*. ## Permissões de entidades principais entre serviços do EMR Sem Servidor **Compatibilidade com o recurso de encaminhamento de sessões de acesso (FAS):** sim As sessões de acesso direto (FAS) usam as permissões do principal chamando um AWS service (Serviço da AWS), combinadas com a solicitação AWS service (Serviço da AWS) de fazer solicitações aos serviços posteriores. Para obter detalhes da política ao fazer solicitações de FAS, consulte [Sessões de acesso direto](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html). ## Perfis de serviço do EMR Sem Servidor | | | | --- |--- | | Oferece suporte a perfis de serviço | Não | ## Perfis vinculados ao serviço do EMR Sem Servidor | | | | --- |--- | | Oferece suporte a perfis vinculados ao serviço | Sim | Para obter detalhes sobre como criar ou gerenciar perfis vinculados a serviços, consulte [Serviços da AWS que funcionam com o IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Encontre um serviço na tabela que inclua um `Yes` na coluna **Perfil vinculado ao serviço**. Escolha o link **Sim** para acessar a documentação do perfil vinculado a serviço desse serviço. # Uso de perfis vinculados ao serviço para o EMR Sem Servidor [O Amazon EMR Serverless usa funções vinculadas a serviços AWS Identity and Access Management (IAM).](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) Um perfil vinculado ao serviço é um tipo exclusivo de perfil do IAM vinculado diretamente ao EMR Sem Servidor. As funções vinculadas ao serviço são predefinidas pelo EMR Serverless e incluem todas as permissões que o serviço exige para chamar outros serviços em seu nome. AWS Um perfil vinculado ao serviço facilita a configuração do EMR Sem Servidor porque você não precisa adicionar as permissões necessárias manualmente. O EMR Sem Servidor define as permissões desses perfis vinculados ao serviço e, exceto se definido de outra forma, somente o EMR Sem Servidor pode assumir os próprios perfis. As permissões definidas incluem a política de confiança e a política de permissões, que não pode ser anexada a nenhuma outra entidade do IAM. Um perfil vinculado ao serviço poderá ser excluído somente após excluir seus atributos relacionados. Isso protege seus recursos do EMR Sem Servidor, porque você não pode remover a permissão por engano para acessá-los. Para obter informações sobre outros serviços compatíveis com perfis vinculados a serviços, consulte [Serviços da AWS que funcionam com o IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) e procure os serviços que apresentam **Sim** na coluna **Perfis vinculados a serviços**. Escolha um **Sim** com um link para acessar a documentação do perfil vinculado para esse serviço. ## Permissões de perfil vinculado ao serviço do EMR Sem Servidor O EMR Serverless usa a função vinculada ao serviço chamada **AWSServiceRoleForAmazonEMRServerless**para permitir que ele ligue em seu nome. AWS APIs A função AWSService RoleForAmazon EMRServerless vinculada ao serviço confia nos seguintes serviços para assumir a função: + `ops.emr-serverless.amazonaws.com` A política de permissões do perfil chamada `AmazonEMRServerlessServiceRolePolicy` permite que o EMR Sem Servidor conclua as ações a seguir nos recursos especificados. **nota** Como o conteúdo da política gerenciada muda, a política mostrada aqui pode estar desatualizada. Veja a maioria das up-to-date políticas [da Amazon EMRServerless ServiceRolePolicy](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRServerlessServiceRolePolicy) no Console de gerenciamento da AWS. + Ação: `ec2:CreateNetworkInterface` + Ação: `ec2:DeleteNetworkInterface` + Ação: `ec2:DescribeNetworkInterfaces` + Ação: `ec2:DescribeSecurityGroups` + Ação: `ec2:DescribeSubnets` + Ação: `ec2:DescribeVpcs` + Ação: `ec2:DescribeDhcpOptions` + Ação: `ec2:DescribeRouteTables` + Ação: `cloudwatch:PutMetricData` A política a seguir é a `AmazonEMRServerlessServiceRolePolicy` completa. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "EC2PolicyStatement", "Effect": "Allow", "Action": [ "ec2:CreateNetworkInterface", "ec2:DeleteNetworkInterface", "ec2:DescribeNetworkInterfaces", "ec2:DescribeSecurityGroups", "ec2:DescribeSubnets", "ec2:DescribeVpcs", "ec2:DescribeDhcpOptions", "ec2:DescribeRouteTables" ], "Resource": [ "*" ] }, { "Sid": "CloudWatchPolicyStatement", "Effect": "Allow", "Action": [ "cloudwatch:PutMetricData" ], "Resource": [ "*" ], "Condition": { "StringEquals": { "cloudwatch:namespace": [ "AWS/EMRServerless", "AWS/Usage" ] } } } ] } ``` ------ A política de confiança a seguir está anexada a esse perfil para permitir que a entidade principal do EMR Sem Servidor assuma o perfil. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": "arn:aws:iam::123456789012:role/aws-service-role/emr-serverless.amazonaws.com/AWSServiceRoleForEMRServerless", "Sid": "AllowSTSAssumerole" } ] } ``` ------ É necessário configurar as permissões para permitir que uma entidade do IAM (como um usuário, grupo ou perfil) crie, edite ou exclua uma função vinculada ao serviço. Para obter mais informações, consulte [Permissões de perfil vinculado a serviços](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) no *Guia do usuário do IAM*. ## Criação de um perfil vinculado ao serviço do EMR Sem Servidor Não é necessário criar manualmente um perfil vinculado ao serviço. Quando você cria um novo aplicativo EMR Serverless no ( Console de gerenciamento da AWS usando o EMR Studio), no AWS CLI ou na API, o EMR Serverless cria a função AWS vinculada ao serviço para você. É necessário configurar as permissões para permitir que uma entidade do IAM (como um usuário, grupo ou perfil) crie, edite ou exclua uma função vinculada ao serviço. **Para criar a função AWSService RoleForAmazon EMRServerless vinculada ao serviço usando o IAM** Adicione a instrução a seguir à política de permissões da entidade do IAM que precisa criar o perfil vinculado ao serviço. ``` { "Effect": "Allow", "Action": [ "iam:CreateServiceLinkedRole" ], "Resource": "arn:aws:iam::*:role/aws-service-role/ops.emr-serverless.amazonaws.com/AWSServiceRoleForAmazonEMRServerless*", "Condition": {"StringLike": {"iam:AWSServiceName": "ops.emr-serverless.amazonaws.com"}} } ``` Se você excluir esse perfil vinculado ao serviço e precisar criá-lo novamente, use esse mesmo processo para recriar o perfil na sua conta. Ao criar uma aplicação do EMR Sem Servidor, o EMR Sem Servidor cria o perfil vinculado ao serviço para você novamente. Você também pode usar o console do IAM para criar um perfil vinculado ao serviço com o caso de uso **EMR Sem Servidor**. Na AWS CLI ou na AWS API, crie uma função vinculada ao serviço com o nome do `ops.emr-serverless.amazonaws.com` serviço. Para obter mais informações, consulte [Criar um perfil vinculado ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role) no *Guia do usuário do IAM*. Se você excluir essa função vinculada ao serviço, use esse mesmo processo para criar a função novamente. ## Edição de um perfil vinculado ao serviço do EMR Sem Servidor O EMR Serverless não permite que você edite a função AWSService RoleForAmazon EMRServerless vinculada ao serviço porque várias entidades podem fazer referência à função. Você não pode editar a política do IAM AWS de propriedade que a função vinculada ao serviço do EMR Serverless usa, pois ela contém todas as permissões necessárias que o EMR Serverless precisa. No entanto, você poderá editar a descrição do perfil usando o IAM. **Para editar a descrição da função AWSService RoleForAmazon EMRServerless vinculada ao serviço usando o IAM** Adicione a instrução abaixo à política de permissões da entidade do IAM para a qual precise editar a descrição de um perfil vinculado ao serviço. ``` { "Effect": "Allow", "Action": [ "iam: UpdateRoleDescription" ], "Resource": "arn:aws:iam::*:role/aws-service-role/ops.emr-serverless.amazonaws.com/AWSServiceRoleForAmazonEMRServerless*", "Condition": {"StringLike": {"iam:AWSServiceName": "ops.emr-serverless.amazonaws.com"}} } ``` Para obter mais informações, consulte [Editar um perfil vinculado ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) no *Guia do usuário do IAM*. ## Exclusão de um perfil vinculado a serviço do EMR Sem Servidor Se você não precisar mais usar um recurso ou serviço que requer um perfil vinculado ao serviço, é recomendável excluí-lo. Dessa forma, você não tem uma entidade não utilizada que não seja monitorada ativamente ou mantida. Contudo, você deve excluir todas as aplicações do EMR Sem Servidor em todas as regiões para poder excluir o perfil vinculado ao serviço. **nota** Se o serviço EMR Sem Servidor estiver usando o perfil quando você tenta excluir os recursos associados ao perfil, a exclusão poderá falhar. Se isso acontecer, espere alguns minutos e tente a operação novamente. **Para excluir a função AWSService RoleForAmazon EMRServerless vinculada ao serviço usando o IAM** Adicione a instrução a seguir à política de permissões da entidade do IAM que precisa excluir um perfil vinculado ao serviço. ``` { "Effect": "Allow", "Action": [ "iam:DeleteServiceLinkedRole", "iam:GetServiceLinkedRoleDeletionStatus" ], "Resource": "arn:aws:iam::*:role/aws-service-role/ops.emr-serverless.amazonaws.com/AWSServiceRoleForAmazonEMRServerless*", "Condition": {"StringLike": {"iam:AWSServiceName": "ops.emr-serverless.amazonaws.com"}} } ``` **Como excluir manualmente o perfil vinculado ao serviço usando o IAM** Use o console do IAM AWS CLI, o ou a AWS API para excluir a função AWSService RoleForAmazon EMRServerless vinculada ao serviço. Para obter mais informações, consulte [Excluir um perfil vinculado ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) no *Guia do usuário do IAM*. ## Regiões compatíveis com perfis vinculados ao serviço do EMR Sem Servidor O EMR Sem Servidor é compatível com a utilização de perfis vinculados ao serviço em todas as regiões em que o serviço está disponível. Para obter mais informações, consulte [Regiões e endpoints da AWS](https://docs.aws.amazon.com/general/latest/gr/rande.html). # Perfis de runtime do trabalho para o Amazon EMR Sem Servidor Você pode especificar as permissões do perfil do IAM que a execução de trabalho do EMR Sem Servidor pode assumir ao chamar outros serviços em seu nome. Isso inclui acesso ao Amazon S3 para quaisquer fontes de dados, destinos e outros AWS recursos, como clusters do Amazon Redshift e tabelas do DynamoDB. Para saber mais sobre como criar um perfil, consulte [Criação de um perfil de runtime de trabalhos](getting-started.md#gs-runtime-role). **Exemplos de políticas de runtime** Você pode anexar uma política de runtime, como a mostrada a seguir, a um perfil de runtime. A seguinte política de runtime de trabalhos permite: + Acesso de leitura aos buckets do Amazon S3 com exemplos do EMR. + Acesso total aos buckets do S3. + Crie e leia o acesso ao AWS Glue Data Catalog. Para adicionar acesso a outros AWS recursos, como o DynamoDB, você precisará incluir permissões para eles na política ao criar a função de tempo de execução. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ReadAccessForEMRSamples", "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::*.elasticmapreduce", "arn:aws:s3:::*.elasticmapreduce/*" ] }, { "Sid": "FullAccessToS3Bucket", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:ListBucket", "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket", "arn:aws:s3:::amzn-s3-demo-bucket/*" ] }, { "Sid": "GlueCreateAndReadDataCatalog", "Effect": "Allow", "Action": [ "glue:GetDatabase", "glue:CreateDatabase", "glue:GetDataBases", "glue:CreateTable", "glue:GetTable", "glue:UpdateTable", "glue:DeleteTable", "glue:GetTables", "glue:GetPartition", "glue:GetPartitions", "glue:CreatePartition", "glue:BatchCreatePartition", "glue:GetUserDefinedFunctions" ], "Resource": [ "*" ] } ] } ``` ------ **Transmissão de privilégios de perfil** Você pode anexar políticas de permissões do IAM ao perfil de um usuário para permitir que ele passe apenas perfis aprovados. Isso permite que os administradores controlem quais usuários podem transmitir perfis específicos de runtime de trabalho para trabalhos do EMR Sem Servidor. Para saber mais sobre como definir permissões, consulte [Conceder permissões a um usuário para passar uma função para um AWS serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html). Confira a seguir um exemplo de política que permite transmitir um perfil de runtime de trabalhos para a entidade principal de serviço do EMR Sem Servidor. ``` { "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::1234567890:role/JobRuntimeRoleForEMRServerless", "Condition": { "StringLike": { "iam:PassedToService": "emr-serverless.amazonaws.com" } } } ``` ## Políticas de permissão gerenciada associadas a perfis de runtime Ao enviar execuções de trabalhos para o EMR Sem Servidor por meio do console do EMR Studio, há uma etapa em que você escolhe um **Perfil de runtime** para associar à sua aplicação. Há políticas gerenciadas subjacentes associadas a cada seleção no console que é importante conhecer. As três seleções são: 1. **Todos os buckets** — Quando você escolhe essa opção, ela especifica a política FullAccess AWS gerenciada do [AmazonS3](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonS3FullAccess.html), que fornece acesso total a todos os buckets. 1. **Buckets específicos**: especifica o identificador de Nome de recurso da Amazon (ARN) de cada bucket que você escolhe. Não há uma política gerenciada subjacente incluída. 1. **Nenhuma**: nenhuma permissão de política gerenciada está incluída. Sugerimos adicionar buckets específicos. Se você escolher todos os buckets, lembre-se de que isso define o acesso total a todos os buckets. # Exemplos de políticas de acesso de usuários do EMR Sem Servidor Você pode configurar políticas refinadas para seus usuários, dependendo das ações que cada um deve executar ao interagir com aplicações do EMR Sem Servidor. As políticas a seguir são exemplos que podem ajudar na configuração das permissões apropridadas para os usuários. Esta seção se concentra somente nas políticas do EMR Sem Servidor. Para obter exemplos de políticas de usuário do EMR Studio, consulte [Configurar permissões de usuário do EMR Studio](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-studio-user-permissions.html#emr-studio-advanced-permissions-policy). Para obter informações sobre como anexar políticas aos usuários do IAM (entidades principais), consulte [Gerenciar políticas do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-using.html) no Guia do usuário do IAM. ## Política de usuários avançados Para conceder todas as ações necessárias ao EMR Sem Servidor, crie e anexe uma política `AmazonEMRServerlessFullAccess` ao usuário, perfil ou grupo do IAM necessário. Confira a seguir um exemplo de política que permite que usuários avançados criem e modifiquem aplicações do EMR Sem Servidor, além de realizar outras ações, como enviar e depurar trabalhos. Ele revela todas as ações que o EMR Sem Servidor requer para outros serviços. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "EMRServerlessActions", "Effect": "Allow", "Action": [ "emr-serverless:CreateApplication", "emr-serverless:UpdateApplication", "emr-serverless:DeleteApplication", "emr-serverless:ListApplications", "emr-serverless:GetApplication", "emr-serverless:StartApplication", "emr-serverless:StopApplication", "emr-serverless:StartJobRun", "emr-serverless:CancelJobRun", "emr-serverless:ListJobRuns", "emr-serverless:GetJobRun" ], "Resource": [ "*" ] } ] } ``` ------ Ao habilitar a conectividade de rede com a VPC, as aplicações do EMR Sem Servidor criam interfaces de rede elástica (ENIs) do Amazon EC2 para se comunicar com os recursos da VPC. A política a seguir garante que qualquer novo EC2 ENIs seja criado somente no contexto dos aplicativos EMR Serverless. **nota** É altamente recomendável definir essa política para garantir que os usuários não possam criar o EC2, ENIs exceto no contexto da inicialização de aplicativos EMR Serverless. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowEC2ENICreationWithEMRTags", "Effect": "Allow", "Action": [ "ec2:CreateNetworkInterface" ], "Resource": [ "arn:aws:ec2:*:*:network-interface/*" ], "Condition": { "StringEquals": { "aws:CalledViaLast": "ops.emr-serverless.amazonaws.com" } } } ] } ``` ------ Se quiser restringir o acesso do EMR Sem Servidor a determinadas sub-redes, você pode marcar cada sub-rede com uma condição de tag. Essa política do IAM garante que os aplicativos EMR Serverless só possam criar ENIs EC2 dentro de sub-redes permitidas. ``` { "Sid": "AllowEC2ENICreationInSubnetAndSecurityGroupWithEMRTags", "Effect": "Allow", "Action": [ "ec2:CreateNetworkInterface" ], "Resource": [ "arn:aws:ec2:*:*:subnet/*", "arn:aws:ec2:*:*:security-group/*" ], "Condition": { "StringEquals": { "aws:ResourceTag/KEY": "VALUE" } } } ``` **Importante** Se você for um administrador ou usuário avançado criando sua primeira aplicação, deverá configurar suas políticas de permissão para permitir a criação de um perfil vinculado a serviços do EMR Sem Servidor. Consulte para saber mais: [Uso de perfis vinculados ao serviço para o EMR Sem Servidor](using-service-linked-roles.md). A política do IAM a seguir permite criar um perfil vinculado ao serviço do EMR Sem Servidor para a sua conta. ``` { "Sid":"AllowEMRServerlessServiceLinkedRoleCreation", "Effect":"Allow", "Action":"iam:CreateServiceLinkedRole", "Resource":"arn:aws:iam::account-id:role/aws-service-role/ops.emr-serverless.amazonaws.com/AWSServiceRoleForAmazonEMRServerless" } ``` ## Política de engenheiro de dados O exemplo a seguir é de uma política que permite aos usuários permissões somente leitura em aplicações do EMR Sem Servidor, bem como a capacidade de enviar e depurar trabalhos. Lembre-se de que, como essa política não nega explicitamente as ações, uma declaração de política diferente ainda pode ser usada para conceder acesso a ações específicas. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "EMRServerlessActions", "Effect": "Allow", "Action": [ "emr-serverless:ListApplications", "emr-serverless:GetApplication", "emr-serverless:StartApplication", "emr-serverless:StartJobRun", "emr-serverless:CancelJobRun", "emr-serverless:ListJobRuns", "emr-serverless:GetJobRun" ], "Resource": [ "*" ] } ] } ``` ------ ## Uso de tags para controle de acesso com Você pode usar condições de tag para controle de acesso refinado. Por exemplo, você pode restringir usuários de uma equipe para que eles só possam enviar trabalhos a aplicações do EMR Sem Servidor marcados com o nome da equipe deles. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "EMRServerlessActions", "Effect": "Allow", "Action": [ "emr-serverless:ListApplications", "emr-serverless:GetApplication", "emr-serverless:StartApplication", "emr-serverless:StartJobRun", "emr-serverless:CancelJobRun", "emr-serverless:ListJobRuns", "emr-serverless:GetJobRun" ], "Resource": [ "*" ] } ] } ``` ------ # Políticas para controle de acesso baseado em etiquetas Você pode usar condições na política baseada em identidade para controlar o acesso a aplicações e execuções de trabalhos com base em tags. Os exemplos a seguir demonstram diferentes cenários e maneiras de usar operadores de condição com chaves de condição do EMR Sem Servidor. Estas instruções de política do IAM são destinadas somente para fins de demonstração e não devem ser usadas em ambientes de produção. Há várias maneiras de combinar declarações de políticas para conceder e negar permissões de acordo com seus requisitos. Para obter mais informações sobre como planejar e testar políticas do IAM, consulte o [Guia do usuário do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/). **Importante** Recusar, explicitamente, permissões para ações de uso de tags é uma consideração importante. Isso evita que os usuários façam a marcação de um recurso e, assim, concedam a si mesmos permissões que você não pretendia conceder. Se as ações de marcação de um recurso não forem negadas, um usuário poderá modificar as etiquetas e driblar a intenção das políticas baseadas em etiquetas. Para obter um exemplo de política que nega ações de marcação, consulte [Negação de acesso para adição ou remoção de etiquetas](#security-iam-TBAC-deny). Os exemplos a seguir demonstram a políticas de permissões baseadas em identidade que são usadas para controlar as ações permitidas com aplicações do EMR Sem Servidor. ## Ações permitidas somente em recursos com valores de etiquetas específicos No exemplo de política a seguir, o operador de condição `StringEquals` tenta corresponder `dev` com o valor da tag department. Se a tag "Department" não tiver sido adicionada à aplicação ou não contiver o valor `dev`, a política não se aplicará e as ações não serão permitidas por essa política. Se nenhuma outra instrução de política permitir as ações, o usuário só poderá trabalhar com aplicações que tenham essa tag com esse valor. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "emr-serverless:GetApplication" ], "Resource": [ "*" ], "Condition": { "StringEquals": { "aws:ResourceTag/department": "dev" } }, "Sid": "AllowEMRSERVERLESSGetapplication" } ] } ``` ------ Você também pode especificar vários valores de tag usando um operador de condição. Por exemplo, para permitir ações em aplicações em que a tag `department` contenha o valor `dev` ou `test`, substitua o bloco condicional no exemplo anterior pelo conteúdo a seguir. ``` "Condition": { "StringEquals": { "emr-serverless:ResourceTag/department": ["dev", "test"] } } ``` ## Marcação obrigatória na criação de um recurso No exemplo abaixo, a tag precisa ser aplicada ao criar a aplicação. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "emr-serverless:CreateApplication" ], "Resource": [ "*" ], "Condition": { "StringEquals": { "aws:RequestedRegion": "us-east-1" } }, "Sid": "AllowEMRSERVERLESSCreateapplication" } ] } ``` ------ A instrução de política apresentada a seguir permite que um usuário crie uma aplicação somente se ela tiver uma tag `department`, que pode conter qualquer valor. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "emr-serverless:CreateApplication" ], "Resource": [ "*" ], "Condition": { "StringEquals": { "aws:RequestedRegion": ["us-east-1", "us-west-2"] } }, "Sid": "AllowEMRSERVERLESSCreateapplication" } ] } ``` ------ ## Negação de acesso para adição ou remoção de etiquetas Essa política impede que um usuário adicione ou remova tags em aplicações do EMR Sem Servidor com uma tag `department` cujo valor não seja `dev`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "emr-serverless:TagResource", "emr-serverless:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:PrincipalTag/department": "dev" } }, "Sid": "AllowEMRSERVERLESSTagresource" } ] } ``` ------ # Exemplos de políticas baseadas em identidade do EMR Sem Servidor Por padrão, os usuários e os perfis não têm permissão para criar ou modificar os recursos do Amazon EMR Sem Servidor. 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)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) no *Guia do usuário do IAM*. *Para obter detalhes sobre ações e tipos de recursos definidos pelo Amazon EMR Serverless, incluindo o formato de cada um dos tipos de recursos, consulte [Ações, recursos e chaves de condição ARNs para o Amazon EMR Serverless](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticmapreduce.html) na Referência de autorização de serviço.* **Topics** + [Práticas recomendadas de política](#security-iam-policy-best-practices) + [Permitir que os usuários acessem suas próprias permissões](#security-iam-id-based-policy-examples-view-own-permissions) ## Práticas recomendadas de política **nota** O EMR Sem Servidor não oferece suporte a políticas gerenciadas, portanto, a primeira prática listada abaixo não se aplica. As políticas baseadas em identidade determinam se alguém pode criar, acessar ou excluir recursos do Amazon EMR Sem Servidor na 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 as políticas AWS gerenciadas e avance para as permissões de privilégios mínimos — Para começar a conceder permissões** aos 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 no 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) ou [Políticas gerenciadas pela AWS para funções de trabalho](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) 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 condições para conceder acesso às ações de serviço se elas forem usadas por meio de uma ação específica AWS service (Serviço da AWS), como CloudFormation. Para saber mais, consulte [Elementos da política JSON do IAM: condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) 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 root, ative Conta da AWS a MFA para obter segurança adicional. 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) no *Guia do usuário do IAM*. ## Permitir que os usuários acessem suas próprias permissões Este exemplo mostra como criar uma política que permita que os usuários do IAM visualizem as políticas gerenciadas e em linha anexadas a sua identidade de usuário. Essa política inclui permissões para concluir essa ação no console ou programaticamente usando a API AWS CLI ou AWS . ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "ViewOwnUserInfo", "Effect": "Allow", "Action": [ "iam:GetUserPolicy", "iam:ListGroupsForUser", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:GetUser" ], "Resource": ["arn:aws:iam::*:user/${aws:username}"] }, { "Sid": "NavigateInConsole", "Effect": "Allow", "Action": [ "iam:GetGroupPolicy", "iam:GetPolicyVersion", "iam:GetPolicy", "iam:ListAttachedGroupPolicies", "iam:ListGroupPolicies", "iam:ListPolicyVersions", "iam:ListPolicies", "iam:ListUsers" ], "Resource": "*" } ] } ``` ## Atualizações sem servidor do Amazon EMR para políticas gerenciadas AWS Acesse detalhes sobre as atualizações das políticas AWS gerenciadas do Amazon EMR Serverless desde que esse serviço começou a rastrear essas alterações. Para receber alertas automáticos sobre mudanças nesta página, assine o feed RSS na página [Histórico de documentos](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/doc-history.html) do Amazon EMR Sem Servidor. | Alteração | Descrição | Data | | --- | --- | --- | | Amazon EMRServerless ServiceRolePolicy — Atualização de uma política existente | [O Amazon EMR Serverless adicionou o novo e `Sid``CloudWatchPolicyStatement` à `EC2PolicyStatement` política da Amazon. EMRServerless ServiceRolePolicy ](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/using-service-linked-roles.html#slr-permissions) | 25 de janeiro de 2024 | | Amazon EMRServerless ServiceRolePolicy — Atualização de uma política existente | O Amazon EMR Sem Servidor adicionou novas permissões para permitir que o Amazon EMR Sem Servidor publique métricas de conta agregadas para uso de vCPU no namespace `"AWS/Usage"`. | 20 de abril de 2023 | | O Amazon EMR Sem Servidor passou a monitorar alterações | O Amazon EMR Serverless começou a monitorar as alterações em suas políticas gerenciadas. AWS | 20 de abril de 2023 | # Solução de problemas de identidade e acesso da Amazon EMR Sem Servidor Use as informações a seguir para ajudar a diagnosticar e corrigir problemas comuns que você pode encontrar ao trabalhar com o Amazon EMR Sem Servidor e o IAM. **Topics** + [Não tenho autorização para executar uma ação no Amazon EMR Sem Servidor](#security_iam_troubleshoot-no-permissions) + [Não estou autorizado a realizar iam: PassRole](#security_iam_troubleshoot-passrole) + [Quero permitir que pessoas fora da minha AWS conta acessem meus recursos sem servidor do Amazon EMR](#security_iam_troubleshoot-cross-account-access) + [Não consigo abrir o servidor de UI/Spark histórico ao vivo do EMR Studio para depurar meu trabalho ou ocorre um erro de API quando tento obter registros usando `get-dashboard-for-job-run`](#security_iam_troubleshoot-emr-identity-access) ## Não tenho autorização para executar uma ação no Amazon EMR Sem Servidor Se isso Console de gerenciamento da AWS indicar que você não está autorizado a realizar uma ação, entre em contato com o administrador para obter ajuda. O administrador é a pessoa que forneceu o seu nome de usuário e senha. O exemplo de erro a seguir ocorre quando o usuário `mateojackson` tenta usar o console para acessar detalhes sobre um recurso fictício do `my-example-widget`, mas não tem as permissões fictícias do `emr-serverless:GetWidget`. ``` User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: emr-serverless:GetWidget on resource: my-example-widget ``` Neste caso, Mateo pede ao administrador para atualizar suas políticas para permitir a ele o acesso ao recurso `my-example-widget` usando a ação `emr-serverless:GetWidget`. ## Não estou autorizado a realizar iam: PassRole Caso receba uma mensagem de erro informando que você não tem autorização para executar a ação `iam:PassRole`, as políticas deverão ser atualizadas para permitir a transmissão de um perfil ao Amazon EMR Sem Servidor. Alguns Serviços da AWS permitem que você passe uma função existente para esse serviço em vez de criar uma nova função de serviço ou uma função vinculada ao serviço. Para fazer isso, é preciso ter permissões para passar o perfil para o serviço. O erro exemplificado a seguir ocorre quando uma usuária do IAM chamada `marymajor` tenta usar o console para executar uma ação no Amazon EMR Sem Servidor. No entanto, a ação exige que o serviço tenha permissões concedidas por um perfil de serviço. Mary não tem permissões para passar o perfil para o serviço. ``` User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole ``` Nesse caso, as políticas de Mary devem ser atualizadas para permitir que ela realize a ação `iam:PassRole`. Se precisar de ajuda, entre em contato com seu AWS administrador. Seu administrador é a pessoa que forneceu suas credenciais de login. ## Quero permitir que pessoas fora da minha AWS conta acessem meus recursos sem servidor do Amazon EMR É possível criar um perfil que os usuários de outras contas ou pessoas fora da organização podem usar para acessar seus recursos. É possível especificar quem é confiável para assumir o perfil. Para serviços que oferecem suporte a políticas baseadas em recursos ou listas de controle de acesso (ACLs), você pode usar essas políticas para conceder às pessoas acesso aos seus recursos. Para saber mais, consulte: + Para saber se o Amazon EMR Sem Servidor é compatível com esses recursos, consulte [Identity and Access Management (IAM) no Amazon EMR Sem Servidor](security_iam_service-with-iam.md). + Para saber como fornecer acesso aos seus recursos em todos os Contas da AWS que você possui, consulte Como [fornecer acesso a um usuário do IAM em outro Conta da AWS que você possui](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) no *Guia do usuário do IAM*. + Para saber como fornecer acesso aos seus recursos a terceiros Contas da AWS, consulte Como [fornecer acesso Contas da AWS a terceiros](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) no *Guia do usuário do IAM*. + Para saber como conceder acesso por meio da federação de identidades, consulte [Conceder acesso a usuários autenticados externamente (federação de identidades)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) no *Guia do usuário do IAM*. + Para saber a diferença entre perfis e políticas baseadas em recurso para acesso entre contas, consulte [Acesso a recursos entre contas no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) no *Guia do usuário do IAM*. ## Não consigo abrir o servidor de UI/Spark histórico ao vivo do EMR Studio para depurar meu trabalho ou ocorre um erro de API quando tento obter registros usando `get-dashboard-for-job-run` Se você usa o armazenamento gerenciado do EMR Sem Servidor para registro em log, e sua aplicação do EMR Sem Servidor está em uma sub-rede privada com endpoints de VPC para o Amazon S3 e você anexa uma política de endpoint para controlar o acesso, adicione as permissões mencionadas em [Registro em log para o EMR Sem Servidor com armazenamento gerenciado](logging.html#jobs-log-storage-managed-storage) na sua política de VPC ao endpoint de gateway S3 para o EMR Sem Servidor armazenar e veicular logs da aplicação.