[連載]「お前は誰だ！」ゼロトラストの柱。アイデンティティ。IdPが無いと始まらない理由[第1回]

恐縮です。
会社員が故、GW前の飲み会に参加しており投稿が滞りました。

ゼロトラストを語るとき、どうしてもSSE/SASEやEDRのほうが目立ちます。
見た目に変化が出やすいからです。VPNが減る。端末が見える。アクセス経路が変わる。ここは分かりやすい。

でも、現場で本当に最初に詰めるべき柱は何かと聞かれたら、私はかなり強くアイデンティティだと思っています。
理由はシンプルです。
誰がアクセスしているのかが定まらないと、他の柱が全部ぼやけるからです。

端末を評価したい。
ネットワークで到達先を制御したい。
ワークロード側でアクセス条件を絞りたい。
データ保護を強めたい。
どれも正しいです。
ただ、その前に「誰に対する制御なのか」が曖昧だと、全部が中途半端になります。

ゼロトラストは、社内だから信頼する設計をやめて、アクセスのたびに判断する設計に変える話です。
だとすると、その判断の起点は何か。
まずは誰かです。
ここが定まらないまま先へ進むと、結局はIPアドレス、ネットワークの場所、例外申請、属人的な運用に戻っていきます。

参考URL

アイデンティティの柱は、ログインを楽にするための柱ではない

ここはかなり大事です。
アイデンティティの柱というと、SSOができる、ログインが楽になる、MFAが入る、という話に寄りがちです。
もちろんそれも大事です。
ただ、ゼロトラストの文脈ではそこが本体ではありません。

本体は、後ろの制御に使える判断材料を揃えることです。

このユーザーは誰か。
所属はどこか。
雇用区分は何か。
特権を持っているか。
どんな認証強度で入ってきたか。
いま使っている端末は管理下か。
例外アカウントなのか。
退職予定や休職状態はどうか。

こうした情報が、アイデンティティの柱に集まって、はじめて他の柱が生きます。
SSE/SASEで「この条件なら許可」と書きたくても、条件の中身が雑なら意味がありません。
EDRやUEMの信号を使いたくても、誰の端末かがきれいにつながっていなければ制御に乗りません。

だからアイデンティティは、認証の便利機能ではなく、制御の起点を作る柱です。
ここを見誤ると、IdPは入ったのにゼロトラストはあまり前に進まない、ということが普通に起きます。

参考URL

なぜ「IdPが無いと始まらない」のか

ここも、かなり断言していいと思っています。
IdPが無いと始まりません。
少なくとも、現代的なゼロトラストの土台としてはかなり苦しいです。

なぜか。
IdPが無い環境では、認証と権限の情報がアプリごとに散ります。
MFAの有無もばらつく。
退職者の剥奪もアプリ単位で漏れる。
例外アカウントは増える。
共有アカウントが残る。
アクセス判断を一か所で揃えられない。

これでは、ゼロトラストでやりたい「毎回ちゃんと判断する」が実装できません。
毎回判断したいのに、判断材料が散っているからです。

逆にIdPが統制点になると、一気に景色が変わります。
SSOがまとまる。
MFAの強制点ができる。
条件付きアクセスの起点ができる。
プロビジョニングと剥奪の流れを寄せられる。
監査ログが集まる。
そして何より、誰に対して何を許すのかを一か所で考えやすくなります。

これはかなり大きいです。
ゼロトラストは製品を入れる話ではなく、判断を制御に変える話です。
その判断の中心点として、IdPはほぼ必須です。(てか、必須)

参考URL

現場で最低限そろえたいもの

アイデンティティの柱で、最初から完璧を目指す必要はありません。
ただし、最低限ここまでは揃えたい、という線はあります。

まずはSSOです。
アプリごとに認証が分かれていると、統制が始まりません。
ログインを便利にするためではなく、認証の入口を寄せるために必要です。

次にMFAです。
しかも、ただ配るだけではなく、できれば認証強度の差を扱えることが重要です。
誰でも同じ一段階認証ではなく、リスクやアカウント種別に応じて強められることが欲しい。

その次が条件付きアクセスです。
ここが無いと、IdPは認証箱で終わりやすい。
ユーザー属性、端末状態、場所、リスクを見て制御できるか。ここが実務では効きます。

さらにライフサイクル管理です。
入社、異動、退職でアカウントと権限がどう変わるか。
ここが手作業のままだと、きれいな認証基盤を作っても運用はすぐに崩れます。

最後に監査ログです。
誰が、いつ、どこから、どう認証したか。
どのポリシーで許可・拒否されたか。
これが取れないと、後段の可視化と分析につながりません。

要するに、アイデンティティの柱で欲しいのは、
認証をまとめること
認証強度を上げること
属性を制御に使うこと
ライフサイクルを閉じること
この4つです。

参考URL

代表的な製品はこの3つから見ればだいたい外さない

この柱で代表例を3つ挙げるなら、まずは
Microsoft Entra ID
Okta Workforce Identity
PingOne for Workforce
でよいと思います。

ここで言いたいのは、どれが一番かという話ではありません。
現場で比較対象に上がりやすく、考え方の違いを見やすい3つ、という意味です。

Microsoft Entra IDは、Microsoft 365、Intune、Defenderとつなげやすいのが強いです。
すでにMicrosoft寄りの環境なら、アイデンティティ、端末、セキュリティ信号をまとめやすい。
この一体感は実務ではかなり効きます。

Okta Workforce Identityは、異種SaaSが多い環境で比較対象に上がりやすいです。
SSO、MFA、ライフサイクル管理を中立的に寄せやすく、Microsoft一色ではない環境で整理しやすい。

PingOne for Workforceは、レガシーアプリや複雑な認証要件が残る環境で見やすい選択肢です。
きれいなSaaS統一環境だけではなく、現実の混在環境を前提に比較しやすい。

大事なのは、製品名そのものより、
自社のアプリ構成と運用の癖にどこまで合うかです。
きれいなデモより、入社・異動・退職、例外アカウント、業務委託、共有端末、管理者アカウントをどうさばけるかを見るべきです。

参考URL

現場でよくある失敗は、だいたい同じ

一番多いのは、SSO導入で終わった気になることです。
これは本当によくあります。
ログインが楽になった。アプリもつながった。見た目には進んだ感じがする。
でも、属性設計が甘い。グループが汚い。例外アカウントが多い。退職者の剥奪が手作業。これでは柱になりません。

次に多いのが、MFAを配っただけで満足することです。
もちろん入れないよりはいいです。
ただ、共有アカウント、特権アカウント、古いプロトコル、役員例外、現場端末の例外を放置すると、守りたいところほど別運用になります。
現場はだいたいここで苦しみます。

さらに危ないのが、人事イベントとつながっていないことです。
入社時の付与より、異動と退職の剥奪の方が難しい。
そして事故につながりやすいのもこっちです。
アカウント管理が人事・総務・情シス・業務部門で分断されていると、IdPを入れても運用は締まりません。

あと見落としやすいのが、管理者アカウントを別腹にしてしまうことです。
一般ユーザーはきれいに統制するのに、管理者だけはローカル運用、共有運用、長寿命認証情報、という形が残る。
これはかなり危ない。
ゼロトラストの入口で、最初に特別扱いを作ってしまうからです。

参考URL

この柱が整うと、次の柱がやっと回り始める

アイデンティティの柱が整うと、次のデバイスの柱が急に意味を持ち始めます。
このユーザーは誰か。
この端末は誰にひもづくか。
この認証は十分に強いか。
このアカウントは一般権限か、特権か。
この情報がつながると、EDRやUEMの信号をアクセス制御に使いやすくなります。

逆にここが弱いと、デバイスは見えるけれど制御にはつながらない。
SSE/SASEは入ったけれど許可ルールが雑。
ログはあるけれど判断軸がない。
そういう、もったいない状態になりやすいです。

なので、ゼロトラストの最初の柱としてアイデンティティを置くのは、思想の話ではありません。
かなり現実的な順番の話です。
最初にここを固めるから、後ろが回り始める。
この順番は、やはり強いです。

まとめ

アイデンティティの柱は、ログインを楽にするための柱ではありません。
誰がアクセスしているのかを定めて、後続の制御に使える判断材料を揃える柱です。

だから、ゼロトラストの話で最初にIdPを置くのは自然です。
むしろ、ここを曖昧にしたまま先へ進む方が危ない。

SSOを入れる。
MFAを整える。
条件付きアクセスを使えるようにする。
ライフサイクルを閉じる。
監査ログを残す。
このあたりが揃って、やっとアイデンティティの柱が柱として立ちます。

そしてこの柱が立つと、次のデバイスの柱がやっと効いてきます。
誰か分からない端末制御より、誰にひもづく端末制御の方が圧倒的に強いからです。

やはり最初はここです。
IdPが無いと始まらない。
これは、かなり本質に近い話だと思っています。

恐縮でした。