最終回 DBをセキュアに保つために行うべき作業
星野 真理
株式会社システム・テクノロジー・アイ
2005/5/26
 |
データアクセスの監視 |
セキュリティ強化を行い、データを悪意のあるアクセスから保護する。よって、データは安全である。
と、いい切りたいところですが、どんなにセキュリティ強化を行ってもデータ漏えい問題が発生しないとは限りません。セキュリティを実装するのが人間である以上、人為的なミスもありますし、思いもよらない盲点がないとはいえません。
万が一、データ漏えいが発生した際に、その原因を突き止め、漏えい経路と漏えいデータの範囲を特定できることが必要です。
DBユーザー管理の項目と、データ管理の項目で述べた作業を行うことで、「誰がどの範囲のデータにアクセスできるか」を把握することはできます。しかし、これだけでは、「いつ漏えいしたのか」が分かりませんし、悪意のあるユーザーが機密データにアクセスしようとトライしていることも検出できません。
そこで必要になってくるのが、データへのアクセスの監視です。監視状況をログに残し、定期的に確認することで不審なアクセスがないかを確認します。監視する対象としては、以下の3つに大別されます。
- DBサーバへのアクセス（OSへのログイン）
- データベースへのアクセス（データベースへのログイン）
- DBデータへのアクセス（表の検索）
今回は、データベースに着目し、2と3について検討していきます。
データベースへのアクセスを監視し、ログに残すことを「監査」と呼びます。監査の実装を考えるときのポイントは、「何を対象として、どのような監査ログが必要か」です。以下の3点を考慮に入れます。
- データ漏えいの際に監査ログから、必要な追跡データが抽出できること
- 監査作業がシステムパフォーマンスの劣化原因とならないこと
- ログデータの容量を検討し、必要最低限のログのみを作成すること
監査対象としては、ログイン、表、時間、ユーザー、アプリケーションなどが挙げられます。これらの対象に対して、どんなときにログを取得するかを組み合わせて考えると以下のようになります。
- ログイン（特定の時間のみ／すべての時間）
特定のユーザーのみ（成功のみ／失敗のみ／両方）
すべてのユーザー（成功のみ／失敗のみ／両方）
- 表へのアクセス（特定の時間のみ／すべての時間）
特定のユーザーのみ／すべてのユーザー
特定の表のみ／すべての表
特定のアプリケーションのみ（成功のみ／失敗のみ／両方）
すべてのアプリケーション（成功のみ／失敗のみ／両方）
このように列挙してみるとどれを選択すべきか迷ってしまいます。さっそく、上記の対象について検討してみましょう。
●ログイン
すべてのユーザーのすべての時間のデータベースへのアクセスについて、成功・失敗の両方を取得するとアプリケーションにログインするたびにログが取得されます。特に、クライアント／サーバのシステムであれば大量のログが取得され、管理も困難となります。
データ漏えいは、ログインしただけでは発生しません。機密データにアクセスできて、初めてデータ漏えいの危険が発生します。それ故、ログインに関しては、パスワード解読を試みた結果発生するログインの失敗を監視するのがいいでしょう。
●表へのアクセス
データベース上のすべての表が機密データではないことを考慮すれば、機密データを含む表だけで十分です。できれば、表の中でも機密列にアクセスした場合のみを監査対象にしたいものです。
●時間
データ漏えいが発生する時間を特定することはできませんから、すべての時間が対象です。
●ユーザー
DBユーザーは、大別するとDB管理者、表の所有者、アプリケーションから使用されるユーザー、エンドユーザー・コンピューティングのためのユーザーの4つに分かれます。
しかし、どのユーザーがデータ漏えいを行うかは、分かりません。DB管理者や表の所有者などの特権ユーザーが表にアクセスするのは当然だからログを残さないという判断は危険です。もし、データ漏えいが特権ユーザーで行われた場合は、原因の特定ができません。つまり、すべてのユーザーが対象になります。
●アプリケーション
機密データに対して、どのアプリケーションからアクセスした場合にログを取得するかを決める必要があります。データベースにアクセスするアプリケーションは、以下のように大別されます。
- システム開発により作成されたアプリケーション
- データベースに付属するクライアントツール
- サードベンダツール
上記3種において、システム開発により作成されたアプリケーションからのアクセスであれば、そのアプリケーションに許可された範囲でのみ機密データにアクセスとなるはずです。よって、このようなアクセスにログを残す必要はありませんし、このようなアクセスにまでログに残すとなるとログ容量が膨大なものになります。
一方、データベースに付属するクライアントツールや、サードベンダツールなどの場合はデータベースにログインしてしまえば、自由にさまざまな処理ができる可能性があります。しっかりログを取得する必要があります。ただし、使用アプリケーションの特定はコーディングを要する可能性が高く、パフォーマンスへの影響も検討する必要がありますので、実装期間は十分に準備してください。
このように監査をする対象を決めたところで、その監査ログの内容についても検討します。データ漏えいが発生した場合に、その原因を突き止めるためには、「いつ」「誰が」「どのデータを」「どのツールで」「何をしたか」が、判明できることが求められます。この条件を満たすためには、監査ログには、以下の内容が必要です。
- DBユーザー名
- OSユーザー名
- クライアントマシン名
- 日時
- 使用したツール
- アクセスした表名
- 実行したSQL
以上、どのような監査ログを取得するのかを決めました。あとは、実装の方法を決めるだけです。使用するデータベースにおける監査ログの機能をチェックします。もちろん、求める機能がデータベースに実装されているとは限りませんし、コーディングに依存するケースも多いでしょう。
では、Oracleを例に挙げて、監査処理の実装計画を図3、図4で確認してみましょう。
 |
| 図3 不正ログインの監視 |
 |
| 図4 機密データへのアクセスを監視 |
 |
3/4
|
|
| Index | |
| DBをセキュアに保つための作業 | |
| Page1 DBユーザー管理 |
|
| Page2 DBユーザーのパスワードの変更確認 データ管理 |
|
 |
Page3 データアクセスの監視 |
| Page4 バックアップ管理 セキュリティと生産性のバランス感覚 コラム：バックアップの意外な実態 |
|
| 関連記事 |
| データベースセキュリティの基礎のキソ |
| Database Expertフォーラム |
 |
Security&Trust記事一覧 |
- Windows起動前後にデバイスを守る工夫、ルートキットを防ぐ （2017/7/24）
Windows 10が備える多彩なセキュリティ対策機能を丸ごと理解するには、5つのスタックに分けて順に押さえていくことが早道だ。連載第1回は、Windows起動前の「デバイスの保護」とHyper-Vを用いたセキュリティ構成について紹介する。 - WannaCryがホンダやマクドにも。中学3年生が作ったランサムウェアの正体も話題に （2017/7/11）
2017年6月のセキュリティクラスタでは、「WannaCry」の残り火にやられたホンダや亜種に感染したマクドナルドに注目が集まった他、ランサムウェアを作成して配布した中学3年生、ランサムウェアに降伏してしまった韓国のホスティング企業など、5月に引き続きランサムウェアの話題が席巻していました。 - Recruit-CSIRTがマルウェアの「培養」用に内製した動的解析環境、その目的と工夫とは （2017/7/10）
代表的なマルウェア解析方法を紹介し、自社のみに影響があるマルウェアを「培養」するために構築した動的解析環境について解説する - 侵入されることを前提に考える――内部対策はログ管理から （2017/7/5）
人員リソースや予算の限られた中堅・中小企業にとって、大企業で導入されがちな、過剰に高機能で管理負荷の高いセキュリティ対策を施すのは現実的ではない。本連載では、中堅・中小企業が目指すべきセキュリティ対策の“現実解“を、特に標的型攻撃（APT：Advanced Persistent Threat）対策の観点から考える。
 |
|
|
|
|
