IT管理に関わらず、アクセス権を管理するアカウント管理はとても重要です。
アクセス権がなければ、鍵の閉まった部屋に鍵無しで入るようなもので、中にはいれなくなります。
また、誰がアクセス権を持っているのか、どこから入れるのかが管理されていれば、インシデント発生時の対処が早くできるでしょう。
当記事ではIT全般統制（Information Technology General Control[以下、”ITGC”と記述します]）におけるアカウント管理のうち、一般ユーザのアカウントの登録と変更プロセスの構築方法を解説します。
当記事をご覧になることでアカウントの「登録」「変更」統制の重要性や構築・運用について具体的に理解し実践に役立てられるでしょう。
また内部統制の評価をされる方にとっても評価ポイントの抑え方を理解できるようになります。
ぜひ最後までお読みください。
アクセス管理の概要と「登録」と「変更」の位置づけ
「登録」は、新規ユーザがシステムやアプリケーションにアクセスできるようにするための初期プロセスを指します。
「変更」は、登録済みのユーザアカウントに対して、何らかの修正や調整が行われるプロセスを指します。
「登録」と「変更」の位置づけ
ITGCではアクセス管理を一般に以下の統制項目を整備します。
- アカウント登録：新規ユーザの登録
- アカウント変更：ユーザの権限やアカウント情報を変更する
- アカウント削除：退職者や不要なユーザを削除する
- モニタリング：ユーザのアカウントの利用状況をチェックする（主に特権ID用の統制）
- ID棚卸：登録されているユーザが必要なユーザか、不要な権限がないかをチェックする
- パスワード管理：パスワードの設定、変更、ポリシー（複雑性、期限、履歴）を管理する
- 権限管理：付与される権限と役職・職務を管理する
当記事で解説する「登録」は1）、「変更」は2）を指します。
（IT業務処理統制にもアクセス管理の統制があります。これはシステムを管理するものではないアプリケーションが対象でユーザ部門内でおよそ統制が完結するものが該当します。当記事では扱いません）
「登録」が必要となるケース
システムを利用するためにはユーザとして登録されていなければ基本的には使用できません。
新規入社する人はアカウントを持っていないので、人事名簿に登録するのと同様にITシステムへアカウントの「登録」を行います。
また、異動で新たな部署に配属されたときに、社内にはアカウントはあるけれども、配属後の部署で使用するシステムのアカウントや権限がない場合にも「登録」を行います。
これから利用するシステムに全くアカウント情報が無い場合には「登録」プロセスを通すものだというイメージです。
「変更」が必要となるケース
役職が変わったとき、担当業務が変わったとき、異動したときには業務に必要なシステムの機能も変わります。
この時に、不要になった権限を削除し、必要な権限を付与することが「変更」です。
登録・変更プロセスのリスクと統制の必要性
権限の付与は「Need to Know」の原則に従って付与します。
これは、ユーザーのアクセスできる情報を、そのユーザーの職務に関連する範囲にのみ制限すべきというもので、情報漏洩対策の大原則として扱われています。
例えば、同じ部署のメンバーでも、
- 入力業務担当者には「入力」権限をもたせる
- 上長は承認する責任があるので「承認」権限をもたせる
- その他のメンバーはデータを利用するのみで「閲覧」権限のみもたせる
というような割り当てをします。
この原則はプログラムやデータの改ざん・消失、誤操作といったインシデントに対しても効果があることはイメージが付くでしょう。
もし必要以上に権限を付与すると以下のようなリスクがあります。
未承認アクセスのリスク
未承認のアカウントや権限があると、そのアカウントを持つものだけではなく、第三者が侵入して利用されるおそれもあります。
また誰が使っているのかわからないアカウントは、アカウントの使用履歴が残っていても、具体的に「誰」が使ったのかかがわからない状態になり、追跡できません。
いわゆる野放し状態のアカウントはリスクでしかありません。
ただし、特権IDのアカウント管理の場合は、特権IDを複数作るのは望ましくないので、1個の特権IDを作成し複数人で使う、いわゆる共有IDで運用するケースがあります。
共有IDを運用する場合は、この記事で解説する統制に追加の統制を用意して対応します。
特権IDに関してはこの記事では扱いませんが、特権IDの統制時には意識しておきましょう。
不適切な権限付与・変更のリスク
必要以外の権限を持つと、不正のような意図的なリスクに繋がるほか、誤操作によるリスクがあります。
善意で同僚が困っているから以前の部署のシステムにアクセスしてちょっと手助けしよう、と操作をしたら、内部統制上は重大なインシデント扱いになります。
アクセスすべきでは無いものが、システムにアクセスして重要なデータに触れた、触れることができるというのは統制が効いてない以外の解釈が難しいのです。
このため、操作できない状態にしてリスクを避けなければなりません。
統制のメリット
登録・変更プロセスの統制はセキュリティ強化、コンプライアンス遵守の支援となります。
また、統制が効いていれば、データの信頼性が増しますから、内部監査対応も外部監査対応も簡素化できるメリットがあります。
効果的な登録・変更プロセスの構築
ITGCのアクセス管理なので、
- 利用者であるユーザ部門が申請し、
- 保守・運用を担うシステム部門が実機・システムにアカウントを登録・変更作業を行う
前提で具体的な統制を解説します。
標準的なフロー
登録・変更共に以下のフローで行います。
- 申請書の作成
- 所属部門の管理責任者による承認
- システム部門による登録前の承認
- アカウント登録・変更の実施
- システム部門責任者による内容の確認・承認
- 所属部門・申請者への通知
それぞれ解説します。
- 申請書の作成
統制の証跡も兼ねて申請書を作成し、回覧する方法で統制フローを辿っていくのが通常です。
「登録」の場合は、新入社員の場合は本人ではなく人事部か所属部門が作成します。
「変更」の場合はすでに社内の人員ですので、本人で作成する場合もあれば新旧の所属部門で作成することもあります。特段の決まりはありません。
- 所属部門の管理責任者による承認
作成された申請書は所属部門の管理責任者による承認を必要とします。
ユーザが所属する部門が最も必要な権限について詳しいため、所属部門の管理責任者が確認し、承認をします。
「変更」の場合は、従前の所属部門で使用する権限は全て削除するのが一般的です。
引き継ぎ業務が終わっていない等の事情がある場合が考えられますので、そのときは期限を決めて削除の依頼を出させるといった例外対応になります。
不要な権限が残るのは「変更」「削除」が適切になされないことがよくある原因なので要注意です。
- システム部門による登録前の承認
所属部門の管理責任者の承認を経たら、システム部門の責任者がアカウント登録前の承認をします。
システム部門の責任者が確かめるのは、所属部門で使うシステムの申請であるか、管理権限の付与なのか、といった大枠の事項のチェック事項です。
この理由は、システム部門ではユーザ部門でアカウントや権限を付与される人が細かい権限を持つのに適切かどうかは把握していない、把握しきれないためです。
明らかに異常であれば却下、ないしは所属部門に問い合わせる対応をとります。
- アカウント登録・変更の実施
実機にシステム部門の担当者がアカウントの登録ないし変更を行います。
- システム部門責任者による内容の確認・承認
実機に申請書の内容を反映したら、システム部門責任者がチェックと承認をします。
申請書はこの統制の段階で次の通知したことを記載し、システム部門が保管します。
- 所属部門・申請者への通知
所属部門と申請者に対し、システムへの反映が終わったことを通知します。
ユーザはシステムを利用できることを実機で操作し、登録や変更されたことを確かめます。
メールや社内連絡ツールで行うことが多いです。
監査項目、注意点
監査側からの監査項目、注意点を以下に列挙、一部解説します。
- アクセス権の申請は適切に行われているか
- 業務上の必要性をチェックしているか
- 管理者がアクセス権の承認をしているか
- 申請は適時に行われているか
- 申請・承認・実機登録の時系列は正しいか
- 申請者と承認者が別人か
「申請は適時に行われているか」
「変更」や「削除」で重要なポイントに、放置されているアカウントや権限がないかというものがあります。
忙しいといった理由で1ヶ月以上放置されるケースは稀にあり事情を調査し考慮したうえで対応しますが、半年や1年も放置されていれば監査上は不備と評価せざるをえません。
「申請・承認・実機登録の時系列は正しいか」
急ぎの申請で時系列が統制の順番どおりではないことがよくあります。
統制の順番が前後することは、統制が効いてないか適切でないということになります。
急ぎということでしたら、不適切な権限の付与ではない・例外対応するに相当の理由があるという証拠を書類（メールも可）なりで残しましょう。
監査人が何と言うかは判断できませんが、口頭ですませて証跡はない、というのは不備・指摘事項となるでしょう。
「申請者と承認者が別人か」
内部統制の承認行為はダブルチェックが原則です。
人手不足の昨今、この原則を貫くのは難しいのですが、できるかぎり守っていただきたいルールです。
同じ部署にいなければ、事情のわかる近くの部署の人に頼むなどの対応をとり、その旨を備考欄に記しておくといった経緯を残すといった対応をしましょう。
効果的な申請書類の設計
内部統制は実施した証跡を残さなければなりません。
アカウントの登録・変更・削除はリスクは異なりますが似た統制ルートを辿るため同一の様式で行うことが多いです。
申請書類に必須の事項、追加であるとよいものを解説します。
必須記載事項
- 所属部門、申請者名
- 申請種別（登録/変更/削除のチェックボックス【一般に削除も同じ申請書を使うことが多い】）
- 承認者情報（所属部門、システム部門）
- 実機登録・変更者
- 日付（申請日および承認日、登録日）
- 付与・変更する権限詳細
- 申請理由
内部統制上、そして監査上のチェックポイントは、
- 統制フロー通りに実施されたか
- 誰が承認したか
- いつ承認したか
- 適切な事由に基づいているか
これらのチェックに耐えうる記載事項が上記の項目です。
状況に応じた追加項目
必須ではありませんが、登録時や事後的なチェックがしやすくなるため以下の2項目は追加で記載してもよいでしょう。
- ユーザID（変更の場合）
- 権限の有効期限
「権限の有効期限」は、期限ごとに申請を行わなければならなくなりますが、引き継ぎで延長する、有期雇用の者や時限付きの委託先に権限を付与する場合には申請漏れによる対応忘れの備えになります。
管理方法・ツールの利用の検討
ここでは管理運用手段・ツールの話を解説します。
内部統制の構築の際の検討事項として参照してください。
電子申請システムの利用
申請は紙面による管理とアプリ管理の二通りあります。
小規模組織でなければ、専用の電子申請システムの利用をすすめます。
理由は、システムの保守・運用部門が登録作業を行う場合、対応すべき一般ユーザの申請は当然多数になります。
管理しているシステムも複数あるため、単純にシステム数✕ユーザ数の申請数になるでしょう。
また、
- 遠隔から申請する場合に対応できる
- システムを変更しても登録ほかの統制は残るので次の統制にも利用可能
- 紙面は記入者次第で文字の読み取りの難易度問題が生じる
といった利点があげられます。
サブスクリプションでコストがかかるものを選ぶ必要はありませんし自社作成でも問題ありません。
PDF形式での申請書管理
”監査上項目、注意点”で解説した監査上のポイントに「時系列通りか」というものがあります。
時系列通りであることを証明するため、そして上書きによる誤修正や改ざんしていないことの証明となるようPDF形式での申請書管理をすすめます。
Excelでの申請書もありますが、改ざんされてはいけませんし、上書き保存されて申請書がなれば困りますし、統制が無効化されているともみられてしまいます。
小規模組織での代替手段（Excelを利用した場合の注意点）
小規模組織の場合、Excelを利用するほうが費用対効果に優れていることもあります。
Excelを利用する際には、改ざん、データの消失、複製による混乱に主に注意してください。
以下に対応策の例を提示します。
- セルのロックとシート保護: 重要なデータや承認欄などは、セルのロックやシート保護機能を使って編集できないように設定する。
- パスワード保護: Excelファイル全体にパスワードをかける。
- 変更履歴の保存: ファイルに対する変更履歴を残すため、Excelの「変更履歴」機能を有効にするか、バージョンごとにファイルを保存して記録する。
- ファイル名にバージョン情報を含める: いつ誰が修正したのかを分かりやすくするために、ファイル名に日付やバージョン番号を含める。
- アクセス権限の設定: 申請書を管理するフォルダやファイルに対して、閲覧や編集の権限を厳格に設定し、無関係な人がアクセスできないようにする。
- クラウドストレージの利用: ExcelファイルをローカルPCのみに保存するのではなく、共有フォルダやクラウドストレージ（例: OneDrive、Google Drive）に保存して、一元管理する。
- 定期的にバックアップを作成: 申請書や承認書類の重要性に応じて、定期的にバックアップを作成し、別の安全な場所に保管する。
- 定期的な保存: 重要な申請書類の入力が完了するたびに、こまめに保存することを促すルールを作る。
モニタリングと定期的なID棚卸
ITGCのアクセス管理の統制にはモニタリングとID棚卸があることは”「登録」と「変更」の位置づけ”の中で解説しました。
「登録」「変更」は予防的統制に分類されるのに対し、「モニタリング」「ID棚卸」は発見的統制に分類され統制が有効であるか、異常が無いかを事後的に検証するものです。
モニタリングとID棚卸を行うことで登録・変更プロセスの有効性を評価し、必要に応じて改善し統制の有効性を高めましょう。
まとめ
当記事では、IT全般統制（ITGC）におけるアクセス管理、特に一般ユーザーアカウントの登録・変更プロセスと統制の構築について詳しく解説しました。
以下に重要なポイントをまとめます：
- アクセス管理の重要性：
- 適切なアクセス権限管理はセキュリティとコンプライアンスの基盤になる
- 「Need to Know」の原則に基づいた権限付与
- 効果的な登録・変更プロセス：
- 標準的なフローには申請、承認、実施、確認、通知の段階がある
- 各段階で適切な責任者による承認と確認
- リスク管理：
- 未承認アクセスや不適切な権限付与のリスクを認識し、対策を講じる
- 申請書類の設計：
- 必須記載事項と状況に応じた追加項目を適切に設定する
- 具体的な管理方法：
- 電子申請システムの利用やPDF形式での管理を推奨
- 小規模組織ではExcelも可能ですが、データの完全性に注意
適切なアクセス管理は、組織の情報セキュリティとコンプライアンスの基盤となります。
本記事で解説したプロセスと統制方法を参考に、自組織に適したアクセス管理体制を構築・運用することで、より安全で効率的なIT環境を実現できるでしょう。
最後に、アクセス管理は「登録」「変更」だけでなく、「削除」のプロセスも同様に重要です。
退職や異動に伴う適時の権限削除は、セキュリティリスクを大きく軽減します。
「削除」プロセスについても、別記事で解説予定ですが、本記事で解説した原則を応用し、適切な統制を設けることをお勧めします。
当記事は以上になります。
最後までお読みいただきありがとうございました。
記事を読んだ感想、質問、疑問点あるいはご指摘事項がありましたら質問フォームにご記載ください。
可能な限りご回答させていただきます。
コメント