Cloud Security Alliance「セキュアなサーバーレスアーキテクチャの設計手法」(2021年9月14日発行) 1. イントロダクション 2. サーバーレスとは何か 3. なぜサーバーレスか 4. ユースケースと事例 5. サーバーレスのセキュリティ脅威モデル 6. セキュリティの設計、コントロール、ベストプラクティス 7. サーバーレスセキュリティの未来展望 8. 結論 9. 参考文献

1. Cloud Security Alliance
Application Containers and Microservices WG
セキュアなサーバーレスアーキテクチャ
設計手法の概説 (v0)

2. 2

3. 3
2. Cloud Security Alliance「セキュアなサーバーレスアー
キテクチャの設計手法」(2021年9月14日発行)
 1. イントロダクション
 2. サーバーレスとは何か
 3. なぜサーバーレスか
 4. ユースケースと事例
 5. サーバーレスのセキュリティ脅威モデル
 6. セキュリティの設計、コントロール、ベストプラクティス
 7. サーバーレスセキュリティの未来展望
 8. 結論
 9. 参考文献
出典：Cloud Security Alliance Serverless WG「 How to Design a Secure Serverless Architecture」（2021年9月14日）
（https://cloudsecurityalliance.org/artifacts/serverless-computing-security-in-2021/）

4. 4
1. イントロダクション
 目的：セキュアなサーバーレスソリューションを展開するためのベストプラクティ
スおよび提言の提供
• 2つのプレイヤー
• サービス／プラットフォームプロバイダー：サーバーレスアプリ
ケーションを構築するサーバーレスプラットフォームの提供者
• アプリケーションオーナー：プラットフォーム上で、稼働するアプ
リケーションのあるサーバーレスソリューションのユーザー
 対象読者：アプリケーション開発者、アプリケーションアーキテクト、
セキュリティ専門家、最高情報セキュリティ責任者（CISO)、リスク
管理専門家、システム／セキュリティ管理者、セキュリティプログラム
管理者、情報システムセキュリティ責任者 など

5. 5
2. サーバーレスとは何か(1)
 サーバーレスコンピューティングの定義
• アプリケーションオーナーのワークロードを提供するのに必要な、計算処理
／インフラストラクチャリソースを割り当てる責任がクラウドプロバイダーに
あるクラウドコンピューティングモデル（“Pay as you go”）
• サーバーレスを利用するアプリケーションオーナーは、展開する必要がある
「呼び出し可能なユニット」および呼び出し可能なユニットを展開する必要
がある一連の「イベント」を、サービスプロバイダーに提供する
 呼び出し可能なユニット
• サービスプロバイダーによりサポートされるランタイムの1つの下で、アプリ
ケーションオーナーがファンクションコードを提供できるようにする
• アプリケーションオーナーが、呼び出し可能なユニットとして機能するコント
ロールのコンテナイメージを提供できるようにする（FaaSの拡張）
 イベント
• トリガーとなる特定のファンクションを引き起こす可能性があるサーバーレス

6. 6
2. サーバーレスとは何か(2)
 サーバーレスセキュリティの概要
出典：Cloud Security Alliance Serverless WG「 How to Design a Secure Serverless Architecture」（2021年9月14日）
（https://cloudsecurityalliance.org/artifacts/serverless-computing-security-in-2021/）

7. 7
2. サーバーレスとは何か(3)
 ファンクションベースのサーバーレス責任共有モデル
出典：Cloud Security Alliance Serverless WG「 How to Design a Secure Serverless Architecture」（2021年9月14日）
（https://cloudsecurityalliance.org/artifacts/serverless-computing-security-in-2021/）

8. 8
2. サーバーレスとは何か(2)
 イメージベースのサーバーレス責任共有モデル
出典：Cloud Security Alliance Serverless WG「 How to Design a Secure Serverless Architecture」（2021年9月14日）
（https://cloudsecurityalliance.org/artifacts/serverless-computing-security-in-2021/）

9. 9
3. なぜサーバーレスか(1)
 3.1 サーバーレスアーキテクチャの優位性と利点
サーバーレスの利点 ポイント
展開のスピード サーバーレスにより、アプリケーションオーナーは、アプリケーションのインフラストラクチャを気にすることなく、ビジネスアプリケーション
を開発することが可能になり、企業が早いペースでアプリケーションを構築・展開できるようになる。従って、よい実験ツールとなり、市
場に迅速に新たな価値をもたらす。
費用 インフラストラクチャ費用：
・エベントベースの課金（通常）により、インフラストラクチャを使用していない時支払う必要はない。
・バーストワークロードで非常に費用対効果がよい – 必要でない時にサーバーを維持する必要はなく、使用するリソースの非常に
細かい粒度とコントロールをを提供できる。
運用費用：
・管理するインフラストラクチャを持たないことにより、維持のための運用費用と時間を削減できる。
アプリケーション
オーナーの体験
展開しやすい：
・ソースコントロールまたは簡単なアプリケーションプログラミングインターフェイス（API)から、CLIツールによる最小限の構成で、
サーバーレスサービスを簡単に展開できる
モニタリングしやすい：
・大抵のクラウドプロバイダーが、サーバーレスファンクションとバンドル化した、すぐに使えるロギング／モニタリングソリューションを提
供する。プラットフォームはAPI駆動型で、アプリケーションオーナーの生産性にとって重要である
サーバー管理のオーバーヘッドがない：
・サーバーレスサービスは、パッチ当て、プロビジョニング、キャパシティ管理、OSメンテナンスなど、すべてのサーバー管理の仕事を吸
収する
スケール 生来拡張性がある
・インフラストラクチャを設定する必要なく、インフラストラクチャを構成することによって、使用に基づいた細かい粒度により、サーバー
レスがオートスケールする。
・ワークロードをスケールアップまたはダウンするためのポリシーを構成する必要はない。
・オンプレミスで稼働する時、スケーリングは、可用性のあるインフラストラクチャに制限される。

10. 10
3. なぜサーバーレスか(2)
 3.2 サーバーレスの責任共有モデル
サービス アプリケーションオーナー サーバーレスプラットフォーム
プロバイダー
プラットフォームのパッチ当て イメージ／ファンクションベースの
サーバーレス
プラットフォームの構成 アプリケーションに関連するアプリケー
ションとプラットフォームの構成
アプリケーションオーナーに対する
最小限の構成の公開
イメージのパッチ当て コンテナイメージベースのサーバーレス ファンクションベースの
サーバーレス
セキュアコーディングのプラクティス イメージ／ファンクションベースの
サーバーレス
サプライチェーンセキュリティ アプリケーション／コンポーネントベース
のサプライチェーン
プラットフォームのサプライチェーン
ネットワークセキュリティのモニタリング イメージ／ファンクションベースの
サーバーレス
CI／CDパイプライン構成 イメージ／ファンクションベースの
サーバーレス

11. 11
3. なぜサーバーレスか(3)
 3.3 サーバーレスが適切な時
• 比較的大規模なアプリケーションまたはアプリケーションの設定で、それら
のサポートのために、成熟したソフトウェア開発および運用（DevOps）
チームやプロセス、製品が利用可能な場合
• アプリケーションは、マイクロサービスという小さいコンポーネントに分割
することができる
 特定のファンクション部分に集中することにより、開発リソースのより
有効な利用が可能になる
• 比較的小規模なアプリケーションまたはチームの場合、従来型インフラスト
ラクチャでアプリケーションをサポートする（IaaS、PaaS）よりも、費用
対効果が低くなる可能性がある
• サーバーレスアーキテクチャは、ほとんどすべてのケースで、デプロイメントの
プロセスを簡素化するので、サーバーレス利に関する決定を行う際に、ビジ
ネスインパクト分析や費用／便益分析を実行する必要がある

12. 12
4. ユースケースと事例(１)
 1. Webアプリケーション：ユーザーが、既存サービスにアクセスしたり、マイ
ナーアップデートを確認または実行する場所。活動終了後、ファンクションが
削除される可能性がある。サーバーレスファンクションは利用可能だが、不適
切な認証、否認防止など、セキュリティ脅威に取組む必要がある。
 2. データ処理活動は、イベント駆動型であり、データ処理要求が完了すると、
削除される可能性がある。たとえば、仲介口座を介して、顧客向けに1日に
購入されたすべての口座の引き落としまたは株式に関する報告書を引き出す
ように、トリガーが設定される。
 3. データの完全性や機密性、セキュリティの課題について、認証や認可に加
えて、サーバーレスファンクションの一部として、取組む必要がある。
 4. バッチ処理のユースケースにおいて、一連のトリガーが設定可能であり、
データを抽出、操作、処理するためにワークフローが組み込まれる。セキュリ
ティの課題は、低レベルの特権アクセス、データの機密性、ユーザーのプライ
バシーである。

13. 13
4. ユースケースと事例(2)
 5. イベントの取り込みと統合：分析アプリケーションからすべてのイベントを
収集し、イベントをインデックス付けして収録するためのデータベースに供給し
て、特定のトリガーにより報告書作成機能を開始し、ダッシュボード／webイ
ンタフェースに発行する。セキュリティの観点から、このようなケースでは、アク
セス管理と否認防止の課題に取組み、検知に必要なメタデータとともにログ
が生成されることを保証する必要がある。
 6. すでにサーバーレスは、業界内で、セキュリティ検知や自動対応向け、特に
構成ミスに対して警告し、その後の行動をとるために利用されている。
 7. サーバーレスは、イメージの認識や処理に利用可能である。事例としては、
Google VisionやAmazon Rekognitionのサービスがあり、識別に基
づいて画像のインデックス付を行う。
 8. サーバーレスは、アプリケーションとともに利用して、顧客が自分のクレジッ
トカード情報をアップロードし、属性を抽出してトランザクションを処理すること
が可能である

14. 14
4. ユースケースと事例(3)
 9. このようなユースケースでは、データセキュリティ、プライバシー、アイデン
ティティ／アクセス管理に取組まなければならない。
 10. イベントをSaaSプロバイダーにつなぎ、処理するために、トリガーを生成
することが可能なユースケースがある。
 11. CI／CDパイプラインは、ソフトウェア開発を介して、迅速に反復実行す
る能力が必要である。サーバーレスは、これらのプロセスを自動化することがで
きる。コードチェックが、構築と自動再ディプロイの契機となるか、または変更
リクエストが、自動化テスト稼働の契機となって、人間による確認の前に、
コードがよく検証されたことを保証する。自動化が必要な場所ではどこでも、
サーバーレスアプリケーションにより、簡素化または加速させ、ワークフローから
手作業のタスクの削減を容易にする可能性がある。
 12. IoTセンサーがメッセージを入力する産業環境では、メッセージに対応し、
対応時に拡張するために、サーバーレスファンクションの利用が可能なトリガー
に基づいて、メッセージを処理する必要がある。障害に加えて、認証、データ

15. 15
4. ユースケースと事例(4)
 13. ビジネスロジックに基づいて、特定のステップを踏むことを要求するアプリ
ケーションの場合：一連のステップを展開するマイクロサービスのワークロード
のオーケストレーションは、サーバーレスファンクションを利用して展開可能であ
る。オーケストレーションの観点からサーバーレスを利用する場合や、監査容
易性の観点からトリガーとなるイベントがデータ／メタデータを通過する場合、
認証や認可に加えて、障害／可用性、否認防止など、いくつかセキュリティの
懸念点がある。
 14. 休暇期間中の顧客サービスのユースケースで、顧客の問合せ、すなわち
チャットボットに対応する場合、サーバーレスは、ピーク時の需要に対して自動
的に拡張し、チャット終了後ファンクションを削除する機能を提供する
 15. ユーザー認証とデータ保護／プライバシーは、セキュリティの観点から、
依然として取組む必要がある課題である
 16. その他産業で普及しているユースケースとしては、スケジュール化された
時間のバックアップなど、インフラストラクチャを自動化するタスクがある。

16. 16
5. サーバーレスのセキュリティ脅威モデル(1)
 5.1 サーバーレス – セキュリティはまったく新しいボールゲームか？
出典：Cloud Security Alliance Serverless WG「 How to Design a Secure Serverless Architecture」（2021年9月14日）
（https://cloudsecurityalliance.org/artifacts/serverless-computing-security-in-2021/）

17. 17
5. サーバーレスのセキュリティ脅威モデル(2)
 5.2 サーバーレス脅威の概要
5.2.1 主要な脅威領域
1. アプリケーションオーナーの
セットアップフェーズの脅威
2. アプリケーションオーナーの
デプロイメントフェーズの脅威
3. サービスプロバイダーの行為
による脅威
出典：Cloud Security Alliance Serverless WG「 How to Design a Secure Serverless Architecture」（2021年9月14日）
（https://cloudsecurityalliance.org/artifacts/serverless-computing-security-in-2021/）

18. 18
5. サーバーレスのセキュリティ脅威モデル(3)
 5.2.2 アプリケーションオーナーのセットアップフェーズの脅威
• アクセス許可または構成ミスに起因する脅威
 幅広く包括的な許可
 幅広く包括的なイベントへのアクセス
 サーバーレスコントロールに渡る幅広いユーザー特権
 弱い構成
• CI／CDパイプラインまたは依存関係における配布パイプライン関連の
脅威
 利用可能なレポジトリとベースイメージのレジストリ
 構築／デプロイメントツールに対する／介した攻撃
 脆弱な依存関係
 脆弱なベースイメージ
• 構成ミスに起因するサービスセットアップ関連の脅威
 関連するクラウドサービスの構成ミスまたは脆弱性

19. 19
5. サーバーレスのセキュリティ脅威モデル(4)
 5.2.3 アプリケーションオーナーのデプロイメントフェーズの脅威
• 呼び出し可能なユニットの設計・展開に起因するランタイム関連の脅威
 データ注入
 グローバルコンテクストの漏えい
 不適切なエラー＆例外処理
 不完全またはセキュアでない認証
• サーバーレスの使った分だけ支払という性質に関連する脅威:
 財務面およびリソースの消耗（リソースの制限が設定された場合）
 リソース過多と意図しなかった出費
• サーバーレスの利用とともに悪化するアプリケーションオーナーのデプロイメ
ントフェーズの脅威：
 セキュアでない秘密管理
 セキュアでないロギング／モニタリング
 ログやメタデータにおける機微データ

20. 20
5. サーバーレスのセキュリティ脅威モデル(5)
 5.2.4 サービスプロバイダーの行為の脅威
• アプリケーションオーナーが消費するサービスプロバイダーのサービスに関連
した一連の脅威
 サービスプロバイダーおよびその依存関係者や個人およびその他の資
産で、サーバーレスまたはその関連サービスを構築するために利用され
るスタック全体など
• 脅威の例：
 脆弱性／悪意のあるサービスのべースイメージ
 脆弱性のあるサービスのランタイム
 呼び出し可能性のあるユニットの呼び出し間における漏えい
 異なる呼び出し可能性のあるユニット間における漏えい
 サーバーレスサービスの正当性
 API／ポータル／コンソールの脆弱性

21. 21
5. サーバーレスのセキュリティ脅威モデル(6)
 5.3 脅威モデル – アプリケーションオーナー向けの25の脅威モデル
• A. アプリケーションオーナーのセットアップフェーズの脅威(1)

サーバーレス固有
1 幅広く包括的な許可：呼び出し可能なユニット
向けの特権最小化原則を維持していない
アプリケーションオーナーは、個々のサーバーレスの呼び出し可能なユニットが稼働する間に有する
特権設定を明確化する場合がある。過度の特権は、攻撃の一部として利用される可能性がある。
2 幅広く包括的なイベントへのアクセス：呼び出し
可能なユニットの引き金となるイベント生成向け
の特権最小化原則を維持していない
アプリケーションオーナーは、誰が、呼び出し可能なユニットの引き金となるイベントを生成する可
能性があるかを明確化する場合がある。幅広いアクセスは、攻撃の展開を大いに簡素化する。特
にイベント駆動型のサーバーレスアーキテクチャにおいて、これは攻撃対象領域に影響を及ぼす。
3 サーバーレスコントロールに渡る幅広いユーザー
特権：DevOpsチーム向けの特権最小化原則
を維持していない
アプリケーションオーナーは、サーバーレスのサービス、イメージ保存などを設定するために、誰がア
クセスする可能性があるかを明確化する場合がある。幅広いアクセスは、攻撃者向けの潜在的な
経路を追加し、インサイダーからのリスクを拡大させる。
4 弱い構成：サーバーレス構成の管理ミスや構成
ドリフトは、プラットフォームや常駐アプリケーショ
ンを脆弱な状態にすることができる
サーバーレスアプリケーションのホスティング向けサービスの多くは、セキュアでないまま構成されて
いる。特定の構成パラメーターは、アプリケーションのセキュリティポスチャ全体に重要な意味を
持っており、注意を払う必要がある – たとえば、誰がファンクションを展開する役割を想定できる
のか、この想定された役割に基づいて、自分に何がでくるのか など
5 関連するクラウドサービスの構成ミスまた
は脆弱性：ワークロードを構築するために、
サーバーレスサービスと協調して稼働する
追加的なクラウドサービスは構成ミスが起
きたり、脆弱な状態になる可能性がある
しばしば呼び出し可能なユニットのセキュリティは、利用する関連クラウドサービスのセキュリティに
依存する。たとえば、呼び出し可能なユニットは、秘密サービスのセキュリティや、アイデンティティ
／アクセス管理システムなどのセキュリティに依存する可能性がある。また呼び出し可能なユニット
は、第三者がサプライチェーンの一部として有するサービスに依存する可能性がある。従って、他
のサービスへの依存や、サーバーレスアプリケーションの一部として、リソースが利用されるサービス
の構成ミスが、サーバーレスファンクションの完全性に影響を及ぼし得る。

22. 22
5. サーバーレスのセキュリティ脅威モデル(7)
• A. アプリケーションオーナーのセットアップフェーズの脅威(2)
サーバーレスとともに悪化する(1)
6 利用可能なレポジトリとベースイメージのレジスト
リ：ライブラリの依存関係とベースイメージを保
存するために利用されるレポジトリとレジストリの
脆弱性
共有された（パブリック／プライベート）コードのレジストリやイメージのレジストリにお
ける脆弱性を特定することにより、悪意のあるコードを組込む可能性がある。独立した
呼び出し可能なユニットの潜在的、劇的な増加により、サーバーレスにおけるこの脅威
は増大している。
7 構築／デプロイメントツールに対する／介した攻
撃：呼び出し可能なユニットやイベントを構築・デ
プロイするために利用されるCI／CD自動化ツー
ルの脆弱性または構成ミス
CI／CDの取組の一部として、自動化ツールは、呼び出し可能なユニット（トリガーと
なるイベントを含む）を構築・デプロイするためにしばしば利用される。このような自動
化は、呼び出し可能なユニットを保存し、サーバーレスのクラウドサービスを設定するた
め、ツールに昇格権限を提供することを必要とする。攻撃者は、悪意のあるコードを標
的となるアプリケーションに組込むため、またはサーバーレスアプリケーションの更新に関
連したサービス妨害（DoS）を引き起こす手段として、これら昇格権限を利用する。
8 脆弱な依存関係：第三者のライブラリにおける
脆弱性または悪意のあるコードで、呼び出し可能
なユニットは、サプライチェーン攻撃の結果である
可能性がある
アプリケーションオーナーの呼び出し可能なユニットは、しばしば、複数の第三者のライブラリの依
存関係を利用する。このようなライブラリは、既存または新たに発見された脆弱性を含む可能性が
ある。従って、悪意のある貢献者は、このようなライブラリにマルウェアを組込む可能性がある – こ
れは、サーバーレス、マイクロサービスなど、すべてのアプリケーションやサービスに適用される。
9 脆弱なベースイメージ：サーバーレスサービス向け
のイメージを作成するために利用されるベースイ
メージにおける脆弱性
アプリケーションオーナーが、イメージベースのサーバーレスの下でイメージを構築するために利用す
るベースイメージは、プレインストールされた依存関係の中で、既存または新たに発見された様々な
タイプの脆弱性に影響されやすく、またプレインストールされたマルウェアを含む可能性がある。

23. 23
5. サーバーレスのセキュリティ脅威モデル(8)
• B. アプリケーションオーナーのデプロイメントフェーズの脅威(1)
サーバーレス固有(1)
1 データ注入：サーバーレスの呼び出し可能なユニットは、
様々なイベントからの起動中、インプットを受取る - 個々の
イベントは、データ注入からの潜在的脅威を表す
信頼できないインプットが、直接翻訳プログラムへ通過する時、または適切に精査・
検証される前に展開される時、インジェクションフローが発生する。このようなフローは、
しばしば攻撃の一部となる。ほとんどのサーバーレスアーキテクチャは、データインジェ
クション攻撃の潜在的ベクターとして、多数のイベントソースを提供する。イベントデー
タの注入は、ビジネス機能を展開するファンクションのオーケストレーションを破壊し、
サービス拒否（DoS）を引き起こし得る。
2 グローバルコンテクストの漏えい：サーバーレスのグローバル
コンテクストは、たとえば、呼び出し可能なユニットの呼び出
しに渡ってトークンを維持する（例．呼び出しごとに、アイデ
ンティティ管理に対する再認証の必要性を保持する）。グ
ローバルコンテクストは、リクエストの間に機微なデータを漏
えいさせる可能性がある。
ワークロードの他のユーザーが所有するデータを提供するために。様々な呼び出し可
能なユニットの呼び出しがしばしば利用されるので、呼び出し可能なユニットの追加
的なリクエストの間のデータ漏えいは、脅威である。機微データが、コンテナの背後に
残っている可能性があり、後続のファンクションの呼び出しの間に露出する可能性が
ある。将来の機能の呼び出しを攻撃するために、悪意のあるデータが意図的に残さ
れる可能性がある。
3 不適切なエラー＆例外処理：標準的なアプリケーションの
デバッグ機能と比較して、サーバーレスベースのアプリケーショ
ンのクラウドネイティブなデバッグ・オプションの処理には限界
がある（そしてより複雑である）。
不適切なエラー処理は、脆弱性を作り出し、バッファーオーバーフローやサービス拒否
（DoS)攻撃のような悪意のある行為を可能にする。冗長なエラーメッセージは、意
図しない情報の攻撃者への開示の結果となり得る – これは、メタデータやリソースの
露出の観点から、すべてのアプリケーションやサーバーレスに当てはまる。

24. 24
5. サーバーレスのセキュリティ脅威モデル(9)
• B. アプリケーションオーナーのデプロイメントフェーズの脅威(2)
サーバーレス固有(2)
4 不完全またはセキュアでない認証：イベントのソースのアイ
デンティティおよび／またはこのようなイベントを生成するユー
ザー／プロセスのアイデンティティの不適切な認証
しばしば、呼び出し可能なユニットは、送信されるイベントの背後にあるエンティティの
アイデンティティを確認するよう求められる。攻撃者は、利用される認証メカニズムの
脆弱性を探そうとする。
5 財務面およびリソースの消耗：攻撃者が、重大な計画外の
支出を引き起こすメカニズムとしてのサーバーレス
攻撃者は、サーバーレスが、「使った分だけ支払う」サービスであるという事実を利用す
る可能性があり、また、アプリケーションオーナーの呼び出し可能なユニットを呼び出
す偽のイベントを多く作り出したり、そして／または長い処理時間に至るようなイベント
を生成することによって（例．コードまたは依存関係において何らかその他の弱点を
露出することによって）、アプリケーションオーナーに、重大な計画外の支出を強いる
可能性がある。
6 リソース過多：攻撃者が、計算処理リソースの終わりのない
プールに入り込むメカニズムとしてのサーバーレス
攻撃者は、サーバーレスが、無制限のリソースプールとして提供されるという事実を利
用する可能性がある。また、脆弱性があると、攻撃者は、呼び出し可能なユニット向
けに利用可能なコンピューターの過多を悪用するよう動機付けられ、利得のために利
用する可能性がある（例．クリプトマイニングを介して、または何らかの第三者への
攻撃を生成するために）。

25. 25
5. サーバーレスのセキュリティ脅威モデル(10)
• B. アプリケーションオーナーのデプロイメントフェーズの脅威(3)
サーバーレスとともに悪化する
7 不十分でセキュアでないロギング／モニタリング
：セキュリティインシデントの不十分な状況認識とセキュリ
ティ侵害を調査する能力の欠如
不十分なロギングは、迅速に攻撃／侵害に対応する組織の能力を妨害し、フォレン
ジック分析の実行を困難または不可能にする。
8 セキュアでない秘密管理：呼び出し可能なユニットが利用す
る秘密の漏えいは、システムの一部への意図しないアクセス
につながったり、権限昇格を可能にしたりする場合が起こり
得る
きっかけとなることがあった場合、特定のクラウドまたは外部リソースへのアクセスのた
めに、しばしば、呼び出し可能なユニットが要求される。そうするために、呼び出し可
能なユニットは、秘密を得る必要がある場合がある。攻撃者は、秘密がセキュアでな
い状態で保存されている場合や、標準設定の資格情報が使用されている場合、この
ような状況を利用することができる。サーバーレスファンクションのあらゆる他のアプリ
ケーションと同様に、資格情報および秘密の漏えいは、なりすまされたIDやデータの
漏えいにつながり得る。
9 安全でないロギング／モニタリング：ロギングデータが攻撃
者に露出したり、攻撃者がログを削除できるようになる。
セキュアでないロギングにより、攻撃者が自らの攻撃を修復したり、行動履歴を削除
して発見やフォレンジックから逃れることが可能になる場合がある。同時に、ファンク
ションのオーナーは、セキュリティ課題を検知できずに、対応できない場合があり、サー
バーレスアプリケーション全体の完全性に影響が及ぶ。
10 機微なロギング／モニタリング：セキュリティやプライバシーを
暗に示す機微情報のロビング／モニタリング
呼び出し可能なユニットやイベントは、ロギングやモニタリングのシステムを介して、秘
密、個人識別情報（PII）、ユーザーデータなど、機微データを露出させる可能性が
ある。

26. 26
5. サーバーレスのセキュリティ脅威モデル(11)
• C. サービスプロバイダーの行為の脅威(1)
サーバーレス固有(1)
1 脆弱性／悪意のあるサービスのべースイメージ：
ファンクションベースのサーバーレスの下で、サービ
スプロバイダーが選択したベースイメージに脆弱
／マルウェアが含まれる可能性がある。
サービスプロバイダーが利用するイメージには、第三者の依存関係が含まれる。このようなイメージ
は、既存または新たに発見された脆弱性の影響を受けやすく、プレインストールされたマルウェアを含
む可能性がある。サービスプロバイダーが、プラットフォームの基盤となるスタックを管理している点
を考慮すると、これはサーバーレスアプリケーションのセキュリティポスチャに影響を及ぼし得る。
2 脆弱性のあるサービスのランタイム：ファンクショ
ンベースのサーバーレスの下で、ランタイムが構成
されるが、しばしばサービスプロバイダーのコードに
よって拡張され、脆弱性のあるランタイムをもたら
す可能性がある。
ファンクションベースのサーバーレスの下で、サービスを形成し、サービスプロバイダーをモニタリングす
るために、しばしば、追加的なコードにより拡張される。デプロイする際に、展開するコンテナは、サー
ビスプロバイダーにより設定される --- これにより、オープンポートまたはその他のランタイム環境に
統合された管理機能に潜在的脆弱性が生まれる可能性がある。従って、サーバーレスアプリケー
ションのセキュリティコントロールがすべての文脈で評価されることが適切である。
3 呼び出し可能性のあるユニットの呼び出し間にお
ける漏えい：所与の呼び出し可能なユニットの呼
び出し間の分離によるサーバーレスサービスの脆
弱性が、規定されたサーバーレスサービス契約外
で破られる。
呼び出し可能なユニットの異なる呼び出しが、しばしば、複数のワークロードのユーザーにより所有
されるデータに機能するため、呼び出し間のデータ漏えいが重大な脅威となる。
たとえば、異なるエンドユーザーまたはセッションのコンテキストに提供するために再利用される呼び
出し可能なユニットが、以前のユーザーにとって機微なデータを置き去りにして漏えいさせる可能性
がある。他方、目的を持って、悪意のあるデータ／状態を置き去りにすると、その後のユーザーに危
害を及ぼす可能性がある。
4 異なる呼び出し可能性のあるユニット間における
漏えい：呼び出し可能なユニットの呼び出し間の
分離によるサーバーレスサービスの脆弱性は、同
一ランタイム環境の頂点で展開され、インスタンス
が順々に破られる。
他の呼び出し可能なユニットは、異なるクラウドやデータへのアクセス権限を有しているため、異なる
IDや秘密を維持し、露出する可能性のある様々な脆弱性を有している。従って、異なる読み出し
可能なユニット間の漏えいは、重大な脅威となる。
たとえば、1つの読み出し可能なユニットを提供し、それから（同じ／異なるアプリケーションオー
ナーの）他のユニットを提供するために、サーバーレス展開環境が再利用される場合、機微データ
が置き去りになる、または悪意のあるデータ／状態を意図的に置き去りにする可能性があり、その
後のユーザーに危害を及ぼしたり、後の特権、IDや秘密を利用したり、後の呼び出し可能なユニッ
トの脆弱性を悪用したりすることがある。

27. 27
5. サーバーレスのセキュリティ脅威モデル(12)
• C. サービスプロバイダーの行為の脅威(2)
サーバーレス固有(2)
5 サーバーレスサービスの正当性：サーバーレスの
下で、ワークロードは、サービスプロバイダーに密
着したアプリケーションオーナーのコードの断片か
ら組み合わされている。サーバーレスのコアサービ
スの正当性は、従って、ワークロードの正当性に
直接影響を及ぼす。
サーバーレス以外のマイクロサービスのクラウドサービスと違って、ワークロードのセキュリティは、サー
ビスプロバイダーのイベントシステムや、イメージ管理、呼び出し可能なユニットの稼働するインスタ
ンスのアクセスコントロールの正当性に依存する。これらのシステムの脅威は、特定の条件下でダウ
ンして、攻撃者への扉を開けることである（例．誤ったイベントを送信し、不適切なファンクションや
コンポーネントを生成し、誤った特権を付与するなど）。認証や認可に加えて、展開前における重要
なイベントのファンクションと検証のオーケストレーションが必要不可欠となる。
6 API／ポータル／コンソールの脆弱性：脆弱性
のあるAPIは、web-APIを利用するか、コマンド
ラインインターフェース（CLI)を動かすか、web
インターフェースを動かすか、いずれの場合でも、
ユーザーが遠隔でサーバーレスプラットフォームを
構成・管理することを可能にする。
管理ポータルまたはコンソールの場合、複数レベルのプラットフォームへの不正アクセスに至る可能
性があり、構成を修正（そして弱体化）し、その環境上で偵察活動を実行するもたらすことになる。
他のアプリケーションは、APIを介して、サーバーレスアプリケーションを呼び出す可能性がある。
サーバーレスファンクションの一部として、追加的リソースやサービスに対する呼び出しが実行される
可能性がある；従って、セキュアなAPIや、そのインプットおよびアウトプット、コンテクストは、サー
バーレスファンクションのセキュリティ全体にとって重要である。

28. 28
5. サーバーレスのセキュリティ脅威モデル(13)
 5.4 サーバーレス脅威の固有性
• 5.4.1 アプリケーションオーナーのセットアップフェーズの脅威
 断片化の観点
• 5.4.2 アプリケーションオーナーのデプロイメントフェーズの脅威
 データ注入の観点
 グローバルコンテクストの観点
 計算処理リソースの割当に関するコントロール喪失の観点
 断片化によりもたらされた複雑性の観点
 コードの堅牢性と正当性の観点
• 5.4.3 サービスプロバイダーの行為の脅威
 分離の観点
 責任共有の観点

29. 29
6. セキュリティの設計、コントロール、ベストプラクティス(1)
 6.1 サーバーレス向け設計の考慮事項(1)
サーバーレスのメリット
1. ステートレスとエフェメラル：短命なサーバーレスのファンクションは、短時間にメモリで
暗号化されていないデータを処理している。サーバーレスファンクションは、ローカルディ
スクに書込みしない。従って、状態を永続化する必要があるファンクションは、外部デー
タストアに依存するので、長命な標的のために設計された攻撃による悪用の可能性を
低減する。
2. 個々のサーバーレスファンクションは、マイクロサービスを実行するために、データのサブ
セットのみを必要とする。このファンクションが、必要なデータのみにアクセスするために
正しいパーミッションを有する限り、ファンクションの利用に成功するためには、どのデー
タなら、密かに撤退することができるかに、より焦点を当てるべきである。
3. サーバーレスアプリケーションは、CSPが管理するコンテナ内または自己管理下のコンテ
ナ内で稼働する。従って、不変のコンテナイメージ上で稼働するコンテナには、固有のセ
キュリティ上のベネフィットがある。長命のサーバーを必要としないコンテナは、簡単かつ
継続的に割当てることができ、コンテナイメージにパッチを当て、インスタンスを計算処
理する。脆弱性のあるまたはパッチ当てされていない、基礎的なインフラストラクチャ上
で稼働するという懸念を低減する。

30. 30
6. セキュリティの設計、コントロール、ベストプラクティス(2)
 6.1 サーバーレス向け設計の考慮事項(2)
サーバーレスのデメリット
1. ベンダーロックイン：ファンクションは、他のサービスプロバイダー環境と互
換性のない、他のクラウドサービスを利用している可能性があり、統合が
CSP環境上の様々なサービスや依存関係に渡る可能性がある（例．
バックエンドデータベースが、RDSやMS SQL Azure上にある可能性が
ある）
2. デプロイメントツールの限界と展開環境の限界：アプリケーションのニー
ズに基づき、必要なツールおよび展開環境を理解し、これらのニーズに基
づき、プロバイダーを選定することが適切である。また、サービスのファンク
ション全体に影響を及ぼす可能性がある潜在的な限界を調査することが
重要である。

31. 31
6. セキュリティの設計、コントロール、ベストプラクティス(3)
 6.1.1 サーバーレスプラットフォーム設計のサーバーレス・マイクロサービスセ
キュリティへの影響(1)
課題点
1. VPC内に展開されたすべてのファンクションは、特にデータの重要性が要求する
場合、公への露出を最小化しているか？
2. 個々のファンクションのために構築したすべてのロールは、要求される特権を最
小化できるように調整されているか？
3. 開発者は、前から存在するロールを再利用したことによって、データ読取り専用
の必要があるファンクションが、データの値を処理・更新するために必要なもの
と同じロールを利用しているか？
4. アプリケーションの再設計が今、HTTPイベントの代わりに、イベントキューに
よって、ファンクションが起動するよう明記しているとする。デプロイメントの選択
肢の1つとして、HTTPイベントのトリガーは除去されたか？
5. HTTPイベントをトリガーとすることができるファンクションがすべて、APIゲート
ウェイの裏側にあるか？

32. 32
6. セキュリティの設計、コントロール、ベストプラクティス(4)
 6.1.1 サーバーレスプラットフォーム設計のサーバーレス・マイクロサービスセ
キュリティへの影響(2)
サーバーレス環境に関する懸念事項
A. 不適切なファンクションのロギング＆モニタリング：
イベント駆動型マイクロサービス／ファンクションの展開環境に、詳細な可視性
を取り入れるためのコントロール
B. セキュアでないサーバーレスのデプロイメント構成：
デフォルト・プラットフォームプロバイダーの構成は、特定のマイクロサービスの
ユースケースに必要なセキュリティのレベルに影響を及ぼし得る
C. セキュアでないアプリケーションの秘密の保存：
アプリケーションの規模や複雑性が拡大するにつれて、アプリケーションの秘密
（API鍵、暗号鍵など）の保存・維持が重要になっている
D. セキュアでない第三者の依存関係の管理：
サーバーレスアプリケーションは、第三者のライブラリに依存している

33. 33
6. セキュリティの設計、コントロール、ベストプラクティス(5)
 6.2 FaaS向けコントロール
a. プラットフォーム構成の監査（コードレビュー、SACT、DAST、ポリシー強制がCI-CDパイプラインの
一部として実行される）
b. プラットフォームのコンポーネントと脆弱性（クラウドプロバイダーは、ネットワークポリシー違反検知や
プラットフォーム層脅威検知・管理とともに、サーバーレスプラットフォーム（ホストOS、コンテナ、オーケ
ストレーションサービス、サービスメッシュなど）のセキュリティの大半に責任があると想定している。これは、
企業がプライベートFaaSの展開を決定した場合、セキュリティコントロールのすべての階層を構築する
必要があることを意味している。
c. ファンクション構成監査（コードレビュー、SAST、DAST、ポリシー強制は、CI-CDコントロールやランタ
イムコントロールの下で、バケットを再現できる）
d. ファンクションコンポーネントと脆弱性（大抵はサーバーレスの脆弱性）はプログラミングに関連する；
インジェクション、破られた認証、アクセスロールの誤用、既知の脆弱性またはセキュアでない秘密の保
存や、セキュアでないデプロイメント設定、不適切な例外処理、不十分なロギング・モニタリングを伴うデ
プロイメントは、OWASPセキュアコーディング・ベストプラクティスの下でバケット化できる。
e. アイデンティティ／アクセス管理（ユーザーとアプリケーションのアイデンティティ管理、連携、SAML 2.0、
アクセスコントロール、多要素認証）
f. ファンクションワークロードセキュリティ – システム完全性のモニタリング、アプリケーション許可リスト、ア
プリケーションのハードニング、マルウェア対策、エクスプロイト防止、検知、対応。

34. 34
6. セキュリティの設計、コントロール、ベストプラクティス(6)
 6.3 CI-CDパイプライン、ファンクションコード、コードスキャン、ファンクション
およびコンテナ向けのポリシー強制
• 静的スキャニング
• 構成テンプレートのスキャン
• ポリシー強制
• 適用される可能性があるファンクションにアクセスするファンクションおよび
サービス向けのアイデンティティ／アクセス管理コントロール
• ゲートウェイとインターフェースのコントロール
• データ保護と、停止時および転送時にデータを保護する暗号化／KMS
サービスとの統合
• ファンクションのオーケストレーションのコントロールと検証
• 検知と対応

35. 35
6. セキュリティの設計、コントロール、ベストプラクティス(7)
 6.4 Delta／コンテナイメージベースのサーバーレス向け追加的コントロール
• 6.4.1 コンテナイメージベースのサーバーレスサービスにアクセスするAPI
アクセスの管理
• 6.4.2 コンテナイメージベースのサーバーレスの構成とポリシー強制
• 6.4.3 ベースイメージ管理とハードニング
• 6.4.4 Kubernetesの構成とサービスメッシュのポリシー強制
• 6.4.5 アクセス管理のコントロール
• 6.4.6 Kubernetesのリスク＆コントロール
• 6.4.7 追加的セキュリティ
 6.5 コンプライアンスとガバナンス
• 6.5.1 サーバーレス向け資産管理
• 6.5.2 サーバーレスガバナンス
• 6.5.3 コンプライアンス

36. 36
7. サーバーレスセキュリティの未来展望
 7.1 サーバーレスの将来のためのFoad
• 7.1.1 コンテナイメージベースのサーバーレスに向けた動き
• 7.1.2 仮想化の変更
• 7.1.3 FaaSの進化
 7.2 サーバーレスセキュリティ
 7.3 データプライバシーのためのサーバーレスの進化