サイバーセキュリティが損なわれる原因を理解する(4)ー設定の脆弱性とは？ソフトウェア脆弱性と混同されがちな脆弱性

　安心、安全が損なわれる、つまりサイバーセキュリティが損なわれる原因とはどういったものでしょうか。今回のコラムでも、前回に引き続き、サイバーセキュリティが損なわれる原因について、あらためて解説してみたいと思います。

　前回までのコラムでは、ソフトウェア脆弱性について解説しました。専門家しか分からない技術的なゴチャゴチャも重要ですが、「ソフトウェアの仕様そのものが脆弱」であるとか、「組み合わせ方が脆弱」であるとか、「検査漏れがあり脆弱」といった、専門家でなくても知っておきたいソフトウェア脆弱性について思いつくままに並べてみました。またこれらは、サプライサイドが触れて欲しくない、彼らにとっては不都合な脆弱性であるということも知っておくべきでしょう。

　今回からは、往々にしてソフトウェア脆弱性と混同されがちな、設定の脆弱性について解説を試みるとしましょう。
　そもそも設定の脆弱性とは何でしょうか。ソフトウェアを安全に作ればそれで良いのではないでしょうか？

　ソフトウェアというものは、製作コストはかさみますが、いったん作ってしまえばコピーは容易なので、できるだけ多くのお客様に量販して、また機能拡張してお客様の要件にあわせていく、という方法が採られます。このため、頭のいいビジネスとしては、できるだけ汎用的なソフトウェアを作って、できるだけ多くのお客様に売っていきましょう、ということになります。
　しかしお客様の要件というのは各社ごとに細かく違うものです。例えば情報を配信するWebサーバひとつとっても、「うちは情報公開が前提だから、隠すものはない」というお客様Aと、「うちは指定した情報だけ公開したい、あとは非公開にしてくれ」というお客様Bがいます。できるだけ汎用的なソフトウェア１本で、両方の顧客の要求を満足したい。じゃあどうするか。
　そこで設定というものが入り込んできます。例えばWebサーバの例ですと、アクセス制限機能というものを設けて、その設定をお客様ごとに変えられるようにしましょうと。そういうことです。
　しかしここで一つの問題が生じます。顧客A, Bが要求していることは正反対です。これを正しく理解して、正しく設定している限りにおいては何の問題もありません。しかし、たとえば個人情報を扱うサイトを運営している顧客Cで、顧客Aの設定をコピーして使ってしまったら、何が起きるでしょうか。

　個人情報の漏洩です。

　残念ながら、インターネットで起きている個人情報の漏洩事件のいくつかは、この程度の初歩的なミスが原因です。具体的にどの事件が、ということを名指しで非難することはしませんが、海外ではこのような設定の不注意が原因で、１国の投票者全員の個人情報が漏洩するような驚くべき事件も起きています。
　さて、このような事件が起きた原因はソフトウェアでしょうか。調べていくと、ソフトウェアそのものは精巧に作られており、アクセス制限の機能もさまざまな利用シーンに合わせて高度に作り込まれています。できるだけ多くのお客様に量販して、また機能拡張してお客様の要件にあわせていくために、ソフトウェアの製作者としてはアクセス制限機能を豊富に用意しているわけです。
　問題なのは、ソフトウェアを設定するエンジニアがこういった基本的な事柄を理解せずに、「まずは動けばよし」で設定してしまったケースです。「まずは」なのですが、動いてしまうとそのことが忘れ去られてしまいます。

　　「あー動いた！やったね！」
　　「動かなくなるとまずいから、もう触るなよ！」

　。。。信じがたい話ですが、システムを統合する現場ではよくあるホラーストーリーのようです。もちろん、検査工程をきちんと設定していれば、かりに「やっつけ」で動かしてしまったとしても設定の不具合は、多くの場合、検査工程で見つけることができます。もちろん検査漏れがなければの話です。
　上で、設定の不具合と言いましたが、このようなセキュリティ上の問題につながる設定の不具合を、設定の脆弱性と呼んでいます。たんに「設定の不具合」というと、影響の少ない、すぐに直せる瑣末な問題のように思われてしまいかねないので、あえて「設定の脆弱性」(Configuration Vulnerability) と呼んで、セキュリティ上の問題が生じることを陽に表現する必要があるのです。
　理想的には、ソフトウェアを設定するエンジニアがソフトウェアの豊富な機能とその正しい設定方法を理解して、システムと情報の安全性を保つような設定をすることです。しかしこれは現実にはかなり難しいのです。それはなぜでしょうか。

　最大の問題は、ソフトウェアの製作者がいろいろな考え方を持っていて、ソフトウェアを設定するエンジニアが製作者の考え方を理解しないと正しく設定できないということです。
　例えばアクセス制限の例ひとつをとってみても、「情報公開が前提で、指定したものだけ隠したい」という設定と、「隠すのが前提で、指定したものだけ公開したい」という設定では、考え方がまるで違います。では、これを使い分ける設定はどう書きましょうか。さらに「隠すと指定したものの中でも、これだけ公開したい」という設定はどう書きましょうか。細かいケースを考え始めるときりがありませんが、ソフトウェアの製作者はこういった細かいケースもきめ細かく設定できるように、自分たちなりの考え方で「設定ファイル」をそれぞれ発明しているのです。
　発明。。。それこそが問題です。自動車はハンドルとブレーキの位置や扱い方が決まっていて、免許をとればどこのメーカーの車でも大抵は運転することができますが、ソフトウェアを正しく設定するためには、運転の考え方がまるで違う車（たとえばブレーキのない車や、自動操縦を前提とした車など）を乗りこなすのと同じように、設計思想から理解しなければなりません。

　私は、ソフトウェアも自動車と同じように、いずれはセキュリティ関連の設定だけでも標準化したほうがいいと思っています。セキュリティの設定をいちいち発明しなければならない、というのは馬鹿げています。しかしソフトウェアは自由につくるべきだ、と考えている人はいまだに多く、頭のいいプログラマほど自分たちの考え方を強く打ち出す傾向にあります。皆さんがお使いのスマートフォンも、OSが違えばセキュリティ設定の基本的な考え方がまるで違っています。パソコンのOSともセキュリティ設定の考え方が違います。これで設定ミスを犯すな、とエンジニアだけに責任をなすりつけるのは酷だというものです。もちろん、プロのエンジニアはこういった複雑性を克服するからこそプロだと今の時代では考えられているのですが。
　基本的な考え方に大きな差異がないのであれば、大学や専門学校の授業で教えることができます。しかしセキュリティ設定の考え方がOSごとに、ソフトウェアごとに違う現状では、授業で教えられることは限られてしまいます。かりに車のハンドルとブレーキの取り付け位置が自動車メーカーごとに違ったとしたら、教習所で安全運転を教えるのも一苦労です。A社のクルマ専用の教習所をつくって、A社のクルマしか運転できないドライバーを育てましょう、といういささか無理のあるビジネスを展開しているのが IT業界だということを我々は認識すべきでしょう。
　そこを蒸し返してどうする、大人になれよ、と思っているIT業界の読者の方もいることでしょう。そんなことだから、IT業界は他の業界から信用されないのだ、ということも言っておきましょう。１０年後、２０年後に普通のエンジニアが無理せずに安心、安全を提供できる世界を我々は目指すべきでしょう。

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


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