組織はアクセス制御において職務分離をどのように強制できますか？

アクセス制御における職務分離

職務分離と職務の分割は、異なる名前ですが同じ管理手法です。監査人は「segregation」と言い、ITチームは「separation」と言う傾向があります。どちらも同じ意味で、重要なプロセスを一人の人間が最初から最後まで二重チェックなしで行ってはいけないということです。

同じ従業員がベンダーを作成し、そのベンダーの支払いを承認し、アカウントを照合できる場合、その取引を独立してチェックするものはありません。SoDは各ステップを異なる役割に割り当てることでチェーンを断ち切ります。SOXは財務報告に関わるすべてにこれを要求し、監査人は紛争が一度だけ文書化されて保管されるのではなく、継続的に監視されている証拠を求めます。

職務分離を強制する方法

まずはコンフリクトをマッピングしましょう。 一人の人物に持たせるべきでない役割や権限のペアをリストアップした職務マトリックスを作成します：vendorの作成とvendor支払いの承認、購入注文の作成とその承認、アクセス要求と同じアクセスの承認。見落とされがちなペアが一つあります：アクセス制御の管理とそれを監査するログの管理です。アクセス権を付与し、誤用を検出するためのログを編集できる管理者は、ログ記録の目的を完全に無効にしています。

人ではなく職務機能に基づいて役割を構築します。 衝突するものがわかったら、個人ではなく役割ごとに権限を割り当て、各役割に必要なものだけを与えます。 最小権限 はここで2つのことを行います。追跡すべき衝突の組み合わせを減らし、アカウントが侵害された場合の被害範囲を制限します。

防止することと検知することを決めてください。 静的コントロールは、矛盾する割り当てが発生する前に阻止し、誰かが互換性のない2つの役割を持つことを防ぎます。動的コントロールは割り当てを通しますが、フラグを立てるか、特定の取引に対して2人目の承認を要求します。ほとんどの組織は両方を必要とします。明らかな矛盾は完全にブロックしてください。包括的なルールでは対応できないグレーゾーンには独立した承認を使いましょう。

高リスクの操作には二人目の担当者を必須にしてください。 役割で完全に分離できないものについては、完了前に独立した承認を求めてください。一人が開始し、別の人が承認します。支払いの解放、コードの展開、または財務管理に関わる変更に適用してください。

可能な限り集中管理しましょう。 システムが多いほど、一貫した適用が難しくなります。厳格な役割で1つのシステムからロックアウトされたユーザーでも、誰も確認しなかった別の場所でアクセス権を持っている可能性があります。可能な場合は、単一のレイヤーでアクセスを管理し、システムごとに再構築されるのではなく、同じポリシーをすべての場所に適用しましょう。

問題が発生したときではなく、スケジュールに沿ってアクセスを見直しましょう。 役割は変化します。人は仕事を変え、一時的な責任を引き受け、誰も付与した覚えのないアクセス権を蓄積します。定期的なレビューを設定し、各役割がまだ仕事に合っているか確認し、不正なアクセスは追跡しましょう。

真の分離が不可能な場合は、補完的な管理策を文書化してください。小規模チームでは、すべての職務を完全に分離できないことがあります。担当者が他にいないために発注書の作成と承認を一人で行わなければならない場合は、ただ肩をすくめて済ませず、管理者による独立したレビューを設けて記録を残してください。

NetSuiteにおける職務分離

NetSuiteのネイティブな役割と権限モデルは、SoDの衝突を検出しません。役割を作成し権限レベルを割り当てることはできますが、同じ人物が持つ2つの役割が衝突していることをプラットフォームが知らせることはなく、その割り当ての保存も止められません。したがって、SoDはスプレッドシートの作業になります。誰かがすべての役割、権限レベル、従業員を職務マトリックスと照合し、役割が変わるたびに繰り返します。遅くて間違いやすく、監査人は一度きりの整理を継続的な管理とは認めません。見逃した衝突、同じベンダー支払いを作成・承認できる一人の存在が、クリーンな監査を是正リストに変えてしまいます。

StrongpointStrongpointのAdvanced SoDモジュールは、その適用をNetSuiteに直接組み込みます。顧客や監査人との長年の作業を経て構築された事前定義ルールライブラリから始め、多くの組織のニーズをすぐにカバーします。必要なルールのみを有効にし、ロールベース、権限ベース、またはその両方のルールを作成して、何かが不足している場合の機密カスタムレコードをより細かく制御できます。ブロックコントロールは、誰かが保存しようとした瞬間に互換性のない割り当てを停止するため、予防は次の四半期レビューではなくリアルタイムで行われます。完全にブロックできない競合については、Strongpointがインシデントを記録し、すべての免除を文書化された変更要求と承認を通じて処理するため、すべての補償コントロールに記録が残ります。テストモードでは、新しいルールを既存のロールや従業員に対してライブ前にモデル化でき、発動前に調整可能です。また、Strongpointはすべてのルール変更、免除、違反を記録するため、SoD監査レポートおよび関連レポートは、誰がいつどのアクセス権を持っていたかの直前の再構築ではなく、SOX監査のための継続的な証拠を提供します。