アクセスキーをコードやイメージに直書きしない：国内 3 件の事例と「一時的な認証情報」への切り替え

何が起きたか（2026-11-09〜10 の公表）

• ラフールサーベイ（旧システム）: エンジニアがプログラムにアクセスキーを直書き。2019 年に当時の開発委託先の開発者が、そのプログラムを含むテスト用実行環境のイメージをネット上に公開し、第三者がキーを入手したと推定。利用企業 182 社・24,232 人分（一部はストレスチェック結果など要配慮個人情報）が取得された。
• アイル「CROSS-POINT」: 導入企業 1 社専用の正規の API 認証キーが外部に流出し、API 経由で会員情報が取得された。
• キングプリンターズ: システム基盤の認証情報が不正利用され、生成 AI サービスが大量に呼び出された（サービス側の利用制限で停止）。再発防止策は「静的な認証情報の運用を廃止し、一時的な認証情報を必要なタイミングで発行する方法に統一」。

対策

1. ソースコード・設定ファイル・コンテナイメージにキーを入れない。 ビルド時に ARG/ENV で渡したキーもイメージ層に残る。実行時にシークレットストアや環境から注入する。
2. 公開済み・共有済みのイメージを棚卸しする。 Docker Hub などの公開リポジトリ、委託先が作ったテスト用イメージも対象。古いタグも含めてシークレットスキャン（gitleaks・trufflehog など）をかける。
3. 見つけたキーは「消す」ではなく失効・再発行する。 イメージやコミットを削除してもコピーは残る。
4. 長期キーを短命の認証情報に置き換える。 クラウドなら IAM ロール／ワークロード ID（OIDC フェデレーション）、STS の一時認証情報など。CI も OIDC で必要な時だけ発行する。
5. 顧客ごとの API キーには上限と監視を付ける。 取得件数のレート制限、想定外の IP・時間帯からの大量取得アラート、定期ローテーション。
6. 委託先の開発ルールに明記する。 「テスト用でもイメージを公開しない」「キーは発注側のシークレット管理から払い出す」を契約・受け入れチェックに入れる。
7. 生成 AI の利用枠に上限を設定する。 キングプリンターズの例ではサービス側の利用制限が被害を止めた。予算アラートと日次上限を必ず設定する。

注意

• 発覚までの期間が長い（ラフールは 2019 年の公開が原因）。旧システム・廃止予定システムのキーほど放置されやすい。

関連

• .gitignore に入れたはずの .env が漏れていないか 5 か所で点検する
• LLM の盗用は「1 トークンの確認呼び出し」で始まる：LiteLLM のキー昇格と GTIG の推奨

出典

• @MalwareBibleJP · 2026-11-10 （ラフール）
• @MalwareBibleJP · 2026-11-11 （アイル）
• @MalwareBibleJP · 2026-11-11 （キングプリンターズ）