セキュリティインシデント対応計画
QR Branding API — GDPR第33〜34条
| 項目 | 内容 |
|---|---|
| 管理者 | QR Branding (Quartzon) |
| 日付 | 2026-03-08 |
| バージョン | 1.0 |
| 次回の見直し | 2026-09-08 |
1. 目的
GDPR第33条（監督機関への通知）および第34条（データ主体への連絡）の要件に従い、個人データに影響するセキュリティ侵害を検知し、対応し、通知するための体系的な手順を定めること。
2. 定義
| 用語 | 定義 |
|---|---|
| 個人データ侵害 | 偶発的または違法な、個人データの破壊、喪失、改変、または無権限の開示につながるセキュリティの侵害（GDPR第4条(12)） |
| セキュリティインシデント | 個人データが関係するかどうかにかかわらず、システムの機密性、完全性、可用性を損なうあらゆる事象 |
| 時刻ゼロ（T0） | インシデントが検知された、または判明した時点 |
3. インシデントの分類
レベル1 — 重大（個人データ侵害）
- 個人データ（vCard、メールアドレス、電話番号）を含むQRコンテンツの露出
- ユーザーのAIプロンプトの露出
- APIキー（RapidAPI、LLMプロバイダー）の漏洩
- ユーザーデータを含むApplication Insightsへの不正アクセス
- サプライチェーンの侵害（悪意のあるNuGet依存関係）
レベル2 — 高（個人データの関与が確認されていないセキュリティインシデント）
- 脆弱性の悪用の成功（SSRF、インジェクションなど）
- 持続的なサービス拒否
- CI/CDパイプライン（GitHub Actions）の侵害
- Azure App Settingsやシークレットへの不正アクセス
- LLMプロバイダーの異常な挙動（他のユーザーのデータを含む応答）
レベル3 — 中（封じ込め済みのインシデント）
- レート制限で検知・遮断された攻撃の試み
- 脆弱性スキャンの検知
- 公開済みのCVEがある依存関係（悪用は未確認）
- リソースの濫用によるサービスの劣化
レベル4 — 低（情報レベルの事象）
- 認証の失敗
- 通常のレート制限の発動
- パフォーマンスのアラート（コールドスタート、タイムアウト）
4. 対応手順
フェーズ1: 検知とトリアージ（T0 → T0+1h）
| ステップ | 対応 | 担当 |
|---|---|---|
| 1.1 | アラートの発生源を特定する（Application Insights、GitHub Security Advisories、ユーザーからの報告、監視） | 技術チーム |
| 1.2 | インシデントをレベル別に分類する（セクション3） | 技術チーム |
| 1.3 | 何が、いつ、どのように検知されたか、および推定される範囲を記録する | 技術チーム |
| 1.4 | レベル1または2の場合: データ保護の責任者にただちにエスカレーションする | 技術チーム |
フェーズ2: 封じ込め（T0+1h → T0+4h）
| ステップ | 対応 |
|---|---|
| 2.1 | インシデントの種類に応じた即時の封じ込め: |
| - APIキーの漏洩 → Azure App Settingsとプロバイダー側でただちにローテーションする | |
| - 脆弱性の悪用 → ホットフィックスをデプロイするか、影響を受けたエンドポイントを無効にする | |
| - SSRF/インジェクション → 検証で攻撃パターンをブロックする | |
| - CI/CDの侵害 → GitHubのトークンを失効させ、最近のコミットを監査する | |
| 2.2 | 証拠を保全する（Application Insightsのログ、設定のスナップショット） |
| 2.3 | 封じ込めが有効であることを確認する |
| 2.4 | 個人データが影響を受けているか評価し、GDPR上の侵害に当たるか判断する |
フェーズ3: GDPRに基づく通知（該当する場合）
第33条 — 監督機関への通知（T0から72時間以内）
侵害が個人の権利と自由にリスクをもたらす場合にのみ必要です。
通知の内容:
- 侵害の性質（どのデータか、影響を受けるデータ主体の推定数）
- 管理者の連絡先
- 侵害により生じうる結果
- 対処のために講じた、または講じる予定の措置
通知が不要な場合:
- データの露出を伴わない可用性のインシデント（DoS）
- 遮断に成功した攻撃の試み
- 個人データ以外（設定、コード）のみに影響するインシデント
QR Brandingの事情: サービスはステートレスで個人データを保存しないため、ほとんどのインシデントは個人データ侵害には当たりません。例外となりうるのは次の場合です。
- リクエストのメタデータを含むApplication Insightsのログの露出
- 通信中のトラフィックの傍受（TLSにより可能性は低い）
- 他のユーザーのプロンプトを露出させるLLMプロバイダーの異常な挙動
第34条 — データ主体への連絡
侵害が権利と自由に高いリスクをもたらす場合にのみ必要です。
次の場合は不要:
- データが暗号化または匿名化されていた
- リスクが顕在化する可能性がなくなるような措置が講じられた
- 不釣り合いな労力を要する（その場合は公表による連絡を行う）
フェーズ4: 根絶と復旧（T0+4h → T0+48h）
| ステップ | 対応 |
|---|---|
| 4.1 | 根本原因を特定して取り除く |
| 4.2 | 恒久的なパッチまたは修正を適用する |
| 4.3 | 回帰テストを実行する |
| 4.4 | CI/CD（GitHub Actions → Azure）経由で本番環境にデプロイする |
| 4.5 | 本番環境で修正が有効であることを確認する |
| 4.6 | 修正後48〜72時間、重点的に監視する |
フェーズ5: 事後対応（T0+48h → T0+2週間）
| ステップ | 対応 |
|---|---|
| 5.1 | インシデントの全体（時系列、影響、対応）を記録する |
| 5.2 | 根本原因分析（RCA）を行う |
| 5.3 | 予防のための改善点を特定する |
| 5.4 | インシデントにより想定外のリスクが判明した場合は、DPIAを更新する |
| 5.5 | 手順の不備が見つかった場合は、この計画を更新する |
| 5.6 | 得られた教訓を共有する（機密データを除く） |
5. インシデントの記録（第33条(5)）
監督機関への通知が必要かどうかにかかわらず、すべてのインシデントを記録しなければなりません。記録には次の項目を含めます。
| 項目 | 説明 |
|---|---|
| インシデントID | 一意の識別子（INC-YYYY-NNN） |
| 検知日時 | T0 |
| 封じ込め日時 | フェーズ2の終了時点 |
| 分類 | レベル1〜4 |
| 説明 | 何が起きたか |
| 影響を受けたデータ | 関係する個人データの種類（該当する場合） |
| 影響を受けたデータ主体 | 推定数 |
| 根本原因 | RCAの結果 |
| 講じた措置 | 封じ込めと是正の対応 |
| 監督機関への通知 | あり/なし、日付、参照番号 |
| データ主体への連絡 | あり/なし、日付、手段 |
| 解決 | 最終的な状況と完了日 |
6. 主な連絡先
| 役割 | 連絡先 |
|---|---|
| 技術責任者 | QR Brandingチーム |
| プライバシー/DPO | support@qr-branding.com |
| RapidAPI Platform | RapidAPIサポート |
| Microsoft Azure Support | Azureポータル |
監督機関（参考）
| 国 | 機関 | ウェブサイト |
|---|---|---|
| スペイン | AEPD | aepd.es |
| EU（全般） | EDPB | edpb.europa.eu |
7. 訓練
少なくとも年1回のインシデント対応訓練を実施し、次のことを行います。
- 手順が機能することを確認する
- 対応時間を測定する
- 能力や連絡体制の不備を特定する
- チームが手順に習熟する
2026-03-08に作成された文書。次回の定期見直し: 2026-09-08。