Utilisation de groupes de sécurité AD pour le contrôle d'SQLaccès Aurora Postgre - Amazon Aurora

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.

Utilisation de groupes de sécurité AD pour le contrôle d'SQLaccès Aurora Postgre

À partir des versions SQL 14.10 et 15.5 d'Aurora Postgre, le contrôle d'SQLaccès Aurora Postgre peut être géré à l'aide de AWS Directory Service pour les groupes de sécurité Microsoft Active Directory (AD). Les versions antérieures d'Aurora Postgre SQL prennent en charge l'authentification basée sur Kerberos avec AD uniquement pour les utilisateurs individuels. Chaque utilisateur AD devait être explicitement affecté au cluster de base de données pour y accéder.

Au lieu de fournir explicitement à chaque utilisateur AD un cluster de base de données en fonction des besoins de l'entreprise, vous pouvez tirer parti des groupes de sécurité AD comme expliqué ci-dessous :

  • Les utilisateurs d'AD sont membres de différents groupes de sécurité AD dans un Active Directory. Ils ne sont pas dictés par l'administrateur du cluster de base de données, mais sont basés sur les exigences de l'entreprise et sont gérés par un administrateur AD.

  • Les administrateurs de clusters de base de données créent des rôles de base de données dans les instances de base de données en fonction des exigences commerciales. Ces rôles de base de données peuvent avoir des autorisations ou des privilèges différents.

  • Les administrateurs de clusters de base de données configurent un mappage entre les groupes de sécurité AD et les rôles de base de données pour chaque cluster de base de données.

  • Les utilisateurs de bases de données peuvent accéder aux clusters de base de données en utilisant leurs informations d'identification AD. L'accès est basé sur l'appartenance au groupe de sécurité AD. Les utilisateurs d'AD obtiennent ou perdent automatiquement l'accès en fonction de leur appartenance à un groupe AD.

Prérequis

Assurez-vous de disposer des éléments suivants avant de configurer l'extension pour les groupes de sécurité AD :

Configuration de l'extension pg_ad_mapping

Aurora Postgre fournit SQL désormais une pg_ad_mapping extension pour gérer le mappage entre les groupes de sécurité AD et les rôles de base de données dans le cluster Aurora PostgreSQL. Pour plus d'informations sur les fonctions fournies parpg_ad_mapping, consultezUtilisation des fonctions de l'pg_ad_mappingextension.

Pour configurer l'pg_ad_mappingextension sur votre cluster de SQL base de données Aurora Postgre, vous devez d'abord l'ajouter pg_ad_mapping aux bibliothèques partagées sur le groupe de paramètres de cluster de base de données personnalisé pour votre cluster de SQL base de données Aurora Postgre. Pour plus d'informations sur la création d'un groupe de paramètres de cluster de base de données personnalisé, consultezGroupes de paramètres pour Amazon Aurora. Ensuite, vous installez l'pg_ad_mappingextension. Les procédures de cette section vous guident. Vous pouvez utiliser le plugin AWS Management Console ou le AWS CLI.

Vous devez disposer d'autorisations en tant que rôle rds_superuser pour effectuer toutes ces tâches.

Les étapes suivantes supposent que votre cluster de SQL base de données Aurora Postgre est associé à un groupe de paramètres de cluster de base de données personnalisé.

Pour configurer l'pg_ad_mappingextension
  1. Connectez-vous au AWS Management Console et ouvrez la RDS console Amazon à l'adresse https://console.aws.amazon.com/rds/.

  2. Dans le volet de navigation, choisissez l'instance Writer de votre SQL cluster de bases de données Aurora Postgre.

  3. Ouvrez l'onglet Configuration de votre instance de rédacteur de cluster de SQL base de données Aurora Postgre. Parmi les détails de l'instance, trouvez le lien Groupe de paramètres.

  4. Cliquez sur le lien pour ouvrir les paramètres personnalisés associés à votre cluster de SQL base de données Aurora Postgre.

  5. Dans le champ de recherche Parameters (Paramètres), tapez shared_pre pour trouver le paramètre shared_preload_libraries.

  6. Choisissez Edit parameters (Modifier les paramètres) pour accéder aux valeurs des propriétés.

  7. Ajoutez pg_ad_mapping à la liste dans le champ Values (Valeurs). Utilisez une virgule pour séparer les éléments de la liste de valeurs.

    Image du shared_preload_libaries paramètre pgAudit ajouté.
  8. Redémarrez l'instance Writer de votre cluster de SQL base de données Aurora Postgre afin que la modification apportée au shared_preload_libraries paramètre prenne effet.

  9. Lorsque l'instance est disponible, vérifiez que pg_ad_mapping a été initialisé. psqlUtilisez-le pour vous connecter à l'instance d'écriture de votre cluster de SQL base de données Aurora Postgre, puis exécutez la commande suivante.

    SHOW shared_preload_libraries; shared_preload_libraries -------------------------- rdsutils,pg_ad_mapping (1 row)
  10. Une fois pg_ad_mapping initialisé, vous pouvez maintenant créer l'extension. Vous devez créer l'extension après avoir initialisé la bibliothèque pour commencer à utiliser les fonctions fournies par cette extension.

    CREATE EXTENSION pg_ad_mapping;
  11. Fermez la session psql.

    labdb=> \q
Pour configurer pg_ad_mapping

Pour configurer pg_ad_mapping à l'aide du AWS CLI, vous appelez l'modify-db-parameter-groupopération pour ajouter ce paramètre dans votre groupe de paramètres personnalisé, comme indiqué dans la procédure suivante.

  1. Utilisez ce qui suit AWS CLI commande à ajouter pg_ad_mapping au shared_preload_libraries paramètre.

    aws rds modify-db-parameter-group \ --db-parameter-group-name custom-param-group-name \ --parameters "ParameterName=shared_preload_libraries,ParameterValue=pg_ad_mapping,ApplyMethod=pending-reboot" \ --region aws-region
  2. Utilisez ce qui suit AWS CLI commande pour redémarrer l'instance d'écriture de votre cluster de SQL base de données Aurora Postgre afin que le pg_ad_mapping soit initialisé.

    aws rds reboot-db-instance \ --db-instance-identifier writer-instance \ --region aws-region
  3. Lorsque l'instance est disponible, vous pouvez vérifier que pg_ad_mapping a été initialisé. psqlUtilisez-le pour vous connecter à l'instance d'écriture de votre cluster de SQL base de données Aurora Postgre, puis exécutez la commande suivante.

    SHOW shared_preload_libraries; shared_preload_libraries -------------------------- rdsutils,pg_ad_mapping (1 row)

    Avec pg_ad_mapping initialisé, vous pouvez désormais créer l'extension.

    CREATE EXTENSION pg_ad_mapping;
  4. Fermez la psql session afin de pouvoir utiliser le AWS CLI.

    labdb=> \q

Récupération d'un groupe SID Active Directory dans PowerShell

Un identifiant de sécurité (SID) est utilisé pour identifier de manière unique un principal ou un groupe de sécurité. Chaque fois qu'un groupe de sécurité ou un compte est créé dans Active Directory, un compte lui SID est attribué. Pour récupérer le groupe SID de sécurité AD depuis Active Directory, vous pouvez utiliser l'ADGroupapplet de commande Get- depuis la machine cliente Windows associée à ce domaine Active Directory. Le paramètre Identity spécifie le nom du groupe Active Directory pour obtenir le nom correspondantSID.

L'exemple suivant renvoie SID le groupe AD adgroup1.

C:\Users\Admin> Get-ADGroup -Identity adgroup1 | select SID SID ----------------------------------------------- S-1-5-21-3168537779-1985441202-1799118680-1612

Mappage du rôle de base de données avec le groupe de sécurité AD

Vous devez explicitement configurer les groupes de sécurité AD dans la base de données en tant que rôle de base de données SQL Postgre. Un utilisateur AD faisant partie d'au moins un groupe de sécurité AD provisionné aura accès à la base de données. Vous ne devez pas accorder rds_ad role au groupe AD un rôle de base de données basé sur la sécurité. L'authentification Kerberos pour le groupe de sécurité sera déclenchée en utilisant le suffixe du nom de domaine tel que user1@example.com. Ce rôle de base de données ne peut pas utiliser de mot de passe ou IAM d'authentification pour accéder à la base de données.

Note

Les utilisateurs AD qui ont un rôle de base de données correspondant dans la base de données auquel le rds_ad rôle leur est accordé ne peuvent pas se connecter dans le cadre du groupe de sécurité AD. Ils y auront accès via le rôle de base de données en tant qu'utilisateur individuel.

Par exemple, accounts-group est un groupe de sécurité dans AD dans lequel vous souhaitez configurer ce groupe de sécurité dans Aurora Postgre SQL en tant que rôle de compte.

Groupe de sécurité AD Rôle de base de données SQL Publier
groupe de comptes rôle des comptes

Lorsque vous mappez le rôle de base de données avec le groupe de sécurité AD, vous devez vous assurer que le rôle de base de données possède l'LOGINattribut défini et qu'il possède le CONNECT privilège d'accéder à la base de données de connexion requise.

postgres => alter role accounts-role login; ALTER ROLE postgres => grant connect on database accounts-db to accounts-role;

L'administrateur peut maintenant procéder à la création du mappage entre le groupe de sécurité AD et le rôle de base de SQL données Postgre.

admin=>select pgadmap_set_mapping('accounts-group', 'accounts-role', <SID>, <Weight>);

Pour plus d'informations sur la récupération SID du groupe de sécurité AD, consultezRécupération d'un groupe SID Active Directory dans PowerShell.

Dans certains cas, un utilisateur AD peut appartenir à plusieurs groupes. Dans ce cas, l'utilisateur AD héritera des privilèges du rôle de base de données, qui a été attribué avec le poids le plus élevé. Si les deux rôles ont le même poids, l'utilisateur AD héritera des privilèges du rôle de base de données correspondant au mappage récemment ajouté. Il est recommandé de spécifier des pondérations qui reflètent les autorisations/privilèges relatifs des rôles de base de données individuels. Plus les autorisations ou privilèges d'un rôle de base de données sont élevés, plus le poids qui doit être associé à l'entrée de mappage est élevé. Cela permettra d'éviter l'ambiguïté de deux mappages ayant le même poids.

Le tableau suivant présente un exemple de mappage entre les groupes de sécurité AD et les rôles de SQL base de données Aurora Postgre.

Groupe de sécurité AD Rôle de base de données SQL Publier Weight
groupe de comptes rôle des comptes 7
groupe de vente rôle de vente 10
groupe de développement rôle de développement 7

Dans l'exemple suivant, user1 héritera des privilèges de sales-role puisqu'il a le poids le plus élevé, tandis que user2 le mappage de ce rôle a été créé ultérieurementaccounts-role, qui partagent le dev-role même poids que. accounts-role

Nom d’utilisateur Adhésion à un groupe de sécurité
user1 groupe de ventes de comptes
user2 groupes-comptes-dev-group

Les commandes psql permettant d'établir, de répertorier et d'effacer les mappages sont présentées ci-dessous. Il n'est actuellement pas possible de modifier une seule entrée de mappage. L'entrée existante doit être supprimée et le mappage recréé.

admin=>select pgadmap_set_mapping('accounts-group', 'accounts-role', 'S-1-5-67-890', 7); admin=>select pgadmap_set_mapping('sales-group', 'sales-role', 'S-1-2-34-560', 10); admin=>select pgadmap_set_mapping('dev-group', 'dev-role', 'S-1-8-43-612', 7); admin=>select * from pgadmap_read_mapping(); ad_sid | pg_role | weight | ad_grp -------------+----------------+--------+--------------- S-1-5-67-890 | accounts-role | 7 | accounts-group S-1-2-34-560 | sales-role | 10 | sales-group S-1-8-43-612 | dev-role | 7 | dev-group (3 rows)

Enregistrement/audit de l'identité des utilisateurs AD

Utilisez la commande suivante pour déterminer le rôle de base de données hérité par l'utilisateur actuel ou par l'utilisateur de session :

postgres=>select session_user, current_user; session_user | current_user -------------+-------------- dev-role | dev-role (1 row)

Pour déterminer l'identité principale de sécurité AD, utilisez la commande suivante :

postgres=>select principal from pg_stat_gssapi where pid = pg_backend_pid(); principal ------------------------- user1@example.com (1 row)

Actuellement, l'identité de l'utilisateur AD n'est pas visible dans les journaux d'audit. Le log_connections paramètre peut être activé pour enregistrer l'établissement d'une session de base de données. Pour plus d'informations, consultez log_connections. La sortie correspondante inclut l'identité de l'utilisateur AD, comme indiqué ci-dessous. Le backend PID associé à cette sortie peut ensuite aider à attribuer les actions à l'utilisateur AD réel.

pgrole1@postgres:[615]:LOG: connection authorized: user=pgrole1 database=postgres application_name=psql GSS (authenticated=yes, encrypted=yes, principal=Admin@EXAMPLE.COM)

Limites

  • L'identifiant Microsoft Entra connu sous le nom d'Azure Active Directory n'est pas pris en charge.

Utilisation des fonctions de l'pg_ad_mappingextension

pg_ad_mappingl'extension a pris en charge les fonctions suivantes :

pgadmap_set_mapping

Cette fonction établit le mappage entre le groupe de sécurité AD et le rôle de base de données avec un poids associé.

Syntaxe

pgadmap_set_mapping( ad_group, db_role, ad_group_sid, weight)

Arguments

Paramètre Description
ad_group Nom du groupe AD. La valeur ne peut pas être nulle ou une chaîne vide.
db_role Rôle de base de données à mapper au groupe AD spécifié. La valeur ne peut pas être nulle ou une chaîne vide.
ad_group_sid Identifiant de sécurité utilisé pour identifier de manière unique le groupe AD. La valeur commence par « S-1- » et ne peut pas être une chaîne nulle ou vide. Pour de plus amples informations, veuillez consulter Récupération d'un groupe SID Active Directory dans PowerShell.
poids Poids associé au rôle de base de données. Le rôle ayant le plus de poids est prioritaire lorsque l'utilisateur est membre de plusieurs groupes. La valeur par défaut du poids est 1.

Type de retour

None

Notes d’utilisation

Cette fonction ajoute un nouveau mappage entre le groupe de sécurité AD et le rôle de base de données. Il ne peut être exécuté que sur l'instance de base de données principale du cluster de base de données par un utilisateur disposant du privilège rds_superuser.

Exemples

postgres=> select pgadmap_set_mapping('accounts-group','accounts-role','S-1-2-33-12345-67890-12345-678',10); pgadmap_set_mapping (1 row)

pgadmap_read_mapping

Cette fonction répertorie les mappages entre le groupe de sécurité AD et le rôle de base de données définis à l'aide de pgadmap_set_mapping la fonction.

Syntaxe

pgadmap_read_mapping()

Arguments

None

Type de retour

Paramètre Description
ad_group_sid Identifiant de sécurité utilisé pour identifier de manière unique le groupe AD. La valeur commence par « S-1- » et ne peut pas être une chaîne nulle ou vide. Pour plus d'informations, consultez Récupération d'un groupe SID Active Directory dans PowerShell .accounts-role@example.com
db_role Rôle de base de données à mapper au groupe AD spécifié. La valeur ne peut pas être nulle ou une chaîne vide.
poids Poids associé au rôle de base de données. Le rôle ayant le plus de poids est prioritaire lorsque l'utilisateur est membre de plusieurs groupes. La valeur par défaut du poids est 1.
ad_group Nom du groupe AD. La valeur ne peut pas être nulle ou une chaîne vide.

Notes d’utilisation

Appelez cette fonction pour répertorier tous les mappages disponibles entre le groupe de sécurité AD et le rôle de base de données.

Exemples

postgres=> select * from pgadmap_read_mapping(); ad_sid | pg_role | weight | ad_grp ------------------------------------+---------------+--------+------------------ S-1-2-33-12345-67890-12345-678 | accounts-role | 10 | accounts-group (1 row) (1 row)

pgadmap_reset_mapping

Cette fonction réinitialise un ou tous les mappages définis à l'aide pgadmap_set_mapping de function.

Syntaxe

pgadmap_reset_mapping( ad_group_sid, db_role, weight)

Arguments

Paramètre Description
ad_group_sid Identifiant de sécurité utilisé pour identifier de manière unique le groupe AD.
db_role Rôle de base de données à mapper au groupe AD spécifié.
poids Poids associé au rôle de base de données.

Si aucun argument n'est fourni, tous les mappages du groupe AD au rôle de base de données sont réinitialisés. Tous les arguments doivent être fournis ou aucun.

Type de retour

None

Notes d’utilisation

Appelez cette fonction pour supprimer un groupe AD spécifique au mappage des rôles de base de données ou pour réinitialiser tous les mappages. Cette fonction ne peut être exécutée que sur l'instance de base de données principale du cluster de base de données par un utilisateur disposant de rds_superuser privilèges.

Exemples

postgres=> select * from pgadmap_read_mapping(); ad_sid | pg_role | weight | ad_grp --------------------------------+--------------+-------------+------------------- S-1-2-33-12345-67890-12345-678 | accounts-role| 10 | accounts-group S-1-2-33-12345-67890-12345-666 | sales-role | 10 | sales-group (2 rows) postgres=> select pgadmap_reset_mapping('S-1-2-33-12345-67890-12345-678', 'accounts-role', 10); pgadmap_reset_mapping (1 row) postgres=> select * from pgadmap_read_mapping(); ad_sid | pg_role | weight | ad_grp --------------------------------+--------------+-------------+--------------- S-1-2-33-12345-67890-12345-666 | sales-role | 10 | sales-group (1 row) postgres=> select pgadmap_reset_mapping(); pgadmap_reset_mapping (1 row) postgres=> select * from pgadmap_read_mapping(); ad_sid | pg_role | weight | ad_grp --------------------------------+--------------+-------------+-------------- (0 rows)