Configurer les Politiques d’entreprise Apidog
Les Politiques d’entreprise appliquent des règles à l’échelle de l’organisation pour gérer les informations d’identification, l’admission des membres, les sessions SSO et les récompenses d’invitation. Les Propriétaires et Administrateurs peuvent les configurer depuis les paramètres de sécurité de l’organisation.
Essayez Apidog dès aujourd'hui
Ce tutoriel explique la portée de chaque politique, sa configuration et les tests à effectuer avant un déploiement à 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.
Ces politiques s’appliquent à l’espace de travail. Elles ne remplacent pas les contrôles d’exécution d’une passerelle API, d’un serveur d’autorisation, d’un maillage de services ou d’une application.
1. Ouvrir les Politiques d’entreprise
- Ouvrez l’organisation Apidog.
- Accédez à Paramètres de l’organisation.
- Dans Sécurité, sélectionnez Politiques d’entreprise.
Seuls les Propriétaires et Administrateurs de l’organisation 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
2. Configurer la Politique relative aux informations d’identification d’authentification
Cette politique vérifie les champs d’authentification sensibles lorsque les utilisateurs modifient ou enregistrent :
- l’authentification API, de dossier ou de requête ;
- les schémas de sécurité ;
- les cas de test API ;
- les scénarios de test.
Interdire les valeurs brutes
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 | Un avertissement s’affiche, mais l’utilisateur peut enregistrer la valeur. |
| Bloquer | L’utilisateur ne peut pas enregistrer la valeur non conforme. |
Autoriser uniquement les références approuvées
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 une variable locale ou une référence Vault Secret. Une variable possédant une valeur initiale partagée peut déclencher un avertissement ou un blocage selon le mode choisi.
Les références autorisées incluent :
- une valeur vide ;
- une variable, par exemple
{{variableName}}; - un Vault Secret, par exemple
{{vault:key}}.
Masquer les valeurs Vault Secret
Activez Le Secret du Coffre-fort ne peut pas être révélé en texte clair si les utilisateurs ne doivent pas pouvoir afficher les valeurs Vault Secret dans l’interface.
Tester avant de bloquer
Pour un déploiement progressif :
- Utilisez le mode Avertir dans un projet pilote.
- Testez la Clé API, le Bearer [REDACTED], l’Authentification de base, OAuth 2.0 et les autres mécanismes utilisés.
- Remplacez les valeurs brutes par une variable approuvée ou un modèle Vault Secret.
- Vérifiez que les flux légitimes sont toujours enregistrés et exécutés.
- Passez au mode Bloquer après traitement des exceptions.
La politique couvre les champs sensibles documentés pour la Clé API, le Bearer Token, les authentifications de base et Digest, OAuth 1.0 et 2.0, Hawk, AWS, NTLM, Akamai EdgeGrid, JWT Bearer [REDACTED] l’authentification combinée.
3. Configurer la Politique de session SSO
Cette politique contrôle l’accès à Mes Équipes lorsqu’un utilisateur est connecté via le SSO de l’organisation actuelle.
- Vérifiez que le SSO est configuré pour l’organisation.
- Dans Politiques d’entreprise, ouvrez Politique de session SSO.
- Activez Restreindre Mes Équipes dans les sessions SSO.
- Enregistrez la politique.
Une fois 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. Pour revenir à l’organisation SSO, une nouvelle connexion via SSO est nécessaire.
Cette politique ne définit ni délai d’inactivité ni durée maximale de session. Elle limite uniquement l’accès à Mes Équipes dans la session SSO de l’organisation actuelle.
Tester la restriction de session
Avec un utilisateur de test non-administrateur :
- connectez-vous via le point d’entrée SSO de l’organisation ;
- vérifiez que l’organisation est disponible ;
- ouvrez Mes Équipes et confirmez le message de restriction ;
- sélectionnez Se déconnecter et changer ;
- reconnectez-vous avec une méthode régulière et vérifiez que Mes Équipes est disponible ;
- confirmez que le retour à l’organisation SSO exige une connexion SSO.
4. Configurer la Politique d’e-mail des membres
Cette politique limite l’adhésion à l’organisation aux domaines d’e-mail approuvés. Apidog vérifie l’adresse e-mail authentifiée finale, et pas uniquement l’adresse utilisée pour envoyer l’invitation.
- Configurez un ou plusieurs domaines autorisés.
- Accédez à Sécurité > Politiques d’entreprise.
- Ouvrez 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 s’applique aux :
- invitations par e-mail ;
- liens d’invitation ;
- connexions SSO ;
- opérations SCIM.
Si l’adresse e-mail authentifiée finale ne correspond pas à un domaine autorisé, Apidog rejette l’adhésion. Aucune adhésion à l’organisation, à une équipe ou à un projet n’est créée. L’utilisateur ne consomme pas de place et n’apparaît ni dans la liste ni dans l’export des membres.
L’utilisateur rejeté reçoit un message d’incompatibilité de domaine ; le rejet est enregistré dans les Journaux d’audit.
Pour chaque voie d’admission utilisée, testez au moins :
- une adresse appartenant à un domaine autorisé ;
- une adresse appartenant à un domaine non autorisé.
5. Configurer la Politique de récompense d’invitation
Cette politique contrôle si les invitations éligibles liées à l’organisation peuvent générer des crédits de récompense.
- Accédez à Sécurité > Politiques d’entreprise.
- Ouvrez Politique de récompense d’invitation.
- Activez ou désactivez les récompenses d’invitation.
- Enregistrez le paramètre.
La désactivation empêche les futures invitations éligibles liées à l’organisation de générer des crédits. Elle ne supprime pas les crédits déjà gagnés.
Il s’agit d’un paramètre administratif, et non d’un contrôle d’accès ou de sécurité. Il ne doit pas être présenté comme une fonctionnalité de suppression des e-mails d’invitation.
Vérifier les quatre politiques
Utilisez une matrice de test et consignez les résultats :
| 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 via SSO. | Ouvrir Mes Équipes dans la session SSO restreinte. |
| E-mail des membres | Rejoindre l’organisation avec une adresse d’un domaine approuvé. | Tenter de rejoindre l’organisation avec une adresse d’un domaine non autorisé. |
| Récompense d’invitation | Confirmer l’état de récompense sélectionné. | Vérifier que les crédits déjà gagnés restent inchangés après désactivation. |
Après les tests, consultez les Journaux d’audit pour les événements d’adhésion ou de rejet pertinents pris en charge par la politique.
Dépannage
| Problème | Vérification |
|---|---|
| Un utilisateur peut enregistrer une information d’identification brute | Vérifiez que le contrôle approprié 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érifiez si la règle exige une variable locale uniquement ou un Vault Secret plutôt qu’une valeur initiale partagée. |
| Le commutateur de session SSO est indisponible | Vérifiez que le SSO est configuré pour l’organisation. |
| Un employé valide est rejeté | Vérifiez l’adresse e-mail authentifiée finale et la liste des domaines autorisés, notamment les alias et les domaines subsidiaires. |
| Un crédit existant disparaît | La désactivation des récompenses ne devrait pas supprimer les crédits déjà gagnés. Notez les informations du compte et contactez le support. |
Limitations importantes
- La Politique relative aux informations d’identification d’authentification couvre les champs et flux documentés, mais pas 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 ni un délai d’expiration, ni une politique d’appareil, ni 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 l’adresse ne correspond 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
- Cadre de gouvernance API — relier propriété, contrôles, preuves et décisions de cycle de vie.
- Mappage de groupes SAML avec Microsoft Entra ID — attribuer l’accès aux équipes à partir des groupes du fournisseur 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 OpenAPI.
Top comments (0)