Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Délégation temporaire de l'IAM pour les partenaires AWS
## Présentation de
La délégation temporaire IAM permet aux AWS clients d' and/or intégrer facilement les produits AWS partenaires dans leur AWS environnement grâce à des flux de travail interactifs et guidés. Les clients peuvent accorder aux AWS partenaires un accès temporaire limité pour configurer les AWS services requis, réduisant ainsi les difficultés liées à l'intégration et accélérant le délai de rentabilisation.
La délégation temporaire IAM permet aux partenaires de :
+ Simplifiez l'intégration des clients grâce au provisionnement automatisé des ressources
+ Réduisez la complexité de l'intégration en éliminant les étapes de configuration manuelles
+ Instaurez la confiance grâce à des autorisations transparentes approuvées par le client
+ Activez les opérations continues avec des modèles d'accès à long terme en utilisant des limites d'autorisation
## Comment ça marche
1. *Le partenaire crée une demande de délégation* - Les partenaires créent une demande en spécifiant les autorisations dont ils ont besoin et pour combien de temps
1. *Avis clients dans AWS la console* : le client voit exactement quelles autorisations le partenaire demande et pourquoi
1. *Approbation* du client : le client approuve la demande et libère un jeton d'échange. Le jeton est envoyé au partenaire sur cette rubrique SNS spécifiée.
1. *Le partenaire reçoit des informations d'identification temporaires* - Les partenaires échangent le jeton contre des AWS informations d'identification temporaires
1. Le *partenaire configure les ressources* - Les partenaires utilisent les informations d'identification pour configurer les ressources requises dans le compte du client
## Qualification des partenaires
Pour bénéficier de l'intégration par délégation temporaire, un partenaire doit satisfaire aux exigences suivantes :
+ *Participation à ISV Accelerate* — Vous devez être inscrit au programme [ISV Accelerate (ISVA](https://aws.amazon.com/partners/programs/isv-accelerate/)).
+ AWS Mise en *vente sur le Marketplace* : votre produit doit être mis en AWS vente sur le Marketplace avec un badge « AWS Deployed on ».
## Processus d'intégration
Procédez comme suit pour intégrer la délégation temporaire dans votre produit :
1. *Étape 1 : Réviser les exigences*
Consultez cette documentation pour comprendre les exigences de qualification et remplissez le questionnaire destiné aux partenaires ci-dessous.
1. *Étape 2 : Soumettez votre demande d'intégration*
Envoyez un e-mail à aws-iam-partner-onboarding @amazon .com ou contactez votre AWS représentant. Incluez votre questionnaire destiné aux partenaires dûment rempli avec tous les champs obligatoires du tableau ci-dessous.
1. *Étape 3 : AWS validation et révision*
AWS sera :
+ Validez que vous répondez aux critères de qualification
+ Passez en revue vos modèles de politiques et vos limites d'autorisation
+ Donnez votre avis sur les artefacts que vous avez soumis
1. *Étape 4 : Affinez vos politiques*
Répondez aux AWS commentaires et soumettez des modèles de politiques ou des limites d'autorisation mis à jour selon les besoins.
1. *Étape 5 : Compléter l'enregistrement*
Une fois approuvé, AWS il devra :
+ Activez l'accès à l'API pour les comptes que vous avez spécifiés
+ Partagez ARNs pour votre modèle de politique et votre limite d'autorisations (le cas échéant)
Vous recevrez une confirmation lorsque l'intégration sera terminée. Vous pouvez ensuite accéder à la délégation temporaire APIs, CreateDelegationRequest GetDelegatedAccessToken depuis vos comptes enregistrés, et commencer à intégrer les flux de travail des demandes de délégation dans votre produit.
## Questionnaire aux partenaires
Le tableau suivant répertorie les informations requises pour l'intégration des partenaires :
| Informations | Description | Obligatoire |
| --- | --- | --- |
| Partner Central AccountID | Numéro de compte de votre AWS compte enregistré sur [AWS Partner Central](https://partnercentral.awspartner.com/partnercentral2/s/login). | Oui |
| PartnerId | ID de partenaire fourni par [AWS Partner Central](https://partnercentral.awspartner.com/partnercentral2/s/login). | Non |
| AWS Identifiant du produit Marketplace | Identifiant de produit pour votre produit fourni par [AWS Partner Central](https://partnercentral.awspartner.com/partnercentral2/s/login). | Oui |
| AWS accountIDs | La liste de votre AWS compte IDs que vous souhaitez utiliser pour appeler la délégation temporaire APIs. Cela doit inclure à la fois vos comptes de production et vos comptes hors production/test. | Oui |
| Nom du partenaire | Ce nom est affiché aux clients dans la console AWS de gestion lorsqu'ils examinent votre demande de délégation temporaire. | Oui |
| Email (s) de contact | Une ou plusieurs adresses e-mail que nous pouvons utiliser pour vous contacter au sujet de votre intégration. | Oui |
| Domaine du demandeur | Votre domaine (par exemple, www.example.com) | Oui |
| Description de l'intégration | Brève description du cas d'utilisation que vous souhaitez traiter à l'aide de cette fonctionnalité. Vous pouvez inclure des liens de référence vers votre documentation ou d'autres documents publics. | Oui |
| Diagramme d’architecture | Schéma d'architecture illustrant vos cas d'utilisation de l'intégration. | Non |
| Modèle de stratégie | Vous devez enregistrer au moins un modèle de politique pour cette fonctionnalité. Le modèle de politique définit les autorisations temporaires que vous souhaitez demander pour les AWS comptes des clients. Pour plus d'informations, consultez la section Modèle de politique. | Oui |
| Nom du modèle de politique | Nom du modèle de politique que vous souhaitez enregistrer. | Oui |
| Limite d'autorisations | Si vous souhaitez créer des rôles IAM dans les comptes des clients à l'aide d'autorisations temporaires, vous devez enregistrer une limite d'autorisation auprès d'IAM. Des limites d'autorisation seront associées aux rôles IAM que vous créez afin de limiter le nombre maximum d'autorisations sur le rôle. Vous pouvez utiliser les politiques AWS gérées sélectionnées comme limite d'autorisation ou enregistrer une nouvelle limite d'autorisation personnalisée (JSON). Pour plus d'informations, consultez la section Limite des autorisations. | Non |
| Nom de la limite d'autorisation | Le nom de votre limite d'autorisation. Le format est le suivant : arn:aws:iam : :partner:policy/permission\$1boundary//\$1 Le nom de la politique doit inclure la date de création sous forme de suffixe. Le nom ne peut pas être mis à jour une fois la limite d'autorisation créée. Si vous utilisez une stratégie AWS gérée existante, fournissez plutôt l'ARN de la politique gérée. | Non |
| Description des limites d'autorisation | Description de la limite d'autorisation. Cette description ne peut pas être mise à jour une fois la limite d'autorisation créée. | Non |
# Comprendre votre intégration
Une fois le processus d'intégration terminé, vous pouvez créer votre intégration avec la délégation temporaire IAM. Une intégration complète implique généralement trois grandes catégories de travail :
## 1. Expérience utilisateur et conception du flux de travail
Créez une expérience frontale dans l'application partenaire qui guide les clients tout au long du flux de travail de délégation temporaire. La candidature du partenaire doit :
+ Présentez un flux d'intégration ou de configuration clair dans lequel les clients peuvent accorder un accès temporaire. Étiquetez clairement cette action, par exemple « Déployer avec délégation temporaire IAM ».
+ Redirigez les clients vers la console de AWS gestion pour examiner et approuver la demande de délégation à l'aide du lien de console renvoyé par l' CreateDelegationRequest API
+ Fournissez un message approprié expliquant quelles autorisations sont demandées et pourquoi. Les clients peuvent voir ce message sur la page de détails de la demande de délégation.
+ Gérez le retour du client à votre demande une fois qu'il a terminé l'approbation en AWS.
## 2. Intégration d'API
Utilisez la délégation temporaire IAM APIs pour envoyer et gérer les demandes de délégation. Une fois vos AWS comptes enregistrés, vous pouvez accéder aux éléments suivants APIs :
+ *IAM CreateDelegationRequest* — Crée une demande de délégation pour le AWS compte d'un client. Cette API renvoie un lien de console vers lequel vous redirigez les clients pour qu'ils examinent et approuvent la demande.
+ *AWS STS GetDelegatedAccessToken*— Récupère les AWS informations d'identification temporaires une fois qu'un client a approuvé votre demande de délégation. Utilisez ces informations d'identification pour effectuer des actions sur le compte du client.
Votre intégration doit gérer le cycle de vie complet des demandes de délégation, y compris la création des demandes, le suivi de leur statut et la récupération des informations d'identification temporaires une fois approuvées.
## 3. Configuration et orchestration des ressources
Une fois que vous avez obtenu des informations d'identification temporaires, orchestrez les flux de travail nécessaires pour configurer les ressources du AWS compte du client. Cela peut inclure :
+ Appeler APIs directement le AWS service pour créer et configurer des ressources
+ Déploiement de l'infrastructure à l' AWS CloudFormation aide
+ Création de rôles IAM pour un accès continu (nécessite l'utilisation de limites d'autorisation)
Votre logique d'orchestration doit être idempotente et gérer les défaillances avec élégance, car les clients peuvent avoir besoin de réessayer ou de modifier leurs approbations de délégation.
# Comprendre les autorisations
Dans le cadre du processus d'intégration des fonctionnalités, vous devrez enregistrer des politiques auprès d'IAM qui définissent les autorisations que vous souhaitez demander pour les comptes des clients AWS . Le processus d'enregistrement fournit une expérience plus cohérente aux clients et permet d'éviter les écueils courants lors de la rédaction de politiques.
Lors de l'inscription, AWS évalue vos politiques par rapport à un ensemble de validations. Ces validations visent à normaliser le format et la structure des politiques et à fournir des protections de base contre les anti-modèles connus. Les validations réduisent également le risque d'augmentation des privilèges, d'accès croisé involontaire et d'accès étendu à des ressources de grande valeur dans les comptes clients.
## Types d'autorisations
AWS prendra en compte deux catégories d'autorisations : les autorisations temporaires et les autorisations à long terme.
### Autorisations temporaires
Les autorisations temporaires limitent les autorisations attribuées à toute session d'accès délégué temporaire. Les autorisations temporaires sont décrites dans les modèles de politique appliqués à la session déléguée. Les modèles prennent en charge les paramètres que vous fournissez lorsque vous créez une demande de délégation. Ces valeurs de paramètres sont ensuite liées à la session. Les autorisations temporaires fonctionnent de la même manière que les politiques de session disponibles AWS STS aujourd'hui : les politiques limitent les capacités de l'utilisateur sous-jacent, mais n'accordent aucun accès supplémentaire. Pour plus d'informations, consultez la AWS STS documentation sur les politiques de session.
### Autorisations à long terme
Les autorisations à long terme limitent les autorisations de tous les rôles créés ou gérés via un accès temporaire. Les autorisations à long terme sont mises en œuvre sous forme de limites d'autorisations IAM. Vous pouvez soumettre une ou plusieurs limites d'autorisation dans AWS le cadre de l'intégration. Une fois approuvé, AWS il partagera avec vous un ARN de politique que vous pourrez référencer dans vos politiques.
Ces politiques de délimitation présentent deux caractéristiques remarquables. Tout d'abord, ils sont immuables. Si vous souhaitez mettre à jour les autorisations, vous pouvez enregistrer une nouvelle limite d'autorisations. Vous pouvez ensuite associer la nouvelle limite d'autorisations aux rôles de vos clients en envoyant une nouvelle demande de délégation. Deuxièmement, les politiques ne sont pas modélisées. Étant donné que la même politique de limites est partagée dans le monde entier, elle ne peut pas être modifiée pour chaque client.
**Important**
Les limites d'autorisation ont une taille maximale de 6 144 caractères.
**Note**
Si vous souhaitez mettre à jour une limite d'autorisation ou un modèle de politique, contactez IAM à l'adresse aws-iam-partner-onboarding @amazon .com. Une fois la nouvelle limite d'autorisation enregistrée, vous pouvez envoyer une demande de délégation aux clients pour mettre à jour le rôle IAM et joindre la nouvelle limite d'autorisation enregistrée. Consultez la section Exemples pour plus de détails.
## Exemple de cas d'utilisation : charge de travail liée au traitement des données
Prenons l'exemple d'un fournisseur de produits qui gère une charge de travail de traitement des données dans les comptes clients. Le fournisseur doit mettre en place une infrastructure lors de l'intégration initiale, mais il a également besoin d'un accès continu pour gérer la charge de travail.
*Autorisations temporaires (pour la configuration initiale) :*
+ Création d' EC2 instances Amazon, de VPC et de groupes de sécurité
+ Création d'un compartiment Amazon S3 pour les données traitées
+ Création d'un rôle IAM pour les opérations en cours
+ Associer une limite d'autorisation au rôle IAM
*Autorisations à long terme (rôle IAM avec limite d'autorisation pour les opérations en cours) :*
+ Démarrer et arrêter les EC2 instances Amazon pour exécuter des tâches de traitement
+ Lire les données d'entrée depuis le compartiment Amazon S3
+ Écrire les résultats traités dans le compartiment Amazon S3
Les autorisations temporaires sont utilisées une seule fois lors de l'intégration pour configurer l'infrastructure. Le rôle IAM créé au cours de ce processus possède une limite d'autorisation qui limite ses autorisations maximales aux seules opérations nécessaires à la gestion continue de la charge de travail. Cela garantit que même si les politiques du rôle sont modifiées, celui-ci ne peut pas dépasser les autorisations définies dans la limite.
# Directives pour l'évaluation des politiques
AWS évaluera les politiques que vous avez soumises par rapport à un ensemble de directives. Les mêmes directives d'évaluation s'appliquent à la fois aux modèles de politiques et aux limites d'autorisation, des différences mineures étant notées le cas échéant.
À des fins d'évaluation, nous séparons les services en groupes distincts. La distinction la plus importante concerne les services sensibles à la sécurité, qui gèrent l'accès, les informations d'identification et les clés. Les politiques garantissant l'accès à ces services doivent être étroitement axées sur le travail effectué. Les services sensibles en termes de sécurité incluent les suivants : AWS Identity and Access Management (IAM) AWS , Key Management Service (KMS), Resource Access AWS Manager (RAM), AWS IAM Identity Center, AWS Organizations et Secrets Manager. AWS
Une distinction secondaire concerne les services qui peuvent accéder aux données au-delà des limites du compte. Les politiques relatives à ces services doivent inclure des protections pour empêcher tout accès involontaire entre comptes.
## Validations communes
Toutes les déclarations de politique doivent suivre les directives suivantes :
+ Toutes les déclarations doivent inclure les champs Effet, Action (ou NotAction), Ressource et Condition dans cet ordre
+ Toutes les actions contenues dans une seule déclaration doivent être répertoriées par ordre alphabétique
+ Tous les éléments ARNs inclus dans la politique doivent suivre la syntaxe définie dans la documentation publique pour les services concernés
+ NotAction les champs ne peuvent être utilisés que dans les instructions Deny
+ Les actions figurant dans les instructions Allow doivent inclure un code de service. Les caractères génériques (« \$1 ») ne sont pas autorisés
## Restrictions relatives aux services sensibles à la sécurité
Les restrictions suivantes s'appliquent aux services sensibles à la sécurité mentionnés ci-dessus :
+ Les actions dans les instructions Allow doivent être plus spécifiques que dans [service] :\$1
+ Les actions figurant dans les instructions Allow pour les modèles de politique d'accès temporaire ne doivent pas contenir de caractères génériques
+ Les actions sensibles, telles que iam : PassRole ou iam :CreateServiceLinkedRole, nécessitent un périmètre supplémentaire, tel que des ressources spécifiques ou des contrôles conditionnels. Ces actions incluent :
+ Transfert de rôle IAM
+ Actions de modification du rôle IAM
+ Actions de modification de la politique IAM
+ AWS Opérations d'écriture ou de chiffrement KMS
+ AWS Opérations d'écriture ou de partage de RAM
+ AWS Opérations du Gestionnaire de secrets pour récupérer ou modifier des secrets, ou modifier des politiques de ressources
+ D'autres actions peuvent utiliser une ressource générique, telle que iam : ListUsers ou iam : GetPolicy
+ Les actions qui gèrent les informations d'identification, telles que iam :CreateAccessKey, sont bloquées
## Restrictions spécifiques à l'IAM
Pour IAM :
+ Seules des opérations d'écriture limitées sont autorisées pour les rôles et les politiques IAM. Vous ne pouvez pas demander d'autorisations sur d'autres ressources IAM telles que les utilisateurs, les groupes et les certificats.
+ Les actions d'attachement aux politiques ou de gestion des politiques en ligne sont limitées aux rôles dotés d'une limite d'autorisation. Les limites d'autorisation doivent être fournies par le partenaire ou figurer sur une liste de politiques AWS gérées autorisées. AWS les politiques gérées peuvent être autorisées si elles n'accordent pas d'autorisations hautement privilégiées ou administratives. Par exemple, les politiques AWS gérées pour des fonctions professionnelles spécifiques ou la SecurityAudit politique peuvent être acceptables. AWS examinera chaque politique AWS gérée sur une case-by-case base spécifique au cours du processus d'intégration.
+ La gestion des politiques n'est autorisée que pour les politiques ayant un chemin spécifique au partenaire : arn:aws:iam : :@ \$1\$1 :policy/partner\$1domain.com/ [feature] \$1 AccountId
+ Les balises ne peuvent être appliquées que lors de la création de ressources, et uniquement pour les rôles et les politiques
+ iam : PassRole les chèques doivent correspondre à un nom ou à un préfixe de chemin spécifique
## AWS STS-restrictions spécifiques
Pour AWS STS :
+ sts : AssumeRole doit être limité à un rôle (ARN), à un préfixe d'ARN de rôle spécifique, ou limité à un ensemble de comptes ou à une unité organisationnelle ID/organizational
## Restrictions relatives au centre d'identité IAM
Pour AWS IAM Identity Center, les actions suivantes sont bloquées :
+ Toutes les actions relatives à la gestion des autorisations (par exemple, sso :AttachCustomerManagedPolicyReferenceToPermissionSet)
+ Modifications apportées aux utilisateurs, aux groupes et aux membres pour AWS Identity Store
+ Gestion des balises
## AWS Organisations : restrictions
Pour AWS les Organisations, seules les actions de lecture seront autorisées.
## Validations supplémentaires spécifiques au service
+ Les actions qui acquièrent des secrets ou des informations d'identification, telles que glue : GetConnection ou redshift :GetClusterCredentials, doivent avoir des conditions correspondant à la totalité ARNs, aux préfixes ARN ou aux balises
+ Pour Amazon Redshift : redshift : n'GetClusterCredentials est autorisé que sur un nom de base de données spécifique, et redshift : GetClusterCredentialsWith IAM n'est autorisé que sur un nom de groupe de travail spécifique
**Note**
Lorsque vous gérez les ressources IAM du compte, nous vous recommandons d'utiliser un chemin indiquant votre nom, par exemple arn:aws:iam : :111122223333 :. role/partner.com/rolename Cela permettra de différencier les ressources associées à votre intégration et de faciliter la découverte, l'audit et l'analyse pour les clients.
## Exigences relatives à l'accès entre comptes
Les instructions susceptibles d'autoriser l'accès entre comptes doivent inclure au moins l'un des éléments suivants :
+ Une condition spécifiant le compte ou l'organisation de la ressource (par exemple, aws : ResourceOrgId correspondant à une ou plusieurs valeurs attendues)
+ Un champ de ressource qui inclut un compte spécifique (par exemple, arn:aws:sqs : \$1:111122223333 : \$1)
+ Un champ de ressource qui inclut un compte non générique et le nom complet de la ressource (par exemple, arn:aws:s3 : full-bucket-name
**Note**
L'accès entre comptes est une fonctionnalité sensible qui nécessite une justification commerciale claire. AWS examinera attentivement la nécessité d'un accès entre comptes lors du processus d'intégration.
# Modèles de politique
Les modèles de politique sont une nouvelle structure IAM conçue pour définir les autorisations temporaires que les partenaires demandent sur les comptes des clients. À l'instar des politiques IAM classiques, elles définissent les autorisations à l'aide d'instructions comportant des éléments Effect, Action, Resource et Condition. La principale différence réside dans le fait que les modèles de politique incluent des paramètres (tels que @ \$1bucketName\$1) qui sont remplacés par des valeurs réelles lorsque vous créez une demande de délégation.
## Comment fonctionnent les modèles de politiques
Dans le cadre du processus d'intégration, vous enregistrez vos modèles de politiques auprès AWS de. AWS attribue à chaque modèle un ARN unique auquel vous faites référence lors de la création de demandes de délégation.
Lorsque vous créez une demande de délégation, vous spécifiez :
+ Le modèle de politique (ARN)
+ Valeurs de paramètres à substituer dans le modèle
AWS combine le modèle avec les valeurs de vos paramètres pour générer une politique IAM standard. Les clients examinent cette politique de rendu final lorsqu'ils approuvent votre demande de délégation, afin de savoir exactement quelles autorisations seront accordées.
**Note**
La politique de rendu final a une limite de taille maximale de 2 048 caractères.
Voici un exemple simple illustrant le fonctionnement de la substitution de modèles.
Modèle de politique :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::@{bucketName}/*"
}
]
}
```
Paramètres fournis dans la demande de délégation :
```
{
"Name": "bucketName",
"Values": ["customer-data-bucket"],
"Type": "String"
}
```
Politique de rendu final (ce que voient les clients) :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::customer-data-bucket/*"
}
]
}
```
## Syntaxe du modèle
Les modèles de politique utilisent deux fonctionnalités clés pour apporter de la flexibilité : la substitution de paramètres et les instructions conditionnelles. La substitution de paramètres vous permet de définir des espaces réservés dans votre modèle qui sont remplacés par des valeurs réelles lors de la création d'une demande de délégation. Les instructions conditionnelles vous permettent d'inclure ou d'exclure des déclarations de politique complètes en fonction des valeurs des paramètres.
### Substitution de paramètres et types
Utilisez la syntaxe @ \$1parameterName\$1 pour définir les paramètres de votre modèle de politique. Lorsque vous créez une demande de délégation, vous devez spécifier le type de chaque paramètre.
#### String
Une valeur unique qui est substituée directement dans le modèle.
Modèle :
```
"Resource": "arn:aws:s3:::@{bucketName}/*"
```
Paramètres :
```
{
"Name": "bucketName",
"Values": ["my-bucket"],
"Type": "String"
}
```
Résultat rendu :
```
"Resource": "arn:aws:s3:::my-bucket/*"
```
#### StringList
Plusieurs valeurs qui génèrent plusieurs entrées de ressources. Lorsqu'un StringList paramètre est utilisé dans un ARN de ressource, il se développe pour créer des entrées de ressource distinctes pour chaque valeur.
Modèle :
```
"Resource": "arn:aws:s3:::@{bucketNames}/*"
```
Paramètres :
```
{
"Name": "bucketNames",
"Values": ["bucket-1", "bucket-2"],
"Type": "StringList"
}
```
Résultat rendu :
```
"Resource": [
"arn:aws:s3:::bucket-1/*",
"arn:aws:s3:::bucket-2/*"
]
```
#### Comportement entre produits
Lorsque plusieurs paramètres sont utilisés dans le même ARN de ressource, StringList les paramètres créent un produit croisé de toutes les combinaisons.
Modèle :
```
"Resource": "arn:aws:s3:::@{bucketNames}/@{prefix}/*"
```
Paramètres :
```
[
{
"Name": "bucketNames",
"Values": ["bucket-1", "bucket-2"],
"Type": "StringList"
},
{
"Name": "prefix",
"Values": ["data"],
"Type": "String"
}
]
```
Résultat rendu :
```
"Resource": [
"arn:aws:s3:::bucket-1/data/*",
"arn:aws:s3:::bucket-2/data/*"
]
```
### Déclarations conditionnelles
Utilisez la directive @Enabled pour inclure ou exclure de manière conditionnelle des instructions complètes en fonction des valeurs des paramètres.
Syntaxe :
+ @Enabled : « ParameterName » - Inclut l'instruction lorsque la valeur du paramètre est « True »
+ @Enabled : « \$1 ParameterName » - Inclut l'instruction lorsque la valeur du paramètre n'est PAS « vraie » (négation)
Modèle :
```
{
"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}/*"
}
]
}
```
Paramètres (lorsque ENABLE\$1S3\$1WRITE est « True ») :
```
[
{
"Name": "bucketName",
"Values": ["my-bucket"],
"Type": "String"
},
{
"Name": "ENABLE_S3_WRITE",
"Values": ["True"],
"Type": "String"
}
]
```
Résultat rendu :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": ["s3:PutObject"],
"Resource": "arn:aws:s3:::my-bucket/*"
}
]
}
```
Paramètres (lorsque ENABLE\$1S3\$1WRITE est « False ») :
```
[
{
"Name": "bucketName",
"Values": ["my-bucket"],
"Type": "String"
},
{
"Name": "ENABLE_S3_WRITE",
"Values": ["False"],
"Type": "String"
}
]
```
Résultat rendu :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "*"
}
]
}
```
Lorsque ENABLE\$1S3\$1WRITE est défini sur « True », l'instruction conditionnelle est incluse. Lorsqu'elle est définie sur « False », l'instruction est exclue de la politique rendue.
## Exemples supplémentaires
Les exemples suivants illustrent les modèles courants d'utilisation des modèles de politique dans le cadre d'une délégation temporaire. Ils se concentrent sur la création de rôles IAM avec des limites d'autorisation pour un accès à long terme et présentent différentes stratégies pour définir les autorisations accordées à des ressources spécifiques. Ces exemples montrent comment trouver un équilibre entre flexibilité et sécurité en utilisant des techniques telles que les préfixes ARN, le balisage des ressources et les mises à jour des limites d'autorisation.
### Exemple 1 : Octroi d'un accès à long terme à des ressources spécifiques
La limite d'autorisation suivante est soumise en tant que « SQSAccessor limite » pour « partner.com » :
```
{
"Effect": "Allow",
"Action": [
"sqs:DeleteMessage",
"sqs:ReceiveMessage",
"sqs:SendMessage"
],
"Resource": "arn:aws:sqs:*:*:*",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "${aws:PrincipalAccount}"
}
}
}
```
**Note**
Cela inclut une condition relative au même compte afin d'éviter d'accorder l'accès aux files d'attente d'autres comptes soumis à des politiques de ressources ouvertes. Une référence directe à l'identifiant de compte du client ne peut pas être incluse car la limite est partagée entre tous les clients et ne peut pas être modélisée.
Comme il s'agit de la première version de cette politique, son ARN est arn:aws:iam : :partner : \$12025\$101\$115 policy/permissions-boundary/partner.com/SQSAccessorBoundary
Le modèle de politique suivant est soumis pour les autorisations d'accès temporaires :
```
{
"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"
}
}
}
]
}
```
### Exemple 2 : Utilisation des préfixes ARN
La limite d'autorisation peut spécifier un préfixe ARN de ressource pour limiter l'accès :
```
"Resource": "arn:aws:sqs:*:@{AccountId}:PartnerPrefix*"
```
Cela limite l'accès aux seules ressources portant ce préfixe, réduisant ainsi la portée des ressources accessibles.
### Exemple 3 : Utilisation de balises pour le contrôle d'accès aux ressources
Vous pouvez étiqueter des ressources lors d'un accès délégué temporaire et vous fier à ces balises pour un contrôle d'accès à long terme.
Limite d'autorisation autorisant l'accès aux ressources étiquetées :
```
{
"Effect": "Allow",
"Action": [
"sqs:DeleteMessage",
"sqs:ReceiveMessage",
"sqs:SendMessage"
],
"Resource": "arn:aws:sqs:*:*:*",
"Condition": {
"Null": {
"aws:ResourceTag/ManagedByPartnerDotCom": "false"
},
"StringEquals": {
"aws:ResourceAccount": "${aws:PrincipalAccount}"
}
}
}
```
Modèle de politique pour étiqueter les nouvelles files d'attente lors de leur création :
```
{
"Effect": "Allow",
"Action": [
"sqs:CreateQueue",
"sqs:TagQueue"
],
"Resource": "arn:aws:sqs:*:*:*",
"Condition": {
"Null": {
"aws:RequestTag/ManagedByPartnerDotCom": "false"
}
}
}
```
Modèle de politique pour étiqueter les files d'attente préexistantes et créer le rôle :
```
{
"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"
}
}
}
]
}
```
Cette approche permet aux clients de confirmer explicitement quelles ressources spécifiques sont accessibles à long terme.
### Exemple 4 : mise à jour de la limite d'autorisation
Pour mettre à jour une limite d'autorisation, enregistrez une nouvelle version avec un nouveau suffixe de date et demandez l'autorisation de la remplacer.
Limite d'autorisation mise à jour avec autorisation supplémentaire :
```
{
"Effect": "Allow",
"Action": [
"sqs:DeleteMessage",
"sqs:PurgeQueue",
"sqs:ReceiveMessage",
"sqs:SendMessage"
],
"Resource": "arn:aws:sqs:*:*:*",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "${aws:PrincipalAccount}"
}
}
}
```
En tant que deuxième version, cette politique possède l'ARN : arn:aws:iam : :partner : \$12025\$101\$120 policy/permissions-boundary/partner.com/SQSAccessorBoundary
Modèle de politique pour mettre à jour la limite d'autorisation pour le rôle existant :
```
{
"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"
}
}
}
]
}
```
Les clients doivent approuver cette demande de délégation pour mettre à jour la limite d'autorisation du rôle existant.
# Construire votre intégration
## Comprendre le cycle de vie des demandes
Avant de créer votre intégration, il est important de comprendre comment les demandes de délégation progressent de leur création à leur réalisation.
### États de la demande
Une demande de délégation passe par les états suivants :
| State | Description |
| --- | --- |
| Non attribué | Demande créée mais pas encore associée à un compte client et à un principal IAM. La demande peut avoir été créée sans spécifier de compte cible, ou avec un identifiant de compte cible mais n'a pas encore été réclamée par le propriétaire du compte. |
| Attribué | Demande associée à un compte client et en attente d'examen |
| En attente d'approbation | Le client a transmis la demande à un administrateur pour approbation |
| Acceptée | Demande approuvée par le client mais le jeton d'échange n'a pas encore été publié |
| Finalisé | Jeton d'échange communiqué au fournisseur du produit. La période de délégation (validité du jeton d'échange) commence lorsque la demande atteint l'état finalisé |
| Refusée | Demande rejetée par le client |
| Expiré | Demande expirée en raison d'une inactivité ou d'un délai d'attente |
### Transitions entre États
*Flux normal (voie d'approbation)*
+ Non attribué → Assigné : le client associe la demande à son compte
+ Assigné → Accepté OU attribué → En attente d'approbation : le client approuve la demande directement OU la transmet à l'administrateur pour examen
+ En attente d'approbation → Acceptée : l'administrateur approuve la demande
+ Accepté → Finalisé : le client libère le jeton d'échange
*Voie de rejet*
+ Attribué → Rejeté : le client rejette la demande
+ En attente d'approbation → Rejeté : l'administrateur rejette la demande
+ Accepté → Rejeté : le client révoque son approbation avant de libérer le jeton
*Chemin d'expiration*
Les demandes expirent automatiquement si aucune action n'est entreprise dans le délai spécifié :
+ Non attribué → Expiré (1 jour)
+ Assigné → Expiré (7 jours)
+ En attente d'approbation → Expiré (7 jours)
+ Accepté → Expiré (7 jours)
+ Rejeté → Expiré (7 jours)
+ Finalisé → Expiré (7 jours)
*États du terminal*
Les états suivants sont terminaux (aucune autre transition) :
+ Finalisé : jeton d'échange envoyé
+ Rejeté : la demande a été refusée
+ Expiré : demande expirée ou période de délégation terminée
Les demandes expirées sont finalement supprimées du système après la période de conservation.
### Gestion des états des demandes de délégation dans votre application
En tant que partenaire, vous devez suivre l'état des demandes de délégation dans votre système et les communiquer à vos clients. Lorsque vous recevez des notifications SNS concernant des changements d'état, stockez ces mises à jour dans votre backend et reflétez-les dans votre interface utilisateur destinée aux clients. Portez une attention particulière à l'état En attente d'approbation : lorsqu'un client transmet une demande à un administrateur pour examen, il vous AWS envoie une notification en attente d'approbation. Les demandes peuvent rester dans cet état jusqu'à 7 jours en attendant l'intervention de l'administrateur. Pendant ce temps, montrez aux clients que leur demande est en attente de l'approbation de l'administrateur dans votre application. Envisagez de fournir un lien profond vers la AWS console où les clients peuvent vérifier l'état de la demande ou effectuer un suivi auprès de leur administrateur. Pour une bonne expérience d'intégration, il est important de gérer correctement la machine d'état dans votre backend et de communiquer les informations d'état correctes aux clients à chaque étape.
![\[alt text not found\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/delegation-states.png)
## Configuration des notifications
IAM utilise Amazon Simple Notification Service (SNS) pour vous communiquer les modifications de l'état des demandes de délégation. Lorsque vous créez une demande de délégation, vous devez fournir un ARN de rubrique SNS à partir de votre AWS compte enregistré. IAM publiera des messages sur cette rubrique pour les événements importants, notamment lorsque les clients approuvent ou rejettent des demandes et lorsque le jeton d'échange est prêt.
**Note**
Les sujets SNS ne peuvent pas se trouver dans des régions optionnelles. AWS Votre rubrique SNS doit se trouver dans une AWS région activée par défaut. Pour obtenir la liste des régions admises, consultez la section Gestion des AWS régions dans le guide de gestion des AWS comptes.
### Configuration de la rubrique SNS
Pour recevoir des notifications de demande de délégation, vous devez configurer votre rubrique SNS pour accorder à IAM les autorisations nécessaires pour y publier des messages. Ajoutez la déclaration de politique suivante à votre politique relative aux sujets 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"
}
]
}
```
**Important**
Le sujet SNS doit figurer sur l'un de vos AWS comptes enregistrés. IAM n'acceptera pas les sujets SNS provenant d'autres comptes. Si la politique thématique n'est pas correctement configurée, vous ne recevrez pas de notifications de changement d'état ni le jeton d'échange.
### Types de notifications
IAM envoie deux types de notifications :
*StateChange Notifications*
Envoyée lorsqu'une demande de délégation passe à un nouvel état (attribuée, en attente d'approbation, acceptée, finalisée, rejetée, expirée).
*ExchangeToken Notifications*
Envoyé lorsqu'un client libère le jeton de délégation (état Finalisé). Cette notification inclut le jeton d'échange dont vous avez besoin pour obtenir les informations d'identification.
### États de notification
Vous recevrez des notifications pour les états de demande de délégation suivants :
| State | Type de notification | Description |
| --- | --- | --- |
| ASSIGNÉ | StateChange | La demande a été associée à un compte client |
| EN ATTENTE D'APPROBATION | StateChange | Le client a transmis la demande à un administrateur pour approbation |
| ACCEPTÉ | StateChange | Le client a approuvé la demande mais n'a pas encore publié le jeton |
| FINALISÉ | StateChange | Le client a publié le jeton d'échange |
| FINALISÉ | ExchangeToken | Cette notification contient le jeton d'échange |
| REFUSÉE | StateChange | Le client a rejeté la demande |
| EXPIRÉ | StateChange | Demande expirée avant d'être terminée |
### Format du message de notification
IAM publie des notifications SNS standard. Les informations relatives à la demande de délégation sont contenues dans le champ Message sous forme de chaîne JSON.
*Champs communs (toutes les notifications)*
| Champ | Type | Description |
| --- | --- | --- |
| Type | String | Soit « StateChange » soit « ExchangeToken » |
| RequestId | String | L'ID de demande de délégation IAM |
| RequestorWorkflowId | String | L'ID de flux de travail que vous avez fourni lors de la création de la demande |
| State | String | État actuel de la demande |
| OwnerAccountId | String | Numéro de AWS compte du client |
| UpdatedAt | String | Horodatage lorsque l'état a changé (format ISO 8601) |
*Champs supplémentaires (ExchangeToken notifications uniquement)*
| Champ | Type | Description |
| --- | --- | --- |
| ExchangeToken | String | Le jeton à échanger contre des informations d'identification à l'aide de l' AWS STS GetDelegatedAccessToken API |
| ExpiresAt | String | Lorsque l'accès délégué expire (format ISO 8601) |
### Exemples de notifications
*StateChange Notification*
```
{
"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": "..."
}
```
*ExchangeToken Notification*
```
{
"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": "..."
}
```
## Échangez des jetons
Un jeton d'échange ou un jeton d'échange est émis par IAM lorsqu'un client accepte et finalise une demande de délégation. Le fournisseur du produit utilise ce jeton d'échange ou d'échange pour appeler l' AWS AWS STS GetDelegatedAccessToken API afin d'obtenir des AWS informations d'identification temporaires avec les autorisations approuvées par les clients. Le jeton d'échange lui-même ne donne pas accès à vos AWS ressources ; il doit être échangé contre des informations d'identification réelles via AWS STS.
Le jeton d'échange ne peut être utilisé que par le compte du fournisseur du produit qui a créé la demande de délégation. Le compte demandeur est intégré au jeton, ce qui garantit que seul le fournisseur de produits autorisé peut obtenir les informations d'identification pour accéder au compte client.
### Durée de l'accès
La période de délégation commence lorsque le client libère le jeton d'échange, et non lorsque le fournisseur du produit l'échange. Une fois que le client a libéré le jeton :
+ Le fournisseur du produit reçoit le jeton via une notification SNS
+ Ils peuvent immédiatement l'échanger contre des informations d'identification
+ Les informations d'identification expirent à : heure de publication \$1 durée approuvée
+ Le fournisseur du produit peut échanger le jeton plusieurs fois avant son expiration pour obtenir de nouvelles informations d'identification si nécessaire.
### Rachats multiples
Les fournisseurs de produits peuvent échanger le jeton plusieurs fois pendant la période de validité pour obtenir de nouvelles informations d'identification. Cependant, toutes les informations d'identification obtenues à partir du même jeton d'échange expirent en même temps, en fonction de la date à laquelle vous avez publié le jeton.
Exemple : Si vous approuvez une demande de délégation de 2 heures et que vous libérez le jeton à 10 h 00 :
| Heure de sortie du jeton | Heure d'échange de jetons | Expiration des informations d'identification | Temps utilisable |
| --- | --- | --- | --- |
| 10 h | 10 h | 12:00 | 2 heures |
| 10 h | 10 h 20 | 12:00 | 1 heure 40 minutes |
| 10 h | 11 h 40 | 12:00 | 20 minutes |
| 10 h | 12 h 10 | Échec (le jeton a expiré) | 0 minutes |
Comme le montre le tableau, l'échange du jeton plus tard dans la période de validité réduit le temps d'utilisation pour le fournisseur du produit.