#02 個人情報流出事故を防ぐために、企業がすべき対策

セキュリティ対談第1回では、2014年に起きた個人情報流出事件を例に、情報流出事件が決して他人事ではなく、どの企業でも発生しうる可能性があるという事実が見えてきた。
また事件が起きてしまった場合の金銭的リスク・社会的リスクの大きさも
軽視できないことがわかった。

第2回では、データベース・セキュリティに関する企業の対応状況と、
効果的なセキュリティ対策について、IBMの與安さんに伺ってみよう。

2015-03-17

“アクセスログ”は取得するだけでよい?

S&I 榎本:機密情報や個人情報流出を防ぐための手段として、データベースへのアクセスログの収集と不正な持ち出しをすぐに検知できることが重要だ、ということでしたが、『DBA 1,000人に聞きました』アンケートによると、データベースの操作履歴・アクセス履歴を“ログとして取得している/一部取得している”と回答した人は、64%という結果でした。

IBM 與安さん:現場では「ログを収集していない」という話を耳にする機会が多いので、この結果は意外ですね。

S&I 榎本:確かに私ももっと少ないと捉えていました。ログが取得できていなければ、万が一、情報流出に気がついたときに、いつ何が起きたのかを追跡することができませんから、対応はどんどん後手に回ります。対応の遅れはメディアを通して露呈していくので、より一層のブランドイメージの低下につながるのではないでしょうか。

IBM 與安さん:ログの取得だけでは、情報流出が発生した際の初動が遅れる可能性があります。お客様に「取得した操作履歴をどうしているか?」と尋ねると、「単に取得しているだけ」と回答される方が多くいらっしゃいます。ログを取得している割合が64%だとしても、活用できる企業がどれぐらいあるか?という観点では微妙なところですね。

S&I 榎本:その点については『情報漏えいなどが発生した場合、ログを確認することで「いつ、だれが、どの情報に対して、どういう操作をしたのか」が迅速に追跡できる仕組みが実装されていますか?』という質問が該当するかと思いますが、この問いに対しては、「はい」と答えている方が約40%です。

お客様の中には、データベースのアクセスログを日次でオペレータがログイン/ログアウトをチェックしているケースもありますね。

IBM 與安さん:事前に実行するコマンドを提出させ、それを操作履歴として残している企業もありますね。これも個人情報流出事故を防ぐための効果的な手段の1つだと思います。

しかし、操作ログの取得と言っても、実行したコマンドのキーロガーの場合もありますし、データベースで実際に起こったSQLの場合もありますし、OSへのログイン・ログアウトだけを操作ログとする場合もあるので、どのレベルでログを取っているかは企業によって異なるようです。万が一、情報流出が起きたときにどう対応できるかは、どのレベルでログを取得しているかによって変わってくるでしょう。

「すぐに検知できる仕組み」』の重要性

S&I 榎本:一方で、データベースに関する警告をリアルタイムに発する仕組みは導入しているか?という質問に対しては、「はい」と回答した人はわずか20%程度ですね。

2014年に発生した内部犯行者による個人情報流出事件において、被害が拡大した原因の1つとして、情報の持ち出しが迅速に検知できなかった、ということが挙げられます。つまり約80%は、万が一の情報流出が起きた場合にすぐに気がつかず、初動が遅れる可能性がある、ということですね。データベース・セキュリティという観点でみると、お客様の現場ではまだまだ道半ばなのかもしれませんね。

IBM 與安さん:データベースレイヤーでのセキュリティ対策という観点では、どんなアクセスがあったのかを監視することが内部犯行による情報流出を防ぐ最初の第1歩です。この点に関しては、先ほどのアンケートからもわかるように、比較的多くの企業がすでに対応しているように見えますが、現実的にはもう少し踏み込む必要があるでしょう。どのレベルでログを取得するかも重要になるのですが、例えば、データベースに対する操作と言っても、ユーザーが打ち込んだキーをキーロガーで監視しても、シェルスクリプトを実行された場合は、シェルスクリプトの中身までは追えないので何も検知できません。データベースにどんなSQLが実際に打ち込まれたのか、をきっちり監視する必要があります。

S&I 榎本:確かにシェルスクリプトの実行コマンドだけがログとして残っていても、何も検知できませんね。その他にデータベース・セキュリティにおいて、重要視するべきポイントは何がありますか?

IBM 與安さん:不正なアクセスがあった場合に、すぐにアラートが挙がる仕組みが重要です。これに関しては、約20%の方しか対策できていないというアンケート結果がありましたが、万が一、不正なアクセスが行われた際にどれだけ対応が早くできるかに関わってくるので、重要なポイントと言えますね。

S&I 榎本:SQL単位のログを監視した上で、何をもってそのSQLを『不正』と判断するのかが難しいですね。

IBM 與安さん:確かに難しいです。例えば、データベースの管理者やシステム管理者から日中帯に個人情報管理DBにアクセスがあった、としましょう。システム管理者の日常業務として顧客情報DBにアクセスすることがないのであれば、これは『不正アクセス』と疑ってアラートを挙げる必要があります。このように、SQL単位では問題なくても、通常ではありえない時間帯に業務に必要のない人のアクセスは、「セキュリティの警報」つまり、「アラート」を挙げる判断基準になります。

個人情報流出事件を防ぐための“3つの要素”

S&I 榎本:データベースレイヤーでのセキュリティ対策として重要なポイントは、まずデータベースで実行されたSQLを監視すること、次に通常では起こりえないアクセスがあった場合に、リアルタイムでアラートを挙げられることの2点。さらに、レポーティング機能を用意しておくことも重要ですよね。

IBM 與安さん:そのとおりです。DBAが業務上必要な操作として行ったアクセスを、後からチェックをかけられる環境を用意しておくことも大事です。週次、もしくは月次単位にデータベースで実行されたSQLを確認できるレポートが必要です。金融機関では、監査法人に対して、データベースへのアクセスログをレポートで提出している企業もあります。

S&I 榎本:まとめさせていただきますと、データベースにおけるセキュリティ対策は、

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

の3つが重要なポイントですね。

しかし、この3点を網羅できるセキュリティ製品を導入すれば、内部からの情報流出事故は防げるというわけではありませんよね。

IBM 與安さん:はい。システムを導入することは、セキュリティ対策を始める「キッカケ」でしかありません。アラートが起きた際に、誰がどのようなアクションを実施するのか、どんな責任範囲でどう対応するのかを決めることも大事です。例えば、アラートを受けた人が、そのユーザーにすぐにコンタクトするなどといったことも検討しておくべきです。

S&I 榎本:つまり、どう運用するか、が大事ということですね。

IBM 與安さん:ええ。お客様にもそういった意識を持って運用する環境を用意していただく必要があります。新たに運用チームを作る必要があるかもしれませんし、既存のチームにアラート発生時の対応としてタスクを増やすだけでもよいかもしれません。企業ごとに最適な方法を決めて運用することが個人情報流出事故を防ぐことになりますし、そうすることで万が一事故が起きてしまった場合にも、ダメージを最小限に抑えられるのだと思います。

今回は、データベースセキュリティ対策として、どのような点をポイントに考えればいいのか與安さんにうかがった。次回は、IBMのデータベースセキュリティ製品「Guardium」を例に、個人情報流出事件を防ぐためにはどんなセキュリティ製品を選べばよいのか、そのポイントを具体的に考えよう。

與安 隆志
Takashi Yoyasu

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

榎本 純一
Junichi Enomoto

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

S&Iに問い合わせる