# Gerenciamento de acesso para recursos da AWS
O AWS Identity and Access Management (IAM) é um serviço da Web que ajuda você a controlar o acesso aos recursos da AWS de forma segura. Quando um [principal](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html?icmpid=docs_homepage_addtlrcs#principal) faz uma solicitação no AWS, o código de aplicação do AWS verifica se o principal está autenticado (fez login) e autorizado (tem permissões). Você gerencia o acesso na AWS criando políticas e anexando-as às identidades do IAM ou aos recursos da AWS. As políticas são documentos JSON no AWS que, quando anexadas a uma identidade ou recurso, definem suas permissões. Para obter mais informações sobre os tipos e os usos de políticas, consulte [Políticas e permissões no AWS Identity and Access Management](access_policies.md).
Para obter mais detalhes sobre o restante do processo de autenticação e autorização, consulte [Como o IAM funciona](intro-structure.md).
Ao fazer uma autorização, o código de aplicação do AWS usa os valores do [contexto da solicitação](intro-structure.md#intro-structure-request) para buscar as políticas correspondentes e determinar se ela será permitida ou negada.
AWSO verifica cada política que se aplica ao contexto da solicitação. Se uma única política negar a solicitação, a AWS negará toda a solicitação e interromperá a avaliação de políticas. Esse processo é chamado de *negação explícita*. Como as solicitações são *negadas por padrão*, o IAM autorizará sua solicitação apenas se todas as partes de sua solicitação forem permitidas pelas políticas aplicáveis. A [lógica de avaliação](reference_policies_evaluation-logic.md) para uma solicitação em uma única conta segue estas regras:
+ Por padrão, todas as solicitações são implicitamente negadas. (Opcionalmente, por padrão, Usuário raiz da conta da AWS tem acesso total.)
+ Uma permissão explícita em uma política baseada em recurso ou identidade substitui esse padrão.
+ Se houver um limite de permissões, SCP de AWS Organizations ou política de sessão, isso poderá substituir a permissão com uma negação implícita.
+ Uma negação explícita em qualquer política substitui todas as permissões.
Depois que sua solicitação for autenticada e autorizada, a AWS aprovará a solicitação. Se você precisar fazer uma solicitação em uma conta diferente, uma política na outra conta deverá permitir que você acesse o recurso. Além disso, a entidade do IAM que você usa para fazer a solicitação deve ter uma política baseada em identidade que permita a solicitação.
## Recursos de gerenciamento de acesso
Para obter mais informações sobre permissões e criação de políticas, consulte os seguintes recursos:
Os registroa a seguir no AWS Security Blog abrangem formas comuns de gravar políticas para acesso a buckets e objetos do Amazon S3.
+ [Writing IAM Policies: How to Grant Access to an Amazon S3 Bucket](https://aws.amazon.com/blogs/security/writing-iam-policies-how-to-grant-access-to-an-amazon-s3-bucket/)
+ [Writing IAM policies: Grant Access to User-Specific Folders in an Amazon S3 Bucket](https://aws.amazon.com/blogs/security/writing-iam-policies-grant-access-to-user-specific-folders-in-an-amazon-s3-bucket/)
+ [IAM Policies and Bucket Policies and ACLs\! Nossa\! (Controlar o acesso aos recursos do S3)](https://aws.amazon.com/blogs/security/iam-policies-and-bucket-policies-and-acls-oh-my-controlling-access-to-s3-resources/)
+ [Uma introdução às permissões em nível de recursos do RDS](https://aws.amazon.com/blogs/security/a-primer-on-rds-resource-level-permissions)
+ [Desmistificação de permissões em nível de recursos do EC](https://aws.amazon.com/blogs/security/demystifying-ec2-resource-level-permissions/)