02事例

とある基幹システムの、守りと運用。

グループ各社の職員の個人データを扱う、とある基幹システムです。情報システム部門の方に向けた説明資料から、お客様とシステムの名前、守りの手がかりになる細部を除いて載せています。

3つの約束

01
止まったままにしない
壊れた版は利用者に届く前に止めます。止まっても、できるだけ人の手を待たずに戻ります。
カナリア配備・自動置き換え・復元の訓練
02
個人データを外に出さない
入口からデータの置き場まで、層を重ねて守ります。持ち出しの疑いはすぐに知らせます。
WAF・内部 IP・データの境界・即時の検知
03
失敗を放置しない
想定した止まり方を台帳に載せ、通知が届くか、直ったかまでを確かめます。
失敗の台帳・無音の検知・修復まで閉じない

数字で見る作り込み

マージした変更: 636; 2026年5月の開発開始から
自動テスト: 約3,000; 実際のデータベースを使う統合テストを含む
台帳に載せた止まり方: 43; 39件は検知と通知先を設定。残りも台帳で毎日数える
監視のアラート定義: 35; 障害とセキュリティ。コードで管理
設計判断の記録: 14; なぜそう決めたかを文書で残す
障害対応の手順書の行数: 約3,100; 通知から手順の節へ直接たどれる

2026年11月1日時点のリポジトリから集計

5つの層で守る

1つ破られても、次の層で止めます。

1入口WAF とレート制限で、攻撃の形と大量の要求を止める。
2認証会社のアカウントのシングルサインオンで本人を確かめ、在籍と許可を確認する。退職日でログインが止まり、1人単位の利用停止もできる。
3認可ロールと担当の関係を API で判定し、項目ごとの閲覧範囲を表で定義する。
4データデータベースは内部の IP だけで、人の接続も本人の ID で行う。データの境界で、外への持ち出しを止める。
5実行物CI が署名していないコンテナイメージは、本番で動かない。

使っている Google Cloud のサービス（守りに関わるもの）

Cloud Run
Cloud SQL（内部 IP だけ）
Cloud Armor
Identity-Aware Proxy
VPC Service Controls
Binary Authorization
Cloud KMS
Secret Manager
Backup and DR
Artifact Analysis
Security Command Center
Workload Identity Federation
Organization Policy
Cloud Logging・Monitoring・Trace

組織の決まりで禁じる

設定を誤っても、権限を乗っ取られても、この決まりを外さない限り実行できません。決まりを変える操作は、それ自体がすぐに通知されます。

禁止サービスアカウントの鍵の作成
禁止データベースの公開 IP
禁止既定のアカウントへの権限の自動付与
禁止ストレージのバケットの公開
禁止組織と指定のドメイン以外への権限の付与
禁止VM の外部 IP
禁止Cloud Run の公開の受け口
禁止OS Login を使わない VM へのログイン
禁止署名の検査を外した Cloud Run
禁止既定のネットワークの自動作成

持ち出しの疑いは、その場で届く

次の操作は、Chat とメールで運用担当に即時に届きます。運用者のアカウントの乗っ取りも想定するので、運用者自身の操作も除外しません。通知には最初に打つコマンドと手順書の節が書いてあり、受け入れ環境で試験発火して鳴ることを確かめています。

データベースへの直接の操作（書き出し・複製など）
シークレットの想定外の読み取り
ファイルの、API を通さない読み取り
権限・監査・監視の設定の変更
組織の決まりの変更
閲覧の記録の書き込みの失敗

触れた記録を5年残す

アプリの閲覧
個人データの閲覧と CSV の出力を記録します。写しをロックしたログに残し、毎朝 1 行ずつ突き合わせるので、記録が消されれば分かります。
データベースの中の操作
人が流した SQL を記録します。値は伏せて残し、記録の量でデータベースが止まらないよう対象を人に絞っています。
クラウドの操作
Google Cloud の監査ログを、保持期間をロックした保管先に残します。保持期間の 5 年の間は、管理者でも消せません。

ログに生の個人情報は出しません。識別子はハッシュにし、データベースのエラーからも値を伏せます。

戻せることまで確かめる

7日: この間の任意の時刻へ戻せる（時点復元）
30日: 毎日のバックアップを別プロジェクトの保管庫に保持。管理者でも消せない
約16分: 時点復元の訓練での本体の停止時間（全体は約68分）

いきなり上書きせず、別のインスタンスへ復元して中身を確かめてから、戻すかを決めます。受け入れ環境で3回、件数や接続まで確かめる訓練をしました。

変更は7つの段を通る

1
PR
本番の枝への直接の変更は禁止。
2
自動の検証
型検査・テスト・実データベースの統合テスト・秘密情報の走査。
3
AIのレビュー
指摘が未解決のままでは取り込めない。
4
受け入れ環境へ
署名・マイグレーション・カナリアの順に自動で。
5
受け入れの確認
本番と同じ構成の環境で動作を確かめる。
6
リリースの依頼
人の依頼がなければ本番には出ない。
7
同じ物を本番へ
確かめた版と照合し、カナリアの確認の後に切り替える。問題があれば数十秒で前の版へ。

点検を続ける

0件
High 以上の指摘（自社診断）
2026年10月28日に実施。OWASP ASVS レベル1 と IPA の基準で、全167ルートを役割ごとに試験。コードで直せる指摘は同日に本番へ反映。
40 / 42
第三者アセスメントの提言に対応
2026年10月に第三者がコードと設定を調査した 42 件の提言のうち、11月1日までに 40 件に対応。残る 2 件は判断のうえで保留。

このシステムの外からも、3つの点検（セキュリティチェック・オペレーションチェック・GCP アドバイザー）が毎日見回っています。

AIが調べて直せる設計

ログは機械が読める形で出し、繰り返しは1行に集約します。障害のたびに、足りなかったログとノイズだったログを直します。

01
検知
エラーを種類ごとに集約し、新規・継続・急増を毎日出す
02
診断
1本のコマンドで版・デプロイ・エラーを一覧する
03
修正
AIが原因を調べ、修正と再発防止を変更にまとめる
04
確認
CI・レビュー・受け入れ環境の同じ関門を通す
05
反映
人のリリースの依頼で本番へ出す