ID 管理と SSO

会社で使う SaaS が増えると、サービスごとにアカウントとパスワードができます。社員はパスワードを使い回すようになり、情シスは入社・異動・退職のたびに何十ものサービスを手で直すことになります。退職者のアカウントの消し忘れは、情報漏えいの原因にもなります。

IdP と SSO は、この問題を「ログインを1か所に集める」ことで解く仕組みで、情シスのアカウント管理の中心です。

IdP（Identity Provider）は、社員のアカウントを1か所に集めて、ログイン（認証）を代わりに行う仕組みです。Okta・Microsoft Entra ID・Google Workspace などが代表です。各 SaaS（SP：Service Provider）は自分でパスワードを持たず、「この人は本人です」という IdP からの証明を信じてログインさせます。これが SSO（シングルサインオン）です。

よい点は、パスワードが1つで済む、MFA や条件付きアクセスを IdP で一括でかけられる、退職時に IdP で止めればつながっている SaaS すべてに入れなくなる、ログインの記録が1か所に集まる、ことです。

認証の種類と強化（SRE の解説）

下の「ブラウザで試す」の図は、SAML（SSO でよく使われる、署名付きの XML で「ログインした」と伝える方式）で、社員が SaaS（Slack）にログインする流れです。SaaS を開く → IdP へリダイレクト → IdP でログイン（MFA）→ 署名付きの証明（アサーション）→ SaaS が署名を確かめてログイン、と進みます。SaaS と IdP は直接通信せず、ブラウザが証明を運んでいる点と、MFA や端末の確認が IdP の手順に集まっている点に注目してください。

SSO の設定では、SaaS が対応している方式に合わせて SAML か OIDC を選びます。どちらも、IdP が「この人は本人です」という証明を SaaS に渡す点は同じで、形式と生まれた背景が違います。

情シスにとってはどちらも「IdP と SaaS の間で信頼を結ぶ設定」で、SaaS が対応している方を使えば大丈夫です。SAML の署名の証明書には期限があり、切れるとその SaaS にだれもログインできなくなるので、期限を管理します。

SSO は、つないだだけでは抜け道が残ります。SaaS 側のパスワードでのログインを止めて SSO を強制し、SSO できない SaaS は別の方法で管理の中に入れます。

• 上位のプランでしか SSO できない：人数・扱うデータの重要さで、上位プランの費用を払う価値があるか判断します。払わないなら次の方法で補います。
• パスワード保管型の SSO：IdP やパスワード管理ツールがパスワードを代わりに入力する方式。退職時にツールで止められますが、SaaS 側のアカウントは残るので削除の手順が必要です。
• 台帳とチェックリスト：SSO 外の SaaS を一覧にし、退職手続きと棚卸しの対象に入れます。

SSO を入れたら、SaaS 側の「パスワードでのログイン」を止めて SSO を強制します（抜け道を残さない）。ただし IdP が止まると全員入れなくなるので、SaaS ごとに SSO を通らない非常用の管理者アカウントを1つ残し、強いパスワードと MFA で金庫のように保管します。

多要素認証（MFA）は、知っているもの（パスワード）・持っているもの（スマホ・セキュリティキー）・本人そのもの（指紋・顔）のうち、2つ以上を組み合わせて確かめることです。パスワードは漏れる前提で考え、MFA を全員に必須にします。ただし MFA にも強さの違いがあります。

FIDO2 がフィッシングに強い理由：認証のときに、ブラウザが「今つないでいるサイトのドメイン」を一緒に確かめるからです。偽サイト（例：login-micros0ft.com）では本物のドメイン用の鍵が使われず、利用者がだまされても認証が成り立ちません。コードを入力する方式は、偽サイトが本物にそのままコードを中継する攻撃（AiTM）で突破されます。管理者や経理など狙われやすい人から FIDO2 にします。

IdP で「誰が・どの端末で・どこから・どのアプリに」の条件を見て、許可・MFA を求める・拒否を決めます（Entra ID の条件付きアクセス、Okta の認証ポリシーなど）。

落とし穴：新しいポリシーはまずレポートだけのモードで影響を確かめてから有効にします。いきなり有効にして、管理者を含めて全員が締め出されることがあります。非常用の管理者アカウントはポリシーから外し、使われたら通知が来るようにしておきます。

プロビジョニングは、アカウントを作る・変える・止めることを、各 SaaS に自動で反映することです。その標準の手順が SCIM（System for Cross-domain Identity Management）で、IdP が SaaS の SCIM の API（/Users・/Groups）を呼んで、ユーザーの作成・属性の変更・無効化を行います。

SCIM に対応していない SaaS

• SSO だけ対応：初回ログイン時にアカウントを作る方式（JIT プロビジョニング）。ただし退職しても SaaS 側のアカウントは消えないので、停止の手順が要ります。
• 独自の API がある：スクリプトやノーコードの道具で、IdP の変更をきっかけに作成・停止します。
• 何もない：管理画面で手作業。退職のチェックリストと定期的な棚卸しに必ず入れます。

入社・異動・退職の手続き

アカウントのもとになる情報（正）は、人事システムの社員データです。人事の登録・異動・退職を、IdP を通して各 SaaS に一方通行で流します。

いちばん元になる情報（正）は人事システムの社員データです。流れは「人事システム → IdP → 各 SaaS」の一方通行にします。

• 入社：人事に登録されると、入社日の前に IdP にアカウントができ、部署のグループに入り、そのグループに割り当てた SaaS にアカウントが作られる。
• 異動：人事で部署が変わると IdP のグループが変わり、前の部署の SaaS の権限が外れ、新しい部署のものが付く。
• 退職：退職日に IdP のアカウントが止まり、SCIM で各 SaaS のアカウントも無効になる。

人事システムと IdP の連携は、IdP 側に対応する接続（Workday など）があるか、なければ CSV や API で取り込みます。注意：人事データの入力ミス（部署名の表記ゆれ・退職日の入れ忘れ）がそのまま全 SaaS に広がるので、人事と一緒に入力のルールを決めます。

「Google でログイン」「Microsoft アカウントで連携」のボタンで、社員が外部のアプリにメールやドライブを読む権限を渡せることがあります。これが OAuth の同意です。一度同意すると、アプリはパスワードを知らなくても、アクセストークンでデータを読み続けられます。

偽のアプリに同意させてデータを盗む攻撃（同意フィッシング）もあります。パスワードも MFA も使わないので、MFA だけでは防げません。

認証と状態管理（Cookie・セッション・トークン・OAuth）（SRE の解説）