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経由でアプリケーションが稼働するWebサーバー（Origin Server）にアクセスするように構成することで、「セキュリティー強化」「可用性向上」「パフォーマンス向上」に役立ちます。以下に概要を図示します。

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

基本的な通信の流れは以下のようになります。

通信の流れ

ブラウザ -> Edge(Reverse Proxy+各種セキュリティー機能+パフォーマンス向上機能: CISの実体) -> Origin(Web Server)

3.Q&A

3-1 一般的な質問

Q: どこにマニュアルがありますか？
A: 以下を参照してください。
https://cloud.ibm.com/docs/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は、実際は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: 以下を参照してください。

• https://cloud.ibm.com/docs/cis?topic=cis-best-practices-for-cis-setup
• https://cloud.ibm.com/docs/cis?topic=cis-manage-your-ibm-cis-for-optimal-security
• https://cloud.ibm.com/docs/cis?topic=cis-manage-your-ibm-cloud-internet-services-deployment-for-optimal-reliability
• https://cloud.ibm.com/docs/cis?topic=cis-manage-your-cis-deployment-for-best-performance

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(S)リクエストあたりのアップロード・データサイズに上限がありますか？
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-
なお、Enterprise PlanではPerformance -> Advancedから、最大アップロードサイズを変更することが可能です。

Q: セキュリティーを向上させるために、Originサーバーへの通信は、CISのEdgeからだけに絞りたいです。CISのEdgeのIPアドレス一覧はどこで確認が可能ですか？
A: 以下から確認可能です。
https://cloud.ibm.com/docs/cis?topic=cis-cis-allowlisted-ip-addresses

Q: www1.example.comとwww2.example.comの2つをCISで管理したいです。この場合、ドメインはいくつ必要になるのでしょうか？
A: example.comをCISにサブドメインとして登録するのであれば、CISで利用するドメインは１つで済みます。その場合、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やFirewallなどの設定をする

という流れになります。3)の作業をすることで、CISはPending状態からActive状態に遷移します。DNS委任作業時には、上位のDNSにてTTLをあらかじめ短くしておきましょう。一般的にDNSのレコードは通常時はTTLを長めに設定していることも多いですが、逆にそのままではCISに切り替わるまでに時間を要する可能性があるからです。

Q: CISの設定がセキュリティー的に問題がないかを確認する方法はありますか？
A: １つの方法は定期的にSecurity Advisorを実行することです。Security Advisorによって現行の設定にリスクがあるかどうかを確認することことができます。もしRisk Highのものがあっても、なぜそのような設定にしているかを見直すきっかけになると思います。
なお、docker run icr.io/ibm/config-advisor:latest -k <APIKEY> <command> を実行した際にレポートを生成するため、最新の状況を確認するためには再度このコマンドを実行する必要があります。
https://cloud.ibm.com/docs/security-advisor?topic=security-advisor-config-setup

Q: 特定のドメインや機能のみにアクセスを制限するように権限を付与することはできますか？
A: IAMの機能を利用してそのように構成することが可能です。手順例は以下を参照してください。
https://qiita.com/testnin2/items/22948266ebcdba31cc15

Q: ブラウザキャッシュについて特に気をつけておくべきことはありますか？
A: 例えば、初回アクセス時にはアクセス先からはjs/cssなどのファイルに対するレスポンスヘッダーにEtagが含まれて応答が返ってきます。ブラウザ（クライアント）は2回目以降のアクセスの際にはこのEtagの値をリクエストヘッダに含めることでコンテンツに変更があるかどうかの確認をアクセス先に依頼します。変更がなければ、アクセス先はコンテンツは送り返さずにStatus 304を返すため、ブラウザ（クライアント）は変更がないことを認識してローカルのキャッシュを使う・・・というのがブラウザキャッシュの仕組みです。
Etagには強いEtag(etag "5afd4a4c-eca4")と弱いEtag(etag W/"5afd4a4c-eca4")がありますが、仮にOrigin Server側で強いEtagを送っていてもCISで弱いEtagに変換してブラウザ側に送るという仕様があります（詳細は以下のページを参照してください）。強いEtagでも弱いEtagでもブラウザキャッシュ自体は可能ですが、Origin Server側が古いWebサーバーを利用している場合には弱いEtagを処理できずにStatus 200が返りブラウザキャッシュが効かなくなるといった事例もあります。
なお、2020年8月時点ではCISではEnterprise Planに限りCaseで依頼することによってRespect Strong ETagsという強いEtagを利用するページルールを作成することが可能です。
https://support.cloudflare.com/hc/en-us/articles/218505467-Using-ETag-Headers-with-Cloudflare

3-2 プラン比較

Q: 各Planの違いは何ですか？どちらを利用するべきでしょうか？
A: 大きく分けてPlanは4つあります。

• Standard Planは固定料金ですが利用できるリソース・機能が少ないです。
• Enterprise Package PlanもしくはEnterprise Usage Planは従量課金ですが、CISとして最大限の機能が利用できます。特にEdge FunctionsはEnterprise Planでのみ利用可能です。また、一部のPage ruleはEnterprise Planのみで利用可能となっています。
• Security PlanはWAFやFirewall機能がEnterprise plan並みに使える機能で固定料金です。
• GLB Planは逆に、そうしたセキュリティー機能を利用せずにGlobal Load Balancer機能を中心に提供します。こちらも固定料金での提供です。

詳細については以下を参照してください。
https://cloud.ibm.com/docs/cis?topic=cis-cis-plan-comparison
https://cloud.ibm.com/docs/cis?topic=cis-use-page-rules

Q: 課金情報はどこに記載がありますか？また、どういうアクセスに関して課金が発生するのかを教えてください。
A: 価格については、以下に記載があります。
https://cloud.ibm.com/catalog/services/internet-services

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

• DNSクエリー(DNS Query Event): CISで定義しているDNSレコードが検索されるたびにカウントされます。
• HTTP(S)リクエスト(HTTP Request Event)：Proxy有効時に、Edgeに対してリクエストしたHTTP(S)リクエストに対してカウントします。
• 転送量（Gigabyte単位）:HTTP(S)によるProxy有効時のProtected Traffic、もしくはTCPでのRangeが有効時に、EdgeからのOutbound通信に対して発生します。つまり、「Edgeからエンドユーザー」への通信量および
  「EdgeからOriginサーバー(WAFやFirewallでブロックされている場合は通信量は発生しない）」への通信量の合計になります。

Q: Enterprise Planには、Enterprise UsageとEnterprise Packageという二種類の提供方法が存在するようです。どちらを利用するべきでしょうか？
A: 機能検証目的もしくはアクセス量が限定されている場合ではEnterprise Usageを、アクセス量が多い場合はEnterprise Packageを推奨します。

• Enterprise Usage: 基本料金なしに、必要な数だけドメインを個別に購入し従量課金で積み重ねて利用するタイプのものです。小さく始めることができますが、逆に転送量やHTTPリクエスト数が増えると、Enterprise UsageはEnterprise Packageに比べて高額になります。
• Enterprise Package: 基本料金が発生しますが、その基本料金の中にドメインが10個、Protected Traffic(5TB), Range(5TB)が含まれています。また、転送量やHTTPリクエスト数に関する課金がEnterprise Usageに比べて10倍以上安くなっており、使用量が増えるとEnterprise Packageの方が安価になります。

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

Q: Free Planを複数回利用することはできますか？
A: Free Planは1つのアカウントにつき、1回のみ利用可能です。

Q: Free PlanとStandard Planに機能差はありますか？
A: ありません。ただし、Free Planは１ヶ月しか使えないという制約があります。

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を利用
• 既存DNSサーバーで、www.example.comのNSレコードとしてCISのName Serverを登録する
• GLBとしてwww.example.comを利用（ドメイン名と揃えることが可能。つまり、サブドメイン持たないAPEXドメインが定義できる）

Q: CISに登録したドメインがexample.comだったとします。GLBとしてこのドメインにホスト名＋サブドメインを追加し、www.test.example.comのようなFQDNでGLBを構成することは可能ですか？
A: 可能です。
たしかに、デフォルトではUniversal Wildcard証明書が使われており、有効なFQDNは*.example.comおよびexample.comのみになっています。この構成は、Security -> TLS -> Edge Certificatesからも確認することができます。このままでは、HTTPでは稼働しますが、HTTPSでは稼働しません（ワイルドカード証明書はone-level サブドメインでしか有効ではありません）。
しかし、この構成画面から、Dedicated Custom証明書を購入して*.test.example.comをSANに追加してあげれば、HTTPSでも接続が可能になります。
詳細は以下をご参照ください。
https://qiita.com/testnin2/items/ef04148867f915ad9203

Q: １つのGLBにつき、Standard Planでは幾つまでOriginサーバーを定義できますか？
A: CISのGLBはpoolに定義されているOriginサーバーにリクエストを割り振ります。プラン比較に記載のあるとおり、Standard Editionは１つのインスタンスにつき6台までしかOriginサーバーを定義できません（定義するべきではありません）。

※実際にやってみると、プールは複数作れて、プールごとに6台まで登録できるため、インスタンスごとに作成可能なOrigin Serverは6台を超えて作れそうな感じです。ただしこれはCloudflare内部のAPIレベルでその強制が期待した動きになっていないためであり、どこかのタイミングで修正される可能性があるとのことです。

Q: ProxyありとProxyなしはどのように挙動が違いますか？
A: Proxyありにした場合は、WAFやFirewallが利用可能になります。Originサーバーへの通信は必ずEdgeからの通信になり、TTLがAutomaticになります。Automaticについては下記に記載があります。
https://support.cloudflare.com/hc/en-us/articles/360017421192-Cloudflare-DNS-FAQ#whatdoestheautomaticttlvaluemean
Proxyなしの場合は、WAFやFirewallは利用されません。またOriginサーバーへの通信は、エンドユーザー端末からの直接通信になります。

Q: Proxyありの場合に、Originサーバーでのアクセスログを確認したところ、接続元が全部Edgeの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: こちらの記事をご参照ください。

Q: GLBに複数のPoolを定義した場合には、どのPoolが利用されますか？
A: どのPoolを利用するかは、Traffic steering policyに依存します。デフォルトはRandomです。以下も参照にしてください。

• https://cloud.ibm.com/docs/cis?topic=cis-traffic-steering&locale=en
• https://developers.cloudflare.com/load-balancing/understand-basics/traffic-steering/steering-policies/
• https://developers.cloudflare.com/load-balancing/understand-basics/traffic-steering/steering-policies/standard-options/

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/cis?topic=cis-cis-origin-certificates#cis-origin-certificates
https://qiita.com/testnin2/items/71ea1fb47ed8aa80eca9

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/cis?topic=cis-cis-tls-options#tls-encryption-modes-origin-only-pull

Q: Edgeで利用可能な証明書にはどういうものがありますか？

• Universal wildcard（単にUniversalと記載されることもあり）
• Dedicated wildcard（単にDedicatedと記載されることもあり）
• Dedicated custom
• Uploaded custom（持ち込みサーバー証明書の利用）

の4つがあります。詳細は以下をご参照ください。
https://qiita.com/testnin2/items/ef04148867f915ad9203

Q: Edgeに持ち込みのサーバー証明書をアップロードすることは可能ですか？
A: 可能です。ただし、無償でアップロードできるのは、各Planで１つまでです。もし個別に証明書をアップロードしたい場合は、2つ目のアップロード以降は１証明書あたり$400発生します。1ドメインで複数の証明書をお持ちの方は、できれば１つの証明書に統合することをお勧めします。
また、Edgeでは自己署名サーバー証明書を利用することはできません。公的なCA局に署名されているサーバー証明書である必要があります。

Q: TLSのCipher Suite（暗号化スイート）を指定・制限することはできますか？
A: 可能です。ポータルからは構成できないため、必要な場合はCaseを起票してください。追って、Support teamがCloudflare社と連携してその実装を行います。
CLIから利用変更できるようになりました。詳細はこちらを参照してください。

Q: HTTP/HTTPS通信で80番/443番以外のポート番号は利用可能ですか？
HTTP: 80,8080,8880,2052,2082,2086,2095
HTTPS: 443,2053,2083,2087,2096,8443
が利用可能です。上記のポート番号であればmTLS使用時でも疎通可能です。また、Originサーバー側も同じポート番号で待ち受けする必要があります。ただし、80/443以外のポート番号を使った場合は、CDN機能が利用できなくなる（Cache)されなくなることに注意してください。
これ以外のポートを利用する場合は、以下の回避策がありますが、どちらもCISの機能を十分に活用できません。

• DNSでproxy-offにする。こうすればCDN/WAFのEdgeを経由しなくなるが、逆にいうとCISはDNSとしてしか働かなくなるので各種パフォーマンス・セキュリティー機能は利用されなくなる。
• CIS Rangeを利用する。ただし、Proxy内でL4レベルのチェックしかされないため、IP Firewall機能は利用できるが、CDN機能もWAF機能も利用できない。

詳細はこちらをご参照ください。

Q: CISはmTLSをサポートしていますか？　例えばAPI ConnectとKuberenetsの間は現行でmTLSを使っているため、「API Connect - CIS - K8S」といった構成にしたいです。
A: サポートしています（内部的にはmTLSはCloudflare Accessの機能を利用しています）。ただし、ポータルからは構成できないため、必要な場合はCaseを起票してください。特に追加費用は発生しませんが、Enterprise Plan(Usage & Packageのみ。Enterprise GLBやEnterprise Securityでは不可）を利用している必要があります。mTLSを有効化するかどうかはFQDNごとに設定が可能です。
参考記事: CIS(IBM Cloud Internet Service)でmTLSを構成する(1) - 基本設定編

Q: Client証明書の情報をHTTP headerに付与してOriginに転送することは可能ですか？
A: mTLSを有効化した上で、CIS Edge functionsを利用すれば可能です。
参考記事: CIS(IBM Cloud Internet Service)でmTLSを構成する(3) - クライアント証明書情報をHTTPヘッダに含める

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のリクエストヘッダー・リプライヘッダーを確認することができます。
その他のHIT以外にどういうステータスがあるかはこちらをご参照ください。

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

We do not cache HTML files by default because we do not consider them to be static; however, if static HTML can be clearly distinguished from dynamic HTML it is possible to cache HTML files using the Page Rules feature.

By default, HTML content is not cached. A page rule to cache static HTML content must be written.

Q: APIアクセスなどの特定のURLに対しては、キャッシュせずに、その都度Originサーバーにアクセスするようにさせたいです。そういう操作は可能ですか？
A: Page Ruleを使えば可能です。Cache LevelをBypassに設定して下さい。

https://cloud.ibm.com/docs/cis?topic=cis-use-page-rules#page-rules-performance
https://cloud.ibm.com/docs/cis?topic=cis-best-practices-for-cis-setup#best-practice-review-security-settings-interference

Q: Originサーバーが稼働していなくても、キャッシュされたコンテンツを返し続けるような設定は可能ですか？
A: 可能です。以下をご参照ください。
https://cloud.ibm.com/docs/cis?topic=cis-manage-your-ibm-cloud-internet-services-deployment-for-optimal-reliability#serve-stale-content

Q: Originサーバーでコンテンツを変更したのですが、変更を反映するためにキャッシュをクリアしたいです。定型操作なので、Customer PortalではなくAPIを使ってキャッシュクリアできないでしょうか？
A: APIは以下をご参照ください。
https://cloud.ibm.com/apidocs/cis/cache
なお、ibmcloud cis cache-purgeコマンドを利用してキャッシュクリアすることもできます。

Q: CISでキャッシュできるファイルサイズの上限を教えてください。
Trial Plan/Standard Plan: 512MB
Enterprise plan: 5GB
Enterprise planの利用者はCaseを起票することでもっと大きなファイルをキャッシュできるようにリクエストすることができます。
https://cloud.ibm.com/docs/cis?topic=cis-caching-concepts#default-cache-behavior
https://support.cloudflare.com/hc/en-us/articles/200172516-Understanding-Cloudflare-s-CDN

3-6 WAF

Q: CISのWAFはどのような特徴を持ちますか？どのような攻撃から保護をしてくれますか？
A: 以下のサイトを参照してください。主な特徴を列挙しておきます。
https://www.cloudflare.com/ja-jp/waf/

• SQLインジェクション攻撃、クロスサイトスクリプティング、クロスサイトリクエストフォージェリなどの一般的な脆弱性から保護。
• OWASP Top 10などのルールを提供。カスタムWAFも利用可能。
• 毎秒約290万件のリクエストをチェック。新たな潜在的な脅威が継続的に特定およびブロック。
• 新たなセキュリティ脆弱性がリリースされると自動的に更新。
• ゼロデイ脆弱性に対応
• WAFルールセットのレイテンシーは1ミリ秒未満
• WAFルールのプロパゲーションは30秒

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

Q: WAFのルールをポータル経由ではなく、スクリプトなどで統一的に構成することは可能ですか？
A: API以外にも、Terraformを使ってWAF ruleを構成することも可能です。
https://cloud.ibm.com/docs/terraform?topic=terraform-cis-resources
https://github.com/IBM-Cloud/terraform-provider-ibm

Q: 一律にSensitivityを設定するのではなく、特定の画面（例えばログイン画面）だけはSecurityを強化することは可能ですか？
A: Page ruleを利用して、特定のURLに限ってはSecurity LevelをHighにするといったことが考えられます。下記リンクもご参照ください。
https://cloud.ibm.com/docs/cis?topic=cis-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はEnterprise Planを購入した際に利用できます。ただし、現状では利用者が自由に構成できるわけではなく、メールベースでのリクエストになります。アクセスログやPOSTデータのサンプル情報を元に、IBM CloudのサポートチームがCloudflare社にCustom WAFを作成・登録するという流れのようです。もし提供情報が十分であれば、一般的には1 business dayで作成が完了するようです。なお、アクセスログの形式ついては、これといったガイドラインやフォーマットは存在していません。どういう攻撃パターンなのかとか、どういうUser-Agentからの攻撃なのかなどをCustom WAFを作成する際に参考にしたいらしいというのが趣旨のようであり、一般的なアクセスログであれば問題ないようです。なお、Custom WAFの作成に関する追加料金は、現時点では特に発生しません。
https://cloud.ibm.com/docs/cis?topic=cis-waf-custom-rules

Custom WAFは非推奨となりました。今後はFirewall rulesを代わりに利用する様に指示されています。
https://support.cloudflare.com/hc/en-us/articles/200172016-Understanding-the-Cloudflare-Web-Application-Firewall-WAF-
https://cloud.ibm.com/docs/cis?topic=cis-waf-settings&locale=en

'Q: WAFはuploadファイルのファイルスキャンをしますか？`
A: 実施しません
https://community.cloudflare.com/t/safety-of-files-uploaded-by-visitors-to-site/46468/5

Q: brute-force（ブルートフォースアタック）を防ぐ方法はありますか？
A:WAFではなく、rate limiting(Enterprise Planのみ）の機能で実装可能です。
https://cloud.ibm.com/docs/cis?topic=cis-cis-rate-limiting
https://support.cloudflare.com/hc/en-us/articles/115001635128

Q: ドメイン全体に適用するのではなく、あるURLに対してのみ、特定のWAF Ruleを有効化したり無効化することは可能ですか？
A: Enterprise Planであれば、ibmcloud cis cis waf-override-createを利用すれば可能です。詳細はこちらを参照してください。CloudflareのAPIではこちらに対応します。

3-7 DNS

Q: ProxyありとProxyなしではどのように挙動が違いますか？
A: DNSレコードのProxy設定を有効にすると、CISのDNSが名前解決リクエストへのレスポンスとして返すのはEdgeのIPアドレスになります。その結果、GLBの利用有無に関わらずクライアントからの名前解決後のHTTP(S)リクエストはいったんCISに向かい、そこからEdgeがProxyのような振る舞いをしてFirewall機能やWAF機能やCDN機能を利用しつつ、登録済みDNSレコードのIPアドレスにリクエストを割り振ってくれます。

一方、HTTP(S)以外のリクエストに対しては、CIS Rangeを利用しない限りはCISはProxyのように振る舞うことはありません。そのため、登録済みDNSレコードにリクエストを割り振ることができません。HTTP(S)以外のリクエストにおいて、CISがProxyとして振る舞いうことを期待し、Firewall機能と組み合わせて利用したい場合には、CIS Rangeを検討してください。
よって、HTTP(S)接続以外の目的でCISのDNSにレコードを登録する場合は、Proxy設定を無効にして登録済みDNSレコードを直接返すように構成する必要があります。Proxyが無効なので、この場合はCISを経由せず、Firwall機能やWAF機能やCDN機能は利用されません。

また、Proxyありにすると必ずTTLがAutomaticになります。Automaticについては下記に記載があります。
https://support.cloudflare.com/hc/en-us/articles/360017421192-Cloudflare-DNS-FAQ#whatdoestheautomaticttlvaluemean

Q: DNSレコードをProxyありにしてHTTP(S)アクセスした場合に、Originサーバーでのアクセスログを確認したところ、接続元が全部EdgeのIPアドレスになります。エンドユーザーのIPアドレスを記録するにはどうすればいいですか？
A: HTTPヘッダに含まれるX-Forwarded-ForもしくはCF-Connecting-IPを記録するようにして下さい。

Q: トップレベルドメイン（＝CISに登録したドメイン=ゾーンAPEX）に対して、CNAME Flatteningは有効になっていますか？
A: はい。詳細はこの記事をご参照ください。

Q: PTRレコードは登録できますか？
A: 現時点ではCISではサポートされていません（近日中にサポートされる予定です）。

Q: Zone転送は利用できますか？
A: 現時点ではCISでは利用できません。
（参考）Cloudflareでは、Secondary DNSという機能が存在し、他ドメインからのゾーン転送を受け付けることができるようです。しかし、そもそもCloudflare/CISのDNSにはproxyありとproxyなしが存在します。もし他ドメインからproxy offとして転送されてくればそのDNSに対してはWAF/CDNなどは利用できないことになります（単なるDNS機能を求めているだけなのであればこれでいいのかもしれませんが・・・）。一方で、proxy onとして転送されてくれば（Cloudflare社のサイトを見ると、そういうように構成もできるみたいです）そのレコードは必ずCloudflare/CISのIPアドレスを返すということですから、Primary側とは別のDNSレコードが返ることになります。仮にZone転送を受け付けることができたとしても、Cloudflare/CISの仕組み上、その運用は難しいことになりそうです。
https://support.cloudflare.com/hc/en-us/articles/360001356152-Configuring-Secondary-DNS

3-8 Firewall

Q: Firewallの設定をしましたが反映されません
A:クライアント側のキャッシュに残っていることが原因であることが多いようです。ブラウザを再起動するか、ここのページなども参考にしてください。

Q: 特定のIPアドレスからのみアクセスを許可し、それ以外の環境からはアクセスさせないようにしたいのですが、どうやればできますか？
A: CISにはFirewallとしてIP FirewallとFirewall Rulesの2つが存在しています。
IP Firewallでは、Domain Lockdownを利用すれば可能です。Domain Lockdownは、単にIPアドレスだけでアクセス制御するのではなく、指定したURLパスに対して特定のIPアドレスもしくはIPアドレスレンジからのアクセスのみをホワイトリストとして許可し、それ以外のIPアドレスからのアクセスをブロックします。例えば、自社オフィスから運用用途のURLへの接続のみを許可する場合などに効果的です。
※仕様上は、このIP addresses and rangesの入力数に制限はないようです。

新規に準備されたFirewall Rulesでは、より細かなFirewall構成が可能であり、「指定したIPアドレスレンジにあてはまらない場合（is not in)は、Blockする」というルールを作成することで対応できます。
※仕様上は、Expressionのサイズが4KBまでは１つのruleで入力できるようです。

https://cloud.ibm.com/docs/cis?topic=cis-firewall-rules
https://cloud.ibm.com/docs/cis?topic=cis-actions
https://cloud.ibm.com/docs/cis?topic=cis-fields-and-expressions
https://cloud.ibm.com/docs/cis?topic=cis-cis-plan-comparison

Q: 各種Firewallにおいて、Ruleはいくつ作成できますか？
A: 以下の通りです。
IP Firewallのルール：2000(Standard Plan), 20000(Enterprise Plan)
Domain Lockdownのルール: 10(Standard Plan), 200(Enterprise Plan)
Firewall Rulesのルール: 100(Standard Plan), 1000(Enterprise Plan)

Q: 特定の国（例：日本）からのWebアクセスのみを許可したいのですが、Standard Planでできますか？
A: Firewall Rulesを使えば、Standard Planでも可能です。例えば「指定した国（Japan)にあてはまらない場合（does not equal)は、Blockする」というルールを作成することで対応できます。具体的な判例は以下を参照してください。
https://cloud.ibm.com/docs/cis?topic=cis-fields-and-expressions

Q: 特定のAPIメソッド名のみをアクセス許可したいのですが、可能ですか？
A: Firewall Rulesにて、例えば「特定のURI pathにあてはまらない場合（does not equal)はBlockする」というルールを作成することで対応できます。 具体的な判例は以下を参照してください。
https://cloud.ibm.com/docs/cis?topic=cis-fields-and-expressions

Q: Firewall Rulesにおいて、rule間の優先順位はどうやって決まりますか？
A: Firewall Rulesのrule engineは複数のruleを平行に処理し、その上で対象トラフィックに対してどのruleを適用するかをpriorityとactionに基づいて決定します。

1. １つのHTTP(S)リクエストに対して適用されるruleは1つのみです。あるruleに対して適用された場合は、それ以外のruleは適用されません。
2. デフォルトのpriorityは0（priorityなし）です。priorityは1（最優先）〜2147483647（低優先）から定義することができます。prioirityありのruleの後に、priorityなし（デフォルトの0）が評価されます。
3. もしpriorityを設定していない場合や、同一のpriorityの場合は、rule中に定義したActionがLog > Allow > Challenge > JS Challenge > Blockの順に優先されます。

Q: Firewall Rulesにおいて、１つのruleの中にexpression（条件）はいくつまで定義できますか？
A: 特にexpressionの数は制限はしていないようです。

Q: IP Firewallにてwhitelist, challenge, Javascript challengeを利用した場合には、WAFでもチェックされますか？
A: 検証してみたところ、以下のような挙動になっているようです。

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

Q: CIS RangeでもFirewallを利用できますか？
A: CIS RangeではIP Firewallのみ対応しています。Firewall Rulesには対応していません。

3-9 ログ

Q: Origin Serverまでリクエストが来た場合には、Origin Serverでアクセスログが取得できます。しかし、CISでキャッシュされた場合には、Origin Serverまでリクエストが来ないため、誰がアクセスしてきたのかが分かりません。CIS側でのアクセスログは取得できるのでしょうか？
A: CISでのアクセスログの取得は可能ですが、Standard Planでは取得できません。CIS Enterprise Planのみで利用可能です。またCustomer Portal経由では取得できず、ibmcloud cis logpull コマンドを利用する必要があります。
https://cloud.ibm.com/docs/cis?topic=cis-logpull
https://cloud.ibm.com/docs/cis-cli-plugin?topic=cis-cli-plugin-cis-cli#logpull-section

Q: CISにおけるアクセスログの保管期間は何日ですか？
A: 7日間です。IBM Cloud docsにも以下の記載があります。
https://cloud.ibm.com/docs/cis-cli-plugin?topic=cis-cli-plugin-cis-cli#logpull-section

--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. The 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.

それ以上の保管が必要な場合は、定期的にダウンロードしておくことを推奨します。

Q: アクセスログを自動的にICOS(IBM Cloud Object Storage)に転送する機能はありますか？
LogPushという機能があります。詳細は、以下を参照して下さい。
https://cloud.ibm.com/docs/cis?topic=cis-logpush
https://qiita.com/testnin2/items/175d8cfa991218f21e86

参考： http_requests, range_events, firewall_eventsが指定できます。デフォルトはhttp_requestsです。
https://cloud.ibm.com/docs/cis-cli-plugin?topic=cis-cli-plugin-cis-cli#logpush-job-create

Q: Standard PlanではCISでアクセスログを取得できないということですが、監査上ログ取得は必須です。Standard Planのままで何か代替策はありませんか？
A: パフォーマンスとのトレードオフにはなりますが、CISでキャッシュさせずにOriginサーバー側に毎回アクセスさせることで、Originサーバーでアクセスログを取得するように構成することが回避策の１つとして考えられます。
例えば、デフォルトではhtmlファイルはCISにキャッシュされないため、トップページ（index.html）へのアクセスはOriginサーバーでのアクセスログに残すことができます。もしhtmlファイルをCISにキャッシュさせるように構成したとしても、トップページ配下のindex.htmlのみはCISにキャッシュさせないように構成するというのは１つの方法でしょう。他にも、ログイン画面のような重要性の高いページについてはキャッシュさせずにOriginサーバー側でログを確実に取得するといったことが考えられます。

Q: リクエスト数やコネクション数やDNS、レートリミットなどのメトリックのログを取得できますか？
A: 以下のコマンドで取得可能です。詳細は下記リンクを参照して下さい。

• ibmcloud cis dns-analytics
• ibmcloud cis ratelimit-analytics
• ibmcloud cis firewall-event-analytics
• ibmcloud cis http-request-analytics
• ibmcloud cis range-analytics (Enteprise plan only)
• ibmcloud cis routing-analytics(Enteprise plan only)

Q: WAFやFirewallなどのセキュリティーイベントのログ情報を取得できますか？
A: 以下のコマンドで最大30日までのログが取得可能です。詳細は下記リンクを参照して下さい。

• ibmcloud cis firewall-event-analytics

以下は実行例です。

セキュリティーイベント（WAF）の抽出

# ibmcloud cis firewall-event-analytics a4135402d38fff24e32ef13c82c1ab4a --dataset firewallEventsAdaptive
Getting Firewall event for domain 'a4135402d38fff24e32ef13c82c1ab4a' ...
OK


Action                            block
Client Country Name               JP
Client IP                         2400:4051:b2e0:df00:a908:4664:3eb3:8c19
Client IP Class                   noRecord
Client Referer Scheme             unknown
Client Request HTTP Host          www5.xxxxxx.tk
Client Request HTTP Method Name   GET
Client Request HTTP Protocol      HTTP/2
Client Request Path               /index.html
Datetime                          2021-06-08T05:19:51Z
Edge Colocation Name              NRT
Kind                              firewall
Match Index                       0
Metadata
	Key                               group
	Value                             cloudflare_specials
	Key                               rule_message
	Value                             SQLi - Libinject with Exceptions
Ray Name                          65bfaaed8860f8bb
Rule Id                           100097F
Source                            waf
User Agent                        Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Firefox/78.0

RuleID=100097Fの確認

# ibmcloud cis waf-packages <DNS_DOMAIN_ID>
Listing WAF packaes of domain '<DNS_DOMAIN_ID>' ...
OK
ID                                 Name                              Detection Mode   Sensitivity   Action Mode
059f5a550fffae09cbb4072edf101bd2   USER                              traditional      N/A           N/A
1e334934fd7ae32ad705667f8c1057aa   IBM                               traditional      N/A           N/A
c504870194831cd12c3fc0284f294abb   OWASP ModSecurity Core Rule Set   anomaly          high          block

# ibmcloud cis waf-rule a4135402d38fff24e32ef13c82c1ab4a 1e334934fd7ae32ad705667f8c1057aa 100097F
Displaying WAF rule 100097F of package '1e334934fd7ae32ad705667f8c1057aa' ...
OK

ID             100097F
Description    SQLi - Libinject with Exceptions
Mode           default
Allowed Mode   default,disable,simulate,block,challenge
Priority       109
Group ID       f90712123fb02287348dd34c0a282bb9
Group Name     IBM Specials

Q: 誰がいつDNSレコードやGlobal Load Balancerを作成したのか？などの監査ログを取得することはできますか？
A: IBM Cloud Activity Tracker with LogDNA を利用することで取得が可能です。ただし、IBM Cloud Activity Tracker with LogDNAでのGlobal Eventsは一般的にFrankfurtで管理されることになっていますが、CISではDallasで管理されるので注意してください。 -> 2020年4月22日からCISもFrankfurtで管理されるようになりました。
以下は、DNSにAレコード（参照先は8.8.8.8)を追加した時の例です。

https://cloud.ibm.com/docs/services/Activity-Tracker-with-LogDNA?topic=logdnaat-cloud_services#network
https://cloud.ibm.com/docs/infrastructure/cis?topic=cis-at_events#at_events

3-10 DDoS保護

Q: L3/L4レベルの攻撃に関しては自動的に保護されますか？
A: DNSやGLBでproxyを有効化しておけば、保護されます。CISは基本的にはHTTP(S)でアクセスするシステムを対象としています。
Clientがアクセスする際には、まず最初にCIS上のproxyとの間にTCPレベルで3way handshakeを行ってコネクションを作成し、その上でHTTP(S)リクエストが開始されます。その後、CISのProxyがOrigin Serverとの間で同様の方法でTCPコネクション・HTTP(S)リクエストを開始します。よって、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でもできません）

Q: DDoSがあった場合には通知されますか？
A: 通知されません

Q: DDoSのログを取得することはできますか？
A: できません。

3-11 CIS Range

Q: CIS Rangeとは何ですか？
A: HTTP(S)以外のTCP/UDPについてもCISを経由することで、GLB機能やFirewall機能を利用することができます。Cloudflare社のCloudflare Spectrumに相当する機能です。2019/08月現在、Enterprise PlanもしくはSecurity Planでのみ利用可能です。

Q: CIS RangeでUDPは利用できますか？
TCPはデフォルトで対応しています。UDPを利用したい場合は、「Range UDP enablement request」というタイトルでCaseを起票してください。

Q: CIS Rangeではどのような挙動でアクセスするのでしょうか？
CIS Rangeでは、CISがあたかもProxy Serverであるかのように振る舞い、CIS経由でOrigin Serverにアクセスします。CISを経由する際には、CIS Rangeで外部に公開するPort番号とOrigin ServerのPort番号は異なるように構成することも可能です。IP Firewallオプションを使用している場合は、CISのProxyでフィルタリングされます。よって、CIS Rangeを利用した場合は、Origin Serverにとってのアクセス元IPアドレスはCISになります。

Q: CIS Rangeには「Proxy Protocol」という機能がありますが、これは何ですか？
Proxy Protocol v1をサポートしているアプリケーションのための機能であり、以下のヘッダを追加することで、アクセス端末のIPアドレスを取得することができます。Proxy Protocolに対応していないアプリケーションの場合は、この機能を有効にすると接続できなくなります。
PROXY_STRING + single space + INET_PROTOCOL + single space + CLIENT_IP + single space + PROXY_IP + single space + CLIENT_PORT + single space + PROXY_PORT + "\r\n"
詳細は以下をご参照ください。
https://cloud.ibm.com/docs/cis?topic=cis-cis-range

Q: CIS Rangeにおいて、IP FirewallのChallengeはどのように動作しますか？HTTP(S)の時と同様に何か確認画面が発生するのでしょうか？
A: 特に何もせずに許可をするだけのようです。

Q: CIS Rangeにおいて、ドメインロックダウン機能は使えますか？
A: ドメインロックダウンはHTTP(S)のURLにしか機能しないので適用されません。

Q: CIS RangeとHTTP(S)にて、適用されるIP Firewallルールを分けることはできますか？
A: IP Firewall機能はドメインごとに構成することが可能なので、CIS RangeとHTTP(S)のドメインを分けることでIP Firewallルールを分けることが可能です。

3-12 CIS Edge Functions

Q: CIS Edge Functionsとは何ですか？
A: javascriptをクライアント（ブラウザ）でもなく、オリジンサーバーでもなく、世界中に広がるCloudflare社のEdgeサーバーで実行することができる機能であり、ビジネスロジックをオリジンサーバーやクライアント側のリソースを利用する必要がありません。Cloudflare Workersの機能に相当します。
Standard Planではアクションを1つしか作成できないことにご注意ください。Enterprise Planでは無制限にアクションを作成することができます。GLB PlanやSecurity Planでは利用できません。
https://cloud.ibm.com/docs/cis?topic=cis-cis-plan-comparison

Q: アクションスクリプトのサンプルはありませんか？
A: 以下をご参照ください。
https://developers.cloudflare.com/workers/about/
https://github.com/cloudflare/worker-examples

Q: 開発時にデバッグ処理（コンソールログへの出力など）をしたいのですが、効率よくやる方法はないでしょうか？
A: こういうサイトを利用するのは如何でしょうか？
https://cloudflareworkers.com/

Q: 利用できるScriptのサイズ制限はありますか？
A: 1MBまでです。その他詳細はこちらをご参照ください。

Q: import文を書いたり複数モジュール化することができません。何かいい方法はありませんか？
A: Webpackを使って複数モジュールを1つのファイルに変換することができます。Webpack自身は一般的なやり方なのでググればでてくると思います。
https://blog.cloudflare.com/using-webpack-to-bundle-workers/
https://ics.media/entry/12140/

3-13 ICOSへのアクセス

Q: ICOSに配置したindex.htmlをCIS経由でアクセスすることは可能ですか？
A: 可能です。ICOSのコンテンツをPublic Accessとして公開してAPIキーなしでもアクセスできるようにした後、Page RuleにてResolve OverRide with COSを選択し、ウィザードからICOSのインスタンスやbucketを指定するのがもっとも簡単な構成方法です。詳細手順や仕組みは以下をご参照ください。
https://cloud.ibm.com/docs/cis?topic=cis-resolve-override-cos
https://qiita.com/testnin2/items/dd58ce2051a6e72fcf02