# RADIUS におけるトランスポートセキュリティ vs. RadSec Extensible Authentication Protocol (EAP) を使用して安全な認証を展開する場合、トランスポートプロトコルの選択 - UDP 上の RADIUS と TLS 上の RADIUS (RadSec) - は、メタデータとプロトコル要素がネットワーク全体でどれだけ सुरक्षितに送信されるかを決定するうえで極めて重要な役割を果たします。 RADIUS と RadSec のどちらも、EAP-TLS、PEAP、EAP-TTLS などの一般的な方式で使用されるものを含む EAP メッセージを運ぶことができます。EAP 方式の内部動作は同じままですが、トランスポートプロトコルは、メタデータの可視性、整合性、機密性、および運用上の挙動に影響します。 この文書では、RADIUS と RadSec が EAP トランスポートにどのような影響を与えるかを比較し、暗号化、共有シークレットの使用、属性の露出、ログへの影響、導入時の考慮事項に焦点を当てます。 *** ### トランスポートセキュリティ: 主要な違い EAP-TLS、PEAP、EAP-TTLS などの EAP 方式は、クライアント（サプリカント）と認証サーバー間の認証メカニズムを提供します。ただし、これらの方式は中間ノード間のメタデータのトランスポートを本質的に暗号化するわけではありません。この役割はトランスポート層プロトコルが担います: * RADIUS (UDP) は、EAP メッセージと RADIUS 属性を平文で送信します。 * RadSec (TLS) は RADIUS パケット全体を暗号化し、転送中のすべての属性とプロトコルヘッダーを保護します。 以下の表は、これらの違いを要約したもので、外部 ID、NAS IP、呼び出し元ステーション ID などの属性の機密性に影響します。EAP 方式がユーザー資格情報（例: 証明書やパスワード）を暗号化する場合でも、RadSec を使用しない標準 RADIUS ではメタデータは露出したままです。 | プロトコル | RADIUS | RadSec | | ------------- | ---------------------------------- | --------------------- | | トランスポート層プロトコル | UDP（通常） | TCP 上の TLS | | 暗号化 | トランスポート暗号化なし | 完全なトランスポート暗号化 | | 既定ポート\* | UDP 1812 | TCP 2083 | | 注記 | ステートレス。ファイアウォールでフィルタリングされる場合があります。 | ステートフル。安全なトンネルを確立します。 | \*これらのポートは標準として認識されていますが、ローカルポリシーやインフラ上の理由により、導入環境によってはカスタマイズされることがあります。 *** ### 両方のプロトコルにおける RADIUS 共有シークレットの役割 RADIUS 共有シークレットは、パケットの整合性とレガシーな暗号化動作のために使用されます。これは、トランスポートが標準 RADIUS であるか RadSec であるかに関係なく適用されます。 **主な用途:** * **Message-Authenticator AVP**: HMAC-MD5 を使用してパケットの整合性を確保します。 * **User-Password AVP（レガシー方式）**: 共有シークレットを使用して資格情報を暗号化します。 * **RadSec の互換性**: RadSec でも、RADIUS の意味論や中間システムとの互換性のために共有シークレットは維持されます。 {% hint style="info" %} **注:** 共有シークレットがネットワーク上で送信されることはありません。HMAC 操作と AVP の検証のためにローカルで使用されます。 {% endhint %} *** ### データ要素の可視性: RADIUS と RadSec この表では、RADIUS (UDP) 上の EAP-TLS と RadSec (TLS) を使用する場合の主要なデータ要素を、転送中の可視性リスクごとに分類して比較します。
データ要素RADIUS (UDP)RadSec (TLS 上の RADIUS)例 / 注記
外側の RADIUS パケット平文（UDP または TCP 上）。暗号化済み（TLS 上）。ヘッダーと AVP の両方を含みます。例: Wireshark や tcpdump でパケットが表示されます。
ユーザー ID（外部 ID）平文で送信されます。暗号化済み（TLS 上）。anonymous@organisation.com レルームルーティングに使用されます。
RADIUS AVP（属性）一部は平文（例: NAS-IP、User-Name）。TLS により完全に暗号化されます。

NAS-IP-Address,

Calling-Station-Id

RADIUS ヘッダー平文TLS で暗号化

Code (Access-Request), Identifier,

Length,

Authenticator

RADIUS 共有シークレット送信されません（内部で使用）送信されません（内部で使用）AVP の暗号化と Message-Authenticator の検証に使用されます。
EAP ペイロード クライアントとサーバー間で暗号化TLS で暗号化TLS ハンドシェイク、証明書検証などを含みます。
ユーザー資格情報（証明書/キー）EAP トンネル内で暗号化EAP トンネル + TLS で暗号化証明書ベース（EAP-TLS）およびパスワードベース（PEAP）の方式に適用されます。subject CN=jsmith, OU=IT
パスワード（例: PEAP または MSCHAPv2）トンネル方式で暗号化（例: PEAP）EAP トンネル + TLS で暗号化パスワードベースの方式に適用されます。
*** ### ID のプライバシー: 外部 ID と内部 ID トンネリングまたは証明書を使用する EAP 方式（例: PEAP、EAP-TTLS、EAP-TLS）は、外部 ID と内部 ID をサポートします: * **外部 ID**: レルームルーティングを容易にするため、User-Name AVP に平文で送信されます。多くの場合、匿名化されます（例: `anonymous@domain.com`). * **内部 ID**: 暗号化された EAP トンネル内で安全に運ばれます（例: ユーザー名/パスワード、証明書 CN）。 #### トランスポート間の挙動: * では、 **RADIUS**外部 ID は平文で送信され、通信上で可視です。 * では、 **RadSec**では、外部 ID を含むパケット全体が暗号化されます。 RADIUS で外部 ID が平文送信されることに関するプライバシー上の懸念は、ID プライバシーを構成するか、共通名属性に PII データを含まないデバイス証明書を活用することで軽減できます {% hint style="info" %} **注**: Windows のネイティブ EAP クライアントのような一部のプラットフォームでは、EAP-TLS などの方式で既定では ID プライバシーをサポートしない場合があり、外側レイヤーで実際の ID が露出する可能性があります。 {% endhint %} #### 外部 ID 以下の表は、各 OS プラットフォームが外部 ID に通常どのような値を設定するかの概要を示します。 | 資格情報の種類 | 外部 ID | 対象 OS | | ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | ユーザー名/パスワード |



通常:
- UPN
- メールアドレス

| | | デバイス証明書 |

クライアント証明書の subject 名にある共通名（CN）プロパティ。

通常:
- DeviceName
- Intune Device ID （GUID）
- AAD Device ID （GUID）

|

| | ユーザー証明書 |

クライアント証明書の subject 名にある共通名（CN）プロパティ。

通常:
- UPN
- メールアドレス

|

| \*Windows で使用される EAP クライアントは、EAP-TLS の ID プライバシーをサポートしていません。 *** ### ログと導入の考慮事項 #### RadSec (TLS) RadSec は RADIUS パケット全体を暗号化するため、受動的な盗聴を防ぎます。TLS セッションを終了するのはこれらのエンドポイントであるため、ログと診断はネットワーク検査からアプリケーションまたは RADIUS サーバーレベルへ移行します。RadSec に移行する組織は、暗号化されたトラフィックに対応できるよう監視ワークフローを評価する必要があります。 #### RADIUS (UDP) 属性（User-Name、NAS-IP-Address など）が平文で送信されると、トラブルシューティングやライブ診断が容易になり、最小限のツールでパケットキャプチャが可能です。ただし、転送中に機密メタデータが露出するリスクは高まります。 #### ネットワークサポート RadSec のサポートは、すべてのネットワークデバイスやインフラで普遍的ではありません。多くのネットワークスイッチ、無線アクセスポイント、ファイアウォールは従来の RADIUS のみをサポートします。混在環境では、最新コンポーネントとレガシーコンポーネントをつなぐために RadSec-to-RADIUS プロキシが必要になる場合があります。本番環境で RadSec を導入する前に、インフラの評価を推奨します。 *** ### 結論と重要なポイント EAP 方式を RADIUS または RadSec のいずれかで転送しても、ユーザー資格情報に対する同じ強力なエンドツーエンド保護が得られますが、転送中のメタデータとプロトコル要素の露出の仕方は大きく異なります。 * **EAP のエンドツーエンド保護**: EAP は、RADIUS と RadSec の両方でユーザー資格情報を強力に保護します。 * **主な違い**: RADIUS は UDP を使用し、RADIUS パケット自体を暗号化しません。一方、RadSec はパケット全体を TLS で包み込み、すべての属性とヘッダーを通信経路上から隠します。 * **メタデータの機密性**: RadSec はすべてのメタデータ（ヘッダー、属性、外部 ID）を暗号化し、ネットワークレベルでの露出を防ぎます。 * **共有シークレット**: 共有シークレットが送信されることはありません。メッセージ整合性チェックの計算と真正性の検証のためにのみローカルで使用されます。 * **トレードオフ**: RadSec は機密性を向上させますが、暗号化のため診断が複雑になり、またすべてのネットワーク機器でサポートされているわけではありません。 *** ### 標準と RFC 参照 プロトコルと仕様の詳細については: * EAP (Extensible Authentication Protocol): RFC 3748 * EAP-TLS: RFC 5216 * RADIUS (Remote Authentication Dial-In User Service): RFC 2865 * RadSec (TLS 上の RADIUS): RFC 6614 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.radiusaas.com/ja/sono/faqs/security-and-privacy/radius-niokerutoransuptosekyuriti-vs-radsec.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.