クラウドサービスが出力するログをのぞいてみよう！

はじめに

2024年のMicrosoft Top Partner Engineer AwardのSecurityカテゴリに選出されたNRIの平田です。2023年はAzureカテゴリ、2024年はSecurityカテゴリと、Microsoft Top Partner Engineer Award には2年連続で選出いただきました。
普段はAzureを用いたデータの蓄積や分析・活用をするための基盤づくりを支援しており、データを活用するにあたって、安心安全な基盤を提供すべくセキュリティについても強く意識して活動していることが評価されたと考えています。何か特別なことをしたというより、必要なことを様々な観点で検討し、セキュリティ要素として設計・実装してきました。セキュリティ方針として実施した主な内容としては以下となります。

Azureベンチマークの活用
監査設定と通知の設計
Microsoft Defenderシリーズの積極的な活用

どれも特別なことではありませんが、積み重ねで強固なセキュリティとなるため、試行錯誤をしながら、具体的な実装を進めていきました。

前置きが長くなりましたが、本ブログでは、セキュリティ要素の一つである監査設定に関する事項について触れたいと思います。

監査設定って、なんで大事なの？

クラウドやテレワークの普及にともない、環境が多様化した結果として、従来の境界型セキュリティモデルだけではシステムのセキュリティ対策として不十分といわれる場面が増え、ゼロトラストと呼ばれる新しいセキュリティの考え方が登場しています。ゼロトラストは、システム内外のすべてのネットワークの安全性を信頼しないという前提に基づいた考え方であり、基本的に、以下のような考え方のもとに成り立っています。

すべてのデータソースとコンピューティングサービスはリソースとみなされる
すべての通信は、ネットワークの場所に関係なく、セキュリティが確保される
企業リソースへのアクセスをセッションごとに付与される
リソースへのアクセスは、クライアントID、アプリケーション/サービス、リクエストする資産の状態、その他の行動属性や環境属性を含めた動的ポリシーにより決定する
企業は、所有している資産の整合性とセキュリティ状態を監視し、測定している
全てのリソースの認証と認可は動的に行われ、アクセスが許可される前に厳密に実施される
企業は、資産やネットワークインフラストラクチャ、通信の状態に関する情報を可能な限り多く収集し、それらを利用してセキュリティ状況の改善する

（引用：NIST SP800-207 「ゼロトラスト・アーキテクチャ」）

監査設定と通知の設計は、上記の基本的な考え方のうち、5と7に該当します。セキュリティ動作に関する情報を常に監視することで、セキュリティインシデント検知の迅速化につながり、測定した情報を解析することで、より効果的な改善策に結びつけることができるようになります。このため、「監査設定と通知の設計」は非常に大事なものと考えられます。

ログの中身をのぞいてみよう！

監査設定の重要性は前段のとおりですが、どのような情報が出力されるかが分かると、どういったことに役立てるかイメージが付きやすいかと思いますので、ここからは具体例を紹介していきます。利用するクラウドサービスによって出力される項目は当然異なりますが、共通している要素もありますので参考にはなるかと思います。

ストレージアカウントの診断ログ

ストレージアカウントの診断はストレージアカウントそのものと、そこに格納するAzure Blob/Azure Queue/Azure Table/Azure Files に対して、有効化が可能です。ストレージアカウントそのものだけの診断設定の場合、Transaction情報しか取得できませんが、下位のリソースに対する設定を行うとStorageRead/StorageWrite/StorageDeleteの情報が追加で取得できるようになります。次の図は、Azure Filesの診断ログの内容です。図に表示された以外のメトリックについてはAzure Files 監視データのリファレンスを参照ください。

図に表示された項目のうち、見るポイントとしては以下のような3項目が挙げられます。

AccountName：ストレージアカウント名が出力されます
CallerIpAddress：ストレージのアクセス元IPアドレスが出力されます
ResponseBodySize：ストレージサービスによって書き込まれた応答パケットのサイズが出力されます

これらの情報から、例えば、特定のストレージアカウントに対し、特定のIPアドレスから極端に大量のデータの読み込みや書き込みが発生している場合、それを異常とみなし検知するといったことが考えられます。なお、この図には表れておりませんが、url項目によって、アクセスしたフォルダ名やファイル名まで特定が可能です。

Azure Synapse AnalyticsのSQL操作ログ

Azure Synapse AnalyticsはAzureが提供するエンタープライズSQLデータウェアハウスとビッグデータ分析サービスが統合された分析サービスです。大量のデータを構造化データとして蓄積・加工・分析可能なサービスであるため、情報流出時のインパクトも甚大なものになります。DBを扱う場合、アクセス履歴や操作履歴を取得し、監査するケースも多いと思われますが、当然、Azure Synapse Analyticsでもログの取得が可能です。

以下の図は、Synapse Analytics 専用SQLプールに対するSQL実行の要求を記録したログ(SynapseSqlPoolExecRequests)の一部です。LogycalServerNameには専用SQLプールが稼働するSynapseワークスペースの名前が出力され、Commandには項目名のとおり実行したSQLリクエストの中身（where句やfrom句も表示されます）が出力されます。今回は、KQLにて「SELECT」を実行したログのみを抽出したログですが、条件を変えることで他のログの出力も可能です。別のログにはなりますが、SQLSecurityAuditEventsでどのユーザが、どのスキーマにアクセスしたか情報取得が可能なため、誰がどういった操作を実行したのかまで、ある程度追うことが可能です。その他のメトリックについてはAzure Synapse Analytics 監視データリファレンスを参照いただければと思います。

Azure Firewallに設定した規則へのヒットに関するログ

最後に通信関連のログを紹介します。Azure Firewall（以下、FW）では診断ログを有効化することで様々な情報を取得することができます。FWではFlow Traceといった通信確立の機序の理解に役立つ情報以外に、FWに設定した各種規則へのヒット状況を記録したログが存在しています。

以下の図はFWに設定したアプリケーション規則のヒット状況を記録したログ（AZFWApplicationRule）の一部です。FqdnやTargetURLが接続先の情報、SourceIPが接続元のIPアドレスを示しています。もともとアプリケーション規則は、接続元と接続先の情報セットでアクセス許可/拒否を設定しますが、設定された規則に対し、実際のアクセスが合致したか・否かで結果がAction列に記録されます。Actionの内容によっては、ActionReasonが出力されることがあります。

この図では、「No rule matched. Proceeding with default action」の記載の通り、規則に合致しない通信が発生したため、アクセス拒否としたことが分かります。図に表示されている項目だけでも、特定の接続元IPからのActionが何度もDenyとなるような要求があった場合、悪意のある動作を実施している可能性があるため、検知の対象となり得ます。このとき、接続元IP（クライアント端末）のログイン履歴は別途取得していれば、通信の発生の時間と組み合わせることで、被疑を限定することも可能です。その他のメトリックについてはAzure Firewall 監視データリファレンスを参照ください。

いかがでしたでしょうか？複数のリソースの各種ログをのぞいてみることで、どういったことが記録できるか、どういったことの通知に利用できそうか、イメージが湧きましたでしょうか？
これら複数のリソースの複数のログの管理・分析をリソース単体毎に行うのは困難なため、AzureではLog Analyticsに情報を集約しています。また、Azure Monitorのアラート設定と組み合わせることで、特別な作り込みをすることなく、疑義のあるログ検知後の通知を行うことも可能です。実際に担当しているシステムでは通知先も検知内容ごとに細かく決めて、運用をしています。また、日々の利用状況から新規の通知の設定や既存設定の廃止なども柔軟に対応し、改善を繰り返しているところです。

おわりに

Microsoft Top Partner Engineer AwardのSecurityを受賞したことから、セキュリティに関して日々の業務で考えていることの一部を紹介しました。セキュリティに関する実装はシステム運用上切り離すことはできず、マネージドサービス利用が進むにつれて、よりゼロトラストを意識した設計は重要になっていくと考えています。方式を検討するにあたっては、上位の設計思想を理解するだけでは足りず、少しでも実サービスの挙動や出力するログの中身を知ることが重要です。あまり見る機会はないかもしれませんが、各ログなどの中身に興味を持つきっかけになれば幸いです。クラウドセキュリティ関連でお困りのことなどありましたら、お気軽にお問い合わせください。