第5章暗号の実務 — 鍵管理・PKI・証明書 | セキュリティ中級・上級ノート

🎯 この章で学ぶこと

暗号は「アルゴリズム選び」より「鍵の運用」で決まるという実務観
鍵のライフサイクル(生成・配布・保管・ローテーション・失効・破棄)
KMS/HSM/シークレットマネージャと封筒暗号の考え方
PKI・X.509証明書・失効の仕組みと、TLS証明書運用の勘所(ACME・mTLS)

5.1 入門の復習を一段深く

入門コース第12章で、ハッシュと暗号化の違い(ハッシュは不可逆・比較用、暗号化は鍵で元に戻せる)、そして対称暗号と非対称暗号の違いを学びました。ここを土台に、一段深い実務観へ進みます。要点を表で再確認します。

	対称暗号(共通鍵)	非対称暗号(公開鍵)
鍵	暗号化と復号で同じ鍵	公開鍵と秘密鍵のペア
速度	速い。大量データ向き	遅い。少量データ・鍵交換・署名向き
課題	鍵を安全に共有する方法	公開鍵が本物である保証(→PKI)
代表例	AES	RSA、楕円曲線(ECDSA/ECDH)

実務で最初に染み込ませるべき考え方はこれです。「暗号の強さは、アルゴリズムではなく鍵の運用で決まる」。最新の強力なAESを使っていても、その鍵をソースコードに平文で書いていたり、全員で共有していたり、一度も更新していなければ、暗号は事実上ザルです。逆に言えば、実務のセキュリティは「どの暗号を使うか」を悩む時間より、「鍵をどう守り、どう回すか」に注ぐべきなのです。以降、この章は一貫して鍵の話をします。

5.2 鍵管理こそ本体

暗号鍵は「作って終わり」ではなく、生まれてから消えるまでの一生=鍵のライフサイクルを管理する対象です。各段階に固有のリスクと打ち手があります。

段階	やること	注意点
生成(Generate)	暗号学的に安全な乱数で鍵を作る	予測可能な乱数・自作の擬似乱数を使わない
配布(Distribute)	必要な相手・システムにだけ安全に渡す	チャットやメールに平文で貼らない
保管(Store)	鍵専用の安全な場所に置く	コードや環境変数に平文で置かない
ローテーション(Rotate)	定期的に、または漏えい時に鍵を更新する	更新しても古いデータを復号できる移行設計が要る
失効(Revoke)	漏れた/不要になった鍵を無効化する	失効が反映される仕組みを用意しておく
破棄(Destroy)	役目を終えた鍵を確実に消す	バックアップやログに残った鍵を消し忘れない

とりわけ入門コース第10章でも強調された鉄則を、ここで改めて刻んでください。鍵を平文でソースコードに書かない。鍵をリポジトリにコミットしない。ハードコードされた鍵は、コードが共有・公開・流出した瞬間にすべての暗号を無力化します。GitHub上に鍵やAPIトークンが誤ってコミットされ、数分以内に自動化ボットに拾われて悪用される事故は、今も日常的に起きています。

もう一つ実務で重要なのがローテーションです。鍵は永久に使い続けるものではありません。定期的に更新することで、万一漏れていた場合の「有効期間」を区切り、被害を限定します。ただし、暗号化に使った鍵を更新すると古い鍵で暗号化した過去のデータをどう復号するかという課題が生じます。実務では、データに「どの鍵バージョンで暗号化したか」を記録し、旧鍵で復号→新鍵で再暗号化する移行設計をあらかじめ用意します。

5.3 KMS・HSM・シークレットマネージャ

「鍵を平文で置くな」と言われても、どこかには置かねばなりません。環境変数は「コードに直書き」よりはましですが、プロセス一覧・ログ・クラッシュダンプから漏れ得るなど限界があります。その一段上の選択肢が、鍵とシークレットの専用管理基盤です。

仕組み	役割	特徴
KMS(Key Management Service)	鍵の生成・保管・利用・ローテーションを一元管理するサービス	クラウド各社が提供。アクセス制御・監査ログと統合できる
HSM(Hardware Security Module)	鍵を専用ハードウェア内で生成・保管し、外に出さない	鍵そのものを取り出せない。高い保証が要る用途向け
シークレットマネージャ	鍵・パスワード・APIトークンなどの秘密情報を安全に保管・配布	アプリは起動時などに取得。ローテーションや失効を集中管理

これらを支える中心的な考え方が封筒暗号(envelope encryption)です。名前のとおり「鍵を鍵で包む」二段構えの仕組みです。

実データは、その都度生成するデータ暗号鍵(DEK: Data Encryption Key)で暗号化する(高速な対称暗号)
そのDEKを、KMS/HSM内から出ないマスター鍵(KEK: Key Encryption Key)で暗号化し、暗号化したDEKをデータのそばに保管する
復号時は、暗号化DEKをKMSに渡してKEKで復号してもらい、得たDEKで実データを復号する

この構造の利点は、最も守るべきマスター鍵(KEK)を安全な場所から一度も出さずに、大量のデータを効率よく暗号化できることです。マスター鍵をローテーションしたいときも、各データを再暗号化する必要はなく、暗号化されたDEKだけを作り直せば済みます。クラウドのデータ暗号化は、たいていこの封筒暗号で動いています。

💡 「暗号化しました」で安心しない

「保存データを暗号化しています」という説明を聞いたら、次に問うべきは「その復号鍵はどこにあり、誰が触れるのか」です。データと同じサーバーに鍵が平文で置いてあれば、サーバーを奪った攻撃者は鍵ごと手に入れます。暗号化の価値は、データと鍵を分離し、鍵へのアクセスを厳しく制御して初めて生まれます。暗号化の有無より、鍵の在り処が本質です。

5.4 PKIと証明書

非対称暗号には「その公開鍵は本当に相手のものか?」という根本課題があります(5.1)。偽の公開鍵をつかまされれば、暗号通信は攻撃者に筒抜けになります。この「公開鍵と持ち主の対応を、信頼できる形で保証する」仕組みがPKI(Public Key Infrastructure、公開鍵基盤)です。

PKIの中心にいるのが認証局(CA: Certificate Authority)です。CAは「この公開鍵は、確かにこのサーバー(この組織)のものだ」という保証を、証明書という形で発行します。証明書の標準形式がX.509で、公開鍵・持ち主(サブジェクト)・発行者(CA)・有効期限・用途などを含み、CAの署名がついています。

信頼はチェーンでつながります。これを信頼チェーン(certificate chain)と呼びます。

ルートCA証明書(自己署名。OS/ブラウザに最初から入っている=信頼の根)
   └─署名─→ 中間CA証明書
                └─署名─→ サーバー証明書(例: www.example.com)

検証: サーバー証明書 → 中間CA → ルートCA と署名をたどり、
      最後に「信頼の根(ルート)」に到達できれば、その証明書を信頼する。

ブラウザやOSは、あらかじめ信頼できるルートCAの一覧(トラストストア)を持っています。ある証明書が、この信頼された根まで正しくチェーンでつながれば「本物」と判断されます。だからこそ、ルートCAの秘密鍵は世界で最も厳重に守られる鍵の一つなのです。

もう一つ重要なのが失効です。証明書が有効期限内でも、秘密鍵が漏れたなどの理由で「もう信頼するな」と伝える必要が出ます。そのための仕組みが2つあります。

仕組み	内容	特徴
CRL(Certificate Revocation List)	失効した証明書の一覧をCAが公開する	網羅的だがリストが肥大化しやすい
OCSP(Online Certificate Status Protocol)	特定の証明書が失効していないかをその都度問い合わせる	リアルタイム性が高い。OCSPステープリングで効率化

5.5 TLS証明書の実務

PKIが最も身近に使われているのがTLS(HTTPS)です。かつてTLS証明書は手作業で取得・更新するもので、「更新を忘れて期限切れ、サイトが警告だらけで停止」という事故が絶えませんでした。これを一変させたのがACMEプロトコルと、それを使うLet's Encryptなどの無料CAです。

ACMEは、証明書の取得・更新を自動化するための仕組みです。サーバーが「このドメインを確かに管理している」ことを自動で証明(ドメイン検証)し、証明書を受け取り、期限が近づけば自動で更新します。証明書の有効期間は短め(90日など)に設定されますが、自動更新が回っていれば人手は不要です。

✅ 期限切れ事故を「監視」と「自動化」で潰す

証明書の期限切れは、今なお大規模障害の定番原因です(有名サービスが証明書失効で一斉に止まる事故が繰り返されています)。対策は2本立てです。(1)自動更新を組み、人の記憶に頼らない。(2)それでも自動化が壊れることはあるので、有効期限を監視し、期限が近づいたら警告を上げる。「自動化したから安心」ではなく「自動化+監視」で二重に守ります。第7章の監視の考え方が、ここでも効きます。

さらに一段進んだ実務としてmTLS(相互TLS)があります。通常のTLSは「サーバーが本物か」をクライアントが確認する片方向ですが、mTLSではクライアントも証明書を提示し、サーバーがそれを検証する——双方が互いを証明書で認証します。マイクロサービス間の通信やゼロトラスト(第3章)の実装で、「正しいサービスだけが互いに通信できる」ことを保証するために使われます。

5.6 やりがちな暗号の失敗

暗号の事故は、たいてい「難しい数学を破られて」ではなく「基本的な運用ミス」から起きます。頻出の失敗と、その理由・対策を整理します。

失敗	なぜ危険か	正しいやり方
自作暗号(独自アルゴリズム)	専門家の検証を経ていない暗号は、ほぼ確実に弱点を持つ	標準化され広く検証されたアルゴリズム・ライブラリを使う
AESのECBモード	同じ平文ブロックが同じ暗号文になり、パターンが漏れる	認証付き暗号(AES-GCMなど)を使う
IV/nonceの再利用	同じ鍵で初期化ベクトル/nonceを使い回すと機密性・完全性が崩れる	毎回ユニークな(多くはランダムな)IV/nonceを使う
MD5 / SHA-1の使用	衝突が現実的に作れ、改ざん検知や署名に使えない	SHA-256以上を使う(パスワードは専用のハッシュ関数)
鍵のハードコード	コードの共有・流出で全暗号が無力化する(5.2)	KMS/シークレットマネージャで管理する

共通する教訓は、「暗号は自分で作らない・自分で工夫しない」ことです。第3章で認証を自作しないと述べたのと同じで、暗号もまた、素人の善意の工夫が最も危険な領域です。実績ある標準を、正しいモード・正しいパラメータで、正しく運用して使う。それが唯一の安全な道です。なお、パスワードの保存はここでの「暗号化」とは別問題で、bcrypt/scrypt/Argon2 のような専用のパスワードハッシュを使う点は入門コース第12章のとおりです。

🛡️ セキュリティの視点 — 暗号は正しく「運用」して初めて意味を持つ

この章を貫く一本の芯は、「暗号技術そのものより、その運用が勝敗を決める」ということです。世界最強のAES-256も、鍵をコードに書けば無意味です。完璧なTLSも、証明書を期限切れにすれば止まります。堅牢なPKIも、ルートCAの秘密鍵が漏れれば崩壊します。攻撃者は難しい暗号解読に挑むより、はるかに簡単な「鍵の置き忘れ」「更新忘れ」「モードの誤用」を狙います。だから実務者が投資すべきは、暗号アルゴリズムの選定に悩む時間ではなく、鍵のライフサイクルを回す仕組み、証明書を監視・自動更新する運用、そして標準を正しく使う規律です。暗号は道具にすぎません。それを守る運用があって初めて、暗号は資産を守ります。

まとめ

暗号の強さはアルゴリズムより鍵の運用で決まる。実務の主戦場は鍵管理にある
鍵は生成・配布・保管・ローテーション・失効・破棄のライフサイクルで管理し、平文でコードに書かない
KMS/HSM/シークレットマネージャと封筒暗号で、マスター鍵を出さずに大量データを守る
PKIはCAと信頼チェーンで公開鍵の正当性を保証し、CRL/OCSPで失効を伝える
TLSはACMEで自動取得・更新し監視で二重化。mTLSで相互認証。自作暗号・ECB・IV再利用・MD5/SHA-1・鍵ハードコードは避ける

練習問題

問題 5-1

あるチームが「顧客データはAES-256で暗号化しているので万全です」と説明しました。あなたはセキュリティレビュー担当として、この一文だけでは判断できないと考えます。追加で確認すべきことを、鍵管理の観点から3つ挙げてください。

解答を見る

アルゴリズムがAES-256であることは出発点にすぎません。鍵の運用こそが本体なので、たとえば次を確認します。

鍵の保管場所とアクセス制御 — 復号鍵はどこにあるか。データと同じサーバーに平文で置いていないか。KMS/シークレットマネージャで管理し、誰が鍵に触れられるか制御・監査しているか。
暗号モードとパラメータ — ECBモードを使っていないか(AES-GCMなど認証付きか)、IV/nonceを毎回ユニークにしているか。
鍵のローテーションと漏えい時の手順 — 鍵を定期的に更新しているか。漏れた場合に失効・再暗号化する仕組みがあるか。鍵がコードやリポジトリにハードコードされていないか。

「暗号化している」より「鍵をどう守り、どう回すか」が本質だという視点で問うのが要点です。

問題 5-2

封筒暗号(envelope encryption)では、なぜデータを直接マスター鍵で暗号化せず、わざわざデータ暗号鍵(DEK)を挟むのでしょうか。この二段構えの利点を2つ説明してください。

解答を見る

利点1:マスター鍵を安全な場所から出さずに済む。実データの暗号化は、その都度作るDEK(高速な対称鍵)で行い、DEKだけをKMS/HSM内のマスター鍵(KEK)で暗号化します。最も守るべきマスター鍵はKMS/HSMの外に一度も出ないため、露出リスクを最小化しつつ、大量のデータを効率よく暗号化できます。利点2:マスター鍵のローテーションが軽い。マスター鍵を更新したいとき、膨大な実データを再暗号化する必要はなく、各データに添えた「暗号化されたDEK」を作り直すだけで済みます。運用コストを大きく下げられます。加えて、データごとにDEKを分けられるため、影響範囲を細かく区切れる利点もあります。

問題 5-3

あるWebサービスが、深夜に突然すべてのアクセスで「この接続は安全ではありません」という警告を出し、利用できなくなりました。コードやサーバーには変更を加えていません。最も疑うべき原因は何で、再発防止のために何を仕込むべきでしょうか。

解答を見る

最も疑うべきはTLS証明書の有効期限切れです。コード変更がなくても、証明書は時間の経過だけで期限を迎え、期限を過ぎるとブラウザが一斉に警告を出してサービスが実質停止します。再発防止:(1)ACME(Let's Encrypt など)による自動更新を組み、更新を人の記憶に頼らない。(2)自動化が壊れる場合に備え、証明書の有効期限を監視して、期限が近づいたらアラートを上げる。「自動化」と「監視」の二重で守るのが定石です。証明書の期限切れは、大規模サービスでも繰り返し起きる古典的な事故です。