Modelli di deployment
Corellix viene consegnato in due forme. Il codice applicativo è lo stesso: quello che cambia è dove gira, chi lo gestisce e dove restano i dati.
Corellix Cloud
Sezione intitolata “Corellix Cloud”SaaS multi-tenant, ospitato e gestito da Corellix su Microsoft Azure.
- Nessuna infrastruttura da installare o mantenere.
- Aggiornamenti applicati da Corellix, in modo continuo.
- Alta disponibilità e scalabilità gestite dalla piattaforma.
- Licenza a sottoscrizione.
- Il portale del cliente risponde su
https://<slug>.services.corellix.io.
Perché i dati arrivino al cloud servono comunque dei punti di raccolta dentro l’infrastruttura del cliente: gli agent installati sulle macchine e, dove le API delle piattaforme non sono esposte verso l’esterno, un’appliance Beacon che raccoglie in locale e trasmette verso il cloud.
Adatto a: managed service provider, service provider, aziende che vogliono partire in fretta senza costruire nulla.
CorellixOS
Sezione intitolata “CorellixOS”Appliance on-premise: un’immagine di sistema immutabile basata su Rocky Linux, che porta con sé un cluster Kubernetes RKE2 e tutti i componenti della piattaforma.
- Deployment di proprietà del cliente, single-tenant.
- I dati non lasciano mai il perimetro: raccolta, elaborazione e archiviazione sono locali.
- Supporto ad ambienti completamente disconnessi (air-gapped).
- Integrazione con l’identity provider e la PKI aziendali.
- Ciclo di vita indipendente: si aggiorna quando decidete voi.
- Il portale risponde su
https://<slug>.services.<vostro-dominio>.
Adatto a: datacenter enterprise, pubblica amministrazione, infrastrutture critiche, settori regolamentati, chiunque abbia vincoli di residenza del dato.
Confronto
Sezione intitolata “Confronto”| Corellix Cloud | CorellixOS | |
|---|---|---|
| Gestione | Corellix | Cliente |
| Tenancy | Multi-tenant | Single-tenant |
| Dove restano i dati | Azure (regione scelta) | Dentro il vostro perimetro |
| Aggiornamenti | Continui, gestiti | Pianificati dal cliente via CoreLCM |
| Air-gap | No | Sì |
| Alta disponibilità | Della piattaforma | Da 3 nodi in su |
| Corell!A | Provider cloud o locale | Modello locale per impostazione predefinita |
| Portale documentazione | docs.corellix.io | docs.<vostro-dominio>, nel cluster |
| Tempo di attivazione | Minuti | Da qualche ora a un giorno |
Modalità di connettività on-prem
Sezione intitolata “Modalità di connettività on-prem”Un’installazione CorellixOS dichiara come può uscire verso Internet. La scelta si fa al provisioning e si cambia in seguito da CoreCLI.
| Modalità | Traffico in uscita | Conseguenze |
|---|---|---|
| Connected | Completo | Tutte le funzionalità, aggiornamenti automatici, mirror delle immagini, accesso remoto ZTNA |
| Proxy-only | Solo attraverso il proxy HTTP(S) configurato | Aggiornamenti via mirror sul proxy con allow-list; ZTNA non disponibile |
| Air-gapped | Nessuno | Aggiornamenti solo da bundle importati a mano; nessun accesso remoto ZTNA |
Il portale documentazione è disponibile identico in tutte e tre le modalità: essendo un componente del cluster, non dipende da alcuna risorsa esterna. Vedi Ambienti air-gapped.
Modello ibrido
Sezione intitolata “Modello ibrido”I due modelli convivono. Uno scenario ricorrente è il service provider che opera la propria istanza cloud e, per i clienti con vincoli di residenza del dato, installa CorellixOS presso di loro mantenendo un accesso remoto controllato al portale di quel cliente.
L’accesso remoto in questo scenario passa da un tunnel ZTNA dedicato: esiste per questo caso d’uso specifico — permettere al provider di raggiungere il portale del cliente — e non è un servizio di accesso generico per gli utenti finali.