ITシステムではアカウントが無ければ操作はできません。
逆に、アカウントがあれば何らかの操作ができます。
不使用のアカウントは悪意のある者からみれば使い勝手がよく狙われやすいので、削除して情報漏洩などを未然に防止することが管理上大事です。
当記事ではIT全般統制（Information Technology General Control[以下、”ITGC”と記述します]）におけるアカウント管理のうち、一般ユーザのアカウントの削除プロセスの構築方法を解説します。
当記事をご覧になることでアカウントの「削除」の統制の重要性や構築・運用について具体的に理解し実践に役立てられるでしょう。
ぜひ最後までお読みください。
「削除」の概要と位置づけ
「削除」とは、登録済みのアカウントが使用されなくなる場合に、そのアカウントを抹消する、または全ての権限を取り消し、実質的に利用不可能な状態（無効化）にすることを指します。
これは、退職、役職変更、業務終了など、アカウントの使用が不要となる事由に基づいて実施されます。
「削除」の位置づけ
ITGCではアクセス管理を一般に以下の統制項目で整備します。
- アカウント登録：新規ユーザの登録
- アカウント変更：ユーザの権限やアカウント情報を変更する
- アカウント削除：退職者等のアカウントや不要なユーザを削除する
- モニタリング：ユーザのアカウントの利用状況をチェックする（主に特権ID用の統制）
- ID棚卸：登録されているユーザが必要なユーザか、不要な権限がないかをチェックする
- パスワード管理：パスワードの設定、変更、ポリシー（複雑性、期限、履歴）を管理する
- 権限管理：付与される権限と役職・職務を管理する
当記事で解説する「削除」は上記の3)を指します。
（IT業務処理統制にもアクセス管理の統制があります。これはシステムを管理するものではないアプリケーションが対象でユーザ部門内でおよそ統制が完結するものが該当します。当記事では扱いません）
「削除」が必要となるケース
削除は、ユーザーの退職や出向あるいは異動によりアカウントを使わなくなるときに実行されます。
他にもID棚卸の統制の結果、長期使用されていないアカウントが検出された場合に削除を行うということもあります。
ただし、長期間使用されないアカウントを必ず削除しなければならないということではありません。
例えば育児休暇といったケースでは、アカウントのステータスをノンアクティブ状態にして削除はしないが利用不可能な状態・無効化する対応も行われます。
さらにアカウントを消してしまうと、削除されたアカウントの履歴まで消える仕様のシステムの場合には、削除せず無効化状態にするほうがよいこともあります。
内部統制の観点からは削除が原則ですが、システムの仕様に応じた対応や明文化したうえで例外を設けることは許容されるでしょう。
「削除」しないことのリスク
不使用アカウントを意図的に残すメリットは、システム管理やサイバーセキュリティの視点からはほぼありません。
現場思考では、
- 再度アカウントを1から作り直す手間をはぶける
- 削除の手間が省ける
- 外部に登録などの管理を委託しており即時に作れないから
といった理由があるのでしょうが、これは不正の温床、セキュリティホールでしかなく、いずれ必ずといっていいほどインシデントが発生します。
具体的なリスクは以下があります。
- 内部者が不正利用する
- 退職者が使用する
- 外部からの不正アクセスで利用される
内部者、外部者を問わず不正を誘発するおそれがあるのです。
さらに、特定のユーザに結びつかない＝事後的な調査ができないということになります。
何か不正が発生し、事後調査でログを調査したが、誰がアカウントを利用したかがわからないため調査が滞る、最悪そこで調査が行き詰まる可能性すらあります。
このような事態を予防するために「削除」は重要な統制なのです。
効果的な削除プロセスの構築
削除プロセスは不要なアカウントが残ることによるリスクに対する統制ですから、
必要なアカウント削除が確実に行われること
が統制の肝です。この統制目標を達成するために削除プロセスを整備します。
標準的なフロー
削除プロセスは一般に以下のフローで行います。
- 申請または人事情報をシステム部門へ通知する
- システム部門で削除前の承認
- 実機上で削除
- 削除のシステム部門の責任者の確認と承認
- （必要な場合）アカウント所持者、人事部門、所属部門へ削除の実施完了通知
以下、それぞれ解説します。
申請または人事情報をシステム部門へ通知する
削除プロセスのトリガーは、退職や部署異動などの人事情報または削除申請に基づきます。
多くの場合、人事部門からの通知が重要なトリガーとなります。
申請や通知はそれぞれ所属部門の責任者の承認を経たもので行いましょう。
申請書を使う、あるいはメールで通知しCCに承認者を含めておくなどで監査ログ（内部監査で検証するための証跡）とすることができます。
システム部門で削除前の承認
システム部門は、削除の対象となるアカウントや権限が正確かどうか確認し、システム部門の責任者が承認し、実際に削除する準備をします。
ここでのチェックでは、本当に削除していいのかを詳細にシステム部門が確かめるものではありません。
削除事由の詳細をシステム部門では管理しきれないこと、現実的ではないことから、違和感が無いかというレベルのチェックにとどまります。
実機上で削除
担当者が実機上のアカウントの削除を実行します。
必ずしも削除するわけではなく、アカウントの無効化による対応もここでは削除に含みます。
ここでは、削除すべきアカウントが全て削除されたことが重要なのです。
また、削除したことのわかる画面キャプチャなどを必要に応じて取得し監査ログを残しましょう。
削除のシステム部門の責任者の確認と承認
ここでの承認プロセスは、削除が正しく行われたか、削除履歴や監査ログが適切に記録されているかを確認することを含みます。
（必要な場合）アカウント所持者、人事部門、所属部門へ削除の実施完了通知
削除完了の通知はすべての関係者に送る必要はなく、状況に応じて実施されます。
たとえば、退職の場合は人事部門と所属部門への通知が主に必要であり、アカウント所持者（ユーザ本人）への通知は通常行わないことが多いです。
逆に、役割変更や業務終了の場合には、アカウント所持者にも通知されることがあります。
削除プロセスにおける一般的な課題と対策
削除プロセスには以下の理由により、統制がうまく機能しないことがあります。
- アカウントが大量にあり削除対応がもれること
- システム部門への削除依頼が通知されず、即時に削除されないこと
これが削除プロセスの課題です。
以下、課題の解説と対策を紹介します。
大量のアカウントがあり、削除対応がもれる
今では業務で利用するシステムやアプリケーションは数多くあります。
システム部門で保守・運用管理しているシステムだけでも複数あり、人員数もいる、退職・異動も多い、となれば管理する数は自然と多くなります。
とはいえ、削除と登録を繰り返すのが手間である、削除せず別のユーザ（例えば新入社員）に割り当てるために残しておいてはいけないのか、という考えは危険です。
削除の統制は、登録や変更と異なり、削除漏れがおきたら誰にも気づかずに放置されてしまうので、タイミングを逃すと延々と不使用アカウントが残るからです。
システム部門への削除依頼が通知されず、即時に削除されないこと
システム部門へ、アカウント削除の申請の提出忘れにより削除対応が遅れることが実務でよくあります。
アカウントの抹消申請は、管理上は会社側で行い、退職者に行わせないのが一般的です。
この削除申請が、他の業務を優先する・忘れるといった理由でシステム部門に送られないということが生じるのです。
2つの対策の紹介
削除の申請をシステムを利用した自動化による対策と定型化による対策を紹介します。
- システムを利用した自動化による対策
退職者リストや異動情報と連動した自動削除or通知システムの構築により削除プロセスのトリガーにするというものです。
また、上記に加えて一定期間アクセスのないアカウントの検知（あるいは異常なアクセスの検知）をシステムに組み込んで自動で調査依頼をする統制を整備しています。
人手を使わず自動・強制的に削除プロセスを始めることと、長期アクセスのないアカウントの割り出しによる調査で漏れなくアカウント削除を実施できます。
システムの導入・費用が必要ですが、システムを加えることで削除漏れの課題に対応しているのです。
- 定型化による対策
退職や異動のタイミングで人事部門から所属部門とシステム部門の両方に退職情報がメール等で送られるようにするという対策です。
所属部門に対してアカウントに対しての対応を促すこと、システム部門に対して削除プロセスが必要になる事案があることの準備を促す効果があります。
「所属部門からシステム部門へ削除申請が一定期間なければ、システム部門から削除不要なのかを問い合わせる」プロセスを組み込むことで削除漏れをある程度減らせるでしょう。
”システムを利用した自動化による対策”を手動で実施するプロセスを削除プロセスに組み込むというイメージです。
ID棚卸との連携
ID棚卸は、アカウント棚卸とも言われるアクセス管理の統制の1つです。
システム部門がシステムから出力したアカウント一覧を、ユーザ部門に送付し、ユーザ部門の責任者がアカウントがあることや権限の適否を回答するという統制です。
この統制により、アカウントに割り当てられた権限やアカウントそのもののチェックを行うことができます。
定期的なID棚卸の重要性
定期的なID棚卸によって、アカウントや権限の削除漏れ、登録プロセスや変更プロセスの間違いを修正する機会が得られます。
ただし、ID棚卸はアカウント数が多いことや、アカウントを1個ずつ手動でチェックするため業務への支障が大きく頻繁に行えません。
最低でも年1回はID棚卸を実施して、削除プロセスを補完しましょう。
ID棚卸結果の活用と継続的な改善
ID棚卸結果の際に、削除漏れや不適切な権限のアカウントが見つかることがあります。
見つかったときには、変更プロセスや削除プロセスを使い修正対応を行います。
ID棚卸で見つかったものも原則「登録・変更・削除」に則って対応し、監査ログを残すようにしましょう。
また、そのようになった原因を調査し、対応策を統制に組み込むことも検討してください。
継続的な改善活動は内部統制の効果的な運用に繋がります。
まとめ
当記事では一般ユーザのアカウント削除のプロセスについて解説しました。
- 削除プロセスの統制の位置づけ
- 削除プロセスの重要性
- 一般的な削除プロセスの紹介と構築時の注意点
- 削除プロセスの課題と対応
- ID棚卸との連携による統制の効率化
削除プロセスは登録・変更プロセスと同様に、ITGCで特に重要になるアカウントに関する統制です。
登録・変更・削除プロセスが適切に運用されていれば、不正とサイバーセキュリティに効果があり、メリットはITGC以外にもあります。
当記事が効果的な削除プロセスの整備・運用の支援となれば幸いです。
当記事は以上になります。
最後までお読みいただきありがとうございました。
記事を読んだ感想、質問、疑問点あるいはご指摘事項がありましたら質問フォームにご記載ください。
可能な限りご回答させていただきます。
コメント