Application des règles

Vous pouvez décider de la manière dont vous souhaitez appliquer une règle lors de sa création et mettre à jour l'application de la règle à tout moment.

Activé

Faire respecter la règle. Selon le service choisi, il est possible de surveiller les tentatives d'accès refusées à l'adresse Activity Tracker Event Routing. Consultez la documentation de chaque service pour savoir comment ils s'intègrent aux restrictions basées sur le contexte.

Désactivé

Aucune restriction ne s'applique aux ressources de votre compte. Sélectionnez cette option si vous n'êtes pas prêt à activer la règle.

Rapport uniquement

Selon le service sélectionné, vous pouvez contrôler l'impact d'une règle sur l'accès sans l'appliquer. En mode rapport uniquement, toutes les tentatives d'accès aux ressources du compte sont enregistrées sur Activity Tracker Event Routing. Si elle est disponible, la surveillance est recommandée pendant 30 jours avant d'appliquer une règle.

Le mode rapport seul n'étant pas disponible pour tous les services, il convient de consulter la documentation de chaque service pour savoir comment ils s'intègrent aux restrictions basées sur le contexte.

Vous pouvez contrôler l'impact de vos règles activées et de vos règles de rapport uniquement. Pour plus d'informations, voir Surveillance des restrictions basées sur le contexte.

Définir le champ d'application d'une règle

Définissez les API que vous souhaitez protéger afin de limiter la portée des restrictions d'une règle. De cette façon, vous pouvez spécifier des protections granulaires pour différentes API qui ont des exigences d'accès distinctes.

Par exemple, vous pouvez créer une règle qui cible une API de plan de données afin qu'elle ne soit accessible qu'à partir d'un cluster Kubernetes, ou de n'importe quel endroit où se trouve votre infrastructure informatique. Ensuite, vous pouvez créer une règle qui cible votre API de plan de contrôle et toutes les API de plateforme pour protéger les interactions avec la console en nuage afin qu'elle ne soit accessible que derrière le VPN de votre organisation.

Seuls certains services permettent de définir l'étendue d'une règle par API.

Avec certains services, vous pouvez restreindre par défaut les actions de toutes les API du service sur vos ressources, ce qui inclut toutes les API actuelles et futures que le service pourrait prendre en charge. Ou sélectionnez des API spécifiques. Par exemple, Kubernetes possède des API de services personnalisés dont vous pouvez restreindre l'accès en fonction du contexte de la demande. Consultez la documentation de chaque service pour en savoir plus sur la façon dont ils s'intègrent aux restrictions basées sur le contexte.

Certains services permettent d'étendre une règle à la protection de toutes les API de la plateforme, c'est-à-dire toutes les API actuelles et futures qu'un service pourrait prendre en charge. L'ajout d'API de plateforme à la portée d'une règle garantit que les opérations de plateforme telles que l'approvisionnement en ressources, la gestion des justificatifs de service et l'attachement de balises ne sont accessibles qu'à partir des emplacements que vous définissez.

Les restrictions basées sur le contexte protègent par défaut toutes les API du service et de la plateforme que le service cible prend en charge.

Zone réseau

Une zone réseau représente une liste d'adresses IP autorisées dans laquelle une demande d'accès est créée. Elle définit un ou plusieurs emplacements réseau qui sont spécifiés par les attributs suivants :

• Des adresses IP (adresses individuelles, plages ou sous-réseaux).
• Clouds privés virtuels
• Des références de service, qui autorise l'accès à partir d'autres services IBM Cloud®.

Type de nœud final

Un type de noeud final représente la connexion via laquelle une demande d'accès est reçue. Il correspond au noeud final qui reçoit la connexion. Vous pouvez autoriser l'accès depuis tous les types de noeud final pris en charge ou depuis des types de noeud final de services spécifiques.

Voici les trois types de noeud final courants :

• Les noeuds finaux publics peuvent accepter des demandes de n'importe quel emplacement.
• Des points d'accès privés sont disponibles pour la plupart des demandes émanant de IBM Cloud®.
• Les points d'extrémité directs sont utilisés dans les scénarios "Bring-Your-Own-IP", généralement pour les demandes provenant de ressources situées dans des VPC.

Certains types de noeud final peuvent ne pas être pris en charge par le service sélectionné.

Pour accéder aux points d'extrémité privés virtuels, les utilisateurs de la CLI doivent se connecter à l'aide de la commande ibmcloud login -a private.cloud.ibm.com --vpc. Pour plus d'informations, voir Création d'une passerelle de point d'extrémité privé(nécessaire pour l'utilisation de VPC).

Authentification multi-facteur

L'authentification multifactorielle (MFA) exige que les identités soient authentifiées en utilisant un autre facteur d'authentification que l'identifiant et le mot de passe. En définissant un niveau d'exigence MFA moins strict, vous permettez aux utilisateurs qui atteignent ou dépassent ce niveau de s'authentifier. Par exemple, si votre règle exige que les utilisateurs s'authentifient avec l'AFM LEVEL1, les utilisateurs qui ont l'AFM LEVEL2 sont toujours conformes puisque LEVEL2 dépasse les critères de sécurité de LEVEL1. Les niveaux d'AMF suivants indiquent le facteur d'AMF minimum pour chaque niveau. Pour plus d'informations, voir IBM Cloud authentification multifactorielle.

• LEVEL1: AMF par courrier électronique
• LEVEL2: TOTP AMF
• LEVEL3: Clé de sécurité MFA

En plus de LEVEL1, LEVEL2, et LEVEL3 MFA, la règle de restriction basée sur le contexte prend également en charge la valeur IAM_ACCOUNT_SETTING, ce qui signifie que la valeur MFA de la règle correspond à ce que vous définissez comme l'exigence MFA pour votre compte. Ainsi, toute modification des paramètres MFA de votre compte s'applique automatiquement à la règle. Pour plus d'informations, voir les options d'AMF.

Si une option est sélectionnée dans la section MFA pour les utilisateurs avec IBMid dans les paramètres d'authentification IAM, la valeur MFA d'IAM est mappée à LEVEL2 MFA dans les restrictions basées sur le contexte. L'AMF est appliquée aux utilisateurs fédérés et non fédérés, même si l'utilisateur non fédéré est sélectionné.

Seuls certains services permettent de spécifier l'AMF dans une règle.

Restrictions basées sur le contexte, les rôles et les actions

Pour gérer les zones du réseau, vous devez disposer d'une stratégie IAM avec un rôle spécifique pour le service de gestion des comptes de restrictions contextuelles. Le tableau suivant présente les rôles d'accès et les actions possibles pour la gestion des comptes.

Pour plus d'informations, voir Actions et rôles pour les services de gestion des comptes.

Vous pouvez également utiliser des zones réseau pour restreindre l'accès au niveau du compte. Pour définir des restrictions au niveau des comptes en utilisant des zones de réseau, allez dans Gérer > IAM > Paramètres dans la console IBM Cloud et entrez le nom de votre zone de réseau.

Rôles et actions des services cibles

Pour gérer les règles, vous devez disposer d'une stratégie IAM avec le rôle d'administrateur pour le service pour lequel vous créez la règle. Le tableau suivant présente les rôles d'accès et les actions possibles pour les services.

Cohérence à terme

Les restrictions basées sur le contexte suivent un modèle finalement cohérent qui est commun à de nombreux services natifs de l'informatique en nuage. Par conséquent, les restrictions contextuelles demeurent hautement disponibles et performantes dans plusieurs régions du monde. Les modifications apportées aux règles de restrictions contextuelles et aux zones réseau sont enregistrées et propagées dans le monde entier. Les modifications d'accès peuvent ne pas prendre effet tant que le processus de propagation n'est pas terminé, généralement en quelques minutes.