Objectifs

• Découvrez les restrictions contextuelles pour protéger vos ressources de cloud
• Définir des zones réseau pour identifier les sources de trafic pour les accès autorisés et refusés
• Créez des règles qui définissent le contexte pour l'accès à vos ressources de cloud
• Découvrez comment tester et contrôler les règles de contexte

Le diagramme suivant illustre l'architecture de la solution telle qu'elle est utilisée dans le tutoriel Application de la sécurité de bout en bout à une application cloud. Les cases supplémentaires avec des lignes bleues en pointillés autour du cluster Kubernetes Service, Container Registry, Key Protectet Object Storage dénotent des restrictions contextuelles implémentées en tant que règles de contexte. Notez que Secrets Manager aurait également pu être protégé, mais qu'il ne s'agit que d'un service facultatif et qu'il n'est pas utilisé dans ce tutoriel.

Avant de commencer

Pour ce tutoriel, vous devez disposer des éléments suivants :

• IBM Cloud CLI,
• Client docker pour envoyer et extraire des images de conteneur.

Vous trouverez les instructions pour télécharger et installer ces outils pour votre environnement d'exploitation dans le guide " Getting started with solution tutorials ".

Pour éviter l'installation de ces outils, vous pouvez utiliser Cloud Shell à partir de la console IBM Cloud.

Configuration

Dans une étape ultérieure, Utiliser Terraform pour configurer des restrictions basées sur le contexte, vous allez déployer des objets CBR en tant que couche de sécurité supplémentaire sur les ressources utilisées dans le tutoriel Appliquer la sécurité de bout en bout à une application cloud.

1. Déploiement de ressources à l'aide de Terraform géré par Schematics comme décrit dans le référentiel GitHub associé.

2. Le IBM Cloud Activity Tracker Event Routing doit être configuré pour acheminer les événements d'audit vers une instance cible IBM Cloud Logs Acheminez les événements d'audit comme décrit dans la configuration d'une cible IBM Logs si celle-ci n'est pas encore configurée dans votre compte.

Présentation: Restrictions basées sur le contexte

Les restrictions basées sur le contexte(CBR) permettent de définir et d'appliquer des restrictions d'accès pour les ressources IBM Cloud en fonction de l'emplacement réseau et du type de demande d'accès. Étant donné que les politiques IAM et les restrictions basées sur le contexte imposent l'accès, les restrictions basées sur le contexte offrent une protection même en cas de compromission ou de mauvaise gestion des informations d'identification.

Une règle régit l'accès à une ressource identifiée par son nom et son type de service, ainsi que par des attributs supplémentaires. Ils peuvent inclure la région, le groupe de ressources et d'autres propriétés spécifiques au service. Les attributs d'une règle sont pour la plupart facultatifs, de sorte que vous pouvez gouverner, par exemple, toutes les instances Key Protect ensemble ou cibler uniquement un fichier de clés spécifique dans une instance Key Protect identifiée.

Le contexte d'une restriction est constitué de zones réseau et de noeuds finaux de service. Vous pouvez définir des zones en fonction d'adresses IP ou de plages spécifiques, ou en configurant le trafic provenant d'un ou de plusieurs VPC ou services cloud. Ainsi, l'accès à l'exemple d'instance Key Protect peut uniquement être autorisé à partir, par exemple, d'une instance Object Storage spécifique, d'une plage bien connue d'adresses IP et uniquement via le noeud final privé.

Les zones réseau peuvent être utilisées pour la définition de plusieurs règles. Les règles ont un mode de mise en application qui est l'un des modes désactivé, rapport uniquement ou activé.

A l'heure actuelle, tous les services de cloud ne prennent pas en charge le mode de génération de rapports uniquement. De plus, ces services ne génèrent aucune entrée de journal associée à CBR lorsqu'ils sont activés. Pour plus de détails, consultez la documentation du service individuel.

Créer une zone et une règle

Pour évaluer l'impact des restrictions contextuelles, vous allez créer une règle régissant l'accès à un espace de nom dans Container Registry. Vous commencez par créer cet espace de nom, puis une zone réseau pour identifier un VPC comme source de trafic.

1. Allez dans les espaces de nomsContainer Registry et notez le nom de l'espace de noms configuré précédemment.
2. Dans la console IBM Cloud, cliquez sur le menu Gérer et sélectionnez Restrictions contextuelles. Dans la page de présentation, cliquez sur Créer une zone réseau.
3. Entrez VPCzone comme nom. Sous VPC autorisés, sélectionnez celui avec votre cluster Kubernetes Service. Cliquez sur Suivant pour vérifier, puis sur Créer la zone.
4. Créez ensuite une règle à l'aide de la zone en cliquant sur Règles dans la navigation de gauche, puis sur Créer.
5. Sélectionnez Container Registry dans la section Service et cliquez sur Suivant.
6. Laissez la section API avec Toutes les API de service cliquez sur Suivant.
7. Ensuite, sous Ressources, choisissez Ressources spécifiques. Sélectionnez Type de ressource comme attribut et spécifiez namespace comme valeur. Ajoutez une autre condition et configurez le nom de la ressource comme NAMESPACE (la même valeur qu'à l'étape 1). Cliquez sur Révision, puis sur Continuer.
8. Sélectionnez la zone VPCzone que vous avez créée précédemment dans la liste. Utilisez ensuite Ajouter et Continuer pour accéder à la dernière étape de la boîte de dialogue. Marquez Enforcement comme Report-only. Ensuite, créer la règle.

Sachez que les zones et les règles CBR sont déployées de manière asynchrone. Cela peut prendre jusqu'à quelques minutes pour qu'ils deviennent actifs (éventuellement cohérents).

Tester la règle et ses modes d'application

1. Dans un nouvel onglet du navigateur, ouvrez le serviceIBM Cloud Logs, sélectionnez l'onglet Cloud Logs et cliquez sur le nom de l'instance qui reçoit les événements d'audit.

2. Démarrez une nouvelle session de IBM Cloud Shell dans un autre onglet de navigateur.

3. Dans le shell, exécutez les commandes suivantes: Définissez une variable d'environnement pour la région de cloud que vous allez utiliser pour Container Registry, par exemple us ou de.

   export REGION=us
   

   Définir une autre variable pour l'espace de noms Container Registry

   export NAMESPACE=<YOUR_NAMESPACE>
   

   Connectez-vous maintenant à Container Registry.

   ibmcloud cr login
   

   Ensuite, extrayez une image de conteneur dans l'environnement shell.

   docker pull docker.io/library/hello-world:latest
   

   Balisez à nouveau l'image pour la télécharger dans votre espace de nom de registre.

   docker tag docker.io/library/hello-world $REGION.icr.io/$NAMESPACE/hello-world
   

   Enfin, pousser l'image du conteneur dans le registre.

   docker push $REGION.icr.io/$NAMESPACE/hello-world
   

4. Passez à l'onglet du navigateur avec le IBM Cloud Logs montrant les journaux d'audit. En mode rapport, les entrées de journal sont écrites dans IBM Cloud Activity Tracker Event Routing lorsqu'une règle correspond, quel que soit le résultat de la décision. L'enregistrement de journal contient des détails sur la demande. Dans l'image ci-dessous, la règle autorisant l'accès à l'espace de noms Container Registry correspond au mode rapport.

   

   Comme indiqué, en mode rapport, toutes les demandes correspondantes génèrent une entrée de journal. Dans les détails de l'événement, vous voyez un attribut decision avec la valeur Autoriser ou Refuser. Dans la capture d'écran ci-dessus, il s'agit de Refuser.

5. Revenez dans l'onglet du navigateur avec le shell et répertoriez les images de conteneur dans l'espace de nom.

   ibmcloud cr images --restrict $NAMESPACE
   

6. Dans un troisième onglet de navigateur, accédez aux règles CBR. En regard de la règle liée au registre que vous avez créée précédemment, cliquez sur le menu des points et sélectionnez Editer. Accédez à Décrire votre règle (étape 3) et passez de Rapport uniquement à Activé. Activez la modification en appuyant sur le bouton Appliquer.

7. Revenez à l'onglet du navigateur avec IBM Cloud Shell. Exécutez la même commande que précédemment pour répertorier les images:

   ibmcloud cr images --restrict $NAMESPACE
   

   Cette fois, un message d'erreur indiquant que vous n'êtes pas autorisé s'affiche.

8. Dans l'onglet du navigateur contenant les journaux, vous devez trouver un nouvel enregistrement similaire au suivant:

   

   La règle a été appliquée et, en fonction de la manière dont vous avez tenté d'accéder au registre, l'accès a été refusé. La raison en est que la règle autorise l'accès à partir d'un VPC spécifique uniquement. L'environnement Cloud Shell et son adresse IP, tels que documentés dans les journaux dans les champs requestData->environment, diffèrent. Par conséquent, la demande est refusée.

Lorsque vous travaillez avec les journaux IBM Cloud Logs, vous pouvez utiliser des chaînes de requête telles que les suivantes pour trouver facilement les enregistrements pertinents :

• En mode rapport, "context restriction" permit OR deny renvoie les lignes de journal avec accès qui auraient rendu une autorisation ou refus.
• En mode rapport, vous pouvez utiliser "context restriction" permit pour afficher uniquement l'accès qui aurait été autorisé. De même, utilisez "context restriction" deny pour les accès refusés.
• En dernier lieu, en mode appliqué, utilisez une chaîne de requête telle que context restriction rendered pour les lignes de journal associées à un accès refusé.

Il est recommandé de surveiller une nouvelle règle pendant 30 jours avant de l'appliquer. Pour en savoir plus sur les restrictions contextuelles de contrôle en mode rapport uniquement et en mode activé, consultez la documentation CBR.

Pour préparer le déploiement d'objets CBR avec Terraform dans une section plus bas, accédez à l'onglet du navigateur avec les règles CBR. Dans ce cas, supprimez la règle précédemment créée en cliquant sur son menu en points et en sélectionnant Supprimer, puis en la confirmant avec Supprimer. Ensuite, cliquez sur Zones réseau et supprimez la zone précédemment créée.

Définissez la stratégie d'accès pour vos ressources de cloud

Pour configurer l'ensemble de règles approprié pour les restrictions basées sur le contexte (CBR), vous devez avoir défini la stratégie d'accès pour vos ressources de cloud. Toutes les ressources doivent être protégées par la gestion des identités et des accès (IAM). Cela signifie que les vérifications d'authentification et d'autorisation doivent être effectuées avant qu'un utilisateur ou un ID de service n'accède à une ressource. Les CBR ajoutent à la protection en coupant l'accès au réseau en fonction de critères d'origine et d'autres règles, mais ils ne remplacent pas la configuration IAM appropriée. De plus, de nombreux services prennent en charge la limitation du trafic réseau aux noeuds finaux privés, ce qui réduit déjà les options d'accès.

Certaines règles peuvent avoir un impact sur le confort d'administration des ressources, par exemple via la console du navigateur. De plus, vous devez vous assurer que vous ne vous refusez pas l'accès aux ressources, aux tableaux de bord de gestion et aux API. Par conséquent, vous devez prendre en compte les hôtes bastion, les réseaux d'entreprise, les passerelles et peut-être même Cloud Shell. En outre, certains services prennent en charge une distinction à granularité fine entre le plan de données et l'accès aux lieux de contrôle pour la configuration CBR, par exemple, API de gestion et de clusterKubernetes Service.

En résumé, ces questions doivent être posées:

• Toutes les ressources sont-elles protégées par IAM et similaires?
• Comment les ressources sont-elles accessibles, sont-elles déjà limitées aux noeuds finaux privés dans la mesure du possible?
• Est-il possible de séparer le plan de données et l'accès au plan de contrôle?
• Qu'est-ce que le trafic est lié à l'utilisation, à quel travail administratif? Comment les urgences sont-elles traitées?
• D'où provient le trafic ci-dessus?

Utilisez le mode de rapport pour connaître les activités correspondant aux restrictions contextuelles. Les décisions basées sur des règles rendent-elles une autorisation ou un refus? Cela correspond-t-il à vos attentes? Pour en savoir plus sur les activités et les gérer correctement avec les règles CBR, une phase de test en mode de génération de rapports d'au moins un mois est recommandée. Cela permet une approche itérative de l'ensemble souhaité de zones réseau et de règles de contexte.

Pour ce tutoriel, nous allons définir les zones réseau suivantes:

• une zone pour le cluster Kubernetes Service
• une zone pour Object Storage
• pour une plage d'adresses IP avec les adresses d'un réseau domestique (entreprise ou bastion) devant servir de zone d'accueil

Par la suite, nous allons définir les règles de contexte comme suit:

• pour l'accès à l'instance Key Protect à partir des zones:
  • Cluster Kubernetes Service
  • Object Storage
• pour l'accès à l'instance Object Storage et à son compartiment à partir des zones:
  • Cluster Kubernetes Service
  • zone d'origine
• pour l'accès à Container Registry et à l'espace de nom avec l'image de conteneur à partir des zones:
  • Cluster Kubernetes Service
• pour l'accès au cluster Kubernetes Service et à son API de gestion depuis les zones:
  • zone d'origine

Toutes les zones et règles ci-dessus peuvent être déployées en mode rapport uniquement ou en mode appliqué à l'aide d'une seule commande Terraform. Notez que les règles ne sont pas destinées à une utilisation en production, mais à titre d'exemple pour examiner l'utilisation et le trafic en mode rapport uniquement.

La documentation contient une liste de ressources prises en charge en tant que références de service. Vous pouvez également extraire la liste à l'aide de la commande d'interface de ligne de commande service-ref-targets ou de la fonction d'API associée Répertorier les cibles de référence de service disponibles.

Utiliser Terraform pour configurer des restrictions contextuelles

Au lieu de créer manuellement les zones réseau et les règles de contexte pour un projet, il est recommandé d'automatiser le déploiement. Les restrictions basées sur le contexte peuvent être déployées en utilisant l'infrastructure sous forme de code (IaC), à savoir le code Terraform. Vous pouvez d'abord déployer les zones et les règles avec des règles en mode rapport uniquement à des fins de test. Ensuite, après des tests approfondis, passez en mode appliqué en mettant à jour la configuration déployée.

resource "ibm_cbr_zone" "cbr_zone_k8s" {
  account_id = data.ibm_iam_account_settings.team_iam_account_settings.account_id
  addresses {
    type = "serviceRef"
    ref {
      account_id       = data.ibm_iam_account_settings.team_iam_account_settings.account_id
      service_instance = data.ibm_container_vpc_cluster.cluster.id
      service_name     = "containers-kubernetes"
    }
  }
  description = "Zone with the Kubernetes cluster"
  name        = "cbr_zone_k8s"
}

resource "ibm_cbr_rule" "cbr_rule_cos_k8s" {
  contexts {
    attributes {
      name  = "networkZoneId"
      value = ibm_cbr_zone.cbr_zone_k8s.id
    }
  }
  contexts {
    attributes {
      name  = "networkZoneId"
      value = ibm_cbr_zone.cbr_zone_homezone.id
    }
  }

  description      = "restrict COS access, limit to cluster"
  enforcement_mode = var.cbr_enforcement_mode
  resources {
    attributes {
      name  = "accountId"
      value = data.ibm_iam_account_settings.team_iam_account_settings.account_id
    }
    attributes {
      name     = "serviceInstance"
      operator = "stringEquals"
      value    = var.cos.guid
    }
    attributes {
      name     = "serviceName"
      operator = "stringEquals"
      value    = "cloud-object-storage"
    }
  }
}

Tester les règles de contexte

Une fois l'ensemble de restrictions basées sur le contexte déployé, il est temps de les vérifier et de les tester. Pour vérifier les objets CBR, accédez à la présentation des restrictions basées sur le contexte. Ensuite, inspectez les nouvelles zones et les règles.

Les tests doivent être effectués sur Container Registry, Object Storage et Key Protect et validés en surveillant les journaux comme précédemment. Etant donné que les zones et les règles incluent une restriction d'accès sur Container Registry, vous pouvez répéter les tests effectués dans la section Test de la règle et de ses modes d'application.

Pour tester la nouvelle règle d'accès à Object Storage, procédez comme suit:

1. Dans un onglet de navigateur, accédez à la liste des instances Object Storage. Cliquez sur le nom de service du tutoriel, par exemple secure-file-storage-cos.
2. Dans un deuxième onglet du navigateur, visitez le tableau de bord IBM Cloud Logs déjà utilisé avec les journaux d'audit.
3. Dans l'onglet contenant la présentation de Object Storage, dans la liste Compartiments, cliquez sur le compartiment de stockage.
4. Utilisez Télécharger pour importer un fichier dans le compartiment. Conservez la valeur Transfert standard et utilisez la zone Télécharger les fichiers (objets) pour sélectionner un fichier. Terminez en cliquant sur Upload.
5. De retour dans l'onglet du navigateur avec les journaux d'audit, il devrait y avoir des enregistrements de journaux liés à CBR intitulés Context restriction matched while in report mode. Cela est dû au fait que les règles ont été déployées en mode rapport. Développez certains enregistrements pour vérifier la décision et les données isEnforced signalées. En fonction de la plage d'adresses IP configurée pour la zone d'origine, la décision peut être Autorisation ou Refus. La valeur de isEnforced doit être false en raison du mode de génération de rapports.

Pour des tests supplémentaires, vous souhaiterez peut-être modifier la plage d'adresses IP de la zone d'origine. Il s'agit de la variable homezone_iprange dans les paramètres Schematics.

Suppression de ressources

Pour supprimer la ressource, utilisez le navigateur et accédez à la présentation des espaces de travailIBM Cloud Schematics. Sélectionnez l'espace de travail, puis dans le menu Actions, sélectionnez d'abord Détruire les ressources, puis utilisez Supprimer l'espace de travail.

Contenu connexe

• Article de blogue Towards Zero Trust with Context-Based Restrictions
• Article de blogue Présentation des restrictions basées sur le contexte
• Qu'est-ce que Zero Trust?
• Bonnes pratiques en matière d'organisation des utilisateurs, des équipes et des applications