DXで加速するコンテナ／マイクロサービス／サーバーレス導入とセキュリティ
•
2 likes•261 views
グローバル企業の間では、次世代デジタルトランスフォーメーション（DX）基盤として、アプリケーションコンテナやマイクロサービス、サーバーレスを導入する動きが本格化し、境界防御の枠を超えた「ゼロトラスト」に基づくアーキテクチャ構築や、「Docker」による開発フローの自動化、「Kubernetes」による運用管理の標準化、「FaaS（Function as a Service）」による運用負荷の軽減などが進んでいます。本講演では、海外事例を題材に、エンタープライズユーザーが最新のクラウドネイティブ基盤を利用する場合のリスク／セキュリティ管理について概説します。
Report
Share
DXで加速するコンテナ／マイクロサービス／サーバーレス導入とセキュリティ
- 1. @esasahara Cloud Security Alliance Application Containers and Microservices WG DXで加速するコンテナ／ マイクロサービス／サーバーレス導入と セキュリティ
- 2. 2 AGENDA • 1. 普及拡大するクラウドネイティブ技術 • 2. コンテナ／マイクロサービス／サーバーレス利用の ユースケース • 3. コンテナ／マイクロサービス／サーバーレスの セキュリティ脅威と対策 • 4. Q&A
- 3. 3 AGENDA • 1. 普及拡大するクラウドネイティブ技術 • 1-1. アプリケーションコンテナ／マイクロサービスとは？ • 1-2. サーバーレスとは？ • 1-3. ゼロトラストとは？ • 1-4. DevOpsとは？ • 1-5. エッジ／フォグコンピューティングとは?
- 4. 4 1-1.アプリケーションコンテナ／マイクロサービスとは？(1) • 米国立標準技術研究所（NIST） 「SP 800-180(Draft): NIST マイクロサービス、アプリケーションコンテナ、システム仮想 マシンの定義」（2016年2月） • アプリケーションコンテナ: 共有OS上で稼働するアプリケーションまたはそのコンポーネントとして パッケージ化し、稼働するように設計された構成物 • マイクロサービス： アプリケーション・コンポーネントのアーキテクチャを、疎結合のパターンに 分解した結果生まれる基本的要素であり、標準的な通信プロトコルや 明確に定義された API を利用して相互に通信する自己充足型サービス を構成し、いかなるベンダー、製品、技術からも独立している
- 5. 5 1-1.アプリケーションコンテナ／マイクロサービスとは？(2) • クラウドからアプリケーションコンテナ、マイクロサービスへの 移行 APIを軸とする自律サービスの疎結合型アーキテクチャへ IaaS PaaS SaaS OS ミドル ウェア アプリ ケー ション ミドル ウェア アプリ ケー ション アプリケーションコンテナ コンテナ管理 ソフトウェア APIゲートウェイ UI/ UX UI/ UX UI/ UX UI/ UX 処理A 処理B 処理C データ データ データ マイクロサービスクラウドサービス 出典：ヘルスケアクラウド研究会（2016年1月)
- 6. 6 1-２.サーバーレスとは？(1) • CSA 「2020年サーバーレスコンピューティング・セキュリティ」 （2020年12月公開予定） • サーバーレスコンピューティング: クラウドプロバイダーが計算処理のランタイム管理面の負荷を軽減し、 計算処理、ストレージ、ネットワークに関するすべての面を含む、物理的 または仮想的なマシンリソースの割当設定を動的に管理する、クラウド コンピューティング展開モデル。サーバーレスアプリケーションのオーナーは、 このようなタスクを管理する必要はない。 • Amazon: Lambda、Fargate、AWS Batch • Google: Cloud Functions、Knative、Cloud Run • Microsoft: Azure Functions、Azure Container Instances • Nimbella: OpenWhisk • IBM: OpenWhis など
- 7. 7 1-２.サーバーレスとは？(2) ・サーバーレスコンピューティングの責任共有モデル CaaS（Container as a Service） FaaS（Function as a Service） 出典：CSA「Serverless Computing Security in 2020」（in progress）
- 8. 8 1-3.ゼロトラストとは?(1) • 米国立標準技術研究所（NIST）「SP 800-207： ゼロトラスト・アーキテクチャ」（2020年4月19日） • ゼロトラスト（ZT)＝危険に晒されたと見なされるネットワークに直面した 情報システムおよびサービスにおいて、正確な、特権の少ない、あらかじめ 要求されたアクセスに関する意思決定を強制する際に、不確実性を最小化 するように設計された概念やアイデアの集合 • ゼロトラスト・アーキテクチャ（ZTA)＝ゼロトラストの概念を活用して、コン ポーネントの関係、ワークフロー計画、アクセスポリシーを包含した、エンタープ ライズのサイバーセキュリティ計画 • ゼロトラストエンタープライズ：ゼロトラストアーキテクチャ計画のプロダクトと して、エンタープライズに配置されるネットワークインフラストラクチャ（物理的 および仮想的）および業務ポリシー
- 9. 9 1-3.ゼロトラストとは?(2) • ゼロトラストの前提： 物理的／ネットワークのロケーションのみ、または資産の所有権のみに基づく 資産／ユーザーアカウントに対して、絶対の信頼を置かない • 認証／権限付与（認可）： エンタープライズリソースへのセッションを開始する前に実行される分離した 機能 • ゼロトラストはエンタープライズネットワークのトレンドへの対応 • 遠隔ユーザー • 私物端末の業務利用（BYOD：Bring Your Own Device) • 企業所有のネットワーク境界内に存在しないクラウドベースの資産 • ゼロトラストは、ネットワークセグメントではなくリソースの保護に焦点を当てて おり、ネットワークのロケーションはもはやリソースのセキュリティ状態の基本的 要素ではない
- 10. 10 1-3.ゼロトラストとは?(3) • ゼロトラストアーキテクチャの論理的コンポーネント： • コントロールプレーン • データプレーン 出典：NIST「SP 800-207 Zero Trust Architecture」（2020年4月11日）
- 11. 11 1-4.DevOpsとは？(1) • アプリケーションの開発と配備を自動化することにフォーカスした、アプリケー ション開発の新しい方法論であり考え方である • 開発チームと運用チームの間の協力とコミュニケーションを改善してより深く 結びつけることを意味し、特にアプリケーション配備とインフラストラクチャ運用 の自動化に焦点を当てている • コード堅牢化、変更管理、本番アプリケーションのセキュリティを改善するだけ でなくセキュリティ運用全般をも強化してくれる 出典：日本クラウドセキュリティ アライアンス「クラウドコンピュー ティングのためのセキュリティガイ ダンス v4.0」日本語版1.1 （2017年7月） 継続的インテグレーション／ 継続的デプロイ（CI/CD） パイプライン
- 12. 12 1-4.DevOpsとは？(2) • DevOpsのセキュリティへの波及効果 項目 波及効果と長所 標準化 DevOps では、本番に組み込まれるものはすべて、承認済みのコードと設定用テンプレートに基づき、継続的 インテグレーション／継続的デプロイ（CI/CD）パイプラインによって生み出される。開発、テスト、本番（の コード）はすべて完全に 同一のソースファイルから派生しており、周知となっている優れた標準からの逸脱を防 いでいる。 自動化された テスト 広範な種類のセキュリティテストは、必要に応じて補助的に手動 テストを加えることで、CI/CD パイプラインに 組み込むことが可能である。 不可変性(immutable) CI/CD パイプラインは、素早く確実に、仮想マシンやコンテナ、インフラストラクチャスタックのマスターイメージ を生成する。これにより配備の自動化と不可変(immutable)なインフラストラクチャを実現する。 監査と変更管理の改善 CI/CD パイプラインはソースファイルにある 1 文字の変更に至るまでの全て を追跡調査できる。バージョン管 理リポジトリに格納され たアプリケーションスタック（インフラストラクチャを含む）の全履歴と共に、その変更は 変更を行った人物と紐づけられる。 SecDevOps/DevSecO ps と Rugged DevOps SecDevOps/DevSecOps は セキュリティ運用を改善するために DevOps の自動化技術を使う。 Rugged DevOps はアプリケーション開発過程にセキュリティテスティングを組み入れることを意味し、よ り強 固で、よりセキュアで、より障害耐性の高いアプリケーションを生み出す。 出典：日本クラウドセキュリティアライアンス「クラウドコンピューティングのための セキュリティガイダンス v4.0」日本語版1.1（2017年7月）
- 13. 13 1-5.エッジ／フォグコンピューティングとは?(1) • 米国立標準技術研究所（NIST）「SP 500-325：フォグ コンピューティング概念モデル」（2018年3月19日） • エッジコンピューティング＝たとえば、ネットワークにアクセス可能な センサー、メーターまたはその他のデバイス上で、ローカル電算処理 機能を提供するためのスマート・エンドデバイスおよびそのユーザーを 包含するネットワークレイヤ • フォグコンピューティング＝拡張可能な電算処理リソースを共有する 連続体へのユビキタスなアクセスを可能にする階層化モデル • サポートされたアプリケーションから／へのレスポンスタイムを最小 化し、エンドデバイス向けにローカルな電算処理リソースを提供し、 必要な時、集中化されたサービスへのネットワーク接続を提供 する
- 14. 14 1-5.エッジ／フォグコンピューティングとは?(2) • スマート・エンドデバイスのクラウドベース・エコシステムをサポート するフォグコンピューティングの全体イメージ 出典：U.S. National Institute of Standards and Technology (NIST) 「NIST SP 500-325, Fog Computing Conceptual Model」（2018年3月19日） 集中化された クラウドサービス フォグノード （物理的or仮想的） スマート・エンド デバイス
- 15. 15 AGENDA • 2. コンテナ／マイクロサービス／サーバーレス利用の ユースケース • 2-1.インダストリー4.0向けフォグ×コンテナ • 2-2.COVID-19対策向けフォグ×サーバーレス
- 16. 16 2-1.インダストリー4.0向けフォグ×コンテナ(1) • Tim Bayer et al. 「状態監視およびインダストリー4.0配布向け フォグ-クラウドコンピューティング・インフラストラクチャ」 （2019年5月2-4日） Proceedings of the 9th International Conference on Cloud Computing and Services Science, CLOSER 2019, Heraklion, Crete, Greece, May 2-4, 2019 • コンテナ化のアーキテクチャ • インフラストラクチャサービス • Kubernetesマスター • Kubernetesノード • ネットワーク・通信 出典：Tim Bayer et al. 「A Fog-Cloud Computing Infrastructure for Condition Monitoring and Distributing Industry 4.0 Services」（2019年5月2-4日）
- 17. 17 2-1.インダストリー4.0向けフォグ×コンテナ(2) • アーキテクチャの全体像 出典：Tim Bayer et al. 「A Fog-Cloud Computing Infrastructure for Condition Monitoring and Distributing Industry 4.0 Services」（2019年5月2-4日） クラウドノード フォグノード スマート・エンド デバイス
- 18. 18 2-1.インダストリー4.0向けフォグ×コンテナ(3) • 適用事例 出典：Tim Bayer et al. 「A Fog-Cloud Computing Infrastructure for Condition Monitoring and Distributing Industry 4.0 Services」（2019年5月2-4日）
- 19. 19 2-2. COVID-19対策モバイル／フォグコンピューティング(1) ・Md Whaiduzzaman et al.「COVID-19地域感染追跡・予防 向けプライバシー保護モバイル／フォグコンピューティングフレームワーク」 （2020年6月） • システム概要 出典：Md Whaiduzzaman et al.「A Privacy-preserving Mobile and Fog Computing Framework to Trace and Prevent COVID-19 Community Transmission」（2020年6月）
- 20. 20 2-2. COVID-19対策モバイル／フォグコンピューティング(2) • 地域感染追跡・予防向けモバイル／フォグコンピューティングフレームワーク ＜システムコンポーネント＞ 1. モバイルアプリケーション 2. 自動リスクチェッカー (ARC) 3. 疑わしいユーザーデータ・ アップローダー・ノード（SUDUN） 4. クラウド／サーバー ＜システムワークフロー＞ 1. ユーザー登録 2. 鍵生成 3. ローテーション可能な固有暗号化 リファレンスコード（RUERC）の スキャンサービス 4. 受信信号強度インジケーター（RSSI） 5. モバイルデバイスのRUERCストレージ 6. 疑わしいもののフィルタリング 出典：Md Whaiduzzaman et al.「A Privacy-preserving Mobile and Fog Computing Framework to Trace and Prevent COVID-19 Community Transmission」（2020年6月）
- 21. 21 2-2. COVID-19対策モバイル／フォグコンピューティング(3) • AWSに関連する展開の概要 • AWS Lambda (サーバーレスアーキテクチャ） • AWS IoT Greengrass • AWS IoT Core • AWS IoT Device Defender • AWS IoT Device Management • Amazon Simple Queue Service(SQS) • Amazon Relational Database Service (RDS) など 出典：Md Whaiduzzaman et al.「A Privacy-preserving Mobile and Fog Computing Framework to Trace and Prevent COVID-19 Community Transmission」（2020年6月）
- 22. 22 AGENDA • 3.コンテナ／マイクロサービス／サーバーレスの セキュリティ脅威と対策 • 3-1.アプリケーションコンテナのクラウドセキュリティ • 3-2.マイクロサービスのクラウドセキュリティ • 3-3.サーバーレスのクラウドセキュリティ
- 23. 23 3-1.アプリケーションコンテナのクラウドセキュリティ(1) • 米国NIST 「SP 800-190: アプリケーションコンテナ・ セキュリティガイド」（2017年9月） • コンテナ技術アーキテクチャ層と構成要素 出典：NIST 「SP 800-190: Application Container Security Guide」（2017年9月）
- 24. 24 3-1.アプリケーションコンテナのクラウドセキュリティ(2) ・コンテナ技術のコアコンポーネントのリスク(1) コンポーネント リスク イメージ ・イメージの脆弱性 ・イメージ構成の欠陥 ・組込まれたマルウェア ・組込まれた平文の秘密 ・信頼できないイメージの使用 レジストリ ・セキュアでないレジストリへの接続 ・レジストリにおける古いイメージ ・不十分な認証および権限付与の制限 オーケストレーター ・制限のない管理者のアクセス ・不正なアクセス ・分離が不十分なコンテナ内のネットワークトラフィック ・ワークロードの機微度レベルの混在 ・オーケストレーター・ノードの信頼性 出典：NIST 「SP 800-190: Application Container Security Guide」（2017年9月）を基にヘルスケア クラウド研究会作成
- 25. 25 3-1.アプリケーションコンテナのクラウドセキュリティ(3) ・コンテナ技術のコアコンポーネントのリスク(2) 出典：NIST 「SP 800-190: Application Container Security Guide」（2017年9月）を基にヘルスケア クラウド研究会作成 コンポーネント リスク コンテナ ・ランタイム・ソフトウェア内の脆弱性 ・コンテナからの制限のないネットワークアクセス ・セキュアでないコンテナ・ランタイムの構成 ・アプリケーションの脆弱性 ・不正なコンテナ ホストOS ・大規模攻撃の対象領域 ・共有されたカーネル ・ホストOSコンポーネントの脆弱性 ・不適切なユーザーアクセス権限 ・ホストOSのファイルシステムの改ざん
- 26. 26 3-1.アプリケーションコンテナのクラウドセキュリティ(4) • CSA 「クラウドコンピューティングのためのセキュリティ ガイダンスv4.0」（2017年7月） • Domain 8：仮想化とコンテナ技術 • 8.1.4 コンテナ =移植性の高いコード実行環境 [主要コンポーネント] • 実行環境 • 統合管理とスケジューリングのコントローラ • コンテナイメージまたは実行するコードのリポジトリ
- 27. 27 3-1.アプリケーションコンテナのクラウドセキュリティ(5) • コンテナのセキュリティ要件 • 利用するコンテナプラットフォームとその下のOSのセキュリティの ための隔離機能を把握し、適切な設定を選択すること • コンテナ間の隔離の実施には物理マシンまたは仮想マシンを用い、 同一の物理／仮想ホスト上の同一のセキュリティ要件のコンテナ はグループ化すること • 配備対象となるのは、確実に、承認済みで認知済みでセキュアな コンテナのイメージかコードだけとなるようにすること • コンテナの統合化・管理およびスケジューラのソフトウェアの セキュリティを適切に設定すること • 全てのコンテナとリポジトリ管理に対して、適切なロールベースの アクセス管理と、強度の高い認証を実装すること。
- 28. 28 3-1.アプリケーションコンテナのクラウドセキュリティ(6) • CSA 「安全なアプリケーションコンテナアーキテクチャ実装の ためのベストプラクティス」（2020年2月） • アプリケーションコンテナの課題に対するリスク緩和策(1) No. リスク緩和策 1 環境全体（開発、品質保証、テスト、本番）のコードプロモーション 2 ホストをセキュアにする 3 プラットフォーム/ホストからのコンテナ継続性監視 4 コンテナネットワーク - ホストとコンテナ間の通信 5 コンテナ・ネットワーク - コンテナ間通信 6 イメージの完全性とセキュリティレベルの検証 7 コンテナのフォレンジック 8 コンテナによるトラストチェーン 出典：CSA 「安全なアプリケーションコンテナアーキテクチャ実装のためのベストプラクティス」（2020年2月）を基に ヘルスケアクラウド研究会作成
- 29. 29 No. リスク緩和策 9 コンテナのボリューム管理 10 コンテナのシークレット管理 11 プラットフォーム管理 - ライフサイクルイベント通知 12 プラットフォーム管理 - リソース要求 13 プラットフォーム管理 - コンテナリソース管理 14 コンテナ管理 - コンテナリソースのスケーリング 15 コンテナ管理 - データのバックアップとレプリケーション 16 コンテナ管理 – CMP間のコンテナのホスト変更 17 コンテナの暗号化 3-1.アプリケーションコンテナのクラウドセキュリティ(7) • アプリケーションコンテナの課題に対するリスク緩和策(2)
- 30. 30 3-2.マイクロサービスのクラウドセキュリティ(1) • 米国NIST 「SP 800-204: マイクロサービスベースの アプリケーションシステム向けセキュリティ戦略」（2019年8月） • マイクロサービスの設計原則 • 個々のマイクロサービスは、他のマイクロサービスから独立して、管理、 複製、スケーリング、アップグレード、展開される • 個々のマイクロサービスは、単独の機能を有し、制限された環境（例． 制限された責任を有し、他のサービスに依存する）で稼働する • すべてのマイクロサービスは、一定の障害や復旧のために設計されるべき であり、可能な限りステートレスである必要がある • 状況管理のために、既存のトラステッドサービス（例．データベース、 キャッシュ、ディレクトリ）を再利用すべきである
- 31. 31 3-2.マイクロサービスのクラウドセキュリティ(2) • マイクロサービスのコア機能 • 認証とアクセス制御 • サービス・ディスカバリー • セキュリティ監視・分析 • マイクロサービスのAPIゲートウェイ機能 • 最適化されたエンドポイント • リクエストやレスポンスの共有、API変換、プロトコル変換 • サーキットブレーカー（遮断機能） • ロードバランサー（負荷分散） • レート制限 • ブルー／グリーン・デプロイメント（本番環境と別に新たな本番環境を 構築し、切り替える） • カナリア・リリース（一部のユーザーから段階的に導入する）
- 32. 32 3-2.マイクロサービスのクラウドセキュリティ(3) • マイクロサービス運用のアーキテクチャ・フレームワーク アーキテクチャ・フレームワーク アーキテクチャ全体における役割 APIゲートウェイ ・南北（クライアントとアプリケーション間）・東西（マイクロ サービス間）のトラフィックを制御するのに使用される（後者 はマイクロゲートウェイを使用） ・マイクロサービスがweb／アプリケーションサーバーに展開さ れる時、マイクロゲートウェイが導入される サービス・メッシュ ・コンテナを使用してマイクロサービスが展開される時、純粋に 東西のトラフィックのために導入されるが、マイクロサービスが VMまたはアプリケーションサーバーにハウジングされる状況下 で使用することができる 出典：NIST 「SP 800-204: Security Strategies for Microservices-based Application Systems 」（2019年8月）
- 33. 33 3-2.マイクロサービスのクラウドセキュリティ(4) • マイクロサービスの脅威とセキュリティ戦略(1) 脅威 セキュリティ戦略 アイデンティティ／アクセス管理 ・認証（MS-SS-1） ・アクセス管理（MS-SS-2） サービス・ディスカバリーのメカニズム ・サービスレジストリ構成（MS-SS-3） セキュアな通信プロトコル ・セキュアな通信（MS-SS-4） セキュリティモニタリング ・セキュリティモニタリング（MS-SS-5） 遮断機能の展開 ・遮断機能の展開（MS-SS-6） ロードバランシング ・ロードバランシング（MS-SS-7） レート制限 ・レート制限（MS-SS-8） 完全性の保証 ・マイクロサービスの最新版の導入（MS-SS-9） ・セッション維持の取扱（MS-SS-10） ボットネット攻撃への対抗 ・資格情報の悪用やリスト型攻撃の防止（MS-SS-11） マイクロサービスのアーキテクチャ・フレーム ワーク ・APIゲートウェイの展開（MS-SS-12） ・サービス・メッシュの展開（MS-SS-13） 出典：NIST 「SP 800-204: Security Strategies for Microservices-based Application Systems 」（2019年8月）
- 34. 34 3-2.マイクロサービスのクラウドセキュリティ(5) • マイクロサービスの脅威とセキュリティ戦略(2) 脅威 セキュリティ戦略 完全性の保証 ・マイクロサービスの最新版の導入（MS-SS-9） ・セッション維持の取扱（MS-SS-10） ボットネット攻撃への対抗 ・資格情報の悪用やリスト型攻撃の防止（MS-SS-11） マイクロサービスのアーキテクチャ・フレーム ワーク ・APIゲートウェイの展開（MS-SS-12） ・サービス・メッシュの展開（MS-SS-13） 出典：NIST 「SP 800-204: Security Strategies for Microservices-based Application Systems 」（2019年8月）
- 35. 35 3-2.マイクロサービスのクラウドセキュリティ(6) • 米国NIST 「SP 800-204A: サービス・メッシュ・アーキテク チャを利用したセキュアなマイクロサービスベース・アプリケーション の構築」（2020年5月） • なぜサービス・メッシュか？ No. セキュリティ戦略 SM-AR1 サービス・メッシュ・コードをマイクロサービス・アプリケーション・コードに組込んで、サービス・メッシュが、アプリケーション開発 フレームワークで重要な役割を果たすようにすることができる SM-AR2 サービス・メッシュ・コードがライブラリとして展開されると、アプリケーションは、APIコール経由でサービス・メッシュにより提供 されるサービスに結合される SM-AR3 サービス・メッシュ機能は、マイクロサービス・インスタンスの前にデプロイされた各プロキシーとともにプロキシーに展開され、マイ クロサービスベース・アプリケーション向けのインフラストラクチャサービスを集合的に提供する（サイドカー・プロキシー） SM-AR4 サービス・メッシュ機能は、マイクロサービス・インスタンスごとではなく、ノードごとにデプロイされたプロキシー（例．物理的 ホスト）とともにプロキシーに展開される 出典：NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」（2020年5月）
- 36. 36 3-2.マイクロサービスのクラウドセキュリティ(7) ・マイクロサービス・ベース・アプリケーションのセキュリティ 項目 考慮点 認証と権限付与 ・認証／アクセスポリシーは、マイクロサービスが呼び出すAPIの種類に依存する ・証明に基づく認証は、公開鍵インフラストラクチャ（PKI)と鍵管理を要求する サービス・ディスカバリー（サービス リクエストの間にサービスを発見す る機能） ・動的に変わるロケーションを持った各サービスに関連して、相当数のサービスと多くのインスタンスが存在 する ・各マイクロサービスには、仮想マシン（VM)またはコンテナとして展開されたものがあり、動的にIPアドレ スが割り当てられた可能性がある ・サービスに関連するインスタンスの数は、負荷変動によって異なる ネットワーク・レジリエンス 技術を介した可用性の向上 ・ロードバランサー（負荷分散） ・サーキットブレーカー（遮断機能） ・レート制限／調整 ・ブルー／グリーン・デプロイメント（本番環境と別に新たな本番環境を構築し、切り替える） ・カナリア・リリース（一部のユーザーから段階的に導入する） アプリケーション監視の要求事項 ・分散ロギング、メトリクス生成、分析パフォーマンス、追跡を介したマイクロサービスの内外のネットワー クトラフィックのモニタリング 出典：NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」（2020年5月）
- 37. 37 3-3.サーバーレスのクラウドセキュリティ(1) • CSA 「2020年サーバーレスコンピューティング・セキュリティ」 （2020年12月公開予定） • FaaS（Function as a Service）アーキテクチャの概要 出典：CSA「Serverless Computing Security in 2020」（in progress）
- 38. 38 3-3.サーバーレスのクラウドセキュリティ(2) • サーバーレスアプリケーションの脅威 1.環境の構成ミス • a. ユーザーの構成管理ミス • b. ポートの露出 • c. 無効化／デフォルト構成 • d. 資格情報の露出 • e. 構成ドリフト 2.脆弱な依存関係 • a. サプライチェーンの脆弱性 • b. 脆弱なイメージ 3.組込型マルウェア 4.ランタイムの課題 • a. データのインジェクションとリモートからの実行 • b. 認証の不備 • c. 不適切なエラーや例外の処理
- 39. 39 3-3.サーバーレスのクラウドセキュリティ(3) • CaaSプラットフォーム共通の脅威 1.コンテナ化とオーケストレーションの脅威 • a. コンテナ化／オーケストレーションツールの脆弱性 • b. コンテナ化／オーケストレーションAPIの悪用 2.不適切に割り当てられた無制限／管理権限アクセス 3.不正アクセス 4.ポータル／コンソールの脆弱性 • その他の脅威 1.自動デプロイメントツールに対する／経由の攻撃 2.搾取されたコードのレポジトリ 3.搾取されたイメージのレポジトリ 4.不十分／安全でないロギング 5.安全でないシークレット管理 6.リソースの浪費 7.安全でないまたは意図しないデータのキャッシュ