Security Operationsの有効化

企業がクラウドを導入するプロセスを開始する際、セキュリティは一貫して最大の関心事の1つです。

クラウド開発は迅速であるため、情報セキュリティ最高責任者(CISO)および関連チームは、クラウドに最初のワークロードをデプロイする前に、セキュリティについて質問することがよくあります。質問には次の例が含まれます。

• 構成ミスおよびリスクの高いアクティビティがクラウドで発生したかどうかはどのようにしたらわかりますか。
• インシデント発生時の応答時間を短縮するにはどのようにしますか。
• セキュリティのベスト・プラクティスを適用するにはどのようにしますか。
• クラウド運用を既存のセキュリティ・プラクティスに統合するにはどのようにしますか。
• 新しいサービスおよびベスト・プラクティスの最新情報を常に把握しておくにはどのようにしますか。
• コンプライアンスを維持するにはどのようにしますか。

詳細は、クラウド中心のCISOのミッションを参照してください。

Security Operations Teamsを早期に有効化

OCIへのオンボーディングの重要な部分は、クラウド導入イニシアチブの開始時にセキュリティ・チームとコラボレーションすることです。プラットフォーム・チームおよび運用チームと協力して、すべての業務にクラウド・セキュリティ・プラクティスを組み込みます。

ほとんどの組織にとって、クラウドの導入には、高い学習曲線と、複数のチームにまたがる大きな文化の変化が伴います。後でなく、プランニングとアーキテクチャのフェーズの早い段階でサイバーセキュリティ・チームに働きかけ、チームがクラウド・サービスの機能と制限に関する共通の理解を持ってプロセスを形成および調整できるようにします。プラットフォーム・チームおよびアプリケーション・チームからの早期のフィードバックにより、セキュリティ管理プロセスは、後で妨げとなるのではなく、クラウド・イニシアチブに対するイネーブラーおよびプロテクタになる可能性が高くなります。

クラウド・ガードの使用

クラウド・ガードは、Oracle Cloudで強力なセキュリティ・ポスチャをモニター、識別、実現および維持するのに役立つ、クラウドネイティブ・サービスである。このサービスを使用して、OCIリソースに構成に関連するセキュリティの脆弱性がないかを調べ、OCIオペレータおよびユーザーにリスクのあるアクティビティがあるかを調べます。検出時、クラウド・ガードは、構成に基づいて修正処理を提案、支援または実行できます。

• クラウド・ガードは、Oracle管理またはユーザー管理ディテクタおよびレスポンダ・レシピを使用します。レシピは、様々な状態に対する識別または応答のルールの組合せです。
• クラウド・ガードが誤って構成されたリソースやテナント間のセキュアでないアクティビティを検出できるように、ディテクタ・レシピでOCIコンパートメントをターゲットにできます。
• クラウド・ガードは、セキュリティ管理者にクラウド・セキュリティの問題を切り分けて解決するための可視性を提供します。
• セキュリティの不整合は、即時利用可能なセキュリティ・レシピで自動的に修正できるため、セキュリティ運用を迅速かつ効率的にスケーリングできます。
• OCI通知サービスを使用して、クラウド・ガード・イベントの詳細(問題のしきい値に達した、問題が検出されたなど)を、既存のプロセスと統合できます。たとえば、通知では、Slackまたは電子メール・メッセージを送信したり、カスタムOCI関数を使用して自動化をトリガーできます。
• Oracle管理レシピは、OCIが最新のルールで最新の状態に維持するため、優れたベースラインを提供します。セキュリティ・ポリシー・チーム(グリーン・チーム)は、Oracle管理レシピをクローニングし、ルールを無効化したり、リスク・レベルを改訂したりしてユーザー管理レシピを作成することにより、組織のニーズに合せてこれらのルールをさらに調整できます。

レポート・リージョンを慎重に選択

クラウド・ガードを有効にすると、レポート・リージョンを選択するように求められます。レポート・リージョンの選択結果を次のものとします:

• 選択したレポート・リージョンによって、組織は、レポート・リージョンがホストされている国のすべての法的要件に準拠するように拘束されます。
• クラウド・ガードを有効にした後は、クラウド・ガードを無効にして再度有効にしないかぎり、レポート・リージョンを変更できません。
• Cloud Guardを無効にすると、すべてのカスタマイズおよび既存の問題(履歴を含む)は失われ、それらのカスタマイズを手動でリストアする必要があります。
• READを除くすべてのAPIコールは、レポート・リージョンで実行する必要があります。クラウド・ガードを有効化するステップを開始する前に、レポート・リージョンに最適な決定を行ってください。

ターゲットをコンパートメントにマップする方法の計画

異なるコンパートメントを異なる方法で監視できるようにターゲットを設定する必要がある場合は、ターゲットをコンパートメントにマップする際に次のガイドラインに留意してください:

• ターゲットのすべてのコンパートメントは、そのターゲットの構成を継承します。ターゲットに対するディテクタおよびレスポンダ・ルールの設定は、そのターゲットに割り当てられた最上位レベル・コンパートメントと、コンパートメント階層内でその下位にあるすべてのコンパートメントに適用されます。一部のコンパートメントをモニタリングから除外する場合は、ルート・レベルの下位にターゲットを作成し、どのターゲットにもルート・コンパートメントを含めないでください。
• 既存のターゲット内で定義されたターゲットは、継承された構成をオーバーライドします。既存のターゲット内で、ターゲットの最上位レベル・コンパートメントの下位にあるコンパートメントを新しいターゲットに割り当てることができます。新しいターゲットに対する検出器およびレスポンダ・ルールの設定は変更可能で、それらの設定は、そのターゲットに割り当てられたトップレベル・コンパートメントと、コンパートメント階層内でその下にあるすべてのコンパートメントに適用されます。

重要な設計の意思決定

主な設計決定事項については、次の情報を参照してください。

• クラウド・ガードのレポート・リージョン。クラウド・ガードを無効にせずに変更できません

• 初期の最上位レベルのターゲットおよび例外戦略を定義します。

  • サンドボックスやPoCなど、クラウド・ガード・モニタリングから除外できるコンパートメントはありますか。

    そうでない場合は、ルート・コンパートメントで初期ターゲットを定義して、テナンシ全体が例外なくモニターされていることを確認します。

    はいの場合、例外を許可するには、ルート以外のコンパートメントにのみクラウド・ガード・ターゲットを作成します。

• レスポンス・レシピおよび適用可能な適用範囲を評価します。

• クラウド・ガード監視の操作フロー。たとえば:
  • レシピおよびターゲットを変更できるのは誰ですか。
  • 自動応答が強制されない場合に修正処理を実行する必要があるのは誰ですか。

クラウド・ガードを使用したセキュリティ・ゾーンの評価および使用

クラウド・ガードは構成ミスを検出し、セキュリティ・ゾーンはこれらの問題の発生を防ぐのに役立ちます。

セキュリティ・ゾーンは、コンパートメントをセキュリティ・ゾーン・レシピに関連付けることで作成されます。セキュリティ・ゾーンでリソースを作成して更新すると、OCIでは、セキュリティ・ゾーン・レシピで定義されたポリシーのリストに対してこれらの操作が検証されます。セキュリティ・ゾーン・ポリシーに違反している場合、操作は拒否されます。ただし、セキュリティ・ゾーンの前に作成された既存のリソースがポリシーに違反することもあります。OCIセキュリティ・ゾーンがクラウド・ガードと統合され、既存のリソースのポリシー違反を識別します。

Oracleは、使用可能なすべてのセキュリティ・ゾーン・ポリシーを含む、最大セキュリティ・レシピという名前の単一の事前定義済レシピを管理します。最大セキュリティ・レシピのポリシーは比較的厳格であり、カスタマイズできないため、組織のブルー・レシピは、セキュリティ・ゾーンをアプリケーション・アーキテクトと共同で評価した後にのみ、適切なワークロードについて検討してください。必要に応じて独自のセキュリティ・レシピを作成します。

セキュリティの原則

一般的に、セキュリティ・ゾーン・ポリシーは次のコア・セキュリティ原則に準拠しています:

• セキュリティ・ゾーンの外部のコンパートメントは安全性が低い可能性があるため、セキュリティ・ゾーン内のリソースをそのようなコンパートメントに移動することはできません。
• セキュリティ・ゾーンのリソースに必要なすべてのコンポーネントも同じセキュリティ・ゾーンに配置されている必要があります。セキュリティ・ゾーンにないリソースは脆弱で、別のセキュリティ・ゾーンのリソースはセキュリティ状態が低い可能性があります。たとえば、セキュリティ・ゾーン内のコンピュート・インスタンスでは、同じセキュリティ・ゾーンにないブート・ボリュームは使用できません。
• セキュリティ・ゾーン内のリソースは、パブリック・インターネットからアクセスできない必要があります。
• セキュリティ・ゾーン内のリソースは、顧客管理キーを使用して暗号化する必要があります。
• セキュリティ・ゾーン内のリソースは、定期的に自動バックアップする必要があります。
• セキュリティ・ゾーン内のデータは特権的とみなされ、セキュリティ・ゾーンの外部にコピーできません。これは安全性が低い可能性があるためです。
• セキュリティ・ゾーン内のリソースは、Oracleが承認した構成およびテンプレートのみを使用する必要があります。詳細は、セキュリティ・ゾーン・ポリシーを参照してください

クラウド・ガード・ターゲットとの関係

• 親コンパートメントがすでにセキュリティ・ゾーン内にあるサブコンパートメントのセキュリティ・ゾーンを作成すると、クラウド・ガードは次のタスクを実行します:
  1. サブコンパートメント用の個別のセキュリティ・ゾーン・ターゲットの作成
  2. 新しいセキュリティ・ゾーン・ターゲットへのデフォルトのOracle管理ディテクタ・レシピの追加
• 親コンパートメントの既存のクラウド・ガード・ターゲットは変更されません。
• 1つのコンパートメントが複数のセキュリティ・ゾーン内にあってはならず、複数のクラウド・ガード・ターゲット内にあってもなりません。

重要な設計決定

• セキュリティ・ゾーン・ポリシーを評価します。
• 非インターネット接続モジュールなどの適用可能なスコープと、開発ライフサイクルの早期に組込みなどの強制プロセスを定義して、後のステージでのロールアウトのブロックを回避します。

定期的なスキャンによる脆弱性のモニター

OCI Vulnerability Scanning Serviceは、ホストで潜在的な脆弱性を定期的にチェックすることで、OCIのセキュリティ状態を改善するのに役立ちます。サービスでは、メトリックおよび結果の詳細を含むレポートが生成されます

脆弱性スキャン・サービスでは、コンピュート・インスタンスおよびコンテナ・イメージ内のいくつかのタイプのセキュリティの問題を識別できます。

• 意図せずに開いたままになっているポートは、クラウド・リソースへの潜在的な攻撃ベクトルになったり、ハッカーが他の脆弱性を悪用するために使用する可能性があります
• 脆弱性に対処するために更新およびパッチが必要なOSパッケージ
• ハッカーが悪用する可能性のあるOS構成
• Center for Internet Security (CIS)によって公開されている業界標準のベンチマーク

脆弱性スキャンは、Distribution Independent Linux用に定義されたセクション5 (アクセス、認証および認可)ベンチマークへの準拠に対してホストをチェックします

Oracle Cloud Infrastructure Registry(コンテナ・レジストリとも呼ばれる)でリポジトリを作成すると、リポジトリでイメージ・スキャンがデフォルトで有効になります。イメージがリポジトリにプッシュされるたびに、そのイメージは共通脆弱性識別子(CVE)データベースでセキュリティの脆弱性がスキャンされます。コンテナ・レジストリは、前回のスキャン以降に変更されたリポジトリ内のイメージを自動的に再スキャンします。

セキュリティ・チームでは、クラウド・ガードのデフォルト構成ディテクタ・レシピを使用して、脆弱性スキャン・サービスによって識別されるセキュリティ脆弱性を検出して対応することもできます。

脆弱性ソース

脆弱性スキャンは、次のプラットフォームで、次の脆弱性ソースを使用して脆弱性を検出します。

考慮事項

• WindowsスキャンにはOVALデータが含まれていないため、Windowsインスタンスが最新で安全であることを確認するためにOCI Vulnerability Scanningのみに依存することはお薦めしません。
• 脆弱性スキャン・サービスを使用して仮想マシン(VM)データベース(DB)システムの問題を識別し、各問題に対処するようにOSを変更することはお薦めしません。かわりに、DBシステムを更新する手順に従って、最新のセキュリティ更新をOSに適用します。
• 脆弱性スキャン・サービスは、Oracle Exadata Database Service on Dedicated Infrastructureやデータベース・サービスなどのOCI Computeサービスで直接作成されなかったホストでは使用できません。これらのサービスに用意されている機能を使用して、ホストに最新のセキュリティ更新があることを確認します。

ログ・アーカイブとSIEM統合

ロギングは、セキュリティ・アナリストが潜在的なセキュリティ違反や情報の内部誤用を検出するために不可欠です。

Oracle Cloud Infrastructure Loggingでは、アナリストはOCIリソースからログにアクセスできます。これには、リソースの実行方法や、アクセス方法を示す重要な診断情報が含まれます。ロギングは、テナンシ内のすべてのログ用の、スケーラビリティに優れた完全管理型の単一管理ポイントです。

デフォルトでは、監査ログは365日間保持されます。OCI Service Connector Hubでは、一部の規制対象産業のコンプライアンス要件を満たすために、ログを不変ストレージに長期間のアーカイブできます。同様のパターンを使用すると、ログは、OCIストリーミング・サービスを使用すると、SplunkやQRadarなどのサードパーティのセキュリティ情報およびイベント管理(SIEM)ツールと統合できます。

重要な設計決定

• 必須ログ・アーカイブ期間: 365日で十分ですか。それとも、不変ストレージを使用してさらに保持する必要がありますか。
• 既存のSIEM統合が必要:既存のSIEMソリューションと統合する必要がありますか。

関連情報

• SIEM統合の設計ガイダンス
• 監査ログをSplunkにエクスポートするサーバーレス・パイプラインを使用してSIEMシステムを実装します。
• OCI Functionsを使用したOracle Cloud InfrastructureログのMicrosoft Azure Sentinelへの取込み

参照実装

• クラウド導入フレームワークのコア・ランディング・ゾーン
• セキュリティ・ゾーンを使用したクラウド内のワークロードの保護