いまどきのシングルサインオン事情 (第4回 まとめ編)

この記事をtweetする このエントリーをはてなブックマークに追加

IT現場の道先案内人 Key Conductors

いまどきのシングルサインオン事情 (第4回 まとめ編)

エンドポイントセキュリティ 2013/06/25

 本連載の第1回第2回第3回では、それぞれ企業向け、文教向け、コンシューマ向けの最新のシングルサインオン動向について解説した。最終回となる第4回では、本連載のタイトルでもある「いまどきのシングルサインオン環境」に求められる要件について解説する。

いまこそ考える、シングルサインオン環境のセキュリティ強化

 最近、ID管理/アクセス管理の分野を騒がせているニュースと言えば、不正ログイン事件だろう。なんらかの手段で攻撃者が入手した大量のユーザIDとパスワードの組み合わせを他のサービスでも使えないか試し、不正にログインを試みるという事件が相次いでいる。

 このようなセキュリティ上の脅威が増加しているいまこそ、シングルサインオン環境の安全性についても再考すべきであろう。シングルサインオン環境は複数のアプリケーションの認証を一元化しているわけであるから、そのIDとパスワードが漏洩した場合の被害は甚大である。
 シングルサインオンはユーザの利便性を向上させることが利点の1つでもあるが、セキュリティの観点からは認証を一元化する前よりも厳密な認証が必要になる。シングルサインオンに関する多くの解説記事などでセキュリティ強化の必要性が説かれているが、ここでは整理の意味も含めて、改めてシングルサインオン環境のセキュリティ強化について考えてみよう。

不正ログインを防止する

 まず考えなければならないのは不正ログインの防止である。不正ログイン防止の対策として、以下のようなものが考えられる。

■アカウントロックの利用

 連続した認証の失敗によりアカウントをロックする。ロックされたアカウントは、一定の時間が経過するか、管理者がロックを解除するまで利用不可能な状態とする。ロックされるアカウントの発生数があまりに多いと管理者への問い合わせなどが増え、管理工数が増加してしまう可能性もあるため、実際に設定する際には許容する失敗回数などを慎重に検討する必要がある。

■パスワードポリシーの強化

 パスワードの登録時や変更時に複雑性を検証し、総当り攻撃によるパスワードの推察を防ぐ。シングルサインオン環境を構築している場合でも、ID/パスワードの管理は別のID管理ツールを利用している場合が多く、パスワードの変更もID管理ツールの専用画面などから行う場合が多い。

■多要素認証の利用

 ID/パスワードによる認証に加えて、さらに別の認証方式を組み合わせ多要素認証を構成する。ID/パスワード以外の認証方式としては、以前の連載でも紹介した以下のようなものがある。

■ワンタイムパスワード認証
■クライアント証明書認証
■リスクベース認証
■マトリクス認証
■生体認証

 ワンタイムパスワード認証は、ハードウェアトークンが不要な方式も広まってきている。例えば、あらかじめ登録したメールアドレスにワンタイムパスワードを送信したり、スマートフォンアプリでワンタイムパスワードを生成するような方式である。ハードウェアトークンを利用する方式では、ハードウェアの調達と配布にコストがかかっていたが、メールやスマートフォンアプリを利用したものであれば導入コストを抑えることができる。

不正ログインされてしまったら

 どんなにセキュリティを強化しても、絶対に不正利用されないシステムの構築は難しいのが現実である。万が一不正ログインされてしまった場合に備えた対策も考えておく必要がある。

■認証ログ、アクセスログの記録

 不正ログインの兆候を事前に発見するためと、不正ログインされてしまった際の調査のために、ログの記録は必須である。シングルサインオンシステムは大きく分けて、ユーザ情報を保存するユーザ情報データベース(LDAPやRDB)と、ユーザインタフェースを提供したり、HTTPリクエストを処理するWebアプリケーションから構成される。そのため、ログもユーザ情報データベースの認証ログと、Webアプリケーションのアクセスログの両方を記録することが推奨される。

 ユーザ情報データベースのログには、認証を行った時刻とその結果(認証の成功/失敗)が記録される。Webアプリケーションのアクセスログには、ユーザがアクセスしたURLや、ユーザから送られてきたHTTPリクエストデータが記録される。

 不正ログインはID/パスワードの試行だけでなく、Webアプリケーションの脆弱性を突いて行われる可能性もある。そのため、シングルサインオンシステムに対するHTTPリクエストを記録し、不正なアクセスの兆候がないかログをチェックすることも必要となる。

■即座にアカウントを無効化する仕組み

 不正ログインされてしまった場合に備えて、即座に該当アカウントを無効化するような仕組みもあるとよい。前述したように、シングルサインオン環境のユーザ管理はID管理ツールを利用することが多い。そのため、アカウントを無効化する機能もID管理ツール側の機能を利用することが多い。

全ての要件を満たすようなソフトウェアはあるか?

 4回に渡っていまどきのシングルサインオン事情について解説してきた。オンプレミスなアプリケーションに対応し、最新のプロトコルにも対応し、なおかつセキュリティも強化する。シングルサインオンを実現するために求められる要件は複雑である。

 1つのソフトウェアで全ての要件を満たせればよいが、現実はそうはいかない。多要素認証を利用したくても希望する認証方式が提供されていなかったり、最新のプロトコルに対応していなかったりと、シングルサインオンソフトウェアの選定に悩むこともあるだろう。

 機能が足りなければ追加実装するという選択肢もあるが、必要な機能を全て実装していてはコストが大幅に膨らんでしまう。大手ベンダの製品であれば、そう簡単には機能を追加してもらえない可能性もある。

 そこで考え方を変えて、複数のシングルサインオンソフトウェアを組み合わせて要件を実現するという方法を考える。それぞれのソフトウェアの得意とする機能を組み合わせて、全体として要件を満たすシステムを構築するのである。図1にそのイメージを示す。

図1.複数のシングルサインオンソフトウェアを組み合わせる

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

図1.複数のシングルサインオンソフトウェアを組み合わせる

 シングルサインオンソフトウェア同士を連携させるためには、SAMLのような認証連携のプロトコルを利用したり、APIを利用するなどの方法が考えられる。

 例えば、弊社が提供しているオープンソースのシングルサインオンソフトウェアであるOpenAMでは、外部から認証状態を確認可能なREST APIが用意されている。このAPIを利用すれば、他のシングルサインオンソフトウェアからOpenAMの認証状態を確認することができる。

 また、OpenAM の認証機能部分はプラグインモデルになっており、任意の処理を実行する認証機能を作りこむこともできる。この機能を利用して、OpenAMが他のシングルサインオンソフトウェアのAPIにアクセスして認証情報を共有するといったことも可能である。

 このように、複数のシングルサインオン方式やプロトコルの違いを吸収し、シングルサインオンのハブ的な役割を果たせるソフトウェアであれば、少々実装が古くなっても将来的な拡張にも対応できるかもしれない。

 シングルサインオンの世界も技術的な進歩が速い。最新の仕様や実装を追いかけるのはとても楽しい。その一方で、最新の仕様に準拠していなくても、長く運用できる拡張性に優れたソフトウェアを選択することも時には重要であるということを覚えておいて頂きたい。

会員限定で「読者からのコメント」が読み書きできます! 「読者からのコメント」は会員限定の機能。会員登録を行い、ログインすると読者からのコメントが読み書きできるようになります。

会員登録(無料)・ログイン

Myリストへ 印刷用ページへ

この記事をtweetする このエントリーをはてなブックマークに追加


この寄稿記事に掲載している情報は、掲載日時点での情報となります。内容は変更となる場合がございますのでご了承下さい。また、「Key Conductors」の寄稿記事及び当該記事に寄せられたコメントについては、執筆者及びコメント投稿者の責任のもと掲載されているものであり、当社が、内容の最新性、真実性、合法性、安全性、適切性、有用性等を保証するものではありません。


30006216


IT・IT製品TOP > Key Conductors > 野村 健太郎(オープンソース・ソリューション・テクノロジ株式会社 ) > いまどきのシングルサインオン事情 (第4回 まとめ編)

このページの先頭へ

キーマンズネットとは
Open Standard Cloud Association(OSCA)所属。某SIerでのID管理/アクセス管理製品のプリセールスを経て、2009年にOSSTechに入社。オープンソースソフトウェアであるOpenAMやOpenLDAPを利用したシングルサインオンシステムの構築を担当している。

ページトップへ