最終回 DBをセキュアに保つために行うべき作業


星野 真理
株式会社システム・テクノロジー・アイ
2005/5/26



 データアクセスの監視

 セキュリティ強化を行い、データを悪意のあるアクセスから保護する。よって、データは安全である。

 と、いい切りたいところですが、どんなにセキュリティ強化を行ってもデータ漏えい問題が発生しないとは限りません。セキュリティを実装するのが人間である以上、人為的なミスもありますし、思いもよらない盲点がないとはいえません。

 万が一、データ漏えいが発生した際に、その原因を突き止め、漏えい経路と漏えいデータの範囲を特定できることが必要です。

 DBユーザー管理の項目と、データ管理の項目で述べた作業を行うことで、「誰がどの範囲のデータにアクセスできるか」を把握することはできます。しかし、これだけでは、「いつ漏えいしたのか」が分かりませんし、悪意のあるユーザーが機密データにアクセスしようとトライしていることも検出できません。

 そこで必要になってくるのが、データへのアクセスの監視です。監視状況をログに残し、定期的に確認することで不審なアクセスがないかを確認します。監視する対象としては、以下の3つに大別されます。

  1. DBサーバへのアクセス(OSへのログイン)
  2. データベースへのアクセス(データベースへのログイン)
  3. 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
バックアップ管理
セキュリティと生産性のバランス感覚
コラム:バックアップの意外な実態


DBセキュリティ虎の巻 バックナンバー


関連記事
データベースセキュリティの基礎のキソ
Database Expertフォーラム

Security&Trust記事一覧


Security&Trust フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)
- PR -

注目のテーマ

Security & Trust 記事ランキング

本日 月間
ソリューションFLASH