Sécurité et intégrité

Sécurité et intégrité de nos transactions financières

Des banques telles que la nôtre recourent à des infrastructures de serveurs spécialisées pour gérer des domaines opérationnels distincts. Selon les exigences d'architecture et la réglementation financière, les principaux types de serveurs sont les suivants :

1. Serveurs bancaires centraux

Ces serveurs constituent l'ossature opérationnelle centrale et assurent la gestion des comptes clients, des transactions et de la conformité :

• Serveurs de traitement des transactions : ils exécutent en temps réel l'autorisation des paiements, les contrôles antifraude et les règlements (par exemple SWIFT, SEPA).
• Serveurs de gestion de comptes : gèrent les événements du cycle de vie des comptes (ouverture/clôture), le calcul des intérêts et le suivi de la liquidité.
• Serveurs de conformité réglementaire : automatisent les contrôles AML (lutte contre le blanchiment de capitaux), les pistes d'audit et les déclarations (par exemple IFRS, RGPD).

2. Serveurs de registre

Responsable de la tenue d'enregistrements financiers inaltérables :

• Serveurs de grand livre : assurent le suivi de la comptabilité en partie double entre les comptes, garantissant la conformité aux normes comptables telles que les IFRS.
• Serveurs de technologie des registres distribués (DLT) : systèmes fondés sur la blockchain pour les paiements transfrontaliers, la vérification KYC et des journaux de transactions infalsifiables.

3. Serveurs de communication externes
Permettent des échanges sécurisés avec des entités externes :

• Serveurs EBICS : gèrent la norme Electronic Banking Internet Communication Standard pour les paiements SEPA, largement utilisée en Allemagne, en France et en Suisse.
• Serveurs Host-to-Host (H2H) : connexions SFTP/FTPS directes pour les opérations d'entreprise à fort volume (par exemple, le traitement groupé des salaires).
• Serveurs de passerelle API : fournissent des interfaces RESTful pour l'initiation de paiements en temps réel et l'agrégation de comptes (sécurisées par OAuth2/mTLS).
• Serveurs d'interface Swift : ils relient la banque au réseau Swift pour la messagerie interbancaire (SCORE est le groupe fermé d'utilisateurs de Swift destiné à l'accès des entreprises, et non un type de serveur).

4. Serveurs de bases de données
Référentiels centraux de données financières structurées :

• Serveurs de données clients : stockent les documents KYC, les historiques de transactions et les analyses comportementales.
• Serveurs de catalogue de produits : gèrent les offres telles que les prêts, les crédits immobiliers et les taux de dépôt.

5. Serveurs de sécurité et d'infrastructure
Garantissent l'intégrité des systèmes et le respect de la réglementation :

• Serveurs HSM (Hardware Security Module) : protègent les clés cryptographiques utilisées pour les signatures numériques et le chiffrement SSL/TLS.
• Serveurs pare-feu/VPN : assurent la segmentation du réseau et l'accès à distance sécurisé pour les collaborateurs.
• Serveurs de reprise après sinistre : hébergent les systèmes de secours assurant la continuité d'activité en cas d'interruption.

Les banques modernes déploient souvent des architectures hybrides, associant des serveurs centraux sur site à des nœuds DLT dans le cloud pour assurer l'évolutivité. Par exemple, une banque peut utiliser les serveurs bancaires centraux sur site d'IBM avec des serveurs de registre hébergés sur AWS pour le rapprochement en temps réel. Cette approche modulaire concilie conformité, performance et innovation.

Les banques doivent concilier la consolidation des serveurs, source d'efficacité, et le maintien de l'isolation, garante de sécurité et de conformité. Voici une synthèse des serveurs regroupables et non regroupables, selon les contraintes techniques et les pratiques du secteur :
Serveurs pouvant être regroupés
1. Serveurs web/applicatifs

• Méthode combinée : virtualisation (VMware, KVM) ou conteneurisation (Docker/Kubernetes)
• Exemple : hébergement de plusieurs portails bancaires (particuliers, entreprises, mobile) sur un cluster d'hyperviseurs avec répartition de charge.

2. Serveurs de bases de données

• Méthode combinée : bases de données cloud multi-locataires (AWS RDS, Azure SQL)
• Les bases de données bancaires centrales Oracle/MS SQL peuvent coexister avec des systèmes d'analyse PostgreSQL/MongoDB dans des configurations de cloud hybride.

3. Passerelles de communication externes

• Méthode combinée : passerelles API unifiées (Apigee, MuleSoft)
• Les services EBICS, SWIFT et SFTP peuvent s'exécuter sur une infrastructure partagée, avec des microservices propres à chaque protocole.

4. Serveurs de reprise après sinistre

• Méthode de combinaison : géo-redondance active-active
• Les répliques de systèmes bancaires centraux et les serveurs de grand livre de secours peuvent partager des grappes de reprise après sinistre.

5. Serveurs middleware

• Méthode combinée : Enterprise Service Bus (ESB)
• Services d'acheminement des paiements, de contrôles de conformité et de conversion de devises consolidés sur IBM Integration Bus/SAP PI.

Serveurs devant rester isolés
1. Serveurs centraux de traitement des transactions

• Raison : la séparation (physique ou par une segmentation stricte) réduit le périmètre des contrôles PCI DSS et SOC 2
• Exemple : les systèmes IBM zSystems exécutant des moniteurs transactionnels CICS ne peuvent pas partager leur matériel avec d'autres charges de travail.

2. Serveurs de modules de sécurité matériels (HSM)

• Raison : les normes FIPS 140-2/140-3 de niveau 3 exigent un matériel dédié inviolable
• Mise en œuvre : modules de sécurité matériels (HSM) Thales/Gemalto gérant les signatures numériques et les clés de chiffrement.

3. Systèmes de registres en temps réel

• Motif : la comptabilité en partie double exige l'atomicité
• Exemple : serveurs de grand livre Oracle Financial Services avec stockage NVMe à connexion directe.

4. Serveurs de reporting réglementaire

• Motif : les journaux d'audit doivent être protégés contre toute altération et conservés pendant les durées exigées par le RGPD et par la législation AML ; la séparation facilite la démonstration de cette conformité.
• Configuration : instances SQL Server isolées pour les rapports MiFID II/FATCA.

5. Systèmes d'autorisation DAB/TPE

• Raison : accord de niveau de service garantissant une disponibilité de 99,999 % et exigences de segmentation du réseau
• Architecture : systèmes IBM Power avec réseaux de stockage SAN Fibre Channel redondants.

Contraintes techniques :

• Les systèmes bancaires centraux à fort volume exigent des connexions réseau dédiées à large bande passante
• La norme PCI DSS exige que les numéros de carte stockés (PAN) soient rendus illisibles et que l'environnement des données de titulaires de cartes soit segmenté
• Le programme de sécurité de la clientèle de Swift (CSP) exige que l'infrastructure Swift soit située dans une zone sécurisée protégée

Nous avons consolidé avec succès 80 % des serveurs non critiques (web/applications/intergiciels), tout en maintenant les systèmes centraux, HSM et de grand livre totalement isolés.

La sécurisation des serveurs de registres dans le cloud exige des protections à plusieurs niveaux, adaptées à la sensibilité des données financières. Sur la base des meilleures pratiques de sécurité d'AWS et de mises en œuvre propres au secteur bancaire, voici une approche structurée :

1. Technologie de registre immuable
Utilisez des bases de données de registre spécialement conçues, avec vérification cryptographique de chaque transaction :

• Chaînage cryptographique : chaque opération est hachée et liée à l'entrée précédente, ce qui crée une piste d'audit inaltérable.
• Contrôles d'intégrité intégrés : la base de données vérifie automatiquement son propre historique, ce qui empêche toute altération.
• Interrogation de type SQL : préserve la compatibilité avec les systèmes financiers existants tout en ajoutant une sécurité de type blockchain.

2. Isolation du réseau

• Architecture VPC : déployez les serveurs de grand livre dans des sous-réseaux privés sans accès à l'internet public.
• Groupes de sécurité : restreindre le trafic entrant à des ports spécifiques (par exemple PostgreSQL/Aurora) en provenance de plages d'adresses IP préalablement approuvées.
• Points de terminaison VPC : recourir à AWS PrivateLink pour des communications sécurisées entre les serveurs de registre et des services tels que S3/KMS, sans exposer les données sur le web public.

3. Chiffrement

• Au repos : des clés gérées par AWS KMS chiffrent les données du registre dans Amazon Aurora, avec rotation automatique des clés.
• En transit : imposer TLS 1.3 pour toutes les communications client-serveur et entre services.
• Chiffrement côté client : chiffrez au préalable les champs sensibles (par exemple, les soldes de comptes) avant leur stockage, à l'aide d'AWS Encryption SDK.

4. Contrôle d'accès

• Rôles IAM : attribuer des autorisations granulaires (par exemple, des rôles limités à l'insertion) afin d'empêcher toute suppression de données accidentelle ou malveillante.
• Identifiants temporaires : utiliser AWS STS pour un accès limité dans le temps lors des opérations de maintenance.
• Application de l'authentification multifacteur (MFA) : exiger des jetons matériels (YubiKey) pour les comptes root/administrateur.

5. Suivi et audit

• Alertes en temps réel : configurez AWS CloudWatch pour déclencher des alertes en cas de schémas de transactions inhabituels (par exemple, virements supérieurs à 1 M€).
• Journaux d'activité : suivi de toutes les modifications du registre via AWS CloudTrail, intégré à des outils SIEM.
• Audits automatisés : exécution hebdomadaire de règles AWS Config afin de vérifier l'état du chiffrement et les politiques réseau.

6. Conformité et gouvernance

• Segmentation par zones : environnements de registre DEV/TEST/PROD distincts à l'aide d'AWS Organizations.
• Rapports automatisés : génération de rapports de conformité PCI DSS/RGPD via AWS Audit Manager.
• Audits par des tiers : planifiez chaque année des tests d'intrusion avec des partenaires agréés par AWS.

7. Reprise après sinistre

• Réplication inter-régions : maintien de répliques chiffrées du registre dans les régions AWS de Francfort et de Stockholm.
• Restauration à un instant donné : activez les sauvegardes continues afin de restaurer les données à n'importe quelle seconde de la période de rétention (jusqu'à 35 jours).
• Sauvegardes isolées du réseau (air-gapped) : conservation d'instantanés trimestriels du grand livre dans AWS Backup Vault avec une durée de conservation de 7 ans.

Pour empêcher la propagation d'écritures malveillantes vers les serveurs de reprise après sinistre (PRA), les banques mettent en œuvre des stratégies de sécurité en couches qui isolent les sauvegardes, imposent des contrôles d'accès stricts et valident l'intégrité des données. Vous trouverez ci-dessous une description technique des principales mesures :
1. Sauvegardes immuables selon une configuration WORM (Write-Once-Read-Many)

• Objectif : empêcher les rançongiciels de modifier ou de chiffrer les données de sauvegarde.

Mise en œuvre : utiliser AWS S3 Object Lock ou Azure Blob Immutable Storage afin d'empêcher la suppression ou la modification pendant une période de conservation définie. Appliquer un hachage cryptographique (SHA-256) aux fichiers de sauvegarde ; toute altération invalide le hachage et déclenche des alertes.
2. Réplication hors ligne et isolée du réseau (air-gapped)

• Isolation du réseau : hébergez les serveurs de reprise après sinistre dans un VPC/VLAN distinct, sans accès entrant depuis Internet. Utilisez une réplication unidirectionnelle (primaire → reprise après sinistre) au moyen d'outils tels qu'AWS Storage Gateway ou Azure Site Recovery, en bloquant toute synchronisation inverse.
• Isolation physique (air-gapping) : pour les systèmes critiques, conservez des sauvegardes sur bande ou un stockage hors ligne qui ne se connectent que pendant les fenêtres de réplication programmées.

3. Contrôles d'accès « zéro confiance »

• Authentification : imposer l'authentification multifacteur (MFA) pour toutes les interfaces de gestion de la reprise après sinistre (par ex. AWS SSO, Azure AD Conditional Access). Attribuer des rôles IAM assortis de droits de moindre privilège (par ex. `s3:GetObject` uniquement).
• Sécurité du réseau : limiter le trafic de réplication aux tunnels VPN IPsec ou à AWS Direct Connect/Azure ExpressRoute. Déployer des systèmes de détection d'intrusion (IDS) tels que Snort ou Suricata afin de surveiller les canaux de réplication.

4. Validation de l'intégrité des données

• Contrôles préalables à la réplication : analyser les données sources à la recherche de logiciels malveillants au moyen d'outils tels que ClamAV ou CrowdStrike Falcon avant la réplication. Comparer les sommes de contrôle avant et après le transfert afin de détecter toute altération.
• Audits postérieurs à la réplication : utilisez AWS Config ou Azure Policy pour faire appliquer les politiques de chiffrement et d'accès sur les serveurs de reprise après sinistre. Planifiez des contrôles d'intégrité quotidiens au moyen de scripts (par exemple, validation `sha256sum`).

5. Environnements logiquement cloisonnés

6. Tests automatisés de basculement

• Attaques simulées : recourir à des outils tels que Chaos Monkey pour simuler des infections par rançongiciel et valider la résilience des serveurs de reprise après sinistre. Mesurer les objectifs de temps de reprise (RTO) et les objectifs de point de reprise (RPO) lors des exercices.
• Analyse forensique : conserver pendant 90 jours les journaux de flux VPC et les événements CloudTrail afin de retracer les anomalies de réplication.

La mise en œuvre de sauvegardes immuables est essentielle pour protéger les données contre les rançongiciels, les suppressions accidentelles et les violations de conformité. Sur la base des normes du secteur et d'outils tels qu'AWS, Veeam et Azure, voici les bonnes pratiques :
1. Imposer l'immuabilité au niveau de la couche de stockage

• Utiliser des configurations WORM (Write-Once-Read-Many) au moyen d'un stockage objet avec S3 Object Lock (AWS), Azure Immutable Blob Storage ou Veeam Hardened Repositories.
• Activez des verrous de conservation afin d’empêcher toute suppression ou modification prématurée, y compris par les administrateurs.

2. Adopter une stratégie de sauvegarde 3-2-1-1

• 3 copies des données (copie principale + deux sauvegardes)
• 2 types de supports de stockage (par ex. disque + cloud)
• 1 copie hors site (géographiquement isolée)
• 1 copie immuable (isolée du réseau ou compatible WORM).

3. Mettre en œuvre des contrôles d'accès stricts

• Contrôle d'accès fondé sur les rôles (RBAC) : restreindre les autorisations au moyen de rôles IAM (par exemple, les politiques d'accès aux coffres AWS Backup).
• Authentification multifacteur (MFA) : à imposer pour les interfaces de gestion des sauvegardes (par exemple, accès conditionnel Azure AD).
• Isolation du réseau : conservez les sauvegardes dans des sous-réseaux privés/VPC sans accès à l'internet public.

4. Chiffrer les données de bout en bout

• Au repos : utiliser AES-256 ou des clés gérées par KMS (AWS, Azure).
• En transit : TLS 1.3 pour les canaux de réplication.
• Chiffrement côté client : chiffrer au préalable les champs sensibles avant la sauvegarde (par exemple, le chiffrement AES-256 de Veeam avec des clés gérées par l'utilisateur).

5. Automatiser la conservation et la validation

• Politiques de conservation : définir le RPO/RTO et automatiser les règles de cycle de vie (par exemple, la conservation de 7 ans d'AWS Backup Vault).
• Validation par somme de contrôle : vérification de l'intégrité avant et après la réplication (par exemple, hachage SHA-256).
• Audits réguliers : utilisez des outils tels qu'AWS Config ou Veeam SureBackup pour tester les restaurations.

6. Superposer les couches de sécurité dans les environnements hybrides

7. Garantir la conformité et l'irrévocabilité

• Verrouiller les paramètres d'immuabilité après les tests (par exemple, l'état « Enabled and locked » d'Azure).
• Respecter la réglementation : se conformer au RGPD, à la loi HIPAA ou à la loi SOX à l'aide d'outils tels qu'AWS Audit Manager.
• Audits par des tiers : planifier des tests d'intrusion annuels (par exemple, avec des partenaires agréés par AWS).

Exemple de flux de travail avec AWS et Veeam
1. Sauvegarde principale : Veeam Backup & Replication vers un compartiment S3 avec Object Lock.
2. Réplication : AWS DataSync vers une région secondaire (Francfort → Stockholm).
3. Validation : journaux CloudTrail quotidiens + exercices de restauration trimestriels.
4. Conservation : période d'immuabilité de 90 jours avec chiffrement KMS.

En combinant des fonctionnalités d'immuabilité, des contrôles d'accès et une redondance hybride, les organisations peuvent mettre en place des sauvegardes résistantes aux rançongiciels tout en répondant aux exigences de conformité.