アーキテクチャ: HIPAA 対応の Cloud Healthcare

このソリューションでは、HIPAA 対応の Cloud Healthcare リファレンス インフラストラクチャを紹介します。このリファレンス インフラストラクチャは、Google Cloud のベスト プラクティスをカプセル化したエンドツーエンドのアーキテクチャであり、ヘルスケアのセキュリティ、プライバシー、コンプライアンスのニーズを満たすのに役立ちます。

免責事項

  • このソリューションは、HIPAA またはその他のデータ プライバシーに関連する法律を準拠するために実施する必要がある、適切な、管理上、技術上の物理的安全保護対策に基づく法的助言を提供するものではありません。
  • このソリューションの範囲は、リファレンス アーキテクチャの実装に限定されます。このアーキテクチャでの実装は、公式の Google プロダクトではありません。リファレンス実装として意図されたものです。コードは、Apache License Version 2.0Google Cloud Healthcare デプロイ自動化ユーティリティとしてオープンソースで利用可能です。このガイドをクイック スタートガイドとして使用し、ユースケースに合うように構成できます。ユーザーは、Google Cloud 上に構築する環境とアプリケーションが、HIPAA の要件に従って正しく構成され、保護されていることを確認する責任があります。

このアーキテクチャは、機密扱いの医療情報をクラウドに転送できるように設計されています。

HIPAA の概要

HIPAA(1996 年に制定された医療保険の相互運用性と説明責任に関する法律)は、個人を特定できる医療情報を保護するために米国内で定められた基準です。HIPAA は、保護対象保険情報(PHI)を電子的に管理するヘルスプラン、多くの医療従事者および医療クリアリング ハウス(総称して「対象事業者」)および「関連事業者」と呼ばれる特定の機能を代行する個人または事業者に適用されます。

HIPAA プライバシー ルールは、対象事業者とその関連事業者に、あらゆる媒体で扱われる PHI の機密性を保護することを求めています。一方、HIPAA セキュリティ ルールは、電子的に作成、受信、維持、または転送する PHI の機密性、整合性、および可用性を管理的、物理的、および技術的手段を使用して保護することを義務付けています。対象事業者および関連事業者にも違反通知ルールおよび義務があります。

HIPAA という語の定義、HIPAA ルールの詳細、および個々の Google Cloud 製品によるそれらのサポート状況の詳細については、Google Cloud HIPAA 概要ガイドをご覧ください。

アーキテクチャの図

このアーキテクチャは、HIPAA 対応の Google Cloud プロジェクトの設定チュートリアルを参照し、Cloud Healthcare データ保護ツールキットを使用しており、構成をコードとして扱うことで、Google Cloud ベースのインフラストラクチャをわずかなステップでビルドできます。次の図は、このアーキテクチャの再利用可能な構成要素である Google Cloud Cloud Deployment Manager 構成スクリプトとパラメータ化された構成テンプレートを使用して、セキュリティとコンプライアンスのベスト プラクティスを実現する方法を示しています。

HIPAA 対応リファレンス アーキテクチャの再利用可能なコンポーネントを示す図

このアーキテクチャは、特定の使用事例やプロダクトをデプロイする際にカスタマイズできるクイックスタートとして設計されています。このままデプロイできる最終的なプロダクトを生成するものではありません。ほとんどのコンポーネントは Cloud Deployment Manager スクリプトを使用して実装しますが、Cloud VPN Dedicated Interconnect や多要素認証などの一部の機能は既存のシステムと統合する必要があるため、カスタマイズ作業が必要です。

アーキテクチャ コンポーネント

次の表は、アーキテクチャのコンポーネントをまとめたものです。詳細については後で説明します。

アーキテクチャ コンポーネントの概要

コンポーネント 目的
データ用の 1 つの Google Cloud プロジェクト Cloud Storage バケット、Compute Engine VM、BigQuery データセット、および Pub/Sub トピックで構成されるベース プロジェクト。このプロジェクトは組織の下に作成され、請求 ID が付与されます(詳細については、組織データの暗号化をご覧ください)。
Cloud Monitoring アカウント セキュリティと IT 管理目的でのモニタリング
Cloud Identity アクセス制御グループを作成し、このグループを組織ノードのユーザーに適用する際に使用します(詳細については、サービス アカウントをご覧ください)。
IAM Cloud Identity グループにプロジェクト リソースへのアクセス権と、それらを変更または使用する権限を付与します(詳細については、Identity and Access ManagementIAM のロールをご覧ください)。
セキュリティ運用のための 2 つの Google Cloud プロジェクト Google Cloud 構成に異常が検出された場合にセキュリティ管理者に通知するための一連のモニタリング ポリシーとアラートを実装する、Forseti Security インスタンスを保持するプロジェクト(詳細については、Forseti セキュリティ モニタリングとルールの適用BeyondCorp のセキュリティ アプローチをご覧ください)。

もう 1 つのプロジェクトは、監査ログ用の Cloud Storage バケットと BigQuery データセット、リソースとデータアクセスのロギング、長期ストレージ、セキュリティ分析のためのログの可用性に関するものです。
共有ネットワーク制御用の 1 つの Google Cloud プロジェクト Cloud VPN Cloud Interconnect、Cloud Router、Virtual Private Cloud(VPC)、サブネット、ファイアウォール ルール用のプロジェクトです。適切な接続性とネットワーク制御機能を備えた共通のネットワーク プロジェクトが含まれる共有 VPC をインストールします。

このセクションでは、アーキテクチャのコンポーネントと関連するベスト プラクティスについて詳しく説明します。内容は次のとおりです。

  • Google Cloud 内のプロジェクト
  • Identity and Access Management(IAM)
  • サービス アカウント
  • 世界規模の Google ネットワークと企業の接続オプション
  • VPC ネットワーク
  • 監査ロギング
  • セキュリティのモニタリングとアラート ポリシー

Google Cloud 内のプロジェクト

Compute Engine VM や Cloud Storage バケットなどの Google Cloud リソースをリソース階層に応じて組織化します。階層の最上位ノードは組織ノードで、その下には複数のプロジェクトがあります。1 つのプロジェクトに複数のアプリが含まれる場合もあれば、逆に 1 つのアプリに複数のプロジェクトが含まれる場合もあります。プロジェクト内のリソースを複数のリージョンや地域に分散することもできます。

権限設定などのセキュリティ機能を組織レベルで設定すれば、リソース階層全体で継承されます。また、必要に応じてより細かく設定することもできます。

プロジェクトを作成するときは、そのプロジェクトで作業する人々にとってわかりやすい名前を付けることをおすすめします。単純なことではありますが、こうした命名規則は、正しいプロジェクトで作業し、最小特権の原則を使用した職掌分散をサポートするのに役立ちます。

このアーキテクチャでは職掌分散と最小特権の例を示します。セキュリティ モニタリング プロジェクト(監査と Forseti のリソース)は、コアデータ分析プロジェクトとは異なるユーザーによって所有されます。中央のネットワーク プロジェクトには独自の権限ポリシーがあります。

プロジェクトを作成したら、ユーザーに役割を付与してアクセス権を与えます。次のセクションで説明するように、役割を個人に割り当てるのではなく、グループ機能を使用して役割を割り当てることをおすすめします。

ID とアクセスの管理

Identity and Access Management(Cloud IAM)サービスを使用して組織のユーザーを設定します。このサービスでは、一連の権限を定義する役割を利用します。IAM を使用して、データ転送、分析、セキュリティ監査の際のさまざまなリソースへのアクセスを制御します。詳細については、エンタープライズ企業のベスト プラクティスをご覧ください。

権限は直接割り当てるのではなく、同じ業務に携わるユーザーをグループにまとめて、IAM の役割を個々のユーザーではなくグループに割り当てることをおすすめします。たとえば、BigQuery データ閲覧者の役割には、BigQuery テーブルの一覧表示、読み取り、クエリを行う権限が含まれていますが、テーブルの作成や既存データの変更を行う権限は含まれていません。

プロジェクトと同様に、役割の割り当て先として作成するグループには意味のわかりやすい名前を付与すると効率的です。たとえば、読み取り専用で分析を行うために Cloud Storage データへのアクセス権を付与するグループには、${org}-*readonly@${org.tld} などを名前を付けます。

次に、リファレンス アーキテクチャで使用されているグループを示します。

グループ 目的 権限
プロジェクト レベルのアクセス
${org}-project-owner@${org.tld} プロジェクト オーナー オーナー
{org}-project-auditor@${org.tld}$ ${org}-health-data のセキュリティ審査担当者、${org}-audit-logs-retention のオーナー セキュリティ審査担当者、オーナー

サービス アカウント

サービス アカウントは特別なタイプの Google アカウントであり、個々のユーザーではなく、Google Cloud サービスの ID またはアプリを表します。ユーザーやグループと同様に、サービス アカウントにも IAM の役割を割り当て、特定のリソースへのアクセス権を付与できます。サービス アカウントの認証はパスワードではなくキーで行います。IAM Service Account API を使用して、キーのローテーションを実装します。Deployment Manager の実行やログのエクスポートなどのサービス間通信にはサービス アカウントの使用をおすすめします。

クラウドの接続性

既存のオンプレミス インフラストラクチャを Google Cloud リソースに接続することもできます。その場合は、帯域幅、レイテンシ、SLA の要件を検討して最適な接続方法を選択する必要があります。インターネット経由で Google Cloud に接続することなく、オンプレミスと VPC ネットワーク間で安定したデータ転送を実現するために、低レイテンシで高可用性のエンタープライズ レベルの接続が必要な場合は、Cloud Interconnect を使用します。

  • Dedicated Interconnect は、オンプレミス ネットワークと Google のネットワークを物理的に直接接続します。
  • Partner Interconnect は、サポート対象のサービス プロバイダを介して、オンプレミス ネットワークと Google Cloud VPC ネットワークを接続します。

Cloud Interconnect の低レイテンシと高可用性を必要としない場合や、クラウドの利用を始めたばかりの場合は、Cloud VPN を使用して、オンプレミス ネットワークと VPC 間に暗号化された IPsec VPN トンネルを設定するという方法があります。

Virtual Private Cloud

VPC ネットワークは、ネットワーク、サブネット、IP アドレス、ルート、ファイアウォール、VPN、Cloud Router など、Google Cloud の基盤となるネットワーキング テクノロジーで構成されます。この基盤を使用して、単一のグローバル VPC ネットワークを共有し、リージョン サブネットに追加できるコンピューティング インスタンスとコンテナを作成できます。

この構成では、すべてのネットワーキング リソースに対するネットワーク ポリシーと制御が集中化され、管理が容易になります。サービス プロジェクト部門はネットワーク以外のリソースの構成と管理を行います。これにより、組織内のさまざまなチームの責任を明確に分離できます。プロジェクト内のリソースは、内部 IP アドレスにより、プロジェクト境界を越えて安全かつ効率的にやり取りできます。

さらに、プライベートの内部 IP アドレスしか持たないリソースであっても、限定公開の Google アクセスを使用して、多くの Google API やサービスにアクセスできます。アプリケーションのフロントエンドを構成してインターネット リクエストを受信し、バックエンド サービスをパブリック エンドポイントから保護できます。サブネット、ルート、ファイアウォールなどの共有ネットワーク リソースをホスト プロジェクトから集中管理できるため、プロジェクト間で一貫したネットワーク ポリシーを適用できます。

監査ロギング

Cloud Logging と Cloud Monitoring を使用することで、ログデータとイベントの保存、検索、分析、モニタリング、およびアラートの発信を行えます。このアーキテクチャでは、管理アクティビティのログとデータへのアクセス(読み取りと書き込み)がデフォルトで有効になっています。ベスト プラクティスとして、すべての Cloud Logging ログを、Cloud Storage にエクスポートして長期間保持することをおすすめします。ログは、別のプロジェクトにある BigQuery データセットにエクスポートされるように構成されています。セキュリティ分析には BigQuery UI を使用できます。Google Cloud は、Splunk などの他のセキュリティ分析ツールとのログファイルの結合もサポートしています。さらに、Cloud Storage ログバケットのオブジェクト バージョニングを有効にしたり、監査ログ プロジェクトにリーエンを適用したりして、ログが誤って削除されるのを防止できます。詳細については、ログ配信の設定をご覧ください。

セキュリティのモニタリングとアラート ポリシー

このアーキテクチャは、Google Cloud 用のオープンソース ツールである Forseti を利用して、プロジェクト リソースの追跡とセキュリティ ポリシーのモニタリングを行います。Forseti は、Google Cloud プロジェクト リソースを体系的にモニタリングして、アクセス制御が意図したとおりに設定されていることを確認するのに役立ちます。Forseti は、ルールベースのポリシーを作成してセキュリティ ポリシーをコード化します。その後、想定外の変化が起こった場合は、通知を送信するか、場合によっては既知の状態に自動的に戻すなどのアクションを実行します。次の表は、このアーキテクチャで実装されている Forseti のルールを示しています。

ルール 説明
監査ロギングルール デフォルトですべての監査ロギングを有効にする必要があります(管理者アクセス、データの読み取りと書き込み)。
BigQuery ルール パブリック、ドメイン、特別なグループのデータセットへのアクセス権がないようにします。
バケットルール すべての ACL ルールを禁止し、IAM のみを許可します。
有効な API のルール ホワイトリストに登録されている API のみが有効になります。
IAM ルール すべてのプロジェクトでドメインのオーナー グループが必要です。
リーエンルール すべてのプロジェクトでプロジェクト削除リーエンが必要です。
ロケーション ルール すべてのデータセットは指定されたロケーションに存在する必要があります。
ログシンク ルール すべてのプロジェクトに BigQuery ログシンクが必要です。

詳しくは Forseti のドキュメントをご覧ください。

このソリューションに関連するチュートリアルの一部として、次のアラートを作成します。

  1. 予期しない Cloud Storage アクセス
  2. IAM ポリシー変更アラート
  3. バケット権限変更アラート
  4. BigQuery 更新アラート
指標 説明
予期しないデータアクセス バケットが予期しないユーザーによってアクセスされると、指定したユーザーまたはグループに通知が送られます。
IAM ポリシーの変更数 IAM ポリシーが変更されると、指定したユーザーまたはグループに通知が送られます。
バケット権限の変更数 バケットまたはオブジェクトの権限が変更されると、指定したユーザーまたはグループに通知が送られます。
BigQuery 更新アラート BigQuery データセットの設定が変更されると、指定したユーザーまたはグループに通知が送られます。

シナリオ

このセクションでは、このアーキテクチャを使用した基本的なシナリオについて説明し、次に、このアーキテクチャを拡張した 2 つ目のシナリオについて説明します。

  • シナリオ 1 では、1 つのホスト プロジェクト、複数のサービス プロジェクト、1 つの共有 VPC を使用します。
  • シナリオ 2 では、1 つの共有サービス VPC と複数の共有 VPC を使用します。

シナリオ 1: 1 つのホスト プロジェクト、複数のサービス プロジェクト、1 つの共有 VPC

上記のアーキテクチャでは、シンプルなカスタムモードの VPC トポロジを実装して、安全性、信頼性、管理性の高いアーキテクチャの基盤を構築しています。共有 VPC を使用すると、各プロジェクトで同じソリューションを複製する必要性が軽減されます。たとえば、Cloud Interconnect ソリューションを共有 VPC に統合すると、リージョンやサービス プロジェクトに関係なく、すべての VM が Cloud Interconnect 接続にアクセスできるようになります。お客様はサブネット、ルート、ファイアウォールなどのネットワーク リソースの一元的な管理手段を維持しながら、VM インスタンスの作成や管理などの管理責任をサービス プロジェクト管理者に委任できます。

このアーキテクチャでは、1 つの共有 VPC を使用した開始方法を示しています。これには次の要素が含まれます。

  • Cloud VPN、Cloud Interconnect、ファイアウォール ルール、Cloud Router などの共有ネットワーク リソース用の 1 つのプロジェクト。
  • 監査ロギングとセキュリティ モニタリングを一元的に行うための 1 つのプロジェクト。
  • データ分析のための複数のサービス プロジェクト。

この構成では、サブネット、ルート、ファイアウォールなどの共有ネットワーク リソースをホスト プロジェクトから集中管理できるため、プロジェクト間で一貫したネットワーク ポリシーを適用できます。一方、サービス プロジェクト部門は、ネットワークと監査保持以外のリソースの構成と管理を行います。これにより、組織内のさまざまなチームの責任を明確に分離できます。プロジェクト内のリソースは、内部 IP アドレスにより、プロジェクト境界を越えて安全かつ効率的にやり取りできます。

シナリオ 2: 1 つの共有サービス VPC、複数の共有 VPC

次の図は、VPC 分離のアーキテクチャを示しています。これは、最初のアーキテクチャをベースにして構築されたものですが、prod VPC を dev/test VPC から分離しています。このアーキテクチャでは、1 つの共有 VPC 内に共通のサービスをまとめて、リソースの重複を回避しています。

prod と dev / test の VPC の分離を示す図

VPC の分離を検討する理由は、アクセス制御、環境間の割り当ての考慮事項など、たくさんあります。また、dev/test 環境では匿名化されたデータのみを使用するのに対して、本番環境では身元を特定できるデータを使用するため、もう 1 つ分離レイヤを追加したほうがよい場合があります。共有サービス VPC では、VPC ピアリングを介してサービスを他の VPC と共有しながら、共通のリソースの管理とデプロイを一元化できます。

VPC ルール以外にも、次のようなツールを使用してデータを安全に保護できます。

  • 機密データを含むワークロードの場合は、VPC Service Controls を使用して、VPC リソースと Google マネージド サービスの周囲にサービス境界を構成し、境界を越えるデータの移動を制御します。VPC Service Control を使用すると、プロジェクトとオンプレミス ネットワークを 1 つの境界にグループ化し、この境界により Google 管理サービスを介したデータアクセスを防止できます。サービス境界に異なる組織のプロジェクトを含めることはできませんが、境界ブリッジを使用すれば、異なるサービス境界内のプロジェクトとサービスの通信が可能となります。
  • Google Cloud Armor と HTTP(S) ロードバランサを統合して、DDoS 防御とネットワーク エッジでの IP アドレスのブロックまたは許可を可能にします。
  • Identity-Aware Proxy(IAP)を使用して、ユーザーの ID とリクエストのコンテキストを確認し、ユーザーにアクセスを許可するかどうか判断します。これにより、アプリへのアクセスを制御します。
  • Security Command Center を使用して、セキュリティ分析、異常検出、脆弱性検出のための単一のインターフェースを提供します。

ベスト プラクティス

このセクションでは、アーキテクチャ自体では明示的に説明されていないものの、実装を検討すべき追加のベスト プラクティスについて説明します。

既存の ID プラットフォームを同期する

組織でオンプレミスまたはサードパーティの ID プラットフォームを使用している場合は、既存のユーザー ディレクトリを Cloud Identity と同期し、ユーザーが会社の認証情報を使用して Google Cloud にアクセスできるようにします。これにより、既存の ID プラットフォームを使用しながら、Cloud Identity で従業員による Google サービスへのアクセスを制御できます。

Active Directory または LDAP サーバーのユーザーとグループを Cloud Identity 提供のユーザー ディレクトリに同期するには、Google Cloud Directory Sync(GCDS)を使用します。GCDS は、組織のユーザーとグループに対応する Google アカウントを提供します。同期は一方向で、ディレクトリ サーバーのデータは変更されません。明示的に構成した場合を除き、パスワードは Google のディレクトリにコピーされません。

シングル サインオン(SSO)を実装する

既存の ID 管理プラットフォームを Cloud Identity と統合すると、シングル サインオン(SSO)を設定できます。SSO を使用すると、いずれかのサービスに一度ログインするだけで、企業のクラウドアプリにアクセスできます。Google Cloud は、既存のオンプレミスまたはサードパーティの ID プロバイダに対して SAML 2.0 ベースの SSO をサポートします。ユーザーは Google Cloud にアクセスする前にメインの ID プロバイダの認証を受ける必要があります。

PHI とロギング

ログ内の PHI をモニタリングし、ログに PHI が含まれないようにします。リソースを作成または更新する際、リソースのメタデータを指定するときに PHI やセキュリティ認証情報を含めないでください。この情報はログに取り込まれることがあります。監査ログには、リソースのデータ コンテンツやログ中のクエリの結果は記録されませんが、リソース メタデータは取り込まれることがあります。

多要素認証を使用する

会社のリソースを保護する上で、多要素認証(MFA)は重要なツールです。セキュリティ キーの使用は、2 段階認証プロセス(2SV)の中で最も安全性の高い手法です。通常は、物理的なキーをパソコンの USB ポートに挿入します。プロンプトが表示されたら、キーをタッチし、暗号の署名を生成します。詳しくは、会社所有のリソースに均一の MFA を適用するをご覧ください。

次のステップ