運営面でのゲートを除外したクラウド活用の末路

2017年1月、日本でも人気のあるオープンソースのデータベースであるMongoDBを活用したアプリがランサムウエア攻撃を受け、話題になりました。その方法とは、一般的なものになりつつあるデータを人質に取り、復元に際して金銭を要求するものでした。

その後の操作で明らかになったのは、問題はソフトウェアではなく、その設定内容(コンフィグレーション)にあったことです。AWS上で実行されているデフォルトのコンフィグレーションでは、インターネットに接続できさえすれば、誰でも容易にデータベースにアクセス可能だったようです。

CloudPetsで露呈したずさんなクラウド運用

一連の騒動には、ある意味有名となった子供向けIoT玩具「CloudPets」が含まれていました。このケースでは、親子の間で交わされた（プライバシーが守られていると思われていた）ボイスメッセージが、データベース（MongoDB上のセキュリティが確保されていないインスタンス）にアクセスできる人物や、アプリケーションのアーキテクチャとそれによるAmazon S3の使い方を理解できるだけのスキルを持った者なら、誰でも閲覧可能であることが判明しました。

つまり、CloudPetsは、プロファイル画像や音声レコードの保存にS3を使用しているにもかかわらず、一切のセキュリティ対策を講じなかったため、場所さえ分かっていれば、誰でもアクセスすることが可能だったのです。

RedLockのCSIチームの調査によると、「Amazon Relational Database ServiceやAmazon RedShiftなど、パブリッククラウドによるコンピューティング環境内のデータベースの82%は暗号化されていない」と言います。

さらに、「このようなデータベースの31%が、インターネットからの接続リクエストを受け入れている」とも指摘されています。

信じられないような調査結果ですが、2017年1月の第1週に発覚した2万7000を超えるMongoDBサーバが侵入された事件がデータの信頼性を裏付けています。

最初の攻撃が明らかになったとき、MongoDBのブログには、次のように書かれていました。

「このような攻撃は、MongoDBに組み込まれている豊富なセキュリティ機能により防止可能です。これらの機能を正しく使用していただく必要があり、そのためには、MongoDBが提供しているセキュリティ関連の資料が役立ちます」（下線は筆者が付け加えたものです）

MongoDBに、セキュリティ機能が欠落していたわけではなく、単にセキュリティがまったく適用されていなかったのです。ここでの問題は、製品そのものではなく、クラウドを通じてIoTやモバイルアプリを消費者の手に急いで届けようとする人々のお粗末な仕事ぶりでした。

クラウドは、セキュリティに配慮しない業務習慣を促進してしまう

データセンターには、ソフトウェアを導入して、それをデータに使用するまでに通過しなければならないゲートがあります。そのゲートは主に、ファイアウォールなどの物理的なものと、プロセスや承認といった運用面でのものといった2種類が存在します。

クラウドは、多くの場合において構造上、物理的ゲートがより少なく、また、アプリケーションが提供されるまでに通過しなければならない運用面のゲートもわずかです。この運用面のゲートが少なくなっていることが、まさに「ローグIT」や「シャドーIT」の元凶なのです。

クラウドを使い始めたのは、元々、リードタイムの長さやプロジェクトが数カ月ではなく数年単位になることに不満を感じていた各事業部門の人々でした。しかし、これに伴い、アプリケーションのセキュリティやパフォーマンスを確保するために設けられていた運用面のゲートも迂回されるようになりました。

これは、クラウド自体の問題ではなく、クラウドを利用する人々の問題です。つまり、IT部門が長年聞かされ続けてきた「物理的ハードウェアの調達に時間がかかりすぎる」という問題だけではなく、「IT部門の承認プロセスを通過するのに時間がかかりすぎる」ことが、競合企業に先んじて製品を市場に出したい各事業部門の人々にとって真の問題となっていることが原因だったのです。

2017年にArxan/IBMが実施した「Mobile and IoT Security」調査の結果も、このことを裏付けています。回答者は、アプリケーション開発チームにかかるプレッシャーがIoTとモバイルアプリにおけるセキュリティ欠落の原因であるとし、69%は脆弱性を含むコードが生まれるのはモバイルアプリ開発を急ぐことに責任があり、また75%はIoTアプリケーションについても同様と答えました。

このようなプレッシャーは、当初の準備作業であるデータベースとクラウド内ストレージをセットアップし、セキュリティを確保する作業にも及んでいます。CloudPetsのコンセプトは、おもちゃ自体ではなく、おもちゃがインターネット経由でデータの送受信を行えることに基づいて構築されています。ですが、CloudPetsを成功させるためには、リリース日であるクリスマスに間に合わせるべく、IoTアプリケーションの開発とクラウドへの展開を急がなければならなかったのではないでしょうか。

アプリケーションのセキュリティ確保は、それを提供するデベロッパーだけの責任ではありません。データベース、ファイル共有、あるいはアプリケーションサービス全般のいずれであれ、アプリケーションを支えるクラウド内のサービスを調達する人々にも、一定の責任があります。また、非現実的な納期を求め、最終的な提供においては運用面のゲートを最小限に留めようとする各事業部門の人々にも責任があります。

運用ゲートの見直しを

IT部門が、デジタルトランスフォーメーションに取り組み、消費者への製品提供を成功させ、かつ安全性を確保できるよう運用面のゲートを合理化しなければならないことは事実です。しかし、各事業部門もデベロッパーも、クラウド内の運用面のゲートを単に回避し続け、「デフォルト」のコンフィグレーションに頼るお粗末なセキュリティでは、消費者だけでなく企業の関係者もリスクに曝すことになります。

これは、製品というよりもプロセスの問題です。つまり、悪用を阻止するためには、アプリケーションとそのユーザーを守るためのポリシーを展開し、コンフィグレーションがそれにふさわしいものであることを確認しなければなりません。

恥ずかしいインシデントを起こさないためには、市場に出すまでに通過しなければならない基本的な運用面のゲートをいくつか導入すると同時にその使用を義務付けること。そして、それによって基本的なセキュリティをクラウド内に導入することから始める必要があります。

生産性と利益の両方を支えるアプリケーションにおいて、パブリッククラウドへの移行が加速しているため、企業や組織はこのような運用面のゲートをこれまで以上に必要としています。また、このような移行への加速は、犯罪者にとって攻撃の機会拡大になると言えるでしょう。