Les 10 pièges de la SOA : 08 – La sécurité

De par leur implication dans des projets SOA (Service Oriented Architecture), les consultants de Xebia vivent de belles réussites. Mais ils rencontrent aussi un certain nombre de projets qui peinent ou qui sont en échec.
Afin de partager ces expériences, nos collègues hollandais, Gero Vermaas, Viktor Grgic, Rik de Groot et Vincent Partington déroulent une série de billets présentant les 10 pièges de la mise en œuvre d’une architecture orientée services (SOA). Comme toujours dans ce genre de « classement », cette liste n’est ni exhaustive ni définitive.

Le troisième de ces pièges concerne la sécurité, élément critique et difficile à adresser.

Lors de la mise en œuvre d’une SOA, il est souhaitable de repenser l’architecture de sécurité (confidentialité, intégrité et disponibilité). En effet, les approches traditionnelles tiennent pour acquise la non-réutilisation des services et en tirent avantage. (Il est plus facile de sécuriser une application quand ces composants ne sont utilisés que par un nombre restreint de consommateurs). Or, la mise en œuvre d’une SOA pousse à la réutilisation de services.
C’est une des raisons pour lesquelles, dans certaines situations, l’aspect sécurité rend la mise en œuvre d’une SOA très (trop) coûteuse (de par la difficulté d’implémentation des aspects sécurité). Il y a donc souvent un compromis à trouver entre la réutilisabilité et la sécurité.

L’émergence des architectures orientées service (SOA) a introduit les problèmes de sécurité suivants :

• L’authentification des utilisateurs finaux des services est déléguée aux applications consommatrices ou au tiers d’intermédiation. Les applications qui fournissent des services peuvent aisément identifier les consommateurs directs ou le tiers d’intermédiation, mais elles n’ont pas connaissance de l’identité des utilisateurs finaux, de leurs droits, ni de leurs intentions.
• Les mesures de sécurité à appliquer dépendent de l’environnement dans lequel une application est utilisée. Malheureusement, l’environnement d’un service change avec chaque nouveau consommateur. De ce fait, la sécurisation d’un service peut rapidement devenir très coûteuse.
• Concernant la disponibilité (qui fait partie de la sécurité), même en pratiquant au mieux le couplage lâche, il existe un certain degré d’interdépendance entre les services. Si un service critique tombe, alors tous ceux qui s’appuient dessus seront également indisponibles.

C’est pourquoi, la mise en œuvre d’une SOA devrait s’accompagner d’une analyse d’impacts sur les failles de sécurités (confidentialité, intégrité des données, disponibilité) par exemple au travers de SPRINT (Simplified Process for Risk Identification).

Perspectives

Il n’existe pas de réponse unique à ces problèmes. Plusieurs technologies (La stack WS-Security, XML Encryption, XML Signatures, SAML, …) et patterns de sécurité permettent d’y répondre. Malheureusement, ces technologies sont encore jeunes et leur implémentation dans les produits composant le socle technique (Serveur d’applications, ESB, …) manque souvent de maturité.

C’est pourquoi, avant de complexifier une architecture en y introduisant toutes ces technologies, il peut être intéressant de considérer les points suivants :

• L’introduction d’un modèle de confiance dans lequel un fournisseur de services fait confiance à ses consommateurs au sein de son système (ou d’une sous partie de celui-ci). Dans ce modèle, il est de la responsabilité des consommateurs d’appliquer la plupart des mesures de sécurité (authentification, intégrité des données). Cela va à l’encontre d’un des principes généraux de la sécurité, mais le compromis est souvent acceptable.
• La propagation du contexte de l’utilisateur final dans l’ensemble des messages. Cela permet aux services ou au tiers d’intermédiation d’appliquer des mesures de traçabilité.
• Les services devraient toujours être Stateless afin de faciliter l’implémentation du fail-over et du load-balancing (Cf. « Service Stateful vs. Service Stateless » par Manuel Eveno).
• Eviter les définitions de services du type doSomething prenant un paramètre de type requête. Il est préférable de définir des services pour un but et une tâche précise. Cela rend les contrôles d’intégrité des données plus facile à mettre en œuvre et empêche l’exposition de fonctionnalités qui ne sont pas requises par les consommateurs.
• Envisager l’utilisation d’appareil hardware pour sécuriser les communications en consommateurs et fournisseurs de services. Ils ont peu d’impacts sur l’architecture des consommateurs et des services.

Traduction libre du billet « Top 10 SOA Pitfalls: #8 – Security » publié par Viktor Grgic.