MAS-234: セキュリティ基準準拠ロードマップ（CIS Controls v8 ベース）

概要

目的

CIS Controls v8 を骨格に、NIST CSF 2.0 / ISO/IEC 27001:2022 Annex A / FISC 安全対策基準との対応関係をマッピングした上で、段階的にセキュリティ統制を実装する。既に発生した failure_pattern #26（OAuth スコープ崩壊）の教訓を組み込み、投資家アピール・金融機関を含む顧客監査対応・プライバシーマーク取得（MAS-254）の前提基盤として位置付ける。

運用モデル:

1. docs/arch/security_framework_mapping.md を読取専用の基準マッピング台帳とし、全 Safeguard の充足状況を一覧化
2. 本仕様書（MAS-234）で Phase 0-6 の段階的ロードマップ を定義
3. 各 Phase の具体的実装は既存案件（MAS-179/MAS-201/MAS-205 等）の完了・再利用で達成し、ギャップ部分のみ本案件スコープで追加実装
4. 採用基準の優先順位: CIS Controls v8 → NIST CSF 2.0 → ISO 27001 Annex A → FISC → 電帳法（MAS-152）/ P マーク（MAS-254）

Human-in-the-Loop: 全監査スクリプトの実行結果は人間レビュー必須。自動修正は Phase 1 の誤コミット防止（pre-commit hook）を除き行わない。

現在のコード・既存資産

既実装・仕様書完了のセキュリティ資産（MAS-234 の前提）

既発生インシデント（教訓として組み込み済）

• failure_pattern #26（2026-04-20）: appsscript.json の oauthScopes 部分宣言により既存スコープ自動検出がオフになり、主要機能が一斉停止。→ Phase 1 の Script Properties / appsscript.json 変更監査 で同種事故を事前検知

修正方針

本案件は 7 Phase で段階実装する。各 Phase の詳細は docs/arch/security_framework_mapping.md の該当 Safeguard 欄と突き合わせて進める。

Phase 0: 現状把握・セキュリティ構成監査（所要 1-2h・即着手）

目的: ベースラインとしての現状セキュリティ設定を機械可読な形で取得し、後続 Phase の差分検証に使用する。

実装: 800_ops/814_audit_security_config.js 新規作成、公開関数 auditSecurityConfig()

収集項目:

1. GAS プロジェクト情報: ScriptApp.getScriptId() / appsscript.json の oauthScopes 全列挙 / 時間トリガー一覧（ScriptApp.getProjectTriggers()）
2. スクリプトプロパティ一覧: キー名のみ（値はマスク表示）
3. Workspace 設定のスナップショット: 2FA 有効状況 / 共有設定 / Admin Reports API で取得できる範囲
4. GCP IAM スナップショット: Service Account 一覧 / ロール割当（MAS-215 で整備済 dev/prod それぞれ）
5. Drive 共有設定: Spreadsheet ファイルの共有権限（メール単位）・外部共有有無

出力先: 99_security_audit シート（新規 DDL 管理外）。実行ごとに clearContents() → setValues、日時スタンプ付き。

該当 CIS: CIS 1（資産のインベントリ）/ CIS 2（ソフトウェア資産管理）/ CIS 3（データ保護の現状把握）

Phase 1: 基礎衛生（Basic Hygiene、4-6h・即着手）

目的: 開発運用における基本的な事故（秘密情報誤コミット・設定崩壊）を物理的に予防する。

実装 5 項目:

1. creds.json / .env 誤コミット防止 CI（.github/workflows/secret-scan.yml 新規）

   • GitHub Actions で PR 時に gitleaks または trufflehog を実行
   • 検出時はコミットブロック + PR コメント自動投稿
   • 既存 .gitignore の見直し（creds.json / .env* が列挙されていることを確認）

2. Pre-commit hook 導入（.husky/pre-commit 新規 or lefthook.yml）

   • ローカルでも同様の秘密情報スキャン
   • appsscript.json 変更時は警告ダイアログ（failure_patterns #26 対策）

3. Script Properties 必須項目チェック（800_ops/815_sp_audit.js 新規）

   • Env モジュールが参照する全キー（ENV / GEMINI_API_KEY / CLAUDE_API_KEY / GCP_PROJECT_ID_DEV / GCP_PROJECT_ID_PROD / VERTEX_REGION 等）の存在を検証
   • 欠落時はダッシュボード警告

4. appsscript.json 変更監視（CI）

   • PR で appsscript.json が変更された場合、CODEOWNERS で Sr 承認必須 + レビューアー指定
   • oauthScopes フィールドの追加を特に注意喚起（failure_patterns #26）

5. 依存関係脆弱性スキャン（.github/workflows/dependabot.yml + Dependabot 設定）

   • package.json の依存の脆弱性を自動検出・PR 作成

該当 CIS: CIS 3（データ保護）/ CIS 4（安全な構成）/ CIS 5（アカウント管理）/ CIS 6（アクセス制御）

Phase 2: アクセス管理（4-6h）

目的: 最小権限原則を全レイヤーで徹底し、Jr 参加時のリスクを構造的に低減する。

実装:

1. Drive 権限定期監査（800_ops/816_drive_access_audit.js 新規）

   • 対象 Drive フォルダ（財務データ格納先）の共有権限を月次で自動取得
   • 外部ドメインへの共有を検出した場合はアラートメール
   • MAS-206（外部共有制限）の運用補完

2. GCP Service Account 最小権限化（MAS-215 延長）

   • dev / prod プロジェクトの SA ロールを棚卸し
   • 不要な Editor / Owner を Custom Role に置換
   • 実装台帳を docs/_internal/biz/gcp_iam_inventory.md に記録

3. CODEOWNERS 強化（MAS-225 延長）

   • appsscript.json / 000_infra/ / 100_config/ 等の重要ファイルに Sr 承認必須
   • @sr-team ラベルの運用

4. Jr 権限分離運用の確立（MAS-229 実装）

   • Jr 入社前（D-90）に本項を着手し、採用プロセスと連動

該当 CIS: CIS 5（アカウント管理）/ CIS 6（アクセス制御）/ CIS 14（セキュリティ意識）

Phase 3: 監査・ログ（6-8h）

目的: 監査証跡の改ざん耐性を確保し、異常操作を検知可能にする。

実装:

1. 監査ログ不可侵化（MAS-213 実装）

   • Sheet.protect() で 98_audit_log 編集禁止
   • setupAllSchemas で冪等再適用

2. 異常操作検知（800_ops/817_anomaly_detection.js 新規・Phase 3 後半）

   • Utils.auditLog の直近 100 件を Gemini に投げて「通常と異なる操作パターン」を判定
   • 例: 深夜のバックアップ削除・不慣れなユーザーによる特権操作
   • 検出時は代表者にメール通知

3. Cloud Audit Logs 統合（MAS-210 の先行切出）

   • GCP 側（MAS-215 整備済）の Admin Activity / Data Access ログを BigQuery or Logs Explorer で定期レビュー
   • 月次で Sr が 30 分レビュー（運用タスク）

4. 98_audit_log → Cloud Logging 転送（将来拡張）

   • 現状は Spreadsheet 内保持。Phase 4 GCP 移行時に Cloud Logging へ転送する準備

該当 CIS: CIS 8（監査ログ管理）/ CIS 13（ネットワーク監視）/ CIS 17（インシデント対応準備）

Phase 4: データ保護（4-6h）

目的: 財務データ・証憑の暗号化確認と改竄防止を技術的に裏付ける。

実装:

1. 暗号化確認レポート（docs/_internal/biz/encryption_attestation.md 新規）

   • Google Spreadsheet: 保存時 AES-256 / 転送時 TLS（Google SOC 2 準拠済、ホワイトペーパー引用）
   • GCP: Vertex AI / Cloud Storage も同水準（MAS-216 関連）
   • 追加の暗号化レイヤー（CMEK）は Phase 5 で MAS-246〜MAS-249 と連動

2. 証憑改竄防止（MAS-152 + MAS-213 の延長）

   • Drive 証憑ファイルのハッシュ値を 35_wrk_receipt に記録する新列「証憑ハッシュ」を追加検討
   • Phase 2 以降の MAS-249（Attestation 検証）で本格展開

3. Secrets の Script Properties → Secret Manager 移行検討

   • 現状: GEMINI_API_KEY / CLAUDE_API_KEY は Script Properties
   • MAS-216 完了で API キー自体は廃止済（OAuth に移行）だが、将来追加する外部 API キーは Secret Manager を本線とする方針を確定

4. Drive 共有リンク URL の期限付き化（将来案件）

   • 外部共有リンクの期限切れ / 自動失効運用を検討（P マーク取得前に必須）

該当 CIS: CIS 3（データ保護）/ CIS 11（データ復旧）

Phase 5: インシデント対応（仕様書起票のみ・本 PR ではスコープ外の実装）

目的: セキュリティインシデント発生時の対応手順を事前に定義し、初動遅延を防ぐ。

成果物（本 PR で仕様書起票のみ、実装は別 PR）:

1. docs/_internal/biz/incident_runbook.md 新規

   • インシデント分類（秘密情報漏洩 / アカウント不正利用 / サービス停止 / データ改竄）
   • 各分類の初動手順（10 分以内 / 1 時間以内 / 1 日以内の 3 段階タイムライン）
   • 連絡フロー（代表者→顧問弁護士→税理士→警察・JPCERT/CC）
   • ログ保全手順（98_audit_log / Drive アクティビティログ / GCP 監査ログの収集方法）

2. docs/_internal/biz/incident_log.md 新規（ひな形）

   • 事案発生時に記録するテンプレート（日時・発見経路・影響範囲・対応記録・再発防止策）
   • failure_pattern #26 の事例を「過去のインシデントログ」として参考収録

該当 CIS: CIS 17（インシデント対応の管理）

Phase 6: ガバナンス（仕様書起票のみ）

目的: ポリシー文書を整備し、MAS-254（P マーク）・MAS-211（SOC 2 / ISO 27001）の外部監査に耐える体制を作る。

成果物（本 PR で仕様書起票のみ）:

1. docs/adr/0010-security-policy.md 新規（ADR-0010 として起票）

   • 組織セキュリティポリシー（対象範囲・責任者・違反時の措置）
   • CIS Controls v8 準拠宣言
   • 従業員教育方針（将来 Jr 入社時 / MAS-223 オンボーディングと連動）

2. docs/_internal/biz/data_classification.md 新規

   • データ分類（公開 / 社内 / 機密 / 極秘）とハンドリング基準
   • 顧客データ / 財務データ / 従業員人件費 / 役員情報の位置付け

3. セキュリティトレーニング計画

   • 年 1 回の振り返り（Sr + Jr）
   • P マーク取得時（MAS-254）に必須

該当 CIS: CIS 14（セキュリティ意識・教育）/ CIS 15（サービスプロバイダ管理）/ CIS 16（アプリケーションソフトウェアセキュリティ）

影響範囲

既存動作への影響

• MAS-234 は新規ガード機構の追加が主で、既存ビジネスロジック（仕訳・マート・RPA）には一切変更を加えない
• Phase 1 の CI 統合で、秘密情報を含む PR は自動ブロック（現状ブロック機構なし → 強化）
• Phase 2 の GCP IAM 再設計は MAS-215 実装済の延長。サービス中断なし

注意事項

1. CIS Controls v8 の Safeguard コード番号は IG1 / IG2 / IG3 でカテゴリ化されている。IG1 = 小規模組織向け基本（56 件）、IG2 = 中規模追加（74 件）、IG3 = 大規模追加（23 件）
2. FISC 安全対策基準の本文は有料 PDF のため、docs/arch/security_framework_mapping.md の FISC 欄には 条項番号と短い要約のみ（全文引用禁止・著作権）
3. 実装順序の原則: Phase 0（現状把握）→ Phase 1（基礎衛生）は即着手、Phase 5-6（インシデント対応・ガバナンス）は仕様書起票先行で実装は別 PR
4. failure_patterns #26 対策: Phase 1 の appsscript.json 変更監視は、oauthScopes 部分宣言による既存スコープ自動検出オフを検知する設計。CI + CODEOWNERS で二重防御
5. 外部監査対応の段階的深化: 本案件完了時点で CIS IG1 充足率 80%+ を目標。SOC 2 / ISO 27001（MAS-211）は Phase 4 GCP 移行後に別案件で本格対応
6. プライバシーマーク（MAS-254）との連動: P マーク取得のための JIS Q 15001 要求事項は、本案件のセキュリティ基盤上に個人情報保護管理体系を追加する形で実現

エッジケース

実データ検証

実装着手前に以下を MCP / コマンドで確認:

1. .gitignore の確認: creds.json / .env* / creds*.json / .clasp.dev.json / .clasp.prod.json が含まれていることを git check-ignore で検証
2. appsscript.json 現状の oauthScopes: 現状で明示宣言されていないことを確認（自動検出に委ねる構成）
3. Script Properties の登録キー: dev / prod 両環境で Env モジュールが参照する全キーが存在することを確認
4. GCP IAM 現状: gcloud projects get-iam-policy bizlp-gas-accounting-dev / -prod で現状のロール割当をスナップショット取得
5. Drive 共有状況: 代表スプレッドシートの getEditors() / getViewers() で現状の共有ユーザーを列挙、外部ドメインの存在を確認
6. 既存 CI 有無: .github/workflows/ の現状を確認（deploy.yml 存在、secret-scan は未整備のはず）

関連ドキュメント

人間が検討すべき事項

1. Phase 5-6 の実装タイミング: 仕様書起票先行の Phase 5-6 を本 PR に含めたが、実装は「採用開始前（D-90）」か「P マーク取得着手時（Phase 3-4 後半）」のどちらが適切か
2. Phase 3 異常操作検知の Gemini 採用妥当性: ルールベース検知で十分か、Gemini による判定が過剰か。料金とのバランス
3. CIS IG1 充足率目標: 80% / 90% / 100% のどれを目標にするか。IG2 の先行対応範囲も要決定
4. FISC 対応の深さ: 金融機関取引が確定した時点で条項レベルの対応を開始するか、今から先行整備するか
5. SOC 2 / ISO 27001（MAS-211）着手時期: Phase 4 GCP 移行完了後の Phase 5 で別案件化。今は参照のみ
6. 外部セキュリティ監査の依頼タイミング: P マーク（MAS-254）取得と同時に外部監査法人に依頼するか、先行してスポット監査を受けるか
7. Jr 入社時のセキュリティ教育カリキュラム: MAS-223 オンボーディングに Phase 6 のセキュリティトレーニングをどう組み込むか
8. インシデント初動連絡フロー: 顧問弁護士・税理士・警察・JPCERT/CC の連絡先を runbook に明記する場合、個人情報保護の観点で別ファイル管理か
9. マッピング台帳の半期更新運用: 基準改訂（CIS v9 等）の検出・追従タイミング（定期タスク化するか都度対応か）
10. コスト試算: Phase 1 CI（gitleaks）・Phase 3 Gemini 異常検知・Phase 4 暗号化監査の累計 GCP / API コスト見積

実装プロンプト（Claude Code 用）

本案件は段階実装のため、Phase ごとに独立した実装プロンプトを発行する。以下は Phase 0-1（即着手分） の統合プロンプト。

あなたはGAS会計システム(bizlp-gas-accounting)のシニア開発者です。
案件 MAS-234「セキュリティ基準準拠ロードマップ」の Phase 0-1 を実装してください。

## 実行前タスク
1. `docs/dev/dev_mas-234_security_roadmap.md` 全文を Read して方針を把握
2. `docs/arch/security_framework_mapping.md` の CIS Controls v8 × NIST CSF 2.0 マッピングを確認（Phase 0/1 該当 Safeguard）
3. `000_infra/004_utils.js` の `Utils.auditLog` / `Utils.getSheetByKey` / `Utils.logInfo` のシグネチャ確認
4. `800_ops/` 既存ファイル（809_backup_tool.js 等）を Read し、新規 800_ops ファイルの命名・構造を踏襲
5. `appsscript.json` の現状（oauthScopes が明示宣言されていないこと）を確認
6. `.gitignore` を Read し creds.json / .env* が列挙済みであること確認

## Phase 0: 監査スクリプト実装

### 修正対象ファイル
- `800_ops/814_audit_security_config.js`（新規）
- `000_infra/002_constants.js`（MENU_DEFINITION に「🛡️ セキュリティ構成監査」を追加）
- `100_config/101_sys_config.js`（99_security_audit シートは DDL 管理外のため変更なし、CLAUDE.md に追記）

### 実装内容
1. `800_ops/814_audit_security_config.js` に公開関数 `auditSecurityConfig()` を定義
2. `collectGasProjectInfo_()`: `ScriptApp.getScriptId()` / appsscript.json 内容 / 時間トリガー一覧を返す
3. `collectScriptProperties_()`: `PropertiesService.getScriptProperties().getKeys()` で キー名のみを取得（値はマスク）
4. `collectWorkspaceSnapshot_()`: Admin Reports API 経由で取得可能な設定（2FA 有効状況等）を取得（権限不足時は fallback）
5. `writeAuditReport_(sections)`: `99_security_audit` シートが未存在なら自動作成、`clearContents()` 後に `setValues` で書込
6. `CLAUDE.md`「DDL 管理外タブ」リストに `99_security_audit` を追記
7. `000_infra/002_constants.js` の MENU_DEFINITION「🔧 メンテナンス」カテゴリに 1 項目追加

## Phase 1: 基礎衛生（CI 統合）

### 修正対象ファイル
- `.github/workflows/secret-scan.yml`（新規）
- `.github/workflows/appsscript-json-guard.yml`（新規）
- `.github/CODEOWNERS`（既存拡張、appsscript.json を @Sr に）
- `.gitignore`（必要に応じて追記）

### 実装内容
1. `secret-scan.yml`: GitHub Actions で `gitleaks` を PR 時に実行、検出時に PR を fail させる
2. `appsscript-json-guard.yml`: `appsscript.json` 変更を含む PR で警告コメントを自動投稿、oauthScopes 変更時は特記
3. `CODEOWNERS` に `appsscript.json @Sr` `000_infra/ @Sr` `100_config/ @Sr` を追加
4. `.gitignore` の現状確認、不足があれば `creds*.json` / `.env*` / `.clasp.*.json` を追記

## 制約
- Phase 0 の監査スクリプトは**読取専用**。一切の変更を加えない（LockService 不要、冪等性は clearContents で担保）
- `appsscript.json` の oauthScopes には**絶対に触らない**（failure_patterns #26）
- 新規関数の命名は 000_infra / 800_ops の既存命名を Read で裏取り（failure_patterns #18-#20）
- Phase 1 の CI は既存 `deploy.yml` と衝突しないことを確認
- CODEOWNERS の変更は最小限（過剰な Sr 承認要求で Jr 作業が停滞しないよう）

## エッジケース
仕様書 §エッジケース E01-E10 を踏襲:
- E01: 権限不足時の部分レポート
- E02: gitleaks false positive → `.gitleaksignore` で除外
- E03: oauthScopes 正当追加時の CODEOWNERS ガード
- E04: 外部共有ホワイトリスト

## 実データ検証
- `.gitignore` に creds.json / .env* が含まれることを `git check-ignore creds.json` で確認
- appsscript.json 現状で oauthScopes 未宣言であることを確認
- `git log --all --pretty=format:%s | grep -i "creds\|secret"` で過去の誤コミット履歴がないこと確認

## 動作確認
1. `npm run push:dev` で Phase 0 スクリプトを dev へ
2. GAS エディタで `auditSecurityConfig()` を手動実行、`99_security_audit` にレポート出力されることを確認
3. テスト用に `creds.test.json` を含む PR を作成し、gitleaks が失敗することを確認
4. `appsscript.json` を変更する PR で警告コメントが自動投稿されることを確認
5. CODEOWNERS 指定ファイル編集時に Sr レビュー要求が自動付与されることを確認

### 拡張思考の使用状況
| フェーズ | 拡張思考 | 備考 |
|---|:---:|---|
| Phase 1 調査 | あり | Admin Reports API の戻り値・権限要件 |
| Phase 2 実装 | なし | 既存パターン（bash / yaml / js）の踏襲 |

推奨実行モデル

変更履歴

仕様書作成プロンプト

ユーザーがセキュリティインシデント予防のため、確立された基準に準拠した段階的実装を進めたい。以下の仕様書・マッピング台帳を起票してほしい。

## 背景

- システム: GAS ベースの会計 ERP (Google Workspace / DocAI / Vertex AI 連携)
- 扱うデータ: 財務諸表、請求書、領収書、取引先マスタ、従業員人件費
- 既発生インシデント: failure pattern #26 (OAuth スコープ崩壊)
- 将来要件: 投資家アピール、顧客 (金融機関含む) の監査対応
- 日本固有要件: 電帳法 (I-08 で対応中)、プライバシーマーク取得 (DS-09 既登録)

## 作成する成果物

### 1. docs/arch/security_framework_mapping.md — 基準マッピング台帳 (最重要)

CIS Controls v8 を骨格に、各 Safeguard を以下のフォーマットで一覧化:

| CIS# | Control / Safeguard | IG | 現状 | 対応案件 ID | NIST CSF 2.0 | ISO 27001 Annex A | FISC 統制基準 | 備考 |

全 18 Controls × 56 Safeguards (IG1) を最低限網羅。IG2 の安全対策も先行リストアップ可。

### 2. docs/dev/dev_mas-234_security_roadmap.md — N-58 案件仕様書

Phase 0-6 の段階的ロードマップ:
- Phase 0: 現状把握 (CIS 1/2/3)
- Phase 1: 基礎衛生 (CIS 3/4/5/6) - creds/.env 誤コミット防止 CI、Script Properties 必須項目チェック
- Phase 2: アクセス管理 (CIS 5/6) - Drive 権限監査、GCP SA 最小権限化
- Phase 3: 監査・ログ (CIS 8) - 監査ログ不可侵化 (N-37)、異常操作検知
- Phase 4: データ保護 (CIS 3/11) - 暗号化確認、証憑改竄防止
- Phase 5: インシデント対応 (CIS 17) - Runbook、Incident Log
- Phase 6: ガバナンス (CIS 14/15/16) - ポリシー文書化、ADR 整備

### 3. TODO_future.md の更新

- N-58 を §3 に追加
- Phase 別内訳テーブルに N-58 を追加

### 4. docs/_config.json の nav 配列更新

- docs/arch/security_framework_mapping.md
- docs/dev/dev_mas-234_security_roadmap.md

## 参考情報

採用基準の優先順位:
1. CIS Controls v8 — 骨格 (IG1 → IG2)
2. NIST CSF 2.0 — 俯瞰・戦略コミュニケーション
3. ISO/IEC 27001 Annex A — 将来の ISMS 認証視野
4. FISC 安全対策基準 第11版 — 金融機関対応時の参考情報
5. 電帳法 — 日本固有の法的要件 (I-08 で対応中)
6. プライバシーマーク — DS-09 で別途対応

除外: PCI DSS / HIPAA / GDPR