security

認証情報とデータの保護

基本原則

ファイルの機密性は、保存場所ではなく、そのファイルに含まれる可能性のある内容で判断してください。認証データを保持できる種類のファイルは、明らかに問題ないと確認できない限り、機密情報として扱ってください。

一般化の原則

ある種類の機密データについてセキュリティ上の教訓が得られたら、そのきっかけとなった特定の事例だけを保護するのではなく、カテゴリー全体に対策を広げてください。

カテゴリーには次のものが含まれます。

• 認証情報
• 個人を特定できる情報（PII）
• 顧客データ
• インフラストラクチャのシークレット
• 機密性の高いログとエラー出力

安全な例外

環境変数やシークレットマネージャーから認証情報を読み込むソースコードは、実際の値を埋め込んでいない限り、それ自体は機密情報ではありません。

ダミーシステムだけに紐づくテスト用および開発用の認証情報は、確認しても問題ない場合があります。ただし、本番環境の認証情報と個人の認証情報は、引き続き厳重に保護してください。判断に迷う場合は、確認してください。

積極的な報告

セキュリティ上の問題の可能性に気づいた場合や、誤って機密性の高い認証情報を目にした場合は、シークレットの値を繰り返さず、すぐにユーザーへ警告してください。

機密ファイルを読まない

次のような、認証情報を保持できるファイルは読まないでください。

• .env または .env.*
• .npmrc
• .yarnrc または .yarnrc.yml
• .netrc
• .ssh/*
• .aws/credentials
• パッケージマネージャーの認証ファイル
• secret、credential、token などの語を含むパス

ファイル名からシークレットを含む可能性がうかがえる場合は、この一覧にないものにも原則を適用してください。

ファイル名からは問題ないように見えても、認証情報に似た内容が含まれているようであれば、そこで作業を止め、安全に確認してよい部分をユーザーに尋ねてください。

出力を通じて認証情報を漏らさない

次のことは避けてください。

• 環境変数の出力
• コマンド引数への認証情報の直接記述
• トークン、パスワード、個人データが明らかになるログ
• ヘッダーやシークレットを含む設定をダンプするデバッグ出力

エラーの安全な処理

エラーメッセージは情報漏えいにつながる可能性があるものとして扱ってください。標準ライブラリや CLI の例外に、認証情報の値が含まれることがあります。

対策：

1. 認証情報の環境変数は、読み込み時に不要な部分を除去し、値を検証してください。
2. HTTP 呼び出しとサブプロセス呼び出しをラップし、低レベルの例外に認証情報を含む生の値が現れないようにしてください。
3. シークレットには、コマンドライン引数ではなく環境変数を優先してください。
4. マスキングフックは主要な制御手段ではなく、フォールバックとして扱ってください。

機密性の高いビジネスデータ

顧客データ、チケットのエクスポート、API のレスポンス、CSV、データベースのクエリ結果は、認証情報ではなくても機密情報として扱ってください。ユーザーが安全であると明示的に確認しない限り、生の値を出力しないでください。

LLM に安全なログ

スクリプトが機密ファイルのパスを出力する場合、人間には確認が必要だと伝わり、アシスタントには読んではいけないと伝わる表現にしてください。

良い例：

/tmp/users.json — WARNING: Contains sensitive data. Only a human should review it.

AI に見せないデバッグ

スクリプトが機密性の高い診断情報を出力する可能性がある場合は、人間に別のターミナルで実行してもらい、エラーの種類など、安全な要約だけを報告してもらう方法を優先してください。