Uploaded byEiji Sasahara, Ph.D., MBA 笹原英司
エッジコンピューティング環境におけるアプリケーションコンテナ／マイクロサービスのセキュリティ／リスク管理
IoTデバイスとクラウドサービスの間にあるエッジコンピューティング環境で、アプリケーションコンテナ、マイクロサービス、DevOps／DevSecOpsといったクラウド・ネイティブの技術を利⽤する場合、ITおよびOT双⽅の観点から要求される、セキュリティ／リスク管理策について考察します。
More Related Content
Similar to エッジコンピューティング環境におけるアプリケーションコンテナ／マイクロサービスのセキュリティ／リスク管理
![[ハードウェア編] クラウドネイティブアーキテクチャとIoTセキュリティ・バイ・デザイン](https://cdn.slidesharecdn.com/ss_thumbnails/csadevsecops20230217final-230227221417-0e3d8bbf-thumbnail.jpg?width=640&height=640&fit=bounds)
エッジコンピューティング環境におけるアプリケーションコンテナ／マイクロサービスのセキュリティ／リスク管理
- 1. @esasahara Cloud Security Alliance ApplicationContainers and Microservices WG エッジコンピューティング環境における アプリケーションコンテナ／マイクロサービスの セキュリティ／リスク管理
- 2. 2 AGENDA • 1. 普及拡大するクラウドネイティブ技術 •2. エッジコンピューティング環境におけるコンテナ／ マイクロサービス利用のユースケース • 3. エッジコンピューティング環境におけるコンテナ／ マイクロサービスのセキュリティ脅威と対策 • 4. Q&A
- 3. 3 AGENDA • 1. 普及拡大するクラウドネイティブ技術 •1-1. アプリケーションコンテナ／マイクロサービスとは • 1-2. エッジ／フォグコンピューティングとは？ • 1-3. ゼロトラストとは？ • 1-4. DevOpsとは？
- 4. 4 1-1.アプリケーションコンテナ／マイクロサービスとは?(1) • 米国立標準技術研究所（NIST） 「SP800-180(Draft): NIST マイクロサービス、アプリケーションコンテナ、システム仮想 マシンの定義」（2016年2月） • アプリケーションコンテナ: 共有OS上で稼働するアプリケーションまたはそのコンポーネントとして パッケージ化し、稼働するように設計された構成物 • マイクロサービス： アプリケーション・コンポーネントのアーキテクチャを、疎結合のパターンに 分解した結果生まれる基本的要素であり、標準的な通信プロトコルや 明確に定義された API を利用して相互に通信する自己充足型サービス を構成し、いかなるベンダー、製品、技術からも独立している
- 5.
- 6. 6 1-2.エッジ／フォグコンピューティングとは?(1) • 米国立標準技術研究所（NIST）「SP 500-325：フォグ コンピューティング概念モデル」（2018年3月19日） •エッジコンピューティング＝たとえば、ネットワークにアクセス可能な センサー、メーターまたはその他のデバイス上で、ローカル電算処理 機能を提供するためのスマート・エンドデバイスおよびそのユーザーを 包含するネットワークレイヤ • フォグコンピューティング＝拡張可能な電算処理リソースを共有する 連続体へのユビキタスなアクセスを可能にする階層化モデル • サポートされたアプリケーションから／へのレスポンスタイムを最小 化し、エンドデバイス向けにローカルな電算処理リソースを提供し、 必要な時、集中化されたサービスへのネットワーク接続を提供 する
- 7. 7 1-2.エッジ／フォグコンピューティングとは?(2) • スマート・エンドデバイスのクラウドベース・エコシステムをサポート するフォグコンピューティングの全体イメージ 出典：U.S. NationalInstitute of Standards and Technology (NIST) 「NIST SP 500-325, Fog Computing Conceptual Model」（2018年3月19日） 集中化された クラウドサービス フォグノード （物理的or仮想的） スマート・エンド デバイス
- 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 AGENDA • 2. エッジコンピューティング環境におけるコンテナ／ マイクロサービス利用のユースケース •2-1.インダストリー4.0向けフォグ×クラウド • 2-2.コネクテッドカー向けマイクロサービス
- 14. 14 2-1.インダストリー4.0向けフォグ×クラウド(1) • Tim Bayeret 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日）
- 15. 15 2-1.インダストリー4.0向けフォグ×クラウド(2) • アーキテクチャの全体像 出典：Tim Bayeret al. 「A Fog-Cloud Computing Infrastructure for Condition Monitoring and Distributing Industry 4.0 Services」（2019年5月2-4日） クラウドノード フォグノード IoTデバイス
- 16. 16 2-1.インダストリー4.0向けフォグ×クラウド(3) • 適用事例 出典：Tim Bayeret al. 「A Fog-Cloud Computing Infrastructure for Condition Monitoring and Distributing Industry 4.0 Services」（2019年5月2-4日）
- 17. 17 2-2. コネクテッドカー向けマイクロサービス(1) • SalmanTaherizadeh et al. 「動的Internet of Things向 け毛細管コンピューティングアーキテクチャ：エッジデバイスからフォグ ／クラウドプロバイダーまでのマイクロサービスのオーケストレーション」 （2018年9月4日） https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6164252/ • モノリシック対マイクロサービス アーキテクチャの アプリケーション構造 出典：Salman Taherizadeh et al. 「A Capillary Computing Architecture for Dynamic Internet of Things: Orchestration of Microservices from Edge Devices to Fog and Cloud Providers」 （2018年9月4日）
- 18. 18 2-2. コネクテッドカー向けマイクロサービス(2) • 異なるレイヤ間のマイクロサービスのオンロード化／オフロード化 出典：SalmanTaherizadeh et al. 「A Capillary Computing Architecture for Dynamic Internet of Things: Orchestration of Microservices from Edge Devices to Fog and Cloud Providers」（2018年9 クラウド層 フォグ層 エッジ層
- 19. 19 2-2. コネクテッドカー向けマイクロサービス(3) • エッジノード：モーターホームAI通信ハードウェア（MACH) •すべてのセンサーがネットワークのエッジ側にあるMACHで接続 される 出典：Salman Taherizadeh et al. 「A Capillary Computing Architecture for Dynamic Internet of Things: Orchestration of Microservices from Edge Devices to Fog and Cloud Providers」（2018年9
- 20. 20 AGENDA • 3.エッジコンピューティング環境におけるコンテナ／ マイクロサービスのセキュリティ脅威と対策 • 3-1.クラウドネイティブのIoTセキュリティ •3-2.スマートシティのIoTセキュリティ • 3-3.アプリケーションコンテナのクラウドセキュリティ • 3-4.マイクロサービスのクラウドセキュリティ
- 21. 21 3-1. クラウドネイティブのIoTセキュリティ(1) ・Cloud SecurityAlliance 「IoT早期導入者のためのセキュリティガイダンス 」（2015年4月） • IoTの 全体像 出典：Cloud Security Alliance「IoT早期導入者のためのセキュリティガイダンス 」（2015年4月）
- 22. 22 3-1. クラウドネイティブのIoTセキュリティ(2) ・IoTのエコシステム 出典：Cloud SecurityAlliance「IoT早期導入者のためのセキュリティガイダンス 」（2015年4月）
- 23. 23 3-1. クラウドネイティブのIoTセキュリティ(3) • IoTセキュリティの管理策 出典：CloudSecurity Alliance「IoT早期導入者のためのセキュリティガイダンス 」（2015年4月）
- 24. 24 3-1. クラウドネイティブのIoTセキュリティ(4) ・Cloud SecurityAlliance 「IoTファームウェア更新プロセスの推奨事項」（2018年9月） • IoTソリューションアーキテクチャの4段階 出典：Cloud Security Alliance「Recommendations for IoT Firmware Update Processes」（2018年9月）
- 25. 25 3-1. クラウドネイティブのIoTセキュリティ(5) • IoTセキュリティの推奨事項 出典：CloudSecurity Alliance「Recommendations for IoT Firmware Update Processes」（2018年9月） 番号 推奨事項 1 更新適用の前に、現在作動しているIoTデバイスの構成のバックアップをとる 2 ロールアップがサポートされるべきであるが、ベンダーの権限付与なく、古いイメージをリロードすべきでない 3 システム設計は、ネットワークの飽和状態を回避し、意図しないダウンタイムを制限するために、管理者によるデバイス 更新のスケジューリングを許容すべきである 4 ベンダーは、自動更新をサポートするシステム管理者による構成のオプションをサポートすべきである 5 1つのコンポーネントが、IoTデバイスを構成する複数のマイクロコントローラーの更新を管理すべきである 6 更新戦略や差のあるまたは完全なイメージは、帯域幅の制限に適応すべきである 7 更新は、認証を受け、エンドツーエンドで保護された完全性を有すべきである 8 認証署名鍵のストレージはセキュアであるべきである 9 更新の失敗をカバーするために復旧手順を提供する 10 ベンダーによる長期サポート契約を保証する
- 26. 26 3-2. スマートシティのIoTセキュリティ(1) ・欧州ネットワーク・情報セキュリティ庁（ENISA) 「スマートシティのサイバーセキュリティ」（2015年12月） 【脅威マトリックス】 可用性 完全性 真正性 機密性 否認不可性／ 責任 出典：ENISA「Cyber securityfor Smart Cities. An architecture model for public transport」（2015年12月）
- 27. 27 3-2. スマートシティのIoTセキュリティ(2) 脅威の全体像 出典：ENISA「Cyber securityfor Smart Cities. An architecture model for public transport」（2015年12月） 意図的攻撃から の脅威 アクシデントから の脅威
- 28. 28 3-2. スマートシティのIoTセキュリティ(3) ・クラウドセキュリティアライアンス／セキュアリングスマート シティ「スマートシティ技術採用のためのサイバーセキュリティガイド ライン」（2015年11月） 項目 概要 設計・計画ス テージ ・停止時、転送時の双方でデータを保護する強力な暗号化 ・認証機能 ・権限付与機能 ・ソフトウェア、ファームウェアなどのアップデートの自動化・セキュア化 ・監査、警告、ロギング機能 ・改ざん防止機能 ・バックドア化／未文書化／ハードコード化されたアカウントがないこと ・基本以外の機能をデフォルト設定にしない ・フェールセーフ／終了 ・セキュア・バイ・デフォルト 脆弱性の履歴・セキュリティ成熟度 ・フローの頻度 ・フローのタイプと、緊急度および影響度 ・競合と比較した製品セキュリティの進化度 ・ベンダーがセキュリティ脆弱性にパッチを当てるのに要する時間とパッチの適用を容易にする方法
- 29. 29 3-2. スマートシティのIoTセキュリティ (4) 項目概要 ベンダーの セキュリ ティ ・ベンダーが、製品のユーザービリティを検証するために、製品テストを実施し、大規模環境をシミュレーションする方法 ・ベンダーが、攻撃や知財の漏えいから自分のインフラストラクチャを保護する方法 ・ベンダーは、スパイや操作から、開発環境や知財を適正に保護しているか ・ベンダーは、独立した主体に、セキュリティフローやバックドアに関するインフラストラクチャのテストを要求するポリシーや手順を 導入しているか ・ベンダーは、製品、ネットワーク、システム上で、定期的に、独立したコードレビューやペネトレーションテストを実施しているか ・ベンダーは、どのようにして、設計詳細、製品リスト、顧客のコンタクト情報など、顧客に関する詳細を保護するするか ・ベンダーは、セキュア開発ライフサイクル（SDLC)プログラムを有しているか ・ベンダーは、マルウェア、バックドアなどを含む製品の発送を防止するために、サイバーサプライチェーン・サイバーセキュリティを 執行するか ・ベンダーは、公のセキュリティ脆弱性開示・報告ポリシーや、脆弱性報告書を入手する適切なコンタクトチャネルを有しているか ・ベンダーは、コンピューター緊急対応チーム（CERT)、コンピューターセキュリティ・インシデント対応チーム（CSIRT）、オンラ インサポートなど、セキュリティ問題／インシデントのためのサポートチームを有しているか 製品管理 ・新製品を現行システムに統合する際、セキュリティの影響度を評価しているか ・新製品統合のためのセキュリティ要求事項を保証するために、特別な手段を導入しているか 検証試験 スマート技術を採用する組織は、製品のセキュリティ機能に関するベンダーの要求事項を確認すべきである ・基本的なセキュリティ要求事項の法令遵守 ・ペネトレーションテスト ・ハードニング ・認証 ・運用セキュリティの検証と妥当性確認
- 30. 30 3-2. スマートシティのIoTセキュリティ(5) 項目 概要 技術の導入・技術が、選定フェーズのセキュリティテストに合格したことを保証する ・技術が、セキュアに配送されたことを保証する ・強力な暗号化が可能なことを保証する ・セキュアなシステム管理を保証する ・強力なパスワード設定を保証する ・不必要なユーザーアカウントが削除されていることを保証する ・利用しない機能やサービスが無効であることを保証する ・セキュリティイベントに対する監査が可能なことを保証する ・改ざん防止、破壊防止メカニズムを追加する 技術の運用と 維持 ・モニタリング ・パッチ当て ・定期的な評価と監査 ・ロギング環境の保護 ・アクセス制御 ・サイバー脅威インテリジェンス ・危険な状態への対応と発見 技術の廃棄 ・再利用技術の回避 ・セキュアなデータ消去 ・ベンダー入れ替えの重要性
- 31. 31 3-3.アプリケーションコンテナのクラウドセキュリティ(1) • 米国NIST 「SP800-190: アプリケーションコンテナ・ セキュリティガイド」（2017年9月） • コンテナ技術アーキテクチャ層と構成要素 出典：NIST 「SP 800-190: Application Container Security Guide」（2017年9月）
- 32. 32 3-3.アプリケーションコンテナのクラウドセキュリティ(2) ・コンテナ技術のコアコンポーネントのリスク(1) コンポーネント リスク イメージ ・イメージの脆弱性 ・イメージ構成の欠陥 ・組込まれたマルウェア ・組込まれた平文の秘密 ・信頼できないイメージの使用 レジストリ・セキュアでないレジストリへの接続 ・レジストリにおける古いイメージ ・不十分な認証および権限付与の制限 オーケストレーター ・制限のない管理者のアクセス ・不正なアクセス ・分離が不十分なコンテナ内のネットワークトラフィック ・ワークロードの機微度レベルの混在 ・オーケストレーター・ノードの信頼性 出典：NIST 「SP 800-190: Application Container Security Guide」（2017年9月）を基にヘルスケア クラウド研究会作成
- 33. 33 3-3.アプリケーションコンテナのクラウドセキュリティ(3) ・コンテナ技術のコアコンポーネントのリスク(2) 出典：NIST 「SP 800-190:Application Container Security Guide」（2017年9月）を基にヘルスケア クラウド研究会作成 コンポーネント リスク コンテナ ・ランタイム・ソフトウェア内の脆弱性 ・コンテナからの制限のないネットワークアクセス ・セキュアでないコンテナ・ランタイムの構成 ・アプリケーションの脆弱性 ・不正なコンテナ ホストOS ・大規模攻撃の対象領域 ・共有されたカーネル ・ホストOSコンポーネントの脆弱性 ・不適切なユーザーアクセス権限 ・ホストOSのファイルシステムの改ざん
- 34. 34 3-4.マイクロサービスのクラウドセキュリティ(1) • 米国NIST 「SP800-204: マイクロサービスベースの アプリケーションシステム向けセキュリティ戦略」（2019年8月） • マイクロサービスの設計原則 • 個々のマイクロサービスは、他のマイクロサービスから独立して、管理、 複製、スケーリング、アップグレード、展開される • 個々のマイクロサービスは、単独の機能を有し、制限された環境（例． 制限された責任を有し、他のサービスに依存する）で稼働する • すべてのマイクロサービスは、一定の障害や復旧のために設計されるべき であり、可能な限りステートレスである必要がある • 状況管理のために、既存のトラステッドサービス（例．データベース、 キャッシュ、ディレクトリ）を再利用すべきである
- 35. 35 3-4.マイクロサービスのクラウドセキュリティ(2) • マイクロサービスのコア機能 • 認証とアクセス制御 •サービス・ディスカバリー • セキュリティ監視・分析 • マイクロサービスのAPIゲートウェイ機能 • 最適化されたエンドポイント • リクエストやレスポンスの共有、API変換、プロトコル変換 • サーキットブレーカー（遮断機能） • ロードバランサー（負荷分散） • レート制限 • ブルー／グリーン・デプロイメント（本番環境と別に新たな本番環境を 構築し、切り替える） • カナリア・リリース（一部のユーザーから段階的に導入する）
- 36. 36 3-4.マイクロサービスのクラウドセキュリティ(3) • マイクロサービス運用のアーキテクチャ・フレームワーク アーキテクチャ・フレームワーク アーキテクチャ全体における役割 APIゲートウェイ・南北（クライアントとアプリケーション間）・東西（マイクロ サービス間）のトラフィックを制御するのに使用される（後者 はマイクロゲートウェイを使用） ・マイクロサービスがweb／アプリケーションサーバーに展開さ れる時、マイクロゲートウェイが導入される サービス・メッシュ ・コンテナを使用してマイクロサービスが展開される時、純粋に 東西のトラフィックのために導入されるが、マイクロサービスが VMまたはアプリケーションサーバーにハウジングされる状況下 で使用することができる 出典：NIST 「SP 800-204: Security Strategies for Microservices-based Application Systems 」（2019年8月）
- 37. 37 3-4.マイクロサービスのクラウドセキュリティ(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月）
- 38. 38 3-4.マイクロサービスのクラウドセキュリティ(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月）
- 39. 39 3-4.マイクロサービスのクラウドセキュリティ(6) • 米国NIST 「SP800-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月）
- 40. 40 3-4.マイクロサービスのクラウドセキュリティ(7) ・マイクロサービス・ベース・アプリケーションのセキュリティ 項目 考慮点 認証と権限付与 ・認証／アクセスポリシーは、マイクロサービスが呼び出すAPIの種類に依存する ・証明に基づく認証は、公開鍵インフラストラクチャ（PKI)と鍵管理を要求する サービス・ディスカバリー（サービス リクエストの間にサービスを発見す る機能） ・動的に変わるロケーションを持った各サービスに関連して、相当数のサービスと多くのインスタンスが存在 する ・各マイクロサービスには、仮想マシン（VM)またはコンテナとして展開されたものがあり、動的にIPアドレ スが割り当てられた可能性がある ・サービスに関連するインスタンスの数は、負荷変動によって異なる ネットワーク・レジリエンス 技術を介した可用性の向上 ・ロードバランサー（負荷分散） ・サーキットブレーカー（遮断機能） ・レート制限／調整 ・ブルー／グリーン・デプロイメント（本番環境と別に新たな本番環境を構築し、切り替える） ・カナリア・リリース（一部のユーザーから段階的に導入する） アプリケーション監視の要求事項・分散ロギング、メトリクス生成、分析パフォーマンス、追跡を介したマイクロサービスの内外のネットワー クトラフィックのモニタリング 出典：NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」（2020年5月）
- 41. 41 3-4.マイクロサービスのクラウドセキュリティ(8) ・サービス・メッシュの定義と技術的背景(1) 出典：NIST 「SP 800-204A:Building Secure Microservices-based Applications Using Service-Mesh Architecture」（2020年5月） 項目 考慮点 マイクロサービスの機能 ・ビジネスロジック：ビジネス機能、計算処理、サービス構成／統合 ・ネットワーク機能：サービス間の通信メカニズム サービス・メッシュのコン ポーネント データプレーン：アプリケーションからのリクエストをフォワードする機能を提供するデータパス コントロールプレーン：メッシュに渡ってデータプレーン（プロキシー）の行動を制御・構成するために使用される APIツール類 サービス・メッシュの機能 ・認証と権限付与 ・サービスディスカバリー ・セキュアなコミュニケーション ・コミュニケーション向けのレジリエンス／安定性機能 Ingressコントローラー ・サービスメッシュ内部にある実際のAPIを覆っているすべてのクライアント向けの共通API ・HTTP／HTTPSのようなwebに適したプロトコルから、RPC／gRPC／RESTのようなマイクロ サービスが使用するプロトコルへのプロトコル変換 ・クライアントからのシングルコールに対応して、サービスメッシュ内部の複数サービスへのコールから 受け取った結果の構成 ・負荷分散 ・パブリックTLS終了
- 42. 42 3-4.マイクロサービスのクラウドセキュリティ(9) ・サービス・メッシュの定義と技術的背景(2) 出典：NIST 「SP 800-204A:Building Secure Microservices-based Applications Using Service-Mesh Architecture」（2020年5月） 項目 考慮点 Egressコントローラー ・メッシュ外にあるマイクロサービス向けのマイクロサービスから発生する内部トラフィックをコントロールするサービ ス・プロキシー ・外部ネットワークへの通信をホワイトリスト化する単一セットのワークロード（例．ホスト、IPアドレス） ・資格情報の交換：外部システムの資格情報に直接アクセスするアプリケーションなしに、内部のID 資格情報から外部の資格情報（例．SSOトークン、API鍵）に変換する ・webに適したプロトコル（例．HTTP／HTTPS）から、マイクロサービスに適したプロトコル （例．RPC／gRPC／REST）へのプロトコル変換 通信ミドルウェアとしての サービス・メッシュ：相違 点 ・伝統的な分散システム向けミドルウェア：アプリケーションデリバリー・コントローラー（ADC)、負荷分散装置、 APIゲートウェイ ・マイクロサービスの通信トラフィックの特徴：「東西」＞「南北」 • 「南北」トラフィック：クライアントとアプリケーション間の通信トラフィック • 「東西」トラフィック：マイクロサービス間の通信トラフィック ・軽量通信ミドルウェアとしてのサービス・メッシュ：プロダクションアプリケーションとして許容できるパフォーマン ス・レベルが要求される ・クラウドネイティブ・アプリケーションの機能として、マイクロサービス・アプリケーションが、コンテナなしで導入され るケース：サービスベース・アーキテクチャ、APIドリブン通信、コンテナベース・インフラストラクチャ、DevOpsプ ロセスに関するバイアスなど
- 43. 43 3-4.マイクロサービスのクラウドセキュリティ(10) ・サービス・メッシュの定義と技術的背景(3) 出典：NIST 「SP 800-204A:Building Secure Microservices-based Applications Using Service-Mesh Architecture」（2020年5月） 項目 考慮点 サービス・メッシュ：最先 端の手法 ・各マイクロサービスをコンテナとして展開する ・アプリケーションは、コンテナ・オーケストレーション・ツールを利用して管理されるコンテナ・クラスター（可用性と パフォーマンスの向上目的）を活用する ・クラウドプロバイダーが提供し、コンテナ管理／オーケストレーション環境に必要な展開／構成ツールを有する Container as a Service (CaaS) 経由で、アプリケーションをホストする
- 44.