Sécurité RDS : chiffrement et groupes de paramètres

RDS prend en charge le chiffrement au repos au moyen du service AWS de gestion des clés (KMS). Lorsque vous activez le chiffrement lors de la création de l’instance DB, toutes les données des volumes EBS sous-jacents, les sauvegardes automatisées, les instantanés et les Read Replicas sont chiffrés à l’aide de la clé KMS spécifiée.

Le chiffrement doit être activé au moment de la création : vous ne pouvez pas chiffrer sur place une instance existante qui ne l’est pas. La solution consiste à prendre un instantané non chiffré, à le copier en activant le chiffrement, puis à effectuer la restauration à partir de l’instantané chiffré. La clé KMS peut être une clé gérée par AWS ou une clé gérée par le client (CMK) pour bénéficier d’un contrôle et d’un audit supplémentaires.

Comme vous ne pouvez pas activer le chiffrement sur une instance existante, suivez ce processus de migration :

1. Créez un instantané manuel de l’instance non chiffrée
2. Copiez l’instantané et activez le chiffrement pendant la copie, en spécifiant une clé KMS
3. Restaurez une nouvelle instance de base de données à partir de l’instantané chiffré
4. Mettez à jour le point de terminaison de votre application pour utiliser la nouvelle instance
5. Supprimez l’ancienne instance non chiffrée

Cette approche entraîne un certain temps d’interruption, sauf si vous utilisez DMS pour maintenir la nouvelle instance chiffrée synchronisée avant le basculement.

RDS chiffre les données en transit à l’aide de SSL/TLS. Chaque moteur fournit un certificat d’autorité de certification téléchargeable que votre pilote client utilise pour vérifier l’identité du serveur. Pour imposer les connexions SSL, configurez le moteur de base de données afin qu’il rejette les connexions non chiffrées.

Pour MySQL, définissez le paramètre require_secure_transport = ON dans le groupe de paramètres. Pour PostgreSQL, définissez ssl = 1 et, éventuellement, rds.force_ssl = 1 afin de rejeter entièrement les connexions autres que SSL. De nombreux pilotes de base de données Java et Python acceptent également un paramètre de chaîne de connexion sslmode=require.

Les groupes de paramètres sont des collections nommées de paramètres de configuration du moteur que vous associez à une instance RDS. Ils constituent l’équivalent RDS de la modification de my.cnf sur MySQL ou de postgresql.conf sur PostgreSQL, mais ils sont gérés par AWS et font l’objet d’un versionnage pour chaque famille de moteurs.

AWS fournit un groupe de paramètres par défaut pour chaque version de moteur, mais ses paramètres ne peuvent pas être modifiés. Pour personnaliser les paramètres, créez un groupe de paramètres personnalisé, modifiez les paramètres souhaités, puis associez-le à votre instance de base de données. Les modifications des paramètres statiques nécessitent un redémarrage ; les paramètres dynamiques prennent effet immédiatement.

Après avoir créé un groupe de paramètres personnalisé, vous pouvez modifier les paramètres individuellement à l’aide de la commande CLI modify-db-parameter-group ou de la console. Les paramètres possèdent une méthode d’application : immediate (prise d’effet sans redémarrage) ou pending-reboot (prise d’effet uniquement après le prochain redémarrage de l’instance).

Paramètres importants à connaître pour l’examen : max_connections (limite le nombre de connexions simultanées), innodb_buffer_pool_size (taille du cache en mémoire de MySQL), log_bin_trust_function_creators (autorise les fonctions stockées qui écrivent dans le journal binaire) et rds.force_ssl (impose SSL pour PostgreSQL).

Les groupes d’options ressemblent aux groupes de paramètres, mais ils contrôlent les fonctionnalités complémentaires du moteur de base de données plutôt que son réglage de configuration. Ils sont principalement utilisés avec Oracle et SQL Server pour activer des fonctionnalités telles qu’Oracle Application Express (APEX), Transparent Data Encryption (TDE) de SQL Server ou l’authentification Active Directory de SQL Server.

Chaque option d’un groupe d’options peut avoir ses propres paramètres. Les groupes d’options sont soumis à un versionnage pour chaque famille de moteurs et doivent être associés à l’instance de base de données. La plupart des moteurs open source (MySQL, PostgreSQL, MariaDB) nécessitent rarement des groupes d’options personnalisés.

RDS prend en charge l’authentification IAM des bases de données pour les moteurs MySQL et PostgreSQL. Au lieu d’utiliser un nom d’utilisateur et un mot de passe statiques, votre application assume un rôle IAM et génère un jeton d’authentification temporaire (valide pendant 15 minutes) à l’aide de la commande AWS CLI generate-db-auth-token ou d’un appel du SDK.

Cette fonctionnalité évite les mots de passe de base de données à longue durée de validité, permet la rotation automatique des identifiants via les politiques IAM et centralise le contrôle des accès. Elle nécessite d’activer --enable-iam-database-authentication sur l’instance et de créer un utilisateur de base de données associé à un rôle IAM.

AWS Secrets Manager peut stocker et faire tourner automatiquement le mot de passe principal de votre instance RDS ainsi que les identifiants de votre application. Lorsque la rotation est activée, Secrets Manager appelle une fonction Lambda qui met à jour le mot de passe de la base de données et stocke la nouvelle valeur dans le secret : votre application récupère la dernière valeur du secret via l’API Secrets Manager et dispose ainsi toujours d’identifiants valides.

Lors de la création d’une instance RDS dans la console, vous pouvez choisir de confier à Secrets Manager la gestion des identifiants principaux. Cela élimine les mots de passe codés en dur dans le code ou les variables d’environnement.

Les instances RDS s’exécutent au sein d’un VPC et utilisent des groupes de sous-réseaux DB pour définir les sous-réseaux (répartis sur plusieurs AZ) dans lesquels l’instance peut être placée. La bonne pratique consiste à placer RDS dans des sous-réseaux privés sans accès direct à Internet.

Les groupes de sécurité contrôlent les adresses IP et les autres groupes de sécurité autorisés à atteindre le port de la base de données (par exemple, TCP 3306 pour MySQL). Le groupe de sécurité du niveau applicatif doit être l’unique source autorisée dans le groupe de sécurité RDS, ce qui applique le principe du moindre privilège au niveau du réseau. Ne configurez jamais 0.0.0.0/0 (tout le trafic) comme règle entrante dans un groupe de sécurité RDS.

Enhanced Monitoring publie dans CloudWatch Logs des métriques au niveau du système d’exploitation (CPU, mémoire, système de fichiers, entrées-sorties disque) toutes les 1 à 60 secondes, offrant une granularité plus fine que les métriques CloudWatch par défaut, publiées toutes les 60 secondes. Cette fonctionnalité utilise un agent exécuté sur l’hôte de la base de données et est disponible pour tous les moteurs, à l’exception du mode de mise en miroir de SQL Server.

Les journaux d’audit de la base de données (journal général des requêtes et journal des requêtes lentes pour MySQL ; pgaudit pour PostgreSQL) peuvent être publiés dans CloudWatch Logs à des fins d’analyse de conformité. Activez-les via les groupes de paramètres, puis configurez les exportations de journaux dans la console RDS, sous Log exports.

Bonnes pratiques essentielles de sécurité RDS pour l’examen SAA-C03 :

• Activez le chiffrement au repos avec une CMK KMS lors de la création de l’instance
• Imposez le SSL/TLS en transit via les paramètres du groupe de paramètres
• Placez les instances dans des sous-réseaux privés avec des groupes de sécurité restrictifs
• Utilisez l’authentification IAM des bases de données ou Secrets Manager pour éviter les mots de passe statiques
• Activez CloudTrail pour journaliser les appels d’API RDS et CloudWatch Logs pour les journaux d’audit des bases de données
• Utilisez les règles AWS Config (par exemple, rds-instance-public-access-check) pour détecter les erreurs de configuration

Vérifiez votre compréhension des concepts AWS Solutions Architect (SAA-C03) présentés dans cette leçon.

Dans cette leçon, vous avez appris que le chiffrement au repos de RDS utilise KMS et doit être activé lors de la création, que les groupes de paramètres contrôlent la configuration du moteur, notamment l’application de SSL/TLS en transit, et que l’authentification IAM des bases de données et Secrets Manager éliminent les mots de passe statiques de base de données. Nous allons maintenant étudier les tables, les éléments et la conception des clés primaires de DynamoDB.