Modello di sicurezza

Principi

Zero trust. Nessuna richiesta è affidabile per provenienza. L’appartenenza alla rete interna non è una credenziale.

Minimo privilegio. Ogni componente e ogni utente hanno i permessi che servono e nessuno in più.

Impostazioni sicure. Ciò che è pericoloso è disattivato di partenza e va attivato consapevolmente.

Difesa in profondità. Nessun controllo è l’unico. Il fallimento di uno non compromette il sistema.

Verifica continua. Certificati, permessi, configurazioni e conformità sono sorvegliati, non verificati una volta all’installazione.

Autenticazione

Chi	Come
Utenti del portale	Credenziali locali o identity provider aziendale, con MFA
Integrazioni	Chiave API, revocabile, con i permessi di chi l’ha creata
Agent	Chiave dedicata, limitata agli endpoint di ingest
Servizi fra loro	Chiave interna e mTLS dentro il cluster
Amministratori dell’appliance	Credenziali di piattaforma su Citadel e CoreCLI

Le sessioni utente usano token JWT con scadenza di 60 minuti, rinnovabili finché la sessione è valida.

Autorizzazione

Il modello dei permessi è granulare e si applica ovunque: portale, API, Corell!A. Non ci sono percorsi che lo aggirano — il portale usa le stesse API pubbliche, con gli stessi controlli.

Vedi Utenti e permessi.

Cifratura

In transito. TLS su tutte le comunicazioni esterne; mTLS fra i servizi di piattaforma dentro il cluster. Vedi Certificati e TLS.

A riposo. I volumi dell’appliance sono cifrabili a livello di storage. I segreti Kubernetes sono cifrati da Arcanum: una copia di etcd senza Arcanum non è leggibile.

Credenziali privilegiate. Cifrate dal motore transit di Arcanum, con la chiave che non lascia mai il servizio.

Segreti

Nessun componente ha credenziali in un file di configurazione. Ogni servizio si autentica ad Arcanum con la propria identità e riceve solo i segreti del proprio ambito.

Le credenziali inserite dagli utenti — connettori, provider AI, account PAM — non sono più leggibili dopo l’inserimento. Si possono sostituire, non consultare, e questo vale anche per gli amministratori.

Superficie esposta

La superficie verso l’esterno è minima e definitiva:

Porta	Servizio
443/TCP	Tutto il traffico applicativo, smistato per hostname
8443/TCP	Citadel, la console dell’appliance
22/TCP	Solo per la procedura di break-glass

Tutto il resto è interno al cluster. Le comunicazioni fra i nodi usano una rete di cluster con policy di rete attive.

Isolamento dei dati

Su Corellix Cloud i tenant sono isolati a livello di database: un database globale per la configurazione di piattaforma e un database per tenant per i dati del cliente.

Su CorellixOS l’appliance è single-tenant per costruzione: il problema non si pone.

Audit

Sono registrati:

• gli accessi e i tentativi falliti;
• le operazioni che modificano configurazione o stato;
• gli accessi ai segreti;
• le sessioni privilegiate, con registrazione obbligatoria;
• le esecuzioni di script e comandi remoti;
• le operazioni di lifecycle sull’appliance;
• gli accessi di break-glass alla shell.

Gli audit sono consultabili dal portale e da Citadel, ed esportabili verso un SIEM.

Aggiornamenti di sicurezza

L’immagine CorellixOS è ricostruita periodicamente con gli aggiornamenti di sicurezza del sistema operativo e delle dipendenze. Il canale di aggiornamento è lo stesso degli aggiornamenti funzionali; le vulnerabilità che richiedono attenzione immediata sono comunicate separatamente.

Il fatto che l’immagine sia immutabile ha una conseguenza rilevante: non si applicano patch a un’appliance in esecuzione, si sostituisce l’immagine. Due appliance alla stessa versione sono identiche, il che elimina la deriva di configurazione come categoria di problema.

Segnalare una vulnerabilità

Scrivete a security@corellix.io. Le segnalazioni ricevono riscontro e sono gestite secondo un processo di divulgazione responsabile.