【入門編】 RSA秘密鍵の漏洩検知と失効プロセス – 暗号理論・認証基盤 & エンドポイントセキュリティ防御ガイド

秘密鍵が「盗まれた」その瞬間、あなたはどう動く？――RSA鍵の漏洩と失効のリアル

エンジニアの皆さん、こんにちは。セキュリティの世界へようこそ。

今日は、私たちのインフラを守る「最高位の門番」である、RSA秘密鍵のお話です。もし、あなたがサーバーの鍵をどこかで落としてしまったら？あるいは、クラウドの設定ミスで秘密鍵がGitHubに公開されてしまったら？

教科書には「失効させよ」と一言で書かれていますが、現場ではそんなに単純ではありません。「泥棒が合鍵を持って、あなたの家に侵入しようとしている」その状況を、一緒に整理していきましょう。

—

1. 秘密鍵は「マスターキー」：なぜ漏洩が致命的なのか

まず、基本的なイメージを持ちましょう。RSAのような公開鍵暗号は、「公開鍵（錠前）」と「秘密鍵（鍵）」のペアで成り立っています。

公開鍵： 誰でもコピーしていい錠前。みんながあなたの家（サーバー）に荷物を送るために使います。
秘密鍵： あなただけが持つ、絶対に他人に渡してはいけないマスターキー。

もしこの秘密鍵が漏れると、泥棒は「あなたになりすます」ことができます。通信を盗聴するだけでなく、あなたのフリをして偽の情報を流したり、不正なコマンドを実行したりできてしまうんです。これはもう、防犯ブザーを鳴らすどころの話ではありません。

—

2. 「鍵を無効化する」という考え方：CRLとOCSP

鍵が漏れたら、一刻も早く「その鍵はもう使えない」と世界中に周知する必要があります。ここで登場するのが、CRL（証明書失効リスト）とOCSP（オンライン証明書状態プロトコル）です。

CRL：指名手配リストの配布

街中の警察官に「この泥棒の顔写真（失効した鍵のリスト）」を配り歩くようなものです。

メリット： ネットが繋がっていなくても確認できる。
デメリット： リストが長くなると、照会に時間がかかるし、更新のラグが発生する。

OCSP：リアルタイムの照会窓口

「この鍵、今使っても大丈夫？」と、その都度、認証局（警察本部）に電話で確認する仕組みです。

メリット： 常に最新の状態を確認できる。
デメリット： 認証局のサーバーがダウンすると、誰もあなたのサイトにアクセスできなくなるリスクがある。

最近では、このOCSPの欠点を補うために「OCSP Stapling」という技術がよく使われます。サーバーが「警察署から発行された『この鍵はまだ有効です』という証明書」をあらかじめ受け取っておき、アクセスしてきた人にそれを提示する仕組みです。これなら、余計な手間をかけずに安全性を担保できますね。

—

3. もし鍵が漏れたら？再発行までのロードマップ

「あ、やってしまった！」と気づいた瞬間、パニックにならずに以下の手順を踏んでください。

1. 即座に鍵を破棄する： 漏洩した鍵は、二度と使わないでください。
2. 新しい鍵ペアを生成する： 以前のものとは全く別の鍵を作り直します。
3. 証明書署名要求（CSR）を作成： 再度、認証局に「新しい鍵を使って証明書を発行してください」と頼みます。
4. 証明書のインストール： 新しい証明書をサーバーに設置します。

実践：OpenSSLでの鍵生成コマンド

新しい鍵を作る際は、最低でも「2048bit」以上、推奨は「4096bit」のRSA鍵を使いましょう。

# 新しい秘密鍵を生成（4096bitの強度で）
openssl genrsa -out server.key 4096

# 生成した秘密鍵からCSR（証明書署名要求）を作成
# ※このとき、組織名やドメイン情報を正確に入力してください
openssl req -new -key server.key -out server.csr

—

4. 現場で役立つ「安心」のための設定

セキュリティは設定して終わりではありません。Webサーバー（Nginxなど）での設定例を少しだけ見てみましょう。

# Nginxの設定例：OCSP Staplingを有効にする
ssl_stapling on;
ssl_stapling_verify on;
# 認証局の証明書を指定
ssl_trusted_certificate /etc/nginx/cert/chain.pem;

# 脆弱な暗号スイートを無効化する（重要！）
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;

このように、ssl_staplingを有効にすることで、ユーザーのブラウザがわざわざ警察（認証局）に電話をかけなくても、サーバーから「この鍵はまだ指名手配されていませんよ」という証明を提示できるようになります。

—

最後に：完璧な防御はない、だからこそ「早期発見」

技術が進歩しても、ヒューマンエラーによる鍵の漏洩を完全にゼロにすることは非常に困難です。だからこそ、私たちは「漏れたらすぐに対処できる体制」を整えておく必要があります。

秘密鍵をソースコードに書かない（環境変数やシークレット管理サービスを使う）。
秘密鍵のパーミッションを厳しく設定する（chmod 600 を忘れずに！）。
万が一の際に、証明書を再発行する手順をドキュメント化しておく。

一歩ずつで構いません。今日学んだ「鍵の漏洩と失効」という概念が、皆さんのシステムの守りを少しでも強固にする一助になれば幸いです。

また次回の記事で、より深いセキュリティの泥沼でお会いしましょう。それでは！