Introduction
La "sécurité" est généralement perçue comme une discipline complexe et abrutissante. Un "pattern" (ou modèle) est
un terme que la plupart des gens pensent comprendre intuitivement car la reconnaissance et la généralisation des
modèles perçus font naturellement partie de l'éducation humaine. Pour cet exercice, les définitions suivantes sont
utilisées en tant que définitions de travail :
La sécurité désigne "La condition d'un système résultant de l'établissement et du maintien de
mesures pour protéger le système". [1]
"Un pattern est l'abstraction d'une forme concrète qui se répète dans des contextes non
arbitraires spécifiques". [2]
La tentative d'associer ces deux termes, "sécurité" et "patterns", peut donc sembler paradoxale. La production de
patterns de sécurité a été tentée à plusieurs reprises (voir l'annexe A). Dans le présent document, nous nous
sommes efforcés de collecter et de codifier le matériel ayant été rassemblé pendant plusieurs années par divers
spécialistes en sécurité, à partir de différents suivis client et de produire une ossature pour les patterns de
sécurité IBM. La définition de travail des "patterns de sécurité" dans le contexte du présent document est la suivante
:
Abstraction des conditions résultant de l'établissement et du maintien de mesures récurrentes, utilisées pour
protéger le système.
La communauté de développement de logiciels déploie actuellement des efforts pour établir [3] une méthodologie pour le développement de patterns.
Toute discipline scientifique ou d'ingénierie est basée sur une terminologie commune permettant d'exprimer ses
concepts et sur un langage permettant de relier ces derniers entre eux. L'objectif des patterns, au sein de la
communauté de développement de logiciels, est de créer une base de documentation technique afin d'aider les
développeurs à résoudre les incidents récurrents, rencontrés tout au long du processus de développement de
logiciels. Les patterns aident à créer un langage partagé pour communiquer les connaissances et l'expérience sur
ces incidents et leurs solutions. La codification formelle de ces solutions et de leurs relations permet de
capturer la base de connaissances qui détermine la compréhension d'architectures de qualité répondant aux exigences
de leurs utilisateurs. L'élaboration d'un langage de pattern commun pour acheminer les structures et les mécanismes
des architectures permet de raisonner intelligiblement sur ces dernières. L'accent initial n'est pas tant mis sur
la technologie que sur la création d'une culture susceptible de documenter et de prendre en charge une architecture
et une conception d'ingénierie saines. [4]
Le point fondamental de confusion est que les patterns, comme la beauté, semblent résider dans le regard de
l'observateur. Par conséquent, si vous réunissez cinq experts en sécurité, ils définiront des patterns spécifiques
de leur domaine d'intérêt.
C'est la raison pour laquelle il est utile de faire ici une digression sur les "rôles" afin d'aider à grouper les
patterns selon des intérêts communs.
Qui est le premier ?
Dans le monde du développement de logiciels, certains conçoivent des objets, d'autres créent des images et rédigent des
documents, d'autres écrivent du code et d'autres enfin rassemblent tous ces éléments et fournissent des systèmes
informatiques.
Chaque organisation possède généralement une façon propre de définir les tâches, mais il existe des rôles archétypes.
Un archétype est le modèle idéalisé d'une personne, d'un objet ou d'un concept à partir duquel des instances
similaires sont dérivées, copiées, modélisées ou générées. En psychologie, un archétype est le modèle d'une
personne, d'une personnalité ou d'un comportement. [5]
Dans toute organisation de moyenne à grande échelle, les tâches sont affectées à différentes personnes, en fonction de
leurs responsabilités dans l'organisation. En général, les analystes métier et les applications métier doivent
protéger les actifs en informations de l'entreprise. Ils pilotent la création des exigences des applications métier
pour la sécurité.
Archétype 1 - Analyste métier
Les organisations devant se conformer à des exigences législatives ou réglementaires prévoient parfois un ensemble
spécifique de tâches au niveau "C" afin de surveiller et de mettre en oeuvre ces réglementations. Le responsable
de la sécurité (CSO - Chief Security Officer) et le responsable de la confidentialité (CPO - Chief Privacy Officer)
collaborent généralement avec les analystes métier afin de compiler un ensemble d'instructions et d'exigences propres à
l'entreprise, à savoir les bases des pratiques métier d'excellence.
Archétype 2 - Responsable de la sécurité (de la confidentialité)
La plupart des organisations, quelle que soit leur taille, possèdent aujourd'hui un pare-feu. Les utilisateurs
individuels établissent, à leur domicile, un pare-feu pour leur réseau domestique. Ces dispositifs doivent être
configurés et gérés. Certains sont simples, d'autres sont plus complexes.
Archétype 3 - Responsable de la sécurité du réseau
Lorsqu'il s'agit de comprendre et de sélectionner un type de mécanisme de sécurité afin de répondre aux exigences
de l'entreprise, plusieurs personnes travaillent de concert pour mettre en oeuvre la sécurité.
Archétype 4 - Architecte de sécurité
Security Developer, Security Deployer, Security Policy Author, Security Policy Administrator, Security System
Adminstrator
Observation des patterns par rôle
L'objectif du présent document et du module de diapositives associé est de fournir une ossature qui permet d'identifier
et d'illustrer des patterns de sécurité communs existants, au sein de la communauté des analystes métier, clients
d'IBM. La tâche de l'effort d'élaboration de patterns e-business consiste à regrouper le volume
d'informations en une abstraction assez générale pour pouvoir être utilisée par des spécialistes dans d'autres domaines
que la sécurité tout en conservant un contexte suffisant pour fournir des bases concrètes à la communauté des experts
en sécurité.
IBM est un microcosme de l'industrie du développement de logiciels car cette entreprise représente à la fois le
développement de produits et le développement de services d'application métier ainsi que les produits intermédiaires
pour la gestion et le déploiement d'applications.
Il existe plusieurs méthodologies permettant de concevoir et de développer des applications sécurisées (c'est-à-dire,
MASS, Open Group, JAAS) mais un grand nombre est destiné aux professionnels chevronnés en sécurité ayant une parfaite
compréhension de la technologie. Ainsi, un groupe de patterns peut être "patterns d'architecture de sécurité". Des
architectures détaillées sont nécessaires pour développer la technologie fournissant des solutions de sécurité et ces
architectures sont mentionnées par les patterns le cas échéant, mais le présent document n'est pas destiné à documenter
tous les patterns d'architecture de sécurité.
Qu'est-ce que la sécurité ?
Le groupe de travail IETF est une organisation qui a joué un rôle fondamental dans le développement d'Internet tel que
nous le connaissons aujourd'hui. En 2000, le groupe de travail IETF a établi un glossaire relatif à la sécurité qui
contient la plupart des concepts fondamentaux de la sécurité informatique. Des améliorations sont apportées, des
technologies et des mécanismes apparaissent et disparaissent mais les définitions élémentaires demeurent.
Les composants les plus couramment utilisés aujourd'hui dans le domaine de la sécurité sont les suivants :
identification et authentification, autorisation, assurance, audit, protection des messages, confidentialité,
intégrité. Plutôt que de fournir uniquement des patterns pour chaque mécanisme de sécurité, le présent livre blanc
a examiné l'ensemble des mécanismes de sécurité afin d'en identifier les caractéristiques communes. Ce livre blanc
met l'accent sur l'identification d'un "pattern de solution de sécurité". Ces éléments communs ont été créés à
partir de l'observation d'un ensemble détaillé d'éléments de pattern individuels pour chaque mécanisme de sécurité
(c'est-à-dire le mécanisme d'authentification comporte les éléments nom d'utilisateur, mot de passe, Kerberos,
indicateur clé de performances), puis en faisant abstraction de ces éléments communs entre l'authentification,
l'autorisation, l'assurance, etc.
La recherche d'éléments communs dans tous les patterns de sécurité a entraîné l'identification des trois
sous-éléments de pattern présents dans un format donné dans tout type de solution de sécurité :
-
à une étape donnée de l'exécution du logiciel, le mécanisme de sécurité doit être appelé (c'est-à-dire à
un "point de contrôle")
-
il existe généralement un type de méta-informations important pour l'exécution du point 1 et désigné par
l'expression "propriétés d'accès et d'accréditation au système"
-
une tâche est liée à l'initialisation et à la maintenance permanente du mécanisme de sécurité ; ce type de tâche
est désigné par l'expression "tâches de gestion de la sécurité/d'enchaînement des activités".
L'exemple d'"identification" démontre comment chaque mécanisme de sécurité peut être mappé sur ces trois
sous-éléments. Extrait du glossaire du groupe de travail IETF :
identification - (I) Action ou processus présentant un identificateur à un système afin que le
système puisse reconnaître une entité système et la distinguer d'autres entités (voir :
authentification).
Distinguer une personne d'une autre lors de l'appel d'une application est un pattern auquel est confrontée toute
entreprise. Les stratégies permettant de résoudre l'incident métier varient en fonction du nombre et de la diversité
des éléments impliqués dans l'application et dans son environnement de déploiement. Certaines entreprises laissent
la décision de la "désignation" à chaque application ou à un groupe d'applications dans un secteur
d'activités. Certaines entreprises sont limitées par les logiciels de leurs centres de données. D'autres ont
étroitement lié l'environnement de déploiement d'application à un ensemble strict de mécanismes.
Il existe néanmoins un point où un "identificateur" est présenté à une application et cela est considéré comme un
pattern de "point de contrôle de sécurité", pour identification. La quantité et le type des informations requises
varient aussi considérablement. Un identificateur peut être le nom d'une personne réelle
(c'est-à-dire Maryann Hondo) ou un pseudonyme (par exemple, mhondo). L'identificateur peut être un
identificateur unique universel (UUID) ou il peut être unique au sein d'un espace de nom qualifié (c'est-à-dire mhondo@us.ibm.com).
Caractéristiques d'un pattern de sécurité
-
Définition d'un ou plusieurs points de contrôle (identité, authentification, autorisation, mise en application de
règles, audit, conformité, protection des messages)
-
Définition de propriétés de protection de système (contraintes de configuration ; règles d'accès et
d'accréditation)
-
Définition de tâches de gestion (application des accès, synchronisation des registres/référentiels, gouvernance,
surveillance)
-
RFC 2828 Internet Security Glossary May 2000
-
Understanding and Using Patterns in Software Development, Dirk Riehle et Heinz Zullighoven.
-
Design Patterns: Elements of Reusable Object-Oriented Software, Erich Gamma, Richard Helm, Ralph Johnson
et John Vlissides.
-
Patterns and Software: Essential Concepts and Terminology, Brad Appleton : http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html#Origins
-
Wikipedia : http://en.wikipedia.org/wiki/Archetype
|