Exigences du projet

Avant que l'intégration d'une application dans le service eIAM puisse avoir lieu, une série de directives et d'autres exigences formelles doivent être respectées. En principe, le service eIAM donne des directives pour l'intégration des applications. Le dossier eIAM contient différents éléments pour la saisie des informations. La structuration doit aider à saisir les informations sur le déroulement du projet de manière plus simple et plus compréhensible en fonction de l'avancement. Le déroulement graphique du projet eIAM et le dossier eIAM doivent vous aider à impliquer correctement vos parties prenantes.

Responsabilités eIAM <=> Application

La figure ci-dessous montre schématiquement dans quel domaine eIAM et dans quel domaine le projet a la responsabilité organisationnelle. La figure montre respectivement une application web dans les réseaux de l'administration fédérale et une application en dehors des réseaux de l'administration fédérale.

: Responsabilités eIAM <=> Appliaktion

Le chef de projet de l'OFIT, en collaboration avec ses parties prenantes (Stakeholder), est responsable des tâches suivantes:

La commande de load balancer ainsi que des enregistrements DNS et autres définitions d'infrastructure pour la communication entre eIAM-Web PEP et l'application.
La commande de règles de pare-feu pour la communication entre eIAM PEP et l'équilibreur de charge avant l'application, si le port TCP standard 443 n'est pas utilisé sur l'équilibreur de charge. Si une ouverture de pare-feu correspondante doit être demandée par le responsable de l'application, la liste des adresses IP source des PEP peut être demandée au SIE responsable d'eIAM.
Toute la zone verte de la figure est sous la responsabilité du client.

Exigences relatives aux environnements système

Le service eIAM dispose de trois environnements d'exploitation (Stages/Instance). L'environnement de référence ou d'intégration (REF), l'environnement de réception ou de pré-production (ABN) et l'environnement de production (PROD). Ces trois environnements sont isolés et indépendants les uns des autres.

Les intégrations avec eIAM se font en principe toujours et exclusivement dans l'environnement de référence. Une intégration directe d'une application dans l'environnement de réception ou de production n'est pas possible. Après validation par le client, l'environnement de référence est transporté (staging) vers l'environnement de réception d'eIAM, puis vers l'environnement de production dans le cadre du Customer-Change-Plan (CC-Plan).

Si un autre environnement d'exploitation (en plus de REF, ABN, PROD) doit être intégré à eIAM pour la même application, celui-ci est traité comme une application supplémentaire du point de vue d'eIAM. Comme eIAM ne peut pas mettre à disposition un environnement supplémentaire, une intégration supplémentaire doit avoir lieu dans l'environnement de référence et le staging doit ensuite être effectué dans l'environnement de réception.

Confirmer la conformité avec OIAM

Cas: exploitation de l'application dans le réseau administratif fédéral.
Les exigences en matière de sécurité de l'information sont respectées conformément à l'OIMA .
Cas: exploitation de l'application dans un réseau externe.
Pour le respect de l'OIMP art. 17 . En cas de communication de données personnelles à un opérateur externe (solutions IaaS, PaaS, SaaS Cloud), le client doit demander la fédération eIAM vers l'extérieur, au moyen du formulaire de demande intégré dans le dossier eIAM, signé numériquement par le DSIO et à télécharger en format PDF dans le dossier eIAM.

Concept d'autorisation de l'utilisateur

Il est également de la responsabilité du projet d'élaborer un concept d'autorisation des utilisateurs sur la base des présents documents.

Sécurité

L'OFIT est responsable de la sécurité de la plateforme eIAM. Le projet et le responsable de l'application sont responsables de la sécurité de l'application métier.
Dans le cadre de la gestion des correctifs et des versions, l'OFIT s'assure que la plateforme eIAM est à tout moment à la pointe de la technologie. Pour ce faire, il introduit régulièrement des patchs de sécurité et de nouvelles versions de composants logiciels dans le système d'exploitation ainsi que dans le middleware. Le client est informé à l'avance de l'application de ces correctifs et versions (sauf en cas de correctifs d'urgence), afin qu'il puisse éventuellement adapter son application. La responsabilité de ces travaux incombe exclusivement au client.

Besoin de protection

Le projet est responsable de la classification correcte du besoin de protection de l'application, respectivement de ses données. Il doit déterminer le besoin de protection par une analyse des besoins de protection (SchuBAn). Si l'analyse des risques indique un besoin de protection élevé, l'application doit être protégée par une authentification à deux facteurs basée sur l'eIAM.

Niveaux de protection

Dans le présent contexte, les niveaux de protection (SN) désignent une classification, réglementée par des directives de la ChF TNI, des exigences en matière de sécurité du traitement des données par rapport au besoin de protection des données traitées. Les données dans eIAM (informations dans les comptes d'utilisateurs) ont un SN1. Les applications protégées par eIAM peuvent avoir le SN2 si ce niveau de protection ne résulte pas de l'Ordonnance sur la protection des informations (OPrI, ) (sauf si seuls des chiffres (Chiff-retext) sont transmis, car ceux-ci n'ont par définition que le SN1). En d'autres termes: Si le SN2 résulte de la loi sur la protection des données (LPD, ), l'application métier concernée peut obtenir des prestations d'authentification auprès de l'eIAM, mais il ne faut pas utiliser d'identités électroniques faibles et la protection des données doit être assurée par l'application. De manière générale, il convient de noter que les prestations IAM ne peuvent pas garantir la confidentialité des données, mais uniquement l'authentification et, le cas échéant, l'autorisation de certaines données fiables et traçables. La confidentialité doit être obtenue par des mesures au niveau des données, en général la cryptographie, indépendamment de la gestion des identités et des accès.

Concept SIPD

Le projet est responsable de l'élaboration d'un concept ISDS (protection des données de l'information) si les résultats de l'analyse des besoins de protection l'exigent. Ce concept doit être disponible au plus tard avant le transfert d'une solution dans l'environnement d'acceptation de l'OFIT.

Déclaration de conformité de l'architecture

Le projet est responsable de l'établissement d'une déclaration de conformité architecturale. Celle-ci doit être disponible au plus tard avant le transfert d'une application dans l'environnement d'acceptation.

Alimentation eIAM de solutions cloud

L'alimentation d'applications dans AWS et Azure et d'autres clouds est pratiquée avec succès. Les SaaS et autres modèles de cloud sont aussi soumis à l'obligation d'achat.