Architecture Technique
Nous nous sommes efforcés, dans les articles « Focus sur le rôle de l’architecte technique » et « Le rôle de l’architecte technique dans le cycle de vie d’un projet » de vous présenter notre métier que vous devriez désormais bien connaître. Ainsi, pour parvenir à réaliser ses missions, l’architecte s’appuie sur ses compétences techniques, sur son expérience dans les réseaux d’entreprise et sur un certain nombre d’indicateurs, sujet qui va nous intéresser aujourd’hui.
Via la présente nouvelle série de trois articles, nous vous proposons d’aborder une méthode facilitant la réalisation des missions d’Architecture Technique. Pour ce faire, nous présenterons dans un premier article un ensemble d’indicateurs de sécurité bien connus et sur lequel les architectes s’appuient pour faire évoluer le socle technique du SI, j’ai nommé le DICT. Nous détaillerons, dans un deuxième article, et ceci aussi clairement que possible, quelques moyens simples permettant d’améliorer le niveau de ces indicateurs. Enfin, nous terminerons cette saga avec un article présentant plusieurs exemples issus de nos différentes expériences. Un programme riche mais ô combien intéressant.
Le DICT, c’est quoi ?
L’acronyme DICT est à traduire par D pour la Disponibilité, I pour l’Intégrité, C pour la Confidentialité et T pour la Traçabilité. Il s’agit d’indicateurs de sécurité utilisés en informatique, très utiles pour évaluer les besoins de sécurité associés à une ressource/application donnée. On retrouve d’ailleurs assez régulièrement l’acronyme dans la littérature informatique puisqu’il permet très simplement de couvrir l’essentiel des grands domaines de la sécurité et permet de communiquer aisément sur le sujet à des personnes n’ayant pas forcément des profils techniques. Mais quelles définitions pouvons-nous poser sur ces termes ?
- La disponibilité : le système doit fonctionner sans faille durant les plages d’utilisation prévues et garantir l’accès aux services et ressources installés dans le temps de réponse attendu.
- L’intégrité : les données doivent être celles que l’on attend, et ne doivent pas être altérées de façon fortuite, illicite ou malveillante. En clair, les éléments considérés doivent être exacts et complets.
- La confidentialité : seules les personnes autorisées peuvent avoir accès aux informations qui leur sont destinées. Tout accès indésirable doit être empêché.
- La traçabilité (ou « preuve ») : il s’agit de la garantie que les accès et tentatives d’accès aux éléments considérés sont tracés et que ces traces sont conservées et exploitables.
L’objectif du DICT est donc simple : garantir qu’une ressource soit, selon les exigences métier, disponible, intègre et sécurisée tout en veillant à ne pas faire de sur-qualité (On considérera que plus l’indice DITC de la ressource auditée est élevé, plus les coûts d’hébergement, de sécurité … seront élevés. L’’indice permet donc également de freiner l’appétit des métiers et des équipes projet qui souhaitent disposer de ressources bien supérieures à leur besoin réel.)
La donnée est une ressource primordiale dans l’entreprise, il s’agit du cœur d’expertise de nos sociétés modernes ; les données doivent donc être accessibles et protégées et c’est le travail des architectes techniques de proposer des leviers permettant de garantir une sécurité optimale pour ces informations.
Ainsi, pour évaluer si une ressource est correctement sécurisée, il faut auditer ses niveaux de Disponibilité, d’Intégrité, de Confidentialité et de Traçabilité. L’évaluation sur une échelle de ces critères permet alors de déterminer si cette ressource est correctement protégée. L’expression du besoin attendu peut-être de deux origines :
- Interne, c’est-à-dire inhérente au métier de l’entreprise comme par exemple dans le cas de l’hébergement de données médicales (l’information étant extrêmement sensible, le niveau de sécurité de la solution qui hébergera ces données devra être élevé).
- Externe, issue des contraintes légales qui pèsent sur les biens de l’entreprise, comme en 2018 avec la mise à jour de la Loi « Informatique et Liberté » et l’ajout du chapitre sur le RGPD (Règlement Général sur la Protection des Données) qui a chamboulé les règles et usages sur les données par les organisations (et nécessitant bien souvent d’adapter les SI pour être en conformité).
Pour bien préciser le fonctionnement de l’analyse des critères DICT, il est important de dire que ce ne sont pas les architectes qui réalisent ces analyses. Même s’ils disposent des compétences techniques leur permettant de le faire, ce sont généralement les équipes cybersécurité ou les équipes de gouvernance de la donnée (de concert avec le RSSI) qui ont la responsabilité de gérer cette tâche. L’architecte aura pour mission de proposer des solutions techniques permettant de garantir que la ressource auditée répond au niveau DICT exigé par les équipes sécurité. L’architecte est le plus à même d’y répondre étant donné qu’il est garant des services applicatifs et des services d’infrastructures disponibles sur le SI.
Exemple de grilles d’analyse simple
Pour définir le niveau de DICT d’une ressource, la cyber sécurité s’appuie généralement sur ce type de grille d’analyse (qui est un exemple) :
Il existe plusieurs méthodes permettant de réaliser l’analyse de la sécurité du SI comme par exemple la méthode EBIOS (Expression des Besoins et Identification des Objectifs de Sécurité) de l’ANSSI, la méthode MEHARI (Méthode Harmonisée d’Analyse des Risques)ou encore la méthode MARION (Méthode d’Analyse de Risques Informatiques Optimisée par Niveau) du CLUSIF, qui proposent des approches différentes de l’analyse de la sécurité mais utilisent cette notion de DICT. Ces méthodes sont bien évidemment plus complexes, plus exhaustives que les simples grilles que nous vous présentons aujourd’hui. Cependant, pour une première évaluation rapide des besoins (et surtout dans un objectif de compréhension de la démarche), les grilles présentées ci-dessus sont un bon début (à adapter aux critères de chacun bien évidemment si vous souhaitez vous en servir).
Que retenir de ce premier article
Vous êtes maintenant en mesure de comprendre ce que veut dire l’acronyme DICT, vous savez qui est en charge de réaliser l’analyse DICT d’une application ou d’un service d’infrastructure et êtes en mesure de situer où est le rôle de l’architecte dans cette démarche. Dans ce premier article, nous avons abordé le Quoi. Dans le prochain article de la série nous aborderons le Comment via la présentation de quelques moyens simples permettant d’améliorer les niveaux de disponibilité, d’intégrité, de confidentialité et de traçabilité dans un système d’information.
Si toutefois vous souhaitez avoir plus de détails sur les subtilités des différentes méthodes d’analyse sécurité, n’hésitez pas à contacter notre cabinet de conseil Pramana. Nous tacherons de vous accompagner tout au long de votre projet, qu’il soit orienté cloud via nos architectes certifiés AWS et AZURE, ou sur site via nos architectes forts de leurs expériences réussies dans le domaine.
Antoine Gaydon
Consultant en Architecture Technique
Pramana
