Ogni controllo qui sotto è nel codice, non in roadmap. Nulla è ancora in produzione. Elenchiamo ciò che facciamo e non facciamo: le assenze fanno parte dell’architettura, non sono lacune da colmare.
Registro append-only per costruzione
Le voci del record sono indirizzate per contenuto e concatenate. L'hash di ogni voce include l'hash della voce precedente. Modificare o eliminare una voce rompe la catena – rilevabile alla verifica successiva.
Token delimitati al workspace, nessuna chiave API condivisa
I token di superficie e di gateway valgono per un solo workspace. Persi o ruotati, toccano solo quel workspace. Un token può essere legato con DPoP, così una copia rubata senza la chiave del client è rifiutata.
Una lettura del tuo account da parte dello staff finisce nel tuo registro, non solo nel nostro
La console di amministrazione dello staff esiste per lavoro operativo legittimo – triage degli incidenti, riconciliazione della fatturazione, risposta agli abusi. Quando un membro dello staff apre il tuo account o uno dei tuoi abbonamenti, una voce admin_read append-only viene scritta nella catena Tops del tuo stesso workspace, con il nome dell'operatore, la superficie e il record. I trigger SQLite impongono l'append-only a livello di database, così nemmeno la console di amministrazione può riscrivere la traccia delle proprie azioni – e la voce è marcata come di origine piattaforma da un canale firmato che nessun cliente possiede, così nessuno può falsificarne una in nessun senso. Le scansioni in massa degli operatori che non nominano alcun cliente sono registrate invece sulla nostra catena di audit del provider; preferiamo che il tuo registro resti segnale piuttosto che riempirlo. I 9 tipi di Infrastructure sono configurabili dal cliente per workspace (filtri per ambiente, tassi di campionamento, interruttori per tipo) – con un minimo inviolabile per le azioni che devono sempre essere registrate.
Percorso dei dati giurisdizionale
Scegli una regione alla creazione del workspace. Le tre regioni europee salvano i dati sotto la giurisdizione UE di Cloudflare: Cloudflare li tiene nell’UE e sceglie il datacenter; Regional Services tiene il calcolo nella giurisdizione. I checkpoint si firmano sotto WEUR o ENAM.
Cifratura in transito e a riposo
TLS 1.3 per tutto il traffico dei clienti. D1, Aurora e R2 cifrano a riposo con chiavi del provider; le chiavi di firma dei checkpoint stanno in Cloudflare Secrets e le credenziali upstream sono sigillate da una chiave di cifratura.
Nessuna telemetria di terzi sui dati dei clienti
Nessun APM o analytics di terzi accede al contenuto dei record dei clienti. Il sito marketing si limita ad analytics aggregate di visualizzazioni, senza cookie, dove attivi.
Isolamento database per piano
I workspace Free e Starter condividono un database Cloudflare D1 regionale e ogni lettura e scrittura porta l’id del workspace; Pro, Pro+ e Team hanno ciascuno il proprio archivio separato su Cloudflare nella regione scelta, uno per workspace, con isolamento rigoroso tra tenant, incluso nel piano. Scale, Enterprise e l’add-on di isolamento hanno il database Amazon Web Services Aurora proprio del workspace: nessuno schema condiviso da interrogare.
Accesso del personale registrato
Ogni lettura del piano dati da parte dello staff scrive una voce Tops sul workspace interessato, con l'identità del membro dello staff, l'orario e il motivo. La console di amministrazione autentica tramite Cloudflare Access + WebAuthn per amministratore + token API per amministratore. L'accesso amministrativo lato provider (admin Cloudflare, admin AWS) è registrato presso il provider.
