Chaque contrôle ci-dessous est dans le code, pas sur une roadmap. Rien n’est encore déployé. Nous listons ce que nous faisons et non, car les absences font partie de l’architecture – pas des lacunes à combler.
Registre en ajout seul par construction
Les entrées du registre sont adressées par leur contenu et chaînées. Le hachage de chaque entrée inclut le hachage de l'entrée précédente. Modifier ou supprimer une entrée rompt la chaîne – détectable à la prochaine vérification.
Jetons limités à l'espace de travail, aucune clé API partagée
Les jetons de surface et de passerelle sont limités à un seul espace. Perdus ou renouvelés, ils n’affectent que cet espace. Un jeton peut être lié par DPoP : une copie volée sans la clé du client est refusée.
Une lecture de votre compte par notre personnel atterrit dans votre registre, pas seulement le nôtre
La console d'administration interne existe pour le travail opérationnel légitime – tri des incidents, rapprochement de facturation, réponse aux abus. Lorsqu'un membre du personnel ouvre votre compte ou l'un de vos abonnements, une entrée admin_read en ajout seul est écrite dans la chaîne Tops de votre propre espace de travail, nommant l'opérateur, la surface et l'enregistrement. Des déclencheurs SQLite imposent l'ajout seul au niveau de la base de données, de sorte que même la console d'administration ne peut réécrire la piste de ses propres actions – et l'entrée est estampillée « origine plateforme » via un canal signé qu'aucun client ne détient, donc personne ne peut en forger une non plus. Les balayages opérateurs en masse qui ne nomment aucun client sont consignés dans notre chaîne d'audit fournisseur ; nous préférons que votre registre reste du signal plutôt que du remplissage. Les 9 types Infrastructure sont configurables par le client pour chaque espace de travail (filtres d'environnement, taux d'échantillonnage, bascules par type) – avec un plancher de coupe-circuit sur les actions toujours enregistrées.
Chemin de données juridictionnel
Choisissez une région à la création. Les trois régions européennes stockent sous la juridiction UE de Cloudflare : Cloudflare garde les données dans l’UE et choisit le datacenter ; Regional Services garde le calcul dans la juridiction. Les points de contrôle sont signés sous WEUR ou ENAM.
Chiffrement en transit et au repos
TLS 1.3 pour tout le trafic client. D1, Aurora et R2 chiffrent au repos (clés gérées par le fournisseur) ; clés de signature des points de contrôle dans Cloudflare Secrets ; identifiants amont scellés sous clé de chiffrement.
Aucune télémétrie tierce sur les données client
Aucun APM ou analytics tiers n’accède au contenu des enregistrements clients. Le site marketing se limite à des statistiques de pages agrégées, sans cookie, si activées.
Base isolée selon forfait
Les espaces Free et Starter partagent une base Cloudflare D1 régionale, et chaque lecture et écriture porte l’id d’espace ; Pro, Pro+ et Team ont chacun leur propre stockage séparé sur Cloudflare dans la région choisie, un par espace, avec une isolation stricte entre clients, inclus dans le forfait. Scale, Enterprise et l’option d’isolation ont la base Amazon Web Services Aurora propre à l’espace : aucun schéma partagé à interroger.
Accès du personnel journalisé
Chaque lecture du plan de données par le personnel inscrit une entrée Tops sur l'espace de travail concerné, avec l'identité du membre du personnel, l'horodatage et le motif. La console d'administration s'authentifie via Cloudflare Access + WebAuthn par administrateur + jetons API par administrateur. L'accès administrateur côté fournisseur (admin Cloudflare, admin AWS) est journalisé chez le fournisseur.
