Restriction de l'accès par contexte de réseau

Les restrictions basées sur le contexte permettent aux administrateurs de limiter l'accès aux ressources. Que faire si certaines données ne doivent être accessibles qu'à partir de réseaux de confiance ? Une règle correctement configurée restreint tous les accès aux données sauf si la demande provient d'une zone réseau approuvée et d'un type de noeud final (public, privé ou direct).

Utilisation des restrictions basées sur le contexte

Une restriction basée sur le contexte est constituée d'une règle et d'un ou de plusieurs contextes (zones réseau et / ou type de noeud final). Ces restrictions ne remplacent pas les règles IAM, mais vérifient simplement qu'une demande provient d'un contexte autorisé, tel qu'une plage d'adresses IP, de VPC ou de références de service.

Un utilisateur doit avoir le rôle Administrator sur un service pour créer, mettre à jour ou supprimer des règles. Un utilisateur doit disposer du rôle Editor ou Administrator pour créer, mettre à jour ou supprimer des zones réseau.

Les restrictions basées sur le contexte ne prennent pas en charge l'application de règles de restrictions basées sur le contexte à des objets ou des dossiers spécifiques, uniquement au niveau du compartiment.

Vous pouvez en savoir plus sur le fonctionnement des restrictions contextuelles dans la documentation détaillée ou suivre un tutoriel rapide.

Les événements de journal d'audit générés proviendront du service de restrictions contextuelles et non de Object Storage.

Si aucune règle n'est applicable à une ressource particulière, l'accès est déterminé par les règles IAM et la présence d'un pare-feu de compartiment existant.

Les restrictions contextuelles sont uniquement appliquées au niveau du compartiment et non à des objets ou des dossiers spécifiques.

Un compte est limité dans le nombre de règles et de zones réseau pouvant être prises en charge.

Pare-feux de compartiment et restrictions contextuelles

Avant la disponibilité des restrictions contextuelles, Object Storage lui-même imposerait des restrictions d'accès basées sur les adresses IP. Bien que cette méthode soit toujours prise en charge, il est recommandé d' utiliser les nouvelles restrictions contextuelles à la place du pare-feu de compartiment existant.

Les pare-feux de compartiment et les restrictions basées sur le contexte fonctionnent indépendamment les uns des autres, ce qui signifie qu'il est possible d'avoir une demande autorisée par l'un et refusée par l'autre.

Les demandes de création de compartiment doivent être autorisées par des restrictions contextuelles.
Pour toutes les autres demandes de compartiment ou d'objet, les restrictions contextuelles et le pare-feu de compartiment doivent autoriser la demande.

Une adresse IP autorisée par des restrictions contextuelles peut toujours être refusée par le pare-feu de compartiment.

A propos des pare-feux de compartiment existants

Certaines règles s'appliquent lors de la définition d'un pare-feu :

Un utilisateur qui définit ou visualise un pare-feu doit posséder le rôle Manager sur le compartiment.
Un utilisateur disposant du rôle Manager sur le compartiment peut afficher et éditer la liste des adresses IP autorisées à partir de n'importe quelle adresse IP pour empêcher les verrouillages accidentels.
La console Object Storage peut toujours accéder au compartiment, à condition que l'adresse IP de l'utilisateur soit autorisée.
Les autres services IBM Cloud ne sont pas autorisés à contourner le pare-feu. Cette limitation signifie que les autres services dont l'accès au compartiment est régi par des règles IAM (tels que Aspera, SQL Query, Security Advisor, Watson Studio, Cloud Functions, etc.) ne seront pas en mesure d'accéder au compartiment.

Lorsqu'un pare-feu est défini, le compartiment est isolé du reste d'IBM Cloud. Tenez compte de l'impact de ceci sur les applications et les flux de travaux qui dépendent des autres services qui accèdent directement à un compartiment, avant d'activer le pare-feu. Cela peut être évité en utilisant des références de service et des restrictions contextuelles à la place.

L'accès à partir d'un environnement VPC peut passer des vérifications allowed_network_type et des adresses IP de sous-couche de zone VPC peuvent être ajoutées à la liste allowed_ip. Il n'est pas possible de restreindre l'accès à une adresse IP de superposition pour une instance de serveur virtuel VPC individuelle ou un serveur bare metal.

Tout d'abord, vérifiez que vous disposez d'une instance de Object Storage et que vous avez mis à disposition au moins un compartiment. Si ce n'est pas le cas, suivez le tutoriel d'initiation pour obtenir les prérequis et vous familiariser avec la console.

Définition d'une liste d'adresses IP autorisées à l'aide d'un pare-feu existant

Commencez par sélectionner Stockage pour afficher votre liste de ressources.
Sélectionnez ensuite l'instance de service contenant votre compartiment à partir du menu Stockage. Vous accédez ainsi à la console Object Storage.
Choisissez le compartiment pour lequel vous souhaitez limiter l'accès à des adresses IP autorisées.
Sélectionnez Règles d'accès dans le menu de navigation.
Sélectionnez l'onglet Adresses IP autorisées.
Cliquez sur Ajouter des adresses IP, puis choisissez Ajouter.
Spécifiez une liste d'adresses IP en notation CIDR, par exemple 192.168.0.0/16, fe80:021b::0/64. Les adresses peuvent suivre les normes IPv4 ou IPv6.
Cliquez sur Ajouter.
Le pare-feu ne sera pas appliqué tant que l'adresse ne sera pas sauvegardée dans la console. Cliquez sur Sauvegarder tout pour appliquer le pare-feu.
Notez que tous les objets de ce compartiment ne sont accessibles qu'à partir de ces adresses IP.

Supprimer les restrictions d'adresse IP à l'aide d'un pare-feu existant

Dans l'onglet Adresses IP autorisées, cochez les cases en regard des adresses IP ou des plages à retirer de la liste d'adresses autorisées.
Sélectionnez Supprimer, puis confirmez la suppression en cliquant à nouveau sur Supprimer dans la boîte de dialogue qui s'affiche.
La liste d'adresses mise à jour ne sera pas appliquée tant que les modifications ne seront pas sauvegardées dans la console. Cliquez sur Sauvegarder tout pour appliquer les nouvelles règles.
Désormais, tous les objets de ce seau ne sont accessibles qu'à partir de ces adresses IP!

Si aucune adresse IP autorisée n'est répertoriée, cela signifie que les politiques IAM normales s'appliqueront au seau, sans restrictions sur l'adresse IP de l'utilisateur, à moins que des restrictions contextuelles ne soient en place.

Mise en place d'un ancien pare-feu par le biais d'une API

Les pare-feu sont gérés à l'aide de l'API de configuration des ressources COS. Cette nouvelle API REST est utilisée pour la configuration des compartiments.

Les utilisateurs disposant du rôle manager peuvent afficher et éditer la liste des adresses IP autorisées à partir de n'importe quel réseau pour empêcher les verrouillages accidentels.