1. Riservatezza
Il responsabile del trattamento gestisce un'impresa individuale senza ulteriori collaboratori con accesso ai dati. Tutti i subfornitori impiegati (vedi DPA § 7) sono vincolati alla riservatezza. I propri dispositivi (workstation di sviluppo) sono cifrati con FileVault, protetti da Touch ID e password robuste, nonché dotati di blocco automatico dello schermo.
2. Pseudonimizzazione (art. 32 comma 1 lett. a GDPR)
- Nei log gli indirizzi e-mail non vengono indicati in chiaro, bensì
esclusivamente come
tenant_idovvero ID utente anonimizzato (pino log redaction). - Gli indirizzi IP vengono sottoposti ad hashing per il rate limiting tramite un
IP_HASH_SALTsegreto (HMAC-SHA-256); gli IP originali non vengono memorizzati in modo persistente. - L'IPv4 viene normalizzato a /32, l'IPv6 a /64, per limitare ulteriormente la riconducibilità.
3. Cifratura (art. 32 comma 1 lett. a GDPR)
3.1 Cifratura in transito
- Tutte le connessioni: HTTPS / TLS 1.2+ (HSTS attivo).
- Connessioni SMTP verso IONOS via STARTTLS, TLS 1.2+ imposto.
- Connessioni al database interne tramite socket UNIX o TLS.
3.2 Cifratura a riposo
- Token OAuth (social media): AES-256-GCM
„envelope encryption" con chiavi versionate
(
ENCRYPTION_KEY,ENCRYPTION_KEY_V2…V16). Formato:v{N}:iv:tag:ct. Il contesto AAD è vincolato atenantId:socialAccountId:platform— la manomissione del contesto della riga fa fallire la decifratura. - Password: Argon2id con parametri OWASP 2024
(
m=19456 KiB, t=2, p=1). Gli hash legacy bcrypt vengono riconosciuti al login e ricalcolati in modo trasparente con Argon2id. - Cifratura del disco delle VM: l'infrastruttura cloud IONOS offre la cifratura del disco a livello di provider.
- Secret: file
.envesclusivamente con permessi di file0600, mai nel repository Git.
4. Controllo degli accessi (fisico / infrastruttura)
- Il sistema di produzione gira nei data center IONOS in Germania (certificati ISO 27001, ISO 22301). L'accesso fisico è tutelato lato provider (servizio di sicurezza 24/7, biometria, videosorveglianza).
- Accesso SSH ai server:
esclusivamente tramite chiave pubblica (nessun login con password),
tramite una porta SSH non standard (2222),
con Fail2ban contro il brute force,
e con enforcement di
IdentitiesOnly=yes. - Il firewall (firewalld) limita le connessioni in entrata alle porte 2222 (SSH), 80 (redirect HTTP verso HTTPS) e 443 (HTTPS).
- SELinux in modalità enforcing.
5. Controllo degli accessi (livello applicativo)
- Autenticazione: e-mail + password (Argon2id)
oppure SSO (Google / Microsoft / Apple). Token di sessione basati su JWT
con firme
ES256e rotazione delkid(slot di chiave CURRENT + facoltativo PREVIOUS per la rotazione zero-downtime). - Rotazione del refresh token: rotazione basata su famiglie
con una grace window di 10 secondi in Redis; ≥3 grace hit dello stesso
vecchio token-ID attivano
theft_detectede la revoca della famiglia. - Isolamento multi-tenant tramite Postgres Row-Level-Security (RLS):
le connessioni dell'app girano sotto il ruolo DB
castloop_app(senza BYPASSRLS). Ogni transazione impostaapp.tenant_idtramiteSET LOCAL. Le migration girano sottocastloop_migrator(con BYPASSRLS). Persino una SQL injection non può uscire dal proprio ambito tenant (defense-in-depth). - Rate limiting: script Lua di Redis (check+increment atomico) contro brute force e abusi.
- CSRF: cookie SameSite-Strict + token CSRF.
- CSP: Content-Security-Policy con nonce per richiesta
e
strict-dynamic, previene l'XSS. - Accesso SSH ai server: solo un singolo amministratore (il titolare).
6. Controllo della separazione
- Database separati per progetto sul server condiviso
(DB Postgres dedicato
castloopcon utente dedicatocastloop_user, nessun accesso ad altri DB). - Gli ambienti di produzione, staging e sviluppo sono separati tra loro; i secret di produzione non finiscono mai in staging/dev.
- Mollie Key-Strict-Mode: in produzione esclusivamente chiavi
live_*, in staging/dev esclusivamente chiavitest_*— imposto tramite zodsuperRefine.
7. Integrità (art. 32 comma 1 lett. b GDPR)
- RLS impedisce la manipolazione di dati cross-tenant (vedi 5).
- Postgres advisory lock (chiave
821912301) gestisce le migration Drizzle — due deploy paralleli non possono migrare contemporaneamente. - Cifratura dei token OAuth vincolata all'AAD: la manomissione del contesto della riga fa fallire la decifratura (protezione dell'integrità tramite il tag AES-GCM).
- Idempotenza dei webhook Mollie: tabella dedicata
mollie_webhook_eventscon chiave di idempotenza(resource_id, payload_hash)(sha256 su JSON canonico). - Validazione dell'input lato client e lato server (schemi zod).
8. Disponibilità
- Auto-restart pm2:
castloop-api,castloop-workerecastloop-appgirano sotto supervisione pm2 e si riavviano automaticamente in caso di crash. - Graceful shutdown: SIGTERM/SIGINT drenano
le richieste HTTP e i job BullMQ; con cap rigido tramite
SHUTDOWN_TIMEOUT_MS. - Endpoint di healthcheck per il monitoraggio.
- Backup snapshot delle VM: gestiti dal provider IONOS,
a rotazione giornaliera. Nessun backup autonomo tramite
pg_dump— il layer di snapshot del provider è ritenuto sufficiente.
9. Resilienza
- Il rate limiting protegge dal sovraccarico.
- BullMQ con meccanismi di retry (exponential backoff) per il rendering dei clip e la pubblicazione sulle piattaforme.
- L'orphan sweeper dell'ingest Mollie (intervallo 60s, grace 120s, dedupe BullMQ-jobId=eventId) previene il drift dei pagamenti in caso di webhook falliti.
- Connessioni ioredis indipendenti per BullMQ vs. codice dell'app prevengono collisioni di key-prefix.
10. Ripristinabilità (art. 32 comma 1 lett. c GDPR)
- Snapshot delle VM a rotazione giornaliera (gestiti da IONOS).
- Il deployment tramite Git + rsync consente un rollback a un commit precedente entro pochi minuti.
- Le migration idempotenti, gestite tramite advisory lock, consentono un sicuro re-run in caso di guasti parziali.
11. Procedure di verifica periodica
- Aggiornamenti delle dipendenze (
npm audit, Dependabot) almeno mensilmente. - Patch del sistema operativo (AlmaLinux) almeno mensilmente.
- Monitoraggio dei log: log pino con redaction dei campi sensibili
(password, token, JWT, header
authorization/cookie, API key,DATABASE_URL,REDIS_URL,SMTP_PASS). - Revisione interna annuale delle TOM, con eventuale adeguamento allo stato della tecnica.
- Se necessario / su richiesta del cliente, penetration testing esterno.
12. Controllo dell'incarico
- Contratti DPA scritti con tutti i subfornitori impiegati (vedi DPA § 7), nella misura in cui questi siano da qualificare, sotto il profilo della protezione dei dati, come responsabili del trattamento.
- Canali di istruzione documentati: dashboard del cliente, corpus contrattuale AGB/DPA, e-mail informale a info@castloop.de.
- Nessun impiego di ulteriori subfornitori senza un preavviso di 30 giorni al cliente (vedi DPA § 7).