What is Serverless Security?

サーバーレスコンピューティングとは?

サーバーレスコンピューティングとは、クラウドプロバイダーがサーバーを実行し、マシンリソースの割り当てを動的に管理するクラウドコンピューティングモデルを指します。AWS Lambda Functions、Google クラウド Functions、 Azure Functions は、アプリケーションを構築する一般的なサーバーレス フレームワークです。

サーバーレス アーキテクチャには、自動化されたほぼ無限のスケーリングの利点があります。 開発者とデプロイされたコードの間に立ちはだかるものはほとんどないため、市場投入までの時間が短縮され、個々の機能の保守とテストが容易になります。 最後に、実際に消費されるアプリケーションリソースの量は価格に影響するため、使用した分だけ支払うため、コストが削減されます。

サーバーレスは、顧客からクラウドプロバイダーへの責任の追加的な移行を意味します。 インフラストラクチャが関与しないため、運用のオーバーヘッドが大幅に削減されます。

インフラストラクチャ管理をクラウドプロバイダーに移行することで、組織と顧客にサービスを提供するソリューションの開発に集中できます。 これにより、独自の競争上の優位性に集中し続けることができ、多くの場合、コンピューティングだけでなく、人材を開発にシフトすることによるコスト削減にもつながります。

サーバーレスはセキュリティをどのように向上させるのか?

ここでは、いくつかの重要なポイントをご紹介します。

1. クラウドプロバイダーは、オペレーティングシステム、ランタイムセキュリティ、パッチ適用を処理します。 サーバーレス アプリケーションをデプロイする場合、スタックの大部分の制御をクラウド プロバイダーに譲り、クラウド プロバイダーはキー管理などのサービスを提供します。 OS のセキュリティ強化、管理者権限、SSH、セグメンテーションを所有しなくなりました。 AWS、 Microsoft、 Google は、スタックの各部分にパッチを適用し、セキュリティを確保する上で信頼性が高いため、スタックの大部分を提供することで、その点で確実に改善されます。
2. ステートレス/エフェメラル。さらに、サーバーレスコンピューティングの刹那的でステートレスな性質は、攻撃者の生活をより困難にします。 AWS Lambdaのようなサーバーレス関数は、数秒間実行された後、終了します。 容器はリサイクルされます。 サーバーレス関数がメモリを持たずに行ったり来たりするという事実は、長期的な攻撃のリスクを軽減します。
3. サーバーレスアプリケーションの可視化 – 利点サーバーレスアプリケーションがクラウド内の多数の小さな機能として構造化されているという事実は、セキュリティのための素晴らしい機会を提供します。 アプリケーション・セキュリティ・ツールは、アプリケーションの内部フローを監視またはフィルタリングするためだけに、パッケージ化されたアプリケーションを分析およびインストルメント化するために、信じられないほどの時間を費やすことがよくあります。
4. マイクロサービスの小型化 = 各機能に適した最小限のロールを構築できる機能。 小規模なマイクロサービスに移行することで、よりきめ細かなIAMを行うことができます。 これらの小さなことのそれぞれにセキュリティポリシーを適用する機会があり、攻撃対象領域を大幅に減らすことができます。

コンテナ内の関数が S3 から読み取るためにアクセスする必要がある限り、そのコンテナ内のすべての関数にもその権限があります。 AWS Lambdaでは、個々の関数に権限を適用し、そのような権限を必要最小限の範囲に制限することができます。 関数の 1 つに脆弱性がある場合、攻撃者はその関数の限られた機能にのみアクセスでき、コンテナーを付与するための大規模なアクセス許可セットにはアクセスできません。

サーバーレスセキュリティの課題とは?

サーバーレスアプリケーションの構造の変化に伴い、いくつかの新しい課題が生じています。

1. セキュリティの可視化が難しくなります。 サーバーレスになると、情報の総量とリソース数が増加します。 これにより、すべてのデータを理解する能力が妨げられます。 毎日 10 億件のイベントがログに記録されているため、真のオブザーバビリティを実現するために、大量のデータからインテリジェンスを取得することは困難です。
2. プロトコル、ベクトル、および攻撃ポイントはすべての機能に増加しており、プロトコル = 潜在的な攻撃ポイントです。 これには、Google Functions、Azure Functions、AWS Lambdaのセキュリティに対する独自のアプローチが必要です。
3. より多くのリソース = 管理する権限が増えます。 リソースが多いほど、管理する権限も増えるため、これらすべてのインタラクションの権限を決定する際に課題が生じます。 自動化されたテクノロジーは、構成のリスクを検出し、最小特権の関数のアクセス許可を自動的に生成できます。
4. サーバーレスアプリのオブザーバビリティ – 課題。 サーバーレス アプリは、複数のバージョンとリージョンにわたって、さまざまなクラウド プロバイダーのさまざまなサービスを使用します。 攻撃対象領域と潜在的なリスクを理解するには、サーバーレスエコシステム全体を包括的に把握する必要があります。 アプリが普及するにつれて、このセキュリティに重点を置いたビューの構築と保守がますます困難になる可能性があります。

サーバーレスセキュリティをどこに導入するか?

サーバーレスアプリケーションでは、WAF、ファイアウォール、IDSなどの従来のセキュリティを配置する場所がありません。 攻撃者とリソースの間に壁を築くことは、いくつかの理由から簡単ではありません。

1. より速く、より頻繁なデプロイメントは非常に良いことですが、サーバーレスの速度は、セキュリティの構成において新たな課題を引き起こす可能性があります。
2. セキュリティツールでは、処理に時間がかかり、すべてのリクエストに時間を掛ける必要があります。 幸いなことに、ほとんどのサーバーレスセキュリティのベストプラクティスでは、追加の処理時間は必要ありません。
3. 周囲の侵食。 従来のアプリケーションには明確な境界がありました。 外側と内側がはっきりしていて、境界でセキュリティを行うことができました。 警備を周辺だけに残すのは理想的ではありませんが、それでも壁を作ることは可能でした。

サーバーレス アプリケーションは、より多孔質できめ細かいです。 数十または数百の機能で構成されるサーバーレスアプリケーションは、独自のポリシー、ロール、API、監査証跡などを備えた小さなマイクロサービスです。 これにより、攻撃対象領域が変わり、各エントリ ポイントの背後に多くの機能が隠されている少数のエントリ ポイントではなく、より多くのエントリ ポイントが存在し、それぞれが背後にアプリの小さな部分を持つようになります。 アプリケーションを保護するには、各エントリ ポイントについて考える必要があります。

次のようなさまざまなイベントが関数をトリガーできます。

• クラウドストレージイベント(例: AWS S3、Azure Blob Storage、Google クラウド Storage)
• ストリームデータ処理(例: AWS Kinesis)
• データベースの変更(例: AWS DynamoDB、Azure CosmosDB)
• コードの変更 (例: AWS CodeCommit)
• 通知(SMS、メール、IoTなど)

サーバーレスセキュリティの脅威とは?

攻撃者の動機は変わりませんが、サーバーレスアプリケーションで使用する戦術は変更する必要があります。 以下は、この新しいアプリケーションアーキテクチャに固有のサーバーレスセキュリティの脅威の一部です。

1. 過剰な特権を持つ関数の脅威

サーバーレス アプリケーションでは、個々の関数に権限を適用し、そのような権限を必要最小限の範囲に制限することができます。 これにより、攻撃対象領域を大幅に最小化し、攻撃の影響を軽減できます。

残念ながら、チェック・ポイントの最近の調査によると、開発者の大多数はこの機会を活用していないことがわかりました。 当社の調査では、サーバーレスアプリケーションの機能の98%が危険にさらされており、16%が「深刻」と見なされていることがわかりました。 さらに、これらの関数のほとんどは、関数とアプリケーションのセキュリティを向上させるために削除できる必要以上のアクセス許可でプロビジョニングされます。

関数を分析する場合、チェック・ポイントは各関数にリスク・スコアを割り当てます。 これは、発見された姿勢の弱点に基づいており、弱点の性質だけでなく、それが発生する状況も考慮します。 ライブアプリケーションで何万もの関数をスキャンした結果、ほとんどのサーバーレスアプリケーションは、リスクを最小限に抑えるために必要なほど安全にデプロイされていないことがわかりました。 チェック・ポイントが発見した最大のセキュリティ体制の問題は、不要な権限であり、残りは脆弱なコードと構成に関するものです。

2. グラウンドホッグ・デイ・アタック

サーバーレス関数はエフェメラルで有効期間が短いため、攻撃者がアプリケーションに長期間滞在することがより困難になります。 さらに、これはサーバーレスの多くのセキュリティ上の利点の 1 つです。 ただし、攻撃者の生活が困難になるからといって、攻撃を阻止できるわけではありません。彼らは戦略を変えるだけです。

サーバーレス機能の期間が短いということは、サーバーレスセキュリティの脅威が形を変える可能性があることを意味します。 攻撃者は、たとえば、いくつかのクレジット カード番号を盗むだけの、はるかに短い攻撃を構築する可能性があります。 この1ラウンドの攻撃は、私たちが「グラウンドホッグ・デイ」攻撃と呼ぶもので継続的に繰り返されます。

3. 井戸に毒を盛る

クラウドネイティブ リソースの寿命は短いですが、攻撃者はアプリで長期的な永続性を得る方法を見つけることができます。 攻撃者がサーバーレス アプリケーションの一時的な性質を回避する方法の 1 つは、アップストリーム攻撃、つまり "井戸の毒化" です。

クラウドネイティブ・アプリケーションは、さまざまなサードパーティ・ソースからのコードを含む多くのモジュールとライブラリで構成される傾向があります。 攻撃者は、一般的なプロジェクトに悪意のあるコードを含めようとします。 そして、井戸に毒を盛った後、クラウドアプリ内の悪意のあるコードが電話をかけ、指示を得て、大混乱を引き起こす可能性があります。

4. サーバーレスセキュリティ設定に要する時間の増加

これは正確にはセキュリティの「脅威」ではありませんが、サーバーレスアーキテクチャをセキュリティで保護する取り組みに対する課題であり、障害となる可能性があります。

サーバーレスは、アプリケーション開発速度の向上という利点を伝えます。 残念ながら、開発者がコードとパッケージのワークロードを記述し、セキュリティ運用によってそれらのワークロードにセキュリティ制御を適用するという従来のセキュリティアプローチは、サーバーレスでは機能しません。

開発者がセキュリティを待たなければならない場合、ポート、 IAM ロール、またはセキュリティグループを開くと、速度の向上のメリットはすぐに失われます。 多くの場合、解決策は SecOps を方程式から外すことであり、これは確かにリスクになる可能性があります。

一方、無数のサーバーレスリソースとそれらの間の相互作用に対するアクセス許可の構成は、時間のかかる作業です。 さらに、そのセキュリティ構成に開発者の時間を「費やす」ことは、すぐにコストがかかるだけでなく、時間の理想的な使い方にもなりません。 CloudGuard Platformなどの自動化を活用することで、開発者の時間を過度に費やすことなく、サーバーレスのセキュリティを向上させることができます。

5. セキュリティ処理時間の増加

サーバーレスのもう一つの利点は、実際に消費した分だけ支払うことができるため、コストを削減できることです。 それにもかかわらず、使用した分だけ支払うということは、処理時間が長くなるとコストが増加することを意味します。

アプリに過剰なアプリ sec 構成を配置すると、関数に余分な作業が追加され、コストが増加する可能性があります。 セキュリティのために処理時間を追加することは賢明な投資ですが、過度で不必要なコストの増加を避けるためには、適切な実装が必要です。

上記のサーバーレスセキュリティ構成の時間の増加と同様に、これは正確には脅威ではなく、サーバーレスアーキテクチャをセキュリティで保護する際に取り組む必要がある課題です。