# 最小権限の原則を SaaS の共有アカウントに当てはめる

共有アカウントでは権限が ID に付き、使う人全員に同じ権限が渡るため、人ごとには絞れません。まず SaaS 側の権限の種類(閲覧・編集・管理者)で個人に分け、共有が残る部分は、使える人の一覧、期間、記録の 3 つで補います。

更新日: 2026-09-18

[最小権限の原則](/guides/access-basics/what-is-least-privilege)を SaaS(インターネット経由で使う業務ソフト)に当てはめてみます。人ごとに、その仕事に要る権限だけを、要る間だけ渡す形になります。共有アカウントではこの形が成り立ちません。権限が ID に付いていて、一組の ID とパスワードを知る人全員に同じ権限が渡るためです。共有アカウントの定義は[共有アカウントとは](/guides/shared-accounts/what-is-shared-account)にあります。

## 共有アカウントで最小権限が成り立たない理由

米国 NIST の用語集は、SP 800-53 Revision 5 の定義を載せています。最小権限とは、各主体(entity)にその働きに必要な最小限の資源と権限だけを与えるよう設計する原則です。CNSSI 4009 の定義では、利用者のアクセス権限を、割り当てられた作業に必要な最小限に制限する原則です。どちらも、権限を絞る単位は「主体」や「利用者」です。

SaaS の権限は、利用者ではなく ID に付きます。一人一つの ID なら、ID を絞ることが人を絞ることと同じになります。共有アカウントでは、ID が一つで使う人が複数です。ID の権限を絞っても、その権限は知っている人全員に同じだけ渡ります。閲覧しかしない人にも、管理者の権限が渡ることになります。Microsoft Entra ID の公式ドキュメントは、ID とパスワードを配る従来の共有の欠点を挙げています。誰がアクセスできるか、誰がアクセスしたかが分からないこと。外すには変えて配り直すしかないことです。

IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、ID の発行から削除までを管理する手続を定めるよう勧めています。付ける権限は必要最小限にします。共有 ID はなるべく使わないことも勧めています。やむを得ず使う場合は、共有 ID を利用した人を特定できる仕組みを整え、規定のとおりに運用します。

## 先に SaaS 側の権限の種類で分ける

したがって最初に行うのは、共有をやめて個人の ID に分け、ID ごとに権限の種類を選ぶことです。業務向けの SaaS の多くは、権限の種類を人ごとに割り当てられます。Google アナリティクスの公式ヘルプは、5 つの役割を挙げています。

| 役割 | できること(公式ヘルプの要約) |
| --- | --- |
| 管理者 | すべての管理。利用者の追加と削除、役割とデータ制限の割り当て |
| 編集者 | プロパティ(計測の単位)の設定の管理。利用者の管理はできない |
| マーケティング担当者 | オーディエンス、イベント、キーイベントの作成と変更 |
| アナリスト | データ探索の作成と共有。非サンプリングのデータ探索の申請 |
| 閲覧者 | 設定とデータの閲覧、レポートの表示の変更 |

役割はアカウントとプロパティの単位で人ごとに割り当て、上位で付けた役割は下位に引き継がれます。費用や収益の数字を見せないデータ制限も、役割とは別に付けられます。このように分けられるサービスでは、担当者ごとに「何をする人か」を書き出します。その作業ができる一番低い役割を選び、管理者の役割は少人数に限ります。媒体ごとの権限の分け方は、[Meta のビジネスポートフォリオ](/guides/agency-accounts/meta-business-portfolio-agency-access)、[Google 広告の MCC](/guides/agency-accounts/google-ads-mcc-agency-access)、[Shopify・BASE のスタッフ権限](/guides/agency-accounts/shopify-base-staff-permissions)の記事にまとめています。

分けられないアカウントも残ります。アカウントを一つしか持てないサービス、SNS の公式アカウントそのもの、一つしかない管理者アカウントなどです。どれが当てはまるかの整理は[共有アカウントを個人アカウントに分けられないケースの整理](/guides/shared-accounts/when-accounts-cannot-be-split)にあります。

## 共有が残る部分で代わりに絞る 3 つ

共有が残るアカウントでは、権限の種類の代わりに、次の 3 つで絞ります。

### 使える人の一覧

そのアカウントを使ってよい人を名前で決め、一覧にします。パスワードを知る人は、それより少なくします。権限の種類は絞れなくても、権限を持つ人の数は絞れます。IPA が勧める、必要最小限の割り当てに当たります。

### 期間

担当の間だけ使えるようにし、担当が終わった日に外します。委託なら契約の終了日です。使わなくなった人に権限が残る状態をなくすためで、IPA が挙げる、異動・退職に伴う削除漏れを防ぎます。

### 記録

誰がいつ使ったかを、サービス側の記録とは別に残します。サービス側の記録には、共有アカウントの名前しか残らないためです。IPA が勧める、利用した人を特定できる仕組みに当たります。

3 つのうち「使える人の一覧」は、パスワードを知らなくても使える手段があるときに、知る人より広くできます。手段がなければ、使える人とパスワードを知る人は一致します。一人が担当を外れるたびに、パスワードを変えて残る全員に配り直すことになります。この一覧と知る人を切り離す手段は 2 つあります。ID 管理サービス(Okta や Microsoft Entra ID など)の代理入力と、パスワードを見せずに代わりに入力する仕組みです。方法ごとの違いは[共有アカウントを複数人で安全に使う方法の比較](/guides/shared-accounts/comparison-of-shared-account-methods)にあります。

## 見直しの手順

IPA のガイドラインは、異動や退職に伴う権限の変更・削除漏れと、特定の人への権限の集中による不正利用や権限の濫用を、防ぐべき被害として挙げています。そのために、事業所やフロアの入室とシステムのアクセス権限を見直すルールを定め、付与の状況を管理するよう勧めています。運用や利用状況を監視する仕組みを整えることも挙げています。このうちシステムのアクセス権限について SaaS に当てはめると、手順は 4 つです。

1. サービスごとに、個人の ID とその役割、共有アカウントとその使える人の一覧を作る。一覧の作り方は[共有アカウントの棚卸しの手順と台帳の項目](/guides/shared-accounts/shared-account-inventory)にあります。
2. 一人ずつ、その役割や共有アカウントがいまの作業に要るかを見て、要らないものを外す。
3. 記録を見て、一定期間使っていない人を一覧から外す。使っていない権限は、要らない権限の候補です。
4. 入退社と担当交代のたびに当てはまる行を更新し、それとは別に全件を見直す日を決める。IPA のガイドラインは周期を定めていないため、会社が決めます。

管理者用アカウント(強い権限を持つ ID)は、同じ考え方をより厳しく当てはめる対象です。扱いは[特権 ID(管理者用アカウント)とは](/guides/privileged-access/what-is-privileged-id)にまとめています。


## よくある質問

**共有アカウントでも最小権限は守れますか**

人ごとには絞れません。権限は ID に付き、パスワードを知る人全員に同じ権限が渡るためです。使える人の一覧、期間、記録で、誰がいつ使ったかを絞る形に置き換えます。

**全員に管理者権限を渡すと何が問題ですか**

IPA のガイドラインは、特定の人への権限の集中による不正利用や権限の濫用と、異動・退職に伴う権限の変更・削除漏れを、防ぐべき被害として挙げています。

**SaaS の権限の種類はどこで確かめますか**

各サービスの公式ヘルプです。Google アナリティクスは管理者、編集者、マーケティング担当者、アナリスト、閲覧者の 5 つを、アカウントとプロパティの単位で人ごとに割り当てます。

**権限の見直しはどのくらいの頻度で行いますか**

IPA のガイドラインは周期を定めず、権限の付与状況を管理し、利用状況を監視する仕組みを勧めています。入退社と担当交代のたびに見直し、別に全件を見る日を決めます。

## 参考資料

- [NIST Computer Security Resource Center Glossary「least privilege」](https://csrc.nist.gov/glossary/term/least_privilege)
- [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf)
- [Microsoft Learn「Sharing accounts and credentials - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/users/users-sharing-accounts)
- [アナリティクス ヘルプ「[GA4] アクセスとデータ制限の管理」](https://support.google.com/analytics/answer/9305587?hl=ja)

## Junify の場合

**人手で続けると** SSO や多要素認証を入れても、対応していないサービスと共有のまま残るアカウントは手作業に残り、どこまでを仕組みで覆えているかを自分で把握し続けることになります。

**Junify なら** Junify は、共有が残るアカウントの「使える人の一覧」「期間」「記録」を担います。管理者がアカウントごとに使ってよい担当者を割り当て、担当が終わればその場で外します。担当者はパスワードを知らないため、外した後に使える状態は残らず、誰が・いつ使ったかは一人ひとり残ります。

Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。

- [登録不要の体験デモを見る](https://www.junify.jp/bpo/try)
- [30 分デモを予約する](https://www.junify.jp/bpo/demo)

## 同じテーマの記事

- [監査ログと、監査で示す記録の違い](/guides/access-basics/audit-log-vs-evidence): 監査ログは、システムが動作や利用のたびに自動で残す記録です。監査で示す記録は、そこから誰が・いつ・何をしたかを説明できるように選び、改ざんを防いで決めた期間保存し、管理者以外が点検したものを指します。
- [ブラウザーの拡張機能でできるアクセス管理の範囲](/guides/access-basics/browser-extension-access-control-scope): 拡張機能は、それを入れたブラウザーの中で、決めたサイトのページを読み取り、入力し、動作を変えられます。ブラウザーの外のアプリと、拡張機能の入っていないブラウザーや端末には届きません。この線引きが選ぶときの基準です。
- [私物端末(BYOD)で業務システムを使わせるときの選択肢](/guides/access-basics/byod-options-mdm-vdi-browser): 選択肢は 5 つです。端末全体を管理する MDM、仕事のアプリだけを管理する MAM、画面だけを映す仮想デスクトップ、会社が管理するブラウザー、パスワードを見せずに代わりに入力する仕組み。会社が何を管理するかで分かれます。