Nouveautés d'API7 Enterprise : IAM pour un contrôle d'accès granulaire

Introduction

Les versions précédentes de API7 Enterprise offraient un mécanisme de gestion RBAC (Contrôle d'Accès Basé sur les Rôles) simple, convivial et complet. Ce mécanisme garantissait la sécurité du système tout en accordant aux utilisateurs une configuration flexible des permissions des rôles. Cependant, avec l'augmentation des types de ressources et des fonctionnalités d'API7 Enterprise, la gestion traditionnelle RBAC a progressivement révélé ses limites en matière de contrôle granulaire des permissions. De plus, de plus en plus d'entreprises recherchent des stratégies de gestion des permissions plus raffinées pour répondre à leurs besoins commerciaux complexes et changeants.

Pour améliorer davantage les fonctionnalités de gestion des permissions d'API7 Enterprise, nous avons procédé à une mise à niveau complète du système de permissions des rôles existant en introduisant un modèle de politique IAM (Gestion des Identités et des Accès) plus flexible et puissant. Ce modèle offre aux utilisateurs un contrôle des permissions plus granulaire et une plus grande flexibilité, répondant mieux aux besoins complexes et variables de gestion des permissions des entreprises modernes.

Qu'est-ce que le Modèle de Politique IAM ?

Le modèle de politique IAM (Gestion des Identités et des Accès) représente une méthode de gestion des permissions plus détaillée et efficace. Il permet aux administrateurs de définir des politiques spécifiques, chacune contenant un ensemble de règles (Statements). Ces règles spécifient en détail quels utilisateurs ou rôles peuvent effectuer quelles actions sur quelles ressources. Par rapport au mécanisme RBAC traditionnel, ce modèle offre une plus grande flexibilité et granularité.

Avantages de IAM par rapport à RBAC :

• Contrôle Granulaire : IAM peut contrôler les permissions au niveau des ressources et même pour des attributs ou des opérations spécifiques au sein des ressources, tandis que RBAC attribue souvent les permissions en fonction des rôles, avec une granularité relativement grossière.

• Flexibilité : IAM permet aux administrateurs de gérer directement les politiques et les permissions sans avoir besoin de créer et de gérer de nombreux rôles pour l'attribution indirecte des permissions, rendant la configuration plus simple et flexible.

• Évolutivité : À mesure que les fonctionnalités du système augmentent et que les types de ressources se diversifient, IAM peut s'adapter plus facilement aux changements en ajoutant de nouvelles politiques pour répondre aux nouveaux besoins de permissions, tandis que RBAC peut nécessiter l'ajustement ou l'ajout de nombreux rôles pour s'adapter aux changements.

Comment Utiliser les Politiques IAM dans API7 Enterprise ?

1. Créer des Politiques de Permissions

Après vous être connecté à API7 Enterprise, cliquez sur le bouton "Organization" en haut à droite, puis sélectionnez l'élément de menu "Permission Policies" dans le menu déroulant.

Dans la section Permission Policies, vous pouvez gérer toutes les politiques. Par défaut, il existe une politique super-admin-permission-policy pour l'administrateur initial.

Cliquez sur le bouton "Add Policy" en haut à droite pour accéder au formulaire de création de politique. Ici, vous devez remplir les informations de base des politiques et configurer les permissions dans l'éditeur de politiques, appelé Statements.

Les Statements sont les composants principaux d'une politique, constitués d'un ou plusieurs statements. Chaque statement définit une règle d'accès spécifique.

• Effect : Spécifie l'effet du statement, généralement "Allow" ou "Deny". Une ressource peut être affectée par plusieurs politiques, et le système IAM détermine les permissions d'accès finales en fonction de l'ordre et de la logique des statements.

• Action : Définit une série d'actions autorisées ou interdites, telles que "gateway:DeleteGatewayGroup" ou "iam:GetUser". Ces actions doivent être utilisées conjointement avec des ressources (Resource) pour être significatives.

• Resource : Spécifie les ressources auxquelles le statement s'applique, comme un groupe de passerelles ou un service spécifique. Des caractères génériques (par exemple, <.*>) peuvent être utilisés pour correspondre à plusieurs ressources.

• Condition (optionnel) : Définit les conditions sous lesquelles le statement sera effectif. Par exemple,

  "conditions": {
        "gateway_group_label": {
          "type": "MatchLabel",
          "options": {
            "key": "type",
            "operator": "exact_match",
            "value": "production"
          }
        }
      },
  

  Cela signifie que les opérations définies dans le statement ne seront autorisées que si l'étiquette du groupe de passerelles est définie sur "production".

Par exemple, pour créer une politique qui restreint un utilisateur à ne pouvoir éditer que tous les services publiés au sein d'un groupe de passerelles spécifique, vous pouvez l'écrire comme suit :

{
  "statement": [
    {
      "resources": [
        "arn:api7:gateway:gatewaygroup/{gateway group id}"
      ],
      "actions": [
        "<.*>Get<.*>" // Autoriser l'exécution de toutes les opérations commençant par 'Get', qui représentent la permission de 'lecture' pour le groupe de passerelles spécifié
      ],
      "effect": "allow" // Autoriser l'exécution des opérations définies ci-dessus
      // Note : Cette politique permet d'effectuer toutes les opérations 'Get' sur le groupe de passerelles spécifié, comme récupérer les informations du groupe de passerelles, lister les services au sein du groupe de passerelles, etc.
    },
    {
      "resources": [
        "arn:api7:gateway:gatewaygroup/{gateway group id}/publishedservice/<.*>",
      ],
      "actions": [
        "<.*>" // Autoriser l'exécution de toutes les opérations
      ],
      "effect": "allow" // Autoriser l'exécution des opérations définies ci-dessus
      // Cette politique permet d'effectuer toutes les opérations (créer, lire, mettre à jour, supprimer, etc.) sur les services publiés au sein du groupe de passerelles spécifié.
    }
  ]
}

Dans cet exemple, nous avons défini deux ensembles de ressources (groupe de passerelles et services publiés au sein du groupe de passerelles) et défini les actions autorisées pour chacun. Vous pouvez trouver des exemples courants de configuration de politiques dans le document Exemples de Politiques de Permissions. Pour les valeurs disponibles des ressources et actions et les API correspondantes, consultez le document Actions et Ressources des Politiques de Permissions.

Après avoir créé une politique, elle ne peut pas être directement attribuée aux utilisateurs ; nous devons d'abord attribuer la politique à des rôles spécifiques.

2. Créer des Rôles et Attacher des Politiques

Après vous être connecté à API7 Enterprise, cliquez sur le bouton "Organization" en haut à droite, puis sélectionnez l'élément de menu "Roles" dans le menu déroulant.

Dans la section Roles, vous pouvez gérer tous les rôles. Par défaut, il existe un rôle Super Admin en tant que rôle administrateur intégré.

Cliquez sur le bouton "Add Custom Role" en haut à droite pour accéder au formulaire de création de rôle. Ici, vous devez remplir les informations de base du rôle. Après la création, nous accéderons à la page de détails du rôle.

Dans la page de détails du rôle, cliquez sur le bouton "Attach Policy" pour attribuer les politiques de permissions précédemment créées au rôle.

Les politiques créées peuvent être réutilisées dans plusieurs rôles. Lorsqu'un rôle est associé à plusieurs politiques, ces politiques sont combinées par défaut. C'est-à-dire que les permissions d'un rôle sont la somme des permissions déclarées dans toutes les politiques associées. Après avoir créé un rôle et attaché des politiques, nous pouvons attribuer le rôle à des utilisateurs spécifiques.

3. Attribuer des Rôles aux Utilisateurs

Après vous être connecté à API7 Enterprise, cliquez sur le bouton "Organization" en haut à droite, puis sélectionnez l'élément de menu "Users" dans le menu déroulant.

Dans la section Users, vous pouvez gérer tous les utilisateurs. Par défaut, il existe un rôle admin en tant qu'administrateur intégré.

Dans la colonne d'actions à droite de la liste des rôles, cliquez sur "Update Roles" pour ouvrir le tiroir de formulaire de mise à jour du rôle d'un utilisateur spécifique.

Un utilisateur peut avoir plusieurs rôles. Lorsqu'un utilisateur se voit attribuer plusieurs rôles, les permissions sont combinées. C'est-à-dire que l'utilisateur dispose de la somme des permissions de tous les rôles.

Simplification du Mappage des Rôles

Avec l'optimisation et la mise à niveau du modèle de rôle utilisateur, le processus de mappage des rôles SSO a été simplifié. Désormais, lors de la configuration du mappage des rôles pour les options de connexion, il n'est plus nécessaire de définir des règles de correspondance au niveau des ressources pour chaque rôle individuellement. Les permissions des ressources et des opérations sont directement héritées des rôles intégrés sélectionnés, rendant la configuration des permissions plus intuitive et simplifiant la complexité de la gestion des permissions.

Résumé

L'introduction des politiques IAM a permis une configuration et une gestion des permissions plus flexibles. Cet ajustement améliore non seulement la sécurité du système, mais offre également aux utilisateurs une plus grande possibilité de personnalisation.

À l'avenir, nous continuerons à étendre les types de ressources pris en charge par les politiques IAM, en veillant à ce que toutes les ressources du système puissent être incluses dans une gestion granulaire des permissions, et en optimisant continuellement l'interface d'édition et de gestion des politiques, offrant aux utilisateurs une expérience de gestion des permissions plus complète et efficace.