Facebookの障害とTwitchへの侵害がビジネスリーダーにとって重要な理由
Josh Stella
2021年10月14日
0 分で読めます編集者注
このブログ記事は、もともとfugue.coに掲載されていました。Fugueは2022年にSnykの一員となり、Snyk IaCの重要な構成要素となっています。
今月、FacebookとTwitchはいずれも自らの過失によって深刻な被害を受けました。すべての経営幹部は、何が起きたのか、そしてこうしたインシデントをどうすれば防げるのかを理解する必要があります。

Facebookでは、ネットワーク設定の変更によってサービスが数時間にわたり停止し、WhatsAppとInstagramも同時に利用できなくなりました。その結果、数千万ドルの収益が失われ、数百万人のユーザーがこれらのサービスにアクセスできなくなりました。
Amazon傘下のインタラクティブなライブストリーミングサービスTwitchでは、サーバーの設定ミスによってハッカーが大量の機密データにアクセスしました。そこには、ユーザーに関する情報や未公開アプリケーションのソースコードも含まれており、ハッカーはそれらをインターネット上に公開しました。
この1年間だけで、36%の企業がクラウドの設定ミスによる深刻なセキュリティ漏えいや侵害を経験しました。
これまでも、企業のクラウド利用者が自らの防止可能な設定ミスの被害に遭う事例を何度も見てきました。今回注目すべきなのは、FacebookとTwitchが実質的に自社のクラウドプラットフォームの利用者であるという点です。クラウドプロバイダーがどれほど多くの複雑さを顧客に委ねてきたかを考えると、こうしたインシデントが繰り返し起きるのも不思議ではありません。人々のクラウドセキュリティの能力が低いからではなく、習熟するのが本当に難しいからです。詳しく見ていきましょう。
クラウドのリスクは設定のリスク
クラウドの攻撃対象領域はネットワークではなく、設定です。設定とは、基本的にインフラストラクチャをどのように設計し構築したかを指します。「設定」という言葉は些細なことのように感じられるかもしれませんが、クラウドでは非常に重要です。設定を誤ると脆弱性が生まれ、アプリケーションが停止する可能性があります。たった一つの設定ミスでも、システム停止やデータ侵害という甚大な影響につながり、収益や顧客の信頼を失うことになりかねません。
車を例に考えてみましょう。車にはエンジン、トランスミッション、車輪などの部品があります。どの部品にも設定があり、その一部は安全性に関わり、法律で規制されています。車が製造ラインから出荷される前には、人や機械が設定を検査します。その後、所有者が設定を変更することもあります。安全検査員が設定違反を指摘するのは、不適切な設定が故障や事故を引き起こす可能性があるためです。
規模と複雑さでいえば、企業のクラウド環境は空母に近いものです。数十万ものリソースを含み、それぞれに数十もの設定が関わる場合があります。クラウドエンジニアリングチームは毎日、数十回、場合によっては数百回もの設定変更を行っています。車の例に戻れば、これは時速約113キロで高速道路を走りながら、速度を落とさずにトランスミッションを交換するようなものです。
クラウドは絶えず変化し、変更のたびにリスクが生まれる
クラウドは、人類がこれまでに生み出した中で最も安全なコンピューティングプラットフォームです。ただし、適切に構築し、変更によって脆弱性が生まれないようにすることが条件です。そこが難しいのです。
クラウドが絶えず変化することは、現代の企業の成功に欠かせないスピードと俊敏性を支えています。クラウドを利用する企業は一般に、データセンターを利用する企業よりも早く市場に製品やサービスを投入できます。しかし、変化には大きなリスクも伴います。人々は毎日設定を決め、翌日にはそれを変更しています。セキュリティの観点から、こうした判断はどれほど十分な情報に基づいているでしょうか。
残念ながら、答えは「十分ではない」です。これはソフトウェアエンジニアを非難するものではありません。彼らには多くのことが求められていますが、素晴らしい成果を生み出してくれています。しかし、人間は何千ものデータ項目や、それをはるかに上回る数のルールをすべて記憶しておくのが苦手です。クラウドベースのシステム全体と、あらゆる変更がもたらすセキュリティ上の影響を完全に把握できる人はいません。しかし、クラウド環境を完全に把握し、敵対者にその知識を与えないことは、安全を保つうえで不可欠です。
クラウド環境が大規模化・複雑化するにつれ、この問題はさらに深刻になります。
21世紀の「安楽椅子」ハッキング
幸いなことに、クラウドセキュリティチームはこの課題への認識を深めています。一方、ハッカーには大きく後れを取っています。ハッカーは、クラウドシステムを悪用するために必要な知識を効率よく得るようになりました。自動化を使ってインターネットをスキャンし、環境への侵入に利用できるクラウドの設定ミスを探します。侵入後は、さらに別のミスを利用してリソースを特定し、ネットワーク内を横移動し、検知されずにデータを持ち出します。
Twitchは、データがインターネット上に出回り始めるまで侵害に気づきませんでした。また、たった一つのサーバーの設定ミスが、そのサーバーの範囲をはるかに超えるデータの侵害を可能にしました。数年前のCapital Oneの事例でも同じことが起きました。Capital Oneは、クラウドセキュリティにおいて最も優れた企業の一つとして広く認められています。

ビジネスリーダーとセキュリティリーダーが今すぐできること
クラウドを利用するすべてのビジネスリーダーとセキュリティリーダーは、状況に注意を払い、問いかける必要があります。クラウドはデータセンターよりもはるかに安全にでき、競争力の向上にもつながります。しかし、クラウドでより安全にできるからといって、今すでに安全だとは限りません。安全だと決めつけないことが大切です。
欠かせない5つのステップをご紹介します。
1. クラウド環境の現状を把握する
現在のクラウドセキュリティ態勢を把握する必要があります。クラウドセキュリティチームに、6か月前や前回の監査時点ではなく、今日現在のクラウド環境の状況を報告するよう依頼しましょう。レポートには、インフラストラクチャの設定状況を網羅した全体像と、深刻度別の脆弱性一覧が必要です。正午までに報告できないなら、チームは現状を把握できていません。それは危機感を持つべき事態であり、こうした知識の獲得をチームの最優先事項にしなければなりません。クラウド環境のすべては把握可能です。すぐに取り組みましょう。
2. クラウドセキュリティを予防の視点で考える
現状を把握したら、クラウドセキュリティへの考え方を変えるときです。セキュリティチームは、攻撃者を見つけるための侵入検知やネットワーク監視に、まだ注力しているかもしれません。しかし、クラウドセキュリティはそのようには機能しません。ハッカーが環境に侵入した時点で、もう手遅れです。クラウド侵害は数分で起こり、従来のセキュリティツールではほとんど、あるいはまったく対処できません。クラウドセキュリティで重要なのは、設定ミスによる脆弱性を未然に防ぐことです。
3. Policy as Codeを適用し、取り組みを強化する
クラウドの設定ミスを防ぐ唯一の方法は、クラウド運用のあらゆる側面にセキュリティの自動化を組み込むことです。そのためにはPolicy as Codeが必要です。Policy as Codeを使うと、セキュリティやコンプライアンスのルールをプログラミング言語で記述でき、アプリケーションが設定の正しさを検証できます。人が一貫性なく確認やルール適用を行う代わりに、Policy as Codeによって、クラウドに関わるすべての人が、ルールの内容や適用方法について曖昧さや意見の食い違いなく、安全に運用できるようになります。
4. クラウドに関わるチームの連携を強化する
このモデルでは、セキュリティチームはアプリケーション開発者やクラウドエンジニアにツールを提供する役割を担います。クラウドシステムを開発するエンジニアは、作業内容をポリシーに照らして自動的にチェックし、何かを構築する前にすばやく簡単に修正できます。自動化されたガードレールが、危険な脆弱性を含むクラウド環境のデプロイを防ぎます。さらに、セキュリティチームは環境を継続的に監視し、すり抜けた設定ミスを、攻撃者に見つかる前に検出します。
5. セキュリティをあらゆる場面に根付かせる
組織のクラウドセキュリティを変革するには、新たな人材の採用やトレーニング、プロセスの整備、企業文化の変革が必要です。簡単ではありませんが、実行しなければ大きなリスクを抱え続けることになります。自動化とPolicy as Codeに注力すれば、エンジニアを大量に採用する必要はありません。エンジニアの獲得競争が激化している今、これは朗報です。自動化とPolicy as Codeにより、セキュリティチームはより難易度の高い課題に取り組めるようになり、アプリケーションチームは安全なイノベーションをより速く市場に届けられます。
開発者のために設計されたIaCセキュリティ
Snykは、統合されたポリシー・アズ・コードエンジンにより、SDLCからクラウドでの実行時までInfrastructure as Codeを保護します。すべてのチームが安全に開発、デプロイ、運用できるよう支援します。