Sécurité avec Amazon Aurora Postgre SQL - Amazon Aurora
Sécurisation des SQL données Aurora Postgre avec/SSLTLS

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.

Sécurité avec Amazon Aurora Postgre SQL

Pour obtenir une présentation générale de la sécurité Aurora, consultez Sécurité dans Amazon Aurora. Vous pouvez gérer la sécurité d'Amazon Aurora Postgre SQL à différents niveaux :

  • Pour contrôler qui peut effectuer des actions de RDS gestion Amazon sur les clusters de SQL base de données et les instances de base de données Aurora Postgre, utilisez AWS Identity and Access Management (IAM). IAMgère l'authentification de l'identité de l'utilisateur avant que celui-ci ne puisse accéder au service. Il gère également l'autorisation, c'est-à-dire si l'utilisateur est autorisé à faire ce qu'il essaie de faire. IAMl'authentification de base de données est une méthode d'authentification supplémentaire que vous pouvez choisir lorsque vous créez votre cluster de SQL base de données Aurora Postgre. Pour de plus amples informations, veuillez consulter Identity and Access Management pour Amazon Aurora.

    Si vous l'utilisez IAM avec votre cluster de SQL base de données Aurora Postgre, connectez-vous d'abord au AWS Management Console avec vos IAM informations d'identification, avant d'ouvrir la RDS console Amazon à https://console.aws.amazon.com/rds/l'adresse.

  • Assurez-vous de créer des clusters de base de données Aurora dans un cloud privé virtuel (VPC) basé sur le VPC service Amazon. Pour contrôler quels appareils et EC2 instances Amazon peuvent ouvrir des connexions au point de terminaison et au port de l'instance de base de données pour les clusters de base de données Aurora d'unVPC, utilisez un groupe VPC de sécurité. Vous pouvez établir ces connexions de point de terminaison et de port à l'aide de Secure Sockets Layer (SSL). En outre, les règles de pare-feu de votre entreprise peuvent contrôler si les appareils en cours d'exécution dans votre entreprise peuvent ouvrir des connexions à une instance de base de données. Pour plus d'informations surVPCs, voirAmazon VPC et Amazon ).

    La VPC location prise en charge dépend de la classe d'instance de base de données utilisée par vos clusters de SQL base de données Aurora Postgre. Avec default VPC la location, le cluster de base de données s'exécute sur du matériel partagé. En cas de dedicated VPC location, le cluster de base de données s'exécute sur une instance matérielle dédiée. Les classes d'instances de base de données de performance burstable ne prennent en charge que la VPC location par défaut. Les classes d'instance de base de données de performance à capacité extensible incluent les classes d'instance de base de données db.t3 et db.t4g. Toutes les autres classes d'instance de SQL base de données Aurora Postgre prennent en charge à la fois la location par défaut et la VPC location dédiée.

    Pour plus d'informations sur les classes d'instance, consultez Classes d'instances de base de données Amazon Aurora. Pour plus d'informations sur la dedicated VPC location default et sur les instances dédiées, consultez le guide de l'utilisateur d'Amazon Elastic Compute Cloud.

  • Pour accorder des autorisations aux SQL bases de données Postgre exécutées sur votre cluster de bases de données Amazon Aurora, vous pouvez adopter la même approche générale que pour les instances autonomes de Postgre. SQL Les commandes telles que CREATE ROLE, ALTER ROLE, GRANT et REVOKE fonctionnent de la même façon que dans les bases de données sur site, comme le fait la modification directe des bases de données, schémas et tables.

    Postgre SQL gère les privilèges en utilisant des rôles. Ce rds_superuser rôle est le rôle le plus privilégié sur un cluster de SQL base de données Aurora Postgre. Ce rôle est créé automatiquement et il est accordé à l'utilisateur qui crée le cluster de base de données (le compte utilisateur principal, postgres par défaut). Pour en savoir plus, consultez Comprendre les rôles et les autorisations PostgreSQL.

Toutes les SQL versions disponibles d'Aurora Postgre, y compris les versions 10, 11, 12, 13, 14 et supérieures, prennent en charge le mécanisme d'authentification Salted Challenge Response Authentication (SCRAM) pour les mots de passe comme alternative au message digest (MD5). Nous vous recommandons de l'utiliser SCRAM car il est plus sécurisé queMD5. Pour plus d'informations, notamment sur la façon de migrer les mots de passe des utilisateurs de base de données de MD5 versSCRAM, consultezUtilisation de SCRAM pour le chiffrement de mot de passe PostgreSQL.

Sécurisation des SQL données Aurora Postgre avec/SSLTLS

Amazon RDS prend en charge le chiffrement Secure Socket Layer (SSL) et Transport Layer Security (TLS) pour les clusters de SQL base de données Aurora Postgre. À l'aide deSSL/TLS, vous pouvez chiffrer une connexion entre vos applications et vos clusters de SQL base de données Aurora Postgre. Vous pouvez également forcer toutes les connexions à votre cluster de SQL base de données Aurora Postgre à utiliserSSL/TLS. Amazon Aurora Postgre SQL prend en charge les versions 1.1 et 1.2 de Transport Layer Security (TLS). Nous recommandons d'utiliser la TLS version 1.2 pour les connexions chiffrées. Nous avons ajouté la prise en charge de la version TLSv1 3.3 à partir des versions suivantes d'Aurora Postgre SQL :

  • Version 15.3 et toutes les versions ultérieures

  • Version 14.8 et versions 14 ultérieures

  • Version 13.11 et versions 13 ultérieures

  • Version 12.15 et versions 12 ultérieures

  • Version 11.20 et versions 11 ultérieures

Pour des informations générales surSSL/TLSsupport et les SQL bases de données Postgre, consultez le SSLsupport dans la documentation PostgreSQL. Pour plus d'informations sur l'utilisation d'une TLS connexionSSL/JDBC, consultez la section Configuration du client dans la SQL documentation Postgre.

SSL/TLSle support est disponible dans toutes les AWS régions pour Aurora PostgreSQL. Amazon RDS crée un TLS certificatSSL/pour votre cluster de SQL base de données Aurora Postgre lors de sa création. Si vous activez la vérification du TLS certificatSSL/, le TLS certificatSSL/inclut le point de terminaison du cluster de base de données comme nom commun (CN) du TLS certificatSSL/afin de se prémunir contre les attaques par usurpation d'identité.

Pour vous connecter à un cluster de SQL base de données Aurora Postgre via/SSLTLS

  1. Téléchargez le certificat.

    Pour plus d'informations sur le téléchargement de certificats, veuillez consulter Utilisation TLS deSSL/pour chiffrer une connexion à une de clusters.

  2. Importez le certificat dans votre système d'exploitation.

  3. Connectez-vous à votre cluster de SQL base de données Aurora Postgre viaSSL/TLS.

    Lorsque vous vous connectez en utilisantSSL/TLS, votre client peut choisir de vérifier ou non la chaîne de certificats. Si vos paramètres de connexion spécifient sslmode=verify-ca ousslmode=verify-full, votre client a besoin que les certificats RDS CA figurent dans son magasin de confiance ou soient référencés dans la connexionURL. L'exigence nécessite de vérifier la chaîne du certificat qui signe le certificat de votre base de données.

    Lorsqu'un client, tel que psql ouJDBC, est configuré avecSSL/TLSsupport, le client essaie d'abord de se connecter à la base de données avecSSL/TLSpar défaut. Si le client ne parvient pas à se connecter avecSSL/TLS, il revient à se connecter sansSSL/TLS. Par défaut, l'sslmodeoption pour JDBC les clients basés sur libpq est définie sur. prefer

    Utilisez le paramètre sslrootcert pour référencer le certificat, par exemple, sslrootcert=rds-ssl-ca-cert.pem.

Voici un exemple d'utilisation de psql pour se connecter à un cluster de SQL base de données Aurora Postgre.

$ psql -h testpg.cdhmuqifdpib.us-east-1.rds.amazonaws.com -p 5432 \
    "dbname=testpg user=testuser sslrootcert=rds-ca-2015-root.pem sslmode=verify-full"

Exiger une TLS connexionSSL/à un cluster de SQL base de données Aurora Postgre

Vous pouvez exiger que les connexions à votre cluster de SQL base de données Aurora Postgre utilisentSSL/TLSen utilisant le rds.force_ssl paramètre. Par défaut, le paramètre rds.force_ssl a pour valeur 0 (désactivé). Vous pouvez définir le rds.force_ssl paramètre sur 1 (activé) pour requérirSSL/TLSpour les connexions à votre cluster de bases de données. La mise à jour du rds.force_ssl paramètre définit également le SQL ssl paramètre Postgre sur 1 (activé) et modifie le pg_hba.conf fichier de votre cluster de base de données pour prendre en charge la nouvelle configurationSSL/TLS.

Vous pouvez définir la valeur du paramètre rds.force_ssl en mettant à jour le groupe de paramètres pour votre cluster de base de données. Si le groupe de paramètres pour votre cluster de base de données n'est pas le groupe de paramètres par défaut et que le paramètre ssl a déjà pour valeur 1 lorsque vous affectez la valeur 1 au paramètre rds.force_ssl, vous n'avez pas besoin de redémarrer votre cluster de base de données. Dans le cas contraire, vous devez redémarrer votre cluster de base de données pour que la modification prenne effet. Pour plus d'informations sur les groupes de paramètres, consultez Groupes de paramètres pour Amazon Aurora.

Lorsque le rds.force_ssl paramètre est défini sur 1 pour un cluster de base de données, vous obtenez une sortie similaire à la suivante lorsque vous vous connectez, indiquant queSSL/TLSest désormais requis :


$ psql postgres -h SOMEHOST.amazonaws.com -p 8192 -U someuser
psql (9.3.12, server 9.4.4)
WARNING: psql major version 9.3, server major version 9.4.
Some psql features might not work.
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Type "help" for help.

postgres=>

Détermination de l'état de TLS la connexionSSL/

Le statut chiffré de votre connexion est affiché dans la page d'accueil d'ouverture de session lorsque vous vous connectez au cluster de base de données.

Password for user master: 
psql (9.3.12) 
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256) 
Type "help" for help.   

postgres=>

Vous pouvez également charger l'sslinfoextension, puis appeler la ssl_is_used() fonction pour déterminer siSSL/TLSest utilisé. La fonction renvoie t si la connexion utiliseSSL/TLS, sinon elle renvoief.


postgres=> create extension sslinfo;
CREATE EXTENSION

postgres=> select ssl_is_used();
 ssl_is_used
---------
t
(1 row)

Vous pouvez utiliser la select ssl_cipher() commande pour déterminer le TLS chiffreSSL/:


postgres=> select ssl_cipher();
ssl_cipher
--------------------
DHE-RSA-AES256-SHA
(1 row)

Si vous activez set rds.force_ssl et redémarrez votre cluster de base de données, SSL les non-connexions sont refusées avec le message suivant :


$ export PGSSLMODE=disable
$ psql postgres -h SOMEHOST.amazonaws.com -p 8192 -U someuser
psql: FATAL: no pg_hba.conf entry for host "host.ip", user "someuser", database "postgres", SSL off
$

Pour plus d'informations sur sslmode cette option, consultez la section Fonctions de contrôle de connexion à la base de données dans la SQL documentation Postgre.

Configuration de suites de chiffrement pour les connexions aux clusters de bases de données Aurora Postgre SQL

L'utilisation de suites de chiffrement configurables vous permet d'avoir plus de contrôle sur la sécurité des connexions de vos bases de données. Vous pouvez spécifier une liste de suites de chiffrement que vous souhaitez autoriser pour sécuriser les TLS connexions client-client SSL à votre base de données. Avec les suites de chiffrement configurables, vous pouvez contrôler le chiffrement de connexion accepté par votre serveur de base de données. Cela permet d'éviter l'utilisation de chiffrements non sécurisés ou obsolètes.

Les suites de chiffrement configurables sont prises en charge dans les SQL versions 11.8 et supérieures d'Aurora Postgre.

Pour spécifier la liste des chiffrements autorisés pour le chiffrement des connexions, modifiez le paramètre de cluster ssl_ciphers. Définissez le ssl_ciphers paramètre sur une chaîne de valeurs chiffrées séparées par des virgules dans un groupe de paramètres de cluster en utilisant le AWS Management Console, le ou le AWS CLI. RDS API Pour définir des paramètres de cluster, veuillez consulter Modification des paramètres d'un groupe de paramètres de cluster de base de données dans Amazon Aurora.

Le tableau suivant indique les chiffrements pris en charge pour les versions valides du moteur Aurora PostgreSQL.

Versions du SQL moteur Aurora Postgre Chiffrements pris en charge

9.6, 10.20 et antérieures, 11.15 et antérieures, 12.10 et antérieures, 13.6 et antérieures

  • DHE-RSA-AES128-SHA

  • DHE-RSA-AES128-SHA256

  • DHE-RSA-AES128-GCM-SHA256

  • DHE-RSA-AES256-SHA

  • DHE-RSA-AES256-SHA256

  • DHE-RSA-AES256-GCM-SHA384

  • ECDHE-ECDSA-AES256-SHA

  • ECDHE-ECDSA-AES256-GCM-SHA384

  • ECDHE-RSA-AES256-SHA384

  • ECDHE-RSA-AES128-SHA

  • ECDHE-RSA-AES128-SHA256

  • ECDHE-RSA-AES128-GCM-SHA256

  • ECDHE-RSA-AES256-SHA

  • ECDHE-RSA-AES256-GCM-SHA384

10.21, 11.16, 12.11, 13.7, 14.3 et 14.4

  • DHE-RSA-AES128-SHA

  • DHE-RSA-AES128-SHA256

  • DHE-RSA-AES128-GCM-SHA256

  • DHE-RSA-AES256-SHA

  • DHE-RSA-AES256-SHA256

  • DHE-RSA-AES256-GCM-SHA384

  • ECDHE-ECDSA-AES256-SHA

  • ECDHE-ECDSA-AES256-GCM-SHA384

  • ECDHE-RSA-AES256-SHA384

  • ECDHE-RSA-AES128-SHA

  • ECDHE-RSA-AES128-GCM-SHA256

  • ECDHE-RSA-AES256-SHA

  • ECDHE-RSA-AES256-GCM-SHA384

  • TLS_ ECDHE _ _ ECDSA WITH _ AES CBC _256_ _ SHA

  • TLS_ ECDHE _ _ ECDSA WITH _ AES GCM _256_ _ SHA384

  • TLS_ ECDHE _ _ RSA WITH _ AES CBC _128_ _ SHA

  • TLS_ ECDHE _ _ RSA WITH _ AES GCM _128_ _ SHA256

  • TLS_ ECDHE _ _ RSA WITH _ AES CBC _256_ _ SHA

  • TLS_ ECDHE _ _ RSA WITH _ AES GCM _256_ _ SHA384

  • TLS_ _ RSA WITH _ AES GCM _256_ _ SHA384

  • TLS_ _ RSA WITH _ AES CBC _256_ _ SHA

  • TLS_ _ RSA WITH _ AES GCM _128_ _ SHA256

  • TLS_ _ RSA WITH _ AES CBC _128_ _ SHA

  • TLS_ ECDHE _ _ RSA _ WITH CHACHA2 0_ 05_ POLY13 SHA256

10.22 et ultérieures, 11.17 et ultérieures, 12.12 et ultérieures, 13.8 et ultérieures, 14.5 et ultérieures et 15.2 et ultérieures

  • DHE-RSA-AES128-SHA

  • DHE-RSA-AES128-SHA256

  • DHE-RSA-AES128-GCM-SHA256

  • DHE-RSA-AES256-SHA

  • DHE-RSA-AES256-SHA256

  • DHE-RSA-AES256-GCM-SHA384

  • ECDHE-ECDSA-AES256-SHA

  • ECDHE-ECDSA-AES256-GCM-SHA384

  • ECDHE-RSA-AES256-SHA384

  • ECDHE-RSA-AES128-SHA

  • ECDHE-RSA-AES128-SHA256

  • ECDHE-RSA-AES128-GCM-SHA256

  • ECDHE-RSA-AES256-SHA

  • ECDHE-RSA-AES256-GCM-SHA384

  • TLS_ ECDHE _ _ ECDSA WITH _ AES CBC _256_ _ SHA

  • TLS_ ECDHE _ _ ECDSA WITH _ AES GCM _256_ _ SHA384

  • TLS_ ECDHE _ _ RSA WITH _ AES CBC _128_ _ SHA

  • TLS_ ECDHE _ _ RSA WITH _ AES CBC _128_ _ SHA256

  • TLS_ ECDHE _ _ RSA WITH _ AES GCM _128_ _ SHA256

  • TLS_ ECDHE _ _ RSA WITH _ AES CBC _256_ _ SHA

  • TLS_ ECDHE _ _ RSA WITH _ AES GCM _256_ _ SHA384

  • TLS_ _ RSA WITH _ AES GCM _256_ _ SHA384

  • TLS_ _ RSA WITH _ AES CBC _256_ _ SHA

  • TLS_ _ RSA WITH _ AES GCM _128_ _ SHA256

  • TLS_ _ RSA WITH _ AES CBC _128_ _ SHA256

  • TLS_ _ RSA WITH _ AES CBC _128_ _ SHA

  • TLS_ ECDHE _ _ RSA _ WITH CHACHA2 0_ 05_ POLY13 SHA256

15.3, 14.8, 13.11, 12.15 et 11.20

  • DHE-RSA-AES128-SHA

  • DHE-RSA-AES128-SHA256

  • DHE-RSA-AES128-GCM-SHA256

  • DHE-RSA-AES256-SHA

  • DHE-RSA-AES256-SHA256

  • DHE-RSA-AES256-GCM-SHA384

  • ECDHE-ECDSA-AES256-SHA

  • ECDHE-ECDSA-AES256-GCM-SHA384

  • ECDHE-RSA-AES256-SHA384

  • ECDHE-RSA-AES128-SHA

  • ECDHE-RSA-AES128-SHA256

  • ECDHE-RSA-AES128-GCM-SHA256

  • ECDHE-RSA-AES256-SHA

  • ECDHE-RSA-AES256-GCM-SHA384

  • TLS_ ECDHE _ _ ECDSA WITH _ AES CBC _256_ _ SHA

  • TLS_ ECDHE _ _ ECDSA WITH _ AES GCM _256_ _ SHA384

  • TLS_ ECDHE _ _ RSA WITH _ AES CBC _128_ _ SHA

  • TLS_ ECDHE _ _ RSA WITH _ AES CBC _128_ _ SHA256

  • TLS_ ECDHE _ _ RSA WITH _ AES GCM _128_ _ SHA256

  • TLS_ ECDHE _ _ RSA WITH _ AES CBC _256_ _ SHA

  • TLS_ ECDHE _ _ RSA WITH _ AES GCM _256_ _ SHA384

  • TLS_ _ RSA WITH _ AES GCM _256_ _ SHA384

  • TLS_ _ RSA WITH _ AES CBC _256_ _ SHA

  • TLS_ _ RSA WITH _ AES GCM _128_ _ SHA256

  • TLS_ _ RSA WITH _ AES CBC _128_ _ SHA256

  • TLS_ _ RSA WITH _ AES CBC _128_ _ SHA

  • TLS_ ECDHE _ _ RSA _ WITH CHACHA2 0_ 05_ POLY13 SHA256

  • TLS_ AES GCM _128_ _ SHA256

  • TLS_ AES GCM _256_ _ SHA384

Vous pouvez également utiliser la CLI commande describe-engine-default-cluster-parameters pour déterminer quelles suites de chiffrement sont actuellement prises en charge pour une famille de groupes de paramètres spécifique. L'exemple suivant montre comment obtenir les valeurs autorisées pour le paramètre de ssl_cipher cluster pour Aurora Postgre SQL 11.

aws rds describe-engine-default-cluster-parameters --db-parameter-group-family aurora-postgresql11
                
    ...some output truncated...
	{
		"ParameterName": "ssl_ciphers",
		"Description": "Sets the list of allowed TLS ciphers to be used on secure connections.",
		"Source": "engine-default",
		"ApplyType": "dynamic",
		"DataType": "list",
		"AllowedValues": "DHE-RSA-AES128-SHA,DHE-RSA-AES128-SHA256,DHE-RSA-AES128-GCM-SHA256,DHE-RSA-AES256-SHA,DHE-RSA-AES256-SHA256,DHE-RSA-AES256-GCM-SHA384,
		ECDHE-RSA-AES128-SHA,ECDHE-RSA-AES128-SHA256,ECDHE-RSA-AES128-GCM-SHA256,ECDHE-RSA-AES256-SHA,ECDHE-RSA-AES256-SHA384,ECDHE-RSA-AES256-GCM-SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,
		TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
		TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
		"IsModifiable": true,
		"MinimumEngineVersion": "11.8",
		"SupportedEngineModes": [
			"provisioned"
		]
	},
    ...some output truncated...

Le paramètre ssl_ciphers prend par défaut toutes les suites de chiffrement autorisées. Pour plus d'informations sur les chiffrements, consultez la variable ssl_ciphers dans la documentation Postgre. SQL