Come proteggiamo
Itamite dall'interno.
Non basta che i framework dicano che sei conforme. Spieghiamo qui cosa facciamo in architettura, crittografia, operatività, hardening, supply chain e risposta agli incidenti perché Itamite sia genuinamente sicuro. Niente marketing, ma dettagli concreti e verificabili.
Filosofia di sicurezza
Itamite gestisce inventari sensibili e permette il controllo remoto su endpoint di organizzazioni critiche: ospedali, pubbliche amministrazioni, banche, fintech, studi commercialisti. Una violazione in Itamite non è un nostro incidente; è un incidente per tutti i clienti contemporaneamente. Per questo operiamo secondo il principio "secure by design, secure by default, secure by operation": il design impedisce intere categorie di guasti, i default sono quelli sicuri e l'operatività è auditata in continuo.
L'audit immutabile hash-chain che Itamite offre ai propri clienti, lo applichiamo anche alla nostra operatività interna: ogni accesso di un tecnico Itrion in produzione viene registrato con SHA-256 verificabile. Ogni modifica alla configurazione di un tenant ha timestamp crittografico. Zero eccezioni per gli amministratori. Se Itrion fosse hackerata domani, i log sarebbero dimostrabilmente inalterabili.
Pubblichiamo questa pagina deliberatamente verbosa perché crediamo che la trasparenza sia parte della sicurezza. Se diciamo solo "we take security seriously" senza dettagli, non puoi verificare nulla. Per questo spieghiamo architettura, decisioni crittografiche, operatività, hardening del cluster, supply chain, programma di pentesting e processo di risposta agli incidenti con dati concreti.
Come è costruita la sicurezza di Itamite
Isolamento multi-tenant rigoroso
Ogni tenant ha database logico separato con tenant_id in tutte le tabelle e RLS (Row Level Security) in PostgreSQL. Cluster Kubernetes con NetworkPolicies che segmentano il traffico per namespace. Per Enterprise: opzione single-tenant con cluster Kubernetes dedicato e BYOK.
Cifratura at-rest e in-transit
TLS 1.3 obbligatorio in tutte le comunicazioni (agente-server, client-server, server-DB). Cifratura AES-256-GCM at-rest per PostgreSQL e MinIO/S3. Per dati altamente sensibili (audit log): cifratura a livello applicativo con chiave per tenant. BYOK opzionale Enterprise.
Sessioni remote E2E
Diffie-Hellman effimero per ogni sessione di controllo remoto. Nemmeno Itrion può leggere il contenuto di schermo, audio o tastiera durante una sessione. Solo i metadati (chi ha avuto accesso, quando, durata) restano nei log. Registrazione opzionale con SHA-256 firmato memorizzata nel MinIO/S3 del cliente.
Audit immutabile hash-chain
Ogni evento (accesso, modifica config, sessione remota, inventario, comando eseguito) viene registrato in log con SHA-256 che include l'hash del log precedente. Qualsiasi modifica retroattiva rompe la catena ed è rilevabile. Inalterabile anche dai DBA di Itrion.
Hardening del cluster Kubernetes
CIS Kubernetes Benchmark v1.8 applicato integralmente. Pod Security Standards "restricted". NetworkPolicies per namespace. Service Mesh (Istio) con mTLS automatico. Secret cifrati con sealed-secrets + external-secrets da HashiCorp Vault. Ingress con WAF (ModSecurity + OWASP CRS).
Sicurezza della supply chain
SBOM pubblicato per ogni release (formato SPDX + CycloneDX). Immagini Docker firmate con cosign + sigstore. Provenance attestation SLSA Level 3. Renovate bot per il rilevamento di dipendenze vulnerabili. CI/CD che rifiuta il merge se ci sono CVE critiche non patchate.
Operatività e risposta
Programma di pentesting annuale con BDO Madrid: tre settimane di test, report dettagliato, remediation obbligatoria pre-pubblicazione. Bug bounty pubblico da Q3 2026. SOC interno con rilevamento 24x7 (Wazuh + Grafana + alert al team di reperibilità rotativa). RTO <4h, RPO <15 min per Enterprise. Backup cifrati off-site con replica MinIO verso tre datacenter UE diversi. Processo di risposta agli incidenti: rilevamento automatico + analisi di severity + escalation al CISO di Itrion + comunicazione ai clienti coinvolti in <2h per gli incidenti confermati + post-mortem pubblico 7 giorni dopo con root cause e misure preventive. Politica trasparente: comunichiamo gli incidenti anche quando non saremmo legalmente obbligati.
- Pentesting annuale: BDO Madrid (società indipendente)
- SOC interno 24x7: reperibilità rotativa permanente
- RTO <4h, RPO <15 min: per i clienti Enterprise
- Backup cifrati: replicati in 3 datacenter UE
- Politica trasparente: comunicazione degli incidenti in <2h
Domande sulla sicurezza della piattaforma
Posso richiedere l'ultimo report di pentesting?
Cosa succede se Itrion viene hackerata?
BYOK è disponibile?
Siete conformi ISO 27001?
Più dettagli sotto NDA
Se hai bisogno del report di pentesting completo, dell'architettura tecnica dettagliata o di una due diligence di sicurezza: contattaci.