Sécurité et haute disponibilité : le faux dilemme des bases de données

"Sécuriser, ça ralentit." "La haute dispo, ça complexifie." "On ne peut pas tout avoir." J'entends ces phrases dans chaque audit. Elles sont fausses. Non seulement elles sont fausses, mais elles sont dangereuses — parce qu'elles justifient l'inaction. Et l'inaction, en sécurité comme en disponibilité, c'est le vrai risque.

La vérité que personne ne veut admettre : la sécurité et la haute disponibilité sont les deux faces d'une même pièce. Elles ne se font pas concurrence. Elles se renforcent. Une base bien sécurisée est plus résiliente. Une base hautement disponible est plus facile à sécuriser. Et les techniques pour atteindre l'une servent souvent l'autre. Démonstration.

AlwaysOn : haute disponibilité ET isolation de sécurité

Les AlwaysOn Availability Groups de SQL Server sont la référence en matière de haute disponibilité. Un primaire, un ou plusieurs secondaires, failover automatique. C'est le pitch commercial. Mais ce que peu de gens réalisent, c'est que les réplicas secondaires sont aussi un outil de sécurité puissant.

Vous pouvez configurer un réplica secondaire en lecture seule et y diriger vos requêtes de reporting, vos analyses, vos exports. Ça, c'est la performance. Mais ça, c'est aussi la sécurité : vos utilisateurs de reporting n'ont pas accès au primaire. Ils ne peuvent pas, par accident ou par malveillance, lancer une requête qui verrouille la base de production. L'isolation est physique, pas juste logique.

-- Configuration d'un Availability Group (simplifié)
CREATE AVAILABILITY GROUP [AG_Prod]
FOR DATABASE [CommandesDB]
REPLICA ON 
    N'SRV-PRIMAIRE' WITH (ENDPOINT_URL = 'TCP://SRV-PRIMAIRE:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)),
    N'SRV-SECONDAIRE' WITH (ENDPOINT_URL = 'TCP://SRV-SECONDAIRE:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));

-- Lister les réplicas et leurs rôles
SELECT 
    replica_server_name,
    role_desc,
    connected_state_desc,
    operational_state_desc
FROM sys.dm_hadr_availability_replica_states;

Un réplica en lecture seule, c'est de la haute disponibilité (si le primaire tombe, le secondaire prend le relais) et de la sécurité (isolation des accès de reporting) en même temps. Ce n'est pas un compromis. C'est un gain sur les deux axes.

TDE : la performance que tout le monde surestime

Transparent Data Encryption chiffre les fichiers de données et de logs au repos. Le grand mythe : "TDE ralentit tout de 20%." Faux. Les benchmarks sérieux montrent un overhead de 2 à 5% sur la plupart des charges OLTP, et quasi nul sur les reads. Pourquoi ? Parce que le chiffrement/déchiffrement se fait au niveau des pages, en CPU, et que les CPUs modernes ont des instructions AES-NI qui rendent ça presque gratuit.

-- Activer TDE sur une base
USE master;
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'MotDePasseComplexeEtLong!2025';

CREATE CERTIFICATE TDE_Cert 
WITH SUBJECT = 'Certificat TDE pour CommandesDB';

USE CommandesDB;
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE TDE_Cert;

ALTER DATABASE CommandesDB 
SET ENCRYPTION ON;

-- Vérifier l'état du chiffrement
SELECT 
    db_name(database_id) AS DBName,
    encryption_state_desc,
    percent_complete,
    key_algorithm,
    key_length
FROM sys.dm_database_encryption_keys;

Le vrai coût de TDE n'est pas la performance. C'est la gestion des certificats. Si vous perdez le certificat qui protège la clé de chiffrement de la base, vous perdez la base. Point. Sauvegardez vos certificats. Sauvegardez-les ailleurs que sur le même serveur. Testez la restauration des certificats. C'est ça, le vrai risque de TDE — pas les 3% de CPU.

Always Encrypted : quand la sécurité a un vrai coût

Always Encrypted, lui, a un coût réel. Contrairement à TDE qui chiffre au repos, Always Encrypted chiffre les données au niveau applicatif — le moteur SQL Server ne voit jamais les données en clair. C'est une sécurité beaucoup plus forte, mais ça a un prix : pas de range scan sur les colonnes chiffrées (sauf avec deterministic encryption et types compatibles), pas de tri, pas d'agrégation sur les colonnes chiffrées de manière aléatoire.

Mon conseil : utilisez Always Encrypted pour les données sensibles par nature — numéros de carte de crédit, données médicales, numéros de sécurité sociale. Pas pour tout. Le chiffrement déterministe permet l'égalité (=), mais pas les range scans. Le chiffrement aléatoire ne permet même pas l'égalité. Choisir le bon type de chiffrement par colonne, c'est un vrai travail d'architecture, pas une décision binaire.

Le mythe du "chiffrement ralentit tout"

Récapitulons les overheads réels :

• TDE : 2-5% sur OLTP, négligeable sur reads. Instructions AES-NI.
• Backup encryption : overhead minimal, les backups sont I/O-bound, pas CPU-bound.
• Connection encryption (TLS) : overhead négligeable avec les ciphers modernes (AES-GCM, ChaCha20).
• Always Encrypted : overhead réel, mais limité aux colonnes chiffrées. Pas de range scan, pas de tri.
• Row-Level Security : overhead de l'évaluation du prédicat, généralement < 5% si le prédicat est bien écrit.

Le pattern ? La plupart des couches de sécurité modernes ont un overhead négligeable. Celles qui ont un overhead réel (Always Encrypted) sont optionnelles et ciblées. L'idée que "sécuriser ralentit tout" est un héritage des années 2000, quand le chiffrement software était coûteux. Aujourd'hui, le hardware fait le travail. L'excuse ne tient plus.

Row-Level Security : la sécurité qui simplifie l'architecture

Row-Level Security (RLS) permet de filtrer les lignes accessibles à un utilisateur au niveau du moteur, pas de l'application. Au lieu d'écrire WHERE ClientId = @CurrentUserClientId dans chaque requête, vous définissez un prédicat de sécurité une fois, et le moteur l'applique partout.

-- Activer RLS sur une table
ALTER TABLE Commandes
ENABLE ROW LEVEL SECURITY;

-- Créer un prédicat de filtrage
CREATE SECURITY POLICY CommandesSecurityPolicy
ADD FILTER PREDICATE dbo.fn_CurrentUserFilter(ClientId) 
ON dbo.Commandes;

-- La fonction de prédicat
CREATE FUNCTION dbo.fn_CurrentUserFilter(@ClientId INT)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN 
    SELECT 1 AS fn_result 
    WHERE @ClientId = SESSION_CONTEXT(N'CurrentUserId');

L'avantage sécurité est évident : même si un développeur oublie le filtre dans une requête, le moteur l'applique. Impossible de fuiter des données par accident. Mais l'avantage disponibilité l'est moins : avec RLS, vous pouvez avoir une seule base partagée entre plusieurs clients (multi-tenant) sans risque de cross-contamination. Pas besoin de schémas séparés, pas besoin de bases séparées. Une base, un schéma, isolation garantie par le moteur. C'est plus simple à opérer, donc plus disponible.

L'audit : la sécurité qui aide la disponibilité

L'audit logging a mauvaise réputation : "ça génère trop de données, ça ralentit les écritures." C'est vrai si l'audit est mal configuré — tout auditer, y compris les SELECT sur des tables de référence, c'est absurde. Mais un audit ciblé — qui trace les modifications, les accès aux données sensibles, les changements de schéma — a un overhead minimal et une valeur inestimable.

Et l'audit aide la disponibilité d'une façon inattendue : quand quelque chose casse en production, l'audit vous dit qui a fait quoi et quand. Sans audit, vous devinez. Avec audit, vous savez. Le temps de diagnostic diminue. Le MTTR (Mean Time To Recovery) diminue. La disponibilité augmente. La sécurité et la disponibilité, encore une fois, main dans la main.

Le vrai coût : pas la sécurité, mais l'absence de sécurité

Voici le calcul que personne ne fait. Un overhead de 3% sur une base qui tourne 24/7, c'est invisible. Une breach qui expose 100 000 enregistrements clients, c'est : notification obligatoire, amendes RGPD (jusqu'à 4% du CA annuel), perte de confiance client, audit forcé, équipe incident pendant des semaines. Le ratio coût-sécurité vs coût-breach est de 1 pour 1000, au minimum.

Et la disponibilité ? Une breach cause souvent un downtime — l'équipe incident éteint les accès, isole les systèmes, reconstruit. Une base non sécurisée est une base moins disponible, parce qu'elle est plus vulnérable aux incidents qui causent des downtimes. La sécurité n'est pas l'ennemie de la disponibilité. L'absence de sécurité l'est.

La chaîne de confiance : backup, certificats, restauration

Le maillon le plus faible de la haute disponibilité, c'est souvent le backup. Vous avez des backups chiffrés ? Bien. Vous avez le certificat qui déchiffre les backups ? Où ? Sur le même serveur que les backups ? Si le serveur brûle, vous perdez les backups ET le certificat. Game over.

-- Sauvegarder le certificat maître TDE (CRITIQUE)
USE master;
BACKUP CERTIFICATE TDE_Cert 
TO FILE = 'C:\Backup\Certs\TDE_Cert.cer'
WITH PRIVATE KEY (
    FILE = 'C:\Backup\Certs\TDE_Cert.pvk',
    ENCRYPTION BY PASSWORD = 'AutreMotDePasseComplexe!2025'
);

-- Sauvegarder la master key du serveur (CRITIQUE)
BACKUP SERVICE MASTER KEY 
TO FILE = 'C:\Backup\Certs\SMK.bak'
ENCRYPTION BY PASSWORD = 'EncoreUnMotDePasse!2025';

Ces fichiers doivent être stockés hors du serveur de base de données, idéalement dans un coffre-fort numérique ou un gestionnaire de secrets (Azure Key Vault, AWS KMS, HashiCorp Vault). Et la restauration doit être testée. Pas en théorie. En pratique. Sur un serveur différent. Avec les vrais fichiers de backup. Parce qu'un backup non testé n'est pas un backup — c'est un vœu pieux.