Utilisez cette page pour répondre aux questions que soulève un déploiement. Quand une autre page traite une question en entier, la réponse renvoie vers elle.
| Question | Réponse |
|---|
| De quoi avez-vous besoin de notre part pour commencer ? | Trois choses : une organisation dans la console avec un administrateur qui peut inviter tous les autres, un accès HTTPS sortant sur 443 vers app.openlatch.ai, et le périmètre, c’est-à-dire les machines de la première vague. Les scripts d’installation apportent le client avec eux : une machine n’a besoin d’aucun environnement d’exécution. Prérequis en fait une liste de contrôle |
| Faut-il des droits d’administrateur sur la machine ? | Non. Le client s’installe et s’exécute au niveau de l’utilisateur, ne charge aucun pilote et n’ouvre aucun port entrant |
| Pouvons-nous le déployer avec nos outils de gestion existants ? | Oui. Comme le client s’exécute en contexte utilisateur, il se livre par un script au niveau de l’utilisateur plutôt que par un programme d’installation au niveau de l’appareil, avec l’identifiant transmis depuis votre coffre de secrets par l’environnement et jamais écrit dans un script, un paquet ou une ligne de commande. Créez une clé par vague de déploiement et révoquez-la quand la vague se termine. Voir Déployer le client |
| Quels agents couvre-t-il ? | L’installation détecte les agents présents sur une machine et raccorde chacun de ceux qu’elle trouve. Niveaux de contrôle liste les agents raccordés aujourd’hui, plan par plan. Chaque agent apparaît dans la console avec son niveau de contrôle, Enforced, Monitored ou Known, qui indique le contrôle dont vous disposez sur lui |
| Le développeur doit-il faire quelque chose ? | En général non. Certains agents demandent au développeur de confirmer la connexion une fois, au premier lancement après l’installation, et openlatch status montre quels agents attendent encore. Voir Vérifier et déployer |
| Question | Réponse |
|---|
| Que doit atteindre OpenLatch, et ouvre-t-il quelque chose ? | Une seule destination, en sortie : app.openlatch.ai sur TCP 443 en HTTPS, autorisée par nom car il n’existe aucune plage d’adresses statique. Rien en entrée : le client n’écoute que sur l’interface de bouclage. Voir Exigences réseau |
| Notre seule sortie est un proxy authentifié. Qu’est-ce qui est pris en charge ? | HTTP et HTTPS CONNECT, SOCKS5, les proxys transparents, et PAC ou WPAD là où le résolveur du système d’exploitation l’évalue. Les authentifications Basic et Kerberos (Negotiate) sont prises en charge. NTLM ne l’est pas, par choix de conception ; Negotiate est la voie sur ces parcs. Les identifiants de proxy sont conservés dans le magasin d’identifiants du système d’exploitation |
| L’inspection TLS pose-t-elle problème ? | Non, à condition que l’autorité de certification d’interception soit approuvée. Installez-la dans le magasin de confiance du système d’exploitation, ou indiquez-la au client, auquel cas elle est fusionnée par-dessus le magasin du système. La vérification n’est jamais désactivée, et OpenLatch n’émet aucun certificat |
| Le trafic propre de nos agents change-t-il ? | Non. Vos agents atteignent leurs points d’accès de modèles exactement comme avant. Ces points d’accès doivent rester joignables et être exemptés de la mise en tampon des réponses et de l’inspection des flux |
| Que se passe-t-il quand une machine est hors ligne, ou la console injoignable ? | Les politiques restent en vigueur sur la machine, car la décision est prise localement. Les enregistrements sont conservés sur la machine et envoyés quand la console redevient joignable. Voir Architecture |
| Question | Réponse |
|---|
| Est-ce un proxy ou une passerelle devant nos agents ? | Ni l’un ni l’autre. OpenLatch s’exécute dans le cycle de vie de l’agent lui-même, et la décision est prise sur la machine avant que l’action ne s’exécute. Rien de chez nous n’est sur votre chemin réseau, et OpenLatch ne termine aucune connexion TLS |
| Qu’est-ce qui quitte la machine ? Nos prompts ? Notre code source ? | Les prompts sont capturés en métadonnées par défaut : qu’il y en a eu un, quand, dans quelle session et sa longueur. Le texte du prompt n’est pas envoyé sauf si votre organisation l’active, et les requêtes et réponses échangées avec un modèle ne sont jamais envoyées à OpenLatch. Ce qui part, ce sont les métadonnées d’action avec les identifiants et les chemins de fichiers masqués, plus les signaux d’identité nécessaires pour attribuer une action ; le contenu des fichiers est filtré par défaut. OpenLatch ne se connecte à aucun de vos dépôts. Voir Traitement des données et sécurité |
| Où la console est-elle hébergée ? | Aux États-Unis, dans la région US-East, avec les données de chaque organisation isolées de celles de toutes les autres. Les verdicts sont produits sur vos propres machines : le lieu de stockage des enregistrements n’affecte pas l’application. La liste des sous-traitants est disponible sur demande |
| Qui peut se connecter à la console, et qui voit quoi ? | L’authentification unique SAML 2.0 se configure par organisation, et l’accès dans la console suit quatre rôles. Chaque changement d’administration est écrit dans un journal d’audit en ajout seul que vous pouvez exporter. Voir Configurer l’organisation |
| Quelqu’un peut-il le désactiver sur sa propre machine ? | OpenLatch vise un agent qui se comporte mal : qui tourne en boucle, gaspille du budget, subit une injection et agit par ses outils, ou enfreint une politique tout en fonctionnant normalement par ailleurs. Le client s’installe au niveau de l’utilisateur : une personne qui contrôle sa machine peut le retirer. Ce qu’elle y perd, c’est la couverture, pas la discrétion : la couverture est signalée machine par machine, et une machine qui cesse de remonter apparaît comme un trou au lieu de passer pour couverte |
| Question | Réponse |
|---|
| Est-ce que cela ralentit l’agent ? | La décision est prise sur la machine, sans appel réseau ni modèle sur le chemin : une action couverte n’attend aucun aller-retour. OpenLatch ne publie aucun chiffre de latence. Ce qu’il affirme, c’est que chaque action couverte atteint le point de décision des politiques, et que le verdict produit par une politique explicite est celui qui est appliqué |
| Comment confirmer qu’une machine est vraiment connectée ? | openlatch status indique si la machine est connectée, si des politiques sont présentes et si les agents sont raccordés, et openlatch doctor prouve chacun de ces points. Les agents de la machine apparaissent ensuite dans le registre des agents de la console avec un propriétaire. Voir Vérifier et déployer |
| Comment fonctionnent les mises à jour, et peut-on les figer ? | Le client peut se mettre à jour, et chaque téléchargement est vérifié en intégrité avant tout remplacement. Laissez cela actif pour les installations des développeurs. Un parc géré le désactive, garde la vérification active, et livre la nouvelle version dans sa propre fenêtre de maintenance. Voir Exploiter |
| Comment faire entrer les notifications et les enregistrements dans nos outils ? | Les notifications partent par e-mail, vers un canal de messagerie comme Slack ou Microsoft Teams, ou vers un webhook qui vous appartient, et le journal d’audit s’exporte en CSV ou JSON selon la conservation que vous définissez. Voir Configurer les canaux de notification |
| Comment le désinstaller ? | openlatch uninstall détache le client de chaque agent de la machine et laisse chacun tel qu’il était. Ajouter --purge supprime aussi le répertoire local et l’identifiant conservé. Voir Exploiter |
| Comment ouvrir une demande de support ? | Contactez votre référent technique OpenLatch par le canal convenu avec votre organisation. Lancez openlatch doctor --rescue sur la machine concernée et joignez l’archive expurgée qu’il produit, avec le système d’exploitation et l’heure du problème avec son fuseau horaire. Les signalements de sécurité vont à security@openlatch.ai |
