「使っているクラウドサービスを数えたら、十五個ありました。それぞれにIDとパスワードがあって、入退社のたびに全部を手で足したり消したりしています。この前、退職した人のアカウントが二つ残っているのが見つかって……。もう、誰がどこに入れるのか把握しきれていません」——先日、社員四十名ほどの会社の情シス兼任担当者から受けた相談です。
会計、勤怠、チャット、名刺管理、営業支援、経費精算——中小企業でも、業務ごとにSaaSを使うのが当たり前になりました。便利な反面、それぞれに別々のID・パスワードがぶら下がり、入退社のたびに一つずつ手で足し引きする運用が限界を迎えています。パスワードの使い回し、退職者アカウントの消し忘れ、把握不能なアクセス権——これらは静かに、しかし確実に情報漏洩のリスクを膨らませます。本記事では、Google WorkspaceをID基盤（IdP）にしたシングルサインオン（SSO）で、ログイン管理を一元化する進め方を整理します。
「SaaSごとにID」がなぜ危険なのか
問題の根は、IDがサービスごとにバラバラに存在していることです。ここから複数のリスクが生まれます。
パスワードの使い回し。サービスが増えるほど、社員は覚えきれず同じパスワードを使い回します。一つが漏れれば芋づる式に破られ、これはアカウント乗っ取りの主因です（パスキー・2段階認証の記事で扱ったとおりです）。
退職者の消し忘れ。入社時は急いで全部作りますが、退職時は「メインのメールは止めたが、あのSaaSは残っていた」が起きます。止め忘れたアカウントは、退職者が外から入れる裏口になります。
アクセスの不可視化。誰がどのサービスにどの権限で入れるのか、一覧で把握できない。棚卸ししようにも、管理画面が十五個に散らばっていては現実的に無理です。
SSOは、この「バラバラなID」を一つのID基盤に束ねることで、これらを根本から解きます。
SSO/IdPとは — 入口を一つにするという考え方
IdP（Identity Provider）とは、社員の身元（ID）を一元的に管理し、各サービスへの「この人は本人です」という保証を発行する基盤です。SSO（シングルサインオン）は、そのIdPに一度ログインすれば、連携した各SaaSへ個別のパスワード入力なしで入れる仕組みです。技術的にはSAMLやOIDCといった標準規格でSaaSとIdPを連携させます。
中小企業にとって現実的なのは、すでに持っているGoogle WorkspaceをIdPとして使うことです。多くのSaaSは「Googleでログイン」やSAML連携に対応しており、Google Workspaceのアカウントを入口にすれば、新たにID基盤を買わずに一元化を始められます。社員はGoogleにログインすれば各サービスに入れ、管理者はGoogleアカウントを一つ止めれば連携先すべてから締め出せる——入退社の手間と消し忘れが、同時に消えます。入社側の標準化はアカウント発行・オンボーディングの記事、退職側は退職時アカウント処理の記事と地続きです。
| SaaSごとに個別ID | Google IdP＋SSO | |
|---|---|---|
| ログイン | サービスごとにパスワード | 一度ログインすれば各サービスへ |
| 退職処理 | サービスごとに手で削除 | Googleを止めれば連携先も遮断 |
| 監査 | 管理画面が散在し把握不能 | 入口が一つで棚卸しできる |
| 認証強化 | サービスごとにバラバラ | 2段階認証を入口で一律に効かせられる |
SSOだけでなく「棚卸しとプロビジョニング」までが受託の勘所
SSOを「ログインが楽になる仕組み」とだけ捉えると、片手落ちになります。本当の価値は、アカウントのライフサイクル全体を一元管理できることにあります。
まず前提として、現状のSaaSとアカウントの棚卸しが要ります。何を使い、誰が入れ、どれが野良（管理外）契約か——これを可視化しないとSSOの設計は始まりません。次に、SSOと自動プロビジョニングを組み合わせると、Google側でユーザーを追加・停止した瞬間に、連携先のアカウントも自動で作成・停止されます。ここまで来て初めて、「入社したら使え、退職したら一斉に消える」が実現します。加えて、入口に2段階認証やアクセス制御（コンテキストアウェアアクセスの記事）を効かせれば、全SaaSの認証強度を一度に底上げできます。受託では、この「棚卸し→SSO→プロビジョニング→認証強化」を、業務を止めずに段階導入するのが勘所です。
事例: 十五個のSaaSを「Googleログインひとつ」に束ねた会社
具体例を挙げます。冒頭のように十五を超えるSaaSを個別IDで運用し、退職者アカウントの残存が見つかった会社（社名は伏せます）から相談を受けました。まず全SaaSとアカウントを棚卸ししたところ、契約したまま誰も使っていないサービスや、退職者のアカウントが複数見つかりました。
そこで、利用頻度と対応状況からSAML/Google連携できるサービスを優先し、主要な十サービスをGoogle WorkspaceのSSOに寄せました。可能なものは自動プロビジョニングを設定し、Googleアカウントの停止で連携先も止まるようにしました。あわせて入口に2段階認証を必須化。結果、社員のログインは「Googleに入るだけ」に簡素化され、退職処理は一か所で完結し、消し忘れがなくなりました。効いたのは連携そのものより、先に棚卸しをして「何を束ねるべきか」を決めたことでした。
いきなり全SaaSを連携せず、「棚卸しと主要3サービス」から
順番の注意です。十五個すべてを一気にSSO連携しようとすると、規格に対応していないサービスや例外運用でつまずき、頓挫します。まずやるべきはSaaSとアカウントの棚卸し、そして利用頻度が高くSAML/Google連携に対応した主要な数サービスから寄せることです。ここで「入口を一つにする」効果を体感してから、対応可能なサービスを順次足し、自動プロビジョニングや認証強化を重ねていく。この順番なら、大きな投資や現場の混乱なしに、ログイン管理を安全に一元化できます。
SaaSが増えすぎて管理しきれない、退職者アカウントの消し忘れが不安、パスワードの使い回しをなくしたい——そうしたお悩みがあれば、グリームハブのIT・システム開発の無料相談からお気軽にご相談ください。SaaSの棚卸しから、Google WorkspaceをIdPにしたSSO設計、自動プロビジョニング、認証強化まで、無理のない範囲で一元化をご一緒します。
