医療におけるサードパーティベンダーリスク管理

医療におけるサードパーティベンダーリス
ク管理
(2022年12月21日)
Cloud Security Alliance
Health Information Management WG

AGENDA
1. 日本国内におけるサードパーティベンダーを介したインシデ
ント事例
2. 米国の医療機関におけるサードパーティベンダーを介した
インシデント事例
3. 金融機関におけるサードパーティベンダーリスク管理事例
4. Cloud Security Alliance
「医療におけるサードパーティベンダーリスク管理」
5. Q&A／ディスカッション

AGENDA
1. 日本国内におけるサードパーティベンダーを介したインシデ
ント事例

4
1. 日本国内におけるサードパーティベンダーを介したインシデント事例
(1)
• 日経XTECH 「個人情報漏えい事件を斬る」(2005年~2008年)
(https://xtech.nikkei.com/it/article/COLUMN/20060407/234812/)

5
(2)
• 日経XTECH 「〔92〕再発防止策見えない情報流出後の自治体発表」
(2007年6月4日) (https://xtech.nikkei.com/it/article/COLUMN/20070531/273230/)
• 2007年5月16日、A市は、合併した旧町の住民記録および税に関する情報が電算保
守の
外部委託先から流出したことを発表
• 電算保守受託業者であるB社の元社員が契約に違反して，情報を保存した社用PC
を
持ち帰り、ファイル交換ソフト「Winny」をインストールしている自宅PCにデー
タを複写。
ウイルス感染によりデータが流出した
• 住基情報、住民税、軽自動車税、固定資産税、税引き落とし口座、税収納などに
関する
情報が流出(住民税、固定資産税、税引き落とし口座には個人情報が含まれてい
た)

6
(3)
• 2007年5月16日、E市は、6町合併に伴う電算システム統合の外部委託先F社から，
公営
住宅に関連する住民の個人情報が流出したことを発表
• 外部委託先F社はB社へ再委託しており、流出元がB社元社員の自宅PCであること
が判明
• 2007年5月22日、G市は、合併当時の旧町の住民記録の一部がファイル交換ソフト
「Winny」を介して流出したことを発表
• 電算システム統合業務を受託したH社が、B社へ再委託しており、流出元がB社元
社員の自宅PCであることが判明
• 各自治体の経緯の説明
• A市：社用パソコンを持ち帰り，ファイル交換ソフト（Winny）をインストール
している
自宅パソコンにデータを複写
• C町：自宅にデータを持ち帰り，自分のパソコンに入れていたデータが流出した
• E市：重要データをファイル交換ソフトWinnyの入った自宅のパソコンに保存し

7
(4)
• 日経XTECH 「〔122〕住基情報の委託先管理で求められる自治体首長の
リーダーシップ」(2008年1月21日)
(https://xtech.nikkei.com/it/article/COLUMN/20080117/291287/)
• 総務省「住民基本台帳に係る電算処理の委託等に関する検討会報告書」(2007年12
月
20日) (https://www.soumu.go.jp/main_sosiki/jichi_gyousei/c-gyousei/daityo/old/pdf/071221_1_s3-2.pdf)
• 事業者の対応上の問題
• 再委託に係る承認手続の不履行
• 委託先事業者による再委託先事業者に対する委託契約の規定内容遵守（指定場所での処理，
データの持ち出しの禁止など）の不徹底
• 再委託先事業者における情報セキュリティ確保措置の不備（特に，在宅勤務が伴う
勤務体制下での不備）
• 再委託先事業者の従業員による自宅パソコンのデータの不正保存
• 当該パソコンへのファイル交換ソフトのインストール・ウイルス感染
• まとめ
• 法律改正によらない対応であっても、規範性を有する技術的基準の改正による対応に、運用上

8
(5)
• 日経XTECH 「〔123〕IT市場を左右するSaaS事業者の個人情報保護対
策」(2008年1月28日) (https://xtech.nikkei.com/it/article/COLUMN/20080124/291863/)
• 総務省 ASP・SaaSの情報セキュリティ対策に関する研究会
「ASP・SaaSの情報セキュリティ対策に関する研究会報告書」
「ASP・SaaSにおける情報セキュリティ対策ガイドライン」(2008年1月30日最終版)
(https://www.soumu.go.jp/main_sosiki/joho_tsusin/policyreports/chousa/asp_saas/index.html)
• SaaS／ASPが急速に普及・拡大を続ける背景要因
• ブロードバンドの普及
• 個人情報保護法の施行等による企業の意識の変化
• ASP／SaaSサービスの多様化
• 人的・金銭的リソースに限界のある中小企業が個人情報保護法に対応するために、高いレベルの
運用・管理ノウハウを持つASP・SaaSサービスを利用するようになったことが大きい
• 経済産業省「SaaS向けSLAガイドライン」(2008年1月21日)
(http://www.meti.go.jp/policy/netsecurity/secdoc/contents/downloadfils/080121saasgl.pdf)
• 各種セキュリティ規格の準拠性に関する確認事項
• 機密性に関する確認事項
• 完全性に関する確認事項
• 可用性に関する確認事項
• 運用保守における確認事項

AGENDA
2. 米国の医療機関におけるサードパーティベンダーを介した
インシデント事例

10
2. 米国の医療機関におけるサードパーティベンダーを介したインシデン
ト事例(1)
• 米国ブラックボー「FORM 10-Q: 1934年証券取引法第13条または15条
(d)項に基づく2020年4-6月期四半期報告書」(2020年8月4日)
(https://investor.blackbaud.com/sec-filings/sec-filing/10-q/0001280058-20-000038)
• 非営利組織向けに特別設計のクラウド型ソフトウェアおよび関連サービスを開発・提
供する企業(米国NASDAQ上場)
• 2020年8月4日、米国証券委員会(SEC)のサイバーセキュリティリスク開示ガイドラ
インに
基づき、ランサムウェア攻撃に起因するセキュリティインシデントが2020年5月に
発生したことを2020年4-6月期四半期報告書の中で公表
出典：Blackbaud, Inc.「QUARTERLY REPORT PURSUANT TO SECTION 13 OR 15(d) OF THE SECURITIES EXCHANGE ACT OF 1934
For the quarterly period ended June 30, 2020」(2020年8月4日)

11
ト事例(2)
• グリニッジ病院(コネティカット州ニューヘイブン)
• 2020年8月12日、ブラックボーが、グリニッジ病院に対して、2020年2月7日～
5月20日の間、同社の寄付管理システムがランサムウェア攻撃に遭い、不正アク
セスしたグループが非金融情報を削除したことを通知
• グリニッジ病院の運営母体であるイェール・ニューヘブン・ヘルスシステム（YNHHS）は直
ちに、どの
情報が潜在的に漏えいしてどの人々が影響を受けたかを確認するために、広範囲に及ぶ内部調
査を開始
• 2020年10月9日、グリニッジ病院が、企業ブラックボーで発覚したデータ漏えい
インシデントの影響を受けたことを正式に公表
• 寄付者とのコミュニケーションやエンゲージメントにブラックボーのソフトウェアを利用して
おり、今回のインシデントの影響を受けた可能性のある関係者全員宛に、通知書面を送付
• 漏えいしたデータには、銀行口座、社会保障番号、クレジットカード情報など、個人の金融情
報は含まれていない
• ブラックボー側の見解：外部集団からの要求に応じて身代金を支払い、すべての
データが破壊され、いかなる情報も流出していないことが保証された
• ブラックボーのパブリッククラウド環境（例．Microsoft Azure、Amazon Web Services）

12
ト事例(3)
• 米国ブラックボー「FORM 10-Q: 1934年証券取引法第13条または15条
(d)項に基づく2020年7-9月期四半期報告書」(2020年11月3日)
• 2020年7-9月期のセキュリティインシデント関連支出：320万米ドル(約4億3200万円)
*1US$=135
• 2020年7-9月期にセキュリティインシデント関連で発生した保険金回収額：290万米ドル(3億9150
万円)
出典：Blackbaud, Inc.「QUARTERLY REPORT PURSUANT TO SECTION 13 OR 15(d) OF THE SECURITIES EXCHANGE ACT OF 1934
For the quarterly period ended September 30, 2020」(2020年11月3日)

13
ト事例(4)
• 米国ハーバード・アイ・アソシエイツ「データ侵害通知」(2021年2月5
日) (https://oag.ca.gov/system/files/Patient%20Letter%20-%20IDX%20Proof%20Copy.pdf)
• 2021年1月15日、ハーバード・アイの外部委託先であるオンライン・データスト
レージ・ベンダーより、同社のコンピュータシステムに外部からの不正アクセスがあ
り、データの一部(保護対象
保健情報(PHI)を含む)が盗まれたという通知を受ける
• ハーバード・アイは、ベンダーより、ハッカーが盗んだデータの代償と
して金銭を要求しているという通知を受ける
• ベンダーは、サイバーセキュリティ専門家および連邦捜査局(FBI)に
相談した後、金銭を支払ったが、その際に、ハッカーはデータを返却し、
ベンダーに対して、データを公開したり、コピーを保存したりすることは
ないと告げたと説明している
• ベンダーは、ハッカーが、2020年10月24日までには、ハーバード・
アイのデータにアクセスしていた可能性があると結論付ける(ハッカーが
出典：Harvard Eye Associates「Notice of Data Breach」(2021年2月5日)
(https://oag.ca.gov/system/files/Patient%20Letter%20-%20IDX%20Proof%20Copy.pdf)

14
ト事例(5)
• ハッカーが盗んだ情報
• ハーバード・アイが所有する患者情報：
患者の名前、住所、電話番号、電子メールアドレス、生年月日、病歴、医療保険
情報、
治療薬、ハーバード・アイからの診療に関する情報など
• 外科センター向けの管理サービスを実行するためにハーバード・アイが利用して
いた
アリシア外科センターにおいて眼科手術を受けた患者情報：
手術に関連する医療情報が含まれている可能性がある
• ハーバード・アイの職員に係わる個人情報：
現在および過去のハーバード・アイの職員と、家族および受益者に関する特定の
個人情報
• ベンダー側の対応：
• インシデント発生後、FBIに連絡する一方、サイバーセキュリティ専門家を雇用
して調査を
実施し、ハッカーからのアクセスをブロックして、再発防止対策を講じる

15
ト事例(6)
• 米国ピーチステート・ヘルスマネジメント「臨床検査機関が潜在的な
HIPAAセキュリティ規則違反で25,000米ドルを支払うことで和解」
(2021年5月25日) (https://www.hhs.gov/about/news/2021/05/25/clinical-laboratory-pays-25000-settle-
potential-hipaa-security-rule-violations.html)
• ピーチステート（ジョージア州）：HIPAA規則の適用対象主体（CE）である医療機
関からの委託を受けて、保護対象保健情報（PHI)を利用した臨床／遺伝子検査サー
ビス業務を行う事業提携者（BA）に該当する臨床検査サービス機関
• 2017年12月、米国保健福祉省(HHS)の公民権室(OCR)が、ピーチステートのHIPAA
プライバシー／セキュリティ規則の遵守状況に関する調査を開始
• HIPAAセキュリティ規則違反事項を確認⇒制裁金25,000米ドル(＝3,375,000円)
A) ピーチステートが保有する電子PHIの機密性、完全性、可用性に対する潜在的リスクや脆弱
性に関する正確で完全な評価の実施を怠っていた。
B) リスク分析または評価で特定された合理的で適切なレベルまで、リスクや脆弱性を低減する
のに十分な
セキュリティ対策の導入を怠っていた。
C) 電子PHIを含むまたは利用する情報システムにおける活動を記録・検証するハードウェアや

AGENDA
3. 金融機関におけるサードパーティベンダーリスク管理
事例

17
3. 金融機関におけるサードパーティベンダーリスク管理事例(1)
• 米国キャピタル・ワン「キャピタル・ワンのサイバーインシデントに関
する情報」(2022年4月22日更新) (https://www.capitalone.com/digital/facts2019/)
• 何が起きたか？
• 2019年7月19日、外部の個人が不正アクセスを実行し、キャピタル・ワンのクレ
ジットカード顧客およびクレジットカード商品を申し込んだ個人に関する特定タ
イプの個人情報を取得したと判断した(*外部通報者からの通知により、クラウド
ストレージから流出したデータがGitHub上で公開状態にあることが発覚)
• 何をしたか？
• 直ちに問題を修正し、迅速に連邦政府の法執行機関とともに作業を開始した
• データを取得した外部の個人は、FBIにより拘束された
• 政府機関は、データが復旧されたこと、データが詐欺に利用されたり、個人によ
り共有された証拠はないと信じていることを表明した
• どんな影響があったか？
• このイベントは、米国内の個人約1億人、カナダ国内の個人約600万人に影響を及
ぼした
• アクセスされた情報には、クレジットカードの既存顧客および申込者の名前、住

18
• キャピタル・ワンへの問い合わせに対するFAQ
1. 何が起きたのか？
2. どのようにして、キャピタル・ワンはインシデントを発見したか？
3. いつこれが発生したのか？
4. 自分に影響が及んだか否かを、どのようにして知るのか？
5. 誰がこのサイバーインシデントに関する責任があるのか？
6. このインシデントは、キャピタル・ワンの他の企業からの顧客に影響を及ぼすの
か？
7. このインシデント以降、自分を保護するために、キャピタル・ワンは何をしてい
るのか？
8. このサイバーインシデントに関して、自分の情報を尋ねる電話やテキストメッ
セージを受けた。自分は何をすべきか？
9. 不正やID詐欺から自らを守るためにとれる追加的なステップはあるか？
10.自分の社会保障番号やアカウント番号が影響を受けたという通知を受け取ってい
ないが、心配である。自分は何をすべきか？
11.このサイバーインシデントに関連した和解策はあるか？

19
• キャピタル・ワンに対する集団訴訟への対応
• キャピタル・ワングループおよびクラウドサービス事業者に対する集
団訴訟に
おいて、総額1億9000万米ドル（＝256億5000万円）を支払うこと
で
和解
出典：「Capital One Data Breach Class Action Settlement」(2022年11月28日更新)(https://www.capitalonesettlement.com/en)

20
• G7サイバーエキスパートグループ「金融セクターにおけるサードパー
ティのサイバーリスクマネジメントに関するG7の基礎的要素」(2022年
10月13日採択)
(日本語仮訳：https://www.boj.or.jp/announcements/release_2022/data/rel221021a4.pdf)
• サードパーティとの関係＝その組織がグループ内企業であるか外部提供者であるかに
かかわらず、金融機関と組織との間に結ばれる製品又はサービスを提供するための、
あらゆる業務上の関係又は契約
• 業務委託関係＝業務委託がなければ金融機関自身により提供されていたビジネス
上の
機能、サービス又はプロセスをサードパーティが提供する
• ICTサプライチェーン＝金融機関が自身の業務を支えるために用いるICTエコシステ
ムを形成
する、サードバーティ間の相互の結び付きから成る
• サプライチェーンには、すべての製品、サービス及びインフラに加え、それらの
提供者、供給者及び製造業者も含まれる
• 更新点：脅威が絶えず変化する環境に対応するために、広範な情報共有と透明性の大

21
• G7の基礎的要素(1)
要素内容
<サードパーティのリスクマネジメントのライフサイクル>
1.ガバナンス金融機関のガバナンス組織は、サードパーティのサイバーリスクマ
ネジメントの効果的な監視及び実行に関する責任を有すること
2.サードパー
ティのサイバー
リスクに対する
リスクマネジメ
ントプロセス
金融機関は、サードパーティのリスクマネジメントのライフサイク
ル全体を通じ、サードパーティのサイバーリスクを管理する有効な
プロセスを有すること
・サードパーティと重要性の特定：金融機関は、サードパーティの一覧及び当
該サード
パーティが金融機関の業務にとってどの程度重要かの理解を維持すること
・サイバーリスクの評価とデューディリジェンス：金融機関は、サードパーティ
と新たな取引関係に入る前、及び関係が継続する間、自らのサイバー戦略と整合
的かどうかを検討するために、サードパーティのサイバーリスク評価及び
デューディリジェンスを実施すること
・契約の構成：金融機関とサードパーティとの契約は、再委託から生じるもの

22
• G7の基礎的要素(2)
要素内容
3.インシデント
対応
金融機関は特に重要なサードパーティを含むインシデント対応計画
を策定し、
演習を実施すること
4.コンティン
ジェンシープラ
ンと出口戦略
金融機関は、サードパーティがサイバー関連のパフォーマンスの期
待要件を満たさない場合又は金融機関の許容範囲を超えるサイバー
リスクをもたらす場合に備えて、適切なコンティンジェンシープラ
ンと出口戦略を有しておくこと
<システム全体のサイバーリスクのモニタリングとセクター横断的な調整管理>
５.潜在的なシ
ステミックリス
クのモニタリン
グ
金融セクター全体にわたるサードパーティとの取引がモニタリング
されるとともに、潜在的にシステミックな影響を及ぼす可能性を有
するサードパーティの
サイバーリスクの要因が評価されていること
6.セクター横断
的な調整
セクターを跨るサードパーティへの依存に関連したサイバーリスク

AGENDA
4. Cloud Security Alliance
「医療におけるサードパーティベンダーリスク管理」

24
4. Cloud Security Alliance「医療におけるサードパー
ティベンダーリスク管理」(2022年7月29日発行)(1)
(https://cloudsecurityalliance.org/artifacts/third-party-vendor-risk-management/)
[構成]
• イントロダクション
• 特定
• サードパーティベンダーの特定と優先順位付け
• サードパーティの関係性からの潜在的リスク
• 保護
• リスク評価
• セキュリティに関する質問
• リスク処理
• 検知
• モニタリング
• 対応
• 対応
• 復旧
• 追加的考慮事項
• クラウド
• 自動化
• プログラムの効果の追跡と改善
出典：CSA Health Information Management WG「Third-Party
Vendor Risk Management in Healthcare」（2022年7月29日）

25
4. CSA「医療におけるサードパーティベンダーリスク
管理」(2)
医療におけるサードパーティベンダーリスク管理が失敗する理由
• 手動のリスク管理プロセスにおける自動化と信頼性
の欠如によって、医療で利用されるデジタルアプリケ
ーションや医療機器のサイバー脅威と拡散に追いつく
ことが困難になっている
• ベンダーリスク評価は、時間と費用を要し、ごくわずか
の組織だけが全ベンダーのリスク評価を行っている
• 重要なベンダー管理のコントロールやプロセスは、
部分的に実装されているか、実装されていない
「重要インフラのサイバーセキュリティを向上させるための
フレームワーク(NISTサイバーセキュリティフレームワーク)
1.1版」(2018年4月16日)
• 特定
• 保護
• 検知
出典：CSA Health Information Management WG「Third-Party
Vendor Risk Management in Healthcare」（2022年7月29日）

26
管理」(3)
サードパーティベンダーの特定と優先順位付け
• 医療機関にとって、業務のサードパーティベンダーへのアウトソーシングは、事
業戦略の一環
• 医療機関が認識すべきサードパーティベンダーのリスク
• サイバーセキュリティリスク：サードパーティベンダーのサイバーセキュリティ制御の不備
により、組織の
データの機密性、完全性、可用性が影響を受けるリスク
• レピュテーションリスク：サードパーティベンダーが関与するインシデントが発生した場合、
医療機関の
ブランドレピュテーションにネガティブな影響が及ぶリスク
• コンプライアンスリスク：事業を遂行するために組織が従わなければならない法律や規制、
内部プロセスの違反から生じるリスク
• プライバシーリスク：サードパーティベンダーと共有する個人データに対する権限のないア
クセスが可能となるリスク
• オペレーショナルリスク：サードパーティベンダーの業務は医療機関の業務と絡み合ってお

27
管理」(4)
保護：サードパーティベンダーのリスク評価
• リスク分析（リスクの特定、推計、評価）プロセスの推奨事項
• ベンダーの分類：
サードパーティベンダーを分類する手法を開発し、個々のベンダーのリスク
評価に
割り当てる
• サードパーティ評価頻度の設定と固有のリスク評価に基づくスコープ：
サードパーティリスク評価は、一度限りのプロセスでなく、継続的なモニタ
リングや再評価を必要とする
• 認識された標準規格を利用したサードパーティ評価の実施：
評価をベンダーおよび内部ステークホルダーと共有し、ベンダーが課題に取
組み、評価結果をリスク登録に記録することを保証する
• パフォーマンスの評価
• 財務リスクの評価

28
管理」(5)
検知：継続モニタリングと脅威インテリジェンス
• 継続モニタリングプログラムの設定によるベネフィット
• ベンダーに対するリアルタイムの洞察を通して、プロアクティブなアプロー
チを可能にする
• 人的ミスや不正確さを防止するために客観的なコンテキストを提供する
• 遅くて費用のかかる人手による評価を実行するのとは反対に、時間や資源を
節約する
• 簡単なカスタマイズを可能にして、自動化とデータインテリジェンスを利用
し、評価が
ベンダーや産業、コンプライアンスのニーズに合わせられる
• 最高のリスクのみに焦点を当てるのを可能にする
• 脅威インテリジェンスサービスプロバイダーの活用
• インターネット上のソース（例．公開Web／ダークWeb上のWebサイト、
フォーラム、マーケットプレイス、ランサムウェア恐喝サイト、貼り付け・

29
管理」(6)
対応：指針となるインシデント対応プレイブック
インシデント対応プレイブックの推奨事項
アクセスを遮断する。企業は、サイバー攻撃の影響を受けるサードパーティへのアクセスを遮断できるようにする必
要がある。
医療提供組織は、残りのネットワークからサードパーティのサイバー資産を分離しなければならない。
サードパーティによる侵害が自組織に影響を及ぼしたか否かを判断する。もし影響があれば、次のステップは、イン
シデントの
範囲や影響度を理解するために、フォレンジック分析を実施することになる。
サードパーティの侵害への関与からの信頼性を評価し、契約条件を確認する。
損害を低減する。これは、追加的なセキュリティタスクや、自システムへのさらなる侵入を最小化するツールを通し
て実現可能に
なる。
起きたことや影響度、復旧計画について、ステークホルダーに伝達する。
インシデントに重要インフラストラクチャの侵害が含まれていたら、72時間以内に、国家安全保障省(DHS)のサイ
バーセキュリティ・
インフラストラクチャセキュリティ庁(CISA)に報告しなければならない。これは、2022年3月に成立した法律の要求
事項である。
インシデントの再発を防止する方法を決定するために、根本原因分析(RCA)を実施する。

30
管理」(7)
復旧：マルチステークホルダーコミュニケーション
• どのような手段で迅速に通常業務に戻すかを考える
• 医療提供組織のサードパーティベンダーがインシデントから復旧する場合、患者
に対する
ケアを継続することが必要不可欠
• インシデント対応チームがイベントを特定したら、影響を受けたベンダーが提供
するサービスの代替ソースを特定するために、積極的にベンダーを関与させる
• サービスが停止しなくても、医療提供組織のデータが公開されるようなケース：
• 法令により、定められた期間内に当局への報告や当事者への通知が求められ
ることが
あるので、インシデント対応プレイブックは、このような要求事項をカバー
すべき
• 復旧の取組中のコミュニケーション：
• 内外双方のステークホルダーと情報を共有する必要がある

31
管理」(8)
サードパーティベンダーとしてのクラウド事業者の管理
管理項目推奨事項
データセキュリティと制御他のサードパーティ管理者とともに、プロバイダーは、クラウドベンダーの内
部統制の強度を評価しなければならない
データ転送データは、インターネットや無線ネットワーク経由で転送される可能性がある。
医療組織は、クラウドコンピューティングベンダーを選定する際に、すべての
法令の要求事項を遵守しなければならない。データが転送・保存される場所を
特定することを忘れてはならない
マルチテナント性医療組織に対して、共有されたハードウェア上でデータが混じり合う可能性を
考慮するよう求める。
ロケーションデータをクラウド上に移転することは、ハードウェアプロバイダーが制御でき
ない遠隔地に資産を移転することを意味する。加えて、データは米国外に保存
される可能性がある。
信頼性クラウドのような共有リソースに依存する場合、医療組織は、必要な時にリ
ソースが利用できないというリスクに直面する。
持続可能性医療組織は、万一クラウドが故障した場合に業務を継続する手段を理解するた
めに、クラウドプロバイダーの災害復旧・事業継続計画が適正であるかを判断

32
4. CSA「医療におけるサードパーティベンダーリスク管
理」(9)
医療組織に求められるクラウドセキュリティ対策
• 多要素認証
• 保存時・転送時双方のデータ暗号化
• 適応型アクセスやアイデンティティプルーフィングなどの連携型ア
クセス制御
• クラウド環境におけるユーザーの行動を管理するデータセキュリ
ティポリシーの開発・展開
サードパーティベンダーリスク管理の負荷を軽減する自動化ソリュー
ション
メリット内容
効率性自動化プログラムは、効率的な評価時間、制御されたプロセス、一貫したワークフロー、正確な文書化を可
能にする。
透明性すべてのサードパーティの記録をスクリーニング・モニタリングすることによって、医療提供組織は、現実
のリスクに対応できる。自動化されたリスクベースのプログラムで重要なのは、適切にデータを利用し、リ
スクを上手に低減するためにリソースを適用することにある。
ポリシーの組
織化と分類
文書へのアクセスを表すために利用する構造によって、文書を分類する。構造は検索可能である必要がある。
迅速な通知自動化プログラムは、違反やリスクを直ちに報告することができる。

33
[参考]CSA「クラウド利用者のためのSaaSガバナンス
の
ベストプラクティス」(2022年6月8日発行)(1)
(https://www.cloudsecurityalliance.jp/site/wp-
content/uploads/2022/08/SaaSGovernanceBestPracticesforCloudCustomers_J.pdf)
[構成]
1. はじめに
2. 概要
3. 情報セキュリティポリシー
4. 情報セキュリティ組織
5. 資産管理
6. アクセス制御
7. 暗号化および鍵管理
8. 運用セキュリティ
9. ネットワークセキュリティマネジメント
10. サプライヤーとの関係
11. インシデント管理
12. コンプライアンス
13. CASBの機能と今後の展望
14. 結論
出典：CSAジャパン「クラウド利用者のためのSaaSガバナンスのベストプラクティス」（2022年6
月8日）

34
[参考]CSA「クラウド利用者のためのSaaSガバナンスの
(https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2022/08/SaaSGovernanceBestPracticesforCloudCustomers_J.pdf)
サードパーティベンダーとしてのSaaS事業者に係るリスク管理ポリシーに盛り込むべ
き項目
推奨項目
サードパーティとの関係に対して、組織内で説明可能な単一の役割または立場
サードパーティ製品またはサービスに依存する業務運営の重要性について、できれば定量的に、その役割ま
たは立場を担う人物が書面による評価を提供することを要件とする
上記で特定した重要性を考慮し、事故がそのようなサードパーティに影響を与える可能性およびそのような
事故が組織の業務に与える影響を評価するための方法論
• 外部監査およびセキュリティレビュー
• セキュリティスコアリング／評価ベンダーのツール
• 顧客組織による監査、侵入テスト、プロバイダの製品またはインフラに対する自動スキャンツール
の使用など、直接的な技術デューデリジェンス
上記に基づいて設定されたリスク閾値は、サードパーティがこれを超えた場合、サードパーティ側（契約で
義務付けられている）、組織自体（何らかの補償的管理を通じて）、またはその両方による是正措置の要求
の引き金となる
上記の閾値を超えるリスクを受容する権限を有する、組織内の単一の説明可能な役割または地位、並びにそ
のようなリスク受容を文書化し正当化するための透明性のあるプロセス

35
[参考]CSA「クラウド利用者のためのSaaSガバナンスの
(https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2022/08/SaaSGovernanceBestPracticesforCloudCustomers_J.pdf)
個々のサプライヤーに合わせた契約書の作成に際しての留意事項
留意事項
製品の可用性だけでなく、基礎となるデータの機密性と完全性についてのサービスレベル合意書（SLA）の
作成
組織が監査や侵入テストなどの外部検証プロセスを受け、その結果を提供することの要求
客観的なリスク評価システムに基づいて、組織が特定した脆弱性を、所定の期間内に解決または低減策を特
定する要求事項
組織が脆弱性の重大性または悪用の可能性を低減するために代償措置を適用できるような脆弱性をサプライ
ヤーが特定した場合，サプライヤーは特定の期間内に組織に通知するという要求事項
組織のデータの機密性、完全性、可用性に影響を与えた、または与える可能性のあるインシデントの調査及
び是正において、サプライヤーが組織に協力するための要求事項
データセンターの新規立地を通知し、好ましくない立地を拒否する権利をサプライヤーに求める要件

36
• 5. Q&A／ディスカッショ
ン

医療におけるサードパーティベンダーリスク管理

Recommended

Recommended

More Related Content

Similar to 医療におけるサードパーティベンダーリスク管理

Similar to 医療におけるサードパーティベンダーリスク管理 (20)

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

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

医療におけるサードパーティベンダーリスク管理