オウンドメディアのアクセス管理で問題になりやすいのは、権限を付与した瞬間ではなく、担当者の退職・異動・契約終了後です。
誰が制作・編集・公開を担うかという役割分担と、運用体制全体の設計は、[コンテンツ制作・運用体制の全体像](https://rebranding.co.jp/media/content-production-operations/)で整理しています。
CMSの権限を正しく設計していても、Google Search Console、Google Analytics、サーバー、クラウドストレージ、Git、デザインツールなどに不要なアクセスが残れば、オフボーディングは完了していません。
本記事で扱うのは、「誰にどの権限を与えるか」という初期の権限設計ではなく、「今もアクセスが正当か」を監査し、不要アクセスを期限内に剥奪して証跡を残す運用です。
編集・承認・公開ロールの分け方や版管理、ロールバックの設計は、「オウンドメディアの編集権限・版管理を設計する方法」で解説しています。本記事ではそこを繰り返さず、退職・異動・外注終了時のオフボーディングと定期アクセスレビューに限定します。
30秒でわかる結論｜見るべきは「権限設計」ではなく「アクセスの正当性」です
アクセス権限監査では、次の5点を確認します。
- オウンドメディアに関係する対象システムを漏れなく一覧化する
- 各アカウントを在籍・所属・契約状態と突合する
- 孤児アカウント、共有ID、休眠アカウント、高権限アカウントを抽出する
- 退職・異動・外注終了ごとの剥奪期限に沿って無効化・縮小する
- 誰が、いつ、何を確認し、何を変更したかを証跡として残す
CIS Controls v8.1のSafeguard 5.1では、企業が管理するアカウント台帳に氏名、ユーザー名、開始・終了日、所属等を含め、少なくとも四半期ごとに有効アカウントが正当か確認することを示しています。Safeguard 6.2では、退職、権限取消、役割変更時にアクセスを失効させるプロセスを求めています。
つまり、権限監査の中心は「設定が正しいか」ではなく、「現在もその人・会社がアクセスしてよい状態か」を証明できることです。
監査対象は「CMS」ではなく「オウンドメディアに触れられる全システム」です
退職者のWordPressアカウントだけ削除しても、Search Consoleの所有者権限やサーバーの管理権限が残っていれば、アクセス経路は残ります。
監査対象は、人×システム×アカウント×権限×在籍・契約状態で管理します。
| 対象システム | 監査で見るもの | 見落としやすい点 |
|---|---|---|
| CMS | ユーザー、権限、最終利用 | 退職者、外部ライター、管理者残存 |
| Search Console | 所有者、フルユーザー | 旧制作会社の所有者権限 |
| Google Analytics | 管理者、編集者、閲覧者 | 旧担当者の個人アカウント |
| タグ管理 | 公開権限、承認権限 | 旧代理店の公開権限 |
| サーバー・ホスティング | 管理画面、SSH、FTP等 | 個人発行アカウント、共有認証情報 |
| DNS・CDN | 管理者、ゾーン編集 | 外注先の高権限が残る |
| クラウドストレージ | 共有フォルダ、外部共有 | 個人メールへの共有 |
| Git・開発環境 | Write/Admin、Deploy | 退職エンジニアの権限 |
| デザインツール | 編集、チーム管理 | 契約終了デザイナーの権限 |
| パスワード管理 | Vault共有、管理者 | 共有IDの認証情報が残る |
「記事を公開できる人」だけでなく、データを閲覧できる人、設定を変更できる人、認証情報を取得できる人まで監査対象に含めます。
最初に在籍・契約情報とアカウント一覧を突合する
アクセスレビューの起点は、CMSのユーザー一覧ではありません。
先に「現在アクセスしてよい人・会社の正本」を用意し、実際のアカウント一覧と突き合わせます。
正本として使う情報は、たとえば次のとおりです。
- 社員名簿
- 部署・役割
- 退職予定日
- 異動日
- 外注先一覧
- 契約開始日・終了日
- プロジェクト終了日
- 一時利用者の有効期限
その上で、各ツールから取得したアカウント一覧と照合します。
最低限、次の列を持つ管理台帳にすると判断しやすくなります。
| 項目 | 内容 |
|---|---|
| 氏名・会社名 | 誰のアクセスか |
| 在籍・契約状態 | 在籍、異動、退職予定、退職済、契約中、契約終了 |
| 対象システム | WordPress、Search Console等 |
| アカウントID | メールアドレス、ユーザー名 |
| 現在の権限 | 管理者、編集者、閲覧者等 |
| 業務目的 | 現在なぜ必要か |
| 開始日 | 権限付与日 |
| 終了予定日 | 契約・担当の終了予定 |
| 最終利用日 | 休眠確認に利用 |
| オーナー | 判断責任者 |
| 判定 | 継続、縮小、停止、要確認 |
| 対応期限 | いつまでに変更するか |
| 実施日 | 実際に変更した日 |
| 証跡 | チケット、ログ、スクリーンショット等 |
CIS Controls v8.1でも、アカウント台帳に開始・終了日や所属を含め、定期的に正当性を確認する考え方が示されています。
孤児アカウント・共有ID・休眠アカウントを優先して洗い出す
全アカウントを一覧化した後は、単に人数を数えるのではなく、正当性を説明しにくいアカウントを先に抽出します。
孤児アカウント
孤児アカウントとは、現在の所有者や利用目的を説明できないアカウントです。
たとえば次のような状態です。
- 社員名簿に存在しないメールアドレス
- 退職者名義のアカウント
- どの制作会社のものか分からない外部アカウント
- 誰が使っているか分からない「editor01」のようなID
- プロジェクト終了後も残っている一時アカウント
孤児アカウントは、権限の強弱より先に所有者と目的を確認します。所有者や利用目的を確認できなければ、継続理由を説明できません。
共有ID
共有IDは、一つの認証情報を複数人で利用するアカウントです。
共有IDを使っていると、個人アカウントを削除しても、退職者や契約終了者が共有パスワードを知っている可能性があります。
NIST SP 800-53 Rev.5のAC-2では、共有・グループアカウントを利用する場合、メンバーが外れた際に認証情報を変更するプロセスを設けることが示されています。
したがって、退職・契約終了時には次を確認します。
- 共有IDを使っていたか
- 共有パスワードを知っていたか
- パスワード管理ツールの共有Vaultへアクセスできたか
- APIキーやSSH鍵など共通認証情報を持っていないか
共有IDを廃止できない場合でも、利用者台帳と認証情報変更のトリガーを定義します。
休眠アカウント
CIS Controls v8.1のSafeguard 5.3では、対応可能な環境では45日間利用されていない休眠アカウントを削除または無効化する基準が示されています。
ただし、オウンドメディアでは月1回しか作業しない担当者もいます。
そのため「45日」を機械的に適用するのではなく、45日を要確認の基準として使い、業務頻度と照らして継続可否を判断するほうが現実的です。
オフボーディングは「退職・異動・外注終了」で剥奪SLAを分ける
退職・異動・外注終了は、同じ「権限変更」でも緊急度が違います。
そこで、各イベントについて誰が通知し、誰が判定し、誰が変更し、いつまでに完了するかをあらかじめ決めます。
| イベント | 基準 | 推奨する対応期限の考え方 | 主な対応 |
|---|---|---|---|
| 退職 | 業務上のアクセス理由が消滅 | 退職時点までに無効化 | 全システム停止、共有認証情報変更 |
| 異動 | 旧業務の権限が不要になる | 異動日を起点に速やかに見直し | 継続・縮小・停止をツール別判断 |
| 外注終了 | 契約上のアクセス理由が消滅 | 契約終了時点までに停止 | 外部アカウント停止、共有リンク解除 |
| 一時プロジェクト終了 | プロジェクト用途が終了 | 終了日を有効期限として扱う | 一時権限停止 |
| 緊急終了 | リスクが高い終了事由 | 通知前を含め即時対応を検討 | 先行無効化、認証情報変更 |
ここでいうSLAは、各社の就業規則や契約条件に代わるものではありません。アクセス失効をいつまでに完了させるかという社内運用基準です。
CIS Controls v8.1のSafeguard 6.2は、退職、権限取消、役割変更時にアカウントを即時無効化するプロセスを示しています。実際の運用では、通知時点と退職・契約終了時点を明確にし、担当者が迷わない状態にします。
退職時は「削除」ではなく、まずアクセス不能にする
退職時にアカウントをすぐ完全削除すると、投稿者情報、操作履歴、所有ファイルなどの扱いに影響することがあります。
そのため、基本は次の順で処理します。
- ログインできない状態にする
- セッションやトークンを失効させる
- 所有ファイル・記事・設定を後任へ移管する
- 共有ID、APIキー、SSH鍵等の影響を確認する
- 監査ログや投稿者情報の保持要否を確認する
- 不要になった時点で削除する
- 実施内容を証跡に残す
CIS Controls v8.1も、監査証跡の保持が必要な場合、削除ではなく無効化が必要になる場合があるとしています。
重要なのは「ユーザーを消した」ことではなく、退職後にアクセスできない状態になったことを確認できることです。
異動時は「権限の蓄積」を止める
異動では、全アカウントを停止するのではなく、新しい職務に必要なものだけ残します。
たとえば編集部からマーケティング部へ異動した場合、次のような判断が考えられます。
| システム | 異動前 | 異動後の判断例 |
|---|---|---|
| WordPress | 公開権限 | 停止または閲覧のみ |
| Analytics | 閲覧 | 継続 |
| Search Console | フル | 制限付き権限へ縮小 |
| サーバー | 管理者 | 停止 |
| Drive | 編集 | 必要フォルダのみ継続 |
NIST SP 800-53 Rev.5のAC-2は、利用者の異動や必要性の変化をアカウント管理に連携し、アクセス権を見直す考え方を示しています。
異動前の権限を残したまま新しい権限を追加すると、役割変更のたびに権限が積み上がります。定期監査では、この「権限の蓄積」を重点的に確認します。
外注終了時は「契約終了日」をアカウントの期限として扱う
外部ライター、制作会社、SEO会社、デザイナー、開発会社などは、社内人事システムに載っていないため権限残存が起きやすい対象です。
外注アカウントは、付与時点で次を登録します。
- 契約先会社名
- 利用者名
- 発注担当
- 利用システム
- 権限
- 権限付与日
- 契約終了予定日
- アカウント停止予定日
- 再確認日
契約終了日が未定でも、無期限扱いにはしません。四半期レビューのたびに「今も契約上必要か」を再確認します。
定期アクセスレビューは5ステップで進める
イベント発生時のオフボーディングとは別に、四半期などの定期レビューを実施します。
STEP1．前回レビュー時点の対象システム一覧を更新する
新しく導入したSaaS、制作会社だけが使っているツール、移行前の旧サービスが残っていないか確認します。
「ユーザー一覧」より前に「監査対象システム一覧」を更新することで、そもそも確認対象から漏れていたサービスを見つけられます。
STEP2．各システムの実アカウント一覧を取得する
台帳を見て終わりにせず、各システムの現在値を取得します。
確認するのは、少なくとも次です。
- アカウントID
- 現在の権限
- 最終利用日
- 外部ユーザーか
- 管理者・所有者か
- 共有ID・サービスアカウントか
STEP3．在籍・契約情報と突合し、例外を抽出する
次に、アカウント一覧と正本を突き合わせます。
要確認として抽出する例は次のとおりです。
- 退職済なのに有効
- 契約終了済なのに有効
- 異動済なのに旧高権限が残る
- 所有者不明
- 45日以上未利用
- 終了予定日を過ぎている
- 管理者権限の理由を説明できない
- 共有IDの利用者が不明
STEP4．継続・縮小・停止・要確認に分類し、処理する
判定は4種類にすると運用しやすくなります。
継続：現在の業務上必要で、利用者と目的を確認できる
縮小：アクセスは必要だが、現在の権限より弱くできる
停止：退職、契約終了、業務終了などで不要
要確認：所有者・目的・終了日等が不明で判断できない
「要確認」を無理に継続扱いにしないことが重要です。確認期限と責任者を設定し、期限までに正当性を確認できなければ停止判断へ進めます。
STEP5．結果と差分を証跡として残す
アクセスレビューの完了条件は、「一覧を見た」ではありません。
最低限、次を記録します。
| 項目 | 記録例 |
|---|---|
| レビュー日 | 2026年8月27日 |
| 対象システム | WordPress、Search Console等 |
| 対象アカウント | user@example.com |
| 判定 | 停止 |
| 理由 | 外注契約終了 |
| 実施内容 | アカウント無効化 |
| 実施者 | Web担当 |
| 確認者 | 編集長 |
| 完了日 | 2026年8月27日 |
| 証跡 | チケット番号、変更ログ等 |
次回レビューでは、この記録を前回値として差分確認できます。
証跡は「監査した事実」と「変更した事実」を分けて残す
証跡では、次の二つを区別します。
監査証跡
- 誰がレビューしたか
- いつレビューしたか
- 何を確認したか
- どの判定をしたか
- 誰が承認したか
変更証跡
- どのシステムで
- どのアカウントを
- どの権限からどう変更したか
- いつ変更したか
- 誰が変更したか
口頭やチャットだけで完了させると、次回の監査で「本当に止めたか」を確認できません。
変更チケット、システム監査ログ、権限一覧のエクスポート、管理台帳など、後から追跡できる記録に残します。
四半期レビューで見るべき優先順位
アカウント数が多い場合は、リスクの高いものから確認します。
| 優先度 | 対象 | 理由 |
|---|---|---|
| 最優先 | 退職者・契約終了者 | 正当なアクセス理由が消えている |
| 最優先 | 管理者・所有者 | 変更可能範囲が広い |
| 最優先 | 孤児アカウント | 所有者・目的を説明できない |
| 高 | 共有ID | 利用者を個別に追跡しにくい |
| 高 | 外部ユーザー | 社内人事と連動しにくい |
| 高 | 休眠アカウント | 不要化している可能性がある |
| 中 | 異動者 | 旧権限が蓄積しやすい |
| 低 | 現担当の通常権限 | 現在利用中である可能性が高い |
オフボーディングと定期監査の役割分担
退職・異動・外注終了の都度処理だけでは、通知漏れや過去の残存権限を拾えません。
一方、四半期レビューだけでは、退職者のアクセスが次回監査まで残る可能性があります。
そのため両方を組み合わせます。
| 運用 | 目的 | 起点 |
|---|---|---|
| オフボーディング | 不要になったアクセスを期限内に失効 | 退職・異動・契約終了等のイベント |
| 定期アクセスレビュー | 通知漏れ、孤児、休眠、権限蓄積を発見 | 四半期等の定期日 |
イベントで止め、定期監査で漏れを拾うという二重構造にすると、担当者変更が多い運用でもアクセス残存を減らせます。
人事・発注・編集・情シスの連携点を固定する
権限監査が失敗する原因は、ツール設定だけではありません。
退職や契約終了の情報を持つ部署と、実際にアクセスを変更できる担当が分かれていることがあります。
実務では、次の役割を固定します。
| 担当 | 役割 |
|---|---|
| 人事・総務 | 退職・異動情報を通知 |
| 発注担当 | 外注開始・終了を通知 |
| 編集長 | 業務上のアクセス必要性を判定 |
| Web担当・情シス | アカウント無効化・権限変更を実施 |
| 責任者 | 例外・継続判断を承認 |
NIST SP 800-53 Rev.5のAC-2でも、アカウント管理プロセスを人員の退職・異動プロセスと整合させることが示されています。
「退職を知っている人」と「アカウントを止められる人」をワークフロー上でつなぐことが、オフボーディング漏れ防止の中心です。
アクセス権限監査チェックリスト
- 対象システム一覧を更新した
- 実アカウント一覧を各システムから取得した
- 社員の在籍・異動・退職状態と突合した
- 外注先の契約状態と突合した
- 終了予定日を過ぎたアカウントを確認した
- 孤児アカウントを確認した
- 共有IDの利用者と認証情報変更要否を確認した
- 休眠アカウントを確認した
- 管理者・所有者権限を優先確認した
- 退職者の全アクセス経路を停止した
- 異動者の旧権限を縮小・停止した
- 外注終了者のアカウントと共有リンクを停止した
- 継続・縮小・停止・要確認の判定を記録した
- 要確認には責任者と期限を設定した
- 変更実施日を記録した
- 監査証跡と変更証跡を残した
- 次回レビュー日を設定した
まとめ
オウンドメディアのアクセス権限監査は、CMSのロール設計をやり直す作業ではありません。
目的は、在籍・契約状態と実アカウントを突合し、現在も正当なアクセスだけを残すことです。
退職・異動・外注終了時にはオフボーディングを実行し、四半期レビューでは孤児アカウント、共有ID、休眠アカウント、権限の蓄積を確認します。
まずはCMS、Search Console、Analytics、サーバー、Drive、Gitなどの対象システムを一覧化し、在籍・契約情報と実アカウントを突き合わせてください。
権限ロール、承認ゲート、版管理、ロールバックの設計そのものを見直す場合は、「オウンドメディアの編集権限・版管理を設計する方法」を参照してください。
参考文献・データ元
CIS Critical Security Controls Navigator v8.1
発表元：Center for Internet Security
使用内容：Safeguard 5.1のアカウント台帳・四半期レビュー、5.3の休眠アカウント、6.2のアクセス失効プロセス
URL：https://www.cisecurity.org/controls/cis-controls-navigator
CIS Critical Security Control 5: Account Management
発表元：Center for Internet Security
使用内容：アカウント管理の基本方針
URL：https://www.cisecurity.org/controls/account-management
CIS Critical Security Control 6: Access Control Management
発表元：Center for Internet Security
使用内容：アクセス資格情報・権限の付与、管理、失効
URL：https://www.cisecurity.org/controls/access-control-management
NIST SP 800-53 Rev.5「AC-2 Account Management」
発表元：National Institute of Standards and Technology
使用内容：アカウントの作成・変更・無効化、退職・異動との連携、共有アカウント認証情報の変更、定期レビュー
URL：https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf