不正行為を未然に防ぐログの分析と活用
ログの分析と活用でセキュリティを維持する
データベースセキュリティ製品を使ってアクセスログを監視、分析することによって、さまざまな事象が分かり、不正アクセスや情報漏えいの防止が可能になります。
ログイン失敗を記録したログを例に取りましょう。エンドユーザーが単純にパスワードをタイプミスした場合に、次のログインで成功している場合は正常な振る舞いと見なすことができます。しかし、同じIDで何度もログインの失敗が続けば、パスワードを探るための辞書攻撃と見なすことができます。また、操作の失敗を監査したときに、Webサーバ/APサーバ経由のアクセスによる通常のアプリケーション操作では、実行されるSQLコマンドはプログラムで規定されているので、基本的に処理の失敗は起こりません。もし、そのアクセス経路で失敗が記録されているとしたら、システムに詳しい運用担当者やデータベース管理者が正規のアクセス経路を装って、不正にアクセスしている可能性があると判断できます。
●図2 ログイン失敗のログから判断できることユーザーアカウントとアクセスポイントの関係を監査したときにも、いろいろな状況を判断することができます。通常、固定された端末からWebサーバ/APサーバ経由でアクセスされる場合は、端末のOSへのログインID、Webサーバ/APサーバへのログインID、データベースへのログインIDの組み合わせは固定されています。しかし、規定されていないWebサーバ/APサーバ端末からWebサーバ/APサーバにログインするアカウントを利用してアクセスした場合は、誰かがWebサーバ/APサーバ用のアカウントを使って不正にアクセスしていると考えられます。また、複数のエンドユーザーが1台の端末を利用していれば、共有端末でのアクセスであるか、なりすましでのアクセスかが判断できます。
●図3 アカウントとアクセスポイントとの関係から正当性を判断するこのほかにも、システム運用時間外のアクセスがあった場合、あるいは非常に長いセッションがあった場合は、ログインしたままの離席や帰宅など業務ルールに違反しているユーザーを特定できます。さらに、データベースによっては1回のセッションでどれぐらいのデータ量を読み取ったか、どれだけのボリュームにアクセスしたかを記録できるので、日々のオペレーション傾向が把握できます。それと比較して大量のデータ読み取りがあれば、異常なアクセスと見ることができます。
情報漏えい事件から学ぶべきこと
第1回の冒頭で、大手証券会社の顧客情報漏えい事件の事例を紹介しましたが、不正アクセス禁止法と窃盗の罪に問われた同社のシステム部元部長代理の行動を振り返ってみると、データベースセキュリティツールでログ監査をきちんと実施していれば、事件は未然に防ぐことができたと考えられます。
退職社員が148万人の顧客情報を持ち出し――三菱UFJ証券が発表
http://www.itmedia.co.jp/enterprise/articles/0904/08/news092.html
業績に大きな打撃、補償には適切に対応
---三菱UFJ証券の秋草社長が会見(ITpro)
http://itpro.nikkeibp.co.jp/article/NEWS/20090418/328650/
部長代理による犯罪の実行は、別の従業員のIDとパスワードを使用し、顧客情報を管理するサーバにアクセスして顧客情報を取得したことに始まります。このときの行為をさらにブレークダウンすると、
- Windows端末に自分のIDでログイン
- →データベースアクセスツールに他人のIDでログイン
- →データベースにアクセスして148万人の顧客情報を不正に取得
という流れで実行されています。このときに犯行を発覚しにくくするために、特定端末を長時間使用しないなどの工作を行っていたことも後に判明しています。
同社ではログの収集をしていたと思われますが、セキュリティツールによってそのログを活用していれば、OSのユーザーIDとデータベースアクセスツールのユーザーID、さらにアクセス端末の組み合わせによって「正規でないアクセス」であるとすぐに判断できたはずです。また、このアカウントの組み合わせにより、端末だけを数回変えた複数のアクセス元から、何度かログイン/ログアウトした点も把握できたと考えられます。さらに、数回に分けたとしても数百万人ものレコードを読み取ったことは、通常のオペレーション傾向と比較して明らかに異常だと検知できたと思われます。
このように、犯行に結び付く怪しいアクセスがあったことをログの分析で把握していれば、顧客情報が外部に流出する手前で疑わしい人物を特定できたでしょうし、犯行を未然に防ぐことができたかもしれません。
ログを収集していても、それを分析して不正かどうか判断することを人間が行うのでは負荷もコストも増大します。収集したログをリアルタイムで検知し、通報する、データベースセキュリティツールの重要性の高さを理解し、正しくログを「運用」しましょう。
セキュリティ、そろそろ本音で語らないか(10)
誌上セミナー「拡大を続けるログ砂漠」(@IT Security&Trust)
http://www.atmarkit.co.jp/fsecurity/rensai/talk10/talk01.html
セキュリティ、そろそろ本音で語らないか(12)
セキュリティシステムをマネジメントせよ (@IT Security&Trust)
http://www.atmarkit.co.jp/fsecurity/rensai/talk12/talk01.html
成田泰彦 (なりた やすひこ)
フォーティネットジャパン株式会社
セールスエンジニアリング部 シニアコンサルティングSE
株式会社アシストにてRDBMSを使ったアプリケーション開発の技術支援エンジニアとしての経験を基に、後年ではシングルサインオン・アクセスコントロールシステムの構築支援・コンサルタントを担当。
その後アイピーロックスジャパン、日本オラクルにてDBセキュリティ、ID管理セキュリティソリューションをプリセールスエンジニアおよびセールスマンとして担当。
さらにはDBセキュリティコンソーシアムの研究員も務めるなどして、ここ最近の約10年間はセキュリティソリューションにどっぷり漬かってきている。
現在はフォーティネットジャパンにてコンサルタントとして奮闘中。つい最近ゴルフを始めたばかりで、下手くそな自分と一緒にラウンドしていただける忍耐力の強い方を募集中。
3/3 |
Index | |
不正行為を未然に防ぐログの分析と活用 | |
Page 1 データベースセキュリティの実効性を高めるログ管理 データベース監査機能における大きな課題 |
|
Page 2 ログ収集の方式 Audit型 メモリ参照型 パケットキャプチャ型 |
|
Page 3 ログの分析と活用でセキュリティを維持する 情報漏えい事件から学ぶべきこと |
ここがポイント! DBセキュリティの実装 |
- Oracleライセンス「SE2」検証 CPUスレッド数制限はどんな仕組みで制御されるのか (2017/7/26)
データベース管理システムの運用でトラブルが発生したらどうするか。DBサポートスペシャリストが現場目線の解決Tipsをお届けします。今回は、Oracle SE2の「CPUスレッド数制限」がどんな仕組みで行われるのかを検証します - ドメイン参加後、SQL Serverが起動しなくなった (2017/7/24)
本連載では、「SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は、「ドメイン参加後にSQL Serverが起動しなくなった場合の対処方法」を解説します - さらに高度なSQL実行計画の取得」のために理解しておくべきこと (2017/7/21)
日本オラクルのデータベーススペシャリストが「DBAがすぐ実践できる即効テクニック」を紹介する本連載。今回は「より高度なSQL実行計画を取得するために、理解しておいてほしいこと」を解説します - データベースセキュリティが「各種ガイドライン」に記載され始めている事実 (2017/7/20)
本連載では、「データベースセキュリティに必要な対策」を学び、DBMSでの「具体的な実装方法」や「Tips」などを紹介していきます。今回は、「各種ガイドラインが示すコンプライアンス要件に、データベースのセキュリティはどのように記載されているのか」を解説します
|
|