サイバーセキュリティが損なわれる原因を理解する(5)ー「設定の脆弱性」について別の角度から解説する

　前回のコラムでは、たんなる「設定の不具合」と片付けることのできない、「設定の脆弱性」がなぜ生じるのかをみてきました。ソフトウェアの開発者と、それを客先などで設定するエンジニアの連携ミス、と片付けてしまうことも多いのでしょうが、じつは「ソフトウェア開発者の創造性」の裏側にひそむ、どす黒い問題だったのですね。（前回のコラムはこちら）
　今回も、設定の脆弱性について別の角度から解説を試みるとしましょう。
　ビジネスに大打撃を与えるような設定の脆弱性は、どうすれば防止できるでしょうか。たんに、システムの導入時に気をつけて、設定の脆弱性がないようにしっかり検査すれば良いのでしょうか？

　システムの導入時に、お金をかけていろいろな検査をするのはよくある話だと思います。その段階で、設定の脆弱性なるものに気をつけて検査をしていれば、それなりに問題が見つかって、問題を解消できていると思います。
　あなたは新サービスを担当しているとします。ようやくサービスインして、うまく動いているシステムで、ある時、今つかっているソフトウェアにセキュリティ上の問題が見つかり、バージョンアップすることになりました。このとき、あなたはエンジニアに急いでバージョンアップするよう指示します。
バージョンアップしたところ、カスタマーサポート部門から「登録ユーザ以外から見えないはずのファイルが、インターネット全体から見えてしまっている」と連絡を受けます。一体、何が起きているのでしょうか。

　セキュリティの問題を改善するためにバージョンアップしたはずが、何故、情報漏洩につながったのでしょうか。

　このケースでは、いくつか原因が考えられます。まず「設定ファイルが元に戻ってしまった」ケース。サービスインの時には細心の注意をはらって設定して、「登録ユーザ以外からは見えないように」設定したとします。しかし急いでバージョンアップしたとき、エンジニアは「まずは動かすこと」を優先してソフトウェア付属の設定ファイルを使ってしまいました。ソフトウェア付属の設定ファイルには、登録ユーザ専用のアクセス制限など何も書かれていなかったので、世界中から読める状態となり情報漏洩につながってしまいました。
　つぎに「設定ファイルの書き方が変わった」ケース。新しいバージョンでは、ソフトウェアの開発者が「新しい考え方」を導入して、設定ファイルの書き方が「はるかによくなった」のです。あろうことか、古い設定を「無視して」新しい設定がなければ情報公開するようになっていたため、世界中から読める状態となり情報漏洩につながってしまいました。
　そして「設定ファイルの置き場所が変わった」ケース。古いバージョンでも、テスト時に設定ファイルを別のディレクトリにコピーして試行錯誤していたのですが、バージョンアップのときに、そちらを見にいくようにソフトウェアの挙動が変わっていたため、テスト用の設定ファイルが有効になってしまい、世界中から読める状態となり情報漏洩につながってしまいました。

　ありえない。。と、みなさんの呻く声が聞こえてきそうですが、経験豊富なエンジニアなら、爆笑しながら似たような経験談を語ってくれることでしょう。

　では、急いでバージョンアップするのはやめにして、注意深くリリースノートを読んで、しっかりテストしてからバージョンアップすればこの手の脆弱性はなくせるのでしょうか。

　問題はバージョンアップだけではありません。最近、CDNを別の事業者に切り替えたら情報漏洩につながった、という報道がありました。これも設定の脆弱性だと言えるでしょう。
　Webサーバから個人情報をふくむページを配信するときに、CDNが誤ってキャッシュしてしまうと他人の個人情報が表示される可能性があります。CDNでキャッシュしないように設定する方法はCDN事業者によってさまざまなので、それを間違えると情報漏洩につながるんですね。ソフトのバージョンアップ時に「設定ファイルの書き方が変わった」ケースに相当すると言えるでしょう。
　ある意味、CDNの切り替えというのはシステムの結合テストのやり直しに相当する労力を要するわけで、大変なコストが発生するものだということは直感的にもわかると思います。結合テストをおざなりにして、コストメリットだけで CDN事業者を切り替えたら、つまるところ検査工程の工数が積まれていないわけですから、かなり高い確率で上記のような問題が起きると思います。
　この問題はCDNに限ったものではありません。多くの場合、システムの中核となるソフトウェアと、それを取り巻くWAFやロードバランサなどのアプライアンスは、かなり高度な通信プロトコルを駆使して連携プレーをしています。A社、B社と同じような機能をもっており、あたかもレゴブロックを取り替えるがごとく置き換えることができるという幻想にとらわれがちですが、実際に置き換えるには高度な製品・サービスの知識に加えて、ソフトウェアやプロトコルの知識も必要となります。

　今回はこれくらいにしておきましょう。次回のコラムでも、設定の脆弱性について紹介したいと思います。


■関連ページ
【アクセリアのセキュリティ関連サービス】
　・WAFサービス（Scutum）
　・サイバーリスクに備える保険