Tâche: Identification des 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 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
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