Costruito sicuro predefinitivamente.
Configurabile al tuo livello di rischio.

L'indicizzazione e la ricerca dei documenti rimangono sulla tua VM ReefOffice: bge-m3 crea gli embedding localmente e Qdrant memorizza il testo e i vettori localmente. Su un pilot Private AI, la generazione gira sull'infrastruttura GPU gestita da ReefOffice in Germania tramite un tunnel crittografato. La tua richiesta e gli estratti rilevanti dei documenti raggiungono quella GPU, mentre i tuoi file sorgente, indice, conversazioni e dati dell'applicazione rimangono sulla tua VM. La conservazione da parte del provider e le garanzie contrattuali sono in fase di validazione prima della disponibilità a pagamento. Se connetti la tua chiave AI esterna, quel provider riceve la richiesta e gli estratti selezionati secondo i propri termini.

Le automazioni preconfigurate (indicizzazione documenti, sollecito fatture, archiviazione contratti, configurazione affare chiuso,…) girano in un runtime di automazione solo per operatori gestito da ReefOffice — non in Activepieces, il builder no-code che il tuo team utilizza. Le credenziali di cui hanno bisogno (i tuoi account amministratore Nextcloud / Dolibarr / Paperless, il relay postale) vengono memorizzate crittografate e lette solo dal job in esecuzione tramite credenziali di runtime limitate al job; non vengono mai scritte in alcuna definizione di flusso di lavoro che un utente può aprire. Quando l'agente AI privato attiva una delle automazioni approvate, chiama un shim locale nella whitelist che inietta le credenziali lato server, così l'agente non riceve mai credenziali generali del motore di automazione. La tua sandbox Activepieces contiene zero credenziali di operatore, e l'accesso di runtime viene applicato solo per operatori ad ogni deploy, così un account stale non può permanere con l'accesso. Questo chiude la classe di rischio in cui un'automazione integrata diventa un modo per leggere fuori una password amministrativa.

Corretto, e questo è per design — LUKS è lo strumento giusto per le minacce del disco a riposo (dischi fisici, dismissione e snapshot che non includono i materiali di sblocco dell'avvio). Per un server in esecuzione applichiamo un livello separato di controlli integrato in ogni build NixOS: ptrace è limitato (scope=3) per impedire l'ispezione dei processi, kexec è disabilitato così il kernel non può essere sostituito a runtime, l'eBPF non privilegiato è bloccato, i puntatori del kernel sono nascosti (kptr_restrict=2), l'userfaultfd non privilegiato è disabilitato, la creazione di io_uring non privilegiata è limitata e i coredump vengono soppressi. La disabilitazione completa di io_uring rimane disponibile per deploy hardened speciali, ma la predefinita mantiene la compatibilità con l'infrastruttura privilegiata. L'immutabilità di NixOS significa che nessun gestore di pacchetti può installare silenziosamente binari inaspettati. La scansione CVE giornaliera (vulnix) rileva pacchetti vulnerabili e riporta i risultati nella dashboard.

Sì — ogni server esegue una scansione CVE giornaliera usando vulnix, uno strumento nativo di NixOS. Poiché NixOS fissa le versioni esatte dei pacchetti come hash crittografici (build riproducibili), vulnix può confrontare ogni pacchetto installato con il National Vulnerability Database in pochi secondi. I risultati appaiono nella scheda Sicurezza della tua dashboard con nome del pacchetto, versione e ID CVE. NixOS di solito distribuisce un pacchetto corretto entro 24-48 ore dalla disclosure di un CVE — la scansione giornaliera successiva conferma la correzione. Questo è qualcosa che la maggior parte degli stack self-hosted non può fare senza strumentazione significativa; qui funziona out of the box.

La modalità air-gapped è la risposta completa — non deteniamo alcuna chiave SSH, così una compromissione completa della nostra infrastruttura non ha percorso SSH verso la tua VM. In modalità Gestita, il registro di audit con hash concatenato registra le operazioni del pannello di controllo. Inoltre, puoi abilitare l'opzionale email di riepilogo settimanale dalle impostazioni del tuo account: riassume le attivazioni/disattivazioni dei servizi, i risultati degli aggiornamenti NixOS e il conteggio CVE sui tuoi server — dando una conferma regolare, prevista e facilmente leggibile che nulla di inaspettato è successo. Qualsiasi anomalia in quel riepilogo è un segnale precoce per rivedere il registro di audit completo.

LUKS protegge il file system root crittografato se qualcuno ottiene l'accesso a un disco root rimosso o a uno snapshot del disco root senza i materiali di sblocco dell'avvio. ReefOffice usa LUKS non attended così i server possono riavviare automaticamente, il che significa che la partizione di avvio e l'initrd sono una parte separata del modello delle minacce. Un'immagine completa del provider sia dello storage di avvio che di root non è la stessa di un disco root rimosso crittografato. I percorsi rimanenti della VM in esecuzione, come la memoria a livello hypervisor o l'accesso a runtime, sono governati dai controlli del provider, contratti e audit piuttosto che da LUKS.

Un aggressore dovrebbe compromettere la VM in esecuzione, o ottenere sufficiente materiale di avvio e accesso al disco per sbloccare il file system root crittografato, poi leggere /etc/reefoffice/secrets.env. La chiave di backup non è mai nel database del pannello di controllo ReefOffice. Se il tuo requisito di conformità è che la chiave di backup deve essere irraggiungibile sotto qualsiasi compromissione a livello VM, la modalità a conoscenza zero rimuove la custodia della chiave di backup di ReefOffice dopo la consegna.

Alla prima connessione SSH dopo il provisioning, il pannello di controllo registra la public host key della VM (Trust On First Use — TOFU). Ogni connessione successiva verifica che la key corrisponda a quel record. Una corrispondenza errata — che indica che la VM è stata sostituita o che un MITM è stato inserito — causa il fallimento immediato della connessione e viene scritta nel registro di audit. Questo significa che una VM contraffatta non può intercettare silenziosamente il traffico di gestione anche se DNS o routing IP sono compromessi.

Il tuo server gira su Contabo GmbH, un'azienda di hosting tedesca fondata nel 2003 con i propri datacenter a Monaco e Norimberga — non un rivenditore. Contabo serve oltre 225.000 clienti in 190 paesi su oltre 450.000 server, e il monitoraggio indipendente di HOSTtest ha registrato il 100% di uptime per il Q3 2025 e il Q4 2024. Contabo è una società tedesca registrata (Amtsgericht München, HRB 180722).