ロギングデータのエクスポートのシナリオ: セキュリティとアクセス分析

このシナリオでは、組織のクラウドインフラストラクチャ環境のセキュリティと分析の要件を満たすために、Cloud Logging から BigQuery にログをエクスポートする方法を示します。多くの場合、組織では分析ツールを使用して、未承認の構成変更やデータへの不適切なアクセスを特定します。Cloud Logging は、セキュリティと分析の要件を満たすために、管理者アクティビティログとデータアクセスログの 2 種類の監査ログをキャプチャできます。

このシナリオでは、エクスポートの一環として、エクスポートしたログが構成された BigQuery のデータセットに配信されます。必要に応じて、ログへのアクセスを制限する権限を付与します。エクスポートされたデータを日付パーティション分割テーブルに整理することで、データの管理と照会が簡単になります。この手法により、クエリの一部としてスキャンされるデータ量を減らして、クエリのコストを削減できます。パーティショニングの利点の 1 つは、パーティションの有効期限を設定することで、役立つと思われる期間、ロギングデータを維持できることです。たとえば、監査ロギングデータを 3 年間保持し、その後削除できます。

このシナリオは、Cloud Logging のエクスポートのための設計パターンの一部です。

ロギングのエクスポートを設定する

次の図は、BigQuery へのロギングのエクスポートを有効にする手順を示しています。

BigQuery でロギングエクスポートデータセットを設定します。
すべての Google Cloud サービスの監査ログを有効にします。
ログエクスポートを構成する
BigQuery データセットの IAM ポリシー権限を設定する

BigQuery へのログエクスポートの有効化

BigQuery でデータセットを設定する

エクスポートしたログをホストするデータセットを設定するための手順を行います。集約ログを使用する場合、組織内のいずれかの Google Cloud プロジェクトに BigQuery データセットを配置する必要があります。単一のプロジェクトにログエクスポートを使用している場合、BigQuery データセットは同じプロジェクト内にある必要があります。

ベストプラクティス: テーブルを作成するときにパーティションの有効期限を設定して、ロギングのエクスポートに使用するストレージのサイズと、時間の経過に伴うストレージの累積コストを抑制します。

すべてのサービスで監査ロギングを有効にする

データアクセス監査ログは、BigQuery を除き、デフォルトで無効になっています。すべての監査ログを有効にするには、IAM ポリシーを更新する手順に沿って、監査ポリシーのドキュメントに記載されている構成を指定します。手順は次のとおりです。

現在の IAM ポリシーをファイルとしてダウンロードします。
監査ログポリシーの JSON または YAML オブジェクトを現在のポリシーファイルに追加します。
更新されたポリシーファイルでプロジェクトを更新します。

すべてのサービスに対してすべての監査ログを有効にする JSON オブジェクトの例を次に示します。

"auditConfigs": [
    {
        "service": "allServices",
        "auditLogConfigs": [
            { "logType": "ADMIN_READ" },
            { "logType": "DATA_READ"  },
            { "logType": "DATA_WRITE" },
        ]
    },
]

ログエクスポートを構成する

集約エクスポートまたはログエクスポートを設定したら、監査ログをエクスポートするためにロギングフィルタを絞り込む必要があります。次のロギングフィルタには、管理アクティビティ監査ログとデータアクセス監査ログに加えて、特定の種類のリソースのログも含まれます。

logName:"/logs/cloudaudit.googleapis.com" OR
resource.type:gce OR
resource.type=gcs_bucket OR
resource.type=cloudsql_database OR
resource.type=bigquery_resource

gcloud コマンドラインツールから、gcloud logging sinks create コマンドまたは organizations.sinks.create API 呼び出しを使用し、適切なフィルタを持つシンクを作成します。次の gcloud コマンドの例では、この組織に対して gcp_logging_sink_gcs という名前のシンクが作成されます。シンクにはすべての子プロジェクトが含まれ、特定の監査ログを選択するためのフィルタリングを指定します。

gcloud logging sinks create gcp_logging_sink_bq22 \
     bigquery.googleapis.com/projects/compliance-logging-export/datasets/gcp_logging_export \
     --log-filter='logName:"/logs/cloudaudit.googleapis.com"' \
     --include-children \
     --organization=324989855333

コマンドの出力は次のようになります。

Created [https://logging.googleapis.com/v2/organizations/324989855333/sinks/gcp_logging_sink_bq].
Please remember to grant `serviceAccount:gcp-logging-sink-bq@logging-o324989855333.iam.gserviceaccount.com` the WRITER role on the dataset..
More information about sinks can be found at /logging/docs/export/configure_export

この API 呼び出しからの戻り値の serviceAccount エントリにおいて、gcp-logging-sink-bq@logging-o324989855333.iam.gserviceaccount.com という ID がレスポンスに含まれます。この ID は、エクスポート用に作成された Google Cloud サービスアカウントを表します。この ID に送信先への書き込みアクセス権を付与するまで、このシンクからのログエントリのエクスポートは失敗します。詳細については、次のセクションまたは BigQuery データセットに必要な権限をご覧ください。

BigQuery データセットの IAM ポリシー権限を設定する

編集者権限を持つ gcp_logging_export データセットにサービスアカウント gcp-logging-sink-bq@logging-o324989855333.iam.gserviceaccount.com を追加することにより、宛先に書き込む権限がサービスアカウントに付与されます。これらの権限が追加されるまで、シンクのエクスポートは失敗します。

サービスアカウントに権限を付与するには、次の操作を行います。

Cloud Console で BigQuery に移動します。

BigQuery に移動
gcp_logging_export データセットの隣にあるをクリックし、[共有データセット] をクリックします。
[ユーザーを追加] フィールドにサービスアカウントを入力します。

このフィルタを使用してログエクスポートを作成すると、構成されたプロジェクトの BigQuery データセットへの入力が、ログファイルによって開始されます。

ベストプラクティス: 必要に応じて、最小権限のポリシーを実装します。特定の Google Cloud ユーザーアカウント、Google グループ、Google Cloud サービスアカウントに基づいて、データセット権限を構成できます。BigQuery データセットへのアクセス権を付与するには、IAM 権限を使用します。

権限セットの例として、次の操作が可能です。

BigQuery データセット権限から、必須でないユーザーをすべて削除します。
BigQuery 管理者に完全なアクセス権を付与します。
エクスポートユーザー権限を付与して、エクスポートログを書き込みます。
他の個別のユーザーに Google Cloud ロギングエクスポートへの閲覧権限を付与します。

データセットの IAM 権限は、Cloud Console から直接更新することも、gsutil コマンドラインユーティリティまたは IAM API を使用して更新することもできます。

エクスポートされたログの使用

BigQuery データセットにログをエクスポートすると、Cloud Logging はエクスポートされたログエントリを保持する日付別テーブルを作成します。ログエントリは、エントリのログ名に基づく名前が付けられたテーブルに格納されます。

日付別テーブル

次のサンプルのように、テーブルリストは YYYYMMDD の接尾辞とともに表示されます。

テーブルのリスト

エクスポートされたログは監査ログであるため、管理者アクティビティログとデータアクセスログは protoPayload 形式で BigQuery に読み込まれます。

外部アクセスの許可

セキュリティアナリスト、DevOps チーム、監査担当者などの特定のユーザーに対して、エクスポートされたログへのアクセス権を付与することもできます。BigQuery では、ログへの安全なアクセス権を付与する多くのオプションが用意されています。

ログの保存場所

BigQuery でユーザーが閲覧できるログを選択するためのオプションは複数あります。

共有するログのコピーを作成する。

手動かプログラムによって、個々のログテーブルやログテーブルのセットを作成し、そのコピーを個別の BigQuery データセットに配置します。次に、必要に応じて個別の BigQuery データセット権限を使用して、特定のユーザーとログを共有します。

メリット: コピーされたデータのみに公開されるデータ量を制限できます。

デメリット: 個別のデータセットを作成、共有、管理する必要があり、コストが高くなる可能性があります。
すべてのログに読み取り専用アクセス権を付与する。

手動かプログラムによって、BigQuery ロギングエクスポートテーブルへの閲覧者権限を設定し、すべてのログエクスポートへのアクセス権を付与します。

メリット: アクセス権を簡単に付与できます。

デメリット: 特定のログファイルではなく、すべてのログにアクセス権を付与する必要があります。

ユーザーのアクセス制御

BigQuery でログへのアクセス権を付与するオプションは複数あります。

Google グループを使用する。

ロギングエクスポート BigQuery データセットへの読み取り専用アクセス権を持つ auditors@example.com などの Google グループを作成します。次に、Google グループで監査担当者の追加や削除を行い、Google アカウントのリストを管理します。

メリット: グループでアクセスを簡単に管理できます。ユーザーアクセスの目的は明確です。

デメリット: グループメンバーシップを確認しないとアクセスできるユーザーがわかりません。
個別の Google アカウントを使用する。

ロギングエクスポートの BigQuery データセットへのアクセス権を、必要とする各ユーザーの個々の Google アカウントに付与します。

メリット: 各ユーザーを手動またはプログラムで簡単に追加できます。

デメリット: 監査ユーザーを他の閲覧者から区別できません。

サンプルの質問とクエリ

監査ログに対してさまざまなクエリを実行できます。これらのクエリは、Google Cloud のデータにアクセスしているのは誰か、オートスケーラーが時間の経過に伴いどのように動作しているかを知るために分析します。

前週に最も頻繁にデータにアクセスしたユーザーは誰か

次のクエリでは、データアクセスの Cloud Audit ログを使用して、データアクセスログで最も頻繁に出てくるユーザーアカウントを検索します。

SELECT
   protopayload_auditlog.authenticationInfo.principalEmail,
   COUNT(*) AS COUNTER
FROM
(TABLE_DATE_RANGE(
Logging_export.cloudaudit_googleapis_com_data_access_,
DATE_ADD(CURRENT_TIMESTAMP(),-7,'DAY'),
CURRENT_TIMESTAMP())
)
WHERE
  protopayload_auditlog.methodName = "jobservice.query"
GROUP BY
   protopayload_auditlog.authenticationInfo.principalEmail
ORDER BY
   protopayload_auditlog.authenticationInfo.principalEmail,
   COUNTER desc
LIMIT
  1000

先月「accounts」テーブルのデータにアクセスしたユーザーは誰か

次のクエリでは、Cloud Audit Logs のデータアクセスログを使用して、accounts テーブルに最も頻繁にクエリを実行しているユーザーアカウントを確認します。your-project-id を実際のプロジェクト ID に置き換えます。

SELECT
   protopayload_auditlog.authenticationInfo.principalEmail,
   COUNT(*) AS COUNTER
FROM
(TABLE_DATE_RANGE(logging_export.cloudaudit_googleapis_com_data_access_,DATE_ADD(CURRENT_TIMESTAMP(),-30,'DAY'),CURRENT_TIMESTAMP()))
WHERE
  protopayload_auditlog.methodName = "jobservice.query" AND
  protopayload_auditlog.authorizationInfo.permission = "bigquery.tables.getData"
AND
  protopayload_auditlog.authorizationInfo.resource = "projects/your-project-id/datasets/bqtesting/tables/accounts"
GROUP BY
   protopayload_auditlog.authenticationInfo.principalEmail
ORDER BY
   protopayload_auditlog.authenticationInfo.principalEmail,
   COUNTER desc
LIMIT
  1000

前週に仮想マシンを削除したユーザーは誰か

次のクエリでは、Cloud Audit Logs の管理アクティビティログを使用して、過去 1 週間に仮想マシンを削除したユーザーアカウントを確認します。

SELECT
  timestamp,
  resource.labels.instance_id,
  protopayload_auditlog.authenticationInfo.principalEmail,
  protopayload_auditlog.resourceName,
  protopayload_auditlog.methodName
FROM
(TABLE_DATE_RANGE(
logging_export.cloudaudit_googleapis_com_activity_,
DATE_ADD(CURRENT_TIMESTAMP(),-7,'DAY'),
CURRENT_TIMESTAMP())
)
WHERE
  resource.type = "gce_instance"
  AND operation.first IS TRUE
  AND protopayload_auditlog.methodName = "v1.compute.instances.delete"
ORDER BY
  timestamp,
  resource.labels.instance_id
LIMIT
  1000

次のクエリは、単純なカウントでアカウントを要約するフォローアップクエリです。

SELECT
  protopayload_auditlog.authenticationInfo.principalEmail,
  count(*) as counter
FROM
(TABLE_DATE_RANGE(
logging_export.cloudaudit_googleapis_com_activity_,
DATE_ADD(CURRENT_TIMESTAMP(),-7,'DAY'),
CURRENT_TIMESTAMP())
)
WHERE
  resource.type = "gce_instance"
  AND operation.first IS TRUE
  AND protopayload_auditlog.methodName = "v1.compute.instances.delete"
GROUP BY
  protopayload_auditlog.authenticationInfo.principalEmail
ORDER BY
  protopayload_auditlog.authenticationInfo.principalEmail,
  counter
LIMIT
  1000

先月オートスケーリングが使用された頻度はどうだったか。オートスケールトレンドは上昇基調、下落基調、安定のうちどれか

次のクエリでは、管理アクティビティの Cloud Audit ログを使用して、先月オートスケーリングが使用された頻度を確認します。

SELECT
  protopayload_auditlog.methodName,
  COUNT(*) AS counter
FROM
(TABLE_DATE_RANGE(
logging_export.cloudaudit_googleapis_com_activity_,
DATE_ADD(CURRENT_TIMESTAMP(),-30,'DAY'),
CURRENT_TIMESTAMP())
)
WHERE
  resource.type = "gce_instance_group_manager"
GROUP BY
  protopayload_auditlog.methodName,
ORDER BY
  protopayload_auditlog.methodName
LIMIT
  1000

次のクエリを使用すると、時間の経過に伴う Compute Engine インスタンスマネージャーの動作の傾向を可視化できます。

SELECT
  timestamp,
  protopayload_auditlog.methodName AS methodName,
  COUNT(*) AS counter
FROM
(TABLE_DATE_RANGE(
logging_export.cloudaudit_googleapis_com_activity_,
DATE_ADD(CURRENT_TIMESTAMP(),-30,'DAY'),
CURRENT_TIMESTAMP())
)
WHERE
  resource.type = "gce_instance_group_manager"
GROUP BY
  timestamp,
  methodName
ORDER BY
  timestamp,
  methodName

上記のクエリを Google データポータルのデータソースカスタムクエリとして使用すると、次のグラフに示すように時間の経過に伴う傾向を可視化できます。

データポータルの可視化

詳細については、データポータルカスタムクエリをご覧ください。

最も頻繁にアクセスされているデータは何で、アクセスしたユーザーは誰か

次のクエリでは、データアクセスの Cloud Audit ログを使用して、最も頻繁にアクセスされている BigQuery データセットを確認し、関連するユーザーアカウントとその数を表示します。

SELECT
  protopayload_auditlog.authorizationInfo.resource,
  protopayload_auditlog.authenticationInfo.principalEmail,
  COUNT(*) AS counter
FROM
(TABLE_DATE_RANGE(
logging_export.cloudaudit_googleapis_com_data_access_,
DATE_ADD(CURRENT_TIMESTAMP(),-30,'DAY'),
CURRENT_TIMESTAMP())
)
WHERE
  protopayload_auditlog.authorizationInfo.permission = "bigquery.tables.getData"
GROUP BY
  protopayload_auditlog.authorizationInfo.resource,
  protopayload_auditlog.authenticationInfo.principalEmail
ORDER BY
  protopayload_auditlog.authorizationInfo.resource,
  protopayload_auditlog.authenticationInfo.principalEmail,
  counter DESC
LIMIT
  1000

前週の BigQuery に対するクエリのトップ 10 は何か

次のクエリでは、データアクセスの Cloud Audit ログを使用して、最もよく使用されているクエリを確認します。

SELECT
  protopayload_auditlog.servicedata_v1_bigquery.jobQueryRequest.query,
  COUNT(*) AS counter
FROM
(TABLE_DATE_RANGE(
Logging_export.cloudaudit_googleapis_com_data_access_,
DATE_ADD(CURRENT_TIMESTAMP(),-7,'DAY'),
CURRENT_TIMESTAMP()))
WHERE
  protopayload_auditlog.methodName = "jobservice.query"
GROUP BY
  protopayload_auditlog.servicedata_v1_bigquery.jobQueryRequest.query
ORDER BY
  counter DESC
LIMIT
  1000

過去 30 日間にデータアクセスログに記録された特に一般的な操作は何か

次のクエリでは、データアクセスの Cloud Audit ログを使用して、過去 30 日間に最も多く記録されたアクションを確認します。

SELECT
  protopayload_auditlog.methodName,
  resource.type,
  COUNT(*) AS counter
FROM
(TABLE_DATE_RANGE(
logging_export.cloudaudit_googleapis_com_data_access_,
DATE_ADD(CURRENT_TIMESTAMP(),-30,'DAY'),
CURRENT_TIMESTAMP())
)
GROUP BY
  protopayload_auditlog.methodName,
  resource.type
ORDER BY
  COUNTER DESC
LIMIT
  1000

次のステップ

Cloud Logging ログを Elastic Cloud にエクスポートする
他のエクスポートシナリオを確認する。
Google Cloud に関するリファレンスアーキテクチャ、図、チュートリアル、ベストプラクティスを確認する。Cloud Architecture Center を確認する。