ZERO-Trustで社内Webへ簡単にアクセス
導入の敷居が高そうなゼロ・トラストを簡単に自社Webシステムへのアクセスに利用する方法です。VPNの代替としても導入ができます。
VPNの問題点
VPNを使ったセキュリティモデルは「境界防御モデル」と呼ばれ、一度VPN経由で境界内に入った場合には、境界内の各種のサーバやシステムとアクセスが可能なためにセキュリティ上の懸念があります。
また、VPNでのアクセスはネットワークや機器にかかる負荷が高いため、在宅社員がリモートワークで一斉にアクセスすると、「遅い」とか「つながらない」などの状況に陥ります。
ゼロトラスト・モデル
IDとデバイスに対する認証を行い、認証を受けたユーザーや機器のみがターゲットのアプリにアクセスができるモデルが、ゼロトラストのセキュリティの考え方です。
ID管理 ( idP ) と ID認識型プロキシ ( IAP )
ユーザーやアクセス端末などの管理は、idP(identity Provider)で行います。
ゼロトラスト・モデルでは、ユーザー管理のidPとクライアントとターゲットのサーバーとの通信はD認識型プロキシ( IAP : Identity Aware Proxy )で中継します。
ID認識型プロキシはVPNでのアクセスに比べ高い負荷はかかりません。VPNのようなネットワーク全体へのアクセスではなく、許可されたユーザーと端末のみを指定のサーバーへアクセスさせるセキュアな運用ができます。
Microsoftをはじめ、各社から様々なZero-Trustのサービスや製品が提供されています。Zero-Trustモデルでは
1)idP : Identity Provider
ID管理 / ユーザーIDや利用端末および認証のアクセス管理機能
( IAM : Identity and Access Management と呼ばれることもあります )
2)ID認識型プロキシ / IAP : Identity Aware Proxy
クライアントとターゲットサーバーとの中継機能
の2つのモジュールが必要です。
ID認識型プロキシ( IAP : Identity Aware Proxy ) には、「透過型プロキシ」と「リバースプロキシ型」の2つの方式があります。利用する「ID認識型プロキシ」のタイプにより、導入時の構成やコストが大きく変わります。
透過型プロキシでの構成
- idP ユーザー管理・アクセス許可
- WAN側 ID認識型透過プロキシ 1台
- LAN側 プロキシコネクタ 1台
- エージェントやプログラムのインストールが必要
リバースプロキシでの構成
- idP ユーザー管理・アクセス許可
- WAN側 ID認識型リバースプロキシ 1台
- エージェントやプログラムのインストールは不要
WANから社内LAN側のサーバーへアクセスさせる際の比較
ID認識型プロキシの方式 | 透過プロキシ・タイプ | リバースプロキシ・タイプ |
ID管理 | idP必須 | idP 必須 |
ID認識型プロキシの台数 | WAN / LAN側にそれぞれ1台
合計2台 |
WAN側に1台のみ |
Firewallのポリシー | http / https 外向き | http / https 内向き |
エージェントなど | エージェントや専用プログラムのインストールが必須 | エージェントや専用プログラムは不要 |
ターゲットのサービス | Webサービス
Web以外のサービス(各社により相違) |
Webサービスに限定 |
ターゲットのOS | エージェントが動作もしくは専用プログラムがインストールできるOSに限定される | ターゲットWebのOSは問わない |
導入のコスト | 高い | 低い |
ベンダーロックイン | 発生しやすい | 発生しにくい |
透過プロキシタイプの場合は、社内のFirewallのポリシーは通常の通りにWeb ( http / https )は外向きのポリシーのままで利用ができます。ただしプロキシとプロキシコネクタはWAN側とLAN側にそれぞれ1台の合計2台が必要です。またエージェントや専用プログラムのインストールが必要のため、導入時の構成が大掛かりとなります。透過プロキシタイプの製品やサービスによっては利用するidPやターゲットサーバーのOSが限定されるケースもあり、ベンダーロックインが生じる場合もあります。
リバースプロキシの場合は、社内のFirewallのポリシーはターゲットのWeb ( http / https ) はLANへの内向きのポリシーを設定します。ターゲットのWebへのエージェントのインストールは不要のため、WAN側へのリバースプロキシ1台のみで手軽に導入が出来ます。利用するidPなども広く選択できることやターゲットWebのOSの制約もないので、ベンダーロックインなども発生しません。
ゼロトラストの簡単導入
ターゲットのサービスをWebに限定することで、ID認識型リバースプロキシが利用でき
- エージェントや専用プログラムのインストール不要
- ターゲットのWebサーバーやOSの制限無し
- ターゲットのWebサーバー側の変更不要
- ターゲットのWebサーバーの設置場所は任意( LAN / WAN )
- ID認識型プロキシはWAN側に1台のみ設置
などのシンプル構成でゼロトラスト導入や運用が可能です。
社内Webサーバーへのアクセスに際して、簡単にゼロトラスト・セキュリティを導入するために
1) idP / 認証サーバーとして「SAML認証対応のidP」
2) IAP / ID認識型プロキシとして「SAML認証対応のSP&ID認識型リバースプロキシ」
で構成をします。
- SAML形式のプロキシは、SP ( Service Provider )という名称になります
必要な機器
- idP ( Identity Provider )
SAML認証に対応のidPであればどれでも利用ができます
Azure AD / G Suite / TrustLogin / OneLogin / Okta / CloudGate Uno / HENNGE ONE / G SuiteなどのiDaaSや自社で運用の Keycloak / OpenAM 他など
- ID認識型リバースプロキシ( IAP : Identity Aware Proxy )
「SAML認証に対応のSP機能とリバースプロキシ」を1台で運用出来る「ID認識型リバースプロキシ」アプライアンス Powered BLUE Reverse Proxy for SSO / IDaaS を利用します。
Zero Trust モデルの構成&アクセス
社内Webサーバーへのアクセス 例
設定の手順
idP側の設定
- idPへアカウントを作成
- SAML認証を有効
- アクセスポリシーを設定
ID認識型リバースプロキシ側の設定
- リバースプロキシのSAML認証を有効
- リバースプロキシからのリダイレクト先Web-URLを指定
- リバースプロキシにはユーザーアカウントの作成不要
ゼロトラストでの認証のステップ
① ID認識型リバースプロキシへアクセス
② 初回のみidPへアクセス ( シングルサインオン )
③ idPの認証後にリバースプロキシ先のWebにリダイレクト
* SP initiated SAML および idP initiated SAMLに対応
WAN側に設置のサーバーへのアクセス
WAN側に設置のWebサーバーへのアクセスについても、ID認識型リバースプロキシ経由でアクセスさせることができます。Webの「認証が弱い」もしくは「認証がない」場合にも、ID認識型リバースプロキシ経由でのアクセスに限定することにより、ゼロ・トラスト・セキュリティの構成に組み込んでセキュアなWebアクセスでの運用ができます。
冗長構成
ロードバランサー配下での運用構成
複数の認証機能対応&自動同期のリバースプロキシで処理を行い高負荷にも対応
マルチAZでの運用構成
異なるアベイラビリティゾーンでの運用により、回線やデータセンターの耐障害性の向上。GSLBやRoute53などを利用して異なるデータセンター間でのリバースプロキシの同期と負荷分散を行います。
運用先 例
・リージョンA / 東日本データセンター
・リージョンB / 西日本データセンター
終わりに
ご不明な点などは、ムービットの お問い合わせフォーム からお問い合わせください。