#1. はじめに
IBM Cloudのcustomer portalへのアクセス制限については、
- ユーザーレベルでのIPアドレス制限
- アカウントレベルでのIPアドレス制限
の2つが存在する。この制限方法の仕様について挙動を確認してみた。
参考ドキュメント
https://cloud.ibm.com/docs/account?topic=account-ips&interface=ui
#2. 検証結果
##検証1: 新規ログインとログイン済みのセッションの挙動
| テストケース概要 | 結果 | |
|---|---|---|
| 1 | 許可しているIPアドレスからの新規ログイン | ログイン可能 |
| 2 | 許可していないIPアドレスからの新規ログイン | ログイン不可 。ただし、以下の矢印から別アカウントにスイッチは可能
|
| 3 | 別アカウントに新規ログインした後に、対象アカウントにスイッチ | スイッチ不可。 
|
| 4 | すでにログイン済みの状態で、そのユーザーに対して既存のIPアドレスからアクセスできないように設定 | そのままアクセスできた。一旦ログアウトして再度ログインしたらログイン不可となった。 |
| 5 | アクセスを許可しているアドレスから一旦ログインした後、端末のIPアドレスを許可されていないアドレスに変更 | そのままアクセスできた。このあと、他のアカウントにスイッチして戻ってきても、やはりブロックされずにそのままアクセスできた。 |
以上の結果より、IPアドレス制限のチェックはログインの時にしか実施しておらず、一旦ログインさえできてしまえばそのセッションは影響を受けないようだ。
逆に5の結果からすると、一旦ログインできた状態で、その端末を別の場所に持ち出しても継続して一定時間はアクセスできてしまうことがわかる。デフォルト値は以下のようになっているため、場合によってはこのあたりのセッション時間を短くすることも考慮した方が良さそうだ。
##検証2: ユーザーレベルの設定とアカウントレベルの設定の組み合わせ
| テストケース概要 | 結果 | |
|---|---|---|
| 1 | アカウントレベルでは許可されているが、ユーザーレベルでは許可されていないIPアドレスからの新規ログイン | ログイン不可 |
| 2 | アカウントレベルでは許可されていないが、ユーザーレベルでは許可されているIPアドレスからの新規ログイン | ログイン不可 |
| 3 | アカウントレベルでもユーザーレベルでは許可されているIPアドレスからの新規ログイン | ログイン可 |
ユーザーレベルがアカウントレベルより優先される訳でもなく、両方設定している場合は両方の条件が満たされていないとログインできなかった。基本のアクセス制限はアカウントレベルで一律に実施し、特別なユーザーに限ってはさらにそこから絞り込むという使い方を想定しているのかもしれない。IBM Cloud docsにも以下のような記載があった。
If an IP address restriction is defined for both the account and the user, the IP address needs to match both specifications to be able to generate an IAM token.