レッスン2：アカウント・アクセス管理の運用

このレッスンで学ぶこと

IdP（Entra ID／Okta／Google Workspace）の選定軸と冗長化の考え方を語れる
SCIM プロビジョニングの仕組みと SaaS への一括反映の設計を理解できる
オンボーディング（入社日）とオフボーディング（退職日）の実務手順を組める
退職者アカウントを即時無効化する運用を設計できる
半期に 1 回の権限棚卸しサイクルを回せる

前レッスンで情シスの 3 役割を整理しました。本レッスンでは、その 3 役割すべての起点になる「アカウント運用」に踏み込みます。中核メッセージ 2「アカウント運用が情シスの生命線——入社と退社の 2 点で 8 割が決まる」の実装編です。

なぜアカウント運用が情シスの生命線か

情シスの業務のなかで、アカウント運用は次の 3 つの意味で決定的です。

セキュリティの起点：情報漏洩・不正アクセスの多くが、アカウント管理の不備から発生する
業務効率の起点：入社初日にアカウントが動かないと、新入社員の初日は空白になる
監査対応の起点：年次監査で最も指摘を受けやすい領域が「退職者アカウントの残存」

これらは技術ではなく運用の問題であり、情シス担当者の日常業務の質で決まります。

IdP の選定と冗長化

現代の企業 IT では、複数の SaaS（Microsoft 365、Google Workspace、Slack、Zoom、Salesforce、HubSpot、GitHub、Notion など）を使うのが普通です。それぞれに個別のアカウントを作ると、退職時に全部消すのに漏れが必ず出ます。ここで登場するのが IdP（Identity Provider、アイデンティティ・プロバイダー）です。

flowchart LR
  A[IdP<br/>ユーザーの中央管理] --> B[SaaS 1<br/>Microsoft 365]
  A --> C[SaaS 2<br/>Slack]
  A --> D[SaaS 3<br/>Salesforce]
  A --> E[SaaS N<br/>その他]

IdP に一元的にユーザーを登録し、各 SaaS へは SSO（Single Sign-On）で連携する形にすると、次の効果が得られます。

従業員はパスワードを 1 つだけ覚えればよい
IdP でアカウントを無効化すると全 SaaS で一斉に無効になる
権限変更も IdP 側で一括管理できる

主要 IdP の選定軸

日本の中堅企業でよく使われる IdP は 3 つです。

IdP	特徴	適したシーン
Microsoft Entra ID（旧 Azure AD）	Microsoft 365 とのネイティブ統合、Windows 環境	Microsoft 365 中心の企業
Okta	独立系ベンダー、対応 SaaS の多さ	マルチクラウド、Best of Breed 派
Google Workspace	Google 系サービスと統合、UI シンプル	Google Workspace 中心の企業

Entra ID は 2023 年 7 月に Azure AD から改称されました。Okta は 2009 年設立、Auth0 を 2021 年 5 月に買収し、開発者向け機能を拡充しています。

冗長化の考え方

IdP は「全 SaaS の入口」になるため、IdP 自体が止まると業務全体が止まります。冗長化の観点は次の 3 つです。

サービス側の冗長性：IdP ベンダー自体の SLA と稼働実績（Entra ID・Okta・Google Workspace はいずれも 99.9% 以上）
バックドア認証：IdP 障害時に管理者だけ入れる緊急用ルート（Break Glass Account）
監査ログのバックアップ：IdP 側のログ以外に自社側でもコピー保存

⚠️ 注意 「バックドア認証」は名前が悪いですが、正当な運用設計の一部です。IdP 全体が数日間停止した場合に、社内システムを緊急復旧するために管理者だけが使える別ルートで、パスワードは金庫で厳重に管理します。日常的に使うものではありません。

SCIM プロビジョニング設計

IdP でユーザーを作ったら、各 SaaS 側にもユーザー情報を反映する必要があります。手動で 20〜30 の SaaS に個別に登録するのは非現実的です。ここで使うのが SCIM（System for Cross-domain Identity Management）です。

SCIM の仕組み

SCIM は 2015 年 9 月に IETF で標準化された（RFC 7643/7644）プロトコルで、IdP から SaaS へユーザー情報を自動連携します。

プロビジョニング：IdP でユーザーを作ると、対応 SaaS にも自動でアカウント作成
同期：IdP で属性（氏名・部署・役職）を変更すると、SaaS にも自動反映
デプロビジョニング：IdP でユーザーを無効化すると、SaaS でも自動無効化

SCIM 対応 SaaS の確認

すべての SaaS が SCIM に対応しているわけではありません。導入時に確認します。

フル SCIM 対応：Slack、Zoom、Notion、GitHub Enterprise、Salesforce など主要 SaaS
部分対応：一部の SaaS はプロビジョニングのみ・デプロビジョニングのみ
未対応：小規模 SaaS や日本ローカル SaaS は SCIM 未対応が多い

SCIM 未対応の SaaS は、退職時に手動で無効化する運用が残ります。この漏れが情報漏洩の温床になります。

オンボーディング／オフボーディングの実務手順

アカウント運用の 8 割は、入社時と退職時に集中します。それぞれの実務手順を型化します。

オンボーディング（入社日）

前日または当日朝までに完了させておきたい 8 項目です。

IdP でユーザー作成（属性：氏名・メール・部署・役職）
部署に応じた SaaS グループへ追加（Salesforce、Slack のチャンネル、GitHub の Team など）
Microsoft 365／Google Workspace のライセンス割当
PC キッティング（レッスン 4 で詳述）
Wi-Fi 接続情報の準備
初期パスワードとパスキー登録手順の準備
業務マニュアル・IT ガイドラインへのアクセス
初日オリエンテーション枠の確保（30〜60 分）

漏れがあると新入社員の初日が空白になり、印象と生産性の両面で損失が出ます。

オフボーディング（退職日）

退職日当日または翌日までに完了させたい 6 項目です。

IdP でユーザー無効化（削除ではなく無効化：ログ保存のため）
Microsoft 365／Google Workspace のライセンス回収と Mailbox / Drive のデータ引継ぎ
SaaS 個別アカウントの無効化（SCIM 対応で自動、非対応は手動）
VPN・社内 Wi-Fi アクセスの無効化
PC・貸与機器の回収と初期化
物理入退室カード・鍵の回収

💡 ポイント 「削除」ではなく「無効化」する理由は、監査対応と法的リスクへの備えです。退職者のメール・データが調査対象になる可能性がある期間（多くは退職後 3 か月〜1 年）は、削除せず無効化のまま保持します。

退職者アカウントの即時無効化

退職者アカウントの残存は、情報漏洩と監査指摘の最大要因です。次の 3 原則を守ります。

退職通告後、退職日までに準備：退職日ではなく通告時から準備を開始
退職日 17:00 に無効化：業務終了時刻に合わせて即時に無効化
無効化ログの即時確認：IdP のログで全 SaaS の無効化完了を確認

退職通告から退職日までに時間があれば、退職者は「引き継ぎ用」を口実に情報持ち出しの機会を得られます。退職通告後は権限最小化（メールと Slack だけに絞る）を早期に実施することが実務の推奨です。

半期に 1 回の権限棚卸し

入退社時の運用を完璧にしても、部署異動・プロジェクト終了で「使われなくなった権限」は蓄積します。これを掃除するのが半期に 1 回の権限棚卸しです。

棚卸しの 4 ステップ

リスト出力：IdP と各 SaaS から現在のユーザー権限一覧を出力
部署長への確認依頼：部署長に「所属メンバーの現在の権限を確認し、不要なものにチェック」を依頼
不要権限の削除：チェックのあった権限を情シスが削除
完了報告：棚卸し結果を経営陣と監査担当に報告

年 2 回のサイクル（6 月と 12 月が多い）を回すことで、監査時の「退職者アカウント残存」の指摘を大幅に減らせます。

講師の現場メモ——「退職者アカウントの無効化が 1 週間遅れて Slack で機密情報が持ち出された話」

私が独立初年度に伴走した中堅 IT 企業で、退職者のアカウント無効化が 1 週間遅れたことがありました。理由は「引き継ぎのために残しておいた」でした。

問題が発覚したのは、退職者が新しい勤務先で使う機密情報を Slack から一括ダウンロードしたことでした。過去のチャンネルログ、共有ドキュメントへのリンク、顧客リストが含まれていたと後で判明しました。証拠は IdP と Slack のログに残っていましたが、時すでに遅く、既存顧客との契約関係も影響を受けました。

退職者アカウントは、退職日 17:00 に必ず無効化する——これを鉄則としました。引き継ぎに必要な情報は事前に別の場所（共有ドライブ、ドキュメント）にコピーしておき、退職者のアカウントは維持しません。この事故以降、私が伴走するどの会社でも「退職通告後 24 時間以内に権限最小化、退職日 17:00 に完全無効化、翌日に IdP と全 SaaS のログで完了確認」の運用を徹底しています。

情シスの生命線はアカウント運用にあり、その 8 割は入社と退社の 2 点で決まる——この事故は私に、その言葉の重さを教えてくれました。

中核メッセージ 6 個の再掲

本コース全体を通じて、6 個のメッセージを繰り返します。

情シスは「守る・選ぶ・運用する」の 3 役割——役割ごとに時間を配分する
アカウント運用が情シスの生命線——入社と退社の 2 点で 8 割が決まる
SaaS は買った瞬間ではなく解約時に苦しむ——契約時に出口を設計する
ヘルプデスクは「早く直す」より「二度と起こさない」——ナレッジ化が本業
インシデントは一次受付・トリアージ・エスカレーションの 3 手で対応する
IT 予算は「守り・攻め・維持」の 3 分類で経営に説明する

このレッスンで扱うのはメッセージ 2「アカウント運用は情シスの生命線」です。IdP・SCIM を活用したうえで、入社と退社の運用手順を型化することが、セキュリティ・業務効率・監査対応の 3 つを同時に守る鍵です。

次のレッスンで扱うこと

次のレッスン 3 では、社内ネットワーク運用に踏み込みます。LAN 設計（VLAN・IP アドレス設計）、DNS／DHCP 運用、拠点間 VPN、Wi-Fi AP キッティング、ゼロトラスト移行判断の 3 前提までを整理します。クラウドと利用者側の視点は既刊 IT 基礎系入門で扱われているため、本コースはオンプレ社内ネットワークの運用手順に振り切ります。

確認クイズ

このレッスンで学んだ内容を確認しましょう。