Édition du 26 août 2026

Sécurité et cloisonnement des données

eFactGate applique une architecture de sécurité garantissant le strict cloisonnement des données entre entreprises clientes (multi-tenant) et la confidentialité des factures transmises. La plateforme est pilotée par le framework de conformité sécurité ITechSource, avec profil documenté, registres, politiques et audits périodiques.

1. Framework de conformité sécurité

Depuis août 2026, eFactGate est intégré au framework de conformité sécurité ITechSource. Ce dispositif structure les mesures techniques et organisationnelles, la preuve d'application et le suivi d'amélioration continue.

Référentiels d'alignement

  • ANSSI SR2 — Exigences de sécurité pour les services numériques (authentification forte, chiffrement, journalisation, maîtrise des accès et des déploiements).
  • RGPD — Protection des données personnelles : registre des traitements, exercice des droits, notification d'incident, minimisation et conservation.
  • ISO/IEC 27001 — Bonnes pratiques de management de la sécurité de l'information (politique, risques, contrôles, amélioration continue) — alignement opérationnel.
  • SOC 2 — Principes de confiance (sécurité, disponibilité, confidentialité) — alignement des contrôles techniques et de supervision.

Dispositif documentaire et de preuve

  • Profil de conformité — Classification des données, périmètre, architecture de sécurité et dérogations tracées avec échéance.
  • Registre des traitements et analyse de risques applicatifs.
  • Politique applicative, procédures (dont exercice des droits RGPD) et plan d'amélioration.
  • Audits de sécurité périodiques avec grille d'exigences obligatoires / conseillées et preuves d'implémentation (infrastructure as code, journaux, captures opérationnelles).

En août 2026, l'audit de confirmation a validé la conformité aux 17 exigences obligatoires du framework (authentification, chiffrement, supervision, continuité, RGPD).

2. Architecture multi-tenant — isolation stricte

Chaque entreprise (SIRET) est un périmètre isolé, qu'elle soit inscrite directement ou rattachée à un concentrateur (éditeur SaaS). Le compte concentrateur voit ses N entreprises ; un autre tenant ne les voit pas. L'identifiant de tenant vient uniquement du JWT ou de la clé API — jamais du body, d'une query ou d'un header client.

Isolation au niveau base de données

  • Filtrage systématique par tenant / enterprise_id — Chaque requête SQL métier est filtrée par l'identifiant extrait du JWT via un mécanisme centralisé (TenantFilter) qui ne peut pas être contourné par le code métier.
  • Extraction du tenant depuis le JWT uniquement — Le tenant n'est jamais déterminé à partir du body, des query params ou des headers HTTP. Il est toujours extrait du token d'authentification signé côté serveur, empêchant toute usurpation.
  • Index dédiés — Les tables métier sont indexées sur les clés d'isolation pour garantir les performances même avec un grand nombre de tenants.

Isolation au niveau API

  • Middleware d'authentification obligatoire — Chaque requête passe par un middleware qui valide le JWT (signature, expiration, révocation) avant d'atteindre les handlers métier.
  • RBAC (Role-Based Access Control) — Les rôles (super_admin, tenant_admin, user, api_key) déterminent les actions autorisées. Un utilisateur ne peut jamais accéder aux ressources d'un autre tenant, quel que soit son rôle.
  • Clés API scopées et hashées — Chaque clé API est liée à une entreprise et stockée sous forme de hash (SHA-256). L'utilisation d'une clé d'un tenant A sur les ressources d'un tenant B est techniquement impossible.
  • Rate limiting — Limitation des tentatives sur login, inscription et soumission de factures, avec en-tête Retry-After en cas de dépassement.

Isolation au niveau stockage

  • Préfixe S3 par entreprise — tenants/…/enterprises/{enterprise_id}/… pour le contenu des factures, ACK, imports et tickets.
  • Une clé KMS par entreprise — Chaque SIRET a sa CMK (alias efg-ent-…). Un concentrateur n'a pas une clé unique pour ses clients : N entreprises = N clés. Objets S3 en SSE-KMS avec contexte enterprise_id. RDS : AES-256 au repos (clé compte).

3. Chiffrement en transit

  • TLS 1.2+ — Communications clients ↔ API, API ↔ base de données et API ↔ plateformes agréées chiffrées en TLS 1.2 minimum (CloudFront configuré en TLS 1.2+).
  • CloudFront + certificats ACM — Frontend et API exposés derrière CloudFront avec certificats SSL gérés par AWS Certificate Manager.
  • Connexions internes chiffrées — Connexions PostgreSQL (RDS) et cache (Redis / ElastiCache lorsque déployé) protégées en transit dans le VPC.

4. Authentification et gestion des accès

  • AWS Cognito (tier Plus) — Identités avec MFA TOTP obligatoire, politique de mots de passe ≥ 12 caractères (majuscule, minuscule, chiffre, symbole) et Threat Protection (Advanced Security) en mode ENFORCED.
  • Sessions courtes — Access / ID tokens valides 15 minutes, refresh token 24 heures.
  • Révocation (logout global) — Blacklist des jetons (identifiant jti) pour invalider une session après déconnexion.
  • Rotation des secrets — Clés de signature Cognito rotées automatiquement. Les clés API peuvent être révoquées instantanément.
  • Audit trail — Authentifications, échecs de connexion et actions administratives journalisés. Alerte automatique si ≥ 5 échecs d'authentification en 5 minutes (CloudWatch → SNS).

5. Protection des données de facturation

  • Minimisation — eFactGate parse surtout SIRET, n°, dates et montants pour router. Les webhooks client ne portent que flux_id, statut et horodatage — pas le XML.
  • Rétention 90 jours — Copie de transit du contenu (S3) puis purge. L'archivage légal 10 ans relève du client / de la PA, pas d'eFactGate (sous-traitant).
  • Contacts sur facture B2B — UBL / CII / Factur-X prévoient un contact professionnel. Ce n'est pas un motif de rejet. Traitement conforme (obligation e-facture + contrat) ; pas de LLM, pas de profilage, pas de revente.
  • Tickets B2C (OCR) — L'e-reporting PPF est agrégé. E-mail et téléphone extraits d'un ticket PDF sont masqués (je...nt@domaine.tld, 06...78).
  • Secrets connecteurs — Jamais en clair dans les journaux ; protégés au repos avec la base (RDS).

6. Infrastructure et déploiement sécurisés

  • AWS région Paris (eu-west-3) — Données hébergées en France, conformément aux exigences de souveraineté.
  • VPC privé — Base de données et caches non exposés sur Internet. L'API (ECS Fargate) est accessible derrière CloudFront / load balancer.
  • Security Groups restrictifs — Principe du moindre privilège : chaque composant ne communique qu'avec les services strictement nécessaires.
  • ECS Fargate — Conteneurs sans serveurs à patcher ; mises à jour d'infrastructure portées par AWS.
  • Intégrité des déploiements — Vérification du digest SHA-256 de l'image conteneur à chaque push ECR ; déploiement depuis poste admin à IP fixe (pas de pipeline de déploiement ouvert).
  • Journalisation et traçabilité cloud — CloudWatch Logs (rétention ≥ 90 jours), CloudTrail (événements de management), alertes budget et sécurité.

7. Conformité réglementaire et garanties

  • RGPD — ITechSource est sous-traitant (DPA) ; le client / l'éditeur est responsable de traitement. Droits d'accès, rectification, portabilité ; effacement des factures limité par l'obligation légale (art. 17.3.b). Self-service API (/api/v1/rgpd/export, /api/v1/rgpd/erase). DPO : dpo@itechsource.fr.
  • ANSSI SR2 — Alignement sur les contrôles SR2 applicables au service (MFA, politique mot de passe, sessions courtes, chiffrement, supervision, maîtrise du déploiement).
  • ISO 27001 / SOC 2 — Contrôles alignés sur ces référentiels via le framework ITechSource (politique, risques, preuves, audits) — sans se substituer à une certification tierce indépendante.
  • Réforme e-facturation 2026 — Conformité aux exigences du Portail Public de Facturation et des plateformes de dématérialisation partenaires.
  • Conservation — eFactGate : 90 jours de contenu en transit. Archive comptable 10 ans : client / PA.

8. Continuité et gestion des incidents

  • Supervision — Alertes automatiques (échecs d'authentification, anomalies opérationnelles, budget cloud).
  • Notification sous 72 h — En cas de violation de données personnelles, clients et CNIL notifiés dans les 72 heures (RGPD art. 33).
  • Plan de continuité — Sauvegardes RDS automatiques (rétention 7 jours), protection contre la suppression accidentelle (deletion protection), versioning S3. Objectifs : RPO ≤ 24 h, RTO ≤ 4 h.

Dernière mise à jour : 4 septembre 2026 — KMS par entreprise, rétention 90 j, traitement RGPD des contacts portés par les factures.