WEBマガジン

「内部統制におけるアクセスコントロールの効率化 その2」

2012.09.11 株式会社オージス総研  栗田 健史

 前回"内部統制におけるアクセスコントロールの効率化"をテーマとして、アクセスコントロールを整理し、アクセスコントロールを効果的かつ効率的に実行するためには、その対象物の特定(何を守るのか)とアクセス経路(どうやってシステム資源に達するか)やアカウントのライフサイクルを把握することで、分かりやすいコントロールが実装できるというお話をしました。個々の事象で捉えるのでは無く、全体を構造化し、アクセスコントロールを"見える化"することで、漏れなくポイントを定めた対応が可能となります。

 今回は、アクセスコントロールの中でも分かりにくい論理アクセスコントロールについてお話しします。論理アクセスコントロールには基盤レベルのオペレーティングシステムやデータベースのアクセスコントロールも有りますが、今回は対象をアプリケーションアクスセスコントロールに絞り、ライフサイクルに沿って全体を構造化しながら具体的な実施内容を考えてみましょう。

 前回も記載しましたが、情報資源に対するアクセスのリスクは「組織内外から、非権限者にアクセスされること」1です。これを裏返して考えると「権限者のみにアクセスさせること」がコントロールと言うことになります。

1 FISC(金融情報システムセンター)の『システム監査指針』

 下図は、アプリケーションのアクセスコントロールの全体像を示したものです。

アプリケーションコントロールの全体像
図1.アプリケーションコントロールの全体像

1.ID・PASSWORDの設計

 認証方法にはいろいろな方法が有ります。指紋・声紋・虹彩など生体を使う生体認証、 "物"を保持していることと"記憶(暗証番号)"を組み合わせた2要素認証など、しかし、実際によく使われているのはID・PASSWORDによる認証方法です。
 ID・PASSWORDの設計は、全社的に定めたセキュリティポリシーに従い個別のシステムの重要性や利用者などを考慮した上で運用面も含めた設計が必要です。

表1.ID・PASSWORDの設計例
ID・PASSWORDの設計例

 アカウント申請の手続き、ロックアウト解除手続き、棚卸しの方法、モニタリングの方法などの運用についても検討が必要です。

2.権限設計

 まずは、内部牽制が働く適切な業務分掌を定めます。例えば、"この処理はこの人しか出来ない"、"この入力をした人とは別の人がチェック処理を行う"などです。これをシステム上の仕組みとして組み込むのがアクセス権の設定ですが、アクセス権の設定方法は、様々な方法が有ります。基本は利用者とリソースをどう関連付け、どの処理が利用可能か不可能かを設定しますが、利用者側では、役職、役割、組織など個人を束ねてリソースと関連づける場合や、リソース側では、メニュー単位、サブシステム単位、グループ単位など個別処理を束ねて利用者と関連付ける方法もあります。また、個別処理をさらに細かくフィールド単位に分ける場合もあります。


図2.

 アクセス権の申請手続きなどアクセス権についてもID・PASSWORDと同様運用面の考慮が必要です。また、アプリアカウント(アクセス権)を更新できる人の管理は特に重要です。このようなオールマイティな権限は、どのような作業も出来てしまうため、以下のようなリスクを低減する運用を検討しましょう。
・アクセス権の更新は、職務分離した他部署(運用部門など)に依頼する。
・アプリ利用部署でアクセス権の更新を実施する場合は、
 - 人数を限定し役職者などに割り振る
 - アクセス権更新を実施できる端末を役職者の近くの席などに限定する
 - アクセス権更新時のログを取る

3.ID・アクセス権の申請・登録

 アプリケーションの利用段階では、各利用者と使用できる権限の設定をシステムへ実装します。一般的によく使われるのがアクセス権の申請です。職務分掌に基づき設計したアクセス権の中から適切なものを申請書に記載し、役職者がそれを承認する方法です。
 個別に申請を出さない方法としては、組織内の当該業務における役割分担表などで各個人の役割が決まっておれば、その役割分担表をもとにシステム上の設定を変更する方法があります。
 また、人事情報(人事システムのアカウント)と連動して、異動・退職・昇格などが当該システムのアクセス権に反映される場合もあります

 内部統制では、この業務分掌が現在利用しているシステムで確実に実装できているかがポイントとなります。経産省の情報セキュリティ管理基準(平成20年改正版)でも以下を規定しています。

7.1.1.3利用者及びサービス提供者には、アクセス制御に適合する業務上の要求事項を明確に規定して提示する

 ここでいう"業務上の要求事項"とは、職務分掌のことで具体的には組織内の役割分担表などですが、以下の点には注意が必要です。
・役割分担が個人まで特定しにくい・分かりにくい
・担当者が更新しているだけで役職者が承認していないな(承認欄がない)
・人や役割が変わっても更新されていない(承認日・更新日付がない)
 このような"業務上の要求事項"はシステム構築時にはしっかり作成されることが殆どですが、時間が経つと放置されることがよく見受けられます。異動が発生した場合に何をするかをリストアップしておくとか、アカウント棚卸し時に必ず"業務上の要求事項"と"システム上のアプリアカウント"を確認することが有効です。

 さて、次のステップは実際に個人が利用する認証・認可の段階ですが、ここ以降は次の機会にお話ししたいと思います。

*本Webマガジンの内容は執筆者個人の見解に基づいており、株式会社オージス総研およびさくら情報システム株式会社、株式会社宇部情報システムのいずれの見解を示すものでもありません。

『WEBマガジン』に関しては下記よりお気軽にお問い合わせください。

同一テーマ 記事一覧

「システム監査の進め方」

2017.08.28 ITガバナンス 株式会社オージス総研  栗田 健史

「内部統制におけるアクセスコントロールの効率化 その3」

2013.11.11 ITガバナンス 株式会社オージス総研  栗田 健史

「リスクをどのようにして見つけますか?」

2011.10.04 ITガバナンス 株式会社オージス総研  栗田 健史

「内部統制におけるアクセスコントロールの効率化」  

2010.10.03 ITガバナンス 株式会社オージス総研  栗田 健史