皆さん、こんにちは。クラウドエンジニアの北川です。
早速ですが、皆さんは「DevSecOps」という概念をご存知でしょうか。
DevSecOps とは、システム計画から設計、開発 ～ 運用に至るまでのあらゆる工程にセキュリティ対応を取り入れることで、システムのセキュリティを向上させるという概念・方法論になります。
※ 詳しくは、弊社湯下の投稿記事 (いま注目されている DevSecOps とは - vol.1) をご参照ください。
DevSecOps の考え方に則ったプロジェクトにおいて、運用・監視フェーズで特に重要なことは、システムのセキュリティチェックを継続的に行い、即座に問題を検知・対処・分析する体制作りです。
本ブログでは、それを実現するプロダクトの 1 つである、Palo Alto Networks 社の「Prisma Cloud」をご紹介していきたいと思います。
また、本ブログでは Prisma Cloud を実際に触った様子をご紹介します。
意外とシンプルかつ簡単にセキュリティチェックができるというところを掴んでいただけると嬉しいです。
Prisma Cloud とは、マルチクラウド環境 (Azure、AWS、GCP) において、横断的にセキュリティ脅威を検出／可視化し、コンプライアンス準拠をサポートする SaaS 型の製品です。
Prisma Cloud は主に以下のセキュリティ脅威の検出・可視化を行います。
Prisma Cloud には、監視する対象に応じて、以下の 2 つの機能を有しています。
| No. | 機能 | 概要 |
|---|---|---|
| 1. | CSPM (Cloud Security Posture Management) | AWS、Azure などのクラウド リソース設定の脆弱性について分析、監視 |
| 2. | CWPP (Cloud Workload Protection Platform) | VM、OS、コンテナ等にエージェントをインストールしてワークロードを分析、監視 |
それぞれのイメージ図は以下の通りです。
左側の各種クラウドリソースから API によってセキュリティ情報を抽出するのが CSPM 、右側の各種プラットフォームからエージェント経由でセキュリティ情報を送信するのが CWPP となります。
クラウド リソース単位だけではなく、VM、OS、コンテナ単位でのセキュリティチェックも行うことで、総合的にクラウド環境のセキュリティ対策を行うことができます。
次の章からは、具体的に Prisma Cloud でセキュリティチェックを行うまでの流れを説明していきます。
「Microsoft 365 導入・運用支援サービス」はこちらこの章では AWS 環境と Azure 環境を Prisma Cloud に接続して、リソース情報を抽出するところまで確認していきます。
と言っても、Palo Alto 社から提供されている管理者ガイドに沿って進めていけば問題ありません。特につまずくところも無しです。
ここではステップ毎にかいつまんで説明していきます。
なお、検証には Prisma Cloud の Free Trial 版を使用しています。ここからメールで問い合わせることで検証用のアカウント作成を行ってもらえます。
製品およびサービスに関するお問い合わせ手順を箇条書きすると、以下の通りとなります。
VPC フローログとは、VPC のネットワーク インターフェイスで送受信される IP トラフィックに関する情報をキャプチャしたログです。 Prisma Cloud は、この VPC フローログからセキュリティ検査に必要な情報を取得します。
VPC フローログの保存先として CloudWatch ロググループを作成します。
※ この作業は AWS 管理コンソール上で行います。
■ CloudWatch ロググループ作成中の画面キャプチャ
続いて、VPC フローログも作成します。
■ VPC フローログ作成後の画面キャプチャ
次に、Prisma Cloud に AWS クラウドアカウントを追加します。
Prisma Cloud の Free Trial 版を開始した直後の Prisma Cloud コンソールは、このような画面になっています。
左下の名前 [Takuto Kitagawa] から、表示言語を日本語に変更できます。
AWS クラウドアカウントを追加するには、[設定] - [クラウドアカウント] - [追加] をクリックします。
画面遷移を続けていくと、外部 ID の情報が表示されます。
AWS 管理コンソールより、スタック作成を行います。External ID に Prisma Cloud で確認した外部 ID を入力し、[スタックの作成] をクリックします。
作成したスタックの出力タブから [ロールAPN] を確認し、Prisma Cloud 側の画面に入力して [次へ] をクリックします。
アカウントグループとは、AWS や Azure のテナントをグループ単位で整理できる管理単位となります。 今回は検証用なのでデフォルトで用意されている [Default Account Group] を選択します。
AWS テナントでインスペクタや Guard Duty を実装していなければ、以下のような画面結果となります。
これで AWS テナントのリソース情報やセキュリティ脆弱性情報が、Prisma Cloud コンソール上で確認できるようになります。
ただし、即時反映はされません。30 分程度すると、徐々に Prisma Cloud コンソール上にアラート情報が出てくるようになります。 どうしてもタイムラグが出てきてしまうため、お客様環境で実施する場合は、Prisma Cloud にクラウドアカウントを追加して、翌日にアラートを確認する、といったスケジュール感が良いと思います。
以下が、30 分ほど経過した Prisma Cloud コンソールの SecOps ダッシュボードとなります。
同様に Prisma Cloud と Azure も接続してみましょう。AWS と全く同じというわけにはいかないため、手順も少々異なります。
手順を箇条書きすると以下の通りとなります。
まずは AWS と同様に、クラウドアカウントの追加をクリックします。
少し画面遷移すると、Azure のテナント ID とサブスクリプション ID を入力する画面になります。
テナント ID とサブスクリプション ID は、それぞれ Azure Portal の以下から確認することができます。
■ [Azure Active Directory] - [概要] - [テナント ID]
■ [サブスクリプション] - [概要] - [サブスクリプション ID]
ID を入力し、[次へ] をクリックします。
次の画面では、以下のような流れになります。
[Terraform テンプレートをダウンロード]
↓
[Azure 上で Terraform テンプレートを実行]
※ 所有者ロールが付与されたアカウントで実行する必要があります。
↓
[出力されたアプリケーション ID、アプリケーションキーを入力]
Cloud Shell 上で Terraform テンプレートを実行した出力結果は、以下の通りです。
それぞれの値は、以下に対応します。
上記の情報を Prisma Cloud コンソール画面上に入力し、[次へ] をクリックします。
アカウントグループ、および Status の画面は AWS と同等のため、ここでは割愛します。
Azure クラウドアカウントの追加も完了すると、30 分程度で徐々に Azure のリソース情報も出てきます。
※ 分類別アセットのグラフのラベルが日本語訳されてしまっていますが、空色 = Azure です。
※ こんな感じで AWS と Azure のアラートが 1 つのポータルで一元管理できるのがマルチクラウド対応製品の良いところですね。
「Microsoft 365 導入・運用支援サービス」はこちら1 章の内容を実施し、時間を置いてしばらく経つと、自然とセキュリティ アラートが出力されているはずです。
セキュリティ アラートは、Prisma Cloud コンソールの左ペインで [アラート] - [概要] で確認できます。
※修復可能の [真] にチェックを入れることで、Prisma Cloud 側で自動修復できるアラートを表示させることができます。
今回は上から 2 番目の [Azure Storage Account default network access is set to ‘Allow’] アラートの詳細を見てみましょう。
これは、Azure ストレージ アカウントの接続元を [すべてのネットワーク] に設定していると発生するアラートです。インターネットからの接続を意図せず許可してしまっている、ということも考えられるので、これは重要なアラートとなります。
Azure 管理ポータル上だとこのような状態ですね。
Prisma Cloud コンソールに戻り、[Azure Storage Account default network access is set to ‘Allow’] と書かれている箇所をクリックすると、以下のようにアラートの概要が出てきます。
また、アラートが発生しているリソース名も出てきていますね。これで、セキュリティ的に問題があるリソースが一目で分かるようになるというわけです。
さらに、推奨事項には丁寧に各クラウドコンソール上でのアラート解決方法まで記載されています。
ただ、この推奨事項を見たところで、結局 Azure なら Azure の管理ポータルにわざわざ入らないといけないのか、、と思いますよね。
Prisma Cloud ではそんなことが必要なく、Prisma Cloud 上でポチポチしていくだけでこれらのアラートを解決できるような機能があります。それが「自動修復」です。次の章で説明していきます。
「Microsoft 365 導入・運用支援サービス」はこちらどのように自動修復するかというと、先程の画面で各アラートの項目の [修正] をクリックすれば OK です。
そうすると、下記のポップアップ画面が表示されるので、[コマンドを実行する] をクリックします。
見ていただくと分かる通り、対処方法が Azure CLI コマンドで記載されています。自動修復はセキュリティ アラートの解決策をコマンドとして提示できる場合、Prisma Cloud からキックして各クラウドのリソースに対してコマンドを実行するものと言えます。逆に言えば、コマンドで解決できないアラートやどうしても人が対処法を判断しないといけないアラートについては自動修復することができない、ということになるかと思います。
自動修復が成功すると「成功」と表示されます。
Azure 管理ポータル上はどうなっているかというと、しっかり修正後の状態になっていました。
これでセキュリティ アラートについて 1 つ解決することができましたね。
3 章と 4 章では、Azure のストレージ アカウントのアラートを例として確認していきましたが、もちろん AWS でも同等のアラート確認やアラート解決が可能となります。
「Microsoft 365 導入・運用支援サービス」はこちら今回のブログでは Prisma Cloud で各クラウドとの接続を行い、セキュリティ アラートの 1 つを解決するまでの流れをご紹介しました。
もちろん実運用でこんなことをやっていては、日が暮れてしまいます。そのため、次回以降は、複数のアラートを人の手を介さずに一気に自動修正してしまう方法をご紹介します。
また、CIS Benchmark などの特定のガバナンスに沿ったアラート発報、E-mail や Amazon SQS への通知方法などについても、ご紹介します。
今後のブログ内容として、以下を予定しています。
DevSecOps という言葉を聞くと何だか抽象的で導入が難しそうだなと思われるかもしれませんが、このように具体的な製品の動きを紐解いていくと、実際のシステムや実施作業がイメージしやすくなるのかなと思います。
今回と今後の DevSecOps のブログを参考に、システム開発時でもシステム運用時でも常にセキュリティを意識してプロジェクトを円滑に進めていただけると幸いです。
Have a good DevSecOps life !!!!
関連ページ |
