オウンドメディアのアクセス管理で問題になりやすいのは、権限を付与した瞬間ではなく、担当者の退職・異動や外注先との契約終了のあとです。そのとき、関わっていたアカウントと権限を、すべて止められているでしょうか。
誰が制作・編集・公開を担うかという役割分担と、運用体制全体の設計は、コンテンツ制作・運用体制の全体像で整理しています。
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・休眠アカウントを優先して洗い出す
全アカウントを一覧化した後は、人数を数えるのではなく、正当性を説明しにくいアカウントを先に抽出します。ここでは、孤児アカウント、共有ID、休眠アカウントの3種類を取り上げます。
孤児アカウント
孤児アカウントとは、現在の所有者や利用目的を説明できないアカウントです。たとえば次のような状態です。
- 社員名簿に存在しないメールアドレス
- 退職者名義のアカウント
- どの制作会社のものか分からない外部アカウント
- 誰が使っているか分からない「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と呼びます。
ここでいう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ステップで進める
イベント発生時のオフボーディングとは別に、四半期などの定期レビューを実施します。次の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 | 利用者を個別に追跡しにくい |
| 高 | 外部ユーザー | 社内人事と連動しにくい |
| 高 | 休眠アカウント | 不要化している可能性がある |
| 中 | 異動者 | 旧権限が蓄積しやすい |
| 低 | 現担当の通常権限 | 現在利用中である可能性が高い |
退職者・契約終了者、管理者・所有者、孤児アカウントの3つは、いずれも最優先です。現担当の通常権限は、現在利用中である可能性が高いため、後に回します。
オフボーディングと定期監査の役割分担
退職・異動・外注終了の都度処理だけでは、通知漏れや過去の残存権限を拾えません。一方、四半期レビューだけでは、退職者のアクセスが次回監査まで残る可能性があります。そのため両方を組み合わせます。
| 運用 | 目的 | 起点 |
|---|---|---|
| オフボーディング | 不要になったアクセスを期限内に失効 | 退職・異動・契約終了等のイベント |
| 定期アクセスレビュー | 通知漏れ、孤児、休眠、権限蓄積を発見 | 四半期等の定期日 |
イベントで止め、定期監査で漏れを拾うという二重構造にすると、担当者変更が多い運用でもアクセス残存を減らせます。
人事・発注・編集・情シスの連携点を固定する
権限監査が失敗する原因は、ツール設定だけではありません。退職や契約終了の情報を持つ部署と、実際にアクセスを変更できる担当が分かれていることがあります。
実務では、次の役割を固定します。
| 担当 | 役割 |
|---|---|
| 人事・総務 | 退職・異動情報を通知 |
| 発注担当 | 外注開始・終了を通知 |
| 編集長 | 業務上のアクセス必要性を判定 |
| 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
‹ 親記事: コンテンツ制作・運用体制とは？編集フロー・役割分担・品質チェックの仕組みを体系的に整理
関連記事
- › 記事品質チェックリストの作り方｜編集基準・校正・根拠確認・公開承認を標準化する
- › SEO記事のコンテンツブリーフ作成方法｜検索意図・見出し・根拠・内部リンクを制作前に定義する
- › オウンドメディアの著者・監修者設計｜誰が書き、誰が確認したかを記事単位で明示する方法
- › オウンドメディア編集部の作り方｜編集長・ライター・監修者・SEO担当の役割分担
- › 記事の更新期限を決める方法｜鮮度・重要度・順位下落で判断
- › 記事の出典・根拠を管理するエビデンス台帳の作り方｜更新期限・一次情報・引用箇所を追跡
- › オウンドメディアの編集権限・版管理を設計する方法｜誤公開・上書き・承認漏れを防ぐ
- › 生成AIを記事制作に使う運用ルールの作り方｜利用範囲・人間レビュー・機密情報を管理
- › 記事の出典を定期確認｜リンク切れ・情報鮮度・一次情報をチェック
- › 生成AIを使った記事制作の検証ログを作る方法｜プロンプト・根拠確認・修正履歴を残す
- › コンテンツ制作の遅れを確認｜企画・執筆・確認・公開を可視化
- › 外注記事の受入れ基準を作る方法｜納品形式・根拠・著作権・修正責任を標準化
- › オウンドメディアの画像・図版ライセンスを管理する方法｜出典・利用範囲・期限を台帳化
- › 外注ライター・制作会社の評価スコアカードを作る方法｜品質・納期・修正回数・専門性を継続評価
- › オウンドメディアの緊急訂正・公開停止フロー｜訂正・一時非公開・削除の判断基準と復旧手順
- › 法人向けサービスページの比較表の作り方｜料金・対象・対応範囲・実績・契約条件を同じ軸で整理
- › 導入事例ページの作り方｜成果数値・導入期間・取り組み内容
- › オウンドメディア担当者の引き継ぎチェックリスト｜記事・CMS・編集ルール・分析データ・進行中企画を整理
- › 導入事例ページの作り方｜業種・課題・成果で探せる構成と導線
- › 法人向けサービスページのFAQの作り方｜料金・対象・導入条件・契約・セキュリティの質問を整理
- › 法人向けサービスページの導入フローの作り方｜期間・準備物・担当・例外条件まで整理
- › 法人向けサービスのセキュリティ情報の載せ方｜認証・データ保管・権限・問い合わせ先の整理方法
- › 法人向けサービスサイトの情報更新を誰が持つ？営業・法務・制作で料金・実績・契約条件を管理する方法
- › オウンドメディアの表記ガイドラインの作り方｜表記ゆれ・数字・固有名詞・引用ルールを統一
- › オウンドメディアのインタビュー記事の作り方｜企画・質問設計・取材・原稿確認・公開まで
- › オウンドメディアの記事テンプレートの作り方｜原稿フォーマット・出典・CTA・FAQ・著者欄を標準化
- › Claudeの料金プラン比較｜無料・Pro・Team・法人向けの選び方
- › NotebookLMの使い方｜資料の読み込み・要約・質問の基本手順
