アーキテクトが主導するコンテナ／マイクロサービス／サーバーレスのセキュリティ
1 like380 views
デジタルトランスフォーメーション（DX）を契機に、コンテナやマイクロサービス、サーバーレス技術の導入が本格化するとともに、ユーザーとサービスプロバイダーとの間で調整役を担うアーキテクトに注目が集まっています。本講演では、ビジネスニーズに即応するアプリケーション開発（Dev）と、安定的なインフラ運用（Ops）の観点から、アーキテクトがセキュリティ・エコシステムの実装に果たす役割について、事例を交えながら紹介します。
![28
3-1.アプリケーションコンテナのクラウドセキュリティ(4)
• CSA 「クラウドコンピューティングのためのセキュリティ
ガイダンスv4.0」（2017年7月）
• Domain 8：仮想化とコンテナ技術
• 8.1.4 コンテナ
=移植性の高いコード実行環境
[主要コンポーネント]
• 実行環境
• 統合管理とスケジューリングのコントローラ
• コンテナイメージまたは実行するコードのリポジトリ](https://image.slidesharecdn.com/sasaharaitmedia20201210ver0-201127222451/85/-28-320.jpg)
アーキテクトが主導するコンテナ／マイクロサービス／サーバーレスのセキュリティ
- 1. @esasahara Cloud Security Alliance Application Containers and Microservices WG アーキテクトが主導する コンテナ／マイクロサービス／サーバーレス のセキュリティ
- 2. 2 AGENDA • 1. 普及拡大するクラウドネイティブ技術 • 2. コンテナ／マイクロサービス／サーバーレスにおける アーキテクトの役割 • 3. コンテナ／マイクロサービス／サーバーレスの セキュリティ脅威と対策 • 4. Q&A
- 3. 3 AGENDA • 1. 普及拡大するクラウドネイティブ技術 • 1-1. デジタルトランスフォーメーション（DX）とは? • 1-2. ゼロトラストとは？ • 1-3. DevOpsとは？ • 1-4. アプリケーションコンテナ／マイクロサービスとは？ • 1-5. サーバーレスとは？
- 4. 4 1-1.デジタルトランスフォーメーション（DX）とは? • IDCの定義： （https://www.idc.com/itexecutive/research/dx） • デジタルトランスフォーメーション(DX)は、新たな技術を、 劇的に変化するプロセス、顧客エクスペリエンス、そして 価値に適用することを意味する。 • DXは、組織が、既存の技術やモデルを強化するよりも、 イノベーションやデジタルディスラプションを支援するような、 デジタルネイティブエンタープライズとなることを可能にする。
- 5. 5 1-2.ゼロトラストとは?(1) • 米国立標準技術研究所（NIST）「SP 800-207： ゼロトラスト・アーキテクチャ」（2020年4月19日） • ゼロトラスト（ZT)＝危険に晒されたと見なされるネットワークに直面した 情報システムおよびサービスにおいて、正確な、特権の少ない、あらかじめ 要求されたアクセスに関する意思決定を強制する際に、不確実性を最小化 するように設計された概念やアイデアの集合 • ゼロトラスト・アーキテクチャ（ZTA)＝ゼロトラストの概念を活用して、コン ポーネントの関係、ワークフロー計画、アクセスポリシーを包含した、エンタープ ライズのサイバーセキュリティ計画 • ゼロトラストエンタープライズ：ゼロトラストアーキテクチャ計画のプロダクトと して、エンタープライズに配置されるネットワークインフラストラクチャ（物理的 および仮想的）および業務ポリシー
- 6. 6 1-2.ゼロトラストとは?(2) • ゼロトラストの前提： 物理的／ネットワークのロケーションのみ、または資産の所有権のみに基づく 資産／ユーザーアカウントに対して、絶対の信頼を置かない • 認証／権限付与（認可）： エンタープライズリソースへのセッションを開始する前に実行される分離した 機能 • ゼロトラストはエンタープライズネットワークのトレンドへの対応 • 遠隔ユーザー • 私物端末の業務利用（BYOD：Bring Your Own Device) • 企業所有のネットワーク境界内に存在しないクラウドベースの資産 • ゼロトラストは、ネットワークセグメントではなくリソースの保護に焦点を当てて おり、ネットワークのロケーションはもはやリソースのセキュリティ状態の基本的 要素ではない
- 7. 7 1-2.ゼロトラストとは?(3) • ゼロトラストアーキテクチャの論理的コンポーネント： • コントロールプレーン • データプレーン 出典：NIST「SP 800-207 Zero Trust Architecture」（2020年4月11日）
- 8. 8 1-3.DevOpsとは？(1) • アプリケーションの開発と配備を自動化することにフォーカスした、アプリケー ション開発の新しい方法論であり考え方である • 開発チームと運用チームの間の協力とコミュニケーションを改善してより深く 結びつけることを意味し、特にアプリケーション配備とインフラストラクチャ運用 の自動化に焦点を当てている • コード堅牢化、変更管理、本番アプリケーションのセキュリティを改善するだけ でなくセキュリティ運用全般をも強化してくれる 出典：日本クラウドセキュリティ アライアンス「クラウドコンピュー ティングのためのセキュリティガイ ダンス v4.0」日本語版1.1 （2017年7月） 継続的インテグレーション／ 継続的デプロイ（CI/CD） パイプライン
- 9. 9 1-3.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月）
- 10. 10 1-4.アプリケーションコンテナ／マイクロサービスとは？(1) • 米国立標準技術研究所（NIST） 「SP 800-180(Draft): NIST マイクロサービス、アプリケーションコンテナ、システム仮想 マシンの定義」（2016年2月） • アプリケーションコンテナ: 共有OS上で稼働するアプリケーションまたはそのコンポーネントとして パッケージ化し、稼働するように設計された構成物 • マイクロサービス： アプリケーション・コンポーネントのアーキテクチャを、疎結合のパターンに 分解した結果生まれる基本的要素であり、標準的な通信プロトコルや 明確に定義された API を利用して相互に通信する自己充足型サービス を構成し、いかなるベンダー、製品、技術からも独立している
- 11. 11 1-4.アプリケーションコンテナ／マイクロサービスとは？(2) • クラウドからアプリケーションコンテナ、マイクロサービスへの 移行 APIを軸とする自律サービスの疎結合型アーキテクチャへ IaaS PaaS SaaS OS ミドル ウェア アプリ ケー ション ミドル ウェア アプリ ケー ション アプリケーションコンテナ コンテナ管理 ソフトウェア APIゲートウェイ UI/ UX UI/ UX UI/ UX UI/ UX 処理A 処理B 処理C データ データ データ マイクロサービスクラウドサービス 出典：ヘルスケアクラウド研究会（2016年1月)
- 12. 12 1-5.サーバーレスとは？(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 など
- 13. 13 1-5.サーバーレスとは？(2) ・クラウドにおけるサーバーレスの責任共有モデル CaaS（Container as a Service） FaaS（Function as a Service） 出典：CSA「Serverless Computing Security in 2020」（in progress）
- 14. 14 1-5.サーバーレスとは？(3) ・FaaS（Function as a Service）の責任共有モデル 出典：CSA「Serverless Computing Security in 2020」（in progress）
- 15. 15 1-5.サーバーレスとは？(4) ・CaaS（Container as a Service）の責任共有モデル 出典：CSA「Serverless Computing Security in 2020」（in progress）
- 16. 16 AGENDA • 2. コンテナ／マイクロサービス／サーバーレスにおける アーキテクトの役割 • 2-1. クラウド・アーキテクトとは？ • 2-2. コンテナ／マイクロサービスとアーキテクト • 2-3. サーバーレスとアーキテクト
- 17. 17 2-1.クラウド・アーキテクトとは？(1) • Azure Developer Community Blog 「The Cloud-native Azure Application Architect Map」（2019年8月20日） https://techcommunity.microsoft.com/t5/azure-developer-community-blog/the-cloud-native-azure- application-architect-map/ba-p/812242 • データ＆ビッグデータ • 共通デザインパターン： SAGA、サーキットプレーカー、 イベント駆動型アーキテクチャなど • ドメイン駆動設計＆マイクロサービス • 人工知能（AI)、自然言語処理（NLP） 教師あり＆教師なし機械学習（ML)など • その他：アプリケーション開発時、 定期的に戻るもの（リアルタイムhttp、 検索、ジョブスケジューリングなど） Azure Developer Community Blog 「The Cloud-native Azure Application Architect Map」（2019年8月20日）
- 18. 18 2-1.クラウド・アーキテクトとは？(2) • Azure Developer Community Blog 「The Azure Infrastructure Architect Map」（2019年7月21日） https://techcommunity.microsoft.com/t5/azure-developer-community-blog/the-azure-infrastructure- architect-map/ba-p/766268 • 高可用性 • 災害復旧 • モニタリング • バックアップ＆復元 • ネットワーク • Infrastructure as Code（IaC） Azure Developer Community Blog 「The Azure Infrastructure Architect Map」（2019年7月21日）
- 19. 19 2-1.クラウド・アーキテクトとは？(3) • Azure Developer Community Blog 「The Azure Security Architect Map」（2019年6月23日） https://techcommunity.microsoft.com/t5/azure-developer-community-blog/the-azure-security- architect-map/ba-p/714091 • ネットワーク層 • アイデンティティ層 • アプリケーションサービス層 • アプリケーションデータ • セキュリティ体制 • 鍵、認証、シークレット管理、暗号化機能 • モバイルデバイス管理（MDM）＆モバイル アプリケーション管理（MAM) Azure Developer Community Blog 「The Azure Security Architect Map」（2019年6月23日）
- 20. 20 2-2.コンテナ／マイクロサービスとアーキテクト(1) • クラウドセキュリティアライアンス「安全なマイクロサービスアーキテクチャ実装の ためのベストプラクティス」（日本語版：2020年11月17日） • ユースケース例：マイクロサービスへのモノリシック・アプリケーションの分解(1) 視点 課題 開発者 1. アプリケーションの断片化が進むと、開発者はマイクロサービスの可視性が低下し、各コンポーネントが他のコン ポーネントと問題なく動作することを保証するという課題が生じる 2. 相互運用性の確保の観点から、弱いテストケースは、ソフトウェア開発サイクルの後半で可用性とパフォーマン スの問題のリスクを高める可能性がある 3. モノリスの分解の結果、内部ソフトウェアモジュールは、顧客の利用面に向いているもの、プロセス間通信に関連 する内部ユーティリティまたは中間機能であるもの、記録システムまたは参照システムであるデータストアに向い ているものに分類されるが、中にはマイクロサービスの採用を妨げる制約の源となりうるものがある 4. マイクロサービスアーキテクチャアプローチはRESTfulなメソッド駆動型のスタイルであり、すべての状況がアプ ローチに簡単に適合するわけではない（例．SOAPプロトコルバックエンド接続） 5. マイクロサービスのスタイルでは、すべての開発者が「ネットワークプログラミング」の開発者となる 6. 堅牢なマイクロサービステスト、合成データ、および SWAGGER のような API ドキュメンテーションフレーム ワークがないと、予期せぬセキュリティやパフォーマンスの欠陥につながるコードプロモーションのリスクが高まり、 不注意な情報開示まで含めてリスクが高まる可能性がある
- 21. 21 2-2.コンテナ／マイクロサービスとアーキテクト(2) • ユースケース：マイクロサービスへのモノリシック・アプリケーションの分解(2) 視点 課題 運用者 1. 開発プロセスやステージング、本番環境で使用するための実績のあるコードプロモーションシステムがないと、コード プロモーションの遅れが増える可能性がある 2. 選択されたマイクロサービス間の柔軟で安全なネットワーク転送を提供することが課題となる可能性がある 3. コンテナが実行されなくなったときに、マイクロサービスが状態を失わないようにするための設計責任を共有している 4. アプリケーションが断片化すると、マイクロサービスアプリケーションの動作を把握できなくなる可能性がある アーキ テクト 1. マイクロサービスアーキテクチャに再構築し、それらのマイクロサービスを調整することのコストとメリットのバランスを 見つけるとともに、アジャイル開発クルー、クループログラムマネージャーとスクラムマスター、技術チーム、およびビジネス ステークホルダーの間で作業するソフトウェアアーキテクトとして実際に機能しているが、ソリューション、インフラストラク チャ、セキュリティ、データ、ネットワークアーキテクトなど、すべての情報技術アーキテクトがこの役割で機能するわけで はない 出典：クラウドセキュリティアライアンス「安全なマイクロサービスアーキテクチャ実装のためのベストプラクティス」(2020 年11月17日)を基にヘルスケアクラウド研究会作成
- 22. 22 2-2.コンテナ／マイクロサービスとアーキテクト(3) • クラウドセキュリティアライアンス 「Microservices Architecture Pattern」 （2020年12月末公開予定） • マイクロサービス参照アーキテクチャ • アイデンティティ提供 • 検知サービス • 暗号化サービス （鍵＆認証管理） • DevOps／セキュア・ソフトウェア 開発ライフサイクル（CI／CD） • コンテナのレジストリ • APIのレジストリ 出典：CSA「Microservices Architecture Pattern」（in progress）
- 23. 23 2-3.サーバーレスとアーキテクト • AWS Architecture Blog 「10 Things Serverless Architects Should Know」（2019年7月23日） https://aws.amazon.com/jp/blogs/architecture/ten-things-serverless-architects-should-know/ 1. APIとマイクロサービスの設計 2. イベント駆動型アーキテクチャと非同期メッセージングパターン 3. 分散マイクロサービス環境におけるワークフローのオーケストレーション 4. Lambdaコンピューティング環境とプログラミングモデル 5. サーバーレス導入の自動化と継続的インテグレーション（CI)／継続的デプロイ（CD) 6. サーバーレス・アイデンティティ管理、認証、権限付与（認可） 7. エンドツーエンドのセキュリティ技術 8. 包括的なロギング、評価体系、トレーシングを備えたアプリケーションの可観察性 9. アプリケーションが上手く設計されたことの保証 10.サーバーレスコンピューティングが進化し続けるのに合わせた学習の継続
- 24. 24 AGENDA • 3.コンテナ／マイクロサービス／サーバーレスの セキュリティ脅威と対策 • 3-1.アプリケーションコンテナのクラウドセキュリティ • 3-2.マイクロサービスのクラウドセキュリティ • 3-3.サーバーレスのクラウドセキュリティ
- 25. 25 3-1.アプリケーションコンテナのクラウドセキュリティ(1) • 米国NIST 「SP 800-190: アプリケーションコンテナ・ セキュリティガイド」（2017年9月） • コンテナ技術アーキテクチャ層と構成要素 出典：NIST 「SP 800-190: Application Container Security Guide」（2017年9月）
- 26. 26 3-1.アプリケーションコンテナのクラウドセキュリティ(2) ・コンテナ技術のコアコンポーネントのリスク(1) コンポーネント リスク イメージ ・イメージの脆弱性 ・イメージ構成の欠陥 ・組込まれたマルウェア ・組込まれた平文の秘密 ・信頼できないイメージの使用 レジストリ ・セキュアでないレジストリへの接続 ・レジストリにおける古いイメージ ・不十分な認証および権限付与の制限 オーケストレーター ・制限のない管理者のアクセス ・不正なアクセス ・分離が不十分なコンテナ内のネットワークトラフィック ・ワークロードの機微度レベルの混在 ・オーケストレーター・ノードの信頼性 出典：NIST 「SP 800-190: Application Container Security Guide」（2017年9月）を基にヘルスケア クラウド研究会作成
- 27. 27 3-1.アプリケーションコンテナのクラウドセキュリティ(3) ・コンテナ技術のコアコンポーネントのリスク(2) 出典：NIST 「SP 800-190: Application Container Security Guide」（2017年9月）を基にヘルスケア クラウド研究会作成 コンポーネント リスク コンテナ ・ランタイム・ソフトウェア内の脆弱性 ・コンテナからの制限のないネットワークアクセス ・セキュアでないコンテナ・ランタイムの構成 ・アプリケーションの脆弱性 ・不正なコンテナ ホストOS ・大規模攻撃の対象領域 ・共有されたカーネル ・ホストOSコンポーネントの脆弱性 ・不適切なユーザーアクセス権限 ・ホストOSのファイルシステムの改ざん
- 28. 28 3-1.アプリケーションコンテナのクラウドセキュリティ(4) • CSA 「クラウドコンピューティングのためのセキュリティ ガイダンスv4.0」（2017年7月） • Domain 8：仮想化とコンテナ技術 • 8.1.4 コンテナ =移植性の高いコード実行環境 [主要コンポーネント] • 実行環境 • 統合管理とスケジューリングのコントローラ • コンテナイメージまたは実行するコードのリポジトリ
- 29. 29 3-1.アプリケーションコンテナのクラウドセキュリティ(5) • コンテナのセキュリティ要件 • 利用するコンテナプラットフォームとその下のOSのセキュリティの ための隔離機能を把握し、適切な設定を選択すること • コンテナ間の隔離の実施には物理マシンまたは仮想マシンを用い、 同一の物理／仮想ホスト上の同一のセキュリティ要件のコンテナ はグループ化すること • 配備対象となるのは、確実に、承認済みで認知済みでセキュアな コンテナのイメージかコードだけとなるようにすること • コンテナの統合化・管理およびスケジューラのソフトウェアの セキュリティを適切に設定すること • 全てのコンテナとリポジトリ管理に対して、適切なロールベースの アクセス管理と、強度の高い認証を実装すること。
- 30. 30 3-1.アプリケーションコンテナのクラウドセキュリティ(6) • CSA 「安全なアプリケーションコンテナアーキテクチャ実装の ためのベストプラクティス」（2020年2月） • アプリケーションコンテナの課題に対するリスク緩和策(1) No. リスク緩和策 1 環境全体（開発、品質保証、テスト、本番）のコードプロモーション 2 ホストをセキュアにする 3 プラットフォーム/ホストからのコンテナ継続性監視 4 コンテナネットワーク - ホストとコンテナ間の通信 5 コンテナ・ネットワーク - コンテナ間通信 6 イメージの完全性とセキュリティレベルの検証 7 コンテナのフォレンジック 8 コンテナによるトラストチェーン 出典：CSA 「安全なアプリケーションコンテナアーキテクチャ実装のためのベストプラクティス」（2020年2月）を基に ヘルスケアクラウド研究会作成
- 31. 31 No. リスク緩和策 9 コンテナのボリューム管理 10 コンテナのシークレット管理 11 プラットフォーム管理 - ライフサイクルイベント通知 12 プラットフォーム管理 - リソース要求 13 プラットフォーム管理 - コンテナリソース管理 14 コンテナ管理 - コンテナリソースのスケーリング 15 コンテナ管理 - データのバックアップとレプリケーション 16 コンテナ管理 – CMP間のコンテナのホスト変更 17 コンテナの暗号化 3-1.アプリケーションコンテナのクラウドセキュリティ(7) • アプリケーションコンテナの課題に対するリスク緩和策(2)
- 32. 32 3-2.マイクロサービスのクラウドセキュリティ(1) • 米国NIST 「SP 800-204: マイクロサービスベースの アプリケーションシステム向けセキュリティ戦略」（2019年8月） • マイクロサービスの設計原則 • 個々のマイクロサービスは、他のマイクロサービスから独立して、管理、 複製、スケーリング、アップグレード、展開される • 個々のマイクロサービスは、単独の機能を有し、制限された環境（例． 制限された責任を有し、他のサービスに依存する）で稼働する • すべてのマイクロサービスは、一定の障害や復旧のために設計されるべき であり、可能な限りステートレスである必要がある • 状況管理のために、既存のトラステッドサービス（例．データベース、 キャッシュ、ディレクトリ）を再利用すべきである
- 33. 33 3-2.マイクロサービスのクラウドセキュリティ(2) • マイクロサービスのコア機能 • 認証とアクセス制御 • サービス・ディスカバリー • セキュリティ監視・分析 • マイクロサービスのAPIゲートウェイ機能 • 最適化されたエンドポイント • リクエストやレスポンスの共有、API変換、プロトコル変換 • サーキットブレーカー（遮断機能） • ロードバランサー（負荷分散） • レート制限 • ブルー／グリーン・デプロイメント（本番環境と別に新たな本番環境を 構築し、切り替える） • カナリア・リリース（一部のユーザーから段階的に導入する）
- 34. 34 3-2.マイクロサービスのクラウドセキュリティ(3) • マイクロサービス運用のアーキテクチャ・フレームワーク アーキテクチャ・フレームワーク アーキテクチャ全体における役割 APIゲートウェイ ・南北（クライアントとアプリケーション間）・東西（マイクロ サービス間）のトラフィックを制御するのに使用される（後者 はマイクロゲートウェイを使用） ・マイクロサービスがweb／アプリケーションサーバーに展開さ れる時、マイクロゲートウェイが導入される サービス・メッシュ ・コンテナを使用してマイクロサービスが展開される時、純粋に 東西のトラフィックのために導入されるが、マイクロサービスが VMまたはアプリケーションサーバーにハウジングされる状況下 で使用することができる 出典：NIST 「SP 800-204: Security Strategies for Microservices-based Application Systems 」（2019年8月）
- 35. 35 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月）
- 36. 36 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月）
- 37. 37 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月）
- 38. 38 3-2.マイクロサービスのクラウドセキュリティ(7) ・マイクロサービス・ベース・アプリケーションのセキュリティ 項目 考慮点 認証と権限付与 ・認証／アクセスポリシーは、マイクロサービスが呼び出すAPIの種類に依存する ・証明に基づく認証は、公開鍵インフラストラクチャ（PKI)と鍵管理を要求する サービス・ディスカバリー（サービス リクエストの間にサービスを発見す る機能） ・動的に変わるロケーションを持った各サービスに関連して、相当数のサービスと多くのインスタンスが存在 する ・各マイクロサービスには、仮想マシン（VM)またはコンテナとして展開されたものがあり、動的にIPアドレ スが割り当てられた可能性がある ・サービスに関連するインスタンスの数は、負荷変動によって異なる ネットワーク・レジリエンス 技術を介した可用性の向上 ・ロードバランサー（負荷分散） ・サーキットブレーカー（遮断機能） ・レート制限／調整 ・ブルー／グリーン・デプロイメント（本番環境と別に新たな本番環境を構築し、切り替える） ・カナリア・リリース（一部のユーザーから段階的に導入する） アプリケーション監視の要求事項 ・分散ロギング、メトリクス生成、分析パフォーマンス、追跡を介したマイクロサービスの内外のネットワー クトラフィックのモニタリング 出典：NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」（2020年5月）
- 39. 39 3-3.サーバーレスのクラウドセキュリティ(1) • CSA 「2020年サーバーレスコンピューティング・セキュリティ」 （2020年12月公開予定） • FaaS（Function as a Service）アーキテクチャの概要 出典：CSA「Serverless Computing Security in 2020」（in progress）
- 40. 40 3-3.サーバーレスのクラウドセキュリティ(2) • CaaS（Container as a Service）アーキテクチャの概要 出典：CSA「Serverless Computing Security in 2020」（in progress）
- 41. 41 3-3.サーバーレスのクラウドセキュリティ(3) • サーバーレスアプリケーションの脅威 1.環境の構成ミス • a. ユーザーの構成管理ミス • b. ポートの露出 • c. 無効化／デフォルト構成 • d. 資格情報の露出 • e. 構成ドリフト 2.脆弱な依存関係 • a. サプライチェーンの脆弱性 • b. 脆弱なイメージ 3.組込型マルウェア 4.ランタイムの課題 • a. データのインジェクションとリモートからの実行 • b. 認証の不備 • c. 不適切なエラーや例外の処理
- 42. 42 3-3.サーバーレスのクラウドセキュリティ(4) • CaaSプラットフォーム共通の脅威 1.コンテナ化とオーケストレーションの脅威 • a. コンテナ化／オーケストレーションツールの脆弱性 • b. コンテナ化／オーケストレーションAPIの悪用 2.不適切に割り当てられた無制限／管理権限アクセス 3.不正アクセス 4.ポータル／コンソールの脆弱性 • その他の脅威 1.自動デプロイメントツールに対する／経由の攻撃 2.搾取されたコードのレポジトリ 3.搾取されたイメージのレポジトリ 4.不十分／安全でないロギング 5.安全でないシークレット管理 6.リソースの浪費 7.安全でないまたは意図しないデータのキャッシュ