Vai al contenuto

Sicurezza del parco — nota di architettura

Traduzione automatica dell'originale francese.

Ciò che questa pagina afferma, e ciò che deliberatamente omette

Descrive i sistemi di sicurezza, le loro connessioni e i relativi flussi. Non fornisce nessun indirizzo IP, nessun nome host, nessun nome utente, nessun FQDN di servizio. Gli host sono identificati dal loro ruolo.

Questa scelta non è una questione di cortesia: una pagina di documentazione, anche dopo l'autenticazione, alla fine viene copiata in un ticket, uno screenshot o un portapapella. Un'architettura rimane un'architettura senza le sue coordinate; una lista di FQDN pubblici, invece, è una mappa d'attacco pronta all'uso.

Le coordinate risiedono nel vault privato e nel vault. Consultare Visualizzare un segreto dal vault.

La stessa regola vale per le sottosezioni di questa sezione, con un'ulteriore clausola: nessun punto debole ancora presente. Descrivono l'architettura, i principi e il modo in cui vengono verificati; lo stato attuale — ciò che è in corso, ciò che fallisce — risiede nel vault privato e nel pannello di conformità.

Il principio guida

Il parco non ha un unico perimetro da difendere. Ha strati che falliscono separatamente: un attaccante che riesce a superare uno, deve comunque superare il successivo, e ogni superamento lascia una traccia in un sistema che lo strato precedente non controlla.

Quattro regole governano l'insieme:

  1. Un'unica autorità di identità. Nessun servizio gestisce i propri account se può delegare. Un abbandono, una password compromessa, un secondo fattore: un unico punto di contatto.
  2. Ciò che rileva non è necessariamente ciò che esegue. I log di un sistema partono da un altro luogo. Un sistema compromesso può mentire su se stesso, ma non può cancellare ciò che è già andato.
  3. Il silenzio è uno stato sospetto. Un sensore che non dice nulla e un sensore morto producono la stessa assenza. Pertanto, ogni catena di rilevamento deve avere un elemento funzionale: non un contatore che dice "sono attivo", ma un caso noto, introdotto esplicitamente, che deve essere rilevato ad ogni passaggio.
  4. Dimostrare, non dichiarare. Ogni controllo è misurato da un sensore che è stato visto fallire almeno una volta; la sua valutazione viene registrata in un registro che non può essere riscritto senza che ciò venga rilevato, e lo stato "conforme" viene calcolato sulla base delle prove — non si basa mai su un singolo elemento. Consultare Conformità e prove.

La sezione in sintesi

La difesa del parco si articola in quattro funzioni, e una quinta che le verifica tutte:

flowchart LR
    classDef p fill:#0f766e,stroke:#0f766e,color:#fff
    classDef d fill:#7c2d12,stroke:#7c2d12,color:#fff
    classDef r fill:#9a3412,stroke:#9a3412,color:#fff
    classDef c fill:#1e40af,stroke:#1e40af,color:#fff
    classDef g fill:#3f3f46,stroke:#3f3f46,color:#fff

    prev["PRÉVENIR<br/>périmètre · identité · secrets<br/>chaîne d'approvisionnement · correctifs"]:::p
    det["DÉTECTER<br/>SIEM · exécution · réseau<br/>fichiers · vulnérabilités"]:::d
    rep["RÉPONDRE<br/>notification unique · réponse automatique<br/>investigation · registre d'incidents"]:::r
    cont["SURVIVRE<br/>sauvegardes immuables · restauration chronométrée<br/>clé maîtresse hors ligne"]:::c
    prouv["PROUVER<br/>catalogue de contrôles · sondes<br/>registre chaîné · ancre git"]:::g

    prev --> det --> rep --> cont
    prouv -.->|"mesure"| prev
    prouv -.->|"mesure"| det
    prouv -.->|"mesure"| rep
    prouv -.->|"mesure"| cont
Pagina Cosa si trova
Questa pagina L'architettura: i livelli, le loro connessioni, i loro flussi — e la prevenzione
Rilevamento Una domanda, un motore: SIEM, esecuzione, rete, file, vulnerabilità — e i loro elementi funzionali
Risposta Notifica, risposta automatica limitata, indagine approfondita, registro degli incidenti
Continuità Livelli di backup, immutabilità, esercizio di ripristino, chiave maestra
Conformità e prove NIS2 e SOC 2 come quadro di riferimento, controlli, sensori, registro concatenato, audit
Glossario Ogni termine e il suo significato all'interno di questo parco

Panoramica

flowchart TB
    classDef edge fill:#0f766e,stroke:#0f766e,color:#fff
    classDef det fill:#7c2d12,stroke:#7c2d12,color:#fff
    classDef id fill:#1e40af,stroke:#1e40af,color:#fff
    classDef data fill:#3f3f46,stroke:#3f3f46,color:#fff

    client["Client Internet"]

    subgraph perimetre["1 · Périmètre"]
        dns["DNS public<br/>zone déléguée au registrar"]
        nat["Routeur — NAT entrant<br/>un seul port ouvert"]
        edge["Proxy de bordure<br/>terminaison TLS · sur le NAS"]:::edge
        proxy["Proxy interne<br/>routage · en-têtes · journalisation"]:::edge
        ips["CrowdSec<br/>analyse des journaux → 403"]:::edge
    end

    subgraph identite["2 · Identité"]
        idp["Fournisseur d'identité<br/>OIDC · SAML · MFA"]:::id
        fa["forward_auth<br/>mur, sans identité applicative"]:::id
    end

    subgraph prive["3 · Réseau privé"]
        cp["Plan de contrôle VPN<br/>auto-hébergé sur le VPS"]:::edge
        mesh["Maillage WireGuard<br/>chiffré de bout en bout"]:::edge
        dnsf["Filtrage DNS<br/>listes + horizon dédoublé"]:::edge
    end

    subgraph contenu["4 · Contenu"]
        av["Moteur antivirus central<br/>un seul daemon, protocole INSTREAM"]:::det
        yara["Analyse statique profonde<br/>dépliage récursif · YARA"]:::det
        quar["Quarantaine partagée<br/>sur le NAS"]:::data
    end

    subgraph detection["5 · Détection et réponse"]
        siem["SIEM / XDR<br/>intégrité fichiers · CVE · MITRE"]:::det
        fleet["Collecte journaux + métriques"]:::det
        rt["Détection à l'exécution<br/>appels système · eBPF"]:::det
        ids["IDS réseau<br/>signatures sur le trafic"]:::det
        ar["Réponse automatique<br/>blocage à durée limitée"]:::det
        hub["Répartiteur d'alertes"]:::det
        chat["Messagerie d'équipe<br/>deux destinations"]:::det
        dfir["Investigation à chaud<br/>client sur chaque machine"]:::det
    end

    subgraph socle["6 · Socle"]
        coffre["Coffre de secrets"]:::data
        sops["Secrets chiffrés au repos<br/>dans le dépôt"]:::data
        backup["Dépôts de sauvegarde chiffrés<br/>ajout seul · copies hors site"]:::data
        smart["Santé des disques"]:::data
        preuve["Registre de preuves<br/>chaîné · ancré dans git"]:::data
    end

    client --> dns --> nat --> edge --> proxy
    proxy --> ips
    ips -->|"IP décidée"| proxy
    proxy --> idp
    proxy -.->|"dernier recours"| fa
    idp --> proxy

    mesh --- cp
    mesh --- dnsf

    av --> quar
    yara --> quar

    proxy --> siem
    av --> siem
    yara --> siem
    fleet --> siem
    siem --> hub --> chat
    smart --> hub
    rt -.->|"après mesure du bruit"| hub
    ids -.->|"après mesure du bruit"| hub
    siem -->|"identifiant de règle"| ar
    chat -.->|"enquête"| dfir

    coffre -.-> sops
    backup -.-> quar
    siem -.->|"sondes"| preuve
    backup -.->|"sondes"| preuve

Lo schema è letto dall'alto verso il basso, nell'ordine in cui una richiesta malevola incontra le difese. Gli strati 5 e 6 hanno ciascuno la propria pagina: Rilevamento, Risposta, Continuità e Conformità e prove.

1 · Ambito e esposizione

La catena di ingresso

Una richiesta proveniente da Internet attraversa quattro dispositivi prima di raggiungere un contenitore: il risolutore pubblico, il router che effettua il NAT, un proxy di confine ospitato sul NAS, e poi un proxy interno sull'host Docker principale.

Il confine WAN non è l'host Docker

Questo è il punto più controintuitivo dell'architettura, e quello che richiede più tempo quando viene trascurato. Di conseguenza:

  • Qualsiasi filtraggio L3 eseguito sull'host Docker non blocca nulla proveniente da Internet: l'indirizzo sorgente che vede è quello del proxy di confine, mai quello del client.
  • Interrogare un servizio per nome dalla rete locale non testa il percorso WAN. La risoluzione è duplicata: lo stesso nome punta altrove a seconda da dove si richiede. Testare il WAN implica forzare la risoluzione verso l'indirizzo pubblico.

Dettaglio del percorso completo: Catena di reverse proxy e DNS e risoluzione.

Certificati

I certificati sono emessi da ACME tramite il challenge DNS-01, tramite l'API del registrar. Questa scelta ha una diretta conseguenza di sicurezza: non è necessario alcun record A pubblico per emettere un certificato. Un servizio può quindi essere servito in TLS sulla rete locale senza che il suo nome venga mai pubblicato in una zona DNS pubblica — la trasparenza dei certificati rimane, però, pubblica.

Rilevamento e remediazione applicativa

CrowdSec legge i log di accesso del proxy interno, decide e applica la sua decisione tramite un modulo integrato nel proxy, che risponde con 403. Utilizza anche una lista di blocco comunitaria.

È stato implementato dopo un audit superficiale che ha rilevato 74 indirizzi esposti e nessun sistema di rilevamento delle intrusioni. È l'unico componente che agisce sul contenuto di una richiesta HTTP; al di sopra, il NAT non ha alcuna conoscenza del HTTP.

Cosa CrowdSec non può vedere

Il proxy interno vede l'indirizzo reale del client solo se questo viene trasmesso in un header da un proxy di front-end, e solo se il proxy interno si fida di questo header. Un errore di configurazione in questo punto non causa alcun problema: semplicemente blocca il proxy di front-end, o non blocca nessuno. Il sintomo è un sistema che sembra funzionare.

2 · Identità e accesso

Un fornitore di identità unico (Authentik) gestisce gli account, i gruppi, il secondo fattore e le sessioni. Coesistono due modalità di connessione, e l'ordine di priorità è una regola, non un gusto:

Modalità Cosa impara il servizio Quando utilizzarla
OIDC / SAML nativo Identità, gruppi, ruoli, disconnessione Predefinito, non appena il servizio lo supporta
forward_auth Niente. Un muro davanti all'applicazione Ultima risorsa, per un servizio senza concetto di account

Non mai mettere entrambi sullo stesso servizio

Il proxy di autenticazione intercetta i percorsi di callback OAuth prima che raggiungano l'applicazione. Il risultato è un ciclo di connessione prodotto da tre componenti che sembrano tutti funzionare correttamente — ognuno svolge esattamente il proprio lavoro. Questo è un difetto che non si riflette in alcun log di errore.

L'accesso locale a un servizio viene disabilitato solo dopo un primo accesso federato di successo. L'ordine inverso comporta la disconnessione.

3 · Rete privata

I dispositivi non si connettono tramite i loro indirizzi di rete locale quando escono dalla rete locale. Un mesh WireGuard li collega, con un piano di controllo auto-ospitato situato sul VPS pubblico — quindi senza dipendenza da un servizio di terze parti per l'appartenenza alla rete.

Ne derivano due proprietà:

  • Un dispositivo al di fuori della rete locale comunica con il SIEM tramite l'indirizzo del mesh, mai tramite un indirizzo locale che non esiste per esso. Questo è un errore classico durante l'installazione di un agente.
  • Il nome del piano di controllo e il suffisso delle macchine devono essere due domini distinti. Un client gestisce la risoluzione del suffisso: un piano di controllo situato al di sotto diventerebbe inaccessibile da un nodo connesso. Il server, infatti, non avvia in questa configurazione.

Un filtraggio DNS (liste di blocco, riscritture interne) serve alla rete locale e raddoppia la risoluzione: lo stesso nome rende l'indirizzo interno accessibile all'interno, l'indirizzo pubblico all'esterno.

Un dispositivo nel sottorete annunciata

Attivare l'accettazione delle route su una macchina già situata nella sottorete che il mesh annuncia comporta la perdita di accesso alla rete. Il sintomo assomiglia a un guasto di Internet; la causa è una route appresa che sovrascrive la route locale.

4 · Contenuti: antivirus e analisi dei file

Un solo motore, per una ragione che non è l'economia

Il parco utilizza un singolo agente antivirus. Gli altri dispositivi non installano nessun binario, nessuna base di firme: inviano il contenuto su un canale dedicato (protocollo INSTREAM) e ricevono una valutazione.

Perché solo uno, e perché un mirror privato?

Il parco dispone di un singolo indirizzo IP pubblico. Diversi client di aggiornamento che interrogano la rete di distribuzione delle firme da questo indirizzo terminano con la limitazione della velocità, per poi essere bloccati.

Il sintomo non è un errore: è una base di firme che invecchia silenziosamente. Un antivirus con una base di firme di tre mesi funziona, risponde rapidamente e fornisce risposte errate.

Quindi, un solo processo del parco si connette a Internet per recuperare le firme, due volte al giorno, e le distribuisce a tutti gli altri tramite un mirror interno. Gli altri hanno l'accesso a Internet disabilitato tramite configurazione.

Il client registra, non il server

In INSTREAM, l'agente riceve solo un flusso di byte: il suo registro indica che una firma è stata trovata in "un flusso", senza percorso o macchina. L'unica entità che detiene le informazioni complete è il client. Pertanto, è lui che scrive nel registro di sistema, nel formato esatto richiesto dal decodificatore del SIEM.

Conseguenze per la protezione

Un motore centrale è un servizio di rete: vede solo ciò che gli viene inviato. Un host senza client non è "protetto" — è assente dal perimetro. La copertura viene quindi letta nella lista dei client e delle loro aree monitorate, mai nello stato dell'agente.

Rilevamento: quarantena, non eliminazione

Un file rilevato viene spostato in quarantena su un'area condivisa del NAS, con accesso limitato e conservazione. L'eliminazione è possibile, ma non è il problema, per due ragioni rilevate in questo ambiente:

  • Esistono falsi positivi reali che hanno già interessato file sani (un ebook, archivi di un'applicazione); l'eliminazione sarebbe stata inutile;
  • Alcune aree monitorate sono sincronizzate con altri dispositivi: rimuovere un file da questa area ne diffonderebbe la scomparsa ovunque. Questo è voluto per una vera minaccia, distruttiva per un falso positivo.

Analisi statica approfondita

Dove un antivirus emette un verdetto su un file, un secondo motore di analisi statica fa ciò che l'antivirus non fa: estrae ricorsivamente (archivio in archivio, documento, oggetto incorporato, macro, eseguibile) e passa decine di scanner su ogni oggetto estratto, inclusi un motore di regole YARA con migliaia di regole. Nessun codice viene eseguito: si tratta di un'analisi statica, non di un ambiente di prova.

Un insieme di regole che non caricano dice nulla

Il motore compila il suo insieme di regole in un unico blocco. Una singola regola invalida invalida tutto l'insieme. Il contenitore rimane quindi apparentemente in buone condizioni e non rileva più nulla — un guasto perfettamente silenzioso.

Un contatore delle regole caricate non è sufficiente per rilevarlo: indica quante regole sono in memoria, ma non se stanno ancora riconoscendo qualcosa. Il test è una regola canarino, posizionata tra le altre, la cui attivazione è richiesta ad ogni passaggio — è lei che distingue "nessun problema" da "nulla funziona". Vedi Rilevamento.

5 · Il desktop macOS

La macchina macOS viene trattata come un sistema del parco, non come un'eccezione.

Livello Ruolo
Agente SIEM Integrità dei file, controlli di configurazione, segnalazione al responsabile
Client antivirus Invio del contenuto delle aree a rischio al motore centrale, su programmazione
Firewall per processo Little Snitch — ogni binario richiede l'autorizzazione per uscire
Enumeratore di persistenza KnockKnock, collegato al motore antivirus del parco

KnockKnock collegato al motore centrale

KnockKnock elenca tutto ciò che viene eseguito autonomamente su un Mac: agenti e demoni di avvio, estensioni del kernel, moduli di autorizzazione, elementi di connessione, estensioni del browser, attività programmate. Si tratta della domanda "cosa viene eseguito senza che io lo chieda", che è esattamente la domanda che ci si pone dopo una compromissione.

Nella sua forma attuale, lo strumento interroga un servizio pubblico di reputazione tramite l'impronta del file. Il parco utilizza una versione derivata che invia il contenuto al motore antivirus interno invece:

  • nessun dato esce dalla rete locale, né impronta né contenuto;
  • non è necessaria alcuna chiave API, quindi non ci sono limitazioni di velocità;
  • il giudizio si basa sul contenuto reale del file, non su ciò che un terzo ha già visto.

Un firewall per processo rende le interruzioni silenziose

Su questa macchina, ogni nuovo strumento di rete è silenzioso finché non viene autorizzato, e l'errore assomiglia esattamente a un'interruzione di rete: la connessione rimane in attesa di una decisione visualizzata in una finestra — invisibile per un'attività programmata o una sessione remota.

Da ciò deriva una regola di progettazione: un'attività senza interfaccia deve passare attraverso un interprete già autorizzato, mai attraverso un binario appena installato. Un'applicazione interattiva, invece, può aprire la propria connessione: qualcuno è disponibile per rispondere alla finestra.

Accesso completo al disco

L'elenco completo dei punti di persistenza richiede l'autorizzazione "accesso completo al disco", concessa tramite un binario e solo manualmente, nelle impostazioni del sistema. Nessun comando può concederla da remoto: è una proprietà del sistema operativo, non una limitazione dello strumento.

Un audit parziale si segnala come tale

L'enumeratore percorre circa venti categorie in sequenza. Basta che una chiamata di sistema rimanga bloccata in attesa ininterrotta – uno stato in cui il processo non risponde più né a una richiesta di arresto né a un arresto forzato – affinché una singola categoria determini l'intero audit. Un'attività pianificata che "uccide e riavvia" quindi mette in pausa un processo ad ogni passaggio.

La regola adottata: una categoria che blocca viene esplicitamente esclusa, le altre continuano a funzionare, e l'elenco delle categorie non percorse viene inserito nel corpo della notifica. Un audit che non ha esaminato una parte non è un audit positivo – e "nessun problema rilevato" assomiglia esattamente a "non controllato".

6 · Rilevamento, correlazione, allarme

Il SIEM

Un manager SIEM/XDR raccoglie gli agenti di tutti gli host. Fornisce quattro cose che i log grezzi non forniscono:

  • Monitoraggio dell'integrità dei percorsi sensibili;
  • Verifiche di configurazione rispetto a standard di sicurezza;
  • Rilevamento di vulnerabilità tramite correlazione tra pacchetti installati e database CVE;
  • Correlazione e mappatura su una matrice di tecniche di attacco.

Una seconda catena raccoglie log e metriche verso un motore di ricerca distinto. Entrambe rispondono a domande diverse: una risponde "è un attacco noto?", l'altra "cosa è successo, minuto per minuto".

Oltre al SIEM

Il SIEM visualizza lo stato dei sistemi. Tre motori coprono ciò che non vede: Falco monitora le chiamate di sistema dei container durante l'esecuzione, Suricata applica firme al traffico di rete, e Velociraptor permette di interrogare l'intera flotta durante un incidente. I loro ruoli, le loro funzionalità e i loro limiti di progettazione sono descritti in Rilevamento e Risposta.

Il percorso per il rilevamento

sequenceDiagram
    autonumber
    participant Z as Zone surveillée
    participant C as Client de scan
    participant M as Moteur antivirus
    participant J as Journal système
    participant A as Agent SIEM
    participant S as Manager SIEM
    participant H as Répartiteur d'alertes
    participant D as Zulip + Telegram

    Z->>C: fichier nouveau ou modifié
    C->>M: contenu, en INSTREAM
    M-->>C: verdict + signature
    Note over C: le serveur ignore le chemin<br/>et la machine : c'est le client<br/>qui détient le contexte
    C->>Z: mise en quarantaine
    C->>J: ligne au format attendu par le décodeur
    A->>J: lecture
    A->>S: événement
    S->>S: règle → niveau de sévérité
    S->>H: intégration filtrée par identifiant de règle
    H->>D: un envoi, deux destinations

Due potenziali problemi in questa catena, entrambi silenziosi

Il filtro di integrazione. Mira a un identificatore di regola, mai a un gruppo. Un filtro per gruppo carica regole vicine e invia duplicati sullo stesso canale.

Il livello di gravità. Decide cosa viene segnalato. Un livello troppo alto fa inviare due volte da due percorsi diversi; un livello troppo basso disattiva la rilevazione. Questo viene verificato provocando intenzionalmente una rilevazione con un file di test innocuo, non rileggendo la configurazione.

La notifica

Tutte le notifiche convergono verso un unico dispositivo di distribuzione: un emettitore invia una volta, e il dispositivo di distribuzione replica verso le destinazioni. Quando una destinazione cambia, solo la mappa dei canali viene modificata — nessun emettitore deve essere aggiornato. Il dettaglio — e ciò che il sistema fa automaticamente quando una regola lo prevede — è in Risposta.

Una notifica ripetuta non dice più nulla

Ogni notifica ricorrente viene gestita con un intervallo e una durata. Una notifica che arriva ogni ora da tre settimane non è più una notifica: è un rumore che l'occhio filtra, e nasconde la vera notifica.

7 · Segreti

Dove Cosa Proprietà
Cassetta di sicurezza auto-ospitata Password, token, chiavi, note Fonte di verità, sbloccata da un servizio dedicato
File crittografati nel repository Variabili d'ambiente delle stack Crittografati a riposo, versionati, decrittabili al momento del deployment
Analisi prima del commit e prima dell'invio Diversi rilevatori di segreti impilati su ogni commit, poi l'intero storico in integrazione continua Blocca prima che il segreto entri nella cronologia
Scansione degli host Segreti ancora in chiaro sui dischi Gravità determinata dalle autorizzazioni del file

Tre regole che non possono essere negoziate:

  1. I file di ambiente non vengono letti né versionati in chiaro.
  2. Un segreto non passa mai attraverso un URL. Il log di errore di un motore di workflow registra l'URL risolta, inclusi i token — e questa informazione sopravvive alla rotazione del segreto.
  3. Un valore letto dalla cassetta di sicurezza passa attraverso un canale, mai attraverso la linea di comando: non attraversa la tabella dei processi, né la cronologia del shell, né la trascrizione di una sessione assistita.

Procedura: Consultare un segreto dal cofre.

8 · Catena di approvvigionamento

È la superficie più dinamica e quella su cui nessun firewall è in grado di proteggere.

Quarantena delle versioni. Nessuna versione pubblicata da meno di sette giorni è installata. Questa è l'unica difesa che avrebbe potuto bloccare la diffusione di pacchetti compromessi negli ultimi mesi: tutti sono stati rilevati e rimossi in poche ore o giorni. Il tempo trasforma una situazione critica in un semplice inconveniente.

La quarantena si applica in tre posizioni diverse

I tre gestori di pacchetti dell'ecosistema applicano questa regola, ma con tre unità e tre posizioni: una basata sul tempo, un'altra basata sui minuti, e la terza basata sui secondi; una applicata a livello di macchina, l'altra solo per repository.

Conseguenza pratica: un repository può non avere alcuna quarantena, e questo non viene segnalato. Pertanto, il file di configurazione che la definisce fa parte della struttura di un nuovo progetto, proprio come il file di esclusione delle versioni.

Immagini bloccate dall'impronta. Le immagini dei container sono bloccate dal loro "condensato", non da un'etichetta. Un'etichetta è un riferimento variabile: stable di oggi non è stable di domani, e questo non è indicato nel file di composizione.

Registro interno. Le immagini create in locale risiedono in un registro privato, e un "mirror" di registro assorbe le immagini pubbliche, eliminando così le dipendenze dirette verso un servizio di terze parti al momento dell'avvio.

Vulnerabilità note e inventario. Le immagini in esecuzione e i repository sono scansionati quotidianamente, e ogni scoperta viene classificata in base a tre criteri: gravità, utilizzo effettivo e esposizione, piuttosto che solo in base alla sua valutazione. Ogni immagine in esecuzione ha il suo SBOM. Dettagli: Rilevamento.

9 · Patch e esposizione hardware

Patch. Gli host seguono un ciclo di aggiornamenti non monitorato, esteso durante la notte con un ritardo casuale per host. I componenti la cui aggiornamento riavvia un servizio critico sono esclusi volontariamente e gestiti manualmente.

Un aggiornamento importante disattiva i repository di terze parti

Questo è successo in questo parco: un aggiornamento del sistema ha disattivato i repository di terze parti, lasciando i componenti interessati senza aggiornamenti di sicurezza per tre mesi – senza errori visibili. Dopo ogni aggiornamento importante, la presenza dei repository viene verificata esplicitamente.

Dischi. Lo stato SMART di tutti i dischi fisici è storicizzato e viene segnalato prima del guasto. Un punto di attenzione: gli indicatori dei produttori non parlano tutti la stessa lingua, e uno stato "fallito" potrebbe essere solo una mappa di corrispondenza mal interpretata. La sostituzione viene decisa in base a una tendenza, mai in base a un singolo rilevamento.

Backup. Ogni host invia un repository crittografato al NAS, con retention, verifica dell'integrità e ripristino tramite navigazione. La crittografia viene effettuata dal cliente, prima dell'invio: il server del repository non detiene le chiavi. Il repository rifiuta qualsiasi cancellazione proveniente dagli host, esistono copie al di fuori del sito, e un ripristino reale viene cronometrato regolarmente: vedere Continuità.

10 · I flussi, senza indirizzi

Da Vers Canale Oggetto
Client Internet Proxy di rete HTTPS Tutte le richieste pubbliche
Proxy di rete Proxy interno HTTPS Routing applicativo
Proxy interno Fornitore di identità HTTP interno Autenticazione
Proxy interno CrowdSec API locale Decisione di blocco
Client di scansione Motore antivirus TCP dedicato, IN STREAM Contenuto da analizzare
Processo di aggiornamento Distribuzione di firme HTTPS in uscita Solo uscita dalla rete per la catena antivirus
Agenti Manager SIEM Canale crittografato dell'agente Eventi, integrità, inventario
Agenti fuori dalla rete locale Manager SIEM Stesso, tramite il mesh Stesso
Manager SIEM Distribuitore di allarmi HTTP interno Allarmi filtrati in base all'identificatore della regola
Distribuitore Messaggistica di team HTTPS in uscita Notifiche, due destinazioni
Host Server di backup HTTPS interno Dati già crittografati
Host Cofano di segreti HTTPS interno Lettura di un segreto, tramite tubo
Rilevamento in esecuzione File locale, poi distribuitore Locale, poi HTTP interno Eventi di chiamate di sistema, notificati dopo la misurazione del rumore
Punto di convergenza del traffico IDS di rete Ascolto passivo Firme applicate durante il passaggio
Client di indagine Server di indagine Canale crittografato, tramite il mesh fuori dalla rete locale Richieste e risultati di indagine
Lanciatore di sonde Registro di prove API autenticata Verdetti datati
Registro di prove Due repository Git remoti HTTPS in uscita Ancoraggio giornaliero

Cosa non copre questa architettura

Un documento che elenca solo i suoi punti di forza è essenzialmente una brochure. I limiti strutturali — quelli relativi alle scelte architettoniche, non allo stato della luce — sono chiaramente definiti:

  • Il NAS è sia il confine WAN, lo spazio di archiviazione principale e il repository di backup. Si tratta di un singolo punto di guasto, e anche della macchina più esposta. Per questo motivo, il repository di backup rifiuta qualsiasi cancellazione proveniente dagli host, e per questo motivo esistono copie al di fuori del sito.
  • Un singolo indirizzo IP pubblico. L'intera catena di aggiornamento delle firme dipende da esso, e un blocco da parte del fornitore compromette la rilevazione senza errori visibili.
  • Nessun sandbox dinamico. L'analisi dei file è statica. Un binario che rivela il suo comportamento solo durante l'esecuzione supera entrambi i motori.
  • La protezione antivirus è una lista di zone, non una proprietà dell'host. Una cartella appena creata non è monitorata finché non viene aggiunta.
  • Il sistema macOS dipende dalle autorizzazioni concesse manualmente (accesso completo al disco, regole del firewall in uscita). Una reinstallazione le perde tutte, silenziosamente.
  • CrowdSec opera su HTTP. Un servizio esposto su un altro protocollo è coperto solo dal filtraggio di rete.

Da leggere successivamente

Dernière vérification de cette page : 2026-09-11