本当は怖い、情報の分散保持

　さて、この事件をもう少し分解してみよう。問題の本質は、内部ログに本来入れてはいけない情報が残っていたことにある。これはTwitterに限らず、多くの企業で運用中のシステムにも潜んでいるリスクかもしれない。

　システム開発において、デバッグ目的でさまざまな情報をログに出力する。だが、実運用が始まればこのような機能は不要になることが多いし、そもそも本来出力すべきではないかもしれない。ここに落とし穴が潜んでいる。

　まずは、ログの出力が適切に運用されているかどうか、その中に不要な情報が含まれていないかどうかを確認したい。特にパスワードやクレジットカード情報、氏名や住所などの個人情報の有無は重点的にチェックしておきたい。

　もう1つ気を付けたいのは「バックアップファイル」の存在だ。ログなどのデータ出力と同時にバックアップも自動作成するシステムも多い。問題は、バックアップの保存先だ。過去のインシデントでは、バックアップファイルが公開サーバに保存され、情報漏えいにつながったケースも散見される。

　例えば、JPCERTコーディネーションセンターが2017年8月に行った注意喚起では、データベースのダンプファイルが公開サーバに保存され、外部から閲覧可能になるリスクに触れた。ダンプファイルは、特に何も指定しなければ「dump.sql」という名称でドキュメントルートに保存されることが多い。

　つまり、「http://example.com/dump.sql」のような類推可能なURLからデータベース内に保存された全情報を入手されるリスクがある。多くのダンプファイルは暗号化を施していないと思われるので、万が一漏えいすると被害は甚大なものとなる。

　強固にデータを保護する仕組みを作っても、同じデータが別の場所に保存されていては全く意味がない。しかも、意図しない分散保持は把握しづらく、発見すること自体が難しい。例えば、システム移行時に「仮置き」したバックアップファイルは削除漏れが発生しやすい。時間が経過するにつれ、「なぜここにバックアップがあるのか不明だが、削除していいかどうかも分からない」といった理由で放置され続ける可能性もある。適切な処理が求められる。

インシデント発生時、何をどう伝えるべきか

　インシデントが発生した後に、ユーザーに対して何をどう伝えるかという点にも考慮が必要だ。そこで本稿でも何回か紹介した「サイバーセキュリティ経営ガイドライン」を挙げたい。

　「インシデント発生時に組織内で整理しておくべき事項」というExcelシートが付いている。インシデント発生時に内部でどのような情報を集めるべきかというチェックリストだ。これを活用するためには平常時から目を通しておきたい。

　今回、Twitterが発表した不具合は、「3.3億人」という数字、「平文パスワードが不正に保存されていた」という事象に目をうばわれがちだ。しかし、その内容をしっかりと読み解いていけば、Twitterのセキュリティポリシーや運用ノウハウが垣間見える。

　サイバー攻撃が激化する中、多くの企業では脅威から身を守るための技術や製品の導入を進めている。しかし、運用や管理における「バッドプラクティス」がインシデントを引き起こす可能性も多い。Twitterの「パスワード平文保存事件」を他山の石として、自社の秘密保持体制の見直しにつなげたい。