Auditer les actions administratives dans votre Oracle RDS et EC2
Préface
Service de bases de données relationnelles Amazon (Amazon RDS) est un service web qui facilite la mise en place, l’exploitation et la montée en charge d’une base de données relationnelle dans le cloud AWS. Il offre une capacité redimensionnable et économique pour une base de données relationnelle standard dans l’industrie et gère des tâches d’administration de base de données courantes.
DataSunrise est un Partenaire Technologique Avancé AWS certifié sur la compétence en Sécurité dans la Protection des Données et le Chiffrement ainsi que d’autres qualifications validées par AWS. DataSunrise peut fonctionner sur site, sur une instance EC2 ou sous forme de cluster sur plusieurs instances EC2, dans une machine virtuelle ou sur du matériel dédié. La suite DataSunrise Data and Database Security (DataSunrise) pour tous types d’Amazon RDS agit comme un pare-feu applicatif de base de données (DAF) en se positionnant en tant qu’homme du milieu pour toutes les sessions, requêtes et commandes passant de n’importe quel client à l’instance Amazon RDS. Et puisque DataSunrise est le logiciel et non une solution SaaS, vous êtes responsable de mettre en place et de configurer correctement votre instance DataSunrise.
L’objectif principal de cet article est de présenter l’approche permettant d’auditer l’activité des comptes privilégiés. Nous verrons comment configurer DataSunrise pour auditer l’activité des DBA dans Oracle RDS. Toutefois, toutes les étapes générales s’appliquent à n’importe quelle instance Amazon RDS.
Vue d’ensemble d’Oracle RDS et prérequis
Comme vous le savez sans doute, Amazon RDS permet l’accès aux bases de données via toute application cliente SQL standard et n’autorise pas l’accès direct à l’hôte par SSH, etc. Cette architecture ne permet pas d’installer des agents de base de données dans Amazon RDS et limite l’utilisation de privilèges puissants de DBA comme SYSDBA. Amazon RDS adopte un modèle de responsabilité partagée qui exclut une intervention humaine directe sur la plateforme de calcul. Toutefois, avec Amazon RDS, vous pouvez réaliser vos tâches de manière légèrement différente et unifiée. Par exemple, un DBA peut accéder aux journaux de la base de données ou sauvegarder des instances Amazon RDS avec des instantanés en utilisant la Console de Gestion AWS, l’AWS CLI ou l’API RDS. D’autre part, vous n’êtes pas en mesure d’accéder à Amazon RDS via des connexions SSH ou RDP pour des activités liées à la base de données ou au système d’exploitation – et potentiellement nuisibles. Veuillez donc garder à l’esprit qu’en possédant le rôle IAM requis, vous pouvez modifier et gérer votre instance Amazon RDS pour répondre aux exigences de votre système sans vous connecter à Amazon RDS via SSH/RDP.
Un aspect important concerne le rôle Oracle SYSDBA et des privilèges similaires. Le rôle SYSDBA est attribué uniquement à l’utilisateur RDSADMIN (AWS utilise l’utilisateur système « rdshm ») et le mot de passe RDSADMIN est inconnu. De plus, avec Oracle RDS, vous ne pouvez pas connaître le mot de passe de l’utilisateur SYS. Et tout cela signifie que :
- vous ne pouvez pas vous connecter à votre Oracle RDS en utilisant l’utilisateur RDSADMIN ou SYS ;
- vos utilisateurs de base de données ne peuvent pas obtenir le rôle SYSDBA ou d’autres rôles puissants d’Oracle Database ;
- vous ne pouvez pas vous connecter à distance à l’instance Oracle RDS en utilisant le rôle SYSDBA ou tout autre rôle puissant d’Oracle Database.
Ces privilèges limités sécurisent et protègent chaque instance RDS. Oracle RDS crée pour vous un utilisateur DBA limité (par exemple, l’utilisateur « admin » par défaut) afin que vous puissiez vous connecter à l’instance Oracle RDS en utilisant cet utilisateur. Par la suite, vous pouvez créer un autre utilisateur et ce nouvel utilisateur n’obtiendra pas plus de privilèges que ceux dont dispose votre utilisateur « admin ». Cela est encore lié au modèle de responsabilité partagée de gestion dans AWS. L’équipe Amazon RDS a défini une ligne rouge que vous ne pouvez pas franchir.
Nous laisserons la mise en place d’Oracle RDS en dehors du champ de cet article et, pour continuer avec les prochaines étapes, vous aurez besoin d’une instance Oracle RDS opérationnelle et nous espérons que vous pourrez démarrer un nouvel Oracle RDS ou vous avez déjà accès à une instance Oracle RDS existante. Si vous souhaitez connaître les meilleures pratiques pour faire fonctionner Oracle RDS, veuillez consulter la documentation AWS.
Dans la section suivante, nous examinerons ce qui est disponible pour l’audit de l’activité des DBA.
Activité des DBA sur Oracle RDS et options d’audit
Les limitations des instances RDS soulèvent de nombreuses questions sur la manière d’auditer des actions spécifiques aux DBA telles que ALTER SYSTEM, CREATE USER, DROP DATABASE, etc. Et comment auditer ces utilisateurs internes à RDS comme RDSADMIN ? Examinons toutes les options disponibles.
- Vous pouvez consulter l’activité interne de RDS via les fichiers journaux de la base de données Amazon RDS Vous pouvez visualiser, télécharger et surveiller les journaux de la base de données en utilisant la console Amazon RDS, l’interface en ligne de commande AWS (AWS CLI) ou l’API Amazon RDS. Amazon fournit un service de restauration à un instant T (Point-In-Time Recovery) et affirme que RDS charge les journaux de transactions des instances de base de données vers Amazon S3 toutes les 5 minutes. Ainsi, les fichiers journaux de la base de données et le service CloudTrail vous aident à analyser l’activité de l’utilisateur RDSADMIN ainsi qu’à obtenir des informations supplémentaires sur les événements Oracle RDS. Toutes ces options sont intéressantes jusqu’à ce que vous ayez besoin d’une surveillance des transactions en temps réel et d’alertes.
- Avec des instances DAF fonctionnant sur des machines virtuelles EC2 séparées, vous pouvez auditer toutes les sessions et requêtes transitant vers votre instance Amazon RDS. Le but des instances DAF est de devenir votre gardien de base de données et, puisque vous devez surveiller l’activité des DBA, nous examinerons cette option en détail par la suite. Les instances DataSunrise sur les boîtes EC2 sont capables de surveiller et de sécuriser l’activité réseau vers Amazon RDS.
Vue d’ensemble de DataSunrise sur AWS et prérequis
La mise en place et la configuration des instances sécurisées de DataSunrise impliquent plusieurs étapes importantes. Pour préparer votre instance DataSunrise sécurisée dans l’environnement AWS, veuillez suivre les étapes décrites dans notre document DataSunrise AWS Security Best Practices. Pour en citer quelques-unes, les étapes suivantes sont nécessaires :
- attribuer les rôles IAM appropriés à vos instances EC2 hébergeant les instances DataSunrise ;
- créer et attribuer des groupes de sécurité VPC à votre instance Amazon RDS et aux instances EC2 disposant du logiciel DataSunrise ;
- utiliser des mots de passe sécurisés et uniques pour chaque compte.
L’architecture ci-dessous se compose d’une instance de base de données (RDS ou sur une instance EC2) derrière le DAF, d’une base de données de stockage d’audit séparée (RDS ou sur une instance EC2) et d’une instance DataSunrise qui sert de serveur proxy pour les connexions utilisateurs.
En option, DataSunrise fournit des scripts CloudFormation pour déployer dans AWS des solutions de sécurité de base de données sécurisées et économiques. Suite à la création de votre instance Amazon RDS, ces scripts automatisent toutes les tâches requises pour déployer des instances EC2, installer DataSunrise sur ces instances EC2, configurer un équilibreur de charge Amazon ainsi que la création de toutes les autres ressources AWS nécessaires. Nous passerons l’option CloudFormation et poursuivrons avec un scénario à instance EC2 unique. Nous avons préparé des vidéos sur la manière d’installer une instance DataSunrise, veuillez regarder l’une des vidéos et suivre les étapes requises :
- Installation de DataSunrise sur Linux Installation de DataSunrise sur Linux — YouTube
- Installation de DataSunrise sur Windows Installation de DataSunrise sur Windows — YouTube
À la fin du processus d’installation, votre instance DataSunrise devrait être accessible depuis votre navigateur Web. Vous devrez avoir une instance DataSunrise opérationnelle afin de pouvoir accéder à la Console Web de DataSunrise avec les privilèges requis.
Le prochain prérequis concerne la Configuration de la Base de Données que vous devez créer dans l’instance DataSunrise pour démarrer un proxy vers Amazon RDS. Veuillez vous référer au Guide de l’utilisateur DataSunrise, section « 3.1 Création d’un profil de base de données cible et d’un proxy » et section « 5.1.6 Création d’utilisateurs de base de données nécessaires pour récupérer les métadonnées de la base de données ». Comme DataSunrise en mode proxy agit comme un homme du milieu en interceptant tous les paquets TCP non-AWS vers l’instance Amazon RDS, vous pouvez utiliser le même port standard d’Oracle Database, le 1521, puisque l’instance DataSunrise fonctionne sur une autre instance EC2. Enfin, assurez-vous que votre instance Amazon RDS ne soit PAS accessible depuis une autre adresse IP/nom et port non-AWS, hormis via l’instance DataSunrise. Toutes ces étapes garantiront que toutes vos applications clientes puissent accéder à votre instance Oracle RDS exclusivement par l’intermédiaire de votre instance DataSunrise.
Configuration de DataSunrise pour auditer les DBA
Comme nous l’avons mentionné précédemment, lors de la création de votre Oracle RDS, vous recevez un compte DBA limité et son mot de passe ; par défaut, Oracle RDS propose l’utilisateur de base de données « admin » pour accéder à votre instance. Et comme vous vous en souvenez, Amazon RDS désactive le privilège SYSDBA pour vous. Cela réduit ainsi les risques potentiels affectant l’instance Amazon RDS. Si votre Oracle RDS est accessible depuis votre machine de bureau, essayez de vous connecter à votre Oracle RDS en tant que SYSDBA pour le prouver, voir un exemple ci-dessous.
Vous verrez qu’aucun privilège SYSDBA, SYSOPER ou autre privilège lié à SYS n’est disponible dans Oracle RDS, que ce soit via TCP ou SSH.
Vous devez donc veiller à auditer les connexions réseau – les connexions à distance en utilisant l’outil adéquat tel que DataSunrise DAF. Nous allons configurer l’instance DataSunrise pour capturer tout type d’action que votre DBA peut effectuer à distance sur l’instance Amazon RDS.
Résumé des étapes suivantes
Pour auditer les actions des DBA, nous allons effectuer les étapes suivantes :
- Identifier vos noms / comptes d’utilisateurs DBA. DataSunrise répertorie les Utilisateurs de Base de Données dans son menu de Configuration. Si vous avez plus d’un DBA, créez un nouveau Groupe d’utilisateurs de base de données sous Configuration → Utilisateurs de base de données. Dans notre exemple, nous utiliserons le DBA appelé « admin » qui a été généré par notre instance Oracle RDS.
- En utilisant Configuration → Groupes d’objets, créez une nouvelle entrée et ajoutez un seul élément avec l’expression régulière « . * ».
- Créez une nouvelle règle d’audit pour inclure le Groupe d’utilisateurs de base de données et le Groupe de requêtes afin d’auditer l’activité des DBA.
- Vérifiez l’activité des DBA dans l’instance DataSunrise.
1. Identifier et configurer vos utilisateurs DBA dans DataSunrise
Poursuivons avec toutes ces étapes. Tout d’abord, sous Configuration → Utilisateurs de base de données, vérifiez que l’utilisateur « admin » est connu de votre instance DataSunrise. Si DataSunrise n’en possède pas, créez l’utilisateur « admin » manuellement. Si vous avez plusieurs instances Oracle RDS et qu’il utilise le même nom d’utilisateur DBA « admin », vous pouvez choisir l’option <Any> Instance. N’oubliez pas de cliquer sur le bouton Enregistrer afin de sauvegarder vos paramètres sur chaque page.
Dans l’image ci-dessus, nous avons créé l’utilisateur ADMIN et l’avons inclus dans le groupe « Oracle DBA Team ». Si vous avez créé plusieurs utilisateurs DBA, veuillez les ajouter au Groupe d’utilisateurs « Oracle DBA Team » dans l’instance DataSunrise.
2. Configurer un nouveau Groupe de requêtes
Deuxième étape – nous allons créer notre nouveau Groupe de requêtes « AnyQuery » et ajouter un seul élément « . * » dans l’item de requête. Veuillez consulter les paramètres dans l’image ci-dessous.
Lorsque vous créez une nouvelle requête pour le Groupe de requêtes (voir le bouton « Ajouter » sur l’image), veuillez vérifier la case à cocher « Expression régulière ».
À ce stade, nous avons l’utilisateur de base de données « ADMIN », le Groupe d’utilisateurs « Oracle DBA Team » enregistré dans l’instance DataSunrise et notre Groupe de requêtes « AnyQuery » comportant une requête avec le modèle d’expression régulière « . * » pour correspondre à n’importe quelle requête. Nous avons ainsi parcouru la moitié du chemin.
3. Créer et configurer une nouvelle règle d’audit
Ensuite, nous allons créer une nouvelle règle d’audit portant le nom « Oracle : admin queries » en utilisant ce que nous avons créé dans l’instance DataSunrise. Veuillez ouvrir la Console Web et accéder à Audit → Règles. Cliquez sur Créer pour créer la nouvelle règle. Veuillez consulter les détails dans les images ci-dessous.
Nous utiliserons l’onglet Filtres de déclarations et l’onglet Groupe de requêtes sur la page afin de connecter notre règle aux paramètres correspondants que nous avons définis précédemment, voir les détails dans les images suivantes.
Lorsque vous sélectionnez le Groupe d’utilisateurs DBA Oracle pour le paramètre de session Groupe d’utilisateurs de BD, vous faites en sorte que DataSunrise capture toute session provenant de n’importe quelle IP/hôte possédant un nom d’utilisateur figurant dans la liste « Oracle DBA Team ». Lorsque vous ajoutez un autre utilisateur de base de données à ce groupe, cette règle vérifiera automatiquement le nouvel utilisateur. Et puisque vous utilisez l’onglet Groupe de requêtes sur la page de la règle d’audit et que vous avez sélectionné « AnyQuery », DataSunrise vérifiera toute expression ou requête que votre équipe DBA exécutera via l’instance DataSunrise. Par la suite, vous verrez ces événements dans Audit → Traçage transactionnel.
De plus, et de manière optionnelle, vous pouvez envoyer les détails des événements d’audit à un SIEM externe via le protocole Syslog ou pousser des alertes vers d’autres systèmes externes (SMTP/email, Jira, ZenDesk, messageries instantanées). Pour configurer une connexion à un serveur compatible Syslog, veuillez naviguer vers Configuration → Paramètres Syslog et configurer les paramètres requis sur cette page. Voir les sections « 7.7 Paramètres Syslog (groupes CEF) » et « 10.6 Paramètres d’intégration Syslog » dans notre Guide de l’utilisateur pour plus de détails. Pour envoyer des alertes à d’autres destinataires que ceux de Syslog, ajoutez de nouveaux éléments aux Abonnés (Console Web : Configuration → Abonnés → Ajouter un serveur… dans le menu Abonné). Vous trouverez plus d’informations sur les Abonnés dans la section « 7.5 Paramètres des abonnés » du Guide de l’utilisateur DataSunrise. Par la suite, vous pourrez utiliser les paramètres Syslog et/ou Abonnés dans vos règles DataSunrise (voir la première image ci-dessus) ; veuillez consulter les sections correspondantes dans les Guides de l’utilisateur et d’administration de DataSunrise. Une fois configuré, vous pourrez choisir vos éléments Syslog et Abonné dans votre règle d’audit. N’oubliez pas de cliquer sur le bouton Enregistrer sur la page de la règle d’audit pour sauvegarder les nouveaux paramètres.
De cette manière, nous avons sélectionné les types de requêtes que nous devons auditer (et éventuellement notifier certaines personnes par le biais d’alertes) pour une instance Amazon RDS spécifique ou plusieurs instances si vous choisissez l’option « <ANY> » dans la liste déroulante Instance sur la page de la règle. Il existe plusieurs options pour exclure l’audit des requêtes typiques telles que celles des outils DBMS. Pour plus d’informations, consultez la section « 6.4.2 Filtre de groupe de requêtes » dans le Guide de l’utilisateur DataSunrise en relation avec le paramètre Groupe de requêtes à exclure des règles.
4. Vérifier l’activité des DBA dans l’instance DataSunrise
Pour vérifier que notre nouvelle règle d’audit capture les requêtes, nous allons exécuter des requêtes CREATE USER et DROP USER en utilisant l’outil Oracle SQL Developer. Nous nous connecterons à l’instance Oracle RDS via l’instance DataSunrise.
Ensuite, nous pourrons vérifier les Traçages transactionnels dans l’instance DataSunrise.
Comme nous avons activé l’option Enregistrer les événements dans le stockage dans notre règle d’audit, nous pouvons retrouver ces événements sur
la page Audit → Traçage transactionnel sur la console Web de notre instance DataSunrise.
Remarques concernant EC2 avec instance Oracle Database
Il y a certaines considérations concernant l’utilisation d’instances de bases de données sur des instances Amazon EC2 en conjonction avec DataSunrise. Puisque vous configurez et administrez ces instances, vous pouvez, pour diverses raisons, autoriser des connexions locales (SSH, RDP, etc.) ou des connexions distantes (TCP de la base de données) qui contournent l’instance DataSunrise (ou votre équilibreur de charge). Toutes ces connexions doivent être strictement limitées pour garantir un niveau maximal de sécurité et de gestion. Dans votre VPC, nous recommandons de mettre en œuvre des règles strictes en utilisant les groupes de sécurité et les ACL réseau. Le but de toutes ces restrictions est d’éliminer l’accès direct à votre instance de base de données depuis toute adresse IP ou réseau, à l’exception de l’accès par le biais de l’instance DataSunrise vers le port de la base de données uniquement.
Les étapes suivantes figurent dans la section « Configuration des paramètres DataSunrise » de cet article. Et comme vous vous demandez probablement encore comment auditer vos rôles SYSDBA potentiellement nuisibles (et similaires), nous examinerons les capacités d’audit de DataSunrise pour vous aider à cet égard.
À partir de DataSunrise 6.2, vous pouvez inclure des paramètres de session dans les conditions Filtrer les sessions. Veuillez consulter ci-dessous notre règle d’audit intégrant la condition d’audit du SYSDBA et des privilèges similaires, en plus du groupe Oracle DBA Team défini dans le paramètre Groupe d’utilisateurs de BD. Nous supposons que nous avons configuré notre instance DataSunrise pour protéger Oracle Database fonctionnant sur une instance EC2 et qu’il n’existe aucun autre moyen de se connecter au serveur de base de données qu’à travers l’instance DataSunrise en mode proxy uniquement.
Comme notre DAF protège Oracle Database sur EC2, nous allons essayer de nous connecter à Oracle via le proxy DataSunrise. Sur les images ci-dessous, nous nous connectons à la base de données à l’aide d’Oracle SQL Developer via l’instance DataSunrise et utilisons le nom d’utilisateur « sys » avec le rôle SYSDBA. Nous avons défini que cela est autorisé dans notre instance Oracle Database. Consultez le résultat du test de connexion sur l’image suivante.
Si le test se conclut avec le statut Succès, nous pouvons essayer d’exécuter certaines requêtes de la même manière que nous l’avons fait précédemment dans la section « Configuration de DataSunrise pour auditer les DBA » de cet article. Oracle SQL Developer exécutera les requêtes via l’instance DataSunrise. Ensuite, dans la console Web DataSunrise, nous pourrons consulter Audit → Traçage transactionnel ou Traçage des sessions afin de voir toutes les requêtes et sessions de l’utilisateur « sys ». Notre règle d’audit capture l’utilisateur de base de données « sys » malgré le fait que cet utilisateur particulier ne figure pas dans la liste du groupe « Oracle DBA Team » que nous avons créé précédemment dans l’instance DataSunrise. Lorsque nous ouvrons Audit → Traçage des sessions et sélectionnons un élément particulier, nous verrons que l’instance DataSunrise enregistre des détails sur les rôles Oracle Database ainsi que d’autres informations utiles.
De cette manière, nous avons configuré l’instance DataSunrise pour auditer toute l’activité des DBA, y compris les privilèges SYSDBA et autres privilèges système similaires dont dispose Oracle Database.
Conclusion
Nous avons constaté qu’Oracle RDS demande moins d’efforts pour sécuriser l’instance Oracle Database et auditer l’activité des DBA. Sur les instances EC2, cela demande de retrousser vos manches et de configurer les paramètres de session et, grâce à la version 6.2 de DataSunrise, vous pouvez auditer les rôles intégrés d’Oracle Database. Pour plus d’informations, veuillez consulter le Guide de l’utilisateur DataSunrise ainsi que les références jointes.
Références
Vue d’ensemble d’Amazon RDS
AWS RDS – Vue d’ensemble des instances de base de données
DataSunrise Inc. et AWS
DataSunrise Security pour Amazon RDS
Vue d’ensemble des fichiers journaux de la base de données Amazon RDS
AWS RDS – Vue d’ensemble des fichiers journaux
Service de restauration à un instant T d’AWS
AWS RDS – Restauration à un instant T
Meilleures pratiques de sécurité AWS de DataSunrise
DataSunrise – Meilleures pratiques de sécurité AWS
DataSunrise prend en charge AWS CloudFormation
DataSunrise – Support AWS CloudFormation
DataSunrise sur AWS Marketplace
DataSunrise – Profil AWS Marketplace
Manuel Oracle Database sur les privilèges SYSDBA et SYSOPER
Oracle Database – Privilèges SYSDBA et SYSOPER
Guide de l’utilisateur DataSunrise