※本記事は、Paul Toalによる”How to do Identity Management, whilst not doing Identity Management“を翻訳したものです。
この数週間で、忘れられないことが2つありました。まず、先日あるウェビナーに参加して、セキュリティの一般的な課題、リスク、リスクの軽減について話をしたのですが、質疑応答の時間に、複数の異なるユーザー名とパスワードの扱いに関する質問を受けてとても驚きました。思い出したくもないほど長い期間、IDの問題と格闘してきた人の1人である私にとっては、シングル・サインオン（SSO）が当たり前なのです。しかし、誰もがSSOを使えるわけではないことを心に留めておかなければなりません。私の一番下の娘は今月大学に入ったのですが、複数のシステムで複数の資格証明を使い分けています。
2つ目は、ID管理について、複数のお客様と何度も同じような会話をしているということです。お客様は普通、たくさんのサードパーティ製のサービスを購入しています。Oracle Cloudのサービスかもしれませんし、SaaS、PaaS、IaaS、またはその他のサービスかもしれません。そうしたサービス間でSSOを使用するにはどうすればよいのか、と訊かれるところから会話が始まります。頻繁に交わされる会話はこのようなものです。
私：今は、ユーザーIDをどこに保存して、ユーザーを認証しているのですか?
お客様：AD（またはその他のIDストア）です。
私：そうですか。統合を進めたいと思っているID管理システムがあるのでしょうか?
お客様：はい。ADです。
私：いえ、それはディレクトリですよね。ID管理システムは、利用されていますか?
お客様：いいえ、いくつかスクリプトを使ってはいますが……
私は決して、ID管理システムをしかるべきところに用意していないことで、お客様を責めようとしているのではありません。たしかに、ID管理システムには大きなビジネス上の価値があり、法律や規制の遵守に役立ちますし、短期間で成果を上げつつ、段階的なメリットを得ることもできます。しかし以前にも説明したように、そうしたシステムは概して複雑であるため、注意深く実装する必要があります。
ただし、先ほどの例のようにお客様と話をするとき、お客様はID管理のプログラムを探しているわけではありません。お客様はいくつかのサービスを使っていて、パスワードをあっちにもこっちにもそっちにも入力することなく、そうしたサービスへのアクセスを管理したいと思っているのです。
そこで私は、「IDを管理せずに、IDを管理する方法とは」というテーマで記事を書くことにしました。もう少し正確に言うと、ID管理のプログラムをフル装備せずに、新しいサービスを導入するにはどのようなことを検討すればよいのか、ということがテーマです。これは重要です。あなたの会社が人材管理（HCM）のためにOracleのSaaSを導入したところだとしましょう。HCMプログラムの一環としてIdentity and Access Management（IAM）を導入することは避けたいと思っています。IAMを利用する場合は、専用のプログラムを作成して、会社全体に展開しなければならないからです。
IAMを導入しない場合は、HCMプロジェクトのみを対象にして何をする必要があるのか、明確に分かっていなければなりません。
シングル・サインオン（SSO）
私がお客様と話すときに、一番よく質問されるのがこれです。すでに使っている認証の方法にSSOを統合して、ユーザーがユーザー名とパスワードをいくつも入力しなくて済むようにするにはどうすればよいのでしょうか。
統合の方法はいくつかありますが、比較的新しいと言えるサービスを使っているのであれば、おそらくフェデレーション（つまりSAML）による統合を選ぶことになるでしょう。
次のことを考えてみる必要があります。
- 既存の資格証明のうち、ユーザーが認証を行う必要があるものはどれか。
- ユーザーの種類（顧客、従業員、サプライヤーなど）が複数ある場合、資格証明の形式も異なっている必要があるか。
- 自社が使用できる統合の方式（SAMLなど）を、プロバイダはサポートしているか。
- 対象となっている特定のサービスでは、資格証明を確認するためのもっと強力な方法（多段階認証など）が必要ではないか。
- 対象となっている新しいサービスへのアクセスを管理する、コンテキストベースのルール（地理的位置ベースのアクセスなど）が必要ではないか。
- そのサービスには社外と社内の両方からアクセスできる必要があるか。
このような点について検討し、現在の認証プロバイダと統合する方法を決めたら、IDライフサイクル管理（ILM）について考えてみる必要があります。
IDライフサイクル管理
ここが、ちょっと注意しなければならないところです。ここで油断していると、もっと大きな意味でのID管理に関する議論が始まって、身動きが取れなくなってしまいます。対象のシステムがHCMの場合は特にそうです。大がかりなIAMプログラムでは、HCMはID情報の主要なソースでもあるからです。
しかし、ここで想定している新しいサービスでは、社内のユーザーにサービスを普及させる方法、そしてユーザーが更新された場合の管理の方法に重点を置き、対応していく必要があります。
次のことを考えてみてください。
- 新しいサービスに入力する自分のIDデータをどこから取得したいのか。
- ソースのIDデータへの更新や変更を、ターゲットでどのように管理するのか。
- ソースとターゲットの両方で使用できるインタフェースはあるか。
- ユーザーデータだけを同期しているのか、それともロールを含める必要があるのか。
- すべてのユーザー/ロールを同期しているのか、それとも一部分だけか。
- 新しいサービスには、アクセス制御を判断するのに必要なID情報がすべてそろっているのか。
大抵は複数の選択肢があり、何が回答としてふさわしいのかは、さまざまな要素に左右されます。新しいサービスが特殊なもので、社内で5人しかアクセスしないのであれば、手動でユーザーを作成して管理すれば済むかもしれません。または、10万人の社員全員が給与情報にアクセスする必要があるので、ILMを自動化したいと思っているのかもしれません。
これまでお話ししたような、単体での統合に変更不能なものはなく、要件が変われば進化していくでしょう。ですから、IAMを導入する場合でも、SSOやILMといったサービスが自分の選んだIAMプラットフォームとどのように統合されるかを理解しておくことが必要です。IAMでは、フェデレーションとILMだけではできないたくさんのことを実現できるという点を忘れないでください。高度なIAMプログラムでは、次のようなアクセスやガバナンスのフレームワークを全社で利用できます。
- 認証（フェデレーション、SSO、MFA、リスクベースなど）
- 認可
- アクセス制御
- ユーザー・プロビジョニング/同期
- 認定
- 職務分掌
- セルフサービス/委任管理
- 一元化されたID監査
- ワークフローと承認
- 特権アクセスの管理
もしかすると私は、IAMプログラムをフルに導入したいという読者の気持ちをくじけさせてしまったでしょうか。または、考え抜かれて定義されたプログラムではなく、ポイント・ソリューションにこだわりすぎたでしょうか。いえ、そんなことはまったくありません。優れたIAMプログラムは重要であると私は考えています。とはいえ、すべての人がそれぞれの組織内で、同じような高度な環境にいるわけではありません。IAMプログラムが使える状態にないからといってイノベーションを止めることはできませんし、新しいサービスを導入しないわけにもいきません。そのため、私がここでお話ししているのは、新しいサービス導入への実際的なアプローチであり、このアプローチはもっと広範なIAMプログラムにも完全に対応しています。
ですから新しいサービスを採り入れるときには、そのサービスでSSOを実装する方法、また最低限のユーザー管理を行う方法に重点を置いてください。その両方を勘案しておけば、短期間で成果を上げることができますし、将来もっと戦略的なソリューションを導入するときにも妨げとなることはないでしょう。