Sécurité

EFact traite des documents fiscaux juridiquement contraignants pour le compte d'entreprises marocaines. La sécurité n'est pas une fonctionnalité ajoutée : c'est la contrainte autour de laquelle la plateforme a été conçue.

En bref

EFact chiffre les secrets au repos en AES-256-GCM (dont le mot de passe du certificat de signature), applique une isolation multi-tenant stricte entre organisations, et journalise chaque transition de statut dans une piste d'audit append-only. Les documents fiscaux sont archivés 10 ans en stockage immuable, conformément à la réglementation marocaine.

Statut de l'intégration DGI

La plateforme nationale d'e-facturation de la DGI n'est pas encore ouverte aux intégrations. Toute mention de « DGI » sur cette page désigne aujourd'hui notre simulateur DGI, qui reproduit le flux de clairance officiel (soumission, validation de signature, référence, QR code, callbacks) avec les mêmes mécanismes de sécurité. Le basculement vers la plateforme officielle se fera sans aucun changement côté client.

Authentification

Deux plans d'authentification distincts, isolés au niveau des filtres HTTP afin qu'aucun ne puisse affaiblir l'autre.

Clés API - machine à machine

Format: efact_sk_suivi de 256 bits d'aléa cryptographiquement sûr (CSPRNG, Base64url). Le préfixe reconnaissable facilite la détection des clés fuitées par les scanners de code.
Stockage: Jamais en clair : seul le hash SHA-256 est persisté. Même base compromise, aucune clé exploitable n'en est extractible.
Affichage: Le tableau de bord ne montre que efact_sk_ et les 6 premiers caractères. La clé complète est affichée une seule fois, à la création.
Transport: Exclusivement via Authorization: Bearer. Jamais dans une URL, une query string ou un corps de requête - donc jamais dans les logs d'accès, l'historique du navigateur ou les proxys.
Périmètre: La clé résout elle-même l'organisation côté serveur. Aucun paramètre organizationId manipulable : une clé ne voit que les données de sa propre organisation.
Révocation: Instantanée depuis le tableau de bord. Soft-delete : la clé cesse immédiatement d'authentifier, son enregistrement reste pour la piste d'audit.
Observabilité: Chaque clé enregistre son last_used_at : les clés dormantes ou suspectes sont faciles à repérer et à faire tourner.

Tableau de bord - humains

OpenID Connect: Jetons JWT à courte durée de vie, validés à chaque requête : signature, émetteur et expiration vérifiés auprès du fournisseur d'identité.
Sans état: Aucune session côté serveur, donc aucune surface de fixation de session.
Contrôles hérités: L'identité étant déléguée au fournisseur d'identité, les organisations bénéficient de ses politiques de mot de passe et de sa détection de force brute.Planifié MFA/TOTP et fédération SSO en libre-service.

Séparation des deux plans

L'API utilise des chaînes de filtres de sécurité séparées : le validateur JWT ne s'exécute que sur les routes du tableau de bord, et l'API de facturation authentifie elle-même les clés. Toute route non déclarée explicitement dans l'une des chaînes est refusée par défaut- un nouvel endpoint reste injoignable tant qu'il n'est pas délibérément exposé.

Autorisation et isolation multi-tenant

Chaque requête à périmètre organisationnel passe par un point de contrôle unique, qui vérifie que l'appelant appartient à l'organisation et que son rôle autorise l'action. Le mapping rôle → permission est défini dans le code, non modifiable à l'exécution : la politique est du code, pas de la donnée.

Action	Admin	Client	Viewer
Paramètres organisation et certificat	Autorisé	Non autorisé	Non autorisé
Gestion des membres	Autorisé	Non autorisé	Non autorisé
Gestion des clés API	Autorisé	Non autorisé	Non autorisé
Créer / modifier / annuler des factures	Autorisé	Autorisé	Non autorisé
Lire factures, statuts et statistiques	Autorisé	Non autorisé	Autorisé
Lire le journal d'audit	Autorisé	Non autorisé	Autorisé

Lectures inter-tenant: Renvoient 404, pas 403 : l'API ne confirme jamais l'existence d'une ressource appartenant à une autre organisation.
Identifiants: Toutes les clés primaires sont des UUID - non séquentiels, non devinables. Les attaques par énumération sont éliminées par construction.

Chiffrement

En transit et au repos, sans mode dégradé.

En transit: TLS partout : l'API publique est exclusivement HTTPS. Le canal de transmission DGI est conçu pour un TLS mutuel (mTLS)par certificat client, sur des bundles SSL dédiés par environnement - il pointe aujourd'hui vers le simulateur DGI.
Au repos: Les secrets stockés (p. ex. le mot de passe de votre certificat de signature) sont chiffrés en AES-256-GCM: IV aléatoire de 96 bits par chiffrement, tag d'authentification de 128 bits (toute altération est détectée cryptographiquement), format versionné (v1:) prévu pour la rotation de la clé maîtresse.
Clé maîtresse: Ne touche jamais le code ni la base : injectée par variable d'environnement. Si elle manque ou est malformée, l'application refuse de démarrer. Il n'existe aucun mode dégradé où des secrets seraient stockés sans protection.

Protection contre les abus

Rate limiting: 300 requêtes/minute par clé API (token-bucket). Le dépassement renvoie un 429 structuré avec Retry-After, que les SDK officiels honorent automatiquement (backoff exponentiel + jitter).
Validation en bordure: Les corps de requête sont validés par schéma (ICE à 15 chiffres, codes devise ISO, formats de date) et rejetés avec des erreurs au niveau du champ, avant toute logique métier.
Pagination assainie: Les paramètres de tri et de pagination sont mis en liste blanche côté serveur, ce qui ferme la porte à l'injection de propriété via les expressions de tri.
Enveloppe d'erreur: Une seule forme pour tous les échecs, y compris d'authentification : { code, message, data, errors }. Pas de stack trace, pas de page d'erreur brute, aucune fuite de détail interne.

Callbacks DGI

Les callbacks de statut sont traités comme des entrées non fiables. Ils sont aujourd'hui émis par le simulateur DGI, avec exactement les mêmes garanties que celles prévues pour la plateforme officielle.

Signature: Chaque callback est signé en HMAC-SHA256 sur le corps brut de la requête ; la vérification se fait en comparaison à temps constant.
Anti-rejeu: Chaque callback porte un horodatage vérifié contre un décalage d'horloge maximal.
Idempotence: Chaque callback porte un identifiant d'évènement unique ; les évènements sont persistés et dédupliqués. Un callback rejoué ne peut jamais appliquer un changement d'état deux fois.

Intégrité des documents

Le cœur du produit est lui-même une garantie de sécurité.

Normalisation: Les factures sont normalisées en XML UBL 2.1 et validées contre le XSD officiel avant toute autre opération.
Empreinte: Le XML canonique est haché en SHA-256. Ce hash assure la preuve d'intégrité et l'idempotence du document sur tout son cycle de vie.
Signature: Signature XAdES(RSA/SHA-256) avec le certificat PKCS#12 de l'organisation.
Certificats: Validés à l'upload (format, mot de passe, matériel de clé exploitable) ; leurs mots de passe sont stockés uniquement chiffrés en AES-256-GCM.
Fail-closed: Si une étape cryptographique échoue, toute la transaction est annulée. Une facture ne peut jamais exister à moitié signée.

Piste d'audit

Journal en ajout seul: Chaque transition de statut écrit un enregistrement immuable : statut précédent, nouveau statut, acteur, code de motif, motif lisible et métadonnées structurées.
Lecture seule: Le journal est lisible via l'API (rôles Admin et Viewer), jamais modifiable. Il satisfait les exigences de traçabilité de la conformité fiscale marocaine (article 145-9 du CGI).
Rétention des clés: Les clés révoquées sont conservées, non effacées, pour que l'historique d'audit reste complet.

Secrets et hygiène opérationnelle

Aucun secret en dur: Tous les secrets d'exploitation (clé maîtresse de chiffrement, secrets d'intégration) sont injectés par l'environnement - jamais dans le code ni les fichiers de config.
Garde-fou au démarrage: Le profil de production refuse de démarrer si un secret manque ou reste un placeholder de développement. Un déploiement mal configuré plante bruyamment au boot plutôt que de tourner avec des identifiants faibles. Seuls les noms de secret sont rapportés, jamais les valeurs.
Masquage des logs: Signatures XML, payloads QR, réponses DGI, mots de passe et clés privées PEM sont masqués par motif au niveau de la couche de log, avant l'écriture de toute ligne, vers n'importe quel appender.
Côté SDK: Les SDK officiels appliquent la même discipline : votre clé secrète n'est jamais loggée, jamais placée dans une URL, jamais incluse dans un message d'erreur.

Infrastructure et disponibilité

API sans état: Aucune session : scalable horizontalement derrière un load balancer.
Sondes de santé: Vérifications dédiées à la connectivité DGI et à la détection de factures bloquées.
Métriques: Collectées en continu pour un monitoring permanent.
Auto-réparation: Les soumissions plantées ou temporairement échouées sont automatiquement rattrapées ; les transmissions bloquées sont re-sondées. Voir Architecture.

Conformité

Cadre légal: Conçu pour l'article 145-9 du CGI marocain et le modèle de clearance e-facturation DGI 2026.
Formats mandatés: UBL 2.1 et XAdES, comme l'impose la réforme.
Archivage: Conservation légale de 10 ans des artefacts de facture.
Audits externes Planifié: Tests d'intrusion formels par un tiers, programme coordonné de divulgation de vulnérabilités / bug-bounty, et attestation de type SOC 2 à mesure que la plateforme monte en charge sur le déploiement 2026-2029.

Signaler une vulnérabilité

Écrivez à contact@itzenata.com. Nous demandons aux chercheurs de pratiquer une divulgation responsable et nous nous engageons à accuser réception des rapports rapidement.

Questions fréquentes

Comment EFact protège-t-il les clés et certificats de signature ?

Les secrets, dont le mot de passe du certificat de signature, sont chiffrés au repos en AES-256-GCM. La clé maîtresse provient d'une variable d'environnement jamais versionnée et l'application refuse de démarrer si elle est absente. Aucun secret en clair n'est journalisé, et les clés sont isolées par organisation.

Les données d'une organisation sont-elles isolées des autres ?

Oui. EFact applique une isolation multi-tenant stricte : chaque requête est cloisonnée par organisation et un client ne peut accéder qu'à ses propres factures, clés et paramètres. Les rôles (admin, client, viewer) restreignent en plus les actions possibles au sein d'une même organisation.

Combien de temps les factures sont-elles archivées ?

Les documents fiscaux sont archivés 10 ans, comme l'exige la réglementation marocaine, dans un stockage immuable. Chaque transition de statut d'une facture est en outre enregistrée dans un journal d'audit append-only, garantissant une piste d'audit fiable exigée pour la conformité DGI.