WEB & SYSTEMS

アクセス権の棚卸しと特権IDの管理の進め方

アクセス権の管理は、入社・異動・退職のときの手続きと、定期の棚卸しと、特権IDの管理の3つで考えると整理できます。監査で確かめられやすい点と、記録の残し方まで含めて説明します。

この記事の要点

  • 入社・異動・退職のたびに権限を変える手続きと、定期の棚卸しの両方で、権限のずれを防ぐ
  • 共用の管理者アカウントは持ち主を決め、使った人と操作を後からたどれるようにする
  • 監査では「決まり」だけでなく、実際に行った記録(申請・承認・棚卸しの結果)を確かめられる

アクセス権の管理は、入社・異動・退職のときに権限を付け外しする手続き、定期にいまの権限を見直す棚卸し、強い権限を持つ特権IDの管理、の3つで考えると整理できます。どれか一つだけでは、退職した人のアカウントが残る、異動の前の権限が積み重なる、といったずれを防ぎきれません。

アクセス権の管理で何を防ぐのか

アクセス権の管理で防ぎたいのは、必要のない人が情報やシステムに触れられる状態です。原因の多くは、悪意ではなく手続きの抜けにあります。退職の連絡が情報システムの担当に届かない、異動のときに新しい権限だけを足して古い権限を外さない、委託先の担当が交代したのにアカウントがそのまま、といったことです。

認証と認可の言葉でいえば、本人かどうかを確かめる認証と、何をしてよいかを決める認可のうち、アクセス権の管理は主に認可の側の話です。ただし、認証が弱ければ権限の管理も意味を失うため、両方をあわせて考えます。

金融庁の内部統制の実施基準では、IT全般統制の例の一つに「内外からのアクセス管理などシステムの安全性の確保」が挙げられています。財務報告に関わるシステムでは、IT全般統制の中心的な確認点の一つになります。

出典:財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について(意見書)(金融庁、2023年4月7日)

入社・異動・退職のときに、何をするか

権限の変わり目は、入社・異動・退職の3つです。英語では joiner・mover・leaver と呼ばれることもあります。それぞれで決めておくことを表にまとめます。

場面主にすること抜けやすい点
入社職務に必要な権限だけを、申請と承認を経て付ける「前任と同じ権限」で、不要な権限まで引き継ぐ
異動新しい職務の権限を付け、前の職務の権限を外す新しい権限だけを足し、古い権限が残る
退職最終の出社日に合わせてアカウントを止め、後で削除する人事の連絡が遅れる。クラウドのサービスが漏れる

退職のときの流れ

退職のときは、人事の情報を起点にして、止めるところまでを一続きの手順にしておくと抜けが減ります。

  1. 人事の担当が、退職の日を情報システムの担当に知らせる
  2. 情報システムの担当が、その人が使っているシステムとアカウントを一覧で確かめる
  3. 最終の出社日に、アカウントを止める(削除はデータの引き継ぎの後でもかまいません)
  4. 止めたことを記録し、上長か管理の担当が確かめる

退職のときに、アカウントを止めるまでの流れ

  • 人事の担当退職の日を、情報システムの担当に知らせる
  • 情報システムの担当その人が使っているシステムとアカウントを、一覧で確かめる
  • 最終の出社日アカウントを止める(削除はデータの引き継ぎの後でもかまいません)
  • 記録と確認止めたことを記録し、上長か管理の担当が確かめる

人事の情報を起点にして、止めるところまでを一続きの手順にしておくと、抜けが減ります

社内のシステムだけでなく、部署ごとに契約したクラウドのサービスも対象にします。シングルサインオン(SSO)でログインをまとめておくと、入口のアカウントを止めるだけで多くのサービスに入れなくなり、止め忘れを減らせます。

定期の棚卸しは、どう進めるか

アクセス権の棚卸しとは、いま付いている権限の一覧を、定期に、権限を持つ人の上長やシステムの持ち主に見てもらい、必要かどうかを確かめることです。入社・異動・退職の手続きで漏れたものを拾う役割があります。

進め方の例です。

  1. システムごとに、アカウントと権限の一覧を取り出す
  2. 人事の情報(在籍・所属)と照らし合わせ、退職者や所属の違う人を印にする
  3. 上長やシステムの持ち主が、権限ごとに「要る・要らない」を判断する
  4. 要らない権限を外し、外したことを確かめる
  5. 一覧、判断の結果、外した記録を残す

頻度は、システムの重要さに合わせて決めます。財務報告や個人情報に関わるシステム、管理者の権限は、ほかより間隔を短くすることが一般的です。棚卸しの結果、見直しをした人の名前と日付が残っていないと、後から「行った」ことを示せません。

一覧を見る人が、権限の名前だけでは中身が分からないこともあります。権限ごとに「何ができるか」を短く書いた説明を添えると、判断がしやすくなります。

特権IDは、なぜ別に管理するのか

特権IDとは、システムの設定の変更、利用者の追加、データの書き換えなど、強い操作ができるアカウントのことです。サーバーやデータベースの管理者のアカウント、クラウドの管理画面の最上位のアカウントなどが当たります。誤って使っても、不正に使われても影響が大きいため、ふつうのアカウントとは別の決まりで管理します。

共用の管理者アカウント

製品の初期設定のアカウントなど、複数の人で一つの管理者アカウントを使っている場合は、だれがいつ使ったかが分からなくなります。次のような手当てが考えられます。

  • できるだけ、一人ひとりに個人の管理者アカウントを発行し、共用のアカウントを使わない
  • 共用が避けられない場合は、持ち主(管理の責任者)を決め、パスワードを保管の仕組みに入れて、貸し出しの記録を残す
  • 使った後はパスワードを変える、または一時的な権限で済ませる

非常用のアカウント

障害のときなど、ふだんの手順では入れない場面のために、非常用のアカウント(英語では break-glass とも呼ばれます)を用意することがあります。使う条件、使ってよい人、使った後の報告と見直しを決め、ふだんは使われていないことを確かめられるようにします。

操作の記録

特権IDで行った操作は、ログとして残し、定期に見直します。ログを見られる人と、特権IDを使う人が同じだと、記録を消したり書き換えたりできてしまうため、置き場所と閲覧の権限を分けます。

多要素認証は、どこから入れるか

多要素認証(MFA)は、パスワードに加えて、スマートフォンのアプリや専用の鍵などを組み合わせて本人を確かめる方法です。すべてのシステムに一度に入れるのが難しい場合は、社外から使えるサービス、管理者のアカウント、クラウドの管理画面から始めると、影響の大きいところを先に守れます。

社内のネットワークの中にいるから安全、とは考えずに、一回ごとに確かめる考え方はゼロトラストと呼ばれます。アクセス権の管理と多要素認証は、その土台になります。Webシステムのほかの対策はWebシステムのセキュリティ対策の基本にまとめています。

監査では、何を見られるのか

システム監査や内部統制の評価では、決まりがあるかだけでなく、決まりのとおりに行われた記録があるかを確かめられることが一般的です。主に求められやすい資料の例です。

確かめる点資料の例
権限の付与申請と承認の記録、承認した人と日付
退職者の削除人事の退職者の一覧と、アカウントを止めた記録の照合
定期の棚卸し取り出した一覧、見直した人と日付、外した記録
特権ID特権IDの一覧と持ち主、貸し出しの記録、操作のログと見直しの記録
多要素認証設定の画面、対象外のアカウントとその理由

監査人は、退職者の一覧から何人かを選び、それぞれのアカウントがいつ止められたかをたどる、といった確かめ方をすることがあります。申請と承認がワークフローの仕組みなど日時の残る形で記録されていると、後から作った記録ではないことを示しやすくなります。上場の準備の確認点は上場準備で整えるIT全般統制もご覧ください。

記録がそろっていない場合は、どこから始めるか

これまで記録を残していなかった場合は、すべてを一度にそろえようとせず、影響の大きいところから始めます。

  1. 財務報告、個人情報、顧客のデータに関わるシステムを選ぶ
  2. そのシステムのアカウントと権限の一覧を取り出し、人事の在籍者の一覧と照らし合わせる
  3. 退職者や持ち主の分からないアカウントを止め、止めた記録を残す
  4. 特権IDの一覧を作り、持ち主を決める
  5. 次の回から、申請と承認、棚卸しの記録を同じ形で残す

最初の棚卸しで見つかったずれは、過去の手続きのどこに抜けがあったかを示す手がかりになります。止めて終わりにせず、入社・異動・退職の手続きのどこを直すかまで考えておくと、次の棚卸しで同じずれが見つかりにくくなります。

当社のご支援

アメリア・テクノロジーのシステム監査では、アカウントと権限の一覧、入社・異動・退職の手続き、特権IDの管理の記録を確かめ、改善の優先順位とあわせてご報告します。当社が開発・運用に関わったシステムは監査の対象にせず、監査と改善の担当も分けています。直す作業をどこに頼むかは、お客様が自由に決められます。

  • アクセス管理
  • 特権ID
  • IT全般統制
  • セキュリティ

この記事に出てくる用語

この記事を書いた人

石田 誠 フロレンティナ 取締役CTO

インターネットの黎明期から、ホスティング事業の立ち上げや、インフラ・セキュリティのプロジェクトに携わってきました。現在は、AWS・Azure へのクラウド移行の支援と、業務アプリケーションの要件定義から実装までを担っています。

このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。

あわせて読みたい

Webとシステム開発のコラムを見る コラムの一覧に戻る

無料で相談する無料の診断