SEC03-BP09 Partager des ressources en toute sécurité avec un tiers
La sécurité de votre environnement cloud ne s'arrête pas à votre organisation. Votre organisation peut faire appel à un tiers pour gérer une partie de vos données. La gestion des autorisations pour le système géré par un tiers doit suivre la pratique de l'accès juste à temps en utilisant le principe du moindre privilège avec des informations d'identification temporaires. En travaillant en étroite collaboration avec un tiers, vous pouvez réduire ensemble l'étendue de l'impact et le risque d'accès involontaire.
Résultat souhaité : des informations d'identification AWS Identity and Access Management (IAM) à long terme, des clés d'accès IAM et des clés secrètes qui sont associées à un utilisateur peuvent être utilisées par n'importe qui tant que les informations d'identification sont valides et actives. L'utilisation d'un rôle IAM et d'informations d'identification temporaires vous permettent d'améliorer votre situation globale en matière de sécurité en réduisant l'effort de gestion des informations d'identification à long terme, y compris la gestion et les frais généraux opérationnels de ces détails sensibles. En utilisant un identifiant unique universel (UUID) pour l'ID externe dans la politique d'approbation IAM et en veillant à ce que les politiques IAM restent attachées au rôle IAM sous votre contrôle, vous pouvez auditer et vérifier que l'accès accordé au tiers n'est pas trop permissif. Pour des conseils normatifs sur l'analyse des ressources partagées en externe, consultez SEC03-BP07 Analyser l'accès public et entre les comptes.
Anti-modèles courants :
-
Utilisation de la politique d'approbation IAM sans aucune condition.
-
Utilisation d'informations d'identification IAM et de clés d'accès à long terme.
-
Réutilisation des ID externes.
Niveau de risque exposé si cette bonne pratique n'est pas instaurée : moyen
Directives d'implémentation
Vous pouvez autoriser le partage des ressources en dehors d'AWS Organizations ou accorder un accès tiers à votre compte. Par exemple, un tiers peut fournir une solution de surveillance qui doit accéder aux ressources de votre compte. Dans ces cas de figure, vous devez créer un rôle intercompte IAM en lui attribuant uniquement les privilèges requis par le tiers. De plus, vous devez définir une politique d'approbation à l'aide de la condition d'ID externe. Lorsque vous utilisez un identifiant externe, vous pouvez (ou le tiers peut) générer un identifiant unique pour chaque client, tiers ou location. L'ID unique ne doit être contrôlé que par vous après sa création. Le tiers doit implémenter un processus pour relier l'ID externe au client de manière sécurisée, auditable et reproductible.
Vous pouvez également utiliser IAM Roles Anywhere afin de gérer les rôles IAM pour les applications en dehors d'AWS qui utilisent les API AWS.
Si le tiers n'a plus besoin d'accéder à votre environnement, supprimez le rôle. Évitez de fournir à des tiers des informations d'identification à long terme. Gardez un œil sur les autres services AWS qui prennent en charge le partage. Par exemple, AWS Well-Architected Tool autorise le partage d'une charge de travail avec d'autres Comptes AWS et AWS Resource Access Manager vous aide à partager en toute sécurité une ressource AWS que vous possédez avec d'autres comptes.
Étapes d'implémentation
-
Utilisez des rôles intercomptes pour donner accès aux comptes externes.
Les rôles intercomptes réduisent la quantité d'informations sensibles stockées par des comptes externes et des tiers pour servir leurs clients. Les rôles intercomptes vous permettent d'octroyer l'accès aux ressources AWS de votre compte en toute sécurité à un tiers, par exemple aux AWS Partner ou à d'autres comptes de votre organisation, tout en préservant la capacité de gérer et de vérifier cet accès.
Il se peut que le tiers vous fournisse des services à partir d'une infrastructure hybride ou qu'il extraie des données hors site pour les transférer dans un emplacement hors site. IAM Roles Anywhere permet aux charges de travail tierces d'interagir en toute sécurité avec vos charges de travail AWS et réduit davantage la nécessité d'utiliser des informations d'identification à long terme.
Vous ne devez pas utiliser d'informations d'identification à long terme ni de clés d'accès associées aux utilisateurs pour fournir un accès à un compte externe. Utilisez plutôt les rôles intercomptes pour fournir l'accès intercompte.
-
Utilisez un ID externe avec des tiers.
L'utilisation d'un ID externe vous permet de désigner qui peut assumer un rôle dans une politique d'approbation IAM. La politique d'approbation peut exiger que l'utilisateur qui assume le rôle fasse valoir la condition et la cible dans lesquelles il opère. Elle permet également au propriétaire du compte d'accepter que le rôle soit endossé uniquement dans des circonstances spécifiques. La fonction principale de l'ID externe est de traiter et de prévenir le problème de confusion de principal.
Utilisez un ID externe si vous êtes propriétaire d'un Compte AWS et vous avez configuré un rôle pour un tiers qui accède à d'autres Comptes AWS en plus des vôtres, ou lorsque vous assumez des rôles au nom de différents clients. Collaborez avec votre tiers ou AWS Partner pour établir une condition d'identification externe à inclure dans la politique d'approbation IAM.
-
Utilisez des ID externes universellement uniques.
Implémentez un processus qui génère une valeur unique aléatoire pour un ID externe, comme un identifiant unique universel (UUID). Un tiers qui réutilise des ID externes entre différents clients ne règle pas le problème de confusion du principal, car le client A pourrait être en mesure de consulter les données du client B en utilisant le rôle ARN du client B avec l'ID externe dupliqué. Dans un environnement multilocataire, où un tiers prend en charge plusieurs clients avec différents Comptes AWS, le tiers doit utiliser un ID unique différent comme ID externe pour chaque Compte AWS. Le tiers est responsable de la détection des ID externes dupliqués et de la correspondance sécurisée entre chaque client et son ID externe respectif. Le tiers doit vérifier qu'il peut uniquement assumer ce rôle lorsqu'il indique l'ID externe. Le tiers doit s'abstenir de stocker le rôle du client ARN et l'ID externe jusqu'à ce que l'ID externe soit requis.
L'ID externe n'est pas traité comme un secret, mais il ne doit pas être facile à deviner, comme un numéro de téléphone, un nom ou un numéro de compte. Faites de l'ID externe un champ en lecture seule afin qu'il ne puisse pas être modifié dans le but de se faire passer pour la configuration.
Le tiers ou vous-même pouvez générer l'ID externe. Définissez un processus pour déterminer qui est responsable de la génération de l'ID. Quelle que soit l'entité qui crée l'ID externe, le tiers applique l'unicité et les formats de façon uniforme parmi les clients.
-
Rendez obsolètes les informations d'identification à long terme fournis par le client.
Rendez obsolète l'utilisation d'informations d'identification à long terme et utilisez des rôles intercomptes ou IAM Roles Anywhere. Si vous devez utiliser des informations d'identification à long terme, établissez un plan pour migrer vers un accès basé sur les rôles. Pour plus d'informations sur la gestion des clés, consultez Gestion des identités. Collaborez également avec votre équipe Compte AWS et le tiers pour établir un runbook d'atténuation des risques. Pour obtenir des conseils normatifs sur la façon d'intervenir et d'atténuer les répercussions potentielles d'un incident de sécurité, consultez Réponse aux incidents.
-
Vérifiez que la configuration est conforme aux conseils normatifs ou qu'elle est automatisée.
La politique créée pour l'accès intercompte doit suivre le principe du moindre privilège. Le tiers doit fournir un document de politique de rôle ou un mécanisme de configuration automatisé qui utilise un modèle AWS CloudFormation ou un équivalent pour vous. Cela réduit le risque d'erreurs associées à la création manuelle de politiques et offre une piste auditable. Pour plus d'informations sur l'utilisation d'un modèle AWS CloudFormation afin de créer des rôles intercomptes, consultez Rôles intercomptes
. Le tiers doit fournir un mécanisme de configuration automatisé et auditable. Cependant, si vous utilisez le document de politique de rôle décrivant l'accès nécessaire, vous devez automatiser la configuration du rôle. Si vous utilisez un modèle AWS CloudFormation ou un équivalent, vous devrez surveiller les changements liés à la détection des dérives dans le cadre de la pratique d'audit.
-
Planifiez les modifications.
Votre structure de compte, la nécessité de faire appel à un tiers, ou son offre de service peuvent changer. Vous devez anticiper les changements et les défaillances, et planifier en conséquence avec les personnes, processus et technologies appropriés. Auditez régulièrement le niveau d'accès que vous fournissez et implémentez des méthodes de détection pour vous avertir des changements imprévus. Surveillez et auditez l'utilisation du rôle et de l'entrepôt de données des ID externes. Vous devez être prêt à révoquer l'accès tiers, de façon temporaire ou permanente, en raison de changements ou de tendances d'accès imprévus. De plus, mesurez l'impact sur votre opération de révocation, y compris le temps nécessaire pour l'exécution, les personnes impliquées, le coût et l'impact sur d'autres ressources.
Pour des conseils normatifs sur les méthodes de détection, consultez Bonnes pratiques de détection.
Ressources
Bonnes pratiques associées :
Documents connexes :
Vidéos connexes :
Exemples connexes :
-
Atelier Well-Architected – Lambda cross account IAM role assumption (Level 300)
-
Configure cross-account access to Amazon DynamoDB (Configuration de l'accès intercompte à Amazon DynamoDB)