Techniques et mécanismes pour sécuriser un système

Afin d’éliminer les vulnérabilités, contrer les attaques, et garantir un niveau élevé de protection du réseau et du système d’information, on peut utiliser des services, des mécanismes, des outils et des procédures que l’on nomme, de façon générale, des solutions ou des mesures de sécurité. Par exemple, un service d’identification et d’authentification aide à réduire le risque d’intrusion dans un système. Les politiques de sécurité seront présentées comme un dispositif nécessaire pour renforcer la sécurité des systèmes. Puis il conviendra d’aborder succinctement la manière avec laquelle on peut les construire et les implémenter.
Nous expliquons également d’autres contre-mesures pour renforcer la sécurité comme les mécanismes cryptographiques, le cloisonnement, l’audit, la détection d’intrusion et la tolérance aux intrusions.

Politiques de sécurité

Dans un système informatique, l’autorisation a pour but de ne permettre que les actions légitimes, c’est-à-dire à empêcher qu’un utilisateur puisse exécuter des opérations qui ne devraient pas lui être permises [Deswarte 2003]. Pour définir quelles sont les opérations autorisées et celles qui sont interdites, il faut établir une politique de sécurité ou “doctrine de sécurité”. Les ITSEC [ITSEC 1991] définissent une politique de sécurité comme étant « l’ensemble des lois, règles et pratiques qui régissent la façon dont l’information sensible et les autres ressources sont gérées, protégées et distribuées à l’intérieur d’un système spécifique ». À cet égard, pour construire une politique de sécurité il faut :
– d’une part, définir un ensemble de propriétés de sécurité qui doivent être satisfaites par le système ; par exemple “une information classifiée ne doit pas être transmise à un utilisateur non habilité à la connaître”, et
– d’autre part, établir un schéma d’autorisation, qui présente les règles permettant de modifier l’état de protection du système ; par exemple “le propriétaire d’une information peut accorder un droit d’accès pour cette information à n’importe quel utilisateur”.
Si la politique d’autorisation est cohérente, il ne doit pas être possible, partant d’un état initial sûr (c’est-à-dire satisfaisant les propriétés de sécurité), d’atteindre un état d’insécurité (c’est-à dire un état où les propriétés de sécurité ne sont pas satisfaites) en appliquant le schéma d’autorisation. Comme on l’a déjà expliqué (voir 1.3), les propriétés de sécurité peuvent être définies en fonction de la confidentialité, l’intégrité ou la disponibilité d’informations ou de méta-informations.
Une politique de sécurité peut se développer dans trois directions distinctes : les politiques de sécurité physique, administrative et logique.
La politique de sécurité physique précise un ensemble de procédures et de moyens qui protègent les locaux et les biens contre des risques majeurs (incendie, inondation, etc.) et contrôlent les accès physiques aux matériels informatiques et de communication (gardiens, …).
La politique de sécurité administrative définit un ensemble de procédures et moyens qui traite de tout ce qui ressort de la sécurité d’un point de vue organisationnel au sein de l’entreprise. La structure de l’organigramme ainsi que la répartition des tâches (séparation des environnements de développement, d’industrialisation et de production des applicatifs) en font partie. Lespropriétés de sécurité recherchées visent, par exemple, à limiter les cumuls ou les délégations abusives de pouvoir, ou à garantir une séparation des pouvoirs.
La sécurité logique fait référence à la gestion du contrôle d’accès logique, lequel repose sur un triple service d’identification, d’authentification et autorisation. Elle spécifie qui à le droit d’accéder à quoi, et dans quelles circonstances. Ainsi, tout utilisateur, avant de se servir dusystème, devra décliner son identité (identification) et prouver qu’il est bien la personne qu’il prétend être (authentification). Une fois la relation établie, les actions légitimes que peut faire cet utilisateur sont déterminées par la politique d’autorisation (ce type de politiques nous intéresse particulièrement, et sera décrit en détail dans le chapitre suivant).
L’autorisation consiste à gérer et à vérifier les droits d’accès, en fonction des règles spécifiées dans la politique de sécurité. On dit qu’un sujet (entité qui demande l’accès, dite aussi entité active) possède un droit d’accès sur un objet (entité à laquelle le sujet souhaite accéder, dite aussi entité passive) si et seulement s’il est autorisé à effectuer la fonction d’accès correspondante sur cet objet. Les droits d’accès peuvent être symboliquement représentés dans une matrice de droits d’accès dont les lignes représentent les sujets et les colonnes représententles objets. Une cellule de la matrice contient donc les droits d’accès d’un sujet sur un objet. La matrice est gérée conformément aux règles définies dans la politique de sécurité.
L’autorisation est mise en œuvre par des mécanismes de contrôle d’accès. Il est généralement recommandé d’organiser ces mécanismes de façon à implémenter la notion de “moniteur de référence”, défini dans le livre orange [TCSEC 1985]. Le moniteur de référence est un intermédiaire entre les sujets et les objets. Il vérifie que chaque accès d’un sujet vers un objetest garanti par un droit d’accès dans la matrice de droits d’accès ; en l’absence de ce droit d’accès, l’accès est refusé. Le moniteur de référence doit être inviolable (il ne doit pas pouvoir être modifié), incontournable (il ne doit pas être possible d’accéder à un objet sans être contrôlé par le moniteur de référence), et totalement vérifié (il ne doit comporter aucune faute de conception ou de réalisation).

Certificats

Le raisonnement précédemment appliqué (chiffrement et signatures à clés publiques) suppose l’authenticité des clés publiques, disponibles sur un annuaire ou un serveur web par exemple.
Néanmoins, cette authenticité n’est pas garantie dans un environnement ouvert tel qu’Internet, et il n’est pas impossible qu’un certain pirate Bob modifie l’annuaire ou le serveur web qui héberge les clés publiques et remplace ainsi la clé publique d’une certaine Alice par la sienne.
Une fois ce déguisement commis, Bob peut lire les courriers destinés à Alice et signer des messages en se faisant passer pour Alice. En effet, si un utilisateur envoie un message chiffré à Alice, il va le chiffrer avec la clé publique de Bob (croyant que c’est la clé d’Alice). Bob pourra déchiffrer les messages destinés à Alice avec sa clé privée, et lire ainsi le courrier confidentiel d’Alice. Le raisonnement du scénario de l’usurpation de la signature est le même.
Pour contrer ce type d’attaques et afin d’assurer la validité de la clé publique, il a fallu créer un mécanisme supplémentaire, le certificat électronique.
Un certificat permet d’établir un environnement de confiance entre deux entités distantes ayant besoin de communiquer entre elles et de s’échanger des informations non-répudiables (nécessité de signature) ou confidentielles (application de chiffrement). En effet, un certificat est souvent destiné à remplir trois rôles : authentification de l’émetteur, garantie de l’intégritédes documents, et éventuellement un horodatage.
Selon la norme X509 V3, un certificat électronique doit contenir notamment : le nom de l’autorité de certification, le nom et le prénom de la personne, son entreprise, son adresse électronique, sa clé publique, les dates de validité du certificat ainsi qu’une signature électronique (figure 1.8). Cette signature, calculée sur les informations contenues dans le certificat, est l’empreinte de ces informations chiffrée avec la clé privée de l’autorité de certification qui a délivré ce certificat.
Nous avons décrit séparément les mécanismes de chiffrement et de signature. Mais il est possible de cumuler les deux fonctions, par exemple, en envoyant un message chiffré et signé. Les logiciels courants appliquent la signature avant le chiffrement à l’émission, et le déchiffrement puis la vérification de la signature à la réception. Toutefois, il est possible d’inverser l’ordre de réalisation de ces opérations. publique de Bob. S’il ne la connaît pas, il peut interroger l’annuaire électronique pour récupérer un certificat de Bob. Ce certificat est signé avec une autorité ACBob. Le logiciel de messagerie peut vérifier la signature de ce certificat pour s’assurer que ce document a bien étécrée par l’autorité ACBob et qu’il n’a pas été modifié. Avec cette assurance, le logiciel de messagerie peut récupérer la clé publique de Bob contenue dans ce certificat. La vérification ducertificat et l’extraction de la clé publique sont schématisées dans la figureci-dessous.

Tolérance aux intrusions

Il est illusoire de croire qu’on peut éviter les attaques sur les systèmes de grandes tailles. De même il est impossible d’éliminer toutes les vulnérabilités. Il faut donc s’attendre à ce que certaines attaques réussissent, c’est-à-dire produisent des intrusions. D’ailleurs, le terme intrusion doit être pris dans un sens large, puisqu’il ne faut pas considérer que tous les intrus sont externes. Un grand nombre d’entre eux sont des utilisateurs enregistrés qui tentent d’étendre leurs privilèges, voire des utilisateurs privilégiés qui abusent de leurs privilèges.
Puisqu’il est inévitable que des intrusions se produisent, il serait intéressant de tolérer les intrusions, c’est-à-dire de faire en sorte que l’intrusion dans une partie du système n’ait pas de conséquence sur sa sécurité. Pour cela, on pourrait utiliser les techniques développées dans le cadre plus général de la tolérance aux fautes. Mais cela pose deux problèmes principaux :
– si un attaquant a réussi à s’introduire dans une partie du système, il ne doit pas lui être trop facile de réussir la même attaque sur une autre partie ; cela signifie que chaque “partie” soit suffisamment sécurisée et, de préférence, qu’elle soit diversifiée, c’est-à-dire que ses constituants ne présentent pas les mêmes vulnérabilités [Deswarte et al.1999] ;
– il ne faut pas qu’une seule intrusion dans une partie du système fournisse à l’attaquant des informations sensibles ; ceci est d’autant plus important que la redondance, nécessaire à la tolérance aux fautes, peut fournir plus d’occasions d’attaques aux pirates éventuels.
Une technique de tolérance aux intrusions a été développée pour préserver la confidentialité tout en permettant de tolérer les fautes accidentelles et les intrusions, y compris par des utilisateurs privilégiés : la fragmentation-redondance-dissémination, [Fabre et al.1996]. Cette technique est fondée sur le principe d’utilisation de la répartition d’un système sur un réseau local de façon à ce qu’une intrusion ne mette pas en défaut la confidentialité, l’intégrité ou la disponibilité du système. La fragmentation consiste donc à découper les informations sensibles en fragments de telle sorte qu’un fragment isolé ne contienne pas d’information significative (confidentialité). On ajoute de la redondance à ces fragments de façon à ce que la modification ou la destruction de fragments n’empêche pas la reconstruction de l’information (intégrité et disponibilité). Enfin, la dissémination vise à ce qu’une intrusion ne donne accès qu’à des fragments isolés. La dissémination peut être topologique, en utilisant des sites de stockage différents, ou en transmettant les fragments sur des canaux de communications indépendants.
Elle peut être temporelle, en transmettant des fragments dans un ordre aléatoire et en y ajoutant éventuellement des faux fragments de bourrage. La dissémination peut aussi porter sur les privilèges, en exigeant la coopération de plusieurs personnes ayant des privilèges différents pour accomplir une opération (séparation des pouvoirs).
Lorsque la confidentialité n’est pas critique, on peut utiliser des méthodes classiques de tolérance aux fautes, comme la détection et la correction d’erreurs, ou le masquage d’erreurs.
Dans ce contexte, la détection d’erreurs peut reposer sur des techniques de détection d’intrusions, ou sur la comparaison de plusieurs exécutions diversifiées. La correction d’erreurs repose alors sur la reprise (ré-exécution à partir de sauvegardes) ou sur la poursuite (on rétablit le système dans une configuration correcte). Le masquage d’erreurs consiste à avoir suffisamment d’exemplaires des données et des exécutions pour pouvoir corriger les dégâts causés par les intrusions.

Politiques et modèles de sécurité

Préambule

Le précédent chapitre a présenté les définitions relatives à la notion de sûreté de fonctionnement. La sécurité a été présentée comme la combinaison de trois propriétés : la confidentialité, l’intégrité et la disponibilité de l’information. Ensuite, les principales techniques et mesures de sécurité ont été définies, et l’analyse a montré l’intérêt des politiques d’autorisation dans la construction de la sécurité d’un système ou d’une organisation. Examinons maintenant les grandes familles de politiques de sécurité ainsi que les principaux modèles de sécurité représentés dans la littérature ; en l’occurrence les politiques discrétionnaires, obligatoires, à base de rôles, ainsi que les modèles HRU, Take-Grant, TAM, graphe des privilèges, etc. Nous évalurons les avantages et les limites de ces modèles et politiques de sécurité, puis les confrontons aux spécificités des SICSS, déjà identifiées. Les résultats de projets récents, s’intéressant aux problèmes de la sécurité dans le domaine médical, et plus précisément aux politiques de sécurité, seront également abordés.
Enfin, la discussion des politiques actuellement en vigueur permettra de conclure qu’elles ne couvrent pas toute la richesse des SICSS. Sur le plan réglementaire, les bases et textes légaux existent, même s’ils ne sont pas assez formalisés ou formalisables, de même qu’ils ne sont pas encore appliqués ou applicables dans les pays européens. Sur le plan technique, les notions de rôles et d’équipes sont prometteurs. Néanmoins, elles nécessitent une adaptation considérableet doivent être complétées par de nouveaux concepts.

Modèles associés aux DAC

Cette section présente les premiers modèles conçus ou utilisés pour représenter les politiques discrétionnaires. Notons tout de même que ces modèles peuvent éventuellement être utilisés pour représenter et formaliser d’autres types de politiques. Néanmoins, pour des raisons principalement chronologiques, il a semblé plus pertinent de les inclure dans cette section.

Modèle de Lampson

La notion de matrice de contrôle d’accès, dédiée à la représentation des droits d’accès (autorisations), a été introduite par Lampson dès 1971 [Lampson 1971]. La structure de ce modèle est celle d’une machine à états où chaque état est un triplet (S,O,M) avec : S désignant un ensemble de sujets, O un ensemble d’objets et M une matrice de contrôle d’accès. Chaquecellule M(s,o) de cette matrice contient les droits d’accès que le sujet s possède sur l’objet o.
Les droits correspondent généralement à des actions élémentaires comme lire ou écrire. La matrice des droits d’accès n’est pas figée. En effet, si de nouveaux objets, de nouveaux sujets ou de nouvelles actions sont ajoutées dans le système, il devient alors nécessaire d’enregistrer toutes les permissions accordées pour ces nouvelles entités. Par conséquent, la mise à jour d’une politique de sécurité exprimée par ce modèle est quelque peu fastidieuse. Enfin, ce modèle ne permet pas d’exprimer directement des interdictions ou des obligations.
Le modèle de Lampson a été progressivement amélioré pour donner naissance à d’autres modèles tels que HRU [HRU 1976] et Take-Grant [Jones et al. 1976].

Modèle HRU

Le modèle HRU s’est intéressé à la complexité de la tâche de vérification des propriétés assurées par une politique d’autorisation. Comme dans le modèle de Lampson, HRU utilise une matrice d’accès classique, la différence réside en ce que HRU précise les commandes qui peuvent lui être appliquées. Les seules opérations possibles sont données dans le tableau 2.1.
Le format des commandes est présenté dans le tableau 2.2, où x i est un paramètre de la commande, a (i) Œ Aest un droit, et opiest une des six opérations élémentaires possibles.

Graphe de privilèges

Dacier et Deswarte ont proposé une extension du modèle ATAM afin d’augmenter son efficacité, notamment dans le cas de schémas d’autorisation particuliers [Dacier & Deswarte 1994]. En effet, ils ont montré que l’introduction de privilèges Ad-hoc dans un modèle TAMpeut améliorer sa complexité algorithmique dans certaines situations bien précises.Puis ils ont proposé un autre modèle, le “graphe de privilèges”, dans lequel un privilège est défini comme étant un ensemble de droits S qu’un sujet s peut posséder sur un objet o . Lesnœuds du graphe sont des ensembles de privilèges que possèdent chaque utilisateur sur des ensembles d’objets, autrement dit, des ensembles de triplets (U, O, S A) où U représente un sujet, O un objet et SA un ensemble de droits. Pour chaque type d’objets q , S q désigne l’ensemble des objets de type q. L’existence d’un arc d’un premier ensemble de privilèges vers un second indique que la possession de ce premier ensemble permet d’acquérir le second, par application d’une ou plusieurs règles du schéma d’autorisation [Dacier & Deswarte 1994 ; Dacier 1994].
Par exemple, l’application de la règle « un sujet b peut accorder tous les droits en lecture qu’il a sur un objet de type obj 3 » créerait un nœud que l’on peut définir de la façon suivante : N = {(b, O, lecture) | O Œ Sobj3 Ÿ lecture Œ [b,O]}. Ce nœud représente un sous-ensemble des privilèges que b possède effectivement dans la matrice d’accès lorsque la règle est appliquée, mais ce sous-ensemble n’est pas figé. En effet, une telle définition désigne également les droitsinsérés dans la matrice après que le nœud a été créé. Ceci est possible puisque le contenu dunœud n’est jamais énuméré mais seulement défini.
À partir d’un état initial, l’application successive des règles du schéma d’autorisation conduirait à l’obtention (pour tout sujet U) de MU , l’ensemble maximal de privilèges que Upourrait obtenir. Cet ensemble correspond à la ligne de la matrice représentant l’état maximal, au sens de TAM. En pratique, la construction du graphe de privilège (ses nœuds et ses arcs) se fait progressivement par application des règles qui composent le schéma d’autorisation. Pour cela, Dacier et Deswarte ajoutent deux opérations primitives aux six autres définies dansTAM :  make_edge et make_node. La première crée un nœud tandis que la deuxième crée un arc dans le graphe (à conditions que ceux-ci n’existent pas déjà). L’ensemble des opérations estd’abord utilisé pour réécrire les règles du schéma d’autorisation sous forme de commandes.

Table des matières

INTRODUCTION GÉNÉRALE
CHAPITRE 1. SÉCURITÉ DES SYSTÈMES D’INFORMATION ET DE COMMUNICATION EN SANTÉ ET SOCIAL
1.1. CARACTÉRISTIQUES DES SYSTÈMES D’INFORMATION ET DE COMMUNICATION EN
SANTÉ ET SOCIAL
1.1.1. Définition et enjeux
1.1.2. Complexité des SICSS
1.1.3. Diversité des exigences de sécurité
1.1.4. Menaces pesant sur les informations manipulées par ces systèmes
1.2. CONCEPTS DE LA SÛRETÉ DE FONCTIONNEMENT
1.2.1. Définitions de base
1.2.2. Les fautes dues à l’homme
1.3. LA SÉCURITÉ DES SYSTÈMES D’INFORMATION
1.3.1. Introduction!: définition de la sécurité
1.3.2. Confidentialité
1.3.3. Intégrité
1.3.4. Disponibilité
1.3.5. Autres facettes de la sécurité
1.4. INTRUSIONS, ATTAQUES, VULNÉRABILITÉS
1.5. TECHNIQUES ET MÉCANISMES POUR SÉCURISER UN SYSTÈME
1.5.1. Politiques de sécurité
1.5.2. Autres contre-mesures
1.5.2.1 Mécanismes cryptographiques
1.5.2.2 Cloisonnement et pare-feux
1.5.2.3 Audit
1.5.2.4 Détection d’intrusions
1.5.2.5 Tolérance aux intrusions
1.5.2.6 Évaluation de la sécurité
CHAPITRE 2. POLITIQUES ET MODÈLES DE SÉCURITÉ
2.1. CLASSIFICATION DES POLITIQUES ET MODÈLES DE SÉCURITÉ
2.2. POLITIQUES ET MODÈLES D’AUTORISATION DISCRÉTIONNAIRES (DAC)
2.2.1. Présentation des DAC
2.2.2. Modèles associés aux DAC
2.2.2.1 Modèle de Lampson
2.2.2.2 Modèle HRU
2.2.2.3 Modèle Take-Grant
2.2.2.4 Modèle TAM
2.2.2.5 Graphe de privilèges
2.3. POLITIQUES ET MODÈLES D’AUTORISATION OBLIGATOIRES (MAC)
2.3.1. Les politiques multi-niveaux
2.3.1.1 Politique du DoD et modèle de Bell-LaPadula
2.3.1.2 Politique d’intégrité de Biba
2.3.2. Politiques de Clark et Wilson
2.3.3. Politique de la muraille de Chine
2.4. POLITIQUES DE CONTRÔLE DE FLUX
2.5. POLITIQUES DE CONTRÔLE D’INTERFACES
2.6. POLITIQUES ET MODÈLES DE SÉCURITÉ PAR RÔLES (RBAC)
2.7. POLITIQUES ET MODÈLES DE SÉCURITÉ PAR ÉQUIPES (TMAC)
2.7.1. Définition de TMAC
2.7.2. C-TMAC!: Context-TMAC
2.8. APPLICATION DE CES APPROCHES AUX SICSS
2.8.1. Discussion des politiques et modèles existants
2.8.2. Politiques de sécurité pour les SICSS
2.8.2.1 Politique de sécurité de SEISMED
2.8.2.2 Politique de sécurité de la BMA
2.8.2.3 Politique de sécurité de la SMA
2.8.2.4 Recommandations de la FMAG
2.8.2.5 Conclusion et présentation du projet MP6
CHAPITRE 3. BÂTIR UNE POLITIQUE DE SÉCURITÉ POUR LES SICSS
3.1. MÉTHODOLOGIE DE NOTRE APPROCHE0
3.1.1. Description d’un scénario représentatif
3.1.2. Identification des informations à protéger
3.1.3. Expression des objectifs de sécurité
3.1.4. Définition des règles de sécurité
3.1.5. Modélisation formelle
3.2. DE LA DESCRIPTION DES SICSS AUX BESOINS DE SÉCURITÉ À SATISFAIRE
3.2.1. Étude de cas 1!: Sphère médicale
3.2.1.1 Scénario
3.2.1.2 Informations à protéger
3.2.1.3 Risques identifiés
3.2.1.4 Besoins de sécurité
3.2.1.5 Règlement de sécurité
3.2.2. Étude de cas 2!: Sphère sociale
3.2.2.1 Scénario d’accès en amont
Scénario d’accès en aval
3.2.2.3 Ressources à protéger, menaces, exigences et règles de sécurité
3.2.3. Étude de cas 3!: Analyse de différents scénarios d’anonymisation d’informations médicales
3.2.3.1 Problématique de l’anonymisation
3.2.3.2 Notion d’objectifs d’anonymisation
3.2.3.3 Notion d’exigences d’anonymisation
3.2.3.4 L’anonymisation dans les pays européens
3.2.3.5 Scénario 1!: transfert des données médicales
3.2.3.6 Scénario 2!: unions professionnelles
3.2.3.7 Scénario 3!: Programme de Médicalisation des Systèmes d’Information “PMSI”
3.2.3.8 Scénario 4!: traitement des maladies à déclaration obligatoire
3.2.3.9 Scénario 5 : traitements des données statistique
3.2.3.10 Scénario 6!: études épidémiologiques focalisées
3.2.3.11 Une nouvelle solution générique
CHAPITRE 4. LE MODÈLE OR-BAC
4.1. MOTIVATION
4.2. CONCEPTS DE BASE DU MODÈLE OR-BAC
4.2.1. Organisations
4.2.2. Rôle dans Organisation (RdO)
4.2.3. Vue dans Organisation (VdO)
4.2.4. Activité dans Organisation (AdO)
4.2.5. Le contexte
4.2.5.1 Contexte et contraintes du rôle
4.2.5.2 Contexte d’objet
4.2.5.3 Attributs d’utilisateurs
4.2.5.4 Contexte de l’utilisation
4.3. REPRÉSENTATION D’OR-BAC EN UML
CHAPITRE 5. CHOIX D’UN FORMALISME POUR OR-BAC
5.1. INTÉRÊT D’UNE APPROCHE FORMELLE
5.1.1. Consultation d’une politique de sécurité
5.1.2. Cohérence d’une politique de sécurité
5.1.3. Propriétés attendues d’une politique de sécurité
5.1.4. Complétude et interopérabilité
5.2. CHOIX D’UN LANGAGE DE BASE POUR FORMALISER OR-BAC
5.2.1. Logique de premier ordre
5.2.2. Logique modale
5.2.3. Logique déontique
5.3. LANGAGE PROPOSÉ POUR OR-BAC
5.3.1. Le langage
5.3.1.1 Constantes
5.3.1.2 Variables
5.3.1.3 Formules atomiques
5.3.1.4 Fonctions
5.3.2. La sémantique
5.3.3. Les conditions de vérité
5.4. UTILISATION DU LANGAGE PROPOSÉ POUR SPÉCIFIER UNE POLITIQUE DE SÉCURITÉ
5.4.1. Spécification des règles de fonctionnement
5.4.1.1 Les sujets et les rôles
5.4.1.2 Les objets et les vues
5.4.1.3 Les actions et les activités
5.4.1.4 La hiérarchie
5.4.1.5 Le contexte
5.4.1.6 Les contraintes
5.4.2. Spécification des objectifs de sécurité
5.4.3. Spécification des règles de sécurité
CHAPITRE 6. APPLICATION D’OR-BAC AUX SICSS ET MISE EN OEUVRE
6.1. DÉMARCHE UML
6.2. SPÉCIFICATION DES CONCEPTS DE LA POLITIQUE DE SÉCURITÉ
6.2.1. Concepts structurels
6.2.2. Concepts comportementaux
6.3. EXEMPLE DE MISE EN ŒUVRE
CONCLUSION GÉNÉRALE
ANNEXE A!: MENACES POUVANT AVOIR DES CONSÉQUENCES DANS LE MONDE MÉDICAL
A1. MENACES POUVANT PORTER ATTEINTE À LA CONFIDENTIALITÉ
A2. MENACES POUVANT PORTER ATTEINTE À L’INTÉGRITÉ
A3. MENACES POUVANT PORTER ATTEINTE À LA DISPONIBILITÉ
A4. MENACES POUVANT PORTER ATTEINTE À L’AUDITABILITÉ
ANNEXE B!: ANONYMISATION DES DONNÉES DU PMSI
B1. TRAITEMENTS RÉALISÉS AU NIVEAU DES SERVICES ADMINISTRATIFS
B1.1 Constitution du fichier VID-HOSP
B1.2 Constitution du fichier ANO-HOSP et transmission au DIM
B2. TRAITEMENTS RÉALISÉS AU NIVEAU DU DIM
B2.1 Constitution du fichier HOSP-PMSI
B2.2 Constitution du fichier anonyme chaînable
B2.3 Traitements réalisés au niveau de l’ARH
ANNEXE C!: INTRODUCTION À UML
C1. UML EN RÉSUMÉ
C2. LES DIAGRAMMES UML
C2.1 Les cas d’utilisation
C2.2 Les modèles structuraux
C2.3 Les modèles comportementaux
ANNEXE D!: CONTRÔLE D’ACCÈS POUR UN CENTRE DENTAIRE
D1. ANALYSE CONCEPTUELLE
D1.1 Dictionnaire de données
D1.2 Règles de gestion
D1.3 Modèle conceptuel de communication
D1.4 Modèle conceptuel de données
D1.5 Modèle conceptuel de traitement
D2. ANALYSE LOGIQUE
D3. ANALYSE PHYSIQUE
RÉFÉRENCES BIBLIOGRAPHIQUES