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ôlesPrincipal: Complémentaire: Auxiliaire:
EntréesObligatoire: Facultatif: Externe:
  • Aucun
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).

  1. 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.
  2. 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.
  3. 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).
  4. 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).
  5. 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.
  6. 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