【認証の小話】シングルサインオンと認証、認可

IceWallサポートチームの真野です。
これまでに、OpenID Connect仕様に沿ったRP/OP機能を有する製品開発、そして、2段階認証としてメールを利用したOTP(One-Time Password)生成・認証プラグインの開発を経て、現在は日本ヒューレット・パッカード社と共同開発している『IceWall SSO』というSSO製品のサポートチームに所属しています。

今日は、入社から6年、認証技術一本でどっぷりやってきた私が、認証に関するあれこれを改めて説明していきます。

セキュリティと利便性の関係

昨今、セキュリティの重要性は年々高まってきています。
またセキュリティを考慮する理由も、
クラウドサービスの利用などITの高度化に合わせたリスク対策であったり、
個人情報漏洩に対する危機感によるものであったりと様々です。

一般的にセキュリティを高めるということは、それに反比例して利便性を下げることにも繋がります。
家のドアに鍵をかけなければ、鍵を開ける手間が省ける代わりに、泥棒にとっては格好の餌となります。
逆にドアに何重もの鍵をかけてしまうと泥棒は諦めるかもしれませんが、家に入るたびに手間と時間がかかります。
また、どの鍵がどのドアに対応しているのか判断することが大変になってしまいます。
そのため、セキュリティを高めるにはどうするかを考える場合、利便性とのバランスも考えることが必要不可欠です。
セキュリティと利便性のバランスを考慮すると、シングルサインオンは欠かせない技術と言えます。

ではなぜ、シングルサインオンがセキュリティや利便性に優れているのでしょうか？

シングルサインオンとは？

シングルサインオンとは、認証が必要な複数のアプリケーション・サービスを利用する際に、一度ログインするだけで各サービスが利用可能になる仕組みのことです。
シングルサインオンを使わない場合、複数のサービスを利用するユーザはそれぞれのユーザIDやパスワードを記憶しなければなりません。これでは利用するサービスが増えれば増えるほどユーザの負担が増大します。
結果、パスワードを覚えきれず、
・パスワードを多くのサービスで使いまわす
・紙媒体等に記録してしまい、漏洩のリスクが高まる
・パスワードの初期化作業を都度行うことになり、手間がかかる
など、様々なデメリットが出てしまいます。

シングルサインオンは、これらデメリットへ対応することに適しています。
1つのサービスに対して認証が成功した際、有効期限がついたアクセス権限等を用いることで、各サービスはユーザID・パスワードを確認することなく、アクセス権限等を用いてユーザがログインしてもよいかを検証します。
そのため、ユーザが一つのユーザID・パスワードを管理するだけで良くなり、一度ログインし有効期限が切れていない間は、各サービスにログインし直す必要もなくなるので、ユーザからの利便性がグッと向上します。

シングルサインオンを実現するための方式は幾つも存在します。
ここでは、以下の方式を紹介します。

• リバースプロキシ型
• エージェント型
• フェデレーション型

それぞれにメリット・デメリットが存在します。

リバースプロキシ型

リバースプロキシ型は、ユーザと利用するサービスの間にリバースプロキシサーバを設置し、リバースプロキシサーバにシングルサインオンの機能を導入することで実現する方式です。
リバースプロキシサーバの後ろに各サービスを配置し、リバースプロキシサーバがリクエストやアクセス権限の管理を一元的に行います。

メリット

各サービスに対してシングルサインオンの機能を実現する必要がないため、コストが少ない。

リバースプロキシサーバを経由することで、後ろにある各サービスが隠蔽されるためリバースプロキシのセキュリティを高めることで全体の安全性が高められる。

デメリット

リバースプロキシに対してアクセスが集中するため、アクセス分散などの処理が必要となる場合がある。

リバースプロキシを経由して各サービスにアクセスできるようにネットワーク構成を変更する必要がある。

エージェント型

エージェント型は、各サービスにシングルサインオンを行うためのエージェントと呼ばれるモジュールを組み込み、各サービス側でシングルサインオンの機能を導入することで実現する方式です。
各サービスへリクエストが来た際に、サービス内に組み込んだエージェントが、ユーザ情報を管理しているサーバに対して、ログイン可能か、アクセス権限は問題ないかを問い合わせ、結果が認証OKかを確認します。

メリット

ネットワーク構成を変更する必要がない。

各サービスが処理を行うため、ボトルネックになる箇所が少なく、パフォーマンスがリバースプロキシ型と比べ優れている。

デメリット

各サービスにエージェントを組み込む必要があり、サービスが増えるごとに手間がかかる。

各サービスのサーバがエージェントに対応していないことがある。

フェデレーション型

フェデレーション型は、前述の２つの方式が基本的には社内など限られた範囲での認証に利用されるのに対し、クラウドサービスや別システムなど社外に対するサービスとのシングルサインオンを実現するための方式として多く利用されている方式です。
この方式は、ユーザID・パスワードの代わりに認証情報をサービス間で受け渡すことで、シングルサインオンを実現します。
多くのクラウドサービスは、このチケットの渡し方をSAML（Security Assertion Markup Language）やOpenID Connectといった標準化された仕様に基づいて決めています。

まとめ

大きく３つの方式をご紹介しましたが、各方式にはそれぞれメリット・デメリットが存在します。シングルサインオンを実現するためにどの方式が一番適しているのか、よく考えてからシングルサインオンを導入する必要があります。

また、シングルサインオンにももちろんデメリットが存在します。
大きなものでは、１つのユーザID・パスワードのみで他のサービスに認証が行えるため、この認証情報が他人に漏れてしまうと大きな被害を被ってしまうことが挙げられます。
そのため、この認証情報が漏れない、漏れても簡単には利用できないようにセキュリティを別途考慮する必要があります。例えば、ユーザID・パスワードが漏れた際の防止策として、OTPやFIDO U2Fなどといった２段階認証を利用する、ログイン時に登録しているメールアドレスにログイン情報をメールし、不正アクセスを監視するなどといった考慮が挙げられます。

『セキュリティを向上させるために、とにかく高セキュリティのものを！』
『利便性を高めるものを入れて、効率化を図る！』
と、どちらか片方のみの考えで製品やサービスを導入することは思わぬ落とし穴に陥ることがあり、必要なことはセキュリティと利便性のバランスでありメリットがデメリットを上回るかどうかだと私は考えています。

これを読まれた皆様がよりセキュリティと利便性のバランスについて、興味を持っていただけたら幸いです。