HIPAA 対応プロジェクトの設定

このチュートリアルでは、Google Cloud Healthcare Data Protection Toolkit の手順について説明します。このツールキットは、Google Cloud リソースをデプロイして、米国の医療保険の相互運用性と説明責任に関する法律(HIPAA: Health Insurance Portability and Accountability Act)で定義されている保護対象保健情報(PHI)を含む医療データを保存、処理するための自動化フレームワークです。このチュートリアルは、HIPAA 対応の Google Cloud Healthcare アーキテクチャについての記事と合わせてお読みいただくように構成されています。

概要

このチュートリアルでは医療機関を対象に、Google Cloud の使用を開始し、データストレージ、分析、アプリケーション開発用に Google Cloud インフラストラクチャを構成する方法について説明します。このセットアップには、適切なアクセスの構成、監査ログの保持、不審なアクティビティのモニタリングなど、医療データのセキュリティおよびプライバシーに関する多数のおすすめの方法が含まれています。これらのベスト プラクティスの詳細については、Google Cloud HIPAA ホワイトペーパーをご覧ください。

このチュートリアルでは、PHI の保存と処理が可能な各種の Google Cloud サービスについて説明しますが、すべての Google Cloud リソースタイプとユースケースが網羅されているわけではありません。網羅的に扱うのではなく、このチュートリアルでは、主にリソースタイプのサブセットを取り上げて説明します。 Google の業務提携契約(BAA)に基づく HIPAA コンプライアンスをサポートする Google Cloud サービスのリストについては、Google Cloud 上の HIPAA コンプライアンスをご覧ください。また、セキュリティプライバシーコンプライアンスに関する Google Cloud のドキュメントを確認することもできます。

免責

  • このチュートリアルはリファレンス アーキテクチャを説明するものであり、HIPAA またはその他のデータ プライバシーに関連する法律を準拠するために実施する必要がある、適切な、管理上、技術上および物理的な安全保護対策に基づく法的アドバイスを提供するものではありません。
  • このチュートリアルが扱う範囲は、対象範囲内のリソースによって保存されるデータの保護とモニタリングに限定されます。 このチュートリアルの実施によって、他の Google Cloud ストレージ サービスで保存または処理される派生データアセットを自動的にカバーするものではありません。派生データアセットについては、同様の保護措置を別途講じる必要があります。
  • このチュートリアル内の実装は、公式の Google プロダクトではありません。リファレンス用としての実装を目的として作成されています。コードは、Apache License、Version 2.0 で利用可能なオープンソース プロジェクトである Google Cloud Healthcare Data Protection Toolkit に含まれています。このフレームワークを開始点として使用し、ユースケースに応じて構成できます。 ユーザーは、Google Cloud 上に構築する環境とアプリケーションが、HIPAA の要件に従って正しく構成され、保護されていることを確認する責任があります。
  • このチュートリアルでは GitHub のコードのスナップショットを紹介しています。このスナップショットは時間の経過とともに更新または変更される可能性があります。リファレンス実装には、このチュートリアルで扱うもの以外にも多くのリソースタイプ(Cloud SQL インスタンスや Kubernetes クラスタなど)が含まれている場合があります。最新の適用範囲については、README ファイルをご覧ください。

目標

このチュートリアルの目的は、HIPAA 対応の Google Cloud プロジェクトを設定する Infrastructure as Code(IaC)の実装についてのリファレンスを提供することです。この実装により、次のプロセスが自動化されます。

料金

Google Cloud では、期間限定の無料トライアルと無期限の Always Free 無料枠をお客様に提供しています。これらは、このチュートリアルで使用するいくつかのサービスに適用されます。詳細については、Google Cloud の無料枠ページをご覧ください。

この実装の実行中に蓄積されるデータ量またはログ数によっては、無料トライアルまたは無料枠の制限を超えることなく、実装を完了できる場合があります。料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを出すことができます。

このチュートリアルを終了した後に作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。

始める前に

  1. オンボーディングのベスト プラクティス ガイドを確認します。
  2. Google Cloud での HIPAA コンプライアンスを確認します。
  3. PHI に関連して Google Cloud サービスを使用している場合は、Google Cloud で BAA を実行します。
  4. Google Cloud の基本設定が完了していることを確認します。

環境を初期化する

  1. シェルで、Google Cloud Healthcare Data Protection Toolkit をダウンロードします。注: Cloud Shell でヘルパー スクリプトを実行する場合は、ここで停止して次の手順をスキップできます。

  2. ツールと依存関係サービスをインストールします。

    • Bazel - オープンソースのビルドとテストツール
    • Terraform - Cloud プロビジョニング ツール
    • Cloud SDK - Google Cloud でホストされているリソースとアプリケーションを管理するためのツールセット
    • Git - 分散バージョン管理システム
  3. 認証を設定します。

    gcloud auth login
    

デプロイ準備のチェックリスト

手順の開始前に、次の情報を書き留めておく必要があります。

Google Cloud は、サポートされている G Suite ドメインまたは Cloud Identity ドメインの Google アカウントとグループ、あるいは一般公開の Google グループを使用して権限を制御します。Google Cloud では、事前定義されたロールのグループを作成することをおすすめします。これにより、プロジェクトを変更することなく、グループ メンバーシップによって個々の権限を簡単に制御できます。

コンセプト ドキュメントに記載されているユーザー グループを作成するか、その存在を確認します。組織が G Suite のお客様である場合や、既存の Google Cloud 組織用のリソースのプロビジョニングにスクリプトの使用を予定している場合は、ユーザー グループについて管理者にお問い合わせください。管理者は Google 管理コンソールを使用してこの設定を行います。誰が管理者であるかを調べるには、Cloud Identity のヘルプを使用します。組織ユーザーは、Google Cloud Identity で設定されています。デフォルトでは、設定プロセスで admin として指定されたメール アカウントは組織管理者に割り当てられます。このユーザーは、他の IAM ロールの作成と割り当てができます。データ転送、分析、セキュリティ監査に必要なさまざまなリソースへのアクセスは、IAM グループと関連付けられる役割によって制御されます。

さらに、デプロイ スクリプトを実行するユーザーは、セキュリティ プロジェクトをはじめとして、作成されるすべてのプロジェクトのオーナー グループに属している必要があります。デプロイが正常完了した後に、これらのグループからそのユーザーを削除できます。上の手順で作成した OWNERS_GROUP のメンバーとして現在使用しているユーザーを追加します。G Suite の管理コンソールにログインします。

また、商用アカウント以外でのテストを計画している場合は、Google グループを使用できます。

各 Google グループを作成します。その際に基本的なアクセス許可については次に示すセキュアな設定を使用します。

  • グループタイプ: メーリング リスト
  • トピックの表示: グループのすべてのメンバー(およびマネージャー)
  • 投稿: マネージャーとオーナーのみ
  • グループへの参加: 招待されたユーザーのみ

環境情報の収集とプロジェクト リソースの命名

構成ファイルは YAML 形式です。作成する各リソースとそのそれぞれのプロパティをリストします。多数のサンプル構成ファイルから選択できます。このファイルのリストは随時拡張されます。 リモート監査ログ構成ファイルの使用をおすすめします。

overall セクションには、すべてのプロジェクトに適用される organizationbilling の詳細が含まれています。

  • audit_logs_project セクションで、監査ログをホストするプロジェクトを定義します。
  • forseti セクションで、Forseti リソースをホストするプロジェクトを定義します。
  • 必要なすべてのデータ ホスティング プロジェクトを projects の下にリストします。

Google Cloud 環境の以下の情報を収集し、ファイルを更新します。

パラメータ 値のサンプル
organization_id 12345678
billing_account 000000-000000-000000
location US、EU、Asia(BigQuery および Cloud Storage の場合)

デフォルト設定は、US、EU、Asia の境界内のマルチリージョンのデータ ストレージです。
TTL days audit セクションのこのフィールドは、監査ログの保持期間を決定します(現在はストレージ バケットのみ)。

たとえば、365 などの値です。
project_id 3 つのプロジェクトに一意の名前を付けます。

  1. audit_logs_project
  2. Forseti
  3. データセット プロジェクト (projects.project_id)
stackdriver_alert_email [your admin email id]
owners_group hipaa-sample-project-owner@google.com
auditors_group hipaa-sample-project-auditor@google.com

このツールキットを使用すると、一貫した命名規則やリソースのラベル付けなどのおすすめの方法に準拠できます。プロジェクト名、Cloud Storage バケットと BigQuery データセット名、VPC 名を決定します。命名で推奨される方法については、次のドキュメントをご覧ください。

次を使用して必要な情報を収集します。これらの情報は、デプロイ構成ファイルに追加できます。 命名規則の制定にあたっては、次に示す例を参考にしてください。

  • 会社名: Altostrat Company: altoco
  • ビジネス ユニット: 人事部: hr
  • アプリケーション コード: 給与システム: comp
  • リージョン コード: northamerica-northeast1: na-ne1、europe-west1: eu-we1
  • 環境コード: dev、test、uat、stage、prod
パラメータ 命名規則のサンプル
project_id プロジェクトの命名規則を決定します。

例:
{org-name}-{app/bu/purpose}-{environment}

altoco-edw-prod

audit_logs_project セクションで、監査ログをホストするプロジェクトを定義します。

forseti セクションで、Forseti リソースをホストするプロジェクトを定義します。

必要なすべてのデータ ホスティング プロジェクトを projects の下にリストします。
{storage_name} バケット名 例: {org-name hash}-{source}-{type}-{bu/region}-{seq#}

08uy6-cerner-inpatient-east-1

セキュリティ強化のため、組織名のハッシュを使用します。
BigQuery データセット名 例: {org-name}_{bu/region}_{app/module}

altoco_east_edw
VPC 名 例:
{org-name}-{bu/region}-{environment}-{seq#}

altoco-east-prod-vpc-1

スクリプトを理解する

Google Cloud Healthcare Data Protection Toolkit では、大まかには、Cloud Foundation Toolkitとカスタム ロジックを適宜使用して、リソースのプロビジョニング、ベスト プラクティスに従った IAM とロギングの設定、Forseti のモニタリングの有効化が行われます。

ヘルパー スクリプト

メインのヘルパー スクリプト apply.go は、構成ファイルから YAML 構成を読み取り、構成ファイルにリストされているプロジェクトを作成または変更します。このスクリプトによって、監査ログ プロジェクトと Forseti プロジェクトが作成されます。次に、このスクリプトは、projects にリストされている各プロジェクトにデータ ホスティング プロジェクトを作成します。このスクリプトでは、以下が実行されます。

  • プロジェクトの作成(プロジェクトがまだ存在しない場合)。
  • プロジェクトでの課金の有効化。
  • Terraform の状態を保存するためのバケットの作成(プロジェクト内でローカルに、または中央の DevOps プロジェクトにリモートで)。
  • ワークスペースを作成または選択するよう求めるメッセージの表示。この操作は、Cloud Monitoring を使用して行う必要があります。詳細については、Monitoring ガイドをご覧ください。
  • セキュリティ ルールのモニタリングに使用されるモニタリング アラートの作成。
  • サービス、モニタリング対象リソース、データ保持リソースなど、プロジェクト内にローカル保存されているリソースのデプロイ。
  • 監査ログデータ リソースとシンクの作成(プロジェクト内でローカルに、または中央監査プロジェクト内にリモートで)。
  • Forseti モニタリング リソースの作成。

ヘルパー スクリプト rule_generator.go は、YAML 構成ファイルから構成を読み取り、Forseti ルールを生成して、ローカル ディレクトリまたは Cloud Storage バケットに書き込みます。

注: 現時点では、ルールの生成は、古いマネージャー ベースの構成でのみ機能します。

スクリプトを実行する

Data Protection Toolkit では、構成ファイルを使用して単一のデプロイメントに必要なすべてのリソースを記述します。構成ファイルは YAML 形式です。作成する各リソースとそのそれぞれのプロパティをリストします。

  1. ルートフォルダにサンプルの構成ファイルをコピーします。

  2. ./healthcare/deploy フォルダ内にいることを確認します。

    cp ./samples/simple/config.yaml .
    nano config.yaml
    
  3. 構成ファイルの適切な場所で以前に収集したパラメータを更新します。

メインヘルパー スクリプト apply.go のパラメータは、次のように定義されます。

--config_path
デプロイ構成への相対パスまたは絶対パス。
--projects
デプロイ構成のプロジェクト ID のカンマ区切りのリスト。 このパラメータをスキップして、デプロイ構成にリストされているすべてのプロジェクトを指定することもできます。 このスクリプトは、新しいプロジェクトを作成し、既存のプロジェクトを更新します。
--dry_run
ドライランの指定に使用。--dry_run を省略した場合は、標準実行が指定されます。

ヘルパー スクリプト rule_generator.go のパラメータは、次のように定義されます。

--config_path
デプロイ構成への相対パスまたは絶対パス。
--output_path
ルール生成スクリプトがルールファイルを出力する先のパス。ローカル ディレクトリまたは Cloud Storage バケットを設定できます。設定がない場合は、Forseti サーバー バケットに直接書き込まれます。

ドライラン モード

ドライランを実行すると、指定されたデプロイ構成でそのスクリプトによって実行される内容がすべて確認できますが、実際には実行されません。デプロイが実際に実行されたときに期待どおりに実行されるかどうかを確認できます。

bazel run cmd/apply:apply -- \
    --config_path=[CONFIG_FILE] \
    --projects=[PROJECTS] \
    --dry_run

プロジェクト作成モード

ドライラン実行でコマンドを確認しデプロイを実行する準備ができたら、--dry_run パラメータを指定しないでスクリプトを実行します。

bazel run cmd/apply:apply -- \
    --config_path=[CONFIG_FILE] \
    --projects=[PROJECTS]

更新モード

既存のプロジェクトにリソースを追加する場合、または既存の設定を変更する場合は、--projects フラグで以前にデプロイされたプロジェクトを指定します。

bazel run cmd/apply:apply -- \
    --config_path=[CONFIG_FILE] \
    --projects=[PROJECTS]

ルール生成

メイン スクリプトを使用して Forseti プロジェクトをデプロイ済みの場合、ルール生成スクリプトを実行してルールを生成およびアップロードできます。デフォルトでは、ルールは Forseti サーバー バケットにアップロードされます。独自の Forseti ルールセットを作成する場合は、この手順をスキップします。

bazel run cmd/rule_generator:rule_generator -- \
    --config_path=[CONFIG_FILE]

結果の確認

ヘルパー スクリプトを使用すれば、多数のコマンドをカプセル化できます。このセクションでは、スクリプトを正常に実行した後の Cloud Console の動作について説明します。

Cloud Console

次のように、Cloud Console でプロジェクトを利用できます。

Cloud Console に表示されるプロジェクト

IAM

Cloud Console には、プロジェクトごとのプロジェクト オーナーとして OWNERS_GROUP が、プロジェクトのセキュリティ審査担当者として AUDITORS_GROUP が表示されます。

コンソールのプロジェクトに対する権限

上の図では、OWNERS_GROUPAUDITORS_GROUP のメンバーだけが表示されていました。しかし、多くの場合、プロジェクトで有効にしている API に基づいて、プロジェクト レベルのアクセス権があるサービス アカウントもいくつか表示されます。最も一般的なサービス アカウントは次のとおりです。

ストレージ ブラウザ

ストレージ ブラウザには、ログを保存するために新しく作成されたバケットが表示されます。バケット名、ストレージ クラス、およびロケーションはすべて、デプロイ構成に従います。この例は、ローカルログ配置を示しています。 リモートログ配置では、バケットとデータは異なるプロジェクトに存在し、すべてのデータ プロジェクトのログがローカルログ モードにありながらも統合されます。各プロジェクトには独自のログバケットが存在します。

ローカルログ モードですべてのデータ プロジェクトのログを統合する

ライフサイクル

ログバケットではライフサイクルが有効になっています。ライフサイクル ポリシーを表示して、オブジェクトのデプロイ構成の ttl_days で指定されている値より古いオブジェクトに削除アクションが指定されていることを確認します。

ライフサイクル ポリシーの表示

  • cloud-storage-analytics@google.com の権限とは別に、残りの権限は指定どおりに設定されます。cloud-storage-analytics@google.com がバケットへの書き込みアクセスを必要とする理由については、ログのドキュメントをご覧ください。

    書き込み権限を持つグループ

  • ストレージ ブラウザには、データを保存するために新しく作成されたバケットが表示されます。バケットの名前デフォルトのストレージ クラスロケーションはデプロイ構成の仕様と一致します。

    新しく作成されたバケット

  • 各データバケット内のオブジェクトはバージョン管理されます。 次のコマンドを実行して、確認します。ここで、bucket_name はバケットの名前に置き換えてください。

    gsutil versioning get gs://bucket_name
    
  • データバケットのアクセスログおよびストレージログがキャプチャされてログバケットに保存されていること、およびデータバケットが作成されたときにロギングが開始されたことを確認します。次のコマンドを実行して確認します。

    gsutil logging get gs://bucket_name
    
  • 各バケットの権限は、仕様に従って設定されます。

    バケットへの書き込み権限を持つグループ

Google Cloud Console

Cloud Console で、すべてのサービスのデータ アクセスログがオンになっています。

管理コンソールのデータ アクセスログ

Cloud Console

Cloud Console で、BigQuery API が有効になっていることを確認します。

Cloud Console で有効化された BigQuery API

BigQuery

Cloud Consoleで、Cloud Logging が Cloud 監査ログをシンクするデータセットが表示されていることを確認します。また、[説明]、[データセット ID]、[データのロケーション] の値が、以前に表示されたデプロイ構成とロギング エクスポート シンクの指定と一致していることも確認してください。

Cloud 監査ログのシンク先であるデータセットを BigQuery で表示する

データセットへのアクセスがユーザーの指定どおりに設定されていることを確認します。

また、Cloud Logging のログを BigQuery にストリーミングするサービス アカウントに、データセットに対する編集権限が付与されていることを確認します。

BigQuery データ権限

データを格納するために新しく作成されたデータセットが表示されていること、および [説明]、[データセット ID]、[データのロケーション] の各値ならびに各データセットのラベルがデプロイ構成の指定と一致していることを確認します。

新しく作成されたデータセットを示す BigQuery

データセットへのアクセスが指定どおりに設定されていることを確認します。 プロジェクトで有効にしている API によっては、継承による権限を持つ他のサービス アカウントが表示されることがあります。

データを保存するための BigQuery のデータ権限

Pub/Sub

Pub/Sub に新しく作成されたトピックが表示され、トピック名、サブスクリプションのリスト、各サブスクリプションの詳細([配信タイプ] や [確認応答期限] など)がデプロイ構成の指定と一致していることを確認します。

トピックに対するアクセス権がデプロイ構成と一致していることも確認します。たとえば、次のスクリーンショットは、トピックのオーナーシップを継承している OWNERS_GROUP や、トピックの編集者の役割を持つ READ_WRITE_GROUP を示しています。プロジェクトで有効にしている API によっては、継承による権限を持つ他のサービス アカウントが表示される可能性があります。

新しく作成されたトピックを示す Pub/Sub

Cloud Logging

Cloud Console で、新しいエクスポート シンクが表示されていることを確認します。[出力先] と [書き込み ID] の値を書き留めて、次の手順で BigQuery に表示されるものと比較します。

新しいエクスポート シンクを示す Cloud Logging

ログベースの指標が監査ログ内の不審なアクティビティのインシデントをカウントするように設定されていることを確認します。

不審なアクティビティのインシデントをカウントするように設定されたログベースの指標を示す Cloud Logging

Cloud Monitoring アラート

Cloud Monitoring に、対応するログベースの指標のアラート ポリシーが含まれていることを確認します。

  1. Google Cloud Console で [Monitoring] に移動します。

    Cloud Monitoring

  2. [Alerting] メニューで、[Policies overview] を選択します。

対応するログベースの指標に基づいてトリガーされるアラート ポリシーを示す Monitoring

クエリログ

BigQuery にストリーミングされた監査ログに対して次の SQL クエリを使用すると、不審なアクティビティの種類ごとにログ履歴を時系列順に整理できます。 BigQuery エディタで、あるいは BigQuery コマンドライン インターフェースを介して、このクエリを開始点として使用し、要件を満たすように作成したクエリを定義します。

```sql
SELECT timestamp,
       resource.labels.project_id                              AS project,
       protopayload_auditlog.authenticationinfo.principalemail AS offender,
       'IAM Policy Tampering'                                  AS offenseType
FROM   `hipaa-sample-project.cloudlogs.cloudaudit_googleapis_com_activity_*`
WHERE  resource.type = "project"
       AND protopayload_auditlog.servicename =
           "cloudresourcemanager.googleapis.com"
       AND protopayload_auditlog.methodname = "setiampolicy"
UNION DISTINCT
SELECT timestamp,
       resource.labels.project_id                              AS project,
       protopayload_auditlog.authenticationinfo.principalemail AS offender,
       'Bucket Permission Tampering'                           AS offenseType
FROM   `hipaa-sample-project.cloudlogs.cloudaudit_googleapis_com_activity_*`
WHERE  resource.type = "gcs_bucket"
       AND protopayload_auditlog.servicename = "storage.googleapis.com"
       AND ( protopayload_auditlog.methodname = "storage.setiampermissions"
              OR protopayload_auditlog.methodname = "storage.objects.update" )
UNION DISTINCT
SELECT timestamp,
       resource.labels.project_id                              AS project,
       protopayload_auditlog.authenticationinfo.principalemail AS offender,
       'Unexpected Bucket Access'                              AS offenseType
FROM   `hipaa-sample-project.cloudlogs.cloudaudit_googleapis_com_data_access_*`
WHERE  resource.type = 'gcs_bucket'
       AND ( protopayload_auditlog.resourcename LIKE
             '%hipaa-sample-project-logs'
              OR protopayload_auditlog.resourcename LIKE
                 '%hipaa-sample-project-bio-medical-data' )
       AND protopayload_auditlog.authenticationinfo.principalemail NOT IN(
           'user1@google.com', 'user2@google.com' )
```

次の画像は、BigQuery コマンドライン インターフェースを使用してクエリを実行したときの結果の例を示しています。

BigQuery コマンドライン インターフェースを使用してクエリを実行した際のサンプル結果

クリーンアップ

  1. Cloud Console で [リソースの管理] ページに移動します。

    [リソースの管理] ページに移動

  2. プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
  3. ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

次のステップ