Sécurité SaaS selon DORA

Le Digital Operational Resilience Act (règlement (UE) 2022/2554) constitue un corpus unique de règles pour la résilience opérationnelle numérique du secteur financier de l'UE. Il s'applique directement dans tous les États membres depuis le 17 janvier 2025. Il couvre les banques, les assureurs, les entreprises d'investissement, les établissements de paiement et de monnaie électronique, ainsi que d'autres entités financières.

Le règlement repose sur cinq piliers : gestion du risque ICT, gestion et notification des incidents ICT, tests de résilience opérationnelle numérique, gestion du risque lié aux tiers ICT et partage d'informations. Le SaaS relève surtout du pilier du risque lié aux tiers.

Presque chaque application SaaS utilisée par une entité financière, qu'il s'agisse de suites collaboratives, de CRM, de RH, d'analytique ou de gestion documentaire, est un service ICT fourni par un tiers. Le contrat devient donc un arrangement avec un tiers ICT, au sens du chapitre de DORA sur le risque lié aux tiers.

Les fournisseurs désignés comme prestataires tiers critiques de services ICT sont en outre supervisés directement par les Autorités européennes de surveillance. Cette supervision ne transfère pas pour autant la responsabilité : face à son propre superviseur, l'entité financière répond de la résilience des fonctions soutenues par le SaaS.

DORA impose à chaque entité financière de tenir un registre d'informations couvrant l'ensemble de ses arrangements avec des tiers ICT. Chaque contrat SaaS doit y figurer. Le registre indique l'identité du fournisseur, la description des services, s'ils soutiennent des fonctions critiques ou importantes, la chaîne de sous-traitance, la localisation des données et les droits de résiliation.

Les autorités compétentes reçoivent ce registre et en rendent compte aux Autorités européennes de surveillance. Les enregistrements SaaS incomplets ressortent donc lors des contrôles de supervision, au lieu de rester une lacune interne. Un registre des actifs IT précis en est le point de départ pratique.

L'évaluation est un devoir qui couvre tout le cycle de vie, et non une simple formalité d'achat. Avant de s'appuyer sur un service SaaS, l'entité doit évaluer la capacité technique du fournisseur, ses pratiques de sécurité, la qualité de son support et sa solidité financière, puis renouveler l'examen lorsque les circonstances changent.

La concentration fait l'objet d'une attention particulière : lorsque de nombreuses entités dépendent des mêmes plateformes SaaS, la défaillance d'un seul fournisseur devient un événement sectoriel. Le registre indique donc aussi dans quelle mesure chaque service est réellement remplaçable.

DORA fixe le contenu minimal des contrats de services ICT. En pratique, un accord SaaS doit comporter au moins ces clauses :

DORA harmonise la classification et la notification des incidents majeurs liés aux ICT. Un incident qui commence chez un fournisseur SaaS reste un incident de l'entité. Celle-ci doit détecter qu'une dépendance est dégradée et évaluer l'impact sur ses propres fonctions.

Tous les incidents majeurs ne sont pas une violation de données : la panne d'un fournisseur qui arrête un service critique peut aussi être à notifier. Les rapports initial, intermédiaire et final doivent être remis dans les délais prescrits, ce qui suppose de savoir à l'avance quelles fonctions reposent sur quels services.

Les tests de résilience doivent intégrer la dimension des tiers. Les programmes de tests, y compris les tests d'intrusion fondés sur la menace (TLPT) pour les entités désignées par l'autorité, doivent envisager des scénarios où un service SaaS est indisponible, dégradé ou compromis, et vérifier que la reprise et les stratégies de sortie tiennent sous contrainte.

Toutes les obligations ne s'appliquent pas de la même façon à chaque service. Ces obligations sont en général pilotées dans le cadre d'une gestion de la conformité, et le statut ci-dessous dépend du périmètre.

Aucun contrôle isolé ne couvre tout le périmètre SaaS. La revue des contrats vérifie les documents, tandis que l'inventaire et les journaux d'activité montrent ce qui est réellement utilisé. Les services adoptés sans validation, cœur du Shadow IT, restent dans l'interstice entre les deux.

Le règlement fixe les obligations, mais la pratique commence par la connaissance des SaaS que l'organisation utilise réellement. Les services adoptés par des équipes isolées n'entrent jamais au registre et ne sont jamais évalués, alors qu'ils transportent les mêmes flux de données que les services approuvés.

Aucun des contrôles suivants n'est nommé dans le règlement. Sans eux, toutefois, les obligations que le règlement nomme sont difficiles à remplir. Définir quelles données peuvent atteindre quel service relève de la prévention des pertes de données.

1. 1

   Commencer par l'inventaire

   Recenser chaque application SaaS utilisée, y compris celles que les collaborateurs adoptent d'eux-mêmes.

2. 2

   Classer les données

   Déterminer quelles données peuvent atteindre quel service.

3. 3

   Couvrir les canaux d'entrée

   Appliquer la prévention des pertes de données aux envois depuis le navigateur, aux clients de synchronisation et à la messagerie, pour que les données réglementées n'atteignent que les services du registre.

4. 4

   Journaliser l'activité des utilisateurs

   Conserver une piste de preuves dans et autour des applications SaaS, pour la classification des incidents et les questions des superviseurs.

Commencez par les données dont l'exposition ferait le plus de dégâts, puis cartographiez les services susceptibles de les recevoir. Une politique de classification des données donne à chaque contrat et à chaque contrôle le même point de référence.

Pour aller plus loin : Le concept de « Zero Trust ».