Pマークの運用でつまずきやすいのがアクセス制御です。「アクセス権を適切に管理する」という方針は書けても、何をどこまでやれば「適切」なのかが規格に数値で書かれていません。この記事では、アクセス制御を3つの要素に分解し、それぞれで残すべき記録と抜けやすい対象を整理します。
アクセス制御は3つに分けて考える
まとめて捉えると手が付かないので、次の3点に分けます。
- 入れる範囲を絞る（必要最小限の原則）
- 変わったときに追従する（付与・変更・削除の手順）
- ずれていないか確かめる（定期的な見直し）
このうち抜けやすいのは3番目です。1と2は仕組みとして作られていることが多いのに対し、3は「やろうと思っていたが手が回らない」状態で止まりがちです。
1. 入れる範囲を絞る（必要最小限の原則）
個人情報にアクセスできる人を、業務上必要な人だけに限定するという考え方です。
「全員が見られる共有フォルダ」が典型的な問題
顧客情報を含むファイルが、全社員がアクセスできる共有フォルダに置かれているケースは珍しくありません。業務上は便利ですが、アクセスできる人数がそのままリスクの大きさになります。
まずどこに個人情報が保存されているかを洗い出すところから始まります。ファイルサーバー、各PCのローカル、クラウドストレージ、業務システムのそれぞれを確認する必要があります。
権限は「人」ではなく「役割」に紐づける
個人ごとに設定していくと、人数が増えるほど管理できなくなります。役割（部署・職責）に対して権限を定め、人を役割に割り当てる形にすると、異動時の変更が単純になります。
ID・アカウント管理の基本で全体の考え方を扱っています。
2. 変わったときに追従する
人は入社し、異動し、退職します。アクセス権はこの動きに追従しなければ、実態とずれていきます。
削除が最も抜けやすい
付与は業務が始まらないため必ず実行されますが、削除は忘れても誰も困りません。だから残ります。
退職者のアカウントが有効なまま残っている状態は、本人が使う可能性だけでなく、第三者に悪用されたときに気づけないという問題があります。
退職者アカウントの棚卸し、 入退社時のID管理の流れで手順を扱っています。
異動時は「追加」だけでなく「削除」も
異動では新しい部署の権限を追加しますが、元の部署の権限を外す作業が抜けがちです。異動を繰り返した社員が、社内で最も広い権限を持っているという状態が起こります。
これは審査で確認されやすい箇所です。台帳と実際の権限を突き合わせると露見します。
手順に組み込むべき連携
削除が漏れる原因は、人事の手続きと情報システムの作業が別々に動いていることです。退職の決定を、アカウント削除の担当者が知る経路が必要です。
様式は問いません。「退職の連絡票にアカウント削除のチェック欄を設ける」程度でも、経路として機能します。
3. ずれていないか確かめる（定期的な見直し）
手順を作っても、運用のどこかで漏れは発生します。定期的に突き合わせて、ずれを見つける工程が必要です。
確認する内容
- 台帳に載っているアカウントが、実際に存在するか
- 実際に存在するアカウントが、台帳に載っているか
- 在籍していない人のアカウントが残っていないか
- 各人の権限が、現在の業務に合っているか
- 管理者権限を持つ人が、把握している範囲に収まっているか
2番目が特に重要です。台帳を起点に確認すると、台帳に載っていないアカウント（検証用に作って放置されたものなど）は見つかりません。実機側からも突き合わせる必要があります。
具体的な進め方は IDの棚卸しと監査で扱っています。
頻度は「守れる範囲」で決める
毎月と定めて実施できなければ、記録が途切れます。半年に1回でも、実施した記録が連続している方が説明できます。規程に書いた頻度を守れているかが問われるので、実態より厳しい頻度を掲げるのは不利になります。
抜けやすい対象
社員のアカウントは管理されていても、次の対象が抜けているケースが多くあります。
| 対象 | 抜けやすい理由 |
|---|---|
| 保守ベンダーのアカウント | 契約終了後も有効なまま残る。社内の管理台帳の対象外になっている |
| 共有アカウント | 誰が使ったか特定できず、削除の判断もできない |
| サービスアカウント | システムが使うため人が紐づかず、棚卸しの対象から漏れる |
| ローカル管理者 | 各PCに個別に存在し、全台の把握が難しい |
| 派遣・業務委託の要員 | 契約終了の情報が情報システム担当に届きにくい |
それぞれ 委託先アカウントの管理、 共有アカウントの廃止、 サービスアカウントの管理、 ローカル管理者パスワードの管理で扱っています。
アクセス制御だけでは防げないこと
アクセス権を絞ることは有効ですが、正規の利用者のID・パスワードが盗まれた場合には効きません。権限を持つ本人としてログインされるため、アクセス制御の観点では正当な利用に見えます。
この点を代替措置として説明する際は注意が必要です。「アクセス権を最小化しているので認証は現状のままでよい」という説明は、成り立たない場合があります。
認証側の考え方は Pマークで二要素認証は必須かで整理しています。
よくある質問
アクセス権の見直しはどのくらいの頻度で行うべきですか
規格に頻度の指定はありません。規程で定めた頻度を守れているかが問われるため、実施できる頻度を定めて記録を継続する方が説明しやすくなります。
台帳はどこまで詳しく作る必要がありますか
誰がどのシステムにどの権限を持っているかが分かれば足ります。凝った様式にすると更新が止まり、実態とずれた資料になります。
共有アカウントを完全になくすのは難しいのですが
業務上残さざるを得ない場合は、利用者の範囲を限定し、利用の記録を残す運用にします。ただし個人を特定できない状態は残るため、その前提でリスクを評価した記録が必要になります。
いまの運用を棚卸ししてみる
アクセス権の管理は、どこから確認すればよいか判断しづらい領域です。applippliの無料棚卸しでは、10問・約3分で、ID・パスワードとアクセス権に関連する対応状況を、「解決済み／一部解決／人手で対応／未解決」に仕分けた一覧にできます。結果はPDFレポートでもお届けします。個人情報の入力は不要で、会員登録もありません。棚卸しに着手する前の現状把握にお使いいただけます。
参考・出典
※ 本記事は2026年8月時点で公表されている情報に基づく一般的な解説です。審査の運用や要求事項の詳細は変更される場合があります。個別の判断については、審査機関の案内をご確認ください。