Tâche: Identifier les patterns de sécurité |
|
 |
Pendant la phase initiale d'élaboration de l'architecture d'un système, l'architecte de sécurité est chargé de l'identification et de la sélection des patterns de sécurité principaux qui assurent le niveau de sécurité requis par le système. |
|
Objet
Fournir des mécanismes clés pour le développement de solutions sécurisées en effectuant un choix parmi des patterns
prédéfinis.
|
Relations
Rôles | Principal:
| Complémentaire:
| Auxiliaire:
|
Entrées | Obligatoire:
| Facultatif:
| Externe:
|
Sorties |
|
Description principale
L'objectif de cette tâche est de permettre aux architectes d'identifier les patterns de sécurité de haut niveau
appropriés devant être associés aux éléments architecturaux afin de répondre aux exigences et aux règles de sécurité.
Ces patterns sont alors détaillés à l'aide d'autres patterns plus précis, appropriés à des choix de technologies et de
plateformes spécifiques, réalisés par des tâches de conception et d'implémentation en aval.
Pour plus d'informations sur les patterns de sécurité, voir le Concept : Patterns de sécurité.
|
Etapes
Identifier les exigences de sécurité
Pendant cette étape, le Rôle :
Architecte de sécurité est responsable de la capture des exigences de sécurité de haut niveau pour un projet
et des éléments architecturaux clés pour ce projet. Ces exigences sont capturées dans l'Artefact : Document d'architecture logicielle et l'Artefact : Spécifications supplémentaires et, lorsque ces exigences
limitent considérablement l'architecture de la solution, elles doivent alors également être incluses dans l'Artefact : Architecture de référence. Le rôle de l'architecte de
sécurité est de susciter ces exigences complexes de la part des intervenants dans le projet et de les capturer dans des
instructions faciles à comprendre (intentions).
A ce stade, l'accent est mis sur l'intention car, dans de nombreux cas, lorsqu'on les interroge sur la sécurité, au
cours d'une session de définition des exigences (voir Instructions
: Ateliers de définition des demandes), la plupart des intervenants répondent que, "bien sûr, tout doit être
sécurisé" ; cela signifie-t-il pour autant que tout doit être chiffré, audité, etc ? Question à laquelle la
réponse est "oui, bien entendu". A ce stade, l'architecte de sécurité explique les implications d'une telle
décision, le coût, la complexité, puis le groupe entame une discussion significative afin de déterminer quels patterns
sont importants pour des éléments donnés dans l'architecture. Ce sont ces patterns qui expriment l'intention du système
à l'égard de la sécurité, alors que les patterns au niveau de la conception expriment les mécanismes permettant de
réaliser l'intention et, enfin, les patterns d'implémentation expriment la technologie utilisée pour réaliser
l'intention.
|
Identifier les limites de confiance
La confiance est un aspect clé de toute solution de sécurité. Le besoin de sécurité est basé sur le principe que deux
parties partagent un niveau de confiance donné et que ce niveau peut être sur une échelle allant de "totalement fiable"
(la sécurité devient donc inutile) ou "totalement indigne de confiance" (la paranoïa est alors la règle).
-
Aucune confiance ... égale confiance aveugle : Le fournisseur peut proposer un service public et n'a aucun
besoin d'avoir confiance dans le système appelant. Le système appelant peut envoyer une identité sans aucune preuve
et considérer que le fournisseur suppose l'identité lorsqu'il traite la demande. Aucune mesure n'est prise pour
empêcher des attaques déguisées.
-
Confiance basée sur la configuration du réseau : Aucune configuration logicielle n'assure la fiabilité du
réseau. Le réseau est configuré, si possible par la division en sous-réseaux protégés par des pare-feu, de sorte à
restreindre le nombre de machines susceptibles de transmettre un message au fournisseur. Le cas dégénératif ne
verrait que le système appelant prévu et le système du fournisseur sur le sous-réseau. Parfois, les réseaux privés
virtuels sont utilisés pour restreindre les systèmes appelants potentiels.
-
Confiance basée sur l'infrastructure : L'infrastructure (par exemple, le protocole de transport, si possible
MA SSL ou SSL + BA) est configurée pour identifier le système appelant afin de confirmer qu'il s'agit d'un système
digne de confiance. Lorsqu'il traite une demande, le fournisseur doit uniquement supposer l'identité de l'appelant
dans le message de services Web (SOAP).
-
Confiance basée sur les jetons : Confiance basée sur les jetons de point à point - Le message déclarant
l'identité de l'appelant contient un jeton qui a probablement été créé par un système d'appel sécurisé (par exemple
SAML, LTPA). Confiance basée sur les jetons tierce partie - Le message déclarant l'identité de l'appelant contient
un jeton qui a probablement été créé par un système tiers sécurisé KDC/STS (par exemple SAML, Kerberos).
-
Confiance basée sur le contexte de jeton : Signature couvrant le jeton et le message- Une signature
dans le message créée par un système d'appel sécurisé couvre le message et le jeton, déclarant l'identité de
l'appelant et authentifiant le système appelant. Deux jetons dans le message - Un jeton dans le message authentifie
le système appelant en tant que système sécurisé et un autre jeton identifie l'appelant. Un mécanisme doit lier ces
deux jetons entre eux et au message, comme par exemple, une signature.
-
La phase finale de la "confiance" est l'authentification. Tout jeton donnant une preuve rend inutile un
mécanisme supplémentaire dont l'objectif est d'établir la confiance.
Zones de confiance
Dans les grandes organisations, il est souvent efficace de subdiviser l'entreprise en régions administratives et
d'établir différentes zones de confiance. Divers sous-types de relations de confiance peuvent être établis entre ces
différentes zones. Voici des exemples de la manière dont deux parties peuvent établir une relation de confiance lorsque
seule l'une des deux parties a une relation avec l'utilisateur final.
-
Confiance directe - Echange de jetons : Le domaine de confiance 1 authentifie l'utilisateur final et le
domaine de confiance 2 requiert une identité ou un identificateur (propagation d'identité). Dans certains cas
(c'est-à-dire si seule la personnalisation est requise), l'authentification peut ne pas être nécessaire.
-
Confiance directe - Validation de jetons : Le domaine de confiance 1 peut créer une assertion (assertion
d'identité) en offrant sa propre preuve qu'il a authentifié l'utilisateur identifié. Le domaine de confiance 2
évalue que cette assertion provient d'un interlocuteur sécurisé (domaine de confiance 1) et l'utilise au lieu
d'authentifier l'utilisateur même
-
Services de jetons et fournisseurs de services d'identité : Parfois, des relations de confiance sont
établies entre plusieurs parties et l'authentification de l'utilisateur est séparée en un service indépendant
(fournisseur de services d'identité). Ces fournisseurs de services d'identité possèdent divers degrés de
fonctionnalité. Certains peuvent examiner la destination de la demande, déterminer si l'utilisateur a été
authentifié, savoir si le jeton en cours doit être échangé contre un second jeton et peuvent rediriger cette
demande vers les parties appropriées.
-
Confiance indirecte : Parfois, deux parties n'ont pas de relation de confiance indirecte, mais elles
partagent un tiers qu'elles accréditent toutes deux pour jouer le rôle de "courtier" dans un échange.
-
Délégation : Des combinaisons de relations de confiance directes et indirectes peuvent être établies
|
Identifier les patterns de sécurité de niveau supérieur
Les patterns de sécurité de haut niveau identifiés dans cette tâche sont les suivants. Les éléments de
l' Architecture système affectés par les exigences de sécurité (la sécurité affecte les éléments logiciels et
matériels) peuvent à présent être associés à un ou plusieurs de ces patterns (de préférence, documentés dans l'Artefact : Document d'architecture logicielle) de sorte qu'ils
puissent être précisés pendant la conception.
Identité et authentification
Un utilisateur final possède un identificateur (nom d'utilisateur) et/ou un ensemble d'identificateurs (titres, rôles,
alias) et des preuves (mot de passe) qu'il peut conserver sur un système client comme un ordinateur portable ou un PDA.
Pour s'authentifier, l'utilisateur présente l'identificateur et la preuve à une application lorsqu'il est invité à
s'identifier auprès de l'application. Si l'application valide l'identificateur et la preuve, l'authentification a
abouti et l'identité est alors une "identité authentifiée". Lorsqu'une application implémente une logique métier et
applique ses propres règles de sécurité, elle doit conserver ses données/métadonnées dans un référentiel de
données/métadonnées d'identité (système de fichiers, base de données, etc). Avec l'avènement d'Internet, l'utilisateur
final ne dispose plus seulement du code client d'application sur son propre système mais accède souvent à des
applications à partir d'un navigateur et le réseau localise l'application via un URI (identificateur de ressources
universel) indiqué par l'utilisateur final.
Connexion unique
Lorsqu'un utilisateur dispose de plusieurs applications avec différents identificateurs et preuves, il
devient parfois difficile de gérer les données et les métadonnées d'identité afin de prendre les décisions appropriées.
La connexion unique (SSO) est un terme appliqué à diverses techniques (humaines et automatisées) afin de réduire cette
complexité.
Les solutions de SSO peuvent être basées sur le client ou sur le serveur/service et elles peuvent être plus ou moins
étroitement associées à des applications. La SSO basée sur le Web désigne des solutions basées sur un navigateur et
inclut généralement des cookies. Dans une solution SSO basée sur le client et étroitement liée aux applications, il
incombe à l'utilisateur de s'enregistrer et de synchroniser les id/mots de passe multiples qui sont gérés dans les
différents référentiels d'application. Certaines solutions SSO reposent sur le "mappage d'identité", d'autres
fournissent une "propagation d'identité" ou des "assertions d'identité". De nouvelles initiatives de la solution
Federated SSO permettent à l'utilisateur de s'enregistrer auprès d'un fournisseur de services d'identité tiers qui gère
ensuite également les informations utilisateur, offrant ainsi une alternative d'association moins étroite. Dans les
entreprises, une solution SSO dorsale peut inclure l'entreprise qui joue le rôle de fournisseur de services d'identité.
La solution SSO dorsale inclut un référentiel commun pour toutes les applications et chaque application/serveur est
reconfiguré de sorte à ne pas utiliser un référentiel local. La solution SSO dorsale peut également gérer plusieurs
référentiels d'informations utilisateur et faire appel à un processus de gestion pour forcer la synchronisation des
données d'identité dans plusieurs référentiels. Dans le cas d'identités multiples, il est souvent exigé d'isoler les
applications en domaines lesquels sont souvent rattachés souvent à des domaines administratifs.
Identités numériques
Au fur et à mesure que les personnes et les entreprise sont devenues de plus en plus dépendantes de l'informatique, on
a assisté à une prolifération des informations liées à l'identité. Avec la prise de conscience du vol d'identité, les
gouvernements publient des réglementations destinées aux entreprises sur la protection des informations d'identité dont
elles ont la garde.
Solutions d'identité numérique - Il existe deux stratégies principales pour gérer les identités numériques. La première
est "centrée sur l'utilisateur" et repose sur un utilisateur participant activement à la protection de l'identité, en
s'"enregistrant" auprès de fournisseurs tiers, puis en accordant le droit d'accéder à ses données et métadonnées
d'identité à des fournisseurs en lesquels il a confiance. Liberty Alliance est un consortium qui a conduit cette
stratégie mais des efforts open source ont également été déployés avec l'initiative Higgins en partenariat avec
The Apache Foundation.
La seconde stratégie est un modèle centré sur le métier dans lequel une entreprise fournit des services de gestion des
identités à ses clients, ses partenaires et ses employés. La technologie sous-jacente est identique pour les deux
approches, mais la gouvernance et la responsabilité de la gestion des identités numériques sont différentes. Les
entreprises gèrent des volumes d'informations différents de ceux des individus et ont donc des exigences d'échelle
différentes. Les entreprises doivent également disposer de leurs propres systèmes de gestion des accès utilisateur
basés sur les rôles métier et les conditions métier en constante évolution (c'est-à-dire, vous êtes toujours "Moi-même"
mais vous pouvez ne pas toujours travailler pour l'entreprise xyz).
Autorisation
Au fur et à mesure que les personnes et les entreprise sont devenues de plus en plus dépendantes de l'informatique, les
règles d'accès aux ressources ont été codifiées. Lors de la conception d'applications, la décision des accès aux
informations peut dépendre des informations de contexte métier ou peut être sous-traitée à l'application et gérée par
un ensemble distinct de logiciels intermédiaires. La plupart des produits et des systèmes informatiques ont mis en
oeuvre un ensemble de mécanismes de "contrôle d'accès", mais chacun conserve généralement son propre mappage de noms
d'utilisateur autorisés et de noms de ressource ; ces listes sont appelées "listes de contrôle d'accès".
Protection des messages
Il existe deux types de base de protection : la protection de l'intégrité (preuve que le message n'a pas été modifié
pendant son transfert) et la confidentialité (application de la cryptographie pour assurer que seuls les destinataires
autorisés peuvent visualiser le message). Lorsque les messages sont envoyés sur un protocole, chacun d'eux peut être
signé numériquement ou chiffré ou le protocole réseau peut signer/chiffrer tout le trafic entre les deux points
d'entrée. Lorsque le protocole fournit la protection, il est souvent appelé "point à point" (d'une extrémité à l'autre
du réseau).
|
|
Propriétés
Prédécesseur |
|
Plusieurs occurrences |  |
Commandé par les événements |  |
En cours |  |
Facultatif |  |
Planifié |  |
Réitérable |  |
Considérations clés
Les patterns de sécurité identifiés pendant cette tâche sont de niveau supérieur et ne dépendent pas de technologies ni de
plateformes particulières ; chaque pattern de ce type sera, à son tour, pris en charge par des patterns spécifiques de
technologie et de plateforme. La définition de ces patterns détaillés doit être accessible à l'implémenteur, pour la
technologie et la plateforme choisies par un projet. |
Plus d'informations
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.
|
|