Vai al contenuto
lurno
Sicurezza e privacy

L'isolamento è imposto dal database, non dal codice applicativo.

Ogni richiesta che modifica qualcosa viene autorizzata tre volte, in tre punti che falliscono in modo indipendente. Dietro di essi ci sono 868 policy di row-level security, così un errore in un handler è un bug e non una fuga di dati. Questa pagina è scritta per la persona che deve dare l'approvazione su di noi.

In breve

Come Lurno protegge i dati di un'organizzazione da quelli di un'altra

Lurno autorizza ogni richiesta di modifica in tre punti indipendenti. L'interfaccia verifica un permesso prima di mostrare un comando. Il server verifica lo stesso permesso prima di toccare i dati, e rifiuta se la risposta è no. Il database applica una policy di row-level security che decide quali righe la query può restituire. Tutti e tre devono passare. Le policy di questo tipo sono 868 su 676 migrazioni, e le tabelle applicative vivono in 14 schemi di dominio invece che nello schema public predefinito, così le righe di un'organizzazione restano irraggiungibili dalla sessione di un'altra anche quando il codice sopra di esse è sbagliato. Le modifiche amministrative vengono scritte in un log di audit in sola aggiunta, le cui righe sono concatenate con SHA-256 e verificabili con una query. Augmental Learning Inc. è allineata alle pratiche ISO 27001; non possiede alcun certificato ISO 27001 né alcun report SOC 2, e lo diciamo nel questionario invece di lasciare che un acquirente presuma il contrario.

Autorizzazione a tre livelli
Un modello in cui una richiesta viene autorizzata tre volte, da tre meccanismi che falliscono in modo indipendente. Il primo livello è l'interfaccia: nasconde un comando per cui la persona autenticata non ha permessi. Il secondo è il server: l'handler verifica il permesso prima di toccare i dati e solleva un errore se la risposta è no. Il terzo è il database: una policy di row-level security sulla tabella limita quali righe la query può restituire. Il primo livello è una comodità, il secondo è il confine principale e il terzo è ciò che regge ancora quando il secondo viene saltato.
L'architettura

Tre livelli, e che cosa c'è dietro ciascuno

Livello per livello

Una richiesta, autorizzata tre volte

Un comando nell'interfaccia chiede se la persona autenticata possiede un permesso prima di mostrarsi. L'handler sul server verifica lo stesso permesso prima di fare qualsiasi lavoro. Poi il database applica una policy che decide quali righe la query può vedere. Tre meccanismi, tre punti distinti in cui avere ragione, e basta che uno solo dica no perché la richiesta finisca.

  • Il controllo nell'interfaccia è una comodità, non un confine. Nasconde un pulsante; non protegge una tabella.
  • Ogni controllo passa da un unico catalogo di permessi e da un'unica funzione. Nessun handler legge il nome di un ruolo e decide da sé che cosa quel ruolo significhi.
  • Un ruolo assegnato su un ramo dell'albero di un'organizzazione si propaga lungo quel ramo — e le policy del database leggono lo stesso albero che legge l'interfaccia, quindi le due non possono contraddirsi.
Come sono strutturate organizzazioni e ruoli
Nel database

868 policy su 676 migrazioni

L'isolamento è schema, non consuetudine. Le tabelle vengono create con la row-level security attiva e con policy che delegano alla stessa funzione di permessi chiamata dal server, e un controllo sulle migrazioni cerca le tabelle a cui è stato concesso l'accesso senza una policy dietro. Il numero non è una cifra di marketing — è ciò che il database risponde quando gli si chiede quante policy sta applicando.

  • Le policy non incorporano una logica propria. Chiamano la funzione di permessi, così la risposta non può divergere da quella decisa dal server un istante prima.
  • Le policy di scrittura portano una clausola di verifica oltre a quella di lettura, così un insert non può inserire una riga in un'organizzazione per cui chi scrive non ha permessi.
  • Dove una vista espone dati personali, l'accesso viene concesso colonna per colonna. Una concessione sull'intera tabella annullerebbe silenziosamente la protezione a livello di colonna, quindi non viene usata.
Schemi

Quattordici schemi di dominio, mai quello public

Le tabelle applicative vivono in quattordici schemi con un nome proprio — uno per identità e accessi, uno per le organizzazioni, uno per i media, e così via. Nulla di rilevante sta nello schema public predefinito, che è il posto in cui una concessione accidentale o un'impostazione permissiva ha più probabilità di esporre qualcosa. I media privati non hanno alcuna policy di storage per i browser autenticati: ogni lettura è firmata da un server che ha prima verificato la riga proprietaria, e ogni caricamento viene autorizzato allo stesso modo.

  • I token monouso — inviti, reimpostazioni della password, recupero dell'account — sono conservati come hash con salt. Il token in chiaro viene mostrato una volta sola, nell'email, e mai più.
  • Solo il branding è pubblico. Il logo e la favicon di un'organizzazione devono essere visualizzati prima che qualcuno acceda; gli avatar e i media delle lezioni no, quindi restano firmati.
Responsabilità

Dimostrare a posteriori che cosa è successo

Un log di audit che nessuno può verificare è un file di log con un marketing migliore. Questo è in sola aggiunta e a prova di manomissione, e verificarlo è una query.

Un log in sola aggiunta

Le modifiche amministrative vengono scritte come eventi che riportano attore, azione, risorsa, organizzazione e un payload prima-e-dopo. Nulla aggiorna una riga di audit. Il percorso di scrittura fa solo aggiunte.

Una catena di hash SHA-256

Ogni evento conserva l'hash di quello precedente e un hash di sé stesso, entrambi assegnati da un trigger del database e non dal codice che ha registrato l'evento. Basta cambiare una riga e tutti gli hash successivi smettono di corrispondere.

Una verifica che può vedere in funzione

Una funzione di verifica percorre la catena e indica la prima riga in cui si interrompe. La eseguiremo davanti a lei durante una revisione.

Revisioni degli accessi

Chi ricopre quale ruolo, e in quale organizzazione, rivisto con una cadenza programmata invece che al momento dell'audit. Una revoca è un evento di audit come gli altri.

Due persone per le operazioni distruttive

Anonimizzare o cancellare una persona è una richiesta, poi un'approvazione separata. Chi richiede non può approvare la propria richiesta, e nessuno può prendere di mira sé stesso.

Sessioni che può chiudere

Una persona autenticata può revocare le proprie altre sessioni, e una sessione revocata viene bloccata al controllo dei permessi successivo, non quando il suo token scade.

Privacy

Dal consenso alla cancellazione, con un orologio su ogni passaggio

Ogni tenant è titolare del trattamento dei dati dei propri discenti e Lurno è il responsabile. La meccanica qui sotto è ciò che rende quella divisione reale e non solo contrattuale.

  1. 01

    Consenso, con una versione

    Ogni informativa a cui una persona acconsente porta un numero di versione. Se l'informativa cambia, il vecchio consenso non vale più: la persona viene interpellata di nuovo, e ciò che ha accettato e quando viene registrato. Il trattamento con AI è un consenso separato — lo revochi e nulla viene inviato ad alcun provider.

  2. 02

    Una richiesta di accesso, come procedura guidata

    Un amministratore segue la richiesta passo passo invece di improvvisarla: identificare l'interessato, raccogliere ciò che è conservato sulla piattaforma, produrre l'esportazione. Portabilità significa leggibile da una macchina — JSON e CSV, non un PDF con lo screenshot.

  3. 03

    Conservazione con una data di fine

    I dati personali portano una scadenza di conservazione per categoria invece di restare per sempre per impostazione predefinita. Account inattivi, inviti scaduti e sessioni vecchie hanno tutti una data dopo la quale smettono di esistere.

  4. 04

    Cancellazione con la regola dei due

    Un amministratore la richiede, un secondo la approva, e solo allora viene eseguita. Chi richiede non può mai approvare, e nessuno dei due può esserne l'interessato. La cancellazione raggiunge le tabelle che fanno riferimento alla persona, non solo la riga del profilo.

  5. 05

    Un registro delle violazioni con un orologio di 72 ore

    Un incidente è una riga con una scadenza calcolata a 72 ore dalla scoperta, e promemoria che continuano a scattare finché non viene chiusa. L'orologio parte dalla scoperta, non dal momento in cui qualcuno si ricorda dell'articolo 33.

Residenza dei dati

Dove stanno davvero i dati

File

Uno storage dei media che può puntare altrove

I file vengono scritti attraverso un'interfaccia di storage con quattro implementazioni: Supabase Storage, Amazon S3, Azure Blob Storage e Google Cloud Storage. Di solito è la risposta onesta a un requisito di residenza — un deployment può scrivere i file in un bucket nella regione che le è imposta, invece di aspettare che un fornitore ne apra una. Ci dica il requisito per tempo e le diremo chiaramente se oggi è soddisfatto.

  • Il database, l'autenticazione e le funzioni su cui gira l'API sono ospitati da Supabase. È l'unica dipendenza che non si può configurare diversamente, ed è indicata nel DPA.
  • I domini personalizzati per organizzazione sono serviti tramite Cloudflare con certificati emessi automaticamente, così un discente a Beirut o a Milano vede il suo dominio, non il nostro.
Domini personalizzati e white-label
Analytics

Analisi di prodotto nell'UE, con i discenti esclusi

Le analisi di piattaforma passano da PostHog nella sua regione UE, dietro un'astrazione che permette di sostituire il fornitore senza toccare il prodotto. Il session replay è mascherato e non registra mai i discenti — la superficie dei discenti non è affatto strumentata per il replay.

  • I campi di testo e tutto ciò che è contrassegnato come dato personale vengono mascherati nel browser, prima che un replay venga inviato da qualche parte.
  • Le analisi sono subordinate al consenso e disattivate finché un'organizzazione non le attiva. Nulla che riguardi un minore viene profilato, su nessuna superficie.
Sicurezza dell'AI

Che cosa succede al testo prima che raggiunga un provider AI

Il messaggio di un discente, un PDF caricato, una domanda scritta nel copilot: è tutto contenuto, nessuna di queste cose è un'istruzione. Quella distinzione è imposta, non chiesta in un prompt.

Classificazione delle injection

L'input non attendibile viene classificato prima che parta la chiamata vera. Il testo che tenta di deviare il modello viene segnalato invece che eseguito.

Una recinzione randomizzata

Il testo non attendibile viene racchiuso in un tag, diverso per ogni richiesta, che non può indovinare, e quel tag viene rimosso dal contenuto stesso. Il troncamento richiude la recinzione invece di lasciarla aperta.

Oscuramento prima della chiamata

Nomi, email e identificativi vengono sostituiti prima che qualcosa parta verso un provider. La valutazione avviene su un elaborato anonimizzato; la corrispondenza con il discente resta sul nostro server.

Validazione dello schema di output

Ogni risposta viene validata rispetto a uno schema. Una risposta malformata ha un solo tentativo di riparazione e poi fallisce, invece di finire dentro un corso.

Una tracciabilità dalla proposta alla modifica

Richieste, bozze accettate e bozze rifiutate sono voci distinte nello stesso log concatenato con hash. Ciò che il modello ha suggerito sta accanto a ciò che una persona ha applicato.

Identità

Come accedono le persone

Scritto come serve a un revisore di sicurezza: che cosa è disponibile oggi, e che cosa no.

Account su invito

Gli account vengono creati da un amministratore o da un invito — non esiste la registrazione self-service. I link di reimpostazione e recupero sono monouso e conservati come hash.

Accesso partner (silent SSO)

Un sistema partner che ha già autenticato una persona può consegnarla con un'asserzione firmata, così il discente non vede mai un secondo login. Si configura per organizzazione, con una chiave dedicata, ed è revocabile.

Single sign-on SAML e OIDC

In roadmap

Non costruito. Se il suo rollout dipende da Entra ID o Okta, lo dica alla prima chiamata e le diremo a che punto siamo invece di lasciar intendere che ci sia.

MFA e passkey

In roadmap

Anch'esse in roadmap. Oggi il provider di identità gestisce la password, le sessioni possono essere revocate dal loro titolare e la revoca ha effetto al controllo dei permessi successivo.

Sub-responsabili

Tutti quelli che toccano i suoi dati

Cinque, e ciascuno è indicato nell'accordo sul trattamento dei dati invece di essere scoperto dopo.

CapabilityChe cosa gestisceDove si applica
SupabaseDatabase, autenticazione, archiviazione dei file e le funzioni su cui gira l'APIIl responsabile principale. Lo storage dei media può puntare su S3, Azure o GCS.
CloudflareDNS, TLS e il dominio personalizzato su cui viene servita ogni organizzazioneTermina il TLS per i domini di ogni organizzazione; i certificati sono emessi automaticamente.
OpenAIGenerazione AI, tutoring e bozze di valutazioneChiamato solo quando una richiesta lo richiede, dopo l'oscuramento. Al suo posto si possono configurare Anthropic e Google, e un'organizzazione può collegare la propria chiave.
ResendEmail transazionali — inviti, notifiche, reimpostazioniUn'organizzazione può inviare dal proprio sottodominio, con la propria chiave.
PostHogAnalisi di prodotto e session replay mascheratoRegione UE. Le superfici dei discenti non vengono registrate.

L'elenco che fa fede è quello nell'accordo sul trattamento dei dati, insieme all'appendice FERPA sulla privacy dei dati degli studenti per le scuole. Li inviamo entrambi prima di una chiamata, non dopo.

Accessibilità

WCAG 2.1 AA, e ciò che non abbiamo

Lurno è costruito secondo WCAG 2.1 AA. I controlli automatici axe girano in integrazione continua, quindi un contrasto insufficiente o un'etichetta mancante interrompono una build invece di arrivare a un rilascio. Percorsi da tastiera, focus visibile e preferenze di riduzione del movimento vivono nella libreria dei componenti invece di essere aggiunti a posteriori schermata per schermata. Il prodotto è disponibile in inglese, francese, arabo e italiano, e l'arabo è da destra a sinistra ovunque, non un layout da sinistra a destra tradotto.

Quello che non abbiamo è un VPAT o un audit di accessibilità di terze parti, e preferiamo scriverlo qui invece di seppellirlo nella risposta alla domanda 47. Se un rapporto formale di conformità è una condizione d'acquisto, lo sollevi subito — è una conversazione di scoping, non una casella da spuntare.

Domande che fa l'ufficio acquisti

Risposte prima che debba mandare il questionario

No. Lurno è allineato alle pratiche ISO 27001 — controllo degli accessi, crittografia, logging, gestione delle modifiche e gestione dei fornitori sono implementati come controlli nel prodotto — ma Augmental Learning Inc. non possiede alcun certificato ISO 27001 né alcun report SOC 2. Preferiamo essere verificabili che impressionanti. Tutto ciò che c'è in questa pagina può essere dimostrato in una sessione dal vivo.

Ci mandi il questionario.

Gran parte ha già una risposta qui sopra. Porti il resto — residenza, conservazione, sub-responsabili, il DPA — a una chiamata, e risponderemo con le stesse parole semplici che abbiamo usato qui.