IAP – ムービットのブログ https://www.mubit.co.jp/pb-blog Powered BLUE サーバー Thu, 01 Jun 2023 03:04:42 +0000 ja hourly 1 https://wordpress.org/?v=6.5.2 iDaaS対応Azure AD連携 SAML認証のリバースプロキシ / NTT communications社のSDPF クラウド/サーバー上に構築運用 https://www.mubit.co.jp/pb-blog/?p=13232 Wed, 30 Jun 2021 03:37:13 +0000 https://www.mubit.co.jp/pb-blog/?p=13232 NTT communications が運用するOpenStackのクラウド基盤である、
SDPF クラウド/サーバー（旧 Enterprise Cloud）上にSAML認証対応のリバースプロキシサーバーを構築します。

IDaaS/idPのAzure ADを利用して、テレワークで社内LAN側に設置のWebサーバーにSAML2.0対応のSP機能を持つリバースプロキシ/Reverse Proxy経由でアクセスする場合の構成です。

SP/リバースプロキシの冗長化による負荷分散やマルチリージョン(マルチAZ)での運用も可能です。

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

 

 

NTT communications 社のSDPF クラウド/サーバー での構築

SAML認証対応のリバースプロキシとしては、https://www.mubit.co.jp/sub/products/blue/img2/arrow-finger.gif「Powered BLUE Reverse Proxy for SSO/IDaaS」

を利用します。SDPF クラウド/サーバー環境で構築する方法は

https://ecl.ntt.com/documents/tutorials/_images/instance_create_from_image_disk2.png

https://www.mubit.co.jp/sub/products/blue/img2/arrow-finger.gif　Enterprise CloudにCentOS/RedHat対応Powered BLUEをセットアップ　する
を参照してください

 

Azure AD 連携

Azure AD のSAML認証機能とSAML認証に対応のリバースプロキシのみを利用します。またAzure ADの認証とは別にSP/リバースプロキシ上でSSLクライアント認証などの独自の認証を設定することができます。

  • idP / Azure AD
  • SP / SAML対応リバースプロキシ

 

ゼロトラスト対応

SAML認証対応のリバースプロキシは、「ID認識型リバースプロキシ」として動作します

idPと連携するゼロトラストでの運用となります

ID管理や端末のアクセス設定などのゼロトラスト関連の事項は、すべてidP/Azure AD側で設定をします

Azure AD アプリケーションプロキシとは異なり

  • エージェントは不要
  • ターゲットネットワーク側のプロキシコネクタは不要

のため、「idP」と「ID認識型リバースプロキシ」のみで導入が出来ます。またエージェントなどが不要のためリバース先のWebサイトのOSなどに制約はありません（任意のOSに対応）

https://www.mubit.co.jp/sub//products/blue/img2/zero-trust-17.png

 

 

リモートワーク＆ブラウザ

リモートワーク時の社内Webへのアクセスに際して、モバイル用の閉域網やVPN、専用のエージェントなどは不要です。ユーザーはブラウザのみで利用できます。

https://www.mubit.co.jp/sub/products/blue/img2/burauza-1.png

 

idP(アイデンティティ・プロバイダ）

https://i2.wp.com/techlife.tokyo/wp-content/uploads/2018/07/AzureAD.png?resize=768%2C311&ssl=1

idPとしてはSAML2.0に対応した　Azure ADの他、TrustLogin、G suiteやCloudGate UNO、HENNGE ONE(旧HDE ONE)、OneLogin、Okta等のIDaaSなどや、OpenAM、Keycloakなどと連携が出来ます。

 

ID認識型リバースプロキシ

SPとしては、SAML2.0に対応した「ID認識型リバースプロキシ」機能を持つ「Powered BLUE Reverse Proxy  for SSO/IDaaS」を利用します。

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

この製品は

  • SAML2.0対応のWeb&リバースプロキシ機能
  • Web/Mail/DNS/ftp（インターネットサーバー機能）
  • Let’s Encrypt （フリープラグインで提供）
  • 仮想アプライアンス
  • SSLクライアント認証
  • ワンタイムパスワード認証
  • ひとり情シスでの運用に対応

のリバースプロキシ・アプライアンスです。CentOSやRedHatに対応しておりAzure / AWSなどのクラウド環境や、VMware / Hyper-Vなどの仮想環境でオールインワンで運用することが出来ます。

自社で運用出来るリバースプロキシでは、idPの認証の他にリバースプロキシ独自で、SSLクライアント認証やワンタイムパスワード認証を設定することが可能です。社内LAN側へのアクセスに際して自社のポリシーを個別に適用したい場合などには有効です。

 

ユーザーアカウント不要

SP側のリバースプロキシサーバーにはユーザーアカウントを作成することなくidP/Azure ADによるSAML認証を行い、内部のWebサーバーへ中継させることが出来ます。またグループアクセスでのコントロールに対応しています。

グループアクセスコントロール　例

  • 営業部・開発部・支店のみにアクセスを許可
  • 管理職のみにアクセスを許可
  • 社員・会員・代理店のみにアクセスを許可

SP側のリバースプロキシにはユーザーアカウントがないため、SP側のリバースプロキシからのアカウント漏洩の心配はありません。またアカウントがないので運用が簡単です。

 

SP（サービス・プロバイダ）

「Powered BLUE Reverse Proxy for SSO/IDaaS」をSAML2.0のSP（サービスプロバイダ）として設定します

 

SAML2.0の設定例

http://wp-sam.mubit.jp/　以下の指定ディレクトリにSAML2.0の認証を設定する例です

を利用します。

idPとSPにそれぞれ、SAML認証の設定を行います。

 

構成例

ID認識型リバースプロキシでの設定例です

https://www.mubit.co.jp/sub//products/blue/img2/zero-trust-17.png

 

SAML/SP リバースプロキシのWebサイト

例　https://wp-sam.mubit.jp

  • リバースプロキシ上でSAML2.0の認証を行います
  • SAML認証後に、リバースプロキシにより指定のサイトへリダイレクトさせます

例　社内のSharePointへアクセス

https://www.mubit.co.jp/sub/products/blue/img2/share-point-2-2.png

 

例　社内のWeb Mailへアクセス

https://www.mubit.co.jp/sub/products/blue/img2/roundcube-iphone-1.png

 

ネットワーク構成

ブログのサイトへリレイ

idP  ⇒  SP (Reverse Proxy )https://wp-sam.mubit.jp/blog  ⇒  https://sni-1.mubit.jp/blog/

 

Webメールのサイトへリレイ

idP  ⇒  SP (Reverse Proxy )https://wp-sam.mubit.jp/webmail/  ⇒  https://sni-1.mubit.jp/webmail/

 

設定構成

以下のようなリバースプロキシ構成での設定例です

例　User　 ⇒  　https://wp-sam.mubit.jp/blog 　⇒　 https://sni-1.mubit.jp/blog/

例　User　 ⇒  　https://wp-sam.mubit.jp/webmail/　 ⇒  　https://sni-1.mubit.jp/webmail/

 

SP側の設定

Powered BLUE Reverse Proxy  for SSO/IDaaSにリバースプロキシを運用する仮想サイトを作成

例　http://wp-sam.mubit.jp

 

Webサーバの有効化

Webサーバーを有効にする　にチェックを入れます

仮想サイトのSSL化

リバースプロキシを運用するWebサイトのSSL化を行ないます。SAML認証に際しては、WebサイトのSSL化が必須です。

SSLのサーバー証明書としては

  • サイトのSSL自己証明
  • パブリックなSSLサーバー証明書
  • Let’s EncryptでのSSLサーバー証明書

に対応しています。

 

WebサイトのSSL自己証明の場合

SSLを有効にする　にチェックを入れます

https://www.mubit.co.jp/pb-blog/wp-content/uploads/2019/06/B870-saml-2.png

 

パブリックなSSLサーバー証明書の場合

必要情報を記載して「署名リクエストの作成」ボタンで作成したテキストを、SSLサーバー証明書を発行する機関へ送付します。

https://www.mubit.co.jp/pb-blog/wp-content/uploads/2015/12/csr-1.png

  • 「署名リクエストの作成」でファイルを保存
  • 作成された「署名リクエスト」　ファイル　signig-request.txt を、公的なSSLサーバー証明書の発行機関へ送付

signing-req-1

  • 公的機関で発行された、サーバー証明書を　「インポート」　します
  • 中間証明書のインポートにも対応しています

SSLサーバー証明書が発行されたら「インポート」ボタン操作でSSLサーバー証明書をインポートします

https://www.mubit.co.jp/pb-blog/wp-content/uploads/2015/12/ssl-import-1.png

 

Let’s Encryptの場合

フリープラグイン機能を利用して、Let’s Encryptプログラムをインポートします

FreeSSLを選択

「インストール」　ボタンをクリック

 

Let’s Encryptインストール後に　「有効にする」　にチェックを入れます

 

リバースプロキシ

作成した仮想サイトにリバースプロキシを設定します

複数のリバースプロキシ先/バックエンドを指定できます

 

例　https://wp-sam.mubit.jp/blog/  　 ⇒  　 https://sni-1.mubit.jp/blog/

例　 https://wp-sam.mubit.jp/webmail/　 ⇒  　http://sni-1.mubit.jp/webmail/

 

SAML2.0設定

SAMLのエンドポイントを指定します　　例　/

idP側のxmlのメタデータをSPへインポートします

https://www.mubit.co.jp/pb-blog/wp-content/uploads/2019/06/b870-saml-13.png

idP側のxmlのメタデータをインポートします

SP側のxmlのメタデータをダウンロードします

https://www.mubit.co.jp/pb-blog/wp-content/uploads/2019/06/b870-saml-13.png

idP側で作成のメタデータ（xml）をアップロードします

https://www.mubit.co.jp/pb-blog/wp-content/uploads/2019/06/b870-saml-14.png

SAML2.0の認証をかけたいdirを指定します

例　/blog

https://wp-sam.mubt.jp/blog/  　にSAML認証が適用されます

グループアクセスでのコントロールが不要の場合には、SP側はここまでの設定です。

https://wp-sam.mubt.jp/webmail/ 　 　にSAML認証を適用させる場合も、同様の設定を行います

 

 

attributeの指定

グループでのリバースプロキシへのアクセスコントロールを行なう場合に、attributeを追加で設定します

それぞれのパスに対して、idP側で設定の　attribute-value　もしくは　ロール　の指定が出来ます

部門毎やグループ毎などにリバースプロキシへのアクセスコントロールを行ないたい場合には、便利な機能です。

  • 例　営業部・開発部・総務部はidPでリバースプロキシへのアクセスを許可する
  • 例　特定の役職以上はリバースプロキシへのアクセスを許可する

attribute=”groups”    value=”  mbt”  でのアクセスを許可の場合の設定例

https://www.mubit.co.jp/pb-blog/wp-content/uploads/2019/06/b870-saml-17.png

 

samlの有効化

設定のSAMLを有効にします

https://www.mubit.co.jp/pb-blog/wp-content/uploads/2019/06/b870-saml-15.png

 

 

idPの設定

idP/IDaaSでSAML2.0をサポートしていれば、Powered BLUE Web for SSO/IDaaSと接続が出来ます。

今回はidPとしてAzure ADを利用します

 

Azure AD の前提条件

  • Azure AD Premium

 

エンタープライズ アプリケーションブレード

自社独自のSAMLベースWebを登録の場合には、[エンタープライズ アプリケーション] ブレードを使用して、アプリケーションを Microsoft ID プラットフォームに接続します。

  • お使いの Microsoft ID プラットフォーム管理者アカウントを使用して、Azure Active Directory ポータルにサインインします。
  • Azure Active Directory を選択
  • [エンタープライズ アプリケーション] > [新しいアプリケーション] の順に選択します。
  • (省略可能だが推奨) [ギャラリーから追加する] 検索ボックスに、アプリケーションの表示名を入力します。 検索結果にアプリケーションが表示されたら、それを選択し、この手順の残りをスキップします。
  • [ギャラリー以外のアプリケーション] を選択します。 [独自のアプリケーションの追加] ページが表示されます。

  1. 新しいアプリケーションの表示名を入力します。
  2. [追加] を選択します。

この方法でアプリケーションを追加することにより、事前に統合されたアプリケーションに似たエクスペリエンスを提供します。 まず、アプリケーションのサイドバーから、 [シングル サインオン] を選択します。 次の画面 ( [シングル サインオン方式の選択] ) は、SSO を構成するためのオプションを示しています。

 

SAMLを選択

① 基本的なSAML構成を選択

idp側のxmlを読み込み

メタデータファイルをクリック

idPに読み込むメタデータファイルの指定（SP側のxmlファイル）

もしくは、以下の項目をxmlの内容に沿って記述します

Azure AD SAML の設定例

SAMLの項目

SP側のxmlの内容に従って、以下の項目を設定します。SP側のxmlファイルのアップロードでの登録も出来ます。

エンティティID

https://wp-sam.mubit.jp/endpoint/metadata

 

応答URL (Assertion Consumer Service URL )

https://wp-sam.mubit.jp/endpoint/postResponse

 

サインオンURL

https://twp-sam.mubit.jp/develop-dep/

 

リレー状態

空欄でも可能

 

ログアウトURL

空欄でも可能

② ユーザー属性とクレーム

必要に応じて設定

③ SAML署名

idP/Azure AD側のフェデレーションメタデータ(XML)をダウンロードして、SP側に登録します

グループアクセスコントロールが不要の場合には、ここまでの設定となります

Validate

idPおよびSP側の設定が正しければ、「Validate]　ボタンをクリックすると　SP側のWebページが表示されます。

例　現在のユーザーとしてサインイン

エラーが表示される場合には、メッセージをコピーします

エラーが表示される場合には、メッセージをクリップボードに貼り付けると修正方法が、サジェスチョンされます

エラーを適宜修正して、正常にアクセス出来ればセットアップは終了です。

SAMLアプリケーションにユーザーとグループのアサイン

作成したSAMLアプリケーションを利用出来る、ユーザーやグループを割り当てます

  • アプリケーションのサイドバーで、 [ユーザーとグループ] を選択します。 [<アプリケーション名> – ユーザーとグループ] ページが表示され、割り当てられたユーザーとグループの現在の一覧が示されます。
  • [ユーザーの追加] を選択します。 [割り当ての追加] ページが表示されます。
  • [ユーザーとグループ] (選択した <数>) を選択します。 [ユーザーとグループ] ページが表示され、使用可能なユーザーとグループの一覧が示されます。
  • 一覧から割り当てるユーザーまたはグループを入力するか、スクロールして見つけます。
  • 追加する各ユーザーまたはグループを選択し、 [選択] ボタンを選択します。 [ユーザーとグループ] ページは表示されなくなります。
  • [割り当ての追加] ページで [割り当て] を選択します。 [ – ユーザーとグループ] ページが表示され、追加ユーザーが一覧に示されます。

https://docs.microsoft.com/ja-jp/azure/active-directory/manage-apps/media/configure-single-sign-on-non-gallery-applications/application-users-and-groups.png

 

シングルサインオンでの認証のステップ

①   ID認識型リバースプロキシへアクセス
②   初回のみ idP へアクセス ( シングルサインオン ）
③　idPの認証後にリバースプロキシ先のWebサイトの表示

https://www.mubit.co.jp/pb-blog/wp-content/uploads/2020/11/idp-sso-1.png

* SP initiated SAML および idP initiated SAMLに対応

 

アクセス

https://wp-sam.mubit.jp/develop-dep/

 

初回

シングルサインオンでは、一度  idP/Azure AD  へのログイン

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

 

ターゲットのwebページ

SAML認証後に設定のターゲットのWebページが表示されます

sharepointへ

https://www.mubit.co.jp/sub/products/blue/img2/share-point-2-2.png

WordPressへ

WebMailへ

https://www.mubit.co.jp/pb-blog/wp-content/uploads/2019/06/roundcube-0.png

ビジネスチャットMattermostへ

　

 

 

SSO/SAML認証対応のアプリ

SAML認証対応の各種アプリとシングルサインオンでアクセスができます。

 

多要素認証

idP側の認証とは別に、「Powered BLUE Web for SSO / IDaaS」のSP上で単独で

  • SSLクライアント認証
  • ワンタイムパスワード認証

を設定して運用する事が出来ます

社内Webサイトへのアクセスに際して、IDaaS側の認証に加えて自社で運用出来るリバースプロキシに自社のポリシーに準じた認証を別途設定したい場合には有効です。

 

SSLクライアント認証

SP上でPrivate CAを運用　SSLクライアント証明書を発行してSSLクライアント認証によるアクセスコントロールが出来ます。

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

 

OTP/ワンタイムパスワード認証

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

 

SP/リバースプロキシの冗長構成

SP側のリバースプロキシを2重化して、シングルサインオン/SAML認証でのアクセスを分散させる冗長構成にも対応しています。

 

HA構成

ロードバランサーでの負荷分散

シングルAZ + ロードバランサーhttps://www.mubit.co.jp/sub/products/blue/img2/lb-sso-rev-3.png

 

マルチAZでの運用構成

GSLBやRoute53などを利用してのマルチAZでの運用に対応

異なるアベイラビリティゾーンでの運用により耐障害性の向上

  • リージョンA / 東日本データセンター
  • リージョンB / 西日本データセンター

https://www.mubit.co.jp/sub/products/blue/img2/lb-sso-rev-2.png

 

クラウドやWAN側に設置のWebの認証を強化

認証対応のリバースプロキシ経由でのみWebへアクセスする運用で、セキュリティを確保します

 

 

idPの費用を抑えたい場合

IdPの費用を抑えてSAML認証で運用したい場合には、Azure ADと同様の機能を持ち、idPの基本機能は無料で利用出来るGMOグローバルサイン社のIDaaSサービス「TrustLogin」を使うことも出来ます。

https://www.mubit.co.jp/sub/products/blue/img2/arrow-finger.gif TrustLoginを利用 / SAML対応のリバースプロキシで社内webへ安全にアクセス

 

 

終わりに

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

 

]]> 社内Webシステムのゼロトラスト対応 / ID認識型リバースプロキシでの構成方法 https://www.mubit.co.jp/pb-blog/?p=11454 Fri, 25 Sep 2020 08:50:21 +0000 https://www.mubit.co.jp/pb-blog/?p=11454 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管理 ( idP ) と ID認識型プロキシ ( IAP )

ユーザーやアクセス端末などの管理は、idP（identity Provider)で行います。

ゼロトラスト・モデルでは、ユーザー管理のidPとクライアントとターゲットのサーバーとの通信はD認識型プロキシ（ IAP : Identity Aware Proxy ）で中継します。

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

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

１）idP ： Identity Provider

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

( IAM : Identity and Access Management と呼ばれることもあります )

 

２）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サーバーへのアクセスに際して、簡単にゼロトラスト・セキュリティを導入するために

１） idP / 認証サーバーとして「SAML認証対応のidP」

２） 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 を利用します。

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/zero-trust-17.png

 

設定の手順

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 / 西日本データセンター

 

 

終わりに

ご不明な点などは、ムービットの https://www.mubit.co.jp/sub/products/blue/img2/arrow-finger.gif お問い合わせフォーム からお問い合わせください。

 

]]>