J. Simoncello

Setting up a server to publish Archimate models

2023-10-26T00:00:00Z

Setting up a server to publish Archimate models

I have just finished a project where I had to set up a publishing service for Archimate models in my enterprise. I'd like to share some thoughts about it.
The solution is designed to be as simple and stupid as possible but the "the devil is in the details" (not sure this phrases means anything in english...)

What it should do

The models should either be hosted in our internal gitlab instance or directly on the publishing server
The models should be exported daily (and automatically of course) to html sites with standard Archi export features

* the publishing server is the smallest VM I could ask for (1vCpu/2Gb Memory/40 Gb Drive, and it is still an overkill)
* I use Linux Server with just Apache Web server and Archi.
* Archi runs on this server in headless mode
* Note there is no need to update the website as soon as a commit is pushed to a model, refreshing each website daily is more than enough.

Some models contains "hidden" views and anybody should not be able to access them

* Archi offers a view property (` _hide_from_export` ) that hides the view in the menu of the exported websites, but I had to go further and effectively delete the html files and images from the website. This way, someone reading the html source code cannot get the view url. This is all done in bash script.

"Hidden" views should be accessible to some users

* Each models is published twice : one website without hidden views and one website with the hidden views.
* The private website is protected by Shibboleth. Through SAMLv2, user must be authenticated to our LDAP enterprise server and be granted a dedicated role, prior to get access to this site.

All in all, it does not seem a lot to do but it took around 40 days to setup everything including v2 (see below), write documentation, follow various processes. Yes we are a 100% agile company... and a 200% slow enterprise too.

Some more features...

There are a lot of "hidden" things and features in these 40 days :

Tools to help support in administering and monitoring the solutions I have to say that the server is not operated by our standard IT operator (long story shorts : It would have taken 4-5 additional months, I could not afford it), so I added tools to purge logs, send email on disk 80% full, and so on.
Minor features like adding

* the date/time the website was generated,
* a light version of the menu so that it loads faster on Edge browser.
* a welcome portal page,

Security, I may be a little paranoid here but as an architect I feel my own applications should be commendable on these aspects :

* Tools that check nobody is tampering with the published models and send alerts
* a dedicated firewall to further protect the server

Migrate the legacy website (generated by Mega Hopex) without destroying hyperlinks that were done long ago to the legacy diagrams.
(a lot of) documentation as I am leaving my job, I had to write everything down for a potential successor.
For this reason, I have anticipated the development of the V2 version which provides

* Archistory : a jArchi script which generates a visual diff between snapshots of a model, so that everyone can easily see what have been changed in views between two dates.
* Although my bash script which delete hidden views works like a charm, I have gone one step further and have written a jArchi Script that before export, deletes the view and every concept in the model that only appears in hidden views.
* A REST API which can be used by other applications (or end-users) to query the published models
* the API is coded in Python, with Flask and Flassger (for the swagger generation)
* the data are read from OEF files generated daily by Archi.
* the API offers few endpoints to get Single Point of Trust for any given business object, provides permalink to view with human readable parameters (not internal id but name of the application and the type of view you want to see)

What I have learned

Using jArchi on the server side adds a lot of value. In my use cases :

* it is a lot easier to purge the models from the views I want to hide
* It allows to automate Archistory process (get the latest model, compare it to previous one, generate the diff pages ...)
* Disclosure : I have not deployed it on my production server because Archimatetool is still not referenced in our SAP environnement so that we can not support Archi development.

There is a lot of data in your models, plan time to implement mechanisms so that everyone may not access or alter sensitive information.
Speak with the others architects, incite them to share their models, it does not matter if the models are hosted on git or not, but it matters that they are not forgotten on some local drives. (Remind them to tag the sensitive views !)

Model-Based Architecture Documentation

2023-10-05T00:00:00Z

Model-Based Architecture Documentation

Quelques réflexions supplémentaires qui font suite au long article où j'avais expliqué l'intérêt qu'il y avait à modéliser vos architectes. Il y aura quelques répétitions, mais je voudrais ici aller un cran plus loin, en présentant l'intérêt à baser toute la documentation architecture sur un modèle. J'appelle cela le "Model-Based Architecture Documentation" MBAD donc, en partie pour faire écho à MBSE (Model-Based Systems Engineering) et en partie pour faire des jeux de mots autour de Michaël Jackson.

/pourquoi-modeliser

Je le redis, le modèle est une base de données. Le schéma (ou la vue, les 2 termes sont ici équivalents) est une requête sur cette base de données.
Le fait de modéliser votre documentation architecture (DA dans la suite de l'article) va structurer l'information tout comme une base de données est une structure de stockage beaucoup plus formalisée qu'un tableur.

L'effort de modélisation (car il y a un effort à fournir ne nous le cachons pas) va permettre ensuite de :

requêter cette documentation
valider les données
garantir la cohérence des informations et de leurs mises-à-jour.
éviter de laisser les marges d'interprétation et de flou induites par une documentation purement rédigée.

Une prestation qui produit un livrables sous forme de modèle est bien plus facile à valider que s'il s'agit de documents de plusieurs dizaines de pages.

Je suis convaincu que pour la DA, il faut vraiment abandonner le paradigme "papier" bêtement traduit en multiples fichiers Word (ou, si les schémas sont modélisés, ils sont conservés sous leur forme la moins riche, une copie d'écran dans le document). Le recul de quelques décennies est maintenant suffisant pour voir que cela ne fonctionne quand même pas très bien non ?

La difficulté est qu'il n'y a pas de standard de ce qu'il faut modéliser (et qu'il ne faudrait pas se retrouver à TOUT modéliser) mais je ne suis même pas convaincu qu'un tel standard soit souhaitable. Je préconise qu'au sein de chaque entreprise/organisation, de prendre pour base l'existant de la DA et, par itération, de modéliser progressivement ce contenu. Cette démarche progressive doit se faire en se demandant à chaque étape, si chaque information a réellement sa place dans la DA et si ce n'est pas le cas de l'externaliser en gardant sa forme non structurée.

Je ne peux pas lister tout ce qui serait à modéliser, cela dépend du contexte de chaque organisation, je voudrais juste illustrer par un exemple concret, très orienté SI qui doit se rencontrer dans à peu près toutes les entreprises.

Ensuite, prenez comme base les sollicitations qui vous parviennent, celles qui sont les plus fréquentes ou les plus ardues à traiter, et interrogez-vous si un effort raisonnable de modélisation permettrait de mieux y répondre (ou d'y répondre tout court).

Dans mon cas, on me demandait régulièrement si le cadre technique du SI servait à quelque chose et s'il était respecté. Je n'ai jamais pu y répondre autrement qu'au feeling mais voilà comment je procéderais dans une approche MBAD

D'abord je modéliserais les grands principes (principles) et règles (requirements) de ce cadre technique du SI :

Modélisation des grands principes et pré-requis du SI

Puis pour chaque solution technique, je dois indiquer si ces règles sont ou non respectées :

on modélise le fait que l'application A respecte tous les principes et prérequis sauf R03

L'inconvénient de cette approche est qu'elle créé une ambiguité : l'absence de relation entre A et R03 est-elle un oubli ou volontaire ?
Essayons de faire plus explicite. Archimate n'a pas de relation "négative", j'utilise ici une convention en indiquant [!] pour montrer que la relation signifie "n'est pas réalisée"

En explicitant toutes les relations

C'est mieux mais si on a 150 prérequis, le schéma risque d'être un peu long et chargé. On peut ainsi proposer de factoriser le fait que "tous les prérequis sont satisfaits sauf R03" en indiquant la relation entre A et le principe 'Respecter le référentiel technique'

En allégeant le schéma

C'est une illustration, inutile de dire que cet effort de modélisation doit être mené sur le long-terme pour documenter ainsi tout un SI.

On peut aussi imaginer d'autres questions auxquelles un modèle peut répondre, voici quelques exemples issus de mon expérience personnelle :

Est-ce que tous mes flux inter-applicatifs utilisent un protocole sécurisé ?
Quelles solutions de mon SI embarquent une mécanique d'audit-trail ?
Quelles chaines applicatives ont mis en place leur propre gestion de logs ?
Chez quel fournisseur SaaS ai-je des données de niveau restreint ?
Quelles applications prévues par les architectes d'entreprise n'ont pas été encore implémentées ?

Pourquoi bâtir des modèles et non simplement dessiner des schémas ?

2023-10-04T00:00:00Z

Pourquoi bâtir des modèles et non simplement dessiner des schémas ?

L'architecte SI comme son homologue dans le monde physique de la construction doit produire des plans. Je n'irais pas jusqu'à dire qu'il doit passer tout son temps à cela (il faut se laisser un peu de temps pour de la veille, monter des prototypes, discuter avec d'autres architectes) mais une bonne partie de sa charge de travail doit tourner autour de ces schémas d'architecture.

Et quitte à y passer du temps autant que ce soit le plus efficace possible.

Le schéma peut-être une fin en soi d'ailleurs une fin qui a plusieurs niveaux de finition, il doit permettre

de communiquer sur le fonctionnement, l'intérêt de la solution décrite. Pour cela il doit donc être

* accessible sans une formation particulière, d'où l'intérêt d'un formalisme léger et relativement intuitif
* homogène dans l'entreprise concernée pour éviter de se réinterroger sur la signification de chaque composant à chaque solution abordée

de capitaliser les informations pertinentes de manière synthétique.

Etablir un schéma peut faire peur. Pourquoi ? Mon hypothèse est qu'il est beaucoup plus difficile de tricher lorsqu'on réalise un schéma que quand rédige un texte : dans ce dernier cas, on peut utiliser le conditionnel, adopter des tournures de phrase un peu floue, recourir à des termes ambiguës. Sur un schéma, c'est plus difficile : vos flèches doivent bien partir de quelque part et arriver à un autre endroit, vos boites doivent bien avoir un nom ! Bien sûr, il reste toujours possible de contourner les difficultés en nommant les objets de manière vague en adoptant des vues tellement haut-niveau qu'on ne distingue plus le sol mais on s'aperçoit alors vite que le roi est nu.

Théoriquement n'importe quel outil de dessin peut être employé pour réaliser des schémas (même PowerPoint mais je ne le souhaite à personne) mais c'est oublié qu'au-delà du schéma il y a le modèle. C'est aussi oublier le fait que si vous faites construire votre maison et que l'architecte vous présente des plans sous PowerPoint ou Paint, vous éprouveriez sans doute une légitime appréhension.

Le schéma est un visuel, le modèle est une base de données contenant des concepts liés entre eux.

Tout ce qui n'est pas dans le dossier Views constitue le modèle.

Le modèle est la bibliothèque de concepts que vous trouverez sous Archi dans la fenêtre nommée de manière très pertinente… "Models". Le schéma (ou la vue) est ce que vous trouvez dans la fenêtre principale.

Une vue peut-être considérée comme une projection selon un axe particulier du modèle. Les objets apparaissant dans la vue sont des instanciations des concepts présents dans le modèle.

C'est de la constitution de ce modèle que va découler la vraie plus-value de la méo et une justification majeure du travail rigoureux, constant, exhaustif de réalisation de ces schémas.

Le respect d'un formalisme/langage de modélisation est aussi un exercice qui oblige à se poser des questions sur la nature des concepts représentés et de leurs relations. C'est tout à fait différent d'un schéma « libre » rapidement ébauché sur PowerPoint où l'on choisit des formes/couleurs/flèches au gré des envies : on obtient ainsi (parfois) quelque chose qui peut-être visuellement satisfaisant mais dont la durée de vie est limitée et qu'on ne pourra jamais réellement exploiter.

Un modèle se doit de

respecter le principe DRY (Do not Repeat Yourself), une information n'est saisie qu'une fois peut importe le nombre de fois où elle est employée.
être dynamique, lorsqu'un concept est modifié, la mise à jour se répercute immédiatement à tous les schémas où il est utilisé.
être lisible algorithmiquement, il est possible de l'analyser, de le parcourir pour en extraire de l'information, de ou pour reformater cette information, de le vérifier

Et en contrepartie d'un peu de rigueur, ce modèle va rendre possible :

la réutilisation les concepts précédemment modélisés, en ce sens il est un catalogue de l'existant.
l'accélération de la réalisation et l'homogénéisation de nouveaux schémas
l'analyse, le requêtage des concepts
une mise à jour rapide et surtout fiable des informations : plus besoin de chercher pendant des heures des documents épars pour des pénibles modifications à la main.

Le contenu du modèle se détermine au cas par cas en fonction du contexte et des usages.

A titre personnel, parce que j'apprécie les options tranchées, j'ai l'habitude de dire que le modèle doit contenir tout ce qui concerne directement l'architecte et que s'il n'arrive pas à le modéliser c'est probablement que ce n'est pas de l'architecture (ce qui ne veut pas dire que cela n'est pas pertinent bien entendu).

Mais attention à ne pas aller vers de la sur-modélisation : à chaque fois que vous ajoutez un concept ou une relation avec un concept, soyez fainéant : estimez si on pourrait un jour vous posez une question qui nécessiterait de requêter votre modèle pour y répondre.

Si oui continuez, si non cette information peut sans doute trouver sa place ailleurs, éventuellement dans la documentation du schéma ou du concept.

Exemple : en mon âme et conscience, j'ai considéré qu'on pourrait me demander le nombre d'utilisateurs potentiels d'une application mais aucunement le nombre d'utilisateurs simultanés. Je vais donc incorporer cette information du nombre potentiels d'utilisateurs à mon modèle (par un nombre sur la relation entre l'application et l'utilisateur 30 et 500 ici puis je note cette pratique dans un document qui référence tout ce qui est modélisé afin que tous les architectes de l'entreprise modélisent cette notion de la même façon) mais je ne modéliser pas le nombre d'utilisateurs simultanés

les quantités indiquées sur les associations avec les business-actors correspondent au nombre d'utilisateurs potentiels

Idem, dans un certain contexte, les problématiques de performance sont inexistantes (ce qui ne veut pas dire que les performances sont bonnes mais simplement que lorsqu'elles sont mauvaises on passe cela sous silence), aucune exigence sur ces aspects n'est donc modélisée.

La seule limite est votre capacité à transformer en concept Archimate toutes les notions que vous avez à documenter. Un formalisme comme Archimate permet aisément, sans même avoir à le tordre/détourner, de représenter les exigences non-fonctionnelles, les grandes étapes de la vie d'une application, les besoins en terme d'exploitation, etc…Bref toutes les parties qui constituent un dossier d'architecture.C'est un peu dur au début mais je peux vous certifier qu'une fois qu'on a pris le pli, il est intellectuellement hyper-satisfaisant de ne plus rédiger un dossier d'architecture à l'ancienne en bataillant avec Word.

Je reconnais que c'est une position extrême qui rencontre beaucoup de résistance quand je la propose, tant l'habitude du papier et de sa contrepartie électronique -le document word- est ancrée dans nos méthodes de travail.

Mais n'oubliez pas que la puissance d'un modèle est de pouvoir ensuite être traitée algorithmiquement : vous avez besoin d'un document word/PDF ? Développer un rapport qui traite les informations de votre modèle et vous permette de produire un tel document : ce dernier sera parfait pour les besoins de traçabilité, pour « snapshoter » une version particulière de la documentation d'une solution ou pour des exigences réglementaires.

Bonnes pratiques sur les vues Archimate

2023-09-10T00:00:00Z

Bonnes pratiques sur les vues Archimate

Quelques règles d'hygiène, essentiellement du bon sens, règles qui comme souvent seront plus utiles si vous êtes plusieurs à travailler sur des modèles communs.
Ces règles sont indiquées pour Archi mais je ne doute pas que les autres logiciels proposent quelque chose d'équivalent.

Nommage

Les vues doivent être nommées en respectant un formalisme, selon vos besoins. A titre d'exemple, j'ai utilisé
`[code de la vue]-[Application concernée ou domaine concerné]-[nom de la vue]`

Le `[code de la vue]` est à entendre comme une notion essentiellement technique, parlante plutôt pour un public d'architectes. Au contraire le "nom de la vue" s'adresse plutôt au "grand public".

Ex : "Vc07 - MaSuperAppli- vue fonctionnelle"

Propriétés des vues

Comme tous les concepts Archimate (enfin en tout cas dans Archi mais j'imagine que c'est similaire dans les autres outils), les vues peuvent avoir des propriétés. Là encore, j'ai eu l'occasion d'utiliser :

le code de la vue (on répète donc l'information du titre)
l'application/solution sur laquelle la vue est centrée, cad la solution qui est le personnage principal de la vue.
l'attribut `_hide_from_export_` qui permet de cacher une vue dans les exports
un attribut permettant d'identifier les vues qui auraient été générées de manière automatique (par un script, un outil, la commande "Generate View For.. (Ctrl+G)" dans Archi )

Ici je répète des informations déjà précisées dans le titre. Par principe, je fuis comme la peste la répétition des informations mais ici l'usage des propriétés est utile pour les traitements automatisés par scripts : il est plus fiable de s'appuyer sur ces données que de parser le titre de la vue.

Cartouche

Ajoutez un cartouche sur chaque schéma avec, a minima, titre, auteur date. Si ce n'est pas forcément utile pour les architectes, c'est une information toujours très intéressante pour le public qui consultera les schémas en dehors du contexte de l'outil dans un site web, un PowerPoint, etc.

Lisibilité globale

Efforcez-vous de garder un schéma lisible sans avoir à zoomer/dézoomer en permanence. Adaptez la mise en page (paysage ou portrait) au support final le plus probable (site web, word, PPT, etc..)

Mise en forme

Alignez les éléments les un par rapport aux autres,
Homogénéisez les écarts entre les éléments et la taille des différents concepts
Limitez les croisement de relations.
N'abusez pas des "junctions" elles peuvent alléger la charge visuelle du schéma mais gêner la compréhension : une bonne pratique est d'éviter les junctions de type "plusieurs entrées/plusieurs sorties" et se limiter à "plusieurs entrées/ 1 sortie" ou "1 entrée/plusieurs sorties".

Apparence visuelle des concepts

Respectez les couleurs par défaut définies par votre outil. Cependant, vous pouvez jouer sur la saturation de la couleur pour réduire/accroitre la visibilité d'un élément.

Définissez une feuille de style que tous les architectes partageront (Dans Archi, Menu Preferences > Appearance > Colours > Import Scheme). Les goûts et les couleurs... personnellement j'utilise celle-ci :
V3

Définissez quelles représentations par défaut vous utilisez pour chaque concept : dans Archi c'est au niveau du menu "Preferences > diagram > Default figures"

Définissez des visuels pour mettre en évidence les spécialisations de vos concepts : les utilisateurs verront le plus souvent vos schémas sous forme d'images, une icone permet de facilement leur indiquer cette information sémantiquement importante.

Exemple :

Viewpoint

Je n'ai jamais trop utilisé les viewpoints Archimate (a priori je ne suis pas le seul), laisser l'outil restreindre les concepts utilisables par schémas ne me semble pas très pertinent.

Paragraphe extrait d'Archimate 101

https://archimate-community.pages.opengroup.org/workgroups/archimate-101/fr/#_about_viewpoint_enforcement_in_tools

Is it useful to have a tool that forces you to use only a very restricted set of concepts? No because in some cases you might need a concept which was not planned when defining the viewpoint but makes sense in some very specific cases.

Je vois 2 cas où les viewpoints peuvent présenter un intérêt :

pour des présentations, en utilisant ce principe pour masquer/mettre en évidence des éléments couche par couche.
comme information exploitées par des outils de vérification automatique des schémas afin de contraindre plus fermement ce que doit contenir la vue et éviter ainsi que des écarts fassent planter l'outil.

Eléments "nested"

La superposition visuelle d'un concept dans un autre sans création d'une relation est toujours un peu risquée, d'ailleurs le valideur de modèle d'Archi vous signalera ce genre d'incohérences.

Attention, placer des concepts de technology layer dansun concept de l'application layer ne crée pas de liens automatiquement. Vous pouvez néanmoins paramétrer Archi pour qu'il vous propose de créer une association via les préférences. Cochez la case "association relation" dans la première zone du menu Connections > ARM.
Exemple :

Vues dans des vues

Il est possible de glisser déposer une vue existante dans une autre vue afin de faciliter la navigation entre le schémas. 2 cas d'usage que je trouve intéressants :

faire une vue de type "Sommaire" facilitant la navigation,permettant d'accéder aux autres vues d'un modèle. Vous éviterez ainsi à vos lecteurs d'avoir à se demander par où ils doivent commencer.
faire des "zooms" : partir d'une vue globale peu détaillée et offrir ensuite la possibilité d'accéder aux détails internes d'un concept. En pratique, c'est vite assez délicat à gérer au niveau des relations avec les concepts extérieurs à l'élément "zoomé".

Exemple de sommaire :

Exemple de zoom :

Threat modelling avec Archimate

2023-09-10T00:00:00Z

Threat modelling avec Archimate

Le point de départ

En lisant - on a les occupations qu'on peut - le livre de préparation de la certification CISSP (# (ISC)2 CISSP Certified Information Systems Security Professional Official Study Guide, 9th Edition – ISBN-10: 1119786231), je suis tombé sur une page concernant le threat modelling.

L'idée est de représenter visuellement un certain nombre de composants d'une solution pour faciliter l'identification des menaces. Exemple :

Source :

How to get started with Threat Modeling, before you get hacked. | by Alex Wauters | Medium Oui il y a des flèches bidirectionnelles, oui c'est le mal.

Il s'agit d'une forme de représentation graphique que je n'avais jamais croisée dans le monde professionnel. Y sont notamment indiqués :

les briques de la solution,
les interaction entre ces briques : sous forme de requête/réponse systématiquement, je n'en ai pas trouvé la raison
les « security boundaries »
les fonctions exécutés avec des privilèges élevés.

Je n'ai pas trouvé de formalisme bien défini pour ce type de visualisation et me suis demandé si Archimate pouvait répondre à ce type de besoin en apportant un peu plus de « cadre » à la représentation.

_Cet article présuppose que vous connaissez Archimate ainsi que le logiciel

Archi . Un autre logiciel peut sans aucun doute aboutir au même résultat visuellement mais la deuxième partie de l'article fait appel au plugin jArchi spécifique à Archi._

Le schéma

Première étape, une proposition de mapping entre les concepts utilisés pour ce threat modelling et les concepts Archimate :

Eléments du threat model => Concept Archimate

briques de la solution étudiée => Tout élément pertinent du métamodèle « core »
interactions entre les briques => « flow-relationship » qui représente à la fois la requête et la réponse
security boundaries => voir plus bas
Fonctions privilégiées => application-function
Threat => assessment (voir _How to Model Enterprise Risk Management and Security with the ArchiMate® Language_ Nov 2019 TOGAF)

La difficulté principale est, à mon sens, la modélisation des « frontières », Archimate n'ayant pas de concept de « limite ». Plusieurs solutions sont envisageables

1. faire passer le flux « au travers/par-dessus » : visuellement satisfaisant mais cela reste une convention graphique et ne se retrouve pas dans le modèle.
2. la frontière comme concept : visuellement satisfaisant mais on scinde le flux en 2 sous-flux, ce qui alourdit le modèle et complique l'analyse
3. un attribut ou une spécialisation du flux : on peut par exemple ajouter un attribut « secBoundaries = zone 1 | zone 2 » et/ou une spécialisation. Visuellement, ce n'est pas très parlant, et nécessite un code couleur pour * bien le mettre en évidence. C'est facile à analyser mais peu pratique à mettre à jour : le jour ou « zone 2 » est renommé il faut penser à mettre à jour les propriétés des flux concernés
4. associer un concept au flux : en liant un concept de type « technology-interface » au flux, on obtient quelque chose visuellement parlant, facile à analyser dans le modèle et à mettre à jour.
5. utiliser des concepts déjà modélisés : ici les différentes briques applicatives sont liées à des locations. Visuellement, cela charge un peu le schéma mais on voit immédiatement les flux qui passent d'une « location » à l'autre. Bien entendu cela implique que les « locations » soient correctement modélisées pour représenter les zones logiques d'un SI (et non uniquement des sites physiques par exemple).

La dernière approche a ma préférence car elle évite d'introduire un nouveau concept pour représenter la « boundary » tout en permettant de réutiliser des concepts qui ont probablement déjà été introduits par ailleurs dans le modèle.

Voilà un exemple basique pour une application web avec load balancer, serveurs frontends mutualisés à la maille de l'entreprise, puis frontends et backends dédiés à chaque application. Les backends sont dans une zone sécurisé, tout le reste est dans une zone réseau « à plat ». On a donc 2 « boundaries » :

entre le browser et le datacenter,
entre la zone par défaut du datacenter et la zone dite sécurisée.

Enfin, on identifie 3 vulnérabilités (en violet), nous y reviendrons dans le § suivant : 2 sont associées à des flux non chiffrés, 1 à l'absence de filtrage sur un frontend.

Pour aller plus loin

Nous avons maintenant produit un visuel, c'est bien, cela permet de communiquer, de clarifier les concepts. Tout l'intérêt de modéliser n'est pas juste de produire un beau schéma, mais de progressivement bâtir un modèle qu'on pourra ensuite valoriser par des analyses, des requêtes. Mon objectif est ici, une fois une vulnérabilité modélisée, de « scanner » le reste du modèle afin de détecter tous les autres cas où cette vulnérabilité se rencontre.

Sur l'exemple, ci-dessus, on modélise 3 vulnérabilités :

flux http non chiffré,
flux http non chiffré entre 2 zones différentes (ce qui correspond à un flux traversant les fameuses boundaries abordées au début de l'article),
Frontend non associé à du filtrage : on suppose ici que cela induit la possibilité qu'un attaquant se connecte directement auprès du frontend de l'application sans passer par les briques précédentes qui peuvent porter des services de sécurité.,

Pour cela, nous avons besoin de créer des règles. Elles vont être implémentées via une propriété de la vulnérabilité, ici notée « check_rule » :

Elles sont écrites en javascript afin d'être évaluées par le plugin jArchi d'Archi. Par convention, on considère que la variable « o » référence le concept associé à la vulnérabilité (un flow-relationship ici).

La première vulnérabilité « Unencrypted flow » se code :

o.name.indexOf("(http)")>-1

Se traduit par, « il y a vulnérabilité si le nom du flux indique que le protocole est (http) ».

La vulnérabilité « Unencrypted flow between 2 different zones » peut se coder de la façon suivante :

((o.name.toLowerCase().indexOf("(http)")>-1) && (!compareFirstAncestors(o.source,o.target,"location")))

En bon français, cela se lit : on a une vulnérabilité si le flux est indiqué comme (http) ET que la source et la destination du flux sont situés dans des « locations » différentes.

La méthode compareFirstAncestors n'existe pas dans le SDK de jArchi, c'est une méthode que j'ai conçue pour l'exemple et qui compare le premier « parent » de type « location » contenant chacun des 2 concepts passés en paramètre de la méthode. Elle retourne true si c'est le même concept.

Enfin, la vulnérabilité « No filtering on incoming request » décrite de manière ultra-simplifiée par :

(o.name.indexOf("Frontend")>-1) && (!isRelatedTo(o, "filtering","association-relationship"))

Traduction : il y a vulnérabilité si le composant contient le terme « Frontend » et n'est pas lié à un bloc nommé « filtering ».

De même que « compareFirstAncestors », la méthode « isRelatedTo » a été créée spécifiquement pour mon besoin.

Reste à rédiger ensuite le script qui va vérifier ces règles sur l'ensemble du modèle.

Le script doit itérer sur l'ensemble des concepts « assessment » du modèle.
Si « l'assessment » possède une propriété check_rule, on évalue la valeur de cette propriété.
Si elle est vraie, on créé une relation entre « l'assessment » et l'objet ne respectant pas la règle.

Le code suivant implémente ceci de manière très basique, il mérite un peu de travail pour être pleinement opérationnel :

    $("assessment").each(function (as) {
        let rule = null;
        if (as.prop("check_rule") !== undefined) {
            rule = as.prop("check_rule");
            let assessedElement = "";


            //get the type of the concept associated with the assessment (suppose that an assessment is always associated with this type of concept across models)

            $(as).rels("association-relationship").ends().each(function (element) {
                if (element.type !== "assessment") {
                    assessedElement = element.type;
                    return;
                }
            })

            //check for all concepts of this type in the model
            $(assessedElement).each(function (o) {
                //if rule evaluation is true, create a vulnerabilty association between assessment and object
                if (eval(rule)) {
                    if ($(as).rels("association-relationship").ends(o.type).filter("#" + o.id).size() === 0) {
                        model.createRelationship("association-relationship", "vulnerability", as, o)
                    } else {
                       //do nothing at the moment
                    }
                } else {
                    //delete relationship
                    $("association-relationship").each(function (rel) {
                        if ((rel.source.id === as.id)&& (rel.target.id===o.id) && rel.name==="vulnerability") {
                            rel.delete();
                        }
                    });
                }
            })

        }

    });

Notez la ligne « eval(rule) » qui comme son nom l'indique évalue (cad exécute) la ligne de code indiquée par la propriété « check_rule » de l'assessment.

Après avoir passé le script (et, pour les raisons du test modifiés le protocole du flux browser > load balancer en http), 2 nouvelles associations sont apparues dans le modèle (mais pas dans la vue, on pourrait toutefois facilement les faire ajouter dans le script)

Il y a donc nécessité de faire un peu de code et, surtout, de fournir un effort de formalisation des vulnérabilités. En contrepartie, cet exemple permet de discerner les apports d'un modèle, apports qui vont bien au-delà de simple représentation visuelle.

Conclusion

Ainsi, au-delà d'une « simple » représentation graphique via Archimate (ce qui est déjà beaucoup, entendons-nous bien), on peut utiliser la puissance du modèle pour capitaliser les vulnérabilités détectées sur une solution et rechercher leur occurrence dans les autres solutions modélisées.

Comment automatiser les tests de scripts bash ?

2023-09-10T00:00:00Z

Comment automatiser les tests de scripts bash ?

On parle beaucoup de tests unitaires automatisés en développement Java, Python, JS, etc.. (notez que je dis bien "on parle" et non "on fait"...) mais dès qu'on entre dans le monde des scripts Shell, ce type d'exigence disparaît souvent comme par enchantement. J'ignore s'il y a une raison historique à cette absence de pratique mais, étant très loin d'être un spécialiste de la ligne de commande, et devant pourtant en écrire assez souvent, j'éprouve le besoin de pouvoir tester mes productions, notamment lorsque je prépare des déploiements.

D'aucun diront peut-être qu'à l'état de l'art, on n'a plus besoin de ce genre de compétences mais de Terraform, d'Ansible, que sais-je encore ? Oui sauf que dans la vraie vie, ces technologies ne sont pas toujours disponibles dans mon contexte et que j'ai tendance à privilégier les solutions les plus simples afin de faciliter la vie des personnes qui, après moi, assureront la maintenance. Si je sais qu'elles sont bilingues dans les technos sus-dites, aucun problème mais si ce n'est pas le cas, je fais du basique. Et puis même avec ces technologies, je reste persuadé qu'avoir un moyen d'automatiser la vérification du résultat d'une installation est toujours pertinent.

Bats-core permet ainsi de procéder à de tels tests et semble le faire très bien (j'ai lu la doc mais pas testé sur mes serveurs)

https://github.com/bats-core/bats-core)

Mais comme on est jamais aussi bien servi que par soi-même (et que cela me permettait de pratiquer le bash) J'ai aussi fait mon propre outil qui permet de répondre à ce type de besoin plutôt orienté "vérification d'une installation" avec des méthodes qui permettent de tester par exemple :

l'existence d'un dossier/fichier
l'existence d'un groupe/utilisateur
le fait qu'un service/process soit en cours d'exécution
le fait qu'un package soit installé

Le script est dispo sur mon Gitlab

gitlab

Ainsi on peut tester par exemple la présence d'un fichier

checkFileExists "/etc/yum.repos.d/shibboleth.repo"`

et on obtient à l'exécution une sortie texte, verte si tout est OK, rouge sino.

C'est une solution KISS, beaucoup moins évoluée que Bats bien entendu. Mais, si j'en reviens à mon second § sur la transmission de mes développements à mes successeurs, elle présente l'avantage de ne pas leur demander d'acquérir de nouvelles compétences sur un point pour lesquels ils seront peu fréquemment sollicités.