HENNGE社のIDaaS

1. IDaaSとは

1.1 概要

IDaaS（Identity as a Service）は、SaaSやIaaSと同じように、ID管理をサービスとして提供します。
具体的には、ユーザ認証機能を持ち、また、SaaSサービスとのSAMLによる連携機能を持ち、シングルサインオンを実現します。

1.2 なぜIDaaSが必要か

これまで、多くの企業ではActive Directoryなどを使ってID管理をしてきました。
場合によってはSSOも実現してきたことでしょう。

Q.なぜ、IDaaSが必要なのでしょうか。

A.理由は単純で、Microsoft365などのクラウドサービスの利用が拡大する中、オンプレの認証システムでは、クラウドを含めた認証ができない。
なおかつ、利用するクラウドサービスってすごい数ですよね。日本だと1企業で50～60、アメリカでは100くらい使っているという話も聞きます。そうなると、パスワード管理が複雑になり、セキュリティの観点からSSOが求められます。
加えて、誰でもアクセスできるのではなく、端末の制御として、会社から許可された端末からだけ接続されるようにしたい、そんなニーズもあります。それを実現するのがIDaaSです。

Q.AD FSを利用して、クラウドの認証基盤と連携すればいいのではないか？

オンプレのサーバのメンテナンスが必要で、管理が必要。どこに配置するか問題もあり、社内の端末からの通信であればいいが、社外のPCからの通信の場合、FWにて外部からAD FSへの通信を許可する必要がある。AD FS Proxyをどう配置するかもあって、まあまあ大変であり、セキュリティの懸念もある。AzureADを使った方が便利ですよね。通信もクラウド上で完結しないので、あまり望ましい構成とはいえないかもしれません。
ちなみに、AD FSの仕組みは以下です。SAMLのシーケンスは複雑なので、単純化して流れを書いています。

役割としては、AD FSがIDP、ADが認証サーバ、クラウドサービスがSPとしてSAMLが動作します。ユーザ情報（＋PW）はAD側が持ちますが、ユーザアカウントはSP側でも作成する必要があります。AD FSはIdPとしてフェデレーションをしているだけなので、ADとSPのユーザ情報の同期をするわけではありません。AD FSは、ADに認証を問い合わせ、SP側にチケットを返します。

1.3 クラウドの認証基盤であるIDaaSを使うメリット

❶SSOそのもののメリット
・システム管理者にとって、システムごとユーザ管理やアクセス制御などを行う必要がなく、一元的にセキュリティ対策が行える
・利用者にとって、一つのIDとパスワードだけ覚えればいいので、運用が楽

❷構築、運用が楽
　物理的なサーバを建て、物理的なファシリティーを安定的に確保し、冗長化して信頼性、セキュリティを保って運用するのはけっこう大変です。

❸セキュリティリスクの低減
　オンプレで構築するActive Directoryには、重大な脆弱性が日々報告されています。リアルタイムにパッチを当てたりするのは大変。また、そもそも、Active Directoryは攻撃に弱いので、オンプレミスのActive Directoryは廃止するべき、という考え方もある。
その考えで廃止してAzureAD（EntraID）に移行した事例は以下

・SOMPO HDがオンプレミスのADを停止、ランサムウエア攻撃への耐性を高める
https://xtech.nikkei.com/atcl/nxt/column/18/00001/07735/

❹利用者認証の強化
　パスワードによる認証しか対応していないサービスであっても、多要素認証などの認証を追加で強化できる。

❺クラウドの認証をするにはオンプレだと難しい
クラウドの認証の基盤をオンプレで作るのは、そもそも難しい。実現するにはADFSなどの仕組みが必要。

1.4 他社サービスとの比較

❶EntraID（旧AzureAD）との比較

Q.EntraIDなら無料で利用できるのではないの？

A.以下がEntraIDの料金プランで、無料で利用できるものもあります。ですが、企業向けになると有料プランを選択することになります。また、条件付きアクセスをするには有料プランのみです。
https://www.microsoft.com/ja-jp/security/business/microsoft-entra-pricing

プラン	Free	P1	P2	Entra Suite
料金	無料	899円/ユーザ・月	1349円/ユーザ・月	1799円/ユーザ・月
機能		条件付きアクセスなど		ゼロトラの機能（Microsoft Entra Internet Access など）
その他		Microsoft 365 E3、Microsoft 365 Business Premium に含まれる	Microsoft 365 E5 に含まれる

・HENNGEのIDPを利用する場合、Basicプラン（300円/ユーザ・月）、Pro（500円/ユーザ・月）であり、価格が安い。ただし、他のオプションなどを利用すると、さらに料金が高くなる（BASIC 800円、Pro1000円など）
・操作性は非常に高いと思われる。
・対応しているSPの数に違いはあるか。→特に違いはないだろう。
・条件付きアクセスに関しては、EntraIDの方が優れていると思われる。具体的には、IPアドレスや証明書以外に、OSの種類なども条件に加えることができる。HENNGEの場合、M365のように外部と資産管理ソフトの連携して、条件付きアクセスを強化することもできない。
https://zenn.dev/takuyaot/books/45d4f4494a63ce/viewer/b4511a
・HENNGEの場合、Intuneと連携した端末の制御ができない。あくまでも認証機能のみ。
・条件付きアクセスでは、EntraIDの場合、Intuneが必要。しかし、たとえばIOSの場合、MDMのプロファイルが1つしか入れられなく、キャリアのMDM制御などをしていると、入れられない。HENNGEの場合、デバイス証明書で端末を制限できるので、MDMのアプリを入れる必要はない。証明書もコピーできない。導入は楽な気がする。

❷OKta
IDaaSの機能に関しては、Oktaが充実していると思う。
一方、HENNGEの利点は、
・シンプルでわかりやすい（機能が少ないともいえる）
・コストが安い
・メールセキュリティなどの機能も充実している
・マニュアルなどが準備されている　など

2 HENNGE ONE

2.1概要

HENNGE社のIDaaSサービスは、HENNGE ONEの「Identity Edition」です。
https://hennge.com/jp/service/one/identity/
上記サイトより以下の画像を引用

機能としては、たとえば以下の機能を持ちます。
・シングルサインオン
・アクセス制御
・Active Directory連携
・ID管理機能API
・アクセスログ

2.2 HENNGE Oneが連携する外部サービス

・ここに記載されています。かなりたくさんあります。
Q.EntraIDと比較して連携できるSPは多い？
A.SAMLという標準プロトコルなので、基本的にはどのSPも連携できるはず。だが、実際にはうまくいかないものもある。HENNGEの場合、連携実績のあるSPとのマニュアルを準備している。これが結構便利。

2.3 ユーザの管理について

(1)ユーザ情報の管理

・IDaaS側でユーザとパスワードを持つ
・SP側でもユーザ情報は持つが、パスワード情報は持たないのが原則。ただし、SP側でPWを持つことはできる（PWは2重管理）。その際、SP側でIDP連携を必須（つまり、SPローカルのPWを使わない）にすることができる場合もある。たとえば、Saleforceの場合、以下のように、「Saleforceログイン情報を使用したログインを無効化」のチェックを入れる。

・IDaaSのユーザは、SPに同期できる（SPによってはできないものもある）。パスワードの同期はされない。例として、Saleforceで同期をする場合、以下のSMAL設定における「ユーザープロビジョニングの有効化」を有効化する。

・IDaaS側でユーザのグループは管理できない。SP側でグループや属性を管理する必要がある。
・UPNは、SP側で利用するID。ユーザー名はあくまでもHENNGEの管理用のアカウント。UPNとユーザ名を同じにしてもいい（その方がわかりやすいかも）

(2)ユーザ情報の同期

Q.HENNGE で作成したユーザ情報って同期されるの？

A.MS系は同期をすることがほぼ必須であるが、MS以外のSPの場合は、同期しないことが多い。つまり、SP側でもユーザを登録する必要がある。
とはいえ、Salesforceなど、一部のSPでは同期が可能で、その場合の方法は以下がある。
1)同期を無効　→　ユーザー情報の同期をしない（=SP側では手動でユーザを追加する）
2)同期を有効
　2)-1　JITPを有効　→　ユーザ情報がログインした時点でユーザ情報を同期する。ただし、JITPに対応しているSPというのが大前提で、かつHENNGEとの連携実績がある場合。
　2)-2　HENNGE の連携モジュールを使い、裏ではSCIM連携やその他の仕組みでユーザ同期を図る方法もある。（これもSPによって、できるできないがある）
　2)-3　オンプレADを起点にして連携

・JITP（ジャストインタイムプロビジョニングニング）
　HENNGE Access Control（通常の画面？★）にユーザ登録すると、リアルタイムではなく、ユーザがクラウドサービスにアクセスしたタイミングでユーザが登録される。
https://hennge.com/jp/service/one/identity/account/

・以下はSP（Salesforce）の設定ですが、一番下に「ジャストインタイムのユーザプロビジョニング」の設定があり、ここにチェックを入れると有効化する。

2.4 ログインの流れ

(1)2つのログイン方法

(2)各サービスにログインする場合

・ユーザがログインするには、SPのURLにアクセスすると、IDPにリダイレクトされる。そこでIDとPASSを入れる。
（例）ZOOMの場合、以下のSSOをクリック

会社のドメインを入力する

（例）HENNGEとSalesforceの場合
・（SAMLのシーケンスは複雑なので簡略化していますが、）接続の流れは以下です。

・利用者の画面は、以下のようになります。

2.5 システム構成

(1)HENNGEを使った基本構成

・ローカルのアプリケーションは、ローカルのADサーバ等で認証をする。
・クラウドのアプリケーションに関しては、HENNGEのIDaaSを使ってSSOで認証をする。
・HENNGEでは、ユーザ情報としてユーザー名があり、SPに接続するためのアカウントとして、user1@hng.west.comのようなUserPrincipalName (UPN)で管理する。SPが複数あり、たとえばSP1、SP2とあって、どちらも同じユーザ名を使いたい場合、どちらもuser1や、場合によってはuser1@hng.west.comなどの名前でログインさせる。※@以降が付与されるかはSP側次第。

(2)ローカルADサーバとの連携

多くの企業はローカルのADサーバが統合認証基盤ですが、HENNGEを使った場合、そのADサーバとの連携をどうするのでしょうか。
・基本的には、ローカルの認証とクラウドの認証は、別物と考えた方がいいでしょう。なので、連携せずに、別々に運用する。つまりユーザアカウントの管理も別々（2重管理）
・だから、HENNGEを使って、ローカルのADを撤廃することはできない。
・ユーザ情報の一元化を目的として、連携は可能。連携のためにHENNGE Directory Sync Toolというエージェントのインストールが必要↓。
https://support.hdeone.com/hc/ja/articles/360020013993-HENNGE-Directory-Sync-Tool-%E3%81%AE%E5%AE%9F%E8%A1%8C
・システム構成として、まずはsync toolを構築する。オンプレADの中に入れてもいいが、機能が違うし、障害時の切り分けの観点で分けておいた方がいい。EntraConnectを入れる場合は、同居してもいいかも。
・通信の流れは、オンプレAD　→sync tool→HENNGE

たとえば、ADにユーザが登録されると、定期的に（既定では2 時間に1 回）sync toolに情報が送られ、それをHENNGEに送る。sync toolはユーザ情報を持たない。あくまでも転送するためのツール。もちろん、ADがsync toolに転送するための設定が必要。具体的には、DLLをADにインストールし、Powershellでバッチファイルを動かす（Powershellは必ずしもAD上で動かす必要はない）
・同期する情報は、ID/PW、メールアドレス、表示名、姓名、UPNなど。
・HENNGE 社の資料より、連携のマッピング例

(3)EntraID（AzureAD）との連携

後述します。

3.実際の設定

3.1 ログイン

(1)管理者のログイン

・以下、ログイン画面です。管理者は、ユーザー名とパスワードを入れてログインします。

・メニュー画面は以下です。

(2)一般ユーザのログイン

・一般ユーザがHENNGEにログインすることは可能。
・ログイン画面は同じ。
・SSOの方法として、SPに接続する方法と、こちらのHENNGEの管理画面に入って、利用したいサービスを選択することもできる。

ここで表示されるサービスは、管理者側で設定する。

・右上のユーザのボタンを押してできることは、自分のパスワード変更、ワンタイムパスワードの設定、デバイス証明書の失効処理などができる。

3.2 ユーザー管理

ユーザーの管理として、ユーザを追加、変更、削除をします。

(1)ユーザの管理について

・たとえば、サービスAのユーザIDとサービスBのユーザIDも、どちらもuser3を使いたい場合、どちらも同じくuser3を設定する。
・ユーザー名とUPNのどちらも必須であるが、UPNは、SP側で利用するID。ユーザー名はあくまでもHENNGEの管理用のアカウント。UPNとユーザ名を同じにしてもいい（その方がわかりやすいかも）
・仮に、サービスAのIDがUPN、サービスBのIDが社員番号であった場合、HENNGEの機能（カスタム属性）で社員番号という項目を新たに設定する必要がある。

ユーザ名	user3
UPN	user3@hng.west-sec.com
社員番号	1234567

(2)ユーザの追加

・ユーザー > ユーザー一覧、上の「＋追加」を押す。

手順は、ここに記載があります。
・ユーザ情報を設定する。

以下、最後のところで、どのSPで利用するかのチェックを入れる。

3.3 認証強化

認証を強化することができる。もちろん多要素認証も可能

(1)認証の強化

以下の制御ができる

内容	説明
グローバルIP	送信元のグローバルIPで制限する
デバイス証明書	PCやスマホなどのデバイスにデバイス証明書を入れ、証明書が正しければ接続可能
入場証	Cookie情報を使う（※正直、あまりよくわからない）
セキュアブラウザ	HENNGEが提供しているブラウザ「HENNGE Secure Browser」の利用有無
プッシュ通知アプリ	プッシュ通知アプリをつかってワンタイムパスワードを発行

(2)ワンタイムパスワード設定

・管理画面の右上から、設定
・アプリで発行されたワンタイムパスワード

(3)IPアドレス制限

アクセス設定 > アクセスポリシーグループ > 新規アクセスポリシーグループ にて
アクセスを許可する条件にIPアドレスを記載する。
書き方は、例えば以下
ip4:1.1.1.1
ip4:1.1.1.1/25

(3)デバイス証明書

・管理画面から証明書を発行し、ＰＣに入れる
・1人（1PC）ずつに発行してもいいが、大変なので一括登録もできる。
・PWなしで証明書だけでログインもできる。
・証明書の編集で、ログインタブを「個人」→「パスワードレス」に変更すると、パスワードが不要になると思う。（要確認）
・アクセスポリシーグループで、証明書が必要とかを選択できて、それをユーザに1人ずつ適用する。
・認証の流れは以下。

・証明書が無いと、以下のようにエラーになる。

・デバイス認証をするには、アクセスポリシーグループで、以下の設定を入れる。
device_cert:any

参考までに、他の設定は以下

設定	内容
device_cert:none	HENNGE Device Certificateを使わずにアクセスした場合は "許可" と判断
device_cert:any	HENNGE Device Certificate (個人、共有、パスワードレスのいずれか) を使用してアクセスした場合は "許可" と判断
device_cert:personal	個人タイプの HENNGE Device Certificate を使用してアクセスした場合は "許可" と判断
device_cert:shared	共有タイプの HENNGE Device Certificate を使用してアクセスした場合は "許可" と判断
device_cert:passwordless	パスワードレスタイプの HENNGE Device Certificate を使用してアクセスした場合は "許可" と判断

・利用者への証明書のインストール方法は以下。
a)まず、ユーザを作る必要がある
b)デバイス証明書 > 証明書一覧　から右上の「＋証明書の登録」

c)利用者の情報を登録する。具体的には、ユーザ名、MACアドレス、メールアドレスなど入れる。証明書はこのMACアドレスに紐づけられるようだ。

d)「１枚の証明書を登録する」を押す。

e)入力したメールアドレスに登録方法の案内が送られる

f)手順に従い、以下をインストールする。
CybertrustDeviceiDImporter.msi
g)Cybertrust DeviceiD Importerを起動し、メールに記載された証明書識別子を入れる。

h)セキュリティ警告が出るが、「はい」を押してインストール

g)参考だが、以下のように「個人」のところに証明書が格納される。

(4)条件付きアクセス

端末制御として、従業員に貸与しているPCやスマホからしかログインできないようにさせたい。EntraIDの場合、Intuneを使って、OSの種類などの制御が可能。
一方、HENNGEの場合、↑で説明したデバイス証明書で端末を制限する。これが条件付きアクセスの役割となる。EntraIDと違い、MDMのアプリを入れる必要はない。証明書もコピーできない。導入は楽な気がする。

(5)アクセスポリシーの適用

アクセスポリシーグループを作成し、それをユーザに割り当てる。
❶アクセス設定 > アクセスポリシーグループ　にて、右上の「＋追加」から新規作成
以下は、ワンタイムパスワードの設定にて、「OTPを要求しない条件」として「常にOTPを要求する」を選んだ画面

❷ユーザー一覧でユーザを選択し、アクセスポリシー > アクセスポリシーグループにて、作成したアクセスポリシーグループを選択して適用する。

3.4 ログ管理

ログを見るには、メニュー画面の「ログ管理」から行う。

取得できるログは、以下である。

ログの種類	内容
アクセスログ	ユーザ名ごとのログインの成否、時刻、送信元IPアドレス、SSO TARGETを取得する
ユーザー操作ログ
管理者操作ログ	管理者ユーザごとに、ユーザを作成（Create User）やアクセスポリシーグループの作成（createAccessPolicyGroup）などのログを取得
同期ログ	Microsoft EntraIDなどとの同期の結果のログ
一括登録ログ
セキュアブラウザ認証履歴
デバイス証明書操作履歴

4.SAML連携

4.1 全体像

SPに対して、HENNGEがIdPおよび認証サーバとなって、SSOを実現します。
設定の流れは以下です。
❶IdPであるHENNGE側の設定
・ユーザ登録（HENNGE側にsalesforceのユーザ情報の登録。まあ、CSVで一括が多いだろう）
・IdPのメタデータの発行
・証明書の発行

　↓↓↓↓

❷SP側（今回はSalesforce）の設定
・IdPのメタデータのインポート
・IdPの証明書のインポート
・SPのメタデータの発行
（・ユーザを登録する。MS系以外は、基本的にはユーザ同期はされないので。このとき、SP側にパスワードは不要ですが、パスワードなしでユーザー登録はおそらくできないので、登録することになるでしょう。SSO設定後でも直接ログインが可能なSPについては、ユーザーがSP側のパスワード情報を使って直接ログインすることがないように、ユーザーがわからないランダムパスワードに管理者が変更してしまうこともあります。）

　↓↓↓↓

❸IdPであるHENNGE側の設定
・SPのメタデータのインポート

　↓↓↓↓

❹設定完了
利用者がSPへアクセスすると、HENNGEに対して認証後、サービスを利用できる

4.2【参考】 SAMLのシーケンス

ここで、情報処理安全確保支援士の過去問（平成29年春午後1問3）をもとに、SAMLのシーケンスを紹介します。HENNGEの場合、IDPと認証サーバが一体化しています。

4.3【参考】SPの環境構築

Salesforceのテスト環境は以下で構築できる。
https://qiita.com/mokonacl/items/74c2d70b479139ef6763

(1)環境構築

a)以下のサイトに接続して、サインアップ
https://developer.salesforce.com/signup
ユーザ名をsfuser@west-sec.comとした。
b)しばらくすると、登録したメールアドレスにメールが届く　※少し時間がかかる
c)リンクをクリックして、「Reset Password」を押す。
d)パスワードを設定する。

e)管理画面にログインできる。

f)次回以降は、以下のログインURLからログイン
https://apple-bc-dev-ed.develop.my.salesforce.com/

(2)ユーザの作成

ユーザー > ユーザー　から作成する

※赤字のところを設定していく。
・ユーザ名：ログインするユーザ名で、メールアドレス形式にする必要がある。
・メール：これが連絡先のメールになり、パスワード設定やリセットもこのメールアドレス宛に送られるので、正しく設定する必要がある。
・ロール：あまり関係ないと思う。たとえば、Western Sales Teamにした
・ユーザーライセンス：テストでは、Force.com-Freeなどでいい。権限によってログイン後にできる機能が異なると思う

(3)作成したユーザでログイン

管理者と同じログインURLからログイン
https://apple-bc-dev-ed.develop.my.salesforce.com/
こんな感じでログインできます。

4.4 SPの設定

SPの設定は、システム > サービスプロバイダ設定 から行う
a) 右上の「＋サービスプロバイダの追加」を押す。
「サービスを手動で追加」を押して、以下の画面を設定する。

b) IdPのメタデータが出力される

c)続いて、Salesforce側で設定を行う
・ ID > シングルサインオン設定 を開き、「SAMLに有効化」にチェックをいれる。そして、その下の「新規」からSAMLの設定を行う。　

・HENNGE側で出力されたメタデータを順番に入力していく

・しかし、手作業は面倒で、間違いも起こりやすい。↑のHENNGEの画面にあるIdPメタデータをダウンロードして、以下のSP（Salesforce）の画面の「メタデータファイルから新規作成」でインポートするのが楽。

d)「会社の設定」＞「私のドメイン」＞「認証の設定」＞「編集」を押す。
先ほど作成したHENNGE　ACにチェックを入れ保存する。
この時点でSalesforceの認証がHENNGEに委任される。

e)SAMLのメタデータをダウウンロードする。

f)HENNGE One側で、サービスプロバイダ設定を開き、Salesforceを選択して先ほどダウンロードしたメタデータをインポートする。

メタデータのインポートが完了すると「ACS URL」と「SP issure」が入力される。
g)サービスプロバイダ設定において、Salesforceの設定を確認すると「有効」に変わる。

4.5 プロビジョニングの設定

・HENNGEとSP（今回はSalesforce）にて、ユーザ情報の同期をする場合に設定をする。
・具体的には、HENNGEでユーザを追加したとしても、SPにユーザがなければ、そのユーザはSPにログインができない。そこで、HENNGEのユーザをSPに同期する必要がある。
・画面は以下のシステム > プロビジョニング設定 から、「＋サービスの追加」を押す

・Salesforceにはプロビジョニング設定ができるようになっている。詳しい手順はマニュアルに記載されています。

・同期に関しては、以下のように、同期ボタンから手動で同期させることが可能。※定期同期は現在は対応していない。

5.Microsoft製品との連携

5.1 全体像

・Microsoftとの連携は他のクラウドサービスとは違う。HENNGEのとSPの間にEntraIDが入り、EntraIDとはWeb Services Federation（WS-Fed）というSAMLとは異なるプロトコルで連携する。※WS-Fedの設定は特に必要無。

・上の図において、認証情報の流れを整理します。

	構成	通信の流れ	備考
1	M365などのMS製品だけを使う場合（HENNGEを使わない）	①→③→⑥
2	M365などのMS製品だけを使う場合（HENNGEを使う）	①→③ ②→④→⑤→⑥	・EntraIDに対しては、EntraID Connectでユーザ情報を同期する ・⑤のフェデレーションでは、HENNGEで保持しているパスワードを使う ・この構成のメリットは、EntraIDのライセンスが、条件付きアクセスができるエンタープライズ版を使わずに無料版でできて、価格が安くなる
3	MS製品以外を使う場合（HENNGEを使う）	②→④→⑦

5.2 M365などのMS製品だけを使う場合（HENNGEを使う）

(1)概要

・M365のサービスを使う場合、EntraIDは必須になる。なので、HENNGEとEntraIDで認証連携をする。
・M365からすると、IdPはEntraIDになり、HENNGEが認証サーバ役割になる。
・M365のサービスを使うということは、EntraIDにユーザ登録をすることになる。ユーザは、HENNGEで作ってEntraIDに同期することができる。
※EntraIDからHENNGEに同期することも可能だが、双方向で同期させると2重管理になったり、データの不一致が起こるので、推奨ではない。導入時に1回だけ、EntraIDからユーザを取得することくらいであろう。その手順はマニュアルを参照ください。
・HENNGEからEntraIDへの連携は、先のマニュアルを実施すると、以下の画面の状態になる。

(2)EntraIDとHENNGEでの2つ連携シーン

連携のシーンは以下の2つがあると思う。
1)HENNGEでユーザを登録したとき　→HENNGEからEntraIDにユーザ情報の同期が行われる
2)ユーザがSPであるM365にアクセスがあったとき　→WS-Federationで認証が行われる。

(3)WS-Federation

・接続の流れは、ざっくり書くと以下であるが、SAMLのシーケンスは複雑なので、厳密なシーケンスではない。

・以下のように、MSにサインインするときに、HENNGEにリダイレクトして、PWの認証やアクセス制御はHENNGEで行うことができる。