engineering-security-engineer

セキュリティエンジニアリングガイド

概要

このガイドでは、アプリケーションセキュリティ、インフラストラクチャの強化、脅威モデリング、脆弱性管理、セキュリティ運用について説明します。認証システムの設計、セキュリティ上の問題に関するコードレビュー、CI/CD でのセキュリティスキャンの設定、インシデント対応、シークレット管理、セキュリティフレームワークへの準拠に活用してください。

最初の10分間

• 修正案を提案する前に、攻撃対象領域を把握します。公開ルート、認証のエントリーポイント、管理者用パス、ファイルのアップロード／ダウンロードの流れ、サードパーティのコールバック、シークレットの読み込み経路を確認してください。
• 同梱のスクリプトは、レビュー対象のリポジトリではなく、まずスキルディレクトリから実行します。engineering-security-engineer/scripts/scan_secrets.sh と engineering-security-engineer/scripts/audit_auth_surface.py を使用してください。
• 大規模なモバイル／Web リポジトリでは、まず src、app、server、api、config、scripts など、重要度の高いディレクトリから確認します。必要な場合にのみ、リポジトリ全体をスキャンしてください。
• まず scripts/scan_secrets.sh を使用します。シークレットの露出が確認された場合、優先順位は直ちに変わります。
• 次に scripts/audit_auth_surface.py を使用して、ログインや認可の変更をレビューする前に、認証関連ファイルとセッション／トークンのパターンを一覧化します。
• タスクで最もリスクの高い信頼境界を特定します。ブラウザーから API、API からサービス、サービスからデータベース、または CI からクラウドのいずれかです。

拒否またはエスカレーション

• 認可チェック、入力検証、監査ログを「後で」として省略するセキュリティ上重要な変更は、承認を拒否してください。
• 認証情報の露出、本番環境での安全でない直接オブジェクト参照、侵害の疑いがタスクに含まれる場合は、直ちにエスカレーションしてください。
• 具体的な不具合と、最も限定的で安全な例外を記録せずに、CSP、CORS、Cookie の設定を弱めることを提案してはいけません。
• 要求された解決策が、システム内ですでに示されている法的義務やコンプライアンス上の義務に反する場合は、エスカレーションしてください。

脅威モデリング

脅威モデリングを行うタイミング

• ユーザーデータ、認証、認可、支払い、ファイルアップロードを扱う新機能を構築する前。
• 新しい外部依存関係、サードパーティ連携、API エンドポイントを追加するとき。
• データフロー（新しいデータベース、キャッシュ、キュー）やアクセスパターンを変更するとき。
• PII、金融データ、医療データを扱うシステムについて、既存の脅威モデルを四半期ごとにレビューするとき。

STRIDE フレームワーク

システム内のすべてのコンポーネントについて、以下を評価します。

• なりすまし（Spoofing）：攻撃者が正規のユーザーやサービスになりすませる可能性はありますか？対策：強固な認証（MFA、相互 TLS、ローテーションする API キー）。
• 改ざん（Tampering）：転送中または保存中のデータが変更される可能性はありますか？対策：転送には TLS 1.2 以降、保存には AES-256／KMS、整合性検証には HMAC 署名を使用します。
• 否認（Repudiation）：ユーザーが操作の実行を否認できる可能性はありますか？対策：タイムスタンプ、ユーザー ID、操作、IP アドレスを含む改変不可能な監査ログを使用します。アプリケーションが変更できない別のログストアに送信してください。
• 情報漏えい（Information Disclosure）：ログ、エラーメッセージ、API レスポンス、サイドチャネルを通じて機密データが漏れる可能性はありますか？対策：ログから PII を除去し、クライアントには汎用的なエラーメッセージを返し、シークレットの比較には一定時間比較を使用します。
• サービス拒否（Denial of Service）：システムが過負荷になる可能性はありますか？対策：レート制限、リクエストサイズ制限、タイムアウトの適用、コスト上限を設けたオートスケーリングを使用します。
• 権限昇格（Elevation of Privilege）：ユーザーが認可されていないアクセス権を得る可能性はありますか？対策：すべてのレイヤーで RBAC／ABAC を適用し、最小権限の原則に従い、すべての信頼境界で入力を検証します。

DREAD リスクスコアリング

特定した各脅威を次の項目で 1〜10 点で評価します。

• Damage（損害）：悪用された場合、被害はどの程度深刻ですか？（10 = データの全面的な漏えい、1 = 外観上の問題）
• Reproducibility（再現性）：どの程度容易に再現できますか？（10 = 毎回再現可能、1 = まれな条件が必要）
• Exploitability（悪用可能性）：どの程度のスキルやツールが必要ですか？（10 = スクリプトキディ、1 = 国家レベルの攻撃者）
• Affected users（影響を受けるユーザー）：何人のユーザーが影響を受けますか？（10 = すべてのユーザー、1 = 1 人のユーザー）
• Discoverability（発見可能性）：どの程度容易に発見できますか？（10 = 公開されている、1 = 内部関係者のアクセスが必要）

平均スコアで優先度を決定します。7 超 = Critical（リリース前に修正）、5〜7 = High（スプリント内に修正）、3〜5 = Medium（四半期内に修正）、3 未満 = Low（バックログに追加）。

OWASP Top 10 の判断基準

A01：アクセス制御の不備

• すべての API エンドポイントで、認証と認可の両方を確認する必要があります。ゲートウェイでの認証だけでは不十分です。サービス内でも再確認してください。
• デフォルト拒否を採用します。明示的な権限付与がない場合、リクエストは拒否されます。
• BOLA（Broken Object-Level Authorization）のテストを行います。他のユーザーに属する ID を指定してリソースをリクエストしてください。必ず 403 または 404 を返し、他のユーザーのデータは決して返さないようにします。
• BFLA（Broken Function-Level Authorization）のテストを行います。一般ユーザーのトークンで管理者用エンドポイントを呼び出してください。必ず 403 を返す必要があります。
• すべてのエンドポイントにレート制限を実装します。デフォルトは 100 req/min、認証エンドポイントは 10 req/min、パスワードリセットは 5 req/min です。

A02：暗号化の失敗

• パスワードのハッシュ化には bcrypt（コスト係数 12 以上）または Argon2id を使用します。パスワードに MD5、SHA-1、SHA-256 を決して使用しないでください。
• 保存時のすべての PII を AES-256-GCM で暗号化するか、プロバイダー管理の KMS（AWS KMS、GCP KMS）を使用します。暗号化キーを暗号化データと一緒に保存しないでください。
• すべての接続で TLS 1.2 以上を強制します。TLS 1.0/1.1 は拒否してください。max-age=31536000; includeSubDomains; preload を指定した HSTS ヘッダーを使用します。
• API のレスポンスやエラーメッセージに、シークレット、トークン、パスワード、クレジットカード番号の全桁を記録したり返したりしないでください。下 4 桁だけを表示してください。

A03：インジェクション

• すべてのデータベース操作で、必ずパラメーター化クエリのみを使用します。ユーザー入力との文字列連結によって SQL/NoSQL クエリを構築しないでください。
• API の境界で、すべてのユーザー入力を検証してサニタイズします。単なる文字列の解析ではなく、厳密な型を使うスキーマバリデーター（Zod、Joi、Pydantic）を使用してください。
• HTML 出力には、デフォルトで自動エスケープが有効なテンプレートエンジン（React JSX、autoescape を有効にした Jinja2、Go html/template）を使用します。
• OS コマンドの実行には、言語標準のライブラリを使用します（exec/system は使用しないでください）。シェルの実行を避けられない場合、許可する文字にはブロックリストではなく許可リストを使用してください。

A04：安全でない設計

• 多層防御を適用します。認証 + 認可 + 入力検証 + 出力エンコーディング + 暗号化 + ロギングを実施してください。単一の層だけでは不十分です。
• ユーザーごとのリソース消費を制限します。最大ファイルアップロードサイズ（デフォルト 10MB）、最大リクエストボディサイズ（デフォルト 1MB）、最大クエリ結果数（デフォルト 100、最大 1000）を設定してください。
• 15 分以内にログインに 5 回失敗した場合、アカウントロックを実装します。UX を向上させるため、完全なロックではなく、段階的な遅延（1 秒、2 秒、4 秒、8 秒、16 秒）を使用してください。

A05：セキュリティ設定の不備

• 本番環境では、ディレクトリ一覧表示、デバッグエンドポイント、スタックトレースを無効にします。次のコマンドで確認してください：curl -v https://yourapp.com/debug、curl https://yourapp.com/.env。
• すべてのレスポンスにセキュリティヘッダーを設定します。

  Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; connect-src 'self' https://api.yourapp.com; frame-ancestors 'none'
  X-Content-Type-Options: nosniff
  X-Frame-Options: DENY
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=()
  

• デプロイ前に、デフォルトの認証情報、サンプルデータ、未使用のエンドポイントを削除します。scripts/check_security_headers.sh でスキャンしてください。

A06：脆弱で古いコンポーネント

• CI で npm audit / pip audit / bundle audit を実行します。重大または高レベルの脆弱性が見つかった場合は、ビルドを失敗させてください。
• 依存関係を毎月更新します。セキュリティパッチは、アドバイザリーの公開から 48 時間以内に適用してください。
• 新しい依存関係を追加する前に、最終コミット日（12 か月未満）、ダウンロード数（JS は週 1k 超、Python は週 500 超）、未修正の CVE（重大なものはゼロ）、メンテナンス状況（活動中のメンテナーが 1 人以上）を確認します。
• ロックファイルで依存関係のバージョンを正確に固定します。テスト実行を伴うアップグレード PR を自動作成するため、Renovate または Dependabot を使用してください。

A07: 識別および認証の不備

• すべての管理者アカウント、および PII や財務データにアクセスできるアカウントには MFA を必須にします。
• 有効期間の短いアクセストークン（15 分の JWT）を発行し、不透明なリフレッシュトークンをサーバー側に保存します。リフレッシュトークンはローテーション可能かつ失効可能でなければなりません。
• パスワード要件を実装します。最小文字数は 8 文字とし、漏えいしたパスワードのリスト（Have I Been Pwned API またはローカルの k-匿名性チェック）と照合し、最大文字数を 128 文字未満に設定してはなりません。
• セッション管理では、ログイン後にセッション ID を再生成し、すべての Cookie に Secure、HttpOnly、SameSite=Strict を設定します。機密性の高いアプリケーションでは、アイドル状態のセッションを 30 分後に期限切れにします。

A08: ソフトウェアおよびデータの整合性の不備

• すべての CI/CD アーティファクトの整合性を検証します。Docker イメージに署名し（cosign/Notary）、ダウンロードしたバイナリのチェックサムを検証し、依存関係の整合性にはロックファイルを使用します。
• CI/CD アクションのバージョンはタグではなく SHA に固定します。uses: actions/checkout@a81bbbf を使用し、uses: actions/checkout@v4 は使用しません。タグは変更できますが、SHA は変更できません。
• CDN から読み込むサードパーティスクリプトには Subresource Integrity（SRI）を実装します。

A09: セキュリティログおよび監視の不備

• 次のすべてをログに記録します。認証イベント（ログイン、ログアウト、失敗した試行、MFA チャレンジ）、認可の失敗（403）、入力検証の失敗（400）、管理者の操作、および PII へのデータアクセス。
• 次の情報は決してログに記録しないでください。パスワード、トークン、セッション ID、クレジットカード番号全体、その他の秘密情報。機密フィールドはマスキングします。
• ログは、アプリケーションとは別の一元管理された追記専用システム（CloudWatch、Datadog、Splunk）に送信します。コンプライアンスのため、保持期間はホットストレージで 90 日、コールドストレージで 1 年とします。
• 次の場合にアラートを発生させます。同じ IP から 5 分間に 10 回を超えるログイン失敗があった場合、営業時間外に管理者の操作があった場合、一括 PII エクスポートへのアクセスがあった場合、および 5xx エラー率が 1% を超えた場合。

A10: サーバーサイドリクエストフォージェリ（SSRF）

• ユーザーから提供されたすべての URL を検証し、許可リストを使用します。内部 IP 範囲へのリクエストをブロックします。10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、127.0.0.0/8、169.254.169.254（クラウドメタデータ）。
• アプリケーションで外部 URL の取得が必要な場合は、専用の HTTP クライアントを使用し、DNS 解決先をパブリック IP に制限し、リクエストタイムアウト（5 秒）とレスポンスサイズ上限（10MB）を設定します。
• クラウド環境では、IMDS v1 を無効にし、IMDSv2（AWS）または同等の方式を必須にします。メタデータエンドポイントは、SSRF を悪用して権限を拡大する最も一般的な経路です。

シークレット管理

ルール

• シークレットをソース管理にコミットしてはなりません。.env ファイルには .gitignore を使用し、CI で git-secrets または trufflehog を実行して、誤ったコミットを検出します。
• シークレットは HashiCorp Vault、AWS Secrets Manager、GCP Secret Manager、または Azure Key Vault に保存します。環境変数またはサイドカーを通じて、実行時に注入します。
• スケジュールに従ってシークレットをローテーションします。API キーとデータベースパスワードは 90 日ごと、暗号化キーは 365 日ごとに更新します。ローテーションは自動化してください。手動でのローテーションは見落とされます。
• シークレットが漏えいした場合（git へのコミット、ログへの記録、または権限のない相手への送信など）は、ただちに失効させてローテーションし、漏えい期間中のアクセスログを監査します。PII にアクセスできた場合は、影響を受けたユーザーに通知します。

CI でのシークレット検出

• すべての PR で trufflehog または gitleaks を実行します。検出結果があればマージをブロックします。
• Docker イメージに埋め込まれたシークレットをスキャンします。docker history --no-trunc <image> を実行し、シークレットを含む ENV/ARG がないか確認します。
• Terraform の状態ファイルにシークレットが含まれていないか確認します。すべてのシークレット変数に sensitive = true を使用します。状態は S3 に暗号化して保存し、アクセスを制限します。

サプライチェーンセキュリティ

• ロックファイル（package-lock.json、poetry.lock、go.sum）を使用し、整合性ハッシュを検証してください。
• GitHub Actions はタグではなくコミット SHA に固定してください。使用する前に、アクションのソースコードを確認してください。
• CI で SCA（ソフトウェア構成分析）を実行します。Snyk、Grype、または npm audit --audit-level=high を使用してください。重大または高リスクの検出結果がある場合は、マージをブロックしてください。
• Docker のベースイメージには、特定のバージョンタグ（latest ではなく）を使用し、ダイジェストを検証してください。また、セキュリティパッチを適用するため、毎月イメージを再ビルドしてください。
• 本番アプリケーションのソフトウェア部品表（SBOM）を維持してください。syft または trivy sbom で生成できます。

API セキュリティの判断ルール

• すべての API 呼び出しを認証してください。公開エンドポイントでも、レート制限と不正利用の検知が必要です。
• ユーザー向け API には OAuth 2.0 + PKCE を使用してください。サービス間通信には HMAC 署名付き API キーを使用してください。内部の高セキュリティサービスには相互 TLS を使用してください。
• リクエスト本文を厳格なスキーマで検証してください。不明なフィールドは拒否し（マスアサインメントを防止）、ペイロードの最大サイズを適用してください。
• 実装の詳細を漏らさない、一貫性のあるエラーレスポンスを返してください。{"error": "invalid_request", "message": "Validation failed"} のようにし、スタックトレースや SQL エラーは決して返さないでください。
• Webhook にはリクエスト署名を実装してください。共有シークレットを使用した HMAC-SHA256 を使用します。リプレイ攻撃を防ぐため、署名にタイムスタンプを含め、5 分以上前のものは拒否してください。

自己検証プロトコル

セキュリティ制御を実装した後、次の項目を検証してください。

• 認証：次の条件でテストしてください。トークンなし（401 を想定）、期限切れトークン（401 を想定）、有効なトークンだがロールが不正（403 を想定）、有効なトークンで正しいロール（200 を想定）。変更したエンドポイントだけでなく、すべてのエンドポイントをテストしてください。
• 入力検証：すべての入力フィールドに OWASP のテスト用ペイロードを送信してください。' OR '1'='1、<script>alert(1)</script>、../../../etc/passwd、; ls -la、{{7*7}}。すべて拒否するか、安全にエスケープする必要があります。
• ヘッダー：curl -I https://yourapp.com を実行し、すべてのセキュリティヘッダーが正しい値で設定されていることを確認してください。
• シークレット：リポジトリ全体を検索してください。git log --all -p | grep -iE '(password|secret|api.key|token).*=.*[A-Za-z0-9]{8,}'。実際のシークレットに一致するものがゼロであることを確認してください。
• 依存関係：npm audit / pip audit / trivy image を実行してください。重大または高リスクの脆弱性がゼロであることを確認してください。
• ログ記録：ログイン、ログイン失敗、認可失敗、データアクセスをそれぞれ実行してください。これら4つのイベントが、正しいフィールドとともにすべてログシステムに記録されることを確認してください。
• レート制限：レート制限対象のエンドポイントに、1 分以内に 200 件のリクエストを送信してください。設定されたしきい値で 429 レスポンスが返されることを確認してください。

障害からの復旧

• セキュリティ脆弱性が報告された場合：1 時間以内に DREAD で深刻度を評価します。重大（>7）：24 時間以内に修正し、影響を受けるユーザーに通知します。高（5-7）：7 日以内に修正します。中（3-5）：30 日以内に修正します。低（<3）：バックログに追加します。
• Git でシークレットが公開された場合：直ちに、（1）シークレットをローテーションし、（2）古いシークレットを失効させ、（3）公開期間中に不正使用がなかったかログを検索し、（4）git filter-branch または BFG を使って履歴から削除し、（5）強制プッシュします。データにアクセスされた可能性がある場合は、影響を受けるユーザーに通知します。
• DDoS を検出した場合：CDN レベルの DDoS 保護（Cloudflare Under Attack Mode、AWS Shield）を有効にします。レート制限のしきい値を引き上げます。攻撃元が特定の地域である場合は、ジオブロッキングを有効にします。インフラのスケールアップは最後の手段としてのみ行います。費用がかかり、攻撃者側も規模を拡大できるためです。
• 認証情報が侵害された場合：直ちに、（1）侵害されたアカウントを無効化し、（2）そのアカウントがアクセスできたすべてのシークレットをローテーションし、（3）侵害期間中のアカウントの操作について監査ログを確認し、（4）ユーザーに通知して、MFA の再登録を伴うパスワードリセットを必須にします。侵害されたアカウントがサービスアカウントの場合は、ラテラルムーブメントの兆候がないか、アクセス可能だったすべてのシステムも確認します。
• セキュリティスキャンの失敗でデプロイがブロックされた場合：スキャンを決して回避しないでください。検出結果を確認します。誤検知でなければ修正します。誤検知であれば、理由とレビュー日（最長 90 日後）を説明するコメントを付けて、明示的な抑制を追加します。スキャンツールが壊れている場合は、ツールを修正します。無効化してはいけません。

既存システムのセキュリティ監査

既存システムのセキュリティを評価する際は、次の手順に従います。

1. 攻撃対象領域をマッピングする（30 分）— 以下をすべて列挙します：公開エンドポイント、認証メカニズム、データストア、外部連携、ファイルのアップロード／ダウンロード機能、管理者インターフェース。
2. 認証を確認する（15 分）— トークンの発行、検証、失効はどのように行われていますか？MFA は利用できますか？セッションは適切に管理されていますか？5 つのエンドポイントで BOLA をテストします。
3. シークレットを確認する（15 分）— リポジトリで trufflehog を実行します。環境変数の管理方法を確認します。シークレットが Docker イメージ、ログ、Terraform の状態ファイルに含まれていないことを検証します。
4. 依存関係を確認する（10 分）— npm audit / pip audit / trivy を実行します。重大および高の検出件数を数えます。
5. ヘッダーを確認する（5 分）— 本番 URL に対して scripts/check_security_headers.sh を実行します。欠落しているヘッダーに印を付けます。
6. ログ記録を確認する（10 分）— 認証イベントはログに記録されていますか？ログは一元管理システムに送信されていますか？アプリケーションが自身のログを変更できますか？
7. データの取り扱いを確認する（10 分）— PII は保存時に暗号化されていますか？すべての通信に TLS が使われていますか？バックアップは暗号化されていますか？本番データにアクセスできるのは誰ですか？
8. 検出結果に優先順位を付ける— 各検出結果を DREAD で採点します。リスクスコア上位 5 件を、具体的な修正手順と作業量の見積もりとともに提示します。

成果物

• 信頼境界、想定される悪用経路、DREAD スコアに基づく上位リスクを列挙した脅威の概要。
• 優先度、悪用の前提条件、担当者を含む修正計画。
• 認可、シークレット、ヘッダー、依存関係、監査ログを対象とする検証チェックリスト。
• インシデント対応タスクの場合：タイムライン、封じ込め対応、ローテーション状況、フォローアップの検証手順。

コンプライアンス早見表

SOC 2

• アクセス制御：四半期ごとのアクセスレビューを伴う RBAC。誰が何にアクセスできるのか、またその理由を文書化します。
• 変更管理：すべての変更は、レビューを経てバージョン管理された PR を通じて行います。本番環境への直接アクセスは禁止します。
• 監視：1 年間の保持期間を設定した一元管理ログ。不正アクセスの試行時にアラートを発します。
• インシデント対応：手順を文書化し、毎年テストします。すべてのセキュリティインシデントについて事後分析を行います。

GDPR

• データインベントリ：収集するすべての個人識別情報（PII）、保存場所、収集する理由、保持期間を文書化します。
• 同意：処理を開始する前に明示的な同意を得ます。オプトアウトをオプトインと同じくらい簡単にできるようにします。
• 消去する権利：すべての保存場所からユーザーデータを削除するデータ削除パイプラインを実装します（保持期間内のバックアップも含みます）。
• データ侵害の通知：72 時間以内に監督機関へ通知します。影響を受けたユーザーには「不当な遅延なく」通知します。

HIPAA

• すべての保護対象保健情報（PHI）を保存時（AES-256）および転送時（TLS 1.2 以降）に暗号化します。例外は認められません。
• アクセス制御：必要最小限の原則を適用します。PHI へのすべてのアクセスについて、ユーザー、タイムスタンプ、目的を記録します。
• PHI を処理するすべてのベンダーと業務提携契約（BAA）を締結します。
• PHI にアクセスするすべての担当者を対象に、年次リスク評価とセキュリティトレーニングを実施します。

スクリプト

scripts/check_security_headers.sh

指定した URL の HTTP セキュリティヘッダーを確認します。Content-Security-Policy、X-Content-Type-Options、X-Frame-Options、Strict-Transport-Security、Referrer-Policy、Permissions-Policy をテストします。ヘッダーの欠落、設定不備、存在状況を評価付きで報告します。

scripts/check_security_headers.sh https://yourapp.com
scripts/check_security_headers.sh --json https://api.yourapp.com

scripts/scan_secrets.sh

ディレクトリまたは Git リポジトリをスキャンし、誤ってコミットされたシークレットを検出します。API キー、AWS 認証情報、秘密鍵、データベース接続文字列、JWT シークレット、一般的なトークンの割り当て、よくある認証情報のパターンを確認します。ノイズを減らすため、既定では www/、platforms/、Pods/、dist/、build/ などの生成物／ベンダーツリーをスキップします。

scripts/scan_secrets.sh .
scripts/scan_secrets.sh --git-history /path/to/repo
scripts/scan_secrets.sh --format json /path/to/project

scripts/audit_auth_surface.py

リポジトリをスキャンし、認証、セッション、トークン、Cookie、ミドルウェアに関する重点箇所を検出します。既定では www/、platforms/、Pods/、dist/、build/ などの生成物／ベンダーツリーをスキップします。ログインフロー、RBAC の変更、またはセッションセキュリティをレビューする前に使用してください。

scripts/audit_auth_surface.py .
scripts/audit_auth_surface.py /path/to/repo --top 20

参考資料

• 認証パターン -- JWT とリフレッシュトークンのフロー、OAuth 2.0 PKCE、セッション管理、MFA の実装、RBAC／ABAC モデル、API キー管理。
• セキュリティヘッダー -- 一般的なフレームワーク（React、Next.js、Express）向けの CSP 設定、HSTS の設定、セキュリティヘッダーのテスト。
• 脆弱性のパターン -- Node.js、Python、Go 向けの OWASP Top 10 のコード例（脆弱なバージョンと修正済みバージョン）および自動テストのパターン。
• インシデント対応 -- インシデント対応ランブック、重大度の分類、コミュニケーション用テンプレート、事後検証テンプレート、根本原因分析フレームワーク。
• コンプライアンスチェックリスト -- SOC 2、GDPR、HIPAA、PCI-DSS の実装チェックリストと証跡収集ガイド。