## はじめに

Cloud Run でサービスを運用していると、「エラーが起きていたのに気づかなかった」という経験はないでしょうか。ログを毎日目視で確認するのは現実的ではありませんし、障害の検知が遅れればユーザーへの影響も大きくなります。

Google Cloud には Cloud Logging と連携したアラートポリシーの仕組みがあり、特定の条件に合致するログが発生した際に自動で通知を受け取ることができます。実はこのアラートポリシーには3種類の方式があり、それぞれ得意な場面が異なります。

本記事では、Cloud Run を題材に、3種類のアラートポリシーの特徴と設定方法を Google Cloud コンソール（GUI）と Terraform の両面から解説します。

---

## Cloud Logging のアラートポリシーとは

Cloud Logging では、以下の3種類のアラートポリシーを利用できます。

| 種類 | トリガー条件 | ユースケース | 特徴 |
| :----------------------- | :------------------------------- | :----------------------------------------- | :--------------------- |
| ログベースのアラート | 特定のログエントリが出現 | セキュリティイベント、重大エラーの即時検知 | シンプル、即時性が高い |
| ログベースの指標アラート | ログから作成した指標が閾値を超過 | エラー率の監視、一定期間の集計 | 統計的、柔軟な閾値設定 |
| SQL ベースのアラート | SQL クエリの結果 | 複雑なパターン分析、複数ログの結合 | 高度な分析が可能 |

簡単に言えば、「このエラーが出たらすぐ知りたい」ならログベース、「5分間にエラーが10件以上なら知りたい」なら指標ベース、「複雑な条件で集計して判定したい」なら SQL ベースが適しています。

---

## 事前準備：通知チャンネルの設定

アラートポリシーを作成する前に、通知先となるチャンネルを設定しておきましょう。ここではメール通知を設定します。

### コンソールでの設定

1. Google Cloud コンソールで Monitoring > アラート を開く
2. 上部の「通知チャンネルを編集」をクリック
3. Email の「ADD NEW」からメールアドレスと表示名を登録
4. テスト通知を送信して、正しく届くことを確認

> Tips: メール以外にも Slack、PagerDuty、Webhook など[多数の通知チャンネル](https://cloud.google.com/monitoring/support/notification-options?hl=ja)に対応しています。

### Terraform での設定

以降の Terraform コード例で共通で使用する通知チャンネルの定義です。

```hcl
resource "google_monitoring_notification_channel" "email" {
 display_name = "Email - ops-team"
 type = "email"
 labels = {
 email_address = "ops-team@example.com"
 }
}
```

---

## 1. ログベースのアラート

### 概要

最もシンプルなアラート方式です。ログエクスプローラで定義したフィルタに一致するログエントリが発生するたびに通知されます。

向いているケース:

- セキュリティ上重要なイベント（不正アクセスの試行など）
- 発生頻度が低いが見逃せない重大エラー
- 特定のメッセージやステータスコードの検知

制限事項:

- ポリシーごとに5分に1件のインシデントが上限
- ポリシーごとに1日最大20件のインシデント
- フォルダ・請求先アカウント・組織レベルのログは監視不可
- インシデントはデフォルト7日で自動クローズ

### コンソールから作成する

1. Logging > ログエクスプローラ を開く
2. クエリエディタに以下のフィルタを入力して「クエリを実行」をクリック

```
resource.type="cloud_run_revision"
resource.labels.service_name="my-service"
severity>=ERROR
```

3. 結果を確認したら、ヘッダーの「アラートを作成」>「ログエントリに基づくアラートを作成」をクリック
4. アラートの詳細を入力（アラート名: Cloud Run エラーログ検知、説明: 任意でアラートの目的を記載）
5. 通知先にメールを追加
6. 「保存」をクリック

### Terraform で作成する

```hcl
resource "google_monitoring_alert_policy" "cloud_run_log_alert" {
 display_name = "Cloud Run エラーログ検知"
 combiner = "OR"

 conditions {
 display_name = "Cloud Run ERROR ログの検出"
 condition_matched_log {
 filter = <<-EOT
 resource.type="cloud_run_revision"
 AND resource.labels.service_name="my-service"
 AND severity>=ERROR
 EOT
 }
 }

 notification_channels = [
 google_monitoring_notification_channel.email.name,
 ]

 alert_strategy {
 notification_rate_limit {
 period = "300s"
 }
 auto_close = "604800s"
 }
}
```

condition_matched_log がログベースのアラート専用のブロックです。alert_strategy の notification_rate_limit で通知間隔を制御できます（上記は5分間隔）。

---

## 2. ログベースの指標アラート

### 概要

ログからカスタム指標（メトリクス）を作成し、その指標に対して閾値ベースのアラートを設定する方式です。「5分間にエラーが10件以上」のような統計的な条件で通知したい場合に適しています。

設定は2ステップで行います：

1. ログベースの指標を作成 — ログエントリを数値データに変換
2. アラートポリシーを作成 — 指標に対して閾値を設定

### コンソールから作成する

#### ステップ1：ログベースの指標を作成

1. Logging > ログベースの指標 を開く
2. 「指標を作成」をクリック
3. 以下を設定（指標タイプ: カウンター、指標名: cloud-run-error-count）

```
resource.type="cloud_run_revision"
resource.labels.service_name="my-service"
severity>=ERROR
```

4. 「指標を作成」をクリック

#### ステップ2：アラートポリシーを作成

1. Monitoring > アラート を開き、「ポリシーを作成」をクリック
2. 「指標を選択」で logging.googleapis.com/user/cloud-run-error-count を選択
3. トリガーの条件を設定（条件タイプ: Threshold（閾値）、閾値: 10（5分間に10件以上でアラート））
4. 通知チャンネルにメールを追加して保存

### Terraform で作成する

```hcl
# ログベースの指標
resource "google_logging_metric" "cloud_run_error_count" {
 name = "cloud-run-error-count"
 filter = <<-EOT
 resource.type="cloud_run_revision"
 AND resource.labels.service_name="my-service"
 AND severity>=ERROR
 EOT
 metric_descriptor {
 metric_kind = "DELTA"
 value_type = "INT64"
 }
}

# 指標に対するアラートポリシー
resource "google_monitoring_alert_policy" "cloud_run_metric_alert" {
 display_name = "Cloud Run エラー率アラート"
 combiner = "OR"

 conditions {
 display_name = "5分間のエラー数が10件を超過"
 condition_threshold {
 filter = "metric.type=\"logging.googleapis.com/user/${google_logging_metric.cloud_run_error_count.name}\" AND resource.type=\"cloud_run_revision\""
 comparison = "COMPARISON_GT"
 threshold_value = 10
 duration = "300s"
 aggregations {
 alignment_period = "300s"
 per_series_aligner = "ALIGN_SUM"
 }
 }
 }

 notification_channels = [
 google_monitoring_notification_channel.email.name,
 ]
}
```

ログベースのアラートとの違いは、condition_threshold を使っている点です。duration と alignment_period で評価期間を指定し、threshold_value で閾値を設定します。

---

## 3. SQL ベースのアラート

### 概要

Log Analytics（ログ分析）を有効にした状態で、SQL クエリの結果に基づいてアラートを発行する最も高度な方式です。複数のログソースを結合した分析や、GROUP BY を使った集計など、柔軟な条件指定ができます。

前提条件: ログバケットで Log Analytics が有効化されている必要があります。

### コンソールから作成する

1. Logging > ログストレージ でログバケットの「Log Analytics をアップグレード」を有効化
2. Logging > ログ分析 を開く
3. SQL クエリを入力して「クエリを実行」で結果を確認

```sql
SELECT
 resource.labels.service_name AS service_name,
 COUNT(*) AS error_count
FROM
 `PROJECT_ID.global._Default._AllLogs`
WHERE
 resource.type = 'cloud_run_revision'
 AND severity >= 'ERROR'
 AND timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 10 MINUTE)
GROUP BY
 1
HAVING
 error_count > 20
```

4. クエリ結果が意図通りであれば、「アラートを作成」をクリック
5. 評価間隔や通知先を設定して保存

この例では、10分間にエラーが20件を超えた Cloud Run サービスを検出します。PROJECT_ID は実際のプロジェクト ID に置き換えてください。

### Terraform で作成する

Terraform では condition_sql ブロックを使って SQL ベースのアラートを定義できます。

```hcl
resource "google_monitoring_alert_policy" "cloud_run_sql_alert" {
 display_name = "Cloud Run SQL ベースアラート"
 combiner = "OR"

 conditions {
 display_name = "10分間のエラー数が20件を超過"
 condition_sql {
 query = <<-EOT
 SELECT
 resource.labels.service_name AS service_name,
 COUNT(*) AS error_count
 FROM
 `PROJECT_ID.global._Default._AllLogs`
 WHERE
 resource.type = 'cloud_run_revision'
 AND severity >= 'ERROR'
 AND timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 10 MINUTE)
 GROUP BY
 1
 HAVING
 error_count > 20
 EOT
 minutes {
 periodicity = 10
 }
 row_count_test {
 comparison = "COMPARISON_GT"
 threshold = "0"
 }
 }
 }

 notification_channels = [
 google_monitoring_notification_channel.email.name,
 ]
}
```

minutes.periodicity でクエリの評価間隔（分単位）を指定し、row_count_test でクエリ結果の行数に対する条件を設定します。

---

## 運用のポイント

アラートポリシーは「設定して終わり」ではなく、運用しながら調整していくものです。以下のポイントを意識すると、効果的な監視体制を構築できます。

### フィルタは具体的に

フィルタが広すぎると大量の通知が届き、重要なアラートが埋もれるアラート疲れの原因になります。service_name や severity は必ず絞り込みましょう。

### テスト通知を忘れずに

アラートポリシーを作成したら、意図的にエラーを発生させて通知が正しく届くか確認しましょう。通知チャンネルの設定ミスは意外と多いものです。

### ポリシーの一時停止を活用する

メンテナンス時は、コンソールからアラートポリシーをワンクリックで無効化できます。作業完了後に有効に戻すのを忘れないようにしましょう。

### 3種類の使い分け

| やりたいこと | おすすめの方式 |
| :------------------------------------- | :----------------------- |
| 特定のエラーが出たらすぐ知りたい | ログベースのアラート |
| 一定期間のエラー数で判断したい | ログベースの指標アラート |
| 複雑な条件や複数ログの結合で判断したい | SQL ベースのアラート |

迷ったら、まずはログベースのアラートから始めて、必要に応じて指標ベースや SQL ベースに移行するのがおすすめです。

---

## まとめ

本記事では、Cloud Logging の3種類のアラートポリシーについて、Cloud Run を題材に設定方法を解説しました。

- ログベースのアラート: 特定のログ出現を即座に検知。設定がシンプルで導入しやすい
- ログベースの指標アラート: ログをメトリクスに変換し、閾値で監視。統計的な判断が可能
- SQL ベースのアラート: SQL クエリによる高度な分析。複雑な条件も柔軟に対応

おすすめのフローは、まず GUI で試して動作を確認し、本番運用では Terraform でコード化することです。これにより設定の再現性が担保され、チームでのレビューも容易になります。

Cloud Run に限らず、GCE や Cloud SQL など他のサービスでも同様の仕組みでアラートを設定できるので、ぜひ自分のプロジェクトに合った監視設定を構築してみてください。

---

## 参考リンク

- [ログに基づくアラート ポリシーを構成する - Cloud Logging ドキュメント](https://cloud.google.com/logging/docs/alerting/log-based-alerts?hl=ja)
- [ログベースの指標の概要 - Cloud Logging ドキュメント](https://cloud.google.com/logging/docs/logs-based-metrics?hl=ja)
- [SQL クエリ結果をモニタリングする - Cloud Logging ドキュメント](https://cloud.google.com/logging/docs/analyze/sql-in-alerting?hl=ja)
- [google_monitoring_alert_policy - Terraform Registry](https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/monitoring_alert_policy)
- [google_logging_metric - Terraform Registry](https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/logging_metric)

large_eyecatch.jpg

medium_eyecatch.jpg

small_eyecatch.jpg

thumbnail_eyecatch.jpg

eyecatch.jpg

Cloud Logging のアラートポリシーを活用して Cloud Run を監視しよう

## はじめに

Google Cloud 上でバッチ処理を行う際に、[Cloud Run jobs](https://cloud.google.com/run/docs/create-jobs)を使用したので紹介します。
本記事では、他サービスとの比較と[Cloud Run jobs](https://cloud.google.com/run/docs/create-jobs)の使い方について説明します。

## Google Cloud でバッチ処理できるサービス

Cloud Run jobs を使用するにあたって、他のサービスについても調べたのでそれぞれの特徴をまとめました。

### [Cloud Functions](https://cloud.google.com/functions)

様々なイベントをトリガーにできるので、特定のイベントが発生したときに動かしたいバッチ処理の場合は Cloud Functions を使うと良さそうです。
例えば [Cloud Storage](https://cloud.google.com/storage) に画像がアップロードされた際に、自動的にサムネイルを作成したり、画像にフィルターをかけたりする処理が簡単に作れます。
しかし、最大実行時間に制限(60 分)があるため長時間の処理には適さない場合があります。

### [Batch](https://cloud.google.com/batch)

大規模なバッチ処理ワークロードを効率的に実行するためのフルマネージドなサービスです。
高性能コンピューティング（HPC）、機械学習、データ処理など、さまざまな種類のバッチジョブをスケーラブルかつ柔軟に実行できます。
また、最大実行時間に制限が無いので長時間の処理に適しています。
しかし、Cloud Functions や Cloud Run jobs よりも設定が複雑になってしまうので採用しませんでした。

### [Cloud Run jobs](https://cloud.google.com/run/docs/create-jobs)

Cloud Run の一機能で、バッチ処理や非同期タスクの実行に特化したサービスです。
最大実行時間に制限がありますが、24 時間実行できるのでほとんどのバッチ処理は問題ないでしょう。

## Cloud Run jobs の基本要素

### Cloud Run jobs のリソース構造

Cloud Run jobs は以下のようなリソースで構成されています。 
 ![リソース構造](https://cont.sterfield.co.jp/uploads/resource_a778e2a692.jpg) 

### ジョブ (Job)

実行したいタスクの全体像を定義するルートリソースです。

ジョブでは以下の項目を設定できます。

- コンテナイメージ
- タスク数
- 並列実行数
- リソース(各タスクに割り当てる CPU やメモリなどのリソース量)
- 環境変数
- サービスアカウント

### タスク (Task)

ジョブによって定義されたタスクのインスタンスです。
タスクはジョブに設定された数だけ実行されます。コンテナインスタンスを 1:1 で用意し、コンテナインスタンスごとの進捗を管理します。タスクがエラーで終了した場合は、タスク単位で再実行もできます。

### 実行 (Execution)

タスクの実行履歴です。
ジョブの設定に応じてタスクを実行し、全てのタスクが完了するまでの状態を管理します。1 度作成した実行は、何度でも再実行が可能です。

## Cloud Run jobs の作成・実行方法

### サンプルアプリケーションの用意

以下のコードを適当なフォルダに作成します

環境変数に`SLEEP_MS`を設定すると、設定した時間だけスリープするようになり、時間のかかる処理を再現できます。
`FAIL_RATE`を設定すると、指定した確率でジョブがエラーになり、エラー時の挙動を確認できます。

main.js

```js
// Retrieve Job-defined env vars
const { CLOUD_RUN_TASK_INDEX = 0, CLOUD_RUN_TASK_ATTEMPT = 0 } = process.env;
// Retrieve User-defined env vars
const { SLEEP_MS, FAIL_RATE } = process.env;

// Define main script
const main = async () => {
 console.log(
 `Starting Task #${CLOUD_RUN_TASK_INDEX}, Attempt #${CLOUD_RUN_TASK_ATTEMPT}...`
 );
 // Simulate work
 if (SLEEP_MS) {
 await sleep(SLEEP_MS);
 }
 // Simulate errors
 if (FAIL_RATE) {
 try {
 randomFailure(FAIL_RATE);
 } catch (err) {
 err.message = `Task #${CLOUD_RUN_TASK_INDEX}, Attempt #${CLOUD_RUN_TASK_ATTEMPT} failed.\n\n${err.message}`;
 throw err;
 }
 }
 console.log(`Completed Task #${CLOUD_RUN_TASK_INDEX}.`);
};

// Wait for a specific amount of time
const sleep = (ms) => {
 return new Promise((resolve) => setTimeout(resolve, ms));
};

// Throw an error based on fail rate
const randomFailure = (rate) => {
 rate = parseFloat(rate);
 if (!rate || rate < 0 || rate > 1) {
 console.warn(
 `Invalid FAIL_RATE env var value: ${rate}. Must be a float between 0 and 1 inclusive.`
 );
 return;
 }

 const randomFailure = Math.random();
 if (randomFailure < rate) {
 throw new Error("Task failed.");
 }
};

// Start script
main().catch((err) => {
 console.error(err);
 process.exit(1); // Retry Job Task by exiting the process
});
```

package.json

```json
{
 "main": "main.js",
 "scripts": {
 "start": "node main.js"
 },
 "engines": {
 "node": ">=20.0.0"
 }
}
```

Dockerfile

```Dockerfile
FROM node:20
WORKDIR /app
COPY . .
RUN npm install
CMD [ "npm", "start" ]
```

### コンテナをプッシュ

次のコマンドで [Artifact Registry](https://cloud.google.com/artifact-registry) にコンテナをプッシュします。`${REGION}`と`${PROJECT_ID}`は各自で置き換えてください。

```
gcloud builds submit --tag ${REGION}-docker.pkg.dev/${PROJECT_ID}/gcr.io/job-sample
```

### ジョブを作成

今回は、以下の Cloud Run のコンソールから作成します。 
https://console.cloud.google.com/run/jobs

「ジョブの作成」をクリックします。 
 ![ジョブの作成ボタン](https://cont.sterfield.co.jp/uploads/job_create_1_691d934c36.png) 

「コンテナ イメージの URL」に先ほど作成したコンテナを選択します。
イメージ名が自動的に設定されます。
リージョンやタスク数はお好みで設定して下さい。 
 ![ジョブの詳細](https://cont.sterfield.co.jp/uploads/job_create_2_c2c65e6a14.png) 

### ジョブの実行

「実行」をクリックし、ジョブを開始します。 
 ![実行ボタン](https://cont.sterfield.co.jp/uploads/job_create_3_3049895faf.png)

しばらく経つと、全てのタスクが完了し、実行が完了します。実行の詳細を開くとタスクが完了していることが確認でき、各タスクのログ等が確認できます。 
 ![タスク](https://cont.sterfield.co.jp/uploads/job_create_4_6281075873.png) 

### 作成した Job を定期実行する方法

「トリガー」タブを選択し、「スケジューラ トリガーを追加」をクリックします。 
 ![トリガー追加ボタン](https://cont.sterfield.co.jp/uploads/scheduler_1_1e1f8511c4.png) 

頻度を unix-cron 形式で選択します。
今回は 5 分ごと(`*/5****`)に実行してみます。 
 ![トリガー詳細](https://cont.sterfield.co.jp/uploads/scheduler_2_f70181ea5b.png) 

指定した通り、5 分ごとにジョブが実行されました。 
 ![ジョブ一覧](https://cont.sterfield.co.jp/uploads/scheduler_3_69acf4aa19.png) 

## まとめ

今回は Cloud Run jobs について説明しましたが、各サービスのメリット・デメリットを比較し、要件に合った最適なサービスを選択することが重要です。
今後、他サービスにも触れる機会がありましたら紹介したいです。

## 参考

- https://speakerdeck.com/satohjohn/gcptenohatutichu-li-hatanwokao-etemiru
- https://zenn.dev/google_cloud_jp/articles/cloudrun-jobs-basic
- https://cloud.google.com/run/docs/quickstarts/jobs/build-create-nodejs

small_cloud-run.png

thumbnail_cloud-run.png

cloud-run.png

Cloud Run jobs を利用したバッチ処理

## はじめに

Google Cloud の [Cloud Run](https://cloud.google.com/run?hl=ja) を使ってインターネット上に公開せず内部からのアクセスのみを受け付けるサービスを構築する場合、いくつかの方法がありますが認証オプションを「認証が必要」にしてデプロイする方法がもっとも簡単です。

 ![cloud-run-deploy](https://cont.sterfield.co.jp/uploads/cloud_run_deploy_0b4c2235ac.png) 


この方法でデプロイした Cloud Run サービスの URL にブラウザでアクセスするとリクエストに認証情報が含まれてないため

```
Error: Forbidden
Your client does not have permission to get URL / from this server.
```

というエラーが表示されます。このエラーを回避して、アクセスする方法のうち代表的な3パターンを紹介します。

## 前提

Node.js で書かれたアプリケーションがデプロイされた次の 2 つの Cloud Run サービスがデプロイされている環境があるとします。

- 「Front」はインターネット上から直接アクセスされることを想定しているため、認証オプション「未認証のアクセスを許可」を設定してデプロイされている
- 「Internal」は「Front」から内部でアクセスされるもので外部からのアクセスを拒否したいため、認証オプション「認証が必要」を設定してデプロイされている

![cloud-run-diagram](https://cont.sterfield.co.jp/uploads/cloud_run_diagram_a0a3472409.png) 

## ① 他の Cloud Run サービスからアクセスする方法

「Front」 → 「Internal」

同じプロジェクトでデプロイされた Cloud Run 同士でアクセスする場合、[Google Auth Library](https://github.com/googleapis/google-auth-library-nodejs)を使うことで認証に必要なトークンを含んだ HTTP ヘッダーが取得できます。

「Front」の Cloud Run サービスをデプロイしたサービスアカウントに`Cloud Run 起動元` (`roles/run.invoker`) ロールが付与されている場合、下記のようなコードでアクセスが可能になります。

```
import { GoogleAuth } from "google-auth-library";

・・・

const auth = new GoogleAuth();
const client = await auth.getIdTokenClient(`${「Internal」のURL}`);
const headers = await client.getRequestHeaders();

// headersの中に Authorization: Bearer ${トークン} が設定されている
await fetch(`${「Internal」のURL}`, { headers });
```

## ②Cloud Run 以外のサービスからアクセスする方法

Cloud Scheduler → 「Internal」

[Cloud Scheduler](https://cloud.google.com/scheduler?hl=ja)から「Internal」にアクセスする場合は、HTTP ターゲットを作成する際、Auth ヘッダーを「OIDC トークンを追加」に設定してサービスアカウントに`Cloud Run 起動元` (`roles/run.invoker`) ロールが付与されているものを設定すると、自動でトークンを付与した HTTP アクセスを行ってくれます。

 ![cloud-scheduler](https://cont.sterfield.co.jp/uploads/cloud_scheduler_74457eda15.png) 

[Cloud Pub/Sub](https://cloud.google.com/pubsub?hl=ja)などでも同じように OIDC 認証を設定することでアクセス可能になります。

## ③ ローカルからアクセスする方法

開発者のローカル PC のコンソール → 「Internal」

gcloud CLI を使うことで開発用の汎用 ID トークンを生成することができます。`Cloud Run 起動元` (`roles/run.invoker`) ロールが付与されているユーザーでログインして、[`gcloud auth print-identity-token`](https://cloud.google.com/sdk/gcloud/reference/auth/print-identity-token)を実行するとログインユーザーのトークンが取得できます。

curl コマンドと組み合わせて下記の様に実行することでアクセスが成功します。

```
curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" ${「Internal」のURL}
```

## まとめ

今回紹介した内容はすべて Google Cloud の公式ドキュメントに記載されているものですが、複数のページにまたがって解説されており、個人的に探すのが大変だったのでブログにまとめました。同じような苦労をされている方のお役に立てれば幸いです。

## 参考リンク

- https://cloud.google.com/run/docs/tutorials/secure-services?hl=ja
- https://zenn.dev/steelydylan/scraps/60f3536dd0c9b4
- https://cloud.google.com/scheduler/docs/http-target-auth?hl=ja
- https://cloud.google.com/run/docs/authenticating/developers?hl=ja#curl

small_cloud_run.png

thumbnail_cloud_run.png

cloud_run.png

認証が必要な Cloud Run サービスにアクセスする方法まとめ

## はじめに
先日、東京ビッグサイトで開催されたGoogle Cloud Next Tokyo '23のDay2に参加してきました。

 ![](/uploads/PXL_20231116_001744341_2_90d59a9df4.jpg) 

全体としては生成AIに関するトピックが盛り上がってましたが、セキュリティに関するセッションもいくつかあり、その中で私は下記のセッションに参加して話を聞いてきました。

- [セルフで行う Google Cloud 環境のセキュリティ チェックの方法](https://cloudonair.withgoogle.com/events/next-tokyo?talk=d2-di-04)
- [Google Cloud のセキュリティ機能、基本のキ｜Security Command Center で実現するリスク管理](https://cloudonair.withgoogle.com/events/next-tokyo?talk=d2-sec-02)

どちらのセッションでもSecurity Command Centerを使うことでGoogle Cloudを安全に運用できるという内容でした。
こちらをもとに本記事では、Google Cloudを利用しているがSecurity Command Centerは使ったことがない人向けに、Security Command Centerを使い始めるための設定方法と簡単な使い方の解説します。

## Security Command Centerとは
Security Command CenterはGoogle Cloud上の脆弱性や脅威となりうる設定を検知してくれるサービスです。

有効化しておくと自動で利用しているサービス、リソースを認識して、それらを対象に設定内容をスキャンしてくれるため運用に負荷がかからないのが特長です。また有償版のプレミアムティアーのみの機能となりますが、ISO 27001やPCI DSSのような業界標準への遵守状況も確認できるなどスキャン以外にも様々な機能があります。

今回は無償版のスタンダードティアーでも利用可能なSecurity Health Analytics機能を使って、Google Cloudの設定ミスの診断を試してみました。

## 実際に適用してみた結果
ありがちなユースケースとして、組織の管理権限はもってないが開発環境のプロジェクトだけ変更権限だけを持つユーザーが、Security Command Centerを使ってプロジェクトの脆弱性を診断してみるというシナリオでやってみました。

1. Security Command Centerの有効化
  - まず最初にコンソールでプロジェクトを選択した状態でSecurity Command Centerを開いて有効化を行います。スタンダードとプレミアムの2つのティアーを選択する画面になるので、無償版であるスタンダードを選んで次へを押します。すると、どの機能を有効化するか設定するダイアログが表示されます。すべてデフォルト値のままで進めます。

     ![](/uploads/249ce2bfaa98636550da620a_d3f7f1273a.png) 
      (引用：https://zenn.dev/cloud_ace/articles/scc_standard#security-command-center(%E3%82%B9%E3%82%BF%E3%83%B3%E3%83%80%E3%83%BC%E3%83%89)%E3%82%92%E6%9C%89%E5%8A%B9%E3%81%AB%E3%81%97%E3%81%A6%E3%81%BF%E3%82%8B)

  - 詳細な手順は公式ドキュメントで解説されているのでそちらを参照してください。
  https://cloud.google.com/security-command-center/docs/activate-scc-for-a-project?hl=ja#project-activation-scc-inactive-in-org

2. 診断結果の確認
  - 設定が完了すると自動で脆弱性のスキャンが行われますが、初回のスキャンは少し時間がかかります。今回の例だと24時間ほど待つ必要がありました。
  - 完了するとダッシュボードにスキャン結果が表示されます。脆弱性ページで脆弱性の種類、件数などが確認できます。

     ![](/uploads/scc_1_762224c8e4.png) 
    

3. 脆弱性の対応
  - ここではデフォルトのまま使っていると必ず検出されるOpen RDP portを対象として、実際に対応する場合の流れを解説します。

  - 詳細を開くと脆弱性の詳細や、対象のリソースの情報が確認できます。更に次のステップのところに対応方法が示されます。
    ![](/uploads/scc_2_0a09b3e035.png) 

  - それに従って、ファイアウォール ルールのdefault-allow-rdpの設定を変更します。IPの範囲が0.0.0.0/0がまずいとのことなので削除して35.235.240.0/20を設定します。
     ![](/uploads/scc_3_4f9c670868.png) 

  - なお、ルール自体を無効にしてしまえばIP範囲は変更しなくてよさそうに思えますが、この対応ではだめでした。脆弱性の判断基準としてルールが無効かどうかは関係ないようです。現時点で実害があるかどうかではなく、潜在的な脆弱性として指摘しておくポリシーなのかもしれません。

4. 対応結果の確認
  - 初回スキャンと同様に対応後の確認も特に操作は不要で、自動で再チェックが行われて脆弱性ページの件数が1=>0になります。初回スキャン時と異なり、設定変更後の再スキャンはほぼ即時反映のようで数分後には対応済みになりました。
  - 対応済みの脆弱性を確認したい場合、脆弱性ページ上からは見られなくなってしまいますが、検出結果ページのクエリ編集画面で下記のとおりクエリを変更すると確認可能になります。
    ```
    変更前）
    state="ACTIVE" AND NOT mute="MUTED"

    変更後）
    state="INACTIVE" AND NOT mute="MUTED"
    ```
     ![](/uploads/scc_4_19e81badad.png) 

## まとめ
- Security Command Centerは有効化するだけで特に設定も不要かつ無料で始められるので、使ってみることをおすすめします。
- 検出された脆弱性ごとの対応方法まで案内されるので非常に親切だが、今すぐ対応すべき問題かどうかは利用者自身が判断する必要があります。そのため、まったく知識がない状態で運用することは難しそうです。これについてはGoogle側でも課題と考えているようで、Duet AIによる支援機能が現在開発中とのことです。
- 組織単位でSecurity Command Centerの有効化を行うことで、アカウントの設定不備のようなプロジェクトをまたがった設定内容もスキャン対象となるため、より効果的な運用ができそうです。今回の検証結果をもとに、全社的にSecurity Command Centerを利用する方針を検討していきます。

## 参考リンク
- [Security Command Center](https://cloud.google.com/security-command-center?hl=ja)
- [Security Command Center でお手軽セキュリティ診断](https://zenn.dev/cloud_ace/articles/scc_standard)
- [[Google Cloud] SCC -Security Health Analytics-を試す](https://qiita.com/khoshina/items/f6ccea548e9ed39cdea8)


small_security-command-center.440x512.png

thumbnail_security-command-center.440x512.png

security-command-center.440x512.png

Security Command Centerを使ってGoogle Cloudの設定内容を診断してみよう

Blogブログ

Articles

Contact Us