Audit d’architecture

Méthodologies

L’auditeur intervenant sur un audit d’architecture accompagne le client sur l’ensemble des briques qui constituent l’architecture d’un système d’information moderne : système, réseau, base de données, application et développement.
Lorsqu’il conduit un audit d’architecture, l’analyste doit avoir une compréhension précise de l’environnement du client.

L’audit commence généralement par une phase de prise d’informations, via la documentation existante et la rencontre des équipes techniques et projets lors de réunions techniques. Cette phase peut être ouverte à d’autres contacts utiles, comme par exemple une rencontre avec le comité de direction pour s’informer des objectifs stratégiques. Au terme de cette étape, l’auditeur doit avoir en premier lieu avoir une bonne connaissance du métier du client, de ses contraintes et de ses objectifs. Il s’agit de bien comprendre les enjeux du projet et d’identifier les points sensibles.

Ensuite, l’auditeur doit identifier de manière exhaustive les composants de l’architecture, leurs relations et interactions, ainsi que les flux de données et les entrées-sorties. Ce travail de préparation et de documentation approfondi permet d’aborder dans de bonnes conditions la phase d’audit et de conseil. L’auditeur est ainsi capable de déterminer si l’architecture en place peut rendre tout le service attendu de manière optimale, avec la garantie d’un bon niveau de sécurité.

Livrables

L’auditeur rédige un rapport d’audit qui énumère les points positifs et les axes d’amélioration constatés. Selon le besoin, il peut être amené à détailler des propositions techniques : schéma d’architecture, diagramme fonctionnels ou de flux, cartographie, spécifications, cahier des charges, etc.

Cas d'études

Déploiement sécurisé d'une architecture logicielle

Nous sommes mandatés pour faire le bilan d’un projet d’implémentation d’un ERP au sein d’un contexte industriel (infrastructure SCADA). Le logiciel a été développé par les équipes internes de l’entreprise. Les équipes projets ont des doutes sur la meilleure manière de déployer la solution au sein d’une infrastructure critique, qui ne peut tolérer aucune perturbation. L’application peut être installée sur une machine unique, posée à côté d’équipements critiques. À ce titre, elle présente de potentiels risques de sécurité.

Après avoir pris connaissance du contexte, nous étudions la documentation du projet. Celle-ci décrit de manière détaillée les différents composants logiciels et les flux fonctionnels.
En revanche, seuls des échanges avec les développeurs nous permettent de traduire ces éléments en des termes techniques, notamment au niveau des flux réseau. Nous notons qu’une certaine flexibilité existe au niveau de la configuration des éléments, grâce à une architecture logicielle modulaire.

Nous vérifions dans un premier temps les flux d’entrée-sortie et l’ordonnancement des traitements applicatifs afin de s’assurer de l’absence de vulnérabilité fonctionnelle. Nous notons que le projet présente une surface d’attaque assez importante, car il s’agit d’une interface Web accompagnée de plusieurs services réseau. De plus, l’application nécessite d’accéder à des informations issues de sondes industrielles en milieu industriel, de nature très sensible.

Notre étude permet de proposer une solution sécurisée. L’architecture prévoit la mise en place d’un sas réseau (VLAN) au sein des usines, afin de confiner les serveurs du projet. Seules les données émises par les sondes sont autorisées dans le sens entrant, alors que les serveurs ne peuvent pas initier de requête vers les équipements industriels.
Ce sas héberge ainsi exclusivement la brique logicielle chargée de la collecte des données. Le reste de l’architecture est également modulé du côté de l’infrastructure centrale : pour des raisons de continuité de service, la base de données est hébergée sur la base de données mutualisée, elle-même hébergée dans une zone sécurisée.
Enfin, le serveur dédié à la fourniture des accès Web se déploie dans une zone démilitarisée à destination des utilisateurs finaux.

Préparation du cahier des charges d'un logiciel

Nous intervenons à la demande de notre client pour étudier l’architecture d’un projet de logiciel métier, dans le cadre de la rédaction en cours d’un cahier des charges de développement. Le client a déjà effectué certains choix technologiques et défini de manière précise son besoin, mais il demande notre assistance pour le traduire en terme techniques. Il faut noter que les aspects liés à la sécurité sont essentielles vis-à-vis du métier (données médicales confidentielles) et que le coût de la solution doit rester modéré. En revanche, une perte de disponibilité, même de quelques jours, reste tolérable.

Afin de limiter les coûts, nous préconisons de ne pas redonder les services, mais de s’assurer de l’intégration du projet dans un processus de sauvegarde fréquent. D’autre part, nous recommandons autant que possible de réutiliser des composants logiciels du marché pour le développement. Par exemple, nous préconisons l’utilisation d’un CMS pour l’interface Web utilisateur, ce qui présente également un avantage au niveau de sécurité (code audité et maintenu par des tiers, spécialisés).

Enfin, nous traduisons le besoin dans un schéma d’architecture fonctionnel, avec un diagramme des flux. Celui-ci est conçu afin que l’intégration dans le système d’information existant soit optimale : prise en compte de l’architecture réseau, de la politique de filtrage (sens et nature des flux),
Nous choisissons aussi de nous appuyer autant que possible sur les technologies déjà existantes et supportées au sein de l’entreprise (langages de programmation, librairies logicielles, systèmes d’exploitation, etc), afin de faciliter le support et la maintenance des correctifs de sécurité par les équipes techniques.

Ces éléments sont finalement intégrés au cahier des charges et envoyés aux répondants.

Déménagement d'un cœur de réseau

L’entreprise nous contacte dans le cadre du déménagement de son datacenter. Elle souhaite en profiter pour réaliser une refonte de son réseau et de son infrastructure système. Le client souhaite d’abord virtualiser la quasi-totalité de ses serveurs sur VMWare. Elle nous demande de trancher entre plusieurs propositions techniques évaluées par ses équipes techniques.

Compte tenu d’impératifs de sécurité très importants, nous préconisons de préserver la segmentation physique déjà en place en déployant des serveurs VMWare ESX par zone, plutôt que de se contenter d’une segmentation logique avec un seul serveur de virtualisation.

Nous intervenons également sur diverses problématiques : choix et redondance des équipements de routage et de commutation, maintiens ou abandons de services (Spanning Tree, VTP), orientation des flux, mise en place de ruptures technologiques, etc.

Enfin, nous travaillons à optimiser l’implémentation du protocole de routage du lien d’interconnexion, en préparant les annonces et les préfixes BGP adéquats.