暗号鍵管理の置き場所｜HSM・KMS・ハードコードで「守れる範囲」が変わる、ソースネクストの説明から逆算

暗号鍵管理の置き場所によって、攻撃者がどこまで届くかは変わります。2026年10月15日に最大22,519,960件の会員情報の流出を発表したソースネクストについて、同社の説明として「パスワードは暗号化して保存していたが、暗号化を解除するプログラムをハッキングされた」という趣旨が報じられました。

この一文は、鍵がどこにあり、攻撃者がどの権限を得たかで意味がまるで変わります。本記事は連載「事故から逆算するWebセキュリティ」の第2回として、鍵の置き場所と攻撃者の権限を分けて、それぞれが守れる範囲と守れない範囲を整理します。

インシデントの読み方やほかの事案は サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説 にまとめています。

「復号するプログラムをハッキング」は3通りに読める

まず、確かめられたことと報道と推測を分けます。

・同社の発表：会員情報取得 API が悪用され、10月9日10時頃から13日まで不正な取得が続いた（経緯は ソースネクスト情報漏洩｜最大2,252万件・パスワードも対象）
・報道：冒頭の「暗号化を解除するプログラムをハッキングされた」という同社の説明。当サイトは公式発表の本文で確かめられていない
・本記事が推測しないこと：鍵がどこにあったか、どの経路で復号されたか

X上では、報じられた説明を次の3つに分けて考える整理がありました。

同社はどれに当たるかを公表していません。この表は判定ではなく、自分のシステムがどれに近いかを点検するための枠組みです。

暗号鍵管理の3つの置き場所と、攻撃者の権限ごとにできること

OWASP の Cryptographic Storage Cheat Sheet は、アプリは復号のために何らかの形で鍵に触れる必要があり、アプリを完全に乗っ取った攻撃者から鍵を守り切るのは難しいかもしれない、と書いています。置き場所の差は、まず「鍵素材が持ち出されるか」と「何が記録に残るか」に出ます。

①は、OWASP の Key Management Cheat Sheet が勧める形です。生成・暗号化・復号をモジュールの中で行い、平文の鍵を外に出しません。正規の権限による復号をどこまで拒めるかは、鍵を「誰が・どの条件で」使えるかをどこまで細かく決めたかによります。HSM が呼び出しの意図を見て拒むわけではありません。③は、Cryptographic Storage Cheat Sheet が「鍵をソースコードに直書きしない」「バージョン管理に入れない」と明記している形です。

置き場所より差が出るのは、攻撃者が何を得たかです。

AWS KMSのエンベロープ暗号化で、鍵はどこに出てくるか

AWS KMS の開発者ガイドによると、KMS は FIPS 140-3 のセキュリティレベル3で検証されたHSMで鍵を守り、平文の鍵の素材はHSMの境界の外に出ません（中国リージョンを除く）。違いは、大きなデータの暗号化に使うエンベロープ暗号化にあります。

・KMS の鍵（KMS key）の素材はアプリに渡らない。アプリに渡るのはデータキー
・GenerateDataKey は平文と暗号化済みの2つのデータキーを返す。アプリは平文のデータキーで暗号化し、暗号化済みのデータキーだけをデータの横に保存する
・読むときは Decrypt に暗号化済みのデータキーを渡し、返ってきた平文のデータキーでアプリが復号する

ガイドは、平文のデータキーを使い終えたらできるだけ早くメモリから消すよう書いています。逆に言えば、データに直接触れる鍵は、使っている間アプリのメモリにある。②はこの瞬間を取られる場合です。KMS の呼び出しは Decrypt を含めて CloudTrail に記録され、暗号化のときに渡した暗号化コンテキストは復号のときに完全に一致しないと失敗し、平文のまま記録に出るので、どのデータを復号したかを追えます。

手元で測る——復号の窓口を握られると、何回の呼び出しで何件開くか

KMS を模した小さなプログラムを Python（cryptography 50.0.2）で書き、10万件のパスワードを暗号化した表を用意しました。親の鍵は外から取り出せないオブジェクトの中に置き、復号の窓口だけを公開しています。攻撃者は「アプリと同じ権限で窓口を呼べる」とします。

親の鍵は一度も外に出ていないのに、全件が平文に戻りました。表全体を1つのデータキーで暗号化すると、ログに残るのは復号1回分だけで、量の異常として見つける手がかりがありません。これはローカルの模擬で、実際の KMS で同じ量を呼んだときの時間とスロットリングは未検証です。

暗号鍵管理の対策——復号できる範囲を狭め、呼ばれ方を見る

鍵の置き場所を①に寄せても、復号の窓口が開いていれば読まれます。効くのは、窓口を呼べる範囲・条件・回数を絞ることです。

ソースネクストの発表のタイムラインでは、不正な取得の開始から確認まで約4日でした。量の監視が今回効いたかは分かりませんが、「平常の何倍の復号が何時間続いたか」を測れる設計なら、気づくまでの時間を縮める材料になります。Secrets Manager に置いた秘密も同じです。保管場所が安全でも、取り出しを許されたタスクが侵害されれば取られます。

鍵を替えることと、漏えいへの対応は別

AWS の規範ガイダンスも、古い鍵素材が残って復号に使えるため、ローテーションは追加のセキュリティ上の利点をもたらさないとし、主に規制要件のためと位置づけています。

自分のAWS環境で確かめる——復号できる主体と記録

どれも読み取りだけの操作で、設定は変えません。1行目のロールの ARN と2行目の鍵の別名を、自分の環境の値に置き換えてから実行します。

ROLE="arn:aws:iam::111122223333:role/app-task-role"   # 確かめるタスクロール
KARN=$(aws kms describe-key --key-id alias/app-data --query KeyMetadata.Arn --output text)   # 確かめる鍵
# 1. ロールの IAM ポリシーが復号を許すか（鍵ポリシーとグラントは評価しない）
aws iam simulate-principal-policy --policy-source-arn "$ROLE" \
  --action-names kms:Decrypt kms:GenerateDataKey secretsmanager:GetSecretValue \
  --resource-arns "$KARN" --query 'EvaluationResults[].[EvalActionName,EvalDecision]' --output text
# 2. 鍵ポリシーで誰に何を許しているか
aws kms get-key-policy --key-id "$KARN" --policy-name default --output text
# 3. グラントで操作を受け取っている主体（IAM ポリシーに無くても使える）
aws kms list-grants --key-id "$KARN" --query 'Grants[].[GranteePrincipal,join(`,`,Operations)]' --output text
# 4. 直近90日に Decrypt を呼んだ主体と回数（リージョンごと）
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=Decrypt \
  --max-items 1000 --query 'Events[].Username' --output text | tr '\t' '\n' | sort | uniq -c | sort -rn

読み方は次のとおりです。

・1は IAM ポリシーだけの判定。ロールを起点にしたシミュレーションでは鍵ポリシーを評価できないので、2・3と合わせて読む
・1が implicitDeny でも、2の鍵ポリシーか3のグラントで許されていれば使える。グラントは鍵ポリシーや IAM ポリシーを変えずに権限を渡せる
・4で、呼んだ主体と回数が平常の想定と合うかを見る。イベント履歴は直近90日の管理イベントで、トレイルで KMS を除外していても履歴には残る
・90日より前を追うにはトレイルが要る。書き込みのみの記録にしたトレイルには Decrypt が残らない

AWS CLI 1.46.1 と AWS のモック moto 5.2.4 で、2と3の出力の形を確かめました。IAM ポリシーでは Decrypt を許していないロール（signup-writer）に Decrypt のグラントを付けると、3にはそのロールが出ます。1と4は moto が未実装で、リクエストが組み立てられるところまでしか確かめていません。実アカウントでの出力は未検証です。

リポジトリにハードコードされた鍵を探す

③に当てはまるかは、手元のリポジトリで確かめられます。現在のファイルと、過去のコミットで追加された行の両方を探します。

PAT="AKIA[0-9A-Z]{16}|BEGIN [A-Z ]*PRIVATE KEY|[\"'][A-Za-z0-9+/_-]{43}=[\"']|(secret|key|token|passw)[A-Za-z_]*[\"']?[[:space:]]*[:=][[:space:]]*b?[\"'][^\"']{16,}[\"']"
git grep -nIiE "$PAT"
git log -p --all | grep -iE "^\+.*($PAT)"

10月16日に、検体を置いたリポジトリでは現在のファイルで3件・履歴で4件（後で消した SECRET_KEY も出る）、置かないリポジトリでは0件でした。コードから消した鍵も、履歴には残っています。見つかったら、消すのではなく作り直してください。正規表現で拾える形は一部なので、漏れなく探すには専用のスキャナーを併用します。

パスワードはそもそも暗号化しない——秘密の種類で保存の仕方を分ける

ここまでの話は、元に戻す必要があるデータの話です。何を守るかで、保存の仕方は変わります。

OWASP の Password Storage Cheat Sheet は、ログインパスワードは暗号化ではなくハッシュで保存すべきで、暗号化を使うのは別のシステムへの認証に元のパスワードそのものが要る例外のときだけ、としています。

保存の仕方の詳細は連載第1回の パスワードのハッシュ化と暗号化の違い で扱いました。

参照ソース

• OWASP Cryptographic Storage Cheat Sheet（Key Storage・Separation of Keys and Data。GitHub の原稿で確認）
• OWASP Key Management Cheat Sheet（暗号の操作をモジュールの中で行い、平文の鍵を外に出さない。GitHub の原稿で確認）
• OWASP Password Storage Cheat Sheet（Hashing vs Encryption。GitHub の原稿で確認）
• AWS KMS Developer Guide: Data protection（FIPS 140-3 セキュリティレベル3のHSM、平文の鍵がHSMの外に出ないこと）
• AWS KMS Developer Guide: Rotate AWS KMS keys・AWS Prescriptive Guidance: Key rotation for AWS KMS and scope of impact（古い鍵素材が残り既存の暗号文を復号できること、再暗号化しないこと、ローテーションの位置づけ）
• AWS KMS Developer Guide: Grants in AWS KMS（ポリシーを変えずに権限を渡せること）
• IAM API Reference: SimulatePrincipalPolicy（リソースポリシーは自動で取得されず、ロールを起点にしたシミュレーションでは評価できないこと）
• AWS CloudTrail: Working with CloudTrail event history・Logging management events（直近90日の管理イベント、KMS の除外が履歴に及ばないこと、書き込みのみの記録）
• AWS KMS Developer Guide: Encryption context（暗号文との結び付けと、CloudTrail・ポリシー条件での扱い。GitHub に残る2023年版の原稿で確認）
• ソースネクスト「当社サイトへの不正アクセスによるお客様情報流出のお詫びとお知らせ」2026-10-15（本文は未参照）