- ■ 業務系ウェブアプリケーションをとりまく脅威
-
まず、業務系アプリケーションの主な特性としては、企業内の決まった部署や担当者に利用者が特定および限定されていること、また各利用者が、システムの内部的な処理にまで精通していることなどが挙げられます。
次にウェブアプリケーションの主な特性としては、利用者端末側の設定環境は自由度が高くなる反面、特定のセキュリティ設定を実施、維持させるなどの制御が困難となること、またネットワークの設定に応じて社内外のどこからでもアクセスできる反面、データの不正持ち出しなど事件事故発生の可能性が高くなることなどが挙げられます。
業務系アプリケーションおよびウェブアプリケーションの特性を合わせて概観すると、さまざまな発生源の中でも特に「内部利用者」を発生源とする脅威への対策が検討すべき事項といえます。その脅威とは「利用権限のある者による不正行為」、「利用者による権限の昇格、認証回避」、「内部者の物理的侵入」、「利用者の操作ミス・入力ミス」が挙げられます。
具体的には以下の、脅威のシナリオを描くことができます。 -
◆誰が（Who）：利用者など内部の関係者
◆何を（What）：業務系アプリケーション本体および保存されている情報
◆なぜ（Why）：会計情報の改ざんや保有個人データの横流しなど営利目的
◆どこで（Where）：事務所内など当該情報に容易にアクセスできる場所
◆いつ（When）：夜間・早朝・昼休みなど監視されにくい時間帯
◆どのようにして（How to）：業務上で与えられている権限を利用もしくは、熟知しているシステムの処理プロセスを利用 -
このシナリオのように不正行為者が部外者ではなくシステムの構成や内部処理に精通した利用者など内部関係者である場合には、部外者と比較して厳しい情報セキュリティ対策が実施されていないことが事件事故の発生確率を高める要因となります。
しかも、過去の事件事故事例を振り返って見ると、内部関係者の不正行為による事件事故であるほど、企業の受ける被害が大きくなるケースが多いのです。 - ■ 情報セキュリティ対策：【見える化】および【見せる化】
-
業務系ウェブアプリケーションで注目すべき脅威が【利用権限のある者による不正行為】および【利用者による権限の昇格、認証回避】であるならば、これらに対する最も有効な対策は、広い意味での「アクセス管理」です。
ここでいうアクセス管理とは、単にログイン認証機能をもつという狭義にとどまらず、4Aと呼ばれる要素（認証・認可・管理・監査証跡）を含むものです。アクセス管理は本来、これらをすべて実施しなければ、有効に機能しないことは言うまでもありません。4Aにおける対策事項を以下に示します。 -
◆1.認証（Authentication）：利用者を識別すること。
・十分な強度をもつ認証方式を採用すること（例えば生体認証、二要素認証 等）。
・パスワードを使用する場合は、文字数・文字種・有効制限等をシステムで制限すること。
・利用者1人に対して、必ず１アカウントを割り当てること。
◆2.認可（Authorization）：利用者にアクセスを許可するかどうか判断すること。
・最小権限の原則を業務の必要性に応じて、きめ細かく運用すること。
・アクセス制限はウェブアプリケーションだけでなく、サーバOSやデータベース等にも厳密に適用すること。
・アクセス時刻やアクセス場所（IPアドレス）などでのアクセス制御も検討すべき。
◆3.管理（Aｄｍｉｎｉｓｔｒａｔｉｏｎ）：利用者アカウントやアクセス権の設定・削除を行うこと。
・利用者の退職・異動などへの対応に抜けや漏れがおきない仕組みをつくっておくこと。
・利用申請に対して必ず本人確認すること。利用者の「顔が見える」管理が大切。
◆4.監査証跡（Auditing）：認証・認可・管理の履歴を監査可能な認証として残すこと。
・アクセス管理の処理ログをとり、改ざん不能な媒体で保存すること。認証・認可ログだけでなく、アカウント作成や権限の変更などの管理ログこそが重要。
・最新のログは（一部のサンプリングでもよいので）疑わしい処理がないか分析する。分析をおこなっている事実を社内に知らせることが、不正への抑止力になる。 -
これらの対策事項は、システムに関わるプロフェッショナルの方々からすれば目新しいものではないでしょう。
しかし、これまで業務系ウェブアプリケーションの開発・運用において、これらの対策がきちんと【見える化】および【見せる化】されてきたでしょうか。残念ながら十分であるとは言えません。ここで、業務系ウェブアプリケーション開発運用の際に、【見える化】および【見せる化】の観点から当社がお手伝いしている情報セキュリティ対策として、２つの事例をご紹介します。
-
- 事例１：情報セキュリティ対策の有効性モニタリング
- セキュリティ対策を実施した結果として、その有効性が問題になることがあります。
セキュリティ対策はそのコストは見えますが、結果については金額に換算することができないからです。対策の費用対効果が疑問視され、対策を取り止めるとどうなるかを言い始めるケースも見られます。そこでセキュリティ対策の有効性を【見える】ようにすることが重要となります。情報セキュリティマネジメントシステムの国際認証規格であるISO/IEC27001:2005も、管理策の有効性を測定・評価することを義務付けています。
具体的にはセキュリティインシデントがどれだけ発生したか、「ヒヤリ・ハット」の危険な状態がどれだけ起こったか、といった数値を取り、対策を講じたことによってどれだけ、それが減少したのかを見ていきます。数値が目標に達しなかった場合や悪化した場合には、経営陣に対し報告が上がり、経営陣の関与の下で改善が行われる仕組みになっていなければなりません。悪い情報は現場で握りつぶされる可能性があるからです。有効性を数値で把握し、その記録が経営陣に報告され、関係者に対して指示が下される仕組みが重要となります。 - 事例２：フェーズ別情報セキュリティ対策の監視
- 開発ライフサイクル（計画立案から廃棄まで）の各フェーズで、開発運用チームの実施状況をモニタリング・評価し、システム発注者に報告する仕組みをつくります。
それぞれのフェーズでつくる側は情報セキュリティ対策を【見せる】ことを意識し、ユーザー側は【見える】ようにきちんと情報セキュリティに関する要求を出す仕組みが必要です。個人情報を扱うなど、高い管理レベルが要求されるシステムを開発する場合は、特に重要となります。なぜならばシステム完成後にゼロからテストを実施することは困難ですし、その際に構造上のセキュリティ弱点が発見された場合は致命的となるからです。その修正には莫大な資金と工期を要するでしょう。
ここで情報システムの導入過程における【見える化】および【見せる化】のポイントを解説します。
計画・要件定義フェーズ、外部設計・内部設計フェーズなど上位の設計フェーズでは、RFPにセキュリティ要件を明確に示すなど要求仕様の【見える化】および【見せる化】がポイントとなります。
また、開発実施フェーズにおいては【見える化】および【見せる化】の一環として、コードレビューが挙げられます。何百万行のコードの中から対象となるステップについて、脆弱性につながる関数をすべて抽出し、それぞれ妥当であるかを確認する作業となります。関数が構造上適切につくられているかどうかはツールでチェックできますが、関数のつくり方は正しくても脆弱性がある場合もあります。サニタイジング（無害化）で対処するような問題がその典型です。これらの作業は一般に、ツールでは対応できないためツールをカスタマイズする、もしくは専門家による手作業となります。
さらにシステム導入の全過程に共通して言えることは、ステークホルダーは複数存在し、各ステークホルダーがそれぞれの責任権限を有しながら情報を共有しているということです。ユーザー側のトップマネジメントに見せる情報と、開発側のトップに見せる情報では大きく異なります。
【見える化】および【見せる化】は、誰が見るのかがとても重要になります。
最近の情報セキュリティ対策で求められる【見える化】および【見せる化】の一面をご理解いただけたでしょうか。
※上記ページは掲載時点の内容であるため、ページ中にリンク切れやリンク先が適切でないリンクなどがある可能性があります。ご了承いただくようお願い申し上げます。
