Advertisement
Advertisement

More Related Content

Slideshows for you(20)

Similar to コンテナ/マイクロサービス/サーバーレスのセキュリティと監査(20)

Advertisement

More from Eiji Sasahara, Ph.D., MBA 笹原英司(20)

Recently uploaded(20)

Advertisement

コンテナ/マイクロサービス/サーバーレスのセキュリティと監査

  1. @esasahara Cloud Security Alliance Application Containers and Microservices WG コンテナ/マイクロサービス/ サーバーレスのセキュリティと監査
  2. 2 AGENDA • 1.コンテナ/マイクロサービス/サーバーレスの監査事例 • 2.コンテナ/マイクロサービス/サーバーレスとは? • 3.コンテナ/マイクロサービス/サーバーレスにおける アーキテクトの役割 • 4.アプリケーションコンテナのクラウドセキュリティ • 5.マイクロサービスのクラウドセキュリティ • 6.サーバーレスのクラウドセキュリティ • 7.Q&A
  3. 3 AGENDA • 1.コンテナ/マイクロサービス/サーバーレスの監査事例
  4. 4 1.コンテナ/マイクロサービス/サーバーレスの監査事例(1) ・アップル&グーグル「Apple and Google partner on COVID- 19 contact tracing technology」(2020年4月10日) • 両社は、プライバシー保護コンタクト・トレーシング・サービスに おける曝露通知機能の技術仕様草案(Bluetooth、暗号、 フレームワークAPI)を公開 • 両社は、2020年5月に、公衆衛生当局からの公式アプリケーショ ンを利用して、iOSとAndroidの相互運用性を実現するAPIを リリース(米国連邦政府の医療データ相互運用性推進策を反映) • 両社は、数ヶ月中の間に、Bluetoothベースのコンタクト・トレーシ ング・プラットフォーム機能(分散型)を基本プラットフォームに組 込んで幅広く提供できるようにする
  5. 5 1.コンテナ/マイクロサービス/サーバーレスの監査事例(2) ・厚生労働省「COCOA (COVID-19 Contact-Confirming Application)」(2020年6月19日) • Bluetoothを介した近接検知メカニズムと、Google/Appleが 提供する暴露通知(GAEN) APIを利用した新型コロナウイルス 感染症向け接触確認アプリケーション • Microsoft Azureを採用 • Xamarin(開発環境) • Azure Functions(サーバーレス) • Azure CosmosDB (NoSQLデータベース) 5 Source: The Ministry of Health, Labor, and Welfare, “(COCOA) COVID-19 Contact-Confirming Application”, June 22, 2020 (https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/cocoa_00138.html)
  6. 6 1.コンテナ/マイクロサービス/サーバーレスの監査事例(3) ・アイルランド保健サービス委員会(HSE)の接触追跡 アプリケーション「COVID Tracker」(2020年7月7日) • Bluetoothを介した近接検知メカニズムと、Google/Appleが 提供する暴露通知(GAEN) APIを利用した新型コロナウイルス 感染症向け接触確認アプリケーション • アプリケーション・コードをオープンソース化(COVID Green) してLinuxファウンデーションに寄贈 ⇒ AWS Lambdaを採用 6 出典:Health Service Executive (HSE) 「COVID Tracker App」 (2020年7月7日)(https://covidtracker.gov.ie/) 出典:github.com: COVID GREEN (https://github.com/covidgreen/covid-green-lambdas)
  7. 7 1.コンテナ/マイクロサービス/サーバーレスの監査事例(4) ・オープンソース・テクノロジー・インプルーブメント・ファンド(OSTIF) 「Linux Foundation公衆衛生イニシアティブがCOVID暴露通知 アプリケーションの監査を支援」(2021年1月15日) • OSTIFが、Linux Foundation公衆衛生イニシアティブ (LFPH)の支援を受けて、オープンソース化されたCOVID-19 暴露通知アプリケーション(アイルランド発「COVID Green」と カナダ発「COVID Shield」)に対する監査を実施 • いずれのアプリケーションも、設計における潜在的弱点を特定し、攻 撃者が、ソフトウェアのプライバシー/完全性に対して改ざんしよう とする方法を特定するために、脅威モデルを開発し、クライアント ソースコードのレビューを実施 • サーバーサイド・ソフトウェアはスコープ外 7
  8. 8 1.コンテナ/マイクロサービス/サーバーレスの監査事例(5) ・監査結果 8 監査 指摘項目 Audit One – COVID Shield / COVID Alert ・CVG-01-003 COVID Shield – Misleading Security Guarantees – WILL NOT FIX – EXPLAINED BELOW ・CVG-01-004 COVID Shield – Diagnosis Key Timestamps Set by Client – NO FIX REQUIRED – SERVER DISCARDS DATA ・CVG-01-007 COVID Shield – Tests Fail to Generate Random Keys – FIXED Audit Two – COVID Green / COVID Tracker ・CVG-01-001 COVID Green: Denial of Service through Diagnosis Key Flooding – FIXED ・CVG-01-002 COVID Green: Potential Diagnosis Keys Reuse – FIXED ・CVG-01-005 COVID Green: SMS Provider Obtains Diagnosed Phone Numbers – WILL NOT FIX – EXPLAINED BELOW ・CVG-01-006 COVID Green: Statistical Data Figures Overly Precise – OUT OF SCOPE ISSUE 出典:OSTIF「The Linux Foundation Public Health Initiative Sponsored the Audit of COVID Exposure Notification Apps」(2021年1月15日) https://ostif.org/the-linux-foundation-public-health-initiative-sponsored-the-audit-of-covid-exposure-notification-apps-here-are-the- results/
  9. 9 1.コンテナ/マイクロサービス/サーバーレスの監査事例(6) • 欧州委員会「承認済アプリケーション間の越境移転チェーンの ための相互運用性仕様に関するEU加盟国および欧州委員 会向けeヘルスネットワーク・ガイドライン V1.0」 (2020年6月16日) *2020年10月より実稼働 • シェンゲン協定に基づいた域内経済交流の再開に向けて、接触追 跡アプリケーション越境連携の相互運用性に関わる統一標準規格 として策定 → SAPとドイツテレコムがシステムを構築 • 基本的な相互運用性の要素 • Bluetoothの仕様 • COVID+ Keys(診断キー) • 利害関係国リスト • バックエンドサーバーの相互運用性
  10. 10 1.コンテナ/マイクロサービス/サーバーレスの監査事例(7) • 欧州委員会「接触追跡アプリケーションの相互運用性に 関する技術仕様V1.0」(2020年6月16日) • 1. イントロダクション • 2. アーキテクチャ概要 • 3. 通信 • 4. データ構造(データタイプ、データストレージ) • 5. インタフェース • 6. セキュリティ(機密性、完全性、可用性) • 7. 技術選択 • 8. 監査(全体、データプライバシー、データ転送、トラフィック) • 9. 分散プライバシー保護接近追跡(DP3T)互換性 • 10.代替データ交換手法(ミラーリング、ブロックチェーン)
  11. 11 1.コンテナ/マイクロサービス/サーバーレスの監査事例(8) • 域内共通のフェデレーションゲートウェイサービスの概要 出典:European Commission「Technical specifications for interoperability of contact tracing apps - eHealth Network Guidelines to the EU Member States and the European Commission on Interoperability specifications for cross-border transmission chains between approved apps」(2020年6月16日) (https://ec.europa.eu/health/sites/health/files/ehealth/docs/mobileapps_interoperabilitydetailedelements_en.pdf)
  12. 12 1.コンテナ/マイクロサービス/サーバーレスの監査事例(9) • 自律的な各国のバックエンド 出典:European Commission「Technical specifications for interoperability of contact tracing apps - eHealth Network Guidelines to the EU Member States and the European Commission on Interoperability specifications for cross-border transmission chains between approved apps」(2020年6月16日) (https://ec.europa.eu/health/sites/health/files/ehealth/docs/mobileapps_interoperabilitydetailedelements_en.pdf)
  13. 13 1.コンテナ/マイクロサービス/サーバーレスの監査事例(11) • 接触追跡アプリケーションの越境連携エコシステム導入例 • コンテナプラットフォーム(例:Kubernetesベースの OpenShift) • REST API (例:Node.jsとExpress) • 分散NoSQLデータベース (例:MongoDB) • ロードバランサー (例:Docker上のHAProxy) • Webサーバー(例:Docker上の Nginx) 出典:European Commission「Technical specifications for interoperability of contact tracing apps - eHealth Network Guidelines to the EU Member States and the European Commission on Interoperability specifications for cross-border transmission chains between approved apps」(2020年6月16日) (https://ec.europa.eu/health/sites/health/files/ehealth/docs/mobileapps_interoperabilitydetailedelements_en.pdf)
  14. 14 1.コンテナ/マイクロサービス/サーバーレスの監査事例(12) • セキュリティ:バックエンドの機密性 出典:European Commission「Technical specifications for interoperability of contact tracing apps - eHealth Network Guidelines to the EU Member States and the European Commission on Interoperability specifications for cross-border transmission chains between approved apps」(2020年6月16日) (https://ec.europa.eu/health/sites/health/files/ehealth/docs/mobileapps_interoperabilitydetailedelements_en.pdf)
  15. 15 1.コンテナ/マイクロサービス/サーバーレスの監査事例(13) • 監査:全体 • 監査条件を保証するために、すべての連携ゲートウェイサービスへの リクエストは、監査ログを生成する監査モジュールを通過させて、 データベース内にログ、イベントストリーム、テーブルを生成するよう にする • このデータは、標準的な可視化ツール(例.Tableau、Kibana、 Splunk、Grafana)を経由して、ダッシュボード上に表示すること ができる
  16. 16 1.コンテナ/マイクロサービス/サーバーレスの監査事例(14) • 監査:データプライバシー • 監査メカニズムの留意点 • GDPR遵守のデータ処理 • 不正アクセスのリスクの低減 • データ主体の権利保護 • 具体的な対策例 • 各国のバックエンドのIDを証明するクライアント認証 • アクティブな信頼性メカニズム:バックエンドは、誰が信頼できるか(ホワ イトリスト)、信頼できないか(ブラックリスト)を選択する可能性がある • データアクセスのロギング • TLSを利用した転送時の暗号化 • データベース保存時の暗号化 • 侵入検知と悪用に関するアラート
  17. 17 1.コンテナ/マイクロサービス/サーバーレスの監査事例(15) • 監査:データ転送 • クライアント情報は、クライアント認証や、要求/提出されたデータ (鍵のオリジン、鍵のデスティネーション)、オペレーションのタイム スタンプから抽出されて、クライアントやトラフィックの詳細に関する 統計を作成するために利用される • アップロード/ダウンロードされたすべての情報は、証明可能である ことが保証される • 監査:トラフィック • モニタリング手法 • データベースログ経由 • データベース機能(手動)経由 • 外部のイベントベースのモニタリングツール経由
  18. 18 AGENDA • 2.コンテナ/マイクロサービス/サーバーレスとは?
  19. 19 2.コンテナ/マイクロサービス/サーバーレスとは?(1) 米国連邦金融機関検査協議会(FFIEC) 「クラウドコンピューティング環境におけるセキュリティ」 (2020年4月30日) ・クラウドコンピューティング・サービスのリスク管理 出典:FFIEC 「Security in a Cloud Computing Environment」(2020年4月30日)を基にヘルスケアクラウド研究会作成 項目 管理策 ガバナンス ・金融機関のIT戦略計画やアーキテクチャの一部としてクラウドコンピューティング・サービスを利用するための 戦略 クラウド セキュリティ 管理 ・クラウドサービスプロバイダーのセキュリティに関する適切なデューデリジェンスと継続的な監視・モニタリング ・金融機関およびクラウドサービスプロバイダー向けの契約上の責任、能力、制限 ・クラウドコンピューティング環境に存在するシステムおよび情報資産向け在庫プロセス ・セキュリティの構成、プロビジョニング、ロギング、モニタリング ・アイデンティティ/アクセス管理とネットワーク制御 ・機微データに対するセキュリティ・コントロール ・情報セキュリティ啓発およびトレーニングプログラム
  20. 20 2.コンテナ/マイクロサービス/サーバーレスとは?(2) ・クラウドコンピューティング・サービスのリスク管理(続き) 項目 管理策 変更管理 ・変更管理およびソフトウェア開発ライフサイクルのプロセス ・マイクロサービス・アーキテクチャ レジリエンス と復旧 ・ビジネスレジリエンスと復旧の機能 ・インシデント対応機能 監査および コントロー ルの評価 ・重要システムに対する金融機関のコントロールに関する定期的検証 ・クラウドサービスプロバイダーが管理するコントロールに関する監視およびモニタリング ・クラウドコンピューティングサービス固有のコントロール -仮想インフラストラクチャの管理 -クラウドコンピューティング環境におけるコンテナの利用 -クラウドコンピューティング環境向けのマネージド・セキュリティサービス(例.CASB)の利用 -データおよびサービスの相互運用性とポータビリティの考慮 -データの破壊または無毒化 出典:FFIEC 「Security in a Cloud Computing Environment」(2020年4月30日)を基にヘルスケアクラウド研究会作成
  21. 21 2.コンテナ/マイクロサービス/サーバーレスとは?(3) • クラウドからアプリケーションコンテナ、マイクロサービスへの 移行 APIを軸とする自律サービスの疎結合型アーキテクチャへ IaaS PaaS SaaS OS ミドル ウェア アプリ ケー ション ミドル ウェア アプリ ケー ション アプリケーションコンテナ コンテナ管理 ソフトウェア APIゲートウェイ UI/ UX UI/ UX UI/ UX UI/ UX 処理A 処理B 処理C データ データ データ マイクロサービス クラウドサービス 出典:ヘルスケアクラウド研究会(2016年1月)
  22. 22 2.コンテナ/マイクロサービス/サーバーレスとは?(4) • 米国立標準技術研究所(NIST) 「SP 800-180(Draft): NIST マイクロサービス、アプリケーションコンテナ、システム仮想 マシンの定義」(2016年2月) • アプリケーションコンテナ: 共有OS上で稼働するアプリケーションまたはそのコンポーネントとして パッケージ化し、稼働するように設計された構成物 • マイクロサービス: アプリケーション・コンポーネントのアーキテクチャを、疎結合のパターンに 分解した結果生まれる基本的要素であり、標準的な通信プロトコルや 明確に定義された API を利用して相互に通信する自己充足型サービス を構成し、いかなるベンダー、製品、技術からも独立している
  23. 23 2.コンテナ/マイクロサービス/サーバーレスとは?(5) • CSA 「2021年サーバーレスコンピューティング・セキュリティ」 (2021年3月公開予定) • サーバーレスコンピューティング: クラウドプロバイダーが計算処理のランタイム管理面の負荷を軽減し、 計算処理、ストレージ、ネットワークに関するすべての面を含む、物理的 または仮想的なマシンリソースの割当設定を動的に管理する、クラウド コンピューティング展開モデル。サーバーレスアプリケーションのオーナーは、 このようなタスクを管理する必要はない。 • Amazon: Lambda、Fargate、AWS Batch • Google: Cloud Functions、Knative、Cloud Run • Microsoft: Azure Functions、Azure Container Instances • Nimbella: OpenWhisk • IBM: OpenWhis など
  24. 24 2.コンテナ/マイクロサービス/サーバーレスとは?(6) ・クラウドにおけるサーバーレスの責任共有モデル CaaS(Container as a Service) FaaS(Function as a Service) 出典:CSA「Serverless Computing Security in 2021」(in progress)
  25. 25 2.コンテナ/マイクロサービス/サーバーレスとは?(7) ・FaaS(Function as a Service)の責任共有モデル 出典:CSA「Serverless Computing Security in 2020」(in progress)
  26. 26 2.コンテナ/マイクロサービス/サーバーレスとは?(8) ・CaaS(Container as a Service)の責任共有モデル 出典:CSA「Serverless Computing Security in 2020」(in progress)
  27. 27 AGENDA • 3.コンテナ/マイクロサービス/サーバーレスにおける アーキテクトの役割
  28. 28 3.コンテナ/マイクロサービス/サーバーレスにおける アーキテクトの役割(1) [アプリケーション層/IT業務処理統制からのアプローチ] • 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日)
  29. 29 3.コンテナ/マイクロサービス/サーバーレスにおける アーキテクトの役割(2) [インフラストラクチャ層/IT全般統制からのアプローチ] • 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日)
  30. 30 3.コンテナ/マイクロサービス/サーバーレスにおける アーキテクトの役割(3) [DevSecOps/BISOからのアプローチ] • 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日)
  31. 31 3.コンテナ/マイクロサービス/サーバーレスにおける アーキテクトの役割(4) • クラウドセキュリティアライアンス「安全なマイクロサービスアーキテクチャ実装の ためのベストプラクティス」(日本語版:2020年11月17日) • ユースケース例:マイクロサービスへのモノリシック・アプリケーションの分解(1) 視点 課題 開発者 1. アプリケーションの断片化が進むと、開発者はマイクロサービスの可視性が低下し、各コンポーネントが他のコン ポーネントと問題なく動作することを保証するという課題が生じる 2. 相互運用性の確保の観点から、弱いテストケースは、ソフトウェア開発サイクルの後半で可用性とパフォーマン スの問題のリスクを高める可能性がある 3. モノリスの分解の結果、内部ソフトウェアモジュールは、顧客の利用面に向いているもの、プロセス間通信に関連 する内部ユーティリティまたは中間機能であるもの、記録システムまたは参照システムであるデータストアに向い ているものに分類されるが、中にはマイクロサービスの採用を妨げる制約の源となりうるものがある 4. マイクロサービスアーキテクチャアプローチはRESTfulなメソッド駆動型のスタイルであり、すべての状況がアプ ローチに簡単に適合するわけではない(例.SOAPプロトコルバックエンド接続) 5. マイクロサービスのスタイルでは、すべての開発者が「ネットワークプログラミング」の開発者となる 6. 堅牢なマイクロサービステスト、合成データ、および SWAGGER のような API ドキュメンテーションフレーム ワークがないと、予期せぬセキュリティやパフォーマンスの欠陥につながるコードプロモーションのリスクが高まり、 不注意な情報開示まで含めてリスクが高まる可能性がある
  32. 32 3.コンテナ/マイクロサービス/サーバーレスにおける アーキテクトの役割(5) • ユースケース:マイクロサービスへのモノリシック・アプリケーションの分解(2) 視点 課題 運用者 1. 開発プロセスやステージング、本番環境で使用するための実績のあるコードプロモーションシステムがないと、コード プロモーションの遅れが増える可能性がある 2. 選択されたマイクロサービス間の柔軟で安全なネットワーク転送を提供することが課題となる可能性がある 3. コンテナが実行されなくなったときに、マイクロサービスが状態を失わないようにするための設計責任を共有している 4. アプリケーションが断片化すると、マイクロサービスアプリケーションの動作を把握できなくなる可能性がある アーキ テクト 1. マイクロサービスアーキテクチャに再構築し、それらのマイクロサービスを調整することのコストとメリットのバランスを 見つけるとともに、アジャイル開発クルー、クループログラムマネージャーとスクラムマスター、技術チーム、およびビジネス ステークホルダーの間で作業するソフトウェアアーキテクトとして実際に機能しているが、ソリューション、インフラストラク チャ、セキュリティ、データ、ネットワークアーキテクトなど、すべての情報技術アーキテクトがこの役割で機能するわけで はない 出典:クラウドセキュリティアライアンス「安全なマイクロサービスアーキテクチャ実装のためのベストプラクティス」(2020 年11月17日)を基にヘルスケアクラウド研究会作成
  33. 33 3.コンテナ/マイクロサービス/サーバーレスにおける アーキテクトの役割(6) • クラウドセキュリティアライアンス 「Microservices Architecture Pattern」 (2021年4月公開予定) • マイクロサービス参照アーキテクチャ • アイデンティティ提供 • 検知サービス • 暗号化サービス (鍵&認証管理) • DevOps/セキュア・ソフトウェア 開発ライフサイクル(CI/CD) • コンテナのレジストリ • APIのレジストリ 出典:CSA「Microservices Architecture Pattern」(in progress)
  34. 34 3.コンテナ/マイクロサービス/サーバーレスにおける アーキテクトの役割(7) • 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.サーバーレスコンピューティングが進化し続けるのに合わせた学習の継続
  35. 35 AGENDA • 4.アプリケーションコンテナのクラウドセキュリティ
  36. 36 4.アプリケーションコンテナのクラウドセキュリティ(1) • 米国NIST 「SP 800-190: アプリケーションコンテナ・ セキュリティガイド」(2017年9月) • コンテナ技術アーキテクチャ層と構成要素 出典:NIST 「SP 800-190: Application Container Security Guide」(2017年9月)
  37. 37 4.アプリケーションコンテナのクラウドセキュリティ(2) ・コンテナ技術のコアコンポーネントのリスク(1) コンポーネント リスク イメージ ・イメージの脆弱性 ・イメージ構成の欠陥 ・組込まれたマルウェア ・組込まれた平文の秘密 ・信頼できないイメージの使用 レジストリ ・セキュアでないレジストリへの接続 ・レジストリにおける古いイメージ ・不十分な認証および権限付与の制限 オーケストレーター ・制限のない管理者のアクセス ・不正なアクセス ・分離が不十分なコンテナ内のネットワークトラフィック ・ワークロードの機微度レベルの混在 ・オーケストレーター・ノードの信頼性 出典:NIST 「SP 800-190: Application Container Security Guide」(2017年9月)を基にヘルスケア クラウド研究会作成
  38. 38 4.アプリケーションコンテナのクラウドセキュリティ(3) ・コンテナ技術のコアコンポーネントのリスク(2) 出典:NIST 「SP 800-190: Application Container Security Guide」(2017年9月)を基にヘルスケア クラウド研究会作成 コンポーネント リスク コンテナ ・ランタイム・ソフトウェア内の脆弱性 ・コンテナからの制限のないネットワークアクセス ・セキュアでないコンテナ・ランタイムの構成 ・アプリケーションの脆弱性 ・不正なコンテナ ホストOS ・大規模攻撃の対象領域 ・共有されたカーネル ・ホストOSコンポーネントの脆弱性 ・不適切なユーザーアクセス権限 ・ホストOSのファイルシステムの改ざん
  39. 39 4.アプリケーションコンテナのクラウドセキュリティ(4) • CSA 「クラウドコンピューティングのためのセキュリティ ガイダンスv4.0」(2017年7月) • Domain 8:仮想化とコンテナ技術 • 8.1.4 コンテナ =移植性の高いコード実行環境 [主要コンポーネント] • 実行環境 • 統合管理とスケジューリングのコントローラ • コンテナイメージまたは実行するコードのリポジトリ
  40. 40 4.アプリケーションコンテナのクラウドセキュリティ(5) • コンテナのセキュリティ要件 • 利用するコンテナプラットフォームとその下のOSのセキュリティの ための隔離機能を把握し、適切な設定を選択すること • コンテナ間の隔離の実施には物理マシンまたは仮想マシンを用い、 同一の物理/仮想ホスト上の同一のセキュリティ要件のコンテナ はグループ化すること • 配備対象となるのは、確実に、承認済みで認知済みでセキュアな コンテナのイメージかコードだけとなるようにすること • コンテナの統合化・管理およびスケジューラのソフトウェアの セキュリティを適切に設定すること • 全てのコンテナとリポジトリ管理に対して、適切なロールベースの アクセス管理と、強度の高い認証を実装すること。
  41. 41 4.アプリケーションコンテナのクラウドセキュリティ(6) • CSA 「アプリケーションコンテナとマイクロサービスのセキュリ ティ課題」(2019年7月) [構成] • 1. 序論 • 2. アプリケーションコンテナとマイクロサービスの課題 • 3. アプリケーションコンテナとマイクロサービス: ユースケースと機能 • 4. マイクロサービス
  42. 42 4.アプリケーションコンテナのクラウドセキュリティ(7) • [主旨] • アプリケーションコンテナとマイクロサービスのアーキテクチャ は、DevOpsのようなアジャイルソフトウェア開発手法を 活用して、アプリケーションを設計、開発、展開するために 利用される • セキュリティは、これらのソフトウェア開発手法に組込まれる 必要がある • 本文書では、開発者、運用者、アーキテクトの視点を通し て、信頼性のあるセキュアなシステムのエンジニアリングに おいて、アプリケーションコンテナやマイクロサービスのセキュ リティに取組む際の課題を特定している
  43. 43 4.アプリケーションコンテナのクラウドセキュリティ(8) • CSA 「安全なアプリケーションコンテナアーキテクチャ実装の ためのベストプラクティス」(2020年2月) • アプリケーションコンテナの課題に対するリスク緩和策(1) No. リスク緩和策 1 環境全体(開発、品質保証、テスト、本番)のコードプロモーション 2 ホストをセキュアにする 3 プラットフォーム/ホストからのコンテナ継続性監視 4 コンテナネットワーク - ホストとコンテナ間の通信 5 コンテナ・ネットワーク - コンテナ間通信 6 イメージの完全性とセキュリティレベルの検証 7 コンテナのフォレンジック 8 コンテナによるトラストチェーン 出典:CSA 「安全なアプリケーションコンテナアーキテクチャ実装のためのベストプラクティス」(2020年2月)を基に ヘルスケアクラウド研究会作成
  44. 44 No. リスク緩和策 9 コンテナのボリューム管理 10 コンテナのシークレット管理 11 プラットフォーム管理 - ライフサイクルイベント通知 12 プラットフォーム管理 - リソース要求 13 プラットフォーム管理 - コンテナリソース管理 14 コンテナ管理 - コンテナリソースのスケーリング 15 コンテナ管理 - データのバックアップとレプリケーション 16 コンテナ管理 – CMP間のコンテナのホスト変更 17 コンテナの暗号化 4.アプリケーションコンテナのクラウドセキュリティ(9) • アプリケーションコンテナの課題に対するリスク緩和策(2)
  45. 45 AGENDA • 5.マイクロサービスのクラウドセキュリティ
  46. 46 5.マイクロサービスのクラウドセキュリティ(1) • 米国NIST 「SP 800-204: マイクロサービスベースの アプリケーションシステム向けセキュリティ戦略」(2019年8月) • マイクロサービスの設計原則 • 個々のマイクロサービスは、他のマイクロサービスから独立して、管理、 複製、スケーリング、アップグレード、展開される • 個々のマイクロサービスは、単独の機能を有し、制限された環境(例. 制限された責任を有し、他のサービスに依存する)で稼働する • すべてのマイクロサービスは、一定の障害や復旧のために設計されるべき であり、可能な限りステートレスである必要がある • 状況管理のために、既存のトラステッドサービス(例.データベース、 キャッシュ、ディレクトリ)を再利用すべきである
  47. 47 5.マイクロサービスのクラウドセキュリティ(2) • マイクロサービスのコア機能 • 認証とアクセス制御 • サービス・ディスカバリー • セキュリティ監視・分析 • マイクロサービスのAPIゲートウェイ機能 • 最適化されたエンドポイント • リクエストやレスポンスの共有、API変換、プロトコル変換 • サーキットブレーカー(遮断機能) • ロードバランサー(負荷分散) • レート制限 • ブルー/グリーン・デプロイメント(本番環境と別に新たな本番環境を 構築し、切り替える) • カナリア・リリース(一部のユーザーから段階的に導入する)
  48. 48 5.マイクロサービスのクラウドセキュリティ(3) • マイクロサービス運用のアーキテクチャ・フレームワーク アーキテクチャ・フレームワーク アーキテクチャ全体における役割 APIゲートウェイ ・南北(クライアントとアプリケーション間)・東西(マイクロ サービス間)のトラフィックを制御するのに使用される(後者 はマイクロゲートウェイを使用) ・マイクロサービスがweb/アプリケーションサーバーに展開さ れる時、マイクロゲートウェイが導入される サービス・メッシュ ・コンテナを使用してマイクロサービスが展開される時、純粋に 東西のトラフィックのために導入されるが、マイクロサービスが VMまたはアプリケーションサーバーにハウジングされる状況下 で使用することができる 出典:NIST 「SP 800-204: Security Strategies for Microservices-based Application Systems 」(2019年8月)
  49. 49 5.マイクロサービスのクラウドセキュリティ(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月)
  50. 50 5.マイクロサービスのクラウドセキュリティ(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月)
  51. 51 5.マイクロサービスのクラウドセキュリティ(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月)
  52. 52 5.マイクロサービスのクラウドセキュリティ(7) ・マイクロサービス・ベース・アプリケーションのセキュリティ 項目 考慮点 認証と権限付与 ・認証/アクセスポリシーは、マイクロサービスが呼び出すAPIの種類に依存する ・証明に基づく認証は、公開鍵インフラストラクチャ(PKI)と鍵管理を要求する サービス・ディスカバリー(サービス リクエストの間にサービスを発見す る機能) ・動的に変わるロケーションを持った各サービスに関連して、相当数のサービスと多くのインスタンスが存在 する ・各マイクロサービスには、仮想マシン(VM)またはコンテナとして展開されたものがあり、動的にIPアドレ スが割り当てられた可能性がある ・サービスに関連するインスタンスの数は、負荷変動によって異なる ネットワーク・レジリエンス 技術を介した可用性の向上 ・ロードバランサー(負荷分散) ・サーキットブレーカー(遮断機能) ・レート制限/調整 ・ブルー/グリーン・デプロイメント(本番環境と別に新たな本番環境を構築し、切り替える) ・カナリア・リリース(一部のユーザーから段階的に導入する) アプリケーション監視の要求事項 ・分散ロギング、メトリクス生成、分析パフォーマンス、追跡を介したマイクロサービスの内外のネットワー クトラフィックのモニタリング 出典:NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」(2020年5月)
  53. 53 5.マイクロサービスのクラウドセキュリティ(8) ・サービス・メッシュの定義と技術的背景(1) 項目 考慮点 マイクロサービスの機能 ・ビジネスロジック:ビジネス機能、計算処理、サービス構成/統合 ・ネットワーク機能:サービス間の通信メカニズム サービス・メッシュのコン ポーネント データプレーン:アプリケーションからのリクエストをフォワードする機能を提供するデータパス コントロールプレーン:メッシュに渡ってデータプレーン(プロキシ)の行動を制御・構成するために 使用されるAPIツール類 サービス・メッシュの機 能 ・認証と権限付与 ・サービスディスカバリー ・セキュアなコミュニケーション ・コミュニケーション向けのレジリエンス/安定性機能 出典:NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」(2020年5月)
  54. 54 5.マイクロサービスのクラウドセキュリティ(9) ・サービス・メッシュの定義と技術的背景(2) 項目 考慮点 Ingressコントロー ラー ・サービスメッシュ内部にある実際のAPIを覆っているすべてのクライアント向けの共通API ・HTTP/HTTPSのようなwebに適したプロトコルから、RPC/gRPC/RESTのようなマイクロサー ビスが使用するプロトコルへのプロトコル変換 ・クライアントからのシングルコールに対応して、サービスメッシュ内部の複数サービスへのコールから受け 取った結果の構成 ・負荷分散 ・パブリックTLS終了 Egressコントロー ラー ・メッシュ外にあるマイクロサービス向けのマイクロサービスから発生する内部トラフィックをコントロールす るサービス・プロキシ ・外部ネットワークへの通信をホワイトリスト化する単一セットのワークロード(例.ホスト、IPアドレス) ・資格情報の交換:外部システムの資格情報に直接アクセスするアプリケーションなしに、内部のID資 格情報から外部の資格情報(例.SSOトークン、API鍵)に変換する ・webに適したプロトコル(例.HTTP/HTTPS)から、マイクロサービスに適したプロトコル(例. RPC/gRPC/REST)へのプロトコル変換 出典:NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」(2020年5月)
  55. 55 5.マイクロサービスのクラウドセキュリティ(10) ・サービス・メッシュの定義と技術的背景(3) 項目 考慮点 通信ミドルウェアとし てのサービス・メッ シュ:相違点 ・伝統的な分散システム向けミドルウェア:アプリケーションデリバリー・コントローラー(ADC)、負荷分 散装置、APIゲートウェイ ・マイクロサービスの通信トラフィックの特徴:「東西」>「南北」 • 「南北」トラフィック:クライアントとアプリケーション間の通信トラフィック • 「東西」トラフィック:マイクロサービス間の通信トラフィック ・軽量通信ミドルウェアとしてのサービス・メッシュ:プロダクションアプリケーションとして許容できるパ フォーマンス・レベルが要求される ・クラウドネイティブ・アプリケーションの機能として、マイクロサービス・アプリケーションが、コンテナなしで 導入されるケース:サービスベース・アーキテクチャ、APIドリブン通信、コンテナベース・インフラストラク チャ、DevOpsプロセスに関するバイアスなど サービス・メッシュ:最 先端の手法 ・各マイクロサービスをコンテナとして展開する ・アプリケーションは、コンテナ・オーケストレーション・ツールを利用して管理されるコンテナ・クラスター(可 用性とパフォーマンスの向上目的)を活用する ・クラウドプロバイダーが提供し、コンテナ管理/オーケストレーション環境に必要な展開/構成ツールを 有するContainer as a Service (CaaS) 経由で、アプリケーションをホストする 出典:NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」(2020年5月)
  56. 56 5.マイクロサービスのクラウドセキュリティ(11) ・サービス・メッシュ展開の推奨事項 • サービス・プロキシー向け通信構成(1) 項目 推奨事項 概要 SM- DR1 サービス・プロキシーに 許容されたトラフィック に関する推奨事項 サービス・プロキシーが関連サービス向けのトラフィックを受容できるプロトコルおよびポートの セットを指定する機能があるべきである。デフォルトで、サービス・プロキシは、この構成により 指定された通り、トラフィックの例外を許容スべきでない。 SM- DR2 サービス・プロキシーの 到達可能性に関する 推奨事項 サービス・プロキシーが到達できるサービス・セットは制限されるべきである。名前空間、すなわ ち所与の名前空間またはサービスのランタイム・アイデンティティ内で特別に命名されたサービ スに基づいてアクセスを制限する機能があるべきである。サービス・メッシュのコントロール・プ レーンへのアクセスは、常に、リレー・ディスカバリー、異なるポリシー、テレメトリーデータに提 供されるべきである。 SM- DR3 プロトコル転送機能に 関する推奨事項 サービス・プロキシーは、ターゲットのマイクロサービスよりも、クライアントの異なるプロトコル との通信を支援する組込み機能を有するべきである(例.REST/HTTPリクエストからg RPCリクエストへの変換またはHTTP/1.1からHTTP/2への更新)。これにより、攻撃表 面を増加させる、クライアントごとに分離したサーバー構築へのニーズを回避することが要求 される。 出典:NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」(2020年5月)
  57. 57 5.マイクロサービスのクラウドセキュリティ(12) ・サービス・プロキシー向け通信構成(2) 項目 推奨事項 概要 SM- DR4 ユーザーの拡張可能 性に関する推奨事項 サービス・プロキシーは、ネットワーク機能を処理する組込ロジックに加えて、カスタム・ロジック を定義するための機能を有するべきである。これにより、ユースケース固有のポリシー(例. 予め存在するまたは自家製のポリシー・エンジン)を展開するために、サービス・プロキシーを 拡張できることの保証が要求される。この展開では、サンドボックス化、使用する言語のAPI /ランタイム制限、または安全を保証する事前分析の実行(例.WASM、eBPF)など、 拡張性のリスクをコントールする手段を提供すべきである。 SM- DR5 プロキシー向け動的構 成機能に関する推奨 事項 静的構成に加えて、動的にプロキシーを構成する(例.イベント・ドリブン構成アップデー ト)選択肢があるべきである。言い換えれば、既知の展開時よりも、動的であることが見込 まれる主体向けのディスカバリー・サービスがあるべきである。さらに、従来の構成下で未解 決のリクエストを効率的に処理する(例.完了または終了)一方、プロキシーはランタイム 時、新たな動的構成へ原子的に交換すべきである。これにより、ユーザートラフィックの劣化や ダウンタイムなく(例.サービス・プロキシーを再起動することなく)、ランタイム時、迅速にポ リシー変更を強制することが要求される。 SM- DR6 アプリケーション・サー ビスとプロキシー間の 通信構成に関する推 奨事項 アプリケーション・サービスおよびその関連プロキシーは、ループバック・チャンネル(例.ロー カルホストIPアドレス、UNIXドメイン・ソケットなど)経由のみで通信すべきである。さらに、 サービス・プロキシーは、すべての交換データ・パケットが暗号化された相互TLS(mTLS) セッションを設定することによってのみ個々の通信を行うべきである。 出典:NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」(2020年5月)
  58. 58 5.マイクロサービスのクラウドセキュリティ(13) ・Ingressプロキシー向け構成 項目 推奨事項 概要 SM- DR7 Ingressプロキシー に関する推奨事項 サービス・プロキシーのように、Ingress(スタンドアロン)プロキシー向けにトラフィック・ ルーティング・ポリシーを構成する機能を有すべきである。アプリケーション・ディプロイメントの エッジまで幅広くルーティング・ポリシーの一貫した強制が要求されるため、これが必要とされ る。 出典:NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」(2020年5月)
  59. 59 5.マイクロサービスのクラウドセキュリティ(14) ・外部サービスへのアクセス向け構成 項目 推奨事項 概要 SM- DR8 外部リソースへのアク セス制限に関する推 奨事項 外部リソースまたはメッシュ外部のサービスへのアクセスは、デフォルトで無効化し、特定の目 的地へのアクセスを制限する明示的ポリシーよってのみ許容されるべきである。加えて、外部 リソースまたはサービスは、サービス・メッシュ自体のサービス(例.サービス・メッシュのサービ ス・ディスカバリー・メカニズムに含まれる)としてモデル化すべきである。 SM- DR9 外部リソースへのセ キュアなアクセスに関 する推奨事項 サービス・メッシュ内部のサービス向けに構成される、同様の可用性向上機能(例.タイムア ウト、サーキットブレーカー)が、外部リソースおよびサービスへのアクセス向けに提供される べきである。 SM- DR10 Egressプロキシーに 関する推奨事項 サービスおよびIngressプロキシーのように、Egress(スタンドアロン)プロキシー向けにト ラフィック・ルーティング・ポリシーを構成する機能を有すべきである。ディプロイされた時、外部 リソースおよびサービスへのアクセスは、これらEgressプロキシーにより調整されるべきである。 Egressプロキシーは、アクセスおよび可用性のポリシー(SM-DR8)を展開スべきである。 これは、伝統的なネットワークに基づくセキュリティ・モデルとともに作業するのに役立つ。たとえ ば、インターネットへのアウトバウンド・トラフィックが、ネットワーク内の特定のIPからのみ許 容されると仮定する;Egressプロキシーは、メッシュにおける一連のサービス向けのトラフィッ クを代理する一方、そのアドレスとともに稼働するよう構成することができる。 出典:NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」(2020年5月)
  60. 60 5.マイクロサービスのクラウドセキュリティ(15) • アイデンティティ/アクセス管理向け構成(1) 項目 推奨事項 概要 SM- DR11 ユニバーサル・アイデ ンティティ・ドメインに 関する推奨事項 マイクロサービスのすべてのインスタンスのアイデンティティは、一貫性があり一意であるべきである-稼働 場所に関係なく共通の名前を有すべきであるという点で一貫性があり、システム全体に渡ってという点で 一意であり、サービス名がそのサービスに対応してさえすればよい。これは、異なるロケーションに異なる論 理的サービスがあることを意味しているのではない;個々のサービスに各自のDNS名が割り当てられた、 典型的なドメインネームシステム(DNS)の利用は、この推奨事項を満たしている。サービス向けの一貫 した名前(アイデンティティ)では、システムポリシーが管理可能であることが要求される。 SM- DR12 証明書の展開の署 名に関する推奨事項 サービス・メッシュのコントロールプレーン証明管理システムでは、自己署名により証明を生成する機能を 停止すべきである。この機能は、サービス・メッシュにおいて、他のすべてのアイデンティティ証明向けにイニ シャルサインを自動実行するために、しばしば利用される。その代わり、メッシュのコントロールプレーンで 利用される署名証明が、常に企業の既存のPKIの信頼の基点(Root of Trust)に根付いたもので ある必要がある。これは、既存のPKI(例.失効または監査向け)により、証明の管理を簡素化する ものである。さらに、我々は、ローテーションを簡素化し、きめの細かい失効を可能にするために、別個の 中間署名証明が異なるドメイン向けに生成されるべきことを推奨している。 SM- DR13 アイデンティティ証明 書の更新に関する推 奨事項 マイクロサービスのアイデンティティ証明の有効期間は、インフラストラクチャ内部で管理可能なように、 可能な限り短く-できれば時間の順序に従うべきである。攻撃者は、資格情報が失効するまでの間、資 格情報を利用しさえすればサービスになりすますことができるが、資格情報を成功裏に再び奪うことは、 攻撃者にとってますます難しくなっているので、この方法は攻撃を制限するのに役立つ。
  61. 61 5.マイクロサービスのクラウドセキュリティ(16) • アイデンティティ/アクセス管理向け構成(2) 項目 推奨事項 概要 SM- DR14 アイデンティティ変更 におけるサービス・プ ロキシーのサイクル接 続に関する推奨事項 サービス・プロキシーのアイデンティティ証明がローテーションしている時、サービス・プロキシーは、既存の コネクションを効率的に終了して、新たな証明とともに、すべての新たなコネクションを設定すべきである。 証明書は、mTLSのハンドシェイクの間のみ有効なので、新たな証明が発行された時に既存のコネク ションを置き換えることは厳格に要求されない;むしろ、遅れずに攻撃を制限するために重要である。 SM- DR15 アイデンティティ証明 書に署名しない場合 の推奨事項 マイクロサービスを識別するために利用される証明書は、署名認証であってはならない。 SM- DR16 証明書発行前の ワークロード認証に 関する推奨事項 サービス・メッシュのコントロールプレーンの証明管理システムは、アイデンティティ証明を発行する前に、 サービス・インスタンスの認証を実行すべきである。多くのシステムでは、システムのオーケストレーション・エ ンジンに対するインスタンスを証明し、他のローカル証明(例.HSMから収集した鍵)を利用することに よって、これが達成可能となる。 SM- DR17 セキュアなネーミング サービスに関する推 奨事項 mTLSに利用される証明が、サーバー・アイデンティティを実行したら、サーバー・メッシュは、セキュアな ディスカバリー・サービスまたはDNSによって提供されるマイクロサービス名に、サーバー・アイデンティティ をマッピングするセキュアな命名サービスを提供スべきである。この要求事項は、サーバーがマイクロサービ ス向けに認可されたロケーションであることを保証し、ネットワークハイジャックから保護するために必要で ある。 出典:NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」(2020年5月)
  62. 62 5.マイクロサービスのクラウドセキュリティ(17) • アイデンティティ/アクセス管理向け構成(3) 項目 推奨事項 概要 SM- DR18 きめ細かいアイデン ティティに関する推奨 事項 個々のマイクロサービスは、各自のアイデンティティを有すべきであり、このサービスのすべてのインスタンス は、ランタイム時に同じアイデンティティを示すべきである。これにより、所与の名前空間において、マイクロ サービスのレベルでアクセスポリシーが適用されることが可能となる。これが要求されることによって、サービ スごとでなく、名前空間ごとにアイデンティティを発行することが、共通のマイクロサービスのランタイムにお けるデフォルトとなり、同一の名前空間にあるすべてのサービスが、特に指定されない限り、共通のランタ イムのアイデンティティとなる。加えて、ラベルは、サービス名(アイデンティティ)を増大させて、きめの細 かいロギング構成を可能にし、きめの細かい認可ポリシーをサポートするために、利用することができる。 SM- DR19 認証ポリシーのス コープに関する推奨 事項 認証のポリシー・スコープを指定する機能は、最低限、以下の選択肢を有すべきである:(a)すべての名 前空間におけるすべてのマイクロサービス、(b)特別な名前空間におけるすべてのマイクロサービス、(c) 所与の名前空間における特定のマイクロサービス(SM-DR17で参照したランタイム・アイデンティティ を利用)。 SM- DR20 認証トークンに関す る推奨事項 トークンは、その中に含まれる要求が認証を保証するように、デジタル的に署名・暗号化されるべきであり、 アクセスコントロールに関する意思決定を構築するために、認証されたアイデンティティの増強またはその 一部として利用することができる。さらに、これらのトークンは、ループバック・デバイス経由(ネットワーク・ パスが含まれていないことを保証するため)または暗号化されたチャンネル経由のみで通過させるべきで ある。 出典:NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」(2020年5月)
  63. 63 5.マイクロサービスのクラウドセキュリティ(18) • 監視機能向け構成 項目 推奨事項 概要 SM- DR21 イベントのロギングに 関する推奨事項 プロキシは、入力の妥当性エラーおよび特別な(予期しない)パラメーターのエラー、クラッシュ、コアダ ンプをロギングすべきである。共通の攻撃検知機能には、Bearerトークン再利用攻撃およびインジェク ション攻撃が含まれるべきである。 SM- DR22 リクエストのロギング に関する推奨事項 プロキシは、少なくとも、不規則なリクエスト(例.HTTP使用時の200番以外のレスポンス)向けの 共通ログ形式フィールドをロギングすべきである。成功したリクエスト(例.200番レスポンス)のロギン グは、メトリックが利用可能な時、ほとんど意味がない傾向がある。 SM- DR22 ログメッセージのコン テンツに関する推奨 事項 ログメッセージは、最低限、イベントの日時、マイクロサービス名またはアイデンティティ、リクエストトレー スID、メッセージおよびその他コンテキスト情報(例.ユーザー識別子とURLのリクエスト時)を含むべ きである。しかしながら、たとえばBearerトークンなど、機微な情報を覆うために注意を払うべきである。 SM- DR23 必須指標に関する推 奨事項 外部クライアントおよびマイクロサービスの呼び出し向けにサービス・メッシュを使用してメトリックを収集 するための構成には、最低限、(a)所与の期間におけるクライアント/サービスのリクエスト数、 (b)failureコードによる失敗したクライアント/サービスのリクエスト数、(c)サービス当たりの平均レー テンシーおよび完了リクエストのライフサイクル当たり平均総レーテンシー(理想的にはヒストグラム;ま たはfailureコードによる)を含むべきである。 SM- DR24 分散トレーシングの 展開に関する推奨事 項 分散トレーシングの展開向けにサービス・プロキシを構成する時、アプリケーション・サービスが、受け取っ た通信パケットのヘッダーを転送するように設定されていることを確認するよう注意を払うべきである。 出典:NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」(2020年5月)
  64. 64 5.マイクロサービスのクラウドセキュリティ(19) • ネットワーク・レジリエンス向け構成 項目 推奨事項 概要 SM- DR25 サービス・インスタンス のヘルスチェックの展開 に関する推奨事項 再試行、タイムアウト、サーキットブレーカーまたはカナリア・デプロイメントに関連するデータ (一般的にすべてのコントロールプレーン構成データ)は、キーバリューストアのような、堅 牢なデータストアに保存スべきである。 SM- DR26 サービス・インスタンス のヘルスチェックの展開 に関する推奨事項 再試行、タイムアウト、サーキットブレーカーまたはカナリア・デプロイメントに関連するデータ (一般的にすべてのコントロールプレーン構成データ)は、キーバリューストアのような、堅 牢なデータストアに保存スべきである。 項目 推奨事項 概要 SM- DR27 オリジン間リソース共 有(CORS)に関する 推奨事項 エッジサービス(例.マイクロサービスのエントリーポイント)は、web UIクライアント・サー ビスとしてのように、外部サービスと通信するCORS向けに構成されることがしばしばあり得る。 エッジサービス向けのCORSポリシーは、マイクロサービス・アプリケーション・サービスのコード を経由して処理するよりも、サービス・メッシュ機能(例.IstioにおけるVirtualServiceリ ソースのCorsPolicy構成)を利用して構成されるべきである。 • オリジン間リソース共有(CORS)向け構成 出典:NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」(2020年5月)
  65. 65 5.マイクロサービスのクラウドセキュリティ(20) • 管理運用向け許可の構成 項目 推奨事項 概要 SM- DR28 管理運用向けアクセ ス・コントロールに関 する推奨事項 名前空間、名前空間内で命名されたサービスなど、すべてのサービスレベルで指定可能な、 サービス・メッシュにおける全管理運用向けの粒度の細かいアクセス・コントロール許可(例. ポリシー指定、サービス・レジリエンシー・パラメーター向けの構成パラメーター、カナリア・デプ ロイメント、再試行など)を有すべきである。一般的に、この機能を実行するインタフェースは、 サービス・メッシュ自体の一部でなく、アプリケーションサービス・クラスターの構成に利用され るインストール用ソフトウェアまたはオーケストレーション・ソフトウェアの一部であることがある。 出典:NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」(2020年5月)
  66. 66 AGENDA • 6.サーバーレスのクラウドセキュリティ
  67. 67 6.サーバーレスのクラウドセキュリティ(1) • CSA 「2021年サーバーレスコンピューティング・セキュリティ」 (2021年4月公開予定) • FaaS(Function as a Service)アーキテクチャの概要 出典:CSA「Serverless Computing Security in 2021」(in progress)
  68. 68 6.サーバーレスのクラウドセキュリティ(2) • CaaS(Container as a Service)アーキテクチャの概要 出典:CSA「Serverless Computing Security in 2021」(in progress)
  69. 69 6.サーバーレスのクラウドセキュリティ(3) • サーバーレスの責任共有モデル 出典:CSA「Serverless Computing Security in 2021」(in progress)
  70. 70 6.サーバーレスのクラウドセキュリティ(4) • サーバーレスアプリケーションの脅威 1.環境の構成ミス • a. ユーザーの構成管理ミス • b. ポートの露出 • c. 無効化/デフォルト構成 • d. 資格情報の露出 • e. 構成ドリフト 2.脆弱な依存関係 • a. サプライチェーンの脆弱性 • b. 脆弱なイメージ 3.組込型マルウェア 4.ランタイムの課題 • a. データのインジェクションとリモートからの実行 • b. 認証の不備 • c. 不適切なエラーや例外の処理
  71. 71 6.サーバーレスのクラウドセキュリティ(5) • CaaSプラットフォーム共通の脅威 1.コンテナ化とオーケストレーションの脅威 • a. コンテナ化/オーケストレーションツールの脆弱性 • b. コンテナ化/オーケストレーションAPIの悪用 2.不適切に割り当てられた無制限/管理権限アクセス 3.不正アクセス 4.ポータル/コンソールの脆弱性 • その他の脅威 1.自動デプロイメントツールに対する/経由の攻撃 2.搾取されたコードのレポジトリ 3.搾取されたイメージのレポジトリ 4.不十分/安全でないロギング 5.安全でないシークレット管理 6.リソースの浪費 7.安全でないまたは意図しないデータのキャッシュ
  72. 72 AGENDA • 7. まとめ/Q&A https://www.linkedin.com/in/esasahara https://www.facebook.com/esasahara https://twitter.com/esasahara
Advertisement