このブログ アドレス: https://security.blog.csdn.net/article/details/129303616
1. 従来のリスク
従来のリスクには、主にインジェクション、機密データの漏えい、クロスサイト スクリプティング、構成エラーなどが含まれます。これらの従来のセキュリティ リスクは、クラウドネイティブ アプリケーションにも存在するため、ここでは詳しく説明しません。
2. クラウド ネイティブ アプリケーション アーキテクチャのリスク
2.1.【機密保持】情報漏えいのリスク
1. アプリケーションの脆弱性による情報漏えい
マイクロサービス アプリケーション アーキテクチャでは、1 つのアプリケーションが複数のサービスに分割され、これらのサービスはビジネスの状況に応じて相互にアクセスします. サービスに API の脆弱性がある場合、攻撃者はアプリケーション内のトラフィックを見ることができます. したがって、データ漏洩のリスクに関しては、マイクロサービス アーキテクチャは従来のモノリシック アプリケーション アーキテクチャよりも大きなリスクをもたらします。また、サービスの数が一定の規模に達すると、API の数が増え続けるため、攻撃対象領域が拡大し、データ漏えいのリスクが高まります。
2. 不正な鍵管理による情報漏えい
アプリケーション開発において、セキュリティ意識の低い開発者は鍵の管理を怠り、データ漏えいのリスクにつながることがよくあります。たとえば、開発者はキー情報やデータベース接続パスワードなどの機密情報をアプリケーションにハードコードするため、アプリケーション ログの漏えいやアプリケーション アクセス キーの漏えいのリスクが高まります。
3. アプリケーション間の非暗号化通信による情報漏えい
マイクロサービス アプリケーション アーキテクチャでは、ネットワーク トポロジは比較的複雑で分散しています. アプリケーション間の通信は、HTTP/HTTPS を使用するだけでなく、gRPC などのプロトコルも使用します. gRPC プロトコルはデフォルトで暗号化されていないため、攻撃対象領域が増加し、データ侵害のリスクが高まります。
2.2、【完全性】不正アクセスリスク
1. アプリケーションの脆弱性による不正アクセス
アプリケーションの脆弱性は、不正アクセスの主な原因です。Redis、MongoDB、Jenkins、Docker、ZooKeeper、Hadoop などの一般的なアプリケーションでは、関連する脆弱性が公開されています。マイクロサービス アプリケーション アーキテクチャの下では、それに含まれるすべてのサービスは、現在のユーザーのアクセス制御権限を明確にするために、それぞれのアクセスを承認する必要があります。さらに、サービス アクセス ソースには、ユーザーに加えて他の内部サービスが含まれるため、マイクロサービス アーキテクチャでは、アプリケーションの認証および承認メカニズムがより複雑になり、クラウド ネイティブ アプリケーションの攻撃対象領域が増えます。
2. アクセス権の設定ミスによる不正アクセス
マイクロサービス アプリケーション アーキテクチャでは、アクセス許可は、サービスへのユーザー アクセス許可だけでなく、サービス間の側面も含むため、許可マッピングの関係がより複雑になり、対応する許可構成の難しさも同時に増加します。たとえば、複雑なアプリケーションが 100 個のサービスに分割されている場合、運用保守担当者は各サービスに適切な権限を付与する必要があります.過失によりサービスに間違った権限が設定されている場合、攻撃者はこの欠陥を利用する可能性があります.サービス。サービスに脆弱性が含まれていた場合、単一の脆弱性がアプリケーション全体に広がる可能性があります。
2.3. [可用性] サービス拒否攻撃のリスク
1. アプリケーションの脆弱性によるサービス拒否
アプリケーションの脆弱性は、ReDoS の脆弱性を例にとると、アプリケーションのサービス拒否攻撃につながる可能性があります。ReDoS は、正規表現のサービス拒否です. 一般に、アプリケーションはユーザーに正規表現の入力タイプを提供しますが、特定の入力を効果的に検証することはできません. その後、攻撃者は非常に解析効率の低い正規表現を入力として構築することができます.短期間の CPU 使用率により、最終的にリソースが枯渇し、アプリケーションがクラッシュすることさえあります。
2. アクセス要件とリソース機能の不一致によるサービス拒否
CC 攻撃を例にとると、通常、攻撃者はボットネット、ボット、またはプロキシ サーバーを制御して、標的のホストに大量の正当なリクエストを継続的に送信し、通常のユーザーのリクエスト処理を非常に遅くするという攻撃原理が一般的です。
3. クラウドネイティブアプリ事業のリスク
3.1. 不正アクセスのリスク
1.業務パラメータ異常による不正アクセス
関連するパラメーターは API 呼び出しプロセス中に渡されることが多く、さまざまなビジネス シナリオに応じてさまざまなパラメーターがさまざまな値の範囲を持ちます。対応するパラメータに対する API の監視メカニズムが完全でない場合、攻撃者は異常なパラメータを入力して業務システムに損害を与える可能性があります。たとえば、製品紹介サービスでのみ製品価格が検証され、注文管理および決済サービスでは検証されていない場合、攻撃者は注文管理および決済サービスの API を直接呼び出して、注文価格を 0 元または A に変更できます。負の値は、ビジネス システムに損害を与えます。
2. ビジネスロジック異常による不正アクセス
一般に、攻撃者が特定の方法を使用して API 呼び出しのロジック シーケンスを異常にするリスクがあります。これには、重要な呼び出し手順の欠落や逆転が含まれます。たとえば、攻撃者はこの脆弱性を利用して、支払い手順をバイパスし、注文を直接送信できます。これにより、主要なビジネス ロジックの手順が失われ、ビジネス システムに損失が生じる可能性があります。たとえば、検証コードのバイパス例外は、一種のビジネス ロジック例外です。
3.2. 異常な営業頻度のリスク
異常なビジネス頻度とは、主に 1 つまたは API のグループへの頻繁な呼び出しを指します。たとえば、ビジネス システムでは、グラフィック認証コードを使用して、ロボットによるスワイプ操作を回避することがよくあります。そして、攻撃者が認証コードに対応するサービスを迂回して注文を直接操作できれば、機械による注文のスワイプを実現し、羊毛を作ることが可能になります。
4. サーバーレスのリスク
4.1. 入力ソースの不確実性
従来のアプリケーション開発では、開発者は自分の実際の経験に基づいて、限られた数の可能性から悪意のある入力のソースを特定できますが、サーバーレス モードでは、イベント ソースによって関数呼び出しがトリガーされ、入力ソースの不確実性が開発を制限します。ジャッジ。For example, when a function subscribes to an event source, the function will betried when this type of event occur. これらのイベントは、FaaS プラットフォームまたは未知のイベント ソースから発生する可能性があります. ソースが不明なイベント ソースは、 untrusted としてマークできます. 実際のアプリケーション シナリオでは、開発者が適切な習慣を身につけず、イベント ソースを分類しないと、信頼されていないイベントを FaaS プラットフォーム イベントと間違えて、信頼できる入力として処理することになり、最終的に危険です。
4.2、サーバーレスアプリケーションのリスク
サーバーレス アプリケーションはクラウド ネイティブ アプリケーションであり、クラウド ネイティブ アプリケーションは従来のアプリケーションから派生したものです. 2 つの唯一の違いは、サーバーレス アプリケーション コードの記述では、クラウド ベンダーが提供する独自のコード テンプレートを参照する必要があることです。この制限があります。したがって、サーバーレス アプリケーションは、従来のアプリケーションが直面するリスクにも直面します。
4.3 サーバーレスプラットフォームのリスク
サーバーレス プラットフォームは、主に FaaS プラットフォームを指します。現在、主流の FaaS プラットフォームは、AWS Lambda、Microsoft Azure Functions、Google Cloud Functions などのパブリック クラウド プロバイダー向けの FaaS プラットフォームと、プライベート クラウド向けの FaaS プラットフォームの 2 種類に分けられます。これらのプロジェクトはオープン ソース プロジェクトであり、すべて Kubernetes での展開をサポートしています。一般的なプロジェクトには、Apache OpenWhisk、Kubeless、OpenFaaS、Fission などがあります。
IaaS プラットフォームで仮想マシンを実行し、PaaS プラットフォームでオペレーティング システムとアプリケーションを実行するのと同様に、各サーバーレス機能は FaaS プラットフォームで実行されます。FaaS プラットフォーム自体が、主にデータ、ストレージ、ネットワーク、コンピューティング、オペレーティング システムなどを含むクラウド環境のセキュリティ管理を担当します。IaaS プラットフォームや PaaS プラットフォームと同様に、FaaS プラットフォームも不正アクセスやデータ漏えいのリスクに直面していますが、サーバーレスも FaaS プラットフォーム アカウントのリスクに直面しています。
1. 不正アクセスリスク
FaaS プラットフォームでは、デプロイされた機能の増加に伴い、機能のリソースへのアクセスと機能の実行をトリガーできるイベントが徐々に増加しており、機能間の権限マッピング関係が複雑になり、通常、機能は短時間で実行されます。そのため、FaaS プラットフォームでのアクセス許可の構成はエラーが発生しやすく、攻撃者はしばしば超特権機能を標的にして、安全でない許可構成を介してリソースへの不正アクセスを取得します。さらに、AWS Lambda などのパブリック クラウド FaaS プラットフォームでは、関数の実行環境の欠陥により、関数のコードに脆弱性 (コマンド インジェクションの脆弱性など) が含まれている場合、攻撃者は関数の実行時の欠陥を悪用し、既知の関数の脆弱性を組み合わせて、プラットフォーム アカウントのリソースへの不正アクセス。
2. データ漏洩のリスク
攻撃者が機能に不正アクセスを開始し、多くの場合、データ漏えいを引き起こします. 同様に、アクセス権の設定ミスもデータ漏えいのリスクを引き起こす可能性があります. また、FaaSプラットフォーム自体の脆弱性も情報漏えいのリスクにつながります。
3. FaaS プラットフォーム アカウントのリスク
ご存知のように、開発者は FaaS プラットフォームで機能を実行するコストを負担する必要があります。一般的に言えば、開発者は FaaS プラットフォーム アカウントを登録し、そのアカウントを銀行カードに関連付け、最後に機能の実行回数に応じてクラウド ベンダーに支払う必要があります.FaaS プラットフォームがアカウント単位の支払い頻度に一定の制限を課していない場合関数に既知の脆弱性が含まれているという前提で、攻撃者は上記の欠陥を利用して FaaS プラットフォーム アカウントを攻撃できます。このタイプの攻撃は、サービス拒否攻撃の一種であるサービス拒否攻撃 (DoW) と総称され、アカウントの請求額を使い果たすことを目的としています。
4.4 サーバーレスが悪用されるリスク
サーバーレスの悪用とは、攻撃者が悪意を持ってサーバーレス機能を構築し、それらを攻撃全体のリンクとして使用することを意味し、セキュリティ デバイスの検出をある程度回避できます。例えば、攻撃者は、被害者のホスト上でトロイの木馬を起動して被害者のホストを制御し、攻撃資産の隠蔽を実現するために、パブリック クラウドのサーバーレス機能をリクエスト転送として使用します。
この攻撃フローは、次の 4 つのステップに分かれています。
1) 被害者のホストでトロイの木馬プログラムが実行され、トロイの木馬が攻撃者のホストに接続を確立するよう要求を開始します。
2) 攻撃者は、被害者ホストと攻撃者ホストの間のトランジット マシンとしてサーバーレス機能を構築します.サーバーレス機能は、トロイの木馬内のオンライン パケットを攻撃者ホストに送信する役割を担います.
3) 攻撃者ホストは、サーバーレス機能からのリクエストを受信し、被害ホストとの接続に成功し、応答に被害ホストを制御するコマンドを添付します。
4) パブリック クラウドのサーバーレス機能が、攻撃者ホストからの応答を受信し、実行コマンドを被害者ホストのトロイの木馬プログラムに送信することで、被害者ホストのリモート操作を実現します。
サーバーレス機能をリクエスト中継として利用することで、被害者はパブリッククラウドのサーバーレス機能との通信しか見えず、攻撃者のホストとの通信は簡単には見えず、パブリッククラウド機能のアクセスドメイン名は通常信頼できるドメイン名であるため、一方では被害者の警戒を緩めることができ、他方では攻撃者のホストの IP を隠して攻撃資産の隠蔽を実現できます。さらに、クラウド ベンダーのサーバーの安定性を利用して、ネットワークの問題による被害者のマシンのオフラインをある程度回避することもできます。