compliance-review

コンプライアンスレビュー

業界固有の規制要件に照らして、アプリケーションを評価します。このレビューでは、複雑なコンプライアンスフレームワークを、具体的でテスト可能な技術チェックに置き換え、ブラウザーを使ったテストで検証します。コンプライアンス違反は、高額な罰金、法的措置、事業機会の喪失につながる可能性があります。

使用する場面

次の場合に /compliance-review を使用します。

• 規制対象の業界（医療、金融、政府機関）向けのアプリケーションを構築するとき
• コンプライアンス監査（SOC 2、HIPAA、PCI-DSS）の準備をするとき
• 決済処理や医療データ機能を追加するとき
• GDPR の適用対象となる市場に事業を拡大するとき
• データの取り扱いに影響するインフラストラクチャやアーキテクチャの変更後

参照する標準

• HIPAA — 医療保険の携行性と責任に関する法律（技術的保護措置 §164.312）
• SOC 2 — サービス組織統制（トラストサービス基準）
• PCI-DSS v4.0 — 決済カード業界データセキュリティ基準
• GDPR — 一般データ保護規則（技術的措置）

フェーズの概要

Phase 1: EDUCATE   → Compliance context and applicable frameworks
Phase 2: SCOPE     → Determine which frameworks apply, identify regulated data
Phase 3: ANALYZE   → Browser-based checks against framework requirements
Phase 4: REPORT    → Findings mapped to specific regulatory sections
Phase 5: REMEDIATE → Fix guidance + YAML regression tests for continuous compliance

---

フェーズ 1：理解

重要な理由： HIPAA 違反：違反カテゴリーごとに年間最大 190 万ドル。PCI-DSS 違反：罰金として月額 5,000～100,000 ドルに加え、侵害に対する賠償責任。SOC 2 の不備：認証を求める大企業の顧客を失う可能性があります。GDPR：全世界の年間売上高の最大 4％。これらは机上の話ではありません。規制の執行はすでに行われており、強化されています。

コンプライアンスフレームワークは膨大な文書です。このレビューでは、Web アプリケーションでテスト可能な技術要件を抽出します。人によるプロセスの確認が必要な組織的・手続き的要件（ポリシー、トレーニング、ベンダー管理）は対象外です。

---

フェーズ 2：対象範囲

該当するフレームワークを特定する

1. コードベースから自動検出する：

   • 医療データの取り扱い（HIPAA の指標：HL7、FHIR、患者記録、PHI の参照）
   • 決済処理（PCI-DSS の指標：Stripe、Braintree、クレジットカード入力欄、決済フォーム）
   • EU ユーザーデータ（GDPR の指標：同意バナー、Cookie 通知、EU でのデプロイ）
   • 監査ログ（SOC 2 の指標：監査証跡、イベントログ、アクセスログ）

2. ユーザーに確認する：

   • 該当するフレームワークはどれですか？（自動検出した内容を確認）
     • HIPAA — 医療／保護対象医療情報
     • SOC 2 — エンタープライズ向け SaaS／顧客データ
     • PCI-DSS — 決済カードデータ
     • GDPR — EU の個人データ
     • その他（指定してください）
   • 対象 URL：アプリはどこで実行されていますか？
   • 規制対象のデータ種別：アプリはどのような規制対象データを扱いますか？（自動検出）
   • テスト用認証情報：テストに使用する、規制対象データへのアクセス権があるアカウント

3. 規制対象データのフローをマッピングする：

   • 規制対象データがシステムに入る場所（フォーム、API、インポート）
   • データが表示される場所（ダッシュボード、レポート、エクスポート）
   • クライアント側にデータが保存される場所（該当する場合）
   • データが送信される場所（API エンドポイント、サードパーティーサービス）

---

フェーズ 3：分析

フェーズ 2 のスコープ設定に基づき、該当するセクションのみを実行します。record_evidence: true を指定して new_session でブラウザーセッションを開始します。

HIPAA 技術的保護措置（HIP）

適用対象：アプリケーションが保護対象保健情報（PHI）を扱う場合。

チェック ID	チェック項目	HIPAA セクション	方法
HIP-01	認証なしで PHI が表示されない	§164.312(d)	認証なしで PHI のページにアクセスし、401 またはリダイレクトを確認する
HIP-02	非アクティブ状態が続くとセッションが自動タイムアウトする	§164.312(a)(2)(iii)	アイドル時間を待ち、セッションが期限切れになることを確認する
HIP-03	PHI が URL パラメーターに含まれない	§164.312(e)(1)	PHI のページに移動し、URL を確認する
HIP-04	PHI がブラウザーのコンソール／ログに含まれない	§164.312(b)	get_browser_console_logs で PHI のパターンを確認する
HIP-05	PHI がブラウザーのストレージにキャッシュされない	§164.312(a)(2)(iv)	localStorage と sessionStorage に PHI がないか確認する
HIP-06	PHI は HTTPS 経由でのみ送信される	§164.312(e)(1)	PHI に関するすべての API 呼び出しで HTTPS が使われていることを確認する
HIP-07	PHI へのアクセスが監査証跡に記録される	§164.312(b)	PHI にアクセスし、監査ログのエントリーがあることを確認する
HIP-08	PHI へのアクセスがロールベースで制御される	§164.312(a)(1)	異なるユーザーロールで PHI へのアクセスをテストする
HIP-09	PHI の表示に最小限必要な原則が適用される	§164.502(b)	UI に必要な PHI フィールドのみが表示されているか確認する
HIP-10	緊急アクセス手順が用意されている	§164.312(a)(2)(ii)	ブレークグラスまたは緊急アクセス用 UI があるか確認する
HIP-11	エラーメッセージに PHI が含まれない	§164.312(b)	PHI のページでエラーを発生させ、メッセージを確認する
HIP-12	ログアウトによって PHI へのアクセスが完全に終了する	§164.312(a)(2)(iii)	ログアウトしてから戻るボタンを押し、PHI が表示されないことを確認する

ブラウザーでの検証： PHI を含むページに移動します。アクセス制御をテストします。URL、ストレージ、コンソールに PHI が含まれていないか確認します。待機してセッションタイムアウトをテストします。ログアウトが完全に機能することをテストします。

SOC 2 信頼サービス規準（SOC）

適用対象：顧客データを扱うエンタープライズ SaaS の場合。

チェック ID	チェック項目	SOC 2 規準	方法
SOC-01	すべてのデータアクセスで認証が必須	CC6.1	認証なしでデータのページにアクセスする
SOC-02	強固なパスワード要件が適用される	CC6.1	脆弱なパスワードを使ってサインアップ／パスワード変更をテストする
SOC-03	ユーザーアカウントで MFA を利用できる	CC6.1	アカウントのセキュリティ設定に MFA のオプションがあるか確認する
SOC-04	セッション管理が安全である	CC6.1	Cookie のフラグ、タイムアウト、ログアウト時の動作を確認する
SOC-05	データが転送中に暗号化される	CC6.7	HTTPS が全体で使われていることを確認し、混在コンテンツがないか調べる
SOC-06	アクセスが記録される（監査証跡）	CC7.2	操作を実行し、監査ログのエントリーを確認する
SOC-07	ログイン失敗の試行が監視される	CC7.2	ログインを複数回失敗させ、アラート／ロックアウトを確認する
SOC-08	ユーザー権限がロールベースである	CC6.3	異なるロールをテストし、適切なアクセスが許可されることを確認する
SOC-09	データを削除できる	CC6.5	アカウント／データの削除機能をテストする
SOC-10	システムステータスページまたはヘルスエンドポイントがある	CC7.1	ステータスページまたは /health エンドポイントがあるか確認する
SOC-11	エラー処理で内部情報が漏えいしない	CC7.4	エラーを発生させ、スタックトレースが表示されないことを確認する
SOC-12	バージョン管理から変更管理が確認できる	CC8.1	バージョン情報と変更履歴を確認する

ブラウザーでの検証： 認証境界、パスワードポリシー、MFA フロー、ロールベースのアクセス、監査ログの可視性をテストします。

PCI-DSS v4.0（PCI）

該当するケース：アプリケーションがカード会員データを処理、保存、または送信する場合。

Check ID	Check	PCI-DSS Req	Method
PCI-01	クレジットカード番号が全桁表示されない	3.4	保存済みカードを表示し、マスキングを確認します（下4桁のみ表示）
PCI-02	CVVが認証後に保存も表示もされない	3.3.2	ストレージとAPIレスポンスでCVVを確認します
PCI-03	決済フォームでHTTPSを使用する	4.1	決済ページのURLとすべてのリソースを確認します
PCI-04	決済フォームが準拠したiframe／リダイレクト上にある	SAQ A	Stripe Elements、PayPal、または類似のサービスを使用しているか確認します
PCI-05	URLパラメーターにカード会員データが含まれない	4.2	決済フロー中のURLを確認します
PCI-06	クライアントストレージにカード会員データが含まれない	3.2	localStorage、sessionStorage、cookiesを確認します
PCI-07	コンソールログにカード会員データが含まれない	3.2	決済中にget_browser_console_logsを確認します
PCI-08	決済フォームでカードフィールドのオートコンプリートを防止する	ベストプラクティス	機密フィールドにautocomplete="off"が設定されているか確認します
PCI-09	決済管理に強力な認証を適用する	8.3	管理者／決済管理に強力な認証が必要か確認します
PCI-10	カード会員データへのアクセスをロールで制限する	7.1	管理者以外のユーザーで決済データへのアクセスをテストします
PCI-11	決済エラーメッセージでカード情報を明かさない	3.2	決済エラーを発生させ、メッセージを確認します
PCI-12	CSPで決済ページ上の未承認スクリプトを防止する	6.4.3	特に決済ページのCSPヘッダーを確認します

ブラウザーでの検証： 決済フローをたどります。カード表示のマスキングを確認します。ストレージとコンソールを調べ、カード会員データがないことを確認します。決済フォームがiframe／ホスト型であることを確認します（SAQ A準拠）。

GDPRの技術要件（GDPR）

該当するケース：アプリケーションがEUの個人データを扱う場合。（注：プライバシーに特化したチェックは/privacy-reviewにあります。このセクションではGDPRの技術／コンプライアンス上の義務を扱います。）

Check ID	Check	GDPR Article	Method
GDPR-01	データ処理前に同意を取得する	Art. 6, 7	ページを読み込み、同意前に処理が行われるか確認します
GDPR-02	プライバシーポリシーにアクセスでき、最新である	Art. 13, 14	プライバシーポリシーのページを見つけて確認します
GDPR-03	データ主体のアクセス要求を行う手段がある	Art. 15	データのエクスポート／ダウンロード機能を探します
GDPR-04	消去権を実装している	Art. 17	アカウント削除機能を見つけてテストします
GDPR-05	データポータビリティ（標準形式でのエクスポート）	Art. 20	データエクスポートをテストし、形式（JSON/CSV）を確認します
GDPR-06	同意の撤回が、同意するのと同じくらい簡単である	Art. 7(3)	同意する場合と撤回する場合のUXを比較します
GDPR-07	未成年者の年齢確認（該当する場合）	Art. 8	年齢確認ゲートまたは保護者の同意があるか確認します
GDPR-08	データ処理記録にアクセスできる	Art. 30	処理活動の文書があるか確認します
GDPR-09	データ侵害の通知手段がある	Art. 33, 34	インシデント対応の文書を確認します
GDPR-10	国境を越えた移転の保護措置	Art. 44-49	サードパーティサービスがどこでホストされているか確認します

ブラウザーでの検証： 同意フロー、データエクスポート、アカウント削除、プライバシーポリシーへのアクセスをテストします。国境を越えた移転に関する懸念について、サードパーティスクリプトの配信元を確認します。

---

フェーズ4：レポート

構造化されたレポートをshiplight/reports/compliance-review-{date}.mdに保存します。

# Compliance Review Report
**Date:** {date}
**URL:** {url}
**Frameworks evaluated:** {HIPAA, SOC 2, PCI-DSS, GDPR}
**Regulated data types:** {PHI, cardholder data, EU personal data}

## Overall Compliance Score: {X}/10 | Confidence: {X}%

## Framework Scores
| Framework | Score | Pass | Fail | N/A | Critical Gaps |
|-----------|-------|------|------|-----|---------------|
| HIPAA | 6/10 | 8 | 3 | 1 | Session timeout, PHI in URL |
| SOC 2 | 7/10 | 9 | 2 | 1 | No MFA, weak audit trail |
| PCI-DSS | 8/10 | 10 | 1 | 1 | Card data in console |
| GDPR | 5/10 | 5 | 4 | 1 | Consent, data export, erasure |

## Compliance Status by Check
(Full table of all checks with PASS/FAIL/N-A status, evidence, and confidence)

## Critical Non-Compliance Items
(Findings that could result in regulatory action, ordered by risk)

## Audit Preparation Checklist
- [ ] Fix all CRITICAL findings
- [ ] Fix all HIGH findings
- [ ] Document accepted risks for MEDIUM findings
- [ ] Run YAML regression tests before audit date
- [ ] Prepare evidence documentation from this report

信頼度スコア

• 90-100%：ブラウザーで検証済みで、コンプライアンス違反を確認（例：認証なしでPHIを閲覧できる、コンソールにカード番号が表示される）
• 70-89%：調査から強い証拠が得られている（例：ヘッダーがない、タイムアウト動作がない）
• 50-69%：コードパターンに基づくアーキテクチャ上の懸念（例：監査ログが不完全な可能性がある）
• 50%未満：報告しないでください — コンプライアンス上の指摘は、裏付けが必要です

---

フェーズ5：修正

1. 修正ガイダンス（例）

#### HIP-02: No session auto-timeout
**Regulation:** HIPAA §164.312(a)(2)(iii) — Automatic logoff
**Risk:** Unattended sessions with PHI visible
**Current:** Sessions persist indefinitely
**Fix:** Implement idle timeout (HIPAA recommends ≤15 minutes for PHI access)
- Add client-side idle detection (mouse, keyboard events)
- Server-side session expiry as backup
- Show warning dialog at 12 minutes
- Auto-logout and clear screen at 15 minutes

2. YAML回帰テスト

- name: hip-02-session-auto-timeout
  description: Verify session auto-timeout for HIPAA compliance
  severity: critical
  standard: HIPAA-164.312(a)(2)(iii)
  steps:
    - URL: /login
    - intent: Log in with test credentials
      action: fill
      locator: "getByLabel('Email')"
      value: "[email protected]"
    - intent: Enter password
      action: fill
      locator: "getByLabel('Password')"
      value: "testpass123"
    - intent: Submit login form
      action: click
      locator: "getByRole('button', { name: 'Sign in' })"
    - WAIT_UNTIL: Dashboard with PHI is visible
      timeout_seconds: 15
    - VERIFY: Session timeout warning appears after inactivity period
      timeout_seconds: 900
    - VERIFY: User is automatically logged out after timeout expires
      timeout_seconds: 300

すべてのYAMLテストをshiplight/tests/compliance-review.test.yamlに保存します。

---

深度レベル

• --quick：重要なチェックのみ — 認証境界とデータ露出。約3分。
• default：該当するフレームワークをすべて確認します。約10～15分。
• --thorough：すべてのチェック＋複数ロールのテスト＋エッジケース＋ドキュメントのレビュー。約25～40分。

ヒント

• フレームワークに特化したコンプライアンスレビューを実行します：「HIPAA チェックのみ実行」
• コンプライアンスには証拠が必要です — record_evidence: true と generate_html_report を使用して監査用ドキュメントを作成してください
• このレビューの YAML 回帰テストは、継続的なコンプライアンス監視に役立ちます
• このレビューの対象は技術要件のみです — 組織要件（ポリシー、トレーニング）については人によるレビューが必要です
• プライバシー固有の懸念事項については、/privacy-review を併用してください
• セキュリティ固有の懸念事項については、/security-review を併用してください
• close_session でセッションを終了し、証拠のために generate_html_report を使用してください