Sicurezza e integrità

Sicurezza e integrità delle nostre transazioni finanziarie

Banche come la nostra utilizzano infrastrutture server specializzate per gestire distinti ambiti operativi. In base ai requisiti architetturali e alla normativa finanziaria, le principali tipologie di server includono:

1. Server del core banking

Questi server costituiscono la struttura operativa centrale e gestiscono i conti della clientela, le transazioni e la compliance:

• Server di elaborazione delle transazioni: eseguono in tempo reale l'autorizzazione dei pagamenti, i controlli antifrode e i regolamenti (ad es. SWIFT, SEPA).
• Server di gestione dei conti: gestiscono gli eventi del ciclo di vita del conto (apertura/chiusura), il calcolo degli interessi e il monitoraggio della liquidità.
• Server per la conformità normativa: automatizzano i controlli AML (Anti-Money Laundering), le piste di audit e la reportistica (ad es. IFRS, GDPR).

2. Server del registro

Responsabile della tenuta di scritture finanziarie immutabili:

• Server del libro mastro generale: tengono traccia della contabilità a partita doppia dei conti, assicurando la conformità a principi contabili quali gli IFRS.
• Server Distributed Ledger Technology (DLT): sistemi basati su blockchain per pagamenti transfrontalieri, verifica KYC e registri delle transazioni a prova di manomissione.

3. Server di comunicazione esterna
Consentono interazioni sicure con soggetti esterni:

• Server EBICS: gestiscono lo standard Electronic Banking Internet Communication Standard per i pagamenti SEPA, ampiamente utilizzato in Germania, Francia e Svizzera.
• Server Host-to-Host (H2H): connessioni SFTP/FTPS dirette per operazioni corporate ad alto volume (ad es. elaborazione massiva degli stipendi).
• Server gateway API: forniscono interfacce RESTful per l'avvio dei pagamenti in tempo reale e l'aggregazione dei conti (protette tramite OAuth2/mTLS).
• Server di interfaccia Swift: collegano la banca alla rete Swift per lo scambio di messaggi interbancari (SCORE è il gruppo chiuso di utenti di Swift per l'accesso delle imprese, non un tipo di server).

4. Server di database
Archivi centrali di dati finanziari strutturati:

• Server dei dati della clientela: conservano i documenti KYC, lo storico delle transazioni e le analisi comportamentali.
• Server del catalogo prodotti: gestiscono offerte quali finanziamenti, mutui e tassi sui depositi.

5. Server di sicurezza e infrastruttura
Garantiscono l'integrità dei sistemi e il rispetto della normativa:

• Server Hardware Security Module (HSM): proteggono le chiavi crittografiche utilizzate per le firme digitali e per la cifratura SSL/TLS.
• Server firewall/VPN: impongono la segmentazione della rete e l'accesso remoto sicuro per i dipendenti.
• Server di disaster recovery: ospitano sistemi di backup per garantire la continuità operativa in caso di interruzioni.

Le banche moderne adottano spesso architetture ibride, combinando server core on-premise con nodi DLT basati su cloud per garantire scalabilità. Ad esempio, una banca può utilizzare i server di core banking on-premise di IBM insieme a server di registro ospitati su AWS per la riconciliazione in tempo reale. Questo approccio modulare bilancia conformità normativa, prestazioni e innovazione.

Le banche devono bilanciare il consolidamento dei server, finalizzato all'efficienza, con il mantenimento dell'isolamento a fini di sicurezza e conformità. Di seguito una ripartizione tra server consolidabili e non consolidabili, sulla base dei vincoli tecnici e delle prassi di settore:
Server che possono essere consolidati
1. Server web/applicativi

• Metodo combinato: virtualizzazione (VMware, KVM) o containerizzazione (Docker/Kubernetes)
• Esempio: ospitare più portali bancari (retail, corporate, mobile) su un cluster di hypervisor con bilanciamento del carico.

2. Server di database

• Metodo combinato: database cloud multi-tenant (AWS RDS, Azure SQL)
• I database bancari centrali basati su Oracle/MS SQL possono coesistere con sistemi analitici PostgreSQL/MongoDB in configurazioni di cloud ibrido.

3. Gateway di comunicazione esterna

• Metodo combinato: gateway API unificati (Apigee, MuleSoft)
• I servizi EBICS, SWIFT e SFTP possono operare su un'infrastruttura condivisa, con microservizi specifici per ciascun protocollo.

4. Server di disaster recovery

• Metodo di combinazione: geo-ridondanza active-active
• Le repliche del core banking e i server di backup del libro mastro possono condividere i cluster di disaster recovery.

5. Server middleware

• Metodo combinato: Enterprise Service Bus (ESB)
• Instradamento dei pagamenti, controlli di compliance e servizi di conversione valutaria consolidati su IBM Integration Bus/SAP PI.

Server che devono rimanere isolati
1. Server centrali di elaborazione delle transazioni

• Motivo: la separazione (fisica o mediante rigorosa segmentazione) riduce l'ambito di applicazione dei controlli PCI DSS e SOC 2
• Esempio: i sistemi IBM zSystems che eseguono monitor transazionali CICS non possono condividere l'hardware con altri carichi di lavoro.

2. Server con Hardware Security Module (HSM)

• Motivo: lo standard FIPS 140-2/140-3 Livello 3 richiede hardware dedicato a prova di manomissione
• Implementazione: HSM Thales/Gemalto per la gestione delle firme digitali e delle chiavi di cifratura.

3. Sistemi di registro in tempo reale

• Motivo: la partita doppia richiede l'atomicità
• Esempio: server di registro Oracle Financial Services con storage NVMe collegato direttamente.

4. Server per le segnalazioni regolamentari

• Motivo: i registri di audit devono essere protetti da alterazioni e conservati per i periodi richiesti dal GDPR e dalla normativa AML; la separazione rende più agevole dimostrarlo
• Configurazione: Istanze SQL Server isolate per le segnalazioni MiFID II/FATCA.

5. Sistemi di autorizzazione ATM/POS

• Motivazione: SLA di disponibilità del 99,999% e requisiti di segmentazione della rete
• Architettura: IBM Power Systems con SAN Fibre Channel ridondanti.

Vincoli tecnici:

• I sistemi di core banking ad alto volume richiedono collegamenti di rete dedicati e a elevata larghezza di banda
• Lo standard PCI DSS richiede che i numeri di carta memorizzati (PAN) siano resi illeggibili e che l'ambiente dei dati dei titolari di carta sia segmentato
• Lo Swift Customer Security Programme (CSP) richiede che l'infrastruttura Swift sia collocata in una zona protetta e sicura

Abbiamo consolidato con successo l'80% dei server non critici (web/applicativi/middleware), mantenendo del tutto isolati i sistemi core, HSM e ledger.

La protezione dei server che ospitano i registri contabili nel cloud richiede misure di sicurezza stratificate, adeguate alla sensibilità dei dati finanziari. Sulla base delle migliori pratiche di sicurezza di AWS e di implementazioni specifiche per il settore bancario, si propone il seguente approccio strutturato:

1. Tecnologia del registro immutabile
Utilizzo di database di registro appositamente progettati, con verifica crittografica di ogni transazione:

• Concatenazione crittografica: ogni operazione viene sottoposta a hash e collegata alla registrazione precedente, creando una pista di audit immodificabile.
• Controlli di integrità integrati: il database verifica automaticamente la propria cronologia, impedendone la manomissione.
• Interrogazioni di tipo SQL: mantiene la compatibilità con i sistemi finanziari esistenti, aggiungendo una sicurezza analoga a quella della blockchain.

2. Isolamento della rete

• Architettura VPC: distribuire i server del libro mastro in subnet private prive di accesso a Internet pubblico.
• Gruppi di sicurezza: limitare il traffico in entrata proveniente da intervalli di indirizzi IP preventivamente approvati a porte specifiche (ad es. PostgreSQL/Aurora).
• Endpoint VPC: utilizzare AWS PrivateLink per la comunicazione sicura tra i server del ledger e servizi come S3/KMS senza esporre i dati alla rete pubblica.

3. Crittografia

• A riposo: chiavi gestite da AWS KMS cifrano i dati del registro contabile in Amazon Aurora, con rotazione automatica delle chiavi.
• In transito: applicare TLS 1.3 a tutte le comunicazioni client-server e tra servizi.
• Crittografia lato client: cifrare preventivamente i campi sensibili (ad es. i saldi dei conti) prima della conservazione, utilizzando l'AWS Encryption SDK.

4. Controllo degli accessi

• Ruoli IAM: assegnazione di autorizzazioni granulari (ad esempio, ruoli di solo inserimento) per prevenire cancellazioni accidentali o dolose dei dati.
• Credenziali temporanee: utilizzare AWS STS per l'accesso a tempo limitato durante le attività di manutenzione.
• Applicazione dell'MFA: richiedere token hardware (YubiKey) per gli account root/amministratore.

5. Monitoraggio e revisione

• Avvisi in tempo reale: configurare AWS CloudWatch affinché generi segnalazioni in presenza di andamenti anomali delle transazioni (ad esempio, trasferimenti superiori a EUR 1 milione).
• Registri delle attività: tracciamento di tutte le modifiche al registro contabile tramite AWS CloudTrail integrato con strumenti SIEM.
• Audit automatizzati: eseguire con cadenza settimanale le regole AWS Config per verificare lo stato della cifratura e le policy di rete.

6. Compliance e governance

• Segmentazione per zone: ambienti ledger DEV/TEST/PROD separati mediante AWS Organizations.
• Report automatici: generazione di report di conformità PCI DSS/GDPR tramite AWS Audit Manager.
• Verifiche di terze parti: pianificare annualmente penetration test con partner approvati da AWS.

7. Disaster Recovery

• Replica interregionale: mantenere repliche cifrate del registro nelle regioni AWS di Francoforte e Stoccolma.
• Ripristino a un punto nel tempo (point-in-time recovery): consente di attivare backup continui per ripristinare i dati a qualsiasi secondo compreso nel periodo di conservazione (fino a 35 giorni).
• Backup air-gapped: conservazione di snapshot trimestrali del registro in AWS Backup Vault con un periodo di conservazione di 7 anni.

Per evitare che inserimenti dolosi si propaghino ai server di disaster recovery (DR), le banche adottano strategie di sicurezza stratificate che isolano i backup, impongono rigorosi controlli degli accessi e convalidano l'integrità dei dati. Di seguito una descrizione tecnica delle principali misure:
1. Backup immodificabili con configurazioni Write-Once-Read-Many (WORM)

• Finalità: impedire al ransomware di alterare o cifrare i dati di backup.

Implementazione: utilizzare AWS S3 Object Lock o Azure Blob Immutable Storage per impedire la cancellazione o la modifica dei dati per un periodo di conservazione definito. Applicare l'hashing crittografico (SHA-256) ai file di backup: qualsiasi manomissione invalida l'hash e genera un avviso.
2. Replica air-gapped e offline

• Isolamento della rete: collocare i server di disaster recovery in una VPC/VLAN separata, priva di accesso in entrata da internet. Utilizzare una replica unidirezionale (primario → DR) mediante strumenti quali AWS Storage Gateway o Azure Site Recovery, bloccando la sincronizzazione inversa.
• Air-gapping fisico: per i sistemi critici, mantenere backup su nastro o archiviazione offline che si collegano soltanto durante le finestre di replica programmate.

3. Controlli di accesso Zero-Trust

• Autenticazione: imporre l'MFA per tutte le interfacce di gestione del disaster recovery (ad es. AWS SSO, Azure AD Conditional Access). Assegnare ruoli IAM con autorizzazioni basate sul principio del privilegio minimo (ad es. soltanto `s3:GetObject`).
• Sicurezza di rete: limitare il traffico di replica a tunnel VPN IPsec o ad AWS Direct Connect/Azure ExpressRoute. Impiegare sistemi di rilevamento delle intrusioni (IDS) come Snort o Suricata per monitorare i canali di replica.

4. Convalida dell'integrità dei dati

• Controlli preliminari alla replica: analisi dei dati di origine alla ricerca di malware con strumenti quali ClamAV o CrowdStrike Falcon prima della replica. Confronto dei checksum prima e dopo il trasferimento per rilevare eventuali manomissioni.
• Audit successivi alla replica: utilizzare AWS Config o Azure Policy per applicare le policy di cifratura e di accesso sui server di DR. Pianificare controlli giornalieri di integrità tramite script (ad es. la verifica `sha256sum`).

5. Ambienti logicamente segmentati

6. Test automatizzati di failover

• Attacchi simulati: utilizzo di strumenti come Chaos Monkey per simulare infezioni da ransomware e verificare la resilienza dei server di disaster recovery. Misurazione degli obiettivi di tempo di ripristino (RTO) e degli obiettivi di punto di ripristino (RPO) durante le esercitazioni.
• Analisi forense: conservare per 90 giorni i VPC Flow Logs e gli eventi CloudTrail per ricostruire eventuali anomalie di replica.

L'adozione di backup immutabili è essenziale per tutelare i dati da ransomware, cancellazioni accidentali e violazioni della conformità normativa. Sulla base degli standard di settore e di strumenti quali AWS, Veeam e Azure, le migliori prassi sono le seguenti:
1. Imporre l'immutabilità a livello di storage

• Utilizzare configurazioni WORM (Write-Once-Read-Many) mediante object storage con S3 Object Lock (AWS), Azure Immutable Blob Storage o Veeam Hardened Repositories.
• Attivare i blocchi di conservazione (retention lock) per impedire la cancellazione o la modifica prematura, anche da parte degli amministratori.

2. Adottare una strategia di backup 3-2-1-1

• 3 copie dei dati (copia primaria + due copie di backup)
• 2 tipologie di supporti di memorizzazione (ad es. disco + cloud)
• 1 copia esterna (geograficamente isolata)
• 1 copia immutabile (isolata dalla rete o con tecnologia WORM).

3. Implementare rigorosi controlli di accesso

• Accesso basato sui ruoli (RBAC): limitare le autorizzazioni mediante ruoli IAM (ad es. le policy di accesso ai Backup Vault di AWS).
• Autenticazione a più fattori (MFA): da applicare alle interfacce di gestione dei backup (ad es. Azure AD Conditional Access).
• Isolamento della rete: conservare i backup in subnet/VPC private, prive di accesso a internet pubblico.

4. Cifrare i dati end-to-end

• A riposo: utilizzare AES-256 o chiavi gestite tramite KMS (AWS, Azure).
• In transito: TLS 1.3 per i canali di replica.
• Cifratura lato client: cifrare preventivamente i campi sensibili prima del backup (ad esempio, AES-256 di Veeam con chiavi gestite dall'utente).

5. Automatizzare la conservazione e la validazione

• Politiche di conservazione: definire RPO/RTO e automatizzare le regole del ciclo di vita (ad es. conservazione settennale di AWS Backup Vault).
• Convalida del checksum: verifica dell’integrità prima e dopo la replica (ad esempio tramite hashing SHA-256).
• Audit periodici: utilizzare strumenti quali AWS Config o Veeam SureBackup per testare i ripristini.

6. Sicurezza a più livelli per gli ambienti ibridi

7. Garantire conformità e irrevocabilità

• Bloccare le impostazioni di immutabilità al termine dei test (ad es. lo stato «Enabled and locked» di Azure).
• Conformità alla normativa: allineamento a GDPR, HIPAA o SOX mediante strumenti quali AWS Audit Manager.
• Audit di terze parti: pianificare penetration test annuali (ad es. avvalendosi di partner approvati da AWS).

Esempio di flusso operativo con AWS e Veeam
1. Backup primario: Veeam Backup & Replication su un bucket S3 con Object Lock.
2. Replica: AWS DataSync verso una regione secondaria (Francoforte → Stoccolma).
3. Validazione: log CloudTrail giornalieri + prove di ripristino trimestrali.
4. Conservazione: periodo di immutabilità di 90 giorni con crittografia KMS.

Combinando caratteristiche di immutabilità, controlli di accesso e ridondanza ibrida, le organizzazioni possono realizzare backup resistenti al ransomware nel rispetto dei requisiti di compliance.