はじめに
IBM Cloudコンソールのトップにある「管理」メニューに表示される コンテキスト・ベースの制限(Context-base Restriction) と記載ありますが、あなたはいったい何者？
Qiitaに記事が見当たらなかったので、簡単にご紹介。
「どこからIBM Cloudのサービスを利用するか」を制限するもの
権限管理と言えば、一般的に Administrator, Operator, Writer, Reader といったように 何をして良いか？ を設定します。
IBM Cloudでは、IAMから各サービス単位でもそうですし、アカウント管理の権限についても細かく設定し安全な権限管理を実現できます。
Context-base Restrictionは、IAMの権限管理に 加えて 、どこからのアクセスに限定する、もしくは拒否するといった設定を行うことが可能です。
例えば、社用PCを家に持ち帰り、クローンしていたソースコードからコンテナを作成して、家からこっそりコンテナ等をデプロイしちゃえ！となっても、例えばContainer Registryのサービスを社内ネットワークからしかアクセスできないように塞いでおけば、セキュリティ対策をしていないネットワーク環境から何かしら更新される、というリスクを排除することができます。
これはICOSといったObject Storageサービスも同様で、昨今ランサムウェアもどこから侵入されるかわからないので、せめてセキュリティチェックが走る社内ネットワークは良いけど、自宅ネットワークからクラウドサービスにアクセスするのは勘弁してと考えるCSO、CISOも決して少なくないでしょう。
従来、各サービスのアクセス元IPアドレスによるフィルタリングといった機能は、サービス毎に実装されていましたが、これがContext-base Restrictionで一元的に実装されつつあります。
現在Context-base Restrictionに対応しているIBM Cloudのサービスは限定的です
IAM権限管理の延長線上のサービス
これでIPアドレス制限がいろんなサービスに設定できると思った方は注意が必要です。このアクセス管理はIAMの権限認証を通った後に行われます。
つまり、IAMの権限認証を通らない部分に制限をかけることはできません。
アクセス制限をかけられるもの
- ICOSのUploadやDownload
- Containre RegistryのコンテナのPush/Pull
- VPCのInstance作成や設定変更
アクセス制限をかけられないもの
- Code Engineにデプロイしたアプリケーション
- IKS/OpenShiftで外部公開したアプリケーション
- Context-base Restrictionに対応していないサービス
デプロイされたアプリケーションは、IBM CloudのIAMの認証を通過せずに、直接そのアプリケーションのエンドポイントへアクセスする形になるので、Context-base Restrictionの適用対象外になっています。
一方、ICOSへのアクセス権限はIAMで厳密に設定するため、ICOSへのファイルアクセス前には必ずIAMの認証を通過しています。こういったサービスではContext-base Restrictionの恩恵を受けることが出来ますね。
執筆した2024/7/26時点の情報では各対応サービス毎に以下のイメージでできる/できないが分かれます。
わかりやすく記述すると IBM Cloudのコンソール、もしくはCLIやAPIで操作可能な部分には対応可能、そうでない部分は対象外 になりますね。
| 対応サービス | できる | できない |
|---|---|---|
| Catalog Management Service | ・サービス自体の設定 ・特定のサービスのカタログにアクセスして良いアクセス元の設定 |
|
| Context-based restrictions Service | ・サービス自体の設定 | |
| IAM Access Groups Service | ・サービス自体の設定 | |
| IAM Access Management Service | ・サービス自体の設定 | |
| IAM Identity Service | ・サービス自体の設定 | |
| IAM User Management | ・サービス自体の設定 | |
| Activity Tracker | ・サービス自体の設定 | ・Activity Trackerに記録される操作者のアクセス元フィルタリング |
| App Configuration | ・サービス自体の設定 | |
| Cloud Object Storage | ・サービス自体の設定 ・Upload/Downloadの利用者 |
|
| Code Engine | ・サービス自体の設定 | ・アプリケーションのアクセス元フィルタリング |
| Container Registry | ・サービス自体の設定 ・Push/Pull |
|
| Databases for DataStax | ・サービス自体の設定 ・DBへのアクセス元フィルタリング |
|
| Databases for EnterpriseDB | ・サービス自体の設定 ・DBへのアクセス元フィルタリング |
|
| Databases for Elasticsearch | ・サービス自体の設定 ・DBへのアクセス元フィルタリング |
|
| Databases for etcd | ・サービス自体の設定 ・DBへのアクセス元フィルタリング |
|
| Databases for MongoDB | ・サービス自体の設定 ・DBへのアクセス元フィルタリング |
|
| Databases for MySQL | ・サービス自体の設定 ・DBへのアクセス元フィルタリング |
|
| Databases for PostgreSQL | ・サービス自体の設定 ・DBへのアクセス元フィルタリング |
|
| Databases for Redis | ・サービス自体の設定 ・DBへのアクセス元フィルタリング |
|
| Direct Link | ・サービス自体の設定 | ・通過するパケットのアクセス元フィルタリング |
| DNS Services | ・サービス自体の設定 | ・DNSを参照するアクセス元サービスのフィルタリング |
| Event Notifications | ・サービス自体の設定 ・イベントを連携するアクセス元サービスのフィルタリング |
|
| Log Analysis | ・サービス自体の設定 | ・Log Analysisに記録されるサービスのアクセス元フィルタリング |
| Event Streams | ・サービス自体の設定 | |
| Key Protect | ・サービス自体の設定 | |
| Kubernetes Service / Red Hat OpenShift | ・サービス自体の設定 | ・アプリケーションのアクセス元フィルタリング |
| Messages for RabbitMQ | ・サービス自体の設定 ・MQへのアクセス元フィルタリング |
|
| Secrets Manager | ・サービス自体の設定 | |
| Security and Compliance Center | ・サービス自体の設定 | |
| Transit Gateway | ・サービス自体の設定 | 通過するパケットのアクセス元フィルタリング |
| IBM Cloud® Virtual Private Cloud | ・サービス自体の設定 | ・作成されたIaaSに対するアクセス元フィルタリング |
| Schematics | ・サービス自体の設定 | ・デプロイのスクリプトがアクセスする先の外部サービスに対するフィルタリング |
サービスのどのレベルにまで制限をかけられるのか？
各指定可能なサービス毎に設定項目を洗い出しました。
Service ID と Instance IDは同じでは、と作りながら思ったりしましたが、UI上異なる名称なので仕方ありませんね…
例えば、Code Engineであれば、特定のロケーション(東京のみ)に制限をかけて、他のロケーションは変更可能としたり、IKSやOpenShift環境では特定のリソースグループのクラスターだけ制限をかける、といったことが可能です。
どうやって設定するか
サンプルとしてContainer Registryに対するアクセス制御の手順を紹介します。
現在どのような状態かというと、東京のContainer Registryに cbr-test-spaceと katahiro-space の2つにそれぞれ hello-world:latest のイメージが格納されている状態で、どちらも参照できています。
では、Context-base Restrictionの設定を行ってみましょう。
まず、Context-base Restrictionの設定ページで、ネットワークゾーン を選択し、どこからのアクセスを許可するかの設定から作ります。
設定が何もない人も多いと思いますが、右側から 作成 を選択します
名称と、今回は許可するIPアドレスに適当にですが 192.168.0.0/24 を指定しています。インターネット越しのアクセスを行うので、それが制限できればいったん登録するのは何でも良いです。企業であれば、企業ネットワークから外向きに出ていくProxyのグローバルIPアドレス等を入れて頂ければ、社内ネットワークからのアクセスに制限できます。
今回は、RFC1918のPrivate Networkで利用するIPアドレスを指定してみています。（つまりインターネットからのアクセスを許可しない)
設定に 許可されたVPC とあるように、アカウント内の特定のVPCからのみのアクセスに制限する、といった設定も可能です。
設定に問題が無ければ Create で作成してください。
これで無事にネットワーク制約が作成できました。先に制約を作成しておくと、後でサービス毎に許可設定を作成する際に流用がしやすくなり、対象ネットワークの変更が発生した際にネットワーク制約を変更すれば各サービスへの制約もまとめて変更することが可能になります。
さて、今度は対象のサービスに対して制約を作成するので、 ルール を選択します。
右側から 作成 を選びます
対象のサービスを選択します。今回は Container Registry を選択します。
デフォルトで設定されていますが、APIを通じた操作の全てを制限の対象とします。Container Registryはそれ以外の設定ができません。
今回はリソースを選択せずに、全てのリソースを対象とします。
※リソース選択する場合の動作の違いは後ほど紹介します。
エンドポイントタイプは特に指定せずに、許可されたネットワークゾーンとして、先ほど作成したネットワークゾーンを選択して 追加 します。
エンドポイントタイプを指定すると、パブリックエンドポイントだけや、プライベートエンドポイントだけ、といった制限をかけることも可能です
右側に表示されるルール内容に問題なければ 実行 を選択してください。
ネットワークゾーンの設定を複数作成していると、先ほどの画面でまとめてゾーンの設定が可能になります。
ルールを即時反映させるには 有効 を選択してください。こちらでは、逆に有効だったルールを 無効 に変更することや、 レポートのみ を利用して、制限はしないけれど、Activity Trackerにこの制限に抵触したことをレポートさせることも可能です。
今回は即時有効にするため、 有効 を選択して 作成 します
これで Containre Registry に対して 192.168.0.0/24 以外からのアクセスを許可しない設定ができました。
では、先ほどと同じように Container Registry に登録されたイメージ一覧を表示するコマンドを実行すると、インターネット越しにアクセスしている私の環境では何もみえなくなりました。
これで無事にIPアドレス制限をかけることが出来たことがわかります。
では、もう少し工夫して、指定可能なリソースに限定して制限をかけてみましょう。
先ほどは すべてのリソース に対して制限を行いましたが、特定のリソースとし、今回は cbr-test-space のみをその対象としています。
これでルールを更新して、Container Registryのイメージ一覧を表示すると下記のようになります。
cbr-test-space と katahiro-space の2つのNamespaceがありましたが、 cbr-test-space にのみIPアドレスの制限を入れたため、 cbr-test-space のイメージはインターネット越しに確認できなくなりましたが、何の制約も入っていない katahiro-space のイメージは見える状態になっています。
このようにサービス全体に制限をかけることができますし、条件を指定可能なサービスはその条件に合わせて制限をかけることも可能です。
さいごに
いかがでしたでしょうか？
Context-base Restrictionを利用すると、それに対応しているサービスについては一元的なアクセス制御を行うことが可能になり、サービスのパブリックエンドポイントを利用していたとしてもそのアクセス元を絞ることで、利用者にとって納得のいくセキュリティの構成に近づくことができるでしょう。
ただ、執筆時点では、まだContext-base Restrictionに対応していないサービスも多く、特にSaaS系サービスこそIPアドレス制限したいにも関わらず、対応していない、というのも多い状況です。
IBM Cloud上のサービスがことごとくContext-base Restrictionの対象となることを祈りながら、この記事を締めたいと思います。
読んで頂いた方はありがとうございました！