例　 Web / WordPress  / Roundcube / Mattermost などのWebページへのSSLアクセス認証

Private CA 機能の他に、SSLクライアント認証やリバースプロキシ－機能を持つPowered BLUE Private CA を利用します。サーバーの設定は全てGUIからの操作に対応しており、証明書の発行、失効なども簡単に自社管理での運用が出来ます。Let’s Encryptにも対応しており、WebサイトのSSLサーバー証明書の自動更新での運用も可能です。

Powered BLUE Private CA の 機能

• プライベート CA （プライベート認証局）
• SSLクライアント認証
• Mail / Web / DNS  サーバー
• Webサイト
• WordPress
• Mattermost / ビジネスチャット（拡張機能）
• Roundcube / Webmail
• Let’s Encrypt 対応
• リバースプロキシー

などを１台のPowered BLUE Private CAで同時に運用出来ます。

運用例

仮想サイト A.co.jp  で以下のWeb サービスを同時に運用。既存環境にも簡単に導入が出来るため、働き方改革によるリモートワークやテレワークの実現をサポート。

• Let’s Encrypt でサイトのSSLサーバー証明書を利用
• WordPressで一般向けWebを運用　(SSLクライアント認証なし）
• WordPressで社員用Webを複数運用　(SSLクライアント認証）
• Mattermost を運用　(SSLクライアント認証）
• Roundcube を運用　(SSLクライアント認証）
• リバースプロキシを運用　(SSLクライアント認証）

など

CA/リバースプロキシを分離での運用にも対応

• Public-CAやPrivate-CAを分離での運用例

別サーバーで運用のCAとの連携も出来ます

「Fujitsu Cloud Service for OSS (4OSS)」の特徴は

• OpenStack準拠
• Ansible/Horizonからコントロール可能
• 単一ゾーンでのSLA 99.99%
• アンチ・アフィニティをサポート
• オブジェクトストレージからのダウンロードにも費用がかからない
• 回線費用は無償（ベストエフォート）

などです。

FUJITSU Hybrid IT Service FJcloud-O上へのPowered BLUEのセットアップは以下も参照のこと

　「Fujitsu Cloud Service for OSS(4OSS)」上にCentOS 7のインスタンス構築設定

　「FUJITSU Hybrid IT Service FJcloud-O」上へのPowered BLUEのセットアップ

Powered BLUE Private CAの設定

サーバー起動後に、GUIでウイザードを実行します。GUIへのアクセスポートは　http 81 / 444 番です　firewallには TCP 81/444番 を通過させる設定が必要です

サーバーへのアクセス 例　http://54.65.17.7:444

管理サーバー名などを入力します

DNS などはEnterprise Cloudのデフォルトで設定されたものでも構いません。自社で独自に構築するのであれば、適宜指定します。

サーバーのIP/Gatewayなどは、変更せずにこのまま利用します。

adminのパスワードを入力します。

Languageに日本語を選択すると、GUIの表示は日本語となります。

Time-Zoneなどを適宜選択します。

ウイザードの終了後に、サーバーへ再ログインします。

管理サイト　サーバー名等を設定します。

NTPサーバーを指定します

プライベートCAの構築

プライベートCAを運用する仮想サイトを設定します

CA証明書の作成

• CA証明書の有効期限を設定
• CAのパスワードを設定

以上でCAの構築は終了

SSLクライアント証明書の発行

プライベートCAでSSLクライアント証明書を発行。クライアント証明書は、会社や部門全体での一括発行や、１ユーザーごとの個別の発行が出来ます。

SSLクライアント証明書を個別発行の場合（1枚発行の場合）

例　suzuki@mubit.com ユーザーのクライアント証明書を作成

有効期限などを指定して発行します

有効期間やポリシーを設定して、「部門や全社員の一括発行」なども対応しています。

SSLクライアント証明書をダウンロードします

ユーザーが個別に、発行されたSSLクライアント証明書をURL通知でダウンロードさせることも出来ます。

SSLクライアント証明書のブラウザへのインストール(IEの場合）

ツール　－　インターネットオプション　－　コンテンツ　－　証明書　を選択

個人のタグを選択

個人の証明書ストアへインポートします

SSLクライアント認証の設定

Private CAとWebサーバーを同一の仮想サイトで運用の場合

• 例　ca-test.mubit.jp　で運用の場合

SSLサーバー証明書の登録

• Webサーバーを運用するサイトへSSLのサーバー証明書を登録します
• 「自己署名デジタル証明書の作成」　または　「署名リクエストの作成」または Let’s Encrypt対応 で作成します。

自己署名デジタル証明書の作成の場合　(プライベートSSLサーバー証明書の場合）

• 「自己署名デジタル証明書の作成」から必要事項を記入して、SSLを有効にします
• 自己署名によるSSLのサーバー証明書が登録されます。

署名リクエスト / CSR で作成の場合 (パブリックSSLサーバー証明書の場合）

公的なSSLサーバー証明書を登録の場合には、ブラウザへの警告メッセージ

「このWebサイトで提示されたセキュリティ証明書は、信頼された証明機関から発行されたものではありません」

を抑制することが出来ます

SSLのサーバー証明書は

•  ドメイン認証証明書（DV:Domain Validation）
•  組織認証証明書（OV:Organization Validation）
•  EV証明書（EV:Extended Validation）

が登録出来ます

• 必要事項を記入して、　「署名リクエストの作成」　ボタンを押します

SSLサーバー証明書のインポート公的機関で発行された、サーバー証明書を　「インポート」　します

• 中間証明書のインポートにも対応しています
• Let’s Encrypt対応（Let’s EncryptのSSLサーバー証明書も組み 込めます
•  SNI対応　(IPアドレス1個で複数のWebサイトのSSL化）

SSLクライアント認証を有効

https://ca-test.mubit.jp へアクセス時のSSLサイトのクライアント認証を有効にします

Web Page 　https://ca-test.mubit.jp へのアクセス

SSLクライアント認証が有効の場合 / Web ページへアクセスが出来ます

グループウエアへのアクセス例
SSLクライアント証明書が有効の場合

SSLクライアント認証が無効の場合

Private CAとWebサーバーを異なるサイトで運用の場合

Webサービス用の仮想サイトを構築します

例　test-web.mubit.jp

test-web.mubi.jp サイトからPrivate-CA の運用サイト　http://ca-test.mubit,.jp 　とのcrl （失効リスト）の同期設定を行ないます

Webサーバーを運用するサイトには、SSLのサーバー証明書をインストールします

リバースプロキシ連携の場合

別サーバーで運用中のWebサーバーへのアクセス時にSSLクライアント認証

desknets / サイボウズ へのリバースプロキシの設定例

既存で運用中のWebサーバー（デスクネッツ/ サイボウズ）側の変更は不要です

既存のWebサービスとの連携

リバースプロキシによるSSLクライアント認証と既存のWebサービスとの連携の例 /多要素認証

• MosP勤怠管理/MosP人事管理/MosP給与計算
• NTTデータ イントラマートワークフロー
• エイトレッド X-point
• NIコラボスマート
• 楽々Workflow II
• eValue NS
• サイボウズ
• デスクネッツ
• Active! mail
• Powere egg
• RoundCube
• Aipo
• WaWaOffice
• Seagull Office
• OpenWebMail
• Zabbix
• Proself
• FileBlog
• Mattermost

リバースプロキシ設定&有効化

Private-CA を運用のサイトでリバースプロキシも運用します

プライベート認証局のこの仮想サイトにアクセスしたクライアントを、SSLクライアント認証後にリバースプロキシで指定したサーバーへリダイレクトさせます。

例　https://PrivateCAのサイト/demo/   －＞　http://www.zyx.co.jp/demo/

SSLクライアント認証でCA＆デスクネッツへのアクセス　-　承認された場合

有効なSSLクライアント証明書がインストールされたブラウザで、初回にアクセス時のブラウザでの表示例 （Ｆｉｒｅｆｏｘ）

https://ca-test.mubit.jp/dneo/dneo.cgi

SSLクライアント認証後のMosP勤怠管理のログイン画面

2要素認証 —  MosPの認証画面

MosPへログイン後の画面

SSLクライアント認証後のdesknet’s NEOのログイン画面

2要素認証 —  デスクネッツネオの認証画面

desknet’s NEOへログイン後の画面

SSLクライアント認証後のサイボウズのログイン画面

2要素認証 —  サイボウズの認証画面

サイボウズへログイン後の画面

SSLクライアント認証 / NTTデータイントラマートへのログイン

イントラマートへログイン後の画面

SSLクライアント認証 / X-pointのへのログイン

X-pointのへのログイン後の画面

SSLクライアント認証 / Active Mail のへのログイン

Active Mailへログイン後の画面

SSLクライアント認証 / 楽々ワークフローII へのログイン

楽々ワークフローII へのログイン後の画面

SSLクライアント認証 / eValue NSへのログイン

eValue NS へのログイン後の画面

SSLクライアント認証 / FileBlogへのログイン

FileBlog へのログイン後の画面

SSLクライアント認証 / roundcubeのへのログイン

roundcube へのログイン後の画面

SSLクライアント認証 / ownCloudへのログイン

ownCloud へのログイン後の画面

SSLクライアント認証 /MosP人事管理へのログイン

MosP人事管理 へのログイン後の画面

SSLクライアント認証 /MosP給与計算へのログイン

MosP給与計算へのログイン後の画面

Mattermostへのログイン

LB / ロードバランサ / SSLクライアント認証 / リバースプロキシ-連携

• SSLクライアント認証　&  ロードバランサー連携

• CAとSSLクライアント認証＆リバースプロキシを冗長化

Private CAとSSL VPNでのSSLクライアント認証連携

SSL-VPNでSSLクライアント認証後に指定のサーバーへアクセス
　SSL VPNでのSSLクライアント認証例

SSLクライアント認証を行なった上で、RDPなどでのアクセスが出来ます

SSLクライアント認証時のアクセスコントロール

有効なSSLクライアント証明書を有している場合でも、Webサイト毎に各種のアクセスコントロールが設定出来ます
失効リスト(CRL)に関わらず、ただちにWebへのアクセス禁止を設定できます
SSLクライアント証明書を失効させることなく、Webへのアクセスを禁止できます

• 利用するアプリでのアクセス制限
• 組織や部門でのアクセス制限
• 曜日や時間帯でのアクセス制限
• 特定ユーザーでのアクセス制限
• 端末を紛失したので、ただちにＡさんのSSLクライアント証明書でのアクセスを禁止

Powered BLUE Private CA へのフリープラグインなどのインストール

WordPressのインストール&セットアップ

Let’s Encryptのインストール＆セットアップ

 Rouncubeのインストールセットアップ

ownCloudのインストール＆セットアップ

php7 インストール＆セットアップ

ワンタイムパスワード認証＆SSLクライアント認証の併用

SSLクライアント認証とワンタイムパスワード認証の併用(多要素認証)及びリバースプロキシ機能までも1台のPowered BLUEサーバー上での運用も出来ます。 医療機関など、高度な安全性を求められる場面などに対応します 。

Powered BLUE ワンタイムパスワード認証アプライアンス

■アクセス手順
1）ワンタイムパスワードの表示
2）SSLクライアント認証後にWebサイトにアクセス
3）ID/パスワード/ワンタイムパスワード入力
4）ワンタイムパスワード認証の成功後　Webサイトの表示

*「OTP＋任意パスワード」認証にも対応

デモサーバー

Powered BLUEの　　デモサーバー

• 冗長構成のSSLクライアント認証＆リバースプロキシ( Reverse Proxy )
• クライアントから終端のWebサーバーまで、全経路での常時SSL通信

を行う場合の構成例です。

Client ⇒ ( 443 ) ⇒ LB  ⇒ ( 443 ) ⇒ SSLクライアント認証＆リバースプロキシ ⇒ ( 443 / 80 ) ⇒ Web

OpenStackのロードバランサー/ LBaaS v2 では、SSLのサービスを通過させるだけでオフロードをせずにリバースプロキシでSSLクライアント認証を行ないます。ロードバランサーにはSSLサーバー証明書の登録は必要ありません。

SSLクライアント認証後のリバースプロキシにより、最終のWebサーバーまで全経路にわたりSSL/TLSでの通信を行う構成です。リバースプロキシ先のWebサーバを外部から隠ぺいし安全性を高めることが出来ます。

１）SSLクライアント認証&リバースプロキシの冗長構成（Private CAは分離構成）

構築方針

１）SSLクライアント認証&リバースプロキシの冗長構成

• OpenStackのロードバランサー(LBaaS v2)でSSLをターミネートしない
• ロードバランサーを利用して負荷分散＆冗長構成の運用を行う
• ロードバランサーではTCP 443からTCP 443への転送
• クライアントからWebサーバーまでの全経路で常時SSL通信（https）を行う
• Private CA (認証局）は、OpenStack上で運用する
• SSLクライアント端末認証は、リバースプロキシ側で行う
• ロードバランサー（1台）とSSLクライアント認証&リバースプロキシ（2台）Webサーバー3台＆Private CA 1台 は同一ネットワークへ配置
• ロードバランサーには、SSLサーバー証明書の登録は不要
• 設定は全てWeb GUIから行なう

使用する機器

• FUJITSU Hybrid IT Service FJcloud-O（IaaS）
• FUJITSU Hybrid IT Service FJcloud-O　のロードバランサー ( LBaaS v2 ）
• Powered BLUE プライベート CA   1台 ( 認証局 / FUJITSU Hybrid IT Service FJcloud-Oで運用 )
• Powered BLUE リバースプロキシ　2台（ SSLクライアント認証 & Rev-Proxy / FUJITSU Hybrid IT Service FJcloud-Oで運用）
• Powered BLUE Web サーバー　3台（ Web / FUJITSU Hybrid IT Service FJcloud-Oで運用）
• SSLサーバー証明書

■プライベートCAとしては、

• Powered BLUE プライベートCA

を利用します。

公的な認証局 ( Public CA )も利用出来ます（例　グローバルサイン  ）

■SSLクライアント認証＆リバースプロキシとしては

• Powered BLUE リバースプロキシ

を利用します

■Web サーバーとしては

• Powered BLUE

を利用します

ネットワーク構成

• LAN 10.0.5.0 / 24
• ルーター / gw      　IP=10.0.5.1
• ロードバランサー   IP=10.0.5.2　 / IP=133.162.67.28  / LM-master-web.mubit.com
• B870-CA                 IP=10.0.5.20   / IP=133.162.67.42 /  B870-CA.mubit.com
• Rev1 / B870-REV1 IP=10.0.5.22  / IP=133.162.67.20 /  B870-REV1.mubit.com
• Rev2 / B870-REV2 IP=10.0.5.27  / IP=133.162.67.25 /  B870-REV2.mubit.com
• Web1 / B870-WEB1 IP=10.0.5.31  / IP=133.162.67.53 /  B870-LBC1.mubit.com
• Web2 / B870-WEB2 IP=10.0.5.32  / IP=133.162.67.54 /  B870-LBC2.mubit.com
• Web3 / B870-WEB3 IP=10.0.5.37  / IP=133.162.67.57 /  B870-LBC3.mubit.com
• 運用するゾーン  　 east-3 or west-3

設定&構築

今回はFUJITSU Hybrid IT Service FJcloud-OのGUIからの操作で構築します。尚OpenStack 標準のGUI / Horizonからの操作やAPI ,  Ansibleでの構築も可能です。

Networkの設定

OpenStack / FUJITSU Hybrid IT Service FJcloud-O　のネットワークなどの基本設定を行ないます。

• 4OSS/OpenStack上にNetworkなどを初期設定します

Private CAの設定

Private CAとしては、Powered BLUE Private CAを利用します

4OSS/OpenStack上にPowered BLUE Private CA サーバーをセットアップします。

• B870-CA  /  B870-CA.mubit.com  /  IP=10.0.5.20  / IP=133.162.67.42

SSLクライアント証明書の発行

プライベートCAでSSLクライアント証明書を発行。クライアント証明書は、会社や部門全体での一括発行や、１ユーザーごとの個別の発行が出来ます

SSLクライアント証明書を個別発行の場合（マニュアルで1枚発行の場合）

例　suzuki@mubit.com ユーザーのクライアント証明書を作成

有効期限などを指定して発行します

有効期間やポリシーを設定して、部門や全社員の一括発行も出来ます

SSLクライアント証明書をダウンロードします

ダウンロードURLを通知して、ユーザーが個別にダウンロードすることも出来ます

SSLクライアント証明書のブラウザへのインストール(Firefoxの場合）

「証明書を表示」をクリック

あなたの証明書」のインポートをクリック

SSLクライアント証明のパスワード入れてインストールします

正常にインポート時の表示

証明書マネージャーにインストールしたクライアント証明書が表示されます

プライベートCA設定のポイント

CRLを配布できるSSLクライアント認証＆リバースプロキシのIPを指定できます

例　SSLクライアント認証＆リバースプロキシ

• B870-REV1 IP=10.0.5.22
• B870-REV2 IP=10.0.5.27

Private CA へのIPのアサイン

• B870-CA  /  B870-CA.mubit.com  /  IP=10.0.5.20  / IP=133.162.67.42

リバースプロキシの設定

Powered BLUE サーバーは1台で

• SSLクライアント認証＆リバースプロキシサーバー

の機能を有しています。

2台のリバースプロキシサーバーに、

SSLサーバー証明書を入れます。またSSLクライアント認証の設定とリバースプロキシの設定を行ないます。

Powered BLUE サーバーは、ベースOSとして　CentOS 7.x / RedHat 7.x (64bit) で動作します。CentOS / RedHat 対応のアプリケーションをインストール＆運用することも出来ます。WordPress や Let’s Encrypt などは、フリープラグインにより簡単にPowered BLUE サーバーへインストール&利用が出来ます。

ポイント

• 2台のリバースプロキシサーバーに、同一のSSLサーバー証明書を入れます
• SSLサーバー証明書は、自己証明書やLet’s Encrypt、パブリックなサーバー証明書を登録出来ます

自己証明書の場合

同一のSSLのサーバー証明書を作成します（1台目のhttpsサーバー）

• 「自己署名デジタル証明書の作成」　または　「署名リクエストの作成」　で作成します

自己署名デジタル証明書の作成の場合

• 「自己署名デジタル証明書の作成」から必要事項を記入して、SSLを有効にします

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

• 署名リクエスト(CSR)で作成の場合
• 必要事項を記入して、「署名リクエストの作成」　ボタンを押します

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

公的機関で発行された、SSLサーバー証明書を「インポート」します

サーバー証明書＆秘密鍵のエクスポート（1台目のhttpsサーバー）

• 1台目のWebサーバーに登録されている、「サーバー証明書＆秘密鍵」が含まれているssl-certificate.txtを「エクスポート」

サーバー証明書＆秘密鍵のインポート（2台目以降のhttpsサーバー）

• 1台目のWebサーバーから取り出した「証明書＆秘密鍵」が含まれている「ssl-certificate.txt」を2台目以降のWebサーバーへインポート
• 1台目のサーバー証明書と秘密鍵のコピーが2台目にインストールされます

Let’s Encryptの場合

Let’s Encryptは、無償で利用できる公的なSSLサーバー証明書です。Powered BLUE 870 へはフリープラグインを利用して、1台目のWebサーバーへSSLサーバー証明書をインストールします。

　Let’s Encryptのインストール＆セットアップ方法

2台目のWebサーバーへのSSLサーバー証明書のインストールは、上記の「パブリックなSSLサーバー証明書を利用の場合」と同様の操作方法で、1台目から「SSLサーバー証明書と秘密鍵」をエクスポート&2台目へ「SSLサーバー証明書と秘密鍵」をインストールします。

SSLクライアント認証を設定

• 1台目、2台目ともWebアクセス時の 「SSLクライアント認証」 を有効にします

CAからCRL自動入手&更新の設定

• CAからCRL（失効リスト）を自動入手出来る設定をします
• 取得先CA 　ホスト名　( 例　B870-CA.mubit.com )
• 同期結果 「成功」 の場合には、CAからCRLが正常に入手できています
• 2台のリバースプロキシサーバーとも同様の設定を行ないます

アクセスコントロール

有効なSSLクライアント証明書を有している場合でも、Webサイト毎に各種のアクセスコントロールが設定出来ます
失効リスト(CRL)に関わらず、ただちにWebへのアクセス禁止を設定できます
SSLクライアント証明書を失効させることなく、Webへのアクセスを禁止できます

・組織や部門でのアクセス制限
・曜日や時間帯でのアクセス制限
・特定ユーザーでのアクセス制限
・端末を紛失したので、ただちにＡさんのSSLクライアント証明書でのアクセスを禁止

ログの出力先などの指定

SSLクライアント認証時のアクセスログの出力先を指定出来ます

リバースプロキシの設定

1台目、2台目ともリバースプロキシからWebへのリダイレクト先を設定します

設定例　（複数のリダイレクト先を指定できます　）

• WEB1            ⇒　https://10.0.5.31/WEB1/
• WEB2            ⇒　https://10.0.5.32/WEB2/
• WEB3            ⇒　https://10.0.5.37/WEB3/

• activemail   ⇒　https://10.0.5.31/activemail/
• proself        ⇒　https://10.0.5.31/proself/
• owncloud   ⇒　https://10.0.5.31/owncloud/
• cybozu        ⇒　http://10.0.5.32/cybozu/
• dneo           ⇒　http://10.0.5.32/dneo/
• mubit          ⇒　http://www.mubit.com/dir/

Webサーバーの設定

それぞれのWebサーバーへホームページやWebアプリケーションを入れます

B870-Web1 （ https Web サーバーNo1 )

B870-Web2 （ https Web サーバーNo2 )

B870-Web3 （ https Web サーバーNo3 )

リバースプロキシサーバーへのグローバルIPのアサイン

1台目 リバースプロキシ へのIPのアサイン

• B870-REV1 / B870-REV1.mubit.com　/ IP=10.0.5.22   /  IP=133.162.67.20

2台目 リバースプロキシ へのIPのアサイン

• B870-REV2 / B870-REV2.mubit.com　/ IP=10.0.5.27 / IP=133.162.67.25

ロードバランサー ( LBaas  v2) の作成

• ロードバランサ名の設定　（例　LB-master-1　IP=10.0.5.2 ）
• ロードバランサのプロトコル選択（例　プロトコル　TCP　/　ポート443　)
• 分散するサーバーの設定

負荷分散設定

分散プロトコルの設定

• リスナー名　例　lb-https
• プロトコル　HTTPS-HTTPS
• フロントエンドポート　443 (ロードバランサーの受信側ポート）
• 最大接続数　例　2000

負荷分散設定

• プール名　例　https-pool
• 分散アルゴリズム　例　ラウンドロビン
• セッション維持ポリシー　例　SOURCE_IP  (httpsの場合には、この選択のみ可能）
• バックエンドプロトコル　例　HTTPS
• バックエンドポート　例　443

分散先のターゲットWebサーバーの指定

• 1台目 Webサーバー B870-REV1 / 仮想Webサイト名　B870-REV1 ( IP=10.0.5.22 )
• 2台目 Webサーバー B870-REV2 / 仮想Webサイト名　B870-REV2 ( IP=10.0.5.27 )

ヘルスモニタの設定

• チェック方式　例　HTTPS

ヘルスモニターのチェック方式には、 「TCP」または「HTTPS」を指定する必要があります。

ロードバランサーへグローバルIPアドレスの設定

• ロードバランサー   IP=10.0.5.2　/  IP=133.162.67.28 /  LM-master-web.mubit.com

ロードバランサー　NUAGE:VIP IP=10.0.5.2 へグローバル IP=133.162.67.28 をアサインします

グーローバルIPのアサイン状況

• ロードバランサー   IP=10.0.5.2　/  IP=133.162.67.28 /  LM-master-web.mubit.com

• B870-CA                 IP=10.0.5.20   / IP=133.162.67.42 /  B870-CA.mubit.com

• Rev1 / B870-REV1 IP=10.0.5.22  / IP=133.162.67.20 /  B870-REV1.mubit.com
• Rev2 / B870-REV2 IP=10.0.5.27  / IP=133.162.67.25 /  B870-REV2.mubit.com

• Web1 / B870-WEB1 IP=10.0.5.31  / IP=133.162.67.53 /  B870-LBC1.mubit.com
• Web2 / B870-WEB2 IP=10.0.5.32  / IP=133.162.67.54 /  B870-LBC2.mubit.com
• Web3 / B870-WEB3 IP=10.0.5.37  / IP=133.162.67.57 /  B870-LBC3.mubit.com

ロードバランサーにグローバルIPをアサインしても、ロードバランサーの名称は空白のままです。

DNSへの登録

• IP=133.162.67.28 /  LM-master-web.mubit.com　（ロードバランサー名）

Webへのアクセスは、ロードバランサー名のＡレコードで行います

Webサーバー側の設定

1台目　B870-REV1.mubit.com　の設定

ロードバランサーにアサインのサーバーのＡレコード名　LM-master-web.mubit.comでアクセス出来るように 1台目の B870-REV1.mubit.com に

• ウェブサーバーの別名 LM-master-web.mubit.com を指定
•  URLのリライトを無効設定( URLが書き換わらないようにします ）

2台目  B870-REV2.mubit.com　の設定

ロードバランサーにアサインのサーバーのＡレコード名　LM-master-web.mubit.comでアクセス出来るように 2台目の B870-LBC2.mubit.com に

• ウェブサーバーの別名 LM-master-web.mubit.com を指定
•  URLのリライトを無効設定( URLが書き換わらないようにします ）

Ａレコードでのアクセス

https://LM-master-web.mubit.com/web1/

1台目 B870-LBC1 へ　 SSLクライアント認証が通るとWeb　pageが表示されます（URLは書き換わっていません ）

https://LM-master-web.mubit.com/web2/

2台目 B870-LBC2 へ　 SSLクライアント認証が通るとWeb　pageが表示されます（URLは書き換わっていません ）

https://LM-master-web.mubit.com/web3/

3台目 B870-LBC3 へ　 SSLクライアント認証が通るとWeb　pageが表示されます（URLは書き換わっていません ）

SSLクライアント認証例　（承認されない場合）

有効なSSLクライアント証明書が無いクライアントからのアクセスの場合 ( IPhone )

Google Chrome の場合

デモサーバー

Powered BLUEの　　デモサーバー

クラウド基盤を利用することで、導入時の費用や導入までの期間を短縮することが可能です。また既存のオンプレ側のネットワーク環境の変更も不要です。

オンプレの環境へ各種の認証対応（ワンタイムパスワード認証・AD認証・SSLクライアント認証・SAML認証）のリバースプロキシ経由でアクセスさせる場合の構成です。

【１】リバースプロキシ構成

リバースプロキシ経由で、オンプレのWebへアクセスさせる構成

【２】冗長構成

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

【３】オンプレ環境とクラウド環境の組み合わせ

シングルAZ構成

ロードバランサーなどはクラウド環境側のリソースを利用する構成

マルチAZ構成

データセンターを複数利用する場合には、GSLBでの冗長構成も出来ます

異なるアベイラビリティゾーン（AZ)を利用して認証対応のリバースプロキシにより耐障害性の向上

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

【４】認証に対応のリバースプロキシ

各種の認証機能に対応のリバースプロキシとしては、「Powered BLUE Reversse Prox  アプライアンス」　を利用します。

対応の認証方式

【１】リバースプロキシ & OTP/ワンタイムパスワード認証
【２】リバースプロキシ & SSLクライアント認証
【３】リバースプロキシ & ワンタイムパスワード認証 ＋ SSLクライアント認証
【４】リバースプロキシ & AD認証 ( Active Directory連携 )
【５】リバースプロキシ & AD認証 + LDAP 認証
【６】リバースプロキシ & AD認証 +  SSLクライアント認証
【７】リバースプロキシ & LDAP認証
【８】リバースプロキシ & SSLクライアント認証＋LDAP認証
【９】リバースプロキシ & SAML認証（ ゼロトラスト対応 ）

【５】対応の運用先環境

仮想アプライアンスのイメージでの提供・仮想環境へインポートするだけですぐに運用できます

• 仮想環境 ( VMware / Hyper-V )

• クラウド環境（ AWS / Azure / VPS 他）

終わりに

詳しい話を聞いてみたい方などは、ムービットの  お問い合わせフォーム からご連絡ください。

ID認識型Web/SSO対応

Webサーバーとしては、ゼロトラストに対応の「ID認識型Webサーバー機能」を有する「Powered BLUE Web for SSO / IDaaS 」が利用出来ます。

IdaaSなど任意の「idP」と連携して、簡単にゼロトラスト・セキュリティに対応のWebサイトを構築してシングルサインオンで自社運用ができます。

対応のidP

Azure AD / G Suite / TrustLogin / OneLogin / Okta / CloudGate Uno / HENNGE ONE  / Keycloak / OpenAM など

設定の手順　idP側の設定

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

ID認識型Webサイト側の設定

Webページを作成して、idPとの認証を設定します

• Webサイトの認証を設定したいディレクトリのSAML認証を有効

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

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

対応環境

「Powered BLUE Web for SSO / IDaaS 」の運用先

• 仮想環境 ( VMware / Hyper-V )

＊仮想アプライアンスのイメージでの提供・仮想環境へインポートするだけですぐに運用できます

• クラウド環境（ AWS / Azure / VPS 他）

冗長構成

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

自動同期機能を利用しての冗長運用

• シングルAZでのSP/Webの運用
• Webコンテンツやサイト設定の同期など

マルチAZ構成
複数のアベイラビリティ・ゾーンでのSP/Webの運用

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

終わりに

ご不明な点などは、ムービットの  お問い合わせフォーム からお問い合わせください

• Active Directory認証
• OTP認証
• SSLクライアント認証
• SAML認証 ( ゼロトラスト対応 / シングルサインオン ）
• Basic認証
• Digest認証

などが利用できます。複数の認証を組み合わせて多要素認証での運用や冗長構成（HA)での運用にも対応しています。

用意および設定する機器

認証対応のWebサーバとしては、「Powered BLUE Web  アプライアンス」　を利用します。

Webサーバーの運用先

• 仮想環境 ( VMware / Hyper-V / Nutanix )

＊仮想アプライアンスのイメージでの提供・仮想環境へインポートするだけですぐに運用できます

• クラウド環境（ AWS / Azure / VPS 他）

【１】AD認証のWeb構成

対応の認証方式

• Active Directroy認証

＊クライアントからリダイレクト先のWebやADまでの全経路での暗号化通信に対応

ADサーバーの構築

Windows Serever 上にADサーバーを構築＆設定します

AD認証設定

Webサーバー側でActive Directoryの認証方式を選択します

• LDAP認証
• Kerberos認証

認証のステップ（AD認証）

１）Webへアクセス・アカウントやパスワードを入力
２）AD認証
３）ADの認証後にWebページを表示

＊任意のWeb dirにAD認証を設定できます

【2】AD認証＋SSLクライアント認証

対応の認証方式

• Active Directroyとのkerberos認証
• SSLクライアント認証

Webサーバー側でのSSLクライアント認証 設定

• Private-CA 機能によりSSLクライアント証明書を発行します
• Public-CAで発行のSSLクライアント証明書でSSLクライアント認証を行います

認証のステップ（SSLクライアント認証＋AD認証）
１）Webへアクセス（SSLクライアント認証）
２）アカウントやパスワードを入力
３）AD認証
４）ADの認証後にWebページを表示

【3】ワンタイムパスワード認証のWeb構成

対応の認証方式

• OTP認証
• QRコード対応
• 「OTP＋任意のパスワード」の組み合わせに対応
•  TOTP / HOTP  対応

対応のソフトウエアトークン

Google Authenticatorなどの無償のソフトウエア・トークン＆QRコードに対応

• Google Authenticator　　設定例
• WinAuth　　設定例
• Authy　　設定例
• IIJ SmartKey　　設定例
• Microsoft Authenticator　　設定例
• 他

認証のステップ（ワンタイムパスワード認証）

1）ワンタイムパスワードの表示
2）Webサイトにアクセス　ID/パスワード/ワンタイムパスワード入力
3）2要素認証の成功後　Webサイトの表示

【4】SSLクライアント認証のWeb構成

SSLクライアント認証の有効化

• Webサーバー側のSSLクライアント認証を有効にします
• *Private-CA 機能により、SSLクライアント証明書を発行します

SSLクライアント認証のアクセスコントロール

• 時間帯や曜日によるアクセス制限
• 部門によるアクセス制限

例　月曜日から金曜日　9時から18時　までの時間帯のみWebアクセス許可

認証のステップ（SSLクライアント認証）

１）SSLクライアント認証
２）認証後にWebを表示

【5】ワンタイムパスワード認証＋SSLクライアント認証のWeb構成

ワンタイムパスワードの設定

SSLクライアント認証の有効化

• Webサーバー側のSSLクライアント認証を有効にします

• 時間帯や曜日によるアクセスコントロール
• 例　月曜日から金曜日　9時から18時　まで時間帯のみのアクセス許可

認証のステップ（SSLクライアント認証＋ワンタイムパスワード認証）

1）ワンタイムパスワードの表示
2）SSLクライアント認証後にWebサイトにアクセス
3）ID/パスワード/ワンタイムパスワード入力
4）ワンタイムパスワード認証の成功後　Webサイトの表示

【6】SAML認証のWeb構成/ゼロトラスト対応

対応の認証方式

• SAML認証

idPの設定

Azure AD / TrustLogin / OneLogin / Okta / CloudGate Uno / HENNGE ONE / G Suite / Keycloak / OpenAM 他 を利用します

• idPへアカウントを作成します
• SAML認証を有効にします

Webサーバー側でSAML認証の有効化

• Webサーバー側でSAML認証を有効にします
• Webサーバー側にユーザーアカウントは不要です

認証のステップ（SAML認証）

1）idPへアクセス ( シングルサインオン / 初回のみ ）
2）idPの認証後にWebサイトにアクセス

【７】SAML認証+自社独自SSLクライアント認証のWeb構成

idPの認証とは別に、Webサーバー側に自社独自にSSLクライアント認証を設定する運用

idPのポリシーとは別に、自社独自のアクセス設定ができるのでセキュアな運用が可能です

対応の認証方式

• SAML認証
• SSLクライアント認証

idP側の設定

Azure AD / TrustLogin / OneLogin / Okta / CloudGate Uno / HENNGE ONE / G Suite / Keycloak / OpenAM 他 を利用します

• idPへアカウントを作成します
• SAML認証を有効にします

Webサーバー側　SAML認証の有効化

• Webサーバー側でSAML認証を有効にします
• Webサーバー側にユーザーアカウントは不要です

SSLクライアント認証

idP側の認証とは別にWebページへのアクセス認証に、Webアクセスに際してSP上で自社独自にSSLクライアント認証を設定します

認証のステップ（自社独自のSSLクライアント認証＋SAML認証）

１）SSLクライアント認証
２)   idPへアクセス ( シングルサインオン / 初回のみ ）
３）idPの認証後にWebサイトにアクセス

【8】SAML認証+自社独自ワンタイムパスワード認証のWeb構成

idPの認証とは別に、Webサーバー側に自社独自にワンタイムパスワード認証を設定する運用

idPのポリシーとは別に、自社独自のアクセス設定ができるのでセキュアな運用が可能です

対応の認証方式

• SAML認証
• ワンタイムパスワード認証

idP側の設定

Azure AD / TrustLogin / OneLogin / Okta / CloudGate Uno / HENNGE ONE / G Suite / Keycloak / OpenAM 他 を利用します

• idPへアカウントを作成します
• SAML認証を有効にします

Webサーバー側　SAML認証の有効化

• Webサーバー側でSAML認証を有効にします
• Webサーバー側にユーザーアカウントは不要です

Webサーバー側　ワンタイムパスワード認証

idP側の認証とは別にWebページへのアクセス認証に、Webアクセスに際してSP上で自社独自にワンタイムパスワード認証を設定します

認証のステップ（自社独自のSSLクライアント認証＋SAML認証）

１）OTP表示
２)   Webへアクセス ( ワンタイムパスワード認証 ）
３）idPのSAML認証後にWebサイトの表示（シングルサインオン / 初回のみ）

【９】冗長構成

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

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

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

デモサーバー

ワンタイムパスワード認証やSAML認証をはじめ、各種の認証に対応のWebやリバースプロキシの動作や操作の確認が出来ます。

　デモサーバー

終わりに

詳しい話を聞いてみたい方などは、ムービットの  お問い合わせフォーム からご連絡ください。

◉ AD認証に対応のリバースプロキシ

Active Directroy認証に対応の　「Powered BLUE Reverse Proxy for AD」アプライアンスを利用します。AD認証とSSLクライアント認証を併用しての多要素認証での運用もできます。

機能

• リバースプロキシ機能
• リバースプロキシのAD認証
• リバースプロキシのSSLクライアント認証
• リバースプロキシのHA対応
• ポータルサイト機能

運用構成

• LAN側に設置のWebへのアクセス

運用先

「Powered BLUE Reverse Proxy for AD」の運用先

• 仮想環境 ( VMware / Hyper-V / Nutanix )

＊仮想アプライアンスのイメージでの提供・仮想環境へインポートするだけですぐに運用できます

• クラウド環境（ AWS / Azure / VPS 他）

Active Directroy サーバー

Windows Serever 上にADサーバーを構築＆設定します

Powered BLUE アプライアンス

VMware / Hyper-V 環境の場合、Powered BLUE Reverse Proxy for AD アプライアンスのサーバーイメージを仮想環境にインポート＆認証方式やリバースプロキシのリダイレクト先を指定します。

対応の認証方式

Active Directroyとの

• AD認証
• Kerberos認証
• LDAP認証

など

利用する認証を選択

Active DirectoryとLDAP認証で連携の場合

リバースプロキシの設定

リバースプロキシのリダイレクト先を指定します（複数のリバース先を設定できます）

認証のステップ

１）リバースプロキシへアクセス
２）アカウントやパスワードを入力（ADとLDAP認証）
３）認証後にリバース先のWebを表示

ポータルサイト機能

リバースプロキシの機能に加えて、ポータルサイトの機能も有しています。

1. ポータルサイトにアクセス後に指定のバックエンドへのリダイレクト
2. 複数の異なるリダイレクト先の設定

などの運用が出来ます。

 プロキシID

バックエンドのWebサーバー側へプロキシIDを渡すことが出来ます

• リバースプロキシのプロキシIDをhttpヘッダーに追加
• バックエンド側では、連携のリバースプロキシを限定できます

◉ 多要素認証での運用にも対応

 SSLクライアント認証 +  ADとLDAP認証

ADとのLDAP認証連携に加えてPrivate-CA機能やSSLクラアント認証機能も有しており、リバースプロキシへアクセス時の多要素認証での運用にも対応

• リバースプロキシの認証 = SSLクライアント認証 +  ADとLDAP認証

SSLクライアント認証の有効化

SSLクライアント認証でのアクセス制限

• 時間帯や曜日によるアクセスコントロール
• 例　月曜日から金曜日　9時から18時　までの時間帯のみのアクセス許可

認証のステップ（SSLクライアント認証＋ADとLDAP認証）

１）SSLクライアント認証
２）リバースプロキシへアクセス
３）アカウントやパスワードを入力（ADとLDAP認証）
４）認証後にリバース先のWebを表示

SSLクライアント証明書の無い場合

HTTPヘッダーへのCNなどの情報追加

SSLクライアント認証時に証明書の各種情報をHTTPヘッダーに追加して、バックエンドのWebへ送信。バックエンドのWeb側ではユーザー認証に利用が可能です。

CN　      例　ichiro-ohtani@xyz.com
　部門名    例　Sales
　会社名    例　XYZ Co. Ltd.

emailAddress=ichiro-ohtani@xyz.com,CN=ichiro-ohtani@xyz.com,OU=Powered
BLUE Client (1),OU=Sales,O=XYZ Co. Ltd.,L=Kita-ku,ST=Tokyo,C=JP

◉ 冗長運用

リバースプロキシのHA機能により、ロードバランサーでの負荷分散やマルチAZでの運用に対応（Active-Activeでの運用に対応）

ロードバラアンサー配下での運用構成

クラウド環境と自社環境のミックス構成

ロードバランサーなどはクラウド環境側のリソースを利用する構成

マルチAZでの運用構成
異なるアベイラビリティゾーン(マルチAZ)での運用により耐障害性の向上

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

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

WAN側に設置のWebサーバーへのアクセスについても、認証対応のリバースプロキシ経由でアクセスさせることができます。既存Webの「認証が弱い」もしくは「認証がない」場合にも、認証対応のリバースプロキシ経由でのアクセスに限定することにより、セキュアなWebアクセスができます。

◉ VPNとリバースプロキシの比較

VPNの場合

アクセス集中により、VPN速度の低下などが発生

一度VPN経由でネットワーク内に入った場合には、各種のサーバやシステムとアクセスが可能なためにセキュリティ上の懸念があります。

リバースプロキシの場合

リバースプロキシはWebアクセスなのでVPNのような高い負荷はかかりません。利用者はブラウザのみでストレスなくWebアクセスが可能です。VPNのようなネットワーク全体へのアクセスではないため、指定のサーバーのみにアクセスを許可させるセキュアな運用ができます。またAzure AD アプリケーション プロキシのような面倒な設定は不要です

ターゲットサーバーの隠蔽

ユーザーから見えるのはリバースプロキシまでです。リバース先のターゲットのサーバー・ドメイン名を隠蔽します。

• リバースプロキシ　  https://rev-proxy.xxx.com/
• ターゲット              https://target.yyy.co.jp/zzz
• リダイレクト設定　  https://rev-proxy.xxx.com/　－－＞ https://target.yyy.co.jp/zzz
• ユーザーブラウザへの表示　https://rev-proxy.xxx.com/zzz

デモ

Powered BLUE   　デモサーバー

終わりに

詳しい話を聞いてみたい方などは、ムービットの  お問い合わせフォーム からご連絡ください。

既存で運用のバックエンドのWebサイト側の変更は不要です。HA対応のワンタイムパスワード認証機能付きリバースプロキシを設置するだけの簡単導入に対応しています。リバースプロキシの運用先もAWSやクラウド、仮想環境など任意の場所で運用が可能です。

リバースプロキシ/Reverse Proxy

一般的なリバースプロキシは

今回は、HA＆ワンタイムパスワード認証対応の

を構築＆運用します

ワンタイムパスワード認証機能付のリバースプロキシ

今回利用する

「Powered BLUE 870/OTP-Rev」は、リバースプロキシへのアクセス時に

• ワンタイムパスワード認証
• ID/パスワード認証
• リバースプロキシによるリダイレクト
• Active-ActiveのHA（Master-Slave)での動作に対応

までを構築＆運用出来るアプライアンスです。

ソフトウエアトークン対応

ワンタイムパスワードの生成では、OSSや無償で利用できるソフトウエアトークンに対応しており、導入時の利用者側の負担を抑えることができます。

ソフトウエアトークンの設定

ユーザーが利用するPCやモバイル端末で利用できる無償のソフトウエアトークンの設定例

Google Authenticator のインストール & セットアップ方法
WinAuth のインストール & セットアップ方法
Authy のインストール & セットアップ方法
IIJ SmartKey のインストール & セットアップ方法

クラウドや仮想対応

AWS/Azureなどのクラウド環境や、VMware/Hyper-vなどの仮想環境での運用にも対応しています。仮想環境へ仮想アプライアンスのイメージをインポートするだけで、すぐに自社管理のワンタイムパスワード認証機能付きのリバースプロキシの運用が可能です。

ワンタイムパスワード/OTPの設定、発行、ユーザー管理やリバースプロキシの構築や認証設定、サーバーの運用やメンテナンスまでをGUIの操作から簡単に行なえます。

AWSでの構築

　Powered BLUE のAWSでの構築＆設定例

ワンタイムパスワード認証の設定（1台目：マスター）

Webアクセス時のワンタイム・パスワード認証を設定します

任意のディレクトリにワンタイムパスワード認証が設定可能です

• 仮想サイト & 認証のディレクトリ（例 トップdir /  にワンタイムパスワード認証設定の場合 ）

ユーザー認証設定（1台目：マスター）

ユーザーへワンタイムパスワード認証を許可します

例　鈴木　二郎 へワンタイムパスワード認証を有効に設定

秘密鍵の共有フロー

QRコード（共有鍵）の表示

• ソフトウエア・トークンを起動して、QRコード（2次元バーコード）をスマフォで読み撮り登録します
• QRコード読み撮りのカメラの無いPCなどもコードの設定で登録が出来ます
• QRコードは、ユーザー毎に異なります

リバースプロキシの設定画面（1台目：マスター）

ワンタイムパスワード認証＆リバースプロキシ

https://xxx.yyy.com/ 　 —-> https://www.powered.blue/

冗長構成

「Powered BLUE 870/OTP」はマスター＆スレーブの冗長構成での運用に対応しています。

HAでは1台目のマスター側の設定情報を2台目以降のスレーブ側と同期します。

HA運用に際して

管理者は、マスター側のサーバーのリバースプロキシやSSLサーバー証明書、およびユーザーアカウントをメンテするだけでスレーブ側は自動で同期するため、冗長構成時の運用でも管理者の負担を増やしません。

ロードバランサー配下での運用やGSLB、Route53との組み合わせによるマルチAZでの運用にも対応しています。

ロードバランサー配下での運用

シングルAZ + ロードバランサー

マルチAZでの運用

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

認証ステップ

１）ワンタイムパスワードを表示させる
２）リバースプロキシにアカウントやワンタイムパスワードを入力
３）ワンタイムパスワード認証後にリバースプロキシ先のWebが表示

リバースプロキシ先のWebアプリなど

SharePointへ

Roundcubeへ（Webmail)

RocketChatへ

サイボウズへ

デスクネッツへ

WordPressへ

デモサイト

Powered BLUE のデモサイトを用意しています

ワンタイムパスワード認証対応のリバースプロキシなどの動作を確認することが出来ます

　Powered BLUE 870 のデモサイト

終わりに

ワンタイムパスワードやSSLクライアント認証でＷebサイトの認証を強化したい方、既存で運用のWebへのアクセスに認証機能を導入したい方。デモ環境で試してみたい方や詳しい話を聞いてみたい方などは、ムービットの  お問い合わせフォーム からご連絡ください。

ワンタイムパスワード認証のWebサーバーの負荷分散を行いたい、2重化で運用したい場合などでも、簡単に構築運用が出来ます

ワンタイムパスワード認証機能付属のWebサーバー

ワンタイムパスワード認証機能を持つWebサーバー   「Powered BLUE 870/OTP」を使います。このアプライアンスサーバーは、自社専用のワンタイムパスワード認証機能付属のWebサーバーを自社で簡単に構築＆運用することが出来ます。

ビジネスポータルのWebサイトにワンタイムパスワード認証を設定する。また特定のディレクトリ以下にワンタイムパスワード認証を設定するなどの多彩な運用形態が取れます。リバースプロキシ機能も有しており、既存で運用のWebサイトへの認証連携にも対応しています。

運用先

アプライアンスで提供されるので、運用先の環境ですぐに利用が出来ます

• AWSやVPSなどのクラウド環境
• VMware ESXiやHyper-Vなどの仮想環境

AWSにも対応

　Powered BLUE のAWSでの構築＆設定例

対応のトークンなど

ユーザー側では、Google Authenticatorのフォーマットに対応の無償のソフトウエア・トークンを利用できます

• Google Authenticator
• Authy
• IIJ SmartKey
• WinAuth
• 他

ユーザーは、ソフトウエアトークンで自身のQRコードを映すだけで簡単にOTP認証に対応のWebサイトの登録が出来ます

仮想サイトを作成(１台目：マスター）

例　test-opt.mubit.com

Webページ(１台目：マスター）

作成した仮想サイトには、デフォルトでindex.htmlが自動作成されています。このindex.htmlファルを適宜変更して、Webページを作成できます。

デフォルトのindex.html

ワンタイムパスワード認証の設定(１台目：マスター）

Webアクセス時のワンタイム・パスワード認証を設定します

任意のディレクトリにワンタイムパスワード認証が設定可能です

• 仮想サイト & 認証のディレクトリ（例 トップdir /  にワンタイムパスワード認証設定の場合 ）

ユーザー認証設定(１台目：マスター）

ユーザーへワンタイムパスワード認証を許可します

例　鈴木　二郎 へワンタイムパスワード認証を有効に設定

冗長構成(２台目：スレーブ）

「Powered BLUE 870/OTP」はマスター＆スレーブの冗長構成での運用に対応しています。

同期するデータは、仮想サイト毎に

• Webサイトの情報（静的なWebページデータやWebスクリプト属性)
• WebサイトのSSLサーバー証明書
• 設定情報

など自動で同期します

HA運用に際して

管理者は、マスター側のサーバーの設定を行うだけです。スレーブ側は自動で同期するため、冗長構成時の運用でも管理者の負担を増やしません。

ロードバランサー配下での運用やGSLB、Route53との組み合わせによるマルチAZでの運用にも対応しています

ロードバランサー配下での運用

マルチAZ構成での運用

Webサイトへのアクセス手順

1）ワンタイムパスワードの表示
2）Webサイトにアクセス　ID/パスワード/ワンタイムパスワード入力
3）2要素認証の成功後　ターゲットのWebサイトの表示

デモサイト

デモサイトではWebサイトアクセス時のワンタイムパスワード認証などの操作や設定などの確認が出来ます

　Powered BLUE 870 のデモサイト

終わりに

ワンタイムパスワードやSSLクライアント認証でＷebサイトの認証を強化したい方、既存で運用のWebへのアクセスに認証機能を導入したい方。デモ環境で試してみたい方や詳しい話を聞いてみたい方などは、ムービットの  お問い合わせフォーム からご連絡ください

インターネット側に、認証機能に対応のリバースプロキシを設置して「認証後」に社内のWebへリダイレクトさせることが出来ます。社内Web側の認証機能が「弱い」もしくは「認証がない」場合でも、運用ができます。

例　社内に設置のSharepoint へのアクセス

例　社内のWebMailへのアクセス

リバースプロキシの特徴

• ブラウザで利用可能
• モバイル端末用の閉域網やVPNは不要
• ターゲットWebの改修不要
• リバースプロキシ先のWebサーバーを外部から隠蔽

今回は、認証機能に対応のリバースプロキシとして「Powered BLUE リバースプロキシ 」アプライアンスを利用します。

リバースプロキシでの認証方法

認証方式としては

• • • ワンタイムパスワード認証 (OTP認証）
    • SSLクライアント認証 (証明書認証）
    • AD認証
    • SAML / OIDC認証 (シングルサインオン）
    • FIDO2 / WebAuthn（生体認証）

など

複数の認証を組み合わせての運用や、ユーザーやリバースプロキシ先のタ―ゲットのWebサイトに応じて認証方式を変更しての運用も可能です。

各種のリバースプロキシの認証方式の特徴・比較

Powered BLUE リバースプロキシの特徴

各種の認証に機能に対応のリバースプロキシとして、Powered BLUE リバースプロキシを利用します。

• アプライアンス（仮想 / クラウド / ハードウエアに対応）
• 任意の場所での運用
• 自社管理での運用
• 電源オンですぐに運用
• ひとり情シスでの運用

リバースプロキシの設定例

・複数のリバース先を設定可能
・リバース先のポート( http / https / 任意のポート番号）を指定可能
・終端までSSL通信での運用が可能 （End-to-EndのSSL通信）

【１】 OTP/ワンタイムパスワード 認証付属 リバースプロキシ

google authenticatorなどの無償のソフトウエア・トークン対応

QRコード / 2次元バーコード対応

ワンタイムパスワードのユーザー管理・認証とリバースプロキシを1台で運用

対応のモデルは　 Powered BLUE 870 / OTP & Reverse Proxy

【２】SSLクライアント 認証付属 リバースプロキシ

Private CA機能を有しており、SSLクライアント証明書の発行・管理・認証とリバースプロキシまでを1台で運用

対応のモデルは　 Powered BLUE Private CA & Reverse Proxy

【３】 ワンタイムパスワード認証+SSLクライアント認証付属 リバースプロキシ (多要素認証）

Private CA機能をとSSLクライアント証明書の発行・管理・認証およびワンタイムパスワード認証とリバースプロキシまでを1台で運用

認証の併用やそれぞれの単独認証などユーザーやリバース先などで、利用の認証を変えることが可能

対応のモデルは　　 Powered BLUE Web Station

【４】 AD認証付属 リバースプロキシ

社内のADと連携出来ます。AD認証に対応のリバースプロキシとして動作

Kerberos認証やLDAP認証に対応

対応のモデルは　 Powered BLUE Reverse Proxy for AD

【5】 SSLクライアント認証＋AD認証付属 リバースプロキシ

社内のADと連携出来ます。「SSLクライアント認証とAD認証」に対応の多要素認証のリバースプロキシとして動作

対応のモデルは　 Powered BLUE Reverse Proxy for AD

【6】 SAML/OIDC認証対応 リバースプロキシ

既存のID / パスワード認証のWebを改修することなくシングルサインオンを構成します。

iDaaS/idpと連携して、SAML/OIDC認証に対応のID認識型リバースプロキシとして動作します。

リバースプロキシからWebへのID/パスワードの代理入力機能により、シングルサインオンでの運用に対応（ターゲットWeb側の改修は不要で構成できます）

iDaaS/idp としては、SAML やOIDC認証 に対応の Azure AD / G Suites / TrustLogin / OneLogin / Okta / CloudGate Uno / HENNGE ONE /  Keycloak 他 と連携出来ます

代理認証

リバースプロキシからWebへ「ID / パスワード」を代理入力＆代理認証

• ユーザー操作でのWebへの「ID / パスワード」の入力不要
• SAML / OIDC認証に未対応のWebをSSOのメンバーとして構成

対応のモデルは　 Powered BLUE Reverse Proxy for SSO / IDaaS

【7】 SAML/OIDC 認証付属 リバースプロキシ＋SSLクライアント認証

iDaaS/idPのSAML/OIDC認証とは別に、自社管理で運用するリバースプロキシ上でSSLクライアント認証やワンタイムパスワード認証の設定にも対応

リバースプロキシからWebへのID/パスワードの代理入力機能により、シングルサインオンでの運用に対応

社内Webへのアクセスに際して、IDaaSとは異なる自社のポリシーに準じた独自の認証を設定して運用する場合には有効です

ID認識型リバースプロキシ＋SSLクライアント認証

代理認証

リバースプロキシからWebへ「ID / パスワード」を代理入力＆代理認証

• ユーザー操作でのWebへの「ID / パスワード」の入力不要
• SAML / OIDC認証に未対応のWebをSSOのメンバーとして構成

対応のモデルは　 Powered BLUE Reverse Proxy for SSO / IDaaS

【8】 FIDO2/生体認証対応リバースプロキシ

スマートフォンやタブレット、PCなどのFIDO2 / 生体認証機能に対応のリバースプロキシとして、パスワードレス認証で運用できます。

リバースプロキシからWebへのID/パスワードの代理入力機能により、シングルサインオンでの運用に対応

代理認証

リバースプロキシからWebへ「ID / パスワード」を代理入力＆代理認証

• ユーザー操作でのWebへの「ID / パスワード」の入力不要
• SAML / OIDC認証に未対応のWebをSSOのメンバーとして構成

対応のモデルは　 Powered BLUE Reverse Proxy for SSO / IDaaS

【冗長化】

ロードバランサー配下での運用構成

シングルAZ + ロードバランサー

マルチAZでの運用構成

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

マルチAZ + GSLB

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

WAN側Webへの認証強化

WAN側設置のWebへアクセスを「認証対応のリバースプロキシ経由に限定」

認証機能のない社内Webサーバーをクラウドの公開基盤側に移設して運用する場合にも、セキュリティレベルを確保できます

デモサイト

Powered BLUE のデモサイトを用意しています

各種操作や認証設定、リバースプロキシなどの動作を確認することが出来ます

デモサイト

製品についての、ご質問やご相談など

Webサーバーの認証機能としては、認証なし、OTP/ワンタイムパスワード認証、SSLクライアント認証、SSO/シングルサインオン/SAML認証や各種認証の組み合わせによる2要素認証・多要素認証などに対応。

セキュリティの要件や用途に合わせて、Webアクセス時に各種の認証機能を組み合わせて自社管理での運用が出来ます。

Webサーバーとしては、各種の認証機能に対応のWebアプライアンス　「Powered BLUE 」を利用します。

製品の特徴としては

• OTP/ワンタイムパスワード認証
• SSLクライアント認証
• SSO/SMAL2.0認証
• インターネットサーバー機能（Mail / Web / DNS )
• WordPressに対応
• Let’s Encrypt に対応
• ひとり情シスでの運用に対応

などの機能を有したWebアプライアンスです。

製品の形態

仮想アプライアンスに加え、ハードウエア・アプライアンスにも対応しています。

仮想対応

VMware ESXi やHyper-Vに対応の仮想アプライアンスのイメージで提供。仮想アプライアンスのイメージを仮想基盤にインポートするだけですぐに運用が出来ます。

クラウド対応

AWSやAzure、ALTUS ( アルタス ) / GMOクラウド、WebARENA / NTTPC コミュニケーションズ、FUJITSU Cloud Service for OSS ( 富士通 ）、Enterprise Cloud ( NTT communications )、VPS他

AWSでの構築

　Powered BLUE のAWSでの構築＆設定例

Powered BLUE の各種認証

Powered BLUE のWebサーバーは、以下の6つのパターンでの認証＆運用に対応しています。各種の認証機能付きのWebサーバーを自社管理で運用出来ます

各種の認証製品は　…..

続きを読む