Les différentes approches d’architectures de sécurité

A l'heure où le piratage et les failles sont pratiquement monnaie courante, préserver un modèle de sécurité robuste et les exigences de conformité et de gouvernance associées devient vital. Selon les responsables de sécurité, le principal problème de la discipline tient à la tendance qu'affichent les entreprises à l'ajouter plutôt qu'à l'intégrer dès la conception. 

Une conformité et une sécurité descendantes reposent sur l'hypothèse que les besoins de sécurité et de gouvernance des applications peuvent se déterminer à partir de l'infrastructure métier dans laquelle elles sont utilisées.  Evidemment, rien n'est dit sur les données en soi qui expliciterait le degré de sécurisation de celles-ci ou le mode de suivi de leurs modifications. Le défi consiste à traduire des entrées métier utiles en modèle de gouvernance et de sécurité.

Une approche consiste à puiser dans les résultats qu'obtiennent les architectures d'entreprise pour mettre en correspondance les besoins de gouvernance et de sécurité avec les applications. Cette capacité est intégrée à toutes les infrastructures actuellement répandues. Et chacun des modèles met à disposition des témoignages de réussite utilisateur.  Une liaison d’architectures d'entreprise signifie qu'une modélisation permet de définir des exigences de sécurité que des produits de gouvernance sont en mesure de concrétiser grâce à leur prise en charge du modèle utilisé. Il s'agit là de la plus « descendante » de toutes les approches, même si elle reste pratiquement impossible à appliquer en l'absence d'une pleine implication dans l’architecture.

Une approche légèrement différente peut s'avérer plus facile à adopter. L'infrastructure d'architecture de sécurité ouverte est un modèle probleme-driven, qui présuppose qu'une entreprise dispose d'un service informatique, d'applications et de moteurs métier qui engendrent des problèmes de sécurité. A l'instar d'autres approches émergentes de fournisseurs tels qu'IBM et Microsoft, celle-ci vise à élaborer une superstructure qui vient coiffer et harmoniser en son sein les applications, services et pratiques en vigueur. En se focalisant sur le modèle de sécurité et sur des pratiques d'harmonisation auxquelles se conformer, l'entreprise peut inclure des éléments informatiques disparates sans reprendre l’architecture depuis le début.

Le défi de cette approche tient à ce qu'elle suppose d'identifier préalablement les problèmes auxquels l'entreprise est confrontée. Dans un véritable modèle piloté par l’architecture, la gouvernance et ka sécurité sont issues de pratiques métiers ; une approche qui réduit le risque de négliger certaines particularités. Or les approches « probleme-driven » ne peuvent gérer aucun risque tant que celui-ci n'est pas reconnu. Créer la superstructure nécessaire à ces approches peut, en outre, constituer un défi du fait de la grande variété d'outils techniques susceptibles d'être impliqués, particulièrement au niveau du middleware.

Ces modèles descendants peuvent constituer une option convaincante dans des situations où sécurité et gouvernance sont complexifiées par l'intégration des applications à celles des clients et des fournisseurs. L'harmonisation des pratiques à l'échelle de plusieurs entreprises (même en présupposant que chacune dispose de telles pratiques) est une tâche difficile ; tâche dont les modèles problem-driven peuvent se dispenser. Pourtant, les défis de mise en œuvre peuvent s'avérer complexes du fait du besoin d'une intégration interentreprise.

Les approches « montantes » s'attaquent d'abord au problème d'une mise en oeuvre unifiée simple. Ensuite, elles supposent qu'une approche flexible peut être adaptée à des besoins de sécurité et de gouvernance tels qu'ils sont exposés. Certaines approches vont également faire appliquer une prise en charge dernier cri de la sécurité et de la gouvernance, suffisante pour couvrir l'exposition de nombreuses entreprises, si ce n'est toutes.

L'approche de ce type la plus agressive (et donc la plus exhaustive) repose sur la technologie ESB (Enterprise Service Buses). Les ESB lient applications et composants dans des flux de processus métier via l'application d'une discipline en matière d'interfaces et de règles métier. Ainsi, les ESB fournissent une architecture très robuste au sein de laquelle des normes de sécurité et de conformité peuvent être mises en œuvre.

En apparence, ni le modèle de sécurité descendant, ni le modèle ascendant ne semblent faciles à appliquer à un environnement informatique existant. Côté approche descendante, il faut savoir si une infrastructure est en place et si les applications courantes utilisent un nombre limité d'outils de workflow et d'interface à des fins de connexion. Côté approche montante, toute la question tient à la facilité d'adoption de la technologie ESB, et donc vraisemblablement de l'utilisation d'un environnement SOA par les applications en place.

Cette dernière question est la plus importante. Si les applications en place reposent à la fois sur des services et une technologie SOA, un modèle montant est envisageable, voire plus simple à adopter. Même si des équipes souhaitent adopter une approche descendante, l'homogénéité des interfaces facilitera l'élaboration d'une infrastructure de sécurité et de gouvernance.

Si les applications courantes sont plutôt de type RESTful, il sera probablement difficile de basculer vers une approche ESB ; un modèle descendant sera plus adapté. Dans ce cas, les entreprises devront sélectionner une solution d’architecture descendante classique ou problem-driven selon qu’elle a ou non formalisé ses pratiques.

Au niveau architecture, la prise en charge de la sécurité et de la gouvernance est régie par un modèle qui contrôle les flux d'informations ou l'accès aux ressources. Les infrastructures SOA s'adaptent au premier, tandis que les infrastructures Web et RESTful prennent en charge le second. Une sécurité d'architecture reposant sur l'un ou l'autre de ces principes sera plus simple. Toutefois, si l'entreprise ne se prépare pas à anticiper de futures orientations avec les microservices, le Cloud computing, les conteneurs et le Web, il sera probablement difficile de trancher.

Pour cette raison, et pour la majorité des utilisateurs, la « meilleure » approche sera sans doute le modèle problem-driven, avec pour attente que la tâche à venir se concentre sur le contrôle des flux d'informations et l'accès aux ressources.

Actuellement, si les architectures de sécurité et de conformité abordent ces points, elles ne reflètent aucune norme unique en termes de mise en œuvre. En d'autres termes, les utilisateurs devront élaborer ce chaînon manquant à leur propre initiative. Les principaux éditeurs de logiciels (IBM, Microsoft et Oracle) sont tous en mesure de livrer les outils nécessaires à cette fin. Toutefois, leur efficacité quant à l'optimisation pratique desdits outils varie d'un compte à l'autre. Mais mieux vaut commencer dès maintenant, car les choses n'iront pas en se simplifiant.