Dernièrement, un ami m'a demandé : « qu'est-ce que je dois faire signer à mes clients pour être autorisé légalement à analyser leurs données confidentielles à l'aide d'un LLM, en fonction des types d'hébergement qui s'offrent à moi ? ».

Il travaille dans une entreprise sous-traitante industrielle. Contrairement à ma note du mois de juin, cette fois il ne s'agit pas de Données de santé (DDS), ni de PII, mais de secrets industriels. D'après ce que j'ai compris, le sujet est surtout contractuel.

Pour la suite de cette note, j'appelle Verdier Industries (nom fictif) l'entreprise de mon ami, afin d'incarner mes propos.

Dans cette note, je veux être très pratique : je souhaite générer des exemples de documents légaux à faire signer aux clients de Verdier Industries en fonction des options suivantes :

• a. LLM en SaaS hors UE
• b. LLM en SaaS en Europe hors France
• c. LLM en SaaS en France
• d. LLM installé sur une machine virtuelle avec GPU, louée chez Scaleway, OVH, etc.
• e. LLM installé sur un serveur physique dans ses locaux

Idéalement, je souhaite pouvoir facilement comparer ces documents légaux et analyser l'impact que cela aura sur la relation commerciale.
Lesquels risquent de faire peur à ses clients ou au contraire de les rassurer.

Avant d'entrer dans le détail, une précision sur le terme « accès à un LLM ». Si je simplifie, un LLM s'utilise de deux façons très différentes :

• via une interface de chat, dans un navigateur ou une application : c'est le cas de ChatGPT, Claude, Le Chat (Mistral AI), etc. Une personne écrit un message, le modèle répond. Ces noms désignent des interfaces de chat, pas le modèle qui est derrière. Les modèles portent d'autres noms.
• via une API : une sorte de porte d'entrée technique qui permet à un logiciel d'envoyer des demandes au modèle automatiquement, sans qu'un humain tape dans une fenêtre de chat. Quelques exemples de modèles connus au mois de septembre 2026 : GPT-5.6 Sol, Claude Sonnet 5, DeepSeek 4.1 Flash.

Dans cette note, je ne traite que du second cas, l'accès par API.
La raison : c'est le modèle LLM qui est très difficile à héberger soi-même, pas l'interface de chat.
Un LLM a besoin de serveurs puissants, équipés de GPU coûteux. Une fois qu'on dispose d'un accès au modèle, héberger une interface de chat comme Open WebUI ou LibreChat est plutôt facile, car ces services fonctionnent sur des machines modestes.

Autrement dit, les cinq options ci-dessous décrivent surtout où et comment on accède au modèle, pas comment on l'affiche à l'écran.

Une dernière précision : cette note traite uniquement des questions légales. Je compte publier une autre note pour tout ce qui concerne les estimations de coût d'hébergement pour chacune de ces options.

Je détaille les cinq options d'accès à un LLM

J'ai fait le choix de découper les offres commerciales réellement disponibles pour chacune de ces options par localisation du traitement des données, et non pas par juridiction du fournisseur.

J'ai indiqué la juridiction du fournisseur dans le tableau de synthèse en fin de section. Je tiens à préciser que cette question de juridiction n'est pas anecdotique pour les clients.

Solutions SaaS

Un service SaaS, ici, veut dire que le modèle est fourni et exécuté par un tiers : les données de Verdier Industries et de ses clients partent chez le fournisseur, qui renvoie une réponse. Contrairement aux solutions IaaS, Verdier Industries n'a donc pas besoin d'un administrateur système, interne ou externe, pour gérer le serveur qui fait tourner le modèle, ni pour s'occuper du modèle.

LLM en SaaS hors UE (a)

Lieu de traitement des données : hors de l'Union européenne.

Les offres les plus courantes en API directe chez des producteurs de LLM sont :

• OpenAI,
• Anthropic
• et Google Gemini

On trouve aussi des AI providers comme Deepinfra ou Together AI.

LLM en SaaS en Europe hors France (b)

Lieu de traitement des données : dans l'UE, mais le fournisseur n'est pas français.

Côté américain, l'endpoint européen d'OpenAI traite les données en Irlande (Dublin). Attention, le contrat reste conclu avec une entité américaine : OpenAI reste donc soumis au Cloud Act.

On y trouve aussi des acteurs européens comme :

• IONOS et leur offre AI Model Hub
• ou STACKIT et leur offre AI Model Serving

mais ces deux acteurs offrent un accès seulement à des modèles peu puissants.

LLM en SaaS en France (c)

Lieu de traitement des données : en France.

Les offres portées par une entité française sont :

• Mistral AI
• OVHcloud avec AI Endpoints
• Scaleway avec Generative APIs

En septembre 2026, Mistral AI et OVHcloud ne proposent que des modèles très peu puissants, bien loin derrière GLM-5.2 ou DeepSeek V4 Flash 0731 proposé par Scaleway.

Les acteurs américains peuvent aussi traiter dans des data centers en France, à condition de choisir explicitement un déploiement mono-région :

• AWS avec Bedrock
• Azure avec Azure OpenAI
• Google Cloud avec Vertex AI
• Together AI avec leur offre Dedicated inference, tuned for production

Pour tous ces acteurs, le contrat reste conclu avec une entité américaine : ils restent donc soumis au Cloud Act.

Solutions IaaS en France (d)

Une machine virtuelle avec GPU louée, c'est de l'IaaS : seule l'infrastructure est louée, le modèle LLM est installé et administré par un informaticien administrateur système de Verdier Industries. Le fournisseur n'a donc pas accès à l'OS de la machine virtuelle, donc pas aux données traitées.

Nuance : sur une machine virtuelle, l'hébergeur contrôle l'hyperviseur et pourrait en théorie accéder à la mémoire de la VM, ce qui n'est pas le cas sur un serveur bare metal.

• Quelques acteurs français :
  • Scaleway, offres GPU Instances
  • OVH, offres Cloud GPU
  • Outscale, offres GPU NVIDIA
  • Cloud Temple
• Acteurs américains dans leur datacenter en France soumis au Cloud Act :
  • Together AI, offres GPU clusters
  • AWS, offres Accelerated computing Amazon EC2 instance types
  • Azure, offres GPU accelerated VM size series
  • Google Cloud, offres accelerator-optimized

Sur site, un serveur dans les locaux de Verdier Industries (e)

Le serveur est dans les locaux de Verdier Industries : aucun tiers n'intervient, ni pour la machine, ni pour le modèle.

L'informaticien administrateur système de Verdier Industries doit prendre en charge l'installation, sur ce serveur, de logiciels comme vLLM, Ollama ou llama.cpp permettant d'instancier des LLM.

À ce coût matériel, DeepSeek V4 Flash me dit qu'il faut ajouter la facture d'électricité : un serveur 8x H100 ou H200 consomme de l'ordre de 10 kW au niveau informatique et 14 kW au niveau de l'installation, refroidissement inclus, soit de l'ordre de 15 000 à 30 000 € par an à pleine charge selon le prix du kWh.

Concrètement, un tel serveur ne peut pas être placé dans une pièce de bureaux : il faut une alimentation électrique dédiée, un refroidissement dimensionné et une pièce isolée acoustiquement.

Tableau de synthèse

Option	Fournisseur	Pays de l'entité	Datacenter	Résidence UE	Exposition CLOUD Act
SaaS hors UE	OpenAI	États-Unis	États-Unis	Non	Oui
SaaS hors UE	Anthropic	États-Unis	États-Unis	Non	Oui
SaaS hors UE	Google	États-Unis	États-Unis	Non	Oui
SaaS hors UE	Deepinfra	États-Unis	États-Unis	Non	Oui
SaaS hors UE	Together AI	États-Unis	États-Unis	Non	Oui
SaaS Europe hors France	OpenAI	États-Unis	UE (Irlande)	Oui	Oui
SaaS Europe hors France	IONOS	Allemagne	UE	Oui	Non
SaaS Europe hors France	STACKIT	Allemagne	UE	Oui	Non
SaaS en France	Mistral AI	France	France	Oui	Non
SaaS en France	Scaleway	France	France	Oui	Non
SaaS en France	OVHcloud	France	France	Oui	Non
SaaS en France	AWS	États-Unis	France	Oui	Oui
SaaS en France	Microsoft	États-Unis	France	Oui	Oui
SaaS en France	Google	États-Unis	France	Oui	Oui
SaaS en France	Together AI	États-Unis	France	Oui	Oui
IaaS	Scaleway	France	France	Oui	Non
IaaS	OVHcloud	France	France	Oui	Non
IaaS	Outscale	France	France	Oui	Non
IaaS	Cloud Temple	France	France	Oui	Non
IaaS	Together AI	États-Unis	France	Oui	Oui
IaaS	AWS	États-Unis	France	Oui	Oui
IaaS	Microsoft	États-Unis	France	Oui	Oui
IaaS	Google	États-Unis	France	Oui	Oui
Sur site	—	Auto-hébergé	Locaux de Verdier Industries	Oui	Non

Les 6 situations contractuelles

À partir de toutes les options d'hébergement d'un LLM listées précédemment, voici la liste de toutes les situations contractuelles.
Le classement va du plus simple à opérer (SaaS hors UE) au plus difficile (serveur sur site).

Cas	Option	Exposition des données à un tiers	Transfert hors UE	Cloud Act
1	(a) SaaS hors UE	Oui	Oui	Oui
2	(b/c) SaaS datacenter en UE ou FR, entité US	oui	Non	Oui
3	(b/c) SaaS datacenter en UE ou FR, entité UE	oui	Non	Non
4	(d) IaaS US avec datacenter en FR	non	Non	Oui
5	(d) IaaS FR avec data center en FR	non	Non	Non
6	(e) sur site	aucun tiers	Non	Non

Liste des démarches administratives à effectuer pour chaque situation contractuelle

Je pars de la situation suivante : Verdier Industries a déjà 50 clients sous contrat, il décide de réaliser les démarches légales auprès de ses clients afin d'être autorisé à envoyer des données confidentielles de ses clients à son LLM à travers la solution qu'il a retenue. Quels sont les documents à produire, envoyer au client, faire signer, etc.

Hypothèse générale : les contrats clients interdisent la divulgation des données confidentielles à un tiers sans accord écrit. Un avenant signé est donc nécessaire.

J'ai dressé la liste des étapes de ces procédures administratives avec l'aide de DeepSeek V4.1 Flash.

Cas 1 - SaaS hors UE

Procédure pas à pas :

1. Verdier Industries demande à son fournisseur (par exemple OpenAI) les documents suivants et les rassemble :
   • son accord de confidentialité ;
   • son engagement de non-entraînement et de rétention zéro ;
   • son DPA (Data Processing Agreement, accord de traitement des données), si données personnelles ;
   • ses CCT (Clauses Contractuelles Types), si données personnelles ;
   • la liste de ses sous-traitants ultérieurs ;
   • ses certifications et attestations de sécurité : SOC 2 Type II (attestation) et ISO/IEC 27001 (certification), et le cas échéant ISO/IEC 27017, 27018, 27701 et 42001, SecNumCloud ou HDS.
2. Verdier Industries rédige un avenant type au contrat client, structuré en articles :
   • article 1 : autorisation de divulgation des données à un tiers ;
   • article 2 : confidentialité ;
   • article 3 : acceptation du risque Cloud Act ;
   • article 4, si données personnelles : autorisation de sous-traitance (article 28.2 du RGPD) et annexe des CCT.
3. Verdier Industries joint à l'avenant les documents obtenus à l'étape 1.
4. Verdier Industries envoie le dossier à chaque client.
5. Le client signe l'avenant et le renvoie.
6. Verdier Industries archive l'avenant signé et ses pièces jointes par client.

Selon ce que prévoit le contrat client pour le RGPD :

• Si le contrat contient une autorisation générale, par exemple : « Le client autorise Verdier Industries à recourir à des sous-traitants ultérieurs. Verdier Industries informe le client par écrit au moins 30 jours à l'avance, et le client peut s'opposer à cette modification. » Alors, pour le RGPD, Verdier envoie une simple notification, et si le client ne s'oppose pas dans les 30 jours, le nouveau sous-traitant est accepté, sans signature.
• Si le contrat contient une autorisation spécifique, par exemple : « Verdier Industries ne peut confier les données à un sous-traitant ultérieur qu'après accord écrit préalable du client. » Alors Verdier doit faire signer l'avenant pour le RGPD aussi.
• Dans les deux cas, ces clauses ne couvrent ni les secrets industriels ni le risque Cloud Act : pour ces deux points, l'avenant doit être signé.

Cas 2 - SaaS datacenter en UE ou FR, entité US

Les données sont traitées dans l'UE, mais le fournisseur est une entité américaine : il reste soumis au Cloud Act. Comme il n'y a pas de transfert hors UE, les CCT ne sont pas nécessaires.

Procédure pas à pas :

1. Verdier Industries demande à son fournisseur (par exemple l'endpoint européen d'OpenAI) les documents suivants et les rassemble :
   • son accord de confidentialité ;
   • son engagement de non-entraînement et de rétention zéro ;
   • son DPA (Data Processing Agreement, accord de traitement des données), si données personnelles ;
   • la liste de ses sous-traitants ultérieurs ;
   • ses certifications et attestations de sécurité : SOC 2 Type II (attestation) et ISO/IEC 27001 (certification), et le cas échéant ISO/IEC 27017, 27018, 27701 et 42001.
2. Verdier Industries rédige un avenant type au contrat client, structuré en articles :
   • article 1 : autorisation de divulgation des données à un tiers ;
   • article 2 : confidentialité ;
   • article 3 : acceptation du risque Cloud Act ;
   • article 4, si données personnelles : autorisation de sous-traitance (article 28.2 du RGPD).
3. Verdier Industries joint à l'avenant les documents obtenus à l'étape 1.
4. Verdier Industries envoie le dossier à chaque client.
5. Le client signe l'avenant et le renvoie.
6. Verdier Industries archive l'avenant signé et ses pièces jointes par client.

Pour le RGPD :

• Si le contrat contient une autorisation générale de sous-traitance : une notification avec droit d'opposition suffit, sans signature.
• S'il exige un accord écrit au cas par cas : l'avenant doit être signé.
• Dans les deux cas, la confidentialité des secrets industriels et le risque Cloud Act imposent une signature.

Cas 3 - SaaS datacenter en UE ou FR, entité UE

Les données sont traitées dans l'UE par une entité européenne : ni transfert hors UE, ni exposition au Cloud Act.

Procédure pas à pas :

1. Verdier Industries demande à son fournisseur (par exemple Scaleway) les documents suivants et les rassemble :
   • son accord de confidentialité ;
   • son engagement de non-entraînement et de rétention zéro ;
   • son DPA (Data Processing Agreement, accord de traitement des données), si données personnelles ;
   • la liste de ses sous-traitants ultérieurs ;
   • ses certifications et attestations de sécurité : SOC 2 Type II (attestation) et ISO/IEC 27001 (certification), et le cas échéant ISO/IEC 27017, 27018, 27701 et 42001, SecNumCloud ou HDS.
2. Verdier Industries rédige un avenant type au contrat client, structuré en articles :
   • article 1 : autorisation de divulgation des données à un tiers ;
   • article 2 : confidentialité ;
   • article 3, si données personnelles : autorisation de sous-traitance (article 28.2 du RGPD).
3. Verdier Industries joint à l'avenant les documents obtenus à l'étape 1.
4. Verdier Industries envoie le dossier à chaque client.
5. Le client signe l'avenant et le renvoie.
6. Verdier Industries archive l'avenant signé et ses pièces jointes par client.

Pour le RGPD :

• Si le contrat contient une autorisation générale de sous-traitance : une notification avec droit d'opposition suffit, sans signature.
• S'il exige un accord écrit au cas par cas : l'avenant doit être signé.
• Dans les deux cas, la confidentialité des secrets industriels impose une signature.

Cas 4 - IaaS US avec datacenter en FR

L'infrastructure est louée chez un hébergeur américain. L'hébergeur n'accède pas au contenu des données, mais il reste soumis au Cloud Act.

Procédure pas à pas :

1. Verdier Industries demande à son hébergeur (par exemple AWS) les documents suivants et les rassemble :
   • son accord de confidentialité ;
   • son engagement de non-accès au contenu des données hébergées : mémoire vive, volumes de stockage et snapshots des machines virtuelles, sauf demande écrite de Verdier Industries ou réquisition d'une autorité judiciaire ou administrative compétente ;
   • son DPA (Data Processing Agreement, accord de traitement des données), si données personnelles ;
   • la liste de ses sous-traitants ultérieurs ;
   • ses certifications et attestations de sécurité : SOC 2 Type II (attestation) et ISO/IEC 27001 (certification), et le cas échéant ISO/IEC 27017 et 27018.
2. Verdier Industries rédige un avenant type au contrat client, structuré en articles :
   • article 1 : autorisation d'héberger les données sur une infrastructure tierce ;
   • article 2 : Verdier Industries garantit que l'hébergeur n'a pas accès au contenu des données, son accès étant limité à l'infrastructure nécessaire à l'hébergement, hors réquisition d'une autorité judiciaire ou administrative compétente ;
   • article 3 : acceptation du risque Cloud Act ;
   • article 4, si données personnelles : autorisation de sous-traitance (article 28.2 du RGPD).
3. Verdier Industries joint à l'avenant les documents obtenus à l'étape 1.
4. Verdier Industries envoie le dossier à chaque client.
5. Le client signe l'avenant et le renvoie.
6. Verdier Industries archive l'avenant signé et ses pièces jointes par client.

Pour le RGPD :

• Si le contrat contient une autorisation générale de sous-traitance : une notification avec droit d'opposition suffit, sans signature.
• S'il exige un accord écrit au cas par cas : l'avenant doit être signé.
• Dans les deux cas, la confidentialité des secrets industriels et le risque Cloud Act imposent une signature.

L'engagement de non-accès demandé à l'hébergeur peut être rédigé ainsi :

L'hébergeur s'engage à ne pas accéder au contenu des données hébergées, en particulier à la mémoire vive, aux volumes de stockage et aux snapshots des machines virtuelles, sauf demande écrite de Verdier Industries ou réquisition d'une autorité judiciaire ou administrative compétente. En cas de réquisition, l'hébergeur en informe Verdier Industries dans les meilleurs délais, sauf si la loi lui interdit de le faire.

Cas 5 - IaaS FR avec data center en FR

L'infrastructure est louée chez un hébergeur français ou européen : ni transfert hors UE, ni exposition au Cloud Act.

Procédure pas à pas :

1. Verdier Industries demande à son hébergeur (par exemple Scaleway) les documents suivants et les rassemble :
   • son accord de confidentialité ;
   • son engagement de non-accès au contenu des données hébergées : mémoire vive, volumes de stockage et snapshots des machines virtuelles, sauf demande écrite de Verdier Industries ou réquisition d'une autorité judiciaire ou administrative compétente ;
   • son DPA (Data Processing Agreement, accord de traitement des données), si données personnelles ;
   • la liste de ses sous-traitants ultérieurs ;
   • ses certifications et attestations de sécurité : SOC 2 Type II (attestation) et ISO/IEC 27001 (certification), et le cas échéant ISO/IEC 27017 et 27018, SecNumCloud ou HDS.
2. Verdier Industries rédige un avenant type au contrat client, structuré en articles :
   • article 1 : autorisation d'héberger les données sur une infrastructure tierce ;
   • article 2 : Verdier Industries garantit que l'hébergeur n'a pas accès au contenu des données, son accès étant limité à l'infrastructure nécessaire à l'hébergement, hors réquisition d'une autorité judiciaire ou administrative compétente ;
   • article 3, si données personnelles : autorisation de sous-traitance (article 28.2 du RGPD).
3. Verdier Industries joint à l'avenant les documents obtenus à l'étape 1.
4. Verdier Industries envoie le dossier à chaque client.
5. Le client signe l'avenant et le renvoie.
6. Verdier Industries archive l'avenant signé et ses pièces jointes par client.

Pour le RGPD :

• Si le contrat contient une autorisation générale de sous-traitance : une notification avec droit d'opposition suffit, sans signature.
• S'il exige un accord écrit au cas par cas : l'avenant doit être signé.
• Dans les deux cas, la confidentialité des secrets industriels impose une signature.

L'engagement de non-accès demandé à l'hébergeur peut être rédigé ainsi :

L'hébergeur s'engage à ne pas accéder au contenu des données hébergées, en particulier à la mémoire vive, aux volumes de stockage et aux snapshots des machines virtuelles, sauf demande écrite de Verdier Industries ou réquisition d'une autorité judiciaire ou administrative compétente. En cas de réquisition, l'hébergeur en informe Verdier Industries dans les meilleurs délais, sauf si la loi lui interdit de le faire.

Cas 6 - Hébergement sur site

Le serveur est dans les locaux de Verdier Industries : aucun tiers n'intervient.

• Aucun document à obtenir d'un tiers.
• Aucun avenant à faire signer : les données ne quittent pas les locaux et ne sont divulguées à personne.
• Pour rassurer le client, Verdier Industries peut l'informer que le traitement se fait en interne, sans sous-traitant ultérieur.

Liste des différences entre les situations contractuelles

Différences entre cas 2 et cas 1

• Les données restent dans l'UE : les CCT ne sont plus nécessaires.
• Le reste est identique, notamment le risque Cloud Act.

Différences entre cas 3 et cas 2

• Le fournisseur est une entité européenne : plus de risque Cloud Act.
• L'article 3 de l'avenant (acceptation du risque Cloud Act) disparaît.
• Le reste est identique.

Différences entre cas 4 et cas 3

• Le fournisseur ne traite plus les données : l'hébergeur n'accède pas au contenu, et l'avenant le garantit (article 2).
• L'engagement de non-entraînement et de rétention zéro disparaît.
• L'article 1 de l'avenant devient une autorisation d'héberger, et non plus une autorisation de divulgation.
• Le risque Cloud Act réapparaît, car l'hébergeur est américain.

Différences entre cas 5 et cas 3

• Le fournisseur ne traite plus les données : l'hébergeur n'accède pas au contenu, et l'avenant le garantit (article 2).
• L'engagement de non-entraînement et de rétention zéro disparaît, remplacé par un engagement de non-accès au contenu.
• L'article 1 de l'avenant devient une autorisation d'héberger, et non plus une autorisation de divulgation.
• Les certifications attendues sont allégées : plus de 27701 ni 42001, qui n'ont plus de sens quand le fournisseur ne traite pas les données.
• Le reste est identique : ni transfert hors UE, ni risque Cloud Act.

Différences entre cas 5 et cas 4

• L'hébergeur est français ou européen : plus de risque Cloud Act.
• L'article 3 de l'avenant (acceptation du risque Cloud Act) disparaît.
• Le reste est identique.

Différences entre cas 6 et cas 5

• Aucun tiers n'intervient : plus de documents à obtenir ni d'avenant à signer.
• Il ne reste qu'une information au client, sans sous-traitant ultérieur.

Ce que je retiens

En travaillant cette note, je m'attendais, naïvement, à ce que le cas 5 — un LLM installé sur une machine virtuelle avec GPU louée chez un hébergeur français, dans un data center français — soit indolore contractuellement, c'est-à-dire qu'il n'exige aucun avenant aux contrats clients, mais ce n'est pas le cas.

En réalité, l'infrastructure reste louée à un tiers. Les contrats clients interdisent la divulgation des données confidentielles à un tiers sans accord écrit, et même si l'hébergeur n'accède pas au contenu, le fait de lui confier l'infrastructure qui porte les données déclenche quand même la signature.

Gagner en souveraineté réduit le nombre d'articles et la gravité du risque, mais ne ramène pas le travail contractuel à zéro.

Mon regard de praticien de terrain

Comme dans ma note du mois de juin sur les données de santé, je termine cette note avec un sentiment partagé.
Je suis un praticien de terrain : j'administre les serveurs, je gère les données de mes propres mains. En lisant tout cet édifice contractuel, je sais qu'il s'agit d'une convention humaine — ce que l'on nomme le constructivisme juridique, il me semble — souvent assez éloignée de la logique et de la pratique du terrain.

C'est un exercice d'analyse que j'aime beaucoup, mais qui m'est difficile. Il me crée une dissonance cognitive. D'un côté, je pense en praticien : je vois ce qu'on pourrait faire techniquement, concrètement, physiquement, pour renforcer la sécurité des données. De l'autre, ces protections juridiques sanctionnent devant un juge, mais ne protègent pas la donnée physiquement. C'est une protection par la sanction, pas une protection réelle. Ma culture hacker est de protéger pour de vrai, pas par le droit. Je crois que c'est là la source de ma dissonance, et parfois de mon énervement.

J'y trouve régulièrement de l'incohérence, parfois une forme d'hypocrisie, un peu comme un jeu de théâtre. Je ne dis pas que cela ne sert à rien — sans doute que ce cadre protège. Peut-être que mon regard de praticien me rend trop sensible à ce qui sépare la théorie juridique du terrain.

Suite à ma note "Danger des permissions par défaut de OpenCode sur un projet d'infrastructure as code", une amie m'a mise sur la piste des hooks pour intégrer efficacement le blocage de l'exécution de commandes dangereuses dans mon harness.

claude-code-hooks

Elle utilise Claude Code et je pense qu'elle utilise le projet claude-code-hooks (lien direct), et plus précisément son script block-dangerous-commands.js.

Ce projet est présenté dans le billet Claude Code's Most Underrated Feature: Hooks du 25 janvier 2026, que j'ai pris le temps de lire avec attention.

Après lecture, ce billet confirme la piste suggérée par mon amie : les hooks semblent être la solution la plus répandue pour bloquer les commandes dangereuses.

J'ai découvert cc-safety-net

J'ai ensuite cherché une solution "clé en main" équivalente à block-dangerous-commands.js pour OpenCode et suis tombée sur cc-safety-net (lien direct), un projet qui a même démarré un peu avant claude-code-hooks (source) :

Le nom cc-safety-net combine l'abréviation de Claude Code ("cc") et "safety net", qui veut dire "filet de sécurité".

cc-safety-net ne se limite pas à Claude Code et OpenCode : il prend aussi en charge Codex, Gemini CLI, GitHub Copilot CLI et Kimi Code.

J'ai installé cc-safety-net

J'ai installé cc-safety-net sur mon instance OpenCode. Bien qu'il ne soit pas visible dans la liste des plugins de l'interface OpenCode — ce qui semble normal — il fonctionne correctement d'après mes tests :

$ git init
$ touch file1.md
$ git add file1.md
$ git commit -m "First import"
$ touch file2.md
$ opencode run --agent="build" "exécute git reset --hard"

> build · deepseek-v4-flash

✗ git reset --hard failed
Error: BLOCKED by CC Safety Net

Reason: git reset --hard destroys all uncommitted changes permanently. Use 'git stash' first.

Command: git reset --hard

If this operation is truly needed, ask the user for explicit permission and have them run the command manually.

La commande `git reset --hard` est bloquée par le CC Safety Net car elle détruit irréversiblement les changements non commités.

**Alternatives :**
- `git stash` pour sauvegarder les changements avant de reset
- Exécute la commande toi-même manuellement si tu confirms vouloir tout perdre

Que veux-tu faire ?

Par défaut, cc-safety-net contient peu de règles : il bloque les commandes de suppression sur le système de fichiers et git, comme documenté ici : "blocked-commands".

Après la lecture de la page "allowed-commands", j'ai cru que cc-safety-net proposait aussi un mode whitelist. En réalité, il fonctionne seulement en mode blocklist — pas de mode "tout bloquer" avec un système de whitelist.

Pour le moment, j'ai décidé d'activer le mode par défaut de cc-safety-net.

Création de rulebooks pour mon projet homelab

Ce que je trouve très intéressant avec cc-safety-net, c'est la possibilité d'ajouter facilement des "Custom Rules" grâce aux "rulebooks". Cette fonctionnalité est jeune, à peine 3 semaines. Pour le moment, je n'ai trouvé que 2 "rulebooks" sur GitHub.

J'ai utilisé le skill /cc-safety-net pour créer mes "rulebooks" pour les commandes kubectl, helmfile, tofu et mise de mon projet homelab.sklein.xyz. Pas sans difficulté : le skill a dû corriger plusieurs erreurs de syntaxe dans les fichiers json qu'il a générés. Je ne sais pas si c'est normal. Mais à la fin, ça a fonctionné.

Je viens de configurer tout cela, je n'ai aucun retour d'expérience, j'essaierai d'en donner un d'ici une semaine.

Encore un problème avec rtk !

Par contre, j'ai découvert que cc-safety-net a lui aussi des difficultés avec rtk : [Bug]: rtk bypasses safety net.

Pour les secrets, je compte tester Rehydra

Contrairement à claude-code-hooks, cc-safety-net ne propose pas de hooks pour cacher les secrets à l'agent.

#JaiDécouvert le projet rehydra qui me semble très intéressant :

PII security for AI workflows, coding agents and browser workloads. Detects, replaces, encrypts, and rehydrates back when needed.

source

cc-safety-net versus agentsh ?

J'ai seulement survolé le sujet, mais j'ai l'impression que agentsh analyse et intercepte ce qui se passe directement au niveau du système d'exploitation, du système de fichiers, réseau, et processus. Il n'agit pas au niveau applicatif, il n'a pas besoin de comprendre ce que fait en théorie la commande, il observe réellement son action sur l'OS.

Pour le moment je pense que cc-safety-net est une bonne première étape de sécurité pour mes besoins. Mais agentsh a attiré ma curiosité, peut-être que je le testerai prochainement.

Remerciement

Merci à mon amie CC de m'avoir mise sur la piste des hooks 🤗.

En étudiant la compatibilité de Prempti avec rtk (voir cette note : "Danger des permissions par défaut d'OpenCode sur un projet d'infrastructure as code"), j'ai découvert ici que rtk contourne les règles de permissions de OpenCode ! Mais aussi Claude Code d'après ce que j'ai compris.

J'ai testé et c'est vrai ! Voici mon test.

J'ai rtk installé et configuré pour OpenCode au niveau global, avec rtk init -g --opencode.

Voici à quoi ressemble le dossier de mon projet de test :

$ tree -a
.
├── .opencode
│   └── opencode.json
└── foobar

2 directories, 2 files

$ cat .opencode/opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "agent": {
    "build": {
      "permission": {
        "bash": {
          "git *": "deny",
        }
      }
    },
  }
}

La commande git est interdite à l'agent build.

Je lance :

$ opencode run --agent="build" "exécute la commande unix 'git status'"

> build · deepseek-v4-flash

$ rtk git status
* No commits yet on main
?? .opencode/
?? foobar

Pas encore de commit sur `main`. Fichiers non suivis : `.opencode/` et `foobar`.

rtk a réussi à lancer la commande git status !

Voici un test sans rtk :

$ mv ~/.config/opencode/plugins/rtk.ts /tmp/rtk.ts
$ opencode run --agent="build" "exécute la commande unix 'git status'"

> build · deepseek-v4-flash

✗ git status failed
Error: The user has specified a rule which prevents you from using this specific tool call. Here are some of the relevant rules [{"permission":"*","action":"allow","pattern":"*"},{"permission":"bash","action":"allow","pattern":"*"},{"permission":"bash","pattern":"git *","action":"deny"}]

La commande `git status` est bloquée par une règle de permission qui interdit les commandes `git *` dans bash.

Souhaites-tu autoriser cette commande ?

Sans rtk, le système de permissions d'OpenCode fonctionne parfaitement, l'exécution de git status est interdite.

D'après mes recherches snip a le même problème de sécurité.

Je pense que pour le moment je vais arrêter d'utiliser rtk 🤔.

Cette après-midi, DeepSeek V4 Flash (via OpenCode) a fait une boulette dans mon projet homelab.sklein.xyz !

En voulant corriger le Helmfile de déploiement de Hindsight, il a lancé :

$ mise run destroy-cnpg-hindsight

sans réaliser que cette task Mise allait lancer la commande suivante :

helmfile -f helmfile/helmfile.yaml.gotmpl destroy

sans remarquer que mon fichier helmfile/helmfile.yaml.gotmpl contenait tous mes services et pas seulement cnpg-hindsight !

Ce qui est marrant, c'est qu'après le « Oups », il a tout de suite essayé de se rattraper. Heureusement, je suis au début de l'installation de mon homelab — rien d'important à perdre — et j'ai pu tester que la restauration du backup continu de CloudNativePG basé sur barman fonctionne bien.

DeepSeek V4 Flash n'est pas à blâmer : je ne l'ai pas aidé avec mes instructions, je lui ai tendu un piège.

Suite à cet incident sans gravité, j'ai pris conscience que faire travailler un agent de coding sur un projet d'Infrastructure as code est bien plus risqué que sur un projet de développement cloisonné, sans accès à la production.

J'ai commencé par ajouter ces quelques lignes dans mon fichier AGENTS.md :

## Safety Rules

- **Never run any `destroy-*` script or `helmfile destroy` command without explicit user confirmation** in the same conversation turn. Always ask first.
- If you must run `helmfile destroy`, always use `--selector name=<release>` to target only one release.
- When in doubt about a command's destructiveness, ask before executing.

Ensuite, j'ai remarqué que l'agent plan de OpenCode avait par défaut un accès trop large au tool bash pour un projet d'Infrastructure as code, je me suis lancé dans le renforcement des permissions :

{
  "$schema": "https://opencode.ai/config.json",
  "agent": {
    "plan": {
      "permission": {
        "bash": {
          "*": "ask",
          "kubectl get *": "allow",
          "kubectl describe *": "allow",
          "kubectl logs *": "allow",
          "kubectl top *": "allow",
          "tofu plan*": "allow",
          "tofu show*": "allow",
          "tofu output*": "allow",
          "tofu state*": "allow",
          "helm list*": "allow",
          "helm status*": "allow",
          "helm diff*": "allow",
          "helmfile *list*": "allow",
          "helmfile *status*": "allow",
          "helmfile *diff*": "allow",
          "git log*": "allow",
          "git diff*": "allow",
          "git status": "allow",
          "git show*": "allow",
          "jj log*": "allow",
          "jj diff*": "allow",
          "jj status": "allow",
          "ls*": "allow",
          "find*": "allow"
        }
      }
    }
  }
}

Ensuite, je me suis demandé s'il existait des solutions clé en main de limitation d'accès aux commandes cli, du même style que rtk, pour autoriser seulement des commandes de lecture sans risque.
#JaiDécouvert Prempti et agentsh. Je me suis demandé si l'intégration de l'un de ces outils n'allait pas entrer en conflit avec rtk. En étudiant les issues sur la sécurité de rtk, j'ai découvert que : rtk contourne le système de permissions d'OpenCode.

Il y a quelques jours, dans ma note "Setup Fedora CoreOS avec LUKS et TPM", je disais :

Attention, j'ai découvert que cette méthode n'est pas sécurisée en cas de vol physique du serveur !

Si un attaquant boot depuis un autre disque avec le même firmware et le même kernel, il pourra extraire en clair la clé LUKS stockée dans le TPM 🫣.

source

Une solution pour traiter ce point faible est d'utiliser un pin éloigné physiquement du serveur qui l'utilise.

Le framework Clevis utilise le terme "pins" pour désigner les différents méthodes de déverrouillage d'un volume LUKS.

Origine du mot "pin" ?
Claude Sonnet 4.5 m'a expliqué que le terme "pin", qui se traduit par "goupille" en français, désigne la pièce mécanique qui bloque l'ouverture d'un cadenat.

Par exemple, dans un contexte self hosting dans un homelab, je peux héberger physiquement un serveur dans mon logement et le connecter à un pin sur un serveur Scaleway ou sur un serveur dans le homelab d'un ami.

Les pins distants, accessibles via réseau, sont appelés serveurs Network-Bound Disk Encryption.

Si le serveur Network-Bound Disk Encryption est configuré pour répondre uniquement aux requêtes provenant de l'IP de mon réseau homelab, en cas de vol du serveur, le voleur ne pourra pas récupérer le secret permettant de déchiffrer le volume LUKS.

Dans le playground install-coreos-iso-on-qemu-with-luks-and-tang, j'ai testé avec succès le déverrouillage d'un volume LUKS avec un serveur Network-Bound Disk Encryption nommé tang.

Pour être précis, dans la configuration de ce playground, deux pins sont obligatoires pour déverrouiller automatiquement le volume : un pin tang et un pin TPM2. Le nombre minimum de pins requis pour le déverrouillage est défini par le paramètre threshold.

clevis, qui permet de configurer les pins et de gérer la récupération de la passphrase à partir des pins, utilise l'algorithme Shamir's secret sharing (SSS) pour répartir le secret à plusieurs endroits.

Voici quelques scénarios de conditions de déverrouillage que clevis permet de configurer grâce à SSS :

• TPM2 ou Tang serveur 1
• TPM2 et Tang serveur 1
• Tang serveur 1 ou Tang serveur 2
• 2 parmi Tang serveur 1, Tang serveur 2, Tang serveur 3
• ...

Si les conditions ne sont pas remplies, systemd-ask-password demande à l'utilisateur de saisir sa passphrase au clavier.

---

Je n'ai pas trouvé d'image docker officielle de tang. Toutefois, j'ai trouvé ici l'image non officielle padhihomelab/tang (son dépôt GitHub : https://github.com/padhi-homelab/docker_tang).
Dans mon playground, je l'ai déployé dans ce docker-compose.yml.

---

J'ai trouvé la configuration butane de tang simple à définir (lien vers le fichier) :

  luks:
    - name: var
      device: /dev/disk/by-partlabel/var
      wipe_volume: true
      key_file:
        inline: password
      clevis:
        tpm2: true
        tang:
          - url: "http://10.0.2.2:1234"
            # $ docker compose exec tang jose jwk thp -i /db/pLWwUuLhqqFb-Mgf5iVkwuV4BehG9vzd2SXGMyGroNw.jwk
            # pLWwUuLhqqFb-Mgf5iVkwuV4BehG9vzd2SXGMyGroNw
            thumbprint: dx9dNzgs-DeXg0SCBQW5rb7WQkSIN1B8MIgcO6WxJfI
        threshold: 2 # TMP2 + Tang (or passphrase keyboard input)

La seule complexité que j'ai rencontrée est la méthode pour récupérer le paramètre thumbprint de l'instance tang.

Voici la méthode que j'ai utilisée :

$ docker compose exec tang jose jwk thp -i /db/pLWwUuLhqqFb-Mgf5iVkwuV4BehG9vzd2SXGMyGroNw.jwk
pLWwUuLhqqFb-Mgf5iVkwuV4BehG9vzd2SXGMyGroNw

Autre difficulté, il faut ajouter les arguments kernel suivants pour activer l'accès réseau dès le début du process de boot afin de permettre à clevis d'accéder au serveur tang :

variant: fcos
version: 1.6.0
kernel_arguments:
  should_exist:
    - ip=dhcp
    - rd.neednet=1

---

J'ai intégré au README.md du playground une section nommée "How to switch from 2 required ping to 1 or the opposite?", pour documenter comment modifier à chaud la configuration clevis.
Par exemple pour changer de serveur tang ou modifier le nombre de pins nécessaires pour déverrouiller la partition chiffrée.

---

Il est conseillé d'activer le pin TPM2 en complément de tang pour éviter ce type d'attaque décrit par Claude Sonnet 4.5 :

Imaginons un admin malveillant dans ton entreprise :

• Il a accès physique aux serveurs
• Il a accès au réseau (donc au serveur Tang)
• Il clone un disque pendant la nuit
• Il essaie de le monter sur sa propre machine pour extraire des données

Tang seul : ❌ Il réussit
TPM + Tang : ✅ Il échoue

Claude Sonnet 4.5

---

À noter que l'instance tang ne contient pas la passphrase et ne voit jamais passer la passphrase via son API.
Voici les explications que m'a données Claude Sonnet 4.5 :

Tang ne stocke pas la passphrase secrète de chiffrement LUKS. C'est justement tout l'intérêt de cette solution !

Voici comment ça fonctionne :

Le principe de Tang + Clevis

1. Génération de clé dérivée : Clevis (le client) contacte le serveur Tang et récupère sa clé publique
2. Chiffrement avec la clé de Tang : Clevis utilise cette clé publique pour chiffrer la passphrase LUKS
3. Stockage local : La passphrase chiffrée est stockée localement dans l'en-tête LUKS du disque (pas sur le serveur Tang)
4. Déchiffrement au boot :

• La machine contacte Tang
• Tang utilise sa clé privée pour aider à déchiffrer
• La passphrase LUKS est reconstituée
• Le disque est déverrouillé

Ce que Tang sait et ne sait pas

• ❌ Tang ne connaît jamais votre passphrase LUKS
• ❌ Tang ne stocke rien concernant vos clés
• ✅ Tang fournit juste un service cryptographique (un oracle de déchiffrement)
• ✅ C'est un serveur sans état (stateless)

C'est du chiffrement asymétrique avec un mécanisme appelé "network-bound disk encryption" : le disque ne peut être déchiffré que si la machine peut contacter le serveur Tang sur le réseau.

Claude Sonnet 4.5

---

Voici quelques ressources supplémentaires au sujet des techniques de déverrouillage automatique des volumes LUKS :

• Fedora Magazine - Using Linux System Roles to implement Clevis and Tang for automated LUKS volume unlocking
• Conférence lors du FOSDEM 2017 : Securing Automated Decryption New Cryptography and Techniques
• Disk encryption: LUKS ( Linux Unified Key Setup) with Tang · Posts · Jeff’s note

Comme je l'ai dit dans cette précédente note, jusqu'il y a peu de temps, je ne m'étais jamais intéressé et j'avais même évité les technologies liées aux trusted computing.

Il y quelques jours, j'ai testé avec succès l'installation d'une Fedora CoreOS avec une clé de déchiffrement LUKS sauvegardée dans une puce TPM2 à l'aide de clevis.

Grâce à TPM, cette configuration évite de devoir saisir la clé de déchiffrement au moment du boot de l'OS.
Je trouve cette approche particulièrement pertinente sur une distribution CoreOS qui utilise zincati pour appliquer automatiquement les mises à jour de l'OS à des horaires définis (voir note à ce sujet).

---

Pour tester cette configuration, j'ai créé le playground install-coreos-iso-on-qemu-with-luks , qui me permet de tester localement l'installation dans une VM QEMU.
Pour émuler le TPM2, j'utilise swtpm et le BIOS UEFI Open source edk2-ovmf .

Dans ce test, j'ai choisi de créer et de chiffrer une partition pour stocker les données du dossier /var/, qui sur CoreOS est l'emplacement qui contient les données mutables (accessibles en écriture).

Voici la configuration butane de LUKS encryption avec les options TPM2 et clevis que j'ai utilisées (fichier complet) :

storage:
  disks:
    - device: /dev/nvme0n1
      wipe_table: false
      partitions:
        - number: 4
          label: root
          size_mib: 15000
          resize: true
        - number: 5
          label: var       <=== label
          size_mib: 0  # 0 = use all remaining space

  luks:
    - name: var            <=== label
      device: /dev/disk/by-partlabel/var
      wipe_volume: true
      key_file:
        inline: password
      clevis:
        tpm2: true
        
  filesystems:
    - path: /var
      device: /dev/mapper/var
      format: xfs
      wipe_filesystem: true
      label: var
      with_mount_unit: true

Je trouve le contenu de ce fichier de configuration assez simple et explicite.

---

J'ai ensuite créé un second playground install-coreos-iso-on-baremetal-with-luks.

L'installation automatique s'est déroulée sans problème sur un serveur baremetal.

J'ai testé la désactivation de TPM2 dans le BIOS : la console m'a alors demandé de saisir la clé manuellement. C'est plutôt pratique en cas de problème TPM, branchement du disque sur une autre machine…

La clé de chiffrement LUKS n'est pas stockée en clair dans le fichier ISO, il n'est donc pas nécessaire de sécuriser l'accès à ce fichier.

---

Attention, j'ai découvert que cette méthode n'est pas sécurisée en cas de vol physique du serveur !

Si un attaquant boot depuis un autre disque avec le même firmware et le même kernel, il pourra extraire en clair la clé LUKS stockée dans le TPM 🫣.

D'après mes recherches, la seule approche qui semble permettre à la fois la protection contre le vol physique et le reboot automatique serait d'utiliser clevis avec un serveur tang plutôt que le TPM.

Je compte tester cette configuration dans les prochaines semaines (depuis, cette note a été publiée : Setup Fedora CoreOS avec LUKS et Tang).

#JaiDécouvert le nom officielle de Evil maid attack (from "Is luks unlock with TPM2 more secure?").

#JaiDécouvert Cold boot attack (from "ArchWiki - Trusted Platform Module").

Comme beaucoup de libristes, en 2002, j'ai été effrayé par le projet Palladium de Microsoft.

Palladium (NGSCB) était une initiative Microsoft annoncée en 2002 pour créer une plateforme de "trusted computing" basée sur du matériel sécurisé (une puce TPM dédiée) contrôlant strictement quels logiciels pouvaient s'exécuter et quels périphériques étaient autorisés à communiquer avec le système. L'objectif était de permettre à Microsoft de certifier cryptographiquement l'intégrité de toute la chaîne matérielle et logicielle, depuis le démarrage de l'ordinateur jusqu'aux applications en cours d'exécution.

On imaginait des scénarios concrets comme une carte son qui refuserait de capturer de l'audio depuis une sortie protégée par DRM, ou une carte graphique qui bloquerait la capture d'écran de contenu vidéo protégé.

À cette époque, Microsoft était en position hégémonique écrasante sur le marché des ordinateurs personnels : MacOS d'Apple représentaient moins de 3% des parts de marché.
Palladium représentait concrètement une forme de totalitarisme numérique sous contrôle total de Microsoft et des ayants droit.

Pour la communauté du libre, cela signifiait concrètement que ce système pourrait empêcher l'exécution de systèmes d'exploitation libres, bloquer l'accès aux périphériques sans drivers signés par Microsoft, et conduire à une génération d'ordinateurs où Linux serait techniquement banni ou très difficile à installer.

Heureusement, les critiques venues de toutes parts , combinées aux accusations de monopole et aux risques antitrust, ont contraint Microsoft à faire marche arrière. Cela a abouti à la situation actuelle où le TPM est davantage orienté vers la sécurité que vers le DRM et la restriction des libertés des utilisateurs.

Cet épisode a eu des conséquences durables pour moi : depuis, dès que j'entendais parler de puce de sécurité ou de TPM, j'avais immédiatement une réaction de rejet, parce que cela évoquait pour moi vendor lock-in, restrictions et contrôle par Microsoft. Je n'ai jamais cherché à en savoir plus.

C'est seulement en septembre 2025, lors de mon exploration du filesystem fs-verity, que j'ai découvert que les fonctionnalités du TPM2 sont en réalité très intéressantes et peuvent servir des objectifs de sécurité légitimes, très bien supportées par Linux.

Mon objectif du weekend est d'avancer sur le Projet 34 - "Déployer un cluster k3s et Kubevirt sous CoreOS dans mon Homelab".

Je veux apprendre à configurer LUKS encryption sous CoreOS avec un démarrage automatique basé sur TPM2 via clevis.

Je veux aussi m'assurer qu'en cas de problème, je peux toujours monter la partition chiffrée en saisissant manuellement la clé secrète.

Dans l'article "Hetzner Considered Hostile: A PSA", j'ai découvert le terme anglais Threat actor et son article Wikipedia : Threat actor.

Qui peut être traduit en français par "acteurs malveillants ou "acteurs de menace".

#JaiDécouvert le site Formation DevOps | DevSecOps de Stéphane Robert. Énormément d'informations très bien catégorisées et en français !

J'ai parcouru la section Analyser le code ! et j'y ai découvert :

• Checkov
• Grype
• Trivy

Alexandre m'a partagé l'article "Linux : Enregistrer toutes les commandes saisies avec auditd" qui présente Linux Audit.

The Linux audit framework provides a CAPP-compliant (Controlled Access Protection Profile) auditing system that reliably collects information about any security-relevant (or non-security-relevant) event on a system. It can help you track actions performed on a system.

-- from

La norme de sécurité de l'industrie des cartes de paiement (Payment Card Industry Data Security Standard ou PCI DSS) est un standard destiné à poser les normes de la sécurité des systèmes d'information amenés à traiter et stocker des process ou des informations relatives aux systèmes de paiement.

Dans ce cadre, de nombreuses conditions sont à respecter afin d'être compatible avec cette norme. Parmi celles-ci, l'enregistrement des commandes et instructions saisies par les utilisateurs à privilèges sur un système.

-- from

D'après ce que j'ai compris, la fonctionnalité Linux Audit est implémentée au niveau du kernel.

Linux Audit permet de surveiller les actions effectuées sur les fichiers (lecture, écriture…) et les appels syscalls.

D'après ce que je comprends, Linux Audit est conçu à des fins de sécurité. Il semble peu adapté pour documenter les opérations réalisées sur un serveur dans le cadre d'un travail collaboratif.

#JaiDécouvert restic-exporter : « Prometheus exporter for the Restic backup system ».

#JaiLu L'option ControlMaster de ssh_config.

J'y ai découvert l'open ControlMaster de OpenSSH.

#JaiLu Google Authenticator - ArchWiki.

Code source de Google Authenticator PAM module : https://github.com/google/google-authenticator-libpam.

#JaiLu Securing A Linux Server.

J'ai trouvé cet article excellent.

J'y ai découvert :

• ipsum ;
• maltrail ;
• Scam-Blocklist
• blocklist-abuseipdb
• https://github.com/teler-sh/teler

J'ai un peu parcouru la documentation de OpenBao, #JaimeraisUnJour faire un POC de cet outil.

#JaiLu ces threads Lobster : Security best practices for small company, SSH Key Management Challenges and Requirements.

#JaiLu The SOC2 Starting Seven (from)

First: for us, SOC2 is about sales. You will run into people with other ideas of what SOC2 is about. Example: “SOC2 will help you get your security house in order and build a foundation for security engineering”. No. Go outside, turn around three times, and spit. Compliance is a byproduct of security engineering. Good security engineering has little to do with compliance. And SOC2 is not particularly good. So keep the concepts separate.

-- from

😉

Suite à cela, j'ai lu l'article Wikipédia sur System and Organization Controls.

This is not an instruction guide for getting SOC2-certified. Though: that guide would be mercifully short: “find $15,000, talk to your friends who have gotten certified, get referred to the credible auditor that treated your friends the best, and offer them the money, perhaps taped to the boom box playing Peter Gabriel you hold aloft outside their offices”.

-- from

😉

If there is one thing to understand about SOC2 audits, it’s: SOC2 is about documentation, not reality.

-- from

🙈

Puis ils vous remettront un questionnaire de 52 000 lignes appelé Liste de demandes d'informations (IRL), basé d'une manière occulte sur ce que vous leur avez dit que vous faisiez. Vous le remplirez. Vous aurez quelques réunions, puis vous leur enverrez un chèque. Le nom de votre entreprise figurera sur un rapport.

-- from

🙈

#JaiDécouvert Shibboleth.

PRs, Protected Branches, and CI/CD

Enable Protected Branches for your master/deployment branches in Github. Set up a CI system and run all your deploys through it. Require reviews for PRs that merge to production. Make your CI run some tests; it probably doesn’t much matter to your auditor which tests.

We probably didn’t even need to tell you this. It’s how most professional engineering shops already run. But if you’re a 3-person team, get it set up now and you won’t have to worry about it when your team sprawls and new process is a nightmare to establish.

-- from

J'implémente systématiquement ce workflow dès que je travaille en équipe. Cependant, je me demande à partir de combien de développeurs cela devient réellement pertinent. Avant de lire cet article, je pensais que cela valait la peine à partir de trois développeurs.
À noter que ma motivation première de mise en place de ce workflow n'est pas la sécurité, mais la fluidité de développement en équipe et d'éviter les bugs.

Centralized Logging

Sign up for or set up a centralized logging service. It doesn’t matter which. Pipe all your logs to it. Set up some alerts – again, at this stage, it doesn’t matter which; you just want to build up the muscle.

-- from

Pour cela, j'utilise Grafana avec Loki branché sur un Object Storage.

The AWS console is evil. Avoid the AWS console.

Instead, deploy everything with Terraform (or whatever the cool kids are using, but it’s probably still just Terraform). Obviously, keep your Terraform configs in Github.

C'est aussi l'une de mes premières motivations pour utiliser Terraform ! 😊

#JaiDécouvert Munki, MicroDMD, NanoMDM qui sont des MDM.

Web Application Firewalls: Most SOC2’d firms don’t use them, and most WAFs don’t work at all.

-- from

🙂

Endpoint Protection and AV: You have MDM and macOS/Windows full complement of security features and a way to force them enabled, you’re covered. AV software is a nightmare; avoid it while you can.

-- from

🙂

Alexandre m'a partagé OpenSCAP mais je n'ai pas encore pris le temps de l'étudier.

#OnMaPartagé ce projet https://pts-project.org/ :

The PiRogue Tool Suite is an open-source consensual digital forensic analysis and incident response solution that empowers organizations with comprehensive tools for network traffic analysis, mobile forensics, knowledge management, and artifact handling.

J'ai l'impression que c'est un outil lié à la sécurité informatique, mais après une première lecture de 2min, je ne comprends pas très bien ni son utilité ni son usage 🤔.

https://github.com/anchore/grype

https://www.checkov.io/

• [ ] https://github.com/bunkerity/bunkerweb

Date de création de cette note : 2024-10-11.

Quel est l'objectif de ce projet ?

Je souhaite implémenter et publier un projet de "référence", de type skeleton, dont la fonction est d'installer les éléments de base d'un serveur Ubuntu LTS sécurisé.

Comme point de départ, je peux utiliser mon repository poc-bash-ssh-docker-deployement-example et le faire évoluer.

Le script _install_basic_server_configuration.sh se contente d'installer Docker.

J'aimerais y intégrer les recommandations présentes dans l'excellent article "Securing A Linux Server".

J'aimerais, entre autres, ajouter les fonctionnalités suivantes :

• [x] Amélioration de la configuration de OpenSSH ;
• [x] Installation et configuration de ufw ;
• [x] Mise en place de ipsum ;
• [x] Installation et configuration de fail2ban ;
• [x] Système d'installation / suppression de clés ssh ;
• [x] En option : installation et configuration de node exporter ;
• [x] En option : installation et configuration de l'envoi des logs de journald et Docker vers Loki en utilisatant Promtail (installation et configuration de l'envoi des logs de journald vers Loki en utilisant Vector) ;
• [x] En option : installation de configuration de Grafana ; avec Grizzly configuration des dashboards
  • [x] des logs et
  • [x] metrics des serveurs
• [x] En option : installer et configurer apticron pour envoyer un message dans les logs dès qu'un package de sécurité doit être installé.
  • [x] Génération d'une alerte Grafana si une mise à jour de sécurité doit être installé
• [x] En option : envoie de notification sur smartphone en cas d'alerte Grafana, via ntfy
• [ ] En option : installation et configuration de Linux Audit ;

Le repository doit présenter cette installation :

• [x] via Vagrant
• [ ] sur un Virtual machine Scaleway avec Terraform

Repository de ce projet :

• basic_ubuntu_server_install_playground

Ressources :

• poc-bash-ssh-docker-deployement-example
• "Securing A Linux Server"

https://fr.wikipedia.org/wiki/Norme_de_sécurité_de_l'industrie_des_cartes_de_paiement

https://fr.wikipedia.org/wiki/OpenSSH

https://complianceascode.readthedocs.io/en/latest/manual/user/01_introduction.html

Site web : https://people.redhat.com/sgrubb/audit/

GitHub : https://github.com/linux-audit/audit-userspace

https://fr.wikipedia.org/wiki/Fail2ban

https://manpages.debian.org/bookworm/apticron-systemd/apticron.1.en.html

https://github.com/stamparm/ipsum

Daily feed of bad IPs (with blacklist hit scores).

The PostgreSQL Audit Extension (pgAudit) provides detailed session and/or object audit logging via the standard PostgreSQL logging facility.

The goal of the pgAudit is to provide PostgreSQL users with capability to produce audit logs often required to comply with government, financial, or ISO certifications.

Page GitHub : https://github.com/pgaudit/pgaudit

https://en.wikipedia.org/wiki/Uncomplicated_Firewall

https://github.com/aquasecurity/trivy

https://github.com/topics/hardening

Émulateur TPM.

Dépôt GitHub : https://github.com/stefanberger/swtpm

Article Wikipedia : https://en.wikipedia.org/wiki/Evil_maid_attack

tang est un serveur Network-Bound Disk Encryption léger et sans état.

Dépôt GitHub : https://github.com/latchset/tang

Voir aussi TPM, LUKS, clevis.

tang est un projet créé par Red Hat, dans l'équipe The latchset Organization.

Le framework Clevis utilise le terme "pins" pour désigner les différents méthodes de déverrouillage d'un volume LUKS.

Origine du mot "pin" ?
Claude Sonnet 4.5 m'a expliqué que le terme "pin", qui se traduit par "goupille" en français, désigne la pièce mécanique qui bloque l'ouverture d'un cadenat.

Cliquez ici pour voir la liste des pins supportées par Clevis.

Article Wikipedia : https://en.wikipedia.org/wiki/SQL_injection

Article Wikipedia : https://fr.wikipedia.org/wiki/MISC_(magazine)