組織のアクセス権限管理

組織内のアクセス権限を管理する

従業員は業務で、会社のメール、CRM、コードリポジトリ、クラウドストレージなどを使います。アクセス権限は依頼のたびに追加されがちです。その結果、現在の業務では使わない権限が残ったり、プロジェクトから離れた人のアカウントが有効なままになったりします。

アカウントが侵害されたり、重要なデータが誤って変更されたりしたとき、過剰な権限が被害を大きくする可能性があります。アクセスは、従業員がシステムを利用している期間を通して管理する必要があります。

まず、誰が何をするのかを決める

アクセスには二つの異なる確認があります。認証は、誰がログインしたのかを確認します。認可は、その人にどの操作を許可するかを決めます。

たとえば、顧客情報の閲覧は担当者に許可し、財務データの変更は限られたグループだけに許可できます。個々のシステムを設定する前に、こうした境界を明確にしておきます。

権限をロールにまとめる

従業員一人ひとりに個別の権限を設定していると、誰がどの理由でアクセスできるのか把握しにくくなります。ロールを使うと管理しやすくなります。業務内容ごとに権限をまとめ、必要なロールを従業員に割り当てます。

たとえば、編集者は記事の作成や修正を行い、編集責任者は公開も行えるようにできます。RBACでは権限をロールに割り当て、利用者はそのロールを通じてアクセスします。NISTはRBACを、ロールとその権限に基づくアクセス管理として説明しています。

必要最小限の権限を付与し、追加には理由を求める

私の基本方針は、従業員に現在の業務に必要な権限だけを最初に付与することです。標準の範囲を超えるアクセスが必要な場合、申請には必要な業務、対象となるデータやシステム、利用する期間を明記します。

*「使うかもしれない」*という理由だけでは不十分です。追加権限はシステムの責任者やプロジェクトリーダーの承認を得て、必要な範囲に限定します。作業が終わったら、そのために追加した権限を取り消します。

Webアプリケーションでは、保護対象の操作をサーバー側で毎回確認する必要があります。画面上のボタンを隠すだけでは、アクセス制御になりません。新しい操作に対するルールがまだ決まっていない場合は、デフォルトでアクセスを拒否する方が安全です。この考え方はOWASP Authorization Cheat Sheetでも推奨されています。

作業が終わったらすぐにアクセスを取り消す

従業員がプロジェクトの作業を終え、今後参加しない場合は、プロジェクト関連システムへのアクセスをすぐに取り消します。定期的な権限レビューまで待つ必要はありません。コードリポジトリ、クラウド環境、ドキュメントなどが対象です。

別のチームへ異動した場合は、新しい業務に合わせて以前の権限を見直します。組織を退職する場合は、アカウントと社内システムへのアクセスをすぐに停止します。これはNIST SP 800-53のAC-2に記載されたアカウント管理の考え方にも沿っています。

日常業務と管理者権限を分ける

通常の業務に管理者権限は必要ありません。強い権限は、それが必要な作業に限って使います。管理者アカウントやリモートアクセスには多要素認証を有効にします。CISAも、通常アカウントと特権アカウントを分け、付与した権限が引き続き必要か定期的に確認することを推奨しています。CISAの組織向けガイダンス。

従業員ごとに個別のアカウントを用意します。共有ログインでは、誰が操作したのか分かりにくくなり、問題の調査も難しくなります。

重要な操作の責任を分ける

一部の操作には追加の確認が必要です。たとえば、一つのアカウントで支払いの作成から承認まで完了できる状態はリスクがあります。

こうした操作を複数の担当者に分けると、ミスや不正のリスクを抑えられます。重要な手続きでは、誰が実行し、誰が承認するのかを決めておきます。

権限管理の担当者を決める

各システムについて、誰がアクセスを承認し、誰がロールを割り当て、誰が内容を見直すのかを明確にします。まず、システム、ロール、担当者を一覧にすると現状を把握しやすくなります。

そのうえで、管理者権限を持つ人、プロジェクトを離れた人の有効なアカウント、業務変更や退職時の対応を確認します。

アクセス権限は、その人の現在の業務に合わせて管理します。 業務が終われば、その業務のために付与した権限も取り消します。