#03 データベース・セキュリティ製品は何を基準に選べばよいのか?

2回にわたり、データベース・セキュリティの重要性とセキュリティ対策を行う際に重視すべきポイントをIBM與安氏にお話いただいた。

第3回はIBM社が提供しているInfoSphere Guardium(以下、Guardium)製品を例に、
より実践的かつ具体的に導入を検討してみよう。

2015-03-24

データベース・セキュリティ製品を分類してみよう

S&I 榎本:さて、第3回はいよいよ『実践編』とまいりましょう。まず、データベース・セキュリティ製品は、大きく3つのタイプに分類できます。

  1. エージェント型
  2. ネットワークキャプチャ型
  3. 監査ログを利用する製品

の3つです。

IBM 與安さん:3番目に挙げられた『監査ログを利用する製品』ですが、一般的に商用のデータベースの多くがAUDIT機能を持っているので、「ログを取得して活用する」という観点で“始めやすい”という特長があります。一方で、取得したログをデータベース・サーバーの中に溜め込むので、どうしてもデータベースに負荷がかかってしまいます。また、多種のデータベースを使っている場合、監査ログとして捉えたときにデータベース毎にフォーマットが異なるため、最終的に見やすく成形する手間や、リアルタイムアラートに対応するとことが難しいというデメリットもあります。

データベースのAUDIT機能を使わない手段としては、ネットワークキャプチャ型があります。データベース・サーバーがつながるスイッチに搭載されたミラーポートを使って、パケットをミラーリングして解析しようというものです。データベースにかかる負荷が非常に少ないという点では、非常にメリットがあります。しかし、データベースに直接ログインした場合や、SSHでログインしてコマンドを打った場合は、コマンドが暗号化されているためログが取得できないという弱点があります。またデータベースの接続自体が暗号化されている場合も、ログが取得できません。このデメリットをカバーしているのが、データベース・サーバーに導入するエージェント型です。エージェント型では、サーバーへの負荷を最小限に留め、暗号化されていてもログが取得できるという特長があります。

S&I 榎本:それぞれの特長を鑑みると『エージェント型』が、もっとも合理的に感じるのですが…

IBM 與安さん:そうですね。ただ『エージェント型』にもいくつか種類があります。エージェント型の中でもメモリーサンプリング方式を採用しているソフトウエアでは、特定のタイミングでデータをポーリングする、つまり一定間隔でログを取得します。当然、タイミングがずれるとログが取得できませんし、取得間隔を短くするとデータベースに負荷が大きくなってしまいます。間隔を短くしたとしても、短時間に大量のデータが流れると、すべてのログを取得することができません。

S&I 榎本:なかなかうまくいかないものですね。IBM社で扱っているデータベース・セキュリティ製品『Guardium』は、『エージェント型』に分類されますが、ログが取れないケースはないという理解をしていますが。

IBM 與安さん:ええ。まずGuardiumは、エージェント型に該当しますが、メモリサンプリング方式とはログの取得方法が異なります。

Guardiumは、データベース・サーバーにインストールする『エージェント』とログの解析を行う『コレクターサーバー(管理サーバー)』の2つのコンポーネントから成っている製品です。カーネルレベルでログを取得するため、取りそびれるということはありません。

サーバー負荷は高負荷時でもわずか5%な『Guardium』の特長とは?

S&I 榎本:私自身、お客様に提案していてよく耳にするのですが、「エージェントをデータベース・サーバーに導入する」と説明すると、やはり多くのお客様はデータベースの負荷を気にされますが、実際に導入した場合の負荷はどの程度になるのでしょうか。

IBM 與安さん:ええ。実際に導入したお客様のケースでは、エージェントによる負荷は常時1〜2%程度ですね。高負荷の場合でも3〜5%程度になることが多いです。

S&I 榎本:サーバーにかかる負荷という観点では、ほぼ気にしなくてよいレベルと言えますね。なぜ、これほどサーバーに負荷をかけずにログの解析を行うことができるのか、そのポイントは、Guaridumがエージェントとコレクターサーバーの2つのコンポーネントで成り立っている点にあるのでしょうか。

IBM 與安さん:はい。Guardiumでは、エージェントが取得したログを、コレクターサーバーに送信し、このSQLはどのユーザーが何時何分にどのテーブルに対して実行したものかなど、すべてコレクターサーバーで解析し、必要があればアラートを挙げるといった処理を行っているので、データベース・サーバーにかかる負荷を抑えることができるわけです。最終的にログを保管するのもコレクターサーバーです。

S&I 榎本:データベース・サーバーはログを取得するだけで、実際にログを解析しアラートを挙げるのは専用アプライアンスであるコレクターサーバーになるため、既存システムには変更がほぼないと言えますよね。

IBM 與安さん:はい、データベースそのものに変更はありません。

Guardiumを導入されるお客様は、新規にシステムを導入するタイミングでセキュリティ製品を導入されるのではなく、既存システムに対して、後からセキュリティを強化したいというケースが大半です。このため既存のデータベースに変更を加える必要がないというのは、それだけで導入のハードルが下がるはずです。

S&I 榎本:既に稼働しているシステムに対して変更を加えることを嫌うお客様は多いので、変更無く導入できるのは魅力的ですよね。

データベース・セキュリティという観点では、もう1つ大事な要素として『ログの改ざん防止』があると思っています。蓄積したログを、悪意をもって何らかの手段で意図的に改ざんされてしまうと、ログそのものの信頼性が失われてしまいますから。Guardiumのコレクターサーバーは、アプライアンスサーバーなので、一般のユーザーはもちろんroot権限でもアクセスできないから安心ですね。自由にコマンドを打つこともできませんから、取得したログを改ざんされる危険がない、という点も大事なことだと思いますが。

IBM 與安さん:ええ、ログ自身のデータの信頼性を担保できますし、「いつ、誰が、どのテーブルに対してどのようなSQLを実行したか」を正確に追跡することができます。

S&I 榎本:サーバーなどに監視ソフトウェアをインストールする形式ですと、rootやAdministrator権限を持つユーザーであれば、ログを操作が行えます。ログの信頼性という観点は、意外と見落としがちな気がします。

IBM 與安さん:rootやAdministrator権限であってもログに触ることができないという点は、Guardiumの優位性の1つです。お客様にも高く評価していただいています。

標準テンプレートはなんと80種類以上。
柔軟に対応できるGuradiumのレポーティング機能

S&I 榎本:セキュリティ製品を選ぶ際のポイントとして、

  1. 不正アクセスに対するリアルタイムアラート
  2. アクセスログの取得
  3. ログに対するレポーティング機能

という3点が挙げられましたが、ここまでのお話で、「1.不正アクセスに対するリアルタイムラート」と「2.ログの取得」はクリアしました。

「3.レポーティング機能」についてですが、Guardiumはあらかじめ多数のテンプレートが用意されていて、レポートが充実しているのも特長の1つですよね。

IBM 與安さん:監査に必要なテンプレートなど、これまでに導入したお客様からのリクエストを取り込みながら作成したテンプレートが約80種類ほどご用意してあります。このためお客様はログを取得すると同時に、すぐにレポートを作成することができます。

S&I 榎本:標準のテンプレートに、これまでのお客様のリクエストを基に作成された、さまざまな形式のテンプレートが用意されているのは、非常に助かりますね。汎用的なものばかりですと、どうしても自社のニーズには合わない…といった「不便さ」がでてきてしまいますからね。管理コンソール画面からお客様自身で自由にレポートが作成できる点も、「不便さ」を解消できるポイントの1つだと思います。

IBM 與安さん:そうですね。標準で80種類以上のテンプレートが付属している上に、Guardiumのコレクターサーバーに用意されているWeb管理コンソール画面から、お客様自身で自由にレポートを作成できるので、標準テンプレートでは網羅できない情報をレポートにまとめなければならない場合にも、柔軟に対応できます。

S&I 榎本:データベースのAUDIT機能を使った、ログをベースにスクリプトなどで整形しレポーティング機能をスクラッチで作成するとなると、監査時に新たなレポートが必要になった場合などの改修を含め、それなりにコストがかかりますよね。テンプレートの充実は、コストの抑制にもつながります。

IBM 與安さん:コスト抑制もGuardiumが選ばれる理由の1つですね。ある金融のお客様で、取得したログを自前のシステムで解析していたのですが、サーバーのバージョンアップに伴いログが取得できなくなってしまったケースがありました。その場合、新たにログ解析用のシステムを作成しなおす必要があり、作り直した場合とコストを比較した結果、Guardiumを導入されました。他にも、金融庁監査が入り、すべてのデータベースを監査対象にしなさいとなったお客様も、すべてのデータベースのレポーティング機能を作ることとGuardiumを導入した場合のコストを比較し、Guardiumを導入されたケースもあります。

ビジネス成長に合わせた拡張
でコストを最大限に抑制

S&I 榎本:IBM製品となると、DB2やInformixにしか対応していないと思われがちではないかと思いますが、決してそんなことはない。Guardiumはマルチプラットフォーム対応なので、今はOracleを使っていて、将来は他のデータベースを使う可能性がある、という場合にもそのままお使い続けていただけるのではないでしょうか。データベース・サーバーのAUDIT機能をONにしていると、データベースが変わる度にログ解析やレポーティング機能を作り直す必要がありますが、Guardiumの場合はその必要はないでしょう。将来の拡張性を考えた場合も、Guardiumであればコストを最大限抑えられます。

IBM 與安さん:DB2やInformixはもちろんですが、OracleやMicrosoft SQLサーバー、HadoopやBigInsightsのようなビッグデータ用のデータベースや、MongoDBなどに代表されるNoSQLと呼ばれるデータベースにも幅広く対応しています。新たにビジネスを始める場合や、新たなデータベース・サーバーを構築する場合にも、簡単に横展開できるので、お客様のビジネス成長に合わせて拡張していくことができます。

IBMのお客様には、金融や公共など、大規模なデータベースを管理している企業や団体などが多いのですが、大量のデータを管理するためのコストを気にされる方も多くいらっしゃいます。Guardiumの場合、それぞれのコレクターサーバーを一括で管理する「統合管理サーバー」を用意することができます。アラートの設定なども1台ずつ個別に設定する必要もないので、運用負担も抑えられますし、コストも抑えられます。

S&I 榎本:どの企業でもDBAの人数は限られているでしょうから、管理者の負担が軽減されるのはとても重要なことですよね。

IBM 與安さん:やはり、セキュリティという分野はどうしても収益を生む分野ではないので、人員も含めて積極的に投資されないという傾向があるのは事実だと思います。不幸にもインシデントが起きてしまった場合のリスクや、内製化で解決しようとした場合のコスト・運用負担など、コストを総合的に判断してデータベース・セキュリティ製品の導入を検討していただきたいですね。

S&I 榎本:ありがとうございました。

今回は、IBM社のデータベース・セキュリティ製品『Guardium』を例に、製品を選ぶ際のポイントを伺った。既に稼働しているシステムにセキュリティ製品を導入するケースが大半だからこそ、システム変更が必要ないものや、サーバー負荷が少ない点は重要なポイントになるだろう。また、「監査」などの観点から、レポーティング機能も重要だと言える。

次回は、S&Iがある業種の企業に対して行ったデータベース・セキュリティ製品の提案をご紹介したい。

與安 隆志
Takashi Yoyasu

日本アイ・ビー・エム株式会社。データベースアドミニストレーターからサーバー全般のインフラ管理者として従事した経験を持つ。現在は、データベース管理とISMS等の監査対応の経験を活かし、Guardium製品のテクニカルセールスを担当。

榎本 純一
Junichi Enomoto

エス・アンド・アイ株式会社。金融系でのアプリケーション開発およびPowerSystemの仮想化基盤設計、構築の経験を経て、現在は、IBM ソフトウェア製品を中心にしたテクニカルセールスに従事している。

S&Iに問い合わせる