日本版SOX法に必要なセキュリティポリシーとは？：セキュリティツールで作る内部統制（7）（2/3 ページ）

[中島 浩光，＠IT]

外部から本番環境を守ることも大切

　日本版SOX法の監査では、当然ながら本番環境のシステムが主な対象となります。開発環境やテスト環境の財務システムで不正なトランザクションを実行しても、財務報告に影響があるわけではないので、重要なのは本番環境です。

　ユーザーのIDとアクセス権の管理・制御を行うアイデンティティアクセス管理は、この本番環境内部における統制活動であるといえます。そもそも、その本番環境がきちんと外部から保護されていなければ、内部の統制活動が有効でなくなってしまう可能性もあるため、これをきちんと外部から保護することが非常に重要です。本番環境の保護には以下のようなものがあります。

（1）物理セキュリティ

　「セキュリティ区画の設置」と表現する場合もありますが、施設レベルの入退出管理といい換えてもよいでしょう。一般の業務エリアや、サーバルームなどに対してきちんと入退出管理が行われているか、特にサーバルームやネットワーク機器を収納したラックなどに対して、社内であっても業務上必要な人だけがアクセスできるようになっているかどうかが重要になります。

（2）ネットワークセキュリティ

　現在の情報システムにおいて、スタンドアロンのシステムはまずないといってよいでしょう。また、インターネットなどの外部ネットワークとまったく接続していないシステムもないと思います。そのため、ネットワークレベルで本番環境を保護するセキュリティ対策が重要になります。

　インターネット接続におけるセキュリティ対策として、ファイアウォールを設置するといったことはすでに一般的に行われていると思いますが、BtoB接続におけるWAN回線（専用線やVPN回線など）などにおいても、接続する相手先はあくまで「外部」となりますので、ファイアウォールの設置は必要になります。子会社やグループ企業などとの接続については、システムを共有している場合もあり微妙なところではありますが、可能であれば対策を打っておいた方がいいでしょう。

　また、本番環境に対する「外部」という意味では、社内に存在する開発・テスト環境も外部と位置付けられます。本番環境と開発・テスト環境がネットワーク的に分離できていない＝開発･テスト環境から本番環境に自由にアクセスが可能である場合、本番環境の正式な利用者ではないはずの開発者がアクセスできることになってしまい、アクセス管理の有効性が保証できなくなります。

　この問題点は、米国SOX法対応における指摘事項でも上位に挙げられており、監査する側としても意識しているといってよいでしょう。このため、本番環境と開発・テスト環境については、ネットワークを物理的に切断してしまうか、そうでなければその間にファイアウォールを設置するといった対策を施しておくことが必要になります。

（3）不正プログラム対策（ウイルス対策など）

　ウイルス対策についてはすでに一般的に行われており、対策が取られているかどうかというより、パターンファイルのアップデートがきちんと行われているかどうかといった、運用面における対策を徹底する必要があるでしょう。また、COBIT ver.4.0では不正プログラムの1つとしてスパイウェアに関する記述があります。

DS5.9 Malicious Software Prevention, Detection and Correction

Ensure that preventive, detective and corrective measures are in place (especially up-to-date security patches and virus control) across the organisation to protect information systems and technology from malware (virus, worms, spyware, spam, internally developed fraudulent software, etc.).

　ウイルス対策が一般化してきている現在、継続的なセキュリティの向上を考慮すると、近い将来スパイウェア対策も求められてくる可能性はあります。

外部委託におけるセキュリティ管理とは

　現在の情報システムにおいては、外部委託は数多く行われています。外部委託分野では、システム運用のアウトソーシングや、ハウジング／ホスティング、WAN回線サービス、システム開発など、非常に多くのサービスが提供されています。これらの外部委託業務についての内部統制については、セキュリティの確保を含めて、米国SOX法においても日本版SOX法においても委託元が責任を持つ必要があります。

　では、外部委託サービスにおいてセキュリティを確保するために、委託元でできることは何かというと、1. SLAでの規程、2. 定期的なレビュー／監視、の2点になります。

1．SLAでの規程

　SLA（Service Level Agreement）は、実際のサービス契約において提供されるサービスの内容とそのレベルを定義したものであり、WAN回線サービスやシステム運用サービスなどにおいては一般的になっています。

　日本版SOX法対応としては、このSLAにおいてセキュリティに関する項目を定義し含めることが重要となります。どのようなものを定義するかは委託する業務の内容によって変わりますが、例えば、業務システムの運用管理を委託した場合では、以下のようなものが考えられます。

• 業務システムを利用している業務に対して、実質的な影響があったセキュリティ事故の件数
• ユーザーID、アクセス権の変更作業完了までの目標時間
• システム管理者IDの不正な利用の割合
• システム管理者IDによる作業に関するレビューの実施率
• セキュリティ上の事故が発生した場合、初期対応を開始するまでの時間
• 必要なセキュリティ上のレポートを予定どおりに提出している割合

　筆者が思い付くままに挙げてみましたが、これらの項目の目標値を設定し、その達成度合いを評価するには、委託されている具体的な業務と、その業務フローや行うべきことを明確に定義することが必要です。そのうえで実際の委託業務の結果（監査証跡）から目標値に対する実績値を算出し、PDCAサイクルを回していきます。

2．定期的なレビューと監視

　SLAにおいて目標値を設定した場合には、前述したようにそれをベースにPDCAサイクルを回していくことで、ある程度は定期的なレビュー／監視を行うことができます。

　SLAでの目標値がない場合でも、委託元が定期的に委託業務のレビュー／監視を行うことにより、委託先の業務に問題がないかどうかを確認することは可能です。その場合、監査証跡や担当者へのインタビューなどにより、業務フローが明確であるか、セキュリティ上の違反はないか、といった点を定量的・定性的に評価していくことになります。ただし、委託業務の内容があいまいな場合や、監査証跡がそろっていない場合には、委託した業務がきちんと行われているかどうかの確証が得られないことになります。

　そのため、外部委託を行うに当たっては、SLAもしくはサービスに対する評価項目を設定するとともに、業務の明確化、監査証跡の取得をあらかじめ行えるようにしておく必要があるでしょう。