0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@tyskJ

OCI Cloud Guard で実現する発見的統制

0
Last updated at Posted at 2026-03-14

001samune.png

はじめに

本記事では OCI Cloud Guard についてまとめていきます。

概要

OCI Cloud Guard は、クラウド全体の脆弱性を監視・是正する サービスです。
CSPM を実現するサービスです。

具体的な機能としては以下の通りです。

  • デプロイしている OCI サービス設定内容に関するセキュリティリスク診断
  • IAM ユーザーの アクティビティに関するセキュリティリスク診断
  • AWS で言うと、AWS Security Hub CSPM + Amazon GuardDuty みたいなサービスという印象です

OCI Cloud Guard を構成するコンポーネントをそれぞれ見ていきましょう。

Target (ターゲット)

OCI Cloud Guard にて チェックする対象のこと です。
具体的には コンパートメントを指定 します。
ポイントは以下のとおりです。

  • 指定したコンパートメントの 子コンパートメントもチェック対象 になる
  • IAM ポリシーを検査する には ルートコンパートメントを指定する必要がある

Detector (ディテクタ)

ディテクタ・レシピを基にターゲットで指定したコンパートメントのリソース及びアクティビティを監視及び問題点を検出 します。

ディテクタ・レシピとは検出ルールの集合です。
ディテクタ・レシピの種類は以下 5 種類あります。

レシピ名 概要
OCI Configuration Detector Recipe ・各OCIサービス設定を監視するルール
OCI Activity Detector Recipe ・リソース操作を監視するルール
OCI Threat Detector Recipe ・IAMユーザーの不正操作を監視するルール
OCI Instance Security Detector Recipe ・コンピュートでの不審な振る舞いを監視するルール
OCI Container Security Config Recipe ・OKE環境にて実行されるポリシー違反したコンテナを監視するルール

上記オラクルマネージドディテクタ・レシピがデフォルトで提供されています。
カスタムディテクタ・レシピを作成することも可能で、その場合はオラクルマネージドディテクタ・レシピをクローンして作成します。

  • オラクルマネージドディテクタ・レシピに定義されているルールの無効及びリスクレベルの変更はできません。ただし、ルール毎に Conditional group という設定項目が有り、特定のリソースを対象・除外することは可能です
  • そのためオラクルマネージドでも監視対象リソースのフィルタリングは可能ですが、そういった対応が必要な場合は基本的にカスタムディテクタ・レシピを作成して対応しましょう
  • ディテクタ・レシピの変更に関するベストプラクティスは以下ドキュメントを参照してみてください

Responder (レスポンダ)

ディテクタが問題を検出した際に レスポンダレシピを基に OCI Cloud Guard がアクションを実行 します。

レスポンダの種類は以下 2 種類です。

タイプ 概要
Notification ・ディテクタで問題を検出した際のイベントを OCI Events にプッシュする
Remediation ・ディテクタで検出した問題を修正する

レスポンダ・レシピとは上記タイプのアクションルールの集合です。
デフォルトでは オラクルマネージドの OCI Responder Recipe が提供されています。
カスタムレスポンダ・レシピを作成することも可能で、その場合はオラクルマネージドレスポンダ・レシピをクローンして作成します。

ディテクタ・レシピと同様に、レスポンダ・レシピもターゲットにアタッチする必要があります。

  • オラクルマネージドレスポンダ・レシピに定義されているルールの無効化はできません

使用方法(デモ)

検証構成

検証構成図は以下の通りです。
なお、以下リソースは作成済みで進めていきます。

  • 子コンパートメント
  • 可視性がパブリックのバケット

検証では、OCI Cloud Guard を有効化し、実際に検出されるかを確かめていきます。

architecture.drawio.png

  • 環境コードは以下 GitHub にあげてますので、よかったら覗いてみてください

OCI Cloud Guard 有効化

OCI コンソール左上のハンバーガーマークをクリックし、Identity & Security → Cloud Guard をクリックします。
図1.png

「Enable Cloud Guard」をクリックします。
図2.png

最初は、Cloud Guard 自身が各サービスを検査するのに必要な IAM ポリシーの作成を促されますので「Create policy」をクリックします。
図3.png

作成に成功すると「Next」ボタンが有効になるのでクリックします。
図4.png

  • 実際に作成されたポリシーは以下の通りです
  • ルートコンパートメントに作成されます
CloudGuardPolicies
allow service cloudguard to manage cloudevents-rules in tenancy where target.rule.type='managed'
allow service cloudguard to read vaults in tenancy
allow service cloudguard to read keys in tenancy
allow service cloudguard to read compartments in tenancy
allow service cloudguard to read tenancies in tenancy
allow service cloudguard to read audit-events in tenancy
allow service cloudguard to read compute-management-family in tenancy
allow service cloudguard to read instance-family in tenancy
allow service cloudguard to read virtual-network-family in tenancy
allow service cloudguard to read volume-family in tenancy
allow service cloudguard to read database-family in tenancy
allow service cloudguard to read object-family in tenancy
allow service cloudguard to read load-balancers in tenancy
allow service cloudguard to read users in tenancy
allow service cloudguard to read groups in tenancy
allow service cloudguard to read policies in tenancy
allow service cloudguard to read dynamic-groups in tenancy
allow service cloudguard to read authentication-policies in tenancy
allow service cloudguard to use network-security-groups in tenancy
allow service cloudguard to read data-safe-family in tenancy
allow service cloudguard to read autonomous-database-family in tenancy
allow service cloudguard to read log-groups in tenancy
Allow any-user to { WLP_BOM_READ } in tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent'}
Allow any-user to { WLP_CONFIG_READ } in tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent'}
Endorse any-user to { WLP_LOG_CREATE } in any-tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent' }
Endorse any-user to { WLP_METRICS_CREATE } in any-tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent' }
Endorse any-user to { WLP_ADHOC_QUERY_READ } in any-tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent' }
Endorse any-user to { WLP_ADHOC_RESULTS_CREATE } in any-tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent'}

続いて自動作成ウィザードが表示されます。
Select a region は、Cloud Guard の検出結果を保持するリージョンです。
リージョンの変更は一度 Cloud Guard を無効化する必要がある ため慎重に選択しましょう。

Compartments to monitor は、Cloud Guard で監視する対象のコンパートメントを選択 します。
ここで選択したコンパートメントを指定したターゲットが自動作成されます。
ターゲットの設定変更・削除は後からでも可能 なので、最初は All で問題ないと思います。
自動でターゲットを作成してほしくない場合は None を選択 しましょう。

recipe で指定したレシピは、自動作成されるターゲットにアタッチされます。
カスタムレシピを作成していなければオラクルマネージドのレシピから選択が可能です。
後からアタッチ・デタッチは可能です。
図1.png

  • ちなみにオラクルマネージドのレシピはルートコンパートメントに所属しています

上記の通り有効化すると、ルートコンパートメントに、ルートコンパートメントを対象とする、ルートコンパートメント名のターゲットが自動作成されます。
図2.png

ターゲットの構成を見ると、ウィザードで指定したレシピがアタッチされているのも確認できます。
図3.png

  • 試しに無効化すると、ターゲットは削除されました
    image.png
    図4.png

設定してから時間はかかりましたが(約30~40分くらい)、実際に検出結果がダッシュボードに表示されているのが確認できました。
図1.png

通知受信までを設定

有効化するだけでは、上記の通り検出はされますが、通知や自動修正はされません。
また、オラクルマネージドレスポンダ・レシピではルール毎の有効無効が制御できないので、今回はカスタムレスポンダ・レシピを作成しターゲットにアタッチします。
加えて、こちら でも触れましたが、レスポンダ・レシピの Notification タイプルールはあくまでイベントを OCI Events にプッシュするだけ です。
そのため実際に通知を受信するにはイベントルールと通知を作成する必要があります。

OCI Notifications にてトピックとサブスクリプションを作成

まず始めに OCI Notifications にてトピックとサブスクリプションを作成します。
手順は割愛しますが、今回はルートコンパートメントに作成しました。
後述するイベントルールと異なるコンパートメントに作成しても問題ありません。
図2.png
図3.png

OCI Events にてイベントルールを作成

続いて、OCI Cloud Guard がプッシュしたイベントを拾って通知をするためのイベントルールを作成します。
ここで 1つ注意点があります。
OCI Cloud Guard がプッシュするイベント (に限らずOCIリソースがプッシュするイベント) は、OCIリソースが所属するコンパートメントに閉じられます。
加えてイベントルールは、所属するコンパートメント及び子コンパートメントのイベントを拾います。

イベントは、このコンパートメントに作成したルールと、このコンパートメントおよび子コンパートメントのリソースから発行されたイベント・メッセージを比較します。

そのため、検出されたOCIリソースが存在するコンパートメントもしくは上位のコンパートメントにイベントルールを作成する必要がある ということです。

今回は全てのコンパートメントのイベントを拾いたいので、ルートコンパートメントにイベントルールを作成します。

OCI コンソール左上のハンバーガーマークをクリックし、 Identity & Security → Cloud Guard をクリックします。
図4.png

Create Rule をクリックします。
図5.png

各種項目を入力します。ポイントは、Event Type を Detected - Problem としている点です。
Actions に OCI Notifications のトピックを選択し Create Rule をクリックして完了です。
図6.png

カスタムレスポンダ・レシピの作成 & ターゲットへのアタッチ

続いて OCI Cloud Guard からイベントをプッシュするための設定をしていきます。

Responder recipes にて Clone をクリックします。
図7.png

Recipe にてクローン基になるオラクルマネージドレスポンダ・レシピを選択し Clone をクリックします。
図8.png

クローン直後だと、クローン基と設定値は同じなので、修正していきます。
カスタムレスポンダ・レシピ内の Responder rules を選択し、Remediation タイプのルール全てにチェックを入れます。
図9.png

その状態で Actions → Disable をクリックします。確認画面が出るので Disable をクリックし完了です。
図10.png

続いてターゲットにアタッチしていきます。
アタッチするターゲットをクリックします。
図11.png

Configuration タブ内の Responder recipes 欄の Add recipes をクリックします。
図12.png

先程作成したカスタムレスポンダ・レシピを選択し Add recipes をクリックして完了です。
図13.png

通知確認

実際にメールを受信し、パブリックなバケットに対する検出結果を確認できました。
図10.png

レスポンダアクティビティとしてもイベントをプッシュしているのが確認できます。
図15.png

自動修復を設定

続いて自動修復の設定を有効化していきます。
Remediation タイプのルールは、一部対象外ですが、設定することで自動修復をすることが可能です。
今回は、可視性がパブリックのバケットをプライベートに修復するルールを自動化します。

IAMポリシーにステートメント追加

こちら でも触れた通り、OCI Cloud Guard を有効化する際に IAM ポリシーを作成しました。
こちらの IAM ポリシーは読み取りの権限しか付与されていません。
そのため、修復を実施するための IAM ポリシーを付与します。

ターゲットメニュー内のレスポンダ・レシピを選択します。
図6.png

Make Bucket Private ルールの Edit をクリックします。
図7.png

Add statements をクリックします。
図8.png

Success となればOKです。
image.png

自動修復有効化

先程の画面上にて、Execute automatically にチェックを変更し、同意ボタンにもチェックを入れます。
実行時のイベントをプッシュしたいので Post Remediation Notification は有効のままにします。
自動修復を有効化する場合は条件グループの指定が必須のため、 今回は東京リージョンのリソースを対象とするように指定しています。
各項目入力後 Save をクリックして完了です。
図9.png

ルール有効化

最後にルールを有効化します。
無効化した際の手順と同様に、Make Bucket Private ルールを選択し、Actions → Enable で有効化します。
image.png

動作確認

時間をおいて確認すると、バケットの可視性がプライベートに修正されていました。
image.png

レスポンダアクティビティとしても対応した際のイベントがプッシュされているのが確認できます。
image.png

今回の手順では設定を入れていませんが、イベントルールに Remidiate のイベントを拾う設定を入れると、以下の用に修正後のイベント通知を受信することが可能です。
図11.png

おわりに

本記事では、クラウド全体の脆弱性を監視・是正するサービスである OCI Cloud Guard についてまとめました。
無償で利用可能なサービス ですので商用環境では必ず有効化しましょう。

🌟この記事が誰かの役に立てば幸いです！
また、ご質問やフィードバックもお待ちしています。

番外編

ディテクタ・レシピ & レスポンダ・レシピ の編集における注意点

それぞれ編集する場所が２つあり、場所によって編集可能な内容が異なります。

ディテクタ・レシピについて

１つ目の場所は ディテクタ・レシピメニューからの編集 です。
図1.png

ここでは以下 4 つの項目が編集可能です。

  • ステータス
  • リスクレベル
  • ラベル
  • 条件グループ

image.png

2つ目の場所は ターゲットメニュー内のディテクタ・レシピからの編集 です。
図2.png

ここでは以下 1 つの項目が編集可能です。

  • 条件グループ

image.png

レスポンダ・レシピについて

１つ目の場所は レスポンダ・レシピメニューからの編集 です。
図3.png

ここでは以下 1 つの項目が編集可能です。

  • ステータス

image.png

2つ目の場所は ターゲットメニュー内のレスポンダ・レシピからの編集 です。
図4.png

ここでは以下 4 つの項目が編集可能です。

  • IAMポリシーステートメントの追加
  • ルールトリガー
  • イベントプッシュ
  • 条件グループ

図5.png

参考資料

リファレンス

ブログ

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?