こんにちは。k.sasakiです。
先日リリースされたクラウドガードのInstance Securityレシピについて、動かしてみましたので、情報共有させていただきます。
目次
Instance Security レシピとは
以下記事によると4つの主要な機能があります。
Instance Security now available in Oracle Cloud Guard
・ セキュリティ監視：脆弱性、オープンポートを収集し、対処ガイダンスを提供可能
・ カーネルレベルの可視性：eBPF技術により、OSレベルの異常検出が可能
・ クエリの実行：独自のセキュリティクエリを定期的または即時に実行可能
・ SIEM統合：OCI Loggingと統合し、セキュリティデータを外部ツールに送信可能
そして、機能差分のあるStandard版とEnterprise版の2種類のレシピがリリースされています。
Standard版のレシピは無償で、Enterprise版のレシピは有償です。
今回は無償で使用できるStandard版のレシピについて有効化して、スキャンと、クエリ機能の動作を確認します。
Instance Securityレシピの有効化
クラウドガードの利用方法については弊社の過去ブログを参照にしていただくとして、今回は、ドキュメントを見ながら、Instance Securityのレシピの有効化を行います。
【Oracle Cloud】Cloud Guard を有効化してOCIの問題を確認する
ポリシーの作成
まずは、Instance Securityレシピの利用に必要なポリシーを設定します。ポリシーにある"workloadprotectionagent"というのが初見ですが、インスタンスで動作する、クラウドエージェントのプラグインを指しているようです。
Allow any-user to { CG_BOM_READ } in tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent'}
Allow any-user to { CG_CONFIG_READ } in tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent'}
Allow any-user to { CG_ADHOC_QUERY_READ } in tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent'}
Allow any-user to { CG_ADHOC_RESULTS_CREATE } in tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent'}
Endorse any-user to { CG_LOG_CREATE } in any-tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent' }
Endorse any-user to { CG_METRICS_CREATE } in any-tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent' }
Endorse any-user to { CG_ADHOC_QUERY_READ } in any-tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent' }
Endorse any-user to { CG_ADHOC_RESULTS_CREATE } in any-tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent' }
レシピのアタッチ
ディテクタレシピにStandard版とEnterprise版のレシピが追加されています。今回はStandard版をクローンし、これを検証用のコンパートメントを割り当てたターゲットに追加を行いました。
レシピの詳細設定
Standard版のレシピの検出項目については以下2つです。それぞれ、より問題が検出しやすいように設定変更を行います。
Scanned host has vulnerabilities
指定されたCVEの重大度の脆弱性が検出された場合、問題として検出する項目です。
問題として検出する閾値をHIGHからNONEへ下げて問題の検出数を上げる設定をします。
CVE Severity Level :HIGH -> NONE
Scan Schedules : Daily (変更なし)
以下は設定変更後の状態です。
Processes listening on open ports
ネットワーク接続をリッスンしているプロセスを検出する項目です。
TCP22やUDPのポートについて検出されない設定となっているため、検出するように設定します。
Allowd ports : TCP:[22], UDP:[] -> (削除)
Scan Schedules : Daily (変更なし)
以下は設定変更後の状態です。
インスタンスのデプロイ
今回は、Oracle Linux8イメージを使用し、クラウドガードのターゲットとして設定されたコンパートメントに検証用インスタンス"cg-inssec"を作成しました。
ドキュメントの前提条件に記述はないですが、クラウドエージェントの"Cloud Guard Workload Protection"のプラグインを使用するため、デプロイ時、またはデプロイ後に有効化が必要です。
本プラグインに対応したログファイルやディレクトリは以下の通りです。
/var/log/oracle-cloud-agent/plugins/oci-wlp/oci-wlp.log
/usr/lib/systemd/system/wlp-agent-osqueryd.service
/opt/wlp-agent/*
検出数を増やすため、さらに、Webサーバ（httpd)をセットアップし、特に設定を変更せずデフォルトで起動しておきます。
OS側のfirewalldの停止も忘れずに実施しておきます。
yum install httpd
systemctl enable httpd
systemctl start httpd
systemctl disable firewalld
systemctl stop firewalld
httpdも起動した際のポートの状態は以下の通りです。
[root@cg-inssec opc]# ss -nat | grep LISTEN
LISTEN 0 128 0.0.0.0:22 0.0.0.0:
LISTEN 0 128 0.0.0.0:111 0.0.0.0:
LISTEN 0 5 127.0.0.1:44321 0.0.0.0:
LISTEN 0 5 127.0.0.1:4330 0.0.0.0:
LISTEN 0 128 [::]:22 [::]:
LISTEN 0 511 :80 :
LISTEN 0 128 [::]:111 [::]:
LISTEN 0 5 [::1]:4330 [::]:
LISTEN 0 5 [::1]:44321 [::]:
動作確認 : Instance Securityレシピ スキャンによる問題の検出
スキャンを行うタイミングがDailyということで、いつ実行されるか不明のため、数日間インスタンスを稼働させてスキャン結果の確認を行いました。結果については、"クラウド・ガード＞リソース" より確認できます。
問題/脆弱性/オープンポートと、3つメニューがありますのでそれぞれ見ていきます。
検出結果 : 問題
1件検出されました。といっても、クラウド・ガードが管理するレコード上で1件という扱いなだけで、この1件のレコードに対して検出されtあ脆弱性がレベルごとに羅列されるという形です。
もともとOCIに"脆弱性スキャン"サービスでは、CVE番号に対してリンクがつけられてCVEの詳細を確認できましたが、そういったものはなく、検出されたCVEが羅列されるのみです。
検出結果 : 脆弱性
0件検出です。ここに検出されたCVEが並んで表示されて欲しい気がしますが、現時点ではそんなことはないようです。今後表示されていくのかしら？？
検出結果 : オープンポート
0件検出です。ポートスキャンが実施されていれば、少なくとも22と80番ポートは検出されるはずですので、動作しなかったようです。
動作確認 : Instence Securityレシピ クエリの実行
クエリについてはオープンソースのOSQueryを実行し、SQLiteで認識されるクエリがサポートされています。いくつかサンプルがドキュメントに記載されています。
メニュー : 問合せの実行
クエリを手動実行する際に使用するメニューです。
今回はOCIドキュメントに例として記載のあった、メモリ使用率の高いプロセスTOP10のクエリについてTOP 30まで表示するように変更して実行してみます。
クエリの実行ボタンを押して、1分ほど待つと結果が出力されます。
SELECT文を実行して結果出力のインターフェースが5行単位は辛いです。エクスポート機能がほしい。
メニュー : 過去の問合せ
過去に実行したクエリの履歴が確認でき、その際の出力や、同じクエリの再実行ができます。
結果画面です。こちらも5行単位です（涙）。
メニュー : お気に入りの問合せ
クエリをお気に入りとして登録して、問い合わせ実行の際に呼び出すことができます。
メニュー : スケジュール済み問合せ
こちらはEnterprise版のレシピでしか使用できない項目となります。スケジュールされたクエリについて定期的に実行し、OCI Loggingに結果を出力させる構成です。欲を言えば、こっちも1日数本でいいから、Standard版でも使用できるようにして欲しかったですね。
動作確認できなかった機能
いくつか動作確認できなかった機能があったので、結果としてまとめておきます。
ポートスキャン
レシピ自体は割り当てていて、同じレシピ上の "Scanned host has vulnerabilities"による検出は動作してるので、これだけ動作を確認できない理由は不明です。動作確認を断念。
OCI Logging連携
クラウドガードのターゲットにレシピを割り当てる際に、OCI Loggingとの連携を設定できたのですが、スキャンやクエリが実行された後でも、Logging側への出力は得られず。動作確認を断念。
おわりに
以上、先日追加された、Instance SecurityレシピのStandard版について触れてみました。
無償で使用できるレシピがあるのはありがたいですね。
注意点としては、スキャンが実行される時間が不明なので、動作確認のためには数日かかることと、クエリの利用上限です。詳細はドキュメントに記載がありますが、Standard版の場合は、月30件まで/リージョン単位のクエリ上限があります。
Enterpsire版ではクエリ件数の制限はなくなりますので、時間をかけてきっちり検証するならEnterprise版のレシピの利用をお勧めします。（なお、スケジュールクエリについてはEnterprise版でも1日の回数/容量に制限があります。）
また、本機能に対応したクラウドエージェントの"Cloud Guard Workload Protection" プラグインがインスタンスデプロイ時にデフォルト有効であるため、使用しないのであれば、手動で無効化する必要があります。
以上、最後までご覧いただきありがとうございました。