クラウドでの患者データのプライバシーとセキュリティー

米国の法律に基づくクラウド・プロバイダーの責任とクラウド・コンシューマーの責任

この記事の意図する目標は、クラウド・サービスのプロバイダーとコンシューマーの両方が、米国の医療関連の法律で定めるセキュリティーおよびプライバシー要件を遵守できるように支援することです。記事では、該当する法律の概要を説明した後、これらの法律がクラウド・サービスではどのような意味を持つかを検討し、クラウドでの問題としてデータの制御、アクセス、完全性、可用性、共有マルチテナント環境、事故に対する備えと対処、そしてデータ・セキュリティーを取り上げます。(この記事の内容を法律上の助言としては受け取らないでください。)

Erin Gilmer, Attorney at Law

Erin GilmerErin Gilmer は、HIPAA および HITECH を専門に患者を擁護するテキサス州オースティンの弁護士です。Colorado Law School で法律の学位を取得し、2008年にテキサス州法曹界に承認されました。2005年に最優秀の成績で卒業したコロラド大学では、国際的な側面に力を入れて心理学の学位、そして経済学の学位を取得しました。副専攻としたのは、政治学です。彼女は Health 2.0 Austin を発足し、現在そのリーダーとして活躍しています。



2012年 11月 22日

今や、電子カルテや医療機器、そしてモバイル・アプリケーションや Web アプリケーションなどの新しい技術を利用することで、医師が患者の健康状態を改善し、生命を救えるようになっています。医師はこれらの新しい技術を利用して、これまで以上に多くの情報を収集し、収集したデータから患者の健康状態を把握します。これらの技術やそこに格納されるデータは連動し、常に相互作用しながら医療情報を送信します。けれども、医療情報を送信するために使用するシステムはますます複雑になっており、それに伴いリスクと脆弱性も増大しています。個人の医療情報は、もはや医師だけに委ねられているのではありません。特に、データ・ストレージを管理し、医療情報にアクセスできる個々の管理者にも、情報の保護責任が課せられるようになりました。

米国政府は医療情報の機密性を踏まえ、1996年に HIPAA (Health Information Portability and Accountability Act: 医療保険の相互運用性と説明責任に関する法律) を制定し、さらに 2003年に HITECH 法 (Health Information Technology for Economic and Clinical Health (HITECH) Act: 経済的および臨床的健全性のための医療情報技術に関する法律) を制定しました (「参考文献」を参照)。これらの法律では、慎重に扱うべき医療情報の保護責任を持つ事業体がプライバシーとセキュリティーを確保するための対策を講じること、そして情報のプライバシーやセキュリティーが侵害された場合には患者に通知することを義務付けています。

コンシューマーがクラウド・サービスに移行する際には、これらの法律が定める標準を理解し、厳守することが、法律の適用対象事業体としての責任を果たすとともに、健康に関する個人的な話を打ち明ける患者の信頼を維持するカギとなります。クラウド・サービスに伴う問題に対処するための土台を提供するために、この記事ではまず HIPAA および HITECH について、これらの法律、規則、規制が誰に適用されるのかを含め、この 2 つの法律の概要を説明します。その後、クラウド・サービスのコンシューマーとクラウド・プロバイダーの両方が HIPAA と HITECH の規制に抵触することがないように、データの制御、アクセス、完全性、可用性、共有マルチテナント環境での影響、事故に対する備えと対処、そしてデータ・セキュリティーの問題について順に検討していきます。

HIPAA および HITECH 法

HIPAA についての話題では、複数の法律、規則、規制が複雑に組み合わせられていることが無視されがちです。Privacy (プライバシー) と Securiy (セキュリティー) という言葉が、HIPAA と HITECH の両方に不可欠な微妙なニュアンスが考慮されずに専門的な流行語として使用されることが多いため、「コンプライアンス」が意味する内容が曖昧なものになってしまう可能性があります。

HIPAA

保護されるべき医療情報

HIPAA では、特定の情報を、PHI (Protected Health Information: 保護されるべき医療情報) と見なしています。PHI に含まれるのは、患者の過去、現在、そして将来の身体的または精神的健康状態に関する情報、患者に提供された医療の情報、患者の過去、現在、そして将来の医療に対する支払い情報、そして個人を識別する ID 情報です。PHI には、PII (Personally Identifiable Information: 個人識別情報) が組み込まれます。PII は、患者の名前、住所、患者に関連付けられた日付 (誕生日や医療サービスの提供日)、電話番号、FAX 番号、e-メール・アドレス、URL、IP アドレス、社会保障番号 (訳注: 社会保障番号は、米国社会保障局が米国の住民に対して発行している、個人を特定できる番号) 、口座番号、免許証番号、医療記録番号、医療保険受取人番号、機器の ID とシリアル番号、自動車の登録番号と車体番号、生体 ID、そして写真などです。つまり PHI には、患者に関する記録を追跡できるあらゆる固有の識別番号、コード、特徴などが組み込まれます。

EPHI (Electronic Protected Health Information: 保護されるべき電子医療情報) とは基本的に、電子的に作成、受信、保持、送信される PHI あるいは個別に識別可能な医療情報のことです。HIPAA Privacy Rule (プライバシー・ルール) はあらゆる形態 (手書き、印刷、電子、または口頭) のすべての PHI に適用される一方、HIPAA Security Rule (セキュリティー・ルール) は EPHI にのみ適用されます。

HIPAA は、特定の医療情報に関する固有のプライバシー標準およびセキュリティー標準で構成されています。これらの標準はそれぞれ、HIPAA Privacy Rule (略して、Privacy Rule (プライバシー・ルール))、HIPAA Security Rule (略して、Security Rule (セキュリティー・ルール)) と呼ばれます。HIPAA がこの 2 つのルールの適用対象とする事業体には、医療機関、医療保険を扱う事業体、医療情報センターなどが挙げられます。

HSS (Department of Health & Human Services: 米国保険社会福祉省) の Web サイト (「参考文献」を参照) では、以下のように記述されています。

「HIPAA Privacy Rule は、対象事業体が保持する個人の医療情報を連邦政府によって保護し、患者に対して医療情報に関する各種の権利を与えるものです。それと同時に、Privacy Rule では患者の治療やその他の重要な目的のために必要な個人の医療情報を開示できるようにバランスが取られています。」

同様に、Security Rule は「対象事業体が電子的に保護されるべき医療情報の機密性、完全性、可用性を確実にするために適用する一連の保護手段 (管理上の保護手段、物理的保護手段、および技術上の保護手段) を規定します。」

HITECH 法

HITECH 法は、HIPAA の Privacy Rule と Security Rule を拡張し、HIPAA への違反に対する罰則を厳しくしています。以前は HHS の OCR (Office for Civil Rights: 公民権局) は対象事業体だけを管轄としてプライバシーの侵害を適用していましたが、HITECH 法により、HIPAA の Privacy Rule と Security Rule の適用対象は、対象事業体の BA (Business Associate: 事業提携者) にまで拡大されました。BA の定義は、PHI の使用または開示に関与する特定の職務または活動を対象事業体に代わって行うか、対象事業体にサービスを提供する個人または事業体です。現在、OCR が法律執行の対象としている管轄は BA にも及んでいます。BA が、苦情の処理や管理、データ分析、診療内容審査、医療業務管理などのサービスを提供することはよくあります。対象事業体に代わって直接 PHI を保管するクラウド・プロバイダー、あるいは BA を介して間接的に PHI を保管するクラウド・プロバイダーも、BA として見なされるようになりました。


BA としてのクラウド・プロバイダー

クラウド・プロバイダーは、EPHI を委任される BA として独特の立場にあります。HIPAA が制定された時点では、「クラウド」という概念はまだ存在していませんでした。当時は、この概念を予測することもできなかったでしょう。現在、医療情報をクラウドに保管するという方法を選ぶ対象事業体や他の BA の数は、ますます増えてきています。その一般的な理由は、コスト削減、ストレージ管理、プラットフォームの長所、リソースの可用性、バックアップとリカバリー、IT 保守作業の軽減です (「参考文献」を参照)。けれども EPHI をクラウドに保管するということは、事実上、コンシューマーが EPHI をクラウド・プロバイダーに開示していることになります。したがって、そのクラウド・プロバイダーは BA です。このことから、クラウド・プロバイダーが HIPAA および HITECH の規定を遵守することが必要不可欠となっています。

BAA とクラウド

EPHI がクラウドに保管されると、明確な BAA (Business Associate Agreement: 提携事業者契約) の重要性がうやむやになる可能性があります。BAA とは、本質的には SLA (Service-Level Agreement: サービス・レベル・アグリーメント) であり、HIPAA および HITECH へのコンプライアンスに対処するための具体的な条項を規定するものです。対象事業体には、EPHI の提供先 BA と BAA を締結することが義務付けられています。同様に、BA も、EPHI を渡す相手との BAA の締結が必要です。これらの BAA には、BA が HIPAA の Privacy Rule と Security Rule を遵守するという具体的な保証が含まれていなければなりません。BAA に必要となる内容は、サービスへのアクセスとサービスの使用に関する契約条件、サービス期間、サービスの終了条件、サービス終了時のデータ破棄などです。BA がクラウド・プロバイダーである場合は、BAA にそのクラウド・プロバイダーによる情報の処理方法とコンシューマーからの情報の収集、使用、管理の方法を概説するプライバシー・ポリシーも含める必要があります。そして最も重要な点として、EPHI のセキュリティーおよび保護に関する責任をクラウド・プロバイダーに譲るか、あるいはクラウド・プロバイダーと共有するとしても、データの所有権はクラウド・プロバイダーに譲渡されないことを BAA に明記しなければなりません。

HIPAA では、対象事業体が患者の同意を得ることなく、医療行為 (Treatment, Payment or health care Operations (TPO)) に関する EPHI を交換することを許可しています。ただし、開示できるのは、情報交換の目的を実現するために必要な最小限の EPHI だけです。したがって、対象事業体同士、または対象事業体と BA との間で EPHI を交換することはできますが、対象事業体が EPHI を BA に公開する場合には、提供する EPHI を、その BA が適切に保護するという十分な保証を得なければなりません。そのための手段が、BAA (Business Associate Agreement: 提携事業者契約) です。

侵害

HHS では EPHI の侵害を、「保護されるべき医療情報のセキュリティーまたはプライバシーを侵害し、それによって該当する個人の経済、評判、その他に損害を与える危険性のある・・・容認されない情報の使用法または開示」と定義しています。

2009年以降、医療記録に対する大規模な侵害 (500 人以上の医療記録に影響を与えるものとして定義された侵害) において、2100 万人近くの EPHI のセキュリティー侵害が発生しています (「参考文献」を参照)。これらの大規模な侵害のうち、21 パーセントは BA に影響がありました。さらに、OCR に報告された、500 人未満の医療記録が関係する侵害は何万件にも及びます。

大規模な侵害の原因として最も多いのは窃盗 (55 パーセント) です。次いで、EPHI への不正アクセスまたは EPHI の不正開示 (20 パーセント)、情報消失 (11 パーセント)、ハッキング (6 パーセント)、情報の不適切な破棄 (5 パーセント)、不明またはその他の原因 (3 パーセント) と続きます。図 1 に、この内訳を示します。

図 1. 医療データ侵害
大規模な医療データ侵害で最も多い原因

規制ガイドライン

クラウドは新しい概念であるため、規制ガイドラインはまだ完成していません。この記事を執筆している時点で、HHS は HITECH 施行に関する最終的な規則をまだ公開していませんが、NIST (National Institute of Standards and Technology: 米国立標準技術研究所) から発行されているガイドラインはあります。また最近になって、ONC (Office of the National Coordinator for Health Information Technology: 国家医療 IT 調整室) からもガイドラインが発行されました。国家レベルでのガイドラインがないなか、HIMSS (Health Information Management Systems Society: 医療情報管理システム学会) や CSA (Cloud Security Alliance: クラウド・セキュリティー・アライアンス) がガイドラインを発行し始めており、HITRUST 社による CSF (Common Security Framework: 共通セキュリティー・フレームワーク)、CSA による CCM (Cloud Controls Matrix: クラウド管理マトリクス)、CIS (Center for Internet Security: インターネット・セキュリティー・センター) によるベンチマーク、NSA (National Security Agency: 国家安全保障局) による構成ガイドなど、いくつかの業界標準の策定が進められています。

ただし、これらの数字は誤解を招く恐れがあります。窃盗はもはや、紙の図表を盗むことだけではありません。ラップトップを盗むことも含まれます。同様に、情報消失がフラッシュ・ドライブの紛失を意味する可能性があります。さらに、これらの数字は過去のデータ侵害の状態を反映しているものです。電子的に入力されて、(クラウドを含む) 新しい形で保管される情報がますます多くなっていることから、データ侵害の統計の内容も必然的に変わってきます。また、クラウドへのマイグレーションにより、EPHI に対する新手の攻撃が発生しています。これらの悪意のある攻撃が、オフサイトに保管された EPHI の脅威となっているのが現状です。オフサイトでは、当初 EPHI を委ねられた事業体による制御が今までのようには及びません。

データ侵害がどのように発生するかに関係なく、HIPAA 違反には州政府レベルと連邦政府レベルの両方で、刑事処分や民事処罰が課せられます。しかもこれらの罰則は、HITECH 法でさらに厳しくなっています。連邦政府レベルでは、民事上の罰金として 1 年間最大 150 万ドルが課せられ、刑事処分については 10 年の懲役と、最大 25 万ドルの罰金が課せられることもあります。これとは別に、州政府による罰則もあります。

クラウドでの問題

クラウドへのデータの移行には、対象事業体、従来の BA、そして新たな BA であるクラウド・プロバイダーなどにとって HIPAA へのコンプライアンスを複雑にする、クラウドへのデータ移行に特有の問題が伴います。これらの問題には、データの制御、アクセス、可用性、共有マルチテナント環境、事故に対する備えと対処、データ保護が挙げられます。記事の残りでは、このすべての問題について検討します。EPHI をクラウドに保管することには多くの利点があるものの、コンシューマーとクラウド・プロバイダーは、クラウドへのデータ移行に特有のそれぞれの問題が HIPAA および HITECH へのコンプライアンスに与える影響を認識しておかなければなりません。


データの制御

コンシューマーがデータの保管をクラウド・プロバイダーに委ねる場合、それは、データを直接制御できなくなることを意味します。まずは、アプリケーション・レベルでのデータ制御を手放すことになります。さらに、データの地理的配置によってクラウド・デプロイメント・モデルの問題が悪化すると、データを直接制御できる範囲はさらに絞られてきます。そこで問題となるのは、誰がデータにアクセスするかです。データを制御するのが誰であるかを知ること、つまりそのデータに対する責任の所在を知ることが、コンプライアンスをどのように維持するかを理解する上で不可欠になります。EPHI をクラウドに移すとデータの制御も移ることから、コンシューマーとプロバイダーは、サービスが提供される前にデータのプライバシーとセキュリティーに対する責任の所在を BAA に明記する必要があります。

IaaS、PaaS、SaaS でのコンシューマーによるデータの制御

IaaS では、コンシューマーが任意のソフトウェアをデプロイして実行できるように、クラウド・プロバイダーが処理、ストレージ、ネットワークなどのリソースを提供します。コンシューマーはオペレーティング・システム、ストレージ、デプロイするアプリケーション、そして場合によってはネットワーク・コンポーネントも制御できるため、責任が大きくなることを覚悟しなければなりません。PaaS では、プロバイダーでサポートしている言語とツールを使用して、コンシューマーが独自のアプリケーションや入手したアプリケーションをクラウド・インフラストラクチャーにデプロイすることができますが、コンシューマーが制御できるのはデプロイしたアプリケーションのみとなります。SaaS の場合、コンシューマーはクラウド・プロバイダーのアプリケーションを使用するため、制御できるのはほんのわずかな部分に限られます。対象事業体または BA は、それぞれのレベルで提供されるサービスの利点と引き換えに、制御できる範囲を犠牲にすることになります (この記事のクラウド・サービス・レベル・モデルの説明は、主に CSA の「Security Guidance for Critical Areas of Focus in Cloud Computing」に基づいています。「参考文献」を参照してください)。

アプリケーションとインフラストラクチャー

クラウド・コンピューティングのサービス・レベル・モデル (SaaS (Software as a Service)、PaaS (Platform as a Service)、IaaS (Infrastructure as a Service)) はそれぞれに異なるレベルの制御をコンシューマーに許可しますが、多くの場合、制御レベルに応じた代償は、セキュリティーで払うことになります。コンシューマーとプロバイダーはそれぞれの組織にとっての適切なバランスを見つけると同時に、データの制御を失った場合に想定されるリスクを進んで見出さなければなりません。これらのモデルでは、いずれもコンシューマーがクラウド・インフラストラクチャーを制御することはできませんが、IaaS を利用する場合には制御の幅が広がり、PaaS を利用する場合、SaaS を利用する場合の順で、制御できる部分が少なくなっていきます。アプリケーション・レベルまたはインフラストラクチャー・レベルで契約が締結された場合でも曖昧なまま残るのは、元のデータ所有者がデータを完全には制御できなくなることによって、データに対する責任が完全にクラウド・プロバイダーに移されるのか、それとも責任の一部が移されるのかという点です。HIPAA および HITECH へのコンプライアンスが意味することは、EPHI データを誰が制御しようとも、データを制御する当事者に、アクセス・セキュリティー、データ侵害の監視、監査、リスク管理をはじめとする多数の分野での責任の比重が重く置かれるということです。

デプロイメント・モデル

アプリケーション・レベルであるか、インフラストラクチャー・デベルであるかに関係なく、クラウドのデプロイメント・モデル自体がデータの制御に影響を与えます。「パブリック・クラウド」モデルでは、インフラストラクチャーが一般に公開されるため、データをデプロイすると本質的に制御が失われます。その対極にある「プライベート・クラウド」モデルでは、インフラストラクチャーが公開されるのは単一のコンシューマーに対してだけです。「コミュニティー・クラウド」は特定のコミュニティーにだけ公開され、「ハイブリッド・クラウド」はパブリック・クラウド・モデルとプライベート・クラウド・モデルの両方を使用します。最大限の制御レベルで最大限のプライバシーとセキュリティーを確保するには、プライベート・クラウド・モデルを使用して EPHI を保管するべきですが、パブリック・クラウドを使用して EPHI を保管することも可能です。実際、CDC (Centers for Disease Control and Prevention: 米国疾病管理予防センター) では症候群発生監視データの保管にパブリック・クラウドを使用しています (「参考文献」を参照)。けれども、パブリック・クラウドを使用すると EPHI の脆弱性が増すため、コンシューマーがこのモデルを使用することにした場合は、より慎重な検討をする必要があります。

多くのクラウド・プロバイダーは EPHI の特異性を理解し、デプロイメント・モデルを変更して EPHI の保管に特化したクラウド・サービスを提供するようになっています。例えば、いくつかのプロバイダーではクラウド・サービスの一部を分離して、EPHI 関連のデータ専用としています。このようなサービスを提供しているプロバイダーはまだ少数派ですが、EPHI 専用のサービスにかかるコストは、コンシューマーにとって不本意な場合もあります。したがって、アプリケーション・レベルおよびインフラストラクチャー・レベルでの場合と同じく、コンシューマーはデプロイメント・モデルとして、パブリック・クラウド・モデル、プライベート・クラウド・モデル、コミュニティー・クラウド・モデル、またはハイブリッド・クラウド・モデルを採用することで、許容できるリスクの程度を選択しています。コンシューマーがデプロイメント・モデルとしてどれを選んだとしても、クラウド・プロバイダーがデータを制御できる範囲を考えると、クラウド・プロバイダーに HIPAA および HITECH の規定に従って EPHI のプライバシーおよびセキュリティーを確保する義務があることに変わりはありません。

地理的な場所

クラウド・サービスでは、データを複数の場所に保管することができます。これは、緊急事態 (停電、火災、破壊行為、システム障害、自然災害など) が発生した場合にはメリットがあります。コンシューマーが業務を行う場所とは異なる場所 (冗長化されていたり、バックアップ・データが取られたりしている場合は、異なる複数の場所) にデータが保管されていれば (または、冗長データやバックアップ・データとして保管されていると)、重要なビジネス・オペレーションを中断せずに継続できることがさらに保証されます。

その一方、データがどこに置かれているかを知らないコンシューマーは、別のレベルで EPHI の制御を失うことになります。データが置かれている場所を知らなければ、遵守すべき法律、規則、規制を知ることはできません。ある特定の地理的な場所では、EPHI に国際法が適用されて、データに対するアクセス権の所在が HIPAA および HITECH 法に反して変更される場合も考えられます。


データ・アクセス

コンシューマーによるデータの制御がさまざまなレベルで失われることを考えると、誰がデータにアクセスできるか、そしてアクセスをどのように管理するかが問題になってきます。最低限必要な規則に従えば、EPHI へのアクセスは、EPHI にアクセスする必要のあるユーザーのみができるように制限しなければなりません。しかし、クラウド・プロバイダーが管理するデータが、複数の場所 (それぞれの場所には、そこに勤務している従業員がいるか、そうでなければサード・パーティーの契約作業員がいます) に保管されると、事態は複雑になってきます。関与する事業体の数が増えれば、クラウド内の EPHI にアクセスする機会を持つ個人の数も増え、それによってデータのセキュリティー・リスクも大きくなります。

セキュリティーを確保するには、クラウド・プロバイダーとコンシューマーが協力してアクセス特権を作成および変更する手段を実装し管理しなければなりません。そのための最初の一歩は、特定のアクティビティー (ファイルの読み取りやプログラムの実行など) を行う権限を与えるユーザーまたはコンピューター・システムを決定することです。

個人へのアクセス権限の付与

コンシューマーがクラウドに保管するデータへのアクセス権限を与える相手を定義する責任は、コンシューマー自身にあります。そして、コンシューマーが決定した内容を施行するのはクラウド・プロバイダーの責任です。けれども一般には、EPHI にアクセスする可能性のあるすべての従業員が、機密情報取扱作業従事者としての許可手続きを経なければなりません。コンシューマー、クラウド・プロバイダー、そしてクラウド・プロバイダーの提携先が、各個人に割り当てられた職務と責任を正確に反映した職務明細書を作成し、職務履行の監視を実施する必要があります。

クラウド内の EPHI に対するアクセス権限を付与されたすべての従業員 (クラウド・プロバイダーまたはコンシューマーのどちらの従業員であるかに関わらず) には、固有のユーザー名を付与し、それらのログイン情報の機密を保持する方法に関するトレーニングを提供する必要があります。さらに、これらの従業員が、HIPAA の Privacy Rule と Security Rule に関する公式トレーニングを受けることも必要です。ユーザーには、それぞれに定義された役割に応じてアクセス権限を付与し、必要に応じて即座にアクセス権限を変更または取り消してください。

認証

HIPAA では、EPHI にアクセスしようとする個人または事業体にその権利があることを検証する手順を実装するように規定しています。この検証は、従業員固有のユーザー名とパスワードや、その他の判断基準を含めたログイン・システムによって行うことができます。しかし、コンシューマーのシステムとクラウド・プロバイダーのシステムの両方に対する複数のログインを管理すると厄介なことになるという理由で、一部のクラウド・プロバイダーはコンシューマーの社内認証システムを統合できるようにしています。認証システムを統合する手段には、LDAP (Lightweight Directory Access Protocol) メカニズムまたは SSO (Single Sign-On: シングル・サインオン) 技術がありますが、これらの手段自体が別のセキュリティー・リスクをもたらす恐れがあります。

クラウド・プロバイダーは、SAML (Security Assertion Markup Language) を使用して、リアルタイムの認証、トランザクションの許可、およびユーザー・アクセス権限の付与と取り消しを行うこともできます。ただし、NIST による「Guidelines on Security and Privacy in Public Cloud Computing (パブリック・クラウド・コンピューティングにおけるセキュリティーおよびプライバシーに関するガイドライン)」(「参考文献」を参照) によると、SAML では十分でない可能性があるため、クラウド・プロバイダーがさらに XACML (eXtensible Access Control Markup Language) を使って「クラウド・コンシューマーの特権を適応させてリソースに対するアクセス制御を維持する」場合もあります。

アクセスの監査

アクセスに関して最も重要なことは、クラウド・プロバイダーとコンシューマーの両方が、アクセス監査手順に同意しなければならないことです。セキュリティー・ルールでは、EPHI の不適切な開示を見つけられるように、情報システムのアクティビティーに関するレコード (監査ログ、アクセス・レポート、セキュリティー・インシデント追跡レポートなど) の定期的な審査を義務付けています。さらに、EPHI が含まれる情報システム、あるいは EPHI を使用する情報システムでのアクティビティーを記録および検査するためのハードウェアとソフトウェア、そしてこれらの手順を実施するための仕組みを実装しなければなりません。HITECH 法では EPHI の侵害を監視することまで要求しています。EPHI の侵害の監視は、HIPAA と HITECH の規制では重要な検討事項となります。なぜなら、これは、事故への対処と侵害通知に関する法律に適用されるだけでなく、最終的には侵害を食い止めてその被害を軽減できるかどうかに関わってくるためです。

完全性

EPHI の完全性は、誰がデータへのアクセス権限を持っているかによって影響されます。コンシューマーとプロバイダーが、クラウドに保管される EPHI へのアクセス権限を持つユーザーを設定しなければならないだけでなく、データの完全性を確保し、偽造から保護することも重要です。実際のところ、データの完全性は、HIPAA の Security Rule の主要な目標の 1 つとなっています。この Security Rule では、完全性を「データまたは情報が不正に改変または破壊されていない状態であることを表す性質」として定義しています。EPHI をクラウドに保管すると、EPHI にアクセスするための手段が増えるため、データの完全性を確実にすることが一層困難になります。


共有マルチテナント環境

パブリック・クラウド・サービスがコストの削減を提供できる理由は、多くの場合、パブリック・クラウドのインフラストラクチャーには共有マルチテナント環境が含まれており、その環境でコンシューマーが他の知らないコンシューマーと、コンポーネントやリソースを共有するためです。けれども、共有マルチテナント環境には、コンシューマーが自分以外のコンシューマーのデータにアクセスできる可能性が生じたり、コンシューマー同士のデータが入り混じる可能性が生じたりするなど、多くのリスクが伴います。しかも、共有マルチテナント環境では、あるコンシューマーのリソース使用状況によって他のコンシューマーが使用可能なリソースが減ってパフォーマンスが低下したり、クラウド・プロバイダーによるアップグレードやパッチの適用がコンシューマーのビジネス・オペレーションの妨げになったりする可能性もあります。さらに、共有インフラストラクチャーではクラウド・プロバイダーがテナント別にアクティビティーを分離することができないというリスクも考えられます。その場合、HIPAA と HITECH へのコンプライアンスを維持するために不可欠な、アクセスの監視と監査、そしてデータの削除に影響が出ます。これらの問題に対処するには、クラウド・プロバイダーが例えば仮想化技術、アプリケーション・レベルの分離、あるいはデータベース・レベルの分離などの分離手法を明確に定義しなければなりません。


データの可用性

HIPAA の Security Rule の理念の 1 つは、EPHI の可用性を実現することです。特に、緊急事態やその他の事故に直面した場合でも、EPHI の可用性は維持されなければなりません。EPHI をクラウドに移す利点の 1 つとして、クラウド・サービスではさまざまな方法でデータの可用性を高められることが挙げられます。冗長データを複数の場所に保管するクラウド・サービスは、緊急事態からリカバリーする能力が優れているはずです。また、オンデマンドのリソース・キャパシティーにより、サービスの需要が増大した場合のレジリエンシーを実現し、プラットフォームでのパッチの適用や保守のための計画的なサービスの中断を最小限にすることができます。さらに、クラウド・サービスは、DoS (Denial of Service: サービス拒否) 攻撃を緩和することにもなります。DoS 攻撃は、多数の偽のリクエストによってターゲットを飽和状態にし、正当なリクエストにタイムリーに応答できないようにして、データを使用できない状態にしてしまう可能性があります。

クラウド・サービスは、インターネットまたは仮想プライベート・ネットワーク (Virtual Private Network: VPN) 上で提供することができます。そのための手段となるのは、Web ブラウザーや、クラウド・プロバイダーが提供するアプリケーション、つまりインターフェースを提供するサービスです。けれどもインターフェースを提供することによって、送信中のデータの傍受、データの改ざんや破損、クライアントおよびサーバーのエンドポイントでの認証のリスクなどに EPHI をさらすことになります。OWASP (Open Web Application Security Project) では、アプリケーションのアーキテクチャーと設計、およびソフトウェア開発ライフサイクル全体をとおして対処しなければならない Web アプリケーションの脆弱性トップ 10 のリストを公開しています。


事故への備えと対処

HIPAA および HITECH へのコンプライアンスでは、事故への対処が鍵を握る可能性があります。いかに多くの保護対策を実装したとしても、すべての事故 (災害、不正アクセス、窃盗、ハッキング、紛失、従業員の誤りなど) を防げるわけではないことを踏まえ、HIPAA の Privacy Rule と Security Rule では以下の点を強調しています。

  • 事故に対処し、損害を軽減することの重要性
  • 重要なビジネス・オペレーションの中断を抑えること
  • EPHI のセキュリティーおよびプライバシーを確保すること

事故への備え

事故が発生する前から、コンシューマーとプロバイダーは危機管理計画などの特定のポリシーと手順を用意しておかなければなりません。また、脅威と脆弱性の監視も積極的に行わなければなりません。HIPAA の Security Rule で第一に要件としている保護対策は、リスク・アセスメントの実施です。コンシューマーは、社内に保管されているデータと、クラウドなどの社外に保管されているデータの両方に対し、定期的に独自のリスク・アセスメントを実施しなければなりません。クラウド・プロバイダーも、クラウド・インフラストラクチャーのリスク・アセスメントを実施しなければなりません。発見された脆弱性は記録する必要があります。クラウド・プロバイダーの場合、これらの脆弱性をコンシューマーに報告し、コンシューマーが脆弱性に伴うリスクを許容できるかどうか、あるいは脆弱性への対処方法を判断できるようにする必要があります。

EPHI の保管場所を特定し、リスク・アセスメントを実施するとともに、コンシューマーはデータがバックアップされていることを確実にする必要があります。具体的に言うと、EPHI の「元通りに回復できる完全なコピー」を作成し、保持するということです。クラウド・サービスによるオフサイト・データ・バックアップは、この要件を満たす上で役立ちますが、それでもまだ、バックアップを保持する場所の問題や、バックアップ・データへアクセスする方法の問題、バックアップを実施する時間間隔の問題、バックアップを保持する期間の問題などが残されます。

また、前述したとおり、アクセスの管理も重要です。コンシューマーとクラウド・プロバイダーはアクセスを監視して、アクセス権限を与えられて認証可能なユーザーだけが EPHI にアクセスできることを確実にしなければなりません。アクセス権限を失ったユーザーは、必ずユーザー・リストから削除する必要があります。

もう 1 つ重要な点として、クラウド・プロバイダーとコンシューマーは、継続的に脆弱性のテストを行い、テスト結果に応じてポリシーと手順を修正しなければなりません。クラウド・プロバイダーは、テストの結果として行った変更や見つかった問題をコンシューマーに直ちに報告しなければなりません。

事故への対処

クラウド・プロバイダーは、事故への対処において重要な役割を果たします。クラウド・プロバイダーには、事故の検証、分析、収束、そしてデータの収集、保護、問題是正、サービスの回復といった責任があります。前述のように、攻撃を分析して事故に対処する上で重要となる最初のステップの 1 つは、監査ログを使用することです。プロバイダーが監査ログやその他の科学的犯罪情報を調査した後は、EPHI の機密性、完全性、可用性を確保する必要性を念頭に置いて、事故の収拾作業を進めていく必要があります。冗長データやバックアップ・データを使用することで、クラウド・プロバイダーが問題を是正できる場合や、事故以前の状態に戻すことができる場合もあります。

コンシューマーは、事故が発生した場合にクラウド・プロバイダーに要求する事項の概要をまとめる必要があります。特に重要なのは、事故の検証方法、そして事故分析に使用する情報の収集方法です。さらに、コンシューマーとクラウド・プロバイダーがリカバリー時刻の目標およびリカバリー・ポイントの目標を話し合い、両者が協調して事故に対処できる態勢を整えておくことも必要です。


データ保護

送信中のデータ、保管中のデータ、またはバックアップ・データを保護するには、いくつかの手段があります。ほとんどの保護手段は、EPHI を管理するクラウド・プロバイダーが講じなければなりません。これらの保護手段には、データ侵害の監視、暗号化、鍵管理、データの削除が含まれます。

データ侵害に対する監視

コンシューマーがデータの制御をクラウド・プロバイダーに委ねるということは、システムでデータ侵害を監視するためにクラウド・プロバイダーが使用するプロセスに依存するということになります。これらのプロセスには、例えばファイアウォールの使用、ネットワークへの侵入の検出、サーバー・ログの監視、エンド・ユーザーのファイル・アクセス監視などがあります。どの手法を使うにしても、クラウド・プロバイダーは使用しているプロセスが適切に機能していることを定期的にチェックしてください。データ侵害が検出された場合、あるいは脆弱性が見つかった場合には、コンシューマーに報告しなければなりません。

暗号化

許可されていない個人がデータを使用、読み取り、あるいは解読できないようにするために、事業体はデータを暗号化することができます。HIPAA の Security Rule に基づく EPHI 暗号化は、「アルゴリズムに基づくプロセスにより、機密プロセスまたは鍵を使用しなければ意味を付与できる可能性が低い形にデータを変換する」ことであり、暗号解読を可能にする機密プロセスまたは鍵が侵害されていないことが前提となります。OCR によると、コンシューマーとクラウド・プロバイダーは、NIST でテストされて有効であるとみなされた暗号化プロセスを使用することができます。保管中のデータについては、NIST Special Publication 800-111 に従ったデータ暗号化でなければなりません。送信中のデータの暗号化は、NIST Special Publications 800-52 および 800-77 に準拠していれば有効です (「参考文献」を参照)。

鍵管理

暗号鍵管理方式も、データを保護する手段です。この手段は、コンシューマーが使用することもできますし、クラウド・プロバイダーが提供することもできます。鍵管理をすでに導入しているところもありますが、業界標準はまだ揃っていません。鍵管理は現在、IEEE (Institute of Electrical and Electronics Engineers) や OASIS (Organization for the Advancement of Structured Information Standards)、そして KMIP (Key Management Interoperability Protocol) の開発者などによって、標準が策定されつつあります。鍵管理方式をすでに使用している場合には、鍵ストアのセキュリティーを確保する方法、鍵ストアへのアクセス制限、バックアップおよびリカバリー・ソリューションの実装などの点について考慮する必要があります。

データの削除

HIPAA の Security Rule では、対象事業体および BA は「保護されるべき電子医療情報と、この情報を保管したハードウェアまたは電子メディアの最終的な破棄に対処するためのポリシーと手順を実装すること」が義務付けられています。したがって、要求された場合には、クラウド・プロバイダーは EPHI が適切に削除され、バックアップ・コピーからでも再現できないことを確実にしなければなりません。このようにデータを完全に消去するには、上書きや消磁、またはその他の手段によって EPHI をストレージ・メディアから抹消しなければならないことが考えられます。OCR では、NIST の『Guidelines for Media Sanitization (記録媒体のサニタイズ・ガイドライン)』に準拠していれば、EPHI を保管または記録したメディアが消去、パージ、または破壊されているものと見なします。パブリック・クラウドでは、物理的に配置または混蔵されたデータによってデータ破棄が複雑になり、さらに処理に手間がかかる可能性があります。


まとめ

データ・ストレージの様相が変わり、クラウドに移される EPHI が増えているなか、HIPAA と HITECH に示される内容が指す意味も変わってきています。EPHI を完全に保護するための HIPAA の Privacy Rule と Security Rule は、今では BA にも適用されるようになりました。BA には、クラウド・プロバイダーも含まれます。コンシューマー (対象事業体と BA の両方を含む) とクラウド・プロバイダー (BA) との間で EPHI を移すと、責任の所在が変わってきます。コンシューマーからクラウド・プロバイダーに完全に責任が移る場合もあれば、両者の間で責任を共有する場合もあります。このような変更は、コンプライアンスにも影響してきます。

クラウドでは、データの制御、アクセス、可用性、共有マルチテナント環境、事故に対する備えと対処、データ保護という問題が持ち上がります。これらの問題を理解することで、クラウド・プロバイダーとコンシューマーはそれぞれの責任を認識できるようになります。

突き詰めると、データに対する責任は HIPAA および HITECH へのコンプライアンスにとってのみならず、患者からの信頼を確保する上でも重要です。医師は BA を信頼して、患者が打ち明けた最も私的で重要な情報を委ねます。そのような患者の EPHI はクラウドに保管される場合がありますが、その EPHI のセキュリティーが侵害されたとすれば、患者は医師への信頼を失くすでしょう。その結果、患者の治療が危険にさらされる可能性もあります。このように、HIPAA と HITECH には、法律を超えた重要性があります。EPHI は単なるデータではありません。それは、個人、その個人の健康、そして生命を表します。

参考文献

学ぶために

製品や技術を入手するために

  • ご自分に最適な方法で IBM 製品を評価してください。評価の方法としては、製品の試用版をダウンロードすることも、オンラインで製品を試してみることも、クラウド環境で製品を使用することもできます。また、SOA Sandbox では、数時間でサービス指向アーキテクチャーの実装方法を効率的に学ぶことができます。

議論するために

  • developerWorks コミュニティーに参加してください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者によるブログ、フォーラム、グループ、ウィキを調べることができます。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=846084
ArticleTitle=クラウドでの患者データのプライバシーとセキュリティー
publish-date=11222012