Ｗｅｂ教材一覧＞ ネットワーク＞ ネットワークセキュリティ技術
ＬＡＮ接続、IEEE 802.1X、ＥＡＰ、ＲＡＤＵＩＳ、ＰＰＰ、ＰＰＰｏＥ、サプリカント、認証装置、認証サーバ、ＥＡＰｏＬ、ＥＡＰ－ＭＤ５、ＥＡＰ－ＴＬＳ、ＰＥＡＰ、、ＭＡＣ ＲＡＤＩＵＳ認証、ＲＡＤＩＵＳ認証、ＰＡＰ、ＣＨＡＰ、Ｗｅｂ認証、ＡＮＤ認証、ＡＡＡ、送信ドメイン認証、メールサーバ、ＳＰＦ、ＤＫＩＮ、ＤＭＡＲＣ、エンベロープアドレス、ヘッダアドレス、ＤＮＳＳＥＣ、ＤＮＳキャッシュポイズニング、共有サイト、クライアント、リソースオーナー、リソースサーバ、認可サーバ、認証、認可、ＯｐｅｎＩＤ、OpenID Connect、ＯＡｕｔｈ、アクセストークン、マッシュアップ、Ｗｅｂサービス、シングルサインイン
利用者の端末機器をＬＡＮ（有線でも無線でも）に接続するとき、その接続を認めるかどうかを認証するための規格を対象にします。
ここでの主要プロトコルは、ＬＡＮ認証全般に関するIEEE 802.1X、その実装のうち、端末とスイッチハブやアクセスポイントとの間で認証を行うＥＡＰ、さらにネットワーク層で高度な認証を行うＲＡＤＵＩＳです。
Point-to-point とは、２台の機器を回線接続することです。ＰＰＰは、その接続での代表的な認証方式です。初期の電話回線利用時代には相手を決定するのに電話をかけました。それをダイアルアップＰＰＰ、イーサーネットが主流になった頃はＰＰＰｏＥ（PPP over Ethernet）といわれました。
ＰＰＰの通信は、データリンク層でのＬＣＰ（Link Control Protocol、リンク制御プロトコル）とネットワーク層でのＮＣＰ（Network Control Protocol、ネットワーク制御プロトコル）の２つの通信プロトコルを使用しています。
ＬＣＰではＰＡＰ（Password Authentication Protocol、パスワード認証プロトコル）やパスワードをハッシュ化して送るＣＨＡＰ（Challenge-Handshake Authentication Protocol）を使ってユーザ認証を行ってリンクを確立した後、ＮＣＰで多様な通信プロトコルに必要な設定や認証を行って接続を確立します。
当時から、ＰＰＰを用いた認証方式にＲＡＤＩＵＳがあり、認証サーバとして用いられていました。
ＥＡＰやＲＡＤＩＵＳは、ＰＰＰの発展プロトコルだといえます。現在ではＰＰＰをそのまま使うのは稀です。
IEEE 802.1xとは、有線LAN、無線LANで使用される認証プロトコルです。
以下の３要素が連携して認証します。
・サプリカント：ＬＡＮに接続する端末にインストールされた認証クライアント・ソフトウェア
・認証装置：IEEE 802.1x対応のスイッチングハブやアクセスポイント
・認証サーバ： 認証を判断するサーバ。RADIUSサーバなど。
端末と認証装置を接続したときに、サプリカントの情報（ユーザＩＤやパスワードなど）がＥＡＰメッセージとして認証装置に送られます。そのプロトコルがＥＡＰです。
認証装置は、自ら認証するのではなく、ＥＡＰメッセージを暗号化してＲＡＤＩＵＳパケットとして認証サーバに送ります。認証サーバは、端末のユーザＩＤやパスワードなどを調べて認証し、その結果を認証装置に戻します。
その結果を認証装置が受けて、端末の接続許可・拒否を決定するのです。
IEEE 802.1X の重要なプロトコルであるＥＡＰは、左図のような階層になっています。
ＥＡＰは、多くのプロトコルの集合体です。ＥＡＰをＬＡＮ環境に合わせたものをＥＡＰｏＬ（EAP over Lan）といいます。ＬＡＮでの通信プロトコルは、有線ＬＡＮ（Ethernet）では IEEE 802.3、無線ＬＡＮでは IEEE 802.11シリーズが一般的ですが、ＥＡＰｏＬはそれを仮想化して一つにまとめたものです。
また、ＥＡＰにはＥＡＰ－ＭＤ５やＥＡＰ－ＴＬＳなど多様な認証方式があります（後述）。
IEEE 802.1X の３要素であるサプリカント－認証装置－認証サーバ の関係は右図のようになります。
端末をＬＡＮに接続し、許可・拒否されるまでの手順は上図の右下のようになります。
（注）端末が有線ＬＡＮに参加するとは、通常は、既に設定してある多数の端末を接続しているＶＬＡＮ（Virtual Local Area Network）に新端末を追加することになります。キー通知でのキーとは、スイッチンハブでの該当するＶＬＡＮの番号のことです。
データリンク層での認証プロトコルＰＰＰを拡張した認証プロトコルの総称です。ＰＰＰは多様な環境で拡張機能をもつようになり、それらをＥＡＰｘｘのような名称がつけられました。IEEE802.1Xに規定されるフレームワークにおいて、どの認証方式を用いるかを指定するプロトコルです。仕様は、RFC 2284で規定されています。
ＥＡＰ自体はセキュリティ機能を持っていません。次に代表的な認証方式を掲げます。すべてクライアントとサーバ間を暗号化通信で行いますが、認証にユーザＩＤとパスワードを用いるか、ＳＳＬ／ＴＳＬでの電子証明書を用いるかの違いです。
端末 認証サーバ
ＥＡＰ－ＭＤ５ ユーザＩＤ、パスワード －
ＥＡＰ－ＴＬＳ 電子証明書 電子証明書
ＰＥＡＰ ユーザＩＤ、パスワード 電子証明書
ＲＡＤＩＵＳは、ダイアルアップ時代にインターネット接続において端末を認証するプロトコルでしたが、イーサーネットの時代になり端末と接続機器の間での認証に対応しました。そのような背景のため、ＲＡＤＩＵＳの基本仕様では非暗号化パスワードをそのまま流す PAP(Password Authentication Protocol)、チャレンジ型認証の CHAP は EAP-MD5 とは非互換などがありました。ＥＡＰはデータリンク層、ＲＡＤＩＵＳはネットワーク層のプロトコルでしたが、連携には問題があります。
RFC3579 で EAP over RADIUS の仕様が策定され、IEEE 802.1X はその仕様を採用しています。すなわち、IEEE 802.1X対応ＲＡＤＵＩＳでは、ＥＡＰとＲＡＤＩＵＳとの連携が円滑になり、端末と認証機器間の認証を EAPoL で行い、認証機器と認証サーバ間の認証を RADIUS で行うこと、EAPoLでのＥＡＰメッセージをＲＡＤＩＵＳパケットとして通信することが可能になったのです。現在のＲＡＤＩＵＳはIEEE 802.1X対応が通常です。
IEEE 802.1X での、全体の構造や認証の方法は前述しました。そのうち、認証装置と認証サーバ（ＲＡＤＩＵＳサーバ）との関係を簡単に復習します。
認証装置と認証サーバ間は Ethernat で接続され、認証装置がＲＡＤＩＵＳクライアント、認証サーバがＲＡＤＩＵＳサーバになります。
、
認証装置は端末から受け取ったＥＡＰメッセージを暗号化したＲＡＤＩＵＳパケットにして、認証サーバに端末の認証を依頼します。
端末と認証装置は既にＥＡＰｏＬでＬＡＮ接続されているので、認証装置と認証サーバ間の接続が確立すると、端末と認証サーバ間もＬＡＮで接続されたことになります。それに必要な情報交換を行います。
認証サーバは、ＥＡＰメッセージの内容（ユーザＩＤやパスワード、電子証明書など）を認証データベースの情報と突合せ、必要があれば、端末から追加情報を得たりして、端末の認証を行い、その結果を認証装置に戻します。
認証装置は、認証結果により接続の可否を端末に伝えます。接続許可のときはＬＡＮ通信に必要な情報を端末に伝えます。
ＲＡＤＩＵＳは、IEEE 802.1X 以外の認証プロトコルがあります。代表的なものを掲げます。
ＲＡＤＩＵＳの機能をＡＡＡということがあります。
ＲＡＤＩＵＳには、ユーザＩＤとパスワードの組み合わせだけなく、多様な情報を暗号化したＲＡＤＩＵＳデータベースをもっています。例えば、次のような項目もあります。
これらを１台のＲＡＤＩＵＳサーバで管理するよりも、内容に応じて複数のサーバに分散したほうが運用が容易になるとか、セキュリティの観点から分散させることもあります。
ゼロトラストとは「何も信頼しない」ことを前提としたセキュリティ対策の考え方です。
従来のセキュリティ対策は、保護すべきデータやシステムがネットワークの内側にあることを前提にしていました。それで、ネットワークを、信頼できる「内側」と信頼できない「外側」に分離し、その境界線にファイアウォールなどのセキュリティ機器を設置し、外部からの攻撃を遮断することが主流でした。
ところが現在は、保護すべき対象が外側のクラウドに存在するなど、境界が曖昧になり、従来の考え方が通用しない環境が出現してきました。ゼロトラストでは、すべてのユーザやデバイス、すべての通信を「信頼できない」ものとして捉えます。 具体的には、ネットワークの内外に関わらない通信経路の暗号化や多要素認証の利用などによるユーザー認証の強化、ネットワークやそれに接続される各種デバイスの統合的なログ監視、重要な情報資産やシステムへのアクセス監視などがあります。
その手段として、ワンタイムパスワード認証や端末認証などを利用した認証強化などとともに、次の手段が注目されています。
ここでは「なりすましメール」を防ぐことを対象にします。
メールを受け取ると、メールソフト画面の差出人の欄に、差出人の氏名あるいはメールアドレスが表示されますが、それは送信者が送信に使った本当のメールアドレスではなく、メールソフトのfrom欄に送信者が任意に記述したものなのです。悪意のある送信者は、この機能を使って、あたかも信頼のあるところからのメールのように見せかけることができます。
メールは、送信者端末機器→送信側メールサーバ→受信側メールサーバで送られます。そのプロトコルはＳＭＴＰですが、なまのＳＭＴＰは送信時の本人認証機能をもっていません。多くのプロバイダは、契約者に限定するなど何らかの認証方法を講じていますが、なかには認証をしないことをウリにしている（アングラ）サーバもあります。悪意の送信者はこのようなサーバを使って勝手なメールアドレスで送信できるのです。
その対策の一つに、送信側メールサーバと受信側メールサーバ間での転送メールに関して、受信側メールサーバが認証することがあります。それを送信ドメイン認証といいます。
代表的な送信ドメイン認証の方式に、ＳＰＦ、ＤＫＩＮ、ＤＭＡＲＣなどがあります。
ＳＦＰやＤＫＩＮは、単純な機能は認証対象は送信側メールサーバであり送信者ではありません。しかし、下記のように、送信者が自分のメールアドレスを詐称することが大きな問題です。
メールを送信するとき、郵便での封筒での住所に相当する受信者のメールアドレス(toアドレス）と送信者のメールアドレス（fromアドレス）を指定します。これをエンベロープto、エンベロープfromといいます。また、手紙に「～様」「～より」と書くことがあります。これらをヘッダto、ヘッダfromといいます。ヘッダアドレスは送信者が任意のアドレス（存在の有無不問）にすることができます。
メールの送受信は、エンベロープアドレスで行われます。不達メッセージエンベロープfromに通知されます。
ところが、受信者のメールソフトの「差出人」や「宛先」で表示されるのはヘッダアドレスなのです。受信者は、ヘッダfromからのメールだと判断します。
通常はエンベロープアドレスとヘッダアドレスは同じなのですが、例えば次のような理由により、異なるアドレスにしたいこともあります。
しかし、これを悪用すると、本当はエンベロープfromなのにヘッダfromだと思わせ、なりすますことができます。
ＳＦＰやＤＫＩＮを拡張して、メールの中身に入り、エンベロープアドレスとヘッダアドレスを比較して、一致しないときに警告を表示するようにしているものもあります。
しかし、一致しないときはすべて遮断するというのでは困ります。通過・遮断させるヘッダアドレスをリストするとか、悪意のヘッダアドレスを収集するなどの工夫が必要ですが、それには通常のプロトコルの範囲ではなく、メールソフトのフィルタリングやアンチウイルスソフトなどの分野になります。
ＤＮＳ（Domain Name System）とは、メールアドレスやＵＲＬのドメイン名とＩＰアドレスとを対応付けるシステムです。ＤＮＳサーバには、これまでに解決したドメイン名とＩＰアドレスの対応の一覧表を持っています。その一覧表にないときは、上位のＤＮＳサーバに聞きに行きます。このようにバケツリレー式に問い合わせることにより解決できるという仕組みです。
悪意を持つ者が、その一覧表を改ざんしてＩＰアドレスを悪意のあるメールサーバやＷｅｂサイトにすると、これまで信用してアクセスしていたメールアドレスやＵＲＬが、悪意を持つサーバに繋がれてします。この手口をＤＮＳキャッシュポイズニング（DNS cache poisoning）といいます。
キャッシュポイズニングは、そもそも怪しい（アングラ）サーバを介して、詐称したパケットが攻撃対象となるＤＮＳサーバに送信されることによるものです。
ＤＮＳＳＥＣでは、キャッシュポイズニングを防ぐ仕組みです。
ＤＮＳサーバが上位のＤＮＳサーバ（このＩＰアドレスが改ざんされているかもしれない）に問い合わせるとき、上位ＤＮＳサーバの電子証明書を得ることで、本来の上位のＤＮＳサーバであることを確認できます。また、問合せパケット内に、暗号化した特定の文字列を入れておき、応答の中の文字列が正しく復号できないときは、応答が不正サーバからであり、ここで得たＩＰアドレスが改ざんされているかもしれない（信用できない）と結論できます。
次のようなケースを例にします。
あなたは、共有サイトに、写真やアプリを登録しています。限定した友人からのアクセスを期待していますが、友人により、写真を見るだけ、写真の投稿、アプリの実行など限定したいのです。
あなたが、共有サイトに写真やアプリを投稿して、あなたの友人に写真を見せたりアプリを利用させることを例に、ここで用いる用語を説明します。
次の４つのサーバなどがあります。
認証（Authentication）誰であるかを特定すること OpenID
認可（Authorization） 利用権限を与えること OAuth
本人認証だけでは全ての権限を与えることになります。特定の処理だけに限定するには認可が必要です。逆に、認可されれば認証は不要だと考えられますが、認可情報は第三者に漏洩する可能性があるので、重要なときには認証も必要になります。
（注）OAuth 2.0 は、アクセストークンの要求方法とそれに対する応答方法を標準化したものです。
OpenID Connectは、OAuth 2.0を使ってＩＤ連携をする際に、OAuth 2.0では標準化されていない機能で、かつＩＤ連携には共通して必要となる機能を標準化したものです。
多くのサイトがそれぞれのサービス（Ｗｅｂサービス）をしています。例えば旅行の計画をするとき、列車予約と旅館予約の両方が必要になりますが、ＪＲや私鉄、個別の旅館のサイトをいちいち調べるのでは大変です。それらのＷｅｂサービスを束ねるポータルサイトがあれば便利です。
このような大規模のものでなく、店舗紹介ページにGoogle地図を埋め込むような小規模なものもあります。実際にはGoogleに利用を申し込むのですが、形式的には店舗ページがポータルサイト、Google地図がＷｅｂサービスになります。
このような仕組みをマッシュアップといいます。
ここでは、大規模マッシュアップを想定した記述になっています。テーマは、利用者がポータルサイトを介して多数のＷｅｂサービスサイトを巡回するとき、異なるサイトにはいるたびに、ユーザＩＤ、パスワードなどを入力する手間を省くために、ポータルサイトで入力したものだけでよい（シングルサインイン）ようにする仕組みです。
その仕組みには、OAuth 2.0／OpenID Connect を用います。
上述の「共有サイト」との関係、マッシュアップの特徴を列挙します。
技術的には、「共有サイト」での用語を使うべきでしょうが、不自然な表現になるので、勝手に（OAuth 2.0／OpenID Connect の規格用語ではない）用語を使います。
次のような手順により、利用者は最初のログインだけ（シングルサインイン）で、ポータルサイトに登録されているＷｅｂサービスサイトを巡回することができるのです。