これは実話を元にしたフィクションです
つい先日、特定のテーブルのレコードが全削除されるような事件を耳にしました.
そこで再確認できたことは、アクセス権を渡すなら権限を絞ることの重要さでした.
実際にあった話を書くわけにもいかないので、その話をベースに若干変更したフィクションです.
何が起きたのか
あるシステムのDBに、関連会社のAさんが作業上、ツールなどを介して直接アクセスする必要がありました. その作業では、データの確認や修正があったことは言うまでもありません.
ある日、Aさんはツールで操作を誤ってしまい、あるテーブルの全レコードを削除してしまったのでした.
要は、DELETE FROM table_name;が発行されたということです.
何故、起きたのか
当事者では、ないので想像で語るしか出来ません.
その想像を語る価値もないので、皆さんのご想像にお任せします.
どれだけの問題なの？
データや復旧の可不可によって、レベルが変わります.
NetflixやHulu、dTVなどといったVODサービスを想像してみてください.
VODサービスには、動画のようにサービス提供に必要なコンテンツや、ユーザーの決済情報や連絡先などを保持する会員情報、各ユーザーの視聴履歴などの履歴データなどが保存されると考えられます.
例えば、コンテンツが削除されてしまった場合はどうでしょうか？
コンテンツは、VODサービスにとってはサービスそのものです.
これが削除されるということは、サービスが停止し、解約の危険や競合のサービスへの顧客流出などが考えられます.
皆さんは色んなサービスを利用していると思うので、これが1,2時間程度でなら許せる方もいるでしょう.
もし、バックアップなどがなく、復旧できない状態だったらどうなるでしょうか？
これは言うまでもなく分かりますよね.
会員情報についても同様です.
軸は違いますが、これも相当というか、会員系サービスの場合は致命的過ぎます.
「決済系の情報が操作ミスで消えました」と言われたら、あなたはそのサービスを利用し続けようと思いますか？
最後に履歴データですが、視聴履歴などといった情報も重要なことには重要ですが、その情報をサービスの根幹にしてない限りは、サービスは継続可能でしょう.
もちろん、顧客流出はあります.
が、上2つの例とは比較にならないです.
例としてVODサービスを挙げてみましたが、どうでしょうか？
レベルは変わりますが、どれも操作ミスで消えていいとはなりませんよね.
どうすればいいのか
こういった出来事を全て防ぐことは、もちろん出来ません.
それでも出来る対策はあったはずです.
例えば、
- トランザクションを貼り、正しい結果にならなければロールバック出来るようにしておく
- アクセスさせる場合は、必要なテーブルに必要な操作のみだけ与える
- 実行前に、自分以外の第3者に発行されるSQL（見れるツールがある）を確認してもらう
- 操作する時は、第3者と都度確認しながら操作する
などが最低限考えられると思います.
システムを作っている人間として、この他にもいくつかの選択肢を提示出来ると思います.
それでも起きてしまう時は、起きてしまいます.
だからといって、対策を全く講じないのは愚の骨頂です.
どのデータが「そのサービスにとってどれだけ重要なのか」は、アーキテクチャ設計者やサービス担当者などといった方々は、サービスを開始前からは判断出来ます.
であれば、それらに対してどう対策を講じるのかも、考えておく必要はあります.
最後に
今回は、実話を元にしたフィクションでの話をしました.
どうだったでしょうか？
この話を聞くまでは、参考書に載ってる都市伝説か何かだと思っていました.
が、実際は都市伝説ではなく、意外と身近で起きる事件なんだなと.
年末にこんな話を聞くなんて縁起でもない...
