Accès aux applications privées

Périmètre et configuration

L’accès privé est désactivé tant que la plateforme ne l’a pas activé. Le service n’ouvre aucune connexion entrante vers le réseau client et le dépôt ne fournit pas d’agent. Un agent client interroge le service en sortie via mutual TLS signé ; ce canal de contrôle n’est pas un proxy généraliste. Les responsables du tenant enregistrent une destination HTTPS exacte. Une approbation indépendante par God est requise avant toute transmission.

1. Vérifiez l’activation de la fonctionnalité, l’application et le profil du tenant ainsi que l’état de l’agent inscrit.
2. Saisissez la destination HTTPS exacte et les chemins autorisés ; ne fournissez aucun identifiant.
3. Soumettez la demande à approbation et attendez son état approuvé avant d’attendre une transmission.

Agents, certificats et appareils

L’inscription de l’agent utilise une initialisation à usage unique, une clé privée conservée par le client, un certificat de courte durée et des requêtes signées. La clé n’est jamais téléversée. Le renouvellement et la révocation sont distincts ; une révocation invalide tous les certificats de l’agent. L’état d’un appareil géré est un signal d’assurance, pas une preuve de bon fonctionnement. Vérifiez la fraîcheur des preuves avant de les utiliser dans une règle.

1. Créez une inscription pour le connecteur du tenant voulu et protégez le jeton à usage unique.
2. Générez la clé localement et vérifiez que l’agent est compatible et inscrit.
3. Renouvelez avant l’expiration ; révoquez les agents compromis ou les certificats d’appareil obsolètes.

Zones réseau et règles

Les règles peuvent prendre en compte le tenant, l’application, le rôle, la ressource, le niveau d’assurance de l’appareil, la force de l’authentification, l’ancienneté de la session et les signaux réseau. Le mode « rapport uniquement » présente les décisions envisagées sans bloquer l’accès. Les règles sont versionnées ; prévisualisez-les avant publication. Les diagnostics de santé et un signal réseau ne suffisent jamais à accorder un accès.

1. Examinez le périmètre du tenant et de l’application, les signaux, la priorité et le mode d’application.
2. Prévisualisez une requête représentative et comparez le résultat à la décision attendue.
3. Après publication, examinez la décision réelle et corrigez le périmètre, pas les contrôles d’assurance.

Affectations, sessions et déconnexion

Les affectations visent un utilisateur, un groupe ou un package et peuvent nécessiter une approbation et une date d’expiration. Les utilisateurs déconnectent leurs propres sessions ; les responsables du tenant peuvent terminer celles de leur application. La déconnexion d’urgence, réservée à God, exige une authentification renforcée récente résistante à l’hameçonnage et révoque les sessions de l’application, les points de terminaison, les identifiants conservés et les familles de jetons. Elle ne révoque pas un agent partagé par d’autres applications et n’efface pas un cookie amont.

1. Demandez l’affectation exacte à l’application et vérifiez son approbation avant utilisation.
2. Dans l’inventaire, confirmez l’utilisateur et l’application avant de terminer une session.
3. Pour une déconnexion d’urgence, effectuez réellement l’authentification renforcée et vérifiez la révocation et l’audit.

Identités de workloads et secrets

Les identités de workloads ont des propriétaires, des relations de confiance, des identifiants, des jetons, des affectations de packages, des revues et des incidents. Les opérations de lecture et d’écriture nécessitent leurs autorisations respectives. Ne demandez que la relation de confiance ou l’accès au package nécessaire et obtenez l’approbation du propriétaire ou une approbation indépendante. Révoquez les jetons ou certificats exposés. Ne placez jamais de secrets dans les données de profil, les notes d’audit ou les exports.

1. Vérifiez le propriétaire de l’identité, le tenant, les identifiants et l’état de la revue.
2. Demandez la relation de confiance ou le package nécessaire en précisant le motif et l’approbation requise.
3. Renouvelez les identifiants et révoquez les jetons ou certificats exposés ; vérifiez qu’ils sont inactifs.

Diagnostics, audit et conservation

Les diagnostics affichent des événements limités, des décisions par catégorie, la latence, la fraîcheur de l’agent et l’expiration des certificats ; ils excluent le contenu des requêtes, les identifiants, les jetons, les adresses IP brutes et les user-agents. Les contrôles d’audit, de dossiers de preuves, de conservation, de mise sous séquestre et d’export ont des périmètres distincts. Traitez les preuves téléchargées comme des données sensibles. Contrat de l’API d’administration : /api/auth/management/openapi.json.

1. Vérifiez le périmètre du tenant et de l’application, la fraîcheur de l’agent, l’état de santé et la catégorie de refus.
2. Pour les investigations conservées, utilisez l’audit ou les dossiers de preuves en limitant leur périmètre.
3. Avant un export ou une modification de conservation, vérifiez les autorisations et les mises sous séquestre, puis contrôlez le résultat d’audit.

Questions fréquentes

Pages associées

• Authentification unique et identité
• Protocoles de fédération et provisionnement
• Administration SSO
• Gouvernance des identités et accès privilégiés