Documento pubblico sulla sicurezza
Sicurezza: controlli, limiti e segnalazioni.
La piattaforma custodisce credenziali e fa eseguire workflow con modelli linguistici sui dati aziendali. Qui descriviamo le protezioni applicate e ciò che resta fuori dal loro perimetro.
I controlli applicati
Nove invarianti sono dichiarate nel repository e verificate da codice e test identificati.
| Invariante | Applicazione pratica |
|---|---|
| Le credenziali non vengono mai scritte in chiaro | Cifratura a busta con chiave per organizzazione. Se la chiave di cifratura delle chiavi non è disponibile, il servizio non si avvia. Non esistono percorsi alternativi per lo sviluppo. |
| Nessun segreto entra nel contesto di mklang | Uno step non riceve credenziali: il runtime dei connettori le risolve al momento della chiamata. I checkpoint della piattaforma vengono cifrati prima di raggiungere il database. |
| Un webhook non verificato non avvia nulla | La firma HMAC copre corpo originale e timestamp. Firme mancanti, errate, scadute o sconosciute ricevono la stessa risposta. |
| Senza credenziali l’accesso è negato | Nessuna configurazione rende facoltativa l’autenticazione. Un test percorre le route registrate per verificare che nuovi endpoint non restino senza protezione. |
| Le letture tra organizzazioni richiedono due guasti indipendenti | I dati sono protetti sia dal controllo dell’organizzazione nell’applicazione sia dalla row-level security forzata di PostgreSQL. |
| Le risposte dei connettori sono dati esterni | La provenienza viene marcata prima che i dati raggiungano una valutazione, così che i controlli di provenienza e di flusso possano applicarsi. |
| Il logging usa un elenco di campi ammessi | Un campo aggiunto domani da un fornitore viene oscurato per impostazione predefinita. |
| Le credenziali del data plane sono limitate all’uso previsto | Il control plane rinnova le credenziali; il runner effettua le chiamate. I refresh token e il materiale necessario solo a ottenere un nuovo token restano dietro il broker. |
| Un’azione esterna viene registrata prima della chiamata e confermata dopo | Una registrazione ambigua ferma l’esecuzione. L’esecuzione durevole è almeno una volta: nessuna politica di retry può superare questa condizione. |
Inoltre, ogni modifica viene registrata nell’audit nella stessa transazione del database che la applica.
Il modello di minaccia
Nel perimetro
- Accesso ai dati di altre organizzazioni: controlli applicativi, row-level security e isolamento del calcolo per esecuzione.
- Compromissione delle credenziali: chiavi per organizzazione e revoca visibile nello stato delle connessioni.
- Prompt injection che raggiunge un’azione: i dati esterni sono tracciati strutturalmente e la piattaforma rifiuta le azioni raggiunte attraverso decisioni contaminate.
- Workflow ostili: prima dell’esecuzione vengono verificate la firma del bundle e ogni file nel manifest firmato.
- Esaurimento delle risorse: quote per concorrenza, esecuzioni e token.
Fuori dal perimetro
- Compromissione del fornitore del modello: questa dipendenza di fiducia viene dichiarata, non neutralizzata.
- Compromissione delle API esterne chiamate dai connettori.
- Utenti di un’organizzazione che agiscono nei propri permessi: l’autorizzazione limita le azioni e l’audit le registra.
- Sicurezza fisica e dell’hypervisor del provider di hosting.
- Garanzie di disponibilità: nessun accordo sul livello di servizio viene offerto finché non ne viene venduto uno.
Il codice Python viene eseguito in container temporanei senza credenziali dell’host, con durata limitata e senza rete. JavaScript e gli elenchi di destinazioni di rete non vuoti vengono rifiutati perché non implementati.
Dove risiedono i dati
La piattaforma tratta i dati dei workflow su istruzione del cliente. La tabella descrive dove sono conservati; i dati necessari alle valutazioni raggiungono anche il fornitore del modello.
| Classe | Dove | Cifratura a riposo | Conservazione |
|---|---|---|---|
| Credenziali | Control plane | Chiave DEK per organizzazione | Fino alla revoca; cancellazione dell’intera organizzazione tramite procedura operativa |
| Payload degli step, contesti e checkpoint | Data plane | Chiave data plane per organizzazione | Nessuna scadenza automatica attuale |
| Metadati delle esecuzioni | Control plane | A livello database | Nessuna scadenza automatica attuale |
| Tracce di esecuzione | Data plane | Chiave data plane per organizzazione | 30 giorni predefiniti, configurabili da 1 a 365 |
| Eventi di audit | Control plane | A livello database | Sola aggiunta; nessuna scadenza automatica attuale |
L’hosting è in Germania. I backup vengono verificati e il ripristino è stato provato su un host temporaneo. Le copie fuori dall’host sono cifrate con una chiave che l’host non possiede.
Il fornitore del modello è un sub-responsabile: riceve i dati necessari alla valutazione secondo la configurazione del deployment. Il cliente fornisce una connessione al provider; le credenziali non entrano negli input degli step.
Segnalare una vulnerabilità
Verifica soltanto risorse tue. Non aprire issue pubbliche: l’host di produzione non è un bersaglio di test pubblico.
Scrivi in privato a info@gianlucamazza.it, con oggetto “mklang platform security”. Per inviare email cifrate, chiedi prima una chiave con un messaggio in chiaro.
| Impegno | Termine |
|---|---|
| Conferma di ricezione | Tre giorni lavorativi |
| Valutazione con gravità e decisione | Dieci giorni lavorativi |
| Correzione, mitigazione o motivazione scritta | Comunicata con la valutazione |
| Riconoscimento della segnalazione | Se desiderato |
Evidenze per la revisione
Una revisione di sicurezza che richiede di leggere il codice è uno dei criteri dichiarati per avviarne la pubblicazione. La richiesta apre quella valutazione.
Le affermazioni fattuali sul sito rimandano a un registro incluso nei sorgenti e alle relative evidenze. La build verifica che test, documenti e riferimenti registrati esistano ancora; la correttezza del contenuto richiede anche una revisione umana.