Beveiliging en integriteit van onze financiële transacties
Banken zoals de onze gebruiken gespecialiseerde serverinfrastructuren om afzonderlijke operationele domeinen te beheren. Op basis van architectuureisen en financiële regelgeving zijn de belangrijkste servertypen:
1. Kernbankservers
Deze servers vormen de centrale operationele ruggengraat en beheren cliëntrekeningen, transacties en compliance:
- Transactieverwerkingsservers: voeren in realtime betalingsautorisatie, fraudecontroles en afwikkelingen uit (bijv. SWIFT, SEPA).
- Servers voor rekeningbeheer: verwerken gebeurtenissen in de levenscyclus van rekeningen (opening/afsluiting), renteberekeningen en liquiditeitsmonitoring.
- Compliance-servers: automatiseren AML-controles (Anti-Money Laundering), audittrails en rapportage (bijv. IFRS, GDPR).
2. Grootboekservers
Verantwoordelijk voor het bijhouden van onveranderlijke financiële gegevens:
- Grootboekservers: Houden de dubbele boekhouding bij over rekeningen heen en waarborgen naleving van boekhoudnormen zoals IFRS.
- Distributed Ledger Technology (DLT)-servers: Op blockchain gebaseerde systemen voor grensoverschrijdende betalingen, KYC-verificatie en manipulatiebestendige transactielogboeken.
3. Externe communicatieservers
Maken beveiligde interactie met externe entiteiten mogelijk:
- EBICS-servers: beheren de Electronic Banking Internet Communication Standard voor SEPA-betalingen, die veel wordt gebruikt in Duitsland, Frankrijk en Zwitserland.
- Host-to-host-servers (H2H): Directe SFTP/FTPS-verbindingen voor zakelijke transacties met een hoog volume (bijv. bulkverwerking van salarisbetalingen).
- API-gatewayservers: bieden RESTful-interfaces voor betalingsinitiatie in realtime en rekeningaggregatie (beveiligd via OAuth2/mTLS).
- Swift-interfaceservers: verbinden de bank met het Swift-netwerk voor interbancair berichtenverkeer (SCORE is de gesloten gebruikersgroep van Swift voor zakelijke toegang en is geen servertype).
4. Databaseservers
Centrale opslagplaatsen voor gestructureerde financiële gegevens:
- Klantgegevensservers: Bevatten KYC-documenten, transactiehistorie en gedragsanalyses.
- Productcatalogusservers: beheer van het aanbod, zoals leningen, hypotheken en depositorentes.
5. Beveiligings- en infrastructuurservers
Waarborgen systeemintegriteit en naleving van de regelgeving:
- Hardware Security Module (HSM)-servers: beveiligen cryptografische sleutels voor digitale handtekeningen en SSL/TLS-versleuteling.
- Firewall-/VPN-servers: zorgen voor netwerksegmentatie en beveiligde externe toegang voor medewerkers.
- Servers voor noodherstel: hosten back-upsystemen voor bedrijfscontinuïteit bij storingen.
Moderne banken zetten vaak hybride architecturen in, waarbij on-premises kernservers worden gecombineerd met cloudgebaseerde DLT-nodes voor schaalbaarheid. Een bank kan bijvoorbeeld de on-premises kernbankiersystemen van IBM gebruiken naast door AWS gehoste grootboekservers voor realtime reconciliatie. Deze modulaire aanpak brengt compliance, prestaties en innovatie in evenwicht.
Banken moeten een evenwicht vinden tussen serverconsolidatie voor de efficiëntie en het handhaven van isolatie voor beveiliging en compliance. Hieronder volgt een overzicht van combineerbare en niet-combineerbare servers op basis van technische beperkingen en sectorpraktijken:
Servers die kunnen worden gecombineerd
1. Web-/applicatieservers
- Combinatiemethode: virtualisatie (VMware, KVM) of containerisatie (Docker/Kubernetes)
- Voorbeeld: Het hosten van meerdere bankportalen (retail, zakelijk, mobiel) op een hypervisorcluster met load balancing.
2. Databaseservers
- Combinatiemethode: multi-tenant clouddatabases (AWS RDS, Azure SQL)
- Core-bankingdatabases van Oracle/MS SQL kunnen naast analysesystemen op basis van PostgreSQL/MongoDB bestaan in hybride cloudomgevingen.
3. Externe communicatiegateways
- Combinatiemethode: geïntegreerde API-gateways (Apigee, MuleSoft)
- EBICS-, SWIFT- en SFTP-diensten kunnen op gedeelde infrastructuur draaien met protocolspecifieke microservices.
4. Disaster-recoveryservers
- Combinatiemethode: actief-actieve geografische redundantie
- Replica's van het kernbankensysteem en back-upgrootboekservers kunnen gebruikmaken van gedeelde disaster-recoveryclusters.
5. Middlewareservers
- Combinatiemethode: Enterprise Service Bus (ESB)
- Betalingsroutering, compliancecontroles en valutaconversiediensten, geconsolideerd op IBM Integration Bus/SAP PI.
Servers die geïsoleerd dienen te blijven
1. Centrale transactieverwerkingsservers
- Reden: Scheiding (fysiek of door strikte segmentatie) beperkt de reikwijdte van de PCI DSS- en SOC 2-controles
- Voorbeeld: IBM zSystems met CICS-transactiemonitors kunnen de hardware niet delen met andere workloads.
2. Hardware Security Module (HSM)-servers
- Reden: FIPS 140-2/140-3 Level 3 schrijft speciale, manipulatiebestendige hardware voor
- Implementatie: HSM's van Thales/Gemalto voor het beheer van digitale handtekeningen en encryptiesleutels.
3. Realtime grootboeksystemen
- Reden: Dubbel boekhouden vereist atomiciteit
- Voorbeeld: Oracle Financial Services-ledgerservers met rechtstreeks aangesloten NVMe-opslag.
4. Servers voor toezichtrapportage
- Reden: Auditlogs moeten worden beschermd tegen wijziging en worden bewaard gedurende de termijnen die de AVG en de AML-wetgeving vereisen; scheiding maakt dit gemakkelijker aantoonbaar
- Opzet: afzonderlijke SQL Server-instanties voor MiFID II-/FATCA-rapportages.
5. ATM-/POS-autorisatiesystemen
- Reden: SLA met een beschikbaarheid van 99,999% en vereisten voor netwerksegmentatie
- Architectuur: IBM Power Systems met redundante Fibre Channel-SAN's.
Technische beperkingen:
- Core-bankingsystemen met een groot transactievolume vereisen specifieke netwerkverbindingen met hoge bandbreedte
- PCI DSS vereist dat opgeslagen kaartnummers (PAN) onleesbaar worden gemaakt en dat de omgeving waarin kaarthoudergegevens worden verwerkt wordt gesegmenteerd
- Het Swift Customer Security Programme (CSP) vereist dat de Swift-infrastructuur zich in een beschermde, beveiligde zone bevindt
Wij hebben met succes 80% van de niet-kritieke servers (web/applicatie/middleware) geconsolideerd, terwijl de kern-, HSM- en grootboeksystemen volledig geïsoleerd blijven.
Het beveiligen van grootboekservers in de cloud vereist meerlaagse beschermingsmaatregelen die zijn afgestemd op de gevoeligheid van financiële gegevens. Op basis van de beveiligingsbest practices van AWS en bankspecifieke implementaties volgt hieronder een gestructureerde aanpak:
1. Onveranderlijke grootboektechnologie
Gebruik speciaal ontwikkelde grootboekdatabases met cryptografische verificatie van elke transactie:
- Cryptografische ketening: elke transactie wordt gehasht en gekoppeld aan de voorgaande registratie, waardoor een onveranderlijk controlespoor ontstaat.
- Ingebouwde integriteitscontroles: de database verifieert automatisch haar eigen historie en voorkomt zo manipulatie.
- SQL-achtige bevraging: Behoudt de compatibiliteit met bestaande financiële systemen en voegt blockchainachtige beveiliging toe.
2. Netwerkisolatie
- VPC-architectuur: plaats grootboekservers in private subnets zonder openbare internettoegang.
- Beveiligingsgroepen: Beperk inkomend verkeer tot specifieke poorten (bijv. PostgreSQL/Aurora) vanaf vooraf goedgekeurde IP-bereiken.
- VPC-endpoints: Gebruik AWS PrivateLink voor beveiligde communicatie tussen ledgerservers en diensten zoals S3/KMS, zonder de gegevens bloot te stellen aan het openbare web.
3. Versleuteling
- In rust: door AWS KMS beheerde sleutels versleutelen grootboekgegevens in Amazon Aurora, met automatische sleutelrotatie.
- Tijdens transport: Dwing TLS 1.3 af voor alle communicatie tussen client en server en tussen diensten onderling.
- Clientzijdige versleuteling: Versleutel gevoelige velden (bijv. rekeningsaldi) vooraf vóór opslag met behulp van de AWS Encryption SDK.
4. Toegangscontrole
- IAM-rollen: Wijs gedetailleerde bevoegdheden toe (bijvoorbeeld rollen met uitsluitend invoerrechten) om onbedoelde of kwaadwillige verwijdering van gegevens te voorkomen.
- Tijdelijke toegangsgegevens: Gebruik AWS STS voor tijdgebonden toegang tijdens onderhoud.
- MFA-afdwinging: Vereis hardwaretokens (YubiKey) voor root- en beheerdersaccounts.
5. Monitoring en audit
- Realtimemeldingen: Configureer AWS CloudWatch zodat waarschuwingen worden gegenereerd bij ongebruikelijke transactiepatronen (bijv. overboekingen van meer dan € 1 miljoen).
- Activiteitenlogboeken: alle wijzigingen in het grootboek worden vastgelegd via AWS CloudTrail, geïntegreerd met SIEM-tools.
- Geautomatiseerde audits: voer wekelijks AWS Config-regels uit om de encryptiestatus en het netwerkbeleid te controleren.
6. Compliance en governance
- Zonegebaseerde segmentatie: gescheiden DEV/TEST/PROD-grootboekomgevingen met behulp van AWS Organizations.
- Geautomatiseerde rapportage: Genereer PCI DSS/AVG-compliancerapporten via AWS Audit Manager.
- Audits door derden: Plan jaarlijks penetratietests in met door AWS goedgekeurde partners.
7. Herstel na een calamiteit
- Replicatie tussen regio's: Houd versleutelde grootboekreplica's aan in de AWS-regio's Frankfurt en Stockholm.
- Point-in-time recovery: Schakel continue back-ups in om gegevens te herstellen naar elk willekeurig moment binnen de bewaartermijn (maximaal 35 dagen).
- Air-gapped back-ups: Bewaar driemaandelijkse grootboekmomentopnamen in de AWS Backup Vault met een bewaartermijn van 7 jaar.
Om te voorkomen dat kwaadaardige invoer zich verspreidt naar disaster recovery-servers (DR), hanteren banken gelaagde beveiligingsstrategieën die back-ups isoleren, strikte toegangscontroles afdwingen en de gegevensintegriteit valideren. Hieronder volgt een technische uiteenzetting van de belangrijkste maatregelen:
1. Onveranderlijke back-ups met Write-Once-Read-Many-configuraties (WORM)
- Doel: voorkomen dat ransomware back-upgegevens wijzigt of versleutelt.
Implementatie: Gebruik AWS S3 Object Lock of Azure Blob Immutable Storage om verwijdering of wijziging gedurende een vastgestelde bewaartermijn te voorkomen. Pas cryptografische hashing (SHA-256) toe op back-upbestanden; elke manipulatie maakt de hash ongeldig en activeert waarschuwingen.
2. Air-gapped en offline replicatie
- Netwerkisolatie: Plaats DR-servers in een afzonderlijke VPC/VLAN zonder inkomende internettoegang. Gebruik unidirectionele replicatie (primair → DR) via tools zoals AWS Storage Gateway of Azure Site Recovery, waarbij omgekeerde synchronisatie wordt geblokkeerd.
- Fysieke air-gapping: Bewaar voor kritieke systemen tape-back-ups of offline opslag die uitsluitend tijdens geplande replicatievensters wordt aangesloten.
3. Zero-trust-toegangscontroles
- Authenticatie: Dwing MFA af voor alle DR-beheerinterfaces (bijv. AWS SSO, Azure AD Conditional Access). Wijs IAM-rollen toe met minimale rechten (bijv. uitsluitend `s3:GetObject`).
- Netwerkbeveiliging: Beperk replicatieverkeer tot IPsec-VPN-tunnels of AWS Direct Connect/Azure ExpressRoute. Zet intrusiedetectiesystemen (IDS) zoals Snort of Suricata in om replicatiekanalen te monitoren.
4. Validatie van data-integriteit
- Controles vóór replicatie: Scan brongegevens vóór de replicatie op malware met hulpmiddelen zoals ClamAV of CrowdStrike Falcon. Vergelijk checksums vóór en na de overdracht om manipulatie op te sporen.
- Audits na replicatie: gebruik AWS Config of Azure Policy om versleutelings- en toegangsbeleid af te dwingen op DR-servers. Plan dagelijkse integriteitscontroles via scripts (bijvoorbeeld `sha256sum`-validatie).
5. Logisch gescheiden omgevingen
6. Geautomatiseerde failovertests
- Gesimuleerde aanvallen: Gebruik hulpmiddelen zoals Chaos Monkey om ransomware-infecties te simuleren en de veerkracht van DR-servers te valideren. Meet de recovery time objectives (RTO) en recovery point objectives (RPO) tijdens oefeningen.
- Forensische analyse: bewaar VPC Flow Logs en CloudTrail-gebeurtenissen gedurende 90 dagen om afwijkingen in de replicatie te herleiden.
Het implementeren van onveranderlijke back-ups is essentieel om gegevens te beschermen tegen ransomware, onbedoelde verwijderingen en schendingen van de regelgeving. Op basis van sectorstandaarden en tools zoals AWS, Veeam en Azure gelden de volgende best practices:
1. Dwing onveranderlijkheid af op de opslaglaag
- Gebruik WORM-configuraties (Write-Once-Read-Many) via objectopslag met S3 Object Lock (AWS), Azure Immutable Blob Storage of Veeam Hardened Repositories.
- Schakel retentievergrendelingen in om voortijdige verwijdering of wijziging te voorkomen, ook door beheerders.
2. Hanteer een 3-2-1-1-back-upstrategie
- 3 kopieën van gegevens (primair + twee back-ups)
- 2 typen opslagmedia (bijv. schijf + cloud)
- 1 externe kopie (geografisch gescheiden)
- 1 onveranderlijke kopie (air-gapped of WORM-ingeschakeld).
3. Voer strikte toegangscontroles in
- Rolgebaseerde toegang (RBAC): beperk machtigingen met behulp van IAM-rollen (bijv. toegangsbeleid voor AWS Backup Vault).
- Multifactorauthenticatie (MFA): dwing dit af voor beheerinterfaces voor back-ups (bijv. Azure AD Conditional Access).
- Netwerkisolatie: Bewaar back-ups in private subnetten/VPC's zonder openbare internettoegang.
4. Versleutel gegevens end-to-end
- In rust: Gebruik AES-256 of via KMS beheerde sleutels (AWS, Azure).
- Tijdens transport: TLS 1.3 voor replicatiekanalen.
- Versleuteling aan cliëntzijde: Gevoelige velden vooraf versleutelen vóór de back-up (bijvoorbeeld de AES-256-versleuteling van Veeam met door de gebruiker beheerde sleutels).
5. Bewaring en validering automatiseren
- Bewaartermijnen: Definieer RPO/RTO en automatiseer levenscyclusregels (bijv. de bewaartermijn van 7 jaar van AWS Backup Vault).
- Controlesomvalidatie: controleer de integriteit vóór en na replicatie (bijv. met SHA-256-hashing).
- Regelmatige audits: Gebruik hulpmiddelen zoals AWS Config of Veeam SureBackup om herstelprocedures te testen.
6. Gelaagde beveiliging voor hybride omgevingen
7. Zorg voor naleving en onherroepelijkheid
- Vergrendel de onveranderlijkheidsinstellingen na het testen (bijv. de status "Enabled and locked" van Azure).
- Voldoe aan regelgeving: Sluit aan bij GDPR, HIPAA of SOX met behulp van hulpmiddelen zoals AWS Audit Manager.
- Audits door derden: plan jaarlijkse penetratietests in (bijv. met door AWS goedgekeurde partners).
Voorbeeldworkflow met AWS en Veeam
1. Primaire back-up: Veeam Backup & Replication naar een S3-bucket met Object Lock.
2. Replicatie: AWS DataSync naar een secundaire regio (Frankfurt → Stockholm).
3. Validatie: dagelijkse CloudTrail-logs + driemaandelijkse hersteltests.
4. Bewaartermijn: onveranderlijke periode van 90 dagen met KMS-versleuteling.
Door onveranderlijkheidskenmerken, toegangscontroles en hybride redundantie te combineren, kunnen organisaties back-ups realiseren die bestand zijn tegen ransomware en tegelijkertijd voldoen aan de compliancevereisten.