社内Webシステムのゼロトラスト対応 / ID認識型リバースプロキシでの構成方法

ZERO-Trustで社内Webへ簡単にアクセス

導入の敷居が高そうなゼロ・トラストを簡単に自社Webシステムへのアクセスに利用する方法です。VPNの代替としても導入ができます。

 

VPNの問題点

VPNを使ったセキュリティモデルは「境界防御モデル」と呼ばれ、一度VPN経由で境界内に入った場合には、境界内の各種のサーバやシステムとアクセスが可能なためにセキュリティ上の懸念があります。

 

また、VPNでのアクセスはネットワークや機器にかかる負荷が高いため、在宅社員がリモートワークで一斉にアクセスすると、「遅い」とか「つながらない」などの状況に陥ります。

https://www.mubit.co.jp/pb-blog/wp-content/uploads/2020/06/vpn-1.png

 

ゼロトラスト・モデル

IDとデバイスに対する認証を行い、認証を受けたユーザーや機器のみがターゲットのアプリにアクセスができるモデルが、ゼロトラストのセキュリティの考え方です。ゼロトラスト・モデルでは、ID認識型プロキシ( IAP : Identity Aware Proxy )を利用します

ID認識型プロキシはVPNでのアクセスに比べ高い負荷はかかりません。VPNのようなネットワーク全体へのアクセスではなく、許可されたユーザーと端末のみを指定のサーバーへアクセスさせるセキュアな運用ができます。

 

ID管理 ( IAM ) と ID認識型プロキシ ( IAP )

 Microsoftをはじめ、各社から様々なZero-Trustのサービスや製品が提供されています。Zero-Trustモデルでは

1)ID管理 / ユーザーIDや利用端末および認証のアクセス管理

( IAM : Identity and Access Management )

2)ターゲットサーバーとの中継

ID認識型プロキシ( IAP : Identity Aware Proxy )

の2つが必要です。

 

ID認識型プロキシ( IAP : Identity Aware Proxy ) には、「透過型プロキシ」と「リバースプロキシ」の2つの方式があります。利用するID認識型プロキシのタイプにより、導入時の構成やコストが大きく変わります。

 

WANから社内LAN側のサーバーへアクセスさせる際の比較

ID認識型プロキシの方式 透過プロキシ・タイプ リバースプロキシ・タイプ
ID管理 IAM 必須 IAM 必須
ID認識型プロキシの台数 WAN / LAN側にそれぞれ1台

合計2台

WAN側に1台のみ
Firewallのポリシー http / https 外向き http / https 内向き
エージェント ターゲットWebへのエージェントのインストールが必須 エージェントは不要
ターゲットのサービス Webサービス

Web以外のサービス(各社により相違)

Webサービスに限定
ターゲットのOS エージェントがインストールできるOSに限定される ターゲットWebのOSは問わない
導入のコスト 高い 低い
ベンダーロックイン 発生しやすい 発生しない

透過プロキシタイプの場合は、社内のFirewallのポリシーは従来通りにWeb(http/https)は外向きのポリシーのままで利用ができます。ただしPorxyの台数が2台とターゲットのWebへのエージェントのインストールが必要のため、導入時の構成が大掛かりとなります。透過プロキシタイプの製品やサービスによっては利用するidPやターゲットサーバーのOSが限定されるケースもあり、ベンダーロックインが生じる場合もあります。

リバースプロキシの場合は、社内のFirewallのポリシーはターゲットのWeb(http/https)はLANへの内向きのポリシーを設定します。ターゲットのWebへのエージェントのインストールは不要のため、リバースプロキシの1台のみで手軽に導入が出来ます。利用するidPなども広く選択できることやターゲットWebのOSの制約もないので、ベンダーロックインなども発生しません。

 

ゼロトラストの簡単導入

ターゲットのサービスをWebに限定することで

  • エージェント不要
  • ターゲットのWebサーバーやOSの制限無し
  • ターゲットのWebサーバー側の変更不要
  • ターゲットのWebサーバーの設置場所は任意( LAN / WAN )
  • ID認識型プロキシはWAN側に1台のみ設置

などのシンプルな構成が可能です。

社内Webサーバーへのアクセスに際して、簡単にゼロトラスト・セキュリティを導入するために

1) 認証サーバー(IAM)として「SAML認証対応のidP」

2) ID認識型プロキシ(IAP)として「SAML認証対応のSP&ID認識型リバースプロキシ」

で構成をします。

  • SAML形式のIAMは、idP( Identity Provider )という名称になります
  • SAML形式のプロキシは、SP ( Service Provider )という名称になります

 

 

必要な機器

  •  IAM = 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 を利用します。

https://www.mubit.co.jp/sub/products/blue/img2/pb-vm-3.png

 

 

Zero Trust モデルの構成&アクセス

社内Webサーバーへのアクセス 例

https://www.mubit.co.jp/sub/products/blue/img2/idp-sp-10.png

 

設定の手順

idP側の設定

  • idPへアカウントを作成
  • SAML認証を有効
  • アクセスポリシーを設定

https://japan.zdnet.com/storage/2017/08/03/de5e58b6c73ae8f65bb4ce49490d6dce/newsigninpage.jpg

 

ID認識型リバースプロキシ側の設定

  • リバースプロキシのSAML認証を有効
  • リバースプロキシからのリダイレクト先Web-URLを指定
  • リバースプロキシにはユーザーアカウントの作成不要

 

 

ゼロトラストでの認証のステップ

1)ID認識型リバースプロキシへアクセス
2)初回のみidPへアクセス ( シングルサインオン )
3)idPの認証後にリバースプロキシ先のWebにリダイレクト

 

 

WAN側に設置のサーバーへのアクセス

WAN側に設置のWebサーバーへのアクセスについても、ID認識型リバースプロキシ経由でアクセスさせることができます。Webの「認証が弱い」もしくは「認証がない」場合にも、ID認識型リバースプロキシ経由でのアクセスに限定することにより、ゼロ・トラスト・セキュリティの構成に組み込んでセキュアなWebアクセスでの運用ができます。

 

冗長構成

ロードバランサー配下での運用構成
複数の認証機能対応&自動同期のリバースプロキシで処理を行い高負荷にも対応

 

 

マルチAZでの運用構成
異なるアベイラビリティゾーンでの運用により、回線やデータセンターの耐障害性の向上。GSLBやRoute53などを利用して異なるデータセンター間でのリバースプロキシの同期と負荷分散を行います。

運用先 例
・リージョンA / 東日本データセンター
・リージョンB / 西日本データセンター

 

終わりに

詳しい話を聞いてみたい方などは、ムービットの https://www.mubit.co.jp/sub/products/blue/img2/arrow-finger.gif お問い合わせフォーム からご連絡ください。