Bluemix
SoftLayer
ShinobiLayer
ibmcloud
CIS

CIS(IBM Cloud Internet Service)についてのFAQ


1. はじめに

IBM Cloud Internet Services (CIS)は、IBM Cloudが提供するWebパフォーマンス・セキュリティー・可用性向上サービスをAll in oneで提供するCloudflare社の技術を利用したサービスです。

よく質問をいただくので、FAQをまとめてみました。

FAQについては、随時アップデートをしていきたいと思います。


2.CIS概要

CISはインターネットからのWebアクセスで必要とされる機能をAll in oneで提供してくれるサービスです。CISのEdge Server経由でアプリケーションが稼働するWebサーバー(Origin Server)にアクセスするように構成することで、「セキュリティー強化」「可用性向上」「パフォーマンス向上」に役立ちます。以下に概要を図示します。

CIS.png

CISを利用することで、Origin Serverを多彩な攻撃から保護するだけでなく、Origin Serverの障害時に別のサーバーや拠点に処理を割り振ることが可能です。また、Origin Serverの更改を行うことなく、CDNやTLS 1.3+0RTTやHTTP/2.0等の高速化技術の恩恵を受けることもできます。まさにインターネット利用に必要な機能がAll in oneで揃っている便利なソリューションですね。


3.Q&A


3-1 一般的な質問

Q: どこにマニュアルがありますか?

A: 以下を参照してください。

https://cloud.ibm.com/docs/infrastructure/cis/getting-started.html#getting-started-with-ibm-cloud-internet-services-cis-

Q: CISとClouflare社の関係はどうなっていますか?

A: CISはIBM Cloud上でポータルやAPIを呼び出すためのコントロール・プレーンやインターフェースを提供していますが、実際のデータプレーンはCloudflare社のサービスになります。よって、Global Load BalancerやCDNなどが稼働するCISのEdge Serverは、実際はCloudflare社のデータセンター上で動いています。

Q: CISはどこで稼働していますか?

A: 先述のFAQのとおり、CISのポータルはIBM Cloudとして提供していますが、Global Load BalancerやCDNなどを実際に処理しているサーバーはCloudflare社の環境上で稼働しています。以下のリンクによると、Cloudflare社の拠点は日本にはTokyo(NRT)とOsaka(KIX)の二箇所に拠点があります。

https://www.cloudflarestatus.com/

https://www.cloudflare.com/ja-jp/network/

※このプレスリリースをみる限りでは、Equinix上で動いているように見えますね。

https://www.equinix.co.jp/newsroom/press-releases/pr//?prId=122561

Q: CISのベストプラクティスはどこに記載がありますか?

A: 以下を参照してください。

Q: CISのメンテナンス情報はどこで取得できますか?

A: 以下をご参照ください。

https://cloud.ibm.com/status?component=internet-svcs&selected=status

https://cloud.ibm.com/status?component=internet-svcs&selected=maintenance

Q: HTTP/HTTPSリクエストあたりのアップロード・データサイズに上限がありますか?

A: Free Plan/Standard Planでは1リクエストあたり100MB、Enterprise Planでは1リクエストあたり500MBのサイズ制限があります。これを回避するには、アップロード対象のデータをこの閾値を超えないようなチャンクサイズに分割するか、CISを経由しないようにProxyをOFFにするといった対応が考えられます。下記もご参照ください。

https://support.cloudflare.com/hc/en-us/articles/201303340-How-can-I-change-the-client-maximum-upload-size-

Q: セキュリティーを向上させるために、Originサーバーへの通信は、CISのEdge Serversからだけに絞りたいです。CIS Edge ServersのIPアドレス一覧はどこで確認が可能ですか?

A: 以下から確認可能です。

https://cloud.ibm.com/docs/infrastructure/cis/whitelisted-ips.html

Q: www1.example.comとwww2.example.comの2つをCISで管理したいです。この場合、ドメインはいくつ必要になるのでしょうか?

A: example.comをCISにサブドメインとして登録するのであれば、CISで利用するドメインは1つで済みます。その場合、example.com配下の他のレコードもCISで管理する必要があるため、既存サイトを移行する際には注意が必要です。www1.example.comやwww2.example.comのみをCIS管理にしてドメイン名=GLB名にすることも可能ですが、その場合はCISにおいてドメインを2つ利用することになります。詳細はGLBの項をご参照ください。

Q: CISへのドメイン移行時に気をつけておく必要はありますか?

A: CISが利用できるようになるには、

1)CISでの作業:CISで管理するサブドメインを登録する

2)CISでの作業:(オプション)もし既存DNSにレコードが存在するのであれば、CISにも移行しておく

3)上位DNSでの作業:CISで管理するサブドメインがCISに委任されるように、対象サブドメインのNSレコードとしてCISのネームサーバーを設定する

4)CISでの作業:GLBやIP Firewallなどの設定をする

という流れになります。4)は3)より先に設定しても構いません。3)の作業をすることで、初めてインターネットからアクセスできるようになりますが、その際には上位のDNSにてTTLをあらかじめ短くしておきましょう。一般的にDNSのレコードは通常時はTTLを長めに設定していることも多いですが、逆にそのままではCISに切り替わるまでに時間を要する可能性があるからです。


3-2 プラン比較

Q: Standard PlanとEnterprise Planの違いは何ですか?どちらを利用するべきでしょうか?

A: Standard Planは固定料金ですが利用できるリソースが少なく、Enterprise Planは従量課金であるが利用できるリソースが多いという違いがあります(例えばGlobal Load BalancerのOriginサーバーの数がStandard Planだったら6個だが、Enterprise Planなら100個可能)。また、Enterprise PlanにしかEdge Serversでのアクセスログを外部保管する機能やHTTP/HTTPS以外のTCPアプリケーションを稼働させるCIS Rangeによる保護機能がありませんので、これらの機能が必要な場合はEnterprise Plan一択になります。細かな差については、以下も参照してください。

https://cloud.ibm.com/docs/infrastructure/cis/plan-comparison.html#plan-comparison

Q: CIS Enterprise Planの課金はどこに記載がありますか?また、どういうアクセスに関して課金が発生するのかを教えてください。

A: 価格については、以下に記載があります。

https://cloud.ibm.com/catalog/services/internet-services

従量課金分についての意味は以下の通りです。


  • DNSクエリー(DNS Query Event): CISで定義しているDNSレコードが検索されるたびにカウントされます。

  • HTTP(S)リクエスト(HTTP Request Event):Proxy有効時に、CISのEdge Serverに対してリクエストしたHTTP(S)リクエストに対してカウントします。

  • 転送量(Gigabyte単位):HTTP/HTTPSによるProxy有効時のProtected Traffic、もしくはTCPでのRangeが有効時に、CIS Edge ServersからのOutbound通信に対して発生します。つまり、「CIS Edge Serversからエンドユーザー」への通信量および
    「CIS Edge ServersからOriginサーバー(WAFやIP Firewallでブロックされている場合は通信量は発生しない)」への通信量の合計になります。

Q: Enterprise Planの機能を利用したいです。CIS Enterprise UsageとCIS Enterprise Packageは、どちらを利用するべきでしょうか?

A: 機能検証目的もしくはアクセス量が限定されている場合ではCIS Enterprise Usageを、アクセス量が多い場合はCIS Enterprise Packageを推奨します。


  • CIS Enterprise Usage: 基本料金なしに、必要な数だけドメインを個別に購入し従量課金で積み重ねて利用するタイプのものです。小さく始めることができますが、逆に転送量やHTTPリクエスト数が増えると、CIS Enterprise UsageはCIS Enterprise Packageに比べて高額になります。

  • CIS Enterprise Package: 基本料金が発生しますが、その基本料金の中にドメインが10個、Protected Traffic(5TB), Range(5TB)が含まれています。また、転送量やHTTPリクエスト数に関する課金がCIS Enterprise Usageに比べて10倍以上安くなっており、使用量が増えるとCIS Enterprise Packageの方が安価になります。

Q: Free PlanからStandard Planへのアップグレードにはネットワーク断が発生しますか?

A: 発生しません。

Q: Free Planを複数回利用することはできますか?

A: Free Planは1つのアカウントにつき、1回のみ利用可能です。

Q: Free PlanとStandard Planに機能差はありますか?

A: ありません。ただし、Free Planは1ヶ月しか使えないという制約があります。


3-3 Global Load Balancer

Q: 今まで外部に公開しているサーバーがwww.example.comだったとします。もし

「CISに登録するドメインとしてexample.com」を登録し、「GLBとしてwww.example.com」を構成する場合、www以外のレコードまでCIS管理下に配置されるため影響範囲が大きく移行が不安です。www.example.comのみをCIS管理にすることはできませんか?

A: 以下のように構成することで可能です。


  • CISに登録するドメインとしてwww.example.comを利用

  • GLBとしてwww.example.comを利用(ドメイン名と揃えることが可能。つまり、サブドメイン持たないAPEXドメインが定義できる)

  • 既存DNSサーバーで、www.example.comのNSレコードとしてCISのName Serverを登録する

最後のNSレコードとしてCISのName Serverを登録するまでは、CISのドメインはPending Stateの状態になるので、インターネット経由で名前解決がされることがないため、既存環境にアクセスし続けたままになります。既存DNSサーバーでNSレコードを登録した時点で、CISに切り替わることになります。

Q: CISに登録したドメインがexample.comだったとします。GLBとしてこのドメインにホスト名+サブドメインを追加し、www.test.example.comのようなFQDNでGLBを構成することは可能ですか?

A: 可能です。

たしかに、この登録したドメインにおいて、Edge証明書として有効なドメインは、デフォルトでは*.example.comおよびexample.comのみです。この構成は、Security -> TLS -> Edge Certificatesからも確認することができます。このままでは、httpでは稼働しますが、httpsでは稼働しません(ワイルドカード証明書はone-level サブドメインでしか有効ではありません)。

しかし、この構成画面から、*.test.example.comをEdge certificatesに追加してあげれば、httpsでも接続が可能になります。

Q: 1つのGLBにつき、Standard Planでは幾つまでOriginサーバーを定義できますか?

A: CISのGLBはpoolに定義されているOriginサーバーにリクエストを割り振ります。Standard Editionは1つのpoolに6つまでしかOriginサーバーを定義できません。よって、ドキュメント上は6つまでしか割り振れないという説明になっています。

しかし、poolは複数作れて優先度をつけることができます。また、GLBはどこからアクセスしてきたかでどのpoolに優先してアクセスするかも定義できます。その結果、日本からアクセスした時はpool1, pool2の優先順位で、USからアクセスした時はpool2, pool1の優先順位にすることができます。このケースの場合、pool1もpool2もactiveなのでCISに割り振られるOrigin サーバーの数は、Standard Planでも12になります(とはいっても、世界中からアクセスされないとこの12は活かせない訳ですが)。

Q: ProxyありとProxyなしはどのように挙動が違いますか?

A: Proxyありにした場合は、WAFやIP Firewallが利用可能になります。Originサーバーへの通信は必ずCISのEdge Serversからの通信になり、TTLがAutomaticになります。Automaticについては下記に記載があります。

https://support.cloudflare.com/hc/en-us/articles/360017421192-Cloudflare-DNS-FAQ#whatdoestheautomaticttlvaluemean

Proxyなしの場合は、WAFやIP Firewallは利用されません。またOriginサーバーへの通信は、エンドユーザー端末からの直接通信になります。

Q: Proxyありの場合に、Originサーバーでのアクセスログを確認したところ、接続元が全部CISのEdge ServersのIPアドレスになります。エンドユーザーのIPアドレスを記録するにはどうすればいいですか?

A: HTTPヘッダに含まれるX-Forwarded-ForもしくはCF-Connecting-IPを記録するようにして下さい。

Q: セッションアフィニティ機能を利用するために、 「Keep session affinity with cookie」を選択しました。この場合のCookie名は何になりますか?

A: __cfduidです。

Q: ヘルスチェック設定において、ヘルスチェック間隔、リトライ回数、タイムアウトの間に、何か制限はありますか?

A: ヘルスチェック間隔は以下の式に従う必要があります。

interval >= (1 + retries) * timeout

Q: Enterprise Planでは、ヘルスチェックの間隔を5秒にまで小さくできると書かれてありますが、Customer Portalからは設定できません。

A: ヘルスチェックの間隔として、GUIから構成できるのは10秒までです。それより小さい値を構成するためにはibmcloud cis glb-monitor-createを利用して下さい。

Q: カスタムのエラーページを作成することはできますか?

A: こちらの記事をご参照ください。


3-4 TLS

Q: セキュリティーを向上させるために、Originサーバーには自己証明書を使って"End-to-End flexible"を利用するのではなく、「CA局署名済み証明書」を導入して"End-to-End CA Signed"で接続したいと考えています。この「署名済みの証明証」は自分で持ち込む必要があるのでしょうか?

A: 自分で持ち込むことも可能ですが、CIS発行のOrigin用の証明書を利用することも可能です。このCIS発行のOrigin用証明書に対しては特に追加費用は発生しません。このCIS発行のOrigin用証明書は、Cloudflare社が独自CA局として署名しているため、CISからのアクセスに対しては「署名済みの証明証」として機能します。CIS管理下にある自社ドメインに対して証明書を発行できますが、任意のドメインやIPアドレスに対しては証明書を発行できません。有効期限は、最短7日から最大15年間の中から選択可能です。詳細は以下をご参照ください。

https://cloud.ibm.com/docs/infrastructure/cis?topic=cis-cis-origin-certificates#cis-origin-certificates

Q: "End-to-End CA Signed"を選択した際には、かならずCISとOrigin Serverの間はhttpsが利用されますか?

A: いいえ。GLBに対してHTTPでアクセスした場合はCISとOrigin Serverの間はHTTPになりますし、GLBに対してHTTPSでアクセスした場合にはCISとOrigin Serverの間はHTTPSになります。もしGLBに対してHTTPでアクセスした場合であっても、CISとOrigin Serverの間をHTTPSに強制したい場合は、"HTTPS only origin pull"(Enterprise Planのみ選択可能)を利用してください。

https://cloud.ibm.com/docs/infrastructure/cis?topic=cis-cis-tls-options#tls-encryption-modes-origin-only-pull

Q: CISはmTLSをサポートしていますか? 例えばAPI ConnectとKuberenetsの間は現行でmTLSを使っているため、「API Connect - CIS - K8S」といった構成にしたいです。

A: Enterprise Planでサポートしており、特に追加費用は発生しません。ドメインごとに設定が可能であり、client-sideは自己証明書を使うこともできます。ただし、ポータルからは構成できないため、mTLSが必要な場合はCaseを起票してください。


3-5 CDN

Q: デフォルトでは何がCDNでキャッシュされますか?

A: 以下を参照して下さい。

https://support.cloudflare.com/hc/en-us/articles/200172516-Which-file-extensions-does-Cloudflare-cache-for-static-content-

Q: CDNにキャッシュされているかどうかは、どうやったら判別できますか?

A: HTTPのリプライヘッダーでcf-cache-status: HITとなっていれば、キャッシュされています。例えばFirefoxでは、右上のメニュー -> ウェブ開発 -> ネットワークを選択することでHTTPのリクエストヘッダー・リプライヘッダーを確認することができます。

image.png

Q: htmlファイルがキャッシュされません。どうすればキャッシュされるようになりますか?

A: htmlファイルはデフォルトではキャッシュされない仕様です。そのため、デフォルトではhtmlファイルへのアクセスの度にOriginサーバーへの通信が発生します。htmlファイルをキャッシュしたい場合は、Page Ruleで指定してください。

https://cloud.ibm.com/docs/infrastructure/cis/cache.html#how-do-i-cache-html-

https://cloud.ibm.com/docs/infrastructure/cis/using-page-rules.html#performance

Q: APIアクセスなどの特定のURLに対しては、キャッシュせずに、その都度Originサーバーにアクセスするようにさせたいです。そういう操作は可能ですか?

A: Page Ruleを使えば可能です。Cache LevelBypassに設定して下さい。

https://cloud.ibm.com/docs/infrastructure/cis/using-page-rules.html#use-page-rules

Q: Originサーバーが稼働していなくても、キャッシュされたコンテンツを返し続けるような設定は可能ですか?

A: 可能です。以下をご参照ください。

https://cloud.ibm.com/docs/infrastructure/cis/managing-for-reliability.html#serve-stale-content

Q: Originサーバーでコンテンツを変更したのですが、CISがキャッシュされたコンテンツを返し続けます。Customer PortalではなくAPIでキャッシュクリアできないでしょうか?

A: APIは以下をご参照ください。

https://cloud.ibm.com/apidocs/cis/cache

なお、ibmcloud cis cache-purgeコマンドを利用してキャッシュクリアすることもできます。


3-6 WAF

Q: WAFは最初はどのように設定しておくことが推奨ですか?

A: まずは"Simulate"を選択し、WAFによって処理は止められないがイベントとしては記録されるように構成することで、通常の業務処理がWAF ruleに引っかかるかどうかをチェックすることを推奨します。テストの結果、WAF ruleに引っかかる処理は、アクセス方法を変えたりsensitivityを変更するといった方法が考えられます。特に問題がなければ、"Challenge" や"Block"に変更するといった流れが適切だと思われます。

Q: WAFのルールをポータル経由ではなく、スクリプトなどで統一的に構成することは可能ですか?

A: API以外にも、Terraformを使ってWAF ruleを構成することも可能です。

https://github.com/IBM-Cloud/terraform-provider-ibm

Q: 一律にSensitivityを設定するのではなく、特定の画面(例えばログイン画面)だけはSecurityを強化することは可能ですか?

A: Page ruleを利用して、特定のURLに限ってはSecurity LevelをHighにするといったことが考えられます。下記リンクもご参照ください。

https://cloud.ibm.com/docs/infrastructure/cis/managing-for-security.html#manage-your-ibm-cis-for-optimal-security

Q: WAFのルールが追加されたり、デフォルトアクションが後から変更されることはあるのでしょうか?どこでそういう変更情報を取得することができますか?

A: 以下で通知されるようです。

https://cloud.ibm.com/status?component=internet-svcs&selected=announcement

Q: Custom WAFはどうやったら構成できますか?

A: Custom WAFはCIS Enterpriseを購入した際に利用できます。ただし、現状では利用者が自由に構成できるわけではなく、メールベースでのリクエストになります。アクセスログやPOSTデータのサンプル情報を元に、CISチームがCustom WAFを作成・登録するという流れのようです。なお、アクセスログの形式ついては、これといったガイドラインやフォーマットは存在していません。どういう攻撃パターンなのかとか、どういうUser-Agentからの攻撃なのかなどをCustom WAFを作成する際に参考にしたいらしいというのが趣旨のようであり、一般的なアクセスログであれば問題ないようです。

https://cloud.ibm.com/docs/infrastructure/cis/waf-custom-rules.html

'Q: WAFはuploadファイルのファイルスキャンをしますか?`

A: しません

https://community.cloudflare.com/t/safety-of-files-uploaded-by-visitors-to-site/46468/5


3-7 DNS

Q: ProxyありとProxyなしではどのように挙動が違いますか?

A: DNSレコードのProxy設定を有効にすると、CISのDNSが名前解決リクエストへのレスポンスとして返すのはCISのIPアドレスになります。その結果、GLBの利用有無に関わらずクライアントからの名前解決後のHTTP/HTTPSアクセス接続先はCISになりますが、CISが登録済みDNSレコードにリクエストを割り振ってくれます。

一方、DNSレコードのProxy設定を有効化して名前解決後の接続先がCISになったとしても、HTTP/HTTPS以外のリクエストに対しては、CISは登録済みDNSレコードにリクエストを割り振ることができません。HTTP/HTTPS接続以外の目的でCISのDNSにレコードを登録する場合は、Proxy設定を無効にして登録済みDNSレコードを直接返すように構成する必要があります。

また、Proxyありにすると必ずTTLがAutomaticになります。Automaticについては下記に記載があります。

https://support.cloudflare.com/hc/en-us/articles/360017421192-Cloudflare-DNS-FAQ#whatdoestheautomaticttlvaluemean


3-8 IP Firewall

Q: 特定のIPアドレスからのみアクセスを許可し、それ以外の環境からはアクセスさせないようにしたいのですが、どうやればできますか?

A: Domain Lockdownを利用すれば可能です。Domain Lockdownは、特定のIPアドレスもしくはIPアドレスレンジからのアクセスのみをホワイトリストとして許可し、それ以外のIPアドレスからのアクセスをブロックします。自社オフィスから運用用途のURLへの接続のみを許可する場合に効果的です。

Q: 特定の国(例:中国)からのアクセスをブロックしたいのですが、Standard Planでできますか?

A: Country FilteringはStandard Planでは"Challenge"しか設定できません。"Block"したいのであれば、Enterprise Planを利用する必要があります。

Q: IP Firewallにてwhitelist, challenge, Javascript challengeを利用した場合には、WAFでもチェックされますか?

A: 検証してみたところ、以下のような挙動になっているようです。


  • whitelist: 指定したIP、IPレンジ、ASからのアクセスはWAFで保護されず、
全てを許可します。ただし、国を指定した場合のみWAFでも保護されます。

  • challenge: WAFでも保護されます。

  • Javascript challenge: WAFでも保護されます。


3-9 ログ

Q: Origin Serverまでリクエストが来た場合には、Origin Serverでアクセスログが取得できます。しかし、CISでキャッシュされた場合には、Origin Serverまでリクエストが来ないため、誰がアクセスしてきたのかが分かりません。CIS側でのアクセスログは取得できるのでしょうか?

A: CISでのアクセスログの取得は可能ですが、Standard Planでは取得できません。Enterprise Planのみで利用可能です。またCustomer Portal経由では取得できず、ibmcloudコマンドもしくはAPIを利用する必要があります。

https://cloud.ibm.com/docs/infrastructure/cis/logpull.html#logpull

https://cloud.ibm.com/docs/infrastructure/cis/cli/cli-log.html

Q: CISにおけるアクセスログの保管期間は何日ですか?

A: 7日間です。これは、下記のように$ ibmcloud cis logpull --helpにも記載があります。

オプション:

--available-fields List of all available fields.
--ray-id value Lookup logs by specific ray id.
--fields value Define field set in return.
This must be specified as a comma separated list without any whitespaces, and all fields must exist.
The order in which fields are specified doesn't matter, and the order of fields in the response is not specified.
Note that fields are expected to be case sensitive.
--start value The (inclusive) beginning of the requested time frame.
This can be a unix timestamp (in seconds or nanoseconds), or an absolute timestamp that conforms to RFC 3339.
At this point in time, it cannot exceed a time in the past greater than 7 days.
Default is 65 minutes earlier.
--end value The (exclusive) end of the requested time frame.
This can be a unix timestamp (in seconds or nanoseconds), or an absolute timestamp that conforms to RFC 3339.
'end' must be at least 5 minutes earlier than now and must be later than 'start'.
Difference between 'start' and 'end' must be not greater than 1h.
Default is 5 minutes earlier.
--count value Number of logs to retrieve. (デフォルト: -1)
--sample value Percentage of sampling. When sample is provided, a sample of matching records is returned.
If sample=0.1 then 10% of records will be returned.
Sampling is random: repeated calls will not only return different records, but likely will also vary slightly in number of returned records.
When count is also specified, count is applied to the number of returned records, not the sampled records.
So, with sample=0.05 and count=7, when there is a total of 100 records available, approximately 5 will be returned.
When there are 1000 records, 7 will be returned. When there are 10,000 records, 7 will be returned. (デフォルト: 1)
-i value, --instance value インスタンス名。 設定しない場合、'ibmcloud cis instance-set' によって指定されるコンテキスト・インスタンスが使用されます。

それ以上の保管が必要な場合は、定期的にダウンロードしておくことを推奨します。なお、今後はIBM Cloud Object Storage(ICOS)に直接プッシュする機能が予定されていますが、実装時期は未定です。

Q: Standard PlanではCISでアクセスログを取得できないということですが、監査上ログ取得は必須です。Standard Planのままで何か代替策はありませんか?

A: パフォーマンスとのトレードオフにはなりますが、CISでキャッシュさせずにOriginサーバー側に毎回アクセスさせることで、Originサーバーでアクセスログを取得するように構成することが回避策の1つとして考えられます。

例えば、デフォルトではhtmlファイルはCISにキャッシュされないため、トップページ(index.html)へのアクセスはOriginサーバーでのアクセスログに残すことができます。もしhtmlファイルをCISにキャッシュさせるように構成したとしても、トップページ配下のindex.htmlのみはCISにキャッシュさせないように構成するというのは1つの方法でしょう。他にも、ログイン画面のような重要性の高いページについてはキャッシュさせずにOriginサーバー側でログを確実に取得するといったことが考えられます。

Q: リクエスト数やコネクション数などのメトリックは、取得できますか?

A: Standard Plan/Enterprise Planの双方で、ibmcloudコマンドもしくはAPIを使うことで、直近の90日分が取得可能です。


3-10 DDoS保護

Q: L3/L4レベルの攻撃に関しては自動的に保護されますか?

A: DNSやGLBでproxyを有効化しておけば、保護されます。CISは基本的にはHTTP/HTTPSでアクセスするシステムを対象としています。

Clientがアクセスする際には、まず最初にCIS上のproxyとの間にTCPレベルで3way handshakeを行ってコネクションを作成し、その上でHTTP/HTTPSリクエストが開始されます。その後、CISのProxyがOrigin Serverとの間で同様の方法でTCPコネクション・HTTP/HTTPSリクエストを開始します。よって、SYN Floodのような単純なL3/L4レベルのプロトコル攻撃はTCPコネクションがそもそも生成されないので、自動的に保護されることになります。

Q: L7レベルの攻撃に関しては自動的に保護されますか?

A: L7の攻撃に関しては、以下の4つの保護方法・緩和方法が提供されています.これらは、DNSやGLBでproxyを有効化していることが前提です。


  • WAF(保護):  
    SQL Injectionなど通常のWebシステムには重要な機能ですが、Volume Attackからの保護という観点であれば、それほど効果はないと思います。

  • CDN(緩和):
    キャッシュされている分、Origin側に負荷を与えないという意味でCDN機能による緩和は一般的には期待できます。

  • Defense Modeに変更(保護):
    利用者が明示的に該当ドメインに対するアクセスを完全に遮断する方法です。このModeにしている間は全てのアクセスが止まるので、下記の対策等を行うまでの暫定処理と言えるでしょう。

  • Firewall(保護):
    IPアドレスベースで指定ができるので、事前に正規の送信元が分かっていればそこからのアクセスだけに絞り込むことができるため、有効な保護手段と言えます。また、サービスを不特定多数に公開している場合であっても、今後DDoS攻撃を受けた際にそのIPアドレスを即時にブロックしておくことが可能です。
    また、「特定の国からはアクセスさせない」、などのCountry Filteringも設定できます。Country Filteringは、Enterprise Planだと特定の国からのアクセスをBlockすることができますが、Standard PlanではBlockはできません。ただ、Standard Planでも、以下のようなチャレンジプログラムを実施しないとアクセスできないように構成することは可能なので、これでも対策となると思います。(残念ながら、現時点では「日本からのみアクセスを許可する」、といったwhitelist設定はEnterprise Planでもできません)
    image.png

Q: DDoSがあった場合には通知されますか?

A: 通知されません

Q: DDoSのログを取得することはできますか?

A: できません。


3-11 CIS Range

Q: CIS Rangeとは何ですか?

A: HTTP/HTTPS以外のTCPについてもCISのIP Firewallを経由することで保護し、ロードバランスすることができる、Cloudflare社のCloudflare Spectrumに相当する機能です。2019/02月現在、Enterpriseプランでのみ利用可能であり、UDPには対応していません。(Cloudflare版ではできるので、そのうち対応されると思います)

Q: CIS Rangeにおいて、IP FirewallのChallengeはどのように動作しますか?HTTP/HTTPSの時と同様に何か確認画面が発生するのでしょうか?

A: 特に何もせずに許可をするだけのようです。

Q: CIS Rangeにおいて、ドメインロックダウン機能は使えますか?

A: ドメインロックダウンはURLにしか機能しないので適用されません。

Q: CIS RangeとHTTP/HTTPSにて、適用されるIP Firewallルールを分けることはできますか?

A: IP Firewall機能はドメインごとに構成することが可能なので、CIS RangeとHTTP/HTTPSのドメインを分けることでIP Firewallルールを分けることが可能です。

Q: CIS Rangeで、特定のIPアドレスレンジからのアクセス以外はブロックするようにIP Firewallを構成することはできますか?

A: 現時点ではできず、都度ブロックするIPレンジを指定するしかできないようです。


3-13 CIS Edge Functions

Q: CIS Edge Functionsとは何ですか?

A: javascriptをクライアント(ブラウザ)でもなく、オリジンサーバーでもなく、世界中に広がるCloudflare社のEdgeサーバーで実行することができる機能であり、ビジネスロジックをオリジンサーバーやクライアント側のリソースを利用する必要がありません。Cloudflare Workersの機能に相当します。

2019/02月現在、Standard/Enterpriseプランの両方で利用できますが、ベータ提供です。Standardプランではアクションを1つしか作成できないことにご注意ください。Enterpriseは無制限にアクションを作成することができます。

https://cloud.ibm.com/docs/infrastructure/cis/plan-comparison.html#plan-comparison

Q: アクションスクリプトのサンプルはありませんか?

A: 以下をご参照ください。

https://developers.cloudflare.com/workers/about/

https://github.com/cloudflare/worker-examples


3-14 ICOSへのアクセス

Q: ICOSに配置したindex.htmlをCIS経由でアクセスすることは可能ですか?

A: 可能です。ICOSのコンテンツをPublic Accessとして公開してAPIキーなしでもアクセスできるようにした後、Page RuleにてResolve OverRide with COSを選択し、ウィザードからICOSのインスタンスやbucketを指定するのがもっとも簡単な構成方法です。詳細手順は以下をご参照ください。

https://cloud.ibm.com/docs/infrastructure/cis?topic=cis-resolve-

(補足)一般的に、ICOSのbucket配下のコンテンツに対しては、以下のアクセス方法が可能です。

a) https://<cos-endpoint>/<bucketname>/index.html

b) https://<bucketname>.<cos-endpoint>/index.html

このResolve OverRide with COSというPage Ruleを選択した際には、b)の方法でICOSにアクセスしています。https://<bucketname>.<your domain>/index.htmlでICOSにアクセスできるように、このPage Ruleを選択した際にはCNAMEの設定がDNSに対して自動的に追加されています(このCNAMEの設定はResolve OverRide with COSを削除しても、自動的には削除されない仕様のようです。手動で削除する必要があります)。また、Hostヘッダーを上書きしてあたかも.でICOSにアクセスしているかのように振舞っています。