Chapitre 11 - Intégrité et Sécurité

Chapitre 11

Intégrité et sécurité

GPA775 Chapitre 11 - Intégrité et sécurité 2

Introduction

Un système informatique est sujet à toutes sortes d'avaries :

Ø les crashes-disques: information stockée détruites

Ø les coupures d'alimentation: information stockée en mémoire est perdue;

Ø les erreurs de logiciel: les traitements fournissent des résultats erronés et la base est incohérente;

Ø le piratage: infiltration au système par une entité non-autorisée.

Il est donc primordiale, pour toutes BD d'intégrer un système de récupération capable de détecter les défauts et de restaurer la base de données afin qu'elle retrouve sa consistance antérieure à l'avarie qui l'affecte.


Contenu et définition

Les points abordés dans ce chapitre sont les suivants :

ØLes transactions;

ØL’intégrité;

ØLa sécurité.

Dans le jargon des BD, on désigne:

ØLes transactions comme une opération dont l’exécution permet de conserver la consistance de la BD.

ØL’intégrité comme une protection contre les accidents.

ØLa sécurité comme une protection contre le piratage.


Les transactionsPour une BD, l'exécution simultanée de plusieurs transactions (multitâches) permet: Øde partager les ressources machine Ød’optimiser ainsi le temps CPU consommé.

Chaque utilisateur ne mobilise que quelques fractions de seconde l'unité CPU, et a l'impression d'être seul avec la machine. La consistance de la BD est donc mise à l'épreuve par les requêtes simultanées qui sont concurrentes vis-à-vis du SGBD. C'est pourquoi le SGBD est muni d'un processeur de requêtes multitâches qui gère l'ensemble des transactions simultanées.


Les transactions…quelques règles

Si la BD était consistante avant la transaction, elle doit l'être après.

Ainsi, la transaction doit être atomique :

Ø toutes les instructions propres à une transaction T doivent être effectuées en totalité ou pas du tout.

Le résultat d’une transaction ne doit pas être visible par les autres transactions avant la fin de celle-ci.De plus, le traitement d'une transaction doit permettre une seule lecture et/ou écriture sur disque.

Note : C’est le module de récupération de la BD qui est responsable de l'atomicité des transactions.

1


Les transactionsUne transaction peut se trouver dans l'un des états suivants :

Ou en cours: état initial de la transaction

Lorsque la dernière instruction de la transaction a étéatteinte.

Après exécution correcte.

Après rejet et lorsque la BD a retrouvé son état initial.

Lorsque la transaction ne peut s'effectuer au complet.


Les transactions

Une transaction est dans un état échoué (manqué) à la suite d'erreurs logiques ou matérielles.

Le système peut alors choisir l'une de ces 2 options :

Ø relancer la transaction, s'il s'agit d'ennuis matériel ou logiciel sans rapport avec la logique interne de la transaction;

Note : une transaction relancée est considérée comme une nouvelle transaction.

Ø tuer la transaction, s'il s'agit d'ennuis avec la logique interne de la transaction, qui ne peuvent être éliminés que par la correction du programme d'application.

Il faut donc être prudent lorsqu'on fait des écritures à des sorties observables (imprimante, écran, fichier).

Ø Les applications bien construites n'autorisent l'édition de résultats que lorsque la transaction est validée.


La Sérialisation

Les traitements de transactions simultanées sont courant dans un environnement réparti. Pour les comprendre, nous allons voir le concept de sérialisation.

Une transaction est sérialisable lorsque l'exécution parallèled'une succession de transactions est équivalente àl'exécution en série de la séquence de ces transactions.

ØDans le traitement de transactions concurrentes, le système ne devrait engendrer que des transactionssérialisables.

Si deux opérations peuvent être inverties dans une séquence, on les dit permutables.Note : Il est en général très difficile de déterminer quelles sont

les transactions permutables.


La Sérialisation

Pour illustrer le concept de sérialisation, nous utiliseront quatre séquences différentes dans l’exemple suivant. Ces séquences sont testées à l'aide de deux transactions T0 et T1 effectuées sur les valeurs A et B. Les valeurs initiales de A et B sont :

A = 1000$B = 2000$

T0 Transfert de 50$ du compte A vers B

T1 Transfert de 10% du compte A vers B


La Sérialisation : Séquence 1

Les valeurs initiales de A et B sont : 1000$ et 2000$ respectivement. La transaction T0 est effectuée avant T1.À la fin de la Séquence 1, les valeurs finales de A et B sont : 855$ et 2145$.

T0 T1

Read (A)

A := A - 50

Write (A)

Read (B)

B := B + 50

Write (B)

Read (A)

temp := A * 0.1

A := A – temp

Write (A)

Read (B)

b := b + temp

Write (B)

A:950

A:950

B:2000

B:2050

A:1000

temp:95

B:2050

B:2145

A:855



La transaction T1 est effectuée avant T0.

À la fin de la Séquence 2, les valeurs finales de A et B sont : 850$ et 2150$.

Note : Même si la somme respective des deux séquences (S1et S2) est équivalente (3000$), le résultat final est différent.

Ces deux transactions sont des successions séries qui sont légales pour la BD mais différentes pour l'utilisateur.

T0 T1

Read (A)

temp := A * 0.1

A := A – temp

Write (A)

Read (B)

b := b + temp

Write (B)

Read (A)

A := A - 50

Write (A)

Read (B)

B := B + 50

Write (B)

B:2100

temp:100

A:900

B:2000

A:1000

A:900

B:2100

B:2150

A:850



Les transactions sont maintenant effectuées en parallèle, on se retrouve devant une situation beaucoup plus complexe.

L'entrelacement des transactions T0 et T1 conduit à plusieurs séquences possibles.

La Séquence 3 représente une possibilité. À la fin de la séquence, la somme finale de A et B (3050$) != 3000$. Donc la base est dans un état inconsistant!

Note : Comme nous exigeons d'une transaction qu'elle préserve la consistance de la base, nous attendons qu'une succession de transactions fasse de même.

T0 T1

Read (A)

A := A - 50

Read (A)

temp := A * 0.1

A := A – temp

Write (A)

Read (B)

Write (A)

Read (B)

B := B + 50

Write (B)

B := B + temp

Write (B)

B:2000

temp:100

A:950

B:2000

A:1000

A:900

B:2050

B:2100

B:2050

A:1000

A:900

A:950

B:2100



La Séquence 4 est équivalente à la Séquence 1 parce que les valeurs de A et B lues par la transaction T1 ont été produites par la transaction T0 dans ces deux séquences. À la fin de la séquence, la somme finale de A et B est de 855 +2145 = 3000$.

T0 T1

Read (A)

A := A - 50

Write (A)

Read (A)

temp := A * 0.1

A := A - temp

Write (A)

Read (B)

B := B + 50

Write (B)

Read (B)

B := B + temp

Write (B)

A:855

A:1000

B:2000

A:950

B:2145

B:2050

A:950

temp:95

B:2050

A:950

B:2050

B:2145

A:855


Concept de sérialisation

Pour formaliser le concept de sérialisation, nous dirons que les séquences S1 et S2 sont équivalentes (S1 ≡ S2) si :Ø les ensembles des transactions constituant S1 ≡ S2sont les mêmes;Øpour chaque donnée X, si dans la séquence S1 la

transaction Ti exécute un read(X) et la valeur de X lue par Ti a été écrite par Tj, il en est de même pour S2;Øpour chaque donnée X, si dans S1 la transaction Tiexécute le dernier write(X), il en est de même pour S2.

e.i.: les opérations de lecture et d'écriture doivent conserver la consistance de la BD. Si ce principe est respecté, on peut découper les transactions en plus petits blocs pour les traiter de manière parallèle.


Test de sérialisabilité

Pour s’assurer qu'une séquence de transactions est sérialisable, il faut que toutes les liaisons Ti → Tj satisferont àl’une ou l’autre des conditions suivantes:

ØTi exécute un write(X) avant que Tj n'exécute unread(X);

ØTi exécute un read(X) avant que Tj n'exécute unwrite(X);

ØTi exécute un write(X) avant que Tj n'exécute unwrite(X).



Pour tester la sérialisabilité, il faut construire un graphe de précédence des transactions et détecter les cycles.

La séquence suivante n'est pas sérialisable puisqu'elle comporte un cycle, donc elle ne satisfait pas aux conditions requises.

T0 T1



Par contre, ce graphe de précédence ne comporte pas de cycle et peut être linéarisé de 2 façons différentes.

Ti

Tm

TkTj

Ti

Tm

Tk

Tj

Ti

Tm

Tk

Tj


Exemple de test de sérialisabilité

Soit 3 transactions :

Voici la séquence A :

Transaction T1 Transaction T2 Transaction T3

read_item(X); read_item(Z); read_item(Y);

write_item(X); read_item(Y); read_item(Z);

read_item(Y); write_item(Y); write_item(Y);

write_item(Y); read_item(X); write_item(Z);

write_item(X);


read_item(Z);

read_item(Y);

write_item(Y);

read_item(Y);

read_item(Z);

read_item(X);

write_item(X);

write_item(Y);

write_item(Z);

read_item(X);

read_item(Y);

write_item(Y);

write_item(X);



Sur le graphe de précédence de la Séquence A, on constate qu’il ne peut y avoir de séquence sérielle équivalente pour cette séquence. En effet, puisque l’on y retrouve les cycles suivants :cycle : X( T1 →T2 ), Y( T2 → T1 )cycle : X( T1 →T2 ), YZ( T2 → T3 ), Y( T3 → T1 )

T2

T3

T1

Y, Z

Y

Y

X



Voici la séquence B :Transaction T1 Transaction T2 Transaction T3

read_item(Y);

read_item(Z);

read_item(X);

write_item(X);

write_item(Y);

write_item(Z);

read_item(Z);

read_item(Y);

write_item(Y);

read_item(Y);

write_item(Y);

read_item(X);

write_item(X);


read_item(X); read_item(Z); read_item(Y);

write_item(X); read_item(Y); read_item(Z);

read_item(Y); write_item(Y); write_item(Y);

write_item(Y); read_item(X); write_item(Z);

write_item(X);



Sur le graphe de précédence de la Séquence B, on constate qu’il existe une séquence sérielle équivalente pour cette séquence : T3 → T1 → T2

T2

T3

T1

Y, Z

X, Y

Y



Le graphe de précédence suivant représente 2 séquences équivalentes. On y retrouve :

T3 → T1 → T2 et T3 → T2 → T1

T2

T3

T1


Verrouillage

Un bon moyen d'assurer la sérialisabilité est de rendre l’accès aux données traitées inaccessibles à toute autre transaction concurrente.La méthode la plus utilisée consiste à verrouiller la donnée qu'elle va être traiter.

Il existe deux modes importants :

Ø le mode partagé; noté P, une transaction T peut lire une donnée X mais non l'écrire;

Ø le mode exclusif; noté E, une transaction T peut lire et écrire une donnée X.


Verrouillage

La matrice de compatibilité de verrouillage suivante montre qu’on peut entretenir plusieurs modes P entre plusieurs transactions pour une même donnée X.Cependant, une demande en mode E doit attendre le déverrouillage du mode P pour accéder la donnée X.

Une transaction demande:

Ø un verrouillage partagé de la donnée X en émettant l’instructionLP(X);

Ø un verrouillage exclusif de la donnée X en émettant l’instruction LE(X).

Ø un déverouillage de la donnée X en émettant l’instruction UN(X).

FalseFalseEFalseTrue P

EP


Exemple de verrouillage

La séquence suivante montre la transaction T0 utilisant le mode exclusif E pour modifier les données A et B.

T0

LE(A)

Read (A)

A := A - 50

Write (A)

UN(A)

LE(B)

Read (B)

B := B + 50

Write (B)

UN(B)

Verrouillage exclusif

Déverrouillage

Verrouillage exclusif

Déverrouillage

Nous utilisons le

mode exclusif puisqu’il y a modification des données!


Exemple de verrouillage

La séquence suivante montre la transaction T1 utilisant le mode partagé P pour afficher les données A et B.

T1

LP(A)

Read (A)

UN(A)

LP(B)

Read (B)

UN(B)

Display (B + A)

Verrouillage partagé

Déverrouillage

Verrouillage partagé

Déverrouillage

Le mode partagés’utilise qu’en lecture


Algorithmes de verrouillage

Les algorithmes suivants montre une méthode de verrouillage et déverrouillage binaire. Pouvez-vous dire quelle est le problème de cette approche?lock_item(X) :

B : if LOCK (X)=0 (l’item n’est pas vérouillé)then LOCK (X)←1 (Verrouille l’item)

else beginwait( jusqu’à ce lock (X)=0 et que le gestionnaire de verrou réveille la transaction );goto Bend;

unlock_item(X) :LOCK (X)←0 (Déverrouille l’item)if une transaction est en attentethen réveille la transaction;

À première vue, ça semble

logique…


Algorithmes de verrouillage

La séquence suivante illustre un problème entre 2 transactions T0 et T1 :Ø T0 verrouille exclusivement B;

Ø T1 demande un verrouillage partagé de A et B.

Ø T1 attend que T0 déverrouille B;

Ø T0 demande un verrouillage exclusif de A

Ø T0 attend que T1 déverrouille A.

Un problème survient puisque T0 et T1 sont en interblocage(verrou mortel).

Dans une telle situation, le système doit rejeter l'une des 2 transactions.

T0 T1

LE(B)

Read(B)

B:= B - 50

Write(B)

LP(A)

Read(A)

LP(B)

LE(A)


Protocole de verrouillage deux phases

Ce protocole garantit la sérialisabilité, car il implique que chacune des transactions émette ses demandes de verrouillage et de déverrouillage en 2 phases :Øverrouillage croissant; une transaction peut obtenir des

verrouillages mais pas de nouveau déverrouillage;• Initialement, une transaction est en phase de verrouillage

croissant.

Øverrouillage décroissant; une transaction peut obtenir des déverrouillages mais pas de nouveau verrouillage.

• Lorsqu'elle libère un verrouillage, elle entre en phase de décroissance et aucun verrouillage ne peut plus être imposé.

Ce protocole de verrouillage deux-phases assure lasérialisabilité mais ne permet pas d'éviter les interblocages.


Détection des interblocages et récupération

Pour sortir le système d'un interblocage, il existe une méthode qui utilise un algorithme d'inspection du système. Cet algorithme détecte la présence ou non d'un verrou mortel. Si ce piège est détecté, l'algorithme procède aux opérations suivantes :

Øconserve l'information relative aux affectations des données gérées par les transactions;

Øexploite cette information pour confirmer l'état verrouillédu système;

Ø récupération du système pour en supprimer le verrouillage.


Détection des interblocages et récupération

La question qui se pose alors, est la suivante : Quand faire appel à l'algorithme de détection de verrou mortel ?La réponse dépend de 2 paramètres :

1. Quelle est la fréquence des interblocages?

2. Combien de transactions sont affectées par un interblocage?

Si les verrous mortels sont fréquents, il faut systématiquement invoquer l'algorithme à la même fréquence. Au pire, il faut l'invoquer dès qu'une réquisition de données n'est pas immédiatement satisfaite.


Intégrité des données

Nous pouvons rencontrer plusieurs types d'avaries:Øerreurs logiques d'un programme;Øentrées erronées;Ødonnées introuvables;Ø “crash” système → perte d'information en mémoire vive;Ø “crash” disque → perte d'information sur un bloc-disque.

On a donc besoin de protection lorsque le système est en cours de transaction. En particulier lorsqu'il y a échange entre le disque et la mémoire vive. Dans un SGBD, l’intégrité est assurée par des procédures de récupération.


Intégrité des données

Rappel: Une BD est implantée sur des disques et positionnée en blocs fixes.

Les transfèrent des données entre le disque et la mémoire sont déclenchés au moyen d'ordres :

Ø INPUT(X): transfert du bloc-disque physique la donnée X en mémoire centrale (bloc-tampon ou bloc-mémoire),

ØOUTPUT(X): transfert du bloc-mémoire la donnée X sur bloc-disque.


Transfert des données

Exemple : Soit la variable locale en mémoire vive xi et la donnée X sur le disque et les opérations E/S:

Ø READ(X, xi): xi ← X en 2 étapes,

1.si bloc de la donnée X n'est pas en mémoire: INPUT(X)

2. xi ← X

Ø WRITE(X, xi): X ← xi en 2 étapes,

1. si bloc de la donnée X n'est pas en mémoire: INPUT(X)

2. X ← xi

Ces 2 opérations n'exigent qu'un transfert disque→mémoire (INPUT).

Le bloc-mémoire est écrit sur disque seulement si :

1. le tampon mémoire manque de place lors d'un INPUT,

2. le système veut figer le changement sur disque.

À ce moment le système force le transfert mémoire → disque (OUTPUT)


Séquences des lectures/écritures♦L'opération INPUT se fait la première fois qu'on accède à X;

♦Ensuite, on ne modifie que les xi en mémoire;

♦L'opération OUTPUT peut ne pas s'effectuer immédiatement après un WRITE

Ø Ainsi, si le système subit une avarie entre la modification de xi et l'exécution de l'opération OUTPUT, nous avons une PERTE d'information !!!

Exemple: Pour une transaction bancaire, le transfert de 50$ d'un compte A à un compte B où A initial = 1000$ et B initial = 2000$.

Programme qui traite la transaction :

Read (A, a)a:= a - 50Write (A, a)

Read (B, b)b:= b + 50Write (B, b)


Séquences des lectures/écrituresLa séquence de la transaction est la suivante :

N° TRANSFERT MÉMOIRE DISQUE

1 Read(A,a) → INPUT A 1000 1000 : A

2 a := a – 50 950

3WRITE(A,a): attente, assez de place dans letampon de la mémoire vive

4 Read(B,b) → INPUT B 2000 2000 : B

5 b := b + 50 2050

6 → OUTPUT A 950 : A

7 WRITE (B,b) → OUTPUT B 2050 : B


Séquences des lectures/écrituresSi on simule 3 situations d'avaries mémoire :

Ø le crash mémoire arrive juste après l'étape 5 mais avant les étapes 6 et 7 :

• perte de la transaction;

• le disque est dans l'état initial (A + B = 3000) donc pas de problème.

Ø le crash mémoire arrive après l'étape 7 :

• transaction complétée;

• le disque est modifié et (A + B = 3000) donc pas de problème.


Séquences des lectures/écritures

Ø le crash mémoire arrive juste après l'étape 6 mais avant l'étape 7 :

• perte de la transaction;• le disque est modifié, mais (A + B != 3000)… donc

problème!!!

Nous avons vu qu’une transaction est dans un état échoué àla suite d'erreurs logiques ou matérielles. Le système peut alors choisir l'une de ces 2 options :Ø relancer la transaction;Ø tuer la transaction.

Pour les aider à récupérer les transactions manquées, les systèmes utilisent différentes méthodes utilisant un journaldans lequel il inscrit l’état des transactions.


TransactionPour la récupération de transactions, il existe plusieurs méthodes :

1. Journal incrémental à mise-à-jour différée;

2. Journal incrémental à mise-à-jour immédiate;

3. Journal à point de contrôle.

Note: Ces techniques sont utilisées pour des avaries àperte de mémoire volatile (vive).Pour les pannes disques (mémoire non-volatile), il faut prévoir un archivage régulier sur médium externe (bandes magnétiques, etc.)


Journal incrémental à mise-à-jour différée

Pour l'exemple de la transaction bancaire (p.217), la difficultéprovient de la modification de la base de données à l'étape 6, sans avoir été assurés que la transaction était validée. La transaction T a transférée 50$ du compte A vers le compte B, mais si un crash intervient après OUTPUT (A) et avant OUTPUT (B) on ne peut :Øni tuer la transaction (950 + 2000 != 3000);Øni ré-exécuter la transaction (900 + 2050 != 3000).



Pour résoudre le problème il faut :

1. Inscrire toutes les transactions d'écriture dans un journal ("log file") en mémoire sûre (fichier sur disque);

2. Différer toutes les opérations d'écriture jusqu'à la validation partielle de la transaction;

3. Lorsque la transaction est partiellement validée, les instructions du journal sont exécutées et les données sont écrites à nouveau sur le disque.

Ainsi…

• Si le système tombe en panne avant que Ti soit complétée, on ignore le journal de la transaction Ti.

• Sinon, l'ensemble des données mises à jour par Ti, ainsi que leurs nouvelles valeurs peuvent être retrouvées dans le journal.



Le système utilise les commandes suivantes pour gérer le journal:

• “ Ti start ” indique le début d’une transaction;• “ Ti commits ” indique que la transaction est

terminée.

Les données ne sont écrites sur le disque que lorsque le Ti commits a été inscrit dans le journal. Le module de récupération, en cas de panne, utilise le journal pour reprendre les opérations inscrites entre :

• “ Ti start ” et “ Ti commits ” en utilisant l'opération Redo Ti .

Note : L'opération Redo doit être équivalente au résultat de l’exécution unique.



Exemple avec écriture au journal lors de transactions:N° TRANSFERT JOURNAL DISQUE

T0.1 Read(A,a) → INPUT A « T0 start » 1000 : A

T0.2 a := a – 50 → OUTPUT A : fichier-journal « T0,A,950 »

T0.3 WRITE → attente, assez de place et la transaction n'est pas terminée

T0.4 Read(B,b) → INPUT B 2000 : B

T0.5 b := b + 50 → OUTPUT B : fichier-journal « T0,B,2050 »

T0.6 WRITE →OUTPUT A et B : fichier-données

« T0 commits » 950 : A

2050 : B

T1.1 Read(C,c) → INPUT C « T1 start » 700 : C

T1.2 c : =c - 100 → OUTPUT C : fichier-journal « T1,C,600 »

T1.3 WRITE → OUTPUT C « T1 commits » 600 : A


Journal incrémental à mise-à-jour immédiate

Ømême principe que le journal à mise à jour différée,Ømais conserve l'état précédent du système (avant

modifications),• pratique en traitement concurrent (aucune différence en

traitement simple).Exemple :

“ T0 start ”“ T0,A,1000,950 ”“ T0,B,2000,2050 ”“ T0 commits ”“ T1 start ”“ T1,C,700,600 ”“ T1 commits ”

état précédent du système


Journal incrémental à mise-à-jour immédiate

Avec ce nouveau mécanisme on peut concevoir une opération Undo qui remet la BD dans l'état précédent. Ici, le système peut inscrire les données immédiatement après les avoir modifiées sans attendre d'avoir inscrit “ Ti commits ”dans le journal.Si une panne survient:

Ø les transactions qui ont une entrée “ Ti commits ” dans le journal seront exécutées.

Øpour les autres transactions, la commande Undo replace les données sur le disque à leurs états précédents.



Exemple :

a) Opérations de lecture et d’écriture de 2 transactions dans unenvironnement en traitement simple

b) L’état du journal au moment du crash

Les opérations de la T1 vont être refait, mais pas celles de

T2 (le commit n’ayant pas été

complété)


Journal à points de contrôleAvec un journal incrémental, il faut, en cas de panne système, parcourir l'intégralité du journal pour identifier les transactions à itérer et à annuler. Cela présente 2 inconvénients :

Øcette recherche demande du temps;

Øet de toutes façons, la plupart des transactions sont normalement cohérentes dans la base.

Pour éliminer ce genre de servitude, on fait appel à des points de contrôle.


Journal à points de contrôleLes points de contrôle sont :

Øutile lorsque la BD est rafraîchie régulièrement;

• ajout d'un "checkpoint" immédiatement après rafraîchissement;

Øpermet de diminuer le temps de mise-à-jour après une panne.

Principe :Le journal est "remonté" (à partir de la fin) vers le dernier point de contrôle et la BD est mise à jour à l'aide des procédures usuelles.


Journal à points de contrôleExemple de récupération avec points de contrôle

Ø T1 est complétée et ne requiert aucune récupération;Ø T2 et T3 devront être exécutées de nouveau;Ø T4 et T5 sont ignorée.

Temps

T1

T2

T3

T4

T5

Point de contrôle Panne de système


Journal à points de contrôleAutre exemple de récupération avec points de contrôle

Dernier

point de

contrôle

T2 et T3 sont ignorées car leur commit n’ont pas étés fait. T4 est refait car le commit a été fait après

le dernier point de contrôle.


Contraintes d'intégrité

Les contraintes permettent de garantir que les modifications permises sur la base ne provoquent pas de perte de consistance:

• Leurs prédicats permettent de vérifier l'entrée des données;

Exemple 1 en SQL :

assert contrainte-solde on Dépôt : solde ≥ 0

Cette contrainte interdit que le solde soit négatif.


Contraintes d'intégritéExemple 2 en SQL:

assert contrainte-adresse :( select Client

from Clientèle )contains

( select Clientfrom Dépôt )

Si la BD ne respectent pas les contraintes d’intégrité, une action automatique est déclenchée ("trigger") par le système après modification de la base.

Un client ne peut pas ouvrir un compte s’il n'apparaît pas dans la relation Clientèle.


Intégrité et système réparti

La différence essentielle entre une BD centralisée et une BDrépartie se caractérise par la dispersion des données entre plusieurs sites informatiques.

Cette dispersion est la cause de nombreux problèmes.

Les divers protocoles de verrouillage peuvent être utilisés en environnement réparti. Comme les demandes de verrouillage et de déverrouillage ne sont plus issues d'un seul site, le système n’utilise qu'un seul coordinateur.



Lorsqu'une transaction doit bloquer une donnée, le coordinateur détermine si cette opération peut être immédiatement effectuée.

ØSi c'est le cas, il envoie un message au site émetteur de la demande.

ØSinon, cette demande est différée. La transaction peut lire les données d'un quelconque site possédant une réplique des données.Pour une opération d'écriture, tous les sites possédant une réplique des données doivent être impliqués dans l'opération.



Cette méthode présente les avantages et désavantagessuivants :Øsimplicité de mise en œuvre;Øsimplicité du traitement des interblocages: comme

toutes les demandes sont faites sur le même site, les algorithmes de traitement de verrouillage, de déverrouillage et de verrous mortels sont semblables àceux utilisés sur un système centralisé.Øembouteillage: le site du coordinateur devient un

carrefour congestionné par les demandes;Øvulnérabilité: si le site du coordinateur tombe en panne,

le gestionnaire des multitraitement est perdu. On doit faire appel à une technique de récupération.



Un compromis peut être trouvé entre ces avantages et désavantages au moyen d'un coordinateur multiple, dont le gestionnaire de verrouillage et de déverrouillage est réparti entre plusieurs sites.Chacun des gestionnaires locaux administre les demandes et cela réduit les embouteillages, mais complique le traitement des verrous mortels.


Récupération d’un système réparti

Pour garantir l’atomicité des transactions, les BD réparties sont munies d'un gestionnaire de transactions. L'ensemble des gestionnaires locaux coopèrent à la gestion des transactions globales.Chaque site du système réparti comporte 2 sous-systèmes :Le gestionnaire de transactions qui gère les transactions (locales ou globales) pour un site donné et se charge de :Ø l'entretien du journal aux fins de récupérationØ la participation pour mener en parallèle l'exécution des transactions.

Le coordinateur de transactions qui coordonne l'exécution des transactions (locales ou globales) pour un site donné et se charge :Ø du démarrage des transactions;Ø du découpage des transactions en sous-transactions et répartition

sur les sites appropriés pour l’exécution;Ø du suivi global des transactions qui peut se solder par la validation

ou par le rejet sur tous les sites.


Résistance aux pannes

La répartition des données ajoute quelques problèmes additionnels:Ø panne de site;Ø panne de liaison;Ø perte de messages;Ø coupure de réseau.

Ce genre de problème peut provoquer des erreurs de calcul lors du traitement des requêtes.

Le résultat de l’exécution d’une transaction simultanée devrait être identique à celui de son exécution isolée. Pour que le système soit robuste, il faut :

Ø détecter un de ces défauts,

Ø reconfigurer le système pour qu'il continue de fonctionner

Ø et procéder à la récupération du système lorsque le défaut est éliminé.



Par exemple, imaginons que le site S1 ait détecté un défaut, il lui faut alors amorcer une procédure de récupération :Øsi des données répliquées sont stockées sur le site en

panne, le fichier système (catalogue) doit être remis àjour pour que les requêtes ne fassent plus appel à la copie stockée sur le site en défaut;Øsi des transactions étaient en cours sur le site en panne,

elles doivent être avortées;Øsi le site en défaut était le serveur centralisé des sous-

systèmes (serveur de désignation de sous-relations, serveur de coordination des multitraitement, serveur de détection d'interblocage), il faut le remplacer (serveur «backup»).



Lorsqu'un site se libère d'une panne, le système consulte son journal pour déterminer le sort des transactions en cours d'exécution lorsque la panne est intervenue :

ØSi le journal contient des transactions valides àreprendre (commits), il effectue alors un redo(T);

ØSi le journal contient des transactions invalides àreprendre (pas de commits), il effectue alors un undo(T).


SécuritéPour assurer la sécurité, les données doivent être protégées contre :

ØLes accès non autorisés;

ØLes modifications erronées;

ØLes inconsistances accidentelles;

ØLe piratage.

Au chapitre 4, nous avons introduit le concept de vue en tant que personnalisation de la BD vis à vis de l'utilisateur. Ainsi, une vue cache les données que l'utilisateur n'a pas besoin de voir.Cette fonction sert aussi bien à simplifier l'usage de la BD qu'àrenforcer la sécurité.


SécuritéLes systèmes de bases de données relationnelles assurent leur sécurité à deux niveaux :

ØAu niveau des relations, un utilisateur peut être autoriséou non à accéder à une relation donnée.

ØAu niveau des vues, un utilisateur peut être autorisé ou non à accéder aux données qui font partie d'une vue donnée.


Privilèges d'accèsUn utilisateur, en fonction de son titre, peut avoir plusieurs types de privilèges :Ø Lecture;Ø Insertion;Ø Mise à jour;Ø Effacement;Ø Accès aux index;Ø Accès aux relations (création, modification, abandon).

Pour gérer les droits d'accès à la BD, on peut à l'aide de SQLaccorder des privilèges par l'instruction grant.

grant “liste de privilèges” on “relation ou vue” to “liste d'utilisateurs”

La liste de privilèges permet d'en attribuer plusieurs à la fois sous une même instruction : select, insert, delete, update, ...


Privilèges d'accèsPour retirer des privilèges à un utilisateur, nous utilisons la commande revoke. REVOKE {liste_privilèges | ALL [PRIVILEGES]} ON objet FROM {liste_utilisateurs | PUBLIC}]

Exemples: GRANT ALL PRIVILEGES ON EMPLOYE TO EricGRANT SELECT, UPDATE (SALAIRE) ON EMPLOYE TO Lucie

REVOKE UPDATE ON EMPLOYE TO Lucie


Privilèges d'accès


Restriction sur les colonnes de la BD en fonction du code d’accès de l’utilisateur.

Permet de personnaliser la base en fonction des utilisateurs et de leurs permissions d'accès et à la modifications des données.

Concepts de vues


Restriction d’accès sur les tuples

Cette figure montre l'utilisation d'une vue pour restreindre l'accès à des tuples précis de la BD en fonction du code d'accès de l'utilisateur.

Concepts de vues


Cryptage des donnéesLes précautions très diverses que l'on peut prendre pour protéger une BD peuvent ne pas être suffisantes pour des données très importantes.Dans de tel cas, celles-ci doivent être cryptées. Il n'est pas possible de lire de telles données à moins de connaître le code qui permet le décryptage.Exemple:ØRobert Lefebvre devient C^;^->N;^ @^>Y>

Un intrus avisé qui consulte un grand nombre de données peut briser le code utilisé. Un exemple de mauvais cryptage :ØRobert Lefebvre devient Spcfsu Mfgfcwsf

Pouvez-vous

trouver le code

utilisé ?


Cryptage des donnéesUn bon système de cryptage des données possède les propriétés suivantes :

Ø il doit être simple pour l'utilisateur de crypter et de décrypter les données qu'il manipule,

Ø le processus de cryptage ne dépend pas de la confidentialité de l'algorithme mais d'une clé de cryptage,

Ø la clé de cryptage doit être excessivement difficile àidentifier pour un intrus.


Bonne fin de session à tous!

Documents

Chapitre 11 - Intégrité et Sécurité