Pick Upテクノロジー
データベース・セキュリティの実装 第1回 アクセスコントロールと権限管理
■データベースのセキュリティで情報を保護することの意義
RDBMSにおける情報保護、いわゆるデータベース・セキュリティは2004年、個人情報保護法の完全施行を前にして多くの漏洩事件が明るみに出た時期を大きなターニングポイントとして、速くて止まらず管理しやすければ良いというだけはなくセキュリティが確保されているということが同時に強く求められるようになったと言えるだろう。
内部犯行による意図的な情報漏洩事件について考えるときにやっかいな問題のひとつは「情報を盗んでも窃盗ではない」ということであるが、この問題を解決する方法の一つとして期待されているのが不正競争防止法の改正である。2009年4月に改正案が国会で可決・成立しており、2011年に入って実際の検挙事例も出てきた。この不正競争防止法では「不正の利益を得る目的」で「営業秘密を記録した媒体等を横領する行為、無断で複製する行為」が処罰対象となるとされ、情報を盗む行為自体を直接的に処罰することが可能になると考えられている。
出所：経済産業省「不正競争防止法の一部を改正する法律案」平成21年 （平成21年4月21日可決成立）
しかし不正競争防止法を適用するためには「営業秘密の三要件」（秘密管理性・有用性・非公知性）を満たすように、情報が「営業秘密」としてしっかり保護されている必要がある。この三要件における秘密管理性を満たすためには、デジタルデータとして取り扱っている企業の機密情報に対してITシステムの内部でしっかりセキュリティ対策を実施しておかなければならない。このとき情報を格納する「金庫」そのものであるデータベースのセキュリティ対策は非常に重要な役割を果たすと言える。
こうした課題を解決していくために、これから４回にわたってオラクルのデータベース・セキュリティを解説していく。１回目の今回はアクセスコントロール、２回目はログ取得と監査機能、３回目として暗号とその高速化技術、そして最終回では新しいトピックとしてOracle Database Firewallを取り上げるのでご期待頂きたい。
■データベース・セキュリティにおけるアクセスコントロールと権限管理
正しいID/パスワードを使ってログインしたユーザーはその後何をしてもよいわけではなく、アクセスコントロールのための原則のひとつ「最小権限の原則」（Least Privilege）に基づいて管理・制限されていなければならない。これは各ユーザーに業務上必要となる最低限の権限のみを付与するというものであり、データベース管理者、プログラム開発者、運用管理者、アプリケーション（プログラムそのもの）などRDBMS上のユーザーが付与されている権限はそれぞれの職務に必要なものだけに限定されていることが必要である。
１．オブジェクトに対するアクセスコントロール
具体的にはデータベース内の表、ビューといったオブジェクトに対する権限（主にSELECT,INSERT,UPDATE,DELETEといったDMLを使う権限）をユーザーごとに最小化する必要がある。どのユーザーはどの表に対して、どの権限を使うことができるかをアクセスマトリクスに整理して確認し、これに基づいて厳密な権限付与を行うことが重要となる。
データベース用のアクセスマトリクスを作成した例
この時Webアプリケーションのような三層構造のシステムでは「アプリケーションが利用しているユーザー」に対する権限付与を確実にチェックする必要があり、このことはSQLインジェクションなど外部からの攻撃に対する被害を最小化することにもつながる。また多くの権限を全て個別に管理していると運用が非常に煩雑になるためRole（ユーザー定義によるRole）を使って一定の単位でまとめて管理をしていくと良い。
しかし一つの表の中に「アクセスさせて良いデータ」と「アクセスを禁止したいデータ」が混在していて、特定の行、列単位でアクセスコントロールを行わなければならない場合があり、オブジェクトに対する権限を管理しただけでは十分ではない。このときの代表的な構成方法がViewを使って必要な部分だけをもとの表から抽出してアクセスさせる方法である。
ビューを使ったアクセスコントロール
しかし、このViewを使った制御は、アクセスコントロールの粒度が細かくなるとViewの数が増え、組織変更や人事異動、ポリシー変更などの際に管理・メンテナンスが複雑になり、人為的なミスや変更漏れなどが起きる可能性もある。
こうしたときにオラクルでは仮想プライベート・データベース（Virtual Private Database：VPD）を使って、Viewを使うことなく、行・列レベルでのアクセスコントロールが可能である。VPDではあらかじめ設定したアクセス・ポリシーに従ってSQL文を強制的に書き換える（where句を付加する）動作をする「ファイングレイン・アクセスコントロール」とアクセスコントロールを実施するために必要なユーザーの属性（部署名や職責など）を格納しておく「アプリケーション・コンテキスト」の二つの要素から構成されている。
ファイングレイン・アクセスコントロールが適用されている表に対してユーザーがアクセスを試みると、データベースはアプリケーション・コンテキストに格納された値を入手し、その値とアクセス・ポリシーに基づいて必要なwhere句をSQL文に付加する。ポリシーはあらかじめPL/SQLで作成し、アクセス制御を実施したい表・ビューなどに適用しておく。またアプリケーション・コンテキストはデフォルトで用意されたユーザ・コンテキストを使うこともできるが、あらかじめ格納したい属性値を決め、値を格納するためのパッケージを作成したうえで独自に定義することもできる。）
実際にSQLを処理するのはこの後になるため、あたかもはじめから条件句をつけて発行したSQL文であるかのように処理が行われ、その結果の値がユーザー側には返される。従ってユーザーからみると、あたかも自分が発行した（条件句が付加される前の）SQL文に対する結果が返ってきたように見える。これが仮想プライベート・データベースと呼ばれるゆえんである。
仮想プライベートデータベース（VPD）のしくみ
またVPDの場合性能に対する影響が非常に小さいことも特徴である。これは通常の処理以外に追加で行う動作はポリシーの参照とSQL文の変更（where句の追加）を1度実行するだけで良いからである。従って検索の場合、検索対象行数が増えるほど、性能に対する影響（VPDを使わなかった場合と比較した場合の比率）は相対的に小さくなっていく。
具体的な実装方法についてはセキュリティガイドなどを参照されたい。
２．開発や運用・管理のための権限に対するコントロール
データベース上で利用される権限はオブジェクト権限以外にも開発や運用・管理のために利用される様々な権限があり、これらもきちんと管理・分離しておく必要がある。
従来SYS、SYSTEMなどのDBAユーザーとそのパスワードがシステム部門の運用現場などでは複数の人で共有されているケースが多かった。しかしこの状態では実際の業務内容以上に過大な権限を保有する人が増え、内部情報漏えいを引き起こす温床になる。また万一事件・事故が起きた場合に誰が操作をしたのか特定できなくなるという問題もある。
従って今後は開発者、運用・管理者などに対して「便利で簡単、楽だから」という理由で安易にSYSを使わせたり、DBA権限（DBA Role）を付与したりするようなことは行うべきではない。
例えばデータベースの運用者は多くの場合、稼働しているデータベースの起動・停止やバックアップ・リカバリ、チューニングなどを主な業務にしている場合が多く、アプリケーションが取り扱っている実際のビジネスデータ（会計システムであれば財務会計に関する情報）を検索・更新する必要はほとんどないことが多い。にもかかわらずデータベース運用者はDBA権限を持っていて、格納された全ての情報を閲覧・変更することが可能であり、全ての設定変更ができることが多い。
さらに操作履歴をログとして収集していたとしても、データベース内にあれば改ざんすることができる。また悪意がなくても誤操作でデータを変更してしまう可能性もある。
しかし現実的にはSYSやSYSTEMやDBA Roleを使わなければならない作業は存在する。そのためDBA権限を制限する、という従来のデータベースでは不可能だった権限分離を実現するために開発されたのがOracle Database Vaultである。Oracle Database VaultではDBAの管理者権限を制限し、ユーザー管理者、アプリケーション管理者といった複数の管理者に管理業務と権限を分割することが可能となっている
Oracle Database Vaultにおいて、この職務分掌と権限分離を実現するために新たに加わった主な技術要素として Realm があり、複数要素に基づいた厳密な管理を行うための技術要素としてCommand Rule やSecure Application Role がある。
Realm（レルム）：
新たな「Realm（レルム）」という単位は仮想的にデータベース内部を分割し、保護したい表・ビューなど（スキーマ・オブジェクト）を割り付けることができる。Realmには個別に管理者を設けることができるようになり、これらは通常アプリケーション管理者となる。アプリケーション管理者が明示的に許可しない限り、Realmで保護されている表・ビューなどにはDBAであってもアクセスすることはできない。その一方DBAが使用する表・ビューなどは別の専用Realmで保護されているため、他のアプリケーション管理者はアクセスできない。こうして各管理者の権限を分割・制限することで職務分掌と整合性のとれたアクセス管理を実現することになる。
レルムの設定画面：
レルムで保護されたオブジェクトにDBA権限でアクセスを試みてエラーとなる画面：
Command Rule：
特定のSQL（データベースに対して使われる問い合わせ言語）コマンドの使用条件を定義したもの。権限管理のための論理的な条件がRule、複数のRuleを組み合わせてより高度な管理を実現する論理セットがRule Setである。この Rule/Rule Set を使って詳細な条件を設定すると、使用が許可されているコマンドであっても、その使用条件をさらに細かく制限することが可能になる。例えば、平日の日中10:00～18:00のみ、特定の静的IPアドレスを持つ端末からだけコマンドを使用できる、といった管理が簡単に設定できるようになる。
Secure Application Role：
通常は、特定のRoleを付与されたユーザーはそのRoleに含まれている全ての権限を常に使うことができるが、このSecure Application Roleを使うと前述のRule Setで決められた条件を満たす場合にのみ動的使用許可を与えることができるようになる。
オラクルエンジニア通信：「【技術資料】Oracle Database Vault 概要」
オラクルエンジニア通信：「【技術記事】特権ユーザー管理の確立と効率化」
このようにオラクルでは標準機能であるオブジェクト権限やRole、仮想プライベート・データベース（Enterprise Edition）などで細かい権限管理を実装することができる。さらに高度なセキュリティを求められるシステムでは、Oracle Database Vaultを使うことで従来制限できなかったDBAの権限を分離・制限することも可能である。詳しくはホワイト・ペーパー (PDF)や Oracle Database 11g セキュリティガイド なども参照されたい。
次回は皆様からご関心の高い、ログの取得と監査機能について取り上げることにするのでご期待頂きたい。
■関連資料