1. @esasahara
Cloud Security Alliance
Application Containers and Microservices WG
エッジ／フォグコンピューティング環境における
コンテナ／マイクロサービスのメリットとリスク

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

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

4. 4
クラウドセキュリティアライアンス
アプリケーションコンテナ／マイクロサービスWGのご紹介
[目的]
セキュアなアプリケーションコンテナおよびマイクロサービス利用の
ためのガイダンスやベストプラクティスを発行する
アプリケーションコンテナおよびマイクロサービスのセキュリティに
関する啓発活動を行う
[WGリーダー]
Anil Karmel（NIST SP 800-180(Draft) 筆頭著者）
Andrew Wild（QTS Data Centers・CISO)

5. 5
クラウドセキュリティアライアンス
アプリケーションコンテナ／マイクロサービスWGの
作成ドキュメント例
“Challenges in Securing Application
Containers”(2019年7月発行）
“Best Practices for Implementing a
Secure Microservices Architecture”
(2019年7月発行）
“A Unified Standard for the
Microservices Architecture”（作成中）

6. 6
AGENDA
1. ユースケースに学ぶエッジ／フォグコンピューティングの利点と脅威
～エッジ層 Vs. ネットワーク層 Vs. クラウド層～
2. ユースケースに学ぶアプリケーションコンテナの利点と脅威
～インフラストラクチャ層 Vs. アプリケーション層～
3. ユースケースに学ぶマイクロサービスの利点と脅威
～APIゲートウェイ Vs. サービス・メッシュ～
4. エッジ／フォグコンピューティング × コンテナ／マイクロサービスで
求められるセキュリティと人材像
～情報通信技術（IT） Vs. 電子制御技術（OT）～
5. Q&A

7. 7
AGENDA
• 1. ユースケースに学ぶエッジ／フォグコンピューティング
の利点と脅威
～エッジ層 Vs. ネットワーク層 Vs. クラウド層～

8. 8
1-1.エッジコンピューティングとは?(1)
• 米国立標準技術研究所（NIST）「エッジコンピューティングの
公式定義：モバイルクラウドとIoTの構成の強調」
（2018年6月5日）
• [モバイルクラウドコンピューティング（MCC）のグローバル
アーキテクチャ]
出典：U.S. National Institute of Standards and Technology (NIST)「Formal Definition of Edge
Computing: An Emphasis on Mobile Cloud and IoT Composition」（2018年6月5日）
インターネット層
クラウドレット層
デバイス層

9. 9
1-1.エッジコンピューティングとは?(2)
• [クラウドレット層の構造とネットワーキング]
出典：U.S. National Institute of Standards and Technology (NIST)「Formal Definition of Edge
Computing: An Emphasis on Mobile Cloud and IoT Composition」（2018年6月5日）

10. 10
1-1.エッジコンピューティングとは?(3)
• [デバイスの仮想デバイス表示（DVDR)の展開モデル]
出典：U.S. National Institute of Standards and Technology (NIST)「Formal Definition of Edge
Computing: An Emphasis on Mobile Cloud and IoT Composition」（2018年6月5日）

11. 11
1-2.フォグコンピューティングとは?(1)
• 米国立標準技術研究所（NIST）「SP 500-325：フォグ
コンピューティング概念モデル」（2018年3月19日）
• フォグコンピューティング＝拡張可能な電算処理リソースを共有する
連続体へのユビキタスなアクセスを可能にする階層化モデル
• サポートされたアプリケーションから／へのレスポンスタイムを最小化
し、エンドデバイス向けにローカルな電算処理リソースを提供し、必
要な時、集中化されたサービスへのネットワーク接続を提供する
• [構成要素]
• 集中化されたクラウドサービス
• フォグノード（物理的or仮想的）
• スマート・エンドデバイス

12. 12
1-2.フォグコンピューティングとは?(2)
• スマート・エンドデバイスのクラウドベース・エコシステムをサポート
するフォグコンピューティングの全体イメージ
出典：U.S. National Institute of Standards and Technology (NIST)
「NIST SP 500-325, Fog Computing Conceptual Model」（2018年3月19日）

13. 13
1-3.エッジ／フォグコンピューティングのユースケース(1)
• Soraia Oueida et al.「リソース管理向けエッジコンピューティング
ベースのスマートヘルスケア・フレームワーク」（2018年12月6日）
Sensors 2018, 18, 4307; doi:10.3390/s18124307
• エッジベースのスマート
ヘルスケア・フレーム
ワークモデル
出典：Sensors 2018, 18, 4307;
doi:10.3390/s18124307（2018年12月6日）

14. 14
1-3.エッジ／フォグコンピューティングのユースケース(2)
• ヘルスケア・リソース・ワークフローの全体像
出典：Sensors 2018, 18, 4307; doi:10.3390/s18124307（2018年12月6日）

15. 15
1-4. クラウドネイティブのIoTセキュリティ(3)
・Cloud Security Alliance「IoT早期導入者のためのセキュリティガ
イダンス 」（2015年4月）
• IoTの
全体像
出典：Cloud Security Alliance「IoT早期導入者のためのセキュリティガイダンス 」（2015年4月）

16. 16
1-4. クラウドネイティブのIoTセキュリティ(4)
・IoTのエコシステム
出典：Cloud Security Alliance「IoT早期導入者のためのセキュリティガイダンス 」（2015年4月）

17. 17
1-4. クラウドネイティブのIoTセキュリティ(5)
• IoTセキュリティの管理策
出典：Cloud Security Alliance「IoT早期導入者のためのセキュリティガイダンス 」（2015年4月）

18. 18
AGENDA
• 2. ユースケースに学ぶアプリケーションコンテナの
利点と脅威
～インフラストラクチャ層 Vs. アプリケーション層～

19. 19
2-1. エッジコンピューティング向けコンテナのユースケース(1)
• Sanil Kumar D et al. 「KubeEdge, Kubernetesネイティブ
のエッジコンピューティング・フレームワーク」（2019年3月19日）
https://kubernetes.io/blog/2019/03/19/kubeedge-k8s-based-edge-intro/
• KubeEdgeの
アーキテクチャ
出典：Sanil Kumar D et al.
「KubeEdge, a Kubernetes
Native Edge Computing
Framework」
（2019年3月19日）

20. 20
2-1. エッジコンピューティング向けコンテナのユースケース(2)
• KubeEdgeのコンポーネント
• Edged：エッジ側でコンテナ化されたアプリケーションを管理
• Edge Hub：エッジ側の通信インタフェース・モジュール
• Cloud Hub：クラウド側の通信インタフェース・モジュール
• Edge Controller：エッジノードの管理
• Event Bus：MQTTを使用して、内部のエッジ通信を処理
• Device Twin：デバイスのメタデータを処理するデバイス向け
ソフトウェア・ミラー
• Meta Manager：エッジノードでメタデータを管理

21. 21
2-2.インダストリー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ノード
• ネットワーク・通信
出典：Sanil Kumar D et al. 「A Fog-Cloud Computing
Infrastructure for Condition Monitoring and
Distributing Industry 4.0 Services」（2019年5月2-4日）

22. 22
2-2.インダストリー4.0向けフォグ×クラウドのユースケース(2)
• アーキテクチャの要件
出典：Sanil Kumar D et al. 「A Fog-Cloud Computing Infrastructure for Condition Monitoring and Distributing
Industry 4.0 Services」（2019年5月2-4日）を基にヘルスケアクラウド研究会作成
項目 要件
インダストリー
4.0サービスの開
発
R1. クラウド-フォグノード間の分散データ処理タスクのサポート
R2. 適切なノード管理、ノード間通信、タスクの実行を提供するために必要なすべての機能
の提供
計測探針（プ
ローブ）の統合
R3. ノード上での計測探針の統合・展開によるノード状態の決定
R4. 集中型および分散型計測探針に対するサポートの提供
R5. 利用する実際の技術に関係なく、全ノード上に計測探針およびサービスを実行する統
一的手法の提供
R6. 実行中に計測探針およびサービスを移行するのに適した、一貫性のある実行環境を提
供する
ディストリビュー
ション・アルゴリズ
ムの統合
R7. 適宜、アプリケーションサービスを展開するために計測結果を利用するディストリビュー
ション・アルゴリズムの統合
R8. 異なるディストリビューション・アルゴリズムを適用し、構成するための共通インタフェース
の提供

23. 23
2-2.インダストリー4.0向けフォグ×クラウドのユースケース(3)
• アーキテクチャの全体像
出典：Sanil Kumar D et al. 「A Fog-Cloud Computing Infrastructure for Condition Monitoring and Distributing
Industry 4.0 Services」（2019年5月2-4日）

24. 24
2-2.インダストリー4.0向けフォグ×クラウドのユースケース(4)
• デプロイメントのアーキテクチャ
• インタフェースサービスの利用
• インプットを渡す
• Dockerファイルの生成
• Dockerイメージのアップロード
• デプロイメントを渡す・構成
• 計測データの要求
• デプロイメントアルゴリズムの適用
• デプロイメント決定を渡す
• デプロイメントファイルの生成
• デプロイメントファイルを渡す
• Dockerイメージの要求
• デプロイメントの初期化
• アプリケーションポッドのデプロイ
出典：Sanil Kumar D et al. 「A Fog-Cloud Computing
Infrastructure for Condition Monitoring and Distributing Industry
4.0 Services」（2019年5月2-4日）

25. 25
2-2.インダストリー4.0向けフォグ×クラウドのユースケース(5)
• アプリケーション事例
出典：Sanil Kumar D et al. 「A Fog-Cloud Computing Infrastructure for Condition Monitoring and Distributing
Industry 4.0 Services」（2019年5月2-4日）

26. 26
2-2.インダストリー4.0向けフォグ×クラウドのユースケース(6)
• ディストリビューションアルゴリズムの
ディシジョンツリー事例
• 特定のノードタイプを要求するか
• タスクはタイムセンシティブか
• センシティブなデータは含まれて
いるか
• 特定のセキュリティレベルを要求
するか
• 計算処理集約型か
出典：Sanil Kumar D et al. 「A Fog-Cloud Computing
Infrastructure for Condition Monitoring and Distributing
Industry 4.0 Services」（2019年5月2-4日）

27. 27
2-3.医療分野のアプリケーションコンテナのユースケース
• Srini Bhagavan et al.「データ集約的なクラウドベースの医療
アプリケーション設計のケース」（2018年10月9日）
Proceedings of the First International Workshop on Semantic Web Technologies for Health
Data Management (SWH 2018)(http://ceur-ws.org/Vol-2164/paper7.pdf)
• クラウド上の医療
アプリケーション設計
向けアーキテクチャ
• ハイブリッドクラウド
上で、コンテナ
(Kubernetes）
を利用
出典：Proceedings of the First International Workshop on Semantic Web Technologies for Health
Data Management (SWH 2018), Paper7（2018年10月9日）

28. 28
2-4.アプリケーションコンテナとセキュリティ(1)
• コンテナ=移植性の高いコード実行環境
[主要コンポーネント]
• 実行環境
• 統合管理とスケジューリングのコントローラ
• コンテナイメージまたは実行するコードのリポジトリ
• コンテナのセキュリティ要件
• 基盤となる物理インフラ（コンピューティング、ネットワーク、
ストレージ）のセキュリティを確保する
• イメージリポジトリを適切に保護する
• コンテナ内で実行されているタスク／コードにセキュリティを組込む

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

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

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

32. 32
AGENDA
• 3. ユースケースに学ぶマイクロサービスの利点と脅威
～APIゲートウェイ Vs. サービス・メッシュ～

33. 33
3-1. コネクテッドカー向けマイクロサービスのユースケース(1)
• Salman Taherizadeh 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日）

34. 34
3-1. コネクテッドカー向けマイクロサービスのユースケース(2)
• 異なるレイヤ間のマイクロサービスのオンロード化／オフロード化
出典：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
クラウド層
フォグ層
エッジ層

35. 35
3-1. コネクテッドカー向けマイクロサービスのユースケース(3)
• スマートIoTアプリケーション向け毛細管分散型コンピューティング
アーキテクチャ
出典：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

36. 36
3-1. コネクテッドカー向けマイクロサービスのユースケース(4)
• 毛細管コンピューティングアーキテクチャが実行するオン／
オフロード化シナリオのシーケンス図
出典：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

37. 37
3-1. コネクテッドカー向けマイクロサービスのユースケース(5)
• エッジノード：モーターホーム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

38. 38
3-1. コネクテッドカー向けマイクロサービスのユースケース(6)
• 2つのフォグノードが提供するノード選択ランク（NSR）の値
出典：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

39. 39
3-1. コネクテッドカー向けマイクロサービスのユースケース(7)
• 毛細管コンピューティングアーキテクチャが提供する
サービスレスポンスタイム
出典：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

40. 40
3-1. コネクテッドカー向けマイクロサービスのユースケース(8)
• インテリジェントでない手法が提供するサービスレスポンスタイム
出典：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

41. 41
3-1. コネクテッドカー向けマイクロサービスのユースケース(9)
• エッジ、フォグ、クラウド
インフラストラクチャが
提供するレスポンス
タイムの累積分布
関数（CDF)
出典：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

42. 42
3-2. マイクロサービスのセキュリティ (1)
• 米国NIST 「SP 800-204(Draft): Security Strategies
for Microservices-based Application Systems」
（2019年3月）
• 伝統的なモノリシック(一枚岩)・アーキテクチャのネット通販
アプリケーション
出典：NIST “SP 800-
204(Draft): Security
Strategies for
Microservices-based
Application Systems ”
（2019年3月）

43. 43
3-2. マイクロサービスのセキュリティ(2)
・マイクロサービス・アーキテクチャのネット通販アプリケーション
出典：NIST “SP 800-204(Draft): Security Strategies for Microservices-based
Application Systems ”（2019年3月）

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

45. 45
3-2. マイクロサービスのセキュリティ(4)
• マイクロサービスの脅威とセキュリティ戦略
脅威 セキュリティ戦略
アイデンティティ／アクセス管理 ・認証（MS-SS-1）
・アクセス管理（MS-SS-2）
サービス・ディスカバリーの
メカニズム
・サービスレジストリ構成（MS-SS-3）
セキュアな通信プロトコル ・セキュアな通信（MS-SS-4）
セキュリティモニタリング ・セキュリティモニタリング（MS-SS-5）
遮断機能の展開 ・遮断機能の展開（MS-SS-6）
ロードバランシング ・ロードバランシング（MS-SS-7）
レート制限 ・レート制限（MS-SS-8）
出典：NIST “SP 800-204(Draft): Security Strategies for Microservices-based
Application Systems ”（2019年3月）

46. 46
3-2. マイクロサービスのセキュリティ(5)
• マイクロサービスの脅威とセキュリティ戦略(続き）
脅威 セキュリティ戦略
完全性の保証 ・マイクロサービスの最新版の導入（MS-SS-9）
・セッション維持の取扱（MS-SS-10）
ボットネット攻撃への対抗 ・資格情報の悪用やリスト型攻撃の防止（MS-SS-11）
マイクロサービスのアーキテク
チャ・フレームワーク
・APIゲートウェイの展開（MS-SS-12）
・サービス・メッシュの展開（MS-SS-13）
出典：NIST “SP 800-204(Draft): Security Strategies for Microservices-based
Application Systems ”（2019年3月）

47. 47
3-2. マイクロサービスのセキュリティ(6)
• OWASP「OWASP APIs Security Project Kick
Off」(2019年5月）
https://www.owasp.org/index.php/OWASP_API_Security_Project
1. オブジェクトレベルのアクセスコントロールの不備
2. 認証の不備
3. 不適切なデータフィルタリング
4. リソース不足とレート制限
5. 機能／リソースレベルのアクセスコントロールの欠如
6. 一括代入
7. セキュリティ構成ミス
8. インジェクション
9. 不適切な資産管理
10. 不十分なロギング・モニタリング

48. 48
3-2. マイクロサービスのセキュリティ(7)
• Cloud Native Computing Foundation (CNCF)
「サービスメッシュでマイクロサービスのセキュリティを簡素化
する」(2019年4月25日）
https://www.cncf.io/blog/2019/04/25/simplifying-microservices-security-with-a-service-mesh/
サービスメッシュでマイクロサービスのセキュリティを簡素化する
のに役立つ機能
1. 認証
2.権限付与
3.ゼロトラスト

49. 49
AGENDA
• 4. エッジ／フォグコンピューティング × コンテナ／
マイクロサービスで求められるセキュリティと人材像
～情報通信技術（IT） Vs. 電子制御技術（OT）～

50. 50
4-1. 包括的サイバーセキュリティ人材育成フレームワーク(1)
・米国立標準技術研究所（NIST）「SP 800-181:全米
サイバーセキュリティ教育イニシアティブ（NICE)サイバーセ
キュリティ人材フレームワーク」（2017年8月）
• サイバーセキュリティ人材に
求められる役割(Role)と
業務(Task)、その役割や
業務の遂行に必要とされる
具体的な知識(Knowledge)・
技術(Skill)・能力(Ability)を
定義
出典：NIST Special Publication 800-181 National Initiative for Cybersecurity
Education (NICE) Cybersecurity Workforce Framework （2017年8月）

51. 51
4-1. 包括的サイバーセキュリティ人材育成フレームワーク(2)
・有能で即応できるサイバーセキュリティ人材のビルディングブロック
出典：NIST Special Publication 800-181 National Initiative for Cybersecurity
Education (NICE) Cybersecurity Workforce Framework （2017年8月）

52. 52
4-2. クラウドネイティブのシステム開発運用体制(1)
・DevOpsとは？
• アプリケーションの開発と配備を自動化することにフォーカスした、
アプリケーション開発の新しい方法論であり考え方である
• 開発チームと運用チームの間の協力とコミュニケーションを改善
してより深く結びつけることを意味し、特にアプリケーション配備と
インフラストラクチャ運用の自動化に焦点を当てている
• コード堅牢化、変更管理、本番アプリケーションのセキュリティを
改善するだけでなくセキュリティ運用全般をも強化してくれる

53. 53
4-2. クラウドネイティブのシステム開発運用体制(2)
・継続的インテグレーション／継続的デプロイ（CI/CD）
パイプライン
出典：日本クラウドセキュリティアライアンス「クラウドコンピューティングのための
セキュリティガイダンス v4.0」日本語版1.1（2017年7月）

54. 54
4-2. クラウドネイティブのシステム開発運用体制(3)
DevOpsのセキュリティへの波及効果
項目 波及効果と長所
標準化 DevOps では、本番に組み込まれるものはすべて、承認済みのコードと
設定用テンプレートに基づき、継続的インテグレーション／継続的デプロ
イ（CI/CD）パイプラインによって生み出される。開発、テスト、本番
（のコード）はすべて完全に 同一のソースファイルから派生しており、周
知となっている優れた標準からの逸脱を防いでいる。
自動化された
テスト
広範な種類のセキュリティテストは、必要に応じて補助的に手動 テストを
加えることで、CI/CD パイプラインに組み込むことが可能である。
不可変性
(immutable)
CI/CD パイプラインは、素早く確実に、仮想マシンやコンテナ、インフラス
トラクチャスタックのマスターイメージを生成する。これにより配備の自動
化と不可変(immutable)なインフラストラクチャを実現する。
出典：日本クラウドセキュリティアライアンス「クラウドコンピューティングのための
セキュリティガイダンス v4.0」日本語版1.1（2017年7月）

55. 55
4-2. クラウドネイティブのシステム開発運用体制(4)
DevOpsのセキュリティへの波及効果（続き）
項目 波及効果と長所
監査と変更管理の
改善
CI/CD パイプラインはソースファイルにある 1 文字の変更に至るまでの
全て を追跡調査できる。バージョン管理リポジトリに格納され たアプリ
ケーションスタック（インフラストラクチャを含む）の全履歴と共に、その変
更は変更を行った人物と紐づけられる。
SecDevOps/D
evSecOps と
Rugged
DevOps
SecDevOps/DevSecOps は セキュリティ運用を改善するために
DevOps の自動化技術を使う。Rugged DevOps はアプリケーション
開発過程にセキュリティテスティングを組み入れることを意味し、よ り強固
で、よりセキュアで、より障害耐性の高いアプリケーションを生み出す。
出典：日本クラウドセキュリティアライアンス「クラウドコンピューティングのための
セキュリティガイダンス v4.0」日本語版1.1（2017年7月）

56. 56
4-3. OTとIT、セーフティとセキュリティ(1)
・カナダ保健省「ガイダンス文書：医療機器サイバー
セキュリティの市販前要求事項」（2019年6月26日）
• 医療機器サイバーセキュリティリスクとISO 14971に基づくセーフティリスク
出典：Health Canada「Guidance Document: Pre‐market Requirements for Device Cybersecurity」（2019年6月26日）
https://www.canada.ca/en/health-canada/services/drugs-health-products/medical-devices/activities/announcements/cybersecurity-
notice.html

57. 57
4-3. OTとIT、セーフティとセキュリティ(2)
• 医療機器サイバーセキュリティリスクと
ISO 14971に基づくセーフティリスク
出典：Health Canada「Guidance Document: Pre‐market Requirements for
Device Cybersecurity」（2019年6月26日）
https://www.canada.ca/en/health-canada/services/drugs-health-
products/medical-devices/activities/announcements/cybersecurity-notice.html

58. 58
4-3. OTとIT、セーフティとセキュリティ(3)
• 医療機器サイバーセキュリティリスクと
ISO 14971に基づくセーフティリスク
（続き）
出典：Health Canada「Guidance Document: Pre‐market Requirements for
Device Cybersecurity」（2019年6月26日）
https://www.canada.ca/en/health-canada/services/drugs-health-
products/medical-devices/activities/announcements/cybersecurity-notice.html

59. 59
AGENDA
• 5. Q&A
https://www.linkedin.com/in/esasahara
https://www.facebook.com/esasahara
https://twitter.com/esasahara