PASSI - Prestataire d'Audit de la Sécurité des Systèmes d'Information
PASSI est une qualification délivrée par l'ANSSI (Agence nationale de la sécurité des systèmes d'information) aux prestataires habilités à réaliser des audits de sécurité pour le compte d'administrations et d'opérateurs critiques français. La qualification couvre cinq portées d'audit : architecture, configuration, code source, test d'intrusion et organisationnel/physique. Elle est référencée par le Référentiel d'Exigences PASSI publié par l'ANSSI, mis à jour périodiquement.
Pour un acheteur public ou un OIV, exiger un audit PASSI sur la solution retenue est une mesure courante de diligence. La liste officielle des prestataires qualifiés est publiée sur le site de l'ANSSI à l'adresse cyber.gouv.fr.
SecNumCloud - Qualification ANSSI pour hébergeurs souverains
SecNumCloud est la qualification française de référence pour les fournisseurs d'informatique en nuage souverains. Le référentiel exige une indépendance vis-à-vis du droit extra-européen (notamment CLOUD Act et FISA Section 702), une localisation physique des données et des opérations sur le territoire de l'Union européenne, et des mesures techniques renforcées en matière de chiffrement, d'audit et de continuité d'activité.
Le référentiel SecNumCloud 3.2 est publié par l'ANSSI. Sa qualification est obligatoire pour héberger des données sensibles d'État au sens du Référentiel Général de Sécurité. ARDNTECH sélectionne ses sous-traitants d'hébergement parmi les acteurs alignés sur ce référentiel.
HMAC-SHA-256 - Hash-based Message Authentication Code
HMAC est un mécanisme de calcul d'un code d'authentification de message à partir d'une fonction de hachage cryptographique et d'une clé secrète, défini par la RFC 2104 (IETF, 1997). Sa déclinaison HMAC-SHA-256 utilise la fonction SHA-256 normalisée par le NIST dans FIPS 180-4 et fournit un MAC de 256 bits. En pratique, HMAC-SHA-256 sert à garantir l'intégrité et l'authenticité d'un message sans révéler la clé.
Le chaînage de HMAC (où le HMAC d'un événement inclut le HMAC du précédent) construit une audit chain immuable : toute modification rétroactive d'un événement casse la chaîne et devient détectable. ARDNTECH utilise HMAC-SHA-256 chaîné pour son journal d'audit, vérifiable par une commande CLI publique.
Argon2id - Dérivation de clé moderne
Argon2 est l'algorithme de dérivation de clé vainqueur du Password Hashing Competition (2015), normalisé par la RFC 9106 (IETF, 2021). Argon2id, sa variante hybride, combine la résistance aux attaques par canaux auxiliaires d'Argon2i et la résistance aux attaques par compromis temps-mémoire d'Argon2d. Il prend trois paramètres : coût mémoire, coût temps et parallélisme.
La RFC 9106 recommande pour un usage interactif un coût mémoire de 64 MiB minimum, 3 itérations et 1 voie de parallélisme. Pour les usages serveur à plus forte intensité, elle recommande 256 MiB ou plus. ARDNTECH implémente Argon2id avec 256 MiB de mémoire, conforme aux recommandations RFC 9106.
Zero-knowledge - Architecture sans accès en clair
On qualifie de zero-knowledge une architecture dans laquelle le serveur ne dispose, par construction cryptographique, d'aucun moyen technique de lire les données utilisateur en clair. Le chiffrement et le déchiffrement s'effectuent intégralement côté client avec une clé dérivée de la phrase de passe utilisateur, jamais transmise au serveur.
La conséquence opérationnelle est qu'un attaquant compromettant le serveur (ou l'éditeur lui-même, contraint par une réquisition légale) n'a accès qu'à des blobs chiffrés inexploitables sans la clé du titulaire. La contrepartie est l'impossibilité pour l'éditeur de récupérer un mot de passe oublié : le mécanisme de reset détruit nécessairement le coffre précédent.
OpenPGP - Standard de chiffrement asymétrique
OpenPGP est le standard ouvert de chiffrement et de signature de messages, dérivé de l'outil Pretty Good Privacy. Sa spécification courante est la RFC 9580 (IETF, juillet 2024), qui remplace la RFC 4880. OpenPGP combine du chiffrement symétrique pour le contenu (AES-256-GCM, ChaCha20-Poly1305) et asymétrique pour l'échange de clés (RSA, X25519, Ed25519).
Dans un coffre-fort B2B, OpenPGP permet de chiffrer un secret pour plusieurs destinataires sans réencodage central : chaque utilisateur dispose de sa propre paire de clés, et le partage consiste à ré-encoder la clé symétrique de session pour la clé publique du nouveau destinataire. ARDNTECH utilise OpenPGP RFC 9580 côté client pour le partage de secrets entre utilisateurs d'une même organisation.
X25519 / Ed25519 - Courbes elliptiques modernes
X25519 est un algorithme d'échange de clés Diffie-Hellman sur la courbe Curve25519, défini par la RFC 7748 (IETF, 2016). Ed25519 est l'algorithme de signature associé, défini par la RFC 8032. Conçus par Daniel J. Bernstein et son équipe, ces algorithmes offrent un niveau de sécurité équivalent à une clé RSA de 3072 bits avec une empreinte mémoire et CPU bien moindre.
Leur adoption est désormais large : TLS 1.3, SSH, Signal, WireGuard, et OpenPGP depuis la RFC 9580. Les courbes Edwards évitent les écueils d'implémentation courants des courbes NIST historiques (P-256, P-384) en rendant les attaques par canaux auxiliaires plus difficiles à monter.
AES-256-GCM - Chiffrement symétrique authentifié
AES-256-GCM est le couple Advanced Encryption Standard en mode Galois/Counter Mode, avec une clé de 256 bits. Le mode GCM est normalisé par le NIST dans NIST SP 800-38D et fournit à la fois la confidentialité (par chiffrement en mode compteur) et l'authentification (par un MAC issu d'une multiplication dans GF(2¹²⁸)).
Sa large diffusion s'explique par sa performance matérielle (instructions AES-NI et CLMUL des processeurs x86_64 et ARMv8) et sa résistance éprouvée. Il reste sensible à la réutilisation d'IV, qui doit être aléatoire ou strictement séquentielle. AES-256-GCM est la primitive symétrique par défaut d'OpenPGP RFC 9580 et de TLS 1.3.
CLOUD Act - Extraterritorialité américaine 2018
Le Clarifying Lawful Overseas Use of Data Act est une loi fédérale américaine promulguée le 23 mars 2018. Elle autorise les autorités américaines à requérir d'un opérateur soumis au droit américain la communication de données utilisateur, indépendamment de leur localisation physique de stockage. Le texte intégral est publié sur congress.gov.
Une société américaine, ou la filiale européenne d'une société américaine, reste soumise au CLOUD Act même si ses serveurs sont physiquement implantés dans l'Union. C'est ce critère structurel qui distingue un éditeur réellement souverain d'un éditeur dont la maison-mère relève du droit américain.
FISA Section 702 - Surveillance des étrangers
La Foreign Intelligence Surveillance Act, dans sa Section 702 ajoutée en 2008, autorise la collecte de renseignements électroniques par les agences américaines (NSA, FBI) sur des personnes non américaines situées hors du territoire des États-Unis, avec la coopération obligatoire des opérateurs de communications électroniques américains.
La CJUE a jugé en 2020 (arrêt Schrems II) que ce régime, sans mécanisme de recours effectif pour les personnes ciblées en UE, est incompatible avec les garanties fondamentales du droit européen. C'est l'un des motifs récurrents pour lesquels les RSSI européens écartent les opérateurs soumis au droit américain.
Schrems II - Arrêt CJUE C-311/18 (2020)
L'arrêt Data Protection Commissioner contre Facebook Ireland et Maximilian Schrems, rendu le 16 juillet 2020 par la Cour de justice de l'Union européenne, a invalidé la décision d'adéquation Privacy Shield encadrant les transferts de données personnelles entre l'UE et les États-Unis.
Depuis Schrems II, tout transfert vers un pays tiers reposant sur les Clauses Contractuelles Types doit être précédé d'une analyse d'impact de transfert (Transfer Impact Assessment) documentant l'absence de risque de surveillance étrangère. Pour les DPO, choisir un éditeur strictement européen évite cette procédure et le risque réglementaire associé.
RGPD Art. 28 - Sous-traitance des données
L'article 28 du règlement (UE) 2016/679 encadre la relation entre le responsable de traitement et le sous-traitant. Il impose la conclusion d'un contrat écrit fixant l'objet et la durée du traitement, sa nature et sa finalité, le type de données et les catégories de personnes concernées, ainsi que les obligations et droits du responsable.
En pratique, tout éditeur SaaS est sous-traitant au sens de l'Art. 28 dès lors qu'il traite des données personnelles pour le compte de ses clients. ARDNTECH fournit un DPA (Data Processing Agreement) standardisé inclus dans le plan Business et négociable en Enterprise.
RGPD Art. 32 - Sécurité du traitement
L'article 32 du règlement (UE) 2016/679 impose au responsable de traitement et au sous-traitant de mettre en oeuvre des mesures techniques et organisationnelles appropriées pour assurer un niveau de sécurité adapté au risque. Les mesures citées explicitement incluent le chiffrement des données, la capacité à assurer la confidentialité, l'intégrité, la disponibilité et la résilience des systèmes.
L'évaluation du caractère approprié des mesures doit tenir compte de l'état des connaissances, des coûts de mise en oeuvre et de la nature, de la portée et des finalités du traitement. Pour un coffre-fort de secrets B2B, un chiffrement E2EE avec des algorithmes récents (AES-256-GCM, Argon2id RFC 9106) satisfait typiquement cette exigence.
DPA - Data Processing Agreement
Un DPA (Data Processing Agreement), ou accord de traitement des données, est le contrat imposé par l'article 28 du RGPD entre un responsable de traitement et son sous-traitant. Il précise les finalités du traitement, les catégories de données concernées, la durée de conservation, les mesures de sécurité appliquées et les conditions de sous-traitance ultérieure.
Pour un acheteur B2B soumis au RGPD, exiger un DPA signé avant tout déploiement d'un outil SaaS traitant des données personnelles est une obligation légale, pas une option. ARDNTECH fournit un DPA standardisé inclus dans le plan Business, et un DPA négocié en Enterprise.
DPO - Délégué à la Protection des Données
Le Délégué à la Protection des Données (DPO) est la fonction créée par l'article 37 du RGPD. Sa désignation est obligatoire pour les autorités et organismes publics, les organismes dont l'activité principale exige un suivi régulier et systématique de personnes à grande échelle, et les organismes traitant à grande échelle des catégories particulières de données (santé, données biométriques, etc.).
Le DPO conseille sur la conformité RGPD, supervise les analyses d'impact (DPIA), coopère avec la CNIL et sert de point de contact pour les personnes concernées. Dans le cadre d'une évaluation d'un coffre-fort de secrets, le DPO valide notamment le DPA et l'analyse de transfert hors UE si applicable.
NIS2 - Directive européenne sur la cybersécurité
La directive (UE) 2022/2555, dite NIS2 (Network and Information Security), remplace la directive NIS de 2016 et étend significativement le périmètre des opérateurs soumis à des obligations de cybersécurité. Elle couvre désormais les entités essentielles et importantes dans des secteurs élargis (énergie, transport, santé, infrastructure numérique, services gérés, etc.).
NIS2 impose des mesures de gestion des risques, une notification des incidents sous 24 heures (alerte initiale) et 72 heures (rapport complet), et des obligations de sécurité de la chaîne d'approvisionnement. Sa transposition en droit français est en cours. Pour les OIV et OSE, NIS2 renforce les exigences qui existaient sous LPM et NIS1.
OIV - Opérateur d'Importance Vitale
Un Opérateur d'Importance Vitale (OIV) est une organisation publique ou privée dont l'activité est jugée indispensable au bon fonctionnement de la Nation française, désignée confidentiellement par arrêté du Premier ministre. Les OIV sont soumis aux dispositions de la loi de Programmation Militaire (LPM) en matière de cybersécurité.
Les obligations des OIV incluent la déclaration des systèmes d'information critiques (SIC) à l'ANSSI, le respect de règles de sécurité définies par arrêté sectoriel, et la notification des incidents de sécurité. Pour un éditeur SaaS, être référençable par un OIV implique de satisfaire des exigences de qualification (SecNumCloud) et de répondre à des audits PASSI.
TOTP - Time-based One-Time Password
TOTP (Time-based One-Time Password) est un algorithme de génération de mots de passe à usage unique basé sur l'heure courante, défini par la RFC 6238 (IETF, 2011). Il combine un secret partagé (TOTP seed) et un compteur de temps (tranches de 30 secondes par défaut) via la fonction HMAC-SHA-1 pour produire un code numérique de 6 chiffres.
TOTP est le mécanisme de second facteur le plus répandu dans les applications d'entreprise. Il est supporté par toutes les applications d'authentification standard (Google Authenticator, Aegis, etc.) et par ARDNTECH. La RFC 6238 est lisible publiquement sur tools.ietf.org.
WebAuthn / Passkey - Authentification sans mot de passe
WebAuthn (Web Authentication API) est un standard W3C permettant aux applications web de s'authentifier auprès d'un utilisateur à l'aide d'un authentificateur FIDO2 (clé matérielle, empreinte digitale, reconnaissance faciale). La spécification est publiée sur w3.org/TR/webauthn-3/ . Les Passkeys sont une implémentation grand public de WebAuthn où la paire de clés est synchronisée entre appareils via un gestionnaire de clés (iCloud Keychain, Google Password Manager).
Du point de vue de la sécurité, WebAuthn résiste nativement au phishing (la clé est liée à l'origine du domaine) et aux attaques par rejeu. Pour un coffre-fort de secrets B2B, l'activation de WebAuthn pour le déverrouillage supprime le vecteur de compromission le plus fréquent en entreprise : le vol de mot de passe maître par phishing. ARDNTECH supporte WebAuthn / Passkeys sur tous les plans.
AGPL-3.0 - Licence open source copyleft réseau
La GNU Affero General Public License version 3 (AGPL-3.0) est une licence de logiciel libre publiée par la Free Software Foundation. Elle exige que tout déploiement réseau d'un logiciel couvert par cette licence rende disponible le code source correspondant aux utilisateurs qui y accèdent, y compris via un service web.
Pour ARDNTECH, publier sous AGPL-3.0 signifie que toute organisation déployant une instance d'ARDNTECH modifiée doit publier ses modifications. C'est une garantie structurelle pour les clients : si ARDNTECH cessait d'exister, le code resterait accessible et maintenable par la communauté. L'audit du code cryptographique est possible pour n'importe quel RSSI ou auditeur PASSI sans accès spécial.
