IBM Cloud: Customer portalにアクセスする際の許可リスト(FQDNベース）を調べてみた

#1. はじめに
特定のサイトにしかインターネットアクセスを許可していないというセキュリティーポリシーを持っている企業は少なからず存在しているはずである。。ほんこうでは、IBM CloudのCustomer Portalにアクセスする際にはどのようなFQDNに対してアクセス許可をしておけば良いかを調べてみた。

#2. 確認方法

以下のようにIBM cloud上の仮想サーバー上にProxyサーバー（squid)を構成し、端末からのブラウザアクセスは必ずsquid経由で通信するように構成した。

Firefoxの設定例。プロキシサーバーとしてsquidのIPアドレスを指定。

あとは、squidの設定を変更しながらsquidアクセスログを確認し、ちゃんとCustomer Portalが使えるかを確認してみた。

#3. 結論
Analytics目的で多くの3rd Party系サイトも利用しているようだが、そちらは必ずしもアクセスできていなくても良さそうではある。
実験してみると、/etc/squid/squid.confには以下を追加しておくと上手くいっているように思われる。

/etc/squid/squid.conf

#http_access allow localnet
#http_access allow localhost

• SSL-VPN経由の場合、クライアント端末には10.x.x.xのIPアドレスが割り当てられる。この設定を有効にしたままだと全部アクセスを許可してしまいテストにならないので、localhost/localnetからの通信は無効化する。(localnetには10.0.0.0/8がデフォルトで定義されている）

/etc/squid/squid.conf

acl SSL_ports port 443 30000-39999
acl Safe_ports port 80
acl Safe_ports port 443
acl Safe_ports port 30000-39999
acl CONNECT method CONNECT

#
# Recommended minimum Access Permission configuration:
#
# Deny requests to certain unsafe ports
http_access deny !Safe_ports

# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports

• 通常のアクセスはポート443だけを利用するが、PaaS系コンソールは443以外のポートを利用してHTTPS通信を行うものがあるため、SSL_portsとSafe_portsに追加。

/etc/squid/squid.conf

#Autehntication
acl ibmconsole dstdomain .cloud.ibm.com
acl ibmconsole dstdomain iam.bluemix.net
acl ibmconsole dstdomain login.ibm.com
acl ibmconsole dstdomain www.ibm.com
acl ibmconsole dstdomain login.w3.ibm.com
acl ibmconsole dstdomain w3id-ns.sso.ibm.com

#Classic Infrastructure: KVM console
acl ibmconsole dstdomain .iaas.service.networklayer.com

#PaaS
acl ibmconsole dstdomain .appdomain.cloud

#Docs
acl ibmconsole dstdomain ibm.biz

#Chat
acl ibmconsole dstdomain .lpsnmedia.net
acl ibmconsole dstdomain .liveperson.net

http_access allow ibmconsole

# And finally deny all other access to this proxy
http_access deny all

• Squidでは、.cloud.ibm.comと設定した場合は、cloud.ibm.comとそのサブドメインの両方を指す。
• cloud.ibm.comは、ざっとみただけでもこういうFQDNにアクセスしていたので、サブドメインレベルで定義した方が良さそう。
  • identity-2.ap-north.iam.cloud.ibm.com
  • cache.globalcatalog.cloud.ibm.com
  • us-south.certificate-manager.cloud.ibm.com
  • broker.dns-svcs.cloud.ibm.com
  • us-south.event-notifications.test.cloud.ibm.com
  • cloudshell-notification.us-south.cf.cloud.ibm.com
  • jp-tok-ng.iaas.cloud.ibm.com
  • PaaS系の例
    • ROKS: xxxx.jp-tok.containers.cloud.ibm.com:3xxxx
    • Db2 : xxx.db2.cloud.ibm.com
    • ICOS: xxx.xxx.cloud-object-storage.appdomain.cloud
• login.w3.ibm.comやw3id-ns.sso.ibm.comはIBM社員のIBM IDでログインする際の認証にのみ利用されているようなので、IBM社員がアカウントに参画していなければ不要。
• Classic InfrastructureのKVMコンソールはそもそもインターネット経由ではそもそも直接アクセスできないので不要と言えば不要なのだが、今回のようなProxy経由でPrivate NWにアクセスしてKVMコンソールを使いたいのであれば必要。ポート443以外でアクセスすることにも注意。
• PaaS系サービスを利用する場合は.appdomain.cloudを定義した方が良さそう。以下はPaaS系サービスにコンソールアクセスした際の例。ちなみに、.appdomain.cloudはSOAレコードなどをチェックすればIBM管理のドメインであることがわかる。
  • ROKS: console-openshift-console.xxxx.jp-tok.containers.appdomain.cloud
  • Db2 : xxxxx.db2.databases.appdomain.cloud
• Customer Portalで、IBM Cloud docsへのリンクを短縮URL(ibm.biz)を使っている箇所が。これも別途許可するかはオプションだと思われる。
• CaseではなくChatを利用するためにはliveperson系サービスに対するFQDNへのアクセス許可が必要。

もしこれが漏れているのではないか？というコメントがあったら教えてください。