Skip to content

SSO から始める

:upkeep-status: yellow

この記事は https://docs.evolveum.com/iam/myths/sso-first/ の翻訳です。

パスワードだらけでうんざりしていませんか。 うんざりしていない人などいるでしょうか。 全部忘れて、1つだけ覚えればよいなら素晴らしいと思いませんか。 しかも、それを入力するのは一度だけ。 シングルサインオン（SSO）こそ、私たちが本当に欲しいものです。 私たちに必要なものです。 では、できるだけ早く導入しましょう。 アイデンティティ管理プロジェクトは SSO から始めましょう。

もちろん、それは可能です。 ただし、近いうちに非常に高くつく失敗に発展しそうだと、今から上司に覚悟してもらうべきでしょう。

シングルサインオン

シングルサインオン（SSO）は、通常 アクセス管理 と呼ばれる技術分野が提供するサービスです。 それには十分な理由があります。 効率的な SSO ソリューションは、ユーザーの認証情報を一度だけ求めます。 その後は、ユーザーがすでに認証済みであるという事実を保持する必要があります。 そのためにセッションが必要です。 アクセス管理が担うのは、まさにこのセッション管理です。 また、ユーザーが認証されたという情報をアプリケーションへ渡す必要もあります。 認証済みユーザーのアイデンティティに関するデータも渡します。

しかし、このソリューションには大きな欠点があります。 SSO システムが認証データやアイデンティティデータをアプリケーションへ渡すには、アプリケーション側がそれらを 受け取り、正しく 解釈 できなければなりません。 ところが、それを行う汎用的な方法はありません。 この目的のためにプロトコルを設計しようとする試みは、いくつかありました。 SAML のように、一部の状況では非常に有用なものもあります。 しかし、それらは汎用的ではありません。 エンタープライズアプリケーションの大多数は、標準化されたプロトコルをサポートしていません。 運が良ければ、その種類のアプリケーション向けのエージェントがあります。 しかし汎用エージェントが使えるのは、通常、ごく単純な Web アプリケーションだけです。 少しでも複雑なものはカスタマイズが必要になります。 アプリケーション本来の認証機構を、SSO エージェントで置き換えなければなりません。 アプリケーションの認証が差し替え可能であれば、専用の認証プラグインが必要です。 ただし、そのようなケースは今でもかなり珍しいものです。 そうでなければ、ソースコードの修正、高額なプロフェッショナルサービス、さらに高額なサポート契約の拡張、そして昔ながらの泥臭い改造を大量に組み合わせることになります。

さらに、もう1つ問題があります。 アプリケーションが標準プロトコルをサポートしている場合でも、設定が簡単とは限りません。 統合が単純な「ログイン済みかどうか」を少しでも超えると、統合は悪夢になります。 アプリケーションごとに、必要とするアイデンティティデータの組み合わせが微妙に異なるからです。 プロジェクト全体はすぐに、非常に高価なスパゲッティの大皿になってしまいます。

これで終わりではありません。 システムアーキテクチャの観点から、おそらく最も重大な問題がもう1つあります。 ユーザーが1つのパスワードだけで認証される必要があるなら、各ユーザーに存在するパスワードも1つだけでなければなりません。 これは、各ユーザーに1つのアイデンティティが必要だということを意味します。 そして、各アプリケーションはそのアイデンティティを認識する必要があります。 ユーザー識別子は、アプリケーション間でそろっていなければなりません。 これは簡単な作業に見えるかもしれませんが、そうではありません。 まったく違います。 さらに、ユーザーアイデンティティの単一で信頼できるデータベースを整備しなければなりません。 そのようなデータベースはすでにあると思うかもしれません。 しかし、それが完全でない可能性は極めて高いでしょう。 すべてのアイデンティティを含んでいない、必要な属性をすべて含んでいない、属性の形式が誤っている、またはそのすべてが同時に起きています。

それでも、既存のユーザーデータベースの多くは、SSO プロジェクトを始めるには十分であることがあります。 多くの SSO プロジェクトは、いずれにせよ同じユーザーデータベース、たとえば Active Directory を共有している1つか2つのアプリケーションから始まります。 そのような場合、出だしは順調です。 しかし、これは危険な出だしです。 SSO という考えが実現可能だと「証明」してしまい、プロジェクトはさらに多くの費用と時間を使い続けます。 ところが、大きな予算があっても達成できることはごくわずかです。 アプリケーションを1つ追加で統合するたびに悪夢になります。 この種のプロジェクトはたいてい、30個のアプリケーションのうち3個を統合するだけで信じられないほどの費用を使い切って終わります。 それは通常、当初の目標から大きく外れており、この時点で投資回収の可能性は実質的に失われています。

解決策

次の条件を満たしていない限り、アイデンティティおよびアクセス管理（IAM）プロジェクトを SSO から始めてはいけません。

  • 統合を予定しているすべてのアプリケーションで使える、完全なユーザーデータベースがあると絶対に確信している。
  • アプリケーションを SSO に統合する費用が現実的であると確信している。

IAM プロジェクトの開始時点で、この水準の確信を持つことはほぼ不可能です。 したがって、最善の戦略は概念実証から始めることです。 概念実証には、最も単純なアプリケーションを選んではいけません。 それでは実際には何も証明できません。 手元にある中で最も難しいアプリケーションを選んでください。 そうすれば、ソリューション全体の費用を見積もる助けになります。 特定のプロトコルやベンダーに決める前に、概念実証を実施してください。 すべてのベンダーが同等の機能を持っているわけではなく、各製品を使える形にするために必要な作業量も大きく異なります。 SSO がそもそも実現可能だと判断できたら、プロジェクト計画を始められます。

おそらく最善の進め方は次のとおりです。

  1. 提案されたソリューションが実現可能か、実装にどの程度の労力が必要かを確認するため、同様に 現実的な 評価、つまり概念実証を実施する。

  2. ユーザーデータベースの状態を評価する。 選択したユーザーデータベースと、統合を予定しているすべてのアプリケーションのユーザーデータベースを比較する。

  3. 前の手順で得たデータに基づき、統合するアプリケーションと統合しないアプリケーションを選ぶ。 100% の統合は、ほぼ決して現実的ではないことを覚えておく。

  4. プロジェクト費用を見積もり、プロジェクトを計画する。

  5. 費用を見直し、効果と比較し、そもそもプロジェクトを始めるべきかを判断する。

ユーザーデータベース

あらゆる SSO プロジェクトにおける重要な関心事は、ユーザーデータベースです。 ユーザーデータベースの状態が悪いなら、SSO プロジェクトを始めてもまったく意味がありません。 そのようなプロジェクトを完了させることはできません。 それは、成功した IDM プロジェクトのほとんどが SSO から始まらない 理由でもあります。 実際、SSO は通常、アイデンティティ管理の TODO リストの最後の項目です。 典型的な IAM プロジェクトは、まず他の2つの重要な構成要素、アイデンティティストアと IDM システムから始まります。 なぜそれらが必要なのでしょうか。

  • アイデンティティストア は、統合されたユーザーデータベースです。 情報システムのユーザーに関する集約済みの情報を含みます。 通常は、LDAP サーバーなどのディレクトリサービスによって実現されます。 これは通常、SSO システムが利用するデータベースです。
  • アイデンティティ管理システム は、ユーザーデータベースを管理するシステムです。 HR や CRM などのデータソースとアイデンティティストアの間でデータを同期します。 アイデンティティストアを手作業で維持することは通常現実的ではないため、これはアイデンティティストアを最新に保つための重要な構成要素です。 IDM システムは、アプリケーションが必要とするすべてのデータを持つようにもします。 たとえば、アプリケーション内のユーザープロファイルをほぼリアルタイムに作成、削除できます。 その結果、SSO システムははるかに単純になる可能性があります。 アイデンティティデータのスパゲッティではなく、ずっと単純なユーザー識別子だけを扱えばよくなるかもしれません。 これにより、SSO ソリューションの費用は大幅に下がります。

実際、ディレクトリサービス、アイデンティティ管理、アクセス管理は非常にうまく連携します。 あまりに相性がよいため、多くのプロジェクトはこの技術の組み合わせを基盤にしています。

SSO は本当に必要か

そのとおりです。 もしかすると、問題は答えではなく問いにあるのかもしれません。 本当に必要なのは SSO では ない のかもしれません。

同じパスワードである限り、ユーザーが1日に数回パスワードを入力することは、通常それほど問題になりません。 これは SSO が実現することに かなり近い ものです。 この ほぼ SSO のソリューションと本物の SSO の効果の差は、驚くほど小さいものです。 しかし、費用の差は巨大です。 なぜなら、このほぼ SSO のソリューションは、単純な IDM システム を使って実装できるからです。 本物の SSO を実現する場合でも、IDM システムはいずれにせよ必要になります。 したがって、追加費用はほとんどありません。 一方で、SSO プロジェクトで最も高額な部分であるアプリケーションのユーザーインターフェイス統合を行わないことで、膨大な費用と時間を節約できます。 ユーザーは各アプリケーションの標準のユーザーインターフェイスを、そのまま使うだけです。 IDM システムは、パスワードが同期され、常に同じであることを保証します。 または、2つのセキュリティゾーンに2つの異なるパスワードを置くなど、必要に応じて構成できます。 この代替策は、巨大な SSO 費用のごく一部で済みながら、効果の大部分をもたらします。 しかし、この方法の最も良い点は、何も無駄にならないことです。 後で SSO に進むことを選んだ場合でも、IDM システムが管理するアイデンティティストアの上に実装できます。 すべての投資を再利用できます。

「本物の SSO」方式には、他にも代替策があります。 「エンタープライズ SSO」（ESSO）は、各ワークステーションにインストールするエージェントを使います。 エージェントはログイン画面が表示されるのを監視し、ユーザーが気づく前にユーザー名とパスワードを入力します。 ブラウザーの「パスワードを記憶する」機能のようなものですが、はるかに高速です。 アプリケーションの修正を必要としないため、本物の SSO と比べて導入費用はずっと安くなります。 これは良い考えに聞こえるかもしれません。 実際、状況によっては良い考えである場合もあります。 しかし、パスワードが安全な方法で管理され、送受信されることを確認しなければなりません。 また、少しでも本格的な導入では、結局 IDM システムとの統合が必要になります。 したがって、この方式が費用と潜在的なセキュリティ影響を正当化するだけの効果をもたらすか、慎重に検討する価値があります。 さらに悪いことに、ESSO という考え方全体は、新しい Bring Your Own Device（BYOD）の世界とは完全には相性がよくないようです。

「アイデンティティゲートウェイ」と呼ばれることが多い技術も、本物の SSO に対するもう1つの代替策です。 アイデンティティゲートウェイは、Web ログインフォームにユーザー名とパスワードを自動入力する一種のリバースプロキシです。 実際には、ESSO を Web 中心に置き換えたものです。 そのため、現在の技術動向との相性はずっと高くなります。 また、アプリケーションの修正を必要としないため、導入費用は許容できる水準に収まるかもしれません。 しかし、セキュリティや IDM システムとの統合など、ESSO と似た懸念の多くは残ります。 それでも、一部の環境では現実的な代替策になり得ます。

全体として、SSO は簡単な目標ではなく、決して安くもありません。 したがって、リスクが高く高額なプロジェクトへ全速力で突入する前に、代替策を検討する価値は十分すぎるほどあります。

関連項目