【SSE】[Zscaler] [ZIA] [設計] [個別] [非インライン] ユーザ認証方法とユーザ同期方法

はじめに

ZIAでは、ユーザーが利用を開始するまでに

• ユーザ認証（Authentication）
• ユーザ同期（Provisioning）

という2つの仕組みが存在します。

どちらも似たような話に見えますが、役割はまったく異なります。

実際、Zscalerの管理画面でもAuthentication と Provisioningは別々に設定するようになっており、

設計においても明確に分けて考える必要があります。

本記事では、「ユーザーがZIAを利用できるようになるまで」という観点で、それぞれの役割を整理します。

ユーザ認証（Authentication）とは

ユーザ認証とは、「そのユーザー本人であることを確認する仕組み」です。

例えば、Zscaler Client Connector（ZCC）やブラウザからログインすると、ユーザーは認証処理を実施します。

認証方式は主に以下の2種類です。

• Hosted User Database（ローカル認証）
• SAML認証

※本記事ではSP Initiated SSOを前提として説明します。

Hosted User Database

最もシンプルな認証方法です。

ZIA管理画面へ直接ユーザーを登録し、そのユーザー名・パスワードで認証します。

小規模環境や検証環境では利用されることがありますが、企業利用ではあまり多くありません。

SAML認証

現在最も一般的な認証方式です。

認証処理をIdPへ委譲します。

• Microsoft Entra ID
• Okta　等

ユーザーはIdPで認証され、条件付きアクセスや多要素認証なども含めた認証結果がZIAへ返されます。

企業ではこちらを利用するケースがほとんどです。

Authentication Domainの役割

SAML認証を利用する場合、ユーザーが入力したメールアドレス（ユーザーID）から、

どのZscalerテナントへ認証を行うのかを判断する必要があります。

そこで利用されるのが Authentication Domain です。

例えば、「user@company.com」というユーザーIDであれば、「company.com」というドメイン情報をもとに、

まず対象となるZscalerテナントを特定します。

その後、そのテナントで設定されている認証方式（Hosted User DatabaseまたはSAML）で認証が行われます。

SAML認証を利用している場合は、さらにAuthentication Domainごとに設定されたIdPへ認証要求がリダイレクトされます。

例えば、一つのZscalerテナントで

• company.com
• subsidiary.co.jp

といった複数のドメインを利用している場合でも、認証方式はテナント単位で統一されますが、

各ドメインごとに異なるIdPを設定することが可能です。

そのため、グループ会社や買収企業など、複数の認証基盤を持つ環境でも、一つのZscalerテナントで柔軟に認証を構成できます。

ユーザ同期（Provisioning）とは

一方、Provisioningは「ZIAへユーザー情報を登録・更新する仕組み」です。

認証が成功しても、ZIA側にユーザー情報が存在しなければ、

ユーザーへポリシーやライセンスを適用できません。

つまり、認証だけではZIAは利用できません。

逆に、ユーザー情報だけ存在していても、認証できなければログインできません。

つまり、認証とProvisioningは両方必要ということです。

Provisioningの種類

現在主流となるProvisioning方式は、以下の3種類です。

• Hosted User Database
• SAML Auto-Provisioning
• SCIM

※LDAPやZABなど他の方法もありますが、本記事では一般的な構成に絞って紹介します。

Hosted User Database

認証と同様、ZIA管理画面へ直接ユーザーを登録します。

登録した情報をそのまま利用するため、最もシンプルな方式です。

SAML Auto-Provisioning

SAML認証が成功したタイミングで、ユーザー情報をZIAへ自動登録・更新する方式です。

ユーザーが初めてログインしたタイミングでユーザー情報が作成され、以降も認証時に属性情報が更新されます。

比較的シンプルな構成で導入できるため、現在でも多く利用されています。

一方で、ユーザー情報の更新は認証が実行されたタイミングのみとなります。

そのため、長期間ログインし続けるユーザーについては、IdP側で部署やグループを変更しても、

再認証されるまでZIAへ反映されません。

また、退職者をIdPから削除しても、ZIA側のユーザー情報は残り続けます。

SCIM

現在最も推奨されるProvisioning方式です。

SCIMでは、IdPとZIAがリアルタイムに同期されます。

例えば、

• ユーザー追加
• ユーザー削除
• グループ変更
• 部署変更

などが、認証を待つことなく即座に反映されます。

そのため退職者の削除漏れや、異動時のポリシー反映遅延を防ぐことができます。

また、Active Userライセンスについても、利用されなくなったユーザーが

管理画面へ残り続けることがなくなるため、運用面でもメリットがあります。

なお、SCIMを利用する場合、SAML Auto-Provisioningは利用しません。

認証はSAML、ProvisioningはSCIM、という組み合わせが一般的です。

SCIMを利用しないという選択肢

もちろん、すべての環境でSCIMが導入できるわけではありません。

例えば、IdP管理者とZIA管理者が異なる組織であり、運用上SCIMを利用できないケースもあります。

その場合は、SAML認証とSAML Auto-Provisioningだけでも十分運用可能です。

また、属性同期（例：memberOf）を同期対象から外すことで、

ユーザー情報のみをIdPから同期し、グループ管理だけをZIA側で実施する運用も可能です。

構成は少し特殊になりますが、組織体制によっては有効な選択肢となります。

ZIAだけの話ではない

本記事ではZIAを中心に説明しましたが、

実際にはZPAでも同様に認証とProvisioningの仕組みが存在します。

さらに、Zscaler Client ConnectorのApp Profileなど、多くの設定は

ZIAのユーザー情報を基準として動作します。

つまり、ZIA・ZPA・ZCCは、それぞれ独立してユーザーを管理しているのではなく、

ユーザー情報という観点では密接に連携しています。

例えば、ZIAとZPAの両方を利用している環境では、

両サービスで認証・Provisioningが正常に完了していなければ、

ログインに失敗するケースもあります。

そのため、ユーザー管理は「ZIAだけ」「ZPAだけ」という点で考えるのではなく、

Zscaler全体を通した一つのユーザー基盤として捉えることが重要になります。

設計で重要なこと

認証方式とProvisioning方式は、別々に考える必要があります。

例えば、

認証：SAML

• Provisioning：SCIM

という構成もあれば、

• 認証：SAML
• Provisioning：SAML Auto Provisioning

という構成もあります。

設計時には、「どの方法で本人確認を行うか」だけでなく、「ユーザー情報をどのように維持・更新するか」

まで含めて考えることが重要です。

現在では、認証はSAML、ProvisioningはSCIMが第一候補となりますが、

組織体制や運用方法によっては、SAML Auto-Provisioningも十分有効な選択肢となります。

おわりに

ZIAを利用するためには、認証とProvisioningの両方が必要です。

認証は「本人確認」、Provisioningは「ユーザー情報の管理」。

この二つを分けて考えることで、ZIAだけでなくZPAやZCCも含めたZscaler全体のユーザー管理が理解しやすくなります。

今後、ユーザー数が増えたり、運用を効率化したりすることを考えると、

SCIMを利用したリアルタイム同期が有力な選択肢となります。

一方で、組織体制や運用方針によっては、SAML Auto-Provisioningも十分実用的です。

重要なのは、「認証方法」と「ユーザー同期方法」を別々に設計するという考え方です。

➡【次の記事へ】【SSE】[Zscaler] [ZIA] [設計] [個別] [非インライン] Nanolog Storeaming Service

管理人

自称SASEエンジニアです。 2児の父親をやりながら、日々エンタープライズ向けの次世代ネットワークインフラと格闘しています。一日一投稿を目標に投稿頑張りますので、是非読んでください！