Security Engineering の
SRE / 運用 / コスト / Observability 深掘り

1. SRE の原則とセキュリティ運用への適用

Google SRE の原則は「セキュリティ運用」にもそのまま適用できる。セキュリティを SLO で測ることが起点。

2. Security SLI / SLO 設計

セキュリティ運用も SLO（Service Level Objective）で定量化できる。何を測るかを最初に決める。

典型 Security SLI 例

SLO カード例

3. エラーバジェット運用

SLO で 意図的に許容する失敗率を定義し、それを 変更の燃料として扱う。

エラーバジェットの計算

運用ルール（典型）

• バジェット 70% 残：通常運用、変更を進める
• バジェット 30〜70%：変更速度を下げ、安定化を優先
• バジェット 30% 未満：変更フリーズ（緊急修正のみ）、根本原因対応
• バジェット 0%：全変更停止、ポストモーテム + 構造的改善

4. Observability の 3 本柱

「障害を予防 / 検知 / 復旧」するための観測体系。Metrics / Logs / Traces の三本柱。

4 Golden Signals（Google SRE の原則）

• Latency：成功 / 失敗リクエストの応答時間
• Traffic：リクエスト数 / 秒
• Errors：失敗リクエスト率
• Saturation：システムリソースの飽和度

5. Cloud Monitoring 詳細

監視対象のセキュリティメトリクス（公式 + カスタム）

カスタムメトリクス（OpenTelemetry）

• SCC Critical Findings 数：Cloud Functions で集計し OpenTelemetry で投稿
• Audit Log 取り込み P99 遅延：Log Sink の処理時間を計測
• Workload Identity Federation の異常な claim 数：STS Audit Log から派生
• VPC SC Policy Denied 数：境界違反のトレンド

アラート設計の原則

6. ロギング戦略とコスト

料金構造（2026 年 5 月時点）

コスト削減策

1. Exclusion Filter　ヘルスチェック / 内部 SA / 高頻度低リスク操作を除外。例：resource.type="k8s_pod" AND severity="DEBUG"
2. Sampling　VPC Flow Logs / Firewall Logs のサンプリングレートを段階的に下げる（既定 50% → 10%）
3. Tier 分離　ホットログ（30 日 BigQuery）/ ウォーム（1 年 Log Bucket）/ コールド（7 年 GCS Coldline）
4. Data Access 限定有効化　機微サービスのみ ON、その他は OFF を維持
5. Log-based Metrics　大量ログから集計値だけメトリック化、ログ本体は除外可
6. Aggregated Sink の Filter 最適化　組織全体の取り込み量を 30〜50% 削減可能

gcloud logging sinks update _Default \
    --add-exclusion=name=exclude-k8s-debug,filter='resource.type="k8s_pod" AND severity="DEBUG"' \
    --add-exclusion=name=exclude-lb-healthcheck,filter='resource.type="http_load_balancer" AND httpRequest.userAgent="GoogleHC/1.0"' \
    --add-exclusion=name=exclude-secret-list,filter='protoPayload.methodName="google.cloud.secretmanager.v1.SecretManagerService.ListSecrets"'

典型コスト分解（中規模組織 / 月次）

想定: 50 プロジェクト / 月 5 TB の Audit Log 取り込み

7. Cloud Trace / Profiler / Error Reporting

• Cloud Trace：分散トレース。OpenTelemetry SDK で計装、レイテンシボトルネック特定
• Cloud Profiler：継続的 CPU / メモリプロファイリング、本番稼働中に低オーバーヘッド
• Error Reporting：未捕捉例外の集約、Slack / メール通知
• Cloud Debugger：本番コードのスナップショット取得（停止せずに）

セキュリティ系のトレース活用

• IAM / VPC SC 違反のリクエスト経路追跡
• SDP de-identify パイプラインのレイテンシ分析
• Vertex AI 推論の異常応答時間検出

8. セキュリティサービスのコスト管理

主要セキュリティサービスのコストドライバ

コスト可視化と統制

• Cloud Billing → BigQuery エクスポート：ラベル別 / プロジェクト別 / SKU 別の詳細分析
• FinOps ダッシュボード：Looker Studio / Looker で月次レビュー
• 予算アラート：50% / 75% / 90% / 100% / 120% で Slack 通知
• Custom Quota：プロジェクト単位で「BigQuery クエリ usage 上限」「Cloud NAT IP 数」など
• Recommender：Cloud Billing Recommender が「使われていない CMEK 鍵」「過剰な Log 保持」を提案

9. クォータ / キャパシティ計画

主要クォータ（既定値の一部）

容量計画の手順

1. 過去 90 日の使用量を Cloud Monitoring から抽出
2. 増加トレンド + 季節性を分析（イベント / セール / 月末バッチ）
3. 3〜6 ヶ月先の 必要量を予測（線形 / ARIMA）
4. クォータ 80% 到達時点を予測し、その 30 日前に引き上げ申請
5. Cloud Monitoring の SLO Burn Rate Alertで予防検知

10. Runbook / Playbook 整備

Runbook（手順書）に必須の項目

• トリガー条件（どのアラート / イベントで開く）
• 影響範囲の確認（影響評価コマンド）
• 初動対応（封じ込め手順）
• 復旧手順（ステップごとの gcloud / Terraform コマンド）
• エスカレーション基準（誰に / いつ）
• 関連ダッシュボードのリンク
• 過去のインシデントへのリンク

セキュリティ Runbook の代表例

1. SA 鍵漏洩対応（Github / Public への流出検出時）
2. VPC SC 違反による業務停止対応
3. Cloud KMS 鍵 destroy 誤操作対応
4. SCC Critical Finding 対応（IAM 異常 / マルウェア検知）
5. 大量データ漏洩対応（72h 規制報告含む）
6. 外部 IdP 障害時の Super Admin 利用
7. Audit Log 欠落対応
8. 本番 Org Policy 変更ロールバック

11. オンコール / エスカレーション

オンコール体制設計

• Follow-the-Sun：複数拠点で時差カバー（米国 / 欧州 / 日本）
• Primary / Secondary：1 次対応者 + バックアップ
• Escalation Tree：1 次 → 2 次 → Manager → CISO → C-level
• RTO 明示：SEV1 = 15 分、SEV2 = 30 分など

オンコール健康管理（公式 SRE 原則）

• 1 週間のオンコール後に 1 週間のオフタイム
• ページング回数 1 シフトで 2 回以下を目標（Operational Overload）
• 業務時間外のページは compensationを支給
• 四半期に オンコール体験を振り返り、改善

Incident Command（インシデント対応の役割分担）

• Incident Commander (IC)：全体指揮、意思決定
• Operations Lead：実際の復旧操作
• Communications Lead：社内外コミュニケーション
• Scribe：時系列ログを記録（ポストモーテムの材料）

12. Chaos Engineering / Game Day

想定シナリオを意図的に発動させ、対応力を訓練する。

セキュリティ系 Game Day シナリオ例

• SA 鍵漏洩 simulator：テスト用 SA 鍵を Public Gist に投稿し、検知から対応まで計測
• VPC SC Dry Run → 強制 enforce：影響範囲が見えるかテスト
• KMS 鍵 disable：開発環境で鍵を 30 分 disable し、依存サービスの fail-safe を確認
• 外部 IdP 停止：SSO IdP を意図的に停止、Super Admin 復旧手順を演習
• Cloud Logging 障害シミュレーション：Sink writerIdentity を一時剥奪、SIEM の欠落検知
• Critical Finding 発火：SCC に意図的に Finding を作り、対応 SLO 達成を計測

13. IaC / GitOps / Policy-as-Code

セキュリティ構成の IaC 化

• Terraform：組織ポリシー / IAM / VPC SC / KMS 鍵 / SCC Tier すべてコード化
• Config Connector / Config Controller：GCP リソースを Kubernetes CRD で管理
• Crossplane：マルチクラウド統一管理（必要なら）
• Open Policy Agent (OPA) / Gatekeeper：Policy-as-Code、CI で構成検証
• Sentinel：Terraform Enterprise の policy 検証

GitOps の実装例

Policy-as-Code 例（OPA / Rego）

package terraform.gcp.wif

deny[msg] {
  resource := input.resource.google_iam_workload_identity_pool_provider[name]
  not resource.attribute_condition
  msg := sprintf("WIF provider %q must define attribute_condition", [name])
}

deny[msg] {
  resource := input.resource.google_iam_workload_identity_pool_provider[name]
  resource.attribute_condition == ""
  msg := sprintf("WIF provider %q has empty attribute_condition", [name])
}

Drift 検出

• Cloud Asset Inventoryで実際の構成を取得
• Terraform state との差分を Cloud Functionsで日次比較
• 差分があれば Slack 通知 + Security Posture Service で Finding 化

14. DR / BCP 設計

セキュリティ機能の DR 観点

RTO / RPO の目安

• SOC ダッシュボード：RTO 30 分 / RPO 5 分
• Audit Log 取り込み：RTO 1 時間 / RPO 0（欠落なし）
• SCC Findings：RTO 4 時間 / RPO 1 時間
• 規制対応データ（Audit Log）：RTO 8 時間 / RPO 0
• セキュリティ構成全体：RTO 1 営業日 / RPO 1 時間

15. セキュリティ運用 KPI

運用成熟度を測る KPI

16. 成熟度モデルとロードマップ

セキュリティ運用成熟度（5 段階）