FAQ de l'offre : Moyens d'identification électroniques

Non. Nous ne relisons jamais le code comme preuve.
Un extrait de code n’est pas considéré comme une preuve de conformité.
La preuve doit être apportée via :
•    le document de conformité,
•    les schémas,
•    la configuration,
•    les traces,
•    les flux,
•    les résultats de tests. 

Dans le cas où votre proxy utilise un jeton dont il n'est pas à l'origine, par exemple : reçu par un autre proxy de l'EDC PSC, vous vous apprêtez à utiliser un jeton PSC alors que vous n'êtes pas à l’origine de l’authentification dont il est issu. Par conséquent :
•    une introspection du jeton PSC par le proxy est obligatoire,
•    une traçabilité dédiée par le proxy doit être réalisée,
•    et l’usage par le proxy doit être correct vis à vis des rôles FS / Proxy dans l’Espace de Confiance.

Oui. Vous listez toutes les RFC utilisées, en les associant à :
•    leur périmètre,
•    le composant ou le service qui les met en œuvre,
•    et l’usage effectif dans le produit. 

Vous devez détailler tous les flux, y compris internes et systèmes, par type :
•    SSH
•    LDAP
•    SMB
•    HTTP / HTTPS
•    Administration
•    Mise à jour
•    Méta-services internes

Chaque flux doit être associé au composant qui le consomme 

Nous vous conseillons de privilégier un document interne avec un renvoi clair et précis dans le modèle de preuve fourni par l'ANS. L’objectif est :
•    d’éviter les duplications,
•    d’aligner tous les acteurs,
•    et de centraliser l’information dans un document de votre gestion projet interne. 

Attention ne faites jamais référence à d'autres preuves au sein d'une même preuve.

Si une méthode cryptographique propriétaire est utilisée, vous devez :
•    la décrire explicitement,
•    démontrer qu’elle est conforme aux exigences ANSSI,
•    fournir des preuves dans les documents dédiés (analyse, tests, conformité),
•    éviter toute zone grise dans la compréhension du mécanisme.

Vous décrivez avec précision :
•    tout ce qui est attendu de l’Opérateur (installation, configuration, supervision…),
•    comment ces informations lui sont transmises (document installation, guide opérateur, fichier de configuration, etc.).

Même si vous êtes à la fois éditeur et opérateur dans la même structure, les rôles doivent être clairement séparés car les équipes internes d’installation ne sont pas les développeurs. 

Oui.

Vous listez tous les composants, qu’ils soient :
•    obligatoires,
•    optionnels,
•    tiers,
•    embarqués,
•    ou dépendances internes.
Chaque composant doit être accompagné d’une description, d’une version, et de son usage dans le système. 

Nous considérons que le déroulé théorique éditeur a déjà été couvert dans le Bac à Sable.

Ce qui doit apparaître dans la documentation, sont :
•    les mécanismes concrets de génération de l’identifiant de corrélation,
•    le processus réel de gestion des traces,
•    le déroulement théorique de l’authentification tel que mis en œuvre,
•    les types de contrôles ,
•    les liens de test, même si ceux-ci ne sont pas évalués en tant que tels. 

Ces textes sont des guides. Ils servent à contextualiser et orienter sans imposer.