--- title: 認証フレームワーク url: https://doc.liz6.com/ja/networking/12-security-protocols/03-authentication-frameworks locale: ja area: networking tags: - networking - security-protocols date: 2026-06-30 modified: 2026-07-19 description: Kerberos（対称鍵＋チケット）、SAML（フェデレーションID＋XMLアサーション）、WebAuthn（公開鍵＋ローカル生体認証）——3つの認証フレームワークは、それぞれドメイン内、クロスドメイン、フィッシング対策という異なる3つのシナリオを解決します。LDAPとRADIUSは、インフラストラクチャ層でディレクトリおよびネットワークアクセス制御を提供します。 --- # 認証フレームワーク > Kerberos（対称鍵＋チケット）、SAML（フェデレーションID＋XMLアサーション）、WebAuthn（公開鍵＋ローカル生体認証）——3つの認証フレームワークは、それぞれドメイン内、クロスドメイン、フィッシング対策という異なる3つのシナリオを解決します。LDAPとRADIUSは、インフラストラクチャ層でディレクトリおよびネットワークアクセス制御を提供します。 ## 概要 「認証」が常に答えなければならない問いは同じです——**いかにして自分が自分であることを証明するか**。しかし、異なるプロトコルは「証明」を異なる位置に配置しており、それによっていくつかの世代に分かれます： | プロトコル | 年代 | 資格情報の形態 | 信頼の置かれる場所 | 主な戦場 | |---|---|---|---|---| | Kerberos | 1988 | 対称チケット | 中央KDC | 企業内網 / AD | | LDAP bind | 1993 | ユーザー名＋パスワード | ディレクトリサーバー | 内部ディレクトリ / バックエンドストレージ | | SAML 2.0 | 2005 | 署名付きXMLアサーション | IdP | 企業Web SSO | | RADIUS | 1991 | 共有キー + EAP | AAAサーバー | ネットワークアクセス (WiFi/VPN) | | WebAuthn | 2019 | 非対称鍵ペア | ユーザーデバイス | フィッシング耐性のあるパスワードレスログイン | 理解すべき主軸は一つだけです：**パスワードは負債である**。パスワードは再利用され、フィッシングの餌食となり、辞書攻撃を受け、伝送中や保存中に漏洩します。後続の各世代のプロトコルは、パスワードの出現回数を減らす方法を模索してきました——Kerberosはパスワードをローカルでの派生に1回だけ使用し、それ以降はネットワークに送信しません。SAML/OIDCは、パスワードをIdPという1か所にのみ渡すようにします。WebAuthnは、デバイス内のエクスポート不可能な秘密鍵を用いてパスワードを完全に置き換えます。選択の本質は、**既存のインフラストラクチャと脅威モデルにおいて、パスワードをどの程度排除できるか**にあります。 ## Kerberos — チケットによるシングルサインオン Active Directoryドメインログインの基盤です。核心的な思想は、ユーザーがログイン時にのみパスワードから1回鍵を派生し、その後は**期限付きの対称暗号化チケット**によって各サービスにアクセスし、パスワードはネットワークを通過しないというものです。 Kerberos 3段階: 1回のログインで、その後はすべてチケットに依存 役割: KDC = AS(認証サーバー) + TGS(チケット付与サーバー); クライアント; サービス ① AS-REQ/REP · 1回のログイン Client → AS: 「私はaliceです」 AS → Client: TGT(TGS鍵 で暗号化) + セッション鍵(パスワード派生 鍵で暗号化) → パスワード自体はネットワークに送信されない ② TGS-REQ/REP · 各アクセスごと Client → TGS: TGTを提示、 「fileserverにアクセスしたい」 TGS → Client: サービスチケット (fileserver鍵で暗号化) + 新しいセッション鍵 ③ AP-REQ/REP · サービスアクセス Client → fileserver: サービスチケット + authenticator(タイムスタンプ、 リプレイ攻撃防止) fileserverがチケットを解読 → 信頼 KDCの裏書き → (オプション) AP-REP 双方向認証 サーバーはKDCに連絡する必要もなく、ユーザーのパスワードを保存することなくクライアントを検証できる——「自分の鍵で 暗号化されたチケット」を解読できれば、そのチケットがKDCによって発行されたことが証明される。パスワードはログイン時の1回の派生にのみ関与し、それ以降はネットワークに送信されない。 なぜこのように設計されたのか：サーバーは**KDCに連絡する必要もなく、ユーザーのパスワードを保存することなく**クライアントを検証できる——「自分の鍵で暗号化されたチケット」を解読できれば、そのチケットがKDCによって発行されたことが証明される。代償と脅威： - **時刻同期**：authenticatorはタイムスタンプによってリプレイ攻撃を防ぐため、ドメイン全体の時刻のずれは通常5分未満でなければならない（そのためADはNTPに強く依存する）。 - **KDCは高価値の単一障害点**：`krbtgt` アカウントのハッシュを取得すれば、任意のTGTを偽造できる（**Golden Ticket**）。あるサービスの鍵を取得すれば、そのサービスのチケットを偽造できる（Silver Ticket）。 - **Kerberoasting**：サービスチケットはサービスアカウントのパスワードから派生した鍵で暗号化されるため、攻撃者はチケットを要求してからオフラインで弱いパスワードのサービスアカウントを爆破できる——そのため、サービスアカウントには強力なランダムパスワードまたはgMSAを使用する必要がある。 ## LDAP — ディレクトリおよびbind認証 LDAP（RFC 4511）はまず**階層型ディレクトリ**（`cn=alice,ou=users,dc=example,dc=com`）であり、ユーザー、グループ、デバイスおよびその属性を格納する。その「認証」とは、**bind**操作のことである：DNとパスワードを使用してサーバーから「許可/拒否」を取得する。 LDAP アプリケーションアクセス: search-then-bind 2段階 ① サービスアカウントによるbind アプリケーションがサービスアカウントでbind → aliceの完全なDNを検索 ② ユーザーDN + パスワードによるbind aliceのDN + 彼女が入力したパスワードで bindを再度実行 → 成功すればパスワードは正しい bind方式の比較 simple bind DN + 平文パスワード LDAPS/StartTLS上で実行する必要があり、 そうでなければパスワードが平文で送信される SASL bind GSSAPI(Kerberos)/ EXTERNAL(mTLS) パスワードを送信しない、より強力 LDAP自体はSSOプロトコルではない——「資格情報検証 + 身元データソース」であり、SAML/OIDC/RADIUSの背後に隠れてストレージとしてよく使用される。 位置づけの要点：LDAP自体は**SSOプロトコルではない**、それは「資格情報検証 + 身元データソース」であり、SAML/OIDC/RADIUSの背後に隠れてストレージとしてよく使用される。Active Directory ≈ LDAP（ディレクトリ）+ Kerberos（認証）+ DNS（ルーティング）の3点セットの組み合わせである。 ## SAML 2.0 — 企業Web SSO XML時代のブラウザ向けSSO標準（Okta、Azure AD、企業内網）。SP（サービスプロバイダ）は認証をIdP（アイデンティティプロバイダ）に「外部委託」し、IdPは**デジタル署名付きのアサーション（Assertion）**を返す。 SAML 2.0 SP開始型フロー (HTTPリダイレクト + フォームPOSTバインディング) 1 User → SP: 保護されたリソースにアクセス 2 SP → Browser: IdPへリダイレクト、AuthnRequest付き (HTTP-Redirectバインディング) 3 IdPがユーザーを検証（既存セッションを再利用する場合あり）→ Assertionを生成 4 IdP → Browser → SP: 自動POSTフォームでResponseを返送 (HTTP-POSTバインディング) 5 SPがXML署名 + 条件を検証 → ローカルセッションを確立 Assertionの重要フィールド <Issuer> 誰が発行したか (SPの信頼リストに含まれている必要がある) <Subject><NameID> ユーザー識別子 <Conditions NotBefore=".." NotOnOrAfter=".."> 有効期限 → リプレイ攻撃防止 <AttributeStatement> email / groups / role など <ds:Signature> XML-DSig署名 (アサーション全体またはResponse全体をカバー) セキュリティの要点（SAMLの落とし穴のほとんどは署名検証にある）： - **XML Signature Wrapping (XSW)**：攻撃者が合法な署名付き要素の位置をずらし、偽造されたアサーションを注入する。SPは「署名が適用されているのが、まさに信頼されるべき要素であること」を厳密に検証し、スキーマ解析を固定する必要がある——これがSAML実装で最も一般的なCVEの発生源である。 - **`Audience`（このアサーションは自分宛てであること）、`NotOnOrAfter`（期限切れでないこと）、`Recipient`および`InResponseTo`（リプレイ攻撃/注入防止）、`NameID`の単一消費**を検証する必要がある。 - なぜまだ生き残っているのか：純粋なブラウザリダイレクト、JavaScript不要、レガシーな企業IdPとの互換性が最高である。新規プロジェクトではOIDCが首选である。 ## WebAuthn / Passkeys — フィッシング耐性のあるパスワードレス FIDO2/WebAuthn（W3C）は**非対称鍵**のペアを用いてパスワードを置き換える：秘密鍵は生成後にデバイスのセキュリティユニットにロックされ、エクスポート不可であり、サーバーは公開鍵のみを保存する。 WebAuthn: 非対称鍵ペアがパスワードを置き換え、秘密鍵はデバイスから出ない 登録 · navigator.credentials.create Server → challenge (ランダム) Authenticator (RP ID=example.com)のために鍵ペアを生成、 秘密鍵はローカルに保持 → credential_idを返す + public_key + (オプション) attestation Server credential_idを保存 ↔ public_key 認証 · navigator.credentials.get Server → challenge + 許可された credential_id Authenticator ユーザー検証 (指紋/PIN) → 秘密鍵で (challenge + origin + RP ID)に署名 Server 公開鍵で署名を検証 + 確認 challenge + origin 署名はorigin/RP IDにバインドされる——Authenticatorは正しいドメインのみを認識するため、これはパスワードやOTPでは提供できないフィッシング耐性の保証である。 それ**が唯一真に重要な性質はフィッシング耐性である**：署名には`origin`/RP IDがバインドされており、ブラウザは`example.com`の資格情報を`example.com`に対してのみ使用する。ユーザーが`examp1e.com`に騙された場合でも、Authenticatorは一致する資格情報を見つけられず、有効な結果に署名できない——これはパスワード、OTP、プッシュ通知では提供できない保証である。その他の概念： - **attestation**：「これは某モデルの正規品Authenticatorである」ことを証明する。消費シナリオでは通常検証しない（プライバシー + 互換性の理由）。 - **discoverable credential（resident key）**：ユーザーハンドルをAuthenticatorに保存し、「ユーザー名を入力せずにログインする」を実現する——これが**Passkey**の基盤である。 - **Passkey = 同期可能なdiscoverable資格情報**：iCloud Keychain / Google Password Managerを介してデバイス間で同期され、使いやすさが大幅に向上するが、信頼はクラウドアカウントに移行する。ハードウェアキー（device-bound）は同期されず、より強力だが紛失しやすい。 ## RADIUS — ネットワークアクセスのAAA RADIUS（RFC 2865）が管理するのは「ウェブサイトのログイン」ではなく、「**このネットワークに接続できるか**」——WiFi（WPA2/3-Enterprise）、VPN、スイッチポート（802.1X）である。AAAを行う：Authentication（認証）、Authorization（認可）、Accounting（監査）。 RADIUS: ネットワークアクセス層のAAAフロントエンド NAS AP / スイッチ / VPNゲートウェイ RADIUSサーバー Authentication/Authorization/Accounting UDP 1812/1813 共有シークレット (NAS↔サーバー) EAPトンネルが実際の認証方法を担う EAP-TLS = 証明書による双方向認証 (最強) PEAP/TTLS = TLSトンネル内でさらに MSCHAPv2などを実行 よく参照される LDAP / AD / Kerberos 802.1X 3者 端末 (supplicant) スイッチ (authenticator) RADIUS (server) RADIUSは単なるAAAフロントエンドであり、アクセス層とアイデンティティ層を分離する——実際のアカウントデータはLDAP/AD/Kerberosに残る。 要点：RADIUS自体は単なるAAAフロントエンドであり、アイデンティティデータは通常LDAP/ADにある。それは「アクセス層」と「アイデンティティ層」を分離する。コマンド単位での細粒度な認可と監査（ネットワーク機器の運用保守）が必要な場合は、**TACACS+**（コマンド単位認可、全体暗号化）に置き換える。 ## 選択基準 | 要件 | 首选 | 主要な理由 | |---|---|---| | ADドメイン内のサービス相互認証 | Kerberos | チケットSSO、パスワードはネットワークに送信されない | | 内部ディレクトリ / バックエンドアイデンティティソースとして | LDAP(S) | SSOではなくデータソースであり、他のプロトコルの背後に隠れる | | 企業Web SSO（レガシーIdP） | SAML 2.0 | 純粋なブラウザ、互換性が最高 | | モダンアプリ / モバイル / フェデレーションログイン | [OIDC](/networking/12-security-protocols/02-oauth2-and-openid-connect.md) | JSON/JWT、SAMLより軽量 | | フィッシング耐性のあるユーザーログイン | WebAuthn/Passkey | originバインド、パスワードを排除 | | WiFi / VPN / ポートアクセス制御 | RADIUS + EAP | ネットワークアクセス層のAAA | | ネットワーク機器のコマンド単位認可監査 | TACACS+ | 細粒度 + 全体暗号化 | 実践では、これらは排他的選択ではなく階層的に組み合わせて使用される：典型的な組み合わせは、**WebAuthn/OIDCをユーザーログインのフロントエンドとして、LDAP/ADをアイデンティティソースとして、Kerberos/RADIUSを内網とアクセス制御として使用する**ものである。 ## 参考 - **Kerberos**: RFC 4120 · MIT Kerberosドキュメント · 「Kerberos: The Definitive Guide」 - **WebAuthn**: w3c.github.io/webauthn · webauthn.guide · passkeys.dev - **SAML**: OASIS SAML 2.0 Core · 「On Breaking SAML」（XSW攻撃論文） - **統一プラットフォーム**: Keycloak（OIDC/SAML/LDAP/Kerberosのブローキングを同時に解説、実際に構築して読む価値あり） *Keywords: Kerberos, KDC, TGT, Golden Ticket, Kerberoasting, LDAP, bind, SAML, Assertion, XML Signature Wrapping, WebAuthn, Passkey, FIDO2, phishing-resistant, RADIUS, EAP, 802.1X, TACACS+*