MISE EN SERVICE · SÉCURITÉ INITIALE

Liste de contrôle pour une première mise en service sécurisée

La première configuration détermine si les contrôles de sécurité protègent vos serveurs sans interrompre l’administration légitime. Suivez la liste de contrôle dans l’ordre, conservez une voie d’accès de secours et validez chaque modification depuis une session distincte.

N’activez pas la MFA ni la politique de pare-feu sans accès de secours.

Conservez un accès indépendant par console, hyperviseur, iLO/iDRAC, VPN ou compte administrateur d’urgence (break-glass). Ne placez pas l’unique compte de secours derrière une dépendance MFA non testée.

Pourquoi cette séquence compte

Lira contrôle les opérations sensibles : accès RDP, politique MFA, Pare-feu Windows, Defender, certificats, utilisateurs locaux et mises à jour. La console de gestion doit donc être protégée comme un système administratif et non comme un site web ordinaire.

Une configuration par étapes réduit le risque de verrouillage. Chaque exception devrait être explicite, limitée dans le temps, documentée et revue après le déploiement initial.

Directives de sécurité

L’accès peut-il être restauré depuis la console Lira ?

Oui, tant qu’au moins un canal d’administration indépendant reste disponible.

1. Protégez d'abord la console de gestion

  1. Utilisez un compte administrateur nominatif avec un mot de passe unique ; ne partagez pas les identifiants du portail entre opérateurs.
  2. Activer MFA pour la console de gestion Lira elle-même. Ne créez pas d'exception pour la console : elle contrôle vos serveurs et, si compromis, peut modifier les règles du pare-feu, les utilisateurs, les certificats, le Defender et la politique RDP.
  3. Examinez les sessions actives et déconnectez-vous des navigateurs ou des appareils qui ne sont plus gérés.
  4. N’accordez aux opérateurs que les droits nécessaires sur l’espace de travail et les serveurs concernés ; réservez l’administration globale de la plateforme à un petit groupe dont les actions sont auditées.

2. Ajoutez une adresse de confiance avant de tester les blocs

Ajoutez à la liste d’autorisation Lira l’adresse publique fixe utilisée par vos administrateurs, la sortie du VPN d’administration ou l’hôte de rebond sécurisé avant de tester le blocage automatique. Vous éviterez ainsi qu’une erreur temporaire de mot de passe bloque l’unique voie d’administration légitime.

Une liste d’autorisation ne remplace ni la MFA ni des mots de passe robustes. Limitez son périmètre, documentez chaque entrée, supprimez les adresses qui ne sont plus maîtrisées et réexaminez-la après toute modification du réseau.

  • Confirmez l'adresse du même réseau qui sera utilisé pour l'administration.
  • Ajouter l'adresse dans le portail et vérifier qu'elle apparaît dans la liste de confiance.
  • Si l'adresse est dynamique, préférez un VPN contrôlé ou un hôte de saut avec une adresse d'évacuation stable.

3. Préparez les demandes d'authentification

  1. Installez un authentificateur TOTP basé sur des normes telles que Microsoft Authenticator, Google Authenticator, 1Mot de passe, Bitwarden, ou une autre application approuvée par l'organisation.
  2. Inscrivez MFA à partir de la page de sécurité du compte Lira et stockez les codes de récupération dans un gestionnaire de mot de passe approuvé ou un enregistrement d'urgence hors ligne.
  3. Gardez un deuxième appareil d'authentification contrôlé pour la récupération ; ne photographiez pas les secrets ou les placer dans un chat partagé.
  4. Vérifier le code actuellement affiché avant d’appliquer la MFA à un serveur Windows.

4. Installez et validez le premier agent

Installez l’agent Lira Windows à l’aide de la clé d’enrôlement propre à l’espace de travail, générée après la création du compte. L’agent communique par HTTPS ; aucun port de gestion entrant n’est requis sur l’hôte RDP.

Attendez le premier signal de présence et validez le nom d'hôte, l'adresse, la version du système d'exploitation et la version actuelle de l'agent. Résoudre les noms en double ou les données d'identité incorrectes avant d'envoyer les commandes.

  • Installez d'abord sur un serveur pilote.
  • Confirmez dans le portail les événements, l’état du pare-feu, l’état de Microsoft Defender et la synchronisation de l’heure.
  • Gardez la session RDP existante ouverte tout en testant une nouvelle session.

5. Activer MFA dans un pilote contrôlé

  1. Choisissez un utilisateur pilote nommé et un serveur non critique.
  2. Inscrivez l'utilisateur, vérifiez un code actuel et n'autorisez l'application que pour le pilote.
  3. Ouvrez une nouvelle connexion RDP à partir d'un client séparé ; testez le mot de passe et MFA comme une séquence complète.
  4. Déconnectez-vous, puis répétez le test afin qu’une session mise en cache ne masque pas un problème.
  5. Élargir par petits groupes seulement après le pilote, les journaux d'événements, le compte de récupération et la connectivité des agents sont confirmés.

6. Configurer les certificats et la maintenance

Utilisez un certificat dont le nom alternatif du sujet correspond exactement au nom DNS utilisé par les clients RDP. Maintenir la délégation ACME DNS permanente lorsque le renouvellement automatisé est activé. Consultez le guide détaillé du certificat avant le déploiement.

Planifiez les mises à jour Windows, les analyses de Defender, les modifications de pare-feu et les renouvellements de certificat dans les fenêtres de maintenance. Enregistrez le comportement attendu de redémarrage et de retour avant d'appliquer une politique à plusieurs serveurs.

  • Testez le certificat depuis un client indépendant.
  • Gardez le chemin précédent de reliure et de récupération de console enregistré.
  • Appliquez les modifications à un serveur pilote avant de les déployer sur l’ensemble du parc.

7. Exploiter et réviser

  • Examinez les connexions réussies et échouées, les blocages actifs, les signaux de présence des agents, les décisions de MFA et les entrées du journal d’audit.
  • Supprimer les entrées d'autorisation temporaire et les exceptions de MFA après le déploiement.
  • Renouvelez les identifiants et les éléments de récupération lorsqu’un opérateur quitte l’organisation ou qu’un appareil est perdu.
  • Répéter l'essai de récupération périodiquement et après les changements majeurs de réseau, de certificat ou d'agent.

Questions communes

Pourquoi MFA doit aussi protéger la console ?

La console peut modifier les contrôles qui protègent chaque serveur. En l'excluant, le chemin administratif le plus à impact élevé ne peut être protégé que par un mot de passe et peut permettre à un attaquant de désactiver ou d'affaiblir les contrôles du serveur.

Dois-je autoriser l'adresse de ma résidence ?

Seulement si c'est une voie d'administration contrôlée. Un VPN stable ou un hôte de saut est préférable. N'autorisez jamais la liste d'une adresse que vous ne pouvez identifier ou protéger de façon fiable.

Quel authentificateur choisir ?

Utilisez une application TOTP approuvée, avec sauvegardes chiffrées ou récupération contrôlée. Choisissez une solution que les opérateurs peuvent utiliser de manière fiable et qui respecte votre procédure de récupération des comptes.

Que faire si le lien ou le code MFA n'est plus valide ?

Ne multipliez pas les tentatives. Suivez la procédure de récupération documentée, vérifiez l’heure du serveur et de l’appareil, créez si nécessaire un nouvel enrôlement ou un nouveau code, puis consignez l’incident dans le journal d’audit.

Commencez par un serveur protégé et récupérable

Enregistrez votre organisation, sécurisez la console, ajoutez votre chemin d'administration de confiance, inscrivez MFA et validez le premier agent avant d'élargir la politique.

Ouvrez la console Lira