IT監査

こんにちは



会社の外部財務監査の一環として、IT部門管理の要件へのコンプライアンスの問題を強調したいと思います。 この記事の目的は、関連する法律を説明することではなく、IT部門の管理に対する具体的な影響を説明することです。



おそらく、あなたの多くはすでに暦年末にこれらの要件に毎日のルーチンまたはうわさの形で直面しています（私は2番目の傾向があります）が、個人的には、SOX、HIPAA、SAS 70（SSAE 16に置き換えられた） ）およびITGCは、この問題の包括的な説明に遭遇していません。







少し前まで、私の仕事の一環として、私は新しい従業員のためにプレゼンテーションを準備しました。 実際、プレゼンテーション自体が私にこの記事を書くように促しました。 ここで、CIS諸国での私の経験は非常に限られており、国際的な企業でより多くの仕事をしていることに注意したいと思います。



この質問に興味があれば、歓迎します。

エントリー

これらの要件の出現の歴史について簡単に説明します。2000年代初期のいくつかの大企業での金融詐欺のため、米国大統領は財務諸表の信頼性に対する上級管理職の直接責任に関するSOX法を承認しました。 私たちの時代の財務報告は納屋の本ではなく専門の情報システムで行われているため、これらのシステムに保存された財務データが信頼できることを確認する必要がありました。



それぞれに質問があるかもしれませんが、これはあなたが働いている会社にどのように関係していますか？ 会社が米国株式市場に上場している場合、またはこれらの会社の子会社である場合、IT部門の作業を監視するための内部メカニズムを作成する必要があります。 もちろん、他の部門でも同様のメカニズムを作成する必要がありますが、ここでは、この記事の目的がIT部門であることを繰り返します。



では、そのような制御メカニズムはどのように作成されますか？ 原則として、会社はコンサルティング会社に転向します。コンサルティング会社は監査会社との交渉においてこの会社の代表として行動し、別の監査会社もコンサルタントとして行動する場合があります。 コンサルティング会社は、その成果を使用して、特定の会社ごとにある程度それらを適合させます。



これらの開発は何ですか？ 実際、これは、今後説明するトピックに従って配置されたリスクとコントロールを含む通常のExcelスプレッドシートです。 これらのリスクと統制はどこから来たのですか？ コンサルティング会社の従業員の献身の程度に応じて、さまざまな基準（COBIT、ITIL、COSO）の徹底的な調査から始まり、その後の分析とリスクと統制の独自の「ライブラリ」の構築、そして大企業の元従業員による単純な盗作で終わる、無料の水泳に出発。



IT部門の監査プロセスは、2つの期間に分けることができます。 最初は、原則として、春の終わりまたは初夏に行われ、ITプロセスとコントロールの説明（マトリックスへの入力）が含まれ、各キーコントロールについて少なくとも1つの文書化された例を提供する必要があります。 私自身の経験から、この段階はIT部門自体にとって非常に重要であると言えます。記載されたITプロセスと制御の徹底的なチェックがないと、将来、不正確な可能性が高くなる可能性があります。 監査の2番目の部分は秋に該当し、これらの管理に関する文書を収集することにより、すべての主要な管理をテストすることが含まれます。



ここでは、通常の制御とキー制御の違いについて簡単に説明する必要があります。通常の制御は説明の形でマトリックスに入力されますが、説明に加えてキー制御をテストする必要があります。 制御に関するドキュメントを提供する必要がある場所、および言及だけに自分を制限できる場所を見つける方法は？ まさか。 これは、会社の規模、監査の最初の部分の結果などに基づいて、仲介者と監査人の間で交渉されます。 ただし、以下のほとんどのコントロールでは、ドキュメントが必要です。



監査プロセスの説明を開始する前に、注文と手順のトピックに言及したいと思います。IT部門のすべての主要な作業プロセスを文書化する必要があります。 これらの文書は、会社の経営陣によって承認され、プロセスまたはテクノロジーに重大な変更があった場合に定期的にレビューおよび更新される必要があります。

そしてもう1つの注意：可能であれば、リストをExcel形式で提供します-これにより、監査人と自分の両方が楽になります（同じ要求を繰り返し要求するが、異なる形式で要求すると緊張することがあります）。



コントロールの説明に移りましょう。 リスクと管理の表は、3つの部分に分かれています。

1.論理的および物理的アクセス

2.情報システムの運用

3.情報システムの変更管理

4番目の部分「情報システムの開発」は、通常、変更の文書化に焦点を当てているため、変更管理の一部としてテストされます。

論理的および物理的アクセス

最初のセクションは、監査の対象となるすべての情報システムへの論理的および物理的アクセスです。



1.システム管理者-ここでは、会社のネットワーク（管理者、ドメイン、エンタープライズ、スキーム管理者）およびデータベースを含む各システムの管理者のリストを提供する必要があります。 リストは、システムからエクスポートするか、スクリーンショットの形式で提供する必要がありますが、最初の方が望ましいです。

システム管理者権限を持つ従業員ごとに承認注文が存在する必要があります。 また、同じ権限を持つ各サービスアカウントを知る必要があります。







2.従業員のアクセス権-いくつかのサブアイテムがテストされます。

a。 テスト年度に就業した従業員-そのような従業員のリストを提供する必要があります。最も単純なのは、会計プログラムからです（給与を受け取っていない従業員がいないという事実に基づいて）。

b。 テストされた年に仕事を完了した従業員-同様に、そのような従業員のリスト。

c。 役職を変更した従業員-従業員のリスト。

d。 さらに、会社のネットワークやデータベースを含むすべてのシステムで完全なユーザーリストを提供する必要があります。

監査人の要求に応じて（完全なリストまたは選択）、従業員の雇用および解雇の記入済みおよび認証済みフォームを提供する必要があります。

データはクロスチェックされます：適切な許可なしにシステムへのアクセス権を取得した従業員、オープンアクセス権を持つ解雇/辞職の従業員、未使用のオープンアカウントがあります（90-180日以上前にログイン） 。

また、ユーザー権利の年次監査手順の実装も確認します。各システムでユーザーとその権利の認定リストを提供する必要があります。 ところで、このチェックの助けを借りて、あなたは時間通りに閉じられていない解雇/退職した従業員のアカウントを見つけることができます。



3.リモートアクセス権-リモートアクセス権を持つすべての従業員のリストを提供する必要があります。 従業員リストの監査プロセスは、ユーザー権利の年次監査の一環として検証することもできます。 ADにこれらの権限を持つ別のグループがある場合-追加の相互検証の準備をします。



4.プログラムのローカルインストールの権利-自分のコンピューターの従業員がローカル管理者ではないことが望ましい。



5.外部接続-CD-ROM、USBポート、LANソケット、Wi-Fiポイントをブロックすることをお勧めします。 さらに、接続に追跡および通知システムを使用します。



6.パスワードポリシー-すべてのシステムとADのパスワード設定画面のスクリーンショットを提供する必要があります。 パスワードの最小要件：

a。 最小8文字

b。 さまざまなキャラクターの使用

c。 最大90日後、最低1日後のパスワード変更

d。 少なくとも5世代、または1年間パスワードの履歴を保存する

e。 パスワードを回復する能力の欠如

f。 最大5回の不正な試行後のアカウントロックアウト

g。 ネットワーク管理者がアカウントのロックを解除します（自動リセットロックを使用しないことをお勧めします）

また、すべてのアカウントのADでの最後のパスワード変更の日付も確認します。







7.ファイアウォール-FWバージョンのスクリーンショット、FW管理者のリスト、アラートメーリングリスト。 また、FWでルールの認定された定期的なレビューが必要になる場合があります。 深刻な場合、ログを確認するか、そのようなチェックが実行されたことを証明するドキュメント（！）が必要になります。







8.ウイルス対策-AVバージョンのスクリーンショット、警告メーリングリスト、AVサーバーとクライアントを更新するための設定画面。







9.ラップトップのセキュリティ-ラップトップを持つ従業員のリストが必要になることは非常にまれです（まだ）。 ハードドライブは暗号化されていますか？



10.緊急事態管理-各企業は、このようなインシデント（ネットワークハッキングの試みなど）のリストを保持する必要があります。 四半期ごとのレポートを上級管理職に送信することをお勧めします。

情報システムの運用

さて、情報システムのセキュリティを整理しました。 私たちは彼らの活動に直接進みます。



1.データのバックアップは、このセクションの主要なチェックの1つです。

バックアッププログラムのスクリーンショット、タスクのステータスのメーリングリスト、およびバックアップ設定画面を提供する必要があります。 原則として、各金融システムは独自の仮想サーバーにインストールされ、バックアップの要件は異なる場合があるため（完全、差分、増分）、適切な数のスクリーンショットが必要になります。 バックアッププロセスの継続性はログを表示することで確認されるため、過去3か月間、さらにはテスト年全体にわたってバックアップログを保持する必要があります。 ここでは、2〜3日以上続くバックアップシステムの問題を探しています。 そのような場合、上級管理職は、少なくとも電子メールメッセージの形式でレポートを保持する必要があります。







2.データ回復の検証-テープからのデータ回復のログを提供する必要があります。 経験豊富な監査人は、ファイルサーバーからの複数のドキュメントに限定されないため、データベースと金融システムの回復を実行することをお勧めします。



3.バックアップ用のカセット-カセットの循環および書き換えのポリシーは、次のルールを満たしている必要があります。

a。 毎日のカセットは、少なくとも2週間保管する必要があります

b。 毎週のカセット-少なくとも1か月

c。 毎月のカセット-少なくとも1年

d。 1年のカートリッジ-少なくとも7年

カセットは、少なくともサーバールームではなく、別の建物の耐火金庫に保管する必要があります。 したがって、金庫にアクセスできるすべての従業員のリストが必要です。



4.サーバールームへのアクセス-サーバールームへのアクセス権を持つ従業員の認定リストを提供する必要があります。 訪問ログを保持し、専用のアクセス制御システムをインストールしてこれを行う必要があります。 私の意見では、個人識別（IDタグ）のための通常のアクセスシステムで十分です。 訪問ログを定期的に確認することをお勧めします。場合によっては、興味深い写真が表示されることがあります。



5.サーバールームの環境制御-煙、火災、洪水センサーの存在、独立した空調システム（近くの施設から）、UPSと発電機の存在、緊急時に通知を受け取る従業員のリスト。



6.バックアップDC-本社からの距離、データ転送方法、BCM / DRP計画の可用性（IT部門は計画の2番目の部分に注意を払う必要があります）、計画に従った年次（少なくとも）演習の実施。



7.バッチデータ処理-これは、自動データ処理（通常は夜間に実行される）を意味し、オペレータの介入を必要としません。 設定を変更する権限を持つすべての従業員のリスト、データ処理のステータスのメーリングリストが必要です。 また、バックアップの場合のように、ログを提供してエラーを調べることも必要になる場合があります。



8.インターフェース-原則として、前の段落と相互接続されていますが、私はまだこの制御について言及しています。 すべての金融システムのインターフェース図（それらの間だけでなく、それらへおよびそれらから）を持つことが望ましい。



9.インフラストラクチャの問題を解決する-これは、情報システムおよびインフラストラクチャに関連する会社で発生するすべての問題の登録とその後の解決のための内部コールセンターを意味します（サーバーがクラッシュし、電源がオフになり、マウスが機能しない、2つのスタートボタンなど）。 前のセクションの緊急管理は、この制御の下で実行できます。

情報システムの変更管理

2つのセクションが残され、1つは残されていますが、監査を成功させるには、原則として、ワークプロセス自体の変更が必要なので、細心の注意が必要です。 したがって、情報システムの変更管理。

いくつかのコメントから始めましょう。 まず、開発手順を文書化して承認する必要があります。 第二に、各変更が文書化される専門の開発管理システムを持つことが非常に望ましいです。 第三に、アウトソーシングの開発、または製品の箱入りバージョンの使用を条件として、監査はわずかに異なります。



1.作業環境-非常に簡単です。各金融システムで、開発、テスト、戦闘の少なくとも3つの作業環境のスクリーンショットを提供します。 上記の場合、最後の2つのスクリーンショットで十分です（はい、ボックス版でもテスト環境が必要です）。







2.作業環境へのアクセス-各環境のアカウントのリスト、開発者とテスターの名前のリスト。 開発者とテスターは戦闘環境へのアクセスを許可されず、通常のユーザーは戦闘環境以外のすべてへのアクセスを拒否されます。 ボックス版の場合、テストおよび戦闘環境に十分なリストがあります。 これは中小企業では非常に難しいため、監査人は妥協を図ります。



3.変更を転送するプロセス-理想的には、テスト済みの環境から戦場に変更を転送する責任者は、開発プロセスまたはビジネスプロセスとは関係ありません。 繰り返しますが、この場合、監査人は妥協することもできます。



4.変更-テスト年度に導入された金融システムのすべての変更のリストを提供する必要があります。 なかった？ これは、インストールされたシステムを含むフォルダーのスクリーンショットであり、ファイルは変更日順にソートされています。 存在する場合は、次のドキュメントを提供するためのリクエストのサンプルがあります。

a。 ユーザーからの変更のリクエスト-特別なフォーム、または電子メール。

b。 変更の参照条件-変更の種類（フォームにフィールドを追加するか、最初からモジュールを開発する）に応じて、ドキュメントが必要になります-変​​更を説明する通常の手紙から、さまざまなボスやマネージャーの署名によって認証された本格的な複数ページのドキュメントに

c。 変更テスト-チェックリストと、この変更が要求を満たすユーザーの許可を含むテストケース。

d。 変更を戦闘環境に転送する許可は、この方向での開発を担当する責任者によって署名されます。



5.重要な変更の管理-概して、前の段落と変わりません。 唯一の違いは、通常、重要な変更はドキュメントなしで発生するため、すべてのドキュメントをさかのぼって取得し、将来のために保存することが重要です。



必要なすべてのドキュメントの収集が完了しました。次に何をしますか？ 監査人は、収集した文書を求めて分析します。 監査人は内部監査から独立したままである必要があるため、一部のコントロールについては追加のドキュメントが要求されます（突然、50人を超える従業員がいますが、新しい従業員のアカウントを開く要求は10件のみです;または、ドメイン管理者グループのスクリーンショットからアカウントを削除しましたCEO）。 そして、リスクとコントロールの表にテスト結果が記入され、IT部門の責任者と会社の財務部長に話し合うために提示されます（彼は財務諸表を担当しているため）。

おわりに

監査人の仕事は、プロセスとコントロールの欠陥と欠陥を特定することです。 すべてが完全に機能していても、監査人は小さな些細なことを理解し、それをひねって深刻な欠点を生じさせることができます。 小さな余談：欠陥は3つのカテゴリーに分類されます-欠陥（欠陥）、深刻な欠陥、重大な欠陥。後者は年次財務諸表に含まれ、会社の価値に影響を与える可能性があります。 経験豊富なITマネージャーは、このニュアンスを使用して、部門のニーズに対する追加予算を要求できます。 2年連続でサーバールームに耐火金庫またはアクセス制御システムがないという事実は、取締役会のメンバーで構成される監査委員会のレベルに達し、適切なアプローチで、不足を解消するために必要な予算を獲得することができます。



私の意見では、この説明はIT部門の外部監査のプロセスのアイデアを適切に提供しますが、主な質問はこれだと思います。仲介者の助けなしにIT部門の外部監査に独自に準備できますか？ 私の経験に基づき、私はそれが可能だと宣言しますが、これには多少の努力が必要ですが、長期的には年間でかなりの量を節約できます。 ただし、初めて監査の準備をしていて、自分の長所や知識に自信がない場合は、優れたコンサルティング会社を雇うことをお勧めします。 確かに、監査の準備を支援するために1人の従業員を選抜することをお勧めします。そうすることで、将来的にはこの責任を負うことになります。



提示された情報が、監査に直接参加する人々と、より多くの人々の両方の役に立つことを願っています。

すべての質問にお答えいたします。