Cloud Audit Logging 活用のベスト プラクティス
Google Cloud Japan Team
監査人の皆さんにとって、ログの精査はおそらくかなりの時間を要する作業でしょう。Google Stackdriver スイートに含まれる Google Cloud Audit Logging の仕組みを理解し、その使い方をマスターすることは、Google Cloud Platform（GCP）上にデプロイされたサービスを監査するにあたって、ぜひとも身につけておきたいスキルです。
Cloud Audit Logging についてまず知っておくべきことは、プロジェクトごとに管理アクティビティとデータ アクセスの 2 つのログ ストリームがあることです。GCP サービスはこれらのログにエントリを作成し、「いつ、どこで、誰が何をしたか」という問いの答えを探しやすくします。さらに、これらのログはアプリケーションのログとは区別されます。
管理アクティビティ ログは、リソースの構成またはメタデータを変更する API 呼び出しやその他の管理操作のログ エントリを含み、常に有効になっています。管理アクティビティの監査ログは無料で使用でき、13 か月または 400 日にわたって保存されます。
それに対してデータ アクセス ログは、ユーザー提供データの作成、変更、もしくは読み込みのための API 呼び出しを記録します。このログはあっという間に膨大な量に膨れ上がるため、デフォルトでは無効になっています。
参考までに、監査ログを生成する GCP サービスの一覧はこちらにあります。
監査ログの設定と表示
Cloud Audit Logging は簡単に始められます。一部のサービスはデフォルトでオンになっており、その他も数回クリックするだけでオンになります。ここでは、Cloud Audit Logging のさまざまな機能について、そのセットアップや設定、使い方を説明しましょう。
監査ログ コレクションの設定
管理アクティビティ監査ログはデフォルトで有効になっているので、何もしなくてもログは収集されます。しかし、データ アクセス監査ログは、BigQuery ログを除いてデフォルトで無効になっており、有効にするためにはデータ アクセス ログの設定ページの説明に従う必要があります。
データ アクセス ログについては、テスト プロジェクトを使ってデータ アクセス監査コレクションの設定をチェックしてから、開発および本番プロジェクトにその設定を移すというベスト プラクティスに従いましょう。IAM 制御の設定を誤ると、プロジェクトはアクセス不能になる恐れがあります。
監査ログの表示
GCP Console には監査ログを表示できる場所が 2 つあります。アクティビティ フィードにはサマリー情報、Stackdriver ログ ビューアのページにはエントリ全体が表示されます。
権限
監査ログ データには機密情報として適切なアクセス制御を設定する必要があります。ログに対するアクセスの制御は IAM の役割で設定できます。
ログを表示するには、管理アクティビティ ログ用の logging.viewer（ログ閲覧者）や、データ アクセス ログ用の logging.privateLogViewer（プライベート ログ閲覧者）の役割が必要です。
Cloud Audit Logging 関連の役割の設定では、こちらのハウツー ガイドが役に立ちます。このガイドは、典型的なシナリオをいくつか示し、監査ログへのアクセス制御の必要性と、それを満たす IAM ポリシーの設定方法について説明しています。ここでのベスト プラクティスは、適切な IAM 制御により、監査ログにアクセスできる人を絞り込むことです。
アクティビティ フィードの見方
Cloud Console のアクティビティ ページでは監査ログの概要を俯瞰的に見ることができます。任意のエントリをクリックすると、次に示すように、そのイベントの詳細が表示されます。
デフォルトではデータ アクセス ログは表示されません。表示されるようにするには、“Filter” 設定パネルに移動し、“Categories” の下の “データ アクセス” フィールドを選択します（データ アクセス ログの表示には IAM のプライベート ログ閲覧者の役割も必要なので注意してください）。
Stackdriver ログ ビューアによる監査ログの表示
Stackdriver ログ ビューアを使用すると、監査ログ エントリの詳細を表示できます。ログ ビューアでは、リソース タイプとログ名（管理アクティビティ ログは “activity”、データ アクセス ログは “data_access”）からログを選択できるほか、フィルタリングや自由テキスト検索も行えます。
以下の例では、一部のログ エントリを JSON 形式で表示するとともに、重要なフィールドを強調表示しています。
監査ログのフィルタリング
Stackdriver は 2 種類（基本と高度）のログ フィルタを提供しています。このうち基本ログ フィルタは、ユーザー、リソース タイプ、日時に基づいて表示内容をフィルタリングします。
それに対して高度なログ フィルタは、プロジェクト内のすべてのログ エントリのサブセットを定義する論理式です。次のような選び方が可能です。
- 特定のログもしくはログ サービスのログ エントリ
- 指定時間内のログ エントリ
- 指定した条件を満たすメタデータやユーザー定義フィールドを持つログ エントリ
- サンプリング率で絞り込まれたログ エントリ
以下に示すフィルタは、すべての Cloud IAM API 呼び出しの中から、SetIamPolicy メソッドを呼び出すものを選び出します。
次に示すのは、bigquery.dataViewer の役割を Alice に付与する SetIamPolicy 呼び出しの内容を示すログ エントリの一部です。
ログのエクスポート
ログ エントリが Stackdriver Logging に保存されるのは保持期間中だけで、それを過ぎるとエントリは削除されます。それ以降もログ エントリを残しておきたい場合は、ログ シンクを設定して Stackdriver Logging の外部にエクスポートする必要があります。
シンクは、エクスポート先、エクスポート対象のログ エントリを選択するためのフィルタなどからなる次のプロパティで構成されます。
- シンク識別子 : シンクの名前です。
- 親リソース : このリソースの中にシンクを作成します。プロジェクト、フォルダ、請求先アカウント、組織のいずれかを指定できます。
- ログ フィルタ : このシンクでエクスポートするログ エントリを選択します。すべてのログをエクスポートするか、特定のログだけをエクスポートするかを柔軟に選べます。
- エクスポート先 : フィルタにマッチするログ エントリの送り先となる単一の場所です。Stackdriver Logging は、Google Cloud Storage バケット、BigQuery データセット、Cloud Pub/Sub トピックの 3 種類のエクスポート先をサポートします。
- ライター ID : エクスポート先への書き込み権限を与えられたサービス アカウントを指定します。
ログをエクスポートするためにはログ シンクを設定する必要があります。シンクの作成以前に生成されたログを遡及的にエクスポートすることはできません。
ログのエクスポートには集約エクスポートという機能もあります。これを使えば、Cloud IAM の組織リソースやフォルダ リソースのレベルでシンクを用意し、その組織やフォルダに属するすべてのプロジェクトからログをエクスポートできます。たとえば、次の gcloud コマンドは、組織全体のすべての管理アクティビティ ログを 1 つの BigQuery シンクにエクスポートします。
集約エクスポート シンクの場合、大量のログ エントリがエクスポートされることがあるので注意してください。保存が必要なデータのために集約エクスポート シンクを設計するときは、以下のベスト プラクティスを頭に入れておくことをお勧めします。
- 保持期間よりも長い間必要なログだけをエクスポートする。
- エクスポート先には適切な IAM 制御を設定する。
- 分析に役立つデータをフィルタリングしてエクスポートするように集約エクスポートを設計する。
- ログ シンクの設定はログの収集前に行う。
- 一般的なログ エクスポート シナリオのベスト プラクティスに従う。
除外の管理
Stackdriver Logging には、特定のサービスのログ メッセージや、特定のクエリに合致するログ メッセージをログの対象から外す除外フィルタという機能があります。特定のメッセージをサンプリングし、メッセージ全体の一定割合だけを Stackdriver ログ ビューアに表示することも可能です。除外されたログ エントリは、プロジェクトにおける Stackdriver Logging のログ上限にはカウントされません。
除外される前にログ エントリをエクスポートすることもできます。詳細はログのエクスポートの概要を参照してください。ログに含まれるノイズの部分を除外すれば、ログが見やすくなるだけでなく、月々の上限を超えるログへの課金を最小限に抑えることにも役立ちます。
ベスト プラクティス :
- 役に立たないログ データを対象から外すため、必ず除外フィルタを適用しましょう。たとえば、開発プロジェクトにデータ アクセス ログを残さないようにします。データ アクセス ログの保存は課金サービスなので（ログ上限と超過料金を参照してください）、無駄なデータを残すと余分な出費が発生します。
ベスト プラクティスのまとめ
Cloud Audit Logging は、GCP 環境の管理や問題解決、コンプライアンスの実証に役立つ強力なツールです。ロギング環境のセットアップを開始するときに留意すべきベスト プラクティスを以下にまとめます。
- データ アクセス監査コレクションの設定をテスト プロジェクトで検証してから、開発や本番プロジェクトでその設定を適用する。
- 適切な IAM の役割を適用することで、監査ログにアクセスできるメンバーを制限する。
- 長期保存が必要なログだけをエクスポートする。
- エクスポート シンク先には適切な IAM を設定する。
- 将来の分析に役立つデータをフィルタリングしてエクスポートするように集約エクスポートを設計する。
- ログの収集前にログシンクを設定する。
- 一般的なログ エクスポート シナリオのベスト プラクティスに従う。
- 役に立たないログ データを除外するため、必ず除外フィルタを適用する。
Cloud Audit Logging をセットアップする際に、これらのベスト プラクティスがお役に立つことを願っています。独自のベスト プラクティスをお持ちの方は、ぜひコメントしてください。
* この投稿は米国時間 3 月 15 日、Cloud Solutions Architect の Grace Mollison と、Product Manager の Mary Koes によって投稿されたもの（投稿はこちら）の抄訳です。
- By Grace Mollison, Cloud Solutions Architect, and Mary Koes, Product Manager
