Single Sign On：確認すべき質問

祖父はいつも「新しいことを何でも試すな。まずは誰かが先に死ぬかどうか様子を見ろ」と言っていました。最近、私はいくつかの Single Sign On プロジェクトを形にする取り組みに携わっていて、その言葉が絶えず頭の奥に引っかかっています。ある部分の自分は「すべてにアクセスできるのが、ユーザー名とパスワード1つだけというのは悪い考えだ」と言います。もしハッカー攻撃が起きれば、侵入者はその人のものを手に入れて、あらゆるものにアクセスできてしまう。けれど、別の部分はそれを見て「ユーザーはきっとこれを気に入るよ」と言います。やるのも愚か、やらないのも愚か、という典型的なジレンマです。では、あなたはどうしますか？

Single Sign On とは何ですか？

最初に Single Sign On (SSO) をセキュリティの観点から見たとき、ただし細かな仕組みを理解していない人には、SSO は「企業レベルの自殺」のように見えるかもしれません。そもそも “Single Sign-On” という名称自体が、すべてを 1 セットの認証情報で行うイメージを思い起こさせます。しかし要点は、SSO はユーザーの負担を軽くし、なおかつセキュリティを損なわないよう設計されているということです。あなたが行っているのは、SAML（Security Assertion Markup Language）という仕組みを活用していることです。これは XML ベースのオープンソースのデータ形式であり、異なるアプリケーションや当事者間で認証および認可のデータを交換できます。さらに実際には、ユーザーの AD または LDAP の情報を活用することで、いわばもう 1 つ層を追加し、物事を少し“より強固に”する効果があります。

つまり、AD 上で既に付与されている権限に対して、それがどのように影響するかを結び付けることで、セキュリティを強化しているわけです。多くの場合、アプリケーションに関連付けられた別のユーザー名/パスワードがあるなら、それを一度入力するだけで、SSO アプリがアクセスを提供してくれます。少し怖く聞こえるかもしれませんが、典型的な AD のロックアウトは引き続き機能する点を覚えておいてください。さらに、アカウントが侵害された場合には、多くの SSO ソフトウェアに強力なレポート機能が備わっているという追加のメリットもあります。つまり、侵害されたアカウントやアクセスされたデータを検知できるのです。

Single Sign On を導入する前に確認すべき質問

ここではあえて私が“悪魔の代弁者”になって、誰もが頭の中で抱えている疑問を聞いてみます。結局のところ、どれほど本当に安全なのでしょうか？

まあ、悪魔のように（？）答えを引き延ばして、これから数週間のうちにその点を見ていくことにします。今は、あなたの組織で何らかの Single Sign On を導入したいと仮定しましょう。組織で SSO を導入したいなら、考えておくべきことがいくつかあります。

最初に挙げるべき点は、私たちが話しているのは「新しいもの」なのか、それとも「アップグレード」なのかということです。多くの場合、古いものを置き換える新しい SSO 製品です。ここから、トレーニングとコミュニケーションのことを考え始める必要があります。コミュニケーション——ユーザーに何が起きているのかを知らせるために。トレーニング（たとえそれがオンライン動画だけだとしても）——新しい製品の使い方を教えるために。

それで私たちは何をしようとしているのでしょうか？アクセスを集中管理したいのでしょうか？権限付与を改善することでセキュリティを高めたいのでしょうか？それとも、単に従来どおりの監査（オーディティング）だけを行いたいのでしょうか？おそらく、この3つすべてを達成しようとしているのかもしれません。結論として、最後にどんな状態になるのか、何を期待できるのかを事前に分かっていれば、成功するプロジェクトにつながります。

最初の段階で、どのアプリケーションにアクセス権を提供したいのかを決めておくことは非常に重要です。ほとんどのアプリケーションは SSO とうまく連携しますが、中にはそうでないものもあります。そうでない「それ以外」のアプリケーションは、あなたの作業を本当に大変にし、第三者の関与や、動かすためにそれなりの創意工夫が必要になるかもしれません。つまり、それを想定しておきましょう。

誰がそれを面倒を見るのでしょうか？システムには責任を持つ人が必要で、対応するために、会社内の異なるレベルの複数の人が関わることもあります。たとえば、最近の SSO プロジェクトでは、私はサーバーへのセットアップ、プロジェクト管理の支援、最初のアプリケーションの導入とユーザーの初期投入（seeding）を担当しました。ですが、早い段階で、将来的には新しいユーザーの追加は Tier 1 の担当者が行うことが決まっていました。なので、彼らを体制に入れて、少なくともその時点までのトレーニングを提供する必要がありました。一方で、アプリケーションの管理やサーバーの運用・メンテナンス（もちろん、今後のアップグレードや DR も）は、確実に私の担当となりました。

おそらく私たちが注意すべき最も重要なポイントは、私たちが購入する SSO が、会社が成長し変化していくのに合わせて、継続的に成長し進化し続けるかどうかです。

そして、ずっと昔の60年代に言われていたように、ダイヤルには触らないでください。