導入

社内で利用するSaaSが50種類を超えると、「誰が何のサービスにアクセスできるか」を把握することが急速に難しくなります。営業部門はSalesforceとSansanを使い、マーケティングはHubSpotとGoogle Analytics、エンジニアリングチームはGitHubとJiraとAWSを利用する。部門をまたいで確認しようとしても、管理画面はサービスごとにバラバラで、権限の状態を一覧化できる場所がどこにもない、という状況が多くの中堅・大手企業で生じています。

帝国データバンクの調査によれば、国内企業が利用するクラウドサービスの種類は年々増加しており、従業員500名規模の企業では平均40〜60種類のSaaSを利用しているとされます。その一方で、SaaSのアクセス権を一元管理するための仕組みを持つ企業は少数にとどまるのが現状です。

この状態が続くと、三つの問題が積み重なっていきます。

退職者のアカウントがそのまま残り続ける問題は、その典型です。退職処理が完了した翌週に、元従業員のIDでSaaSへのログインが検出されるケースは決して稀ではありません。次に、異動や昇格に伴う権限の更新漏れがあります。総務部から経営企画に異動した社員が、前部署のファイル共有サービスの管理者権限を半年後もそのまま保持していた、というケースは頻繁に起きます。三つ目は、業務上不要になったにもかかわらず誰にも気づかれない過剰権限です。一度付与された権限は、積極的に削除する仕組みがなければ永続します。

こうしたアクセス管理の不備は、単なる内部統制上の問題にとどまりません。退職者アカウントや過剰権限は、情報漏洩・不正アクセス・内部不正といったセキュリティインシデントの入口になります。J-SOXやISMSの監査でも、アクセス権の管理状況は重点チェック項目の一つです。情報セキュリティ事故の多くは、適切に管理されていなかった認証情報やアクセス権を起点に発生しています。

この記事では、SaaSアクセス管理の基本概念から、ロールベースアクセス制御（RBAC）や最小権限の原則といったセキュリティ設計思想、整備に向けた4ステップまでを体系的に解説します。情シス部門が明日から取り組める実践的な内容を中心にまとめました。

SaaSアクセス管理とは何か

SaaSアクセス管理とは、誰が・どのSaaSに・どんな権限で・いつアクセスできるかを組織として管理する仕組みを指します。個別のサービス設定の話ではなく、組織全体のアクセス権を設計・運用・監査するための体系的なアプローチです。

アクセス管理が担う機能は、大きく三つに分けられます。

一つ目は認証（Authentication）です。アクセスしようとしている人物が、本当に本人であるかを確認するプロセスです。パスワード認証・多要素認証（MFA）・シングルサインオン（SSO）といった手段が該当します。

二つ目は認可（Authorization）です。認証を通過したユーザーが、具体的に何を閲覧・操作できるかを制御します。「Aさんは顧客データの閲覧は可能だが、削除は不可」「Bさんはシステム管理者としてすべての設定にアクセスできる」といった権限の定義がここに含まれます。

三つ目は監査（Audit）です。誰がいつ何にアクセスしたかのログを記録・管理し、不正アクセスや過剰権限を検知します。セキュリティインシデント発生時の原因調査や、法令対応の証跡取得にも欠かせません。

IAM（Identity and Access Management）という概念と混同されることがありますが、IAMはオンプレミス環境を含む広義のID管理・アクセス制御の体系を指します。SaaSアクセス管理はそのSaaS領域に特化したサブセットといえます。

SaaS環境特有の難しさは、サービスごとに管理画面・権限モデル・ログ出力の仕様がまったく異なる点にあります。オンプレミスのActive Directoryのように一元管理できるレイヤーが存在せず、各SaaSを個別に設定・確認しなければなりません。SaaSの数が増えるほど、この分散管理のコストは指数関数的に増大します。

IDaaSとSaaSアクセス管理の関係についても補足しておきます。IDaaS（Okta・Azure AD等）はSSO・MFA・ディレクトリ管理を提供しますが、各SaaS内部での権限レベルの管理や定期棚卸しには対応していません。IDaaSは「誰がSaaSに入れるか」を管理するツールであり、「入ったあとに何ができるか」を管理するのがSaaSアクセス管理の領域です。両者は補完関係にあります。

SaaSアクセス管理の基本概念

SaaSアクセス管理を設計・運用するうえで押さえておくべき、三つのセキュリティ概念があります。ロールベースアクセス制御・最小権限の原則・JITプロビジョニングです。

ロールベースアクセス制御（RBAC）

ロールベースアクセス制御（RBAC: Role-Based Access Control）は、ユーザー個人に直接権限を付与するのではなく、「ロール（役割）」を介して権限を管理するアプローチです。「ユーザー → ロール → 権限」という三層構造が基本になります。

たとえば「営業担当」というロールを定義し、そのロールにSalesforceの「商談データ閲覧・編集」と「顧客台帳の編集」という権限を紐づけます。営業部門のメンバーが入社したとき、個別に権限を一つひとつ設定するのではなく「営業担当ロールをアサイン」するだけで済みます。

RBACのメリットは、権限管理の一貫性と効率性にあります。ロールの定義を変更すれば、そのロールを持つ全ユーザーに一括で反映されます。部門異動時もロールの付け替えだけで処理が完結し、設定ミスが生じにくくなります。

SaaS環境でRBACを実装する場合、まず職種別・部門別・役職別のロールマトリクスを設計します。「全社共通ロール（新入社員向け・管理職向け）」「部門ロール（営業・マーケティング・エンジニアリング）」「プロジェクトロール（特定案件への一時的なアクセス権）」の三層で整理すると管理しやすくなります。

下の表は、ロールマトリクスの簡易例です。

実際の設計では、各SaaSが持つ権限レベルの粒度に合わせてマトリクスを細分化します。すべてのSaaSを同時に整備しようとすると作業量が膨大になるため、機密性の高いデータを扱うサービスから順番に着手するのが現実的です。

[画像: RBACの三層構造（ユーザー・ロール・権限）を示す図]

最小権限の原則（Least Privilege）

最小権限の原則とは、ユーザーが業務を遂行するために必要な最低限の権限のみを付与するというセキュリティ設計思想です。NIST（米国国立標準技術研究所）が定めるセキュリティフレームワークでも基本原則として位置づけられており、ゼロトラストセキュリティのコアコンセプトの一つでもあります。

SaaS環境では過剰権限が常態化しやすい構造があります。初回設定時に「管理者権限を付与しておけば確実」と判断し、以後見直しがされないケースが典型です。

過剰権限の実態として多いのは次の三パターンです。退職者・休職者の権限が残存している「ゴースト権限」、業務で使わなくなったにもかかわらず削除されていない「放置権限」、そして特定業務のために一時的に付与されたが終了後も残っている「期限切れ権限」です。

最小権限を維持するためには、権限の付与ルールを設計するだけでは不十分です。定期的なレビューで「現在付与されている権限が今の業務に本当に必要か」を継続的に確認する仕組みが必要になります。

JIT（Just-In-Time）プロビジョニング

JIT（Just-In-Time）プロビジョニングとは、必要なときだけ権限を付与し、用途が終わったら自動的に剥奪する方式です。「常時付与」ではなく「一時的な付与」によってアクセスリスクを最小化します。

特権アカウントの管理に特に有効です。システム管理者権限や、本番データベースへのアクセス権は、日常的には不要でも特定のメンテナンス作業時にのみ必要になります。JITを導入すれば「作業開始時に権限をリクエスト → 承認 → 作業完了後に自動失効」というフローが実現できます。

ゼロトラストセキュリティとの関係でいえば、ゼロトラストは「すべてのアクセスを常に検証し、デフォルトでは信頼しない」という考え方です。JITプロビジョニングはその実装手段の一つであり、権限の常時保持を排除することでゼロトラストの原則に近づけます。

詳しくは「ゼロトラストセキュリティとは」の記事を参照してください。

SaaSアクセス管理の3大課題

多くの中堅・大手企業が直面しているアクセス管理の課題は、共通した三つのパターンに集約されます。

課題1: 入退社・異動時の権限更新漏れ

人事変動のたびに権限を手動で更新する運用を続けている組織では、更新漏れが必ず発生します。入社時の権限付与は比較的意識されますが、退職時・異動時・休職時の権限削除・変更は後回しにされやすい傾向があります。

退職者のアカウントが残り続ける「孤立アカウント（オーファンドアカウント）」は、特にリスクが高い状態です。退職者本人による不正アクセスだけでなく、認証情報が漏洩した場合に第三者による侵入口になります。

詳しくは「[孤立アカウントとは]」の記事を参照してください。

また、異動時の対応も見落とされがちです。前部署で必要だった権限を削除せずに新部署の権限を追加する運用が続くと、時間の経過とともに各ユーザーが必要以上の権限を蓄積する「権限の肥大化」が起きます。

課題2: 定期的な権限棚卸しができていない

アクセス権の定期的な見直し（アクセス権レビュー）は、J-SOXやISMSが求める重要な統制活動の一つです。しかし、実施できている企業は限られています。

理由の多くは、手間の問題です。全ユーザーの全SaaSのアクセス権を棚卸しするには、各サービスの管理画面を個別に開いて権限状態を確認し、担当マネージャーに確認を依頼し、承認結果を台帳に記録するという煩雑なプロセスが必要です。SaaSが30種類あれば、この作業だけで情シス担当者の数日分の工数を消費します。

詳しくは「[アクセス権レビューとは]」「[アクセス権限 棚卸し 方法]」の記事で解説しています。

課題3: SaaSごとに管理が分散して一元化できない

各SaaSはそれぞれ独自の管理コンソールを持ち、権限モデルも異なります。Salesforceにはプロファイルとロールとパーミッションセットの概念があり、Google WorkspaceにはOU（組織部門）とグループがあり、AWSにはIAMポリシーがあります。

統一された管理インターフェースがないため、情シス担当者は複数の管理画面を行き来しながら対応しなければなりません。誰かのアクセス権を変更するたびに、それが影響するすべてのSaaSを個別に操作する必要があります。

SaaSが増えるほど、この分散管理の課題は深刻化します。新たなSaaSを導入するたびに管理対象が増え、設定ミスや更新漏れのリスクが積み重なります。SaaSスプロール（管理されていないSaaSの野放図な拡大）が進んだ組織では、情シス部門が把握していないSaaSが複数存在するシャドーSaaSの問題も浮上します。

詳しくは「[SaaSセキュリティとは]」の記事も参照してください。

SaaSアクセス管理を整備する4ステップ

アクセス管理の整備は、一度にすべてを変えようとすると必ず頓挫します。現状の可視化から始め、段階的に仕組みを構築していくアプローチが現実的です。

[画像: アクセス管理整備の4ステップを示すフロー図]

Step1: 現状の棚卸し（アクセス権の可視化）

最初にすることは、現在どのSaaSに誰がアクセスできるかを一覧化することです。「台帳がない」状態から始める場合も、まずスコープを絞って着手します。全社いっせいに棚卸しを始めると途中で作業が止まるため、管理対象SaaSをリスト化し、優先度の高いもの（機密性の高いデータを扱うもの・利用者数が多いもの）から着手するのが現実的です。

棚卸しで確認すべき項目は、ユーザーID・権限レベル（管理者/一般/閲覧のみ）・最終ログイン日・アカウント作成日・担当マネージャーの四点です。

この作業を通じて、孤立アカウント（退職者・休職者のID）と過剰権限（業務に不要な管理者権限）を洗い出します。最終ログイン日が90日以上前のアカウントは、まず利用実態を確認する対象として優先的にリストアップします。

Step2: ロール・権限ポリシーの設計

現状把握ができたら、あるべきアクセス権の姿を設計します。ここで作成するのはロールマトリクスです。縦軸にSaaSサービス名、横軸に職種・部門・役職を置き、それぞれの交点に「必要な権限レベル」を記入します。

ロールマトリクスを作るときのポイントは、実際の業務フローに基づいて設計することです。「このSaaSで誰が何の作業をするか」をヒアリングしながら埋めていくと、実態に即したロール設計ができます。情シス部門だけで完結しようとせず、各部門のリーダーに確認しながら進めることが重要です。

また、標準ロールで対応できない例外的なアクセス申請が発生したときのフローも合わせて整備します。申請者・承認者・有効期間・承認根拠を記録する仕組みを作っておくことで、例外がいつまでも残り続ける事態を防げます。

Step3: 入退社・異動連動の自動化

ロールマトリクスが完成したら、人事変動時の権限変更を自動化する仕組みを導入します。

自動化の基本的な考え方は、人事システム（HRシステム）をマスターデータとして位置づけ、そこに記録された入退社・異動情報に連動してSaaSのアクセス権を自動更新することです。IDaaS（Identity-as-a-Service）やSMP（SaaS Management Platform）を人事システムと連携させることで、手動での権限変更作業を排除します。

入社時は、ロールマトリクスに基づいて必要なSaaSのアカウントを自動プロビジョニングします。退職時は、すべてのSaaSのアカウントを自動デプロビジョニングします。異動時は、前部署のロールを削除して新部署のロールを付与するフローを自動化します。

詳しくは「[入退社 アカウント自動化 SaaS]」の記事を参照してください。

Step4: 定期的なアクセス権レビュー

自動化された仕組みを導入しても、定期的なアクセス権レビューは欠かせません。自動化で対応できるのは「登録されている人事変動」に連動した更新であり、業務内容の変化や役割の変動は自動的には反映されません。

アクセス権レビューは四半期または半期ごとに実施することが標準的です。進め方としては、各ユーザーのアクセス権一覧を所管マネージャーに確認してもらい、「不要になった権限」「変更が必要な権限」を特定して更新します。

このとき重要なのは、マネージャーが確認しやすいインターフェースを用意することです。すべてのSaaSの管理画面を個別に開いて確認するよう求めると、マネージャーの協力を得にくくなります。一覧形式で「このユーザーにはこれらのSaaSへのアクセス権があります。それぞれ継続が必要ですか？」と確認できる形にすることが、レビューの完遂率を高めます。

アクセス権レビューの一般的なフローは以下の通りです。

1. 情シスが対象ユーザー・対象SaaSのアクセス権一覧を作成する
2. 所管マネージャーに確認依頼を送付する
3. マネージャーが継続・削除・変更を回答する（期限：2週間）
4. 情シスが回答内容を確認し、削除・変更対象のアカウントを更新する
5. 実施結果を記録として保存する

J-SOX対応の観点では、誰がいつ何を確認・承認したかの証跡を記録として残すことが求められます。棚卸し実施日・確認者・承認者・変更内容をすべてエクスポートできる形で保管します。この証跡取得の自動化が、アクセス権レビューをスムーズに運用するうえでの重要な条件になります。

ジョーシスによるSaaSアクセス管理の実践

ここまで解説したアクセス管理の整備を、ジョーシスのプラットフォームを使って実現する方法を紹介します。ジョーシスはAI駆動型アイデンティティガバナンスプラットフォームとして、350以上のSaaSと連携してアクセス管理を一元化します。

[画像: ジョーシスのダッシュボード画面]

Access Automationは、入退社・異動時のアカウント管理を自動化する機能です。人事システムやHRISと連携し、入社時には必要なSaaSへのプロビジョニングを自動実行します。退職時にはすべてのSaaSのアカウントを自動でデプロビジョニングし、「退職者アカウントの残存」という問題を構造的に解消します。異動時は、前部署のロールを外して新部署のロールを付与する一連の処理をワークフローで自動化できます。Sales Marker社での導入事例では、IT管理工数が約50%削減されています。

Access Reviewsは、定期的なアクセス権棚卸しをワークフロー化する機能です。四半期・半期ごとのレビュー対象ユーザーと対象SaaSをシステム側で自動的に集計し、各マネージャーに確認依頼を送信します。マネージャーは権限の継続・削除・変更をシステム上で回答するだけです。承認結果はすべて自動で記録され、J-SOXやISMS対応の証跡として即座にエクスポートできます。

SaaS Insightsは、SaaSの利用状況とアクセス権を横断的に可視化する機能です。90日以上ログインのないアカウントを自動検出し、未使用アカウントの整理候補として提示します。SaaSごとのライセンス利用率も確認できるため、過剰なライセンス購入の見直しにも活用できます。Anker Japan社では、ジョーシスを活用してITコストを75%削減した実績があります。

ジョーシスのプラットフォームは、これらの機能を350以上のSaaSで一元的に管理できる点が特徴です。個別のSaaSごとに管理画面を行き来する必要がなく、一つのプラットフォームで全社のアクセス権の状態を把握・更新できます。国内外700社以上の導入実績があり、さまざまな規模・業種の情シス部門が活用しています。

まとめ

SaaSアクセス管理は、セキュリティ対策の一環であると同時に、情シス業務の効率化に直結するテーマです。

管理の核となるのは二つです。最小権限の原則に基づいたロール設計と、定期的なアクセス権レビューです。この二本柱を機能させるためには、入退社・異動時の権限変更を自動化する仕組みと、棚卸し作業を担当マネージャーが無理なく実施できるワークフローが必要になります。

「人手管理」から「自動化・仕組み化」へ移行することで、情シス担当者の運用負荷を削減しながら、セキュリティレベルと内部統制の質を同時に高められます。アクセス管理の整備を後回しにすると、SaaSの数が増えるほど対応コストが増大します。早期に仕組みを構築しておくことが、中長期的なリスク低減と業務効率化の両立につながります。

アクセス管理の自動化に取り組む際は、まず現状の棚卸しから始め、ロール設計・自動化ツールの導入・定期レビューの整備というステップを順番に進めることが、確実に成果を出す道筋です。

SaaSアクセス管理の自動化と一元化に関心のある方は、ジョーシスのAccess AutomationとAccess Reviewsについて詳しくご確認ください。

参考情報

• [SaaSセキュリティとは]（内部リンク）
• [ゼロトラストセキュリティとは]（内部リンク）
• [最小権限の原則とは]（内部リンク）
• [孤立アカウントとは]（内部リンク）
• [入退社 アカウント自動化 SaaS]（内部リンク）
• [アクセス権レビューとは]（内部リンク）
• [アクセス権限 棚卸し 方法]（内部リンク）

‍