クラウド構成エラーを回避する 7 つの方法

クラウド エンジニアリング チームとセキュリティ チームは、クラウド環境のセキュリティについていくつかの重要な質問をする必要があり、環境がコンプライアンス監査に合格するかどうかをはるかに超えるレベルの対応を行う必要があります。

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

攻撃者がこれらの脆弱性の 1 つを発見し、環境内に最初の足掛かりを築いたとします。この貫通による爆発半径はどれくらいですか?どのような損害を与えることができますか?

攻撃者があなたの環境や機密データの保存場所に関する情報を発見するのはどれほど簡単ですか?クラウド リソース API キーと過度に緩い IAM (ID およびアクセス管理) 設定を利用して、クラウド コントロール プレーンを侵害し、他のリソースやデータにアクセスする可能性がありますか?バケット同期コマンドなどを使用して、検出されることなくこのデータを自分のクラウド アカウントに抽出できるでしょうか?

さらに調査を進めると、おそらく気に入らないものが見つかるでしょう。ハッカーが悪用する前に、クラウド セキュリティのこれらのギャップを迅速に埋めてください。また、自動化された CI/CD パイプラインを使用している場合でも、クラウド構成の「ドリフト」は常に発生することを認識し、常に注意を払う必要があります。現在、誤って構成されたクラウド環境は存在せず、長期間その状態を維持することは不可能です。

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

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

業界アナリストはこれをクラウド セキュリティ ポスチャ管理 (CSPM)と呼んでいます。ここでクラウド顧客はしばしば間違いを犯し、時には壊滅的な結果を招くことがあります。 Amazon Web Services、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 年間に組織が重大なクラウド セキュリティ侵害または侵害を受けたと回答しています。そして、これらのイベントを可能にする方法はさまざまです。

​​​

出典: 2021年クラウドセキュリティの現状レポート

スケールアウト環境では、オブジェクト ストレージや IAM サービスなどのリソースの構成が非常に複雑になる可能性があり、私たちが知っているすべてのクラウド侵害には、一連の構成ミスによる脆弱性が関係していることに留意してください。単一のリソースの誤った構成だけに焦点を当てるのではなく、ユースケースを徹底的に理解し、環境全体のコンテキストでこれらのサービスを保護する方法について慎重に検討してください。

たとえば、ブロックパブリックアクセスが有効になっているため Amazon S3 バケットが安全に構成されていると確信している場合でも、悪意のある攻撃者が同じ環境内の過剰な権限を持つ IAM リソースを利用してそのコンテンツにアクセスできる可能性があります。爆発半径のリスクを理解することは解決が難しい問題ですが、無視できない問題でもあります。

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

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

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

クラウド インフラストラクチャは非常に柔軟で、API を使用して自由に変更できるため、頻繁に変更する傾向があります。これは良いことです。なぜなら、当社は常にアプリケーションの革新と改善を行っており、この革新をサポートするためにインフラストラクチャを変更する必要があるからです。ただし、途中で誤った構成を防がなければ、環境に多数の誤った構成が導入されることになるでしょう。クラウド エンジニアリング チームとセキュリティ チームの半数は、1 日あたり 50 件を超える構成ミス インシデントに対処しています。

​​​

出典: 2021年クラウドセキュリティの現状レポート

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

クラウドをうまく活用している場合、クラウド環境における唯一の不変の要素は変化です。これは、急速に革新が進み、アプリケーションが継続的に改善されていることを意味するからです。

しかし、あらゆる変化にはリスクが伴います。

ガートナーによると、2023 年までにクラウド セキュリティ障害の少なくとも 99% は顧客の責任となるでしょう。クラウドの誤った構成がクラウド セキュリティ障害の原因であり、誤った構成は 100% 人為的ミスの結果であることを考慮すると、その 1% はヘッジのように思えます。

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

クラウドのセキュリティとポリシーに関する認識不足は、過去 1 年間に報告されたクラウドの誤った構成の主な原因の 1 つでした。すべてのコンプライアンス ルールと社内セキュリティ ポリシーをまとめると、『戦争と平和』と同じくらいの厚さの本になるかもしれません。誰もそれをすべて覚えることはできませんし、覚えることを期待すべきでもありません。

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

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

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

​​​

出典: 2021年クラウドセキュリティの現状レポート

7つの戦略的推奨事項

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

以下に、これを実現するためのクラウド専門家からの 7 つのヒントを示します。

1. 環境の可視性を確立します。

クラウド セキュリティとは、クラウドに関する知識を持ち、その知識への攻撃者によるアクセスを拒否することです。すべてのリソース、構成、関係性など、クラウド環境の完全な状態を理解していない場合、重大なリスクを負うことになります。クラウド プラットフォーム全体にわたってクラウド環境の包括的な可視性を確立して維持し、潜在的な爆発半径リスクを含むすべての変更のセキュリティへの影響を継続的に評価します。

セキュリティ体制が強化されるだけでなく、開発者の作業スピードが速まり、コンプライアンス専門家からもプロアクティブな監査証拠の提供に感謝されるようになります。

2. 可能な限りインフラストラクチャをコードとして使用します。

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

マルチクラウド環境を実行している場合は、 Terraform などの広く採用されているオープンソースの IaC ツールがおそらく最善の選択肢です。クラウド サービス プロバイダーが提供する IaC サービスは無料であり、マルチクラウド サポートを必要としない場合は検討する価値があります。

3. 可能な限り、ポリシーベースの自動化を使用します。

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

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

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

4. 開発者が安全にビルドできるようにします。

クラウドの場合、セキュリティはデータ分析の問題ではなく、ソフトウェア エンジニアリングの問題です。クラウド セキュリティの専門家には、エンジニアリング スキルと、開発から CI/CD、ランタイムまでのソフトウェア開発ライフサイクル (SDLC) 全体の仕組みに関する理解が必要です。開発者には、SDLC の早い段階でセキュリティを導入するのに役立つツールが必要です。セキュリティを、展開後の問題のみに焦点を当てた後付けのものではなく、先見性のある開発の密接なパートナーにしましょう。

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

5. アクセス ポリシーをロックダウンします。

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

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

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

「デフォルトで拒否」という考え方を採用します。

6. すべてのクラウド リソースにタグを付けます。

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

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

Microsoft Azure には、クラウド リソースのタグ付け規則に関する優れたリソースがあります。

7. 平均修復時間 (MTTR) を決定します。

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

将来に向けて

クラウドの使用が増えるにつれて、環境の複雑さとセキュリティを維持する課題が増加します。ハッカーは自動化を利用して、数分でクラウドの設定ミスを特定し、悪用するため、まず設定エラーを回避することが重要です。開発者にポリシー・アズ・コードベースの自動化ツールを提供することで、セキュリティスタッフを増やすことなく、セキュリティの取り組みを拡大し、これらの新しい課題に対応できるようになります。また、データセンターよりもクラウドの方が高速に移動できるようになります。

元のタイトル:クラウドの設定ミス攻撃を回避する 7 つの方法

原作者: ジョシュ・ステラ