#04 データベースセキュリティ製品 “Guardium”を提案!

これまで3回にわたり、情報流出事故はなぜ起きるのか、事故を防ぐためにはどう対策すればよいのかについて日本IBMの與安さんと一緒に紐解いてきた。今回は、S&Iの榎本が、個人情報や機密情報を抱える企業に対して、データベース・セキュリティの提案をしてみよう。

2015-04-28

内部犯行による情報流出事故の原因と有効な解決策まとめ

内部犯行による情報流出事件の問題点は、「データベースから個人情報が大量流出」「流出発覚までに長時間経過」の2点が挙げられます。

これらの原因は、ログを取得していたものの、不正なアクセスをリアルタイムで検知できる仕組みがない、身内の関係者は不正をしないという思い込みから、内部犯行者へのセキュリティレベルが低いことにあります。

“データ保管庫”であるデータベースレベルでのセキュリティ強化が、非常に有効な解決策となります。イレギュラーなアクションがあった際に、リアルタイムで通知される仕組みがあれば、外部への情報流出を未然に防止できるはずです。

今回は、個人情報流出への対策として、IBMが提供するデータベース・セキュリティ製品『Guardium』を提案させていただきます。

個人情報や機密情報が保管されたデータベースを持つ企業の方に
Guardiumを提案します

今回は、データベース・セキュリティ製品の導入を検討しているこちらの4社の方にお集りいただきました。皆さん、いろいろな事情で社名を伏せていますが、セキュリティのお話をさせていただくときには、よくあることです(笑)

A社 製造業。ECサイトで自社製品を販売。100万件程度のお客様情報をデータベースに保管。
B社 流通業。自社で販売している商品などに対するお問い合わせ窓口としてコールセンターを設置。お客様情報は、だいたい30万件くらい。
C社 金融業。保険に加入していただいたお客様の情報 約5,000万件ほどを保管。
D社 人材派遣サービス。人材紹介を希望された方など約50万件の個人情報を管理。

業種や個人情報の件数は各社さまざまですね。もう既にセキュリティ対策をしっかりと進めていらっしゃるかとは思いますが、今回はデータベース・セキュリティに絞ってお話させていただきます。

皆さんは、データベース・セキュリティ製品を導入するにあたって、懸念していることや心配なことってありますか?

A社
データベースサーバーのパフォーマンスが下がってしまわないかが心配です。我々はECサイトがビジネスの肝なので、少しでもレスポンスが落ちると取り引きに影響がでますので。あとは、常に稼働しているシステムなので、データベースの設定変更はできる限り加えたくないですね。

B社
不正アクセスは、とにかくすぐに検知したいのですが、想定外のアクションはすべて不正アクセスとして検知することはできるものでしょうか?

原則、業務時間中に個人情報にアクセスするのはコールセンターで働く社員だけなので、コールセンター以外の人がアクセスした場合は、それが社員のアクセスであっても「不正アクセス」として検知できるようにしたいですね。

D社
アクセスログが、改ざんされてしまったら元も子もないですよね。ログを取るだけではなくて、そのログの正確性までを担保できるとよいのですが。

皆さん、業種に応じてさまざまな不安があるようですね。それでは、今回提案するIBM Guardium製品の概要を簡潔にご紹介します。

きっと皆さんの不安を払拭できると思います!

まず以下のフロー図をご覧ください。

第3回の対談の中でもご紹介しましたが、Guardiumは「エージェント型」の製品です。データベースサーバーにインストールする「エージェント」と、ログの解析を行う「コレクターサーバー」の2つのコンポーネントから成り立っています。

データベースサーバーが取得したログをコレクターサーバーで解析します。さまざまな条件やパターン・方式を指定することで、不正アクセス発生時のアラートをリアルタイムで通知します。オプションになりますが、アラート発生と同時にアクセスを遮断することも可能です。

"不正アクセス"があった際、即時対応が可能になるので、情報流出を最小限に抑えることができます。

B社さんの要望にもあった、業務時間帯のコールセンター以外で働くIDからのアクセスは、すべて"不正アクセス"としてアラートを挙げるように設定することもできます。

その他にも業務委託先に付与したユーザーから個人情報DBへアクセスがあった場合や、通常では使用しないアプリケーションからのアクセスなども"不正アクセス"として検知し、アラートをあげることができます。

Guardiumを使用する場合は、データベースサーバーのAUDIT機能をONにすることなく、トランザクションの監視を行うため、データベースへの負荷は非常に低いです。通常時なら数%程度という実測値があります。もちろん、データベースサーバー側の設定変更やネットワークの設定変更も必要ありません。

コレクターサーバーは、OSおよびデータベースレベルでの特権をユーザーが使用できない構造になっているので、ログが改ざんされることはありません。バックアップファイルも処理する際に暗号化しているため、こちらも改ざんはできません。

データベース・セキュリティ製品を検討するケースの大半は、既に稼働しているシステムへの追加導入です。同時に、いま問題なく稼働しているシステムの設定を変えたくない、という企業はとても多いです。Guardiumであれば、A社さんのように負荷を気にする必要がないだけでなく、既存システムへの影響や変更もありませんので、非常に導入しやすい製品とも言えます。

C社
弊社には、データベースサーバーが複数あります。DB2やMySQLなどさまざまなメーカーのデータベースがあるのですが、システム管理部もメンバーが限られていますし、できればまとめて管理したいのですが、Guardiumの対応データベースはどんな感じでしょうか?

A社
弊社も今はデータベースは1台だけですが、早々に新たなビジネスが始まろうとしているので、新たなデータベースを用意する可能性があります。まだ、どこのメーカーのデータベースにするか決まっていないので、できれば汎用的に利用できるものがいいのですが…

Guardiumは、IBM社の製品ですが、DB2以外にも多数のDBMSやOSをサポートしています。複数のDBMS・OSが混在するシステムでの横展開もできますから、C社さんの要望にも十分に応えられますよ。

さらに、A社さんのように今後管理するデータベースが増えていく場合にも向いています。お客様のビジネス成長に合わせた拡張が可能です。

B社
監査で、レポートの提出を求められるケースがあります。どういったレポートを提出すればよいのかわからなかったり、ちょっとテンプレートを変えようとしたら、かなりの手間がかかってしまい困っています。

Guardiumはレポーティング機能も充実しています。

80種類以上の監査対応レポートのテンプレートが標準で提供されます。これだけ種類があると、監査の際に、レポートを提出しなさい、と言われた場合もさほど労せずに提出できるんじゃないでしょうか。テンプレートにないフォーマットのレポートが必要な場合でも、管理画面から作成するのも割と簡単ですからご安心ください。


モデルケースはOracle DBサーバー2台/
Microsoft SQLサーバー2台を監視

Guardiumを導入することで、"不正アクセス"をリアルタイムで検知しアラートをあげるようになるため、情報流出を未然に防止することができます。パフォーマンス低下やログの改ざんなどは心配する必要がありません。

今回は、モデルケースとして、Oracle DBサーバー2台(Active-Standby構成) / Microsoft SQLサーバー2台(Active-Active構成)の監視を行う場合の構成をご紹介します。

詳細
Guardium 監視対象データベースサーバー 3台 (※1)

  • Oracleサーバー(Active-Standby)監視対象:1台
  • Microsoft SQLサーバー(Active×2)監視対象:2台
Guardium コレクター 2台

  • Active機:1台
  • Standby機:1台

(※1) 監視対象データベースサーバーはActive機3台、Standby機1台の4台構成で、常時監視する対象サーバーはActiveの3台のみを対象。OracleサーバーのCPUスペックはX5260 4Core、Microsoft SQLサーバーはX3480 4Coreを想定。

まず、Guardiumのライセンス(PVU数:プロセッサー・バリュー・ユニット)は、各サーバーのスペックより決まります。Oracleサーバーは200PVU、Microsoft SQLサーバーは560PVUで、トータル760PVUとなります。

Guardiumのコレクターサーバーのサイジングは、内部犯行が起因となる情報流出を鑑みてデータベースサーバーに対する特権ユーザーのローカルアクセス、リモートアクセスのみを対象とします。

その他にも、

  • アプリケーションとデータベース間は、コネクションプール環境であることを想定
  • アプリケーションとデータベース間の通信は、いずれも暗号化されていないことを想定
  • SQLの値は個人情報が含まれるため、ログ取得対象外とすることを想定
  • 監査ログ取得は、特定対象テーブル(10数個程)を対象に制限することを想定
  • アプリケーションサーバからの定型SQL処理は、ログ取得対象外とすることを想定
  • 定型バッチ処理は、ログ取得対象外とすることを想定
  • リザルトセットの監視はしないことを想定
  • コレクターActive障害時のFailOver先、バックアップデータのリストア先、パッチ、バージョンアップ検証先としてStandby機を配置する。

といった前提条件のもと、コレクターサーバーの台数は、Active機1台、Standby機1台の2台構成になります。

【サンプル構成のご提供価格】

項目 価格(税別)
ソフトウェア一式 約620万円
構築サービス一式 300万円〜

※ ソフトウェアの価格は、2015年1月時点の価格となります。
※ 運用・保守サービスは、別途ご相談となります。

データベースの種類は企業によってさまざまですが、今回は、異なるメーカーのデータベースを2つ運用しているケースでご提案してみました。構成は、個人情報の件数だけではなく、どのトランザクションを監視するかや、データベースがいくつあるかによって変わります。もちろん、条件によっては、今回のモデルケースに当てはまらない場合もあります。

よりリアルな環境に照らし合わせてGuardiumの導入をご検討されている方は、遠慮なく私、榎本までご相談ください!

與安 隆志
Takashi Yoyasu

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

榎本 純一
Junichi Enomoto

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

S&Iに問い合わせる