はじめに

こんにちは。宮井です。

「Oracle Cloud Guard(クラウド・ガード)」 の第三弾です。
みなさん、過去2回分は読んで頂きましたでしょうか?

●第一弾「クラウド・ガードを設定してみました①~セキュリティリスクの検知~」の記事はこちら
●第二弾「クラウド・ガードを設定してみました②~セキュリティリスクへの対処方法~」の記事はこちら
あわせてご覧くださいませ!

前回までは、クラウド・ガードのコンソール画面から公開設定としてしまったオブジェクトストレージのバケットを検知して、コンソール画面上から修正する方法を確認しました。

今回は、より実践的な内容を試してみます。

検知したセキュリティリスクを自動で修正する仕組みを導入してみたいと思います。

そのため、もう一段階踏み込んだ対処をするべく、新たに運用ルールを設けます。

  • 意図して公開設定(パブリック)とするオブジェクトストレージのバケットには、専用のタグをつける
  • タグのついていないバケットは、自動的にプライベート設定に変更される仕組みとする
  • 例外として、タグのついたバケットは検知対象から除外する

例外をどのように認めるかが難しいですね。
色んな方法が考えられるかと思いますが、今回は1案としてこのようなことを試していきたいと思います。

 

実際に運用する際は、当社のエンジニアがお客様と一緒に例外の条件を考えていきます。ご安心ください。

検証の流れは以下の通りです。

  1. 条件となるタグの作成
  2. ディテクタ・レシピの修正
  3. レスポンダ・レシピの修正
  4. 対象となるバケット(オブジェクトストレージ)の作成
  5. 問題の検知および修正の確認

それでは検証していきましょう!

クラウド・ガードによるセキュリティ・リスクへの対処の自動化

条件となるタグの作成

詳細は割愛しますが、下記のようなタグを事前に作成しました。
今回のシナリオでは、オブジェクトストレージにて公開用のバケットを作成する際、以下のタグを付けるルールにします。

条件はタグ以外にもありますので、運用に合わせて選択ください。

  • タグ・ネームスペース:cloudguard
  • タグ・キー:visibility
  • タグ値:public

ディテクタ・レシピの修正

前回設定したターゲットを確認します。
リソースのディテクタ・レシピを編集していきます。


ディテクタ・レシピを確認すると3つのレシピが確認できます。
タイプ列を見てもらうとそれぞれ異なっていることが分かります。

前回検知した問題を確認してみます。

ディテクタ・タイプ列は構成となっていますね。
今回はOCI Configuration Detector Recipe(Oracle管理)を変更します。

レシピの中にこのようなルールが定義されています。
ルールを選択して編集します。条件グループというものが設定できるため、こちらを利用したいと思います。

先ほど作成したタグがついていないものという条件を設定します。
つまり、タグのついたものは意図的な設定であるため、検知させないというものになります。

こちらでディテクタ・レシピの修正は完了です。

レスポンダ・レシピの修正

次にレスポンダ・レシピの修正を行いたいと思います。OCI Responder Recipe(Oracle管理)を変更します。ルール・トリガーを自動的に実行にします。
こちらは対象コンパートメントにて条件グループを定義します。

これで事前の設定は完了です。

対象となるバケット(オブジェクトストレージ)の作成

それではいよいよバケットを作成します。
比較のためにタグのついたバケットとついていないバケットを作成します。public-tagのみ作成したタグを付けています。これで後は待つだけになりました。

問題の検知および修正の確認

しばらく待つとバケットの状態がパブリックからプライベートに変わりました!クラウド・ガード側も見てみます。

解決済みの一覧の中に存在していました。
問題が解決済みとなっていますね。

レスポンダアクティビティでどんなことが起こったか詳細を確認してみます。

Make Bucket Privateというのが、先ほどレスポンダ・レシピで設定したルールですね。
Automatically Triggeredというコメントがあり、実行されていることが分かります。

さて、やりたかったことが出来ているようです。

さいごに

今回はクラウド・ガードでセキュリティリスクを自動で修正する仕組みづくりを検証してみました。
ただし今回の方法でも誤ってタグを付けてしまった場合は、この仕組みが働きません

間違いを減らすことはできても確実とは言い切れないですね。

それでもリスクを減らすことにはつながるかと思います。
どのような形で設計をすべきなのか、実運用に照らして検討してみてください。

最初に紹介した通知サービスなどの連携を行うことでさらに便利にしていくことも出来そうですね。
クラウド・ガードに関する記事は今回でひと段落となります。

当社はOracleデータベースOracle Cloudサービスを多数展開しております。
何かお困りのことがありましたら、お気軽にお問い合わせください!

●第一弾「クラウド・ガードを設定してみました①~セキュリティリスクの検知~」の記事はこちら
●第二弾「クラウド・ガードを設定してみました②~セキュリティリスクへの対処方法~」の記事はこちら
あわせてご覧くださいませ!

投稿者プロフィール

技術チーム
技術チーム
DBひとりでできるもんを盛り上げるべく、技術チームが立ち上がり早6年。ひとりでできるもんと言いつつ、技術者が読んでプッとなるような、極めてピンポイントでマニアックな技術ネタを執筆しています!