Site cover image

Site icon imageおかしんワークス

ビジネステクノロジーエンジニア @okash1n のブログです
2020-12-25
SSOSAMLBusiness Technology

なぜWebサービスの選定においてSAML/SSOが重要なのか

この記事は corp-engr 情シスSlack（コーポレートエンジニア x 情シス）Advent Calendar 2020 #3 の最終日（25日目）です。

今年情シスSlackは3本のアドベントカレンダーが実施されておりますので、是非3本とも覗いていってください！

また、情シスSlackはこちらの参加リンクから参加可能です

目次

目次TL;DRこの記事の目的ビジネス環境の変化とWebサービスの必要性Webサービスの利用が拡大すると起こること1. 管理工数の増大2. セキュリティの重要性や統制の難度が上がる（特にID周り）3. サービス利用者側のパスワード管理が大変になる閑話「Webサービスを利用していなかった頃はどうだったのか」SAML/SSOの機能が何故必要なのか何故ログイン方法をSAML/SSOに限定する機能が必要なのか1. 管理工数の削減2. セキュリティ面3. サービス利用者のパスワード管理SAML/SSOの機能の為にEnterpriseプランを契約すべきか（意思決定者向け）企業向けのWebサービス提供事業者様へまとめ

TL;DR

この記事の目的

どうも、 おかしん@okash1n です。メリークリスマス。色々あった2020年も終わりを迎えようとしていますね。

さて、この記事ではタイトルの通りWebサービスを選定する際にそのWebサービスが「SAML/SSOの機能を有していること」が重要である理由を解説していきたいと思います。

また、単にSAML/SSO（シングルサインオン）出来るだけではなく、「ログイン方法をSAML/SSOに限定する機能を有していること」が重要である理由についても解説します。

SAML/SSOがついたプランでWebサービスを契約したい時に、意思決定者に対してSAML/SSOの必要性を説明する際の資料として使ってもらえれば幸いで御座います。

ビジネス環境の変化とWebサービスの必要性

さて、SSOの話に進む前に少しだけWebサービスの利用がこれほどまでに進んだ理由についておさらいします。

私はこれだけWebサービスが広く使われるようになった理由は「速さ」にあると思ってます。

まず、Webサービスを利用することで組織が獲得したい機能を素早く調達できます。メールやディレクトリ、Web会議、共有カレンダー、共有ストレージ、といった機能をGoogle WorkspaceやMicrosoft 365といったサービスを一切使わずに組織に取り入れるには非常に時間とコストがかかります。

Image in a image block

2006年の Google Apps のローンチやその後のiPhoneの台頭によって、ジワジワと企業のWebサービス利用は拡大してきました。複数の遠隔地から従業員や顧客、パートナーを含む社内および社外のステークホルダーが、ビジネスリソースに対して素早くアクセス出来ることは非常に重要です。競合企業より情報を素早くデリバリー出来ることは競争力を高めるどころか勝敗を分ける直接的要因と言っても過言ではありません。

A社が見積り・申込書を郵送で送り、署名・捺印して返送している間にB社はWeb申し込みだけで簡単に顧客を増やします。ビジネスにおけるあらゆるプロセスでこの差が生まれるので勝負になりません。

そして新型コロナウイルスの感染拡大に伴ってこの流れは更に加速するでしょう。腰の重い政府・官公庁ですらWebサービス利用の大幅な拡大を始めています。

ITサービスを上手く活用できないと競合他社との勝負の土俵にすら立てない時代です。

Webサービスの利用が拡大すると起こること

1. 管理工数の増大

企業で複数のWebサービスを利用するようになると以下のような管理工数が芋づる式に増えていきます。

  • 入退社に伴うアカウントの作成・削除
  • 部署やロールに応じた権限設定
    • 部署異動などによって定期的に発生する

IT部門が、これらの作業だけで月に2〜3人日くらい取られてしまうことも稀ではありません。管理工数の増大は人件費の増大に直結し、本来IT部門が取り組むべきシステムの全体設計やアーキテクトとしての役割、様々な自動化推進、ビジネスを加速させる為のIT基盤・セキュリティ整備などに費やす時間が目減りします。

前項で「ITサービスを上手く活用できないと競合他社との勝負の土俵にすら立てない時代」と書きましたが、これを担うIT部門が機能しなくなるとビジネスは負けます。

2. セキュリティの重要性や統制の難度が上がる（特にID周り）

大抵のWebサービスはインターネットさえ繋がっていれば世界中どこからでもアクセスが可能です。それは強みでもあるのですが、ビジネスリソースの漏洩リスクも高くなります。

ビジネスリソースの漏洩は企業や取引先に賠償やブランド失墜など多大なるダメージを与える可能性が高い為、ビジネスリソースの漏洩リスクが高まると各企業は取引先に対してセキュリティチェックを行ったり、ISMSの認証規格の取得をしたり、セキュリティルールの整備をしたりといった行動を取るようになります。

基本的にはWebサービスを利用するとセキュリティレベルはそのサービス側に依存します。ログイン一つ取っても二要素認証を有効化出来るかどうかや、パスワードの要件など自社のセキュリティルールに合わせられるかどうか、そのコントロールが難しくなります。

セキュリティの重要性が高まるのに、統制を取るのは難しくなるのです。

3. サービス利用者側のパスワード管理が大変になる

IDおよびPasswordが漏洩すると、Webサービス上にある情報が全て漏洩してしまうことになり、複数のWebサービスでID/Passwordを使いまわしていると、一つのサービスでの漏洩が利用する全てのWebサービス上の情報の漏洩に繋がります。よって利用しているあらゆるWebサービスにおいて別のパスワードを設定する必要があるのですが、利用するWebサービスの数が多くなると管理が大変になります。

パスワード忘れなどによる管理者へのアカウント復旧依頼なども増えるでしょう。

閑話「Webサービスを利用していなかった頃はどうだったのか」

一昔前の社内情報システムはいわゆる「イントラネット」の形でWindows ServerやActive Directory（LDAP）を用いて統合管理されているケースが多かったです。管理者はADのユーザーを作成し、ADのOUやポリシーを設定するだけで、社内アプリケーション群へのアクセス制御が可能でした。ユーザー側はWindowsマシンにログインする際のユーザーIDとパスワードさえ覚えていれば、様々な社内リソースにアクセス出来ていました。また、それらにアクセスする為に会社に行き、会社のネットワークに接続する必要があった為、ビジネスリソースの漏洩リスクは比較的低かったのです。

SAML/SSOの機能が何故必要なのか

結論から言うとWebサービスがSAML/SSOの機能を有しており、SAML/SSOでのログインに限定出来ると、下図のようにIDやパスワードの管理、IDに対するセキュリティ設定（条件付きアクセスなど）を全てIdP（Identity Provider）に寄せることが出来る為、前項で挙げた1〜3の課題をほぼ解決することが出来ます。

Image in a image block

何故ログイン方法をSAML/SSOに限定する機能が必要なのか

世の中にはSAML/SSOの機能を有しているものの、残念ながらログイン方法をSAML/SSOに限定することが出来ないサービスが多く存在しています。

こういったサービスはせっかくSAML/SSOを有効化しても、依然としてID/Passwordでのログイン方法が残されてしまう為、前項で説明したような「IdPが有する豊富なID管理・IDセキュリティ機能」を迂回されてしまうので、IdPによる統制が効いているとは言えなくなり、セキュリティレベルは各Webサービスのレベルに下がってしまいます。

SAML/SSOの機能を有しているだけでは駄目で、「ログイン方法をSAML/SSOに限定出来る」ことが必須要件なのです。

さて、SAML/SSOを必須にする機能を持っていると、何故前項で挙げた1〜3の課題を解決できるのかもう少し詳しくみていきます

1. 管理工数の削減

様々なWebサービスを利用していると、「サービス数」x「ユーザー数」x 管理対象アカウント数はどんどん増えていきます。Webサービスの場合、ログインさえ出来てしまえば保存されているデータはどこからでもアクセス出来てしまう為、データを守る為にはアカウント管理が重要になります。

アカウント管理においてはアカウントの発行・削除、棚卸し（定期的なチェック）などが必要となりますが、仮に300人の企業で30個のWebサービスを利用していると、管理対象アカウントは9,000になります。ある程度自動化していたとしても30のサービス全てについて、退職時のアカウント削除を行ったり、定期的に不要なユーザーがいないかどうかのチェックを行うのはとても大変です。

Google WorkspaceやMicrosoft 365を利用されている企業では、少なくとも退職時にそれらのアカウントを削除する業務プロセスは情シスやコーポレート部門内で整備されているかと思います。一方で各部門におけるITツールのアカウント削除まではしっかり行えてるか自信が無い企業も多く存在するのでは無いでしょうか？メールアドレスが無効化されていても、登録済みのWebサービスに対しては「メールアドレス」と「パスワード」のセットを退職者が覚えていれば個人のPCなどから簡単にアクセスすることが可能です。

SAML/SSOにログインを限定することができていれば、情シスやコーポレート部門でIdP（Identity Provider）のアカウントを削除してしまえば、接続しているアプリケーション全てに対して完全にログインをブロックすることが出来ます。一人の退職者に対してたった一つの作業を行うのみで、退職者が退職後の社内リソースへのアクセスすることを防ぐことが出来るのです。

これは退職対応のオペレーションが格段に向上することを意味します。退職対応を行う部門は、当然アカウント削除は最終出社日の退社後に行うことになりますが、作業を一瞬で終えることが出来るのであれば負担も軽くなり、即時対応もしやすくなります。

棚卸しもIdPのアカウントに対して行うだけで、完全とは言えないまでもリスクを大幅に減らすことが出来ます。

2. セキュリティ面

世の中には様々なWebサービスが溢れていますが、その全てのサービスのIDに関するセキュリティが同じレベルに達しているとは限りません。二要素認証の機能が無いかもしれませんし、不審なログイン（普段と違うIPアドレスからのアクセスなど）を検知する機能がついているWebサービスはほとんど無いでしょう。

一方でSSOを行う際には必ずIdP（Identity Provider）が必要になります。

Image in a image block

IdPは当然ながらID管理に特化したシステムであり、IdPをクラウドサービスとして提供するIDaaSのうち主要なもの（Azure AD, Okta, OneLogin, Google Cloud Identity, etc）は当然ながら個々のWebサービス（SP）よりIDのセキュリティは充実しています。

WebサービスにSAML/SSOの機能がついていると、システム管理者は全てのWebサービスに対して一律にIdPが有する豊富なID管理・IDセキュリティ機能を適用することが出来るのです。

またWebサービスはWebブラウザやスマートフォンアプリなどからアクセスすることになりますが、主要なIDaaSではSSO先のアプリケーションにどういったブラウザやデバイスを用いてどこからアクセスしたのかを簡単に確認することが出来ます。

Image in a image block

例えば何らかのデバイスやブラウザ、特定のバージョンのアプリケーションなどに外部に情報を送信するような脆弱性やマルウェア混入が確認されニュースになったとしましょう。当然社内で影響があるかどうかを確認したくなるかと思いますが、特にアーリーなWebサービスにおいては、管理者がユーザーの利用デバイスやブラウザ、アクセス元などを簡単に確認出来たりフィルタリングできる機能を備えているWebサービスは稀です。Salesforceの様にある程度成熟したサービスでは整備されている場合もありますが、スタートアップなどが作っているWebサービスにおいて、そこまでの管理向け機能を実装する開発リソースを確保することは困難でしょう。

社内サービスにIDaaSを用いたSSOを必須とする環境を構築できていれば、確認を簡単にするだけでなく、条件付きアクセスといった機能によって管理者側で社内の全てのサービスについて特定のブラウザやデバイスからのアクセスを弾くといったことが容易になるのです。

逆に言えばSSOを構築出来ていなければ、社内で利用しているWebサービス全てについて一律に上記のようなセキュリティ対策をすることは、システム部門のリソースの関係上かなり難しいということになります。

3. サービス利用者のパスワード管理

これは言うまでも無いことですが、Webサービスを複数利用するうえで、ID/Passwordのペアを使い回さないことはセキュリティ上非常に重要です。パスワード管理ツールを導入することで、使いまわしを減らすことは可能ですが、誰もがパスワードの使いまわしをしていないことを担保し続けることは非常に困難です。

社内で利用するWebサービスについて、SAML/SSOでのログインに限定するようにしていれば、ID/Passwordは一つで済みますし、確実にその状態を従業員に強制することが出来ます。人のモラルやリテラシーに頼ったルールや仕組みではガバナンスが効いているとは言えません。システムを利用するのであれば専用のシステムを用いて統制を取りましょう。

SAML/SSOの機能の為にEnterpriseプランを契約すべきか（意思決定者向け）

基本的には値が張ってもSAML/SSOを使えるプランで契約すべきです。前述した「1. 管理工数の削減」や「2. セキュリティ面」はコストをかけてでも実現する価値が高いです。ビジネスをより加速する為のWebサービス利用を、よりスピーディによりセキュアに推進することが、さらなるビジネスの拡大を生みます。そこで生み出される価値に比べれば一人あたりのサービス利用料の増加は大したコストではありません。

SSOを強制出来ないWebサービスを複数導入し、その全てに対してガバナンスを効かせようとすると、膨大な棚卸し工数や管理工数がかかり、情報システム部門の人件費も数人分増えます。仮に人を増やさないとすれば情報システム部門が真に発揮すべき価値は発揮できないと思ってください。人件費に比べればプランのアップグレード費用は微々たるものです。

企業向けのWebサービス提供事業者様へ

Webサービスには「SAML/SSOの機能」および「ログイン方法をSAML/SSOに限定出来る機能」をつけてください。そして可能であれば「管理者だけが使える一時的にSSOを迂回出来るURLを発行する機能、およびそのURLを利用する際にはメールなどによる二要素認証が出来る機能」をつけて頂きたいです（設定ミスにより誰もログイン出来ない状態になった際の救済措置として）

Webサービスを選定・導入する立場にある情報システム部門やセキュリティ部門の人間は、基本的には個々のWebサービスが実装しているID管理・IDセキュリティ機能をIdP以上には信用していません。

他要素認証やFIDO、条件付きアクセスなどを個別に実装しなくても構いません。枯れた技術であるSAML/SSOを実装し、必須化できるようにして頂きさえすれば良いのです。それだけで情報システムやセキュリティの人間はそのサービスのセキュリティレベルを競合サービスより高く見積もります。

そして、前項からは矛盾するのですが、出来れば全てのプランでSAML/SSOの機能をつけて頂きたいです。今までは付加価値的な機能であったかもしれませんが、これからの時代は必須機能です。Webサービスとして必須の機能なのに追加料金を払わないといけないのはおかしな話です。

情報システムやセキュリティの人間は、全てのプランでSAML/SSOをつけているWebサービスを見ると、「あ、この会社は分かってるな」と思います。よほどの機能差が無ければそちらのサービスを選びます。

そもそもtoB向けのWebサービスというのは組織内で広く使ってもらって（出来れば全社で）、業務プロセスに深く組み込んで貰えれば勝ちなのです。目先の契約の取りやすさも確かに大事ですが、長期的に見ればChurnを減らし、利用率を高め、外部環境変化（セキュリティの認証規格取得や上場、企業統合など）の発生時にも使い続けてもらえることが重要です。SAML/SSOを必須化して使っているサービスというのは外部環境変化にも強いです。システム管理者からするとそういったサービスこそ社内のコアサービスに据えたくなるのです。

今はまだSAML/SSO機能がEnterpriseプランの目玉になっている料金設定のサービスが多いですが、これからの時代はEnterpriseプランの目玉は自動化や外部サービスとのインテグレーションや、データを用いた分析・BI的機能をメインに据えていくのが主流になってくると考えています。スタートアップが作っているサービスでも比較的初期からEnterpriseプランを用意しているのを見かけるのですが、インテグレーションや分析系の機能を実装できるまではSAML/SSOを含むコア機能に絞ったスタンダードプランだけで良いと思います。Enterpriseクラスの企業はSAML/SSO必須化の機能がついていれば契約してもらえる可能性は高いです。何故ならIDセキュリティ面を自社でコントロール出来るので、スタートアップが作るサービスに対しても導入ハードルが下がるからです。

クラウドネイティブな時代に向けて、SAML/SSOを全てのプランに付けることによって競合他社から一歩リードしましょう。

まとめ

以上です。皆様良いお年を。

SSOSAMLBusiness Technology