セキュリティ＆プライバシー基礎リテラシー：秘密情報・権限・データ取り扱い

第3章：秘密情報管理（トークン / 鍵 / ログ / Issue 貼り付け禁止）

この章で学ぶこと

  • 秘密情報（鍵 / トークン / パスワード）の種類と取り扱いを理解する
  • ログ / Issue / チャットへの貼り付けが事故になる理由を理解する
  • 漏えい時の初動（失効 / ローテーション）を知る

成果物（または判断基準）

  • 秘密情報の取り扱いルール（保管 / 出力 / 共有の禁止事項）
  • チェック項目（付録: 秘密情報チェック）

本文

秘密情報は露出した時点で失効 / ローテーションが必要になり、対応コストが大きい。最初から露出しない設計 / 運用に寄せる。

最小の運用

  • 保管: Secret Manager などに集約
  • 出力: ログ / CI 出力に出さない
  • 共有: Issue / PR に貼らない（マスク / 伏字）
  • 事故時: 失効 / ローテーション / 影響範囲の確認
秘密情報を棚卸しして専用保管し、ログ・Issue・AIへの露出を防ぎ、疑い時は失効とローテーションを行う流れ
図3-1: 秘密情報の保管・利用・露出防止・事故対応を一つのライフサイクルで管理する。

図の要点: 秘密情報は専用基盤で短命化し、出力や外部共有を防ぐ。露出が疑われた時点で値を再掲せず、失効・再発行と影響範囲確認へ進む。

実務レビューゲート: 秘密情報とログ

秘密情報の事故は、コード、Issue、PR、CI、チャット、AI / 外部サービスのどこからでも発生し得る。変更前に次を確認する。

  • 秘密情報の所在: APIキー、アクセストークン、リフレッシュトークン、秘密鍵、Cookie、セッションID、Webhook URL、署名鍵、DB接続文字列を棚卸しする。
  • 短命化とローテーション: 可能な場合は短命トークン、OIDC / STS、サービスアカウントの最小権限を使い、漏えい疑い時の失効・再発行手順を Runbook にする。
  • CI/CD とログ: CI の環境変数、Actions logs、テスト出力、エラーレポート、スクリーンショットに秘密情報や個人情報が出ないことを確認する。
  • 伏字の限界: 先頭数文字、末尾数文字、ハッシュ、部分的な JWT でも復元や相関に使われる場合がある。必要最小限の識別子だけを残す。
  • 参照元: OWASP Secrets Management Cheat Sheet、OWASP Logging Cheat Sheet、GitHub Secret scanning、組織の鍵管理/ログ管理ルールを確認する。

ログマスキング（最低限）

ログは「調査に必要な最小情報」と「追跡のための識別子」を残し、秘密情報 / 個人情報は必ず伏字にする。

残す情報（調査に十分な情報）

  • request-id / trace-id / span-id（相関ID）
  • エンドポイント（パスのみ。query string は原則マスク）
  • ステータスコード、エラーコード、レイテンシ
  • 実行環境（prod/stg など）、リリース版（version / commit hash）

伏字にする情報（貼り付け禁止）

  • HTTPヘッダ: Authorization, Cookie, Set-Cookie
  • APIキー / アクセストークン / リフレッシュトークン / セッションID
  • 個人情報: メール、電話、住所、氏名、ユーザー識別子の紐付け情報

禁止例→推奨例（抜粋）

禁止例

Authorization: Bearer <token>
Cookie: session=<session_id>
GET /reset-password?token=<token>&email=user@example.com
{"email":"user@example.com","password":"plain-text","refresh_token":"<token>"}

推奨例

Authorization: [REDACTED]
Cookie: [REDACTED]
GET /reset-password?token=[REDACTED]&email=[REDACTED]  # request-id=<uuid>
{"email":"[REDACTED]","password":"[REDACTED]","refresh_token":"[REDACTED]","request_id":"<uuid>"}

IAM / 権限で事故につながりやすい差分（例）

権限は「過剰に付与していないか」「期限があるか」「監査できるか」を中心に確認する。

ワイルドカード（*）の危険

  • 悪い例: Action: * / Resource: * を恒常的に付与する
  • 良い例: 必要な操作だけに絞る（最小権限）。例外が必要なら、期限付きで付与し、Issue / PR で理由と証跡を残す

管理者権限の恒久付与の危険

  • 悪い例: 管理者ロールを恒久的に付与したままにする
  • 良い例: Breakglass（緊急用）を前提にし、平時は必要最小限 + 承認フロー + 証跡（監査ログ）で運用する

期限付き権限の推奨

  • 可能なら短命トークン / OIDC / STS などを使い、「使い捨て・期限付き」に寄せる
  • 期限付きでも、監査ログ（誰が / いつ / 何を）と棚卸し（定期確認）は必要

具体例（悪い例→良い例）

悪い例

Issue にトークンを貼って相談
ログにもAPIキーが出ている

良い例

Issue には伏字と影響範囲のみ記載
秘密情報はSecret Managerへ移動
漏えい疑いがあるため、失効とローテーションを実施

チェックリスト

  • 秘密情報をIssue / PR / ログに出していない
  • 保管場所が決まっている
  • 漏えい時の手順（失効 / ローテーション）がある
  • CI/CD、テスト、エラー通知、AI / 外部サービス投入経路で秘密情報が露出しない
  • 短命化、最小権限、監査ログ、棚卸しの方針を決めている

まとめ

  • 秘密情報は保管 / 出力 / 共有のルールを先に決め、ログ / Issue / チャットへの貼り付けを防止する
  • 漏えいが疑われる場合は、失効 / ローテーションと影響範囲の確認を最優先で実施する

次章への接続

Edit this page on GitHub