Corvidint
Richiedi un briefing

Il suo ambiente, le sue chiavi, le sue evidenze.

Eseguire Corvidint su Kubernetes o Docker Compose nel proprio ambiente, con single sign-on, ruoli per workspace, un audit trail completo e le credenziali nel proprio vault.

Richiedi un briefing
Schermata di accesso: continuare con il single sign-on tramite il proprio identity provider, oppure usare nome utente e password, sotto un avviso che ogni azione viene sottoposta ad audit.

Schermata del prodotto con dati fittizi

Distribuito nel suo ambiente, non nel nostro.

Corvidint si installa su Kubernetes o Docker Compose e si collega all’identity provider, al vault, allo storage e ai modelli che già utilizza.

  1. Il perimetro è suo

    Installazione con manifest Kubernetes, un chart Helm o Docker Compose, su un’infrastruttura sotto il suo controllo.

  2. I suoi servizi, per riferimento

    Basta puntarlo al proprio identity provider, vault dei segreti, database, object storage e model server. Le credenziali restano dove sono.

  3. Un’unica uscita governata

    Il traffico in uscita è negato per impostazione predefinita. La raccolta raggiunge le fonti solo attraverso i profili di egress che un workspace consente.

Il suo ambienteKubernetes o Docker Compose

OIDCIdentity providerSingle sign-on per ogni persona
Per riferimentoVault dei segretiCredenziali delle fonti, egress e chiavi dei modelli
API RESTI suoi strumentiAlert via webhook, ogni azione via API
Corvidint
  • Raccolta
  • Evidenze
  • Analisi
  • Ricerca
  • Alert
Gestito in autonomiaStorageRecord, catture sigillate, indice di ricerca
LocaleModel serverOppure self-hosted, o un provider a sua scelta

Traffico in uscita negato per impostazione predefinita

Profili di egressScelti per fonte

  • Tor
  • VPN
  • Proxy
Fonti autorizzateForum, community chiuse, servizi onion e leak site
Diagramma: Corvidint gira all’interno del suo ambiente, collegato ai suoi servizi, e raggiunge le fonti autorizzate solo attraverso un egress approvato.

Accesso deciso dal ruolo, per workspace.

Le persone accedono tramite il suo identity provider. Ogni workspace isola le proprie fonti, i propri alert e le proprie evidenze, e ogni membro vi ricopre un solo ruolo.

  1. I workspace tengono separati i team

    Ogni richiesta porta con sé il proprio workspace. L’API rifiuta i dati di qualsiasi altro, così team e clienti non vedono mai le evidenze altrui.

    Schermata Workspace: il workspace del settore finanziario UE, la cui sezione identità spiega che l’API rifiuta i dati di qualsiasi altro workspace.

  2. I membri provengono dal suo provider

    Aggiungere una persona tramite il subject emesso dall’identity provider, scegliere un ruolo e indicare un motivo. La modifica viene registrata con il suo nome.

    Finestra Aggiungi membro: il subject emesso dall’identity provider, un ruolo e un motivo obbligatorio registrato nell’audit trail.

  3. Quattro ruoli, nulla di implicito

    I lettori leggono. Gli analisti fanno triage, ricerche ed esportazioni entro la policy. Gli operatori gestiscono la raccolta. Gli amministratori modificano policy e membri.

    Menu delle azioni sul membro: cambiare il ruolo in lettore, analista, operatore o amministratore, ciascuno con ciò che consente.

  4. Ogni modifica riporta un motivo

    Cambiare un ruolo o rimuovere un membro richiede un motivo e finisce nell’audit trail. Le azioni passate restano attribuite.

    Conferma del cambio di ruolo di un membro, da lettore ad analista, con un motivo obbligatorio registrato nell’audit trail.
Schermata Workspace: il workspace del settore finanziario UE, la cui sezione identità spiega che l’API rifiuta i dati di qualsiasi altro workspace.

Schermata del prodotto con dati fittizi

Schermata Workspace: il workspace del settore finanziario UE, la cui sezione identità spiega che l’API rifiuta i dati di qualsiasi altro workspace.

Schermata del prodotto con dati fittizi

Un accesso che fallisce in sicurezza

Schermata di accesso con l’avviso che l’identity provider non ha risposto e la password non è stata verificata.
Provider che non rispondeQuando il suo identity provider non risponde, l’accesso si ferma e ne spiega il motivo. La password non viene verificata altrove.
Schermata di accesso con l’avviso di troppi tentativi di accesso e l’attesa prima del successivo.
Troppi tentativiGli errori ripetuti impongono all’account un’attesa prima del tentativo successivo, e il modulo mostra quanto dura.
Azioni ad alto impatto
Eliminare evidenze, cambiare la conservazione o ritirare una fonte richiede una conferma esplicita e un accesso multifattore, se il suo provider lo segnala.
Sessioni mantenute
«Resta connesso» salva sessione e nome utente in quel browser, mai la password.

Schermata del prodotto con dati fittizi

Schermata della policy del workspace: fonti consentite, esportazioni e classificazione, conservazione per classe di dati con legal hold, interazione e analisi con IA, accesso alle evidenze, base giuridica e finalità.
Conferma di salvataggio della policy del workspace: conservazione delle pagine grezze ridotta da 90 a 60 giorni, un avviso che le pagine grezze più vecchie verranno eliminate e il motivo della modifica.

Schermata del prodotto con dati fittizi

Conservazione e legal hold, stabiliti da lei.

Ogni workspace ha una propria policy: fonti, esportazioni, conservazione e ciò che l’IA può fare. L’API la applica e ogni modifica è sottoposta ad audit.

  1. Solo le fonti che consente

    Crawl, ricerche e alert di un workspace usano solo le fonti elencate nella sua policy.

  2. Esportazioni alle sue condizioni

    Consentire le esportazioni, bloccarle tutte durante una verifica legale e contrassegnare l’output condiviso con una classificazione Traffic Light Protocol.

  3. Un limite per ogni tipo di dato

    Post, catture, pagine grezze, allegati e log di audit hanno ciascuno il proprio limite. Il legal hold sospende ogni eliminazione.

  4. Sola lettura, con IA etichettata

    L’interazione con le fonti resta disattivata, salvo sua autorizzazione. L’output dell’IA è sempre contrassegnato come derivato, mai come evidenza.

  5. Chi apre le evidenze

    Scegliere chi può aprire catture e pagine grezze e registrare accanto a esse base giuridica e finalità.

  6. Mostrato prima di eliminare qualsiasi cosa

    Il salvataggio richiede un motivo e mostra la differenza. Un limite più breve avvisa di cosa eliminerà la pulizia di stanotte.

La policy del workspace su telefono: fonti, esportazioni, conservazione per classe di dati, legal hold, analisi con IA e accesso alle evidenze.
Conferma di salvataggio della policy del workspace: conservazione delle pagine grezze ridotta da 90 a 60 giorni, un avviso che le pagine grezze più vecchie verranno eliminate e il motivo della modifica.

Schermata del prodotto con dati fittizi

I segreti restano nel suo vault.

Credenziali delle fonti, credenziali di egress e chiavi dei modelli vivono nel suo vault dei segreti. Corvidint conserva un riferimento a ciascuno, mai il valore.

Anatomia di un riferimento a un segreto
Solo percorso, versione e presenza

workspacesws_eu_finWorkspacesourcesbasaltFonteloginCredenziale

Versione
3Ruotato nel vault
Riferimento
Risolve
Valore
Mai inviato al browser

Dove un segreto non compare mai

Rotazione
Si ruota un valore nel vault e la console mostra una nuova versione, senza rivelare nessuno dei due valori.
Ritiro
Ritirare una fonte revoca i segreti che utilizzava.
  • File di configurazioneLe impostazioni contengono il percorso nel vault, mai il valore.
  • Log e metricheL’oscuramento tiene i valori fuori dai log, e i nomi e le etichette delle metriche non li riportano mai.
  • Backup dei datiI backup contengono solo percorsi di riferimento, mai materiale segreto.
  • Il browserLa console vede percorso, versione e presenza. Il materiale archiviato non le viene mai inviato.
  • L’audit trailGli eventi registrano cosa è stato fatto e da chi, mai il segreto stesso.

Un ripristino che si prova, non si presume.

Un backup mai ripristinato non è affidabile. I test di ripristino vengono eseguiti a intervalli programmati e dimostrano ciascuno dei passaggi seguenti.

Test di ripristinoA intervalli programmati, fuori dalla produzione

  1. Ripristinare i record

    Il sistema di riferimento torna per primo, dall’ultimo backup o da un punto nel tempo.

  2. Verificare le evidenze

    Ogni cattura viene confrontata con la sua impronta SHA-256 prima di essere considerata valida.

  3. Ricostruire la ricerca

    La ricerca viene ricostruita dai record. Non viene mai ripristinata da un dump.

  4. Riprendere dai checkpoint

    Ogni fonte riparte dall’ultimo checkpoint durevole, non dall’inizio.

  5. Escludere i duplicati

    I post elaborati di nuovo vengono associati a quelli esistenti, mai contati due volte.

  6. Tracciare la lineage

    Ogni post è di nuovo collegato alla sua cattura e all’esecuzione che lo ha raccolto.

Test programmati
I test vengono eseguiti a intervalli programmati, fuori dalla produzione. Avviarne uno a mano richiede una conferma.
Obiettivi per servizio
Gli obiettivi di punto e di tempo di ripristino sono definiti per ogni servizio che gestisce.
Guasti simulati
Perdita dei worker, riavvii del database e guasti di rete vengono simulati, e checkpoint, evidenze e ricerca devono restare coerenti.

Threat intelligence self-hosted, dove restano le evidenze.

Le risposte brevi alle domande che una revisione di sicurezza pone per prime.

Scheda di sicurezzaDeployment self-hosted
Deployment
Kubernetes o Docker Compose, nel suo ambiente
Identità
Single sign-on via OIDC con il suo provider
Ruoli
Lettore, analista, operatore e amministratore, per workspace
Isolamento
Workspace imposti dall’API a ogni richiesta
Azioni ad alto impatto
Conferma esplicita prima dell’esecuzione
Audit
Ogni decisione registrata e attribuibile, rifiuti inclusi
Conservazione
Un limite per classe di dati, con legal hold
Ripristino
Backup e test di ripristino programmati
Segreti
Nel suo vault, referenziati per percorso
Rete
Traffico in uscita negato per impostazione predefinita, egress per fonte
Modelli di IA
Locali, self-hosted o di un provider a sua scelta
Evidenze
Catture sigillate con un’impronta SHA-256
Integrazione
API REST versionata e webhook

Autorizzato e di sola osservazione.

Corvidint monitora solo fonti a cui la sua organizzazione è autorizzata ad accedere. Non aggira mai i controlli di accesso, non compromette account e non sfrutta vulnerabilità dei siti.

I dati trapelati non vengono mai scaricati e l’output dell’IA non è mai trattato come evidenza.

Leggi la policy di uso responsabile

Lo metta alla prova sulle sue fonti.

Ci dica di cosa ha bisogno. Le mostreremo una cattura dal vivo, dal post al record sigillato.

Richiedi un briefing

Preferisce l’email? Scriva a [email protected].