What are Cloud Native Applications?

クラウドネイティブ アプリケーションは、クラウド環境での展開と運用を目的として構築されています。 これらは、サーバーレス機能やコンテナーなどの小規模で独立したマイクロサービスで構成され、クラウド プロバイダーやサードパーティ パートナーが API 経由で提供するサービスを利用し、同時に自動化された安定性、スケーリング、リカバリのためにクラウドを活用します。 クラウド ネイティブ アプリケーションを構築すると、開発チームはクラウドの拡張方法に合わせて最適化されたアーキテクチャの実装に集中できます。

 

デモをリクエストする eBookをダウンロード

What are Cloud Native Applications?

クラウドネイティブ アプリケーションの構造

クラウドネイティブ アプリケーションには、攻撃者がこれらのアプリケーションにどのようにアプローチするかに影響を与える、新しい独特の構造があり、脅威の状況が変わります。 攻撃者がアプローチを変えて第 VI 世代攻撃に移行するにつれて、セキュリティ担当者と開発者はクラウドネイティブ アプリケーションの防御方法をそれに応じて調整する必要があります。

組織にとって最善の防止策を講じるためには、これらの新しい脅威により多くの時間とリソースを割り当てる必要があります。 リソースは戦略的に割り当てる必要がありますが、まず、この新しい脅威の状況で最も可能性の高い脅威を理解する必要があります。

クラウドネイティブアプリケーションの脅威の種類

クラウド ネイティブ アプリケーションのコンピューティング サービスは一時的になるように設計されており、有効期間が短い傾向があります。 これは、クラウド ネイティブ アプリケーションを本質的により安全にする多くの属性のうちの 1 つです。 攻撃者は、システム内で長期的なプレゼンスを簡単に達成できないため、戦術を変更する必要があります。 その結果生まれた戦略の 1 つが Groundhog Day Attack で、攻撃者は、たとえば、ほんの数個のクレジット カード番号を盗み、それを繰り返すという、はるかに短い攻撃を作成します。 攻撃者は、クラウド ネイティブ アプリケーションの自動スケーリングを利用して、その一時性を回避します。

もう 1 つのアプローチは、アップストリーム攻撃、つまりPoisoning the Wellで、攻撃者はアプリケーションの長期的な永続性を獲得することを目的としています。 クラウドネイティブ アプリケーションは、多くのモジュールとライブラリで構成される傾向があります。 1 つのサーバーレス関数には、開発者の作業以外のさまざまなソースからの数万行のコードが含まれる場合があります。 攻撃者は、一般的なプロジェクトに悪意のあるコードを含めようとします。 そして、井戸に毒を入れた後、クラウド アプリケーション内の悪意のあるコードがホームに電話し、指示を取得し、大混乱を引き起こす可能性があります。

クラウド ネイティブ アプリケーションを保護する方法

幸いなことに、クラウド ネイティブ アプリケーションは攻撃されにくい傾向があります。 しかし、新しいタイプのアーキテクチャとして、新しいセキュリティ上の課題があり、開発者はリスクを軽減するために行動する必要があります。 クラウドネイティブ アプリケーションを保護するためのいくつかのベスト プラクティスを次に示します。

  1. 機能レベルで境界セキュリティを適用する 呼び出し可能な小さなコンポーネントへのアプリケーションの断片化と、さまざまなソース (ストレージ、メッセージ キュー、データベースなど) からのイベント ベースのトリガーの使用は、攻撃者のターゲットが増え、攻撃が増えることを意味します。ベクトル。

    Web API およびアプリケーション保護 (WAAP)サービスが次世代の要件に対応できるように進化していることを確認することに加えて、もう 1 つのクラウド ネイティブ セキュリティのベスト プラクティスは、機能レベルでも境界セキュリティを適用することです。 異なるソースタイプによってトリガーされる関数には特に注意してください。

  2. 各機能に適した最小限のロールを作成する クラウド ネイティブ リソース間の多くの対話に対してロールを確立する必要があります。 各サーバーレス機能に固有の権限セットを割り当てる機能は、AppSecをさらに強化する絶好の機会を提供します。

    関数の粒度でIAMを実行すると、 IAM はAppSecツールになります。 各機能に適した最小限の役割の作成に時間を費やします。 さらに、各関数が実行可能な最小の特権セットで実行されるようにして、すり抜けるホールによる損害を最小限に抑えるようにします。

  3. アプリケーションの依存関係を保護する関数には、npm (Node.js) から取り込まれた依存関係が含まれることがよくあります。 PyPI (Python)、Maven (Java)、またはその他の関連するリポジトリ。 アプリケーションの依存関係を保護するには、適切なデータベースと、開発中にアプリケーションのセキュリティをトリガーするネイティブ オーケストレーション ツールなどの自動化ツールへのアクセスが必要です。 これらのツールを継続的に実行することで、新しい脆弱なパッケージが使用されるのを防ぎ、新たに公開された問題に対してアラートを受け取ります。
  4. セキュリティをすべての人の問題にする

    開発者、DevOps、AppSec チームの間で緊密なパートナーシップを築きます。 開発者がセキュリティを所有していないが、責任が免除されないというバランスを見つけてください – 例として、安全なコーディング。 OpenStack Foundation の COO である Mark Collier 氏の発言がブルームバーグの記事で引用されました。「モノリシック/ウォーターフォールからアジャイル/DevOps への移行は、どのテクノロジーを採用するかというよりも、プロセスと組織心理の問題です。

    これは数年前から話題になっており、すぐになくなることはありません。 これは企業が取り組まなければならない大きな問題であり、哲学の世代交代であるため、そこに到達するには何年もかかるでしょう。」

    クラウド ネイティブでは組織のセキュリティと開発の管理方法に異なるアプローチが必要となるため、企業 DNA の通常の動作に反していると感じたとしても、チームが早期にギャップを埋めることが重要です。 これにより、各部門がこの変化を促進し、真の影響を与える真の機会が生まれます。

 

チェック・ポイントでクラウドネイティブアプリケーションをセキュアに

運用部門は、開発者がサーバーレスの速度で作業しながら、現実的かつ安全な方法でアプリケーションをデプロイできるパイプラインを作成する必要があります。

これらはセキュリティに関する多くの項目のうちのほんの一部であり、クラウド ネイティブ アプリケーションやマイクロサーバーに移行するときに考慮する必要があります。 この移行を最適化し、可視性、可観測性、セキュリティ、仮想対策を強化するために、新しいツールが毎日設計されています。 クラウド ネイティブ セキュリティへの対応方法の詳細については、チェック・ポイント ソフトウェアのクラウド セキュリティ ソリューションガイドを参照してください。

×
  Feedback
このWebサイトでは、機能、分析、およびマーケティング上の目的でCookieを使用しています。本Webサイトの使用を継続した場合、Cookieの使用に同意したことになります。詳細については、Cookieについてのお知らせをご覧ください。
OK