DBSC初冬セミナーで「クラウドフォレンジックを効率的に行うアーキテクチャ」というタイトルで登壇しました

DBSC初冬セミナーで登壇した内容です。 www.db-security.org

こんにちは、クラウドセキュリティアーキテクトの大島悠司です。
クラウドフォレンジックは、従来のオンプレミスに対するフォレンジックとアプローチが異なります。オンプレミスからクラウドの移行が加速している現在、クラウド環境におけるフォレンジックのためにどのような備えが必要なのかをご紹介します。

クラウドフォレンジックの課題
クラウドの責任共有モデル
クラウドログの特性
ログ収集と調査を考慮したアーキテクチャ
まとめ

クラウドフォレンジックの課題

クラウドとオンプレミスは様々な違いがあり、フォレンジック調査の進め方に影響します。
以下に相違点を挙げます。

クラウドにおいては、その柔軟性やログの短期保存といった性質により、フォレンジックが困難になる傾向があります。
そのため、クラウドの特性をよく理解して、適切な設計をしておくことが重要になります。

クラウドの責任共有モデル

以下が、代表的なXaaSにおける責任範囲であり、クラウドのサービス形態によって責任範囲が異なります。

クラウドは様々な責任を負ってくれると思われがちです。
しかしながら、いずれの形態もユーザの責任がゼロになることはありません。
例えば、AWSの責任共有モデル資料が以下にありますので、ご一読いただければと思います。

aws.amazon.com

クラウド側で様々なセキュリティ機能を用意してくれていますが、あくまでそれをどのように使うかはユーザに委ねられています。

次に、ワークロード全体で考えてみましょう。
例えば、以下のような簡単なWebサービスをAWS上に構築したとします。
通常、ワークロードはIaaSやPaaSなど様々な要素から構成されているので、全体を俯瞰してみた場合に前述のように責任境界をきれいに線引きすることは出来ません。
ここで大事なのは、各サービスの機能を理解したうえで、ユーザが責任をもってセキュリティ対策をしなければならないということです。

クラウドログの特性

クラウドでは様々なログを取得できますが、前述のクラウドサービス提供形態によってログ量や取得条件が異なってきます。

一般的にSaaSでは、アプリ側で用意されたログが限定的な傾向があります。
利用者は必要なログが取得されており、それをいつでも利用可能ということを契約前にしっかり確認する必要があります。

一方、IaaSはOSのパフォーマンス情報など、様々なログを取得できます。
しかしながら、エージェントのインストールが必要であったり、ログ取得の方法に制約があるので、事前に確認しておく必要があります。

クラウドログの例を見てみましょう。
下に示す例はいずれもJSON形式ですが、このように構造化されたデータであることが多いです。
さらに、同じ意味のログでも、クラウドプラットフォームやサービス機能によってフォーマットが異なります。

Azure AD（サインインログ）

[
    {
        “id”: “9aaedfa6-7d22（省略）",
        "createdDateTime": "2022-11-26T07:46:00Z",
        “userDisplayName”: “ユーザゼロイチ",
        "userPrincipalName": “user01@sample.com",
        "userId": "75577223-289b （省略） ",
        "appId": "c44b4083-3bb0 （省略） ",
        "appDisplayName": "Azure Portal",
        "ipAddress": " 52.93. （省略） ",
        "ipAddressFromResourceProvider": null,
        "clientAppUsed": "Browser",
        "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:107.0) Gecko/ （省略） ",
        "correlationId": "1e8ba1b0-102f （省略） ",
    ~（省略）~
"status": {
            "errorCode": 0,
            "failureReason": "Other.",
            "additionalDetails": null
        },
    ~（省略）~
]

Amazon CloudTrailログ（コンソールログイン）

{
    "eventVersion": "1.08",
    "userIdentity": {
        "type": "IAMUser",
        "principalId": "AIDA（省略）",
        "arn": "arn:aws:iam::（省略）:user/user01",
        "accountId": "（省略）",
        "userName": "user01"
    },
    "eventTime": "2022-11-26T07:45:28Z",
    "eventSource": "signin.amazonaws.com",
    "eventName": "ConsoleLogin",
    "awsRegion": "ap-northeast-1",
    "sourceIPAddress": "52.93. （省略） ",
    "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:107.0) Gecko/（省略）",
    "requestParameters": null,
    "responseElements": {
        "ConsoleLogin": "Success"
    },
    ~（省略）~
}

このようなクラウドログの特性が分析を難しくする要因の一つです。
各サービス単独でログを閲覧する分には、それなりの機能がそろっているので問題ないかもしれません。
しかしながら、性質の異なるログを統合したい場合は、調査に必要なログを集約/加工し、可視化できる仕組みを別途構築する必要が出てきます。

ログ収集と調査を考慮したアーキテクチャ

AWSの例

AWS CloudTrailは、誰が、いつ、何に対して、何をしたかを全て記録してくれるサービスです。
ほぼ5分以内にログを確認することができます。
ただし、ログの保存期間は90日で調査には心もとないので、他サービスに転送することで、長期保存や後追い調査をできるようにしておきましょう。

AWS Configは、何に対して、いつ、何がされたかを全て記録してくれるサービスです。
AWS CloudTrailログとの相関分析で、誰が実施したかも調査でき、さらに、リソースのコンプライアンスチェックも可能です。
ログ保持期間はデフォルトで7年間と長めですが、長期保存の観点でストレージサービスに転送しておくとよいでしょう。

AWSでは、多くのセキュリティサービスはSecurity Hubに集約することが可能です。
検知の一元管理やスコアの確認が可能で、マルチアカウント管理の場合は、全アカウントの検知情報を集約することもできます。

AWSではアカウントを役割ごとに分離することをお勧めします。
そのうえで、前述のセキュリティサービスを有効化し、特定のアカウントで一元管理できるようにするとよいでしょう。

以下のブログで、マルチアカウントとIAMの設計のコツについて解説しているので、こちらもご参照ください。

devblog.nuligen.com

Azureの例

Azureは以下のように様々なレイヤーからログを取得することができます。
それぞれのログの違いを理解したうえで、設計を行う必要があります。

例えば、Azure ADログにはサインインログや監査ログがありますが、こちらは反映に5分程度かかります。
特に気を付けたいのは保持期間が30日しかなく、調査するには心もとない期間です。

また、Identity Protectionという機能もあり、これは不審なログインなどを検知してくれます。
このログは反映に最大8時間かかり、保持期間も90日しかありません。

いずれのログも他サービスへ転送することをお勧めします。

例えば、以下のような構成が良いでしょう。
Azure ADとAzureのログを、分析用のLog Analyticsと保存用のBlob Storageに転送します。
分析に加え、脅威検出やオーケストレーション機能を使いたければ、Azure Sentinelを使う選択肢もあります。

GCPの例

GCPにはCloud Loggingというロギングサービスがあり、以下の種類のログを扱うことができます。
特に注意が必要なのはセキュリティログで、対象のログによってデフォルト設定や保存先が異なります。

以下が、Cloud Loggingのアーキテクチャです。
ログデータはCloud Logging APIを介して、各シンク設定によって対象のバケットに転送されます。
前述のセキュリティログには複数の種類がありましたが、それぞれどのシンクを通り、どのバケットに何日保存されるかを把握しておく必要があります。
ユーザ定義シンクによって、ストレージサービスやBigQueryのような分析サービスにも転送することができます。

例えば、以下のような構成が良いでしょう。
ログデータをCloud LoggingからPub/Subトピックに送信し、Dataflowで前処理します。
前処理されたデータをBigQueryで調査します。
長期保存用にCloud Storageにも保存しておくと安心でしょう。
また、複数のプロジェクトのログを集約シンクで、1つのプロジェクトに集約することもできますので、併せて検討するとよいでしょう。