クラウドの設定ミスによる攻撃を回避する7つの方法

クラウド エンジニアリング チームとセキュリティ チームは、クラウド運用環境のセキュリティについて重要な質問をする必要があり、環境がコンプライアンス監査に合格するかどうか以上のことを検討する必要があります。

たとえば、新しいエンドポイントがインターネットに追加されてから数分後に、攻撃者はそれをスキャンして、その悪用可能性を評価する可能性があります。クラウド構成のエラーが 1 つあるだけで、データが危険にさらされる可能性があります。

サイバー攻撃者がこれらの脆弱性の 1 つを発見し、その動作環境に足がかりを得たとしたら、どれほどの破壊力があるでしょうか?どのような損害が発生する可能性がありますか?サイバー攻撃者が動作環境に関する技術や機密データが保存されている場所を発見するのはどれほど簡単なのでしょうか?クラウド リソース API キーと過度に緩い IAM (ID およびアクセス管理) 設定を悪用して、企業のクラウド コントロール プレーンを侵害し、追加のリソースやデータにアクセスすることは可能でしょうか?バケット同期コマンドなどを使用して、検出されることなくこのデータを自分のクラウド アカウントに抽出できるでしょうか?

さらに詳しく調べると、クラウド構成に多くの穴があることがわかります。ハッカーがそれを悪用する前に、クラウド セキュリティのこれらの穴を迅速に修正する必要があります。また、自動化された継続的インテグレーション (CI)/継続的デリバリー (CD) パイプラインを使用しても、クラウド構成の「ドリフト」は常に発生することを認識し、常に注意を払う必要があります。

クラウドセキュリティは構成セキュリティである

クラウド コンピューティングは本質的に巨大なプログラム可能なコンピュータです。クラウド コンピューティング運用の焦点は、IAM、セキュリティ グループ、データベースやオブジェクト ストレージのアクセス ポリシーなど、セキュリティ上重要なリソースを含むクラウド コンピューティング リソースの構成です。企業は、クラウド コンピューティング リソースが初日から正しく安全に構成され、その後もその状態が維持されるようにする必要があります。

業界アナリストはこれをクラウド セキュリティ態勢管理と呼んでいます。そして、クラウド コンピューティングの顧客はここで間違いを犯しがちで、時には壊滅的な結果を招くこともあります。 AWS、Microsoft Azure、Google Cloud に関連するデータ侵害が発生した場合、これらのサイバー攻撃はクラウド ユーザー自身のミスによって発生したと確信できます。

オブジェクト ストレージ サービス (Amazon S3、Azure Blob など) や仮想ネットワーク (AWS VPC、Azure VNet など) などの個々のクラウド リソースの誤った構成を回避することに細心の注意が払われており、これは極めて重要です。

しかし、クラウド セキュリティは ID に依存していることを認識することも重要です。クラウドでは、多くのサービスが API 呼び出しを通じて相互に接続されており、IP ベースのネットワーク ルールやファイアウォールなどの代わりに、セキュリティを実装するために IAM サービスが必要です。

たとえば、AWS Lambda 関数から Amazon S3 バケットへの接続は、Lambda 関数が引き受けたロール (そのサービス ID) に添付されたポリシーを使用して行われます。 IAM や同様のサービスは複雑で機能が豊富であり、物事をうまく機能させるために過度に許可しすぎることがよくあります。つまり、過度に許可する IAM 構成が標準であり、これは多くの場合危険です。

Cloud IAM は新しい Web ですが、Cloud IAM サービスは構成を通じて作成および管理されるため、クラウド セキュリティでは依然として誤った構成を回避することが重要です。

クラウドの誤った構成とセキュリティインシデント

データセンターと比較すると、クラウド コンピューティング インフラストラクチャの種類ははるかに多く、これらのリソースはすべて完全に構成可能です。利用可能なクラウド リソースの種類と、それらを組み合わせてアプリケーションをサポートする方法を考慮すると、クラウドを構成できる方法の数は事実上無限です。

調査会社が2021年に実施した調査では、クラウドコンピューティングの専門家の36%が、自社が過去1年間に深刻なクラウドセキュリティ侵害やサイバー攻撃を受けたと回答しており、こうしたインシデントはさまざまな形で発生した。

オブジェクト ストレージや IAM サービスなどのリソースの構成は、スケールアウトされた環境では非常に複雑になる可能性があることを覚えておくことが重要です。また、すべてのクラウド侵害には、一連の構成ミスによる脆弱性が伴うことはよく知られています。単一のリソースの誤った構成に焦点を当てるのではなく、そのユースケースを徹底的に理解し、運用環境の完全なコンテキストでこれらのサービスを保護する方法について批判的に考える方がよいでしょう。

たとえば、「パブリックアクセスをブロック」が有効になっているため、Amazon S3 バケットは安全に構成されていると信じている人がいるかもしれませんが、悪意のある人物が同じ環境内の過剰な権限を持つ IAM リソースを利用してそのコンテンツにアクセスできる可能性があります。プログラムが壊れるリスクを理解することは対処が難しい問題ですが、無視できない問題でもあります。

クラウドの設定ミスの規模

クラウドの構成ミスによる脆弱性は、修正された後も再発し続けるという点で、アプリケーションやオペレーティング システムの脆弱性とは異なります。組織では、開発者が既知のアプリケーションまたはオペレーティング システムの脆弱性を本番環境に導入しないようにするために、開発パイプラインに制御を導入する場合があります。これらの展開が保護されると、通常、この問題は解決されます。

クラウドの誤った構成はそれぞれ異なりますが、同じ誤った構成の脆弱性が何度も再発することはよくあります。無制限の SSH アクセスを許可するセキュリティ グループ ルール (例: ポート 22 の 0.0.0.0/0) は、承認されたデプロイメント パイプラインの外部で日常的に発生する誤った構成の一例にすぎません。私がこの例を使用するのは、ほとんどのエンジニアがこの例をよく知っているからです (そして、おそらくキャリアのどこかの時点でこのひどい行為に従事したことがあるでしょう)。

クラウド コンピューティング インフラストラクチャは非常に柔軟であり、API を使用して自由に変更できるため、これが好まれます。これは良いことです。なぜなら、アプリケーションには絶え間ない革新と改善があり、この革新をサポートするためにインフラストラクチャを変更する必要があるからです。ただし、このプロセス中に誤った構成が防止されない場合、運用環境に多数の誤った構成が導入されることが予想されます。クラウド エンジニアリング チームとセキュリティ チームの半数は、1 日に 50 件以上の構成ミス インシデントを処理する可能性があると述べています。

クラウドの設定ミスが発生する理由

クラウド コンピューティング サービスがうまく利用されていれば、クラウド コンピューティング環境における唯一の不変の要素は変化であり、これは企業が急速に革新し、アプリケーションを継続的に改善していることを意味します。しかし、あらゆる変化にはリスクが伴います。

調査会社ガートナーの調査によると、2023年までにクラウドセキュリティ障害の99%以上が顧客自身によって引き起こされることになるという。クラウドの誤った構成はクラウド セキュリティ障害が発生する原因の 1 つですが、誤った構成は完全に人為的エラーの結果であることに注意してください。

しかし、なぜクラウド エンジニアはこのような重大なミスを頻繁に犯すのでしょうか?

クラウドのセキュリティとポリシーに関する認識不足は、過去 1 年間に報告されたクラウドの誤った構成の主な原因の 1 つでした。すべてのコンプライアンス ルールと社内セキュリティ ポリシーをまとめると、おそらく小説 1 冊分になるでしょう。誰もこれらのルールを暗記することはできませんし、暗記できると期待されるべきでもありません。

したがって、構成エラーを防ぐために適切な制御が必要です。しかし、回答者の 31% は、クラウドの誤った構成を防ぐための適切な管理と監視が組織に欠けていると回答しました。

その理由の 1 つは、チームが効果的に管理するには API とクラウド インターフェースが多すぎることです。複数のクラウド プラットフォームを使用すると (回答者の 45% が報告)、各クラウド プラットフォームに独自のリソース タイプ、構成プロパティ、管理インターフェイス、ポリシー、コントロールがあるため、問題がさらに悪化します。チームには、使用中のすべてのクラウド プラットフォームに効果的に対処できる専門知識が必要です。

チームがマルチクラウド環境では機能しないクラウド サービス プロバイダーのクラウド ネイティブ セキュリティ ツールを採用している場合、マルチクラウド セキュリティの課題はさらに複雑になります。

7つの戦略的推奨事項

クラウド セキュリティの主な目的は、ハッカーに悪用される前に誤った構成エラーを防止、検出、修復することです。そのため、インフラストラクチャ アズ コード (IaC) から継続的インテグレーション (CI)/継続的デリバリー (CD) まで、開発ライフサイクルのあらゆる段階で効果的なポリシーベースの自動化を導入する必要があります。

これを実現するためのクラウド コンピューティングの専門家からの 7 つのヒントを紹介します。

（１）環境の可視性を確立する

クラウド セキュリティとは、データを保持し、サイバー攻撃者や競合他社がそのデータや知識にアクセスできないようにすることです。すべてのリソース、構成、関係など、クラウド コンピューティング環境の完全な状態を把握できなければ、重大なリスクにさらされます。企業は、クラウド プラットフォーム全体にわたるクラウド コンピューティング環境の包括的な可視性を確立して維持し、侵害の潜在的なリスクを含む各変更のセキュリティへの影響を継続的に評価する必要があります。

企業はセキュリティ体制を強化して開発者の行動を迅速化できるだけでなく、コンプライアンス担当者も企業が提供するプロアクティブな監査証拠の恩恵を受けることができます。

（２）可能な限りインフラストラクチャをコードとして利用する

いくつかの例外はありますが、特に新しいものについては、企業がクラウド インフラストラクチャ アズ コード (IaC) と自動化された継続的インテグレーション (CI)/継続的デリバリー (CD) パイプラインを超えて何かを構築したり変更したりする理由はありません。 IaC を使用すると、クラウド コンピューティングの運用に効率性、規模、予測可能性がもたらされるだけでなく、展開前にクラウド コンピューティング インフラストラクチャのセキュリティをチェックするメカニズムも提供されます。開発者が IaC を使用すると、展開前にインフラストラクチャのセキュリティを確認するために必要なツールが提供されます。

企業がマルチクラウドを導入している場合、Terraform のような広く採用されているオープンソースの IaC ツールが最善の選択肢となる可能性があります。クラウド コンピューティング サービス プロバイダーが提供する IaC 製品 (AWS CloudFormation、Azure Resource Manager、Google Deployment Cloud Manager など) は無料であり、マルチクラウド サポートが不要な場合は検討する価値があります。

（３）可能な限りポリシーベースの自動化を使用する

クラウド コンピューティング戦略を表現するために人間の言語が使用される場合は、解釈の誤りが生じます。企業のクラウド コンピューティング環境に適用されるすべてのクラウド セキュリティおよびコンプライアンス ポリシーは、実行可能コードとして表現および実装する必要があります。ポリシーをコードとして利用することで、クラウド セキュリティは決定論的になります。これにより、セキュリティ ポリシーを効率的に管理および適用できるようになり、開発者は開発プロセスの早い段階でセキュリティを導入できるようになります。

ベンダー独自のポリシー・アズ・コード ツールを避け、Open Policy Agent (OPA) などのオープン ソース ポリシー エンジンを選択してください。 OPA は、JSON または YAML 出力を生成できるあらゆるものに適用でき、ほぼすべてのクラウド ユース ケースをカバーします。

企業は、IaC とクラウド インフラストラクチャの実行に異なるツールや戦略を必要としないソリューションを優先できます。

（4）開発者が安全に構築できるようにする

クラウド コンピューティングでは、セキュリティはデータ分析の問題ではなく、ソフトウェア エンジニアリングの問題です。クラウド セキュリティの専門家には、エンジニアリング スキルと、開発から継続的インテグレーション (CI)/継続的デリバリー、ランタイムまでのソフトウェア開発ライフサイクル (SDLC) 全体の仕組みに関する理解が必要です。開発者には、ソフトウェア開発ライフサイクル (SDLC) の早い段階でセキュリティを導入するのに役立つツールが必要です。セキュリティを、展開後の後付けではなく、先見の明と開発の密接なパートナーとして位置付けます。

セキュリティ チームに実践的なクラウド エンジニアリングのプラクティスをトレーニングすると、クラウド内のサイバー脅威から身を守るために必要なスキルが身につくだけでなく、キャリアアップに役立つ貴重なスキルと経験も得られます。企業はチームの定着率を向上させ、組織を働きやすい職場として位置づけることができます。

クラウド セキュリティ コース シリーズは、クラウド コンピューティングおよびセキュリティ エンジニアがクラウド コンピューティングのリスクを理解し、その固有のユース ケースのセキュリティ保護について批判的に考える方法を学ぶことができるように設計されています。

（５）アクセスポリシーのロック

組織にクラウド コンピューティング環境にアクセスして管理するための正式な戦略がまだない場合は、今すぐに作成してください。仮想プライベート ネットワーク (VPN) を使用して、Amazon Virtual Private Cloud や Azure Virtual Network などの重要なネットワーク スペースとの安全な通信を強化します。 VPN アクセスを利用できるようにすることで、信頼性の低い Wi-Fi ネットワーク上にいる場合でもチームが企業リソースにアクセスできるようになります。

エンジニアは、クラウド内の共有チーム リソースにアクセスできるように、新しいセキュリティ グループ ルールまたは IP ホワイトリストを作成する傾向があります。頻繁な監査により、仮想マシンやその他のクラウド コンピューティング インフラストラクチャが追加のリスクにさらされていないことが証明されます。要塞ホストの作成を監視し、ソース IP 範囲をロックダウンし、無制限の SSH アクセスを監視します。

AWS、Azure、GCP、その他のパブリック クラウドでは、IAM はユビキタス ネットワークとして機能します。最小権限の原則に従い、Fugue ベスト プラクティス フレームワークなどのツールを活用して、コンプライアンス チェックで見逃される可能性のある脆弱性を特定します。 IAM の変更を変更管理プロセスの一部にし、特権 ID およびセッション管理ツールを活用します。

したがって、「デフォルト・ノー」の考え方を採用する必要があります。

（6）すべてのクラウドリソースにタグを付ける

リソースのタグ付けを実装し、クラウド フットプリント全体にわたって効果的なタグ付け規則を確立します。タグの使用は、企業がクラウド リソースを追跡および管理するのに最適な方法の 1 つですが、タグ付け規則を確立して適用する必要があります。人間が判読できるリソース名を使用し、各リソースの連絡先担当者、プロジェクト名、展開日などの情報を含めます。

クラウド リソースが適切にタグ付けされていない場合は、非常に疑わしいとみなして終了する必要があります。たとえば、Microsoft Azure には、クラウド リソースのタグ付け規則に関する優れたリソースがあります。

（７）平均修理時間を決定する

リスクとクラウド セキュリティの有効性を測定することは、企業が自社の立場と目標を決定する方法です。最も重要な指標は平均修復時間です。企業は、セキュリティ上重要なクラウド リソースの誤った構成を修復するための現在の平均時間を把握していない可能性があります (把握しているクラウド カスタマーはほとんどいません)。そのため、平均時間を変更する必要があります。修復までの平均時間を分単位で目標に設定します。自動修復がチームや環境にとって実行可能なオプションでない場合は、プロセスを調整して、ハッカーが重大な脆弱性を発見する前にチームがそれを検出して修復できるようにします。

将来に向けて

クラウド コンピューティングの導入が拡大するにつれて、企業の運用環境の複雑さと、その環境を安全に保つための課題が増大します。ハッカーは自動化技術を使用して、数分でクラウドの誤った構成を特定し、悪用することができるため、まず構成エラーを回避することが重要です。開発者にポリシー・アズ・コードベースの自動化ツールを提供することで、セキュリティ担当者を追加することなく、セキュリティの取り組みを拡大し、これらの新しい課題に対応できるようになります。さらに、データはデータセンターよりもクラウド内でより速く移動します。