物語（案件ベース）で分かるPKI（公開鍵基盤）

ごきげんよう。二深すうちです。

普段からITの勉強をしていますが、覚えた用語がそれぞれどのようにつながっているのか、いまいち理解できないことがありました。
単語同士の関係や前後関係が整理できていないと、せっかく勉強した内容もどんどん抜けてしまうんですよね。
ということで、今回はPKI（公開鍵基盤）を物語（案件ベース）形式でまとめてみました。

各技術の詳細な解説よりも、技術同士のつながりや、実際のプロジェクトにおける全体の流れをつかむことを重視した構成になっています。

PKI基盤・端末認証導入プロジェクト

登場人物

第1話　私物PCでのアクセス事件

月曜日、午前9時。
兎角はメール確認をしていた。
そこへ無茶課長がやってくる。

無茶課長「兎角君、ちょっといいか」
兎角「はい」
無茶課長「監査で怒られたぞ」
兎角「今回は何ですか？」

無茶課長が資料を机に置く。そこには、
「私物PCによる社内ネットワーク接続の可能性」と書かれていた。

兎角「……確かに、それはまずいですね」
無茶課長「会社が管理している端末だけ、社内ネットワークに接続できるようにしたい」
兎角「今ってIDとパスワードで認証してますよね？」
認田「そうですね。基本的には利用者のIDとパスワードで、利用者本人であることを確認しています」
兎角「じゃあ、正社員のIDとパスワードを使えば、私物PCからでも接続できる？」
認田「できます」
兎角「それだと……社員本人であることは確認できても、そのPCが会社の管理下にあるかは分からない？」
認田「その通りです。認証と認可は分けて考えましょう」

認証と認可

●認証（Authentication）
　接続してきた利用者や端末が、何者であるかを確認すること。

• ID・パスワードによる利用者認証
• 電子証明書による利用者・端末の認証
• 生体認証による利用者認証

●認可（Authorization）
　認証結果や利用者・端末の属性、セキュリティポリシーなどに基づいて、何へのアクセスを許可するか決めること。

現在の仕組みでは、

正社員AのID
 ↓
私物PCで認証
 ↓
社内LAN

も成立してしまい、利用者は正規でも、端末が正規とは限らない。

---

危田「それセキュリティ的にアウトです」
兎角「じゃあ、利用者だけじゃなく端末も確認する？」
認田「その通りです」
技田「ネットワークに接続する段階で端末を認証し、接続可否を制御する方法があります。
　　　今回はIEEE 802.1Xを採用します」

IEEE 802.1X

ネットワークへ接続する際に、接続しようとしている端末や利用者を認証し、その認証結果に応じてネットワークへのアクセスを制御する仕組み。

例えば、会社のLANにPCを接続したとき、

PC
 ↓
「このPCをネットワークに接続していい？」
 ↓
認証
 ↓
認証OK → ネットワークへ接続
認証NG → 接続を拒否

という流れを作る。

今回の目的は、「認証された端末・利用者だけネットワークへの接続を許可する」こと。

技田「ただし、802.1Xそのものが認証方式というわけではありません」
兎角「え？」
技田「実際にどのような方法で認証するかは、別の仕組みを使います」
兎角「なるほど・・・別の仕組みとは？」
技田「EAPです」

EAP（Extensible Authentication Protocol）

ネットワーク認証で、認証情報をやり取りするための共通の枠組み（プロトコル）。

802.1X
  │
  └─ EAP
       ├─ ID・パスワードを使う方式
       ├─ 証明書を使う方式
       └─ その他の認証方式

---

技田「EAPにもいくつか方式があります。今回はEAP-TLSです」

EAP-TLS

EAP + TLS（Transport Layer Security）

EAPを利用し、TLSと電子証明書を使って認証する方式。

ネットワークへ接続するとき、端末と認証サーバーがそれぞれ相手の証明書を確認する（相互認証）。

• 認証サーバー側： 端末のクライアント証明書を検証し、信頼できる証明書かどうかを確認する。
• 端末側： 認証サーバーの証明書を検証し、正当な接続先であることを確認する。

このように、双方が相手の正当性を確認することで、なりすましによる不正な接続や、偽の認証サーバーへの接続を防ぎやすくなる。

---

兎角「なるほど……。じゃあ、会社が認めた端末だと証明するために、端末に証明書を持たせるんですね」
技田「そういうことです」
兎角「でも、その証明書って……誰が発行するんですか？」

会議室が静かになった。

技田「……そこです」
危田「今回の本当の案件は」
証田「ここから始まります」

第1話の技術まとめ

• 802.1X：建物の入口にある「入館チェック」の仕組み
• EAP：入館チェックで使う「本人確認のやり取りのルール」
• EAP-TLS：「証明書を見せて本人確認する」という具体的な方法

第2話　証明書って誰が発行するの？

翌日。

兎角は証田さんの席へ向かった。

兎角「証明書について教えてください」
証田「もちろん」
兎角「証明書って、そもそも何なんですか？」

証田さんはホワイトボードに書いた。

公開鍵
秘密鍵
電子証明書

兎角「あ、公開鍵と秘密鍵は分かります」
証田「では、電子証明書は？」
兎角「公開鍵が誰のものかを証明するもの？」
証田「その理解で大丈夫です。もう少し正確に言うと、公開鍵と、その鍵の持ち主を識別する情報などを結び付けたものです」

電子証明書

電子証明書には、公開鍵や所有者を識別する情報、有効期間などが含まれる。

端末A
 ↓
公開鍵 ＋ 端末Aを識別する情報
 ↓
電子証明書

ただし、情報を記載するだけでは本当にその公開鍵が端末Aのものなのか、第三者には判断できない。
そこで、信頼できる発行元が証明書に電子署名を付ける。

---

兎角「その第三者がCA？」
証田「そうです」

CA　（Certificate Authority／認証局）

電子証明書を発行する役割を担う仕組み、またはその運用主体。

CAは、証明書に記載する情報などを確認したうえで、自らの秘密鍵を使って証明書に電子署名を付ける。
証明書を受け取った側は、発行元のCAを信頼できるか、署名が正しいか、有効期間内かなどを確認する。
こうした検証を通じて、証明書が信頼できるものかを判断する。

---

兎角「じゃあ、CAが証明書を発行している」
証田「はい」
兎角「……あれ？うち、CAありますよね？」
証田「あります」
兎角「じゃあ、それ使えばよくないですか？」

証田さんが少し黙った。

証田「それを調べるのが次の仕事です」

第2話の技術まとめ

• 電子証明書：公開鍵とその鍵の持ち主を識別する情報などを結び付けたもの
• CA（認証局）：証明書を発行し、秘密鍵で電子署名を付ける機関
• 証明書の検証：発行元への信頼や署名、有効期間などを確認し、証明書を信頼できるか判断すること

第3話　現行CAは何に使われている？

プロジェクトのキックオフ。

ホワイトボードには、「現行PKI調査」と書かれていた。

兎角「現行CAをそのまま端末認証に使えばいいんじゃないんですか？」
技田「技術的には可能です」
運野「その言い方、嫌な予感しかしないんですが」
技田「現行CAはあります。ただし、現在の主な用途はサーバや業務システム向けの証明書です」

現行CA
・Webサーバ証明書
・VPN関連証明書
・業務システム証明書
・サーバ間通信

端末認証
→ 現在は証明書を利用していない

兎角「なるほど」
危田「だから今回、端末認証の仕組みを新たに導入するんです」
兎角「じゃあ、既存CAを端末認証にも使えるようにすればいいんじゃないですか？」
証田「それが可能か、技術面と運用面の両方から検討する必要があります」
統制「現行CAの運用ルールは？」
兎角「……？」
統制「端末認証用の証明書を発行することは、現行のポリシーや運用ルールで想定されていますか？」
証田「CAは『発行できるか』だけで判断するものではありません。
　　　まず、誰に、何の目的で、どんな条件で証明書を発行するのか。そこを明確にする必要があります」
兎角「……今回だったら会社管理端末に、ネットワーク認証目的で？」
証田「それを正式な運用ルールとして定めていますか？」
兎角「……（知らんがな）」

ここで兎角は初めて、「証明書を発行できる」ことと「適切に発行してよい」ことは別だと知る。

証田「PKIには、技術だけではなくポリシーがあります」
兎角「ポリシー？」
証田「CPとCPSです」
兎角「また新しい単語が……」

第3話の技術まとめ

• 現行CAの調査：既存CAの用途や機能、運用ルールを確認し、新たな用途に利用できるかを検討すること
• 技術的な発行可否：CAの機能として、必要な証明書を発行できるかという観点
• 運用・統制面の適切性：誰に、何の目的で、どのような条件で発行するかが定められ、適切に運用できるかという観点

第4話　CPとCPS

証田さんがホワイトボードに書く。

CP
CPS

証田「証明書を発行する仕組みを考えるうえで、重要なものです」
兎角「証明書を発行できるかどうかは、前回調べましたよね？」
証田「はい。ただ、技術的に発行できることと、その証明書をどのようなルールで発行・利用するかは別の話です」
統制「仕組みを作る前に、何をルールとして定めるのかを整理する必要があります」
兎角「なるほど……。そのルールがCPとCPS？」
証田「そうです。まずはCPから説明しましょう」

CP（Certificate Policy／証明書ポリシー）

証明書やPKIを何のために利用し、どのような方針や信頼レベルを求めるのかを定めるもの。

例えば、次のような方針を定める。

• 何のために証明書を利用するか
• どのような対象を想定するか
• どの用途で利用するか
• どの程度の信頼性を求めるか

---

兎角「つまり、『この証明書を何に使い、どんな条件で信頼するのか』という方針ですね」
証田「その理解で大丈夫です。では、その方針を実際のCAの運用にどう落とし込むのでしょう？」
兎角「……それがCPS？」

CPS（Certification Practice Statement／認証局運用規程）

CAが証明書ポリシーなどに基づいて、実際にどのように運用するのかを定める文書。

---

兎角「CPが方針で、CPSが実際の運用方法、ということですか？」
証田「基本的には、その理解でよいです。ただし、CPとCPSの関係や、それぞれに記載する内容は、PKIの設計や運用によって異なります」
統制「大切なのは、文書を作ること自体ではありません。定めた方針と実際の運用が矛盾していないことです」
兎角「方針だけ立派でも、実際には守れないルールだったら意味がない、ということですね」
運野「そうです。現場で実行できる運用になっているかも考えないといけません」
兎角「では、今回の端末認証についても、CPとCPSを確認すればよさそうですね」
証田「はい。現行CAの機能だけでなく、既存のポリシーや運用が今回の用途に適しているかも確認する必要があります」

現行CAのポリシーや運用を調査した結果、課題が見えてきた。

兎角「つまり、現行CAでも技術的にはできるけど……」
証田「既存CAを拡張することもできます。ただ、今回の要件を満たすには、機能だけでなく運用や管理体制も見直す必要があります」
危田「既存システムへの影響も考慮する必要がありますね」
運野「端末認証用の運用も、別に整理した方が管理しやすそうです」
証田「既存CAを拡張する案と、新しいCA基盤を構築する案を比較した結果、今回は既存CAはそのまま利用し、端末認証用のCA基盤を新たに構築する方針が適切だと判断しました」
無茶課長「では、新しいCA基盤を構築しよう」
兎角「……自前CA？」
無茶課長「そうだ」
兎角「CAって作れるんですね」
証田「正確には、CAの仕組みを含むPKI基盤を自社で構築・運用します」

ここから、PKI基盤構築プロジェクトが正式に始まった。

第4話の技術まとめ

• CP（Certificate Policy／証明書ポリシー）：証明書やPKIを何のために利用し、どのようなルールや信頼レベルを求めるのかを定めるポリシー
• CPS（Certification Practice Statement／認証局運用規程）：CAが証明書の発行・更新・失効などを、実際にどのような手順や管理体制で運用するのかを定める文書
• CPとCPSの違い：CPが証明書やPKIに求めるポリシーを示し、CPSがCAの具体的な運用方法を示す。両者の関係や記載範囲は、PKIの設計によって異なる
• 現行CAの評価：発行機能だけでなく、新たな用途に対するポリシーや運用の適合性、既存システムへの影響なども考慮して判断する
• PKI基盤の構築方針：既存CAの拡張と新規構築などの選択肢を比較し、要件に合った構成を選択する

第5話　Root CAと中間CA

CAの構成設計会議。

技田さんが構成図を書く。

CA
 ↓
端末証明書

技田「最初はこれでも動きます」
危田「それセキュリティ的にアウトです」
技田「ですよね」
兎角「何がダメなんですか？」

証田さんが説明する。

証田「CAには、信頼の起点となるCAがあります。それがRoot CAです」

Root CA

PKIにおける最上位のCA。

Root CAの証明書は、信頼の起点となる。
そのためRoot CAの秘密鍵は非常に重要。
もしRoot CAの秘密鍵が侵害されれば、そのPKI全体の信頼に重大な影響が及ぶ。

---

兎角「じゃあRoot CAが全部証明書を発行する？」
証田「それだとRoot CAを常に稼働させる必要があります」
鍵谷「攻撃される機会も増えます」
証田「だから下位のCAを作ります」

Root CA
   ↓
中間CA
   ↓
端末証明書

中間CA（Intermediate CA）

Root CAの下位に位置するCA。

Root CAなどの上位CAの下位に位置するCA。
上位CAとの証明書による信頼関係を構成し、構成に応じて下位CAへの署名や証明書発行などの役割を担う。

---

兎角「じゃあ、実際に端末証明書を発行するのは中間CA？」
証田「今回なら、Issuing CAとして構成します」

Issuing CA

実際に端末やサーバ、ユーザーなどの証明書を発行するCA。

Issuing CAはRoot CAの下位CAなので、広い意味では中間CAに含まれる。

---

兎角「つまり今回の構成は？」
証田「こうです」

Root CA
  │
  │ 信頼
  ↓
Issuing CA
  │
  │ 発行
  ↓
端末証明書

兎角「Root CAはなるべく普段使わない？」
鍵谷「その通りです」
鍵谷「Root CAは通常はオフラインで厳重に保管して、日常的な証明書発行はIssuing CAに任せます」

第5話の技術まとめ

• Root CA（ルート認証局）：PKIにおける信頼の起点となる最上位のCA。その秘密鍵が侵害されると、PKI全体の信頼に重大な影響が及ぶため、厳重な保護が必要
• 中間CA（Intermediate CA）：Root CAなどの上位CAの下位に位置するCA。証明書発行などの役割を分担するために設けられる
• Issuing CA（発行CA）：端末・サーバ・ユーザーなどの証明書を実際に発行する役割を担うCA。中間CAとして構成されることが多い
• Root CAとIssuing CAの分離：Root CAが日常的な証明書発行を担当することを避け、秘密鍵を使用する機会を減らすことで、信頼の起点を保護する

第6話　CAの秘密鍵をどう守る？

設計レビュー。

鍵谷「次に、CA秘密鍵の保護について決めましょう」
兎角「サーバに保存するんじゃないんですか？」
鍵谷「CAの秘密鍵が漏れたらどうなります？」
兎角「……そのCAが発行する証明書の信頼性に影響する？」
鍵谷「そうです。特に信頼の起点であるRoot CAの秘密鍵が侵害されれば、PKI全体の信頼に重大な影響が及びます。日常的に証明書を発行するIssuing CAの秘密鍵も、厳重に保護する必要があります」
危田「それセキュリティ的にかなり重大です」
鍵谷「そこで、秘密鍵を保護する仕組みとしてHSMを検討します」

HSM（Hardware Security Module）

暗号鍵を安全に生成・保管し、暗号処理に利用するための専用ハードウェア。

HSMを利用すると、秘密鍵を一般的なサーバ上にそのまま保存する方式と比べて、秘密鍵の保護を強化できる。
構成によっては、秘密鍵をHSMの外に取り出さずに、電子署名などの暗号処理を実行できる。

今回のようにCAの秘密鍵を保護する場合も、HSMの利用を検討する。

---

兎角「HSMって、秘密鍵を守るための金庫みたいなもの？」
鍵谷「イメージとしては近いです。ただ、金庫にしまうだけではなく、安全に暗号処理を実行するための仕組みも備えています」
兎角「じゃあ、HSMが壊れたら？」
鍵谷「だから、可用性や障害時の復旧も考えます。構成に応じて冗長化やバックアップ、復旧手順を設計する必要があります」
兎角「秘密鍵を守ることと、障害が起きたときに復旧できることの両方が必要なんですね」
鍵谷「その通りです。特にCAの秘密鍵は、単純にコピーして保管すればよいというものではありません」
兎角「……CAを作るだけで、こんなに考えることがあるんですね」

新PKIの基本設計がまとまった。

---

次は、実際に端末証明書を発行するための運用を整理する。

兎角「端末証明書が欲しい場合は、端末担当者が申請する？」
証田「そうです。今回は申請を受けて、対象端末や用途を確認したうえで発行する運用を想定しています」

ホワイトボードに書く。

① 証明書申請
      ↓
② 申請内容確認
      ↓
③ 承認
      ↓
④ 証明書発行
      ↓
⑤ 端末へ設定
      ↓
⑥ EAP-TLSで利用

兎角「この『申請内容の確認』って何を見るんですか？」
証田「例えば、その端末が本当に会社の管理対象なのか」
統制「申請者に申請する権限があるかも確認します」
危田「証明書の用途が適切か、という点も重要です」
証田「申請内容に問題がないことを確認し、用途に合った証明書を発行する必要があります」
兎角「なるほど。申請があったからといって、そのまま発行するわけではないんですね」
統制「そうです。そして、誰が確認し、誰が承認したのかも記録します」
兎角「監査のため？」
証木「監査証跡ありますか？」
兎角「出た……」

証明書の発行フロー

今回のPKIでは、申請 → 審査・確認 → 承認 → 発行という統制されたプロセスを採用する。

これにより、不適切な端末への証明書発行を防ぐとともに、

誰が、何の目的で申請し、誰の確認・承認を経て、どの証明書が発行されたのかを追跡できるようにする。

---

兎角「証明書を発行する仕組みだけじゃなくて、誰に発行してよいのかを判断する仕組みも必要なんですね」
証田「その通りです。CAの秘密鍵を保護することと、適切な手順で証明書を発行すること。その両方が重要です」
統制「手順を定めるだけでなく、実際にその手順に従って処理したことを、記録から確認できるようにしておく必要があります」
兎角「秘密鍵を守ること、発行を統制すること、そして記録を残すことですね」

第6話の技術まとめ

• CA秘密鍵：証明書への署名などに使用する重要な秘密鍵。Root CAとIssuing CAの双方について、適切な保護が必要。特にRoot CAの秘密鍵が侵害されると、PKI全体の信頼に重大な影響が及ぶ。
• HSM（Hardware Security Module）：暗号鍵の安全な生成・保管・利用を支援する専用ハードウェア。CA秘密鍵の保護を強化するために利用できる。
• 可用性・復旧設計：HSMやCAに障害が発生した場合に備え、構成に応じた冗長化・バックアップ・復旧手順を検討する。
• 証明書発行フロー：申請、審査・確認、承認、発行という手順を設け、不適切な証明書発行を防ぐ。
• 発行に関する記録：申請・確認・承認・発行の記録を残し、誰がどのような判断・処理を行ったのかを追跡できるようにする。

第7話　その証明書、本当に信頼できる？

新しいPKIの構築が進み、テスト端末に新しい端末証明書を設定した。

兎角「証明書も発行できましたし、これで接続できるはずですよね？」
技田「では、EAP-TLSの接続試験をしてみましょう」

テスト端末から社内ネットワークへ接続を試みる。

しかし、認証に失敗した。

兎角「えっ、証明書はちゃんと発行されていますよ？」
技田「証明書が発行されていることと、その証明書を信頼できることは別です」
兎角「発行されているのに、信頼できない？」
証田「まずは、どこで証明書を検証しているのか確認しましょう」

調査を進めると、認証サーバーに新しいPKIのRoot CAを信頼するための設定がないことが分かった。

技田「今回の問題は、認証サーバーが新しいRoot CAを信頼していないことですね」
兎角「端末に証明書を設定するだけでは、駄目なんですね」
証田「そうです。証明書を使って認証するには、検証する側が、その証明書を信頼できるか判断できる必要があります」
兎角「その信頼するCAの証明書を登録しておく場所があるんですか？」
証田「あります。これを信頼ストアと呼びます」

信頼ストア

端末やシステムが信頼するCAの証明書などを登録・管理する場所。

例えば、認証サーバーが新しいPKIから発行された端末証明書を検証する場合、信頼ストアに登録されたRoot CAの証明書などを基に、証明書の信頼性を確認する。

今回のように新しいRoot CAを信頼する設定がなければ、正しく発行された端末証明書でも、認証サーバーが信頼性を検証できず、認証に失敗する場合がある。

---

兎角「なるほど。信頼ストアにRoot CAを登録すればいいんですね」
証田「それだけでなく、証明書の発行元を順番にたどって、信頼するRoot CAにつながるかどうかも確認します」
兎角「発行元を順番に？」
証田「例えば、Root CA、Issuing CA、端末証明書という関係です。このような証明書同士のつながりを証明書チェーンと呼びます」

証明書チェーン

端末証明書などから発行元のCAをたどり、最終的に信頼するRoot CAにつながることを確認するための関係。

例えば、次のような構成になる。

Root CA
   ↓
Issuing CA
   ↓
端末証明書

端末証明書を検証する際には、発行元のIssuing CAを確認し、さらに上位のRoot CAまで信頼関係をたどる。

ただし、Root CAにつながることだけで、必ず認証に成功するわけではない。有効期間や証明書の用途など、必要な検証条件も確認する必要がある。

---

兎角「なるほど。信頼ストアに登録して、証明書チェーンを確認するんですね」
証田「そうです。今回確認したのは、認証サーバーが端末の証明書を検証する場面です。ただし、EAP-TLSでは端末側も認証サーバーの証明書を検証します」
兎角「つまり、端末側も信頼設定が必要なんですね」
証田「その通りです。どちらも、証明書を検証する側が適切に信頼できる状態になっている必要があります」

---

兎角「証明書を発行する作業と、信頼できる状態にする作業は別なんですね」
技田「そうです。証明書が正しく発行されていても、検証側の設定が不足していれば、認証に失敗する可能性があります」
証田「さらに、信頼するCAの証明書が登録されていても、それだけで証明書が有効だと判断できるわけではありません」
兎角「有効期間や用途なども確認するんですよね？」
証田「その通りです」

発行と信頼は別

証明書の発行とは、CAが所定の手続きに従って証明書を発行すること。

一方、証明書の信頼とは、証明書を検証する側が、信頼するCAや証明書チェーンなどを基に、その証明書を受け入れられるか判断すること。

証明書の検証では、信頼関係に加えて、例えば次のような点も確認する。

• 証明書の有効期間が切れていないか
• 証明書が想定された用途に適しているか
• 電子署名や証明書チェーンに問題がないか
• 必要な場合、証明書が失効していないか

したがって、証明書を発行するだけでなく、利用する側の信頼設定や検証条件まで含めて設計する必要がある。

第7話の技術まとめ

• 信頼ストア：端末やシステムが信頼するCAの証明書などを登録・管理する場所。
• 証明書チェーン：端末証明書などから発行元のCAをたどり、信頼するRoot CAにつながることを確認するための関係。
• 証明書の検証：信頼関係だけでなく、有効期間や用途、電子署名などの条件も確認すること。
• 発行と信頼は別：証明書が正しく発行されていても、検証側の信頼設定や検証条件が整っていなければ、認証に失敗する場合がある。

第8話　10,000台への全社展開作戦

新しいPKIの基本設計がまとまり、端末認証に必要な証明書を発行する準備が整った。

いよいよ、10,000台の端末への導入計画を立てることになった。

無茶課長「では、10,000台、一斉に切り替えよう」
兎角「課長」
無茶課長「何だ？」
兎角「ダメです」
無茶課長「……」
兎角「まずはPoCを実施します」
技田「おお」
無茶課長「PoC？」

PoC（Proof of Concept／概念実証）

新しい技術や構成が、実際の環境で目的を達成できるかを検証すること。

例

• 証明書の申請・承認フローが機能するか
• Issuing CAから正しく証明書を発行できるか
• 発行した証明書を端末に設定できるか
• EAP-TLSで端末認証が成功するか
• 証明書チェーンを正しく検証できるか
• 許可されていない端末を拒否できるか
• 証明書の失効や更新が想定どおりに機能するか

---

兎角「技術的に動くことを、まず確認するんですね」
技田「そうです。設計上は問題がなくても、実際の環境で想定どおりに動くとは限りません」
危田「正常に接続できることだけでなく、拒否すべき端末を拒否できることも確認してください」
兎角「PoCで技術的な実現性を確認できたら、次はどうするんですか？」
運野「いきなり全社展開するのではなく、まずは一部の部署や拠点で実際に運用してみましょう」
兎角「技術的に動くことが確認できても、実際の業務で問題なく使えるとは限らない、ということですね」
運野「そのとおりです。証明書の申請や更新が滞りなくできるか、問い合わせや障害が発生したときに対応できるかも確認する必要があります」
兎角「なるほど。技術面だけでなく、運用面も確認するんですね」
運野「はい。これをパイロット展開といいます」

パイロット展開

一部の部署・拠点を対象に、新しい仕組みを実際に導入して運用すること。

PoCで技術的な実現性を確認できたら、次は一部の部署・拠点で実際に運用する。

---

運野「ここでは、実際の業務の中で運用が回るかを確認します」
兎角「例えば？」
運野「証明書の申請や更新を担当者が処理できるか、問い合わせが来たときに対応できるか。障害が起きたときの手順も確認します」
兎角「なるほど。システムが動くことと、業務として運用できることは別なんですね」

---

PoCとパイロット展開で問題点を洗い出し、必要な修正を行ったら、対象端末を段階的に増やしていく。

段階展開

対象端末や部署をいくつかのグループに分け、順番に新しい仕組みを適用していくこと。

一度に全ての端末を切り替えるのではなく、各段階で問題がないかを確認しながら進める。

PoC
 ↓
パイロット展開
 ↓
段階展開
   （対象を順次拡大）
 ↓
全社への展開完了

---

兎角は、ここまでの作業をWBSに整理した。

端末認証導入プロジェクト
 ├─ 1. 現状調査
 ├─ 2. 要件定義
 ├─ 3. CP・CPS策定
 ├─ 4. PKI基盤の設計・構築
 ├─ 5. 試験・検証
 │   ├─ 証明書の申請・発行テスト
 │   ├─ 端末認証の動作検証
 │   └─ PoC
 ├─ 6. 端末認証の展開
 │   ├─ パイロット展開
 │   ├─ 段階展開
 │   └─ 全社展開
 └─ 7. 導入完了確認
     ├─ 対象端末への導入状況の確認
     ├─ 運用手順・証明書管理体制の確認
     ├─ 残課題・リスクの確認
     └─ 導入完了判定

兎角「作業を分解しておけば、必要な作業の抜け漏れや、どこに課題があるのかを整理しやすくなります」
技田「構築作業だけでなく、試験や展開も作業として管理するわけですね」
運野「証明書の更新・失効を含めた運用手順も、忘れずに整備してくださいね」
危田「それから、展開中に認証トラブルが発生した場合に備えて、ロールバック手順と切り戻しの判断基準も必要です」
兎角「分かっています。導入できたら終わり、ではありませんからね」
無茶課長「……最初から全社展開しなくてよかったな」
兎角「課長、WBSとリスク一覧を確認してから判断してください」

第8話の技術まとめ

• PoC（概念実証）：新しい技術や構成が、目的を達成できるか検証する。
• パイロット展開：一部の部署・拠点で実際に運用し、技術面と運用面の課題を確認する。
• 段階展開：対象端末を徐々に増やし、問題を確認しながら全社展開する。

第9話　その証明書、ずっと使えるわけじゃない！

全社展開が完了し、端末証明書を使ったネットワーク認証の運用が始まった。

そんなある日、社員が使用していた会社管理端末が盗難に遭った。

兎角「端末には端末認証用の証明書が設定されていますよね？」
危田「そうです。盗難端末が不正に利用されないように対応する必要があります」
兎角「端末の利用を停止するだけでは駄目なんですか？」
証田「端末の利用停止だけでは、証明書の不正利用を防げるとは限りません。証明書そのものへの対応も必要です」
兎角「でも、証明書には有効期限がありますよね？　期限が切れるまで待つわけには……」
危田「それセキュリティ的にアウトです」
兎角「ですよね」
証田「証明書は、発行した後も利用状況や有効期限を管理し、状況に応じて更新や失効などの対応を行う必要があります」
兎角「発行したら終わり、ではないんですね」
運野「今回のような端末の盗難だけでなく、有効期限が近づいたときや、端末を廃棄するときにも対応が必要です」
兎角「証明書を発行するところだけ考えていても、運用は回らないんですね」
証田「こうした、証明書の申請・発行から利用、更新、失効までを継続的に管理することを、証明書のライフサイクル管理といいます。そして証明書失効が必要ですね」

証明書のライフサイクル管理

証明書は、発行後も利用状況や有効期限などを把握し、必要に応じて更新や失効などの対応を行う。

例えば、次のような流れで管理する。

申請・発行
　↓
利用・管理
　↓
利用を継続するか判断
　├─ 継続する → 有効期限などを確認し、必要に応じて更新
　└─ 利用を終了する → 利用停止・削除などを実施し、必要に応じて失効

今回の端末盗難も、証明書の利用を継続できるか判断し、必要な対応を行う場面の一つである。

証明書失効

有効期限が残っている証明書でも、期限を迎える前に、その証明書を有効なものとして扱わないようにする手続き。

例えば、次のような場合に失効を検討する。

• 端末が廃棄・返却され、証明書を使う必要がなくなった
• 端末が盗難・紛失した
• 秘密鍵が漏洩した、または漏洩した疑いがある
• 誤った内容の証明書を発行した

今回のように端末が盗難された場合は、組織のルールに従って証明書を失効させ、不正利用のリスクを抑える。

---

兎角「なるほど。証明書は有効期限が切れるまで、必ず使えるというわけではないんですね」
証田「そのとおりです。ただし、失効させるだけでは十分ではありません」
兎角「えっ、失効させても駄目なんですか？」
証田「失効したことを、認証する側が確認できなければなりません」
兎角「つまり、証明書を失効させることと、失効した証明書を使った接続を拒否することは別なんですね」
証田「そういうことです、そこでCRLです」

CRL（Certificate Revocation List）

CAが公開する、失効した証明書の情報をまとめたリスト。

利用側はCRLを参照し、使用しようとしている証明書が失効していないかを確認する。

CAが証明書を失効
       ↓
失効情報をCRLに反映・公開
       ↓
認証する側がCRLを参照
       ↓
失効した証明書だと確認
       ↓
接続を拒否

※ 失効情報がCRLに反映されるタイミングや、CRLを取得・更新する方法は、システムの構成によって異なる。

---

兎角「失効した証明書の一覧を確認するんですね」
証田「はい。特定の証明書について状態を問い合わせる方法もあります。OCSPです」

OCSP（Online Certificate Status Protocol）

特定の証明書について、失効状態を問い合わせるためのプロトコル。

OCSP Responderと呼ばれる応答側に問い合わせ、証明書の状態を確認する。

認証する側
    ↓ 証明書の状態を問い合わせる
OCSP Responder
    ↓
証明書の状態を応答
    ├─ good（OCSP応答上、失効しているとは確認されていない）
    ├─ revoked（失効している）
    └─ unknown（状態を確認できない、または応答側が状態を把握していない）

CRLが失効した証明書の情報をまとめたリストを参照する方式なのに対し、OCSPでは特定の証明書の状態を問い合わせる。

---

兎角「CRLは失効した証明書の一覧を確認する方法で、OCSPは特定の証明書の状態を問い合わせる方法なんですね」
証田「そのとおりです。どちらを利用する場合も、失効情報を確認できなかったときにどう動くかを決めておく必要があります」
危田「失効を確認できないからといって、無条件に接続を許可してしまえば、セキュリティ上の問題につながる可能性があります」
兎角「失効の手続きだけでなく、その情報を認証側がどう扱うかまで設計する必要があるんですね」

---

数週間後。

運野「証明書の期限が近づいています」
兎角「今度は期限切れですか！？」
運野「まだ切れていません。期限が近づいているので、更新の準備が必要です」
兎角「盗難されたときは期限を待たずに失効させる。今回は期限が切れる前に更新する、ということですね」
運野「そのとおりです。期限が切れてから慌てて対応するのでは遅いですからね」

証明書の有効期間と更新

有効期間

証明書が有効なものとして扱われる期間。証明書には有効期間の開始日時と終了日時が設定されている。

証明書更新

証明書の有効期間が終了する前などに、引き続き利用できるよう、新しい証明書を発行して切り替える手続き。

更新の具体的な手順は運用ルールによって異なる。今回の案件では、定められた申請・審査・承認の手順に従って新しい証明書を発行する。

---

兎角「じゃあ、期限が近づいたら申請して、承認してもらって、新しい証明書を発行するんですね」
運野「はい。ただし、新しい証明書を発行しただけでは終わりません」
兎角「えっ、またですか？」
運野「新しい証明書が端末に設定され、認証に使えることを確認する必要があります。古い証明書をどう扱うかも決めておかなければなりません」
兎角「なるほど。更新は、ただ有効期限の日付を延ばすことではないんですね」
証田「そのとおりです。新しい証明書の発行後も、必要な設定や切り替えを行い、古い証明書の扱いを運用ルールに従って管理します」

---

兎角「そうなると、どの端末の証明書がいつ切れるのか、把握しておく必要がありますね」
運野「そうです。証明書の台帳を整備しましょう」
兎角「証明書ID、利用端末、用途、発行日、有効期限、管理者……」
運野「はい。失効した証明書についても、必要な情報を記録します」
兎角「更新の進捗も分かるようにしたいですね。申請中なのか、承認済みなのか、新しい証明書の設定まで終わっているのか」
運野「それなら、更新漏れや対応状況も確認しやすくなりますね」
兎角「……これ、普通に構成管理じゃん」
運野「PKIもIT資産ですからね」
兎角「証明書を発行する仕組みを作るだけじゃなくて、発行後の管理体制まで作らないといけないんですね……」

第9話の技術まとめ

• 証明書のライフサイクル管理：証明書の申請・発行から利用、更新、失効までを継続的に管理すること。
• 証明書失効：有効期限が残っていても、失効が必要と判断された証明書を期限前に無効化する手続き。
• CRL（Certificate Revocation List）：失効した証明書の情報をまとめたリスト。利用側が参照して失効状態を確認する。
• OCSP（Online Certificate Status Protocol）：特定の証明書の失効状態を問い合わせるためのプロトコル。
• 証明書の有効期間：証明書には有効期間が設定されており、期限を過ぎた証明書は通常、有効な証明書として利用できない。
• 証明書更新：期限切れによる認証トラブルを防ぐため、新しい証明書を発行し、必要な設定や切り替えを行う。

第10話　監査で怒られたぞ

数か月後。

全社展開が完了した。

新しいPKI基盤が稼働し、端末認証も正常に動いている。
無茶課長は満足そうだ。

無茶課長「これでプロジェクト完了だな！」

そこへ証木さんが入ってくる。

証木「お疲れ様です」
無茶課長「監査ですね？」
証木「はい。今回は新しいPKI基盤の運用状況を確認します」
無茶課長「今回は大丈夫です。ちゃんと資料も揃っていますから」
証木「では、確認します」

嫌な予感。

---

証木「まず、CPとCPSはありますか？」
兎角「あります」
証木「CPSに記載された証明書の発行手順と、実際の運用は一致していますか？」
兎角「……はい。申請から審査、承認、発行までの手順と記録を確認できます」
証木「では、証明書の申請・承認・発行・失効の記録は？」
兎角「あります」
証木「CA管理者の権限管理記録は？」
危田「あります。管理者に付与された権限と、定期的な確認の記録を管理しています」
証木「HSMの管理記録は？」
鍵谷「あります。管理手順と、必要な操作の記録も確認できます」
証木「バックアップ・復旧手順は？」
運野「あります。担当者と手順を定めています」
証木「証明書台帳の棚卸し記録は？」
運野「あります。発行状況や有効期限、失効状況などを確認しています」
証木「分かりました」
無茶課長「どうですか？　問題ないでしょう？」
証木「では、もう少し確認しましょう」
無茶課長「まだあるのか……」

監査証跡

業務やシステムで行われた処理・操作・判断などを、後から確認できるように残した記録。

PKIでは、例えば次のような記録が監査証跡になる。

• 証明書の申請・承認・発行・失効の記録
• CA管理者の権限付与・変更の記録
• CAやHSMに対する重要な操作の記録
• 証明書台帳の棚卸しや、運用手順の見直しの記録

監査では、単に記録が存在するかだけでなく、必要な処理が適切に行われたことを確認できるかが重要になる。

---

証木「では、実際の証明書発行記録をいくつか確認させてください」
兎角「はい」
証木「この申請は、承認されてから発行されていますね」
兎角「はい。手順どおりです」
証木「では、こちらは？」
兎角「……こちらも記録上は、手順どおりです」
証木「記録上は、というのは？」
兎角「えっ？」
証木「記録があることと、実際に手順どおり処理されたことは同じでしょうか？」
兎角「……記録が正しく残されていることも、確認する必要があるんですね」
証木「そのとおりです。記録だけを見て判断するのではなく、必要に応じて関連する記録や実際の運用と照らし合わせます」
統制「文書に書かれたルール、記録に残された処理、実際の運用。この3つが整合していることが重要です」
兎角「手順書があって、記録が残っていても、それだけで適切な運用だと証明できるわけではないんですね」
証木「はい。監査では、定めたルールが実際に守られているか、管理の仕組みが有効に機能しているかを確認します」
無茶課長「……資料を作っておけばいい、という話ではないんだな」
兎角「課長、最初からそういう話です」

---

証木「今回確認した範囲では、必要な記録が整備され、運用状況も確認できました」
無茶課長「よし！　これで本当に完了だな！」
証木「ただし、監査が終わっても管理は続きます」
無茶課長「……ですよね」

継続的なレビューと管理

PKIは、一度構築すれば永久に同じ状態で使い続けられるものではない。

組織やシステムの構成、脅威、運用体制などが変化すれば、ルールや管理方法の見直しが必要になる。

例えば、次のような管理を継続する。

• CP・CPSの見直し：証明書の利用方針やCAの運用方法が、現在の環境やリスクに合っているか確認する。
• 権限管理の確認：CA管理者などの権限が適切か、不要な権限が残っていないかを確認する。
• 証明書台帳の棚卸し：証明書の利用状況、有効期限、更新・失効状況などを確認する。
• バックアップ・復旧手順の検証：必要なときに復旧できるよう、手順や体制が有効であることを確認する。
• 運用手順のレビュー：実際の運用と手順書にずれがないか、改善すべき点がないかを確認する。

※ 見直しや確認の頻度・範囲は、組織の方針やリスク、適用される要求事項に応じて定める。

---

運野「証明書の更新や失効も、これからずっと続きますからね」
危田「セキュリティ上のリスクも変化します。導入時に決めたルールが、いつまでも適切とは限りません」
鍵谷「CAやHSMの管理も同じです。鍵を安全に扱うための仕組みを、維持していく必要があります」
兎角「つまり、PKIは構築して終わりではなく、運用しながら管理し続けるものなんですね」
証木「そのとおりです」
無茶課長「……プロジェクトが終わったら、少しは楽になると思ったんだが」
証木「監査はプロジェクト完了で終わりではありません。」
無茶課長「……監査で怒られなかったのに、なぜか宿題が増えたぞ！」

第10話の技術まとめ

• 監査証跡：処理・操作・判断などを後から確認できるように残した記録。PKIでは証明書の発行・失効や管理者権限の変更などが対象になる。
• 文書・記録・実態の整合性：手順書が存在し、記録が残っているだけでなく、実際の運用がルールに沿っていることが重要。
• 継続的なレビュー：環境やリスクの変化に応じて、CP・CPSや運用手順を見直すこと。

エピローグ　そして、次の案件へ

数日後。

兎角は、プロジェクトの振り返り資料をまとめていた。
画面の端には、プロジェクトの最初に書いたメモが残っている。

私物PCが社内LANに接続できる

兎角「……ここから始まったんだよな」

最初は、証明書を誰が発行するのかさえ分からなかった。
兎角は、これまでに学んだ用語を振り返り、PKIの全体像を整理した。

【ルール・運用方針】
CP / CPS
       ↓
【証明書を発行する基盤】
PKI / CA / Root CA / 中間CA / Issuing CA / HSM
       ↓
【証明書による端末認証】
電子証明書 / 証明書チェーン / 信頼ストア / 802.1X / EAP-TLS
       ↓
【証明書のライフサイクル管理】
申請・発行 / 有効期間 / 更新 / 失効 / CRL / OCSP
       ↓
【運用の維持・検証】
PoC / パイロット展開 / 段階展開 /  監査証跡 / 監査 / 継続的な見直し

兎角「証明書を発行する仕組みだけじゃなくて、信頼できるように設計して、使い続けられるように管理する。全部、つながってるんだな」

PKIは、CAサーバーを構築して終わりではない。ルールの策定から証明書の発行・利用・管理、そして運用の検証まで、一連の仕組みとして考える必要がある。

兎角「……少しは成長したかな」

そこへ、無茶課長がやってきた。

無茶課長「兎角君、次の案件だ」
兎角「……今度は何ですか？」

無茶課長は、一枚の資料を置いた。
そこには、大きくこう書かれていた。

『時代はゼロトラストだ！』

兎角「…………」
無茶課長「何を根拠に信頼していますか、ってやつだな！」
兎角「課長、それ、証木さんの台詞です」
無茶課長「細かいことはいい。次はゼロトラスト基盤の標準化だ！」
兎角「いや、まだ要件も決まってないじゃないですか！」
無茶課長「監査で怒られたぞ」

兎角「（少しは自分で考えろや！！）」

――YARAKASHI株式会社 情報システム部の戦いは続く。

PKI基盤構築・端末認証導入プロジェクト　完

そして、次の案件へ。