Autorisation et périmètre
Actifs, environnements, méthodes, exclusions, créneaux et conditions d’arrêt sont définis par écrit. Une permission sur un système ne vaut pas autorisation sur un service tiers.
Méthode · Sécurité applicative, API & Azure
Des contrôles adaptés au risque. Des conclusions reliées aux preuves.
Un audit utile précise ce qui a été examiné, ce qui reste inconnu et comment vérifier les corrections. Voici le cadre et les bonnes pratiques proposés pour les missions INOBIC.
Version 1.0 · 7 novembre 2026 · Sélection au cadrage, sans certification ni conformité globale revendiquée.
Avant tout test : convenir du cadre
Accès et données minimisés
Demander le minimum nécessaire, privilégier la lecture seule et des données fictives. Les canaux, destinataires et durées de conservation sont convenus avant réception de données sensibles.
Risque métier et limites
Identifier les flux sensibles, les frontières de confiance et les hypothèses. Séparer revue documentaire, lecture de code, configuration et tests actifs expressément autorisés.
Un socle de contrôles à sélectionner
Ces 22 contrôles constituent une checklist INOBIC à adapter. Ils ne signifient pas que chaque mission couvre toutes les technologies, ni qu’ils ont déjà tous été exécutés sur notre site. Les méthodes, exigences de référence et moyens disponibles sont précisés au cadrage.
Cadrage et preuves
GOV-01 · Autorisation et limites
Consigner actifs, versions, comptes, méthodes, exclusions, droits des tiers, contacts et conditions d’arrêt. Aucune extension implicite.
Preuve attendue : Périmètre daté et autorisation écrite ; références internes sans secret.
GOV-02 · Données et canaux
Convenir des données autorisées, canaux, destinataires, outils externes/IA, durée de conservation et restitution ou suppression.
Preuve attendue : Modalités validées ; preuves minimisées ; accord séparé avant toute publication.
GOV-03 · Architecture et hypothèses
Identifier flux sensibles, frontières de confiance et scénarios métier ; distinguer revue de code, configuration et tests actifs.
Preuve attendue : Schéma ou inventaire versionné et liste des limites.
GOV-04 · Traçabilité du contrôle
Relier chaque contrôle au composant/version, à sa méthode, sa date, son résultat et sa preuve ; ne pas convertir une absence d’accès en succès.
Preuve attendue : Fiche de contrôle et références de preuves expurgées.
Applications et .NET
APP-01 · Autorisation par ressource
Vérifier côté serveur propriétaire, organisation et rôle ; prévoir les cas autorisé, refusé et absence d’identité.
Preuve attendue : Tests positifs et négatifs sur ressources de test et absence de données sur refus.
APP-02 · Authentification et sessions
Selon le mécanisme : validation des jetons, durée et révocation, cookies et protection des opérations sensibles ; ne pas confondre authentification et autorisation.
Preuve attendue : Configuration examinée et scénarios de test définis au cadrage.
APP-03 · Entrées et sorties
Examiner validation, encodage contextuel, requêtes paramétrées et traitements de fichiers/redirections selon les chemins réellement présents.
Preuve attendue : Constats reliés au code et tests ciblés, sans données de production.
APP-04 · Échecs et confidentialité
Tester les comportements sans JavaScript, sans permission ou avec service indisponible ; rechercher données en URL, erreurs et journaux.
Preuve attendue : Tests de dégradation et contrôle de l’absence de données sensibles dans les sorties.
APP-05 · Runtime et dépendances
Identifier versions supportées, dépendances directes/transitives et avis applicables ; distinguer alerte, exposition et exploitabilité.
Preuve attendue : Inventaire daté, source des avis et tri des résultats ; limite si aucun scan disponible.
API et intégrations
API-01 · Périmètre des opérations
Contrôler accès aux objets, propriétés et fonctions sensibles selon les rôles métier.
Preuve attendue : Matrice d’accès et cas négatifs autorisés.
API-02 · Contrats et limites
Examiner validation des requêtes, pagination, quotas et erreurs ; pas de test de charge sans accord distinct.
Preuve attendue : Configuration et tests bornés sur données fictives.
API-03 · Services externes
Revoir destinations sortantes autorisées et données de réponse ; ne pas supposer fiable une API tierce.
Preuve attendue : Chemins d’intégration examinés sans solliciter de tiers hors périmètre.
Azure et identités
AZ-01 · Droits effectifs
Examiner rôles directs/hérités et besoin métier ; éviter d’afficher identités et identifiants dans les pièces publiques.
Preuve attendue : Constats de permissions expurgés ; correction approuvée sans verrouillage administratif.
AZ-02 · Secrets et identités de workload
Préférer des identités managées lorsqu’elles conviennent ; examiner accès aux secrets sans en extraire les valeurs inutilement.
Preuve attendue : Métadonnées et permissions nécessaires ; procédure de rotation si exposition confirmée.
AZ-03 · Exposition et réseau
Examiner les accès publics/privés et restrictions des ressources incluses. Un site public n’est pas une erreur de configuration par nature.
Preuve attendue : Configuration comparée au besoin et impacts de changement évalués.
AZ-04 · Journaux et alertes
Vérifier les événements disponibles, destinataires, alertes et rétention ; ne pas conclure à une absence globale de logs à partir d’une lecture partielle.
Preuve attendue : Preuve de configuration ou statut non vérifié avec accès manquant.
DevSecOps et remédiation
CI-01 · Accès des pipelines
Revoir permissions des jobs, branches et approbations ; isoler les contributions non fiables des secrets de déploiement.
Preuve attendue : Configuration du pipeline et scénario d’accès relus.
CI-02 · Contrôles automatisés
Choisir SAST, SCA et détection de secrets selon la stack ; qualifier les alertes et tracer les dérogations avec responsable et échéance.
Preuve attendue : Rapports datés et traitement des faux positifs ; aucun outil revendiqué sans exécution.
FIX-01 · Correction proportionnée
Relier le changement à la cause, limiter le diff, prévoir revue et retour arrière ; ne pas élargir les privilèges pour résoudre le symptôme.
Preuve attendue : Diff et critères de validation ; identité du validateur à renseigner.
FIX-02 · Contre-vérification
Rejouer le scénario initial et les cas autorisés, refusés et dégradés ; distinguer test unitaire, intégration, navigateur et production.
Preuve attendue : Résultats avant/après sur versions identifiées et limites de couverture.
FIX-03 · Publication et intégrité
Vérifier les fichiers prévus, éviter les preuves privées dans le paquet et contrôler le comportement après publication.
Preuve attendue : Manifest, vérification ciblée en production et plan de retour arrière.
FIX-04 · Clôture et risques résiduels
Lister les éléments non retestés, risques acceptés et actions ouvertes ; convenir de la révocation des accès et de la gestion des données.
Preuve attendue : Restitution et décisions du responsable ; risque accepté distinct de risque corrigé.
Rendre chaque conclusion vérifiable
Un résultat comporte le composant et sa version, la méthode utilisée, la date, l’intervenant, la preuve pertinente et les limites. Un outil automatique produit des alertes à qualifier, pas une conclusion d’audit à lui seul.
Vérifié ou écart
« Vérifié » vaut uniquement pour le critère et le périmètre documentés. Un écart confirmé décrit aussi les conditions nécessaires et l’impact métier.
Partiel ou non vérifié
Un accès manquant, un scénario non exécuté ou une preuve insuffisante restent visibles dans le rapport. L’absence d’alerte ne démontre pas l’absence de vulnérabilité.
Non applicable
Une exclusion doit être justifiée par l’architecture ou le périmètre, pas utilisée pour masquer un contrôle difficile.
Qualifier, corriger, puis contre-vérifier
- 01
Qualifier le constat
Distinguer fait observé, hypothèse et risque. Évaluer les préconditions, l’exposition et l’impact métier. Un score CVSS, s’il est utilisé, doit préciser sa version, son vecteur et les hypothèses ; il ne remplace pas la priorité métier.
- 02
Corriger la cause
Proposer un changement proportionné et relu, avec critères de validation et retour arrière. Une dérogation désigne un responsable, un motif et une date de réexamen.
- 03
Rejouer les scénarios
Tester le défaut initial, le fonctionnement attendu et les refus ou modes dégradés. Indiquer la couche testée : unitaire, intégration, navigateur ou production. Une correction n’est déclarée vérifiée que sur la version effectivement retestée.
- 04
Restituer les limites
Lister les risques résiduels, points ouverts et éléments non retestés. Une acceptation de risque par le responsable reste distincte d’une correction. Clôturer selon les modalités convenues pour les accès et les données.
Protéger les preuves et les échanges
Limiter les captures et journaux au nécessaire ; remplacer les données de test par des marqueurs fictifs, expurger les secrets, identités et références d’infrastructure dans toute version publique. Conserver les originaux uniquement dans l’espace convenu, avec des accès limités.
L’usage d’un service externe ou d’un outil d’IA sur des informations confidentielles doit être convenu au préalable. Une publication de cas demande une autorisation distincte et une revue de l’export. Les empreintes servent à contrôler l’intégrité des pièces, sans constituer une attestation indépendante.
Application au cas INOBIC : ce qui est établi
- Comportement dégradé du formulaire : défaut reproduit localement, correction testée avec et sans JavaScript, puis parcours normal contrôlé sur le site publié.
- Contre-vérification : tests unitaires et navigateur ciblés, contrôles HTTP et intégrité du déploiement. Cela ne couvre pas tous les navigateurs ou tous les scénarios.
- Droits Azure : lecture ciblée des rôles applicables ; point de moindre privilège laissé ouvert. Aucune conformité globale du tenant n’est affirmée.
- Journalisation Azure : politique opérationnelle non établie dans le périmètre de la revue ; ce point reste à vérifier.
- Authentification .NET et API métier : hors périmètre de cette vitrine statique. Le laboratoire pédagogique est présenté séparément.
Cette synthèse rapproche les preuves existantes de notre méthode ; elle ne transforme pas rétroactivement la revue ciblée en audit complet ASVS, Azure ou SSDF.
Lire le constat réel et ses correctifs →Référentiels : un appui, pas un label
Sources officielles consultées le 7 novembre 2026. La version pertinente et les exigences retenues sont consignées pour chaque mission. Les références ci-dessous sont thématiques ; aucune correspondance exhaustive, affiliation ou certification n’est revendiquée.
- OWASP ASVS 5.0.0
Choisir des exigences de vérification applicative ; préciser les exigences et la version dans le périmètre, sans revendiquer un niveau complet non évalué.
- OWASP API Security Top 10 — 2023
Identifier les familles de risques API. Une liste de risques ne constitue pas un protocole exhaustif de tests.
- Microsoft — sécurité ASP.NET Core 10
Adapter les contrôles à la version du runtime et aux mécanismes réellement utilisés.
- Azure Well-Architected — checklist sécurité
Examiner les choix de sécurité du workload autorisé et leurs compromis, sans étendre la revue à tout le tenant.
- NIST SSDF — SP 800-218, version 1.1
Structurer le développement sécurisé et la réponse aux vulnérabilités selon le risque.
Documents pour préparer une mission
Modèles vierges, à adapter. Tous les contrôles commencent à « non vérifié » ; aucune autorisation, preuve ou signature n’est préremplie.
Cadrer votre besoin d’audit