IBM Cloud から提供されている、Web コンテンツ向けにセキュリティやパフォーマンスといった非機能要件を統合的に設計するサービス、それが CIS(Cloud Internet Services)です。mybluemix.net などの IBM Cloud から提供される標準ドメインではなく、独自ドメインを使うことが前提となりますが、そのドメインで運用するウェブアプリケーションやコンテンツ全般を保護して、安全なインターネット環境を提供することができる便利なサービスです:

https://www.ibm.com/jp-ja/cloud/cloud-internet-services
2019111600


この CIS は(独自ドメインの)DNS を使うことでオリジンサーバーとは別の( Cloudflare 社の)サーバーを経由してオリジンサーバーにアクセスします。この中間サーバーを経由することで必要なセキュリティ要件やコンテンツ保護要件を提供する、というものです。

この CIS を利用して、クライアント(ウェブブラウザ)からの SSL(https) 通信を実現するには大きく3種類の方法があります:

(1)クライアント→中間サーバー→オリジンサーバー 間すべての通信をセキュアに行う方法
(2)クライアント→中間サーバー 間はセキュアに行い、 中間サーバー→オリジンサーバー 間の通信は自己証明書を使った暗号化通信を行う方法
(3)クライアント→中間サーバー 間はセキュアに行い、 中間サーバー→オリジンサーバー 間の通信は HTTP 通信で行う方法
2019110703


①、②、③いずれも共通でクライアントと中間サーバーとの間はセキュアな SSL 通信を行います。中間サーバーとオリジンサーバー間の通信をどう考えるか、という点が異なります。ざっくりいうと①がもっともセキュアで、③がもっともセキュアでない方法となります。

①は理想的といえる方法で、全ての区間がセキュアな通信となります。②も通信自体は SSL で暗号化通信となりますが、その際に利用する証明書はいわゆる「自己証明書」となります。①と比較すると(外部の業者などを使わずに)自分で証明書を作ることができるので、コストや有効期限の自由度などの面でメリットがありますが、「要は誰でも(ドメインのオーナーでなくても)作れる証明書」を使った暗号化通信を行う点が異なります。この証明書を普通に使って直接 SSL 通信を行うと、普通は「セキュアな通信でないが、それでも通信するか?」といった確認メッセージを経て通信可能になったりしますが、中間サーバーとして CIS を入れることにより、クライアントはそういった手順を経ずに通信できるようになります。

そして③の方法ですが、これは中間サーバーとオリジンサーバーとの間の通信は暗号化しない方法です。セキュアかどうか、という観点では暗号化しない経路が存在しているわけで他の2つよりは劣っています。一方で、この方法では証明書の作成を必要としません。クライアントから見た証明書は CIS の中間サーバーが自動で発行されたものが使われ、オリジンサーバーには(そもそも暗号化通信をしないので)証明書が不要です。開発段階や試験段階など、インフラに関わる権限が小さい状況下で、かつ(API の仕様など)https 通信が必須となるような場合においては非常に有要な選択肢となります。またこの方法であれば(そもそも取得しないので)証明書の有効期限切れを心配する必要もありません。 また特にオリジンサーバーとして IBM Cloud の PaaS 環境を利用する場合であれば、オリジンサーバーのルーティングを編集してカスタムドメインでのホスト名でしかオリジンサーバーにアクセスできないように設定することで(HTTPS を使わずにアクセスするような)迂回路を遮断する設定にすることも可能です。

今回はこの③の方法でカスタムドメインの https アクセスを行うための設定を紹介します。

まず IBM Cloud の CIS サービスを利用してプロビジョン済みの状態とし、普通にドメインを登録して設定します。その上で「セキュリティ」カテゴリーの「TLS」内で動作モードを「クライアントからエッジ」に設定します(これが③の通信のための設定となります):
2019110701


なお、このモードの設定内容によって上記図の①~③の通信方法が変わります。以下のような関係です:
2019110704


また DNS の CNAME でオリジンサーバーとの紐付けを行います(下図の「信頼性」-「DNS」)。このカスタムドメインの頭につけるホスト名を指定して、CNAME の参照先となる別名を指定します。IBM Cloud の PaaS (米国南部リージョン)を使う場合は参照先を us-south.cf.cloud.ibm.com を指定します。また「プロキシー」を有効にします:
2019110702


なお、ここで指定する参照先と IBM Cloud PaaS のリージョンとの関係については以下を参照ください:
https://cloud.ibm.com/docs/cloud-foundry-public?topic=cloud-foundry-public-custom-domains

最後にオリジンサーバー側を用意します。IBM Cloud PaaS の場合であれば(CNAME で指定した名前).mybluemix.net でアクセスできるようなアプリケーションサーバーを CloudFoundry ランタイムとして作成します(このルーティングは最終的に削除します)。


また IBM Cloud PaaS の場合は「管理」メニューからカスタムドメインを登録する必要があります。この手順の詳細はこちらを参照ください(このリンク先では証明書をインポートする手順まで紹介していますが、今回ここでは SSL の設定を行う必要がないので不要です):
http://dotnsf.blog.jp/archives/1075713365.html


最後に上記で作成した Cloud Foundry ランタイムのルーティングを編集します。経路の編集から「経路の追加」を実行し、mybluemix.net ドメインと同じ名前を指定したカスタムドメイン用の経路を追加します(証明書をインポートしていないので鍵マークには×がついているはずです)。そしてもともとの mybluemix.net 側の経路を削除します。これでカスタムドメインを使った指定でないとアクセスすることはできなくなりました。最後に「保存」します:
2019110705


この状態でカスタムドメインを指定したホスト名で https アクセスを行ってみます。まず最初に CIS がリクエストを受け取ってアクセス内容を(アタックに相当するアクセスでないか)判断します:
2019110706


問題がないと判断されるとオリジンサーバーにルーティングが行われます。結果的に証明書を独自に発行することなくカスタムドメインを使った https 通信ができるようになりました:
2019110707



【参考】
IBM Cloud Certificate Manager で Let's Encrypt 無料 SSL 証明書を取得する