# MAC認証バイパス
{% hint style="danger" %}
～以来 **MACアドレスは簡単に詐称できるため**、MAC認証バイパスの実装は **強く推奨されません** 。ただし、どうしても必要で、管理者がそのようなバイパスを実装することに伴うリスクと、旧式ハードウェアのアップグレードに関する利便性および予算上の制約を十分に比較衡量している場合を除きます。
{% endhint %}
## 概要
**MAC Authentication Bypass (MAB)** は、標準の802.1X企業認証を実行できないデバイス（旧式プリンター、単純なセンサー、組み込みシステムなど）が、もともとは保護されたネットワークに接続できるようにする機能です。MABは、RADIUSサーバーによって管理されている承認済みリストに対して、デバイス固有のMACアドレスを唯一の識別子として使用し、アクセスを許可します。
従来のMAB実装は **、認証を行うデバイスとネットワーク機器間、およびネットワーク機器とRADIUSサーバー間の両方でMACアドレスの詐称に対して** 脆弱です。2つ目の攻撃ベクトルを排除するために、 **MAB-to-EAP**と呼ばれる、より強力なMAB実装を使用できます。これにより、RADIUSサーバーに送信されるMACアドレスの完全性が実質的に保証されます（ただし、認証を行うデバイスとネットワーク機器間のリンクでは、MACアドレスは依然として詐称可能です）。
このガイドでは、安全でない従来の手法である **Pure MAB** と、現代的なトランスポート保護付きの回避策との違いを詳しく説明します。
## MABの用語と実装
**MAB:** MAC Authentication Bypass
**EAP:** Extensible Authentication Protocol
**Supplicant:** Authenticatorとの認証プロセスを開始する主体（ラップトップ、電話、ネットワークインターフェースなど） で、ネットワークへのアクセスを取得します。
**Authenticator:** 認証を強制し、その後Supplicantに ネットワークへのアクセスを付与するネットワーク主体（スイッチ、無線アクセスポイント、VPNゲートウェイなど）。
**Authentication Server:** Supplicantの資格情報（ユーザー名、パスワード、デジタル証明書など）を確認して身元を検証し、ネットワークへのアクセスが許可されているかどうかを判断する責任を持つ、信頼されたネットワーク主体（RADIUSサーバーなど）。
**Pure MAB** (従来の実装): この方式では、AuthenticatorがクライアントのMACアドレスをRADIUSサーバーに送信し、通常は `Calling-Station-Id` RADIUS属性に含めます。RADIUSサーバーは単純な検索を行い、 `Access-Accept` または `Access-Reject`を返します。MACアドレスは識別子として機能するだけで、真の資格情報ではありません。
**MAB-to-EAP** (保護された実装): Pure MABには暗号学的に安全なトランスポートがないため、RADIUSaaSのような多くの最新サービスでは、より強力なアプローチが必要です。この方式では、AuthenticatorがクライアントのMACアドレスをユーザー名とパスワードの両方として使用し、セキュアなEAPプロトコル（例: EAP-TTLS-PAP、PEAP-MSCHAPv2）を使ってRADIUSサーバーへの認証を試みます。クライアントデバイスは、認証が行われていることに気づきません。
## Pure MABの動作方法（外部RADIUSデータベース）
MACアドレスのデータベースが外部RADIUSサーバーによって管理されている場合（一般的な企業構成）、Pure MABでは次の手順が適用されます。
1. 802.1X非対応のクライアントが接続し、ネットワークアクセスを要求します。
2. Authenticatorが接続を検出し、802.1Xのネゴシエーションがないことを確認すると、MAB試行を開始します。
3. AuthenticatorはクライアントのMACアドレス（例: `00:11:22:33:44:55`）を取得し、 `Access-Request` メッセージでRADIUSサーバーに転送します。MACアドレスは通常、 `Calling-Station-Id` RADIUS属性
4. に解析されます。RADIUSサーバーは、設定済みデータベースにMACアドレスが存在するかを確認します。
5. メッセージを返し、MACが見つかれば（一致）、 `Access-Accept` 、見つからなければ（不一致） `Access-Reject` を返します。
6. もし `Access-Accept` を受信すると、Authenticatorはポートを認可し、クライアントがネットワークに参加できるようにします。
### セキュリティ上の考慮事項
一般に、 **MABはほとんど、あるいはまったくセキュリティを提供せず** 、極めて注意して使用すべきです。
* **MAC詐称:** MACアドレスは、現在のほとんどのコンピューターやネットワークカードで簡単に変更（詐称）できます。悪意のある攻撃者は、許可されたデバイスのMACアドレスを観測し、自分のデバイスをそのMACアドレスで動作するように設定することで、無許可のアクセスを得ることができます。
* **識別であって認証ではない:** MABは単なるデバイス識別の一形態です。接続しているデバイスが何であるかは確認できますが、それが誰のものか、または暗号学的に安全かどうかは確認できません。
これらの弱点のため、RADIUSaaSのような多くのクラウドベースの最新認証サービスは、Pure MABやPAP、CHAPのような従来のプロトコルをサポートしていません。その代わり、暗号学的に強固なEAPトンネル内でMACアドレスを資格情報として使用するMAB-to-EAP方式を要求します。
## EAPを用いたMAB実装（MABに対するRADIUSaaSのアプローチ）
AuthenticatorでMABが構成されており、802.1Xをサポートしない従来型デバイスがネットワークアクセスを要求すると、スイッチまたはAPがそのデバイスになりすまし、クライアントに代わって認証を引き受けます 。RADIUSaaSがサポートするEAP [プロトコルのいずれかを使ってRADIUSaaSに認証することにより](https://docs.radiusaas.com/admin-portal/users#protocols): EAP-TTLS-PAPまたはPEAP-MSCHAPv2。このプロセスの一環として、RADIUSaaSは、MACアドレスが手動で追加された [ユーザー](/ja/ptaru/users.md)の形式でRADIUSaaSデータベースに登録されているかを確認します。（username = password = MAC address）もしあれば、 `Access-Accept` メッセージが返され、EAPベースの認証が完了して従来型デバイスにネットワークアクセスが付与されます。AuthenticatorはRADIUSaaSとのTLS接続を確立するため、RADIUSaaSが使用する [サーバー証明書](/ja/ptaru/settings/settings-server.md#server-certificates) を信頼する必要があります。
ユーザー名/パスワードとしてMACアドレスを使用してEAPを開始するのは、より強力なEAPプロトコルを利用しながらMABをシミュレートするためにAuthenticatorが実装する特定の回避策です。
### MABはRADIUSaaSで動作しますか？
PAPまたはCHAPを使用する本来の実装のMABは、RADIUSaaSでは動作しません。上記の定義を踏まえると、Authenticatorが前述のいずれかのプロトコルで認証できる限り、現在のRADIUSaaSの実装はMABをサポートできます。ただし、認証でこれらのサポート対象プロトコルを使用すると、もはや認証のバイパスではなくなり、この場合はより具体的な用語であるMAB-to-EAPが使用されます。
### 構成
**MAB** には、AuthenticatorとAuthentication Serverの両方での構成が必要です。
**Authenticator:**
* 802.1XとMAC Authentication Bypass (MAB)を、802.1X非対応デバイス向けの特定のアクセスポート/SSIDで有効にします。
* RADIUSサーバー証明書を [信頼する](/ja/ptaru/settings/settings-server.md#download).
* *注: 構成手順はベンダー固有です。デバイスのドキュメントを参照してください。*
**Authentication Server:**
* MAB-to-EAPを実装する場合、この方式で認証するすべてのデバイスを最小限のネットワークアクセスしか持たないフォールバックVLANに割り当てるため、RADIUSaaS上で明示的な許可ルールを作成する必要があります。これは最小権限の原則を徹底し、有効なMACアドレスを詐称した悪意ある人物が重要なネットワークリソースにアクセスするのを防ぐために不可欠です。ルールは、環境の認証ポリシーに基づいて構成する必要があります。
* MAB-to-EAPがユーザー名/パスワードベース認証の唯一の用途である場合: この資格情報タイプを使用する任意のデバイスをフォールバックVLANに割り当てる、広範な許可ルール（LAN/Wi-Fi）を作成します。
* ユーザー名/パスワードが他のクライアント（例: ユーザー）にも使用されている場合: このルールは、ユーザー名フィールド内のMACアドレスのパターン（例: `00:11:22:33:44:55`）に特異的に一致するよう、正規表現を使用して慎重に調整する必要があります。これにより、MAB-to-EAPトラフィックのみがフォールバックVLANに分離されます。
* MAB-to-EAPをサポートするには、 [追加して](/ja/ptaru/users.md#add) 次の形式のユーザーを作成する必要があります: Username = Password = MAC address. 例: `00:11:22:33:44:55` = `00:11:22:33:44:55`.
* MACアドレスの形式（コロン、ハイフン、またはなし）は、AuthenticatorがEAP資格情報で送信する形式と完全に一致していなければなりません。整合性のため、コロン表記（例: `00:11:22:33:44:55`）を推奨します。
* 複数のユーザーがいる場合は、 [CSV](/ja/ptaru/users.md#csv-import) ファイルを使って一括インポートできます。
---
# 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/mac-authentication.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.