Sécurité de base de données
Concepts : La sécurité de l’information est vitale, elle conditionne l’activité économique des entreprises et la confiance dans les organisations publiques à caractère confidentiel peut avoir des conséquences fâcheuses sur le plan économique, commercial et juridique.
On envisage souvent la sécurité sous un angle fermé, essentiellement celui de la confidentialité. Mais bien d’autres concepts sous-tendent la sécurité. Ils sont pratiquement tous applicables aux OS ET aux SGBD, tant il est vrai que ces deux domaines sont extrêmement recouvrant. Cela nous conduit à considérer 5 objectifs de la sécurité de l’information :
Disponibilité : Faculté de délivrer correctement un service en termes de délai et de qualité à l’utilisateur, c’est aussi le degré avec lequel une application, un service ou une fonction est accessible sur demande, cette disponibilité se mesure en pourcentage du temps de fonctionnement total, une disponibilité de 100% est possible (temps de reprise nul) il suffit de s’en donner les moyens logiciels et matériels.
Intégrité : Prévenir la modification des données par des personnes non autorisées Qui peut modifier l’information? Quels contrôles sont en place pour limiter les accès? Quels sont les mécanismes permettant de vérifier si l’information a été changée? Quels moyens sont utilisés par les applications pour contrôler la cohérence des informations?
Confidentialité : Empêcher la consultation de données sensibles par des personnes non autorisées. Qui a accès? Quels sont les mécanismes de contrôle d’accès? Qui sont les utilisateurs possédant super privilèges? Les données sont-elles protégées avec un chiffrement: Lors de leur stockage? Durant leurs mouvements?
Traçabilité: Permettre de garder la trace des actions effectuées sur les systèmes à des fins de prévention, de dissuasion et d’audit des incident, en cas de problème important ou d’attaque du système, on peut recourir à l’analyse de traces ou de logs. Le niveau de détail de ces traces est paramétrable et avec cette fonction on peut savoir Qui a accédé? Quelle information sur l’activité est capturée? Comment sont protégés les référentiels d’audit? Une exploitation systématique des audits est-elle en place?
Fiabilité : ensemble Des mécanismes de sauvegarde variés (physique, logique, off-line, on-line, totale, partielle, incrémentale), ainsi que des mécanismes de journalisation, et de reprise permettent de restaurer une information sans pratiquement aucune perte, dans tous les cas de problème matériel ou logiciel. Les mécanismes mis en œuvre pour la sécurité : Les SGBDR doivent fournir un certain nombre de mécanismes internes ou de fonctionnalités assurant un niveau satisfaisant de sécurité. Par exemple : L’authentification : Est le processus qui permet de vérifier qu’un utilisateur réclamant un accès est bien celui qu’il prétend être, ou plus simplement le processus qui contrôle l’identité de l’utilisateur. Cette action (login) se fait en général via la fourniture du couple nom d’utilisateur / mot de passe. Dans certains cas l’authentification peut être implicite et héritée d’une authentification précédente, ou reconnue automatiquement (@IP du user sur le réseau par exemple), bien que simplifiant les accès ce choix peut évidemment s’avérer dangereux.
Les droits et privilèges : Une fois correctement identifié l’utilisateur doit pouvoir accéder aux informations et ressources auxquelles il a droit (et uniquement à celle-là!) Ce problème est résolu le plus simplement avec la gestion de droits élémentaires accordé à un individu, ou plus efficacement avec des rôles et / ou profils affectés à des groupes d’individus…ou à des rôles ou profils. Les Logs ou traces : Permet d’enregistrer tout ou une partie des informations concernant les accès (réussis ou échoués). Cette trace pourra être plus ou moins verbeuse et son volume étroitement surveillé. De ce fait on l’utilisera de manière ciblée sur des périodes de temps spécifiques.
Tolérance aux pannes :Permet avec un matériel ou un logiciel redondant (CPUs, disques, IOS) de supporter de manière partiellement ou complètement transparentes différents types de pannes, tant au niveau du client, que du réseau, que du serveur. Une tolérance totale a bien sûr un coût certain.
Sauvegarde et restauration : Sauvegarder les données sur des supports externes (disques, bandes, etc.) et pouvoir les restituer, les plus à jour possible. Le but est de ne pas perdre de données suite à un problème matériel (panne disque), logiciel (bug) ou une fausse manipulation d’un utilisateur.
Mécanismes transactionnels : L’atomicité des transactions, par définition assure la cohérence des données, même dans des environnements distribués. L’image avant modification, stockée de manière redondante dans ou hors de la BD, permet de faire d’éventuels retours arrière pour retrouver le dernier état cohérent, ou de s’assurer qu’il n’y a pas eu d’opérations partielles ou incomplètes (transaction bancaires par exemple).
Présentation d’Oracle Database
La version actuelle d’Oracle Database est le résultat de plus de 35 ans de développement innovant. Les points saillants de l’évolution de la base de données Oracle sont les suivants: Fondation d’Oracle : En 1977, Larry Ellison, Bob Miner et Ed Oates ont lancé le laboratoire de développement de logiciels de consultants, qui est devenu Relational Software, Inc. (RSI). En 1983, RSI devient Oracle Systems Corporation puis Oracle Corporation. Premier RDBMS commercialement disponible : En 1979, RSI a introduit Oracle V2 (Version 2) comme le premier RDBMS SQL disponible dans le commerce, un événement marquant dans l’histoire des bases de données relationnelles.
Version portable de la base de données Oracle : Oracle Version 3, lancé en 1983, était la première base de données relationnelle à être exécutée sur des mainframes, des mini-ordinateurs et des PC. La base de données a été écrite en C, ce qui permet de transférer la base de données sur plusieurs plates-formes. Améliorations apportées au contrôle de la concurrence, à la distribution des données et à l’évolutivité La version 4 a introduit la cohérence de lecture multi version. La version 5, lancée en 1985, prenait en charge les systèmes de bases de données distribuées et de calcul client / serveur. La version 6 a apporté des améliorations aux E / S disque, le verrouillage des lignes, l’évolutivité et la sauvegarde et la récupération. De plus, la version 6 a introduit la première version du langage PL/ SQL, une extension procédurale propriétaire de SQL.
Unités de programme mémorisées PL / SQL : Oracle7, publié en 1992, a introduit PL / SQL procédures stockées et déclencheurs.
Objets et partition : Oracle8 a été publié en 1997 comme la base de données objet-relationnelle, prenant en charge de nombreux nouveaux types de données. De plus, Oracle8 prenait en charge le partitionnement de grandes tables.
Informatique Internet : Oracle8i Database, publié en 1999, a fourni un support natif pour les protocoles Internet et le support côté serveur pour Java. Oracle8i a été conçu pour l’informatique sur Internet, ce qui permet de déployer la base de données dans un environnement multi tiers. Oracle Real Application Clusters (Oracle RAC) :Oracle9i Database a introduit Oracle RAC en 2001, permettant à plusieurs instances d’accéder simultanément à une seule base de données. En outre, la base de données Oracle XML (base de données Oracle XML) a introduit la possibilité de stocker et de consulter XML.
Calcul en grille : Oracle Database 10g a introduit le grid computing en 2003. Cette libération a permis aux organisations de virtualiser les ressources informatiques en construisant une infrastructure de réseau basée sur des serveurs de produits à faible coût. L’un des principaux objectifs était de rendre la base de données autogérée et autonome. Oracle Storage Management (Oracle ASM) a permis d’atteindre cet objectif en virtualisant et en simplifiant la gestion du stockage de base de données.
Capacité de gestion, diagnostic et disponibilité : Oracle Database 11g, lancé en 2007, a introduit une foule de nouvelles fonctionnalités qui ont permis aux administrateurs et aux développeurs de s’adapter rapidement aux nouvelles exigences de l’entreprise. La clé de l’adaptabilité est de simplifier l’infrastructure de l’information en consolidant les informations et en utilisant l’automatisation dans la mesure du possible.
Connexion au Cloud : Oracle Database 12c, lancé en 2013, a été conçu pour le Cloud, avec une nouvelle architecture Multi tenant, un magasin de colonnes en mémoire et un support pour les documents JSON. Oracle Database 12c aide les clients à utiliser plus efficacement leurs ressources informatiques tout en continuant de réduire les coûts et d’améliorer les niveaux de service pour les utilisateurs.
La base de données
Une base de données est un ensemble structuré et organisé de données qui représente un système d’informations sélectionnées de telle sorte qu’elles puissent être consultées par des utilisateurs ou par des programmes. Elle est constituée d’un ensemble de fichiers physiques situés sur les disques durs du serveur hébergeant la base. La Figure ci-dessous montre les différents types de ces fichiers, il est à noter que les archives des fichiers de journalisation, le fichier de paramètres ainsi que le fichier des mots de passe ne font pas partie prenante de la base de données, mais y sont étroitement reliés.
Les fichiers de contrôle : Ils contiennent des informations de contrôle sur la base de données tel que : Le nom de la base de données. Les noms, les chemins et les tailles des fichiers de données et de journalisation. Les informations de restauration de la base de données en cas de panne.
Le fichier de contrôle est primordial pour que l’instance soit lancée correctement. En effet, cette dernière y lit les chemins de fichiers de données, ainsi que ceux des fichiers de journalisation (et d’autres informations nécessaires au lancement). Si ce dernier est endommagé, la base de données ne peut pas être chargée même si les autres fichiers physiques sont intacts. C’est pour cela qu’il est possible (et recommandé) de multiplexer le fichier de contrôle sur des endroits différents du disque dur. Il est à noter que les informations des fichiers de contrôle peuvent être examinées à partir de la vue V$CONTROLFILE.
Les fichiers de données : Ces fichiers contiennent l’ensemble des données de la base (les tables, les vues, les procédures stockées, …). Ils sont codés dans un format propriétaire. Seules les requêtes SQL permettant un accès implicite à ces fichiers.
Les fichiers de données contiennent des informations de deux types : Le dictionnaire de données et de travail, Les données des utilisateurs.
La lecture de ces fichiers de données est faire à l’aide des processus utilisateurs tandis que l’écriture est assurée par le processus DBWR (Database Writer).
Les fichiers de journalisation : Tout d’abord, faisons un petit rappel sur la notion de transaction ; une transaction est un ensemble d’opérations (requêtes) de mises à jour (insert, update et delete) qui finit par un COMMIT (validation) ou un ROLLBACK (annulation). La validation/annulation concerne tout le bloc de mises à jour (l’ensemble des opérations) depuis un COMMIT/ROLLBACK ultérieur ou depuis le début de la connexion. Une transaction finit donc par un COMMIT/ROLLBACK ou par une déconnexion de l’utilisateur qui vaut un COMMIT si c’est une déconnexion normale et un ROLLBACK si elle ne l’est pas.
Quand un utilisateur Oracle opère des mises à jour sur les données, celles-ci sont non seulement exécutées mais aussi sauvegardées dans les fichiers de journalisation. Cette mesure de sécurité primordiale permet en cas de crash du système de reconstituer les données perdues à partir des informations sauvegardées dans les fichiers de journalisation. C’est d’ailleurs la raison pour laquelle ces fichiers sont multiplexés et/ou copiés. En d’autres termes, même si un fichier de journalisation est irrécupérable, Oracle peut compter sur sa (ou ses) copie(s).
Un ensemble de fichiers journaux multiplexés constitue un groupe de fichiers de journalisation. Si par exemple un groupe inclut trois fichiers journaux, alors ces trois fichiers incluent exactement les mêmes informations, ils sont appelés membres d’un groupe. Il existe au minimum deux groupes de fichiers journaux et ils sont écrits de manière cyclique, c.-à-d., que si les fichiers d’un premier groupe sont pleins, Oracle passe au deuxième groupe et y écrit (dans chaque membre) les transactions nouvellement exécutées quitte à écraser les transactions existantes.
La vue V$LOGFILE contient toutes les informations qui concernent les fichiers journaux de la base de données.
Oracle Database with Oracle RAC One Node
Traditionnellement, Oracle RAC est utilisé dans une architecture multi nœud, avec de nombreuses instances de base de données distinctes s’exécutant sur des serveurs distincts. Oracle RAC One Node vous permet d’exécuter une instance d’une base de données Oracle RAC sur un seul nœud d’un cluster. Ainsi, cette fonctionnalité vous permet de consolider de nombreuses bases de données en un seul cluster pour faciliter la gestion tout en offrant une disponibilité élevée en déplaçant rapidement les instances en cas de défaillance du serveur.
Les avantages d’Oracle RAC One Node : Les avantages de la haute disponibilité pour l’utilisation d’Oracle RAC One Node sont les suivants:
Offre une meilleure disponibilité de bases de données que les solutions de basculement à froid traditionnelles; Fournit une meilleure virtualisation pour les bases de données que les solutions basées sur hyperviseurs;
Permet la migration en ligne des instances de base de données et la mise à jour et la mise à jour en ligne du système d’exploitation et des logiciels de bases de données (sans aucun temps d’arrêt); Fournit une solution complète, à fournisseur unique, sans besoin de mettre en œuvre des produits tiers; Est prêt à l’échelle et la mise à niveau à multi nœud Oracle RAC; Fournit un environnement standardisé et un ensemble d’outils communs pour les déploiements de bases de données Oracle à un ou plusieurs nœuds;
Totalement compatible avec Oracle Data Guard. Toute base de données dans une configuration Data Guard, qu’il s’agisse d’une base de données principale ou d’une base de données en attente, peut-être une base de données Oracle One Node.
Table des matières
INTRODUCTION GENERAL
CHAPITRE I : CONTEXTE GENERALE DU PROJET
I. Présentation de la formation
II. Problématique et Objectifs
1. Problématique
2. Objectifs
CHAPITRE II : GENERALITE SUR LES SGBDR ET ORACLE DATABASE
I. Présentation des SGBDR
1. Définition
2. Etude comparative
3. Sécurité de base de données
II. Présentation d’Oracle Database
1. Bref Historique
2. La base de données
3. INSTANCE
4. Fonctionnement d’Oracle
CHAPITRE III : LA HAUTE DISPONIBILITE
Définition
I. Disponibilités des systèmes
1. Disponibilité et Classification
2. Cause de disfonctionnement
II. Eléments fondamentaux de la Haute Disponibilités
1. Répartition de la charge ou architecture en load-balancing
2. La tolérance aux pannes ou architecture en failover
3. La réplication des données dans un système à Haute disponibilité
CHAPITRE IV : ARCHITECTURE ET CHOIX DE SOLUTIONS DE HAUTE DISPONIBILITES SOUS ORACLE
I. Architectures de Haute Disponibilité
1. Oracle Database
2. Oracle Database with Oracle Clusterware (Cold Cluster Failover)
3. Oracle Database with Oracle RAC One Node
4. Oracle Database with Oracle Real Application Clusters (Oracle RAC)
5. Oracle Database avec Oracle RAC sur les clusters étendus
6. Oracle Database with Oracle Data Guard
7. Oracle Database with Oracle Clusterware and Oracle Data Guard
8. Oracle Database with Oracle RAC and Oracle Data Guard
II. Choix de la solution de Haute disponibilité
1. Critère de sélections basé sur RTO, RPO, ROI et autres facteurs
2. Choix de solution en fonction de temps de récupération
CHAPITRE V : ETUDE ET MISE EN PLACE DE LA SOLUTION DE HAUTE DISPONIBILITE : DATA GUARD
I. Présentation de la solution DATA GUARD
1. Principe
2. Architecture
3. Les Services de Data Guard
4. Data Guard Protection Modes
5. Gestion des décalages d’ARCHIVELOGS
6. Les avantages de la solution Data Guard
CHAPITRE VI : CONFIGURATION ET MISE EN ŒUVRE DE LA SOLUTION DATA GUARD
I. Mettre en œuvre l’environnement physique de la base de données de secours
1. Créer une base de données primaire
2. Préparer la base de données primaire pour la création de la base de données de secours
II. Créer une base de données de secours physique
1. Préparer un fichier de paramètres d’initialisation pour la base de données de secours
2. Configurer l’écouteur et le fichier tnsnames pour prendre en charge la base de données sur les machines principale et de secours
3. Démarrer l’écouteur et vérifier tnsping sur les deux machines virtuelles concernant
les deux services
4. Utiliser RMAN pour cloner la base de données et créer une base de données de
secours
5. Démarrer la base de données de secours physique en mode de récupération géré .. 88
6. Vérifier la base de données de secours physique
