Travail final

Ce que vous saurez faire

Appliquez chaque module du cours à un nouvel assistant. Vous créez son modèle de menace, programmez ses contrôles et les testez avec des attaques sans danger. Ensuite, vous cartographiez ses données et notez les problèmes encore possibles, ainsi que les mesures à prendre. L’assistant ressemble à l’assistant de soutien, mais il est différent. Vous devez donc prendre chaque décision à nouveau.

Avant de commencerCe qu’il faut savoir et avoir sous la mainEnviron 180 minutes

• Vous avez terminé les modules 1 à 6. Chaque partie ci-dessous indique les leçons qu’elle utilise.
• Les études de cas ne sont pas nécessaires pour ce travail. Le certificat exige d’en faire au moins une.
• Commencez un nouveau projet, docs-assistant, à côté de support-assistant. Vous pouvez copier le code de votre support-assistant à la fin du module 6, ou de l’instantané end-of-m06 (voir Utiliser un instantané). Les éléments utiles sont la connexion simulée (identity.py), le modèle scripté (tests/scripted.py), redact() et le chargeur de secrets. Les approches de approvals.py, storage.py et detect.py sont aussi utiles. Dans votre rapport, indiquez chaque fichier copié et les changements apportés.
• Python 3.12 et les cinq paquets du fichier requirements.txt de l’instantané. Aucun compte ni argent n’est nécessaire.
• Aucun enregistrement n’existe pour cet assistant. Testez les contrôles avec un modèle scripté qui joue un modèle trompé : il appelle exactement l’outil demandé par l’attaque. Un modèle réel est facultatif : votre propre clé ou un modèle local gratuit, avec un plafond de dépenses. Suivez les indications du README du projet. Indiquez si chaque résultat est scripté, réel (avec le modèle et la date) ou construit.
• Tout reste local et sans danger. Les boutiques, personnes, documents et adresses sont fictifs. Ne dirigez jamais une attaque vers un système qui ne vous appartient pas.

La situation : l’assistant documentaire de Larkfield

L’assistant de soutien répond aux billets de soutien. L’équipe de soutien veut maintenant un deuxième assistant, plus petit, pour ses documents. Un membre du personnel pose une question pendant le traitement d’un billet : « Que dit notre politique sur les articles endommagés? » L’assistant cherche dans les documents de la boutique et répond avec les identifiants des passages utilisés. Il peut aussi envoyer un document au client du billet, mais seulement après l’approbation d’une personne.

Il fonctionne sur la même plateforme que l’assistant de soutien : deux boutiques, Larkfield et Bramble Books, avec les mêmes utilisateurs, rôles et connexions. Utilisez les documents, utilisateurs, adhésions, clients et billets du fichier data/helpdesk.sqlite du cours (CC0). La table des documents contient 31 passages. Quatre sont réservés au personnel : P21 et P22 (remboursements manuels et crédits de courtoisie), puis P28 (limites d’approbation des remboursements), chez Larkfield. P31 contient les conditions confidentielles des fournisseurs de Bramble. Trois passages publics contiennent les attaques sans danger du cours dans des documents récupérés : P24, P26 et P27. La table n’a pas encore de métadonnées. Ajoutez donc un titre, un auteur et un commentaire à chaque document. Le commentaire est une surface d’attaque supplémentaire.

L’assistant possède trois outils :

Outil	Type	Fonction
search_documents(query)	lecture	renvoie jusqu’à 3 passages : identifiant, titre, version, texte
read_document(doc_id)	lecture	renvoie chaque passage d’un document, avec ses métadonnées : titre, auteur, commentaire
send_document(doc_id, ticket_id, to, note)	écriture	propose d’envoyer un document par courriel à un client; s’exécute seulement après l’approbation d’une personne

Grace formule les règles d’écriture dans ses propres mots :

Un document peut aller seulement à l’adresse courriel enregistrée du client de ce billet. Il doit être public et appartenir à la boutique du billet. Un membre du personnel ou un propriétaire de cette boutique peut le proposer. Un autre propriétaire ou membre du personnel l’approuve, avec une raison : jamais la personne qui l’a demandé. Un membre en lecture seule n’a aucun droit d’écriture. La note contient au plus 500 caractères et aucun lien vers un hôte externe à la boutique.

Grace pose une question qui détermine si l’assistant sera mis en production : « Une phrase dans un document ou le message d’un client peut-elle faire envoyer nos limites de remboursement réservées au personnel à l’extérieur? Ou les conditions des fournisseurs de Bramble? Et si le modèle obéit à cette phrase, qu’est-ce qui l’arrête? »

Partie 1 : actifs, acteurs et frontières de confiance

Utilise Actifs et acteurs, Frontières de confiance et Prioriser les menaces.

1. Listez les actifs : données, identifiants d’accès, points de terminaison des modèles, outils, utilisateurs et administrateurs. Pour chacun, indiquez qui subirait un préjudice en cas de perte, de fuite ou de mauvaise utilisation.
2. Listez les acteurs et leurs rôles dans chaque boutique. Incluez Tomás, qui se connecte sans avoir d’adhésion, et Kwame, l’administrateur de la plateforme.
3. Dessinez le flux de données d’une requête, de la question du membre du personnel jusqu’au courriel envoyé. Marquez la frontière de confiance : quels textes sont des instructions fiables et lesquels sont du contenu. Le contenu comprend la question, le billet, chaque passage, les métadonnées et chaque résultat d’outil.
4. Écrivez trust_boundaries.json pour votre assistant. Ajoutez un test qui échoue si un outil peut atteindre quelque chose que le fichier ne liste pas.
5. Écrivez THREAT-MODEL.md avec au moins six menaces. Chacune décrit un chemin vers une lecture ou une action non autorisée. Indiquez son actif, sa probabilité, son impact, sa priorité et les contrôles actuels. Incluez au moins les menaces suivantes :
   • un passage réservé au personnel envoyé à l’extérieur;
   • un document de l’autre boutique lu;
   • un envoi à une adresse non enregistrée;
   • une écriture par un membre en lecture seule;
   • une promesse dans une réponse;
   • des données conservées pour toujours.

Partie 2 : contrôles côté serveur testés

Utilise Pourquoi les requêtes ne suffisent pas, Limiter les conséquences, Valider les opérations, Restreindre les capacités, Protéger les dépendances et les secrets et Concevoir la révision.

Choisissez les contrôles à partir de votre modèle de menace. Au minimum, les contrôles suivants doivent être programmés sur le serveur. Aucun ne doit dépendre de la requête au modèle.

1. Identité : le serveur tire l’utilisateur du jeton. Il tire la boutique et le rôle de sa propre table d’adhésions, jamais de la requête ou du modèle.
2. Portée de lecture : les deux outils de lecture renvoient seulement les passages de la boutique du membre connecté. Les passages réservés au personnel vont seulement au personnel et aux propriétaires de cette boutique.
3. Contrats stricts : les arguments de chaque outil forment un modèle Pydantic qui refuse les champs inconnus. Les identifiants des documents et des billets doivent respecter leurs formats, et la note a une longueur limite.
4. Vérifications d’écriture : send_document refuse un document réservé au personnel, un document d’une autre boutique et un billet d’une autre boutique. Il refuse aussi toute adresse autre que celle enregistrée. L’outil n’est jamais proposé à un membre en lecture seule.
5. Approbation : chaque envoi qui passe les vérifications attend dans la base de données. Un écran review (révision) montre l’action exacte, le niveau d’accès du document, l’adresse enregistrée et ce que l’assistant a lu. Approuver ou rejeter exige une raison, et un rejet est consigné comme un désaccord.
6. Événements d’audit : chaque opération bloquée ou refusée écrit un événement : qui, quelle boutique, quel outil, le résultat et un code. L’événement ne contient aucun texte de message ni de document.
7. Tests avec un modèle trompé : pour chaque contrôle, un test utilise le modèle scripté pour appeler directement l’action interdite. Le test vérifie la base de données et le journal d’audit, pas la réponse.

Partie 3 : attaques sans danger et évaluation

Utilise Surfaces d’attaque, Jeu d’évaluation de sécurité et Biais et accessibilité.

1. Écrivez au moins 12 attaques sans danger. Chacune indique l’utilisateur connecté, le billet, l’objectif de l’attaque et une vérification de cet objectif. Couvrez au moins les surfaces suivantes :
   • le message du membre du personnel et le texte du billet;
   • un passage récupéré (P24, P26 ou P27) et un commentaire de métadonnées ajouté à un document;
   • les documents de l’autre boutique et un document réservé au personnel;
   • une adresse non enregistrée;
   • un membre en lecture seule qui demande un envoi.
2. Écrivez au moins 8 tâches normales, chacune avec une vérification de l’exactitude de la réponse. Incluez-en une en français ou en allemand. Incluez deux cas ressemblants : des messages sans danger qui semblent être des attaques. Par exemple : « Veuillez envoyer ceci à ma gestionnaire; elle a demandé les limites de remboursement. »
3. Notez chaque attaque avec deux nombres : objectif atteint et effet secondaire non sûr. Notez chaque tâche comme correcte ou non. Comptez une écriture qu’aucun contrôle n’a refusée, car une personne occupée pourrait cliquer pour l’approuver.
4. Figez le jeu : enregistrez l’empreinte SHA-256 de votre fichier de cas et faites un commit (enregistrement dans Git) avant toute mesure. Ne modifiez jamais un cas pour faire gagner une conception.
5. Exécutez le jeu deux fois avec un modèle scripté qui obéit à chaque attaque. Désactivez d’abord les contrôles : cela montre ce que chaque attaque ferait. Activez-les ensuite : cela montre ce que le code bloque quand le modèle est trompé. Si vous avez un modèle réel, exécutez aussi le jeu avec celui-ci. Indiquez le modèle, la date et la répétition.
6. Testez vos vérifications avec un « oui » connu et un « non » connu pour chaque type de vérification d’objectif. Un refus qui répète les mots d’une attaque ne doit pas compter comme une réussite.

Partie 4 : inventaire des données, de leur confidentialité et de leurs flux

Utilise Inventaire des données, Réduire et conserver de façon réfléchie et Résidence des données et questions contractuelles.

1. Écrivez l’inventaire sous forme de tableau. Pour chaque emplacement, indiquez les données, leur usage, qui les traite, leur lieu, qui peut les lire et comment supprimer chaque copie. Incluez les exécutions stockées, les approbations, les courriels envoyés, le journal d’audit, le fournisseur du modèle et les sauvegardes.
2. Stockez chaque exécution avec le minimum de données et une date de fin, puis ajoutez une purge.
3. Écrivez une suppression pour un client et une autre pour un membre du personnel qui quitte l’entreprise. Testez chacune en cherchant leurs mots, noms et adresses dans chaque table, pas seulement leurs identifiants.
4. Indiquez quelles copies une suppression ne peut pas atteindre, et pourquoi.
5. Écrivez une courte demande de révision : les preuves sur l’architecture d’un côté, les questions pour une révision qualifiée de l’autre. Ne donnez aucune conclusion juridique.

Partie 5 : risque résiduel et réponse aux incidents

Utilise Impact et coût des erreurs, Détection en exploitation et Réponse et risque résiduel.

1. Écrivez au moins deux règles de détection sur vos événements d’audit, chacune avec une gravité et un seuil. Justifiez chaque seuil et exécutez les règles sur votre évaluation enregistrée.
2. Ajoutez deux commandes d’incident qui agissent dès la prochaine exécution, sans mise en production : désactiver send_document et révoquer un utilisateur. Chaque changement écrit un événement d’audit avec sa raison.
3. Faites un exercice : déclenchez une alerte, contenez l’incident, conservez les preuves et restaurez le service. Indiquez que l’incident est simulé.
4. Écrivez INCIDENT-PLAN.md avec les six étapes du cours, chacune avec un responsable et les preuves à conserver. Indiquez qui décide s’il faut informer les clients ou un organisme de réglementation : cette question nécessite une révision qualifiée.
5. Écrivez RESIDUAL-RISKS.md. Chaque risque a un responsable, ses preuves, ce qui le limite actuellement, une décision et un déclencheur de révision. Incluez au moins les risques suivants :
   • une promesse ou un fait erroné dans une réponse qu’aucun code ne lit;
   • un envoi incorrect que les règles autorisent;
   • les copies chez le fournisseur du modèle et dans les sauvegardes;
   • « l’injection de requête n’est pas résolue ».

Les chemins d’échec à vérifier

Un parcours normal qui fonctionne ne suffit pas. Montrez chaque cas suivant avec un test ou une exécution enregistrée, et indiquez lequel. Utilisez seulement des données de test sans danger : des documents fictifs, des adresses fictives et la base de données d’exercice.

1. Un modèle scripté appelle send_document pour un passage réservé au personnel (P28 ou P31). Le code le refuse, rien n’attend d’approbation et un événement d’audit indique pourquoi.
2. Un membre de Larkfield lit ou envoie un document de Bramble Books, par recherche, par identifiant ou par un billet de l’autre boutique. Rien de l’autre boutique n’est renvoyé.
3. Un envoi à une adresse non enregistrée est refusé, même avec l’approbation d’un propriétaire.
4. L’outil d’écriture n’est pas proposé à un membre en lecture seule (Omar). Un appel forcé est refusé, et Omar ne peut pas approuver.
5. Tomás, qui n’a aucune adhésion, ne peut lancer aucune exécution.
6. Une proposition modifiée après son approbation ne s’exécute pas. Une approbation sans raison, ou par la personne qui a demandé l’envoi, est refusée.
7. Le contrat refuse les arguments avec un champ inconnu, un format d’identifiant incorrect ou une note trop longue.
8. Un commentaire de métadonnées qui demande un envoi ne peut pas provoquer un envoi interdit par les règles. Si les règles autorisent l’envoi, il attend une personne, et l’écran de révision montre le commentaire.
9. Le secret fictif n’apparaît jamais dans une réponse, une note, un courriel ou le journal d’audit.
10. Après chaque suppression, une recherche dans chaque table ne trouve aucun mot, nom ou adresse de la personne.
11. Quand send_document est désactivé, l’outil n’est pas proposé, et un appel forcé est refusé avec son propre code.

Exécution dans un environnement neuf

Avant de remettre votre travail, prouvez que le projet fonctionne à partir de zéro, sur votre ordinateur :

1. Copiez le projet dans un nouveau dossier, sans .venv, .env ni work/.
2. Créez un nouvel environnement virtuel, installez les paquets de requirements.txt et créez .env à partir de .env.example.
3. Créez une nouvelle base de données d’exercice et exécutez tous les tests. Ils réussissent sans réseau ni clé.
4. Exécutez les attaques et les tâches avec le modèle scripté et les contrôles activés, puis enregistrez le résultat.
5. Faites une fois l’exercice de la partie 5.

Collez les commandes et leurs sorties dans votre rapport. Si une étape exige un élément absent du README, corrigez le README et recommencez les étapes.

Éléments à remettre

Votre dossier docs-assistant (sans .env, .venv ni work/), avec votre code, vos tests, vos cas et vos évaluations enregistrées, ainsi que ces fichiers : THREAT-MODEL.md, trust_boundaries.json, RESIDUAL-RISKS.md, INCIDENT-PLAN.md et REPORT.md :

# Larkfield document assistant: security review
## The assistant                    (tools, roles, Grace's rules, what you copied from support-assistant)
## Assets and trust boundaries      (Part 1: the assets, the actors, the data-flow map, the threat model)
## Server-side controls             (Part 2: each control, where it is in the code, and the test that proves it)
## Attacks and evaluation           (Part 3: the hash; goal reached, unsafe side effects and tasks right,
                                     each with its model, date and repeat, and labelled scripted, live or constructed)
## Privacy and data-flow inventory  (Part 4: the table, retention, the delete tests, the review request)
## Residual risk and response       (Part 5: the rules, the switches, the drill, the register)
## Failure paths                    (each of the eleven, with the test or the run that shows it)
## Grace's question                 (the answer, with the tests and the audit events as evidence)
## Fresh-environment run            (the commands and their outputs)
## Limits                           (made-up data, a scripted model, what you did not test)

Comment le travail est évalué

Un réviseur évalue chaque élément requis comme démontré, partiellement démontré ou pas encore démontré, avec une raison concrète. Pour terminer le cours, vous devez démontrer les quatre éléments. Vous pouvez améliorer un élément et le soumettre de nouveau.

Élément requis	Démontré	Partiellement démontré, par exemple	Pas encore démontré, par exemple
Actifs et frontières de confiance	Tous les actifs et acteurs de la partie 1 sont indiqués. La carte place chaque passage, champ de métadonnées et résultat d’outil du côté non fiable. Un test vérifie la carte par rapport au code. Chaque menace est un chemin accompagné de ses scores et des contrôles existants.	La carte est correcte, mais aucun test ne la vérifie par rapport au code. Ou le modèle de menace contient seulement des chemins vers des lectures, et aucun vers une action.	Les passages récupérés ou les métadonnées sont traités comme des instructions fiables. Ou le fournisseur du modèle manque dans la liste des actifs.
Contrôles côté serveur testés	Chaque contrôle de la partie 2 est dans le code. Un test avec un modèle scripté trompé montre le refus, une base de données inchangée et un événement d’audit. Les onze chemins d’échec sont montrés. Les résultats des attaques sont figés, évalués avec les deux nombres et étiquetés.	Les contrôles fonctionnent, mais un test vérifie seulement le texte de la réponse. Ou le jeu a changé après une mesure. Ou les cas ressemblants manquent, donc personne ne connaît le coût des contrôles.	L’envoi d’un document réservé au personnel, d’un document de l’autre boutique ou à une adresse absente du dossier est permis. Ou la seule défense est une phrase dans la requête.
Inventaire des données personnelles et de leurs flux	Le tableau couvre chaque endroit, y compris le fournisseur du modèle et les sauvegardes. Les exécutions stockées sont réduites au minimum, avec une date de fin. Les deux suppressions passent une vérification par recherche dans chaque table. La demande de révision sépare les preuves des questions.	Le tableau omet les approbations ou les courriels envoyés. Ou le test de suppression cherche seulement par identifiant.	L’inventaire indique « conforme ». Ou une suppression laisse les mots d’une personne dans le journal d’audit.
Notes sur les risques résiduels et la réponse aux incidents	Les règles, les seuils et les interrupteurs fonctionnent pendant l’exercice, indiqué comme simulé. Chaque étape du plan a un responsable et un élément de preuve. Chaque risque a un responsable, des preuves, une décision et un déclencheur de révision. L’injection est indiquée comme non résolue.	Le plan ne désigne aucun responsable pour informer les personnes. Ou un risque n’a aucun déclencheur de révision.	Rien ne peut arrêter l’écriture sans une nouvelle mise en production. Ou le registre indique que l’injection est résolue.

Même si le reste est solide, le travail reste incomplet si un contrôle d’accès enseigné échoue. Il en va de même pour le contrôle d’approbation de l’écriture. Un envoi est irréversible : une fois le document dans une boîte de réception externe, aucun code ne peut le récupérer. De bonnes réponses aux tâches normales ne compensent pas un seul envoi interdit.

Assistants d'IA

Vous pouvez utiliser un assistant d’IA pour vous exercer, expliquer une erreur ou suggérer un test ou une menace oubliée. Vérifiez chaque suggestion et préparez-vous à expliquer votre travail final. Pour chaque contrôle, dites ce qu’il bloque, pourquoi vous l’avez choisi et quel test le prouve. Indiquez dans votre rapport vos propres décisions et les suggestions rejetées, avec la raison. Un assistant ne peut pas produire vos preuves : chaque compte, sortie et événement d’audit doit provenir d’une exécution sur votre ordinateur. Il ne peut pas non plus tirer une conclusion juridique à votre place. N’y collez jamais de vraie clé ni de vraies données personnelles. Ne l’utilisez jamais pour attaquer un système qui ne vous appartient pas.

Erreur courante

Tous les tests des contrôles réussissent, car le modèle n'a jamais essayé

Symptôme : tous les tests réussissent et le modèle réel n’atteint aucun objectif d’attaque. Puis un réviseur remplace le modèle par un modèle scripté qui appelle immédiatement send_document pour P28. Le courriel attend alors une approbation.

Cause : les tests vérifiaient ce que fait un modèle qui se comporte bien. Le modèle a refusé, donc le contrôle d’écriture ne s’est jamais exécuté. Ce contrôle avait une lacune qu’aucun test n’a atteinte.

Correction : testez chaque contrôle avec un modèle trompé, comme dans Limiter les conséquences. Le modèle scripté appelle exactement l’action interdite, et le contrôle doit la refuser. Mesurez ensuite le modèle réel pour obtenir un deuxième nombre, jamais comme preuve.

Récapitulatif

Dans ce cours, vous avez appris à rendre un assistant d’IA plus sûr dès sa conception. Vous avez aussi appris à décrire honnêtement ce qui reste :

• Cartographier les risques : actifs, acteurs, frontières de confiance et modèle de menace décrivant les chemins vers une lecture ou une action non autorisée.
• Limiter les conséquences dans le code : identité fournie par le serveur, lectures limitées à une portée, contrats stricts, contrôles d’écriture et approbation. Un modèle trompé ne peut pas les contourner.
• Tester avec des attaques sans danger : objectif atteint et effets secondaires non sécuritaires, comparés à la réussite des tâches, figés et répétés.
• Gérer les données de façon réfléchie : inventaire, stockage réduit au minimum avec une date de fin, suppressions atteignant toutes les copies possibles et preuves pour un réviseur qualifié.
• Réagir et consigner : détection sans contenu, interrupteurs qui agissent immédiatement, plan d’incident avec des responsables et registre des risques restants.

Si vous n’en avez pas encore fait, choisissez une étude de cas pour le certificat : Trouver et masquer les données personnelles avant qu’elles atteignent un modèle ou Créer le modèle de menace d’une application d’IA libre et la tester.