3.4アクセス管理と認可（最小権限・RBAC・特権ID管理・ログ管理）

「アクセス管理」という言葉は漠然と使われがちですが、実務では識別・認証・認可という3つの異なる工程を区別することが出発点です。「あなたは誰と名乗るか（識別）」「それは本当に本人か（認証）」「その人に何を許可するか（認可）」は、それぞれ異なる仕組みで実現され、認証が突破されても認可の設計次第で被害を限定できるという関係にあります。この節ではこの3工程を軸に、権限をどう絞り、誰がどこまで見られる状態を保つかという管理策を整理します。

3.4.1識別・認証・認可の違い

• 識別（Identification）＝利用者が「自分は誰であるか」を名乗る工程（例: ユーザーIDの入力）。認証（Authentication）＝名乗った本人が「本当にその人物か」を確認する工程（例: パスワード・生体情報・多要素認証による検証）。識別は「主張」、認証は「証明」という違いがある。
• 認可（Authorization）＝認証で本人確認が済んだ利用者に対し、「何を・どこまで許可するか」を決定する工程（例: あるファイルへの読み取りは許可するが書き込みは許可しない）。認証が成功しても、認可の設定次第でアクセスできる範囲は限定される。この3工程は連続しているがそれぞれ独立して設計・監査すべきという理解が重要。
• 具体例で確認＝社員証番号を入力する（識別）→ 指紋認証で本人と確認する（認証）→ 経理部権限を持つため会計システムの参照は可のみで承認操作は不可（認可）。認証を突破されても、認可が適切に絞られていれば被害を限定できるという多層の考え方につながる。

3.4.2最小権限・RBAC・特権ID管理・アカウントライフサイクル・ログ管理

• 最小権限の原則（Principle of Least Privilege）＝利用者に業務遂行に必要な最小限の権限だけを付与する考え方。知る必要性（Need-to-know）＝権限の有無だけでなく、その業務上「知る必要がある」情報だけにアクセスを絞る考え方（権限があっても業務上不要なら見せない）。「念のため広めに権限を与える」運用はリスクを増大させるという理解が重要。
• RBAC（Role-Based Access Control・役割ベースアクセス制御）＝利用者個人にではなく、「role（役割）」に権限を割り当て、利用者をその役割に所属させることで間接的に権限を管理する方式。異動・退職時は役割の割り当てを変更/解除するだけでよく、個人ごとの権限を一つ一つ棚卸しする必要がないため、権限管理の一貫性と運用効率を両立できる。
• 特権ID（管理者ID）＝システムの設定変更・他利用者のアカウント操作等、強力な権限を持つアカウント。一般利用者IDと比べ悪用時の被害が甚大なため、利用の都度申請・承認を要する（常時付与しない）、利用ログを個人単位で厳格に記録、共有アカウントとして複数人で使い回さないといった厳格な管理（特権ID管理）が必須。
• アカウント管理のライフサイクル＝入社（付与）→異動（見直し）→休職/退職（無効化・削除）という一連の管理プロセス。特に退職者アカウントの削除・無効化が遅れると不正アクセスの温床になるため、人事情報と連動した速やかな棚卸しが重要。ログ管理と監視＝認証・認可の記録（誰が・いつ・何にアクセスしたか）を改ざん困難な形で保全し、定期的な棚卸し・異常検知（通常と異なる時間帯のアクセス等）を行うことで、事後追跡と不正の早期発見を支える。

ある企業で発生した内部不正の事案を通じて、アクセス管理の設計思想を確認しましょう。退職した元従業員のアカウントが、退職後も人事システムとの連携不備により1か月以上無効化されないまま残っていたことが判明しました。この元従業員は在職中、経理部門に所属し会計システムへのアクセス権を持っていましたが、退職後にそのアカウントの識別子（ユーザーID）とパスワードを使い、認証を突破して会計システムへ不正ログインしました。しかし調査の結果、実害は限定的でした。理由は、このアカウントにはRBACにより「経理部門・一般担当者」という役割が割り当てられており、その役割の認可は会計データの参照のみで、承認や送金操作といった強力な操作は不可という設計になっていたためです。承認権限や資金移動といった重要な操作は、特権IDに相当する別区分のアカウントでのみ可能で、しかもその特権IDは利用の都度、上長への申請・承認が必要な運用だったため、退職者アカウントでは操作できませんでした。この一件を受けて、企業は2つの再発防止策を講じました。1つはアカウント管理のライフサイクルの徹底で、人事システムの退職処理と連動し、退職日当日にすべてのアカウントを自動的に無効化する仕組みを導入しました。もう1つはログ管理と監視の強化で、通常の業務時間外・休日のログインといった異常なアクセスパターンを自動検知しアラートを出すしくみを導入し、今回のような不正ログインをより早期に発見できる体制にしました。この事例が示すように、認証（本人確認）だけに頼らず、認可の範囲を役割に応じて最小限に絞り、アカウントのライフサイクルとログ監視で多層に守ることが、実務でのアクセス管理の要諦です。

3.4.3この節のまとめ

• 識別=名乗る／認証=本人確認／認可=許可範囲の決定。この3工程は独立して設計・監査する
• 最小権限＋知る必要性で権限を絞る。RBACは役割に権限を割り当て個人はその役割に所属
• 特権IDは利用の都度申請・個人単位でログ記録。退職者アカウントは速やかに無効化、ログ監視で異常を早期検知