Les Politiques d'entreprise appliquent des règles à l'échelle de l'organisation pour la gestion des informations d'identification, l'admission des membres, l'accès aux sessions SSO et les récompenses d'invitation. Les Propriétaires et Administrateurs de l'organisation peuvent configurer ces politiques à partir des paramètres de sécurité de l'organisation.
Ce tutoriel explique la portée de chaque politique, comment la configurer et ce qu'il faut tester avant un déploiement à plus grande échelle.
Avant de commencer
- L'organisation doit utiliser le plan Enterprise.
- Vous devez être Propriétaire ou Administrateur de l'organisation.
- Les politiques disponibles dans Apidog On-Premises peuvent différer de la documentation SaaS.
- Utilisez des utilisateurs de test, des informations d'identification fictives et un projet de non-production pour la validation.
Ces politiques sont des politiques d'espace de travail. Elles ne remplacent pas les contrôles d'exécution dans une passerelle API, un serveur d'autorisation, un maillage de services ou une application.
Étape 1 : Ouvrir les Politiques d'entreprise
- Ouvrez l'organisation Apidog.
- Allez dans Paramètres de l'organisation.
- Dans Sécurité, sélectionnez Politiques d'entreprise.
Seuls les Propriétaires de l'organisation et les Administrateurs peuvent modifier les Politiques d'entreprise.
La page comprend actuellement quatre politiques :
- Politique relative aux informations d'identification d'authentification
- Politique de crédits d'invitation
- Politique de session SSO
- Politique de domaine d'e-mail des membres
Étape 2 : Configurer la Politique relative aux informations d'identification d'authentification
La Politique relative aux informations d'identification d'authentification vérifie les champs d'authentification sensibles pris en charge lorsque les utilisateurs modifient ou enregistrent l'authentification API, l'authentification de dossier, l'authentification des requêtes, les schémas de sécurité, les cas de test API et les scénarios de test.
Choisir le mode valeur brute
Configurez Interdire les valeurs brutes dans les champs sensibles d'authentification :
| Mode | Résultat |
|---|---|
| Désactivé | La règle n'est pas appliquée |
| Avertir | L'utilisateur voit un avertissement mais peut toujours enregistrer |
| Bloquer | L'utilisateur ne peut pas enregistrer la valeur non conforme |
Choisir le mode de référence
Configurez Autoriser uniquement les variables locales ou Vault Secret pour l'authentification avec les mêmes modes Désactivé, Avertir ou Bloquer.
Lorsque ce contrôle est activé, les champs sensibles doivent utiliser des variables locales uniquement ou des références Vault Secret. Une variable avec une valeur initiale partagée peut générer un avertissement ou un blocage selon le mode sélectionné.
Apidog considère les éléments suivants comme des références autorisées pour la politique d'informations d'identification :
- une valeur vide ;
- une référence de variable telle que
{{variableName}}; - une référence Vault Secret telle que
{{vault:key}}.
Contrôler l'affichage des valeurs du Coffre-fort
Activez Le Secret du Coffre-fort ne peut pas être révélé en texte clair lorsque les utilisateurs ne devraient pas pouvoir afficher les valeurs du Secret du Coffre-fort dans l'interface utilisateur.
Tester avant de bloquer
Pour un déploiement contrôlé :
- utilisez Avertir dans un projet pilote ;
- testez la Clé API, le Jeton d'authentification (Bearer Token), l'Authentification de base, OAuth 2.0 et tout autre type d'authentification utilisé par l'organisation ;
- remplacez les valeurs brutes par la variable approuvée ou le modèle de Coffre-fort ;
- confirmez que les flux de travail légitimes sont toujours enregistrés et exécutés ;
- passez à Bloquer une fois les exceptions traitées.
La politique couvre les champs sensibles documentés pour la Clé API, le Jeton d'authentification (Bearer Token), les authentifications de base et Digest, OAuth 1.0 et 2.0, Hawk, AWS, NTLM, Akamai EdgeGrid, JWT Bearer et l'authentification combinée.
Étape 3 : Configurer la Politique de session SSO
La Politique de session SSO contrôle si les utilisateurs peuvent accéder à Mes Équipes lorsqu'ils sont connectés via le SSO de l'organisation actuelle.
- Confirmez que le SSO est configuré pour l'organisation.
- Sur Politiques d'entreprise, trouvez Politique de session SSO.
- Activez Restreindre Mes Équipes dans les sessions SSO.
- Enregistrez la politique.
Lorsqu'elle est activée, Mes Équipes est indisponible pendant la session SSO de cette organisation.
Le paramètre est désactivé par défaut et ne peut être activé qu'après la configuration du SSO. Un utilisateur restreint doit se déconnecter et utiliser une méthode de connexion régulière pour accéder à Mes Équipes. Le retour à l'organisation SSO nécessite une nouvelle connexion via SSO.
Cette politique n'est pas un délai d'inactivité ni un paramètre de durée maximale de session. Elle isole l'accès à Mes Équipes au sein de la session SSO de l'organisation actuelle.
Tester la limite de session
Utilisez un utilisateur de test non-administrateur :
- connectez-vous via le point d'entrée SSO de l'organisation ;
- confirmez que l'organisation est disponible ;
- tentez d'ouvrir Mes Équipes et confirmez le message de restriction ;
- sélectionnez Se déconnecter et changer ;
- connectez-vous avec une méthode régulière et confirmez que Mes Équipes est disponible ;
- confirmez que le retour à l'organisation SSO nécessite le SSO.
Étape 4 : Configurer la Politique d'e-mail des membres
La Politique d'e-mail des membres limite l'adhésion à l'organisation aux domaines d'e-mail approuvés. Apidog vérifie l'e-mail authentifié final de l'utilisateur, et pas seulement l'adresse à laquelle une invitation a été envoyée.
- Configurez un ou plusieurs domaines d'e-mail autorisés pour l'organisation.
- Ouvrez Sécurité > Politiques d'entreprise.
- Trouvez Politique d'e-mail des membres.
- Activez la politique et enregistrez-la.
Configurez les domaines dont les utilisateurs authentifiés peuvent devenir membres de l'organisation.
La même règle d'admission s'applique à :
- les invitations par e-mail ;
- les liens d'invitation ;
- le SSO ;
- le SCIM.
Si l'e-mail authentifié final ne correspond pas à un domaine autorisé, Apidog rejette la tentative d'adhésion. Aucune adhésion à une organisation, une équipe ou un projet n'est créée, l'utilisateur n'occupe pas de place et n'apparaît pas dans la liste des membres ou l'exportation des membres.
Un utilisateur rejeté reçoit un message d'incompatibilité de domaine, et le rejet est enregistré dans les Journaux d'audit.
Testez au moins une adresse approuvée et une adresse non autorisée pour chaque voie d'admission utilisée par l'organisation.
Étape 5 : Configurer la Politique de récompense d'invitation
La Politique de récompense d'invitation contrôle si les invitations éligibles liées à l'organisation peuvent générer des crédits de récompense d'invitation.
- Ouvrez Sécurité > Politiques d'entreprise.
- Trouvez Politique de récompense d'invitation.
- Activez ou désactivez les récompenses d'invitation.
- Enregistrez le paramètre.
La désactivation de la politique empêche les futures invitations éligibles liées à l'organisation de générer des crédits de récompense. Elle ne supprime pas les crédits déjà gagnés.
Il s'agit d'un paramètre administratif, et non d'une politique de contrôle d'accès ou de sécurité. Elle ne doit pas être décrite comme une fonctionnalité de suppression d'e-mails d'invitation.
Vérifier les quatre politiques
Utilisez une petite matrice de test et enregistrez le résultat.
| Politique | Test positif | Test négatif |
|---|---|---|
| Informations d'identification d'authentification | Enregistrer une variable locale ou une référence Vault approuvée | Tenter d'enregistrer une valeur brute fictive en mode Avertir ou Bloquer |
| Session SSO | Accéder à l'organisation SSO via SSO | Tenter d'ouvrir Mes Équipes dans la session SSO restreinte |
| E-mail des membres | Rejoindre avec un domaine authentifié approuvé | Tenter de rejoindre avec un domaine authentifié non autorisé |
| Récompense d'invitation | Confirmer l'état de récompense sélectionné | Confirmer que les crédits existants gagnés restent inchangés lorsqu'ils sont désactivés |
Après les tests, consultez les Journaux d'audit pour les événements d'adhésion ou de rejet liés à la politique pris en charge et pertinents pour le flux de travail.
Dépannage
| Problème | Ce qu'il faut vérifier |
|---|---|
| Un utilisateur peut enregistrer une information d'identification brute | Confirmer que le contrôle d'informations d'identification correct est activé et défini sur Bloquer, et que la valeur se trouve dans un champ d'authentification pris en charge. |
| Une variable approuvée est bloquée | Vérifier si la règle plus stricte exige une variable locale uniquement ou un Secret du Coffre-fort plutôt qu'une valeur initiale partagée. |
| Le commutateur de session SSO est indisponible | Confirmer que le SSO est configuré pour l'organisation. |
| Un employé valide est rejeté | Vérifier l'e-mail authentifié final et la liste des domaines autorisés, y compris les alias et les domaines subsidiaires. |
| Un crédit existant disparaît | La désactivation des récompenses d'invitation ne devrait pas supprimer les crédits déjà gagnés ; enregistrez le compte et demandez au support d'enquêter. |
Limitations importantes
- La Politique relative aux informations d'identification d'authentification s'applique aux champs et flux de travail d'authentification documentés, et non à tous les champs de texte libre, scripts, fichiers ou dépôts externes.
- La Politique de session SSO restreint Mes Équipes dans la session SSO d'une organisation ; ce n'est pas un délai d'attente de session, une politique d'appareil ou un contrôle réseau.
- La Politique d'e-mail des membres régit l'admission. Ne supposez pas qu'elle supprime automatiquement les membres existants dont les adresses ne correspondent plus, sauf si ce comportement est documenté et testé séparément.
- La Politique de récompense d'invitation n'est pas un contrôle de sécurité.
- Aucune de ces politiques n'impose l'authentification ou l'autorisation sur le trafic API déployé.
Tutoriels de gouvernance API connexes :
Ces tutoriels couvrent des contrôles complémentaires pour la gouvernance d'un espace de travail API d'entreprise :
- Cadre de gouvernance API — connecter la propriété, les contrôles, les preuves et les décisions de cycle de vie.
- Mappage de groupes SAML avec Microsoft Entra ID — attribuer l'accès aux équipes à partir de groupes de fournisseurs d'identité.
- Scanner de secrets — examiner les informations d'identification potentiellement exposées dans les ressources Apidog prises en charge.
- Journaux d'audit — enquêter et exporter l'activité administrative de l'organisation.
- Provisionnement SCIM — gérer les utilisateurs de l'organisation tout au long du cycle de vie de l'identité.
- Politiques d'entreprise — configurer les contrôles des informations d'identification, de l'adhésion, des sessions SSO et des invitations.
- Équipes API en libre-service — autoriser les équipes créées par les membres tout en conservant la supervision de la propriété.
- Intégration à GitHub Enterprise Cloud — connecter les dépôts GHE.com pris en charge pour les flux de travail OpenAPI.
Documentation officielle connexe :