ネットワークエンジニア/アーキテクト向けサーベンスオクスリー

私たちの組織は最近ITを再構築し、ネットワークエンジニアをアーキテクト、実装エンジニア、運用サポートエンジニアなどの新しい役割に分離しました。

SOXコンプライアンスと、主な役割は戦略と計画であるため、アーキテクトレベルの担当者の運用環境へのアクセスを制限する適切な制御をどのように/実装するかについて懸念があります。私の理解では、職務分離のためのSOX制御は、財務または会計データに固有であり、（たとえば）開発/ QAのみの担当者向けの本番データベースへのアクセスです。

ルート/スイッチ/トランスポート機器にアクセスするためのSOX要件は何ですか？ネットワークエンジニアには職務の分離がどこで適用されますか？

いくつかのクライアントでこのプロセスを実行した後、通常は少なくとも次のコントロールを実装していることを確認することから始めます。ルート/スイッチ/トランスポートは一般に機能しないため、これらはSOXに固有のものではないことに注意してください純粋な可用性の観点以外の財務報告における役割：

• ネットワークへのすべての変更は、承認された個人によって実行されます（例：スーパーユーザーアクセス用のRADIUS / TACACSでバックアップされたアカウント）
• ネットワークへのすべての変更は、許可された個人によって検討されます（例：おそらくヘルプデスクチケット、変更フォームなどの形の監査証跡を含む、変更管理の正式な方法があります）。
• スーパーユーザーアクセスとそれに変更を加えるための監査証跡が存在します（例：ユーザー/役割の割り当てと実行者を示す、選択したディレクトリサーバーへのログオン）
• 加えられた変更とその変更者に対する監査証跡が存在します（例：ネットワーク構成のバージョン管理、ログインのsyslog記録、対話型コマンド）。

あなたのアーキテクトリソースが本番ネットワークにアクセスすることに関するあなたの質問に答えるために、これがSOX要件によって指示されているとは思いません。

一方、セキュリティの観点からは、最小特権の原則が適用される可能性が高いため、読み取り専用アカウントの方が適切な場合があります。