ArkForge est conçu pour l'entreprise. Chaque composant de Trust Layer est pensé avec une approche security-first — de la clé API que vous recevez à la preuve cryptographique qui est stockée.
Toutes les connexions à trust.arkforge.tech sont servies exclusivement en HTTPS. Le HTTP non chiffré est rejeté au niveau nginx. Les URLs cibles doivent également être en HTTPS — le proxy refuse tout transfert non chiffré.
nginx assure la terminaison TLS en frontal du serveur applicatif, qui est lié uniquement au loopback (127.0.0.1:8100). Le processus applicatif n'est jamais directement exposé à internet.
Les clés API sont des tokens aléatoires de 48 caractères générés avec secrets.token_hex(24) (stdlib Python). Les clés ne transitent jamais en clair dans les logs — tous les headers et clés sont automatiquement redactés avant écriture dans tout fichier de log.
Les tentatives d'authentification sont limitées à 10 par IP et par fenêtre de 5 minutes. Les tentatives excédentaires sont rejetées avec un code 429. Les compteurs sont stockés dans Redis avec un fallback en mémoire, garantissant la protection même en cas d'indisponibilité du cache.
Chaque clé API est associée à un plan (Free, Pro, Enterprise, Platform) avec des quotas mensuels stricts appliqués atomiquement via Redis INCR. Des alertes de quota se déclenchent à 80% de consommation. Le dépassement nécessite un opt-in explicite avec un plafond en euros.
Les clés API sont stockées au repos chiffrées avec Fernet (AES-128-CBC + HMAC-SHA256). La clé de chiffrement est conservée dans un vault séparé — jamais co-localisée avec les données chiffrées.
Chaque preuve générée par Trust Layer est signée et attestée par trois tiers indépendants. ArkForge ne peut ni falsifier ni modifier rétroactivement une preuve une fois émise.
Chaque preuve est signée avec la clé privée Ed25519 d'ArkForge. La clé publique correspondante est publiée et vérifiable de manière indépendante. Ed25519 offre une sécurité 128 bits avec des signatures compactes.
Les horodatages des preuves sont contresignés par un pool d'autorités TSA RFC 3161 (FreeTSA, DigiCert, Sectigo). L'horodatage est juridiquement recevable dans la plupart des juridictions et prouve qu'une preuve existait à un instant précis.
Les hash des preuves sont soumis à Sigstore Rekor, un journal de transparence public et en annexion seule. L'inclusion est vérifiable indépendamment par n'importe qui — aucune confiance envers ArkForge n'est requise.
Les preuves sont en écriture unique. Une fois émise, une preuve ne peut être modifiée, antidatée ou supprimée — ni par ArkForge, ni par quiconque. L'entrée Rekor sert d'ancre permanente.
Les URLs cibles sont validées avant tout transfert. Les plages d'IP privées (RFC 1918), les adresses loopback, les adresses link-local et les endpoints de métadonnées cloud (ex. 169.254.169.254) sont bloqués. La résolution DNS est vérifiée après résolution pour prévenir les attaques DNS rebinding.
Les réponses transmises sont limitées à 1 Mo. Les payloads plus volumineux sont tronqués pour prévenir l'épuisement mémoire. Les timeouts de requête sont imposés à 120 secondes.
Les réponses d'erreur retournent des codes HTTP génériques (401, 403, 429, 500) sans divulguer de détails internes, de stack traces ou d'informations sur l'infrastructure.
Les headers de requête personnalisés sont limités à 10 par requête. Les headers sont validés et nettoyés avant transfert pour prévenir l'injection de headers.
Toute l'infrastructure ArkForge est hébergée sur des serveurs OVHcloud situés en France (Union européenne). Aucune donnée n'est traitée ou stockée en dehors de l'UE.
ArkForge est une entreprise française. La conformité RGPD n'est pas une option — c'est le comportement par défaut. Des accords de traitement des données (DPA) sont disponibles pour les clients Enterprise.
Trust Layer génère des pistes d'audit inviolables satisfaisant les exigences des articles 9, 13–15 et 17 du règlement IA de l'UE pour les systèmes à haut risque. Échéance de conformité : août 2026.
Tous les credentials (clés API, SMTP, Stripe, clés de signature) sont stockés dans un vault dédié. Les secrets ne sont jamais codés en dur, jamais écrits dans le code source, et n'apparaissent jamais dans les logs applicatifs. La redaction des logs s'exécute avant toute écriture dans journald.
Les dépendances Python sont épinglées avec des versions exactes et auditées à chaque commit avec pip-audit. Un workflow GitHub Actions de revue des dépendances bloque les merges introduisant des CVE connus.
Vous avez trouvé une vulnérabilité ? Nous apprécions la recherche en sécurité responsable. Merci de signaler vos découvertes à contact@arkforge.tech avec une description du problème et les étapes de reproduction. Nous nous engageons à accuser réception dans les 48 heures et à résoudre les vulnérabilités confirmées dans les 30 jours.
Nous vous demandons de ne pas divulguer publiquement les vulnérabilités avant que nous ayons eu l'opportunité d'y remédier.