Comment Auditer les Actions Administratives dans votre Oracle RDS et EC2
Préface
Amazon Relational Database Service (Amazon RDS) est un service web qui facilite la configuration, l’exploitation et la mise à l’échelle 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 conforme aux standards de l’industrie et gère les tâches communes d’administration des bases de données.
DataSunrise est un Partenaire Technologique Avancé AWS certifié pour la compétence Sécurité en Protection et Chiffrement des Données avec d’autres qualifications validées par AWS. DataSunrise peut fonctionner sur site, sur une instance EC2 ou en cluster sur plusieurs instances EC2, dans une machine virtuelle ou sur métal nu. DataSunrise Data and Database Security Suite (DataSunrise) pour tous types d’Amazon RDS agit comme un pare-feu pour applications de bases de données (DAF), agissant en tant qu’intermédiaire pour toutes les sessions, les requêtes et commandes de tous clients vers l’instance Amazon RDS. Et comme DataSunrise est un logiciel et non pas une solution SaaS, vous êtes responsable de l’installation et de la configuration de votre instance DataSunrise de la bonne manière.
Le principal objectif de cet article est de présenter l’approche sur la manière d’auditer l’activité des comptes privilégiés. Nous verrons comment configurer DataSunrise pour auditer l’activité DBA dans Oracle RDS. Cependant, toutes les étapes générales s’appliquent à toute instance Amazon RDS.
Vue d’ensemble d’Oracle RDS et prérequis
Comme vous le savez probablement, Amazon RDS prend en charge l’accès aux bases de données à l’aide de toute application client SQL standard et ne permet pas un accès direct à l’hôte avec SSH, etc. Cette architecture ne vous permet pas d’installer des agents de base de données dans Amazon RDS et vous limite dans l’utilisation de privilèges DBA puissants comme SYSDBA. Amazon RDS utilise un modèle de responsabilité partagée qui exclut toute intervention humaine directe sur la plateforme informatique. Cependant, avec Amazon RDS, vous pouvez effectuer 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 les instances Amazon RDS avec des instantanés en utilisant AWS Management Console, AWS CLI, ou RDS API. D’un autre côté, vous n’êtes pas capable d’accéder à Amazon RDS en utilisant des connexions SSH ou RDP pour des activités liées à la base de données ou au système d’exploitation (et probablement nuisibles). Gardez à l’esprit qu’en ayant le rôle IAM requis, vous pouvez modifier et gérer votre instance Amazon RDS pour répondre à vos besoins système sans vous connecter à Amazon RDS via SSH/RDP.
Un aspect important est lié aux privilèges/rôles Oracle SYSDBA et similaires. Le rôle SYSDBA est désigné uniquement pour l’utilisateur RDSADMIN (AWS utilise l’utilisateur système « rdshm ») et le mot de passe RDSADMIN est inconnu. En outre, avec Oracle RDS, vous ne pouvez pas connaître le mot de passe de l’utilisateur SYS. Et toutes ces choses signifient 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 de rôle puissant comme SYSDBA ou autre dans la base de données Oracle ;
- vous ne pouvez pas vous connecter à distance à une instance Oracle RDS en utilisant SYSDBA ou d’autres rôles puissants de la base de données Oracle.
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), vous permettant de vous connecter à l’instance Oracle RDS en utilisant cet utilisateur. Par la suite, vous pouvez créer un autre utilisateur et cet utilisateur ne recevra pas plus de privilèges que votre utilisateur “admin”. Ceci est lié au modèle de gestion de la responsabilité partagée dans AWS. L’équipe Amazon RDS a fixé cette limite que vous ne pouvez pas franchir.
Nous laisserons la configuration d’Oracle RDS en dehors du cadre 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 pouvez démarrer un nouvel Oracle RDS ou que vous avez déjà accès à une instance Oracle RDS existante. Si vous souhaitez connaître les meilleures pratiques pour exécuter 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é du DBA sur Oracle RDS et options d’audit
Les limitations des instances RDS soulèvent de nombreuses questions sur la façon d’auditer les actions spécifiques des DBA comme ALTER SYSTEM, CREATE USER, DROP DATABASE, etc. Et comment pouvez-vous auditer ces utilisateurs internes RDS comme RDSADMIN ? Très bien, examinons toutes les options disponibles.
- Vous pouvez visualiser l’activité interne de RDS en utilisant les fichiers de journal de 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 de Ligne de Commande AWS (AWS CLI) ou l’API Amazon RDSAPI Amazon RDS. Amazon fournit le service de Récupération Point-In-Time et déclare que RDS télécharge les journaux de transactions pour les instances DB vers Amazon S3 toutes les 5 minutes. Ainsi, les fichiers de journal de base de données et le service CloudTrail vous aident tous deux à analyser l’activité utilisateur RDSADMIN avec des informations supplémentaires sur les événements Oracle RDS. Toutes ces options sont bonnes jusqu’à ce que vous ayez besoin d’une surveillance et d’une alerte des transactions en temps réel.
- Avec les instances DAF fonctionnant sur des VM EC2 séparées, vous pouvez auditer toutes les sessions et requêtes s’exécutant vers votre instance Amazon RDS. Le but des instances DAF est de devenir votre garde de base de données et puisque vous avez besoin de surveiller l’activité DBA, nous verrons cette option en détail plus loin. Les instances DataSunrise sur des instances EC2 sont capables de surveiller et sécuriser l’activité réseau vers Amazon RDS.
Vue d’ensemble de DataSunrise sur AWS et prérequis
La configuration et la sécurisation d’instances DataSunrise sécurisées impliquent plusieurs étapes importantes. Pour préparer votre instance DataSunrise sécurisée dans l’environnement AWS, merci de suivre les étapes décrites dans notre document DataSunrise AWS Security Best Practices. Pour en citer quelques-unes, voici les étapes suivantes :
- attribuer les bons rôles IAM à vos instances EC2 avec les instances DataSunrise ;
- créer et assigner des Groupe(s) de Sécurité VPC à vos instances Amazon RDS et EC2 possédant le logiciel DataSunrise ;
- utiliser des mots de passe sécurisés et uniques pour chaque compte.
L’architecture ci-dessous consiste en une instance de base de données (RDS ou sur une instance EC2) derrière DAF, une base de données de stockage d’audit séparée (RDS ou sur une instance EC2), et une instance DataSunrise qui sert de serveur proxy pour les connexions des utilisateurs.

Comme option, DataSunrise fournit des scripts CloudFormation pour déployer sur AWS des solutions de sécurité de base de données sécurisées et économiquement avantageuses. Suite à votre création d’une instance Amazon RDS, ces scripts automatisent toutes les tâches requises pour déployer des instances EC2, installer DataSunrise sur ces instances EC2, configurer Amazon Load Balancer ainsi que la création de toutes les autres ressources AWS requises. Nous passerons l’option CloudFormation et continuerons avec un scénario d’instance EC2 unique. Nous avons préparé des vidéos sur comment installer une instance DataSunrise, veuillez regarder une des vidéos et suivre les étapes requises :
- Installer DataSunrise sur Linux https://www.youtube.com/watch?v=FWoGY2qc0F8
- Installer DataSunrise sur Windows https://www.youtube.com/watch?v=wKlFUdUUbSE
À la fin du processus d’installation, votre instance DataSunrise devrait être accessible depuis votre navigateur Web. Vous aurez besoin de l’instance DataSunrise opérationnelle pour pouvoir accéder à votre Console Web DataSunrise avec les privilèges requis.
Le prochain prérequis est la Configuration de la Base de Données que vous devez créer dans l’instance DataSunrise pour démarrer un proxy pour Amazon RDS. Veuillez vous référer au Guide de l’Utilisateur de DataSunrise, section “3.1 Creating a Target Database Profile and a Proxy” et section “5.1.6 Creating Database Users Required for Getting the Database’s Metadata”. Étant donné que DataSunrise en mode proxy agit en tant qu’intermédiaire en interceptant tous les paquets TCP non-AWS vers l’instance Amazon RDS, vous pouvez utiliser le même port de base de données Oracle standard 1521 puisque l’instance DataSunrise fonctionne sur une autre instance EC2. Enfin, assurez-vous que votre instance Amazon RDS n’est PAS accessible depuis une autre IP / nom non-AWS et port à part via l’instance DataSunrise. Toutes ces étapes garantiront que toutes vos applications clientes peuvent accéder à votre instance Oracle RDS uniquement via votre instance DataSunrise.
Configurer DataSunrise pour auditer le DBA
Comme 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. Et cela réduit la zone possible des menaces potentielles envers 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 prouver que c’est vrai, voir un exemple ci-dessous.

Vous verrez qu’aucun SYSDBA, SYSOPER, ou d’autres privilèges liés SYS ne sont disponibles dans Oracle RDS, que ce soit en utilisant TCP ou SSH.
Par conséquent, vous devez prendre soin d’auditer les connexions réseau – les connexions à distance en utilisant le bon outil tel que DataSunrise DAF. Nous configurerons l’instance DataSunrise pour capturer tout type d’actions que votre DBA peut effectuer à distance vers l’instance Amazon RDS.
Résumé des prochaines étapes
Pour auditer les actions du DBA, nous effectuerons les étapes suivantes :
- Identifier les noms d’utilisateur / comptes de votre DBA. DataSunrise conserve les utilisateurs de base de données sous son menu Configuration. Si vous avez plusieurs DBA, créez alors 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 l’Utilisateur de Base de Données et le Groupe de Requêtes pour Auditer l’activité du DBA.
- Vérifiez l’activité du DBA dans l’instance DataSunrise
1. Identifier et configurer vos utilisateurs DBA dans DataSunrise
Procédons avec toutes ces étapes. Premièrement, sous Configuration → Utilisateurs de Base de Données, nous vérifions si l’utilisateur “admin” est connu de notre instance DataSunrise. Si DataSunrise n’en a pas un, créez alors manuellement l’utilisateur “admin”. Si vous avez plusieurs instances Oracle RDS et que le même nom d’utilisateur DBA “admin” est utilisé, vous pouvez choisir <Any> Instance. N’oubliez pas de cliquer sur le bouton Sauvegarder pour enregistrer vos paramètres sur chaque page.

Dans l’image ci-dessus, nous avons créé l’utilisateur ADMIN et l’avons inclus dans le groupe Équipe DBA. Si vous avez créé plusieurs utilisateurs DBA, veuillez les ajouter au Groupe d’Utilisateurs “Équipe DBA Oracle” dans l’instance DataSunrise.
2. Configurer un nouveau Groupe de Requêtes
Deuxième étape : nous créerons notre nouveau Groupe de Requêtes “AnyQuery” et ajouterons juste une entrée “.*” dans l’élément Requête. Veuillez voir les paramètres dans l’image ci-dessous.

Lorsque vous créez une nouvelle Requête pour le Groupe de Requêtes (voir bouton “Ajouter” sur l’image), veuillez cocher la case “Expression Régulière”.
À ce stade, nous avons l’utilisateur de base de données “ADMIN”, le Groupe d’Utilisateurs “Équipe DBA Oracle” enregistré dans l’instance DataSunrise et notre Groupe de Requêtes “AnyQuery” avec une Requête qui a le modèle d’expression régulière “.*” pour correspondre à toute requête. Nous avons franchi la moitié de la tâche.
3. Créer et configurer une nouvelle Règle d’Audit
Ensuite, nous créerons une nouvelle Règle d’Audit avec le nom “Oracle: requêtes admin” en utilisant ce que nous avons créé dans l’instance DataSunrise. Veuillez ouvrir la Console Web et entrer dans Audit → Règles. Cliquez sur Créer pour créer les nouvelles règles. Veuillez voir les détails sur les images ci-dessous.

Nous utiliserons les onglets Filtrer les Déclarations et Groupe de Requêtes sur la page pour connecter notre règle avec les paramètres correspondants que nous avons effectués précédemment, voir les détails dans les images suivantes.

Lorsque vous sélectionnez le Groupe d’Utilisateurs “Équipe DBA Oracle” pour le paramètre de session Groupe Utilisateur DB, vous faites en sorte que DataSunrise capture toute session depuis toute IP / hôte ayant un nom utilisateur sur la liste “Équipe DBA Oracle”. Lorsque vous ajoutez un autre élément utilisateur de la base de données au Groupe d’Utilisateurs “Équipe DBA Oracle”, cette règle vérifiera le nouvel utilisateur dans cette règle automatiquement. Et puisque vous utilisez l’onglet Groupe de Requêtes sur la page de Règle d’Audit et sélectionnez “AnyQuery” là, alors DataSunrise vérifiera toute expression ou requête que votre équipe DBA exécutera via l’instance DataSunrise. Plus tard, vous verrez ces événements sous Audit → Trails Transactionnels.
En outre et optionnellement, vous pouvez envoyer les détails de l’événement d’audit à un SIEM externe en utilisant le protocole Syslog ou envoyer des alertes à d’autres systèmes externes (SMTP/email, Jira, ZenDesk, messageries instantanées). Pour configurer la connexion au serveur compatible Syslog, veuillez naviguer vers Configuration → Paramètres Syslog et configurez les paramètres requis sur cette page. Voir “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 que des destinataires Syslog, ajoutez de nouveaux éléments aux Subscribers (console Web : Configuration → Subscribers → Ajouter Serveur… Ajouter menu items de Subscribr). Vous pouvez trouver plus d’informations sur les Subscribers dans la section “7.5 Paramètres de Subscriber” du Guide de l’Utilisateur DataSunrise. Plus tard, vous pouvez utiliser la configuration Syslog et/ou les Subscribers dans vos règles DataSunrise (voir première image ci-dessus); veuillez consulter les sections correspondantes dans les Guides de l’Utilisateur et Administratif de DataSunrise. Lorsque configuré, vous pouvez choisir vos éléments de Syslog et Subscriber sur votre Règle d’Audit. N’oubliez pas de cliquer sur le bouton Sauvegarder sur la page de la Règle d’Audit pour enregistrer les nouveaux paramètres.
De cette façon, nous avons sélectionné les types de requêtes que nous devons auditer (et probablement notifier certaines personnes avec des alertes) pour une instance Amazon RDS concrète ou plusieurs instances si vous choisissez l’élément “<ANY>” dans la boîte déroulante Instance sur la page de la règle. Il y a plusieurs options pour éviter d’auditer les requêtes typiques comme DBMS tools, pour plus d’informations voir section “6.4.2 Filtre de Groupe de Requêtes” dans le Guide de l’Utilisateur DataSunrise en relation avec le paramètre Sauter Groupe de Requête des règles.
4. Vérifiez l’activité du DBA dans l’instance DataSunrise
Pour vérifier que notre nouvelle Règle d’Audit capture les requêtes, nous exécuterons les 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 pouvons vérifier les Trails Transactionnels dans l’instance DataSunrise.
Étant donné que nous avons défini l’option Log Event in Storage dans notre Règle d’Audit, nous pouvons retrouver ces événements sur

la page Audit → Trails Transactionnels de notre console Web DataSunrise.
Notes sur EC2 avec une instance Oracle Database
Il y a certaines considérations sur l’utilisation d’instances de base de données sur des instances Amazon EC2 avec DataSunrise. Comme vous installez et configurez ces instances, vous pouvez pour certaines raisons autoriser les connexions locales (SSH, RDP, etc.) ou les connexions distantes (TCP de base de données) qui contournent l’instance DataSunrise (ou votre Load Balancer). 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 place des règles strictes en utilisant les Groupes de Sécurité et ACL Réseau. Le but de toutes ces restrictions devrait être d’éliminer l’accès direct à votre instance de base de données depuis toute IP ou réseau sauf DataSunrise sur votre instance EC2 uniquement vers le port de la base de données.
Les prochaines étapes que vous pouvez voir dans la section “Configurer les paramètres DataSunrise” de cet article. Et comme vous pensez probablement encore à comment auditer vos rôles potentiellement nuisibles SYSDBA (et similaires), nous allons examiner les capacités d’audit de DataSunrise pour vous aider avec cela.
À partir de DataSunrise 6.2, vous pouvez inclure les paramètres de session dans les conditions Filtrer les Sessions. Veuillez voir ci-dessous notre Règle d’Audit avec la condition pour auditer SYSDBA et des privilèges similaires en plus de l’“Équipe DBA Oracle” dans DB User Group. Nous supposons que nous avons configuré notre instance DataSunrise pour protéger Oracle Database fonctionnant sur l’instance EC2 et qu’il n’y a pas d’autre moyen de se connecter au serveur de base de données sauf via l’instance DataSunrise uniquement en mode proxy.

Étant donné que notre DAF protège Oracle Database sur EC2, nous allons essayer de nous connecter à Oracle par le biais du proxy DataSunrise. Sur les images ci-dessous, nous nous connectons à la base de données en utilisant Oracle SQL Developer via l’instance DataSunrise et utilisons le nom utilisateur “sys” et le rôle SYSDBA. Nous avons configuré que cela est autorisé dans notre instance Oracle Database. Voir le résultat du test de connexion sur l’image suivante.

Si le test est passé avec le statut Success, 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 “Configurer DataSunrise pour auditer DBA” de cet article. Oracle SQL Developer exécutera les requêtes via l’instance DataSunrise. Ensuite, sur la console Web DataSunrise, nous pouvons vérifier le Trail Transactionnel Audit ou les Trails de Session pour voir toutes les requêtes et sessions de l’utilisateur “sys”. Notre Règle d’Audit capture l’utilisateur de la base de données “sys” bien que cet utilisateur particulier ne soit pas sur la liste de notre “Équipe DBA Oracle” que nous avons créée précédemment dans l’instance DataSunrise. Lorsque nous ouvrons le Trail de Session Audit et un élément particulier, nous verrons que l’instance DataSunrise enregistre des détails sur les rôles de la base de données Oracle ainsi que d’autres informations utiles.

De cette manière, nous avons configuré l’instance DataSunrise pour auditer toute activité DBA incluant SYSDBA et privilèges système similaires qu’a la base de données Oracle.
Conclusion
Nous avons vu qu’Oracle RDS nécessite moins d’efforts pour sécuriser l’instance Oracle Database et auditer l’activité DBA. Sur les instances EC2, il est nécessaire de retrousser ses manches et de paramétrer les paramètres de session et grâce à la version 6.2 de DataSunrise, vous pouvez auditer les rôles intégrés de la base de données Oracle. Pour plus d’informations, veuillez consulter le Guide de l’Utilisateur DataSunrise et les références jointes.
Références
Vue d’ensemble d’Amazon RDS
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.html
DataSunrise Inc. et AWS
https://www.datasunrise.com/datasunrise-security-amazon-rds/
Vue d’ensemble des fichiers de journal de base de données Amazon RDS
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.html
Service de récupération AWS Point-In-Time
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html
DataSunrise AWS Security Best Practices
https://www.datasunrise.com/documentation/ds-aws-security-best-practices/
DataSunrise prend en charge AWS CloudFormation
https://www.datasunrise.com/professional-info/aws-market-commercial/
DataSunrise sur AWS Marketplace
https://aws.amazon.com/marketplace/seller-profile?id=880a5857-74c1-44ea-a978-094093c08788
Manuel de base de données Oracle sur les privilèges système SYSDBA et SYSOPER
https://docs.oracle.com/database/121/ADMQS/GUID-2033E766-8FE6-4FBA-97E0-2607B083FA2C.htm#ADMQS12004
Guide de l’Utilisateur DataSunrise
https://www.datasunrise.com/documentation/user-guide-download/