IT統制のキモとなる認証とアクセス制御とは：セキュリティツールで作る内部統制（5）（2/2 ページ）

[中島 浩光，＠IT]

アクセス制御〜何をもってアクセスを許可するのか？

　SOX法対応でのIT内部統制において、アクセス制御はセキュリティの中でも非常に重要なポイントとなります。

　あるシステム資源（システム機能、ファイルなど）に対してアクセス制御を行うには、1. アクセス権を定義し、2. 実際のアクセスを制御する、という2つのステップがあります。この2つのステップの両方がきちんと行われないと、業務システム（財務システム）が正しく利用されていることが保証できないことになり、財務報告の正確性・信頼性を保証できないということが起こり得るのです。

　では、各ステップにおいて考慮すべきポイントを以下に述べます。

（1）役割ベースのアクセス制御（Role Based Access Control：RBAC）

　役割ベースのアクセス制御とは、システム資源へのアクセス権をユーザーIDに対して与えるのではなく、○○部長とか××課といった利用者の業務上の役割に対してアクセス権を与え、ユーザーIDはその業務上の役割を持つ、という形でアクセス制御を行うものです。システム的な仕組みとしては難しいものではなく、ユーザーID管理システムでのグループ機能などを利用することにより実現が可能です。

　問題はこれらのアクセス権が正しく設定できているかという部分であり、つまりはアクセス権の情報をどのように定義するのかということになります。

　このアクセス権を正しく設定するには、実は業務プロセスの文書化を行う必要があります。業務プロセスの文書化を行う場合、業務フロー図を思い浮かべていただければよいのですが、そこには、プロセス内のどのタスクでどんなことを行うのかまた、どのタスクで、誰（業務上の肩書）が、どのシステムのどのような機能を利用するのかが記述される必要があります。

　つまり、業務フロー図にはシステム資源へのアクセス権が表現されているのです。そして、それらをまとめたものが役割ベースのアクセス制御設定となり、かつ、「必要最低限の権限（Least Privilege）」といわれるアクセス制御を満たすものになるのです。

（2）4W1H（What、Who、When、Where、How）

　アクセス権の設定を行うには4W1Hが必要だといわれています。

　通常のOSでファイルのアクセス制御を考えると、2W1HのみでWhen、Whereの設定ができない場合もあるのですが、専用のアクセス制御ソフト（例：CAのeTrust Access Control、eTrust SiteMinder）を利用することで、4W1Hの詳細な設定を実現することが可能になります。

　また、英語ではこれにWhy（なぜ・理由）を加えた5W1Hが疑問文の暗記の仕方としてありますが、ファイルへのアクセスなどでアクセス理由を制御することは通常できないので、4W1Hで行います。しかしながら、Webアプリケーションでは4W1Hに加えて、Whyでの制御ができる場合もあります。

　Webのアクセス管理製品の中には、アクセス制御の条件として4W1H以外に、画面のフィールドの値を見てアクセス制御を掛ける機能を持つものがあります（例：CAのeTrust SiteMinder）。つまり、業務的な内容を理由としてアクセスを制御するというもので、例えば経費の承認画面で経費の金額が大きくなって課長承認ではなく部長承認が必要になった場合、その画面では課長は承認できないが、部長であれば承認ができる、といったものがこのケースに当たります。

　前述の役割ベースのアクセス制御に加えて、アクセスの条件を加えることにより、より厳密な「必要最低限の権限」を実現し、かつ、権限外の利用者の不正なアクセスや、権限を持った利用者のアクセス手段の強制を行うことが可能となります。

（3）システム管理者もシステムの利用者

　実際の企業におけるアクセス制御の状況でよくあるのが、一般ユーザーに対してアクセス権の設定は行われているが、システム管理者・アプリケーション管理者に対してアクセス権の設定が適切に行われていないという点です。

　SOX法への対応において必要なのは、「システムに対しての不正を防ぐ＝不要な裏口は徹底的に排除する」という考え方であり、システムにアクセスするIDに対しては「すべてそのIDに必要最低限の権限を与える」ということになります。

　従って、一般利用者だけでなく、管理者IDについてもアクセス制御をきちんと行わなくてはいけません。システム管理者にとっての必要最低限の権限を考えるには、システム管理者が行う業務の業務フローを文書化し、「必要な権限は何か？」を検討していくことが必要になりますが、そういった文書がきちんと作成されている企業はなかなか見当たらないのが現状です。今後日本版SOX法対応を行うに当たっては、システム管理者がいるIT部門においても、その業務プロセスを定義し、アクセス制御を行っていくことが必要となるのです。

（4）権限の分離（Segregation of Duties）

　これは職務分掌、職務の分離ともいわれるのですが、監査における重要な概念の1つです。つまり、ある業務プロセスを、1人の人のみが担当していると不正を防ぐことができなくなるため、業務プロセスの遂行に当たって、いくつかの権限に分けて不正を発生しにくくするという考え方です。

　経費の精算という業務を見てみると、経費の申請をする人、申請を承認する人、実際に出金を行う人を分ける、つまり、申請、承認、実行の3つの権限を分けることにより不正を防ぐ、逆にいうと、3つの権限のうちの2つが同じ人で実行されると不正を防ぎにくくなる、ということになります。

　アプリケーション統制の領域の業務プロセスや会計システムについては、お金の流れに直結するため権限分離がよく意識されるのですが、IT全般統制においても権限分離を意識する必要があります。そして、そこで問題になるのはrootやAdministratorなどの万能の権限を持つIDになります。

　アクセス制御をすべてのIDに対して行うためには、これらの万能権限の問題を解決する必要があります。通常のOSではこの問題を解決するのは困難なため、米国SOX法対応の事例では、セキュアOSなどの製品（例：CAのeTrust Access Control）を利用することで解決した企業も多数あります。

　アクセス制御はシステムに対する直接的な不正を防ぐ部分になるため、裏口がない状態、つまり、できる限りシステムを利用して強制的に制御を掛けることが重要になります。そのため、企業内に存在するアクセス管理機能の設定をしっかり実施することも必要ですが、機能的に不足している部分については設定だけでは防ぎ切れないため、専用のツールを導入することによって実現できる部分が存在します。

　そして、各システムでのアクセス制御をきちんと行わない状態で統合管理を行おうとしても、「ザル」を集めて「大きなザル」を作る作業になりかねません。まず、「ザル」を穴のない「ボール」にしてから、「大きなボール」を作り、新たに穴を作らないために統合管理をするのです。統合管理はすでに存在する「ザル」を穴のない「ボール」にしてくれるものではないのです。

　次回は、アクセス制御の裏側である監査・監視について解説いたします。