2.2 ユーザー認証

Radius サーバーを用いた認証

「Radius サーバー」（Radius プロトコルに対応した認証サーバー）は、ソフトウェアベースのものとハードウェアベースのものの 2 種類があり、すでに広く普及しています。したがって、Radius ベースの認証サービスを持つ企業やインターネットサービスプロバイダなどは、ユーザー認証を Radius サーバーによって行わせるようにすることが可能です。

Radius 認証を使用するように設定されているユーザーがユーザー認証を行う場合、そのユーザーが送信した認証データ (SSL によって暗号化されます) は、SoftEther VPN Server から事前に設定されている Radius サーバーに対して送信されます。Radius サーバーでのユーザー認証に成功すると、SoftEther VPN Server はそのユーザーによる接続を許可します。それ以外の場合 (ユーザー認証に失敗した場合や Radius サーバーにアクセスできない場合) は接続を拒否します。

Radius 認証を使用する場合は、事前に Radius サーバー側で SoftEther VPN Server の IP アドレスを登録し、「共有シークレット」と呼ばれるパスワードを決定してから、仮想 HUB の設定を変更します。使用する Radius サーバーは仮想 HUB ごとに設定することができ、仮想 HUB 間のセキュリティ設定は互いに独立しています。仮想 HUB に対して Radius サーバーの設定を行う際に必要な項目は、下記の 3 項目です。

• 使用する Radius サーバーのホスト名または IP アドレス
• 使用する Radius サーバーの UDP ポート番号
• 事前に取り決めた共有シークレット

これらの情報は Radius サーバーの管理者から入手することができます。また、使用する Radius サーバーは「Password Authentication Protocol (PAP)」を使用可能なように設定しておく必要があります。

また、Radius サーバーに対して SoftEther VPN Server が通知するサーバー製品名は "SoftEther VPN Server" です。

Radius 認証

RADIUS Settings for Each User and for All Users

仮想 HUB 内のユーザーを Radius サーバーによって認証する場合、下記の 2 種類の方法があります。

• 事前に登録した一部のユーザーのみ Radius 認証を使用したい場合。
  この場合は、ユーザー認証方法として Radius 認証を使用するユーザーを作成し、そのユーザーの認証方法を「Radius 認証」に設定します。すると、そのユーザーが仮想 HUB に接続しようとしたときに入力した認証情報が Radius サーバーによって検証され、アクセスが許可または拒否されます。なお、このときに仮想 HUB のユーザーとしての「ユーザー名」と、Radius サーバー上での「ユーザー名」が異なる場合は、Radius サーバー上におけるユーザー名 (別名) を指定することができます。
• 原則として Radius サーバーに登録されているユーザー全員を Radius 認証によって仮想 HUB に接続させたい場合。すでに企業の Radius サーバーに全社員が登録されており、また仮想 HUB への接続を登録されているユーザーに対して原則として許可する場合は、ユーザー名として 「*」(アスタリスク 1 文字) という「ユーザー」を作成し、そのユーザーの種類を Radius 認証に設定することによって、どのようなユーザー名で接続が行われた場合でも常にそのユーザー名と認証情報を Radius サーバーに照会し、その結果認証に成功した場合は仮想 HUB へのアクセスが許可されます。この方法で Radius 認証に成功し仮想 HUB に接続したユーザーは、実際にはそのユーザー名のユーザーは仮想 HUB に登録されていないにもかかわらずユーザー認証に成功したことになりますが、その際のセキュリティポリシーの設定値は 「*」(アスタリスク 1 文字) ユーザーの設定値が使用されます。つまり、「*」 (アスタリスク 1 文字) ユーザーは、その方法で接続した VPN セッションに対するテンプレートとして利用されます。なお、原則として Radius サーバーに登録されたユーザー全員を VPN 接続させたいが、一部のユーザーのみは VPN 接続を禁止したい場合は、禁止したいユーザー名のユーザーを作成して、そのユーザーを Radius 認証に設定し、さらにセキュリティポリシーとして「アクセスを許可」を「無効」にすることでユーザー認証に失敗させることができます。また、「*」(アスタリスク 1 文字) ユーザーが登録されている場合でも、他に仮想 HUB に登録されているユーザーが存在する場合は、明示的に登録されているユーザーデータによるユーザー認証が先に試行され、それに失敗した場合のみ「*」(アスタリスク 1 文字) ユーザーを経由して Radius 認証が行われます。

NT ドメインコントローラまたは Active Directory コントローラを用いた認証

Windows Server による Windows ドメインはすでに広く普及しています。したがって、Windows ドメインベースの認証サービスを持つ企業やインターネットサービスプロバイダなどは、ユーザー認証を「NT ドメインコントローラまたは Active Directory コントローラ」によって行わせるようにすることが可能です。

NT ドメインおよび Active Directory 認証を使用するように設定されているユーザーがユーザー認証を行う場合、そのユーザーが送信した認証データ (SSL によって暗号化されます) は、SoftEther VPN Server から NT ドメインコントローラまたは Active Directory コントローラに対して送信されます。NT ドメインコントローラまたは Active Directory コントローラでのユーザー認証に成功すると、SoftEther VPN Server はそのユーザーによる接続を許可します。それ以外の場合 (ユーザー認証に失敗した場合や NT ドメインコントローラまたは Active Directory コントローラにアクセスできない場合) は接続を拒否します。

NT ドメインおよび Active Directory 認証を使用する場合は、SoftEther VPN Server を認証に使用する「Windows ドメイン」に参加させておく必要があります。Windows ドメインに参加している SoftEther VPN Server は、特別な設定をすることなく NT ドメインおよび Active Directory 認証が設定されているユーザーに対して、NT ドメインおよび Active Directory 認証を行うことができます。

NT ドメインおよび Active Directory 認証

ユーザーごとの NT ドメイン認証設定と全ユーザーに対する NT ドメイン認証設定

仮想 HUB 内のユーザーを、NT ドメインコントローラまたは Active Directory コントローラによって認証する場合、下記の 2 種類の方法があります。

• 事前に登録した一部のユーザーのみ NT ドメインおよび Active Directory 認証を使用したい場合。
  この場合は、ユーザー認証方法として NT ドメインおよび Active Directory 認証を使用するユーザーを作成し、そのユーザーの認証方法を「NT ドメインおよび Active Directory 認証」に設定します。すると、そのユーザーが仮想 HUB に接続しようとしたときに入力した認証情報が、NT ドメインコントローラまたは Active Directory コントローラによって検証され、アクセスが許可または拒否されます。なお、このときに仮想 HUB のユーザーとしての「ユーザー名」と、NT ドメインコントローラまたは Active Directory コントローラ上での「ユーザー名」が異なる場合は、NT ドメインコントローラまたは Active Directory コントローラ上におけるユーザー名 (別名) を指定することができます。
• 原則として NT ドメインコントローラまたは Active Directory コントローラに登録されているユーザー全員を NT ドメインおよび Active Directory 認証によって仮想 HUB に接続させたい場合。
  すでに企業の NT ドメインコントローラまたは Active Directory コントローラに全社員が登録されており、また仮想 HUB への接続を登録されているユーザーに対して原則として許可する場合は、ユーザー名として「*」(アスタリスク 1 文字) というユーザーを作成し、そのユーザーの種類を NT ドメインおよび Active Directory 認証に設定することによって、どのようなユーザー名で接続が行われた場合でも、常にそのユーザー名と認証情報を NT ドメインコントローラまたは Active Directory コントローラに照会し、その結果認証に成功した場合は仮想 HUB へのアクセスが許可されます。この方法で NT ドメインおよび Active Directory 認証に成功し仮想 HUB に接続したユーザーは、実際にはそのユーザー名のユーザーは仮想 HUB に登録されていないにもかかわらずユーザー認証に成功したことになりますが、その際のセキュリティポリシーの設定値は「*」(アスタリスク 1 文字) ユーザーの設定値が使用されます。つまり、「*」(アスタリスク 1 文字) ユーザーはその方法で接続した VPN セッションに対するテンプレートとして利用されます。なお、原則として NT ドメインコントローラまたは Active Directory コントローラに登録されたユーザー全員を VPN 接続させたいが、一部のユーザーのみは VPN 接続を禁止したい場合は、禁止したいユーザー名のユーザーを作成して、そのユーザーを NT ドメインおよび Active Directory 認証に設定し、さらにセキュリティポリシーとして「アクセスを許可」を「無効」にすることでユーザー認証に失敗させることができます。また、「*」(アスタリスク 1 文字) ユーザーが登録されている場合でも他に仮想 HUB に登録されているユーザーが存在する場合は、明示的に登録されているユーザーデータによるユーザー認証が先に試行され、それに失敗した場合のみ「*」(アスタリスク 1 文字) ユーザーを経由して NT ドメインおよび Active Directory 認証が行われます。

証明書認証に関する共通事項

「パスワード認証」や「Radius 認証」、「NT ドメインおよび Active Directory 認証」は、VPN クライアント側が接続先の SoftEther VPN Server に対して、正当な権限を持っていることをユーザー名とパスワードによって証明することによってユーザー認証を行います。「パスワード」を用いたユーザー認証方法は、一般的に十分なセキュリティを確保できますが、企業のセキュリティポリシーがパスワードを用いたユーザー認証を推奨しない場合は、より高い安全性を持った「証明書認証」(PKI 認証とも呼ばれます) を用いてユーザー認証を行う必要があります。証明書認証の方式には、「固有証明書認証」と「署名済み証明書認証」の 2 種類があり、ユーザーごとに使い分けることができます。SoftEther VPN Server に対して「クライアント証明書認証モード」で接続しようとする SoftEther VPN Client は、証明書および秘密鍵の格納場所として、クライアントコンピュータのハードディスクまたは外部のスマートカードのいずれかを選択することができます。

「証明書認証」は、仮想 HUB にコンピュータが接続しようとするとき、接続元のコンピュータが「ユーザー名」と共に「X.509 電子証明書」を提示することにより、SoftEther VPN Server がその証明書が正しいものであるかどうかを検証して、成功した場合のみ接続を許可する方法です。

接続元コンピュータは、提示する「証明書データ」と共に、その証明書内の公開鍵に対応した「秘密鍵 (RSA 秘密鍵)」を所有している必要があります。「証明書データ」は接続元のコンピュータから VPN Server に送信されますが、秘密鍵データは送信されません。次に、VPN Server がクライアントに対して乱数データ (「チャレンジ値」と呼ばれます) を送信し、それを受け取ったクライアントは乱数データを自己が保有している秘密鍵によって署名し、それを送り返します。VPN Server はクライアントから返送された署名データを、クライアントから最初に受け取った電子証明書内の公開鍵を用いて検証し、確かにクライアントコンピュータが、証明書とそれに対応した秘密鍵を所有していることを確認します (もし確認ができない場合は、直ちにユーザー認証は失敗します)。その後、クライアントが提示した証明書が、ユーザー認証データとしてユーザーごとに定義されている属性に一致しているかどうかを検査します。この際の検査方法には 2 種類あり、「固有証明書認証」または「署名済み証明書認証」を、目的に応じて選択することができます。

また、有効期限が切れた証明書、および仮想 HUB 単位で設定することができる「無効な証明書の一覧」リストに登録された証明書は「無効」として認識され、ユーザー認証に必ず失敗します。

証明書認証

固有証明書認証によるクライアント証明書認証

「固有証明書認証」は、あらかじめ仮想 HUB 側のユーザーデータベース内のユーザーに対して「証明書データ」を登録しておき、ユーザーが提示した証明書が事前に登録された証明書と完全に一致する場合に接続を許可する方法です。

固有証明書認証のメリット

「固有証明書認証」を使用すると、SoftEther VPN が持つ証明書認証機能を最も簡単に使用することができます。特に証明書認証を利用するユーザーの数が数ユーザー～数十ユーザー程度の場合は、固有証明書認証機能で十分に VPN システムを運用することができます。具体的な運用方法としては、仮想 HUB の管理者がいくつかの X.509 証明書を作成しておき、それを仮想 HUB に順番に登録しつつ、証明書と秘密鍵をユーザーに安全な方法 (社内 LAN 内の電子メール、共有フォルダ、またはスマートカード) で手渡すことによって、証明書と秘密鍵を持ったユーザーはいつでもそれを用いて VPN Server の仮想 HUB に接続することができます。逆に、証明書はユーザーの側で生成しておき、その証明書をユーザーが仮想 HUB の管理者に渡すことによって証明書を登録することもできます (この方法では、秘密鍵はユーザーの手元から外に出ることはないのでより安全です)。

秘密鍵および X.509 証明書の作成は、既存の様々な PKI に対応したユーティリティ (フリーウェアや市販ソフトウェア) などによって行うことができます。また、「SoftEther VPN サーバー管理マネージャ」の機能の一部である「証明書作成ツール」および「SoftEther VPN コマンドライン管理ユーティリティ」(「6. コマンドライン管理ユーティリティマニュアル」 を参照してください) の「MakeCert」コマンドによって、X.509 証明書ファイルと秘密鍵ファイルを作成することもできます。この簡易ユーティリティは、「自己署名証明書」と「署名済み証明書」の両方の作成をサポートしています。

固有証明書認証のデメリット

「固有証明書認証」は、登録する必要があるユーザー数が多数の場合や、すでに企業内で PKI を導入しており、各社員が「スマートカード」(社員証など) に「秘密鍵」を持っているような場合には利用しにくい方法です。そのような場合は、「署名済み証明書認証」を選択することをお勧めします。

署名済み証明書認証によるクライアント証明書認証

「署名済み証明書認証」は、すでに企業などで各社員に対して企業の CA (証明機関) が、1 つずつ X.509 証明書および秘密鍵ファイルを配布している状況で使用する際に便利な認証方法です。また、現在まだ PKI システムを導入していないが、大量のユーザーを仮想 HUB にアクセスさせたい場合で、証明書認証を使用したい場合にも利用することができます。この方法を利用する場合の必要条件は下記のとおりです。

• 仮想 HUB にアクセスする各ユーザーに対して「X.509 証明書およびそれに対応する秘密鍵」を、ファイルまたはスマートカードの形式で配布している。
• それぞれのユーザー用の証明書は、企業内の CA (証明機関) などの持つルート証明書 (または中間証明書) と秘密鍵によって署名されており、木構造状の信頼関係がある。

「署名済み証明書認証」を使用する場合は、あらかじめ仮想 HUB の「信頼する証明機関の証明書」リストに、各ユーザーの証明書を署名したルート証明書 (または中間証明書) を登録しておきます。

次に新しいユーザーを作成し、そのユーザーの認証方法を「署名済み証明書認証」に設定します。これにより、そのユーザー名として接続してきたクライアントコンピュータが提示した証明書が、仮想 HUB に登録されている「信頼する証明機関の証明書」リストに登録されている証明書のいずれかによって署名されていることが確認できれば、そのクライアントコンピュータに対するユーザー認証は成功します。

ただし、このような方法だけでは、企業のルート CA が発行した証明書を持つ社員であれば誰でも平等に扱われるため、たとえば一部の証明書を持つ社員については、通信できるプロトコルの種類を増やしたいといったユーザーごとの差別化を行う場合には、次に解説する「Common Name またはシリアル番号による接続可能証明書の限定」という方法を併用します。

Common Name またはシリアル番号による接続可能証明書の限定

X.509 証明書の内容には「Common Name」(CN) および「シリアル番号」が含まれている場合があります。そのような場合は、Common Name およびシリアル番号を限定することによって、たとえその証明書が仮想 HUB の信頼できる証明書によって署名されている場合が確認できた場合でも、Common Name またはシリアル番号の、いずれか 1 項目または両方の項目が完全に一致しない限りアクセスを拒否することができます。

この機能を活用すると、信頼できる証明書によって署名された証明書のうち、特定のシリアル番号または CN 値を持っている場合のみ接続できるユーザーを作成しておくことにより、持っている証明書の種類によってセキュリティポリシーなどの差別化を行うことができます。