門林 雄基氏によるコラム、【サイバーセキュリティが損なわれる原因を理解する(5)】を公開

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


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

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

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

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

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


・・・ここから先は、アクセリア株式会社で公開中のコラム本編でご覧ください。
リンク


【門林 雄基氏のコラム】
・第1回：サイバーセキュリティに求められるバランス感覚リンク
・第2回：サイバーセキュリティが損なわれる原因を理解する(1)リンク
・第3回：サイバーセキュリティが損なわれる原因を理解する(2)リンク
・第4回：サイバーセキュリティが損なわれる原因を理解する(3)リンク
・第5回：サイバーセキュリティが損なわれる原因を理解する(4)リンク