Vérifier les références et les certificats des fournisseurs SaaS : les sources publiques

Ce qui peut réellement être vérifié publiquement en matière de références et de certificats

Un sceau ISO 27001 sur la page marketing, des logos de clients et la mention « certifié » sont des autodéclarations. Ils ne deviennent vérifiables que par le biais d'un organisme indépendant du fournisseur : le répertoire de l'organisme de certification émetteur, une clé publique pour la vérification de signature ou la notification d'attribution de l'entité adjudicatrice. La vérification ne s'effectue donc pas en interrogeant le fournisseur, mais en contrôlant ses déclarations auprès de tiers.

Quatre catégories de preuves sont accessibles publiquement, et chacune prouve quelque chose de différent. Une inscription au registre de l'organisme de certification atteste de l'existence, du titulaire, du domaine d'application et de la durée de validité d'un certificat – et non que ce domaine d'application couvre le service SaaS spécifiquement souscrit. Une signature atteste qu'un document provient, sans altération, du titulaire d'une clé spécifique – et non que son contenu est correct. Une clé publique sous une adresse fixe sur le domaine du fournisseur atteste de qui est habilité à émettre le document et rend la vérification indépendante de la participation du fournisseur. Une notification d'attribution atteste de qui a reçu une commande publique et quand – et non de la façon dont le projet s'est déroulé.

Pour les achats, cela signifie : définir pour chaque preuve ce qui est exigé et où elle sera vérifiée de manière indépendante. Exiger du fournisseur le numéro de certificat et l'organisme émetteur plutôt qu'une copie PDF ; exiger l'emplacement de stockage de la clé publique avec son empreinte plutôt qu'un rapport en pièce jointe d'un courriel ; exiger, pour les projets de référence, l'entité adjudicatrice et la date d'attribution afin que la notification puisse être recherchée elle-même. La mise à jour doit être réglée contractuellement : les certificats doivent être renouvelés sans interruption, et les nouvelles versions des rapports doivent être fournies signées.

Comparaison des quatre catégories de preuves vérifiables publiquement

Liste de contrôle pour la vérification des références et des certificats lors de l'achat de SaaS

Contrevérifier les certificats dans le registre de l'organisme de certification

Un certificat ISO 27001 n'est pas délivré par l'organisation auditée : un organisme de certification accrédité réalise un audit externe et vérifie si le système de management de la sécurité de l'information (SMSI) satisfait aux exigences de la norme. L'émetteur et le titulaire du document sont deux parties distinctes ; l'organisme émetteur tient son propre registre de certificats. C'est là que s'effectue la contrevérification, et non du côté du fournisseur.

Six indications doivent être reprises du document : la dénomination juridique de l'entreprise certifiée (et non la désignation du produit ou de la marque), le numéro de certificat, la norme avec son année d'édition (par exemple ISO/IEC 27001:2022), l'organisme de certification émetteur, la durée de validité et le domaine d'application repris mot pour mot. Le domaine d'application détermine l'utilité du certificat : il mentionne les sites, les unités opérationnelles et les activités qui ont été auditées. Les certificats de groupe couvrent rarement chaque filiale et chaque service ; un certificat pour le développement et l'exploitation n'implique pas automatiquement que le centre de calcul qui vous concerne ou les sous-traitants utilisés y sont inclus.

Outre le domaine d'application, le cycle d'audit doit être vérifié. Les certificats ont une durée de validité et sont accompagnés, pendant cette période, d'audits de surveillance récurrents ; avant l'expiration, un audit de renouvellement est prévu. Demandez la date et le type du dernier audit et comparez-les avec la durée de validité. Si un certificat expire dans quelques mois et que la preuve de son renouvellement fait défaut, l'affirmation « certifié » n'est fiable que tant que le papier l'est.

Étapes pour la vérification des certificats dans le registre de l'organisme de certification

Contextualiser les certifications de protection des données selon le droit suisse

Depuis le 1er septembre 2023, la loi révisée sur la protection des données (LPD) ainsi que les nouvelles dispositions d'exécution dans l'ordonnance sur la protection des données (OPDo) et l'ordonnance sur les certifications en matière de protection des données (OCertDP) sont en vigueur ; aucun délai transitoire n'est prévu. La LPD révisée protège la personnalité et les droits fondamentaux des personnes physiques résidant en Suisse, dont les données sont traitées par des privés ou l'État ; les données des personnes morales ne sont plus protégées. Pour l'achat de SaaS, cela signifie : une certification de protection des données concerne les données personnelles de personnes physiques – les données d'entreprise que le même service traite également n'entrent pas dans ce cadre.

L'OCertDP définit le cadre des certifications de protection des données selon la LPD. Comme pour tout certificat, il est possible de vérifier l'organisme émetteur, son accréditation pour le domaine concerné, l'objet décrit dans le document – quels traitements et quelles parties de l'organisation ont été audités – ainsi que la durée de validité. Exigez le document et la désignation de l'organisme certificateur et insistez pour pouvoir consulter vous-même l'inscription.

La certification du fournisseur ne remplace pas l'examen de votre propre responsabilité. Quiconque, en tant que responsable du traitement, externalise des données personnelles auprès d'un fournisseur SaaS, reste responsable du traitement envers les personnes concernées ; ce sont les processus du fournisseur qui sont certifiés, et non l'utilisation du service par vous. L'achat implique donc également vos propres vérifications : quelles données personnelles arrivent dans le service et dans quelle mesure, quel mandat de traitement est convenu, où les données sont traitées et stockées, et comment elles sont récupérées et supprimées à la fin du contrat.

Bases légales pertinentes pour les certifications de protection des données en Suisse

Vérifier soi-même les rapports signés et les clés publiques

Les rapports de sécurité, les rapports de tests d'intrusion et les documents d'audit doivent être exigés sous forme de fichiers signés, et non de simples pièces jointes PDF. En Suisse, les fournisseurs de tests de sécurité font la promotion de rapports signés par PGP. La signature permet une contre-vérification sans avoir à interroger l'expéditeur : si elle est valide, le fichier est inchangé depuis son émission et provient du titulaire de la clé privée correspondante.

Le modèle de vérification que Transpareo décrit pour le passeport numérique de produit peut être transposé directement : l'émetteur publie son identifiant ou sa clé publique sur son propre domaine sous une adresse fixe (selon la norme W3C DID:web), la vérification s'effectue dans le navigateur de l'utilisateur sans contacter de serveur du fournisseur, et l'application d'affichage est open source, de sorte que le code de vérification peut être lu. La clé privée reste chez l'émetteur ; un deuxième émetteur ajoute tout au plus une contre-signature. Pour les achats, cela signifie : exigez l'adresse du dépôt de clés et vérifiez vous-même un fichier fourni.

Pas de chaîne de certificats classique volontairement : les chaînes de certificats expirent au fil des années, tandis qu'une adresse sur le propre domaine reste robuste. Quiconque conserve des preuves qui doivent rester vérifiables même après longtemps mise donc sur des adresses de clés durablement accessibles et non sur une chaîne dont la racine pourrait avoir expiré entre-temps. Si la signature ne se trouve pas sous forme de bloc au-dessus du document, mais au-dessus de chaque indication individuelle, les champs ajoutés ultérieurement restent également prouvables, sans qu'il soit nécessaire de resigner.

Il convient de régler contractuellement le lieu de publication de la clé publique et de son empreinte, l'obligation de fournir chaque rapport signé et – puisqu'une signature ne reste vérifiable que tant que la clé est trouvable – la conservation de la clé et du rapport dans vos propres archives.

Reconstituer les références à partir des données publiques de passation de marchés

Les références peuvent être retracées via les informations publiques sur les marchés publics, car les attributions et les contrats-cadres sont notifiés. L'approche méthodologique utilise trois horizons temporels simultanément : le passé (qui est le leader du marché ?), le présent (quels appels d'offres correspondent aujourd'hui ?) et le futur (quels contrats-cadres arrivent bientôt à expiration ?). Pour la vérification des fournisseurs, cela signifie : rechercher les notifications d'attribution avec le nom du fournisseur et saisir l'entité adjudicatrice, l'objet, la date et la durée, au lieu de se fier à la liste de références de la présentation.

Pour le calendrier, il vaut la peine de jeter un œil aux documents contractuels : un aperçu des marchés publics informatiques dans l'espace DACH mentionne pour l'Allemagne les contrats-cadres EVB-IT, pour l'Autriche les AVB-IT et pour la Suisse les CG Informatique avec leurs cycles de quatre ans ; il recommande d'utiliser ces durées comme instrument de planification. Qui sait quand un contrat-cadre expire sait aussi quand un fournisseur est à nouveau en concurrence et quand les références et les conditions peuvent être comparées à nouveau.

Un titulaire récurrent est la référence la plus éloquente et le signal d'alarme le plus clair à la fois. Un fournisseur qui est en place chez l'adjudicateur depuis des années connaît l'infrastructure et a déjà intégré son système ; celui qui soumissionne pour la première fois part de zéro. L'ordre des attributions et les durées des contrats-cadres permettent donc de lire où existent des dépendances, depuis combien de temps un adjudicateur est déjà lié et quand le marché s'ouvre pour une nouvelle attribution.

Durées des contrats-cadres dans l'espace DACH pour les marchés informatiques

Vérifier les preuves de raccordement et d'interopérabilité dans l'environnement fédéral

L'eIAM est le système central d'accès et d'autorisation de la Confédération ; l'AGOV en est une composante inhérente et occupe une position particulière, tandis que CH-LOGIN est en phase de retrait. La fiche technique pour les achats « Raccordement d'applications à l'eIAM » (version 1.7 du 9 octobre 2024) est accessible publiquement et sert de base pour les questions de raccordement. Elle traite du raccordement des applications à l'eIAM et doit être lue dans la version en vigueur au moment de l'achat.

Selon cette fiche technique, les applications web et les applications mobiles natives sont soumises à une obligation de raccordement à l'eIAM. Le raccordement peut se faire directement ou indirectement, plusieurs variantes de raccordement indirect existant ; la fiche technique distingue en outre les cas où les services du DFJP doivent être utilisés de ceux où le service eIAM est mis en œuvre. Avant d'accepter une promesse d'interopérabilité, faites-vous désigner par écrit la variante de raccordement choisie et la voie prévue, et vérifiez l'obligation de raccordement au regard de la fiche technique.

Cela peut être vérifié sans la participation du fournisseur : la fiche technique est disponible publiquement, tout comme les informations sur l'eIAM, l'AGOV et les fournisseurs d'identité dont l'eIAM tire les identités électroniques. Les questions posées au fournisseur portent ainsi sur des éléments prouvables – quelle variante de raccordement, sur la base de quelle version de la fiche technique, en accord avec quelle instance – et non sur de simples assurances générales d'interopérabilité.

Signaux d'alarme et limites de la vérification publique

Les signaux d'alarme découlent directement des sources publiques : un sceau sans inscription trouvable dans le registre ; un certificat dont le domaine d'application ne couvre pas le service exploité, le site ou les sous-traitants ; un certificat expiré sans preuve de renouvellement ; des clients de référence mentionnés sans notification d'attribution et sans date ; un rapport de sécurité en PDF sans signature.

Les questions qui en découlent s'adressent directement au fournisseur : numéro de certificat, organisme émetteur, domaine d'application repris mot pour mot, durée de validité, date et type du dernier audit ; adresse et empreinte de la clé publique ainsi que l'engagement de fournir chaque rapport signé ; entité adjudicatrice, objet du marché et date pour chaque référence mentionnée ; la variante de raccordement à l'eIAM choisie avec la version de la fiche technique. Quiconque n'obtient pas l'une de ces indications a déjà obtenu une réponse.

Les limites de la vérification publique sont tout aussi claires : seul ce qu'une tierce partie publie est traçable. Les constatations d'audit internes, la liste des sous-traitants, l'historique des incidents et l'état actuel d'une instance productive ne peuvent pas être vérifiés de cette manière ; pour cela, il faut des informations et des droits de vérification garantis contractuellement. Un certificat atteste d'un système de management fonctionnel, et non de la sécurité d'une configuration spécifique en exploitation.