お疲れ様です。

社内SEのちゅみたです。

社内SEの皆さんはIT機器諸々の管理もされていると思うのですが、最近はそういう管理業務でもクラウド化が進んでいますよね。

例えばユーザーや端末を一括管理するAD（アクティブディレクトリ）も自前のWindowsServerに構築せずクラウドのAzureADでできるようになりました。

私は最近転職したのですが、前職の「社内だけのクローズ環境」とは違い、転職先はほぼクラウドベースなのでセキュリティ周りの仕組みが違う＆高頻度で更新されていくので勉強の毎日を過ごしています。

今回はその日々の学びの中で、セキュリティ対策のSSO（シングルサインオン）について書きたいと思います。

情報セキュリティ対策は企業の社会的責任の1つです。

みんなで世の中の巨悪から会社と顧客を守れる人になりましょー！

結論ファースト

• SSOは1度のID、PW認証で複数のサービスにログインできるようになる仕組みのこと
• 導入することでユーザーによるID管理工数の削減と、1つの情報を厳格に管理すれば良いので煩雑にならずセキュリティ向上に繋がる
• SSO（シングルサインオン）には認証方法が様々あり、環境に合わせて認証方法ごとのメリット、デメリットの検討が必要

SSO（シングルサインオン）とは

そもそもSSOってなに？

SSO（シングルサインオン）とは1組のID・パスワードによる認証を1度行うだけで、連携している複数のシステムやクラウドサービス、アプリケーションに自動でログインできるようになる仕組みのことです。

サービスごとに異なるIDとパスワードを入力・管理する必要がなくなるため、ユーザーの利便性が向上します。

Single Sign Onの頭文字を取って「SSO」と表記されます。

なんでSSOがもとめられるの？

1つのIDとパスワードで複数のシステムが利用できるようになり、ユーザーの負担を軽減することができる＆情報漏えいといったセキュリティリスクを抑える効果があるからです。

メール管理やドキュメント管理、CRMの利用など、外部の便利なクラウドサービスを活用することは今や当たり前の時代となりました。

例えばTeams、Slack、GitHub、Zoom、Zendesk…など、このページを見られる方は社内で思い当たるものがあるかと思います。

上記のような複数システムを使用する場合、それぞれでIDとパスワードの組み合わせによってユーザー認証を行っていますが、パスワードの管理が煩雑になり推測されやすい危険なパスワードの設定、同じパスワードを使いまわすケースも生じてしまいます。

SSO（シングルサインオン）の仕組み

SSOの認証方式には主に次の4つの方式があります。

1. 代理認証方式

ユーザーのデバイス（クライアントPC）に導入した専用のエージェントソフトウェアが、代理でIDとパスワードを入力し認証を行う方式です。

クライアントPCに常駐したエージェントがアプリケーションのログイン画面が起動するのを検知すると、自動的にIDとパスワードを入力する仕組みになっています。

メリット

• Webアプリケーション側やクラウドサービス側での追加改修が必要ないので古いサービスなどでも導入できる
• クライアント/サーバ形式のローカルアプリケーションにも対応できる

デメリット

クライアント側にエージェントソフトをインストールする必要がある

2. エージェント方式

Webサーバやアプリケーションに専用のエージェントソフトウェアを導入し認証を行う方式です。

エージェントはアプリケーションへのアクセスを受け、ユーザーが認証済みかどうか、アクセス権限があるかどうかなどを認証サーバーに対して確認を行います。

メリット

• ネットワーク構成を変更せずに導入できる

• ユーザー認証を代行できるため、アプリケーションでの個別のパスワード管理が不要となる

デメリット

• Webサーバーやアプリケーションサーバーへのエージェントのインストールやアップデートが必要なこと
• SSO対象のサーバーがエージェントに対応するソフトウェアを入れておく必要があるので、Webアプリケーション自体がエージェントに対応していない場合は利用できない

3.リバースプロキシ方式

リバースプロキシがユーザー（のデバイス）とWebサービスの間を中継し認証を行う方式です。

リバースプロキシと呼ばれる中継サーバで認証を行い、リバースプロキシ経由で対象システムにアクセスすることでSSOを実現しています。

エージェント方式で組み込んでいたエージェントの機能をリバースプロキシサーバに集約するイメージです。

メリット

• SSO対象システムにはエージェントなどを導入する必要がないため、既存システムへの影響なく事前検証ができるなど先ほどのエージェント方式よりもリリースまでの工数を短縮できます。

デメリット

• アクセスが全てリバースプロキシサーバ経由になることで、リバースプロキシサーバがボトルネックになるケースがある

• 直接Webシステムにアクセスさせずリバースプロキシ経由にするよう、ネットワークの設計を考慮する必要がある

4.SAML認証方式（フェデレーション方式）

IDaaSが持つクラウドサービス間のID連携の仕組みは、フェデレーションと呼ばれます。

このフェデレーションの認証プロトコルにはSAML、OpenID Connect、Oauthなどありますが、よく利用されるSAML方式について説明します。

SAML認証方式とはSecurity Assertion Markup Languageの略で、ユーザーとサービスプロバイダー（以降、SP）、IDプロバイダー（以降、IDP）の3者で認証を行う方式です。

ID管理や認証を行うIDプロバイダ（IDaaSなど）がクラウドサービスのようなサービスプロバイダからの認証要求を受けて、IDプロバイダ側が持っている認証情報を提供します。

通常はサービスごとに認証が必要になりますが、この方式であればIDプロバイダの認証が完了していればほかのサービスについては認証作業が不要になります。

また認証情報を共有するので、サービスごとにパスワードなどを設定する必要もなくなります。

この認証方式を利用する場合は、IDプロバイダとサービスプロバイダの双方がSAML認証に対応しているか確認する必要があります。

①SP initiated SSO

SPが起点となって認証を行います。

ユーザーが、SPのログイン画面にてIDやパスワードを入力すると、IDPへSAML認証要求がリダイレクトされます。

ユーザー認証に成功すると、IDPがSPへSAML認証応答をリダイレクトすることで、ユーザーのSPへのログインが成功します。

 ②IDP initiated SSO

IDPが起点となって認証を行います。

ユーザーが、IDPの認証画面にてIDやパスワードを入力し、ログインに成功すると、利用可能なアプリケーションの一覧画面に遷移します。

ユーザーは表示された一覧画面から、利用したいアプリケーションを選択するだけで、再度IDやパスワードを入力することなく、アプリケーションにアクセスできます。

メリット

• 複数クラウドサービスのSSOが手軽にできる

• 海外でもメジャーなクラウドサービス（GitHubやGWSなど）は対応していることが多い

デメリット

• WEBサービス側がSAMLに対応している必要があるので使えるクラウドサービスが限られている
• 既存のシステムを対応させる場合は、Webサーバの改修が必要

まとめ：SSOはユーザー＆企業どちらにとってもメリット高いので人数が多いなら導入すべき

いかがだったでしょうか。

SSOは導入したい環境の調査や導入コストはかかりますが、ユーザーによるID管理工数の削減と、1つの情報を厳格に管理すれば良いので煩雑にならずセキュリティ向上に繋げることができます。

よくニュースで情報漏洩や流出などインシデント問題が流れますが、それらはハッカーの能力が高いこともありますが、そもそも社内の情報管理体制が問題の部分が多いのではと思います。

会社のシステムを支えるIT部門として、セキュリティ対策についてもっと意識を高く持っていたいですね（戒め）

最後までご精読ありがとうございました！