# Delegação temporária do IAM para parceiros da AWS
## Visão geral
A delegação temporária do IAM permite que os clientes da AWS incluam e/ou integrem de forma otimizada os produtos de parceiros da AWS em seu ambiente da AWS por meio de fluxos de trabalho interativos e guiados. Os clientes podem conceder aos parceiros da AWS acesso limitado e temporário para configurar os serviços necessários da AWS, reduzindo o atrito na integração e acelerando a geração de valor.
A delegação temporária do IAM permite que os parceiros:
+ Simplifiquem a integração de clientes com o provisionamento automatizado de recursos
+ Reduzam a complexidade da integração eliminando as etapas de configuração manual
+ Criem confiança por meio de permissões transparentes e aprovadas pelo cliente
+ Habilitem operações contínuas com padrões de acesso de longo prazo usando os limites de permissões
## Como funciona
1. *Parceiro cria uma solicitação de delegação*: os parceiros criam uma solicitação especificando quais permissões precisam e por quanto tempo.
1. *Avaliações de clientes no Console da AWS*: o cliente vê exatamente quais permissões o parceiro está solicitando e o porquê.
1. *Cliente aprova*: o cliente aprova a solicitação e libera um token de troca. O token é enviado ao parceiro nesse tópico específico do SNS.
1. *Parceiro recebe credenciais temporárias*: os parceiros trocam o token por credenciais temporárias da AWS.
1. *Parceiro configura os recursos*: os parceiros usam as credenciais para configurar os recursos necessários na conta do cliente
## Qualificação de parceiros
Para se qualificar para a integração de delegação temporária, um parceiro deve atender aos seguintes requisitos:
+ *Participação no ISV Accelerate*: você deve estar inscrito no programa [ISV Accelerate (ISVA)](https://aws.amazon.com/partners/programs/isv-accelerate/).
+ *Listagem no AWS Marketplace*: seu produto deve estar listado no AWS Marketplace com o selo “Implantado na AWS”.
## Processo de integração
Conclua as seguintes etapas para integrar a delegação temporária ao seu produto:
1. *Etapa 1: revisar os requisitos*
Analise esta documentação para entender os requisitos de qualificação e preencher o questionário de parceiro abaixo.
1. *Etapa 2: enviar sua solicitação de integração*
Envie um e-mail para aws-iam-partner-onboarding@amazon.com ou entre em contato com seu representante da AWS. Inclua seu questionário de parceiro preenchido com todos os campos obrigatórios da tabela abaixo.
1. *Etapa 3: validação e revisão da AWS*
AWSO :
+ Valide que você atende aos critérios de qualificação.
+ Revise seus modelos de política e limites de permissões.
+ Forneça feedback sobre os artefatos enviados.
1. *Etapa 4: refinar suas políticas*
Responda ao feedback da AWS e envie modelos de políticas ou limites de permissão atualizados, conforme necessário.
1. *Etapa 5: concluir o registro*
Uma vez aprovado, a AWS vai:
+ Habilitar o acesso à API para suas contas especificadas
+ Compartilhar ARNs para seu modelo de política e limite de permissões (se aplicável)
Você receberá uma confirmação quando a integração for concluída. Em seguida, você pode acessar as APIs de delegação temporária, CreateDelegationRequest e GetDelegatedAccessToken, de suas contas registradas e começar a integrar fluxos de trabalho de solicitação de delegação em seu produto.
## Questionário de parceiro
A tabela a seguir lista as informações necessárias para a integração do parceiro:
| Informações | Descrição | Obrigatório |
| --- | --- | --- |
| AccountID da Central de Parceiros | ID da conta da sua conta da AWS registrada no [Central de Parceiros da AWS](https://partnercentral.awspartner.com/partnercentral2/s/login). | Sim |
| PartnerId | ID do parceiro fornecido pela [Central de Parceiros da AWS](https://partnercentral.awspartner.com/partnercentral2/s/login). | Não |
| ID de produto do AWS Marketplace | ID de produto para seu produto fornecido pelo [Central de Parceiros da AWS](https://partnercentral.awspartner.com/partnercentral2/s/login). | Sim |
| AccountIDs da AWS | A lista de seus IDs de conta da AWS que você deseja usar para chamar APIs de delegação temporária. Ela deve incluir suas contas de produção e de não produção/teste. | Sim |
| Nome do parceiro | Esse nome é exibido para os clientes no Console de Gerenciamento da AWS quando eles analisam sua solicitação de delegação temporária. | Sim |
| E-mails de contato | Um ou mais endereços de e-mail que podemos usar para entrar em contato com você sobre sua integração. | Sim |
| Domínio do solicitante | Seu domínio (por exemplo, www.exemplo.com) | Sim |
| Descrição da integração | Breve descrição do caso de uso que você deseja abordar usando esse recurso. Você pode incluir links de referência para sua documentação ou outro material público. | Sim |
| Diagrama de arquitetura | Diagrama de arquitetura ilustrando seus casos de uso de integração. | Não |
| Modelo de política | Você deve registrar pelo menos um modelo de política para esse recurso. O modelo de política define as permissões temporárias que você deseja solicitar nas contas da AWS dos clientes. Para obter mais informações, consulte a seção Modelo de política. | Sim |
| Nome do modelo de política | Nome do modelo de política que você deseja registrar. | Sim |
| Limiar de permissões | Se você quiser criar perfis do IAM nas contas dos clientes usando permissões temporárias, você deve registrar um limite de permissões no IAM. Os limites de permissões serão anexados aos perfis do IAM que você criar para limitar o máximo de permissões no perfil do IAM. Você pode usar políticas gerenciadas pela AWS selecionadas como um limite de permissões ou registrar um novo limite de permissões personalizado (JSON). Para obter mais informações, consulte a seção Limites de permissões. | Não |
| Nome do limite de permissões | O nome do seu limite de permissões. O formato é arn:aws:iam::partner:policy/permission\$1boundary//\$1 O nome da política deve incluir a data de criação como sufixo. O nome não pode ser atualizado depois que o limite de permissões é criado. Se você estiver usando uma política existente gerenciada pela AWS, forneça então o ARN da política gerenciada. | Não |
| Descrição do limite de permissões | Descrição do limite para o limite de permissões. Essa descrição não poderá ser atualizada após a criação do limite de permissões. | Não |
# Noções básicas sobre a integração
Depois de concluir o processo de integração, você pode criar sua integração com a delegação temporária do IAM. Uma integração completa normalmente envolve três categorias principais de trabalho:
## 1. Experiência do usuário e design do fluxo de trabalho
Crie uma experiência de frontend na aplicação de parceiros que oriente os clientes no fluxo de trabalho de delegação temporária. A aplicação do parceiro deve:
+ Apresentar um fluxo claro de integração ou configuração em que os clientes possam conceder acesso temporário. Identifique essa ação de forma clara, como “Implantar com delegação temporária do IAM”.
+ Redirecionar os clientes para o Console de Gerenciamento da AWS para revisar e aprovar a solicitação de delegação usando o link do console retornado pela API CreateDelegationRequest.
+ Fornecer mensagens apropriadas sobre quais permissões estão sendo solicitadas e o porquê. Os clientes podem ver essa mensagem na página de detalhes da solicitação de delegação.
+ Gerenciar o retorno do cliente à sua aplicação após concluir a aprovação na AWS.
## 2. Integração de APIs
Use as APIs de delegação temporária do IAM para enviar e gerenciar solicitações de delegação. Depois que suas contas da AWS estiverem registradas, você poderá acessar as seguintes APIs:
+ *CreateDelegationRequest do IAM*: cria uma solicitação de delegação para a conta da AWS de um cliente. Essa API retorna um link do console para o qual você redireciona os clientes para revisar e aprovar a solicitação.
+ *GetDelegatedAccessToken do AWS STS*: recupera as credenciais temporárias da AWS depois que um cliente aprova sua solicitação de delegação. Use essas credenciais para executar ações na conta do cliente.
Sua integração deve lidar com todo o ciclo de vida das solicitações de delegação, incluindo a criação de solicitações, o monitoramento de seu status e a recuperação de credenciais temporárias quando aprovadas.
## 3. Configuração e orquestração de recursos
Depois de obter as credenciais temporárias, orquestre os fluxos de trabalho necessários para configurar os recursos na conta da AWS do cliente. Isso pode incluir:
+ Chamar APIs de serviço da AWS diretamente para criar e configurar recursos
+ Implantar a infraestrutura usando modelos do AWS CloudFormation
+ Criar perfis do IAM para acesso contínuo (requer o uso de limites de permissões)
Sua lógica de orquestração deve ser idempotente e lidar com as falhas de forma resiliente, pois os clientes podem precisar repetir o processo ou modificar suas aprovações de delegação.
# Análise das permissões
Como parte do processo de integração de recursos, você precisará registrar políticas no IAM que definam as permissões que você deseja solicitar nas contas dos clientes da AWS. O processo de registro fornece uma experiência mais consistente para os clientes e ajuda a evitar armadilhas comuns na criação de políticas.
Durante o registro, a AWS avalia suas políticas em relação a um conjunto de validações. Essas validações têm como objetivo padronizar a formatação e a estrutura das políticas e fornecer proteções básicas contra antipadrões conhecidos. As validações também reduzem o risco de escalonamentos de privilégios, acesso não intencional entre contas e amplo acesso a recursos de alto valor nas contas dos clientes.
## Tipos de permissões
A AWS considerará duas categorias de permissões: temporárias e de longo prazo.
### Permissões temporárias
As permissões temporárias limitam as permissões atribuídas a qualquer sessão temporária de acesso delegado. As permissões temporárias são descritas nos modelos de política que são aplicados à sessão delegada. Os modelos oferecem suporte aos parâmetros que você fornece ao criar uma solicitação de delegação. Esses valores de parâmetros são então vinculados à sessão. Atualmente, as permissões temporárias funcionam da mesma forma que as políticas de sessão disponíveis no AWS STS: as políticas limitam a capacidade do usuário subjacente, mas não concedem nenhum acesso adicional. Para obter mais informações, consulte a documentação do AWS STS nas políticas de sessão.
### Permissões de longo prazo
As permissões de longo prazo limitam as permissões de qualquer perfil criado ou gerenciado por meio de acesso temporário. As permissões de longo prazo são implementadas como limites de permissões do IAM. Você pode enviar um ou mais limites de permissões para a AWS como parte da integração. Depois de aprovado, a AWS compartilhará com você um ARN de política que você pode referenciar em suas políticas.
Essas políticas de limite têm duas características marcantes. Primeiro, elas são imutáveis. Se quiser atualizar as permissões, você pode registrar um novo limite de permissões. Depois, você pode anexar o novo limite de permissões aos perfis de seus clientes enviando uma nova solicitação de delegação. Segundo, as políticas não são modeladas. Como a mesma política de limite é compartilhada globalmente, ela não pode ser alterada de forma individualizada por cliente.
**Importante**
Os limites de permissões têm um limite máximo de tamanho de 6.144 caracteres.
**nota**
Se você quiser atualizar um limite de permissões ou modelo de política, entre em contato com o IAM em aws-iam-partner-onboarding@amazon.com. Depois que o novo limite de permissões for registrado, você poderá enviar uma solicitação de delegação aos clientes para atualizar o perfil do IAM e anexar o limite de permissões recém-registrado. Consulte a seção Exemplos para obter mais detalhes.
## Exemplo de caso de uso: workload de processamento de dados
Considere um provedor de produtos que executa uma workload de processamento de dados nas contas dos clientes. O provedor precisa configurar a infraestrutura durante a integração inicial, mas também requer acesso contínuo para operar a workload.
*Permissões temporárias (para a configuração inicial):*
+ Criar instâncias do Amazon EC2, a VPC e grupos de segurança
+ Criar um bucket do Amazon S3 para dados processados
+ Criar um perfil do IAM para operações em andamento
+ Anexar um limite de permissões ao perfil do IAM
*Permissões de longo prazo (perfil do IAM com limite de permissões para operações em andamento):*
+ Iniciar e interromper as instâncias do Amazon EC2 para executar trabalhos de processamento
+ Ler dados de entrada de um bucket do Amazon S3
+ Gravar resultados processados no bucket do Amazon S3
As permissões temporárias são usadas uma vez durante a integração para configurar a infraestrutura. O perfil do IAM criado durante esse processo tem um limite de permissões que limita suas permissões máximas somente às operações necessárias para o gerenciamento contínuo da workload. Isso garante que, mesmo que as políticas do perfil sejam modificadas, ele não exceda as permissões definidas no limite.
# Diretrizes da avaliação de políticas
A AWS avaliará suas políticas enviadas em relação a um conjunto de diretrizes. As mesmas diretrizes de avaliação se aplicam tanto aos modelos de política quanto aos limites de permissões, com pequenas diferenças observadas quando apropriado.
Para fins de avaliação, separamos os serviços em grupos distintos. A distinção mais importante é para serviços sensíveis à segurança, que gerenciam o acesso, as credenciais e as chaves. As políticas que concedem acesso a esses serviços precisam se concentrar estritamente no trabalho que está sendo feito. Os serviços sensíveis à segurança incluem: AWS Identity and Access Management (IAM), AWS Key Management Service (KMS), AWS Resource Access Manager (RAM), AWS IAM Identity Center, AWS Organizations e AWS Secrets Manager.
Uma distinção secundária são os serviços que podem acessar dados além dos limites da conta. As políticas desses serviços devem incluir proteções para evitar o acesso não intencional entre contas.
## Validações comuns
Todas as instruções de políticas devem seguir estas diretrizes:
+ Todas as instruções devem incluir os campos Effect, Action (ou NotAction), Resource e Condition, nessa ordem
+ Todas as ações em uma única instrução devem ser listadas em ordem alfabética
+ Todos os ARNs incluídos na política devem seguir a sintaxe definida na documentação pública dos serviços relevantes
+ Os campos NotAction só podem ser usados em instruções Deny
+ As ações nas instruções Allow devem incluir um código de serviço. Caracteres curinga genéricos (“\$1”) não são permitidos
## Restrições de serviços sensíveis à segurança
As seguintes restrições se aplicam aos serviços sensíveis à segurança mencionados acima:
+ As ações nas instruções Allow devem ser mais específicas do que [service]:\$1
+ As ações nas instruções Allow para modelos de política de acesso temporário não devem conter curingas
+ As ações sensíveis, como iam:PassRole ou iam:CreateServiceLinkedRole, exigem escopo adicional, como recursos específicos ou verificações condicionais. Entre essas ações estão:
+ Transferência de perfil do IAM
+ Ações de modificação do perfil do IAM
+ Ações de modificação da política do IAM
+ Operações criptográficas ou de gravação do AWS KMS
+ Operações de gravação ou compartilhamento do AWS RAM
+ Operações do AWS Secrets Manager para recuperar ou modificar segredos ou modificar políticas de recursos
+ Outras ações podem usar um recurso curinga, como iam:ListUsers ou iam:GetPolicy
+ As ações que gerenciam credenciais, como iam:CreateAccessKey, são bloqueadas
## Restrições específicas do IAM
Para o IAM:
+ Somente operações de gravação limitadas são permitidas para perfis e políticas do IAM. Você não pode solicitar permissões em outros recursos do IAM, como usuários, grupos e certificados.
+ A anexação de políticas ou as ações de gerenciamento de políticas em linha são limitadas a perfis com um limite de permissões. Os limites de permissões devem ser fornecidos pelo parceiro ou em uma lista de políticas permitidas gerenciadas pela AWS. As políticas gerenciadas pela AWS poderão ser permitidas se não concederem permissões administrativas ou altamente privilegiadas. Por exemplo, políticas gerenciadas pela AWS para funções de trabalho específicas ou a política SecurityAudit podem ser aceitáveis. a AWS analisará cada política gerenciada pela AWS caso a caso durante o processo de integração.
+ O gerenciamento de políticas só é permitido para políticas com um caminho específico do parceiro: arn:aws:iam::@\$1AccountId\$1:policy/partner\$1domain.com/[feature]\$1
+ As tags só podem ser aplicadas durante a criação dos recursos e somente para perfis e políticas
+ As verificações de iam:PassRole devem corresponder a um nome específico ou prefixo de caminho
## Restrições específicas do AWS STS
Para AWS STS:
+ sts:AssumeRole deve ter como escopo um ARN de perfil específico, um prefixo ARN de perfil, ou deve estar limitado a um conjunto de contas ou a um ID da organização/unidade organizacional
## Restrições do Centro de Identidade do IAM
Para o Centro de Identidade do AWS IAM, as seguintes ações estão bloqueadas:
+ Todas as ações relacionadas ao gerenciamento de permissões (por exemplo, sso:AttachCustomerManagedPolicyReferenceToPermissionSet)
+ Modificações de usuários, grupos e membros do AWS Identity Store
+ Gerenciamento de tags
## Restrições do AWS Organizations
Para o AWS Organizations, somente ações de leitura serão permitidas.
## Validações adicionais específicas do serviço
+ As ações que adquirem segredos ou credenciais, como glue:GetConnection ou redshift:GetClusterCredentials, devem ter condições que correspondam a ARNs completos, prefixos ARN ou tags
+ Para o Amazon Redshift: redshift:GetClusterCredentials só é permitido em um nome de banco de dados específico, e redshift:GetClusterCredentialsWithIAM só é permitido em um nome de grupo de trabalho específico
**nota**
Ao gerenciar os recursos do IAM na conta, recomendamos usar um caminho que indique seu nome, por exemplo, arn:aws:iam::111122223333:role/partner.com/rolename. Isso ajudará a diferenciar os recursos associados à sua integração e facilitar a descoberta, a auditoria e a análise para os clientes.
## Requisitos de acesso entre contas
As instruções que potencialmente permitem o acesso entre contas devem incluir pelo menos um dos itens abaixo:
+ Uma condição que especifica a conta ou a organização do recurso (por exemplo, aws:ResourceOrgId que corresponde a um ou mais valores esperados)
+ Um campo de recurso que inclui uma conta específica (por exemplo, arn:aws:sqs:\$1:111122223333:\$1)
+ Um campo de recurso que inclui uma conta que não é curinga e um nome completo do recurso (por exemplo, arn:aws:s3:::full-bucket-name)
**nota**
O acesso entre contas é um recurso sensível que exige uma justificativa comercial clara. A AWS analisará cuidadosamente a necessidade de acesso entre contas durante o processo de integração.
# Modelos de políticas
Os modelos de políticas são um novo constructo do IAM projetado para definir permissões temporárias que os parceiros solicitam nas contas dos clientes. Como as políticas regulares do IAM, elas definem permissões usando instruções com os elementos Effect, Action, Resource e Condition. A principal diferença é que os modelos de política incluem parâmetros (como @\$1bucketName\$1) que são substituídos por valores reais quando você cria uma solicitação de delegação.
## Como funcionam os modelos de políticas
Como parte do processo de integração, você registra seus modelos de política com a AWS. A AWS atribui a cada modelo um ARN exclusivo ao qual você faz referência ao criar solicitações de delegação.
Ao criar uma solicitação de delegação, você especifica:
+ O ARN do modelo da política
+ Os valores de parâmetros a serem substituídos no modelo
A AWS combina o modelo com seus valores de parâmetros para gerar uma política padrão do IAM. Os clientes revisam essa política final renderizada ao aprovar sua solicitação de delegação, vendo exatamente quais permissões serão concedidas.
**nota**
A política renderizada final tem um limite de tamanho máximo de 2.048 caracteres.
Confira um exemplo simples que mostra como a substituição do modelo funciona.
Modelo de política:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::@{bucketName}/*"
}
]
}
```
Parâmetros fornecidos na solicitação de delegação:
```
{
"Name": "bucketName",
"Values": ["customer-data-bucket"],
"Type": "String"
}
```
Política final renderizada (o que os clientes veem):
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::customer-data-bucket/*"
}
]
}
```
## Sintaxe do modelo
Os modelos de política usam dois recursos principais para fornecer flexibilidade: substituição de parâmetros e instruções condicionais. A substituição de parâmetros permite que você defina espaços reservados em seu modelo que são substituídos por valores reais ao criar uma solicitação de delegação. As instruções condicionais permitem que você inclua ou exclua instruções de políticas inteiras com base nos valores dos parâmetros.
### Substituição e tipos de parâmetros
Use a sintaxe @\$1parameterName\$1 para definir parâmetros em seu modelo de política. Ao criar uma solicitação de delegação, você deve especificar o tipo de cada parâmetro.
#### String
Um valor único que é substituído diretamente no modelo.
Modelo:
```
"Resource": "arn:aws:s3:::@{bucketName}/*"
```
Parâmetros:
```
{
"Name": "bucketName",
"Values": ["my-bucket"],
"Type": "String"
}
```
Resultado renderizado:
```
"Resource": "arn:aws:s3:::my-bucket/*"
```
#### StringList
Vários valores que geram várias entradas de recursos. Quando um parâmetro StringList é usado em um ARN de recurso, ele se expande para criar entradas de recursos separadas para cada valor.
Modelo:
```
"Resource": "arn:aws:s3:::@{bucketNames}/*"
```
Parâmetros:
```
{
"Name": "bucketNames",
"Values": ["bucket-1", "bucket-2"],
"Type": "StringList"
}
```
Resultado renderizado:
```
"Resource": [
"arn:aws:s3:::bucket-1/*",
"arn:aws:s3:::bucket-2/*"
]
```
#### Comportamento entre produtos
Quando vários parâmetros são usados no mesmo ARN de recurso, os parâmetros StringList criam um produto cruzado de todas as combinações.
Modelo:
```
"Resource": "arn:aws:s3:::@{bucketNames}/@{prefix}/*"
```
Parâmetros:
```
[
{
"Name": "bucketNames",
"Values": ["bucket-1", "bucket-2"],
"Type": "StringList"
},
{
"Name": "prefix",
"Values": ["data"],
"Type": "String"
}
]
```
Resultado renderizado:
```
"Resource": [
"arn:aws:s3:::bucket-1/data/*",
"arn:aws:s3:::bucket-2/data/*"
]
```
### Instruções condicionais
Use a diretiva @Enabled para incluir ou excluir condicionalmente instruções inteiras com base nos valores dos parâmetros.
Sintaxe:
+ @Enabled: “parameterName”: inclua a instrução quando o valor do parâmetro for “True”
+ @Enabled: “\$1parameterName”: inclua a instrução quando o valor do parâmetro NÃO for “True” (negação)
Modelo:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "*"
},
{
"@Enabled": "ENABLE_S3_WRITE",
"Effect": "Allow",
"Action": ["s3:PutObject"],
"Resource": "arn:aws:s3:::@{bucketName}/*"
}
]
}
```
Parâmetros (quando ENABLE\$1S3\$1WRITE for “True”):
```
[
{
"Name": "bucketName",
"Values": ["my-bucket"],
"Type": "String"
},
{
"Name": "ENABLE_S3_WRITE",
"Values": ["True"],
"Type": "String"
}
]
```
Resultado renderizado:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": ["s3:PutObject"],
"Resource": "arn:aws:s3:::my-bucket/*"
}
]
}
```
Parâmetros (quando ENABLE\$1S3\$1WRITE for “False”):
```
[
{
"Name": "bucketName",
"Values": ["my-bucket"],
"Type": "String"
},
{
"Name": "ENABLE_S3_WRITE",
"Values": ["False"],
"Type": "String"
}
]
```
Resultado renderizado:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "*"
}
]
}
```
Quando ENABLE\$1S3\$1WRITE for definido como “True”, a instrução condicional será incluída. Quando for definido como “False”, a instrução será excluída da política renderizada.
## Exemplos adicionais
Os exemplos a seguir demonstram padrões comuns para o uso de modelos de políticas na delegação temporária. Eles focam a criação de perfis do IAM com limites de permissões para acesso de longo prazo e mostram estratégias diferentes para definir o escopo de permissões para recursos específicos. Esses exemplos ilustram como equilibrar flexibilidade e segurança usando técnicas como prefixos ARN, marcação de recursos e atualizações de limites de permissões.
### Exemplo 1: concessão de acesso de longo prazo a recursos específicos
O limite de permissões abaixo é enviado como “SQSAccessorBoundar” para “partner.com”:
```
{
"Effect": "Allow",
"Action": [
"sqs:DeleteMessage",
"sqs:ReceiveMessage",
"sqs:SendMessage"
],
"Resource": "arn:aws:sqs:*:*:*",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "${aws:PrincipalAccount}"
}
}
}
```
**nota**
Isso inclui uma condição de mesma conta para evitar a concessão de acesso a filas em outras contas com políticas de recursos abertos. Uma referência direta ao ID da conta do cliente não pode ser incluída porque o limite é compartilhado entre todos os clientes e não pode ser modelado.
Como esta é a primeira versão dessa política, seu ARN é arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary\$12025\$101\$115
O modelo de política abaixo foi enviado para permissões de acesso temporárias:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sqs:ListQueues"
],
"Resource": "arn:aws:sqs:*:*:*"
},
{
"Effect": "Allow",
"Action": [
"iam:CreateRole",
"iam:PutRolePermissionsBoundary",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::@{AccountId}:role/partner.com/SQSAccessor",
"Condition": {
"StringEquals": {
"iam:PermissionsBoundary": "arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary_2025_01_15"
}
}
}
]
}
```
### Exemplo 2: uso de prefixos ARN
O limite de permissões pode especificar um prefixo ARN do recurso para limitar o acesso:
```
"Resource": "arn:aws:sqs:*:@{AccountId}:PartnerPrefix*"
```
Isso limita o acesso somente aos recursos com esse prefixo, reduzindo o escopo dos recursos acessíveis.
### Exemplo 3: uso de tags para controle de acesso a recursos
Você pode marcar recursos durante o acesso delegado temporário e contar com essas tags para controle de acesso de longo prazo.
Limite de permissões que permite acesso a recursos marcados:
```
{
"Effect": "Allow",
"Action": [
"sqs:DeleteMessage",
"sqs:ReceiveMessage",
"sqs:SendMessage"
],
"Resource": "arn:aws:sqs:*:*:*",
"Condition": {
"Null": {
"aws:ResourceTag/ManagedByPartnerDotCom": "false"
},
"StringEquals": {
"aws:ResourceAccount": "${aws:PrincipalAccount}"
}
}
}
```
Modelo de política para marcar novas filas na criação:
```
{
"Effect": "Allow",
"Action": [
"sqs:CreateQueue",
"sqs:TagQueue"
],
"Resource": "arn:aws:sqs:*:*:*",
"Condition": {
"Null": {
"aws:RequestTag/ManagedByPartnerDotCom": "false"
}
}
}
```
Modelo de política para marcar filas preexistentes e criar o perfil:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sqs:TagQueue"
],
"Resource": "arn:aws:sqs:*:@{AccountId}:@{QueueName}",
"Condition": {
"ForAllValues:StringEquals": {
"aws:TagKeys": "ManagedByPartnerDotCom"
}
}
},
{
"Effect": "Allow",
"Action": [
"iam:CreateRole",
"iam:PutRolePermissionsBoundary",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::@{AccountId}:role/partner.com/SQSAccessor",
"Condition": {
"StringEquals": {
"iam:PermissionsBoundary": "arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary_2025_01_15"
}
}
}
]
}
```
Essa abordagem permite que os clientes confirmem explicitamente quais recursos específicos podem ser acessados no longo prazo.
### Exemplo 4: atualização do limite de permissões
Para atualizar um limite de permissões, registre uma nova versão com um novo sufixo de data e solicite permissão para substituí-la.
Limite de permissões atualizado com permissão adicional:
```
{
"Effect": "Allow",
"Action": [
"sqs:DeleteMessage",
"sqs:PurgeQueue",
"sqs:ReceiveMessage",
"sqs:SendMessage"
],
"Resource": "arn:aws:sqs:*:*:*",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "${aws:PrincipalAccount}"
}
}
}
```
Como segunda versão, a política tem o ARN: arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary\$12025\$101\$120
Modelo de política para atualizar o limite de permissões no perfil existente:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:PutRolePermissionsBoundary"
],
"Resource": "arn:aws:iam::@{AccountId}:role/partner.com/SQSAccessor",
"Condition": {
"StringEquals": {
"iam:PermissionsBoundary": "arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary_2025_01_20"
}
}
}
]
}
```
Os clientes devem aprovar essa solicitação de delegação para atualizar o limite de permissões no perfil existente.
# Criação da sua integração
## Noções básicas sobre o ciclo de vida de solicitações
Antes de criar sua integração, é importante entender o fluxo das solicitações de delegação, desde a sua criação até a conclusão.
### Estados das solicitações
Uma solicitação de delegação passa pelos seguintes estados:
| Estado | Descrição |
| --- | --- |
| Não atribuída | Solicitação criada, mas ainda não associada a uma conta de cliente e a uma entidade principal do IAM. A solicitação pode ter sido criada sem a especificação de uma conta de destino ou com um ID da conta de destino, mas ainda não reivindicada pelo proprietário da conta. |
| Atribuída | Solicitação associada a uma conta de cliente e aguardando análise. |
| Aprovação pendente | O cliente encaminhou a solicitação a um administrador para aprovação. |
| Aceito | Solicitação aprovada pelo cliente, mas o token de troca ainda não foi liberado. |
| Finalizada | Token de troca liberado para o provedor do produto. O período de delegação (validade do token de troca) começa quando a solicitação chega ao estado Finalizada. |
| Rejeitado | Solicitação rejeitada pelo cliente. |
| Expirada | A solicitação expirou devido à inatividade ou ao tempo limite. |
### Transições de estados
*Fluxo normal (caminho de aprovação)*
+ Não atribuída → Atribuída: o cliente associa a solicitação à sua conta
+ Atribuída → Aceita OU Atribuída → Aprovação pendente: o cliente aprova a solicitação diretamente OU encaminha ao administrador para análise
+ Aprovação pendente → Aceita: o administrador aprova a solicitação
+ Aceita → Finalizada: o cliente libera o token de troca
*Caminho da rejeição*
+ Atribuída → Rejeitada: o cliente rejeita a solicitação
+ Aprovação pendente → Rejeitada: o administrador rejeita a solicitação
+ Aceita → Rejeitada: o cliente revoga a aprovação antes de liberar o token
*Caminho da expiração*
As solicitações expiram automaticamente quando nenhuma ação é executada dentro do prazo especificado:
+ Não atribuída → Expirada (1 dia)
+ Atribuída → Expirada (7 dias)
+ Aprovação pendente → Expirada (7 dias)
+ Aceita → Expirada (7 dias)
+ Rejeitada → Expirada (7 dias)
+ Finalizada → Expirada (7 dias)
*Status terminais*
Os seguintes estados são terminais (sem mais transições):
+ Finalizada: token de troca enviado
+ Rejeitada: a solicitação foi negada
+ Expirada: a solicitação atingiu o tempo limite ou o período de delegação terminou
As solicitações expiradas são excluídas do sistema após o período de retenção.
### Gerenciamento dos estados de solicitação de delegação em sua aplicação
Como parceiro, você deve rastrear os estados de solicitação de delegação em seu sistema e apresentá-los aos seus clientes. Ao receber notificações do SNS sobre mudanças de estado, armazene essas atualizações em seu backend e as reflita na interface de usuário voltada para o cliente. Preste atenção especial ao estado Aprovação pendente: quando um cliente encaminha uma solicitação a um administrador para análise, a AWS envia uma notificação de Aprovação pendente para você. As solicitações podem permanecer nesse estado por até sete dias enquanto aguardam a ação do administrador. Durante esse período, mostre aos clientes que a solicitação deles está pendente e precisa da aprovação do administrador em sua aplicação. Considere fornecer um link direto para o Console da AWS, onde os clientes possam verificar o status da solicitação ou entrar em contato com o administrador. O gerenciamento correto da máquina de estado em seu backend e a apresentação das informações de estado corretas aos clientes em cada estágio é importante para uma boa experiência de integração.
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/images/delegation-states.png)
## Configuração de notificações
O IAM usa o Amazon Simple Notification Service (SNS) para comunicar a você as alterações de estado da solicitação de delegação. Ao criar uma solicitação de delegação, você deve fornecer um ARN do tópico do SNS da sua conta registrada da AWS. O IAM publicará mensagens sobre esse tópico para eventos importantes, incluindo quando os clientes aprovarem ou rejeitarem solicitações e quando o token de troca estiver pronto.
**nota**
Os tópicos do SNS não podem estar em regiões de aceitação da AWS. Seu tópico do SNS deve estar em uma região da AWS habilitada por padrão. Para obter uma lista de regiões de aceitação, consulte Gerenciamento de regiões da AWS no Guia de gerenciamento de contas da AWS.
### Configuração do tópico do SNS
Para receber notificações de solicitações de delegação, você deve configurar seu tópico do SNS para conceder permissões ao IAM para publicar mensagens nele. Adicione a seguinte instrução de política à política do tópico do SNS:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowIAMServiceToPublish",
"Effect": "Allow",
"Principal": {
"Service": "iam.amazonaws.com"
},
"Action": "SNS:Publish",
"Resource": "arn:aws:sns:REGION:ACCOUNT-ID:TOPIC-NAME"
}
]
}
```
**Importante**
O tópico do SNS deve estar em uma de suas contas registradas da AWS. O IAM não aceitará tópicos do SNS de outras contas. Se a política do tópico não estiver configurada corretamente, você não receberá notificações de alteração de estado ou o token de troca.
### Tipos de notificação
O IAM envia dois tipos de notificações:
*Notificações de StateChange*
Enviadas quando uma solicitação de delegação passa para um novo estado (Atribuída, Aprovação pendente, Aceita, Finalizada, Rejeitada, Expirada).
*Notificações de ExchangeToken*
Enviadas quando um cliente libera o token de delegação (estado Finalizada). Essa notificação inclui o token de troca de que você precisa para obter as credenciais.
### Estados das notificações
É possível receber notificações para os seguintes estados de solicitações de delegação:
| Estado | Tipo de notificação | Descrição |
| --- | --- | --- |
| ATRIBUÍDA | StateChange | A solicitação foi associada a uma conta de cliente |
| APROVAÇÃO PENDENTE | StateChange | O cliente encaminhou a solicitação a um administrador para aprovação. |
| ACEITA | StateChange | O cliente aprovou a solicitação, mas ainda não liberou o token |
| FINALIZADA | StateChange | O cliente liberou o token de troca |
| FINALIZADA | ExchangeToken | Essa notificação contém o token de troca |
| REJEITADA | StateChange | O cliente rejeitou a solicitação |
| EXPIRADA | StateChange | A solicitação expirou antes da conclusão |
### Formato das mensagens de notificação
O IAM publica notificações padrão do SNS. As informações da solicitação de delegação encontram-se no campo Mensagem como uma string JSON.
*Campos comuns (todas as notificações)*
| Campo | Tipo | Descrição |
| --- | --- | --- |
| Type | String | “StateChange” ou “ExchangeToken” |
| RequestId | String | O ID da solicitação de delegação do IAM |
| RequestorWorkflowId | String | O ID do fluxo de trabalho que você forneceu ao criar a solicitação |
| Estado | String | Estado atual da solicitação |
| OwnerAccountId | String | ID da conta da AWS do cliente |
| UpdatedAt | String | Carimbo de data e hora em que o estado mudou (formato ISO 8601) |
*Campos adicionais (somente notificações de ExchangeToken)*
| Campo | Tipo | Descrição |
| --- | --- | --- |
| ExchangeToken | String | O token a ser trocado por credenciais usando a API GetDelegatedAccessToken do AWS STS |
| ExpiresAt | String | Quando o acesso delegado expira (formato ISO 8601) |
### Exemplo de notificações
*Notificação de StateChange*
```
{
"Type": "Notification",
"MessageId": "61ee8ad4-6eec-56b5-8f3d-eba57556aa13",
"TopicArn": "arn:aws:sns:us-east-1:123456789012:partner-notifications",
"Message": "{\"RequestorWorkflowId\":\"workflow-12345\",\"Type\":\"StateChange\",\"RequestId\":\"dr-abc123\",\"State\":\"ACCEPTED\",\"OwnerAccountId\":\"111122223333\",\"UpdatedAt\":\"2025-01-15T10:30:00.123Z\"}",
"Timestamp": "2025-01-15T10:30:00.456Z",
"SignatureVersion": "1",
"Signature": "...",
"SigningCertURL": "...",
"UnsubscribeURL": "..."
}
```
*Notificação de ExchangeToken*
```
{
"Type": "Notification",
"MessageId": "e44e5435-c72c-5333-aba3-354406782f5b",
"TopicArn": "arn:aws:sns:us-east-1:123456789012:partner-notifications",
"Message": "{\"RequestId\":\"dr-abc123\",\"RequestorWorkflowId\":\"workflow-12345\",\"State\":\"FINALIZED\",\"OwnerAccountId\":\"111122223333\",\"ExchangeToken\":\"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...\",\"ExpiresAt\":\"2025-01-15T18:30:00.123Z\",\"UpdatedAt\":\"2025-01-15T10:30:00.456Z\",\"Type\":\"ExchangeToken\"}",
"Timestamp": "2025-01-15T10:30:00.789Z",
"SignatureVersion": "1",
"Signature": "...",
"SigningCertURL": "...",
"UnsubscribeURL": "..."
}
```
## Tokens de troca
Um token de troca ou um token de intercâmbio é emitido pelo IAM quando um cliente aceita e finaliza uma solicitação de delegação. O provedor do produto usa esse token de troca ou de intercâmbio para chamar a API GetDelegatedAccessToken do AWS AWS STS e obter credenciais temporárias da AWS com as permissões aprovadas pelos clientes. O token de troca em si não concede acesso aos seus recursos da AWS; ele deve ser trocado por credenciais reais por meio do AWS STS.
O token de troca só pode ser resgatado pela conta do provedor do produto que criou a solicitação de delegação. A conta solicitante está incorporada ao token, garantindo que somente o provedor autorizado do produto possa obter as credenciais para acessar a conta do cliente.
### Duração do acesso
O período de delegação começa quando o cliente libera o token de troca, não quando o provedor do produto o resgata. Depois que o cliente liberar o token:
+ O provedor do produto recebe o token via notificação do SNS
+ Ele pode trocá-lo imediatamente por credenciais
+ As credenciais expiram em: hora da liberação \$1 duração aprovada
+ O provedor do produto pode trocar o token várias vezes antes do vencimento para obter novas credenciais, se necessário
### Vários resgates
Os provedores de produtos podem trocar o token várias vezes durante o período de validade para obter novas credenciais. No entanto, todas as credenciais obtidas do mesmo token de troca expiram ao mesmo tempo, com base em quando você liberou o token.
Exemplo: se você aprovar uma solicitação de delegação de duas horas e liberar o token às 10h:
| Hora de liberação do token | Tempo de troca do token | Expiração da credencial | Tempo utilizável |
| --- | --- | --- | --- |
| 10:00 am | 10:00 am | 12:00h | 2 horas |
| 10:00 am | 10h20 | 12:00h | 1 hora e 40 minutos |
| 10:00 am | 11h40 | 12:00h | 20 minutos |
| 10:00 am | 12:10h | Falha (o token expirou) | 0 minuto |
Conforme mostrado na tabela, trocar o token mais tarde no período de validade resulta em menos tempo de utilização para o provedor do produto.