アプリケーションのクラウドやリモートワーク化に伴い、セキュリティも従来の境界型からゼロトラスト化へ移行してきています。
ゼロトラストでは、ID、デバイス、アプリケーションに対して、セキュリティのチェックをすることが原則になりますが、まず、ゼロトラストを進めるにあたっては、ID管理が肝となります。
OktaやAzureADを始めとするIAM（Identity and Access Management ）やIDaaS（Identity as a Service）など、キーワードはよく聞きますが、クラウド上でどのようにID認証・管理をしていかないといけないのか、イメージがわきにくいかと思います。
この記事では、Webアプリケーションにおいて、従来のID認証・管理からIDaaS環境へどのように変遷していったのか、正確性は求めず、仕組みをイメージしてもらう目的でまとめます。
初期のID認証
初期のWebアプリケーションでは、ユーザ情報やパスワードは、Webアプリケーション単位で、データベースに保管されています。
認証フロー
ユーザ がWebアプリへアクセスします。
Webアプリは、認証フォーム画面を表示します。
ユーザはクレデンシャル情報（ユーザIDとパスワード）をWebアプリへ提示します。
WebアプリがID情報を格納しているDBに対して、クレデンシャルの問い合わせをします。
Webアプリが認証結果をユーザへ通知します。
課題①：ID管理がシステム個別
まず大きな問題点は、ユーザDB（ユーザIDとパスワード）がシステム（Webアプリ）単位で管理されていることです。
Webアプリが複数ある場合に、問題が顕著となります。
ユーザは、システム毎にユーザ名やパスワードを覚えないといけません。シングルサインオンもできません。また、あるユーザの追加、削除もシステム毎に実施しないといけません。
課題②：クレデンシャルの扱い
クレデンシャルの扱いです。ユーザは、クレデンシャル情報（ユーザIDとパスワード）をシステム（Webアプリ）へ提示しています。これはセキュリティ上、好ましくありません。Webアプリ側でなんらか仕掛けることで、クレデンシャル情報を搾取される可能性もあります。
課題③：認証処理
クレデンシャル情報を受け取ったWebアプリは、自ら認証処理を行っています（認証画面を表示したり、ユーザDBへ問い合わせたり）。これも改善したいポイントです。Webアプリはサービスを提供することであって、認証処理は、Webアプリとは切り離して、実施されることが望ましいです。
共通ID認証
各システムで管理していたユーザDBを共通の認証サーバで一元管理させ、システム側は、共通の認証サーバへクレデンシャルを確認します。
共通に認証サーバとして、オンプレのエンタープライス環境では、LDAPサーバやActive Directoryなどがよく使用されます。オンプレ環境では、現在でもよく見かける構成です。
システム個別にIDを管理する必要はなくなりましたが、まだ、課題は残っています。
課題①：パスワード入力
基本的に、ユーザは、Webアプリに対して、都度、Webアプリ単位に同じユーザ名とパスワードを入力する必要があります。シングルサインオンの環境ではありません。
課題②：クレデンシャルの扱い
クレデンシャルの扱いは、初期のID認証と変わらず、Webアプリへ送られます。
課題③：認証処理
初期のID認証と変わらず、Webアプリが認証処理をします。
環境の変化（Webアプリがクラウドへ）
共通ID認証は、Webアプリがオンプレ環境にある場合によく見かける構成です。
ただし、Webアプリがどんどんクラウドへ移行されてきています。
その場合、Webアプリはオンプレにある認証サーバ（LDAPやActiveDirectory）へ認証要求をしないといけません。これは、セキュリティ的にNGです。
共通ID認証の構成は、Webアプリと認証サーバが同じセキュリティレベルに存在している必要があります。
Webアプリと認証サーバ間で直接やりとりするのがNGです。これを回避するために考えられたのが、委託認証（Delegated authentication）です。
委託認証（Delegated authentication）
委託認証は、サービスを提供する側（Webアプリ）が、認証サーバへ問い合わせするのではなく、利用者経由で、認証サーバへ認証処理を任せる方式です。
委託認証のイメージ
お父さん、お母さん、子どもの3者がいたとします。子どもがお菓子を買ってほしいとお父さんにお願いしますが、お菓子を買ってよいかどうかの決定権はお母さんに委託します。
お父さんがWebアプリ、お母さんが認証サーバの役目です。
共通ID認証の方式だと、下記のようになります。この場合、お菓子を買ってあげるかどうかは、お父さんが決定権を持っています。お母さんは買ってよいかの確認だけです。
委託認証の場合は、お父さんがお母さんに聞きにいきません。お菓子を買ってよいかどうかは、子どもからお母さんに聞きにいかせます。
お父さんはお母さんが許可したかどうかだけを聞きます。お父さんはお母さんの判断内容に従います。
SAML（Security Assertion Markup Language）
委託認証でよく使用されるのがSAML（Security Assertion Markup Language）認証です。
SAMLでは、サービスを提供するアプリ側をSP（Service Provider）、ユーザIDを保持し、認証を行う側をIdP（Identity Provider）と呼びます。（上の例では、お父さんがSP、お母さんがIdPです。）
Webアプリ側をSPとし、LDAPやActiveDirectoryのユーザIDを用いて認証を行うためのIdPを別途配置します。ActiveDirectory環境で、一番よく使用されるIdPはADFS（Active Directory Federation Services）です。下記フローは、まず、ユーザがSP（Webアプリ）への接続から開始するSP Initiatedの場合です。
まず、ユーザ がWebアプリへアクセスします。
SP（Webアプリ側）はユーザ認証をIdPで行うよう、リクエストをリダイレクトします。
ユーザ がIdPへ接続します。すると、IdPが認証画面を表示します。
ユーザはクレデンシャル情報（ユーザIDとパスワード）をIdPへ提示します。
IdPがLDAPやActive Diretoryなどと連携し、ユーザID、パスワードの認証を行い、認証結果をSPへ送るよう、リダイレクトします。
ユーザはSP（Webアプリ側）へ、IdPからもらった認証結果を伝えます。これで、SP（Webアプリ側）はサービス提供を開始します。
この認証フローを見ると、SPとIdP間で直接やり取りはしていません。必ず、ブラウザなどのユーザを介して、認証情報をやりとりされます。
認証処理は、IdPで実施します。そのため、クレデンシャル情報はSP（Webアプリ側）へ送信されません。
SP（Webアプリ側）は、IdPで認証した結果だけを取得します。
環境の変化（ユーザがインターネットへ）
リモートワークの普及などにより、ユーザは、インターネットからオンプレ環境を経由せず、直接、クラウド上のWebアプリ（SaaS）へ接続されてきます。
今までの構成のまま、ユーザをインターネットへ移動した場合に、認証はインターネットからオンプレのIdPへリクエストすることになります。
これは、インターネットからオンプレへの接続となり、セキュリティ的には、基本好ましくありません。（ActiveDirectory環境の場合、DMZへADFSプロキシであるWAP（Web Application Proxy）を配置、経由させることで、インターネット環境からオンプレのADFSへ認証させることができます。）
そのため、IdPの機能自体もクラウドへ移行する必要があります。これが、IDaaS（Identity as a Service）というもので、有名なものに、OktaやAzure Active Directoryなどがあります。
IdP機能はクラウドへ移行されましたが、ユーザID自体は、人事システムなどのID情報をオンプレのLDAPやADなどに連携し、管理されていることが一般的です。
この場合は、オンプレのLDAPやADのユーザID情報をIDaaSに対して、同期させます。
Active Directoryでいえば、AzureADに対しては、Azure AD Connect というツール経由で同期します。また、Oktaですと、Okta Agentというエージェントソフトで同期します。
IDaaSによって、同期できる認証ソースや同期手順は異なります。
シングルサインオン（SSO）
IdPとSPは異なる組織のため、予め信用情報を交換することで、IdPが認証OKとなれば、それをSPで信頼する必要があります。下記サイトも参考にしてください。
【SAML】シングルサインオン（SSO）の動作概要
複数のSaaSアプリを利用する場合、SaaSアプリ単位にID、パスワードを管理する運用は非常に困難です。ユーザにとっては、異なるSaaSアプリを使用するたびにID、パスワードを入力、および管理する必要があり、ユーザビリティが低下します。もち...
hirotanoblog.com
2021.06.28
複数のSP（WebAPP-1とWebApp-2）がIdPと信頼関係を結んでいる場合、一度、WebAPP-1でIdPで認証がOKとなれば、他の信頼関係のあるSP（WebApp-2）に対しての接続も、ユーザにクレデンシャル情報を入力させずに、IdPは認証成功として扱います。ユーザにとっては、クレデンシャル情報を入力せず、SPへアクセスできることからシングルサインオンが実現されます。
コメント