Sicurezza dei dati su Archyl Cloud: cosa proteggiamo, come, e cosa non dichiariamo

Da qualche parte nel tuo questionario per i fornitori c'è una riga che dice "I dati dei clienti sono cifrati a riposo? Sì / No". Per Archyl Cloud, la risposta corretta è "sì, ed ecco esattamente quali campi". Il testo della tua architettura (nomi, descrizioni, ADR, documentazione) e le tue credenziali vengono cifrati dalla nostra applicazione prima ancora che il database li veda. I file caricati vengono cifrati dal provider di storage. Identificatori, timestamp, posizioni nei diagrammi ed email degli account restano in chiaro, perché il database deve indicizzarli e metterli in join. Un fornitore che spunta "Sì" senza dire cosa è cosa ti sta chiedendo di prendere il resto del questionario sulla fiducia.

Questo articolo è la risposta lunga. Spiega cosa cifriamo e come, come si spostano i dati, chi può accedere a cosa, cosa riceve il nostro provider di AI, come facciamo i test e cosa puoi fare in base al GDPR. Dice anche chiaramente dove non siamo ancora arrivati: oggi Archyl non possiede alcuna certificazione di sicurezza.

Tutto ciò che trovi qui è coerente con il Security Whitepaper (v3.0) e con il Data Processing Agreement (DPA), entrambi aggiornati il 27 settembre 2026 ed entrambi linkati dal Centro Fiducia. Se una frase qui e una frase lì dovessero mai non coincidere, diccelo, perché una delle due è sbagliata.

La versione breve

Per chi sta compilando un modulo proprio adesso:

Domanda Risposta
Chi gestisce Archyl Cloud? EKO Consulting, una società registrata in Francia.
Quali dati sono cifrati a riposo dall'applicazione? Il contenuto architetturale (il testo del tuo modello C4, ADR, documentazione, contratti API, flow e altro) e tutte le credenziali e i secret, con AES-256-GCM. L'elenco completo è più sotto.
Cosa resta in chiaro? Identificatori e collegamenti tra elementi, timestamp, posizioni nei diagrammi, email e nomi degli account.
File caricati? Google Cloud Storage, bucket privati, AES-256 a riposo (gestito dal provider), regione UE (Belgio) per impostazione predefinita.
In transito? TLS 1.3. La connessione al database richiede SSL.
SSO e MFA? Single sign-on SAML 2.0 e OIDC, autenticazione a più fattori TOTP.
Isolamento dei tenant? Ogni richiesta viene autorizzata rispetto alla risorsa che tocca. I controlli falliscono in modo chiuso (fail closed) e sono testati in CI.
Provider di AI? OpenAI. La scoperta invia firme del codice, non il sorgente completo. Puoi usare la tua chiave oppure fare self-hosting con Ollama.
Certificazioni? Nessuna per ora. SOC 2 Type I: readiness assessment completato, audit indipendente in attesa. ISO 27001: pianificata.
Penetration test? Dieci round interni, da luglio a settembre 2026. Un test indipendente è pianificato insieme all'audit SOC 2.
Notifica delle violazioni? Entro 72 ore.
Contatti? Vulnerabilità: security@archyl.com, con conferma di ricezione entro 24 ore. Protezione dei dati e questionari: privacy@archyl.com.

Il resto dell'articolo è il dettaglio dietro ogni riga.

Cifratura a riposo, campo per campo

Archyl cifra i campi nell'applicazione, prima che vengano scritti nel database. Ogni modello che contiene contenuti dei clienti ha un hook di salvataggio che cifra i suoi campi di testo con AES-256-GCM in ingresso, e un hook corrispondente che li decifra in uscita. Ogni cifratura usa un nonce casuale nuovo, quindi lo stesso valore memorizzato due volte produce due ciphertext diversi.

Questo copre il tuo contenuto architetturale, non solo i tuoi secret:

  • Modello C4: system, container, component ed elementi di codice (nome, descrizione, tag); relazioni (descrizione, tag)
  • Architecture Decision Records: titolo, contesto, decisione, conseguenze, tag
  • Documentazione: titolo, contenuto, percorso del file, tag; i relativi commenti
  • Contratti API: nome, descrizione, contenuto, endpoint, versione
  • Flow e whiteboard: nomi, descrizioni, etichette tecnologiche
  • Inoltre: overlay, canali di eventi, insight, release, regole di conformità, cronologia delle modifiche e snapshot

E ogni credenziale e secret che Archyl memorizza:

  • Token OAuth di GitHub, GitLab e Bitbucket
  • Chiavi API
  • Secret MFA e codici di recupero
  • Credenziali delle integrazioni e del marketplace
  • Token di accesso ai repository
  • Impostazioni delle connessioni cloud

È sempre attivo. La chiave di cifratura è derivata con Argon2id da un secret configurato, e il server si arresta all'avvio se quel secret manca o è più corto di 32 caratteri. Non esiste alcuna configurazione in cui Archyl giri e scriva questi campi in chiaro.

La conseguenza pratica: una copia del database, da sola, mostra la forma dei tuoi dati ma non le loro parole. I nomi dei tuoi servizi, il ragionamento nei tuoi ADR, il corpo dei tuoi documenti, il tuo token GitHub e il tuo secret MFA richiedono tutti anche la chiave.

Inoltre le credenziali non escono mai più dall'API. Le impostazioni delle integrazioni vengono oscurate a ogni lettura: una volta incollata una chiave in Archyl, l'interfaccia può dirti che una chiave è memorizzata, ma non può mostrartela di nuovo, e nessuna chiamata API la restituisce a nessun altro nella tua organizzazione.

Cosa non copre

Un database deve poter trovare, ordinare e mettere in join le righe, e non può farlo sul testo cifrato. Per questo alcuni campi restano in chiaro:

  • Gli identificatori e i collegamenti tra elementi. Il database sa che l'elemento A appartiene al container B e ha una relazione con l'elemento C. Non sa come si chiami nessuno di loro.
  • Timestamp e posizioni nei diagrammi.
  • Indirizzi email, nomi e cognomi degli account. L'email ha un indice univoco, così due account non possono rivendicare lo stesso indirizzo.

Questi campi sono protetti dai controlli di accesso descritti più avanti e da TLS in transito. Questo articolo non afferma nulla, né in un senso né nell'altro, sulla cifratura a livello di disco del database.

File caricati

I file che alleghi alla documentazione (immagini, PDF, altri documenti) non risiedono nel database. Sono memorizzati in Google Cloud Storage, e:

  • I bucket sono privati. Nulla al loro interno è leggibile o elencabile pubblicamente.
  • I file sono cifrati a riposo con AES-256 da Google Cloud Storage, con chiavi gestite dal provider.
  • I file vengono serviti solo tramite URL firmati a breve scadenza. Ogni link dà accesso a un solo file e scade poco dopo essere stato generato, così un link copiato in un ticket o in una chat smette di funzionare invece di diventare un URL pubblico permanente.
  • La regione predefinita è l'UE: Belgio, europe-west1.

Cifratura in transito

Il traffico tra il tuo browser, i tuoi strumenti e Archyl Cloud usa TLS 1.3. La connessione dell'applicazione al suo database PostgreSQL richiede SSL, quindi l'applicazione non comunica con il database in chiaro.

Chi può entrare

Persone

  • L'autenticazione a più fattori usa TOTP, i codici a sei cifre di un'app di autenticazione. Ogni challenge MFA può essere usata una sola volta, e i codici di recupero sono memorizzati come hash bcrypt, quindi possono essere verificati ma non riletti.
  • Il single sign-on supporta SAML 2.0 e OpenID Connect. L'accesso parte sempre da Archyl (solo SP-initiated), e lo state che collega la risposta del tuo identity provider a quella richiesta è legato al browser che l'ha avviata ed è valido una sola volta. Il nostro articolo sull'SSO descrive la configurazione.
  • L'accesso OAuth è disponibile con GitHub, GitLab e Bitbucket.
  • Cambiare la password o rimuovere l'MFA revoca tutte le sessioni precedenti. Se pensi che una password sia trapelata, cambiarla disconnette ogni altro dispositivo che la stava usando.
  • Il reset della password non rivela se un account esiste, e un link di reset smette di funzionare una volta usato.
  • Login, MFA e reset della password hanno un rate limit, con limiti a più livelli in modo che un singolo IP, un singolo account o una singola challenge possano essere tentati solo un numero limitato di volte.

Macchine: chiavi API e agenti AI

  • Le chiavi API sono di sola lettura per impostazione predefinita. L'accesso in scrittura deve essere concesso, e una chiave può essere limitata a progetti specifici, così una chiave data a un job di CI che legge solo il modello di un progetto può fare esattamente quello.
  • Il server MCP, che gli agenti AI usano per leggere e aggiornare la tua architettura, si autentica con OAuth e PKCE obbligatorio. Ogni mutazione richiede uno scope di scrittura, così un agente che hai collegato per rispondere a domande sulla tua architettura non può modificarla a meno che tu non gli abbia concesso l'accesso in scrittura.

Isolamento dei tenant

Il guasto contro cui ogni prodotto multi-tenant deve essere progettato è semplice da descrivere: il server verifica che tu abbia effettuato l'accesso e appartenga a una qualche organizzazione, poi si fida di qualunque identificatore ci sia nella richiesta. Cambi l'ID nell'URL e stai leggendo i dati di qualcun altro.

Archyl autorizza ogni richiesta rispetto alla risorsa che tocca. Chiedere un diagramma, un documento o una chiave significa verificare che il progetto o l'organizzazione proprietaria di quella specifica risorsa sia uno a cui hai accesso, non solo che tu abbia effettuato l'accesso. La stessa regola vale per l'API HTTP e per il server MCP.

Due proprietà fanno sì che questo regga nel tempo:

  • L'autorizzazione fallisce in modo chiuso (fail closed). Se non si può determinare a chi appartiene una risorsa, la risposta è no.
  • Test automatici di tenancy girano in CI e fanno fallire la build se un controllo di autorizzazione viene rimosso, invece di aspettare che qualcuno se ne accorga.

Cosa vede l'AI

Le funzionalità AI di Archyl Cloud usano OpenAI, e nessun altro provider di AI, a meno che la tua organizzazione non configuri la propria chiave.

Per la scoperta dell'architettura, che legge un repository e propone un modello C4, inviamo firme del codice anziché codice sorgente. Ecco un file così come si trova nel tuo repository:

package billing

import (
	"context"
	"github.com/stripe/stripe-go/v82"
)

type InvoiceService struct {
	Repo InvoiceRepository
}

func (s *InvoiceService) Finalize(ctx context.Context, id string) error {
	inv, err := s.Repo.Get(ctx, id)
	if err != nil {
		return err
	}
	if inv.Total > approvalThreshold {
		return ErrNeedsApproval
	}
	return s.Repo.MarkFinal(ctx, id)
}

Ed ecco la sezione che la scoperta costruisce a partire da esso, cioè ciò che entra nel prompt:

--- internal/billing/service.go [go] ---
Imports: context, github.com/stripe/stripe-go/v82
Types: struct InvoiceService,   InvoiceService.Repo InvoiceRepository
Functions: func (s *InvoiceService) Finalize(ctx context.Context, id string) error

La regola di approvazione, la soglia e il corpo di Finalize restano fuori. Ciò che entra: il nome del repository, la struttura di file e directory, e queste firme (import, dichiarazioni di tipi e funzioni, costanti esportate). Basta per capire che un component di fatturazione parla con Stripe. Però non è irrilevante: i nomi di funzioni e tipi descrivono il tuo sistema, quindi trattali come dati che stai condividendo.

Due limiti a questa affermazione, perché tu non ci legga più di quanto dice:

  • Descrive il modo in cui la scoperta gestisce il codice sorgente. Se la scoperta trova nel repository Architecture Decision Records scritti in Markdown, ne invia il testo per poterli trasformare in decisioni strutturate, e invia le prime righe dei file di documentazione per assegnare loro un titolo.
  • Le altre funzionalità AI inviano ciò di cui il loro compito ha bisogno. Un coding agent, per esempio, lavora sui file che sta modificando, quindi li vede.

Se la tua policy stabilisce che il codice può andare solo a un provider con cui hai un contratto, le organizzazioni possono usare la propria chiave AI. Le richieste AI vanno allora a quel provider, con il tuo contratto. Se non deve uscire proprio nulla dalla tua rete, un Archyl self-hosted può eseguire modelli con Ollama sul tuo hardware.

Come lo testiamo

Nella pipeline

La nostra pipeline di CI esegue quattro scanner di sicurezza:

  • govulncheck per le vulnerabilità note nelle dipendenze Go che chiamiamo davvero
  • CodeQL per l'analisi statica del nostro codice
  • gitleaks per i secret committati per errore
  • Trivy per le vulnerabilità nelle immagini dei container e nella configurazione dell'infrastruttura

Nella piattaforma

  • Le richieste in uscita vengono controllate. Ogni integrazione che chiama un URL fornito da te (un server Git self-hosted, un webhook, un endpoint AI) è protetta contro la server-side request forgery, così quell'URL non può essere usato per far raggiungere ad Archyl la propria rete interna.
  • Il browser esegue solo gli script che distribuiamo noi. Una Content-Security-Policy rigorosa elenca ogni script inline tramite hash, e gli script caricati da una CDN portano hash di Subresource Integrity, così una copia modificata viene rifiutata.
  • I container sono blindati. Girano come utente non root, su un filesystem di sola lettura, senza capability Linux.
  • Gli eventi di sicurezza vengono registrati, compresi i login falliti, i tentativi MFA falliti e i token rifiutati.

Penetration test

Tra luglio e settembre 2026 abbiamo eseguito dieci round di penetration test interni. Ogni rilievo è stato corretto e coperto da un test di regressione, così lo stesso problema viene intercettato se si ripresenta.

"Interni" significa esattamente questo: abbiamo eseguito noi stessi questi test, e non è stata coinvolta alcuna società indipendente. Un penetration test indipendente è pianificato nell'ambito dell'audit SOC 2.

I tuoi diritti in base al GDPR

  • Esportazione. Puoi esportare i tuoi dati in JSON.
  • Cancellazione. Eliminare il tuo account elimina tutto ciò che gli appartiene, a cascata attraverso i tuoi dati e compresi gli allegati caricati nell'object storage.
  • Un DPA per ogni cliente. Il Data Processing Agreement è disponibile per tutti i clienti.
  • Notifica delle violazioni entro 72 ore.
  • 30 giorni di preavviso prima di qualsiasi modifica ai nostri sub-responsabili del trattamento, così puoi opporti prima che la modifica avvenga.

Questi sono i sub-responsabili oggi:

Sub-responsabile Per cosa
Google Cloud Storage Allegati della documentazione
OpenAI Funzionalità AI su Archyl Cloud
Stripe Pagamenti. I dati delle carte vanno a Stripe e non toccano mai Archyl.
Sentry Tracciamento degli errori
Mailgun Email transazionali (inviti, verifica, reset della password)
GitHub, GitLab, Bitbucket Solo quando li colleghi, per il login e l'accesso ai repository

Il DPA indica la sede e le garanzie legali di ciascuno.

Cosa non dichiariamo ancora

Una pagina sulla sicurezza che elenca solo i punti di forza ti lascia a cercare le lacune da solo. Eccole:

  • Nessuna certificazione. Archyl non è certificato SOC 2 e non è certificato ISO 27001. Per SOC 2 Type I, il readiness assessment è completato e l'audit indipendente è in attesa. ISO 27001 è pianificata. Quando esisterà un report di audit, il Centro Fiducia lo dirà; fino ad allora, nulla di ciò che pubblichiamo dovrebbe lasciar intendere il contrario.
  • Ancora nessun penetration test indipendente. I dieci round descritti sopra erano interni. Il test indipendente arriva con l'audit SOC 2.
  • Non tutte le colonne sono cifrate. Identificatori, timestamp, posizioni nei diagrammi, email e nomi restano in chiaro, come descritto sopra.

Se il tuo processo richiede una certificazione che Archyl non ha ancora, è un vincolo reale, e preferiamo che tu lo sappia adesso piuttosto che alla sesta settimana di una revisione di procurement.

Dove andare adesso

  • Il Centro Fiducia raccoglie i documenti in un unico posto.
  • Il Security Whitepaper approfondisce ogni controllo, compresi i rate limit e gli eventi di sicurezza che registriamo.
  • Il Data Processing Agreement è la versione contrattuale della sezione GDPR qui sopra.
  • Per domande sulla protezione dei dati, o per voci del questionario a cui questo articolo non risponde, scrivi a privacy@archyl.com.
  • Per segnalare una vulnerabilità, scrivi a security@archyl.com. Confermiamo la ricezione entro 24 ore.

Se sei tu la persona che deve dare l'approvazione ad Archyl, preferiamo che tu trovi una risposta precisa a ogni domanda piuttosto che una risposta sicura alla maggior parte di esse. Dove qualcosa qui non è abbastanza preciso per la tua revisione, chiedi, e lo renderemo preciso.