Configurer l’organisation

Préparez la console pour votre organisation : le compte, l’authentification unique, les utilisateurs et leurs rôles, la recherche des propriétaires, la conservation et les notifications, et l’identifiant avec lequel le client s’inscrit. Tout se passe dans le navigateur, prend environ une demi-heure et ne touche aucune machine. L’installation du client est décrite dans Déployer le client.

Avant de commencer, ayez rempli l’inventaire de préparation, et vérifiez que votre navigateur atteint challenges.cloudflare.com.

Se connecter et finaliser l’organisation

OpenLatch crée l’organisation pour vous, désigne comme propriétaire l’adresse que vous avez donnée à votre contact OpenLatch, et envoie une invitation à cette adresse. L’assistant de bienvenue est l’endroit où vous finalisez la configuration.

1. Acceptez l’invitation. Ouvrez le lien de l’e-mail d’invitation. Il vous mène à la page de connexion propre à votre organisation et admet l’adresse invitée comme propriétaire. Terminez avec n’importe quelle méthode proposée par la page : une passkey, un lien magique, une adresse e-mail et un mot de passe, ou une connexion via un réseau social.

   Résultat attendu : la console s’ouvre sur votre organisation, et votre rôle indique owner.

2. Connectez-vous depuis app.openlatch.ai. Chaque connexion suivante commence par une étape : votre adresse e-mail. Cette étape effectue dans votre navigateur une courte vérification que le visiteur est une personne ; elle ne demande généralement rien, et au plus un clic. La console trouve ensuite l’organisation à laquelle appartient votre adresse et ouvre sa page de connexion avec l’adresse déjà remplie.

   Une adresse qu’aucune organisation ne connaît en est informée. Une vérification qui échoue à chaque fois signifie le plus souvent que le navigateur ne peut pas atteindre challenges.cloudflare.com ; voir Exigences réseau.

3. Suivez l’assistant de bienvenue. Il compte quatre étapes : nommer l’organisation, inviter des collègues, connecter un agent, et un récapitulatif de ce que vous avez fait et passé. Utilisez la première pour définir la raison sociale ou le nom d’entité que vous voulez voir dans le journal d’audit. La connexion d’un agent est décrite dans Déployer le client ; la passer ici ne coûte rien.

   Résultat attendu : l’assistant se ferme sur la console, sans agent inscrit pour l’instant.

Connecter l’authentification unique

L’authentification unique utilise SAML 2.0, configuré par organisation. Microsoft Entra ID, Okta, PingOne et Active Directory Federation Services se connectent tous par le même écran. Les réglages d’identité demandent le rôle admin ou supérieur.

1. Ouvrez Settings › SAML SSO et ajoutez un fournisseur. La page montre les informations du fournisseur de services dont aura besoin la personne qui administre votre fournisseur d’identité. Ayez sous la main les métadonnées de votre fournisseur d’identité.

2. Saisissez les informations du fournisseur d’identité. La console demande l’identifiant d’entité du fournisseur d’identité, son URL d’authentification, son certificat de signature, et les domaines de messagerie autorisés à se connecter. Vous pouvez fournir une URL de métadonnées au lieu de coller le certificat. Choisissez d’abord votre fournisseur d’identité dans la liste : la page affiche un guide de configuration écrit pour ce produit.

   L’assertion envoyée par votre fournisseur d’identité doit porter l’adresse e-mail et le nom d’affichage de l’utilisateur ; le guide de configuration nomme les champs exacts.

3. Enregistrez, lancez le test de connexion, puis connectez-vous. Le test porte sur la configuration enregistrée, pas sur ce qui est encore à l’écran. Il vérifie que l’URL de métadonnées ou l’URL de connexion du fournisseur d’identité répond ; il n’effectue pas de connexion SAML. Connectez-vous ensuite vous-même par SAML, dans une fenêtre de navigation privée, avant de demander à qui que ce soit d’autre de le faire.

   Résultat attendu : le test réussit, et votre propre connexion SAML atteint la console.

4. Décidez qui peut rejoindre. Deux portes contrôlent l’appartenance. Un domaine de messagerie autorisé permet à toute personne ayant une adresse dans ce domaine de s’inscrire dans l’organisation. Une invitation admet une personne nommée. Gardez les domaines autorisés restreints, et appuyez-vous sur les invitations pour tous les autres.

app.openlatch.ai/settings/saml-sso

Les réglages SAML SSO, avec les informations du fournisseur de services et les valeurs que fournit votre fournisseur d’identité.

Configurer l’authentification unique décrit plus en détail les réglages SAML et les autres méthodes de connexion.

Inviter l’équipe et attribuer les rôles

Quatre rôles se succèdent dans un ordre strict de privilèges. Chaque personne invitée commence en viewer : un rôle est accordé délibérément plutôt que retiré après coup.

Rôle	Ce qu’il permet
owner	Tout ce que permet admin, plus la propriété de l’organisation elle-même. Confiez-le à la personne responsable du déploiement
admin	Réglages d’identité, politiques, identifiants du client, conservation et canaux de notification. Accordez-le aux quelques personnes qui mènent le déploiement
editor	Politiques et remplacements de propriétaire d’agent
viewer	Lit les agents, les exécutions, les décisions et le journal d’audit. Suffisant pour tous les autres, y compris un développeur qui vérifie que sa machine est inscrite

1. Invitez par adresse e-mail sous Settings › Users. Chaque invitation produit un lien d’inscription lié à cette adresse. Invitez les personnes qui mènent le déploiement, pas toute l’organisation d’ingénierie.

   Résultat attendu : chaque personne invitée apparaît dans la liste des utilisateurs, en attente, avec le rôle viewer.

2. Relevez les rôles qui doivent l’être. N’accordez admin que là où les réglages d’identité, les identifiants ou la conservation doivent changer. Accordez editor à qui maintient les politiques et le registre des agents. Laissez les autres en viewer.

app.openlatch.ai/settings/users

Les réglages Users : chaque membre et le rôle qu’il détient.

Connecter un annuaire pour la recherche des propriétaires

Cette étape est facultative, et vous pouvez la faire après l’inscription des premières machines. Une connexion d’annuaire rattache le propriétaire de chaque agent connecté, pour que le registre des agents montre une personne plutôt qu’un nom de compte du système d’exploitation. Elle est en lecture seule et ne sert pas à la connexion.

La propriété se rapproche par deux côtés, et les deux doivent être présents. Les machines remontent les signaux qui identifient qui travaille, et l’annuaire transforme ces signaux en une personne nommée. Le côté signaux est un interrupteur sur la même page, Collect identity signals from endpoints, activé par défaut. S’il est désactivé, aucun agent ne peut être rattaché à un propriétaire.

1. Ouvrez Settings › Identity Providers et connectez un annuaire : Microsoft Entra ID, Google Workspace, Active Directory, Okta ou PingOne. Chacun est une source en lecture seule ; aucun ne crée d’utilisateurs, et aucun ne copie l’annuaire dans OpenLatch.
2. Recherchez une personne que vous savez présente dans l’annuaire. Une organisation sans annuaire connecté est un état pris en charge, et un agent dont le propriétaire ne peut pas être déterminé est enregistré comme non attribué plutôt que deviné.

app.openlatch.ai/settings/identity-providers

Identity Providers : l’interrupteur qui permet aux machines de signaler qui travaille, et les annuaires qui en font une personne nommée.

Définir la conservation et les notifications

Définissez ces deux réglages avant le début du déploiement ; une revue de sécurité vous interrogera sur les deux.

1. Définissez la conservation du journal d’audit sous Settings › Audit Trail. Le journal d’audit est en ajout seul et chaîné par hachage. Choisissez une durée de conservation, décidez de la purge automatique, et définissez le format d’export qu’attend votre processus de preuves.

   Réglage	Valeurs
   Conservation	90, 180, 365 ou 730 jours, ou une durée personnalisée. La console recommande 365
   Purge automatique	Activée ou non. Activée, elle supprime toutes les 24 heures les enregistrements au-delà de la durée de conservation
   Export	CSV ou JSON

2. Ajoutez un canal de notification sous Settings › Notification Channels. Pointez-le vers le canal dans lequel l’équipe de déploiement travaille déjà, comme un canal Slack ou un webhook HTTPS, et envoyez un test.

   Résultat attendu : l’envoi de test arrive.

app.openlatch.ai/settings/audit-trail

Les réglages Audit Trail : durée de conservation, purge automatique et format d’export.

Créer l’identifiant du client

Le client s’authentifie auprès de la console avec une clé d’API. Vous la créez depuis une session de navigateur connectée, sur la page API Keys de votre compte, et vous la révoquez depuis la même page.

1. Créez une clé par vague de déploiement, nommée d’après sa vague. Une clé par vague signifie qu’une clé à révoquer ne concerne qu’une seule vague.

   Résultat attendu : la valeur de la clé est affichée une seule fois, en entier, à la création. Ensuite, la liste montre son nom, une valeur masquée, sa date de création et sa dernière utilisation.

2. Stockez-la dans le coffre de secrets de votre organisation. L’installation gérée lit la clé dans l’environnement, sous le nom OPENLATCH_API_KEY. Elle n’est jamais écrite dans un script, un paquet ou une ligne de commande.

3. Gardez-la jusqu’à ce que les machines de la vague en détiennent une autre. Chaque machine enregistre la clé avec laquelle elle a été inscrite et s’authentifie avec elle : révoquer une clé de vague déconnecte toutes les machines de cette vague. Avant d’en révoquer une, donnez une nouvelle clé à ses machines : définissez-la comme OPENLATCH_API_KEY et relancez openlatch init --yes sur chaque machine. La date de dernière utilisation vous indique si une clé est encore présentée avant de la révoquer.

   Résultat attendu : la clé apparaît comme révoquée, et tout ce qui la présente encore, une installation ou une machine, est refusé.

Attention

Une clé passée en ligne de commande atterrit dans l’historique du shell, la liste des processus et les journaux de gestion de configuration. Le client refuse un identifiant passé ainsi. Fournissez-le par l’environnement, depuis votre coffre de secrets.

app.openlatch.ai/account/api-keys

API Keys : chaque clé listée avec une valeur masquée après sa création.

Gérer les clés d’API décrit les clés plus en détail.

En bref

• OpenLatch crée l’organisation et invite son propriétaire ; l’assistant de bienvenue est l’endroit où vous la nommez.
• SAML 2.0 se configure par organisation et se vérifie par un test qui nomme l’étape en échec. Les domaines de messagerie autorisés et les invitations sont les deux portes de l’appartenance.
• Les rôles sont owner, admin, editor, viewer, et chaque personne invitée commence en viewer. Une connexion d’annuaire est facultative, en lecture seule, et rattache le propriétaire d’un agent.
• Définissez la conservation du journal d’audit, avec purge automatique, avant le début du déploiement, et dirigez les notifications vers le canal déjà utilisé.
• Créez un identifiant client par vague de déploiement, fournissez-le par le coffre de secrets sous le nom OPENLATCH_API_KEY, et révoquez-le quand la vague se termine.