【週次復習】PKIと認証の流れを整理する

これまでの1週間、情報処理安全確保支援士（SC）試験の核となる「暗号技術」と「認証技術」について、かなり濃密な内容を学習してきました。お疲れ様でした。

今週学んだ内容は、単独で存在する知識ではなく、すべてが「信頼の連鎖」と「正当性の証明」のために繋がっています。今回は、第3週の総まとめとして、PKI（公開鍵基盤）と認証技術がどのように連携し、システム全体の安全性を担保しているのか、その全体像を整理します。

この「振り返り」こそが、知識を長期記憶に定着させ、午後試験の記述問題で「使える知識」へと昇華させる鍵となります。

はじめに:なぜ「復習」で合格率が変わるのか

情報処理安全確保支援士試験は、単語を覚えているだけでは太刀打ちできません。「なぜその技術が必要なのか」「構成要素が欠けるとどうなるのか」という因果関係を理解しているかが問われます。

今週取り扱った「PKI」と「認証」は、まさにインターネットセキュリティの根幹です。

PKI: 通信相手が本物であることを証明する（インフラ）
認証: 利用者が本物であることを確認する（プロセス）

この2つは車の両輪です。PKIがなければ、私たちは偽の銀行サイトに認証情報を送信してしまうかもしれません。認証が弱ければ、どれだけ通信が暗号化されていても、不正なユーザーにデータを渡してしまいます。

本記事では、これまでの記事で学んだ点と点を線で結び、面として理解を深めることを目的とします。さらに、試験対策だけでなく、実務での応用シーンや、陥りがちな誤解についても詳しく解説していきます。

1. PKI（公開鍵基盤）の完全理解:信頼の構築

まず、週の前半で学んだPKIについて整理しましょう。PKIは「公開鍵が本当にその持ち主のものであること」を第三者が証明する仕組みでした。

1-1. 信頼を支える4つの柱（CA, RA, CP, CPS）

PKIの信頼性は、技術的な暗号強度だけでなく、運用ルールと組織体制によって支えられています。試験でも、これらの用語の定義と役割分担は頻出です。

CA（Certification Authority:認証局）

デジタル証明書を発行し、失効情報（CRL）を管理する組織です
PKIの頂点（または中間）に位置し、自らの秘密鍵で署名を行うことで証明書の正当性を保証します
ルートCAの自己署名証明書は、ブラウザやOSにあらかじめ「信頼されるルート証明書」としてインストールされており、これが「信頼の起点（トラストアンカー）」となります
CAの役割は極めて重大であり、万が一CA自身が侵害されると、PKI全体の信頼が崩壊します。そのため、CAの秘密鍵は、HSM（Hardware Security Module）と呼ばれる物理的に隔離された専用ハードウェア内で厳重に管理されます

RA（Registration Authority:登録審査局）

証明書の発行申請を受け付け、申請者が本人であるかを審査します
RAはあくまで「審査」の窓口であり、実際の証明書発行（署名）はCAが行います
小規模な環境ではCAとRAが同一組織であることも多いですが、役割としては明確に分かれています
RAの審査プロセスには、身分証明書の確認、企業の登記情報の確認、ドメイン所有権の確認などが含まれます
EV証明書（Extended Validation Certificate）の場合、RAはより厳格な審査を実施し、企業の実在性と法的実体を確認します

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

「証明書をどのような目的で、どの程度の信頼性レベルで発行するか」を定めた方針書です
CPは「何をするか（What）」を定義したものであり、利用者（Relying Party）がその証明書を信頼してよいか判断する基準となります
例えば、「個人向けメール署名用」と「サーバー認証用」では、求められる審査レベルや用途が異なります
CPには、証明書のライフサイクル全体（申請、発行、更新、失効、廃棄）における方針が記載されます

CPS（Certification Practice Statement:認証局運用規定）

CPに基づいて、「具体的にどのように業務を運用するか」を定めた手順書です
CPSは「どうやって守るか（How）」を定義したものです
秘密鍵の管理方法（保管場所、アクセス制御、バックアップ手順）、建物の入退室管理、監査ログの保存期間などが詳細に記載されます
CPSは、WebTrustやETSI（欧州電気通信標準化機構）などの外部監査基準に準拠していることが求められます

1-2. X.509証明書の構造と「信頼の連鎖」

デジタル証明書（X.509）は、単なる電子ファイルではありません。そこには、厳格な検証プロセスに耐えうる情報が詰まっています。

証明書の主要な構成要素

バージョン: X.509のバージョン番号（現在はv3が主流）
シリアル番号: CAが発行した証明書を一意に識別する番号。失効時の特定に使用
署名アルゴリズム: 証明書の署名に使用されたアルゴリズム（例:SHA-256 with RSA）
発行者（Issuer）: 証明書を発行したCAの識別名（DN: Distinguished Name）
有効期間: 証明書の有効開始日時と終了日時
サブジェクト（Subject）: 証明書の主体者の識別名。CN（Common Name）には、Webサーバーの場合はFQDN（完全修飾ドメイン名）が入ります
公開鍵情報: 主体者の公開鍵と、その鍵のアルゴリズム、鍵長
拡張フィールド（v3）:
- Subject Alternative Name（SAN）: 複数のドメイン名を1つの証明書でカバーする場合に使用
- Key Usage: 証明書の用途（デジタル署名、鍵暗号化など）を制限
- Extended Key Usage: より詳細な用途（サーバー認証、クライアント認証、コード署名など）を指定
- CRL Distribution Points: CRLの取得先URL
- Authority Information Access（AIA）: OCSP レスポンダのURLや、上位CA証明書の取得先
署名値: 証明書全体のハッシュ値を、CAの秘密鍵で暗号化したもの

検証プロセス（信頼の連鎖）

クライアント（Webブラウザなど）がサーバーから証明書を受け取った際、以下の手順で検証を行います。

署名の検証:
- 証明書の「発行者（Issuer）」フィールドを確認し、その上位CAの証明書を取得
- 上位CAの公開鍵を使って、証明書に付与された署名値を復号
- 復号して得られたハッシュ値と、証明書の本体部分から独自に計算したハッシュ値を比較
- 両者が一致すれば、「証明書が改ざんされていない」かつ「正当なCAが発行した」ことが証明されます
有効期限の確認:
- システムの現在時刻と、証明書の「Not Before」「Not After」を比較
- 有効期間外であれば、証明書は無効と判断
失効確認:
- OCSPまたはCRLを参照し、証明書が無効化されていないかを確認
- 後述するOCSPステープリングが使われている場合、サーバーから事前に取得したOCSPレスポンスを検証
用途の確認:
- 証明書の「Extended Key Usage」が、実際の用途（例:TLSサーバー認証）と一致しているか確認
ドメイン名の確認:
- 接続先のURLのホスト名と、証明書のCN（Common Name）またはSAN（Subject Alternative Name）が一致しているか確認

このプロセスを、ルートCAにたどり着くまで繰り返すのが「信頼の連鎖（Chain of Trust）」です。途中で一つでも検証に失敗すれば、ブラウザは警告画面を表示します。

信頼の連鎖における重要ポイント

試験では、「中間証明書が送信されない場合、どうなるか」という問題がよく出題されます。信頼の連鎖は、エンドエンティティ証明書（サーバー証明書）→中間CA証明書→ルートCA証明書という順序で検証されます。もし中間CA証明書がサーバーから送信されない場合、クライアントは信頼の連鎖を完成できず、証明書エラーとなります。

一部のブラウザは、AIA（Authority Information Access）拡張フィールドに記載されたURLから中間証明書を自動取得する機能を持っていますが、これに依存するのは望ましくありません。サーバー側で適切に中間証明書を含めて送信する設定が必要です。

1-3. 有効性確認の要:OCSPとCRL

証明書の信頼性を維持するためには、「後出しで無効にする仕組み」が不可欠です。秘密鍵が漏えいしたり、社員が退職したりした場合、証明書を即座に無効化（失効）する必要があります。

比較項目	CRL (Certificate Revocation List)	OCSP (Online Certificate Status Protocol)
データの形式	失効した証明書のシリアル番号のリスト（一覧表）	特定の証明書のステータスを問い合わせるリクエスト/レスポンス
クライアントの負荷	リスト全体をダウンロードして解析するため、負荷が高い	対象の証明書について「Good/Revoked/Unknown」を受け取るだけなので軽量
リアルタイム性	次の発行タイミングまで反映されない（タイムラグあり）	OCSPレスポンダが最新情報を反映していれば、比較的リアルタイム
プライバシー	誰の証明書を検証しているか外部に漏れない	どのサイトにアクセスしようとしているかがOCSPレスポンダに知られる可能性がある
可用性	一度ダウンロードすればオフラインでも確認可能	OCSPレスポンダが停止すると確認できない
データサイズ	証明書の発行数が多いと、CRLファイルが巨大化（数MBになることも）	1件あたり数百バイト程度

CRLの詳細

CRLは、CAが定期的（例:24時間ごと）に発行する、失効済み証明書のリストです。CRL自体もCAの秘密鍵で署名されており、改ざんを検知できます。

CRLには以下の情報が含まれます:

発行者: CRLを発行したCAの識別名
発行日時と次回発行予定日時: CRLの有効期間
失効証明書のリスト: 各エントリには、証明書のシリアル番号、失効日時、失効理由（keyCompromise、certificateHold、affiliationChangedなど）が含まれます
署名: CRL全体の署名値

CRLには「完全CRL（Full CRL）」と「差分CRL（Delta CRL）」があります。差分CRLは、前回の完全CRLからの変更分だけを含むため、データサイズを削減できます。

OCSPの詳細

OCSPは、RFC 6960で定義されたプロトコルです。クライアントは、確認したい証明書のシリアル番号を含むOCSPリクエストを、OCSPレスポンダ（通常はCAが運営）に送信します。

OCSPレスポンスには、以下のいずれかのステータスが返されます:

good: 証明書は有効
revoked: 証明書は失効済み（失効日時と理由も含まれる）
unknown: OCSPレスポンダがその証明書の状態を知らない

OCSPレスポンス自体も署名されており、その署名鍵は「OCSP Signing」という拡張属性を持つ専用の証明書で保護されています。

OCSPステープリング（OCSP Stapling）の重要性

OCSPステープリング（RFC 6066）は、TLS拡張機能の一つです。この仕組みでは:

Webサーバーが定期的（例:数時間ごと）にOCSPレスポンダにアクセスし、自身の証明書のステータスを取得
取得したOCSPレスポンス（署名付き）をキャッシュ
クライアントとのTLSハンドシェイク時に、証明書と一緒にOCSPレスポンスを送信（「ステープル」する）
クライアントは、受け取ったOCSPレスポンスの署名を検証し、証明書の有効性を確認

OCSPステープリングの利点:

クライアントのプライバシー保護: クライアントがOCSPレスポンダに直接問い合わせないため、アクセス先のサイトがOCSPレスポンダ（CAが運営）に知られない
パフォーマンス向上: クライアントが追加の通信を行う必要がなく、TLS接続の確立が高速化
可用性向上: OCSPレスポンダが一時的に停止していても、サーバーにキャッシュされたレスポンスで検証可能

午後試験では、「OCSPの課題を指摘し、それを解決する技術を述べよ」という形式で、OCSPステープリングを答えさせる問題が出題されます。

2. 認証技術の深化:「誰であるか」を確定する

PKIで「通信相手（サーバーなど）」の正当性が確認できたら、次は「利用者」の正当性を確認します。

2-1. 多要素認証（MFA）の必然性

「知識（パスワード）」「所持（スマホ・トークン）」「生体（指紋・顔）」の3要素のうち、2つ以上を組み合わせる多要素認証は、もはや必須の要件となりました。

多要素認証の安全性の論理構成

パスワードは、サーバーへのサイバー攻撃やフィッシングで漏えいするリスクが高い（知識の脆弱性）
しかし、攻撃者がパスワードを盗んでも、物理的なスマホ（所持情報）や本人の指紋（生体情報）までは遠隔から盗めない
したがって、異なる属性の要素を組み合わせることで、攻撃のハードルを劇的に上げることができる

多要素認証の実装パターン

実務では、以下のような組み合わせが一般的です:

パスワード + SMS認証コード
- 最も普及している方式
- ただし、SIMスワップ攻撃（携帯電話会社を騙して電話番号を乗っ取る攻撃）や、SMSインターセプト（SS7プロトコルの脆弱性を悪用）のリスクがある
- コストが低く導入しやすい反面、セキュリティレベルは中程度
パスワード + TOTP（Time-based One-Time Password）
- Google Authenticatorなどの認証アプリを使用
- 共有秘密鍵とタイムスタンプから、30秒ごとに変わる6桁のコードを生成
- オフラインでも動作し、SMSより安全
- ただし、認証アプリをインストールしたデバイスが盗まれると危険
パスワード + ハードウェアトークン（FIDO）
- YubiKeyなどの物理的なセキュリティキーを使用
- フィッシング耐性があり、最もセキュアな方式
- デバイスの購入・配布コストがかかる
生体認証 + PIN（デバイスロック）
- スマートフォンの指紋認証や顔認証とPINを組み合わせる
- 生体認証は「所持（デバイス）」と「生体」の2要素と見なせる場合がある
- ただし、生体認証が単なるデバイスロックの解除であれば、その後の認証が「所持」1要素のみとなる点に注意

2段階認証（2Step）と2要素認証（2FA）の違い

試験でも頻出のポイントです:

2段階認証（2-Step Verification）: 認証を2回行うこと。例えば、「パスワード」の後に「秘密の質問」を求める形式。ただし、両方とも「知識」要素なので、セキュリティ強度の向上は限定的
2要素認証（2-Factor Authentication）: 異なる要素（知識・所持・生体）を2つ組み合わせること。「パスワード（知識）+ スマホアプリのOTP（所持）」など

真のセキュリティ強化には、「異なる属性の要素」を組み合わせる2要素認証が必要です。

2-2. パスワードレスの決定版:FIDO認証

今週のハイライトの一つであるFIDO（Fast Identity Online）。これは「認証器（スマホなど）」と「サーバー」の間で、**PKIの技術（公開鍵暗号）**を使って認証を行う仕組みです。

FIDO認証のフロー

登録時（Registration）:
- ユーザーは、サービスのWebサイトで「FIDO登録」を開始
- 認証器（スマホや専用キー）内で、公開鍵と秘密鍵のペアを生成
- 秘密鍵は認証器の安全な領域（Secure Enclave、TPMなど）に保存され、外部に出ることはない
- 公開鍵だけがサーバーに登録される
- この時、ユーザーは生体認証やPINで「ローカル認証」を行い、登録操作が本人によるものであることを確認
認証時（Authentication）:
- ユーザーがログインを試みると、サーバーは「チャレンジ（ランダムなデータ）」を生成して送信
- ユーザーは認証器のロックを解除（生体認証やPIN入力）
- 認証器は、チャレンジとオリジン（アクセス先のドメイン）を含むデータに対し、保存されている秘密鍵で署名
- 署名されたデータ（アサーション）がサーバーに送信される
- サーバーは、登録済みの公開鍵で署名を検証
- 署名が正しく、オリジンも正しければ、認証成功

FIDO2（WebAuthn + CTAP）の構成

FIDO2は、以下の2つの仕様から構成されます:

WebAuthn（Web Authentication）: ブラウザとWebサーバー間の認証プロトコル。W3Cが標準化
CTAP（Client to Authenticator Protocol）: ブラウザ（クライアント）と認証器（Authenticator）間の通信プロトコル。USB、NFC、Bluetoothなどで接続

FIDO認証の革新的な点

秘密鍵がネットワーク上を流れない:
- 従来の認証では、パスワード（秘密情報）がサーバーに送信され、サーバー側で保存されます
- FIDOでは、秘密鍵は認証器内に留まり、署名結果だけが送信されます
- サーバーが侵害されても、秘密鍵は漏えいしません
生体情報もネットワーク上を流れない:
- 生体認証は「認証器のロック解除」に使われるだけで、生体情報自体はローカルに保存され、外部に送信されません
- プライバシー保護の観点からも優れています
フィッシング耐性:
- 署名の対象に「オリジン（ドメイン名）」が含まれます
- 攻撃者が偽サイト（例:goog1e.comなど）を作っても、オリジンが異なるため、署名検証が失敗します
- ユーザーが気づかずに偽サイトでFIDO認証を試みても、認証は成功しません
リプレイ攻撃への耐性:
- 毎回異なるチャレンジが使用されるため、盗聴した署名データを再利用する攻撃は無効です

SC試験での出題ポイント

「FIDOがフィッシング攻撃に強い理由を述べよ」→「署名の対象にオリジン（ドメイン）が含まれるため、偽サイトでは検証が失敗する」
「FIDOで生体情報が漏えいしない理由を述べよ」→「生体認証はローカル（認証器内）でのみ行われ、ネットワーク上を流れない」
「パスワード認証と比較したFIDOの利点」→「秘密鍵がサーバーに保存されないため、サーバー侵害時の漏えいリスクがない」

2-3. 利便性と管理:シングルサインオン（SSO）

最後に、ユーザー体験を向上させるSSOです。ケルベロス認証の仕組みを復習しましょう。

ケルベロス認証の構成要素

KDC（Key Distribution Center）: 認証サービスとチケット発行サービスを統合した中核サーバー
- AS（Authentication Server）: ユーザーの身元を確認し、TGT（Ticket Granting Ticket）を発行
- TGS（Ticket Granting Server）: TGTを確認し、利用したいサービス向けのST（Service Ticket）を発行
クライアント: ユーザーが使用する端末
サービスサーバー: ファイルサーバー、メールサーバーなど、実際に業務で使用するサーバー

ケルベロス認証の詳細フロー

AS_REQとAS_REP（TGTの取得）:
- ユーザーがログイン時にパスワードを入力
- クライアントは、ユーザーIDを含むAS_REQ（Authentication Service Request）をASに送信
- ASは、ユーザーを認証し、TGTを発行してAS_REP（Authentication Service Reply）として返送
- TGTは、「TGS共通鍵」で暗号化されており、クライアントには解読できません
- 同時に、「ユーザーとクライアントの共通鍵」で暗号化されたセッション鍵も送られます
TGS_REQとTGS_REP（STの取得）:
- クライアントが特定のサービス（例:ファイルサーバー）を利用したいとき、TGTをTGSに提示
- TGSは、TGTを復号してユーザーの身元を確認
- サービス向けのST（Service Ticket）を発行してTGS_REPとして返送
- STは、「サービスサーバーとKDCの共通鍵」で暗号化されています
AP_REQとAP_REP（サービスへのアクセス）:
- クライアントは、STをサービスサーバーに提示（AP_REQ: Application Request）
- サービスサーバーは、STを復号してユーザーの身元を確認し、アクセスを許可
- 必要に応じて、サービスサーバーはAP_REP（Application Reply）で応答

ケルベロス認証の重要ポイント

チケットの有効期限: TGTやSTには有効期限（通常は8〜24時間）が設定されており、期限切れ後は再認証が必要です。これにより、盗まれたチケットの悪用期間を制限します
時刻同期の必須性: ケルベロスは、リプレイ攻撃を防ぐためにタイムスタンプを使用します。そのため、KDC、クライアント、サービスサーバーの時刻が同期している必要があります（通常、NTPを使用）。時刻のずれが大きいと認証が失敗します

パスワードをネットワーク上で送信しない: 認証時、クライアントはパスワード自体を送るのではなく、パスワードから導出した鍵で暗号化したデータを送ります。これにより、盗聴によるパスワード漏えいを防ぎます
相互認証: ケルベロスでは、サービスサーバーもクライアントに対して自身の正当性を証明します（AP_REPによる）。これにより、偽サーバーによるなりすましも防げます

ケルベロス認証の課題

KDCが単一障害点（SPOF）: KDCが停止すると、すべてのユーザーが認証できなくなります。そのため、KDCの冗長化（複数台のKDCを配置）が重要です
初期導入の複雑さ: すべてのサービスサーバーとKDCの間で共通鍵を事前配布する必要があり、大規模環境では管理が煩雑になります
クロスドメイン認証の難しさ: 異なる組織（異なるKDC）間での認証連携は、信頼関係の設定が複雑です

3. PKIと認証の融合:セキュアな通信の確立

ここまで個別に見てきた要素技術が、実際のWebアクセス（HTTPS）でどのように組み合わされているのか、統合的な視点で確認します。

3-1. SSL/TLSハンドシェイクにおけるPKI

私たちがブラウザでHTTPSサイトにアクセスするとき、裏側では一瞬のうちにPKIを利用した「サーバー認証」が行われています。

TLSハンドシェイクの詳細フロー（TLS 1.2の例）

Client Hello:
- クライアントが、対応している暗号スイート（暗号化アルゴリズムの組み合わせ）のリストをサーバーに送信
- クライアントが生成したランダムな数値（Client Random）も送信
- サーバー名表示（SNI: Server Name Indication）拡張により、アクセス先のホスト名も送信
Server Hello:
- サーバーが、クライアントの提案から暗号スイートを1つ選択
- サーバーが生成したランダムな数値（Server Random）も送信
Certificate:
- サーバーが自身の証明書（サーバー証明書）を送信
- 中間CA証明書も一緒に送信されるのが一般的
- ここでPKIが登場: クライアントは証明書の検証を実施
  - 署名検証（信頼の連鎖）
  - 有効期限の確認
  - 失効確認（OCSPまたはCRL）
  - ドメイン名の一致確認（CNまたはSAN）
Server Key Exchange（使用する鍵交換方式による）:
- DHE（Diffie-Hellman Ephemeral）やECDHE（Elliptic Curve DHE）を使う場合、サーバーは鍵交換に必要なパラメータを送信
- これらの方式は、PFS（Perfect Forward Secrecy:前方秘匿性）を実現します
Server Hello Done:
- サーバーが、ハンドシェイクの最初のフェーズを完了したことを通知
Client Key Exchange:
- クライアントは、Pre-Master Secret（共通鍵の元となる秘密情報）を生成
- RSA鍵交換の場合、サーバー証明書の公開鍵でPre-Master Secretを暗号化してサーバーに送信
- DHE/ECDHEの場合、クライアント側の鍵交換パラメータを送信
Master Secretの生成:
- クライアントとサーバーの両方が、Pre-Master Secret、Client Random、Server Randomを使って、Master Secretを導出
- このMaster Secretから、実際の暗号通信に使う鍵（セッション鍵）を生成
Change Cipher Spec:
- クライアントとサーバーが、「以降の通信は暗号化する」ことを宣言
Finished:
- 暗号化された最初のメッセージとして、ハンドシェイク全体のハッシュ値を送信
- 双方が検証し、ハンドシェイクが改ざんされていないことを確認
暗号化通信の開始:
- 以降、すべてのHTTPデータは、セッション鍵を使った共通鍵暗号（AESなど）で暗号化されます

TLS 1.3での変更点

TLS 1.3では、ハンドシェイクが簡略化され、往復回数が削減されました（1-RTT）:

Server Key Exchangeなどの個別メッセージが統合され、Server HelloとCertificateが同時に送信される
RSA鍵交換が廃止され、DHE/ECDHEのみサポート（PFSが必須に）
0-RTT（ゼロラウンドトリップタイム）モードにより、再接続時の遅延をさらに削減（ただし、リプレイ攻撃のリスクあり）

中間者攻撃（MITM）の脅威

もし、このプロセスでサーバー証明書の検証が不十分だと、中間者攻撃（MITM: Man-in-the-Middle）を許してしまいます。

攻撃シナリオ:

攻撃者が、クライアントとサーバーの間に割り込む（公衆Wi-Fiなど）
クライアントからのClient Helloを傍受し、攻撃者自身がサーバーとして応答
攻撃者が自己署名証明書や、盗んだ証明書を提示
クライアントが証明書を検証せずに受け入れてしまうと、クライアントは攻撃者との間で暗号化通信を確立
攻撃者は、クライアントからのデータを復号し、内容を盗聴・改ざんした後、本物のサーバーに送信
サーバーからのレスポンスも同様に攻撃者を経由

この攻撃を防ぐために、証明書の厳密な検証が不可欠です。

3-2. クライアント証明書による相互認証（mTLS）

通常のWebサイトは「サーバー認証」だけですが、企業内の重要システムや、ゼロトラスト環境では「クライアント認証」も併用されます。これを相互TLS（mTLS: Mutual TLS）と呼びます。

mTLSの仕組み

通常のTLSハンドシェイクに加えて、以下のステップが追加されます:

Certificate Request:
- Server Hello Doneの前に、サーバーがクライアントに対して「証明書を提示せよ」と要求
- サーバーは、信頼するCAのリスト（Distinguished Namesのリスト）も送信
Client Certificate:
- クライアントは、端末にインストールされたクライアント証明書を送信
- 対応する秘密鍵は、クライアント端末の安全な領域（証明書ストア、TPMなど）に保存されています
Certificate Verify:
- クライアントは、ハンドシェイク全体のハッシュ値に対し、クライアント証明書の秘密鍵で署名
- この署名をサーバーに送信
サーバー側の検証:
- サーバーは、クライアント証明書の検証を実施
  - 信頼するCAから発行された証明書か
  - 有効期限内か
  - 失効していないか
- Certificate Verifyの署名を、クライアント証明書の公開鍵で検証
- すべての検証が成功して初めて、クライアントの接続を許可

mTLSの活用シーン

ゼロトラストアーキテクチャ: ネットワークの境界防御に依存せず、すべてのアクセスを検証する考え方。デバイス認証（mTLS）とユーザー認証（ID・パスワード+MFA）の両方を必須化
API間通信: マイクロサービスアーキテクチャにおいて、サービス間の通信をmTLSで保護。各サービスにクライアント証明書を配布し、相互に認証
企業VPN代替: リモートワーク環境で、VPNの代わりにmTLSによるデバイス認証を実施。許可されたデバイスからのみ社内システムにアクセス可能

mTLSの利点

「ID・パスワードを知っている人」だけでなく、「会社が許可した特定の端末（証明書が入っている端末）を持っている人」だけしか接続できない
これは「所持認証」の一種であり、多要素認証の一要素として機能
証明書の有効期限を短く設定することで、デバイスの定期的な再審査（コンプライアンスチェック）を強制できる

4. 午後試験に向けた記述対策ポイント

今週の学習内容を、実際の試験（特に午後試験の記述）でどう活かすか、具体的なポイントを挙げます。

4-1. 「改ざん検知」と「否認防止」の使い分け

セキュリティの3要素+追加要素に関連して、言葉の定義を厳密に使い分けてください。

メッセージ認証コード（MAC）

共通鍵を使うため、「改ざん検知」と「相手認証」はできる
しかし「否認防止」はできない（鍵を共有している相手も同じMACを作れるから）
例: HMAC-SHA256

デジタル署名

秘密鍵を使うため、「改ざん検知」「本人認証」に加え、「否認防止」ができる
秘密鍵を持っているのは本人だけだから、「私は署名していない」という否認ができない
例: RSA署名、ECDSA

試験での記述例

問:「デジタル署名がMACより優れている点を、否認防止の観点から述べよ」

解答例:「デジタル署名は送信者の秘密鍵で生成されるため、受信者には作成できない。そのため、送信者が後から『自分は送信していない』と否認することを防止できる。一方、MACは共通鍵で生成されるため、受信者も同じMACを作成できてしまい、否認防止機能を持たない。」

4-2. 証明書エラーの原因切り分け

トラブルシューティング系の問題では、「ブラウザに証明書エラーが表示された。考えられる原因を挙げよ」というパターンがあります。以下の観点を即座に引き出せるようにしてください。

主な原因

有効期限切れ（Expired Certificate）:
- 証明書の更新を忘れた
- 更新はしたが、Webサーバーへの適用を忘れた
- 解決策: 新しい証明書を取得し、サーバーに適用。自動更新（Let's Encrypt + certbotなど）の導入も検討
自己署名証明書（Self-Signed Certificate）:
- イントラネット環境で、プライベートCAが発行した証明書を使用
- ルートCA証明書がクライアントのブラウザに登録されていない
- 解決策: グループポリシーやMDMで、ルートCA証明書をクライアントに配布
CNの不一致（Certificate Name Mismatch）:
- URLのドメイン名と、証明書のSubject（CN）またはSAN（Subject Alternative Name）が一致していない
- 例: 証明書のCNが「www.example.com」なのに、「example.com」でアクセスした
- 解決策: SAN（Subject Alternative Name）に複数のドメイン名を登録した証明書を取得。またはワイルドカード証明書（*.example.com）を使用
失効済み（Revoked Certificate）:
- CRL/OCSPで失効判定された
- 秘密鍵の漏えいや、証明書の誤発行により、CAが失効処理を実施
- 解決策: 新しい鍵ペアを生成し、証明書を再発行
中間証明書の欠如（Missing Intermediate Certificate）:
- サーバー側の設定ミスで、中間証明書が送信されていない
- 信頼の連鎖が途中で途切れるため、検証失敗
- 解決策: Webサーバーの設定で、中間CA証明書も含めて送信するように修正（NginxのSSLCertificateChainFileディレクティブなど）
信頼されていないルートCA（Untrusted Root CA）:
- 証明書を発行したCAが、ブラウザの信頼されるルートCAリストに含まれていない
- 新しいCAや、WebTrust監査に未合格のCAの証明書
- 解決策: 信頼されているCAから証明書を再取得
時刻のずれ:
- クライアントのシステム時刻が大きくずれており、証明書の有効期間の判定に失敗
- 解決策: NTPで時刻を同期

4-3. 鍵管理の危殆化対応

「秘密鍵が漏えいした可能性がある」というシチュエーションの問題も頻出です。

即座に取るべき対応

失効申請（Revocation）:
- CAに連絡し、該当する証明書の失効を依頼
- CRLに追加され、OCSPレスポンダも「revoked」を返すようになる
影響範囲の確認:
- 過去の通信の安全性: その秘密鍵で鍵交換したTLS通信（RSA鍵交換の場合）は、盗聴されていた場合、後から復号される可能性がある。PFS（Perfect Forward Secrecy）を使っていない場合、リスクが高い
- デジタル署名の正当性: その秘密鍵で署名されたすべてのデータ（契約書、ソフトウェアなど）について、偽造される可能性がある
- 他のシステムへの影響: 同じ鍵ペアを複数のシステムで使い回していないか確認
再発行:
- 新たな鍵ペアを生成（古い鍵と同じ鍵は絶対に使わない）
- 新しいCSR（Certificate Signing Request）をCAに提出
- 新しい証明書を取得し、すべての関連システムに適用
インシデント分析:
- 秘密鍵がどのように漏えいしたのか、原因を特定
- サーバー侵害、バックアップメディアの紛失、内部不正など
- 再発防止策を策定（HSMの導入、アクセス制御の強化など）
関係者への通知:
- その証明書を信頼していた利用者や取引先に、証明書が失効した旨を通知
- 新しい証明書の情報を共有

PFS（Perfect Forward Secrecy）の重要性

PFSは、過去のセッション鍵が、サーバーの秘密鍵の漏えいによって危険にさらされない性質です。

RSA鍵交換の問題: クライアントがPre-Master Secretをサーバーの公開鍵で暗号化して送信。攻撃者がこの暗号文を記録しておき、後でサーバーの秘密鍵を入手すれば、Pre-Master Secretを復号でき、過去の通信をすべて復号可能
DHE/ECDHEの利点: 毎回異なる一時的な鍵ペア（Ephemeral Key）を生成して鍵交換。サーバーの秘密鍵は、鍵交換パラメータへの署名にのみ使用され、実際の暗号化には関与しない。そのため、サーバーの秘密鍵が漏えいしても、過去のセッション鍵は安全

試験では、「PFSを実現する鍵交換方式を答えよ」→「DHEまたはECDHE」という問題が出ます。

5. 実務での応用シーン:技術の活用例

ここまで学んだ技術が、実際のビジネスシーンでどのように活用されているのか、具体例を見ていきます。

5-1. 電子契約サービスにおけるPKI活用

近年普及している電子契約サービスは、まさにPKIとデジタル署名の応用例です。

技術的な仕組み

契約書の作成: 契約内容をPDF化
デジタル署名の付与:
- 契約者は、自身の秘密鍵（クラウド型の場合、サービス事業者が管理）で契約書のハッシュ値に署名
- この時、契約者の証明書（認定認証事業者が発行）も添付
タイムスタンプの取得:
- TSA（Time Stamping Authority:時刻認証局）から、「この署名がいつ行われたか」を証明するタイムスタンプトークンを取得
- タイムスタンプ自体もTSAの秘密鍵で署名されており、改ざん不可能
保管と検証:
- 署名付き契約書は、サービス事業者のクラウドストレージに保管
- 後から検証する際は、署名を検証し、タイムスタンプの正当性も確認

法的効力の根拠

日本の電子署名法により、本人による電子署名があり、改ざんされていないことが確認できれば、紙の署名・押印と同等の法的効力を持つ
ここで重要なのは「否認防止」機能。後から「私は署名していない」と主張できないことが、契約の信頼性を担保します
認定認証事業者（特定認証業務を行う者）が発行した証明書を使うことで、電子署名法の推定効（本人が署名したと推定される）を受けられます

タイムスタンプの重要性

タイムスタンプがない場合、「署名した時点では証明書が有効だったが、検証時には失効していた」というケースで問題が生じます。タイムスタンプがあれば、「署名時点では確かに有効だった」ことを証明できます。

また、長期署名（PAdES-LTV: PDF Advanced Electronic Signatures - Long Term Validation）では、証明書の有効性情報（OCSPレスポンスやCRL）もPDFに埋め込み、将来の検証に備えます。

5-2. リモートワーク環境でのゼロトラスト実装

コロナ禍以降、VPNに頼らないゼロトラストアーキテクチャが注目されています。

従来のVPNモデルの課題

ネットワークの境界（VPN内か外か）で信頼性を判断
VPNに一度接続すれば、内部のすべてのリソースにアクセス可能（過度な権限付与）
VPN装置が攻撃を受けると、内部ネットワーク全体が危険にさらされる

ゼロトラストアーキテクチャの原則

すべてのアクセスを検証: ネットワークの場所に関係なく、すべてのアクセス要求を認証・認可
最小権限の原則: 必要最小限のリソースへのアクセスのみ許可
継続的な検証: 一度認証したら終わりではなく、セッション中も継続的にリスクを評価

mTLSによるデバイス認証の実装

証明書の配布:
- MDM（Mobile Device Management）やEMM（Enterprise Mobility Management）を使って、管理対象デバイスにクライアント証明書を配布
- 証明書は、デバイスのTPM（Trusted Platform Module）やSecure Enclaveなど、安全な領域に保存
アクセス制御:
- 社内システムへのアクセスに、ユーザー認証（ID・パスワード+MFA）だけでなく、デバイス認証（クライアント証明書によるmTLS）を必須化
- リバースプロキシやゲートウェイで、クライアント証明書の検証を実施
- 証明書がない、または失効している場合は、アクセスを拒否
コンプライアンスチェック:
- 証明書の有効期間を短く設定（例:90日）
- 更新時に、デバイスのコンプライアンス状態を確認
  - OSのセキュリティパッチが適用されているか
  - ウイルス対策ソフトが動作しているか
  - 脱獄（Jailbreak）やルート化（Root化）されていないか
- コンプライアンス違反のデバイスには、証明書を発行しない（または既存の証明書を失効）

FIDO（Fast Identity Online）によるパスワードレス化

従業員に生体認証対応のセキュリティキー（YubiKeyなど）を配布
パスワード管理の負担を軽減しつつ、フィッシング攻撃への耐性を獲得
ヘルプデスクへの「パスワードを忘れた」問い合わせが激減し、運用コストも削減
セキュリティキーを紛失した場合の手順（失効と再発行）を明確化

5-3. 金融機関のAPI連携における認証

オープンバンキングの推進により、銀行のAPIを外部サービス（FinTechアプリなど）が利用するケースが増えています。

OAuth 2.0 + mTLS

APIアクセスには、OAuth 2.0によるアクセストークンに加え、mTLSによるクライアント認証を組み合わせる
これにより、「誰が（どのサービスが）」「どのユーザーの代理で」「どのリソースにアクセスしているか」を厳密に管理
OAuth 2.0 Mutual-TLS Client Authentication（RFC 8705）では、クライアント証明書の公開鍵のハッシュ値をアクセストークンに紐づけることで、トークンの盗用を防止

トランザクション署名

重要な取引（送金など）については、取引内容そのものにデジタル署名を付与
通信経路での改ざんだけでなく、アプリケーションレベルでの不正操作も検知可能に
例: 「A銀行からB銀行の口座XXXXに100万円送金」という取引データに、ユーザーの秘密鍵で署名
サーバー側で署名を検証し、取引内容が改ざんされていないことを確認

FAPI（Financial-grade API）

金融業界向けに策定された、より厳格なAPIセキュリティ標準
OAuth 2.0に、mTLSやJWT署名付きリクエスト、PKCE（Proof Key for Code Exchange）などの追加要件を課す
OpenID Foundationが策定

6. よくある誤解と注意点

試験勉強や実務で陥りがちな誤解を整理しておきます。

6-1. 「暗号化=安全」ではない

通信が暗号化されていても、接続先が偽物であれば意味がありません。

具体例

フィッシングサイトでも、Let's Encryptなどで正規の証明書を取得できるため、「https://」で始まるURLであることは安全性の保証にならない
Let's Encryptは、ドメイン所有権の確認のみで証明書を発行（DV証明書:Domain Validation）。企業の実在性は確認しない
重要なのは、証明書の主体者（CN）が正しいかを確認すること
ブラウザのアドレスバーで、ドメイン名をしっかり確認する習慣が必要
EV証明書（Extended Validation）を使っているサイトでは、企業名がアドレスバーに表示されるため、より確実

試験での記述例

問:「HTTPSで通信が暗号化されているにも関わらず、フィッシング被害が発生する理由を述べよ」

解答例:「フィッシングサイトも正規のCAから証明書を取得できるため、HTTPSで通信が暗号化される。利用者がドメイン名を確認せずにアクセスすると、偽サイトと暗号化通信を確立してしまい、入力した情報が攻撃者に渡る。暗号化は通信経路の保護であり、接続先の正当性は別途確認が必要。」

6-2. 「生体認証=万能」ではない

生体認証は「本人であること」の確認には優れていますが、限界もあります。

注意すべき点

生体情報は変更不可能:
- パスワードは漏えいしても変更できるが、指紋や顔は変更できない
- 一度漏えいすると、一生涯リスクが続く
- だからこそ、FIDOでは「生体情報をローカルでのみ使用し、ネットワーク上を流さない」設計が重要
完全一致はしない:
- 生体認証は「照合」の際に100%一致することはなく、類似度の閾値で判定
- FAR（False Acceptance Rate:他人受入率）: 他人を本人と誤認する確率
- FRR（False Rejection Rate:本人拒否率）: 本人を他人と誤認する確率
- FARを厳しくするとFRRが上がり、利便性が低下（トレードオフ）
なりすましのリスク:
- 高解像度の写真で顔認証を突破する攻撃
- シリコン製の偽指紋で指紋認証を突破する攻撃
- 対策として、活性検知（Liveness Detection）が重要。例えば、「まばたきをする」「顔を動かす」などの動作を求める
プライバシーへの配慮:
- 生体情報は個人情報保護法上の「要配慮個人情報」に該当
- 厳格な管理が必要

試験での記述例

問:「生体認証の課題を2つ挙げ、それぞれについて対策を述べよ」

解答例:「（課題1）生体情報は変更不可能であり、一度漏えいすると恒久的なリスクとなる。（対策1）生体情報をネットワーク上に送信せず、ローカルデバイス内でのみ照合を行う仕組み（例:FIDO）を採用する。（課題2）完全一致判定ができないため、他人受入のリスクがある。（対策2）閾値を適切に設定し、重要な取引では生体認証に加えて別の要素（PIN入力など）を組み合わせた多要素認証を実施する。」

6-3. 「SSOは便利だが、単一障害点にもなる」

SSOは利便性が高い反面、認証サーバーが停止すると、すべてのサービスにログインできなくなります。

対策

認証サーバーの冗長化:
- Active-Active構成やActive-Standby構成で、複数台の認証サーバーを配置
- ロードバランサーで負荷分散
バックアップの認証手段:
- 緊急時用のローカルアカウント（Break Glassアカウント）を用意
- ただし、このアカウントの管理は厳重に（使用時のログ記録、定期的なパスワード変更など）
定期的なDR訓練:
- 認証サーバーの障害を想定した訓練を実施
- フェイルオーバーの手順、復旧時間目標（RTO）の確認
監視とアラート:
- 認証サーバーの死活監視、パフォーマンス監視
- 異常時の自動アラート

SSOの ID Providerが侵害された場合のリスク

ID Provider（IdP: Identity Provider）のアカウントが乗っ取られると、そのIdPを信頼するすべてのサービスに不正アクセスされる
対策: IdPへのアクセスに多要素認証を必須化。特権アカウントには最も強力な認証（FIDOなど）を要求

7. 学習の定着を促す実践トレーニング

知識を「使える状態」にするための、具体的なトレーニング方法を紹介します。

7-1. 証明書の実物確認

自分のブラウザで、実際の証明書を確認してみましょう。

確認手順（Chrome/Edgeの場合）

HTTPSサイト（例:https://www.example.com）にアクセス
アドレスバーの鍵マークをクリック
「証明書」または「この接続は保護されています」→「証明書は有効です」をクリック
証明書の詳細を確認:
- 発行先（Subject）: CN（Common Name）を確認。これがドメイン名と一致しているか
- 発行者（Issuer）: どのCAが発行したか。中間CA証明書の場合もあるため、さらに上位をたどる
- 有効期間: いつからいつまで有効か。最近の証明書は398日以内（約13ヶ月）が上限
- 公開鍵情報: RSA 2048bit、ECDSA P-256などの情報
- 拡張フィールド:
  - Subject Alternative Name（SAN）: 複数のドメイン名が登録されているか
  - Key Usage: どの用途に使えるか（Digital Signature, Key Enciphermentなど）
  - Extended Key Usage: Server Authentication, Client Authenticationなど
- CRL配布ポイント: CRLの取得先URL
- Authority Information Access: OCSPレスポンダのURL、上位CA証明書のURL

学習効果

教科書の知識が、実際のデータ構造として「見える」ことで、理解が深まります
複数のサイトを比較することで、証明書の多様性（EV証明書、ワイルドカード証明書、マルチドメイン証明書など）も学べます
実際にOCSP URLにアクセス（openssl s_clientコマンドなど）して、OCSPレスポンスを確認することも可能

7-2. ケーススタディでの思考訓練

以下のようなシナリオで、「何が問題で、どう対処すべきか」を考える訓練をしましょう。

ケース1: 社内Webシステムで証明書エラー

現象: 社内の業務システムにアクセスすると、「NET::ERR_CERT_AUTHORITY_INVALID」エラーが表示される
原因の仮説: 自社で運用しているプライベートCAの証明書が、クライアントPCにインストールされていない
確認方法: クライアントPCの証明書ストアを確認し、該当するルートCA証明書があるか調べる
対処: グループポリシー（Active Directory環境）やMDMで、ルートCA証明書をクライアントに配布

ケース2: モバイルアプリの認証強化

要件: 従来のID・パスワード認証から、多要素認証に移行したい
選択肢の比較:
- SMS認証: 手軽で導入コストが低いが、SIMスワップ攻撃のリスクあり。推奨度:中
- TOTP（Time-based OTP）: アプリが必要だが、オフラインでも動作。比較的安全。推奨度:高
- FIDO: 最も安全で、フィッシング耐性もある。ただし、対応デバイスが必要。推奨度:最高
結論: 段階的に導入。まずTOTPを標準とし、役員など重要アカウントにはFIDOを必須化。将来的に全社でFIDOに移行

ケース3: 証明書の有効期限管理

課題: 複数のWebサーバーやAPIサーバーで使用している証明書の有効期限がバラバラで、更新漏れが心配
対策:
1. 証明書の一元管理台帳を作成（サーバー名、FQDN、証明書の発行日、有効期限、担当者）
2. 監視ツール（Nagios、Zabbix、CloudWatch Synthetics など）で、証明書の有効期限を自動チェック
3. 有効期限の30日前、7日前にアラートを送信
4. 可能であれば、Let's Encrypt + certbotなどで自動更新を実装

7-3. 用語の関連図を自分で描く

今週学んだキーワードを、紙に書き出して、矢印で関係性を結んでみましょう。

例:PKI周辺

中心に「PKI」を配置
「CA」「RA」「証明書（X.509）」「秘密鍵」「公開鍵」「CRL」「OCSP」「OCSPステープリング」を周囲に配置
「CA」から「証明書」への矢印（発行）
「証明書」から「CRL」「OCSP」への矢印（失効確認）
「RA」から「CA」への矢印（審査済み申請の転送）

例:認証技術周辺

中心に「認証」を配置
「パスワード」「生体認証」「多要素認証」「FIDO」「SSO」「ケルベロス」「mTLS」を周囲に配置
「多要素認証」から「パスワード」「生体認証」「FIDO」への矢印（組み合わせ）
「SSO」から「ケルベロス」への矢印（実装技術の一つ）
「mTLS」から「X.509証明書」への矢印（クライアント認証に使用）

例:PKIと認証の統合

「TLS/SSL」を中心に配置
上部に「PKI」グループ（CA、証明書、OCSP）
下部に「認証」グループ（MFA、FIDO、ケルベロス）
「TLS/SSL」から「証明書」への矢印（サーバー認証）
「TLS/SSL」から「mTLS」への矢印（相互認証）
「mTLS」から「クライアント証明書」への矢印

効果

知識が「点」から「面」になり、午後試験の記述で、複数の技術を組み合わせた解答が書けるようになります
図を描く過程で、理解が曖昧な部分が明確になり、重点的に復習すべきポイントが分かります

まとめと次週への架け橋

今週は、PKIという「インフラ」と、認証という「入り口」について深く掘り下げました。

今週の核心

PKIは、デジタルの世界で「誰が誰であるか」を保証する身分証発行システムのようなもの
認証は、その身分証やその他の証拠（パスワード、生体）を使って関所を通る手続き
X.509、OCSP、FIDO、ケルベロスといった技術は、それぞれの場面で「なりすまし」や「改ざん」を防ぐために特化して進化してきました
これらの技術は、単独ではなく組み合わせることで、真のセキュリティを実現する

これらを体系的に理解していれば、ニュースで見聞きするセキュリティ事件（例:フィッシング詐欺によるID流出、誤った証明書発行による通信障害など）の背景にある技術的な不備が、手に取るように分かるようになっているはずです。

次週の予告:現代のID連携（IDaaSへの道）

さて、ここまでは「1つのシステム、1つの組織」内での認証が中心でした。しかし、現代のWebは、Googleアカウントで様々なサービスにログインできるように、組織をまたいだ認証が当たり前になっています。

次週は、第4週「ID管理とアクセス制御」に突入します。まずは、クラウド時代に必須の知識となる**「SAML」と「OpenID Connect」**について解説します。これらは、今回学んだPKIや認証技術を応用し、異なるドメイン間で安全にID情報をやり取りする仕組みです。

次週で解決する疑問

SSOって便利だけど、裏側でどうやって情報を渡しているの？
OAuthとOpenID Connectって何が違うの？
クラウドサービスの認証は、なぜオンプレミスと違うアプローチが必要なのか？
SAMLアサーションって何？どうやって改ざんを防いでいるの？

そんな疑問を完全に解消し、最新のクラウドセキュリティに対応できる力をつけていきましょう。月曜日の記事にご期待ください！

【次のアクション】

今週の復習として、以下の3つを実践してください。

証明書の実物確認: ご自身のブラウザのアドレスバーにある「鍵マーク」をクリックして、「証明書」の中身を見てみる。「発行者（Issuer）」や「有効期間」、「CRL配布点」「OCSP URL」などのフィールドが、実際にどのように記述されているかを確認する
フローの言語化: 今週学んだキーワード（CA、RA、X.509、OCSP、FIDO、ケルベロス）を使って、「HTTPSでWebサイトにアクセスし、多要素認証でログインするまで」の流れを、自分の言葉で説明できるようにする。家族や同僚に説明してみるのも効果的
過去問演習: IPA公式サイトから過去問（午後問題）をダウンロードし、PKIまたは認証に関する問題を1問解く。答え合わせをして、わからなかった用語は、今週の記事に戻って確認する。特に「なぜそうなるのか」という理由を説明できるレベルまで理解を深める

この3つの実践が、知識の定着と、試験での得点力向上に直結します。繰り返し復習することで、知識が長期記憶に定着し、応用問題にも対応できる力が身につきます。