データへアクセスさせるなら必ず対策をしよう


つい先日、特定のテーブルのレコードが全削除されるような事件を、初めて目の当たりにしました。(私が関わってるわけでない)
そこで再確認できたことは、アクセス権を渡すなら権限を絞ることの重要さでした。

実際にあった話を書くわけにもいかないので、その話をベースに若干変更したフィクションです。

何が起きたのか

あるシステムのDBに、関連会社のAさんが作業上、ツールなどを介して直接アクセスする必要がありました。
その作業では、データの確認や修正があったことは言うまでもありません。

ある日、Aさんはツールで操作を誤ってしまい、あるテーブルの全レコードを削除してしまったのでした。
要は、DELETE FROM table_name;が発行されたということです。

何故、起きたのか

当事者では、ないので想像で語るしか出来ません。
その想像を語る価値もないので、皆さんのご想像にお任せします。

どれだけの問題なの?

データや復旧の可不可によって、レベルが変わります。
NetflixやHulu、dTVなどといったVODサービスを想像してみてください。
VODサービスには、動画のようにサービス提供に必要なコンテンツや、ユーザーの決済情報や連絡先などを保持する会員情報、各ユーザーの視聴履歴などの履歴データなどが保存されると考えられます。

例えば、コンテンツが削除されてしまった場合はどうでしょうか?
コンテンツは、VODサービスにとってはサービスそのものです。
これが削除されるということは、サービスが停止し、解約の危険や競合のサービスへの顧客流出などが考えられます。
皆さんは色んなサービスを利用していると思うので、これが1,2時間程度でなら許せる方もいるでしょう。
もし、バックアップなどがなく、復旧できない状態だったらどうなるでしょうか?
これは言うまでもなく分かりますよね。

会員情報についても同様です。
軸は違いますが、これも相当というか、会員系サービスの場合は致命的過ぎます。
「決済系の情報が操作ミスで消えました」と言われたら、あなたはそのサービスを利用し続けようと思いますか?

最後に履歴データですが、視聴履歴などといった情報も重要なことには重要ですが、その情報をサービスの根幹にしてない限りは、サービスは継続可能でしょう。
もちろん、顧客流出はあります。
が、上2つの例とは比較にならないです。

例としてVODサービスを挙げてみましたが、どうでしょうか?
レベルは変わりますが、どれも操作ミスで消えていいとはなりませんよね。

どうすればいいのか

こういった出来事を全て防ぐことは、もちろん出来ません。
それでも出来る対策はあったはずです。
例えば、

  • トランザクションを貼り、正しい結果にならなければロールバック出来るようにしておく
  • アクセスさせる場合は、必要なテーブルに必要な操作のみだけ与える
  • 実行前に、自分以外の第3者に発行されるSQL(見れるツールがある)を確認してもらう
  • 操作する時は、第3者と都度確認しながら操作する

などが最低限考えられると思います。
システムを作っている人間として、この他にもいくつかの選択肢を提示出来ると思います。
それでも起きてしまう時は、起きてしまいます。
だからといって、対策を全く講じないのは愚の骨頂です。

どのデータが「そのサービスにとってどれだけ重要なのか」は、アーキテクチャ設計者やサービス担当者などといった方々は、サービスを開始前からは判断出来ます(よね)。
であれば、それらに対してどう対策を講じるのかも、考えておく必要はあります。

最後に

今回は、実話を元にしたフィクションでの話をしました。
どうだったでしょうか?
この話を聞くまでは、参考書に載ってる都市伝説か何かだと思っていました。
が、実際は都市伝説ではなく、意外と身近で起きる事件なんだなと。

年末にこんな話を聞くなんて縁起でもない...

コメント

このブログの人気の投稿

新生活始まります

ElasticIPを複数利用する時の注意

タスクの実行結果をwhenで指定するならcheck_modeつける