目次
フォワードプロキシの認証と認可
目次フォワードプロキシの認証の仕組み
フォワードプロキシを使用することで、クライアントは直接インターネットに接続せずとも、プロキシサーバを経由してWebコンテンツにアクセスできます。
フォワードプロキシを使用するか否かは、クライアント側のPC端末の設定でコントロールするため、本来はインターネットとアクセスしてはいけない利用者についての制限機能が必要になります。
それが「フォワードプロキシの認証機能」です。
フォワードプロキシの認証機能では、ネットワーク内でプロキシサーバーを経由してインターネットやその他のネットワークリソースにアクセスする際に、ユーザーの身元を確認するプロセスが入ります。
この仕組みを使うことで、承認されたユーザーのみがネットワークリソースにアクセスできるようにし、不正なインターネットアクセスを防止することができます。
基本的な動作としては、ユーザーがウェブサイトなどにアクセスしようとすると、そのリクエストはまずプロキシサーバーに送信されます。
プロキシサーバーはこのリクエストを受け取ると、ユーザーが認証済みかどうかを確認します。
未認証の場合、プロキシサーバーは認証要求をユーザーに送り返し、認証方法によっても変わりますが通常はブラウザ上にユーザー名とパスワードを入力するためのダイアログボックスが表示されます。
ユーザーが正しい認証情報を入力すると、プロキシサーバーはその情報を検証し、認証が成功した場合にのみ元のリクエストを処理し、インターネットへのアクセスを許可します。
企業のプロキシにおいては、認証機能が実装されているものが多いと思います。
フォワードプロキシを使用するか否かは、クライアント側のPC端末の設定でコントロールするため、本来はインターネットとアクセスしてはいけない利用者についての制限機能が必要になります。
それが「フォワードプロキシの認証機能」です。
フォワードプロキシの認証機能では、ネットワーク内でプロキシサーバーを経由してインターネットやその他のネットワークリソースにアクセスする際に、ユーザーの身元を確認するプロセスが入ります。
この仕組みを使うことで、承認されたユーザーのみがネットワークリソースにアクセスできるようにし、不正なインターネットアクセスを防止することができます。
基本的な動作としては、ユーザーがウェブサイトなどにアクセスしようとすると、そのリクエストはまずプロキシサーバーに送信されます。
プロキシサーバーはこのリクエストを受け取ると、ユーザーが認証済みかどうかを確認します。
未認証の場合、プロキシサーバーは認証要求をユーザーに送り返し、認証方法によっても変わりますが通常はブラウザ上にユーザー名とパスワードを入力するためのダイアログボックスが表示されます。
ユーザーが正しい認証情報を入力すると、プロキシサーバーはその情報を検証し、認証が成功した場合にのみ元のリクエストを処理し、インターネットへのアクセスを許可します。
企業のプロキシにおいては、認証機能が実装されているものが多いと思います。
認証の実装方式
HTTP基本認証(Basic認証)
最もシンプルで広く対応されている方式です。ユーザー名とパスワードをBase64でエンコードして「Authorization」ヘッダーで送信します。
ブラウザはポップアップダイアログボックスを表示して認証情報を要求します。
実装が容易である一方、認証情報が実質的に平文で送信されるため、HTTPS接続上でないと安全ではありません。
ダイジェスト認証
基本認証よりも安全な代替手段として設計され、パスワードそのものではなくハッシュ値を送信します。チャレンジ-レスポンス方式を使用し、サーバーが送信する「nonce」（使い捨ての乱数）とパスワードから計算したハッシュ値を返します。
パスワード自体が送信されないため、基本認証より安全ですが、設定と実装が複雑になります。
NTLM認証
Microsoftによって開発され、主にWindows環境で使用されます。Windowsのドメイン認証と統合されており、ユーザーがWindowsにログインした認証情報を再利用できるため、別途認証情報を入力する必要がありません。
ただし、Microsoft製品以外との互換性に制約があります。
Kerberos認証
統合Windows認証の一部で、セキュアでスケーラブルな認証を提供します。チケットベースの認証システムを使用し、一度認証すれば複数のサービスにアクセスできるシングルサインオン機能を持っています。
主に企業環境で使用され、設定は複雑ですが、高いセキュリティと効率的なユーザー体験を実現します。
フォームベース認証
HTMLフォームを使用してユーザー名とパスワードを収集します。標準的なブラウザダイアログではなく、カスタマイズされたログイン画面を表示できるため、ブランディングや多要素認証など高度な要件に対応できます。
キャプティブポータルとも呼ばれ、正常に認証されるとクッキーやセッショントークンが発行され、以降のリクエストにこれが使用されます。
多要素認証の統合
最近のフォワードプロキシの認証では、多要素認証を実装するケースも増えています。
今まで説明した認証方式はユーザー名とパスワードを使用した認証でしたが、それに加えてスマートフォンなどに使い捨てのワンタイムパスワードを連携し、追加認証する方式です。
フォワードプロキシ環境での多要素認証の統合は、主に次のようなアプローチで実装されます。
フォームベース認証を基盤とする方法が最も一般的なので、例として解説します。
この場合、ユーザーはまずカスタムHTMLフォームで従来の認証情報（ユーザー名とパスワード）を入力し、その後に追加の認証要素（ワンタイムパスワードなど）の入力を求められます。
フォームベース認証は柔軟に入力項目などを設定できることから複雑な認証フローを実装するMFAに最も適しているのです。
例えば、パスワードを確認した後、登録されたモバイルデバイスにプッシュ通知を送信し、ユーザーがそれを承認するというフローも作成できます。
この場合は、HTMLやCSS、Javascriptといったフロントエンド開発の知識と認証ロジックを処理するバックエンドの開発知識が必要ですし、モバイルデバイスへのプッシュ通知にはモバイルアプリの知識も必要となるため、技術的なハードルは高いのが正直なところです。
ですので、実際にはサードパーティのMFAサービスを利用したり、エンタープライズ向けのプロキシ製品(Zscaler、Cisco Umbrella、Fortigate、Palo Alto Networksなど)には、もともと多要素認証機能が備わっているものもあるので、そういったものを活用します。
今まで説明した認証方式はユーザー名とパスワードを使用した認証でしたが、それに加えてスマートフォンなどに使い捨てのワンタイムパスワードを連携し、追加認証する方式です。
フォワードプロキシ環境での多要素認証の統合は、主に次のようなアプローチで実装されます。
フォームベース認証を基盤とする方法が最も一般的なので、例として解説します。
この場合、ユーザーはまずカスタムHTMLフォームで従来の認証情報（ユーザー名とパスワード）を入力し、その後に追加の認証要素（ワンタイムパスワードなど）の入力を求められます。
フォームベース認証は柔軟に入力項目などを設定できることから複雑な認証フローを実装するMFAに最も適しているのです。
例えば、パスワードを確認した後、登録されたモバイルデバイスにプッシュ通知を送信し、ユーザーがそれを承認するというフローも作成できます。
この場合は、HTMLやCSS、Javascriptといったフロントエンド開発の知識と認証ロジックを処理するバックエンドの開発知識が必要ですし、モバイルデバイスへのプッシュ通知にはモバイルアプリの知識も必要となるため、技術的なハードルは高いのが正直なところです。
ですので、実際にはサードパーティのMFAサービスを利用したり、エンタープライズ向けのプロキシ製品(Zscaler、Cisco Umbrella、Fortigate、Palo Alto Networksなど)には、もともと多要素認証機能が備わっているものもあるので、そういったものを活用します。
まとめ
フォワードプロキシの認証機能について、解説してきました。
プロキシはインターネット上のWebコンテンツとの仲介役ですが、そこには高度なセキュリティが必要になります。
企業においては、誰でも自由にインターネットに出れてしまう環境は情報漏洩にも繋がってしまうので、必ずセキュリティ上の防波堤を実装します。
その考えはフォワードプロキシにも適用されるものです。
フォワードプロキシもシステム基盤として、必須級のものになりますので、セキュリティ設計を理解しておきましょう。
プロキシはインターネット上のWebコンテンツとの仲介役ですが、そこには高度なセキュリティが必要になります。
企業においては、誰でも自由にインターネットに出れてしまう環境は情報漏洩にも繋がってしまうので、必ずセキュリティ上の防波堤を実装します。
その考えはフォワードプロキシにも適用されるものです。
フォワードプロキシもシステム基盤として、必須級のものになりますので、セキュリティ設計を理解しておきましょう。