医療情報ガイドラインとaws利用リファレンス改 …...2020/08/10 · ©2020 canon...

医療情報ガイドラインとAWS利用リファレンス改定の動向と概要

キヤノンITソリューションズ株式会社

DXCテクノロジー・ジャパン株式会社

日本電気株式会社

株式会社日立システムズ

フィラーシステムズ株式会社

2020年7月16日

1.医療情報ガイドラインとリファレンスの活用事例

キヤノンITソリューションズ株式会社上島努

©2020 Canon IT Solutions Inc, DXC Technology Japan, Ltd., NEC Corporation, Hitachi Systems, Ltd., FeelerSystemZ Inc.

1.1. 医療情報を取り巻く規制等 3

Hard Law Soft Law

法的な拘束力がある規則。

例）医師法、医療法、民法などで定められた事項

法的な拘束力は無い社会規範

例）ガイドライン、ガイダンスなど

3省3ガイドラインとは？

電子カルテをはじめとした電子化された医療情報を扱う際の情報セキュリティの観点から、医療情報を安全に管理するために策定されているガイドライン。厚生労働省、総務省、経済産業省の3省が出している3つのガイドラインの総称。



• 厚生労働省医療情報システムの安全管理に関するガイドライン• 総務省クラウドサービス事業者が医療情報を取り扱う際の安全管理に関するガイドライン

• 経済産業省医療情報を受託管理する情報処理事業者向けガイドライン

単なるセキュリティ要件ではなく、法令(コンプライアンス)要件未遵守は法令違反とみなされる可能性

診療報酬算定要件としても遵守が求められる

2020年「3省2ガイドライン」へ



出典）総務省報道資料(平成30年7月31日)「クラウドサービス事業者が医療情報を取り扱う際の安全管理に関するガイドライン（第1版）」（案）に対する意見募集の結果及び当該ガイドラインの公表https://www.soumu.go.jp/menu_news/s-news/01ryutsu02_02000209.html

2020年3月5日総務省・経済産業省統合版ガイドラインのパブリックコメント

2020年3月26日厚生労働省ガイドライン改定素案公開

2020年X月X日総務省・経済産業省統合版ガイドライン公開

2020年X月X日厚生労働省ガイドライン第5.1版公開

https://www.soumu.go.jp/menu_news/s-news/01ryutsu02_02000209.html


1.2. 医療情報システム向けAWS利用リファレンス（従来版概要） 6

医療情報システム向けAWS利用リファレンス 3省3ガイドライン

医療情報システム向けAWS利用リファレンス（経済産業省版）

医療機関等のお客さま

医療情報の委託を受けた事業者の

お客さま

医療情報システムの安全管理に関するガイドライン（第5版）

クラウドサービス事業者が医療情報を取り扱う際の安全管理に関するガイドライン（第1版）

医療情報を受託管理する情報処理事業者向けガイドライン

（第2版）

医療情報システム向けAWS利用リファレンス（総務省版）

医療情報システム向けAWS利用リファレンス（厚生労働省版）

基準に対応

作成支援問合せ

参照

参照

Amazon Web Services

Japan Inc.調査協力

医療情報の適正かつ安全な取り扱い、医療情報における適切なクラウドサービスの利用の促進

現在までの取り組み


1.2. 医療情報システム向けAWS利用リファレンス 7

2018年8月経済産業省版リファレンス公開

2018年12月総務省版リファレンス公開

2019年6月厚生労働省版リファレンス公開

▼総務省ガイドライン改定

▼2省ガイドライン統合

AOSデータ株式会社様


1.3. リファレンス活用事例 8

“「AOSBOX Business Plus」のプラットフォームとしてAWSを採用することにより、3省3ガイドラインに準拠できたことは、大変嬉しく思います。本システムは、医療情報向けAWS利用リファレンスを活用することで可能になりました。今後、益々医療システムにおいてクラウドバックアップのニーズが高まるなかで、AWS上に構築されたAOSBOXで、「最適」「簡単」「安心」なクラウドバックアップシステムを提供して参ります。”

AOSデータ株式会社代表取締役社長春山洋様出典）https://www.aosdata.co.jp/news/190117/

AOSBOX Business Plusの医療業界適用時にAWS利用リファレンスを活用

レセプトシステムや電子カルテデータのバックアップとして活用されています。

https://www.aosdata.co.jp/news/190117/

医療機器メーカー様



概況グローバルでの医療機器と連携したオンラインサービスを展開

課題以下を背景として国内でのサービス展開にあたりガイドライン準拠が課題

医療機関からのガイドラインに即したチェックリストへの回答を求められる

診療報酬加算を見据えた前提としてのガイドライン遵守

対応「医療情報システム向けAWS利用リファレンス」を基に、下記を実施

現行サービスのガイドライン適合性診断および不適合項目の対策サービス仕様適合開示書の作成・提供運用管理規程

効果短期間でのガイドライン準拠の達成医療機関チェックリストへの回答例の事前準備

医療関連事業者様



概況今後の臨床系システムの基盤としてAWSを活用していきたい

課題クラウドおよび医療情報のクラウド上での扱いに関する専門家がおらず、どのように医療情報の取り扱いを考慮したクラウド利用の標準化・ガイドライン作りができない。

対応「医療情報システム向けAWS利用リファレンス」を基に、AWS上で医療情報を取り扱う際に守るべき内容を抽出、標準化

効果短期間（3か月）で医療情報の取り扱いを前提としたAWS社内標準・ガイドライン作成

2.医療情報ガイドライン改定の概要

株式会社日立システムズ松本一敏

DXCテクノロジー・ジャパン株式会社影浦正一


2.1.改定の概要 12

2省（総務省・経済産業省）ガイドライン統合の背景

医療情報の安全管理を取り巻く環境の変化

① クラウドサービス利用の増加② 情報処理技術の普及とサイバー攻撃の高度化③ 情報セキュリティやクラウドサービス提供における国際基準との整合性（ISO/IEC 27001 , ISO/IEC 27002 , ISO/IEC 27005 , ISO/IEC27017 , ISO/IEC27018）

厚生労働省ガイドライン改定

データヘルス改革を推進するにあたり、クラウド技術の進展等の技術動向を踏まえた上で、個別具体的な事例を収集し、それぞれについて利用上の方針、留意点を整理。

情報技術の進展や医療情報の連携方法の多様化、2省ガイドライン統合向けた動向への対応、サイバー攻撃に対応する最新のセキュリティ要件を明確にする。

2.2.リスクベースアプローチ 13

リスクベースアプローチとは

リスクを適宜、適切に特定・評価をしておき、リスクに見合った措置（低減・回避・移転・保有）を講ずること

安全対策基準の対象となるシステムの取り扱う情報の機密性、システム障害時の外部への影響度、システムに求められる可用性等のリスク特性を洗い出し、特定システムもしくは通常システムの分類を行う。

システムの分類に応じて、安全対策基準にて必須とされている対策を選定する。

さらに、必須ではない対策の中でリスク特性から実施すべき対策を選定する。

選定した安全対策を実施する場合と、リスクが顕在化した場合の対応費用を比較し、選定した安全対策の実施要否を決定する。

実施しない場合、リスクを保有し、必要に応じてコンティンジェンシープランを策定する。

1st

リスク特性の評価

2nd

リスク特性に応じた

安全対策の決定

3rd

選択した安全対策の

実施要否の決定




なぜリスクベースアプローチなのか

情報処理技術の普及やサイバー攻撃の高度化に伴い、情報セキュリティを確保するための要求が拡大・多様化し、ガイドラインで一律に定めた要求事項の全てに対応することは困難になってきている。

（例えばサイバー攻撃に対して、情報システム全体を完全に防御し、リスクをゼロにするにはコスト的にも時間的にも非常に困難。）

医療情報システムの特性に応じた必要十分な対策を設計するために、一律に要求事項を定めることはせず、リスクベースアプローチに基づいたリスクマネジメントプロセスを定義する。



リスクとは

脅威

主に外部標的型攻撃マルウェアサーバー攻撃

脆弱性

主に内部セキュリティホール設定ミス心理的要素

情報資産

重要な情報機密情報個人情報知的財産

医療情報システムへの• 機密性 (Confidentiality)

• 完全性 (Integrity)

• 可用性 (Availability) に対する脅威（不正な閲覧・操作、ネットワーク上の盗聴・なりすまし、高度サイバー攻撃、情報の窃取・漏洩、情報の改ざん・破壊、医療情報システムの停止、技術的脆弱性の混入、機器や記憶媒体の持ち出し時の紛失・盗難、施設への物理的侵入、災害等）


2.2.改定の概要

情報セキュリティにおけるリスクとは守るべき情報資産に対して、危害や影響が与えられている状態を意味しており、

大きく「脅威」と「脆弱性」２つの要素で構成される。

① リスクにおける脅威・・・組織の外部／内部から情報資産に損害や影響を与える可能性のある要素

② リスクにおける脆弱性・・・情報資産そのものや情報システムに内在する弱点

例）・ソフトウェアやハードウｪア等の欠陥システム内部のバグ、システムに対する新たな攻撃に対する準備不足,

ハードウェアの経年劣化等

・不適切なシステム運用組織におけるルールの不備、情報システムを扱う従業員のリテラシーの低さ等

脅威の分類例示

人為的脅威意図的脅威攻撃（不正侵入、ウィルス、改ざん、盗聴、なりすまし等）

偶発的脅威人為的ミス（ヒューマン・エラー）、障害

環境的脅威環境的脅威災害（地震、洪水、台風、落雷、火事等）

16

2.3.リスクマネジメントプロセスの構築


17

一時的なリスク評価だけでなく、監査を含めた継続的に管理する体制整備が求められる

リスクアセスメントリスク対応リスクコミュニケーション

目的

対象医療情報システムがどのようなもので、事業者がどのようなリスクを認識したかを明らかにする

事業者が識別した各リスクの重要度（リスクレベル）に鑑み、どのような対策を実施するかを明らかにする

提供するシステムの安全性を説明し、医療機関と共通理解を形成する

ステップ1. リスクの特定2. リスク分析3. リスク評価

1. リスク対応選択肢*1の選定2. リスク対応の手順説明

1. リスクコミュニケーション2. 継続的なリスクマネジメント

の実践

成果物• 情報システムの全体構成図• リスクアセスメントの結果一覧

• リスク対応の一覧 • 情報提供すべき内容の文書*2

• 運用管理規程

*1 リスク低減・リスク回避・リスク移転(共有)・リスク保有(受容)から選択する*2 次頁参照

ガイドラインでは、監査の実施方針を運用管理規程に含めること及びリスクマネジメントプロセス

の継続的な見直しを求めているが、監査結果の医療機関等への共有は求めていない


リスクマネジメントの実施例


18

ガイドラインにはリスクマネジメントの実施例として、全体構成図の作成・情報流の特定及び各成果物の例が示されている医療機関等へ情報提供すべき項目(ガイドライン表4-1) ガイドライン5.2 リスクアセスメント及びリスク対応の実施例

アプリケーション提供

プラットフォーム提供

インフラ提供

開発フェーズ

運用フェーズ

契約終了フェーズ

リスクアセスメント結果一覧



本番以外の環境にも着目する

実際の業務・機能・操作に着目する

破棄や移管等の処理に着目する

全体構成図の作成

情報流の特定

リスク対応

1. どこに機器や記録媒体があるか2. 機器同士の接続及び記録媒体の運搬3. 情報の処理(人が扱う場合)

4. 情報の処理(人が直接扱わない場合)

リスク対応一覧リスク対応一覧リスク対応一覧

5.2.1

5.2.2残存するリスクの

評価


医療機関との合意


19

残存リスクを含むリスク対応を医療機関と役割分担や残存リスクについて合意する必要がある

医療機関等へ情報提供すべき項目(ガイドライン表4-1)


リスク対応一覧

医療機関等へ対応を求める事項

残存するリスクの評価

各種マニュアル

医療機関等へ提供する資料医療機関等へとの合意形成

資料を基に以下について、医療機関等と合意形成する

1. 医療機関等との役割分担

2. 受容したリスク（残存するリスク)の内容等

合意に至らない場合

以下により合意形成を図る

1. リスク対応事項の見直し

2. リスクの共通理解


説明義務


20

説明義務を果たすためにリスクマネジメントプロセスを構築する

医療機関等へ情報提供すべき項目(ガイドライン表4-1)

厚生労働省版ガイドラインの要求事項

医療機関等と適切な共通理解を得るために、独立した監査部門や第三者機関による安全性評価結果を提出ることが望ましい⇒4.4 ではPマーク認定・ISMS認証*が求められている

事業者側のリスク対応（前述）

* 医療情報を直接取扱わない事業者については推奨

医師法等の法令・e文書法・電子署名に関する法律・厚生労働省版ガイドラインへの準拠・診療録及び診療諸記録の外部保存基準

求められる対応

事業者の説明義務

3. AWS ユーザにとっての影響と対応の考え方

フィラーシステムズ株式会社鴻池明

3.1 AWSにおけるリスクマネジメントプロセス


22

一時的なリスク評価だけでなく、監査を含めた継続的に管理する体制整備が求められる

リスクアセスメントリスク対応リスクコミュニケーション

目的

対象医療情報システムがどのようなもので、事業者がどのようなリスクを認識したかを明らかにする

事業者が識別した各リスクの重要度（リスクレベル）に鑑み、どのような対策を実施するかを明らかにする

提供するシステムの安全性を説明し、医療機関と共通理解を形成する

ステップ1. リスクの特定2. リスク分析3. リスク評価

1. リスク対応選択肢*1の選定2. リスク対応の手順説明

1. リスクコミュニケーション2. 継続的なリスクマネジメント

の実践

成果物• 情報システムの全体構成図• リスクアセスメントの結果一覧

• リスク対応の一覧 • 情報提供すべき内容の文書*2

• 運用管理規程

*1 リスク低減・リスク回避・リスク移転(共有)・リスク保有(需要)から選択する*2 次頁参照

ガイドラインでは、監査の実施方針を運用管理規程に含めること及びリスクマネジメントプロセス

の継続的な見直しを求めているが、監査結果の医療機関等への共有は求めていない

3.2 医療情報システムにおけるAWS責任共有モデル 23

外部委託された医療情報

リスクの特定、分析、評価する際には、AWSの責任共有モデルを参照して、そのリスクの所在を特定して、対応を検討しなければなりません。

3.3 リスク特定〜評価


24

リスクの特定

リスク分析

リスク評価

リスク対応の選択肢の選定

リスク対応の実施手順

リスクコミュニケーション

継続的なリスクマネジメントの実践

情報システムの全体構成図にはAWS（インフラ）などの内容も盛り込み、リスクの特定、分析、評価を実施する必要ががあります。

3.4 リスク対応の実施手順 25

リスクの特定

リスク分析

リスク評価





リスク対応の実施手順のついては、システム内での対応やAWSの機能を利用した対応なども活用することが可能です。

お客様へ提供するセキュリティ機能群

AWS Identity and

Access Management

AWS WAF Amazon

Inspector

Amazon

GuardDuty

AWS Certificate

Manager

AWS Key

Management

Service

AWS CloudHSMAWS Single Sign-On AWS Firewall Manager

医療情報システム向けAWS利用リファレンス

3.4 リスク対応の実施手順 26

リスクの特定

リスク分析

リスク評価





AWSのセキュリティ認定・認証・監査ホワイトペーパー

また、システムやAWSでの機能的対応ではリスク低減できない場合に、AWSの各種情報を利用してリスク対応することも可能です。


27

決められているものに準拠自らリスクを考えて、選定する

これまでのガイドラインでは利用できなかったAWSのサービスが、

自らがリスクコントロールすることによって利用することが可能となります。

Amazon

Connect

Amazon

AppStream 2.0

Amazon

WorkSpaces

Amazon

WorkDocsAWS

IoT Button

AWS

OpsWorksAmazon

CodeGuruAWS

Elemental

MediaPackage

AWS

Elemental

MediaStore

AWS

Transfer

for SFTP

Amazon

Pinpoint

AWS

Global

Accelerator

AWS

Cloud Map

3.5 AWSの利用の幅が広がる可能性

4.リファレンス改定について

NEC 医療ソリューション事業部岡田真一

4.1 AWS 利用リファレンス改定の概要


29

2省統合版への対応リスクベース部分①リスクアセスメントシートリスク特定→リスク分析→リスク評価→リスク対応の選択肢の選定→リスク対応の実施

②リファレンスシートリスクアセスメントの中の「リスク対応の実施」を中心にリファレンスとして整理

ルールベース部分③制度上の要求事項シート従来のリファレンスを踏襲したもの

厚生労働省版への対応従来版からフォーマットの変更は無し新たに追加された要求事項に対する対応を追加

4.1.1 リスクアセスメントシート（2省統合版） 1/10


30

リスク評価

残存するリスク

影響度顕在率リスクレベル

機器の管理手順を策定し、機器の設置や保守に係わる作業者全員に対して、周知し、理解したことの確認を行う。

・・・

・・・

・・・

人的・組織的対策

物理的対策

技術的対策


物理的対策

技術的対策


― ― ―

物理的対策 ― ―

技術的対策 ― ― ―

リスク特定リスク分析リスク対応

情報流分類関連する脅威特定したリスク影響度顕在率リスクレベル

対応対策の観点対象事業者が実施する対策 AWSが実施している対策医療機関等へ

対応を求める事項

5

医療情報システムの停止

障害等に伴うアプリケーション提供に係る情報の滅失・破壊が生じ、見読性や保存性は失われる

5

対応要否

対象事業者DCの有線LAN上のネットワーク機器でアプリケーション提供に係る情報が転送される

アプリケーション提供に係る情報（医療情報を含む可能性あり）

ネットワーク上の盗聴・なりすまし

対象事業者DCの有線LAN上の

ネットワーク機器におい

て

アプリケーション提供に係る情報の盗聴・なりすましが行われる

3 A 要低減


―

物理的対策

技術的対策

―

施設への物理的侵入アプリケーション提供に係る情報に物理的にアクセスされる

5 3 A

要低減

3 A 要

要

災害等

アプリケーション提供に係る情報処理が地震、水害、落雷、火災等並びにそれに伴う停電当により停止、不具合が生じる

5 3 A ―

・リスクアセスメントのプロセスを表に整理したもの


31

リスク評価




・・・

・・・

・・・


物理的対策

技術的対策


物理的対策

技術的対策


― ― ―







5



5

対応要否






て


3 A 要低減


―

物理的対策

技術的対策

―


5 3 A

要低減

3 A 要

要

災害等


5 3 A ―

5.1.1ガイドラインの章番号

別添2-2 別紙2 旧ガイドラインの対策項目一覧と医療情報安全管理ガイドラインの対応表「対策項目で対応できるリスクシナリオ例」より



32

リスク評価




・・・

・・・

・・・


物理的対策

技術的対策


物理的対策

技術的対策


― ― ―







5



5

対応要否






て


3 A 要低減


―

物理的対策

技術的対策

―


5 3 A

要低減

3 A 要

要

災害等


5 3 A ―




（例）脆弱性への対応漏れや脆弱性是正のための設定変更等により医療情報システムに不具合が生じる。


33

リスク評価




・・・

・・・

・・・


物理的対策

技術的対策


物理的対策

技術的対策


― ― ―







5



5

対応要否






て


3 A 要低減


―

物理的対策

技術的対策

―


5 3 A

要低減

3 A 要

要

災害等


5 3 A ―




34

リスク評価




・・・

・・・

・・・


物理的対策

技術的対策


物理的対策

技術的対策


― ― ―







5



5

対応要否






て


3 A 要低減


―

物理的対策

技術的対策

―


5 3 A

要低減

3 A 要

要

災害等


5 3 A ―



（例）影響度：大顕在率：中程度（起こる可能性がある）→

リスクレベル：A


35

リスク評価




・・・

・・・

・・・


物理的対策

技術的対策


物理的対策

技術的対策


― ― ―







5



5

対応要否






て


3 A 要低減


―

物理的対策

技術的対策

―


5 3 A

要低減

3 A 要

要

災害等


5 3 A ―




36

リスク評価




・・・

・・・

・・・


物理的対策

技術的対策


物理的対策

技術的対策


― ― ―







5



5

対応要否






て


3 A 要低減


―

物理的対策

技術的対策

―


5 3 A

要低減

3 A 要

要

災害等


5 3 A ―



（例）“対応必要” と判断


37

リスク評価




・・・

・・・

・・・


物理的対策

技術的対策


物理的対策

技術的対策


― ― ―







5



5

対応要否






て


3 A 要低減


―

物理的対策

技術的対策

―


5 3 A

要低減

3 A 要

要

災害等


5 3 A ―


リスク対応の選択肢概要

リスク低減リスクへの対策を行うことで、リスクレベル（顕在率及び影響度）を低

減させる。

リスク回避リスクを生じさせる情報流を廃止したり、別の情報流に変更する。

リスク移転

（リスク共有ともいう）

保険への加入により金銭面での損失に備えたり、医療情報システムの運

用を外部に委託することで専門的な業者の管理下に置いたりする。

リスク保有

（リスク受容ともいう）

意思決定に基づき、残存するリスクの顕在化により生じ得る被害や金銭

面での損失を受容する。



38

リスク評価




・・・

・・・

・・・


物理的対策

技術的対策


物理的対策

技術的対策


― ― ―







5



5

対応要否






て


3 A 要低減


―

物理的対策

技術的対策

―


5 3 A

要低減

3 A 要

要

災害等


5 3 A ―


リスク対応の選択肢概要

リスク低減リスクへの対策を行うことで、リスクレベル（顕在率及び影響度）を低

減させる。

リスク回避リスクを生じさせる情報流を廃止したり、別の情報流に変更する。

リスク移転

（リスク共有ともいう）

保険への加入により金銭面での損失に備えたり、医療情報システムの運

用を外部に委託することで専門的な業者の管理下に置いたりする。

リスク保有

（リスク受容ともいう）

意思決定に基づき、残存するリスクの顕在化により生じ得る被害や金銭

面での損失を受容する。


（例）“リスク低減”を選択


39

リスク評価




・・・

・・・

・・・


物理的対策

技術的対策


物理的対策

技術的対策


― ― ―







5



5

対応要否






て


3 A 要低減


―

物理的対策

技術的対策

―


5 3 A

要低減

3 A 要

要

災害等


5 3 A ―



4.1.2 リファレンスのイメージ（2省統合版）


40

AWSのインフラストラクチャー関連事項 AWSサービス関連情報

人的・組織的対策 ― ―

物理的対策

AWSのデータセンターでは、最新式の革新的な建築的、工学的アプローチを採用しています。AWSは大規模データセンターの設計、構築、運用において、長年の経験を有しています。この経験は、AWS プラットフォームとそのインフラストラクチャーに活かされているものです。AWSは日本に存在するAWSサービスで利用されるデータセンターに対する地球科学的な変化のリスクを考慮し、最新式の免震装置の採用を始めとして、そのようなリスクの影響を最小限にするために真剣に取

―

技術的対策 ― ―

3.2②

情報の区分に依らない一律のアクセス管理が行われることで、医療情報等のより重要な情報に対しても、重要性の低い情報と同じレベルで不正な閲覧・操作が行われる。

低減技術的対策

AWS 環境は仮想化されたマルチテナント環境です。AWS は、お客様間を隔離するために設計されたセキュリティ管理プロセス、PCI 統制、その他のセキュリティ統制を実装しています。AWS システムは、仮想化ソフトウェアによるフィルタリング処理により、お客様に割り当てられていない物理ホストや物理インスタンスにアクセスできないように設計されています。このアーキテクチャは独立PCI 認定審査機関 (QSA) によって検証済みであり、2015 年 4月に発行された PCI DSS 3.1 版のすべての要件に準拠することが確認されています。注意: また、AWS にはシングルテナントのオプションもあります。ハードウェア専有インスタンスは、単一のお客様専用のハードウェアを実行するAmazon Virtual Private Cloud (Amazon VPC) で起動される Amazon EC2 インスタンスです。ハードウェア専有インスタンスを使用することで、AmazonVPC および AWS クラウドの利点をフルに活用しながら、Amazon EC2 インスタンスをハードウェアレベルで隔離できます。

詳細、最新情報は下記ホワイトペーパーを参照ください。「主要なコンプライアンスに関する質問と AWSの回答」https://d1.awsstatic.com/whitepapers/compliance/JP_Whitepapers/AWS_Answers_to_Key_Compliance_Questions_JP.pdf

Amazon VPCAmazon Virtual Private Cloud (Amazon VPC) では、AWS クラウドの論理的に分離されたセクションをプロビジョニングし、お客様が定義した仮想ネットワーク内の AWS リソースを起動することができます。自分の IP アドレス範囲の選択、サブネットの作成、ルートテーブルやネットワークゲートウェイの設定など、仮想ネットワーキング環境を完全に制御できます。VPC では、リソースやアプリケーションに安全かつ簡単にアクセスできるよう、IPv4 と IPv6 を両方とも使用できます。Amazon VPC のネットワーク設定は容易にカスタマイズできます。既存のデータセンターと自分の VPC クラウドを既存のデータセンターを拡張するかのように活用することができます。詳細、最新情報は下記を参照ください。https://aws.amazon.com/jp/vpc/

クラウドサービス事業者は、仮想化技術を用いた資源をサービスに供する場合には、論理的に区分管理を行えることを保証できる措置を講じる必要があります。また、Amazon Virtual Private Cloud(Amazon VPC)を活用することができます。

1.情報の区分管理を実施し、区分単位でアクセス管理を実施すること。

2.8 地震、水害、落雷、火災等並びにそれに伴う停電等により、医療情報システムが停止もしくは不具合が生じる。

低減 ―

リスク対応

No. リスクシナリオ対応対策の観点AWSが実施している対策対象事業者

対応の有無医療機関等へ


・「リスク対応」の部分を中心に記載


41



物理的対策


―


3.2②









低減 ―

リスク対応







42



物理的対策


―


3.2②









低減 ―

リスク対応






（例）脆弱性への対応漏れや脆弱性是正のための設定変更等により医療情報システムに不具合が生じる。



43



物理的対策


―


3.2②









低減 ―

リスク対応




AWSが実施している対策




44



物理的対策


―


3.2②









低減 ―

リスク対応




AWSが実施している対策


AWS System &

Organization Control

(SOC) レポートを参照

セキュリティ自動評価サービスAmazon Inspector

AWS

CloudTrail

Amazon

S3 Bucket

Log

Analysis

Apps

【リスク対応】AWS CloudTrail の活用実行されたAPI Callを記録し実行したユーザーやアプリケーション、対象のリソース、イベントの発生日時およびその他の詳細情報を識別して指定したS3バケットにログファイルを送信する

各種AWSサービス

AWS

Management

Console

AWS SDK

applications

AWS CLI

AWS Cloud

4.1.3 リファレンスの活用例


【リスクシナリオ】ログが取得・保存されず、ログの監視・分析による不正な行為等の検出や、情報事故発生後のログの解析による検証ができない。

以下の章立てになっており、前版から特に内容の変更はありません。

6.医療分野における制度上の要求事項

6.1. 医療分野の制度が求める安全管理の要求事項

6.2. 電子保存の要求事項

6.3. 法令で定められた記名・押印を電子署名で行うことについて

6.4. その他取扱いに注意を要する文書等について

6.5. 外部保存の要求事項

AWSリファレンスもこの部分に関しては特に変更はありません。


4.2 制度上の要求事項（2省統合版） 46

制度上の要求事項関連するAWS情報

Seq.

項番項番タイトルサブ項番サブタイトル番号ガイドラインとして必要な要求事項 AWSのインフラストラクチャー関連事項 AWSサービス関連情報クラウドサービス事業者（お客様）の該当事項推奨される追加の実施事項 AWS認証情報

(ISO/IEC27001, Annex.A and ISO/IEC27017)

1 3.2.1 組織的安全管理対策（ア）組織･体制の整備 ① サービスの提供についての管理責任を有する責任者

を設置する。

AWSの法務関連の詳細、最新情報は下記を参照ください。

AWS カスタマーアグリーメント – このカスタマーアグリー

メントは、お客様による当サービスのご利用について規定

するものです

AWS サービス条件 – この追加条件は、お客様による特定の

サービスのご利用に対して適用されます

AWS サービスレベルアグリーメント – このサービスレベル

アグリーメントは、お客様による特定のサービスのご利用

に対して適用されます

AWS 適正利用規約 – この適正利用規約は、当サービスの利

用に関して、禁止される事項を記載したものです

https://aws.amazon.com/jp/legal/

責任共有環境

IT インフラストラクチャーを AWS に移行する際は、お客様

に責任共有モデルを考慮していただく必要があります。こ

の責任共有モデルでは、ホストオペレーティングシステム

や仮想レイヤーから、サービスが運用されている施設の物

理セキュリティまで、AWS の責任範囲で様々なコンポーネ

ントが運用、管理、コントロールされることになり、お客

様の運用上の様々な負担の軽減にも貢献することになりま

す。お客様の責任範囲としては、ゲストオペレーティング

-AWS Artifact

AWS Artifactでは、AWS のセキュリティおよび

コンプライアンスレポートと特定のオンライン

契約にオンデマンドでアクセスできます。AWS

Artifact には、Service Organization Control

(SOC)、Payment Card Industry (PCI) レポー

ト、AWS セキュリティ制御の実装と運用の有効

性を検証する、さまざまな地域やコンプライア

ンス垂直市場の認定機関からの認定が含まれま

す。AWS Artifact で利用可能な契約には、事業

提携契約 (BAA) と機密保持契約 (NDA) が含まれ

ます。

詳細、最新情報は下記を参照ください。

https://aws.amazon.com/jp/artifact/

サービスの管理責任

クラウドサービス事業者は、サービスの管理責任者を設置する

必要があります。

N/A A.6 情報セキュリティのための組織

A.6.1.1

A.6.1.3

C.L.D.6.3 クラウドサービスカスタマとクラウドサー

ビスプロバイダとの関係

C.L.D.6.3.1

厚生労働省版改定ガイドラインの要求事項ごとに、役割分担を定義


4.3 厚生労働省版 47

AWSインフラストラクチャーの対応情報

AWSサービス関連情報

医療機関等の該当事項

推奨事項根拠となる

ISO/IEC27001の該当箇所

フォーマットの変更は無く、新たに追加された要求事項に対する対応を追加。


484.４スケジュール実線：確定スケジュール破線：想定スケジュール

（注記）上記スケジュールは、２省統合版のガイドラインが8月下旬までに公表され、厚生労働省版ガイドラインが10月末までに公表される前提でのものです。ガイドラインの公表時期によってはリファレンスの公開時期が予定より遅くなる可能性があります。

最後に


49

本リファレンスの作成にあたってはAWSパートナー5社が、各々のノウハウを結集し、皆様のクラウドの利活用促進を行うために、協力体制を作り、調査、検討を行い、作成した成果になります。アマゾンウェブサービスジャパンにも調査など、多大な協力を頂きました。

本取り組みがクラウド活用の促進により医療業界における課題解決の一助となること、ひいては患者さんがより良い医療をうけられる環境づくりの一助になれば幸いです。

「医療情報システム向けAWS利用リファレンス」の入手は、下記各社までお問い合わせください。各社のホームページからダウンロードできます。

医療情報ガイドラインとaws利用リファレンス 改 …...2020/08/10 · ©2020 canon...

Documents

医療情報ガイドラインとaws利用リファレンス改 …...2020/08/10 · ©2020 canon...