職務分掌を維持するために重要なのが、システムへのアクセス管理だ。多くのシステムはIDとパスワードで管理しており大丈夫と思うかもしれないが、特に「特権ID」と「データベース・アクセス」が落とし穴になる。
特権IDとは、rootやadministratorなど、OSやミドルウエアで最大の権限を持った管理者向けIDのこと。あらゆる操作が可能なため、どのような統制ができているかは、重点的にチェックされる。もちろん、特権IDを誰でも利用できるようにしている企業は少ないだろう。しかし、複数の開発担当者や運用担当者で共用しているケースもまた、少なくない。そうなると、「誰が、どんな目的で特権IDを利用したか」の記録が残せない。
基本は、役割に応じて管理者権限を振り出すこと。アドバンテストとタイコヘルスケアはともに、特権IDの名称とパスワードを記した紙を金庫で管理している。アドバンテストでは特権IDの利用申請があれば、その作業に合った新しいIDを設定し、与える。タイコヘルスケアは金庫の鍵を中谷透情報サービス本部長が管理し、申請があれば利用目的などを確認した上で特権IDの使用許可を与える（図8）。
 |
| 図8●アクセス管理で、米SOX法404条に対応した各社が受けた指摘事項とその対処方法の代表例 [画像のクリックで拡大表示] |
同じIDを共有していなくても、役割に応じた設定をしていなければ問題だ。キヤノンは、データベース（DB）の管理に関するIDで、そうした指摘を受けた。管理者にはある程度の権限を持たせるため、基本的に書き込みと読み出しの両方の権限を付与していたが、「厳密に分けるべき」とされたのだ。そこで同社は担当者の役割を洗い出し、権限を見直した。
リコーを悩ませたのが、特権的なIDを1つしか振り出せない運用管理ツールの存在だった。操作内容は記録できるが、利用者を特定できない。そこで同社は、そのツールの特権IDが必要な場合は申請を出すようなワークフロー・システムを開発。申請書と操作ログを突き合わせることで「誰が何をしたか」が分かる仕組みとした。
DBアクセスの効率化が盲点に
Webアプリケーションにおいて、アプリケーション・サーバー（APサーバー）のDBコネクション・プーリング機能も、利用者の特定を難しくする。
多くのAPサーバーは、DBとのコネクションを維持する機能を備える。DBアクセスのたびにコネクションを確立していては性能が出ないので、維持したコネクションを共有するためだ。また、同時アクセス・ユーザー数の課金体系を採用しているDBで、ライセンス費用の節約を目的としてコネクション・プーリングを用いる場合もある。自社開発のシステムで、このような仕組みを取り入れるケースは少なくない。
この場合、使い回しのコネクションでは利用者が特定できない。特にDBは、財務報告の大元となるデータを保存している。アドバンテストやリコーなど、この点を指摘された企業は多い。
アドバンテストは、複数のDBアクセス・モジュールで、共通のIDとパスワードを直接記していた。監査人はこれを「悪意を持った人に共通のIDとパスワードを知られ、不正なプログラムを埋め込まれる可能性がある」と指摘。また、「パスワードは年に1回変更する」と定めていたが、「埋め込まれたパスワードについては、当該の統制が有効に運用されていない」とされた。同社はすべてのDBアクセス・モジュールからアクセス用のIDとパスワードを切り分け、定期的にパスワードを変更する仕組みに変えた。
一方のリコーは、アプリケーションへのアクセス・ログとDBへのアクセス・ログをマッチングし、利用者を特定できるようにした。
