Sécurité avec Amazon Aurora PostgreSQL - Amazon Aurora
Sécurisation des données Aurora PostgreSQL avec SSL/TLS

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 PostgreSQL

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 PostgreSQL à différents niveaux :

  • Pour contrôler qui est autorisé à exécuter des opérations de gestion Amazon RDS sur des clusters et des instances de base de données Aurora PostgreSQL, utilisez AWS Identity and Access Management (IAM). IAM gère l'authentification de l'identité de l'utilisateur avant que l'utilisateur 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. L'authentification de base de données IAM est une méthode d'authentification supplémentaire que vous pouvez choisir lorsque vous créez votre cluster de base de données Aurora PostgreSQL. Pour plus d'informations, consultez Identity and Access Management pour Amazon Aurora.

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

  • Les clusters de bases de données Aurora doivent être créés dans un cloud privé virtuel (VPC) basé sur le service Amazon VPC. Pour contrôler les appareils et les instances Amazon EC2 qui peuvent ouvrir des connexions au point de terminaison et au port de l'instance de base de données pour les clusters de bases de données Aurora d'un VPC, vous utilisez un groupe de sécurité VPC. Ces connexions au point de terminaison et au port peuvent être effectuées à l'aide du protocole SSL (Secure Socket Layer). 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 sur les VPC, consultez Amazon VPC et Amazon Aurora.

    La location de VPC prise en charge dépend de la classe d'instances de base de données utilisée par vos clusters de bases de données Aurora PostgreSQL. Avec la location de VPC default, le cluster de base de données s'exécute sur du matériel partagé. Avec la location de VPC dedicated, le cluster de base de données s'exécute sur une instance matérielle dédiée. Les classes d'instance de base de données de performance à capacité extensible prennent uniquement en charge la location de VPC 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 base de données Aurora PostgreSQL prennent en charge à la fois la location de VPC par défaut et dédiée.

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

  • Pour accorder des autorisations aux bases de données PostgreSQL exécutées sur votre cluster de base de données Amazon Aurora, vous pouvez adopter la même approche générale que pour les instances autonomes de PostgreSQL. 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.

    PostgreSQL gère les privilèges en utilisant des rôles. Le rôle rds_superuser est le rôle disposant du plus haut niveau de privilèges sur un cluster de base de données Aurora PostgreSQL. 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, veuillez consulter la section Comprendre les rôles et les autorisations PostgreSQL.

Toutes les versions Aurora PostgreSQL disponibles, y compris les versions 10, 11, 12, 13, 14 et les versions ultérieures, prennent en charge le mécanisme d'authentification SCRAM (Salted Challenge Response Authentication Mechanism) pour les mots de passe comme alternative à l'algorithme MD5. Nous vous recommandons d'utiliser SCRAM qui est plus sécurisé que MD5. Pour savoir comment migrer les mots de passe utilisateur de base de données de MD5 vers SCRAM, consultez Utilisation de SCRAM pour le chiffrement de mot de passe PostgreSQL.

Sécurisation des données Aurora PostgreSQL avec SSL/TLS

Amazon RDS prend en charge le chiffrement SSL (Secure Socket Layer) et TLS (Transport Layer Security) pour les clusters de bases de données Aurora PostgreSQL. En utilisant SSL/TLS, vous pouvez chiffrer une connexion entre vos applications et vos clusters de bases de données Aurora PostgreSQL. Vous pouvez également forcer toutes les connexions à votre cluster de base de données Aurora PostgreSQL à utiliser SSL/TLS. Amazon Aurora PostgreSQL prend en charge le protocole TLS (Transport Layer Security) versions 1.1 et 1.2. Nous vous recommandons d'utiliser TLS 1.2 pour les connexions chiffrées. Nous avons ajouté la prise en charge de TLSv1.3 dans les versions suivantes d'Aurora PostgreSQL :

  • 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 plus d'informations sur la prise en charge de SSL/TLS et les bases de données PostgreSQL, veuillez consulter Support de SSL dans la documentation PostgreSQL. Pour plus d'informations sur l'utilisation d'une connexion SSL/TLS sur JDBC, veuillez consulter Configurer le client dans la documentation PostgreSQL.

La prise en charge de SSL/TLS est disponible dans toutes les régions AWS pour Aurora PostgreSQL. Amazon RDS crée un certificat SSL/TLS pour votre cluster de base de données Aurora PostgreSQL lors de la création du cluster de base de données. Si vous activez la vérification du certificat SSL/TLS, ce dernier inclut le point de terminaison du cluster de base de données en tant que nom commun du certificat SSL/TLS pour assurer une protection contre les attaques par usurpation.

Pour se connecter à un cluster de base de données Aurora PostgreSQL via SSL/TLS

  1. Téléchargez le certificat.

    Pour plus d'informations sur le téléchargement de certificats, veuillez consulter .

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

  3. Connectez-vous à votre cluster de base de données Aurora PostgreSQL via SSL/TLS.

    Lors de la connexion avec SSL/TLS, votre client peut choisir de vérifier ou pas la chaîne du certificat. Si vos paramètres de connexion spécifient sslmode=verify-ca ou sslmode=verify-full, votre client nécessite que les certificats de l'autorité de certification RDS soient dans leur magasin d'approbations ou référencés dans l'URL de connexion. L'exigence nécessite de vérifier la chaîne du certificat qui signe le certificat de votre base de données.

    Quand un client, tel que psql ou JDBC, est configuré avec la prise en charge du protocole SSL/TLS, le comportement par défaut est le suivant : le client essaie d'abord de se connecter à la base de données avec le protocole SSL/TLS. En cas d'impossibilité, le client revient à la connexion sans protocole SSL/TLS. Par défaut, l'option sslmode est définie sur prefer pour les clients JDBC et libpq.

    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 base de données Aurora PostgreSQL :

$ 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"

Exigence d'une connexion SSL/TLS à un cluster de base de données Aurora PostgreSQL

Vous pouvez exiger que les connexions à votre cluster de base de données Aurora PostgreSQL utilisent SSL/TLS en utilisant le paramètre rds.force_ssl. Par défaut, le paramètre rds.force_ssl a pour valeur 0 (désactivé). Vous pouvez affecter au paramètre rds.force_ssl la valeur 1 (activé) pour exiger SSL/TLS pour les connexions à votre cluster de base de données. La mise à jour du paramètre rds.force_ssl affecte également la valeur 1 (activé) au paramètre PostgreSQL ssl et modifie le fichier pg_hba.conf de votre cluster de base de données pour qu'il prenne en charge la nouvelle configuration SSL/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 Utilisation des groupes de paramètres.

Lorsque le paramètre rds.force_ssl a pour valeur 1 pour un cluster de base de données, vous voyez une sortie similaire à la suivante lorsque vous vous connectez, indiquant que SSL/TLS est à présent 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 du statut de la connexion SSL/TLS

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'extension sslinfo, puis appeler la fonction ssl_is_used() pour déterminer si SSL/TLS est utilisé. La fonction renvoie t si la connexion utilise SSL/TLS ; sinon, elle renvoie f.


postgres=> create extension sslinfo;
CREATE EXTENSION

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

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


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

Si vous activez set rds.force_ssl et redémarrez le cluster de base de données, les connexions non-SSL 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 de plus amples informations sur l'option sslmode, veuillez consulter Database Connection Control Functions dans la documentation PostgreSQL.

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

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 la sécurisation des connexions SSL/TLS client à 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 Aurora PostgreSQL 11.8 et versions ultérieures.

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 paramètre ssl_ciphers comme une chaîne de valeurs de chiffrement séparées par des virgules dans un groupe de paramètres d'un cluster à l'aide de la AWS Management Console, de l'AWS CLI, ou de l'API RDS. Pour définir des paramètres de cluster, veuillez consulter Modification de paramètres dans un groupe de paramètres de cluster de base de données.

La table suivante présente les chiffrements pris en charge pour les versions valides du moteur Aurora PostgreSQL.

Versions du moteur Aurora PostgreSQL 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_256_CBC_SHA

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_256_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_SHA

  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_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_256_CBC_SHA

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_256_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

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_256_CBC_SHA

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_256_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_AES_128_GCM_SHA256

  • TLS_AES_256_GCM_SHA384

Vous pouvez également utiliser la commande CLI 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 cluster ssl_cipher pour Aurora PostgreSQL 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, veuillez consulter la variable ssl_ciphers dans la documentation PostgreSQL.