> informazioni > termini politiche > Misure di sicurezza

Misure di sicurezza

Misure di sicurezza di ProcessMind

Data di entrata in vigore: 14 settembre 2026

Il presente documento descrive le misure tecniche e organizzative («TOM») adottate da ProcessMind B.V. per proteggere la riservatezza, l’integrità e la disponibilità dei Dati del Cliente. ProcessMind applica un approccio di difesa in profondità, in cui più livelli di sicurezza indipendenti proteggono i Dati del Cliente a ogni livello — dalla rete e dall’infrastruttura fino all’identità, all’autorizzazione, all’isolamento dei dati, alla crittografia, al monitoraggio e allo sviluppo del software. Tali misure integrano l’Addendum sul trattamento dei dati, l’Informativa sulla privacy e la Policy di hosting SaaS. ProcessMind riesamina e aggiorna tali misure almeno una volta all’anno.

I Dati del Cliente non vengono mai venduti a terzi, condivisi con terzi né utilizzati da terzi per finalità proprie.

1. Sicurezza dell’infrastruttura

1.1 Piattaforma cloud. ProcessMind è ospitato esclusivamente su Amazon Web Services (AWS) nell’UE (Francoforte, Germania, eu-central-1). AWS dispone delle certificazioni ISO 27001, ISO 27017, ISO 27018, SOC 1/2/3 e PCI DSS. Per l’elenco completo, consulti Programmi di conformità AWS.

1.2 Architettura serverless. La logica applicativa di ProcessMind viene eseguita su AWS Lambda e su servizi gestiti da AWS. ProcessMind non gestisce server applicativi di lunga durata amministrati dai clienti, eliminando così un’ampia categoria di attività di applicazione delle patch al sistema operativo e di rafforzamento della sicurezza dei server.

1.3 Perimetri di rete. ProcessMind gestisce una VPC AWS per i controlli relativi a database e rete. Aurora PostgreSQL viene eseguito in subnet private senza accesso in uscita a Internet, non è accessibile pubblicamente e i log di flusso VPC sono abilitati. Per impostazione predefinita, ProcessMind non colloca le funzioni Lambda dell’applicazione all’interno della VPC. Le funzioni Lambda accedono ad Aurora tramite AWS RDS Data API su TLS, utilizzando l’autenticazione IAM e Secrets Manager.

1.4 Distribuzione dei contenuti e controlli edge. Il sito web rivolto ai clienti, la SPA frontend e il traffico delle risorse pubbliche sono serviti tramite Amazon CloudFront. Tutte le distribuzioni CloudFront applicano una politica TLS minima di TLS 1.2 (2021). Le distribuzioni del sito web e della SPA frontend aggiungono inoltre intestazioni di risposta di sicurezza, tra cui HTTP Strict Transport Security (HSTS), Content Security Policy (CSP), frame-ancestors 'none', X-Frame-Options: DENY, X-Content-Type-Options, la politica referrer e la politica delle autorizzazioni. La distribuzione delle risorse pubbliche utilizza CloudFront Origin Access Control per mantenere privato il bucket di origine. Il traffico API rivolto ai clienti è gestito separatamente tramite Amazon API Gateway: il traffico HTTPS di richiesta/risposta è servito tramite un’API HTTP su un sottodominio API dedicato e le connessioni client in tempo reale sono servite tramite un’API WebSocket separata di API Gateway su un sottodominio WebSocket dedicato.

1.5 Separazione degli ambienti. Gli ambienti di produzione e sviluppo utilizzano account AWS, database e stack infrastrutturali separati. Le credenziali degli sviluppatori non consentono l’accesso ai Dati del Cliente in produzione.

2. Crittografia dei dati

2.1 Crittografia in transito. Tutti i dati trasmessi tra i client e i servizi ProcessMind sono crittografati utilizzando TLS 1.2 o versioni successive. Gli endpoint rivolti ai clienti sono esposti tramite HTTPS. I bucket S3, gli argomenti SNS e le code SQS creati direttamente da ProcessMind impongono l’accesso esclusivamente tramite SSL. L’accesso al database tramite RDS Data API e le altre chiamate ai servizi AWS utilizzano HTTPS/TLS.

2.2 Crittografia a riposo. Aurora PostgreSQL è crittografato a riposo utilizzando chiavi AWS KMS gestite dal cliente con rotazione automatica delle chiavi. I bucket S3 relativi ai dati dei clienti e alle operazioni creati direttamente da ProcessMind, compresi i bucket per caricamenti, risorse e log di accesso, utilizzano chiavi KMS gestite dal cliente. Anche i gruppi di log CloudWatch, gli argomenti SNS e le code SQS creati direttamente da ProcessMind utilizzano chiavi KMS gestite dal cliente. I bucket di origine del sito web e del frontend gestiti da SST utilizzano la crittografia lato server S3 gestita da AWS (SSE-S3 / AES-256) anziché chiavi KMS gestite dal cliente.

2.3 Gestione delle chiavi e dei segreti. Le chiavi di crittografia del database sono gestite centralmente tramite AWS KMS e l’accesso alle chiavi è disciplinato da politiche IAM basate sul principio del privilegio minimo. Le credenziali del database sono conservate in AWS Secrets Manager. Il segreto principale di Aurora e il segreto dell’utente applicativo con privilegi limitati vengono ruotati automaticamente ogni trenta (30) giorni. Le chiavi e i segreti di produzione non vengono mai conservati nel codice sorgente; le credenziali utilizzate esclusivamente per lo sviluppo sono isolate dalla produzione. Alcune risorse di supporto gestite da AWS/CDK/SST continuano a utilizzare la crittografia gestita da AWS quando il servizio o il framework non espongono la configurazione di chiavi gestite dal cliente.

3. Isolamento e residenza dei dati

3.1 Isolamento dei tenant. A ciascun tenant cliente è assegnata un’istanza di database dedicata e isolata. I Dati del Cliente non vengono mai mescolati, a livello di database, con i dati di altri clienti. I metadati condivisi (ad es. record degli account, fatturazione, mappature degli utenti ai tenant) sono conservati in un database multi-tenant separato, soggetto a rigorosi controlli di accesso. Le tabelle condivise con ambito tenant e organizzazione sono inoltre protette da politiche di sicurezza a livello di riga (RLS) di PostgreSQL, applicate tramite un contesto del database definito per ciascuna richiesta.

3.2 Residenza dei dati. Tutti i Dati del Cliente, compresi database, file caricati, backup e risultati delle query, sono conservati esclusivamente nell’UE (Francoforte, Germania). Qualora venga incaricato un sub-responsabile del trattamento situato al di fuori del SEE per una specifica attività di trattamento (ad esempio, l’elaborazione di modelli di AI o l’elaborazione dei pagamenti), il trasferimento è disciplinato da un meccanismo di trasferimento adeguato, come descritto nell’Addendum sul trattamento dei dati, e il sub-responsabile del trattamento e il luogo del trattamento sono indicati nell’Elenco dei sub-responsabili del trattamento.

3.3 Conservazione e cancellazione dei dati. I periodi di conservazione e cancellazione sono indicati nella Sezione 6 dell’Addendum sul trattamento dei dati. I Clienti possono cancellare i propri dati in qualsiasi momento tramite l’applicazione o contattando ProcessMind. Le copie di backup vengono rimosse alla scadenza dei periodi di conservazione dei backup applicabili (Sezione 7.1).

4. Gestione delle identità e degli accessi

4.1 Autenticazione. ProcessMind supporta il Single Sign-On (SSO) tramite Microsoft Entra ID (Azure AD), Google OAuth 2.0/OIDC e LinkedIn OAuth 2.0/OIDC. ProcessMind opera in qualità di relying party e non conserva le password degli utenti. L’autenticazione a più fattori è applicata dal provider di identità — ad esempio, quando un’organizzazione collega Microsoft Entra ID (Azure AD), si applicano le politiche MFA e di accesso proprie di tale organizzazione.

4.2 Gestione delle sessioni. Le sessioni del browser utilizzano JSON Web Token (JWT) firmati, trasmessi tramite cookie sicuri e HttpOnly con i flag SameSite e Secure. Le firme dei token sono convalidate a ogni richiesta autenticata.

4.3 Modello di autorizzazione. Per le API principali dell’applicazione, ProcessMind non si affida agli authorizer nativi di API Gateway. L’autorizzazione è applicata in wrapper condivisi dei gestori Lambda, che convalidano lo stato della sessione e l’ambito del tenant prima dell’esecuzione della logica aziendale. Le route pubbliche sono inserite esplicitamente in un elenco di autorizzazione per i flussi non autenticati, i webhook, l’acquisizione di eventi e le richieste preliminari CORS. Gli endpoint API esterni utilizzano gestori di autenticazione dedicati. L’accesso ai Dati del Cliente è limitato al contesto del tenant o dell’organizzazione autenticati.

4.4 Privilegio minimo. I sistemi interni seguono il principio del privilegio minimo. I ruoli IAM sono limitati alle risorse minime necessarie, ove il framework consenta una definizione precisa dell’ambito. Alcuni ruoli generati da SST/CDK utilizzano politiche gestite o inline più ampie per i binding e il funzionamento in fase di esecuzione; tali casi sono riesaminati, limitati alle risorse ove possibile e registrati come eccezioni esplicite.

4.5 Controlli di accesso dei dipendenti. L’accesso dei dipendenti ai sistemi interni è gestito tramite Active Directory con SSO e MFA obbligatoria. Il controllo degli accessi basato sui ruoli (RBAC) garantisce che l’accesso ai Dati del Cliente sia limitato al personale autorizzato che ne abbia necessità per lo svolgimento delle proprie mansioni. I diritti di accesso sono riesaminati periodicamente.

5. Registrazione, monitoraggio e audit

5.1 Registrazione centralizzata. La registrazione degli accessi all’API HTTP e degli accessi WebSocket è abilitata con campi JSON strutturati e i log sono scritti in Amazon CloudWatch Logs, con un periodo di conservazione di una (1) settimana. Tali gruppi di log di accesso sono crittografati con una chiave AWS KMS gestita dal cliente. I log applicativi sono centralizzati in gruppi di log Amazon CloudWatch crittografati con una chiave AWS KMS gestita dal cliente e conservati per dieci (10) anni. Anche gruppi di log separati per audit e telemetria sono crittografati con una chiave AWS KMS gestita dal cliente e conservati per dieci (10) anni. Il gruppo di esportazione dei log del motore Aurora PostgreSQL è conservato per una (1) settimana.

5.2 Dati registrati e non registrati. ProcessMind registra gli eventi di accesso all’API HTTP e a WebSocket, compresi l’ora della richiesta, gli identificativi della richiesta, la route o il percorso, lo stato della risposta, la latenza, l’indirizzo IP di origine e l’user agent. ProcessMind registra inoltre gli eventi di autenticazione, i percorsi di errore asincroni e le attività applicative Lambda di supporto in gruppi di log CloudWatch centralizzati. I log di flusso VPC sono abilitati. Attualmente ProcessMind non abilita la registrazione standard degli accessi CloudFront per le distribuzioni del sito web, della SPA frontend o delle risorse pubbliche.

5.3 Monitoraggio e avvisi. Gli allarmi e i dashboard di CloudWatch monitorano lo stato del sistema, le code di messaggi non recapitabili e gli errori rilevanti per la sicurezza. Gli errori di elaborazione asincrona vengono indirizzati a code di messaggi non recapitabili crittografate (conservazione di quattordici (14) giorni; due (2) giorni per le code delle miniature e degli indici di ricerca) e gli allarmi DLQ attivano notifiche SNS per le indagini. Inoltre, ProcessMind utilizza Sentry per il tracciamento in tempo reale degli errori del frontend, il monitoraggio delle prestazioni e la riproduzione delle sessioni. Le riproduzioni delle sessioni vengono registrate solo per le sessioni in cui si verifica un errore; il testo, gli input dei moduli e i contenuti multimediali sono mascherati o bloccati nelle riproduzioni. I dati Sentry vengono acquisiti nell’UE (Francoforte) e sono limitati ai Dati di utilizzo di ProcessMind (errori del browser, tracce delle prestazioni, metadati del dispositivo e registrazioni mascherate delle riproduzioni). Sentry è incluso nell’elenco dei sub-responsabili.

5.4 Protezione dei log. I log sono conservati in gruppi di log CloudWatch dedicati e soggetti a controlli di accesso e sono crittografati a riposo. I log di produzione e di sviluppo sono separati in base ai confini degli ambienti e degli account.

6. Convalida automatizzata dei controlli e gestione delle vulnerabilità

6.1 Attività svolte da ProcessMind. ProcessMind esegue cdk-nag nell’ambito della sintesi dell’infrastruttura e del flusso di lavoro di distribuzione, utilizzando diversi pacchetti di regole di settore (tra cui AWS Solutions, NIST 800-53 e PCI DSS). I report per ciascuno stack vengono generati e riesaminati nell’ambito della gestione delle modifiche all’infrastruttura. I rilievi sono classificati come corretti, rischio accettato o miglioramento pianificato.

6.2 Gestione delle eccezioni. Le soppressioni sono registrate in un registro centrale ove consentito dal framework, limitate agli stack interessati e soggette a una motivazione scritta; qualora uno stack contenga una soppressione inline, questa è documentata insieme allo stack. Quando un rilievo viene corretto, la soppressione corrispondente viene aggiornata o rimossa. ProcessMind non considera la soppressione un’esenzione generale dal riesame.

6.3 Attività che ProcessMind attualmente non svolge. ProcessMind tiene traccia delle eccezioni sostanziali ai controlli dell’infrastruttura e le riesamina. Le principali sono:

per impostazione predefinita, le Lambda dell’applicazione non sono collocate all’interno della VPC; accedono ad Aurora tramite RDS Data API su TLS con autenticazione IAM e Secrets Manager
nessuna parte del servizio è protetta da AWS WAF: AWS WAF non supporta le API HTTP di API Gateway e anche i restanti punti di accesso non sono protetti da WAF (le connessioni WebSocket utilizzano token HMAC di breve durata; le restrizioni geografiche relative ai pagamenti sono applicate nel sistema di pagamento); inoltre, le distribuzioni statiche non dispongono della registrazione standard degli accessi di CloudFront
il ripristino del database si basa sui backup automatici di Aurora e sul ripristino a un determinato momento, anziché su un piano AWS Backup separato o su Aurora Enhanced Monitoring
non sono presenti replica S3 tra regioni né S3 Object Lock per i bucket modificabili
alcune risorse di supporto gestite da AWS/CDK/SST utilizzano la crittografia gestita da AWS o policy IAM generate più ampie, laddove il servizio non offre un’alternativa controllabile dal cliente

Il registro completo delle soppressioni è mantenuto insieme al codice dell’infrastruttura ed è disponibile su richiesta. L’uso di cdk-nag pacchetti di regole costituisce una convalida dei controlli ingegneristici, non una certificazione esterna, un giudizio di audit o un’attestazione legale di conformità a HIPAA, NIST o PCI DSS.

6.4 Gestione delle dipendenze. Le dipendenze software sono monitorate costantemente per individuare vulnerabilità note. Le vulnerabilità critiche e ad alta gravità vengono corrette con l’obiettivo di intervenire entro sette (7) giorni. Le dipendenze vengono aggiornate secondo un ciclo regolare.

6.5 Ciclo di vita dello sviluppo software sicuro (SDLC). ProcessMind adotta un approccio di difesa in profondità allo sviluppo software. Ogni modifica destinata alla produzione deve superare più livelli indipendenti di convalida automatizzata prima della distribuzione:

Analisi statica e sicurezza dei tipi: la modalità strict di TypeScript ed ESLint impongono la correttezza dei tipi, la sicurezza rispetto ai valori null e schemi di codifica rilevanti per la sicurezza in fase di compilazione.
Revisione del codice assistita dall’AI: l’analisi assistita dall’AI fornisce un’ulteriore prospettiva di revisione delle pull request per individuare rischi per la sicurezza, errori logici e deviazioni dalle convenzioni, integrando i test automatizzati.
Test unitari e di integrazione: una suite completa di test Vitest convalida la logica aziendale, i modelli di accesso ai dati, il comportamento delle API e la gestione degli errori rispetto a risorse AWS attive nell’ambiente di sviluppo.
Test end-to-end: i test del browser basati su Playwright verificano i flussi di lavoro utente critici, tra cui autenticazione, caricamento dei dati, modellazione dei processi, simulazione e isolamento multi-tenant.
Scansione della conformità dell’infrastruttura: cdk-nagconvalida il codice dell’infrastruttura rispetto a più framework di conformità a ogni modifica.
Scansione delle vulnerabilità delle dipendenze: gli audit automatizzati delle dipendenze impediscono che vulnerabilità note critiche e ad alta gravità raggiungano la produzione.

La revisione umana si concentra sull’architettura, sui confini di sicurezza e sulle decisioni a livello di progettazione, anziché sull’ispezione del codice riga per riga. In caso di modifiche strutturali, sensibili sotto il profilo della sicurezza o relative all’infrastruttura, è richiesta un’approvazione esplicita da parte di una persona, in aggiunta alla convalida automatizzata.

Tutti i livelli di convalida sono applicati tramite CI come controlli obbligatori per l’unione delle modifiche all’applicazione e all’infrastruttura nel branch principale. I contenuti del sito web e i rilasci di risorse statiche seguono un processo di rilascio separato e documentato, con controlli al momento della distribuzione — compreso un controllo automatizzato che verifica che i documenti legali siano aggiornati — anziché il controllo CI dell’applicazione. Le correzioni urgenti in produzione possono bypassare il controllo CI, ma devono essere seguite da un’esecuzione completa della pipeline e da una revisione post-incidente entro ventiquattro (24) ore.

7. Backup e ripristino di emergenza

7.1 Backup automatizzati. Amazon Aurora esegue backup continui e automatizzati con un periodo di conservazione di sette (7) giorni. I backup sono crittografati utilizzando le stesse chiavi KMS gestite dal cliente dei database di origine.

7.2 Ripristino point-in-time. Aurora supporta il ripristino point-in-time a qualsiasi secondo all’interno del periodo di conservazione dei backup, consentendo un ripristino rapido in caso di danneggiamento o eliminazione accidentale dei dati.

7.3 Durabilità e controllo delle versioni di S3. I caricamenti di file e gli artefatti operativi sono archiviati in Amazon S3, che offre una durabilità del 99,999999999% (11 nove). Il controllo delle versioni è abilitato nel bucket dei caricamenti e nei bucket delle risorse per supportare il ripristino e il rollback. I bucket di distribuzione del sito web e del frontend contengono artefatti di build riproducibili e non sono considerati un sistema di backup. Attualmente ProcessMind non abilita la replica S3 tra regioni.

7.4 Continuità operativa. Le procedure di ripristino di emergenza sono documentate e sottoposte periodicamente a test. Una sintesi è disponibile nel documento Ripristino di emergenza, continuità operativa e risposta agli incidenti. L’architettura si basa sui servizi gestiti AWS all’interno della regione eu-central-1, che AWS gestisce su più zone di disponibilità; il cluster Aurora attualmente utilizza una singola istanza writer, pertanto il ripristino del database si basa su backup automatizzati e sul ripristino a un determinato momento, anziché su un’istanza standby nella stessa regione. I backup Aurora, la durabilità di S3, le code di messaggi non recapitabili e le risorse statiche ricostruibili dal codice sorgente fanno parte della strategia di ripristino.

8. Risposta agli incidenti

8.1 Notifica degli incidenti. In caso di Incidente di sicurezza (come definito nel DPA), ProcessMind informerà i clienti interessati senza indebito ritardo e, ove possibile, entro settantadue (72) ore dal momento in cui viene a conoscenza dell’incidente.

8.2 Gestione degli incidenti. ProcessMind mantiene procedure documentate di risposta agli incidenti che coprono identificazione, contenimento, eliminazione, ripristino e revisione successiva all’incidente. Una sintesi è disponibile nel documento Ripristino di emergenza, continuità operativa e risposta agli incidenti. Le lezioni apprese dagli incidenti vengono integrate nei controlli e nei processi di sicurezza.

8.3 Comunicazioni. Le notifiche degli incidenti includono la natura e la portata dell’incidente, le categorie di dati interessate, le misure adottate per contenerlo e le azioni raccomandate al cliente.

9. Misure organizzative

9.1. Gestione della sicurezza delle informazioni. ProcessMind mantiene un sistema di gestione della sicurezza delle informazioni allineato ai principi della norma ISO 27001. ProcessMind ha selezionato il proprio percorso di certificazione ISO 27001 e di attestazione SOC 2 Type II; il processo formale di certificazione non è ancora iniziato.

9.2 Consapevolezza della sicurezza. Tutto il personale che ha accesso ai Dati del Cliente riceve una formazione sulla consapevolezza della sicurezza. Le migliori pratiche di sicurezza sono integrate nell’inserimento del personale, nei flussi di lavoro di sviluppo e nelle procedure operative.

9.3 Gestione dei fornitori e dei sub-responsabili. I sub-responsabili sono vincolati contrattualmente a standard di protezione dei dati equivalenti a quelli descritti nel presente documento. ProcessMind mantiene un elenco pubblico dei sub-responsabili e fornisce un preavviso di almeno trenta (30) giorni prima di incaricare un nuovo sub-responsabile. I sub-responsabili sono sottoposti a verifica annuale della conformità.

9.4 Riservatezza. Tutto il personale autorizzato a trattare i Dati del Cliente è vincolato da obblighi scritti di riservatezza.

10. Conformità e certificazioni

Quadro normativo / Standard	Stato
GDPR (Regolamento generale sulla protezione dei dati dell’UE)	Conforme
Residenza dei dati nell’UE (Francoforte, Germania)	Garantita
Certificazioni dell’infrastruttura AWS (ISO 27001, SOC 2, PCI DSS)	Ereditate tramite AWS
ISO 27001 (ProcessMind)	Pianificata — percorso di certificazione selezionato; procedura formale non ancora avviata
SOC 2 Type II (ProcessMind)	Pianificata — percorso di certificazione selezionato; procedura formale non ancora avviata
Convalida automatizzata dei controlli dell’infrastruttura (`cdk-nag` tra cui AWS Solutions, HIPAA Security, NIST 800-53 R4/R5, PCI DSS 3.2.1, Serverless)	Implementata come convalida dei controlli ingegneristici, non come certificazione
Clausole contrattuali tipo (SCC) per i trasferimenti internazionali	Implementate (vedere DPA)
Addendum sul trattamento dei dati (DPA)	Disponibile al pubblico

L’uso di cdk-nag pacchetti di regole non significa che ProcessMind sia formalmente certificata o sottoposta ad audit indipendente rispetto a HIPAA, NIST o PCI DSS. Tali pacchetti di regole sono utilizzati come misure di salvaguardia ingegneristiche per convalidare la progettazione dell’infrastruttura e tenere traccia esplicita delle lacune.

Per domande relative alla sicurezza o alla conformità, oppure per richiedere documentazione come rapporti di audit o questionari di sicurezza compilati, contatti support@processmind.com.