Centro fiduciario

Il dossier, prima della richiesta

Questa pagina anticipa le domande delle revisioni di sicurezza: come è costruita la piattaforma, chi tratta i dati, cosa è agli atti e cosa resta da documentare.

KLA attualmente non possiede la certificazione SOC 2 o ISO/IEC 27001. Consultate qui sotto i controlli documentati, i servizi esterni, le qualifiche di deployment e le evidenze disponibili.

01Architettura e flusso dei dati

Come è costruita la piattaforma

Ogni riga cita i controlli identificati che uno scanner nel cluster verifica di nuovo continuamente: la stessa checklist con cui sono valutate le nostre istantanee di postura.

Isolamento dei tenant: Un’unica piattaforma, confini rigidi. La sicurezza a livello di riga di PostgreSQL è applicata alle tabelle dei tenant e i ruoli di servizio non possono aggirarla; il registro delle evidenze e l’archiviazione degli oggetti sono partizionati per tenant; l’API rifiuta le letture tra tenant.
ISOL-001 · ISOL-002 · ISOL-003
Identità: Keycloak self-hosted, OIDC. Gli endpoint protetti rifiutano token mancanti, non validi ed emessi per un pubblico errato.
AUTH-001 · AUTH-002 · AUTH-003
Credenziali e chiavi: HashiCorp Vault conserva i segreti; i workload non includono credenziali cloud statiche. I dati dei tenant sono crittografati con chiavi di crittografia per tenant tramite Vault Transit, facoltativamente protette da un KMS cloud. Le chiavi di firma delle evidenze provengono da segreti gestiti.
KEYS-001: KEYS-005
Traffico tra servizi: TLS reciproco nell’intera service mesh Linkerd, con autorizzazioni server circoscritte per i servizi interni critici e un obiettivo di copertura della mesh ≥95%, dove ogni eccezione ha durata limitata. TLS 1.3 è applicato all’ingresso.
MTLS-001: MTLS-005 · K8S-006
Valutazione delle policy: Fail-closed. Un checkpoint che non può essere valutato trattiene o blocca l’azione: senza una risposta non si procede.
Audit e telemetria: Le decisioni governate sono emesse come tracce OpenTelemetry e sigillate in un registro delle evidenze per tenant, resistente alle manomissioni (immudb). L’attività del database viene sottoposta ad audit con pgAudit.
OTEL · PGAUDIT
Gestione delle modifiche: GitOps è la fonte di verità: lo stato del cluster è dichiarato nel controllo di versione e sincronizzato da Argo CD, senza derive manuali. I controlli di sicurezza vengono eseguiti in CI e un verificatore di runtime ricontrolla il cluster attivo.
ARGO CD · CI
Catena di fornitura: Le immagini dei container sono firmate con Cosign e fissate tramite digest immutabile.
K8S-005 · COSIGN
Rafforzamento dei workload: Nessun service account predefinito, nessun binding cluster-admin, contesti di sicurezza dei container rafforzati, limiti di risorse per ogni container e nessuna rete host.
K8S-001: K8S-004 · MTLS-004
Postura continua: Uno scanner nel cluster riproduce una checklist fissa e versionata di questi controlli. Le istantanee conservano nomi, metadati e hash, mai valori sensibili.

02Divulgazione dei servizi esterni

Percorsi in uscita nella distribuzione esaminata

Queste righe registrano i percorsi in uscita rilevati nel codice sorgente e in GitOps di sviluppo. Prima di emettere un elenco firmato dei sub-responsabili per la produzione servono l’approvazione del consulente legale e del fondatore. L’operatore di produzione registra fornitore, regione e scelte sui flussi di dati per la propria distribuzione.

Servizio	Finalità	Ambito
Microsoft Azure	Hosting AKS di sviluppo e integrazione con Azure Key Vault. Le attuali evidenze delle etichette dei nodi di sviluppo registrano la regione westeurope.	Infrastruttura di sviluppo
OpenAI	AgentKit usa per impostazione predefinita un provider compatibile con OpenAI e le distribuzioni di esecuzione e valutazione di sviluppo accettano una credenziale OpenAI facoltativa. Quando è abilitato, l’endpoint del modello configurato riceve input e output dell’agente o della valutazione.	Esecuzione e valutazione di agenti in sviluppo
Azure OpenAI	AgentKit e Policy Builder supportano Azure OpenAI quando sono configurati endpoint e credenziali. L’endpoint del modello configurato riceve i prompt dell’agente e gli output del modello.	Provider di modelli configurabile
Anthropic	KLA Analyst e Policy Builder supportano credenziali e percorsi di richiesta Anthropic. Quando è abilitato, l’endpoint Anthropic riceve i relativi prompt e output del modello.	Provider di modelli configurabile
Amazon Bedrock	Policy Builder supporta Amazon Bedrock come provider di modelli configurato. L’endpoint Bedrock selezionato riceve input e output del modello quando un tenant lo abilita.	Provider di modelli configurabile
Google Analytics 4	Misurazione del traffico. Funziona in modalità consenso Google con tutta l’archiviazione negata per impostazione predefinita.	Sito pubblico e console autenticata
Microsoft Clarity	Diagnostica delle sessioni. Si sincronizza con il segnale di consenso ai cookie; l’archiviazione pubblicitaria è sempre negata.	Sito pubblico
Apollo.io	Identificazione dei visitatori aziendali per il follow-up commerciale.	Sito pubblico dopo il consenso al marketing
Calendly	Incorporamento per programmare piloti e demo.	/book-demo
Resend	Consegna SMTP dei messaggi dei lead di marketing.	Raccolta di lead di sviluppo
ntfy.sh	Consegna push per notifiche dei lead di marketing e delle distribuzioni Argo CD.	Notifiche di sviluppo
PagerDuty	Instradamento degli avvisi per gli avvisi critici Argo CD di sviluppo e i relativi metadati.	Operazioni di sviluppo

Plausible Analytics è utilizzato con la distribuzione di sviluppo: lo script del browser e l’endpoint degli eventi puntano a plausible.dev.kla.digital e i manifest del servizio sono mantenuti in questo repository. È un’infrastruttura gestita dalla distribuzione nell’ambito di questa divulgazione tecnica.

03Divulgazione delle vulnerabilità

Come segnalare una vulnerabilità

Una politica semplice, esposta con chiarezza. Preferiamo ricevere la segnalazione direttamente da voi.

Dove segnalare: E-mail [email protected] con i passaggi per riprodurre il problema e la valutazione dell’impatto.
Conferma di ricezione: Confermiamo la ricezione delle segnalazioni entro cinque giorni lavorativi e vi teniamo aggiornati mentre effettuiamo il triage e risolviamo il problema.
Divulgazione coordinata: Coordiniamo con chi segnala i tempi di qualsiasi divulgazione pubblica e riconosciamo chi svolge ricerche in buona fede, se lo desidera.
Porto sicuro: Non intraprenderemo azioni legali per ricerche di sicurezza in buona fede e non distruttive che rispettino i dati dei tenant e la disponibilità del servizio.

04Certificazioni e audit

La linea franca

Una pagina fiduciaria di un’azienda il cui prodotto sono le evidenze non può permettersi una sola dichiarazione implicita. Perciò, con chiarezza:

Certificazioni possedute oggi: Nessuna. Non possediamo certificazioni SOC 2 o ISO/IEC 27001 e nulla in questa pagina deve essere interpretato come se le possedessimo.
Ciò che esiste invece: Un modello di controlli documentato e versionato: sottoposto a scansione continua nel cluster e mappato al linguaggio dei controlli interni e dei framework. Vedi la mappatura dei controlli.
Valutazione indipendente: Pianificata. Pubblicheremo l’incarico in questa pagina quando sarà programmato; non è ancora registrata alcuna data.
Partecipazione agli standard: KLA è membro della CN IA di AFNOR: la commissione francese di standardizzazione dell’IA, comitato specchio di ISO/IEC SC 42 e CEN-CENELEC JTC 21. Si tratta di partecipazione alla definizione degli standard.

05Documenti disponibili su richiesta

La documentazione, su richiesta

Ciò che potete inserire oggi in un dossier di procurement.

White paper sulla sicurezza

Architettura, note di implementazione dei controlli ed evidenze del repository per una revisione tecnica della sicurezza. Lo stato di pianificazione SOC 2 è indicato nel documento.

Mappatura dei controlli
Controlli di runtime, approvazioni umane e lineage di esecuzione mappati al linguaggio dei controlli interni e dei framework.
Vedi pagina →
Accordo sul trattamento dei dati
Una bozza è in revisione presso il consulente legale e il fondatore. Richiedete la versione approvata per il vostro dossier di procurement.
Richiedi →
Esempio di lineage di esecuzione
Un esempio di record di lineage di esecuzione sigillato prodotto da un pilota governato.
Richiedi →

06Risposte preliminari alla revisione

Cosa chiedono di solito le revisioni

Le domande a cui possiamo rispondere prima che arrivi il questionario. Ciò che non è elencato qui non è ancora agli atti: chiedetecelo e ve lo diremo.

Crittografia in transito: TLS 1.3 all’ingresso; TLS reciproco tra servizi nell’intera mesh Linkerd.
Crittografia a riposo: Chiavi di crittografia per tenant tramite Vault Transit, facoltativamente protette da un KMS cloud. Le chiavi di firma delle evidenze provengono da segreti gestiti.
Modello di tenancy: Multi-tenant con isolamento applicato a tre livelli: sicurezza a livello di riga di PostgreSQL obbligatoria e non aggirabile dai ruoli di servizio, partizioni per tenant nel registro delle evidenze e nell’archiviazione degli oggetti, e rifiuto delle letture tra tenant a livello di API.
Identità e accesso: OIDC tramite Keycloak self-hosted; gli endpoint rifiutano token mancanti, non validi e con pubblico errato. Nel cluster: service account con privilegi minimi, nessun binding cluster-admin e contesti di sicurezza rafforzati.
Gestione dei segreti: HashiCorp Vault. Nessuna credenziale cloud statica negli ambienti dei workload; i segreti Kubernetes vengono sincronizzati da Vault tramite ExternalSecrets.
Registrazione e audit: Tracce OpenTelemetry per ogni decisione governata; archiviazione delle evidenze per tenant resistente alle manomissioni; pgAudit sul database. Le istantanee di postura conservano nomi, metadati e hash, mai valori sensibili.
Gestione delle modifiche: Solo GitOps. Lo stato del cluster è dichiarato nel controllo di versione e sincronizzato da Argo CD; i controlli di sicurezza vengono eseguiti in CI e un verificatore di runtime ricontrolla il cluster attivo.
Catena di fornitura: Immagini dei container firmate con Cosign e fissate tramite digest immutabile.
Backup: La configurazione dei backup di sviluppo per PostgreSQL, Redis, immudb, ClickHouse, Vault e i job del database Plausible punta all’endpoint MinIO nel cluster, in minio.kla-infra.svc.cluster.local:9000, e al bucket backups. Il Service MinIO osservato è ClusterIP. Un operatore di produzione seleziona la destinazione dei backup di produzione.
Residenza dei dati: Le evidenze di sviluppo registrano etichette dei nodi AKS in westeurope e destinazioni di backup nel cluster di sviluppo. Queste evidenze descrivono solo lo sviluppo. Un operatore di produzione registra residenza, posizione dei backup e impostazioni di trasferimento verso terzi nel DPA eseguito.
Test di penetrazione: Non è ancora agli atti alcun rapporto di test di penetrazione di terze parti. La scansione automatizzata della postura viene eseguita continuamente rispetto a una checklist di controlli versionata; è pianificata una valutazione indipendente.
Certificazioni: Nessuna posseduta oggi: consultate la linea franca sopra. Il modello di controlli e la relativa mappatura ai framework sono documentati e possono essere esaminati ora.
Divulgazione dei servizi esterni: Le righe sopra registrano i percorsi in uscita rilevati nel codice sorgente e in GitOps di sviluppo. Prima di emettere un elenco firmato dei sub-responsabili per la produzione servono l’approvazione del consulente legale e del fondatore.
Segnalazioni di vulnerabilità: [email protected]: la conferma di ricezione, la divulgazione coordinata e le condizioni di porto sicuro sono pubblicate sopra.

Leggete il dossier e mettetelo alla prova

La revisione di sicurezza più rapida è quella eseguita sul vostro Process.

Contattateci

4 settimane · il vostro Process · evidenze firmate che conservate

Richiedi una revisione di sicurezza