“攻めと守り”で固めるデータベースセキュリティ──「Oracle Database Vault」と「Oracle Audit Vault and Database Firewall」：特権ユーザーによる内部犯行を効果的に防ぎ、万一の際のトレーサビリティを確保する（3/4 ページ）

[PR／＠IT]

PR

データベースのアクセス制御、管理者権限の職務分掌を徹底して内部犯行を防ぐ「Oracle Database Vault」

　初めに取り上げるのはOracle Database Vaultだ。同製品は、主に次の二つの機能を提供する。

1. データベースのアクセス制御
2. データベース管理者権限の職務分掌

　「（1）データベースのアクセス制御」機能を使うと、データベース管理者を含む全てのユーザーに対して、データベースアクセスを詳細にコントロールすることが可能となる。他のセキュリティソリューションに備わる権限付与／奪取の仕組みでも同じことができると考えるかもしれないが、Oracle Database Vaultの機構はそれらとはまったく異なる。たとえ権限を付与されたユーザーであってもブロッキングすることが可能なのだ。データベースアクセスをSQLのレベルで管理できるため、例えばTRUNCATEのようなデータ破壊を引き起こす恐れのあるコマンドの実行を制限するといったこともできるのである。

　また、Oracle Database Vaultの特徴的な機能が、「（2）データベース管理者権限の職務分掌」だ。

　“職務分掌”とは、組織においてそれぞれの職務が果たすべき「責務（職責）」や、職責を果たす上で必要となる「権限（職権）」を明確にするために、職務ごとの役割を整理／配分することを指す。データベース管理の経験をお持ちの方は、DBAロールやSYSDBAロールを持つ特権ユーザーが、データベースに対してどのような操作でも行えることにセキュリティ上の脅威を感じたことがあるだろう。そうしたロールと、そのロールに必要な権限、不要な権限を分けて管理することで、特権ユーザーによる不適切な操作を防ぐことができるのだ。

　それでは、Oracle Database Vaultを導入した環境では、実際にどのようことが行えるのだろうか。次の図を基に説明しよう。

　上図の左側は従来の一般的なセキュリティソリューションで保護された環境だが、この環境は次の二つの問題を抱えている。

• システム権限を持つデータベース管理者が、業務データに簡単にアクセスできる
• データベース管理者は、バックドアユーザーを作れてしまう

　このような特権ユーザーが作成されると、いつ、どこで、誰が、何をやったのか、どのデータを閲覧したのかが分からない状態が発生する。その結果、何らかのインシデントが発生した後の対応が遅くなるという問題が生じる可能性がある。また、特権ユーザーを作れるのはデータベース管理者である。つまり、データベース管理者が意図すれば、バックドアユーザーも簡単に作れてしまうわけだ。

　これに対して、Oracle Database Vaultを導入した環境が図の右側となる。同製品を導入した環境では、「セキュリティ管理者」と「ユーザー管理者」という二つの特徴的なロールが作られる。

　このうち、セキュリティ管理者とは、データベースシステムのセキュリティ管理を担うユーザーである。この管理者は、全てのユーザーに対して、データへのアクセス権限などを設定できる。例えば、セキュリティ管理者がデータベース管理者に対して業務データへのアクセスを禁じる設定を行うと、たとえデータベース管理者がシステム権限を持っていたとしても、業務データにはアクセスできなくなる。これにより、データベース管理者の特権を抑止できるわけだ。

　ここで、「セキュリティ管理者が新たな特権ユーザーとなり、業務データに自由にアクセス可能となるだけではないか？」という疑問を抱いた方がおられるかもしれないが、その心配は無用だ。セキュリティ管理者は、あくまでもデータベースへのアクセスルールを作るだけのユーザーであり、データベースにアクセスすることはできない。この点が、セキュリティ管理者が他のユーザーと大きく異なるところだ。

　それでは、もう一つのユーザー管理者は何を行うのか？ 先にデータベース管理者によりバックドアユーザーが作られる危険性を指摘したが、それを効果的に防止する仕組みがユーザー管理者である。Oracle Database Vaultでは、ユーザー管理者がユーザーを作り、データベース管理者がそれらのユーザーに対して権限の付与を行う。こうして、ユーザー管理とセキュリティ管理を別の担当者が行うことにより、悪意を持ったユーザーにより不正アクセスが行われる危険性を減らしているのである。

レルムとルールセットにより、DBアクセスをコマンドレベルで制御

　Oracle Database Vaultでは、どのような機構によって上記の職務分掌を実現しているのだろうか。この仕組みで鍵となる概念は二つある。一つが「レルム」、もう一つが「ルールセット」だ。

　レルムとは、個々のデータベーススキーマオブジェクトに対して論理的な領域を作成するものであり、これによって各データベースオブジェクトは論理的な“箱”の中で保護される。

　それぞれの箱の中にあるデータベースオブジェクトにアクセスする際には、レルム側の許可が必要となる。もし許可されていないユーザーがアクセスしようとした場合は、セキュリティ違反として監査ログに記録される。

　ルールセットも、Oracle Database Vaultの高度なアクセス制御を支える特徴的な機能である。

　Oracle Database Vaultでは、簡単な数式で書かれたルールにより、データベースへのアクセス制御を行う。この式の中でアクセスを許可するIPアドレスやホスト名、データベースを指定するわけだ。ルールセットとは、それら一つ一つのルールを組み合わせて、より複雑なルール（データベースのアクセスコントロール）を作るためのものである。

　例えば、時刻、曜日、クライアントIPの情報を判定するルールを作ったとしよう。その内容は、時間ならば「9時〜17時」、曜日ならば「月曜〜金曜日」、クライアントIPならば「192.168.100.1」といったものになる。これらを論理積で連結して「月曜〜金曜の9時〜17時、192.168.100.1からのアクセス」といったルールセットを作成する。

　ルールセットを定義したら、それを個別のSQLと関連付けることで具体的なアクセスコントロールの定義を行う。ルールセットとひも付けられたSQLコマンドは「コマンドルール」と呼ぶ。コマンドルールは、それがひも付けられたルールセットの評価の結果が真（True）である場合だけ発行される。