SEC03-BP03 Établir un processus d’accès d’urgence - Pilier Sécurité
Directives d’implémentation Ressources

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 en interne se fédèrent au 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 sur AWS, en commençant par des conseils communs applicables à tous les modes de défaillance, suivis 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 sur 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 le Compte AWS d’accès d’urgence avec les rôles et utilisateurs IAM, ainsi que les rôles IAM entre comptes dans tous les comptes de la charge de travail. Vous pourrez ainsi vérifier que ces ressources sont prêtes et disponibles en cas d’urgence. En créant des ressources au préalable, vous n’êtes pas tributaire des API du plan de contrôle AWS (utilisées pour créer et modifier des ressources AWS) qui peuvent ne pas être disponibles en cas d’urgence. De plus, en créant au préalable les ressources IAM, 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 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 à AWS n’est pas disponible

Comme décrit dans SEC02-BP04 S’appuyer sur un fournisseur d’identité centralisé, nous vous recommandons de faire appel à un fournisseur d’identité centralisé pour fédérer les utilisateurs en interne et accorder l’accès aux Comptes AWS. Vous pouvez fédérer les utilisateurs à plusieurs Comptes AWS au sein de votre organisation AWS à l’aide d’IAM Identity Center, ou vous pouvez les fédérer à des Comptes AWS individuels avec 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’accéder aux Comptes AWS pour effectuer des tâches critiques qui ne peuvent pas attendre que vos fournisseurs d’identité centralisés soient de nouveau disponibles. Par exemple, votre fournisseur d’identité n’est pas disponible pendant 4 heures et, durant cette période, vous devez modifier les limites supérieures d’un groupe Amazon EC2 Auto Scaling dans un compte de production pour faire face à un pic inattendu du trafic client. Vos administrateurs d’urgence doivent suivre le processus d’accès d’urgence pour accéder au Compte AWS de production spécifique et apporter les modifications nécessaires.

Le processus d’accès d’urgence repose sur un Compte AWS d’accès d’urgence créé au préalable, qui est utilisé uniquement pour l’accès d’urgence et dispose de ressources AWS (comme les rôles IAM et les utilisateurs IAM) 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 des rôles IAM d’accès d’urgence autorisés à endosser des rôles entre comptes dans les Comptes AWS nécessitant un accès d’urgence. Ces rôles IAM sont créés au préalable et configurés avec des politiques d’approbation qui assurent la validité des rôles IAM du compte d’urgence.

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

  • Vous pouvez créer au préalable un ensemble d’utilisateurs IAM pour vos administrateurs d’urgence dans le compte d’accès d’urgence avec des mots de passe forts et des jetons MFA associés. Ces utilisateurs IAM seront autorisés à endosser les rôles IAM qui autoriseront ensuite l’accès intercompte au Compte AWS 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 jeton MFA, passe au rôle IAM d’accès d’urgence dans le compte d’urgence, puis passe au rôle IAM d’accès d’urgence dans le compte de la charge de travail pour effectuer l’action de modification d’urgence. L’avantage de cette approche est que chaque utilisateur IAM est associé à un seul 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 utilisateurs IAM avec leurs mots de passe de longue durée de vie et leurs jetons MFA associés.

  • Vous pouvez utiliser l’utilisateur racine Compte AWS d’accès d’urgence pour vous connecter au compte d’accès d’urgence, endosser le rôle IAM d’accès d’urgence et endosser le rôle entre comptes dans le compte de la charge de travail. Nous recommandons de définir un mot de passe fort et plusieurs jetons MFA pour l’utilisateur racine. Nous conseillons également de stocker le mot de passe et les jetons MFA dans un coffre-fort d’informations d’identification d’entreprise sécurisé qui applique des mécanismes solides d’authentification et d’autorisation. Vous devez sécuriser les facteurs de réinitialisation des mots de passe et des jetons MFA : configurez l’adresse e-mail du compte sur une liste de distribution surveillée par vos administrateurs de sécurité cloud, et le numéro de téléphone du compte doit être un numéro partagé également surveillé par ces administrateurs. 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 de défaillance 2 : la configuration du fournisseur d’identité sur AWS est modifiée ou a expiré

Pour permettre aux utilisateurs en interne de se fédérer aux Comptes AWS, vous pouvez configurer l’IAM Identity Center auprès d’un fournisseur d’identité externe ou créer un fournisseur d’identité IAM (SEC02-BP04). Généralement, vous les configurez en important un document XML de métadonnées SAML fourni par votre fournisseur d’identité. Ce document XML 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 peuvent être modifiées ou supprimées par erreur par un administrateur. Dans un autre scénario, le certificat X.509 importé dans AWS peut expirer, et aucun nouveau fichier XML de métadonnées contenant un nouveau certificat n’a encore été importé dans AWS. Ces deux scénarios peuvent désactiver la fédération des utilisateurs en interne à AWS, 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é utilisera le processus d’accès d’urgence pour se connecter au Compte AWS d’accès d’urgence, passera à un rôle dans le compte administrateur d’Identity Center et mettra à jour la configuration du fournisseur d’identité externe en important le dernier document XML de métadonnées SAML 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 où un IAM Identity Center ou une Région AWS serait interrompue, nous vous recommandons de créer une configuration que vous pourrez utiliser pour assurer un accès temporaire à la AWS Management Console.

Le processus d’accès d’urgence utilise une fédération directe entre votre fournisseur d’identité et IAM dans 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 Compte AWS dédié aux processus d’accès d’urgence. Créez au préalable les ressources IAM nécessaires dans le compte, telles que les rôles IAM ou les utilisateurs IAM et, éventuellement, les fournisseurs d’identité IAM. En outre, créez au préalable des rôles IAM entre comptes dans les Comptes AWS de la charge de travail avec des relations d’approbation avec les rôles IAM correspondants dans le compte d’accès d’urgence. Vous pouvez utiliser AWS CloudFormation StackSets avec AWS Organizations pour créer ces ressources dans les comptes membres de votre organisation.

  • Créez des politiques de contrôle des services (SCP) AWS Organizations pour refuser la suppression et la modification des rôles IAM entre comptes dans les Comptes AWS membres.

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

  • Surveillez l’activité du compte d’accès d’urgence en créant des règles EventBridge qui correspondent lors de la connexion à la console et de l’activité de l’API en fonction des rôles IAM d’urgence. 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 à AWS n’est pas disponible et pour le mode de défaillance 2 : la configuration du fournisseur d’identité sur 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 d’utilisateurs IAM : créez au préalable les utilisateurs IAM avec des mots de passe forts et les dispositifs MFA 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 appareils MFA physiques à l’utilisateur racine et stockez-les à des emplacements auxquels les membres de votre équipe d’administrateurs d’urgence peuvent accéder rapidement.

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

  • Comme décrit dans Définir l’accès d’urgence à la AWS Management Console, dans le Compte AWS d’accès d’urgence, créez un fournisseur d’identité IAM pour activer la fédération SAML directe à partir de votre fournisseur d’identité.

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

  • Créez des rôles IAM 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 :