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