Cifra prima.
Archivia dopo.
Ovunque.
Ogni giorno la tua azienda carica documenti sul cloud. Chi gestisce quei server può leggerli. Con FortySeal non può più: ogni file viene reso illeggibile prima ancora di partire, e le chiavi per aprirlo restano solo a te.
Il Gateway si interpone tra le tue applicazioni e qualsiasi storage S3-compatible. Ogni file viene cifrato in memoria con AES-256-GCM; la chiave simmetrica è incapsulata con ML-KEM-1024 e l'intero blob è firmato con ML-DSA-87 — gli algoritmi post-quantistici standardizzati dal NIST nel 2024 (FIPS 203/204/205, livello di sicurezza massimo).
Lo storage riceve solo un blob opaco con nome UUID casuale: zero plaintext, zero metadati leggibili, zero possibilità di correlazione tra file.
Quello che archivi oggi, qualcuno potrebbe leggerlo tra dieci anni.
La protezione usata oggi dalla maggior parte dei sistemi ha una scadenza: i computer quantistici, quando arriveranno, sapranno romperla. Chi ruba dati protetti adesso deve solo conservarli e aspettare. FortySeal usa una protezione di nuova generazione, progettata per resistere anche a quel momento.
La minaccia si chiama harvest now, decrypt later: traffico cifrato con RSA/ECC viene intercettato e archiviato oggi, in attesa che un computer quantistico esegua l'algoritmo di Shor e lo decifri. È una strategia documentata dei servizi di intelligence.
FortySeal usa ML-KEM-1024 e ML-DSA-87, selezionati dal NIST dopo 8 anni di valutazione internazionale e pubblicati come standard FIPS 203/204 nel 2024. Si basano su problemi matematici reticolari che l'algoritmo di Shor non sa risolvere.
Quattro passaggi. Il cloud non legge nulla.
Per te non cambia niente nel modo di lavorare. Cambia solo quello che gli altri possono vedere dei tuoi file: niente.
Invii un file
Come fai oggi, dallo stesso sistema che già usi. Nessuna modifica alle tue abitudini o al tuo software.
Il Gateway lo protegge
Prima di partire, il file viene reso completamente illeggibile e sigillato con una firma digitale. Tutto in un istante, senza mai lasciare tracce.
Il cloud lo archivia
Quello che arriva sul cloud è un pacchetto sigillato con un nome casuale. Il provider non sa cosa contiene, né a chi appartiene.
Tutto viene verificato
Ogni notte e ad ogni download, il sistema controlla che nessuno abbia toccato i tuoi file. Se qualcosa non torna, il file viene bloccato.
Step 1 — la tua applicazione esegue una chiamata PUT REST standard, identica a quella di S3. Zero modifiche al codice esistente.
Step 2 — il Gateway cifra il payload con AES-256-GCM, incapsula la chiave con ML-KEM-1024 e firma il blob con ML-DSA-87. Tutto avviene in RAM: il plaintext non viene mai scritto su disco.
Step 3 — sullo storage arriva solo il blob FSEAL con chiave fisica UUID randomica: nessun nome file, nessuna struttura, nessuna correlazione possibile tra oggetti.
Step 4 — verifica di integrità notturna, ad ogni download e su richiesta manuale. La firma viene controllata in modalità fail-closed: se non è valida, il file non viene consegnato (HTTP 409). Ogni esecuzione lascia uno storico permanente utilizzabile come evidenza di compliance.
Compatibile con Amazon S3, MinIO, Cubbit DS3, Wasabi, Backblaze B2 — stesso endpoint, stesse chiamate REST.
Tre cose che il cloud da solo non può darti.
Questi non sono optional da attivare o configurare. Sono il modo in cui il Gateway è costruito — funzionano sempre, per tutti, senza eccezioni.
Nessuno può leggere i tuoi file — nemmeno noi
Il provider cloud che archivia i tuoi dati non può aprirli. FortySeal stessa non può aprirli. Solo chi ha le chiavi giuste può farlo.
La chiave simmetrica AES-256-GCM è incapsulata con ML-KEM-1024: solo chi possiede la chiave privata PQC può recuperarla. Il blob sullo storage è matematicamente illeggibile senza di essa.
Se qualcuno tocca un tuo file, lo scopri subito
Ogni file ha un sigillo digitale. Se viene modificato — anche di un solo bit — il sistema se ne accorge e non lo consegna. Il file alterato viene bloccato prima di arrivare a te.
AES-256-GCM autentica il ciphertext. ML-DSA-87 firma l'intero blob. Il SHA3-256 del plaintext è verificabile dopo decifratura. Verifica in modalità fail-closed: firma non valida → HTTP 409, consegna bloccata.
Ogni operazione lascia una traccia certificata
Chi ha caricato un file, quando, da dove. Chi lo ha scaricato. Chi ha tentato di accedervi senza permesso. Un registro che non si può cancellare né modificare.
Ogni blob porta la firma del mittente. Il log è immutabile su blockchain privata con retention 365 giorni. Ogni verifica di integrità genera un record IntegrityCheckRun permanente — evidenza di compliance per NIS2 Art. 21 e DORA Art. 9.
I tuoi dati sono separati da quelli degli altri
Se FortySeal serve anche altre aziende, i loro file e i tuoi non si mescolano mai. Non tecnicamente, non logicamente.
Ogni organizzazione ha il proprio service account con keypair PQC dedicati. I file usano chiavi fisiche UUID randomiche: nessuna correlazione possibile tra oggetti di tenant diversi sullo stesso storage S3.
Il sistema si protegge da solo dagli attacchi
Se qualcuno tenta di entrare a forza, il sistema lo blocca. Se un file viene compromesso, viene isolato. Nessuno deve intervenire manualmente.
Rate limiting per-API-key, lockout brute-force per IP (8 tentativi / 15 min), blocco automatico dei blob con anomalie di integrità. Webhook asincroni HMAC per notifiche su ogni evento critico.
Le chiavi di sicurezza si aggiornano senza bloccare niente
Le chiavi crittografiche vengono rinnovate periodicamente — una buona pratica di sicurezza. I tuoi file restano accessibili durante e dopo il rinnovo.
Rotazione delle keypair PQC (KEM + firma) tramite comando gateway_rotate_secret_key. Ogni blob mantiene il riferimento alla chiave con cui è stato cifrato — i file precedenti restano decifrabili, i nuovi usano le chiavi aggiornate.
Lo stesso Gateway, settori diversi.
Dal medico che invia referti alla banca che archivia contratti — il problema è lo stesso: dati che non devono finire in mani sbagliate.
Archiviazione documenti regolamentati
Una banca archivia contratti, estratti conto e report di rischio su Cubbit DS3. DORA impone cifratura a riposo, audit trail, separazione dei ruoli e resilienza operativa.
Parla con il team tecnicoPipeline dati clinici
Un ospedale invia referti DICOM su AWS S3. I dati devono essere cifrati prima di lasciare il perimetro ospedaliero, con chiavi separate per ogni reparto.
Parla con il team tecnicoDisaster recovery multi-provider
Un'azienda SaaS vuole backup su 3 provider diversi con la garanzia che nessuno possa leggere i dati, e che il backup sopravviva alla compromissione di un singolo provider.
Parla con il team tecnicoArtefatti e secrets cifrati
Una pipeline GitHub Actions archivia artefatti di build e configurazioni sensibili su storage esterno, senza esporre i dati al provider CI/CD.
Parla con il team tecnicoAbbiamo cercato i problemi. Li abbiamo trovati. Li abbiamo risolti.
A luglio 2026 abbiamo ispezionato tutto il sistema dall'interno, cercando punti deboli. Ne abbiamo trovati quattro. Tutti e quattro sono stati corretti e coperti da test automatici che li verificano ad ogni aggiornamento.
Essere trasparenti su questo è una scelta: nessun sistema nasce perfetto. Chi non lo dice, mente.
Firma verificata ad ogni download
Se un file viene alterato dopo il caricamento, viene bloccato prima di arrivare a chi lo ha richiesto.
Nessun accesso non dichiarato
Un accesso senza permessi espliciti non entra. Prima, per errore, entrava con permessi di amministratore.
Login protetto da tentativi ripetuti
Dopo 8 tentativi falliti in 15 minuti, l'accesso viene bloccato per quell'indirizzo e per quell'account.
Notifiche solo verso destinazioni verificate
Le notifiche automatiche non possono essere dirottate verso sistemi non autorizzati.
Se la tua azienda deve rispettare queste norme, FortySeal le rispetta con te.
NIS2, DORA, GDPR non sono sticker da mettere sul sito. Sono requisiti tecnici precisi che FortySeal soddisfa per architettura, non per configurazione.
Dove siamo, dove andiamo.
Fase 1 e Fase 2 in produzione. Fase 2b in arrivo.
Fase 1 + 2 — Production-ready
- Cifratura FSEAL v1 con ML-KEM-1024 e ML-DSA-87
- 5 provider S3: AWS, MinIO, Cubbit, Wasabi, Backblaze
- Multi-tenant, audit trail, dashboard
- Rate limiting, webhook asincroni, rotazione chiavi
- Security audit interno applicato
Fase 2b — Compatibilità estesa
- AWS Signature V4 — compatibilità nativa aws cli
- Presigned URL PQC — download diretto one-time
- TTL automatico oggetti — policy retention
- Object versioning
- Webhook delivery log persistente
Fase 3 — Scala e certificazioni
- SDK ufficiali Python, Node.js, Go
- Kubernetes + Helm chart scalabile
- HSM integration (FIPS 140-3 Level 3)
- Certificazione eIDAS 2
- SIEM export (Splunk, Sentinel, QRadar)
Perché abbiamo costruito FortySeal.
Volevamo che la protezione dei dati di livello professionale fosse accessibile a chi ne ha bisogno — senza dover assumere un team di crittografi o capire ogni algoritmo. La sicurezza seria non dovrebbe essere un privilegio.
Due amici appassionati di tecnologia, convinti che la crittografia post-quantistica non debba essere un privilegio per chi ha un team di ingegneri dedicato.
Vuoi vederlo funzionare sui tuoi dati?
Mostraci il tuo caso concreto. In 30 minuti ti facciamo vedere cosa cambia per te.