Fiducia e sicurezza

1. Architettura di sicurezza

• Crittografia a riposo

  Tutti i dati sensibili, incluse le credenziali dei connettori e i certificati dei provider di identità, sono crittografati a riposo con AES-256-GCM.

• Crittografia in transito

  Tutto il traffico è servito tramite TLS 1.3 (HTTPS), con HSTS applicato in modo che i browser rifiutino connessioni non sicure.

• Autenticazione e MFA

  Accesso con Google, oppure con un indirizzo e-mail e una password — almeno 12 caratteri, archiviata esclusivamente come hash scrypt con salt, con tentativi di accesso soggetti a limitazione della frequenza. L'autenticazione a due fattori (TOTP e codici di backup) è disponibile per tutti e può essere resa obbligatoria a livello di organizzazione; Enterprise aggiunge il single sign-on SAML (Okta, Azure AD, Google Workspace, OneLogin) con provisioning just-in-time e protezione contro il replay delle assertion.

• Controllo degli accessi basato sui ruoli

  I ruoli integrati Owner, Admin e Viewer, oltre a ruoli personalizzati granulari, le consentono di concedere accessi con privilegi minimi. Le autorizzazioni vengono applicate a ogni richiesta.

• Controlli di sessione e di rete

  Policy configurabili di durata massima della sessione e di timeout per inattività, oltre all'allowlisting IP che limita l'accesso agli intervalli che ritiene attendibili (Enterprise).

• Protezione perimetrale

  Cloudflare fornisce un Web Application Firewall e la protezione DDoS davanti all'applicazione, con intestazioni di sicurezza (CSP, HSTS, frame-deny) su ogni risposta.

2. Gestione dei dati

Il monitoraggio è in sola lettura. La piattaforma si connette con gli scope più limitati che le consentono di valutare la postura, non richiede mai il contenuto dei file e non modifica nulla nelle sorgenti a meno che non venga attivata la auto-remediation.

• Monitoraggio in sola lettura

  I connettori monitorano tramite scope di sola lettura. Per Google Workspace, la scansione opera su drive.metadata.readonly — può leggere i metadati di condivisione, non il contenuto dei file. L'accesso in scrittura esiste unicamente per la auto-remediation: disattivato per impostazione predefinita, concesso separatamente per ciascun connettore e limitato alla revoca o alla riduzione degli accessi.

• Solo metadati e risultati

  Memorizziamo i metadati delle autorizzazioni, il grafo degli accessi e i risultati che ne deriviamo. Non memorizziamo, indicizziamo né trasmettiamo il contenuto dei suoi documenti.

• Conservazione configurabile

  I dati operativi seguono la sua policy di conservazione — ad esempio fino a 24 mesi di cronologia di audit e una finestra di 90 giorni per i dati transitori — con una soglia di sicurezza in modo che nulla venga eliminato accidentalmente.

• Esportazione ed eliminazione self-service

  Gli Owner possono esportare autonomamente i dati della propria organizzazione e richiedere l'eliminazione dell'account. L'eliminazione viene eseguita dopo un periodo di grazia e poi rimuove i dati.

3. Conformità

Mappiamo i nostri controlli e le evidenze generate dal prodotto rispetto ai principali framework. Si tratta di mappature per supportare il suo audit — 8200.dev non è certificato rispetto a questi standard e non lo affermeremo mai.

• Mappatura dei framework

  I controlli e le evidenze del prodotto sono mappati su SOC 2, ISO 27001, GDPR, HIPAA e NIST CSF 2.0. La dashboard di conformità in-app monitora tutti e cinque affiancati, con analisi delle lacune e un pacchetto di evidenze esportabile.

• Uso limitato delle API Google

  L'utilizzo dei dati utente grezzi o derivati ricevuti dalle API di Workspace è conforme alla Google User Data Policy, inclusi i requisiti di Limited Use. I dati di Workspace vengono utilizzati esclusivamente per fornire e migliorare le funzionalità di sicurezza che lei abilita — non li utilizziamo mai per sviluppare, migliorare o addestrare modelli generalizzati di AI o di machine learning, e non li trasferiamo mai a strumenti o servizi di AI o ML di terze parti per finalità di addestramento.

• Verifica OAuth Google

  Google ha approvato la verifica OAuth di 8200.dev il 2026-08-23 per i tre scope richiesti: drive.metadata.readonly per la scansione, e admin.directory.user.readonly e admin.directory.user.security per l'audit opzionale delle app di terze parti. Qualsiasi nuovo scope — incluso lo scope in scrittura che la auto-remediation richiederebbe su Google Workspace — richiede una nuova verifica prima che venga utilizzato.

4. Responsabilità degli agenti AI

Lo spostamento di responsabilità del 2026 rende l'azienda che implementa l'AI responsabile di ciò che fanno i suoi agenti. 8200.dev produce le prove che Lei ha governato tale accesso. Questo supporta la Sua conformità; non costituisce consulenza legale e non garantisce alcun risultato.

• Inventario completo degli agenti

  Agent Guard mantiene un inventario in tempo reale di ogni agente AI e account di servizio che può raggiungere i Suoi dati, oltre alle concessioni OAuth di terze parti dietro la shadow AI — non è possibile governare ciò che non si può vedere.

• Registro degli accessi immutabile

  Ogni decisione e modifica di accesso viene registrata in un audit trail esportabile (CSV / JSON / CEF / SIEM), così da poter ricostruire cosa un agente AI poteva raggiungere, e quando.

• Governance dimostrabile

  Regole di prevenzione, applicazione degli accessi e una cronologia dei rischi documentata dimostrano controllo e risposta attivi — le prove alla base di un programma di governance dell'AI difendibile.

5. Sicurezza operativa

• Controlli di stato continui

  Controlli di stato automatizzati vengono eseguiti ogni cinque minuti su piattaforma, database e connettori, aprendo automaticamente un incidente quando qualcosa si degrada.

• Pagina di stato pubblica

  Una pagina di stato pubblica pubblica la cronologia di uptime e gli aggiornamenti sugli incidenti, così da conoscere sempre lo stato attuale.

• Test automatizzati

  Il codice sorgente è coperto da oltre 4.000 test automatizzati eseguiti a ogni modifica, in modo che le regressioni vengano rilevate prima del rilascio.

• Audit logging ed esportazione SIEM

  Le azioni rilevanti per la sicurezza vengono registrate in un audit trail immutabile per organizzazione che è possibile esportare come CSV, JSON o CEF e trasmettere al Suo SIEM (Enterprise).

6. Subprocessori

Utilizziamo un piccolo insieme di subprocessori verificati. Ciascuno riceve solo i dati necessari per svolgere la propria funzione.

7. Contatti

Ha bisogno di documentazione sulla sicurezza, di un elenco dei subprocessori o di risposte per una valutazione fornitori? Scriva a [email protected].