Prisma CloudのCSPM導入してみた 後編:可視化したアラートからの問題調査

前回はPrisma Cloudに自分のチームが利用しているクラウドアカウントを登録し、ポリシーの有効化までを記載しました。

ポリシーの有効化だけではアラートとして上がってこないため、今回はそのポリシーに対してアラートルールを設定し、ポリシー違反アラートの対処を行います。

具体的にはポリシー違反検知を行った結果、Audit Event(※)関連の違反として表示された内容の調査と対処について記載します。

※CloudTrailに記録されたログはPrisma Cloudで取り込むとAudit Eventとして表示されます。

1. 有効化したポリシーを全てアラートとして表示
まず、図1のように有効化した全てのポリシーに対してアラートを上げるようにしておき、何か問題が無かったかを見て行きます。
図1. 全てのポリシーを適用したアラートの生成
図1. 全てのポリシーを適用したアラートの生成
2. Dashboard(SecOps)の確認
Prisma Cloudではアラートの発生をGUI上で確認する一つの手段としてDashboard(SecOps)があります。
まずはこちらで見ていくことにします。
直近で見るべき内容がどれくらいあったかを確認するために過去24時間以内のアラートを確認します。(図2)
図2. Time RangeをPast 24 Hoursにすることで過去24時間のアラートを確認
図2. Time RangeをPast 24 Hoursにすることで過去24時間のアラートを確認
件数としては205件、Highが172件もあります。
このクラウドアカウントは少人数で運用しているため、これだけ多くの違反が発生していることは想定していませんでした。
何が起きたか見ていくことにします。
まず図2の左下”Alert by Policy Type over Time”を見ると色がほぼ一色です。
Audit Eventが大量ということで何らかの攻撃を受けている可能性もあります。
何が起きているかAudit Eventが多く発生している時間帯のイベントを見てみます。
図3の18:00~21:00の棒グラフをクリックしてみましょう。
Dashboard(SecOps)の確認
図3. Alerts by Policy Type over Time で Audit Event のみを表示
3. アラートの調査
実際のイベントを確認してみるとDeleteNetworkInterfaceのイベントが大量に出ています。(図4)
図4. 大量のDeleteNetworkInterface
図4. 大量のDeleteNetworkInterface
ネットワークインターフェイス削除のAPIが連続的に実行されていることから、場合によっては外部から攻撃されている可能性もあるため、これが攻撃によるものかを調査します。まずは消している対象が何かをResource Configから確認します。
図5. Resource Configの確認
図5. Resource Configの確認
Configを見ると何が削除されているか以前にregionがus-east-2であることが分かりました。普段自身が利用していないregionであったこともあり、ここでリソースを生成していることすら全く気付いていませんでした。
実際に管理画面からregionを切り替えてECSを表示してみると知らないClusterがあり、Serviceの立ち上げに失敗し続けているように見えます。
このECSのService起動失敗に伴い、自動的にネットワークインターフェイスの削除が発生しており、ECSがServiceの起動をリトライし続けていることにより、上記の動作が発生していると思われます。
この問題が発生しているClusterの対処を行うため、誰が作ったServiceに対してこの動作が発生しているのかPrisma Cloudのログを調べてみましょう。
Investigate項に移動すると検索ボックスが表示され、そこをフォーカスすると入力可能な候補が表示されます。
図6. Investigateの検索ボックスでの自動補完
図6. Investigateの検索ボックスでの自動補完
“event from”でAudit Eventに記録されているログの詳細を検索できるので、問題の発生し始めた期間の少し前から該当のRegionでServiceを作成したユーザが誰なのかを調べてみます。
“event from”以下も入力可能な値は候補が出力されます。今回は以下のような内容で検索を行ったところ、直近でus-east2でServiceを作成したユーザを特定できました。
図7. Serviceを作成したユーザの検索
図7. Serviceを作成したユーザの検索
該当ユーザにヒアリングを行ったところ、テスト用に立ち上げていたClusterで、Serviceの起動失敗は意図されていない状態であることが分かりました。
動作が正常でないこともありますが、本来利用を想定していないRegionでのCluster作成でしたので、作成者の方にこのService を起動していた Clusterごと削除頂き、今後は適切なRegionでの利用を依頼しました。
作成者の方より削除の連絡があり、実際の削除が確認できましたので、これで一安心と言いたいところですが、あずかり知らないところでECSやインスタンスを勝手に生成されているという状況はよろしくありません。
この後、調査する期間を長くすることで、さらに前に作成したインスタンスからCISベンチマークのコンプライアンス違反が見つかり、修復プランの確認や、Assets画面から過去の問題発生状況の確認を行う等、更なる調査や対策を行っていますが、長くなってきましたのでそちらはまた別途記載しようと思います。

まとめ

Prisma Cloudにアカウント情報を登録して少しの期間を確認するだけで設定不備以前に見えていないECSの情報が見え、適切な態勢がとれていないことが分かりました。
今回のECSもそうですが、野良VMもセキュリティリスクになり得えますので、クラウド全体でのリソースの稼働状況の把握や不審な挙動を検知するためにも、Prisma Cloudを始めとするCSPMを利用してクラウドの状態を監視することが、日々クラウドを運用していく上では非常に有意であることがわかりました。

関連動画:『セキュアなアプリケーション開発の実現~Posture Managementによるセキュリティベースラインの向上~』
セキュアな業務環境を従業員に提供することは全ての業務に共通する課題です。アプリケーション開発の現場でもセキュリティ インシデントの抑制が大きな課題として認識されていますが、開発者が抱える特有の理由からセキュリティの優先順位を下げざるを得ない状況があり、その重要性が軽視されてしまうパターンが珍しくありません。本セッションでは開発環境に対してセキュリティインシデントの発生確率を低減するために必要な最低限の仕組みを実装し、セキュリティベースラインを大幅に向上させるための予防ソリューションであるPosture Managementについて解説します。

お問い合わせ・資料請求

株式会社マクニカ DevOps 担当

平日 9:00~17:00