Aller au contenu principal

Approbations et Règle des 4 Yeux (Maker-Checker)

L'écran Approbations (/approvals, accessible via le composant src/app/approvals/page.tsx) est le centre de contrôle réglementaire de TkushPatch. Il implémente le principe bancaire de séparation des tâches Maker-Checker (4 Yeux) conformément aux directives Normes de Gouvernance Bancaire, Sécurité Données Bancaires v4.0 et ISO 27001.

Aucun patch OTA destiné au grand public sur le canal stable ne peut être activé sans avoir franchi cette barrière de validation cryptographique.

1. Principe Maker-Checker et Quarantaine STAGED​

Lorsqu'un développeur mobile (ROLE_RELEASE_DEVELOPER) compile et publie un patch correctif via le CLI (tk-ota-push patch) ou l'API, le patch entre immédiatement dans un état de quarantaine technique :

Processus de double validation (Maker-Checker)
  1. Création du correctif (Maker) : Le développeur publie un patch depuis la CLI. Le patch est placé en attente au statut STAGED.
  2. Examen par un tiers (Checker) : Un second collaborateur autorisé examine les modifications dans la Console Web.
  3. Validation et signature : L'approbateur valide le patch, qui reçoit une signature numérique de production.
  4. Distribution : Le statut passe à APPROVED_AND_SIGNED et le déploiement débute.

Le statut STAGED​

  • Le binaire .vmcode est stocké sur le serveur, mais l'API Data Plane (/api/v1/patches/check) refuse formellement de le servir aux clients mobiles de production.
  • Seuls les appareils de test dont le client_id est explicitement inscrit dans la liste blanche QA peuvent exécuter le patch en quarantaine.

2. Les 3 Gardes-Fous de Pré-Signature​

Avant de présenter le bouton de signature finale, la console d'approbation inspecte automatiquement l'artefact selon 3 critères stricts :

Garde-fouCritère inspectéConséquence en cas d'échec
1. Verrouillage du code natifAbsence de modification du hash de configuration native (patch.native_bridge_ok == true)Rejet automatique : un patch OTA Dart ne peut pas modifier du code C++/Java/Obj-C ou des permissions du manifeste sans provoquer de crash.
2. Intégrité de l'archive binaireSomme de contrôle SHA-256 du micro-diff décompressé (targetSha256Hash) recalculéeAlerte rouge d'intégrité : blocage de la Signature cryptographique pour prévenir toute corruption disque ou altération MITM.
3. Archivage des symboles DartPrésence vérifiée de l'archive .symbols associée à ce numéro de patchAvertissement opérationnel : empêche la perte de traçabilité en cas de crash en production (désobfuscation impossible).

3. Matrice d'Habilitation sur /approvals​

L'accès à l'écran /approvals et aux actions de signature dépend directement du rôle RBAC :

RôleAccès à /approvalsBouton "Approuver & Signer"Bouton "Rejeter / Annuler"
ROLE_ADMIN✅ Oui✅ Oui (sauf s'il est l'auteur en mode multi-membres)✅ Oui
ROLE_SECURITY_OFFICER✅ Oui✅ Oui (Checker désigné)✅ Oui
ROLE_RELEASE_DEVELOPER❌ Masqué❌ Interdit❌ Interdit
ROLE_SRE_ADMIN❌ Masqué❌ Interdit❌ Interdit
ROLE_AUDITOR_READONLY✅ Consultation❌ Lecture seule stricte❌ Lecture seule stricte

[!IMPORTANT] Si un développeur mobile tente d'accéder directement à l'URL /approvals, le composant RoleGuard intercepte la requête et affiche un écran de restriction d'accès conforme au principe de moindre privilège.

4. Mode Solo Tenant vs Organisation Multi-Membres​

Dans le monde réel, une startup ou une phase de pré-lancement démarre souvent avec un administrateur unique. Pour ne pas paralyser les équipes réduites tout en garantissant une sécurité maximale, TkushPatch gère deux modes dynamiques :

A. Mode Développeur Solo (isSoloTenant == true)​

  • Détecté automatiquement lorsque l'organisation compte totalMembers == 1.
  • L'administrateur unique est autorisé à s'auto-approuver de manière dérogatoire.
  • Chaque auto-approbation est marquée d'un indicateur spécifique dans le journal d'audit légal (audit_action: PATCH_APPROVED_SOLO_OVERRIDE), garantissant une traçabilité rétrospective complète.

B. Mode Entreprise / Réglementé (enforceFourEyes == true ou totalMembers > 1)​

  • L'auto-approbation est strictement impossible.
  • Si l'administrateur connecté a soumis le patch via le CLI ou l'API, le bouton de signature est désactivé avec la mention : "En attente de validation par un second collaborateur habilité (RSSI ou Co-administrateur)".

5. Le Processus Cryptographique de Signature cryptographique​

Lorsque l'officier de sécurité clique sur Approuver et Signer avec moteur cryptographique :

  1. La console envoie une requête POST /api/admin/v1/patches/{id}/approve authentifiée par JWT.
  2. Le backend Serveur TkushPatch valide l'identité de l'opérateur et vérifie que actor.id != patch.author_id.
  3. Le backend invoque l'adaptateur ShorebirdRsamoteur de signatureSignerAdapter :
    • Le hash hexadécimal SHA-256 de 64 caractères du binaire (message.as_bytes()) est transmis au moteur service de signature sécurisé Engine.
    • moteur de signature signe ce digest avec la clé privée signature numérique/4096 dédiée à l'environnement cible.
    • La signature numérique signature numérique est encodée en Base64 et persistée avec le patch.
  4. Le statut du patch passe à APPROVED_AND_SIGNED.
  5. Un événement certifié immuable est inscrit dans la table des journaux d'audit avec l'adresse IP et l'identité de l'approbateur.