Fil d'Ariane

Accès aux systèmes tiers

Introduction

Le présent document décrit le niveau d'accès dont Identum a besoin aux systèmes des clients pendant et après la mise en œuvre d'un projet. Notre politique consiste à utiliser un accès temporaire avec le minimum de droits nécessaires pour mener à bien les tâches requises. Identum n'a pas besoin d'un accès permanent aux environnements des clients.


1. Systèmes sources

Identum n'a pas besoin d'un accès permanent aux systèmes sources tels que les systèmes de gestion des ressources humaines et de paie, les systèmes d'information sur les étudiants ou d'autres bases de données relatives au personnel. L'accès aux données exportées depuis ces systèmes, que ce soit par transfert de fichiers ou via une API, est suffisant.

Remarque : sur demande, nous pouvons être amenés à solliciter un accès temporaire pour des tâches spécifiques telles que le dépannage ou la formation.


2. Dataporten / Portail client Feide

Nous n'exigeons pas d'accès permanent à Dataporten ni au portail client Sikt (anciennement Uninett). Un accès temporaire peut être accordé sur demande si nécessaire.


3. Microsoft Azure Active Directory (Azure AD)

Si nos services (eADM/eFeide) doivent synchroniser les utilisateurs, les groupes, les mots de passe, les licences, les affiliations et les statuts avec Azure AD, nous avons besoin d'un compte disposant de droits équivalents à ceux d'un « administrateur d'utilisateurs » dans Microsoft 365.

  • Cet accès n'est nécessaire que pour la durée du projet.

  • Le compte doit être protégé par une authentification à plusieurs facteurs (MFA).

  • Le compte doit être désactivé ou supprimé une fois le projet terminé.

Remarque : la communication permanente entre eADM/eFeide et Azure AD est gérée via une application d'entreprise Azure, et non via un compte utilisateur. Pour plus de détails sur la configuration, consultez notre documentation : Comment configurer Azure AD pour l'intégration.


4. Google Workspace

Pour que nos services puissent synchroniser les utilisateurs, les groupes, les mots de passe, les unités organisationnelles (OU), les appartenances et les statuts avec Google Workspace, nous avons besoin d'un compte utilisateur disposant de droits équivalents à ceux d'un administrateur de gestion des utilisateurs.

  • Ce compte doit être protégé par une authentification à plusieurs facteurs (MFA).

  • Le compte peut être désactivé une fois le projet terminé.

De plus, l'administrateur global du client devra configurer des clés d'accès pour notre client API.


5. Active Directory (AD) sur site

Pour l'intégration à Active Directory sur site, une application cliente est installée sur le réseau interne du client. eADM ne nécessite pas de serveur dédié. Nous déconseillons d'installer l'application cliente eADM sur un contrôleur de domaine.


Communication avec les clients

  • Le client est une application console .NET sous Windows qui s'exécute en tant que tâche planifiée à l'aide d'un compte de service.

  • La communication avec notre solution cloud est initiée par le client via une connexion chiffrée (TLS 1.2 ou version supérieure sur le port 443 en sortie). Aucune ouverture de pare-feu en entrée n'est nécessaire.

  • Chaque client utilise des clés d'authentification uniques pour communiquer avec le service cloud.


Accès des consultants (pendant le projet)

Au cours du projet, le chef de projet et/ou le consultant aura besoin d'un accès à distance à l'environnement Active Directory sur site via un VPN ou TeamViewer.

  • Cet accès doit être protégé par une authentification à plusieurs facteurs (MFA).

  • L'accès peut se faire via un contrôleur de domaine principal, mais nous recommandons d'utiliser un serveur dédié pour le client eADM.

  • Le serveur doit avoir accès à :

    • Utilisateurs et ordinateurs d'Active Directory

    • Module Active Directory pour Windows PowerShell

    • Outils de gestion de Windows Exchange pour PowerShell (le cas échéant)


Configuration requise pour le serveur

  • Système d'exploitation : Windows Server

  • .NET Framework : version 4.0 ou ultérieure

  • PowerShell : version 4.0 ou ultérieure

  • Pare-feu : le port 443 doit être ouvert pour le trafic SSL sortant.

  • Logiciel : veuillez vous assurer que Notepad++ est bien installé sur le serveur.


Autorisations du compte de service

Un compte de service dédié est nécessaire pour exécuter le client eADM. Ce compte doit disposer des autorisations suivantes :

  • Droits AD : Créer, supprimer et modifier des utilisateurs, des groupes et des unités d'organisation.

  • Droits locaux :

    • Se connecter en tant que tâche batch (pour les tâches planifiées).

    • Accès complet en lecture et en écriture à C:\eADM\ et ses sous-dossiers.

  • Droits facultatifs (le cas échéant) :

    • Créer et définir les autorisations NTFS pour les dossiers personnels des utilisateurs.

    • Créer des boîtes aux lettres (enable-mailbox et enable-remotemailbox).

Avertissement : une fois le système mis en production, nos comptes utilisateurs personnels devront être désactivés. Toutes les tâches opérationnelles seront effectuées par le compte de service, et son mot de passe devra être modifié afin qu'Identum n'y ait plus accès.

La présente procédure opérationnelle standard (SOP) définit les autorisations d'accès requises par Identum pour les systèmes tiers des clients, tels qu'Azure AD, Google Workspace et Active Directory sur site. Elle souligne que l'accès est temporaire, limité à la durée du projet, et qu'il respecte le principe du moindre privilège. Ce document détaille les exigences relatives aux comptes de service, à l'accès des consultants, à la configuration des serveurs et aux protocoles de sécurité, notamment l'utilisation obligatoire de l'authentification multifactorielle (MFA) et la désactivation des comptes à l'issue du projet.

Dernière mise à jour :