Loading
|
@IT > 内部統制時代に対応するためのデータベース利用の権限分掌 |
個人情報流出を回避し内部統制に対応するには、情報を格納するデータベースと、それに関わるアクセス権限などを徹底することが重要だ。オラクルが提案する最新データベース・セキュリティ対策を検証する。
日本版SOX法の施行を控えた現在、多くの企業で内部統制に伴う情報セキュリティ対策が急務となった。金融庁が発表した「財務報告に係る内部統制の評価及び監査の基準(案)」によると、内部統制とは業務の有効性や効率性、財務報告の信頼性、事業活動に関わる法令などの遵守、資産の保全が達成されていることを保証するため、組織内で統制活動や監視、リスクの評価と対応、ITへの対応を実施するものと定義している。 つまり、内部統制を実現するには現状のリスクを正しく評価し、適切なITの対応を施さなければならないということだ。最悪の場合、2007年3月13日に発表された大日本印刷による個人情報流出事件のように、企業の社会的地位を揺るがす大問題に発展する可能性がある。 では、このような情報漏えい事件が起こるリスクはどこにあるのだろうか。過去の事件は総じて、内部犯行が大半を占める。通常、機密性の高いデータはデータベース管理者(DBA)などの限られたユーザーのみがアクセスできるよう設定されている。それでもなお情報が流出するということは、その限られた特権ユーザーがアクセスして無断で持ち出している可能性が高いということだ。 DBAの本来の作業は、データベースのバックアップやリカバリ、データファイルの拡大、Redoログバッファのサイズ調整といった運用および管理にある。しかし、それゆえにデータベースへの全面的なアクセスが許可されており、データの持ち出しや削除も簡単に行えてしまうのが実情だ。 DBAは、個人情報はもちろんのこと、全従業員の給与情報や会計データなど、経営リスクに関わるクリティカルなデータを読むことができるのである。ログの改ざんや不正アクセス用ユーザーの無断作成なども実行できるので、情報の正当性の保証すら難しくなる。 30年以上も前からデータベース・セキュリティに取り組むオラクルでは、DBAを脅威と捉える企業が多いことに着目した。オラクルはこれまで、Oracle Database 10gにおいてISO/IEC15408の認証を取得し、データベース管理ソフトウェアを対象とした情報基盤強化税制に対応するなど、セキュリティに対して積極的な姿勢を見せる。その同社が、情報漏洩防止と、より適切な内部統制への対応を目指す企業に提案するのが、「Oracle Database Vault」による厳密なアクセス制御と、「Transparent Data Encryption」によるデータの暗号化である。
Oracle Database Vaultは、これまでDBAに与えられていたデータベース管理やユーザー・アカウント管理、セキュリティ・ポリシー管理、アプリケーション・データの管理などを分割し、DBAの権限を必要最小限に抑えるものだ。 Oracle Database Vaultの特徴は、複数の要素を組み合わせて詳細なアクセス制御を実現する点だ。要素には、タイムスタンプやクライアント・アプリケーション、OSユーザー、ホスト、アクセスした時間帯、曜日、ドメインなどの「ファクタ」と呼ばれるものがある。 これをSQLコマンドなどへ条件付けしてコマンドルールなどを作成することにより、例えばユーザーのSELECT権限やDELETE権限といった実行条件をきめ細かく制御できる(図1)。ファクタには、このほかDEPT表でユーザーが属するDEPTNO列の値といった動的に 変化するようなユーザー定義も適用できる。
制御できるのは、アクセス方法のみではない。データベース内に顧客情報、人事や経理といった保護領域(レルム)を設定し、それぞれに管理者を配置してアクセス制御を設けることができる。 レルムとは、任意のスキーマ・オブジェクトのセットを保護および管理する論理的な単位だ。各レルムの管理者はほかのレルムへアクセスする権限が付与されず、あくまでも閉じたDBA権限が付与されることになる。 その結果、例えばDBAはデータベースサーバの実装および運用に必要なデータディクショナリのみアクセスできるが、人事データにはアクセスできないといったアクセス制御も実現する。レルムは論理的な単位なので、データベースを統合した場合も複数作成することでデータベースを仮想的に運用管理できる。 レポーティング機能も充実している。レルムやファクタを設定する際に監査の有無やタイミングを指定すると、その指定内容に併せて監査ログがデータベース表に記録される。記録される情報には、不正アクセスやアクセス状況のログから、データベース表の権限情報などさまざまだ。当然、監査ログデータは指定された特権ユーザーのみがアクセスできるよう設定される。
内部統制において、もう1つの重要ポイントは「暗号化」である。情報漏えいの流出経路の1つに、ハードディスクなどの盗難や紛失が挙げられる。ハードディスクが盗まれたとき、暗号化されていなければデータは簡単に取得されてしまう。 また、たとえハードディスク内にあるデータベースにID/パスワード設定がされており、アクセスできない場合でも、OSを乗っ取ることができればバイナリーレベルでデータを見ることは可能だ。つまり、アプリケーションレベルでいくらアクセス制御をかけても、物理的およびOSレベルでの暗号化対策が施されていなければ、まったく意味のないものになってしまう。 オラクルでは、Oracle9i Databaseからのオプション機能「Oracle Advanced Security Option」によって、データベースの暗号化機能を提供している。同オプションにはネットワークの暗号化と通信の暗号化が含まれており、Oracle Database 10g Release 2からは新たに「Transparent Data Encryption(TDE)」が追加された(図2)。
従来のAPIによる暗号化では、暗号化処理のためのコール数が多くてパフォーマンスが劣化し、さらに暗号化するためのアプリケーションの変更が必要など、さまざまな課題があった。それに対して、TDEは表定義の変更をすることでデータを暗号化する。そのため、アプリケーションを変更することなくデータベース内に格納されたデータを暗号化できる。さらに、列単位での暗号化や索引の作成および検索も可能だ。 既存アプリケーションを活用できるTDEは、すでに多くの企業で導入されている。例えば大手ISP事業者では住所や氏名といった個人情報を暗号化する際にTDEを利用しており、万が一の盗難に備えての対策を行っている。このほか、Webショッピングサイトなどの小売業では顧客の住所といった個人情報や店舗の売上データなど、製造業者では仕様書や特許関連のデータなど、金融業者では顧客の残高情報といったように、幅広い業種で採用されている。 ただし、TDEの運用においていくつか注意点および制限事項がある。1つは、TDEの暗号化列に対する索引はUnique Scanによるアクセスのみ対応する。また、Range Scanといったデータの順序が意味を持つようなアクセス方式では、列データが暗号化された状態で格納されているので索引できない。 もう1つは、TDEのマスターキーの盗難や不正なデータの復号化を防止するには、Oracle WalletをセキュアなデバイスやOSのファイルシステムに格納する必要がある点だ。当然、OSのIDやパスワードも併せて厳重に管理する。
情報へのアクセスが正しいことを保証するには、データベースによるアクセスログの取得と保全も必須だ。しかし、監査対象のログは業務アプリケーションサーバやWebサーバなど、ネットワークのあらゆる場所で分散的に記録されている。それぞれの特権ユーザーも一元化されていないので、実質的にはDBAであれば自由に監査用ログを改ざんできる状態にあるといってよい。 また、ログデータは増えることがあっても減ることはない。膨大化するデータに対して、監査時に必要なデータを素早く検索して取り出すのはパフォーマンス的に難しい。 このような問題を解決するのが、監査用ログを統合管理しデータウェアハウスとして機能する「Oracle Audit Vault」だ。同製品は、Oracle9i Database Release 2、Oracle Database 10g Release1およびRelease 2のデータベースによる監査データを収集し、データにアクセスした全ユーザーがどのような変更、修正、削除などを行ったか監視する。 さらに、監査証跡の客観性を保つため、DBAによる監査データへのアクセスを制限し、セキュリティ・ポリシーに従って不正行為の通知も行う。これは、Oracle Database Vaultの機能を活用した対策になる。また、検索においてもパーティションなどにより、データへのアクセスを高速化した。同製品は、今後出荷予定だ。 提供:日本オラクル株式会社 企画:アイティメディア 営業局 制作:@IT編集部 掲載内容有効期限:2007年5月31日 |
|