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

@esasahara
Cloud Security Alliance
Application Containers and Microservices WG
コンテナ／マイクロサービス／
サーバーレスのセキュリティと監査

2
AGENDA
• 1.コンテナ／マイクロサービス／サーバーレスの監査事例
• 2.コンテナ／マイクロサービス／サーバーレスとは？
• 3.コンテナ／マイクロサービス／サーバーレスにおける
アーキテクトの役割
• 4.アプリケーションコンテナのクラウドセキュリティ
• 5.マイクロサービスのクラウドセキュリティ
• 6.サーバーレスのクラウドセキュリティ
• 7.Q&A

3
AGENDA
• 1.コンテナ／マイクロサービス／サーバーレスの監査事例

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
・厚生労働省「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
・アイルランド保健サービス委員会（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
・オープンソース・テクノロジー・インプルーブメント・ファンド（OSTIF）
「Linux Foundation公衆衛生イニシアティブがCOVID暴露通知
アプリケーションの監査を支援」（2021年1月15日）
• OSTIFが、Linux Foundation公衆衛生イニシアティブ
(LFPH)の支援を受けて、オープンソース化されたCOVID-19
暴露通知アプリケーション（アイルランド発「COVID Green」と
カナダ発「COVID Shield」）に対する監査を実施
• いずれのアプリケーションも、設計における潜在的弱点を特定し、攻
撃者が、ソフトウェアのプライバシー／完全性に対して改ざんしよう
とする方法を特定するために、脅威モデルを開発し、クライアント
ソースコードのレビューを実施
• サーバーサイド・ソフトウェアはスコープ外 7

8
・監査結果
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
• 欧州委員会「承認済アプリケーション間の越境移転チェーンの
ための相互運用性仕様に関するEU加盟国および欧州委員
会向けeヘルスネットワーク・ガイドライン V1.0」
（2020年6月16日）＊2020年10月より実稼働
• シェンゲン協定に基づいた域内経済交流の再開に向けて、接触追
跡アプリケーション越境連携の相互運用性に関わる統一標準規格
として策定 → SAPとドイツテレコムがシステムを構築
• 基本的な相互運用性の要素
• Bluetoothの仕様
• COVID+ Keys（診断キー）
• 利害関係国リスト
• バックエンドサーバーの相互運用性

10
• 欧州委員会「接触追跡アプリケーションの相互運用性に
関する技術仕様V1.0」（2020年6月16日）
• 1. イントロダクション
• 2. アーキテクチャ概要
• 3. 通信
• 4. データ構造（データタイプ、データストレージ）
• 5. インタフェース
• 6. セキュリティ（機密性、完全性、可用性）
• 7. 技術選択
• 8. 監査（全体、データプライバシー、データ転送、トラフィック）
• 9. 分散プライバシー保護接近追跡（DP3T）互換性
• 10.代替データ交換手法（ミラーリング、ブロックチェーン）

11
• 域内共通のフェデレーションゲートウェイサービスの概要
出典：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
• 自律的な各国のバックエンド

13
• 接触追跡アプリケーションの越境連携エコシステム導入例
• コンテナプラットフォーム（例：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

14
• セキュリティ：バックエンドの機密性

15
• 監査：全体
• 監査条件を保証するために、すべての連携ゲートウェイサービスへの
リクエストは、監査ログを生成する監査モジュールを通過させて、
データベース内にログ、イベントストリーム、テーブルを生成するよう
にする
• このデータは、標準的な可視化ツール（例．Tableau、Kibana、
Splunk、Grafana）を経由して、ダッシュボード上に表示すること
ができる

16
• 監査：データプライバシー
• 監査メカニズムの留意点
• GDPR遵守のデータ処理
• 不正アクセスのリスクの低減
• データ主体の権利保護
• 具体的な対策例
• 各国のバックエンドのIDを証明するクライアント認証
• アクティブな信頼性メカニズム：バックエンドは、誰が信頼できるか（ホワ
イトリスト）、信頼できないか（ブラックリスト）を選択する可能性がある
• データアクセスのロギング
• TLSを利用した転送時の暗号化
• データベース保存時の暗号化
• 侵入検知と悪用に関するアラート

17
• 監査：データ転送
• クライアント情報は、クライアント認証や、要求／提出されたデータ
（鍵のオリジン、鍵のデスティネーション）、オペレーションのタイム
スタンプから抽出されて、クライアントやトラフィックの詳細に関する
統計を作成するために利用される
• アップロード／ダウンロードされたすべての情報は、証明可能である
ことが保証される
• 監査：トラフィック
• モニタリング手法
• データベースログ経由
• データベース機能（手動）経由
• 外部のイベントベースのモニタリングツール経由

18
AGENDA
• 2.コンテナ／マイクロサービス／サーバーレスとは？

19
2.コンテナ／マイクロサービス／サーバーレスとは？(1)
米国連邦金融機関検査協議会（FFIEC）
「クラウドコンピューティング環境におけるセキュリティ」
（2020年4月30日）
・クラウドコンピューティング・サービスのリスク管理
出典：FFIEC 「Security in a Cloud Computing Environment」（2020年4月30日）を基にヘルスケアクラウド研究会作成
項目管理策
ガバナンス・金融機関のIT戦略計画やアーキテクチャの一部としてクラウドコンピューティング・サービスを利用するための
戦略
クラウド
セキュリティ
管理
・クラウドサービスプロバイダーのセキュリティに関する適切なデューデリジェンスと継続的な監視・モニタリング
・金融機関およびクラウドサービスプロバイダー向けの契約上の責任、能力、制限
・クラウドコンピューティング環境に存在するシステムおよび情報資産向け在庫プロセス
・セキュリティの構成、プロビジョニング、ロギング、モニタリング
・アイデンティティ／アクセス管理とネットワーク制御
・機微データに対するセキュリティ・コントロール
・情報セキュリティ啓発およびトレーニングプログラム

20
・クラウドコンピューティング・サービスのリスク管理（続き）
項目管理策
変更管理・変更管理およびソフトウェア開発ライフサイクルのプロセス
・マイクロサービス・アーキテクチャ
レジリエンス
と復旧
・ビジネスレジリエンスと復旧の機能
・インシデント対応機能
監査および
コントロー
ルの評価
・重要システムに対する金融機関のコントロールに関する定期的検証
・クラウドサービスプロバイダーが管理するコントロールに関する監視およびモニタリング
・クラウドコンピューティングサービス固有のコントロール
-仮想インフラストラクチャの管理
-クラウドコンピューティング環境におけるコンテナの利用
-クラウドコンピューティング環境向けのマネージド・セキュリティサービス（例．CASB）の利用
-データおよびサービスの相互運用性とポータビリティの考慮
-データの破壊または無毒化
出典：FFIEC 「Security in a Cloud Computing Environment」（2020年4月30日）を基にヘルスケアクラウド研究会作成

21
• クラウドからアプリケーションコンテナ、マイクロサービスへの
移行
APIを軸とする自律サービスの疎結合型アーキテクチャへ
IaaS
PaaS
SaaS
OS
ミドル
ウェア
アプリ
ケー
ション
ミドル
ウェア
アプリ
ケー
ション
アプリケーションコンテナ
コンテナ管理
ソフトウェア
APIゲートウェイ
UI/
UX
UI/
UX
UI/
UX
UI/
UX
処理A
処理B 処理C
データ
データデータ
マイクロサービス
クラウドサービス
出典：ヘルスケアクラウド研究会（2016年1月)

22
• 米国立標準技術研究所（NIST）「SP 800-180(Draft):
NIST マイクロサービス、アプリケーションコンテナ、システム仮想
マシンの定義」（2016年2月）
• アプリケーションコンテナ:
共有OS上で稼働するアプリケーションまたはそのコンポーネントとして
パッケージ化し、稼働するように設計された構成物
• マイクロサービス：
アプリケーション・コンポーネントのアーキテクチャを、疎結合のパターンに
分解した結果生まれる基本的要素であり、標準的な通信プロトコルや
明確に定義された API を利用して相互に通信する自己充足型サービス
を構成し、いかなるベンダー、製品、技術からも独立している

23
• 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
・クラウドにおけるサーバーレスの責任共有モデル
CaaS（Container as a Service）
FaaS（Function as a Service）
出典：CSA「Serverless Computing Security in 2021」（in progress）

25
・FaaS（Function as a Service）の責任共有モデル

26
・CaaS（Container as a Service）の責任共有モデル

27
AGENDA
• 3.コンテナ／マイクロサービス／サーバーレスにおける
アーキテクトの役割

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
[インフラストラクチャ層／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
[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
• クラウドセキュリティアライアンス「安全なマイクロサービスアーキテクチャ実装の
ためのベストプラクティス」（日本語版：2020年11月17日）
• ユースケース例：マイクロサービスへのモノリシック・アプリケーションの分解(1)
視点課題
開発者 1. アプリケーションの断片化が進むと、開発者はマイクロサービスの可視性が低下し、各コンポーネントが他のコン
ポーネントと問題なく動作することを保証するという課題が生じる
2. 相互運用性の確保の観点から、弱いテストケースは、ソフトウェア開発サイクルの後半で可用性とパフォーマン
スの問題のリスクを高める可能性がある
3. モノリスの分解の結果、内部ソフトウェアモジュールは、顧客の利用面に向いているもの、プロセス間通信に関連
する内部ユーティリティまたは中間機能であるもの、記録システムまたは参照システムであるデータストアに向い
ているものに分類されるが、中にはマイクロサービスの採用を妨げる制約の源となりうるものがある
4. マイクロサービスアーキテクチャアプローチはRESTfulなメソッド駆動型のスタイルであり、すべての状況がアプ
ローチに簡単に適合するわけではない（例．SOAPプロトコルバックエンド接続）
5. マイクロサービスのスタイルでは、すべての開発者が「ネットワークプログラミング」の開発者となる
6. 堅牢なマイクロサービステスト、合成データ、および SWAGGER のような API ドキュメンテーションフレーム
ワークがないと、予期せぬセキュリティやパフォーマンスの欠陥につながるコードプロモーションのリスクが高まり、
不注意な情報開示まで含めてリスクが高まる可能性がある

32
• ユースケース：マイクロサービスへのモノリシック・アプリケーションの分解(2)
視点課題
運用者 1. 開発プロセスやステージング、本番環境で使用するための実績のあるコードプロモーションシステムがないと、コード
プロモーションの遅れが増える可能性がある
2. 選択されたマイクロサービス間の柔軟で安全なネットワーク転送を提供することが課題となる可能性がある
3. コンテナが実行されなくなったときに、マイクロサービスが状態を失わないようにするための設計責任を共有している
4. アプリケーションが断片化すると、マイクロサービスアプリケーションの動作を把握できなくなる可能性がある
アーキ
テクト
1. マイクロサービスアーキテクチャに再構築し、それらのマイクロサービスを調整することのコストとメリットのバランスを
見つけるとともに、アジャイル開発クルー、クループログラムマネージャーとスクラムマスター、技術チーム、およびビジネス
ステークホルダーの間で作業するソフトウェアアーキテクトとして実際に機能しているが、ソリューション、インフラストラク
チャ、セキュリティ、データ、ネットワークアーキテクトなど、すべての情報技術アーキテクトがこの役割で機能するわけで
はない
出典：クラウドセキュリティアライアンス「安全なマイクロサービスアーキテクチャ実装のためのベストプラクティス」(2020
年11月17日)を基にヘルスケアクラウド研究会作成

33
• クラウドセキュリティアライアンス
「Microservices Architecture Pattern」
• マイクロサービス参照アーキテクチャ
• アイデンティティ提供
• 検知サービス
• 暗号化サービス
（鍵＆認証管理）
• DevOps／セキュア・ソフトウェア
開発ライフサイクル（CI／CD）
• コンテナのレジストリ
• APIのレジストリ
出典：CSA「Microservices Architecture Pattern」（in progress）

34
• 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
AGENDA
• 4.アプリケーションコンテナのクラウドセキュリティ

36
4.アプリケーションコンテナのクラウドセキュリティ(1)
• 米国NIST 「SP 800-190: アプリケーションコンテナ・
セキュリティガイド」（2017年9月）
• コンテナ技術アーキテクチャ層と構成要素
出典：NIST 「SP 800-190: Application Container Security Guide」（2017年9月）

37
・コンテナ技術のコアコンポーネントのリスク(1)
コンポーネントリスク
イメージ・イメージの脆弱性
・イメージ構成の欠陥
・組込まれたマルウェア
・組込まれた平文の秘密
・信頼できないイメージの使用
レジストリ・セキュアでないレジストリへの接続
・レジストリにおける古いイメージ
・不十分な認証および権限付与の制限
オーケストレーター・制限のない管理者のアクセス
・不正なアクセス
・分離が不十分なコンテナ内のネットワークトラフィック
・ワークロードの機微度レベルの混在
・オーケストレーター・ノードの信頼性
出典：NIST 「SP 800-190: Application Container Security Guide」（2017年9月）を基にヘルスケア
クラウド研究会作成

38
・コンテナ技術のコアコンポーネントのリスク(2)
出典：NIST 「SP 800-190: Application Container Security Guide」（2017年9月）を基にヘルスケア
クラウド研究会作成
コンポーネントリスク
コンテナ・ランタイム・ソフトウェア内の脆弱性
・コンテナからの制限のないネットワークアクセス
・セキュアでないコンテナ・ランタイムの構成
・アプリケーションの脆弱性
・不正なコンテナ
ホストOS ・大規模攻撃の対象領域
・共有されたカーネル
・ホストOSコンポーネントの脆弱性
・不適切なユーザーアクセス権限
・ホストOSのファイルシステムの改ざん

39
• CSA 「クラウドコンピューティングのためのセキュリティ
ガイダンスv4.0」（2017年7月）
• Domain 8：仮想化とコンテナ技術
• 8.1.4 コンテナ
=移植性の高いコード実行環境
[主要コンポーネント]
• 実行環境
• 統合管理とスケジューリングのコントローラ
• コンテナイメージまたは実行するコードのリポジトリ

40
• コンテナのセキュリティ要件
• 利用するコンテナプラットフォームとその下のOSのセキュリティの
ための隔離機能を把握し、適切な設定を選択すること
• コンテナ間の隔離の実施には物理マシンまたは仮想マシンを用い、
同一の物理／仮想ホスト上の同一のセキュリティ要件のコンテナ
はグループ化すること
• 配備対象となるのは、確実に、承認済みで認知済みでセキュアな
コンテナのイメージかコードだけとなるようにすること
• コンテナの統合化・管理およびスケジューラのソフトウェアの
セキュリティを適切に設定すること
• 全てのコンテナとリポジトリ管理に対して、適切なロールベースの
アクセス管理と、強度の高い認証を実装すること。

41
• CSA 「アプリケーションコンテナとマイクロサービスのセキュリ
ティ課題」（2019年7月）
[構成]
• 1. 序論
• 2. アプリケーションコンテナとマイクロサービスの課題
• 3. アプリケーションコンテナとマイクロサービス:
ユースケースと機能
• 4. マイクロサービス

42
• [主旨]
• アプリケーションコンテナとマイクロサービスのアーキテクチャ
は、DevOpsのようなアジャイルソフトウェア開発手法を
活用して、アプリケーションを設計、開発、展開するために
利用される
• セキュリティは、これらのソフトウェア開発手法に組込まれる
必要がある
• 本文書では、開発者、運用者、アーキテクトの視点を通し
て、信頼性のあるセキュアなシステムのエンジニアリングに
おいて、アプリケーションコンテナやマイクロサービスのセキュ
リティに取組む際の課題を特定している

43
• CSA 「安全なアプリケーションコンテナアーキテクチャ実装の
ためのベストプラクティス」（2020年2月）
• アプリケーションコンテナの課題に対するリスク緩和策(1)
No. リスク緩和策
1 環境全体（開発、品質保証、テスト、本番）のコードプロモーション
2 ホストをセキュアにする
3 プラットフォーム/ホストからのコンテナ継続性監視
4 コンテナネットワーク - ホストとコンテナ間の通信
5 コンテナ・ネットワーク - コンテナ間通信
6 イメージの完全性とセキュリティレベルの検証
7 コンテナのフォレンジック
8 コンテナによるトラストチェーン
出典：CSA 「安全なアプリケーションコンテナアーキテクチャ実装のためのベストプラクティス」（2020年2月）を基に
ヘルスケアクラウド研究会作成

44
No. リスク緩和策
9 コンテナのボリューム管理
10 コンテナのシークレット管理
11 プラットフォーム管理 - ライフサイクルイベント通知
12 プラットフォーム管理 - リソース要求
13 プラットフォーム管理 - コンテナリソース管理
14 コンテナ管理 - コンテナリソースのスケーリング
15 コンテナ管理 - データのバックアップとレプリケーション
16 コンテナ管理 – CMP間のコンテナのホスト変更
17 コンテナの暗号化
• アプリケーションコンテナの課題に対するリスク緩和策(2)

45
AGENDA
• 5.マイクロサービスのクラウドセキュリティ

46
5.マイクロサービスのクラウドセキュリティ(1)
• 米国NIST 「SP 800-204: マイクロサービスベースの
アプリケーションシステム向けセキュリティ戦略」（2019年8月）
• マイクロサービスの設計原則
• 個々のマイクロサービスは、他のマイクロサービスから独立して、管理、
複製、スケーリング、アップグレード、展開される
• 個々のマイクロサービスは、単独の機能を有し、制限された環境（例．
制限された責任を有し、他のサービスに依存する）で稼働する
• すべてのマイクロサービスは、一定の障害や復旧のために設計されるべき
であり、可能な限りステートレスである必要がある
• 状況管理のために、既存のトラステッドサービス（例．データベース、
キャッシュ、ディレクトリ）を再利用すべきである

47
• マイクロサービスのコア機能
• 認証とアクセス制御
• サービス・ディスカバリー
• セキュリティ監視・分析
• マイクロサービスのAPIゲートウェイ機能
• 最適化されたエンドポイント
• リクエストやレスポンスの共有、API変換、プロトコル変換
• サーキットブレーカー（遮断機能）
• ロードバランサー（負荷分散）
• レート制限
• ブルー／グリーン・デプロイメント（本番環境と別に新たな本番環境を
構築し、切り替える）
• カナリア・リリース（一部のユーザーから段階的に導入する）

48
• マイクロサービス運用のアーキテクチャ・フレームワーク
アーキテクチャ・フレームワークアーキテクチャ全体における役割
APIゲートウェイ・南北（クライアントとアプリケーション間）・東西（マイクロ
サービス間）のトラフィックを制御するのに使用される（後者
はマイクロゲートウェイを使用）
・マイクロサービスがweb／アプリケーションサーバーに展開さ
れる時、マイクロゲートウェイが導入される
サービス・メッシュ・コンテナを使用してマイクロサービスが展開される時、純粋に
東西のトラフィックのために導入されるが、マイクロサービスが
VMまたはアプリケーションサーバーにハウジングされる状況下
で使用することができる
出典：NIST 「SP 800-204: Security Strategies for Microservices-based Application Systems 」（2019年8月）

49
• マイクロサービスの脅威とセキュリティ戦略(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）

50
• マイクロサービスの脅威とセキュリティ戦略(2)
脅威セキュリティ戦略
完全性の保証・マイクロサービスの最新版の導入（MS-SS-9）
・セッション維持の取扱（MS-SS-10）
ボットネット攻撃への対抗・資格情報の悪用やリスト型攻撃の防止（MS-SS-11）
マイクロサービスのアーキテクチャ・フレーム
ワーク
・APIゲートウェイの展開（MS-SS-12）
・サービス・メッシュの展開（MS-SS-13）

51
• 米国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
・マイクロサービス・ベース・アプリケーションのセキュリティ
項目考慮点
認証と権限付与・認証／アクセスポリシーは、マイクロサービスが呼び出すAPIの種類に依存する
・証明に基づく認証は、公開鍵インフラストラクチャ（PKI)と鍵管理を要求する
サービス・ディスカバリー（サービス
リクエストの間にサービスを発見す
る機能）
・動的に変わるロケーションを持った各サービスに関連して、相当数のサービスと多くのインスタンスが存在
する
・各マイクロサービスには、仮想マシン（VM)またはコンテナとして展開されたものがあり、動的にIPアドレ
スが割り当てられた可能性がある
・サービスに関連するインスタンスの数は、負荷変動によって異なる
ネットワーク・レジリエンス
技術を介した可用性の向上
・ロードバランサー（負荷分散）
・サーキットブレーカー（遮断機能）
・レート制限／調整
・ブルー／グリーン・デプロイメント（本番環境と別に新たな本番環境を構築し、切り替える）
・カナリア・リリース（一部のユーザーから段階的に導入する）
アプリケーション監視の要求事項・分散ロギング、メトリクス生成、分析パフォーマンス、追跡を介したマイクロサービスの内外のネットワー
クトラフィックのモニタリング

53
・サービス・メッシュの定義と技術的背景(1)
項目考慮点
マイクロサービスの機能・ビジネスロジック：ビジネス機能、計算処理、サービス構成／統合
・ネットワーク機能：サービス間の通信メカニズム
サービス・メッシュのコン
ポーネント
データプレーン：アプリケーションからのリクエストをフォワードする機能を提供するデータパス
コントロールプレーン：メッシュに渡ってデータプレーン（プロキシ）の行動を制御・構成するために
使用されるAPIツール類
サービス・メッシュの機
能
・認証と権限付与
・サービスディスカバリー
・セキュアなコミュニケーション
・コミュニケーション向けのレジリエンス／安定性機能

54
項目考慮点
Ingressコントロー
ラー
・サービスメッシュ内部にある実際のAPIを覆っているすべてのクライアント向けの共通API
・HTTP／HTTPSのようなwebに適したプロトコルから、RPC／gRPC／RESTのようなマイクロサー
ビスが使用するプロトコルへのプロトコル変換
・クライアントからのシングルコールに対応して、サービスメッシュ内部の複数サービスへのコールから受け
取った結果の構成
・負荷分散
・パブリックTLS終了
Egressコントロー
ラー
・メッシュ外にあるマイクロサービス向けのマイクロサービスから発生する内部トラフィックをコントロールす
るサービス・プロキシ
・外部ネットワークへの通信をホワイトリスト化する単一セットのワークロード（例．ホスト、IPアドレス）
・資格情報の交換：外部システムの資格情報に直接アクセスするアプリケーションなしに、内部のID資
格情報から外部の資格情報（例．SSOトークン、API鍵）に変換する
・webに適したプロトコル（例．HTTP／HTTPS）から、マイクロサービスに適したプロトコル（例．
RPC／gRPC／REST）へのプロトコル変換

55
項目考慮点
通信ミドルウェアとし
てのサービス・メッ
シュ：相違点
・伝統的な分散システム向けミドルウェア：アプリケーションデリバリー・コントローラー（ADC)、負荷分
散装置、APIゲートウェイ
・マイクロサービスの通信トラフィックの特徴：「東西」＞「南北」
• 「南北」トラフィック：クライアントとアプリケーション間の通信トラフィック
• 「東西」トラフィック：マイクロサービス間の通信トラフィック
・軽量通信ミドルウェアとしてのサービス・メッシュ：プロダクションアプリケーションとして許容できるパ
フォーマンス・レベルが要求される
・クラウドネイティブ・アプリケーションの機能として、マイクロサービス・アプリケーションが、コンテナなしで
導入されるケース：サービスベース・アーキテクチャ、APIドリブン通信、コンテナベース・インフラストラク
チャ、DevOpsプロセスに関するバイアスなど
サービス・メッシュ：最
先端の手法
・各マイクロサービスをコンテナとして展開する
・アプリケーションは、コンテナ・オーケストレーション・ツールを利用して管理されるコンテナ・クラスター（可
用性とパフォーマンスの向上目的）を活用する
・クラウドプロバイダーが提供し、コンテナ管理／オーケストレーション環境に必要な展開／構成ツールを
有するContainer as a Service (CaaS) 経由で、アプリケーションをホストする

56
・サービス・メッシュ展開の推奨事項
• サービス・プロキシー向け通信構成（1）
項目推奨事項概要
SM-
DR1
サービス・プロキシーに
許容されたトラフィック
に関する推奨事項
サービス・プロキシーが関連サービス向けのトラフィックを受容できるプロトコルおよびポートの
セットを指定する機能があるべきである。デフォルトで、サービス・プロキシは、この構成により
指定された通り、トラフィックの例外を許容スべきでない。
SM-
DR2
サービス・プロキシーの
到達可能性に関する
推奨事項
サービス・プロキシーが到達できるサービス・セットは制限されるべきである。名前空間、すなわ
ち所与の名前空間またはサービスのランタイム・アイデンティティ内で特別に命名されたサービ
スに基づいてアクセスを制限する機能があるべきである。サービス・メッシュのコントロール・プ
レーンへのアクセスは、常に、リレー・ディスカバリー、異なるポリシー、テレメトリーデータに提
供されるべきである。
SM-
DR3
プロトコル転送機能に
関する推奨事項
サービス・プロキシーは、ターゲットのマイクロサービスよりも、クライアントの異なるプロトコル
との通信を支援する組込み機能を有するべきである（例．REST／HTTPリクエストからｇ
RPCリクエストへの変換またはHTTP／1.1からHTTP／2への更新）。これにより、攻撃表
面を増加させる、クライアントごとに分離したサーバー構築へのニーズを回避することが要求
される。

57
・サービス・プロキシー向け通信構成（2）
SM-
DR4
ユーザーの拡張可能
性に関する推奨事項
サービス・プロキシーは、ネットワーク機能を処理する組込ロジックに加えて、カスタム・ロジック
を定義するための機能を有するべきである。これにより、ユースケース固有のポリシー（例．
予め存在するまたは自家製のポリシー・エンジン）を展開するために、サービス・プロキシーを
拡張できることの保証が要求される。この展開では、サンドボックス化、使用する言語のAPI
／ランタイム制限、または安全を保証する事前分析の実行（例．WASM、eBPF）など、
拡張性のリスクをコントールする手段を提供すべきである。
SM-
DR5
プロキシー向け動的構
成機能に関する推奨
事項
静的構成に加えて、動的にプロキシーを構成する（例．イベント・ドリブン構成アップデー
ト）選択肢があるべきである。言い換えれば、既知の展開時よりも、動的であることが見込
まれる主体向けのディスカバリー・サービスがあるべきである。さらに、従来の構成下で未解
決のリクエストを効率的に処理する（例．完了または終了）一方、プロキシーはランタイム
時、新たな動的構成へ原子的に交換すべきである。これにより、ユーザートラフィックの劣化や
ダウンタイムなく（例．サービス・プロキシーを再起動することなく）、ランタイム時、迅速にポ
リシー変更を強制することが要求される。
SM-
DR6
アプリケーション・サー
ビスとプロキシー間の
通信構成に関する推
奨事項
アプリケーション・サービスおよびその関連プロキシーは、ループバック・チャンネル（例．ロー
カルホストIPアドレス、UNIXドメイン・ソケットなど）経由のみで通信すべきである。さらに、
サービス・プロキシーは、すべての交換データ・パケットが暗号化された相互TLS（mTLS）
セッションを設定することによってのみ個々の通信を行うべきである。

58
・Ingressプロキシー向け構成
SM-
DR7
Ingressプロキシー
サービス・プロキシーのように、Ingress（スタンドアロン）プロキシー向けにトラフィック・
ルーティング・ポリシーを構成する機能を有すべきである。アプリケーション・ディプロイメントの
エッジまで幅広くルーティング・ポリシーの一貫した強制が要求されるため、これが必要とされ
る。

59
・外部サービスへのアクセス向け構成
SM-
DR8
外部リソースへのアク
セス制限に関する推
奨事項
外部リソースまたはメッシュ外部のサービスへのアクセスは、デフォルトで無効化し、特定の目
的地へのアクセスを制限する明示的ポリシーよってのみ許容されるべきである。加えて、外部
リソースまたはサービスは、サービス・メッシュ自体のサービス（例．サービス・メッシュのサービ
ス・ディスカバリー・メカニズムに含まれる）としてモデル化すべきである。
SM-
DR9
外部リソースへのセ
キュアなアクセスに関
する推奨事項
サービス・メッシュ内部のサービス向けに構成される、同様の可用性向上機能（例．タイムア
ウト、サーキットブレーカー）が、外部リソースおよびサービスへのアクセス向けに提供される
べきである。
SM-
DR10
Egressプロキシーに
サービスおよびIngressプロキシーのように、Egress（スタンドアロン）プロキシー向けにト
ラフィック・ルーティング・ポリシーを構成する機能を有すべきである。ディプロイされた時、外部
リソースおよびサービスへのアクセスは、これらEgressプロキシーにより調整されるべきである。
Egressプロキシーは、アクセスおよび可用性のポリシー（SM-DR8）を展開スべきである。
これは、伝統的なネットワークに基づくセキュリティ・モデルとともに作業するのに役立つ。たとえ
ば、インターネットへのアウトバウンド・トラフィックが、ネットワーク内の特定のIPからのみ許
容されると仮定する；Egressプロキシーは、メッシュにおける一連のサービス向けのトラフィッ
クを代理する一方、そのアドレスとともに稼働するよう構成することができる。

60
• アイデンティティ／アクセス管理向け構成（1）
SM-
DR11
ユニバーサル・アイデ
ンティティ・ドメインに
マイクロサービスのすべてのインスタンスのアイデンティティは、一貫性があり一意であるべきである－稼働
場所に関係なく共通の名前を有すべきであるという点で一貫性があり、システム全体に渡ってという点で
一意であり、サービス名がそのサービスに対応してさえすればよい。これは、異なるロケーションに異なる論
理的サービスがあることを意味しているのではない；個々のサービスに各自のDNS名が割り当てられた、
典型的なドメインネームシステム（DNS)の利用は、この推奨事項を満たしている。サービス向けの一貫
した名前（アイデンティティ）では、システムポリシーが管理可能であることが要求される。
SM-
DR12
証明書の展開の署
名に関する推奨事項
サービス・メッシュのコントロールプレーン証明管理システムでは、自己署名により証明を生成する機能を
停止すべきである。この機能は、サービス・メッシュにおいて、他のすべてのアイデンティティ証明向けにイニ
シャルサインを自動実行するために、しばしば利用される。その代わり、メッシュのコントロールプレーンで
利用される署名証明が、常に企業の既存のPKIの信頼の基点（Root of Trust）に根付いたもので
ある必要がある。これは、既存のPKI（例．失効または監査向け）により、証明の管理を簡素化する
ものである。さらに、我々は、ローテーションを簡素化し、きめの細かい失効を可能にするために、別個の
中間署名証明が異なるドメイン向けに生成されるべきことを推奨している。
SM-
DR13
アイデンティティ証明
書の更新に関する推
奨事項
マイクロサービスのアイデンティティ証明の有効期間は、インフラストラクチャ内部で管理可能なように、
可能な限り短く－できれば時間の順序に従うべきである。攻撃者は、資格情報が失効するまでの間、資
格情報を利用しさえすればサービスになりすますことができるが、資格情報を成功裏に再び奪うことは、
攻撃者にとってますます難しくなっているので、この方法は攻撃を制限するのに役立つ。

61
SM-
DR14
アイデンティティ変更
におけるサービス・プ
ロキシーのサイクル接
続に関する推奨事項
サービス・プロキシーのアイデンティティ証明がローテーションしている時、サービス・プロキシーは、既存の
コネクションを効率的に終了して、新たな証明とともに、すべての新たなコネクションを設定すべきである。
証明書は、mTLSのハンドシェイクの間のみ有効なので、新たな証明が発行された時に既存のコネク
ションを置き換えることは厳格に要求されない；むしろ、遅れずに攻撃を制限するために重要である。
SM-
DR15
アイデンティティ証明
書に署名しない場合
の推奨事項
マイクロサービスを識別するために利用される証明書は、署名認証であってはならない。
SM-
DR16
証明書発行前の
ワークロード認証に
サービス・メッシュのコントロールプレーンの証明管理システムは、アイデンティティ証明を発行する前に、
サービス・インスタンスの認証を実行すべきである。多くのシステムでは、システムのオーケストレーション・エ
ンジンに対するインスタンスを証明し、他のローカル証明（例．HSMから収集した鍵）を利用することに
よって、これが達成可能となる。
SM-
DR17
セキュアなネーミング
サービスに関する推
奨事項
mTLSに利用される証明が、サーバー・アイデンティティを実行したら、サーバー・メッシュは、セキュアな
ディスカバリー・サービスまたはDNSによって提供されるマイクロサービス名に、サーバー・アイデンティティ
をマッピングするセキュアな命名サービスを提供スべきである。この要求事項は、サーバーがマイクロサービ
ス向けに認可されたロケーションであることを保証し、ネットワークハイジャックから保護するために必要で
ある。

62
SM-
DR18
きめ細かいアイデン
ティティに関する推奨
事項
個々のマイクロサービスは、各自のアイデンティティを有すべきであり、このサービスのすべてのインスタンス
は、ランタイム時に同じアイデンティティを示すべきである。これにより、所与の名前空間において、マイクロ
サービスのレベルでアクセスポリシーが適用されることが可能となる。これが要求されることによって、サービ
スごとでなく、名前空間ごとにアイデンティティを発行することが、共通のマイクロサービスのランタイムにお
けるデフォルトとなり、同一の名前空間にあるすべてのサービスが、特に指定されない限り、共通のランタ
イムのアイデンティティとなる。加えて、ラベルは、サービス名（アイデンティティ）を増大させて、きめの細
かいロギング構成を可能にし、きめの細かい認可ポリシーをサポートするために、利用することができる。
SM-
DR19
認証ポリシーのス
コープに関する推奨
事項
認証のポリシー・スコープを指定する機能は、最低限、以下の選択肢を有すべきである：(a)すべての名
前空間におけるすべてのマイクロサービス、(b)特別な名前空間におけるすべてのマイクロサービス、(c)
所与の名前空間における特定のマイクロサービス（SM-DR17で参照したランタイム・アイデンティティ
を利用）。
SM-
DR20
認証トークンに関す
る推奨事項
トークンは、その中に含まれる要求が認証を保証するように、デジタル的に署名・暗号化されるべきであり、
アクセスコントロールに関する意思決定を構築するために、認証されたアイデンティティの増強またはその
一部として利用することができる。さらに、これらのトークンは、ループバック・デバイス経由（ネットワーク・
パスが含まれていないことを保証するため）または暗号化されたチャンネル経由のみで通過させるべきで
ある。

63
• 監視機能向け構成
SM-
DR21
イベントのロギングに
プロキシは、入力の妥当性エラーおよび特別な（予期しない）パラメーターのエラー、クラッシュ、コアダ
ンプをロギングすべきである。共通の攻撃検知機能には、Bearerトークン再利用攻撃およびインジェク
ション攻撃が含まれるべきである。
SM-
DR22
リクエストのロギング
プロキシは、少なくとも、不規則なリクエスト（例．HTTP使用時の200番以外のレスポンス）向けの
共通ログ形式フィールドをロギングすべきである。成功したリクエスト（例．200番レスポンス）のロギン
グは、メトリックが利用可能な時、ほとんど意味がない傾向がある。
SM-
DR22
ログメッセージのコン
テンツに関する推奨
事項
ログメッセージは、最低限、イベントの日時、マイクロサービス名またはアイデンティティ、リクエストトレー
スID、メッセージおよびその他コンテキスト情報（例．ユーザー識別子とURLのリクエスト時）を含むべ
きである。しかしながら、たとえばBearerトークンなど、機微な情報を覆うために注意を払うべきである。
SM-
DR23
必須指標に関する推
奨事項
外部クライアントおよびマイクロサービスの呼び出し向けにサービス・メッシュを使用してメトリックを収集
するための構成には、最低限、(a)所与の期間におけるクライアント／サービスのリクエスト数、
(b)failureコードによる失敗したクライアント／サービスのリクエスト数、(c)サービス当たりの平均レー
テンシーおよび完了リクエストのライフサイクル当たり平均総レーテンシー（理想的にはヒストグラム；ま
たはfailureコードによる）を含むべきである。
SM-
DR24
分散トレーシングの
展開に関する推奨事
項
分散トレーシングの展開向けにサービス・プロキシを構成する時、アプリケーション・サービスが、受け取っ
た通信パケットのヘッダーを転送するように設定されていることを確認するよう注意を払うべきである。

64
• ネットワーク・レジリエンス向け構成
SM-
DR25
サービス・インスタンス
のヘルスチェックの展開
再試行、タイムアウト、サーキットブレーカーまたはカナリア・デプロイメントに関連するデータ
（一般的にすべてのコントロールプレーン構成データ）は、キーバリューストアのような、堅
牢なデータストアに保存スべきである。
SM-
DR26
サービス・インスタンス
のヘルスチェックの展開
再試行、タイムアウト、サーキットブレーカーまたはカナリア・デプロイメントに関連するデータ
（一般的にすべてのコントロールプレーン構成データ）は、キーバリューストアのような、堅
牢なデータストアに保存スべきである。
SM-
DR27
オリジン間リソース共
有(CORS)に関する
推奨事項
エッジサービス（例．マイクロサービスのエントリーポイント）は、web UIクライアント・サー
ビスとしてのように、外部サービスと通信するCORS向けに構成されることがしばしばあり得る。
エッジサービス向けのCORSポリシーは、マイクロサービス・アプリケーション・サービスのコード
を経由して処理するよりも、サービス・メッシュ機能（例．IstioにおけるVirtualServiceリ
ソースのCorsPolicy構成）を利用して構成されるべきである。
• オリジン間リソース共有(CORS)向け構成

65
• 管理運用向け許可の構成
SM-
DR28
管理運用向けアクセ
ス・コントロールに関
する推奨事項
名前空間、名前空間内で命名されたサービスなど、すべてのサービスレベルで指定可能な、
サービス・メッシュにおける全管理運用向けの粒度の細かいアクセス・コントロール許可（例．
ポリシー指定、サービス・レジリエンシー・パラメーター向けの構成パラメーター、カナリア・デプ
ロイメント、再試行など）を有すべきである。一般的に、この機能を実行するインタフェースは、
サービス・メッシュ自体の一部でなく、アプリケーションサービス・クラスターの構成に利用され
るインストール用ソフトウェアまたはオーケストレーション・ソフトウェアの一部であることがある。

66
AGENDA
• 6.サーバーレスのクラウドセキュリティ

67
6.サーバーレスのクラウドセキュリティ(1)
• CSA 「2021年サーバーレスコンピューティング・セキュリティ」
• FaaS（Function as a Service）アーキテクチャの概要

68
• CaaS（Container as a Service）アーキテクチャの概要

69
• サーバーレスの責任共有モデル

70
• サーバーレスアプリケーションの脅威
1.環境の構成ミス
• a. ユーザーの構成管理ミス
• b. ポートの露出
• c. 無効化／デフォルト構成
• d. 資格情報の露出
• e. 構成ドリフト
2.脆弱な依存関係
• a. サプライチェーンの脆弱性
• b. 脆弱なイメージ
3.組込型マルウェア
4.ランタイムの課題
• a. データのインジェクションとリモートからの実行
• b. 認証の不備
• c. 不適切なエラーや例外の処理

71
• CaaSプラットフォーム共通の脅威
1.コンテナ化とオーケストレーションの脅威
• a. コンテナ化／オーケストレーションツールの脆弱性
• b. コンテナ化／オーケストレーションAPIの悪用
2.不適切に割り当てられた無制限／管理権限アクセス
3.不正アクセス
4.ポータル／コンソールの脆弱性
• その他の脅威
1.自動デプロイメントツールに対する／経由の攻撃
2.搾取されたコードのレポジトリ
3.搾取されたイメージのレポジトリ
4.不十分／安全でないロギング
5.安全でないシークレット管理
6.リソースの浪費
7.安全でないまたは意図しないデータのキャッシュ

72
AGENDA
• 7. まとめ／Q&A
https://www.linkedin.com/in/esasahara
https://www.facebook.com/esasahara
https://twitter.com/esasahara

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

More Related Content

What's hot

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

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

Recently uploaded

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