IBM Cloud Docs
最適なセキュリティーのための CIS の管理

最適なセキュリティーのための CIS の管理

IBM Cloud® Internet Services ( CIS ) のセキュリティ設定には、誤検知やトラフィックへの悪影響を避けるための安全なデフォルトが含まれています。 ただし、これらの安全なデフォルト設定が、あらゆるお客様にとって最善のセキュリティー態勢になるとは限りません。 以下の手順に従って、 CIS アカウントが安全かつセキュアな方法で設定されていることを確認してください。

  • プロキシを使用し、難読化を進めることで、オリジンIPアドレスを保護する。
  • セキュリティレベルを選択的に設定する。
  • ウェブアプリケーションファイアウォール(WAF)を安全に有効化する。
  • TLS設定を行う。

ベスト・プラクティス 1: 発信元 IP アドレスをセキュアにする

サブドメインがプロキシに CIS を使用する場合、 CIS はそれに関連付けられた特定のIPアドレスで応答するため、すべてのトラフィックが保護される。 このプロセスは、あなたが最初に CIS プロキシに接続し、あなたの元のIPアドレスを隠すことを保証するのに役立ちます。

オリジンからの HTTP トラフィックには、すべての DNS レコードに CIS プロキシを使用する

オリジンIPアドレスのセキュリティを向上させるには、すべての HTTP、 HTTPS トラフィックをプロキシする必要があります。

プロキシされていないレコードとプロキシされたレコードを照会して違いを確認する:

dig nonproxied.theburritobot.com +short
1.2.3.4 (The origin IP address)

$ dig proxied.theburritobot.com +short
104.16.22.6 , 104.16.23.6 (CIS IP addresses)

非標準の名前を使用して非プロキシーの発信元レコードを隠蔽する

CIS を通してプロキシすることができず、FTPのようなあなたのオリジンIPを依然として使用するレコードは、追加の難読化を作成することで保護することができる。 特に、 CIS でプロキシできないオリジンのレコードが必要な場合は、非標準の名前を使用してください。 例えば、 ftp.example.com の代わりに [random word or-random characters].example.com. を使用します。この難読化を使用すると、DNS レコードの辞書スキャンでお客さまの発信元 IP アドレスが公開される可能性が低くなります。

可能であれば HTTP トラフィックと非 HTTP トラフィックとで異なる IP 範囲を使用する

HTTP、 HTTP 以外のトラフィックに別々のIPレンジを使用する顧客もいる。 このアプローチは、 HTTP IPレンジのすべてのレコードをプロキシし、異なるIPサブネットで HTTP 以外のトラフィックをすべて隠すのに役立つ。

ベスト・プラクティス 2: セキュリティー・レベルを選択的に構成する

セキュリティー・レベルにより、IP レピュテーション・データベースの機密性が設定されます。 悪い相互作用や誤検出を防止するためにも、ドメインごとにセキュリティー・レベルを構成して、それぞれの必要に応じてセキュリティーの程度を適切に調節してください。

機密性の高い領域のセキュリティー・レベルを高めて「高」にする

ドメインのAdvanced Securityページでこのレベルを上げるか、管理ページやログインページにページルールを追加してブルートフォース試行を減らすことができます:

  1. API の URL パターン (** など) を使用して**「ページ・ルール (Page Rule)」www.example.com/wp-loginを作成します。
  2. **「セキュリティー・レベル (Security Level)」**設定を識別します。
  3. 設定に**「高」**のマークを付けます。
  4. **「リソースのプロビジョン (Provision Resource)」**を選択します。

誤検出を削減するために機密ではないパスや API のセキュリティー・レベルを低くする

一般的なページやAPIトラフィックについては、このレベルを下げることができます:

  1. API の URL パターン (** など) を使用して**「ページ・ルール (Page Rule)」www.example.com/api/*を作成します。
  2. **「セキュリティー・レベル (Security Level)」**設定を識別します。
  3. セキュリティレベルを 「低」 または「 基本的にオフ 」にする。
  4. **「リソースのプロビジョン (Provision Resource)」**を選択します。

セキュリティ・レベルの設定とはどういう意味ですか?

セキュリティー・レベル設定は、特定の IP アドレスがネットワーク上での悪意のある動作により取得した脅威スコアと連動しています。 脅威スコアが10を超えると高いとみなされる。

  • : 0 より大きな脅威スコアが検査対象となります。
  • : 14 より大きな脅威スコアが検査対象となります。
  • 低 (LOW): 24 より大きな脅威スコアが検査対象となります。
  • 実質的にオフ (ESSENTIALLY OFF): 49 より大きな脅威スコアが検査対象となります。
  • OFF: エンタープライズのみ
  • 防御モード :このレベルは、ウェブサイトが DDoS 攻撃を受けている場合にのみ使用する必要があります。 CIS がトラフィックと行動を分析し、あなたのウェブサイトにアクセスしようとしているのが正当な訪問者であることを確認する間、訪問者は約5秒間インタースティシャルページを受け取ります。防御モードは、APIの使用など、ドメイン上のいくつかのアクションに影響を与える可能性があります。 そのセクションのページルールを作成することで、APIやドメインの他の部分にカスタムセキュリティレベルを設定することができます。

セキュリティレベルの設定を定期的に見直すことを検討してください。 手順は CIS のセットアップのベスト・プラクティスに記載しています。

ベスト・プラクティス 3: Web アプリケーション・ファイアウォール (WAF) を安全にアクティブ化する

WAF は、セキュリティーのセクションで設定できます。 ここでは、ドメイン全体でWAFを有効にする前に、WAFが可能な限り安全に設定されていることを確認するために、これらの設定を逆の順序で説明します。 これらの初期設定では、セキュリティー・イベントにデータを追加して詳細にチューニングすることにより、誤検出を減らすことができます。 新しい脆弱性が識別されると、WAF はそれに対応できるように自動的に更新されます。 詳しくは、セキュリティー・イベント機能の使用を参照してください。

WAF は、以下のタイプの攻撃からの保護を提供します。

  • SQL インジェクション攻撃
  • クロスサイト・スクリプティング
  • クロスサイト・フォージェリー

WAFにはデフォルトのルールセットが含まれており、最も一般的な攻撃を阻止するルールが含まれている。 現在、WAFを有効または無効にし、WAFルールセットの特定のルールを微調整することができます。 ルールセットおよび各ルールの動作に関する詳細は 、WAF アクションの ドキュメントを参照してください。

詳しくは、Web アプリケーション・ファイアウォール (WAF) の概念を参照してください。

ベスト・プラクティス 4: TLS 設定を構成する

IBM CIS リバースプロキシとして機能し、トラフィックを暗号化するための複数のオプションを提供します。 リバース・プロキシーでは、データ・センターでの TLS 接続が閉じられ、起点サーバーへの新規 TLS 接続が開かれます。

TLSには、最もセキュアなものから最もセキュアでないもの(Off)まで、6つの動作モードがある:

  1. 認証されたオリジンのプル :(エンタープライズのみ)
  2. 「HTTPS のみ発信元プル (HTTPS only origin pull)」(エンタープライズのみ)
  3. 「エンドツーエンド - CA 署名」(デフォルトで推奨)
  4. 「エンドツーエンド - フレキシブル」(エッジから発信元の間には自己署名の証明書を使用できます)
  5. 「クライアントからエッジ」(エッジから起点の間は暗号化されず、自己署名の証明書はサポートされません)
  6. 「オフ」 (非推奨)

異なる動作モードの詳細については、 TLSオプションを 参照のこと。

IBM CIS では、カスタム証明書を使用することも、 CIS でプロビジョニングされたワイルドカード証明書を使用することもできます。

カスタム証明書のアップロード

証明書の追加] をクリックし、証明書、秘密鍵、バンドル方法を入力することで、カスタム証明書をアップロードできます。 カスタム証明書をアップロードした後、暗号化されたトラフィックとの互換性がすぐに得られ、証明書(例えば、EV(Extended Validation)証明書)の制御が維持されます。 CIS、注文された証明書またはユニバーサル証明書による証明書のピン留めはサポートされていません。 証明書の固定化を使用する場合は、独自のカスタム証明書をアップロードして管理することをお勧めします。

カスタム証明書をアップロードした場合、証明書の管理はお客様の責任となります。 例えば、 CIS は証明書の有効期限を追跡しない。

専用証明書の注文

CIS は、専用の証明書を提供することで、証明書の管理を簡単にします。 秘密鍵の生成、証明書署名要求 (CSR) の作成、証明書を忘れずに更新することなどは必要なくなります。 証明書の追加をクリックしてワイルドカード証明書を注文するか、ホスト名を入力して専用のカスタム証明書を注文することで、専用の証明書を注文できます。 証明書の種類は以下の通り:

  • SHA-2/ECDSA P-256 鍵を使用する署名入り証明書、
  • SHA-2/RSA RSA 2048ビット鍵を使用する署名付き証明書
  • SHA-1/RSA RSA 2048 ビット鍵を使用する署名入り証明書。

CIS は、以下を除くすべてのトップレベル・ドメイン(TLD)の証明書を発行できる:

  • .cu (キューバ)
  • .iq (イラク)
  • .ir (イラン)
  • .kp (北朝鮮)
  • .sd (スーダン)
  • .ss (南スーダン)
  • .ye (イエメン)

CIS 証明書の有効期限を管理する。 専用カスタム証明書のホスト名を編集するには、再注文してから削除する必要があります。 例えば、ホスト名 alpha.yourdomain.com の専用カスタム証明書を注文したとします。 ホスト名 beta.yourdomain.com を専用カスタム証明書に追加するには、ホスト名 alpha.yourdomain.com および beta.yourdomain.com の、別の専用カスタム証明書を注文します。 その後、元の専用カスタム証明書を削除する_必要があります_。

専用証明書を初めて発注する場合、ドメイン制御検証(DCV)プロセスが発生し、対応する TXT レコードが生成される。 TXT レコードを削除すると、別の専用証明書を注文する際に、DCV プロセスが再度発生する。 専用証明書を削除しても、DCV プロセスに対応する TXT レコードは削除されません。

以下は、専用証明書を注文する際によく見られるエラーです:

  • Error connecting to certificate service.
  • Error while requesting from certificate service.

証明書を注文する際にエラーが表示された場合は、ページを更新して再度お試しください。

プロビジョンされた証明書の使用

IBM は、お客様にドメインのワイルドカード証明書を提供する複数の認証局 (CA) とパートナー関係を結んでいます。 これらの証明書の設定には、手作業による検証が必要な場合がある。 これらの追加ステップを実行する際には、サポート・チームの支援を受けることができます。

エッジでの証明書の優先順位

以下のリストは、証明書がエッジに表示される優先順位を示している:

  1. アップロードされたカスタム
  2. 専用カスタム
  3. 専用ワイルドカード
  4. ユニバーサル

最小 TLS バージョン

最小 TLS バージョンを参照してください。 TLS のレベルが高いとセキュリティーも高くなりますが、顧客がサイトに接続することが妨げられる可能性もあります。

ベスト・プラクティス 5: 速度制限の構成

レート制限ルールを使用して、 URL パターンに一致する、または定義されたしきい値を超えるクライアント IP アドレスをブロックすることで、悪意のあるトラフィックからサイトまたは API を保護します。 レート制限の主な使用例は以下の通り:

  • リソースに対するきめ細かいアクセス制御を実施します。 このプロセスには、ユーザーエージェント、IPアドレス、リファラー、ホスト、国、世界地域などの基準に基づくアクセス制御が含まれる。
    • ユーザー・エージェントによる制限: 一般的なユース・ケースは、個々のユーザー・エージェントによって実行される要求の速度を制限することです。
    • 特定のIPアドレスまたはASNを許可する:リソースへのアクセスを制御するもう1つのユースケースは、レート制限ルールからIPアドレスまたはASN(Autonomous System Numbers)を除外または含めることです。
    • リファラーによる制限: アプリケーションの中には、他のソースから発信されたリクエストを受け取るものがあります(例えば、サードパーティのページにリンクする広告によって使用されます)。 個々のリファラーページが生成するリクエスト数を制限して、クォータを管理したり、間接的な DDoS 攻撃を回避したりできます。
    • 宛先ホストによる制限:ホストをカウント特性として使用するレート制限ルールを作成します。
  • 資格情報の詰め込みやアカウント乗っ取り攻撃から保護します。
  • 個々のクライアントによって実行される操作の数を制限します。 この対策には、ボットによるスクレイピング、機密データへのアクセス、新規アカウントの一括作成、eコマース・プラットフォームにおけるプログラムによる購入の防止などが含まれる。
    • コンテンツのスクレイピングを防ぐ(クエリー文字列を通して)
    • コンテンツのスクレイピングを防ぐ(ボディを通して)
    • ボットからの要求の制限
  • リソースの枯渇 (ターゲットを絞った DDoS 攻撃) から REST API を保護し、リソースを一般的に悪用から保護します。
    • 大量の攻撃の防止
    • リソースの保護
  • サーバーの過負荷を防止し、操作数を制限することで、 GraphQL API を保護します。
    • 操作数の制限
    • サーバーの過負荷の防止