2017年1月、非常に人気の高いMongoDBが、攻撃者の手口としてかなり定番化しつつあると見られるデータの人質化の被害に遭いました。その後の侵害調査で判明したのは、ほとんどの場合、攻撃者は何も悪用していなかったということです。問題はソフトウェアではなく、設定にありました。主にAWS上で稼働していたデフォルト設定により、インターネット接続さえあれば誰でもデータベースにアクセスできる状態になっていたのです。
これには、今や悪名高いCloudPets騒動も含まれます。この騒動では、子どもと保護者の間で交わされた音声メッセージ（非公開と考えられていたもの）が、データベース（セキュリティで保護されていないMongoDBインスタンス）を取得できるか、アプリのアーキテクチャとAmazon S3の利用方法を理解している人なら誰でもアクセスできる状態で公開されていました。Cloud Petsはプロフィール画像と音声記録の保存にS3を使用していましたが、あらゆるセキュリティ対策を軽視していたとみられ、適切な参照情報さえあれば誰でもアクセスできる状態になっていました。
さて、CloudPetsだけを批判していると思われないよう、次の点にも触れておきます。RedLock CSIチームは最近、「Amazon Relational Database ServiceやAmazon RedShiftなどのパブリッククラウドコンピューティング環境にあるデータベースの82%が暗号化されていない」ことを明らかにしました。
［劇的な間］
さらに、「それらのデータベースの31%が、インターネットからの受信接続リクエストを受け付けていました」。
さらに付け加えると、2017年1月の最初の数週間に、27,000台を超えるMongoDBサーバーが侵害されました。このインシデントでは、不適切なセキュリティ対策によって被害を受けたのはCloudPetsだけではなく、はるかに多くの組織に及びました。最初の攻撃が公表された際、MongoDBのブログには次のように記されています。「MongoDBに組み込まれた広範なセキュリティ保護機能を使用すれば、これらの攻撃は防止できます。これらの機能を正しく使用する必要があります。そのために、MongoDBのセキュリティドキュメントをご活用ください。［強調は筆者による］」
MongoDB自体が安全でなかったのではなく、単にセキュリティ対策がまったく施されていなかったのです。問題は製品そのものではなく、クラウド経由でIoTアプリやモバイルアプリを消費者に急いで提供しようとする人々の不適切な運用にあります。
安全でない慣行を助長するクラウド
データセンター、つまりオンプレミス環境では、ソフトウェアを一般公開してデータ提供に使用する前に、物理的なゲート（ファイアウォールなど）と運用上のゲート（プロセスや承認）の両方を通過する必要があります。クラウドは設計上、物理的なゲートが少なく、残念ながら多くの場合、アプリを広く一般に公開する前に通過すべき運用上のゲートも少ないように見受けられます。こうした運用上のゲートの減少こそが、「ローグIT」や「シャドーIT」という概念の行き着いた先です。長いリードタイムや、数か月ではなく数年に及ぶプロジェクト期間に不満を抱いた事業部門の関係者は、当初、IT部門を「迂回」するためにクラウドを利用し始めました。しかし、それは同時に、アプリケーションのセキュリティとパフォーマンスを確保するために設けられた運用上のゲートまで迂回することを意味していました。
これはクラウドの問題ではなく、クラウドを導入する側の問題です。この10年間、私たちは「物理ハードウェアのプロビジョニングには時間がかかりすぎる」と聞かされてきました。しかし、競合他社に先駆けて今すぐ市場に投入したい事業部門の関係者を本当に苛立たせているのは、それだけではなく、「IT部門の承認プロセスを通過するのに時間がかかりすぎる」ことなのです。
この見方は、Arxan/IBMがスポンサーを務めた2017年のモバイルおよびIoTセキュリティに関する調査の回答者によっても裏付けられています。回答者は、アプリ開発チームへのプレッシャーがIoTアプリやモバイルアプリのセキュリティ低下を招いていると指摘しました。69%が、モバイルアプリの開発を急ぐことが脆弱なコードを生む原因だと回答し、IoTアプリについても75%が同様に回答しています。
同じプレッシャーは、そもそも製品を役立つものにするデータベースやクラウドストレージの構築とセキュリティ確保にも及びます。Cloud Petsの根幹を成すのは玩具そのものではなく、玩具がデータを送受信できることです。インターネット経由で。つまり、その成功は、クリスマス当日の発売に間に合わせるため、IoTアプリの1つを急いで開発し、クラウドにデプロイできるかどうかにかかっています。
提供を任されたアプリケーションのセキュリティ確保に責任を負うのは、開発者だけではありません。データベース、ファイル共有、一般的なアプリケーションサービスなど、そのアプリケーションを支えるクラウドサービスのプロビジョニング担当者も、セキュリティ確保の責任の一端を担う必要があります。また、非現実的な期限を設定し、最終リリースに向けた運用上の審査を最低限に抑えるよう促すビジネス関係者も同様です。
確かに、IT部門はデジタルトランスフォーメーションを受け入れ、消費者に製品を確実かつ安全に提供するための運用上のゲートを効率化する必要があります。しかし、事業部門や開発者がクラウド上でこうした運用上のゲートを安易に回避し続け、「デフォルト」設定に依存する不十分なセキュリティ対策によって、消費者だけでなく企業のステークホルダーまでリスクにさらすことは許されません。これは製品というよりもプロセスの問題です。アプリとそのユーザーを回避可能な侵害リスクにさらす前に、ポリシーが適用され、構成が正しいことを確認する必要があります。
不名誉なインシデントを回避するには、まず基本的なセキュリティ基準を定め、市場投入前に通過すべき最低限の運用ゲートを定義して適用する必要があります。
生産性と収益の両方を支えるアプリのパブリッククラウドへの移行が加速しているため、組織にはこれまで以上に、こうした運用上のゲートが必要です。そして、移行の加速に伴い、攻撃者がそれらのアプリを悪用する機会も増加します。
著者について
Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事
F5 Application Study Tool：OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版：リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。