SEC10-BP05 Préallouer les accès

Vérifiez que les intervenants en cas d’incident disposent du bon accès préalablement alloué dans AWS afin de réduire le temps d’investigation jusqu’à la reprise.

Anti-modèles courants :

Niveau de risque encouru si cette bonne pratique n’est pas respectée : moyen

Directives d’implémentation

AWS recommande de réduire ou de supprimer l’utilisation des informations d’identification durables dans la mesure du possible et de privilégier les informations d’identification temporaire à la place, ainsi que des mécanismes d’escalade des privilèges juste à temps. Les informations d’identification durables sont sujettes aux risques de sécurité et augmentent les frais généraux opérationnels. Pour la plupart des tâches de gestion, ainsi que pour les tâches de réponse aux incidents, nous vous recommandons de mettre en œuvre la fédération d’identités et l’escalade temporaire pour l’accès administratif. Dans le cadre de ce modèle, un utilisateur demande une élévation à un niveau de privilège plus élevé (par exemple un rôle de réponse aux incidents) et, si l’utilisateur est admissible à cette élévation, une demande est envoyée à un approbateur. Si la demande est approuvée, l’utilisateur reçoit un ensemble d’informations d’identification AWS temporaires qui peuvent être utilisées pour effectuer ses tâches. Une fois que ces informations d’identification ont expiré, l’utilisateur doit soumettre une nouvelle demande d’élévation.

Nous vous recommandons d’utiliser une élévation temporaire des privilèges dans la plupart des cas de réponse aux incidents. La bonne façon de procéder consiste à utiliser AWS Security Token Service et les politiques de session pour délimiter l’accès.

Dans certains cas, les identités fédérées ne sont pas disponibles, par exemple :

Dans les cas précédents, un accès d’urgence aux bris de verre doit être configuré pour permettre une enquête et une résolution rapide des incidents. Nous vous recommandons d’utiliser un utilisateur, un groupe ou un rôle doté des autorisations appropriées pour effectuer des tâches et accéder aux ressources AWS. Utiliser l’utilisateur racine uniquement pour les tâches qui nécessitent des informations d’identification. Pour vérifier que les intervenants en cas d’incident disposent d’un niveau d’accès approprié à AWS et aux autres systèmes pertinents, nous vous recommandons de pré-allouer des comptes dédiés. Les comptes requièrent un accès privilégié et doivent être étroitement contrôlés et surveillés. Les comptes doivent être créés avec le moins de privilèges requis pour effectuer les tâches nécessaires et le niveau d’accès doit être basé sur les playbooks créés dans le cadre du plan de gestion des incidents.

Utilisez des utilisateurs et des rôles spécialement conçus et dédiés au titre de bonne pratique. L’élévation temporaire de l’accès des utilisateurs ou des rôles via l’ajout de politiques IAM ne permet pas de savoir clairement de quel type d’accès bénéficiaient les utilisateurs pendant l’incident et peut empêcher la révocation des privilèges élevés au niveau supérieur.

Il est important de supprimer autant de dépendances que possible afin de vérifier que l’accès peut être obtenu dans le plus grand nombre possible de scénarios de défaillance. Afin de vous faciliter la tâche, créez un playbook permettant de vérifier que les utilisateurs chargés des réponses en cas d’incident ont été créés en tant qu’utilisateurs dans un compte de sécurité dédié et qu’ils ne sont pas gérés via une solution d’authentification unique ou de fédération existante. Chaque intervenant en cas d’incident doit avoir son propre compte nommé. La configuration du compte doit appliquer des stratégies de mot de passe d’un niveau de sécurité élevé à l’authentification multifactorielle (MFA). Si les playbooks de réponse aux incidents ne nécessitent qu’un accès à la AWS Management Console, l’utilisateur ne doit pas avoir de clés d’accès configurées et il doit lui être explicitement interdit de créer des clés d’accès. Cela peut être configuré avec des politiques IAM ou des politiques de contrôle des services (SCP), comme mentionné dans les bonnes pratiques de sécurité AWS pour les AWS Organizations SCP. Les utilisateurs ne doivent pas avoir d’autres privilèges que la capacité d’assumer des rôles de réponse aux incidents dans d’autres comptes.

Pendant un incident, il peut être nécessaire d’accorder l’accès à d’autres personnes internes ou externes afin de prendre en charge les activités d’analyse, de correction ou de reprise. Dans ce cas, utilisez le mécanisme de playbook mentionné précédemment. Celui-ci doit comporter un processus permettant de s’assurer que tout accès supplémentaire est révoqué immédiatement après l’incident.

Pour s’assurer que l’utilisation des rôles de réponse aux incidents peut être correctement surveillée et vérifiée, il est essentiel que les comptes utilisateur IAM créés à cette fin ne soient pas partagés entre les personnes et que l’Utilisateur racine d'un compte AWS ne soit pas utilisé, à moins qu’ils ne soient nécessaires pour une tâche spécifique. Si l’utilisateur root est requis (par exemple, l’accès IAM à un compte spécifique n’est pas disponible), utilisez un processus distinct avec un playbook disponible afin de vérifier la disponibilité des informations d’identification de l’utilisateur racine et du jeton d’authentification multifactorielle.

Pour configurer les politiques IAM pour les rôles de réponse aux incidents, pensez à utiliser IAM Access Analyzer pour générer des politiques basées sur les journaux AWS CloudTrail. Pour cela, accordez à l’administrateur l’accès au rôle de réponse aux incidents sur un compte hors production et exécutez vos playbooks. Une fois que vous aurez terminé, vous pourrez créer une politique autorisant uniquement les mesures prises. Cette politique peut ensuite être appliquée à tous les rôles de réponse aux incidents dans tous les comptes. Vous pouvez éventuellement créer une politique IAM distincte pour chaque playbook afin de faciliter la gestion et la vérification. Les exemples de playbooks peuvent comprendre des plans d’intervention pour les rançongiciels, les atteintes à la protection des données, la perte d’accès à la production et d’autres scénarios.

Utilisez les comptes de réponse aux incidents pour assumer des rôles IAM d’intervention en cas d’incident dans d’autres Comptes AWS. Ces rôles doivent être configurés de façon à pouvoir être assumés uniquement par les utilisateurs du compte de sécurité et la relation de confiance doit exiger que le principal appelant ait été authentifié au moyen de l’authentification multifactorielle. Les rôles doivent utiliser des politiques IAM à portée limitée afin de contrôler l’accès. Veillez à ce que toutes les demandes de AssumeRole pour ces rôles soient enregistrées dans CloudTrail et fassent l’objet d’une alerte, et à ce que toutes les actions effectuées à l’aide de ces rôles soient enregistrées.

Il est vivement recommandé de nommer les comptes utilisateur et rôles IAM afin d’en faciliter la recherche dans les journaux CloudTrail. Un exemple serait de nommer les comptes IAM <USER_ID>-BREAK-GLASS et les rôles IAM BREAK-GLASS-ROLE.

CloudTrail est utilisé pour enregistrer l’activité des API dans vos comptes AWS et doit être utilisé pour configurer les alertes relatives à l’utilisation des rôles d’ntervention en cas d’incidents. Consultez la publication de blog sur la configuration des alertes lorsque les clés racine sont utilisées. Les instructions peuvent être modifiées pour configurer le filtre métrique Amazon CloudWatch afin de filtrer les événements AssumeRole liés au rôle IAM de réponse aux incidents :

{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "<INCIDENT_RESPONSE_ROLE_ARN>" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }

Dans la mesure où les rôles de réponse aux incidents sont susceptibles d’avoir un niveau d’accès élevé, il est important que ces alertes soient transmises à un vaste groupe et qui y donnera suite rapidement.

Lors d’un incident, il est possible qu’un intervenant ait besoin d’accéder à des systèmes qui ne sont pas sécurisés directement par . Celle-ci peut inclure des instances Amazon Elastic Compute Cloud, des bases de données Amazon Relational Database Service ou des plateformes de logiciel en tant que service (SaaS). Il est fortement recommandé d’utiliser AWS Systems Manager Session Manager pour tous les accès administratifs aux instances Amazon EC2 plutôt que d’utiliser les protocoles natifs tels que SSH ou RDP. Cet accès peut être contrôlé à l’aide d’IAM, qui est sécurisé et vérifié. Il est également possible d’automatiser certaines parties de vos playbooks à l’aide des documents AWS Systems Manager Run Command, qui peuvent réduire les erreurs des utilisateurs et accélérer le temps de restauration. Pour accéder aux bases de données et aux outils tiers, nous recommandons de stocker les informations d’identification dans AWS Secrets Manager et d’accorder l’accès aux rôles des intervenants en cas d’incident.

Enfin, la gestion des comptes IAM de réponse aux incidents doit être ajoutée à vos processus Joiners, Movers et Leavers et revue et testée périodiquement pour vérifier que seul l’accès prévu est autorisé.

Ressources

Documents connexes :

Vidéos connexes :

Exemples connexes :