Entrambi i fattori, o nessuno
Un nome utente, una password e un codice dalla tua strumenti di autenticazione. La sessione viene emessa dopo entrambi i fattori e solo dopo entrambi.
Sicurezza e sovranità
Una password e un codice di autenticazione ogni volta, oppure il tuo provider di identità.
I tuoi dati sono l’unica cosa che la IA riesce a raggiungere.
La IA lavora dentro un motore di database avviato senza accesso esterno: legge i dati che le hai dato e nient’altro sulla macchina. Quel confine è il motore stesso, non un elenco di parole da sorvegliare, ed è per questo che tiene comunque sia formulata una domanda.
L’autenticatore fa parte del prodotto, e la sessione viene emessa solo dopo entrambi i fattori.
Un nome utente, una password e un codice dalla tua strumenti di autenticazione. La sessione viene emessa dopo entrambi i fattori e solo dopo entrambi.
Ognuna è sottoposta a hash con scrypt a N=2^17, volutamente lento e avido di memoria: un file rubato vale pochissimo per chi lo ha preso.
Una email sbagliata e una password sbagliata impiegano lo stesso tempo, perché fanno lo stesso lavoro. Il tempo non dice nulla a un attaccante su chi abbia un account qui.
Limitazione e blocco agiscono per account e per indirizzo, e vengono verificati prima dell hashing costoso: limitano quindi anche il costo macchina, oltre ai tentativi.
La scoperta del dominio legge il dominio e ti manda al provider di identità che lo possiede. Nient’altro su di te serve per instradare la richiesta.
Qualsiasi provider di identità SAML 2.0, collegato uno per dominio email cliente. Le tue persone trovano la schermata di accesso che già conoscono.
Viene validata sul certificato proprio di quella connessione, e l’email asserita viene ancorata al dominio proprio di quella connessione.
Poiché il legame è al dominio, un’asserzione firmata di un tenant si risolve su quel tenant e solo su quello.
L’accesso comincia qui, e ogni richiesta porta un nonce monouso speso appena torna indietro: una risposta riprodotta non ha più nulla da spendere.
Due timer che girano insieme, e una modifica di accesso che vale già alla richiesta successiva.
Allontanati e la sessione si chiude da sola. Tornare ti costa dieci secondi, e costa parecchio di più a chi trovasse il tuo portatile.
Il tetto lungo sta in piedi da solo. L’attività sposta il timer di inattività e lascia le dodici ore esattamente dov’erano: una sessione ha una fine anche nel giorno più pieno.
Disattiva qualcuno, cambia una password o reimposta un autenticatore, e ogni sua sessione attiva finisce al primo utilizzo successivo.
Nessun ruolo viaggia mai dentro un token. Una modifica nella directory vale subito, e non quando un token per caso scade.
Una guardia atomica mantiene sempre almeno un amministratore attivo, così qualcuno può sempre raggiungere il back office. È una regola piccola, ed è la differenza fra un pomeriggio tranquillo di riordino e un ticket che nessuno ama scrivere.
Ogni strumento della suite è completo senza IA, ed è una proprietà del software.
Ogni strumento produce il risultato completo sul proprio motore deterministico. Lascia la IA spenta e nulla raggiunge un provider di modelli.
Attivala e gira sulla chiave che hai fornito, con il provider che hai scelto, alle condizioni che hai negoziato con lui. Non forniamo chiavi e non teniamo alcun pool condiviso.
Il client compatibile con OpenAI accetta qualsiasi endpoint tu indichi: puoi puntarlo a un proxy dentro la tua rete, e allora non ne esce proprio nulla.
Ogni rilievo porta un identificativo CIS Controls v8.1 e una funzione NIST CSF 2.0.
Guard marca ogni rilievo che solleva con un identificativo di misura CIS Controls v8.1 e una funzione NIST CSF 2.0, in modo deterministico, e quella marcatura viaggia con il rilievo nel suo CSV, nel suo SARIF, nel suo PDF e a schermo. Il tuo revisore riceve un rilievo con il riferimento di controllo già attaccato, in un formato che i suoi strumenti leggono.
Sono evidenze di audit mappate. Non sono una certificazione, e questo prodotto non ne rilascia. Preferiamo dirlo sul sito piuttosto che farvelo scoprire durante l’audit, e la stessa regola vale per ogni altra affermazione qui.
La tua pista di controllo si scrive mentre lavori.
Le modifiche governate finiscono in un registro concatenato con semplice SHA-256, senza chiave segreta. Il tuo revisore può riverificarne l’integrità dall’export con i propri strumenti, senza doversi fidare della nostra parola.
L’irrobustimento sta nel modo in cui l’immagine è costruita e nel controllo della pipeline.
| Livello | Che cosa è in atto |
|---|---|
| Il container | L’applicazione gira come utente non privilegiato, uid 10001. Root viene usato una sola volta, per prendere possesso del volume dati, e abbandonato prima che qualsiasi cosa parta. |
| Ogni risposta | Header di sicurezza su tutte, compresa una policy che tiene l’app fuori dal frame di chiunque altro. |
| L’accesso | Limitazione e blocco, per account e per indirizzo. |
| Ogni modifica | Un token CSRF su ogni mutazione, legato alla tua sessione. |
| I file su disco | Scritti in modo atomico a 0600, così un segreto scritto a metà non è mai leggibile. |
| La cifratura | Una chiave derivata a parte per ogni scopo, così un segreto non fa mai in silenzio due mestieri. |
| Le dipendenze | Ognuna fissata a un commit esatto, gateway compreso. |
| L’immagine spedita | Non contiene alcun installatore di pacchetti. |
| La pipeline | Una scansione delle vulnerabilità che fa fallire la build, contro una lista di esclusione vuota. |
Tutto in questa pagina è un valore dentro un file, e il file te lo mostriamo volentieri.