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.
Infrastructure OU — Compte Shared Services
| Influencez le futur de l'architecture de référence de AWS sécurité (AWSSRA) en répondant à une courte enquête |
Le schéma suivant illustre les services de sécurité AWS configurés dans le compte Shared Services.
Le compte Shared Services fait partie de l'unité d'organisation de l'infrastructure et son objectif est de prendre en charge les services utilisés par de nombreuses applications et équipes pour obtenir leurs résultats. Par exemple, les services d'annuaire (Active Directory), les services de messagerie et les services de métadonnées entrent dans cette catégorie. L'AWS SRA met en avant les services partagés qui prennent en charge les contrôles de sécurité. Bien que les comptes réseau fassent également partie de l'unité d'organisation d'infrastructure, ils sont supprimés du compte Shared Services pour faciliter la séparation des tâches. Les équipes chargées de gérer ces services n'ont pas besoin d'autorisations ni d'accès aux comptes du réseau.
AWS Systems Manager
AWS Systems Manager
Systems Manager vous aide à maintenir la sécurité et la conformité en scannant vos instances gérées et en signalant (ou en prenant des mesures correctives) les violations des politiques détectées. En associant Systems Manager au déploiement approprié sur les comptes AWS individuels des membres (par exemple, le compte Application), vous pouvez coordonner la collecte des données d'inventaire des instances et centraliser les automatisations telles que les correctifs et les mises à jour de sécurité.
Microsoft AD géré par AWS
AWS Directory Service
AWS Managed Microsoft AD vous aide à étendre votre Active Directory existant à AWS et à utiliser vos informations d'identification utilisateur sur site existantes pour accéder aux ressources du cloud. Vous pouvez également administrer vos utilisateurs, groupes, applications et systèmes locaux sans la complexité liée à l'exécution et à la maintenance d'un Active Directory hautement disponible sur site. Vous pouvez associer vos ordinateurs, ordinateurs portables et imprimantes existants à un domaine Microsoft AD géré par AWS.
AWS Managed Microsoft AD repose sur Microsoft Active Directory et ne vous oblige pas à synchroniser ou à répliquer les données de votre Active Directory existant vers le cloud. Vous pouvez utiliser les outils et fonctionnalités d'administration Active Directory habituels, tels que les objets de stratégie de groupe (GPO), les approbations de domaine, les politiques de mot de passe détaillées, les comptes de services gérés de groupe (GMSA), les extensions de schéma et l'authentification unique basée sur Kerberos. Vous pouvez également déléguer des tâches administratives et autoriser l'accès à l'aide des groupes de sécurité Active Directory.
La réplication multirégionale vous permet de déployer et d'utiliser un seul répertoire Microsoft AD géré par AWS dans plusieurs régions AWS. Cela vous permet de déployer et de gérer plus facilement et à moindre coût vos charges de travail Microsoft Windows et Linux dans le monde entier. Lorsque vous utilisez la fonctionnalité de réplication multirégionale automatisée, vous bénéficiez d'une meilleure résilience tandis que vos applications utilisent un répertoire local pour des performances optimales.
AWS Managed Microsoft AD prend en charge le protocole LDAP (Lightweight Directory Access Protocol) sur SSL/TLS, également appelé LDAPS, dans les rôles client et serveur. Lorsqu'il agit en tant que serveur, AWS Managed Microsoft AD prend en charge le protocole LDAPS via les ports 636 (SSL) et 389 (TLS). Vous activez les communications LDAPS côté serveur en installant un certificat sur vos contrôleurs de domaine Microsoft AD gérés par AWS à partir d'une autorité de certification (CA) Active Directory Certificate Services (AD CS) basée sur AWS. Lorsque vous agissez en tant que client, AWS Managed Microsoft AD prend en charge le protocole LDAPS sur les ports 636 (SSL). Vous pouvez activer les communications LDAPS côté client en enregistrant les certificats CA émis par les émetteurs de certificats de votre serveur dans AWS, puis en activant LDAPS dans votre annuaire.
Dans l'AWS SRA, AWS Directory Service est utilisé dans le compte Shared Services pour fournir des services de domaine pour les charges de travail compatibles avec Microsoft sur plusieurs comptes membres AWS.
Considération de conception
-
Vous pouvez autoriser vos utilisateurs Active Directory locaux à se connecter à l'AWS Management Console et à l'AWS Command Line Interface (AWS CLI) avec leurs informations d'identification Active Directory existantes en utilisant IAM Identity Center et en sélectionnant AWS Managed Microsoft AD comme source d'identité. Cela permet à vos utilisateurs d'assumer l'un des rôles qui leur sont assignés lors de la connexion, d'accéder aux ressources et d'agir sur celles-ci conformément aux autorisations définies pour le rôle. Une autre option consiste à utiliser AWS Managed Microsoft AD pour permettre à vos utilisateurs d'assumer un rôle AWS Identity and Access Management
(IAM).
IAM Identity Center
L'AWS SRA utilise la fonctionnalité d'administrateur délégué prise en charge par IAM Identity Center pour déléguer la majeure partie de l'administration d'IAM Identity Center au compte Shared Services. Cela permet de limiter le nombre d'utilisateurs qui ont besoin d'accéder au compte de gestion de l'organisation. IAM Identity Center doit toujours être activé dans le compte de gestion de l'organisation pour effectuer certaines tâches, notamment la gestion des ensembles d'autorisations fournis dans le compte de gestion de l'organisation.
La principale raison de l'utilisation du compte Shared Services en tant qu'administrateur délégué pour IAM Identity Center est l'emplacement Active Directory. Si vous envisagez d'utiliser Active Directory comme source d'identité IAM Identity Center, vous devez localiser le répertoire dans le compte membre que vous avez désigné comme compte d'administrateur délégué IAM Identity Center. Dans l'AWS SRA, le compte Shared Services héberge AWS Managed Microsoft AD, de sorte que ce compte est désigné comme administrateur délégué d'IAM Identity Center.
IAM Identity Center prend en charge l'enregistrement d'un seul compte membre en tant qu'administrateur délégué à la fois. Vous ne pouvez créer un compte membre que lorsque vous vous connectez avec les informations d'identification du compte de gestion. Pour activer la délégation, vous devez prendre en compte les conditions requises répertoriées dans la documentation de l'IAM Identity Center. Le compte d'administrateur délégué peut effectuer la plupart des tâches de gestion d'IAM Identity Center, mais avec certaines restrictions, répertoriées dans la documentation d'IAM Identity Center. L'accès au compte d'administrateur délégué d'IAM Identity Center doit être étroitement contrôlé.
Considérations relatives à la conception
-
Si vous décidez de remplacer la source d'identité IAM Identity Center d'une autre source par Active Directory, ou de la remplacer par une autre source, le répertoire doit résider (appartenir à) le compte membre administrateur délégué d'IAM Identity Center, s'il en existe un ; sinon, il doit se trouver dans le compte de gestion.
-
Vous pouvez héberger votre AWS Managed Microsoft AD au sein d'un VPC dédié sur un autre compte, puis utiliser AWS Resource Access Manager (AWS RAM) pour partager des sous-réseaux de cet autre compte avec le compte d'administrateur délégué. Ainsi, l'instance AWS Managed Microsoft AD est contrôlée dans le compte d'administrateur délégué, mais du point de vue du réseau, elle agit comme si elle était déployée dans le VPC d'un autre compte. Cela est utile lorsque vous disposez de plusieurs instances Microsoft AD gérées par AWS et que vous souhaitez les déployer localement là où votre charge de travail est exécutée, tout en les gérant de manière centralisée via un seul compte.
-
Si vous disposez d'une équipe dédiée aux identités qui effectue des activités régulières de gestion des identités et des accès ou si vous avez des exigences de sécurité strictes pour séparer les fonctions de gestion des identités des autres fonctions de services partagés, vous pouvez héberger un compte AWS dédié à la gestion des identités. Dans ce scénario, vous désignez ce compte comme administrateur délégué pour IAM Identity Center, et il héberge également votre répertoire Microsoft AD géré par AWS. Vous pouvez atteindre le même niveau d'isolation logique entre vos charges de travail de gestion des identités et les charges de travail des autres services partagés en utilisant des autorisations IAM précises au sein d'un seul compte de service partagé.
-
IAM Identity Center ne fournit actuellement pas de support multirégional. (Pour activer IAM Identity Center dans une autre région, vous devez d'abord supprimer votre configuration IAM Identity Center actuelle.) En outre, il ne prend pas en charge l'utilisation de différentes sources d'identité pour différents ensembles de comptes et ne vous permet pas de déléguer la gestion des autorisations à différentes parties de votre organisation (c'est-à-dire plusieurs administrateurs délégués) ou à différents groupes d'administrateurs. Si vous avez besoin de l'une de ces fonctionnalités, vous pouvez utiliser la fédération IAM pour gérer vos identités d'utilisateur au sein d'un fournisseur d'identité (IdP) extérieur à AWS et autoriser ces identités d'utilisateurs externes à utiliser les ressources AWS de votre compte. Les supports IAM sont IdPs compatibles avec OpenID Connect (
OIDC) ou SAML 2.0. Il est recommandé d'utiliser la fédération SAML 2.0 avec des fournisseurs d'identité tiers tels qu'Active Directory Federation Service (AD FS), Okta, Azure Active Directory (Azure AD) ou Ping Identity pour fournir une fonctionnalité d'authentification unique permettant aux utilisateurs de se connecter à l'AWS Management Console ou d'appeler les opérations d'API AWS. Pour plus d'informations sur la fédération IAM et les fournisseurs d'identité, consultez la section À propos de la fédération basée sur SAML 2.0 dans la documentation IAM et dans les ateliers AWS Identity Federation.
