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

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

この章で学ぶこと

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

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

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

本文

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

最小の運用

  • 保管: Secret Manager などに集約
  • 出力: ログ/CI 出力に出さない
  • 共有: Issue/PR に貼らない（マスク/伏字）
  • 事故時: 失効/ローテーション/影響範囲の確認

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

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

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

  • 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/ログに出していない
  • 保管場所が決まっている
  • 漏えい時の手順（失効/ローテーション）がある

まとめ

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

次章への接続

Edit this page on GitHub