SEC03-BP03 Établir un processus d'accès d'urgence - AWS Framework Well-Architected
Directives d’implémentation Ressources

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.

SEC03-BP03 Établir un processus d'accès d'urgence

Élaborez un processus permettant un accès d’urgence à vos charges de travail dans le cas peu probable où un problème avec votre fournisseur d’identité centralisé surviendrait.

Vous devez concevoir des processus pour les différents modes de défaillance susceptibles de provoquer un événement d’urgence. Par exemple, dans des circonstances normales, les utilisateurs de votre personnel se fédérent vers le cloud à l'aide d'un fournisseur d'identité centralisé (SEC02-BP04) pour gérer leurs charges de travail. Toutefois, si votre fournisseur d’identité centralisé échoue ou si la configuration de la fédération dans le cloud est modifiée, les utilisateurs en interne risquent de ne pas parvenir à se fédérer dans le cloud. Un processus d’accès d’urgence permet aux administrateurs autorisés d’accéder à vos ressources cloud par d’autres moyens (tels qu’une autre forme de fédération ou un accès utilisateur direct) afin de résoudre les problèmes liés à la configuration de la fédération ou à vos charges de travail. Le processus d’accès d’urgence est utilisé jusqu’à ce que le mécanisme de fédération normal soit rétabli.

Résultat souhaité :

  • Vous avez défini et documenté les modes de défaillance considérés comme une urgence : envisagez les circonstances habituelles et les systèmes dont dépendent vos utilisateurs pour gérer leurs charges de travail. Réfléchissez à la façon dont chacune de ces dépendances peut échouer et provoquer une situation d’urgence. Les questions et les bonnes pratiques du pilier Fiabilité peuvent vous être utiles pour identifier les modes de défaillance et concevoir des systèmes plus résilients afin de minimiser le risque de défaillance.

  • Vous avez documenté les étapes à suivre pour confirmer qu’une défaillance est une urgence. Par exemple, vous pouvez demander aux administrateurs d’identité de vérifier l’état des fournisseurs d’identité principal et secondaire et, si les deux ne sont pas disponibles, de déclarer un événement d’urgence pour cause de défaillance du fournisseur d’identité.

  • Vous avez défini un processus d’accès d’urgence spécifique à chaque type d’urgence ou de mode de défaillance. En étant aussi précis que possible, vous éviterez que les utilisateurs abusent d’un processus général pour tous les types d’urgence. Vos processus d’accès d’urgence décrivent les circonstances dans lesquelles chaque processus doit être utilisé, et inversement les situations dans lesquelles le processus ne doit pas être utilisé et renvoie à d’autres processus qui peuvent s’appliquer.

  • Vos processus sont bien documentés avec des instructions détaillées et des playbooks qui peuvent être suivis rapidement et efficacement. N’oubliez pas qu’un événement d’urgence peut être stressant pour vos utilisateurs et qu’ils peuvent être soumis à des contraintes de temps extrêmes. Concevez donc votre processus de manière à ce qu’il soit aussi simple que possible.

Anti-modèles courants :

  • Vous ne disposez pas de processus d’accès d’urgence bien documentés et bien testés. Vos utilisateurs ne sont pas préparés à une situation d’urgence et suivent des processus improvisés lorsqu’une situation d’urgence survient.

  • Vos processus d’accès d’urgence dépendent des mêmes systèmes (tels qu’un fournisseur d’identité centralisé) que vos mécanismes d’accès habituels. Autrement dit, la défaillance d’un système de ce type peut avoir un impact à la fois sur vos mécanismes d’accès habituels et sur les mécanismes d’accès d’urgence, et nuire à votre capacité à vous remettre de la panne.

  • Vos processus d’accès d’urgence sont utilisés dans des situations non urgentes. Par exemple, vos utilisateurs utilisent fréquemment à mauvais escient les processus d’accès d’urgence, car ils trouvent qu’il est plus facile d’apporter des modifications directement que de les soumettre par le biais d’un pipeline.

  • Vos processus d’accès d’urgence ne génèrent pas suffisamment de journaux pour auditer les processus, ou les journaux ne sont pas surveillés pour signaler une éventuelle utilisation inappropriée des processus.

Avantages liés au respect de cette bonne pratique :

  • En disposant de processus d’accès d’urgence bien documentés et bien testés, vous réduisez le temps nécessaire à vos utilisateurs pour répondre à un événement d’urgence et le résoudre. Cela peut se traduire par une réduction des temps d’arrêt et une meilleure disponibilité des services que vous offrez à vos clients.

  • Vous pouvez suivre chaque demande d’accès d’urgence, détecter les tentatives non autorisées d’utilisation abusive du processus pour des événements non urgents et les signaler.

Niveau d’exposition au risque si cette bonne pratique n’est pas respectée : moyen

Directives d’implémentation

Cette section fournit des conseils pour créer des processus d'accès d'urgence pour plusieurs modes de défaillance liés aux charges de travail déployées AWS, en commençant par des directives communes applicables à tous les modes de défaillance, suivies de directives spécifiques basées sur le type de mode de défaillance.

Conseils communs pour tous les modes de défaillance

Envisagez les points suivants lorsque vous concevez un processus d’accès d’urgence pour un mode de défaillance :

  • Documentez les conditions préalables et les hypothèses du processus : situations dans lesquelles le processus doit être utilisé et situations dans lesquelles il ne doit pas être utilisé. Il est utile de détailler le mode de défaillance et de documenter les hypothèses, telles que l’état d’autres systèmes connexes. Par exemple, le processus du mode de défaillance 2 suppose que le fournisseur d'identité est disponible, mais que la configuration AWS est modifiée ou a expiré.

  • Créez au préalable les ressources nécessaires au processus d'accès d'urgence (SEC10-BP05). Par exemple, créez au préalable l'accès d'urgence Compte AWS avec IAM les utilisateurs et les rôles, ainsi que les IAM rôles entre comptes dans tous les comptes de charge de travail. Vous pourrez ainsi vérifier que ces ressources sont prêtes et disponibles en cas d’urgence. En pré-créant des ressources, vous n'avez aucune dépendance vis-à-vis du plan de AWS contrôle APIs (utilisé pour créer et modifier des AWS ressources) qui pourrait être indisponible en cas d'urgence. De plus, en pré-créant IAM des ressources, vous n'avez pas besoin de prendre en compte les retards potentiels dus à une éventuelle cohérence.

  • Incluez les processus d'accès d'urgence dans le cadre de vos plans de gestion des incidents (SEC10-BP02). Documentez la manière dont les événements d’urgence sont suivis et communiqués aux autres membres de votre organisation (tels que vos pairs et la direction) et, le cas échéant, à vos clients et partenaires commerciaux.

  • Définissez le processus de demande d’accès d’urgence dans votre système de flux de travail des demandes de service existant, si vous en avez un. Généralement, ces systèmes de flux de travail vous permettent de créer des formulaires de réception pour collecter des informations sur la demande, de suivre la demande à chaque étape du flux de travail et d’ajouter des étapes d’approbation automatisées et manuelles. Associez chaque demande à un événement d’urgence correspondant suivi dans votre système de gestion des incidents. Le fait de disposer d’un système uniforme pour les accès d’urgence vous permet de suivre ces demandes dans un seul système, d’analyser les tendances d’utilisation et d’améliorer vos processus.

  • Vérifiez que vos processus d’accès d’urgence ne peuvent être initiés que par des utilisateurs autorisés et nécessitent l’approbation de pairs ou de la direction de l’utilisateur, le cas échéant. Le processus d’approbation doit fonctionner efficacement pendant les heures de bureau et au-delà. Définissez comment les demandes d’approbation autorisent les approbateurs secondaires si les approbateurs principaux ne sont pas disponibles et comment elles remontent dans la chaîne de gestion jusqu’à ce qu’elles soient approuvées.

  • Vérifiez que le processus génère des journaux d’audit et des événements détaillés pour les tentatives d’accès d’urgence qui aboutissent et pour celles qui échouent. Surveillez à la fois le processus de demande et le mécanisme d’accès d’urgence pour détecter les abus ou les accès non autorisés. Corrélez l’activité avec les événements d’urgence en cours depuis votre système de gestion des incidents et signalez les situations où des actions se produisent en dehors des périodes prévues. Par exemple, vous devez surveiller le Compte AWS d’accès d’urgence et signaler toute activité, car il ne doit jamais être utilisé dans le cadre des opérations habituelles.

  • Testez régulièrement les processus d’accès d’urgence pour vérifier que les étapes sont claires et accorder le niveau d’accès approprié rapidement et efficacement. Vos processus d'accès d'urgence doivent être testés dans le cadre de simulations de réponse aux incidents (SEC10-BP07) et de tests de reprise après sinistre (REL13-BP03).

Mode de défaillance 1 : le fournisseur d'identité utilisé pour la fédération n' AWS est pas disponible

Comme décrit dans SEC02-BP04 Faites confiance à un fournisseur d'identité centralisé, nous vous recommandons de vous appuyer sur un fournisseur d'identité centralisé pour fédérer les utilisateurs auxquels vous autorisez l'accès à votre personnel. Comptes AWS Vous pouvez fédérer plusieurs Comptes AWS personnes au sein de votre AWS organisation à l'aide IAM d'Identity Center, ou vous pouvez les fédérer à plusieurs personnes Comptes AWS à l'aide de. IAM Dans les deux cas, les utilisateurs en interne s’authentifient auprès de votre fournisseur d’identité centralisé avant d’être redirigés vers un point de terminaison de connexion AWS pour l’authentification unique.

Dans le cas peu probable où votre fournisseur d’identité centralisé ne serait pas disponible, les utilisateurs en interne ne pourraient pas se fédérer aux Comptes AWS ni gérer leurs charges de travail. Dans ce cas d'urgence, vous pouvez fournir un processus d'accès d'urgence permettant à un petit groupe d'administrateurs d' Comptes AWS effectuer des tâches critiques qui ne peuvent pas attendre que vos fournisseurs d'identité centralisés soient de nouveau en ligne. Par exemple, votre fournisseur d'identité n'est pas disponible pendant 4 heures et pendant cette période, vous devez modifier les limites supérieures d'un groupe Amazon EC2 Auto Scaling dans un compte Production afin de faire face à une augmentation inattendue du trafic client. Vos administrateurs d'urgence doivent suivre le processus d'accès d'urgence pour accéder à la production spécifique Compte AWS et apporter les modifications nécessaires.

Le processus d'accès d'urgence repose sur un accès d'urgence précréé Compte AWS qui est utilisé uniquement pour l'accès d'urgence et qui dispose de AWS ressources (telles que IAM des rôles et des IAM utilisateurs) pour soutenir le processus d'accès d'urgence. Pendant les opérations normales, personne ne doit accéder au compte d’accès d’urgence et vous devez surveiller et signaler tout cas d’utilisation abusive de ce compte (pour plus de détails, consultez la section précédente consacrée aux conseils communs).

Le compte d'accès d'urgence possède IAM des rôles d'accès d'urgence autorisés à assumer des rôles entre comptes dans les cas Comptes AWS nécessitant un accès d'urgence. Ces IAM rôles sont précréés et configurés avec des politiques de confiance qui font confiance aux IAM rôles du compte d'urgence.

Le processus d’accès d’urgence peut utiliser l’une des approches suivantes :

  • Vous pouvez précréer un ensemble d'IAMutilisateurs pour vos administrateurs d'urgence dans le compte d'accès d'urgence avec des mots de passe et des MFA jetons forts associés. Ces IAM utilisateurs sont autorisés à assumer les IAM rôles qui autorisent ensuite l'accès entre comptes aux Compte AWS endroits où un accès d'urgence est requis. Nous vous recommandons de créer le moins d’utilisateurs possible et d’affecter chaque utilisateur à un seul administrateur d’urgence. En cas d'urgence, un utilisateur administrateur d'urgence se connecte au compte d'accès d'urgence à l'aide de son mot de passe et de son code de MFA jeton, passe au IAM rôle d'accès d'urgence dans le compte d'urgence, puis passe au IAM rôle d'accès d'urgence dans le compte de charge de travail pour effectuer l'action de modification d'urgence. L'avantage de cette approche est que chaque IAM utilisateur est affecté à un administrateur d'urgence et que vous pouvez savoir quel utilisateur s'est connecté en consultant les événements. CloudTrail L'inconvénient est que vous devez gérer plusieurs IAM utilisateurs avec leurs mots de passe et MFA jetons à longue durée de vie associés.

  • Vous pouvez utiliser l'utilisateur Compte AWS root d'accès d'urgence pour vous connecter au compte d'accès d'urgence, assumer le IAM rôle d'accès d'urgence et assumer le rôle multicompte dans le compte de charge de travail. Nous recommandons de définir un mot de passe fort et plusieurs MFA jetons pour l'utilisateur root. Nous vous recommandons également de stocker le mot de passe et les MFA jetons dans un coffre-fort d'identification d'entreprise sécurisé qui applique une authentification et une autorisation fortes. Vous devez sécuriser les facteurs de réinitialisation du mot de passe et du MFA jeton : configurez l'adresse e-mail du compte sur une liste de distribution d'e-mails surveillée par vos administrateurs de sécurité cloud, et le numéro de téléphone du compte sur un numéro de téléphone partagé également surveillé par les administrateurs de sécurité. L’avantage de cette approche est qu’il n’existe qu’un seul ensemble d’informations d’identification d’utilisateur racine à gérer. L’inconvénient est qu’étant donné qu’il s’agit d’un utilisateur partagé, plusieurs administrateurs ont la possibilité de se connecter en tant qu’utilisateur racine. Vous devez auditer les événements de journal de votre coffre-fort d’entreprise pour identifier quel administrateur a extrait le mot de passe de l’utilisateur racine.

Mode d'échec 2 : la configuration du fournisseur d'identité activée AWS est modifiée ou a expiré

Pour permettre aux utilisateurs de votre personnel de se fédérer Comptes AWS, vous pouvez configurer le centre IAM d'identité avec un fournisseur d'identité externe ou créer un fournisseur d'IAMidentité (SEC02-BP04). Généralement, vous les configurez en important un XML document de SAML métadonnées fourni par votre fournisseur d'identité. Le XML document de métadonnées inclut un certificat X.509 correspondant à une clé privée que le fournisseur d'identité utilise pour signer ses assertions. SAML

Ces configurations côté AWS-side peuvent être modifiées ou supprimées par erreur par un administrateur. Dans un autre scénario, le certificat X.509 importé AWS peut expirer et aucune nouvelle méta-donnée XML associée à un nouveau certificat n'a encore été importée. AWS Les deux scénarios peuvent entraîner une rupture de la fédération au AWS profit des utilisateurs de votre personnel, ce qui peut entraîner une situation d'urgence.

Dans un tel cas d'urgence, vous pouvez fournir à vos administrateurs d'identité un accès AWS pour résoudre les problèmes de fédération. Par exemple, votre administrateur d'identité utilise le processus d'accès d'urgence pour se connecter à l'accès d'urgence Compte AWS, passe à un rôle dans le compte administrateur d'Identity Center et met à jour la configuration du fournisseur d'identité externe en important le dernier XML document de SAML métadonnées de votre fournisseur d'identité afin de réactiver la fédération. Une fois la fédération rétablie, les utilisateurs en interne pourront continuer à utiliser le processus d’exploitation habituel pour se fédérer aux comptes de leur charge de travail.

Vous pouvez suivre les approches détaillées dans le précédent mode de défaillance 1 pour créer un processus d’accès d’urgence. Vous pouvez accorder des autorisations de moindre privilège aux administrateurs d’identité pour qu’ils ne puissent accéder qu’au compte administrateur d’Identity Center et effectuer des actions sur Identity Center dans ce compte uniquement.

Mode de défaillance 3 : interruption d’Identity Center

Dans le cas peu probable d'un centre IAM d'identité ou d'une Région AWS interruption, nous vous recommandons de configurer une configuration que vous pouvez utiliser pour fournir un accès temporaire au AWS Management Console.

Le processus d'accès d'urgence utilise une fédération directe entre votre fournisseur d'IAMidentité et un compte d'urgence. Pour plus de détails sur le processus et les considérations de conception, voir Configurer l’accès d’urgence à la AWS Management Console.

Étapes d’implémentation

Étapes communes pour tous les modes de défaillance

  • Créez un processus d'accès Compte AWS dédié aux urgences. Pré-créez les IAM ressources nécessaires dans le compte, telles que IAM les rôles ou IAM les utilisateurs, et éventuellement les fournisseurs IAM d'identité. En outre, créez au préalable des IAM rôles entre comptes dans la charge de travail Comptes AWS avec des relations de confiance avec les IAM rôles correspondants dans le compte d'accès d'urgence. Vous pouvez utiliser AWS CloudFormation StackSets with AWS Organizations pour créer de telles ressources dans les comptes des membres de votre organisation.

  • Créez des politiques de contrôle des AWS Organizations services (SCPs) pour refuser la suppression et la modification des IAM rôles multicomptes chez le membre Comptes AWS.

  • Activez CloudTrail l'accès d'urgence Compte AWS et envoyez les événements de suivi vers un compartiment S3 central de votre collection de journaux Compte AWS. Si vous l'utilisez AWS Control Tower pour configurer et gérer votre environnement AWS multi-comptes, chaque compte que vous créez AWS Control Tower ou auquel vous vous inscrivez AWS Control Tower est CloudTrail activé par défaut et envoyé vers un compartiment S3 dans une archive de journal dédiée. Compte AWS

  • Surveillez l'activité du compte d'accès d'urgence en créant des EventBridge règles qui correspondent à l'APIactivité des IAM rôles d'urgence lors de la connexion à la console. Envoyez des notifications à votre centre des opérations de sécurité lorsque des activités se produisent en dehors d’un événement d’urgence en cours suivi dans votre système de gestion des incidents.

Étapes supplémentaires pour le mode de défaillance 1 : le fournisseur d'identité utilisé pour la fédération n' AWS est pas disponible et le mode de défaillance 2 : la configuration du fournisseur d'identité activée AWS est modifiée ou a expiré

  • Créez des ressources au préalable en fonction du mécanisme que vous avez choisi pour l’accès d’urgence :

    • Utilisation des IAM utilisateurs : créez au préalable les IAM utilisateurs avec des mots de passe forts et les MFA appareils associés.

    • Utilisation de l’utilisateur racine du compte d’urgence : configurez l’utilisateur racine avec un mot de passe fort et stockez ce mot de passe dans le coffre-fort d’informations d’identification de votre entreprise. Associez plusieurs MFA appareils physiques à l'utilisateur root et stockez-les dans des emplacements accessibles rapidement aux membres de votre équipe d'administrateurs d'urgence.

Étapes supplémentaires pour le mode de défaillance 3 : interruption d’Identity Center

  • Comme indiqué dans Configurer l'accès d'urgence au AWS Management Console, dans l'accès d'urgence Compte AWS, créez un fournisseur d'IAMidentité pour permettre une SAML fédération directe depuis votre fournisseur d'identité.

  • Créez des groupes d’opérations d’urgence dans votre fournisseur d’identité sans aucun membre.

  • Créez IAM des rôles correspondant aux groupes d'opérations d'urgence dans le compte d'accès d'urgence.

Ressources

Bonnes pratiques Well-Architected connexes :

Documents connexes :

Vidéos connexes :

Exemples connexes :