翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# AWS HealthOmics のセキュリティ
のクラウドセキュリティが最優先事項 AWS です。お客様は AWS 、セキュリティを最も重視する組織の要件を満たすように構築されたデータセンターとネットワークアーキテクチャからメリットを得られます。
セキュリティは、 AWS とお客様の間の責任共有です。[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)ではこれをクラウド*の*セキュリティおよびクラウド*内*のセキュリティと説明しています。
+ **クラウドのセキュリティ** – AWS は、 で AWS サービスを実行するインフラストラクチャを保護する責任を担います AWS クラウド。 は、お客様が安全に使用できるサービス AWS も提供します。サードパーティーの監査者は、[AWS コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)コンプライアンスプログラムの一環として、当社のセキュリティの有効性を定期的にテストおよび検証。AWS HealthOmics に適用されるコンプライアンスプログラムの詳細については、「コンプライアンスプログラム[AWS による対象範囲内のサービスコンプライアンスプログラム](https://aws.amazon.com/compliance/services-in-scope/)」を参照してください。
+ **クラウド内のセキュリティ** – お客様の責任は、使用する AWS サービスによって決まります。また、ユーザーは、データの機密性、会社の要件、適用される法律や規制など、その他の要因についても責任を負います。
このドキュメントは、AWS HealthOmics を使用する際の責任共有モデルの適用方法を理解するのに役立ちます。以下のトピックでは、セキュリティおよびコンプライアンスの目的を達成するように AWS HealthOmics を設定する方法について説明します。また、AWS HealthOmics リソースのモニタリングや保護に役立つ他の AWS サービスの使用方法についても説明します。
**Topics**
+ [でのデータ保護 AWS HealthOmics](data-protection.md)
+ [HealthOmics での ID とアクセスの管理](security-iam.md)
+ [のコンプライアンス検証 AWS HealthOmics](compliance-validation.md)
+ [HealthOmics の耐障害性](disaster-recovery-resiliency.md)
+ [AWS HealthOmics およびインターフェイス VPC エンドポイント (AWS PrivateLink)](vpc-interface-endpoints.md)
# でのデータ保護 AWS HealthOmics
責任 AWS [共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)、AWS HealthOmics でのデータ保護に適用されます。このモデルで説明されているように、 AWS はすべての を実行するグローバルインフラストラクチャを保護する責任があります AWS クラウド。ユーザーは、このインフラストラクチャでホストされるコンテンツに対する管理を維持する責任があります。また、使用する「 AWS のサービス 」のセキュリティ設定と管理タスクもユーザーの責任となります。データプライバシーの詳細については、[データプライバシーに関するよくある質問](https://aws.amazon.com/compliance/data-privacy-faq/)を参照してください。欧州でのデータ保護の詳細については、*AWS セキュリティブログ*に投稿された「[AWS 責任共有モデルおよび GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/)」のブログ記事を参照してください。
データ保護の目的で、認証情報を保護し AWS アカウント 、 AWS IAM アイデンティティセンター または AWS Identity and Access Management (IAM) を使用して個々のユーザーを設定することをお勧めします。この方法により、それぞれのジョブを遂行するために必要な権限のみが各ユーザーに付与されます。また、次の方法でデータを保護することもお勧めします:
+ 各アカウントで多要素認証 (MFA) を使用します。
+ SSL/TLS を使用して AWS リソースと通信します。TLS 1.2 は必須ですが、TLS 1.3 を推奨します。
+ で API とユーザーアクティビティのログ記録を設定します AWS CloudTrail。CloudTrail 証跡を使用して AWS アクティビティをキャプチャする方法については、「 *AWS CloudTrail ユーザーガイド*」の[CloudTrail 証跡の使用](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html)」を参照してください。
+ AWS 暗号化ソリューションと、その中のすべてのデフォルトのセキュリティコントロールを使用します AWS のサービス。
+ Amazon Macie などの高度な管理されたセキュリティサービスを使用します。これらは、Amazon S3 に保存されている機密データの検出と保護を支援します。
+ コマンドラインインターフェイスまたは API AWS を介して にアクセスするときに FIPS 140-3 検証済み暗号化モジュールが必要な場合は、FIPS エンドポイントを使用します。利用可能な FIPS エンドポイントの詳細については、「[連邦情報処理規格 (FIPS) 140-3](https://aws.amazon.com/compliance/fips/)」を参照してください。
お客様の E メールアドレスなどの極秘または機密情報を、タグ、または **[名前]** フィールドなどの自由形式のテキストフィールドに含めないことを強くお勧めします。これは、コンソール、API、または SDK を使用して AWS HealthOmics AWS CLIまたは他の AWS のサービス を使用する場合も同様です。 AWS SDKs タグ、または名前に使用される自由記述のテキストフィールドに入力したデータは、請求または診断ログに使用される場合があります。外部サーバーに URL を提供する場合、そのサーバーへのリクエストを検証できるように、認証情報を URL に含めないことを強くお勧めします。
## 保管中の暗号化
**Topics**
+ [AWS 所有のキー](#AWS-owned-cmk)
+ [カスタマーマネージドキー](#customer-owned-cmk)
+ [カスタマーマネージドキーの作成](#creating-co-cmk)
+ [カスタマーマネージドキーを使用するために必要な IAM アクセス許可](#required-iam-cmk)
+ [詳細情報](#more-info-kms)
保管中の機密データを保護するために、 はサービス所有の AWS Key Management Service (AWS KMS) キーを使用してデフォルトで暗号化 AWS HealthOmics を提供します。カスタマーマネージドキーもサポートされています。カスタマーマネージドキーの詳細については、[「Amazon Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)」を参照してください。
すべての HealthOmics データストア (ストレージと分析) は、カスタマーマネージドキーの使用をサポートしています。データストアの作成後に暗号化設定を変更することはできません。データストアが を使用している場合 AWS 所有のキー、AWS\$1OWNED\$1KMS\$1KEY と表示され、保管時の暗号化に使用される特定のキーは表示されません。
HealthOmics ワークフローの場合、カスタマーマネージドキーは一時ファイルシステムではサポートされていません。ただし、すべてのデータは保管時に XTS-AES-256 ブロック暗号暗号化アルゴリズムを使用して自動的に暗号化され、ファイルシステムが暗号化されます。ワークフロー実行を開始するために使用される IAM ユーザーとロールは、ワークフロー入出力バケットに使用される AWS KMS キーにもアクセスできる必要があります。ワークフローでは許可は使用されず、 AWS KMS 暗号化は Amazon S3 バケットの入力と出力に制限されます。ワークフロー APIs の両方に使用される IAM ロールには、使用される AWS KMS キーと、入出力 Amazon S3 バケットへのアクセス権も必要です。IAM ロールとアクセス許可を使用して、アクセスまたは AWS KMS ポリシーを制御できます。詳細については、「 の[認証とアクセスコントロール AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/control-access.html)」を参照してください。
HealthOmics Analytics AWS Lake Formation で を使用すると、Lake Formation に関連付けられた復号アクセス許可も入力および出力 Amazon S3 バケットに付与されます。がアクセス許可 AWS Lake Formation を管理する方法の詳細については、 [AWS Lake Formation ドキュメント](https://docs.aws.amazon.com/lake-formation/latest/dg/register-encrypted.html)を参照してください。
HealthOmics Analytics は、Amazon S3 バケット内の暗号化されたデータを読み取るアクセス許可を Lake Formation kms:Decrypt に付与します。 Amazon S3 Lake Formation を通じてデータをクエリするアクセス許可がある限り、暗号化されたデータを読み取ることができます。データへのアクセスは、KMS キーポリシーではなく、Lake Formation のデータアクセスコントロールによって制御されます。詳細については、Lake Formation ドキュメントの[AWS 「Integrated AWS service requests](https://docs.aws.amazon.com/lake-formation/latest/dg/access-control-underlying-data.html)」を参照してください。
### AWS 所有のキー
デフォルトでは、HealthOmics は AWS 所有のキー を使用して保管中のデータを自動的に暗号化します。このデータには、個人を特定できる情報 (PII) や保護対象医療情報 (PHI) などの機密情報が含まれる可能性があるためです。 AWS 所有のキー aren はアカウントに保存されません。これらは、複数の AWS アカウントで使用するために AWS が所有および管理する KMS キーのコレクションの一部です。
AWS のサービスでは、 AWS 所有のキー を使用してデータを保護できます。を表示、管理、アクセスしたり AWS 所有のキー、その使用を監査したりすることはできません。ただし、データを暗号化するキーを保護するための作業やプログラムを操作したり変更したりする必要はありません。
の使用には月額料金や使用料金はかかりません。また AWS 所有のキー、アカウントの AWS KMS クォータにはカウントされません。詳細については、「[AWS マネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#AWS-owned-cmk)」を参照してください。
### カスタマーマネージドキー
HealthOmics は、作成、所有、管理する対称カスタマーマネージドキーを使用して、既存の AWS 所有の暗号化に 2 番目の暗号化レイヤーを追加します。この暗号化レイヤーはユーザーが完全に制御できるため、次のようなタスクを実行できます。
+ キーポリシー、IAM ポリシー、許可の確立と維持
+ キー暗号化マテリアルのローテーション
+ キーポリシーの有効化と無効化
+ タグを追加する
+ キーエイリアスの作成
+ 削除のためのキースケジューリング
CloudTrail を使用して、HealthOmics が AWS KMS ユーザーに代わって に送信するリクエストを追跡することもできます。別途 AWS KMS 料金がかかります。詳細については、[「カスタマーマネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk)」を参照してください。
### カスタマーマネージドキーの作成
AWS マネジメントコンソールまたは AWS KMS APIs を使用して、対称カスタマーマネージドキーを作成できます。
AWS Key Management Service デベロッパーガイドの[「対称カスタマーマネージドキーの作成](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk)」の手順に従います。
キーポリシーは、カスタマーマネージドキーへのアクセスを制御します。すべてのカスタマーマネージドキーには、キーポリシーが 1 つだけ必要です。このポリシーには、そのキーを使用できるユーザーとその使用方法を決定するステートメントが含まれています。カスタマーマネージドキーを作成するときに、キーポリシーを指定できます。詳細については、AWS Key Management Service デベロッパーガイドの[「カスタマーマネージドキーへのアクセスの管理](https://docs.aws.amazon.com/kms/latest/developerguide/control-access-overview.html#managing-access)」を参照してください。
HealthOmics Analytics リソースでカスタマーマネージドキーを使用するには、呼び出し元のプリンシパルがキーポリシーで [kms:CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html) オペレーションを必要とします。これにより、システムは FAS トークンを使用して、指定された KMS キーへのアクセスを制御するカスタマーマネージドキーへの許可を作成できます。このキーは、HealthOmics が必要とする [kms:grant](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations ) オペレーションへのアクセス権をユーザーに付与します。 HealthOmics 詳細については、[「許可の使用](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)」を参照してください。
HealthOmics 分析では、呼び出し元のプリンシパルに次の API オペレーションを許可する必要があります。
+ kms:CreateGrant は、特定のカスタマーマネージドキーに権限を追加し、HealthOmics Analytics の権限オペレーションへのアクセスを許可します。
+ kms:DescribeKey は、キーの検証に必要なカスタマーマネージドキーの詳細を提供します。これはすべてのオペレーションに必要です。
+ kms:GenerateDataKey は、すべての書き込みオペレーションで保管中のリソースを暗号化するためのアクセスを提供します。また、このアクションは、呼び出し元がキーを使用するためのアクセス権を持っていることをサービスが検証するために使用できるカスタマーマネージドキーの詳細を提供します。
+ kms:Decrypt は、暗号化されたリソースの読み取りまたは検索オペレーションへのアクセスを提供します。
HealthOmics ストレージリソースでカスタマーマネージドキーを使用するには、HealthOmics サービスプリンシパルと呼び出し元プリンシパルをキーポリシーで許可する必要があります。これにより、呼び出し元がキーにアクセスできることをサービスで検証し、サービスプリンシパルを使用してカスタマーマネージドキーを使用してストア管理を実行できます。HealthOmics ストレージの場合、サービスプリンシパルのキーポリシーは、次の API オペレーションを許可する必要があります。
+ kms:DescribeKey は、キーの検証に必要なカスタマーマネージドキーの詳細を提供します。これはすべてのオペレーションに必要です。
+ kms:GenerateDataKey は、すべての書き込みオペレーションで保管中のリソースを暗号化するためのアクセスを提供します。また、このアクションは、呼び出し元がキーを使用するためのアクセス権を持っていることをサービスが検証するために使用できるカスタマーマネージドキーの詳細を提供します。
+ kms:Decrypt は、暗号化されたリソースの読み取りまたは検索オペレーションへのアクセスを提供します。
次の例は、サービスプリンシパルがカスタマーマネージドキーを使用して暗号化された HealthOmics シーケンスまたはリファレンスストアを作成して操作できるようにするポリシーステートメントを示しています。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "omics.amazonaws.com"
},
"Action": [
"kms:Decrypt",
"kms:DescribeKey",
"kms:Encrypt",
"kms:GenerateDataKey*"
],
"Resource": "*"
}
]
}
```
------
次の例は、Amazon S3 バケットからデータを復号するためのデータストアのアクセス許可を作成するポリシーを示しています。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"omics:GetReference",
"omics:GetReferenceMetadata"
],
"Resource": [
"arn:aws:omics:us-east-1:123456789012:referenceStore/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::[[s3path]]/*"
]
},
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:us-east-1:123456789012:key/key_id"
],
"Condition": {
"StringEquals": {
"kms:ViaService": [
"s3.us-east-1.amazonaws.com"
]
}
}
}
]
}
```
------
### カスタマーマネージドキーを使用するために必要な IAM アクセス許可
カスタマーマネージドキーを使用して AWS KMS 暗号化されたデータストアなどのリソースを作成する場合、IAM ユーザーまたはロールのキーポリシーと IAM ポリシーの両方に必要なアクセス許可があります。
[kms:ViaService 条件キー](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service)を使用して、KMS キーの使用を HealthOmics からのリクエストのみに制限できます。
キーポリシーの詳細については、AWS Key Management Service デベロッパーガイド[の「IAM ポリシーの有効化](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html#key-policy-default-allow-root-enable-iam)」を参照してください。
**Topics**
+ [Analytics API のアクセス許可](#analytics-permissions)
+ [Storage API のアクセス許可](#storage-permissions)
+ [HealthOmics が AWS KMS で許可を使用する方法](#grants-kms)
+ [AWS HealthOmics の暗号化キーのモニタリング](#monitoring-kms)
#### Analytics API のアクセス許可
HealthOmics 分析の場合、ストアを作成する IAM ユーザーまたはロールには、kms:CreateGrant、kms:GenerateDataKey、kms:Decrypt、および kms:DescribeKey アクセス許可と、必要な HealthOmics アクセス許可が必要です。
#### Storage API のアクセス許可
HealthOmics ストレージ APIs、次の API オペレーションを呼び出す IAM ユーザーまたはロールには、リストされたアクセス許可が必要です。
**CreateReferenceStore、CreateSequenceStore**
ストアを作成するには、IAM 発信者がアクセス`kms:DescribeKey`許可と必要な HealthOmics アクセス許可を持っている必要があります。HealthOmics サービスプリンシパルは を呼び出し`kms:GenerateDataKeyWithoutPlaintext`て、データのロードとアクセスのアクセス検証チェックを実行します。
**StartReadSetImportJob、StartReferenceImportJob**
データインポートジョブを開始するには、IAM 呼び出し元がインポートするストアの KMS キーに対する `kms:Decrypt`および `kms:GenerateDataKey` アクセス許可と、インポートするオブジェクトを含む Amazon S3 バケットに対する `kms:Decrypt` アクセス許可を持っている必要があります。さらに、呼び出しに渡されるロールには、インポートするオブジェクトを含む Amazon S3 バケットに対する`kms:Decrypt`アクセス許可が必要です。IAM 呼び出し元には、ロールをジョブに渡すアクセス許可も必要です。
**CreateMultipartReadSetUpload、UploadReadSetPart、CompleteMultipartReadSetUpload**
マルチパートアップロードを完了するには、IAM 発信者がマルチパートアップロードを作成、アップロード、完了`kms:Decrypt``kms:GenerateDataKey`するための と が必要です。
**StartReadSetExportJob**
データエクスポートジョブを開始するには、IAM 呼び出し元に、ストアの KMS キーが からエクスポートされる`kms:Decrypt`アクセス許可`kms:GenerateDataKey`と、オブジェクトを受信する Amazon S3 バケットに対する`kms:Decrypt`アクセス許可が必要です。さらに、呼び出しに渡されるロールには、オブジェクトを受信する Amazon S3 バケットに対する`kms:Decrypt`アクセス許可が必要です。IAM 呼び出し元には、ロールをジョブに渡すアクセス許可も必要です。
**StartReadsetActivationJob**
読み取りセットのアクティベーションジョブを開始するには、IAM 呼び出し元にオブジェクトに対する `kms:Decrypt`および アクセス`kms:GenerateDataKey`許可が必要です。
**GetReference、GetReadSet**
ストアからオブジェクトを読み取るには、IAM 呼び出し元にオブジェクトに対する`kms:Decrypt`アクセス許可が必要です。
**読み取りセット S3 GetObject**
Amazon S3 `GetObject` API を使用してストアからオブジェクトを読み取るには、IAM 呼び出し元にオブジェクトに対する`kms:Decrypt`アクセス許可が必要です。カスタマーマネージドキーと AWS 所有のキー 設定の両方にこのアクセス許可を設定します。
#### HealthOmics が AWS KMS で許可を使用する方法
HealthOmics Analytics には、カスタマーマネージド KMS キーを使用するための[許可](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)が必要です。HealthOmics ワークフローでは、グラントは必須ではなく、使用されません。HealthOmics Storage は、サービスプリンシパルから直接カスタマーマネージドキーを使用するため、グラントを使用しないでください。カスタマーマネージドキーで暗号化された分析ストアを作成すると、HealthOmics 分析は [CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html) リクエストを AWS KMS に送信して、ユーザーに代わって許可を作成します。AWS KMS の許可は、顧客アカウントの KMS キーへのアクセス権を HealthOmics に付与するために使用されます。
HealthOmics 分析がユーザーに代わって作成する許可を取り消したり廃止したりすることはお勧めしません。アカウントで AWS KMS キーを使用するアクセス許可を HealthOmics に付与する許可を取り消しまたは廃止すると、HealthOmics はこのデータにアクセスしたり、データストアにプッシュされた新しいリソースを暗号化したり、プル時に復号したりすることはできません。
HealthOmics の許可を取り消すか廃止すると、変更はすぐに行われます。アクセス権を取り消すには、許可を取り消すのではなく、データストアを削除することをお勧めします。データストアを削除すると、HealthOmics はユーザーに代わって許可を廃止します。
#### AWS HealthOmics の暗号化キーのモニタリング
CloudTrail を使用して、カスタマーマネージドキーを使用するときに が AWS KMS ユーザーに代わって AWS HealthOmics に送信するリクエストを追跡できます。CloudTrail ログのログエントリは、HealthOmics によって行われたリクエストを明確に区別するために、userAgent フィールドに HealthOmics.amazonAWS.com を表示します。 userAgent HealthOmics
次の例は、カスタマーマネージドキーによって暗号化されたデータにアクセスするために HealthOmics によって呼び出される AWS KMS オペレーションをモニタリングするための CreateGrant、GenerateDataKey、Decrypt、および DescribeKey の CloudTrail イベントです。
次に、CreateGrant を使用して HealthOmics 分析が顧客提供の KMS キーにアクセスできるようにする方法も示し、HealthOmics がその KMS キーを使用して保管中のすべての顧客データを暗号化できるようにします。
独自の権限を作成する必要はありません。HealthOmics は、CreateGrant リクエストを AWS KMS に送信することで、ユーザーに代わって許可を作成します。の許可 AWS KMS は、顧客アカウントの AWS KMS キーへのアクセスを HealthOmics に許可するために使用されます。
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AssumedRole",
"principalId": "xx:test",
"arn": "arn:AWS:sts::555555555555:assumed-role/user-admin/test",
"accountId": "xx",
"accessKeyId": "xxx",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "xxxx",
"arn": "arn:AWS:iam::555555555555:role/user-admin",
"accountId": "555555555555",
"userName": "user-admin"
},
"webIdFederationData": {},
"attributes": {
"creationDate": "2022-11-11T01:36:17Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "apigateway.amazonAWS.com"
},
"eventTime": "2022-11-11T02:34:41Z",
"eventSource": "kms.amazonAWS.com",
"eventName": "CreateGrant",
"AWSRegion": "us-west-2",
"sourceIPAddress": "apigateway.amazonAWS.com",
"userAgent": "apigateway.amazonAWS.com",
"requestParameters": {
"granteePrincipal": "AWS Internal",
"keyId": "arn:AWS:kms:us-west-2:555555555555:key/a6e87d77-cc3e-4a98-a354-e4c275d775ef",
"operations": [
"CreateGrant",
"RetireGrant",
"Decrypt",
"GenerateDataKey"
]
},
"responseElements": {
"grantId": "4869b81e0e1db234342842af9f5531d692a76edaff03e94f4645d493f4620ed7",
"keyId": "arn:AWS:kms:us-west-2:245126421963:key/xx-cc3e-4a98-a354-e4c275d775ef"
},
"requestID": "d31d23d6-b6ce-41b3-bbca-6e0757f7c59a",
"eventID": "3a746636-20ef-426b-861f-e77efc56e23c",
"readOnly": false,
"resources": [
{
"accountId": "245126421963",
"type": "AWS::KMS::Key",
"ARN": "arn:AWS:kms:us-west-2:245126421963:key/xx-cc3e-4a98-a354-e4c275d775ef"
}
],
"eventType": "AWSApiCall",
"managementEvent": true,
"recipientAccountId": "245126421963",
"eventCategory": "Management"
}
```
次の例は、GenerateDataKey を使用して、ユーザーがデータを保存する前に暗号化するために必要なアクセス許可を持っていることを確認する方法を示しています。
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AssumedRole",
"principalId": "EXAMPLEUSER",
"arn": "arn:AWS:sts::111122223333:assumed-role/Sampleuser01",
"accountId": "111122223333",
"accessKeyId": "EXAMPLEKEYID",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "EXAMPLEROLE",
"arn": "arn:AWS:iam::111122223333:role/Sampleuser01",
"accountId": "111122223333",
"userName": "Sampleuser01"
},
"webIdFederationData": {},
"attributes": {
"creationDate": "2021-06-30T21:17:06Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "omics.amazonAWS.com"
},
"eventTime": "2021-06-30T21:17:37Z",
"eventSource": "kms.amazonAWS.com",
"eventName": "GenerateDataKey",
"AWSRegion": "us-east-1",
"sourceIPAddress": "omics.amazonAWS.com",
"userAgent": "omics.amazonAWS.com",
"requestParameters": {
"keySpec": "AES_256",
"keyId": "arn:AWS:kms:us-east-1:111122223333:key/EXAMPLE_KEY_ARN"
},
"responseElements": null,
"requestID": "EXAMPLE_ID_01",
"eventID": "EXAMPLE_ID_02",
"readOnly": true,
"resources": [
{
"accountId": "111122223333",
"type": "AWS::KMS::Key",
"ARN": "arn:AWS:kms:us-east-1:111122223333:key/EXAMPLE_KEY_ARN"
}
],
"eventType": "AWSApiCall",
"managementEvent": true,
"recipientAccountId": "111122223333",
"eventCategory": "Management"
}
```
### 詳細情報
以下のリソースは、保管時のデータの暗号化に関する詳細情報を提供します。
[AWS Key Management Service の基本概念](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html)の詳細については、 AWS KMS ドキュメントを参照してください。
AWS KMS ドキュメントのセキュリティ[のベストプラクティス](https://docs.aws.amazon.com/kms/latest/developerguide/best-practices.html)の詳細については、「」を参照してください。
## 転送中の暗号化
AWS HealthOmics は TLS 1.2 以降を使用して、パブリックエンドポイントおよびバックエンドサービスを介して転送中のデータを暗号化します。
# HealthOmics での ID とアクセスの管理
AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御 AWS のサービス するのに役立つ です。IAM 管理者は、誰を*認証* (サインイン) し、誰に AWS HealthOmics リソースの使用*を許可する* (アクセス許可を付与する) かを制御します。IAM は、追加料金なしで使用できる AWS のサービス です。
**Topics**
+ [オーディエンス](#security_iam_audience)
+ [アイデンティティを使用した認証](#security_iam_authentication)
+ [ポリシーを使用したアクセスの管理](#security_iam_access-manage)
+ [が IAM と AWS HealthOmics 連携する方法](security_iam_service-with-iam.md)
+ [のアイデンティティベースのポリシーの例 AWS HealthOmics](security_iam_id-based-policy-examples.md)
+ [AWS の 管理ポリシー AWS HealthOmics](security-iam-awsmanpol.md)
+ [AWS HealthOmics ID とアクセスのトラブルシューティング](security_iam_troubleshoot.md)
## オーディエンス
AWS Identity and Access Management (IAM) の使用方法は、ロールによって異なります。
+ **サービスユーザー** - 機能にアクセスできない場合は、管理者にアクセス許可をリクエストします (「[AWS HealthOmics ID とアクセスのトラブルシューティング](security_iam_troubleshoot.md)」を参照)。
+ **サービス管理者** - ユーザーアクセスを決定し、アクセス許可リクエストを送信します (「[が IAM と AWS HealthOmics 連携する方法](security_iam_service-with-iam.md)」を参照)
+ **IAM 管理者** - アクセスを管理するためのポリシーを作成します (「[のアイデンティティベースのポリシーの例 AWS HealthOmics](security_iam_id-based-policy-examples.md)」を参照)
## アイデンティティを使用した認証
認証は、ID 認証情報 AWS を使用して にサインインする方法です。、IAM ユーザー AWS アカウントのルートユーザー、または IAM ロールを引き受けることで認証される必要があります。
AWS IAM アイデンティティセンター (IAM Identity Center)、シングルサインオン認証、Google/Facebook 認証情報などの ID ソースからの認証情報を使用して、フェデレーティッド ID としてサインインできます。サインインの詳細については、「*AWS サインイン ユーザーガイド*」の「[AWS アカウントにサインインする方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」を参照してください。
プログラムによるアクセスの場合、 は SDK と CLI AWS を提供してリクエストを暗号化して署名します。詳細については、「*IAM ユーザーガイド*」の「[API リクエストに対するAWS 署名バージョン 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)」を参照してください。
### AWS アカウント ルートユーザー
を作成するときは AWS アカウント、まず、すべての AWS のサービス および リソースへの完全なアクセス権を持つ AWS アカウント *root ユーザー*と呼ばれる 1 つのサインインアイデンティティから始めます。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。ルートユーザー認証情報を必要とするタスクについては、「*IAM ユーザーガイド*」の「[ルートユーザー認証情報が必要なタスク](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)」を参照してください。
### フェデレーテッドアイデンティティ
ベストプラクティスとして、人間のユーザーが一時的な認証情報 AWS のサービス を使用して にアクセスするには、ID プロバイダーとのフェデレーションを使用する必要があります。
*フェデレーティッド ID* は、エンタープライズディレクトリ、ウェブ ID プロバイダー、または ID Directory Service ソースの認証情報 AWS のサービス を使用して にアクセスするユーザーです。フェデレーテッドアイデンティティは、一時的な認証情報を提供するロールを引き受けます。
アクセスを一元管理する場合は、 AWS IAM アイデンティティセンターをお勧めします。詳細については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[IAM アイデンティティセンターとは](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)」を参照してください。
### IAM ユーザーとグループ
*[IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*は、特定の個人やアプリケーションに対する特定のアクセス許可を持つアイデンティティです。長期認証情報を持つ IAM ユーザーの代わりに一時的な認証情報を使用することをお勧めします。詳細については、*IAM ユーザーガイド*の[「ID プロバイダーとのフェデレーションを使用して にアクセスすることを人間 AWS のユーザーに要求する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)」を参照してください。
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)は、IAM ユーザーの集合を指定し、大量のユーザーに対するアクセス許可の管理を容易にします。詳細については、「*IAM ユーザーガイド*」の「[IAM ユーザーに関するユースケース](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html)」を参照してください。
### IAM ロール
*[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*は、特定のアクセス許可を持つアイデンティであり、一時的な認証情報を提供します。[ユーザーから IAM ロール (コンソール) に切り替えるか、 または API オペレーションを呼び出すことで、ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)を引き受けることができます。 AWS CLI AWS 詳細については、「*IAM ユーザーガイド*」の「[ロールを引き受けるための各種方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)」を参照してください。
IAM ロールは、フェデレーションユーザーアクセス、一時的な IAM ユーザーのアクセス許可、クロスアカウントアクセス、クロスサービスアクセス、および Amazon EC2 で実行するアプリケーションに役立ちます。詳細については、*IAM ユーザーガイド* の [IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) を参照してください。
## ポリシーを使用したアクセスの管理
でアクセスを制御する AWS には、ポリシーを作成し、ID AWS またはリソースにアタッチします。ポリシーは、アイデンティティまたはリソースに関連付けられている場合のアクセス許可を定義します。 は、プリンシパルがリクエストを行うときにこれらのポリシー AWS を評価します。ほとんどのポリシーは JSON ドキュメント AWS として に保存されます。JSON ポリシードキュメントの詳細については、「*IAM ユーザーガイド*」の「[JSON ポリシー概要](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)」を参照してください。
管理者は、ポリシーを使用して、どの**プリンシパル**がどの**リソース**に対して、どのような**条件**で**アクション**を実行できるかを定義することで、誰が何にアクセスできるかを指定します。
デフォルトでは、ユーザーやロールにアクセス許可はありません。IAM 管理者は IAM ポリシーを作成してロールに追加し、このロールをユーザーが引き受けられるようにします。IAM ポリシーは、オペレーションの実行方法を問わず、アクセス許可を定義します。
### アイデンティティベースのポリシー
アイデンティティベースのポリシーは、アイデンティティ (ユーザー、グループ、またはロール) にアタッチできる JSON アクセス許可ポリシードキュメントです。これらのポリシーは、アイデンティティがどのリソースに対してどのような条件下でどのようなアクションを実行できるかを制御します。アイデンティティベースポリシーの作成方法については、*IAM ユーザーガイド* の [カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) を参照してください。
アイデンティティベースのポリシーは、*インラインポリシー* (単一の ID に直接埋め込む) または*管理ポリシー* (複数の ID にアタッチされたスタンドアロンポリシー) にすることができます。管理ポリシーとインラインポリシーのいずれかを選択する方法については、「*IAM ユーザーガイド*」の「[管理ポリシーとインラインポリシーのいずれかを選択する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html)」を参照してください。
### リソースベースのポリシー
リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。例としては、IAM *ロール信頼ポリシー*や Amazon S3 *バケットポリシー*などがあります。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスを制御できます。リソースベースのポリシーでは、[プリンシパルを指定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)必要があります。
リソースベースのポリシーは、そのサービス内にあるインラインポリシーです。リソースベースのポリシーでは、IAM の AWS マネージドポリシーを使用できません。
### その他のポリシータイプ
AWS は、より一般的なポリシータイプによって付与されるアクセス許可の上限を設定できる追加のポリシータイプをサポートしています。
+ **アクセス許可の境界** – アイデンティティベースのポリシーで IAM エンティティに付与することのできるアクセス許可の数の上限を設定します。詳細については、「*IAM ユーザーガイド*」の「[IAM エンティティのアクセス許可境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)」を参照してください。
+ **サービスコントロールポリシー (SCP)** - AWS Organizations内の組織または組織単位の最大のアクセス許可を指定します。詳細については、「*AWS Organizations ユーザーガイド*」の「[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)」を参照してください。
+ **リソースコントロールポリシー (RCP)** – は、アカウント内のリソースで利用できる最大数のアクセス許可を定義します。詳細については、「*AWS Organizations ユーザーガイド*」の「[リソースコントロールポリシー (RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)」を参照してください。
+ **セッションポリシー** – ロールまたはフェデレーションユーザーの一時セッションを作成する際にパラメータとして渡される高度なポリシーです。詳細については、「*IAM ユーザーガイド*」の「[セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)」を参照してください。
### 複数のポリシータイプ
1 つのリクエストに複数のタイプのポリシーが適用されると、結果として作成されるアクセス許可を理解するのがさらに難しくなります。複数のポリシータイプが関与する場合にリクエストを許可するかどうか AWS を決定する方法については、*「IAM ユーザーガイド*」の[「ポリシー評価ロジック](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)」を参照してください。
# が IAM と AWS HealthOmics 連携する方法
IAM を使用して AWS HealthOmics へのアクセスを管理する前に、AWS HealthOmics で使用できる IAM 機能を確認してください。
**で使用できる IAM 機能 AWS HealthOmics**
| IAM 機能 | HealthOmics のサポート |
| --- | --- |
| [アイデンティティベースのポリシー](#security_iam_service-with-iam-id-based-policies) | あり |
| [リソースベースのポリシー](#security_iam_service-with-iam-resource-based-policies) | なし |
| [ポリシーアクション](#security_iam_service-with-iam-id-based-policies-actions) | あり |
| [ポリシーリソース](#security_iam_service-with-iam-id-based-policies-resources) | あり |
| [ポリシー条件キー](#security_iam_service-with-iam-id-based-policies-conditionkeys) | いいえ |
| [ACL](#security_iam_service-with-iam-acls) | いいえ |
| [ABAC (ポリシーのタグ) ](#security_iam_service-with-iam-tags) | はい |
| [一時的な認証情報](#security_iam_service-with-iam-roles-tempcreds) | あり |
| [プリンシパルアクセス権限](#security_iam_service-with-iam-principal-permissions) | あり |
| [サービスロール](#security_iam_service-with-iam-roles-service) | あり |
| [サービスリンクロール](#security_iam_service-with-iam-roles-service-linked) | いいえ |
HealthOmics およびその他の AWS のサービスがほとんどの IAM 機能と連携する方法の概要については、IAM *ユーザーガイド*の[AWS 「IAM と連携する のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。
# サービス間の混乱した代理の防止
混乱した代理問題は、アクションを実行する許可を持たないエンティティが、より特権のあるエンティティにアクションを実行するように強制できるセキュリティの問題です。では AWS、サービス間のなりすましにより、混乱した代理問題が発生する可能性があります。サービス間でのなりすましは、あるサービス (*呼び出し元サービス*) が、別のサービス (*呼び出し対象サービス*) を呼び出すときに発生する可能性があります。呼び出し元サービスが操作され、それ自身のアクセス許可を使用して、本来アクセス許可が付与されるべきではない方法で別の顧客のリソースに対して働きかけることがあります。これを防ぐため、 AWS では、アカウント内のリソースへのアクセス許可が付与されたサービスプリンシパルですべてのサービスのデータを保護するために役立つツールを提供しています。
AWS HealthOmics がリソースに別のサービスに付与するアクセス許可を制限するには、リソースポリシーで [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)および [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) グローバル条件コンテキストキーを使用することをお勧めします。
HealthOmics が引き受けるロールの混乱した代理問題を防ぐには、ロールの信頼ポリシー`arn:aws:omics:region:accountNumber:*`で `aws:SourceArn` の値を に設定します。ワイルドカード (`*`) は、すべての HealthOmics リソースに 条件を適用します。
次の信頼関係ポリシーは、HealthOmics にリソースへのアクセスを許可し、 `aws:SourceArn` および `aws:SourceAccount` グローバル条件コンテキストキーを使用して混乱した代理問題を防ぎます。HealthOmics のロールを作成するときは、このポリシーを使用します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": [
"omics.amazonaws.com"
]
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:omics:us-east-1:123456789012:*"
}
}
}
]
}
```
------
## HealthOmics のアイデンティティベースのポリシー
**アイデンティティベースのポリシーのサポート:** あり
アイデンティティベースポリシーは、IAM ユーザー、ユーザーグループ、ロールなど、アイデンティティにアタッチできる JSON 許可ポリシードキュメントです。これらのポリシーは、ユーザーとロールが実行できるアクション、リソース、および条件をコントロールします。アイデンティティベースポリシーの作成方法については、「*IAM ユーザーガイド*」の「[カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」を参照してください。
IAM アイデンティティベースのポリシーでは、許可または拒否するアクションとリソース、およびアクションを許可または拒否する条件を指定できます。JSON ポリシーで使用できるすべての要素について学ぶには、「*IAM ユーザーガイド*」の「[IAM JSON ポリシーの要素のリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)」を参照してください。
### HealthOmics のアイデンティティベースのポリシーの例
AWS HealthOmics アイデンティティベースのポリシーの例を表示するには、「」を参照してください[のアイデンティティベースのポリシーの例 AWS HealthOmics](security_iam_id-based-policy-examples.md)。
## HealthOmics 内のリソースベースのポリシー
**リソースベースのポリシーのサポート:** なし
リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。リソースベースのポリシーには例として、IAM *ロールの信頼ポリシー*や Amazon S3 *バケットポリシー*があげられます。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスをコントロールできます。ポリシーがアタッチされているリソースの場合、指定されたプリンシパルがそのリソースに対して実行できるアクションと条件は、ポリシーによって定義されます。リソースベースのポリシーで、[プリンシパルを指定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)必要があります。プリンシパルには、アカウント、ユーザー、ロール、フェデレーティッドユーザー、または を含めることができます AWS のサービス。
クロスアカウントアクセスを有効にするには、全体のアカウント、または別のアカウントの IAM エンティティを、リソースベースのポリシーのプリンシパルとして指定します。詳細については、IAM ユーザーガイド**の[IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)を参照してください。
## HealthOmics のポリシーアクション
**ポリシーアクションのサポート:** あり
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
JSON ポリシーの `Action` 要素にはポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。このアクションは関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。
HealthOmics アクションのリストを確認するには、*「サービス認可リファレンス*」の[「AWS HealthOmics で定義されるアクション](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awshealthomics.html#awshealthomics-actions-as-permissions)」を参照してください。
HealthOmics のポリシーアクションは、アクションの前に次のプレフィックスを使用します。
```
omics
```
単一のステートメントで複数のアクションを指定するには、アクションをカンマで区切ります。
```
"Action": [
"omics:action1",
"omics:action2"
]
```
AWS HealthOmics アイデンティティベースのポリシーの例を表示するには、「」を参照してください[のアイデンティティベースのポリシーの例 AWS HealthOmics](security_iam_id-based-policy-examples.md)。
## HealthOmics のポリシーリソース
**ポリシーリソースのサポート:** あり
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件**下で**アクション**を実行できるかということです。
`Resource` JSON ポリシー要素はアクションが適用されるオブジェクトを指定します。ベストプラクティスとして、[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) を使用してリソースを指定します。リソースレベルのアクセス許可をサポートしないアクションの場合は、ステートメントがすべてのリソースに適用されることを示すために、ワイルドカード (\$1) を使用します。
```
"Resource": "*"
```
HealthOmics リソースタイプとその ARNs[「AWS HealthOmics で定義されるリソース](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awshealthomics.html.html#awshealthomics-resources-for-iam-policies)」を参照してください。 **各リソースの ARN を指定できるアクションについては、[「AWS HealthOmics で定義されるアクション](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awshealthomics.html#awshealthomics-actions-as-permissions)」を参照してください。
AWS HealthOmics アイデンティティベースのポリシーの例を表示するには、「」を参照してください[のアイデンティティベースのポリシーの例 AWS HealthOmics](security_iam_id-based-policy-examples.md)。
## HealthOmics のポリシー条件キー
ポリシー条件キーは HealthOmics ではサポートされていません。
## HealthOmicsACLs)
**ACL のサポート:** なし
アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするためのアクセス許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。
## HealthOmics を使用した属性ベースのアクセスコントロール (ABAC)
**ABAC (ポリシー内のタグ) のサポート:** あり
属性ベースのアクセス制御 (ABAC) は、タグと呼ばれる属性に基づいてアクセス許可を定義する認可戦略です。IAM エンティティと AWS リソースにタグをアタッチし、プリンシパルのタグがリソースのタグと一致するときにオペレーションを許可する ABAC ポリシーを設計できます。
タグに基づいてアクセスを管理するには、`aws:ResourceTag/key-name`、`aws:RequestTag/key-name`、または `aws:TagKeys` の条件キーを使用して、ポリシーの[条件要素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)でタグ情報を提供します。
サービスがすべてのリソースタイプに対して 3 つの条件キーすべてをサポートする場合、そのサービスの値は**あり**です。サービスが一部のリソースタイプに対してのみ 3 つの条件キーのすべてをサポートする場合、値は「**部分的**」になります。
ABAC の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可でアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。ABAC をセットアップする手順を説明するチュートリアルについては、「*IAM ユーザーガイド*」の「[属性ベースのアクセスコントロール (ABAC) を使用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)」を参照してください。
HealthOmics リソースのタグ付けの詳細については、「」を参照してください[HealthOmics でのリソースのタグ付け](tagging.md)。
次の例は、特定のタグなしでリソースへのアクセスを拒否する IAM ポリシーを記述する方法を示しています。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"omics:*"
],
"Resource": [
"*"
],
"Condition": {
"Null": {
"aws:RequestTag/MyCustomTag": "true"
}
}
}
]
}
```
------
## HealthOmics での一時的な認証情報の使用
**一時的な認証情報のサポート:** あり
一時的な認証情報は、 AWS リソースへの短期的なアクセスを提供し、フェデレーションまたは切り替えロールを使用する場合に自動的に作成されます。 AWS では、長期的なアクセスキーを使用する代わりに、一時的な認証情報を動的に生成することをお勧めします。詳細については、「*IAM ユーザーガイド*」の「[IAM の一時的な認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)」および「[AWS のサービス と IAM との連携](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。
## HealthOmics のクロスサービスプリンシパルアクセス許可
**転送アクセスセッション (FAS) のサポート:** あり
転送アクセスセッション (FAS) は、 を呼び出すプリンシパルのアクセス許可と AWS のサービス、ダウンストリームサービス AWS のサービス へのリクエストをリクエストする を使用します。FAS リクエストを行う際のポリシーの詳細については、「[転送アクセスセッション](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)」を参照してください。
## HealthOmics のサービスロール
**サービスロールのサポート:** あり
サービスロールとは、サービスがユーザーに代わってアクションを実行するために引き受ける [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)です。IAM 管理者は、IAM 内からサービスロールを作成、変更、削除できます。詳細については、IAM ユーザーガイド**の [AWS のサービスに許可を委任するロールを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)を参照してください。
**警告**
サービスロールのアクセス許可を変更すると、HealthOmics の機能が破損する可能性があります。HealthOmics が指示する場合にのみ、サービスロールを編集します。
## HealthOmics のサービスにリンクされたロール
**サービスにリンクされたロールのサポート:** なし
サービスにリンクされたロールは、 にリンクされたサービスロールの一種です AWS のサービス。サービスは、ユーザーに代わってアクションを実行するロールを引き受けることができます。サービスにリンクされたロールは に表示され AWS アカウント 、サービスによって所有されます。IAM 管理者は、サービスにリンクされたロールのアクセス許可を表示できますが、編集することはできません。
サービスにリンクされたロールの作成または管理の詳細については、「[IAM と提携するAWS のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。表の「**サービスリンクロール**」列に `Yes` と記載されたサービスを見つけます。サービスにリンクされたロールに関するドキュメントをサービスで表示するには、**[はい]** リンクを選択します。
# のアイデンティティベースのポリシーの例 AWS HealthOmics
デフォルトでは、ユーザーとロールには AWS HealthOmics リソースを作成または変更するアクセス許可はありません。IAM 管理者は、リソースで必要なアクションを実行するための権限をユーザーに付与する IAM ポリシーを作成できます。
これらのサンプルの JSON ポリシードキュメントを使用して IAM アイデンティティベースのポリシーを作成する方法については、「*IAM ユーザーガイド*」の「[IAM ポリシーを作成する (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)」を参照してください。
各リソースタイプの ARN の形式など、AWS HealthOmics で定義されるアクションとリソースタイプの詳細については、*「サービス認可リファレンス*[」の「AWS HealthOmics のアクション、リソース、および条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awshealthomics.html)」を参照してください。 ARNs
**Topics**
+ [ポリシーに関するベストプラクティス](#security_iam_service-with-iam-policy-best-practices)
+ [HealthOmics コンソールの使用](#security_iam_id-based-policy-examples-console)
+ [自分の権限の表示をユーザーに許可する](#security_iam_id-based-policy-examples-view-own-permissions)
## ポリシーに関するベストプラクティス
ID ベースのポリシーは、アカウント内で誰かが AWS HealthOmics リソースを作成、アクセス、または削除できるかどうかを決定します。これらのアクションでは、 AWS アカウントに費用が発生する場合があります。アイデンティティベースポリシーを作成したり編集したりする際には、以下のガイドラインと推奨事項に従ってください:
+ ** AWS 管理ポリシーを開始し、最小特権のアクセス許可に移行** – ユーザーとワークロードにアクセス許可の付与を開始するには、多くの一般的なユースケースにアクセス許可を付与する*AWS 管理ポリシー*を使用します。これらは で使用できます AWS アカウント。ユースケースに固有の AWS カスタマー管理ポリシーを定義することで、アクセス許可をさらに減らすことをお勧めします。詳細については、*IAM ユーザーガイド* の [AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) または [ジョブ機能のAWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) を参照してください。
+ **最小特権を適用する** – IAM ポリシーでアクセス許可を設定する場合は、タスクの実行に必要な許可のみを付与します。これを行うには、特定の条件下で特定のリソースに対して実行できるアクションを定義します。これは、最小特権アクセス許可とも呼ばれています。IAM を使用して許可を適用する方法の詳細については、*IAM ユーザーガイド* の [IAM でのポリシーとアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) を参照してください。
+ **IAM ポリシーで条件を使用してアクセスをさらに制限する** - ポリシーに条件を追加して、アクションやリソースへのアクセスを制限できます。たとえば、ポリシー条件を記述して、すべてのリクエストを SSL を使用して送信するように指定できます。条件を使用して、サービスアクションが などの特定の を通じて使用されている場合に AWS のサービス、サービスアクションへのアクセスを許可することもできます CloudFormation。詳細については、*IAM ユーザーガイド* の [IAM JSON ポリシー要素:条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) を参照してください。
+ **IAM アクセスアナライザー を使用して IAM ポリシーを検証し、安全で機能的な権限を確保する** - IAM アクセスアナライザー は、新規および既存のポリシーを検証して、ポリシーが IAM ポリシー言語 (JSON) および IAM のベストプラクティスに準拠するようにします。IAM アクセスアナライザーは 100 を超えるポリシーチェックと実用的な推奨事項を提供し、安全で機能的なポリシーの作成をサポートします。詳細については、*IAM ユーザーガイド* の [IAM Access Analyzer でポリシーを検証する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) を参照してください。
+ **多要素認証 (MFA) を要求する** – で IAM ユーザーまたはルートユーザーを必要とするシナリオがある場合は AWS アカウント、MFA をオンにしてセキュリティを強化します。API オペレーションが呼び出されるときに MFA を必須にするには、ポリシーに MFA 条件を追加します。詳細については、*IAM ユーザーガイド* の [MFA を使用した安全な API アクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) を参照してください。
IAM でのベストプラクティスの詳細については、*IAM ユーザーガイド* の [IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) を参照してください。
## HealthOmics コンソールの使用
AWS HealthOmics コンソールにアクセスするには、最小限のアクセス許可のセットが必要です。これらのアクセス許可により、 の AWS HealthOmics リソースの詳細を一覧表示および表示できます AWS アカウント。最小限必要な許可よりも制限が厳しいアイデンティティベースのポリシーを作成すると、そのポリシーを持つエンティティ (ユーザーまたはロール) に対してコンソールが意図したとおりに機能しません。
AWS CLI または AWS API のみを呼び出すユーザーには、最小限のコンソールアクセス許可を付与する必要はありません。代わりに、実行しようとしている API オペレーションに一致するアクションのみへのアクセスが許可されます。
## 自分の権限の表示をユーザーに許可する
この例では、ユーザーアイデンティティにアタッチされたインラインおよびマネージドポリシーの表示を IAM ユーザーに許可するポリシーの作成方法を示します。このポリシーには、コンソールで、または AWS CLI または AWS API を使用してプログラムでこのアクションを実行するアクセス許可が含まれています。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# AWS の 管理ポリシー AWS HealthOmics
AWS 管理ポリシーは、 によって作成および管理されるスタンドアロンポリシーです AWS。 AWS 管理ポリシーは、多くの一般的なユースケースにアクセス許可を付与するように設計されているため、ユーザー、グループ、ロールにアクセス許可の割り当てを開始できます。
AWS 管理ポリシーは、すべての AWS お客様が使用できるため、特定のユースケースに対して最小特権のアクセス許可を付与しない場合があることに注意してください。ユースケースに固有の[カスタマー管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)を定義して、アクセス許可を絞り込むことをお勧めします。
AWS 管理ポリシーで定義されているアクセス許可は変更できません。が AWS マネージドポリシーで定義されたアクセス許可 AWS を更新すると、ポリシーがアタッチされているすべてのプリンシパル ID (ユーザー、グループ、ロール) に影響します。 AWS は、新しい が起動されるか、新しい API オペレーション AWS のサービス が既存のサービスで使用できるようになったときに、 AWS マネージドポリシーを更新する可能性が最も高くなります。
詳細については、「**IAM ユーザーガイド」の「[AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)」を参照してください。
## AWS マネージドポリシー: AmazonOmicsFullAccess
`AmazonOmicsFullAccess` ポリシーを IAM ID にアタッチして、HealthOmics へのフルアクセスを許可できます。
このポリシーは、すべての HealthOmics アクションへのフルアクセス許可を付与します。注釈ストアまたはバリアントストアを作成すると、Omics は Resource Access Manager (RAM) コンソールの Resource Share Invitation を通じてそのストアへのアクセスも許可します。Lake Formation を介したリソース共有の招待の詳細については、[「Lake Formation でのクロスアカウントデータ共有](https://docs.aws.amazon.com/lake-formation/latest/dg/cross-account-permissions.html)」を参照してください。Omics 管理者ポリシーの場合、Amazon S3 バケットにアクセスするには次のアクセス許可も必要です。
+ PutObject
+ GetObject
+ ListBucket
+ AbortMultipartUpload
+ ListMultipartUploadParts
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"omics:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ram:AcceptResourceShareInvitation",
"ram:GetResourceShareInvitations"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:CalledViaLast": "omics.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "omics.amazonaws.com"
}
}
}
]
}
```
------
## AWS マネージドポリシー: AmazonOmicsReadOnlyAccess
`AWSOmicsReadOnlyAccess` ポリシーを IAM ID にアタッチするには、その ID のアクセス許可を読み取り専用アクセスに制限します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"omics:Get*",
"omics:List*"
],
"Resource": "*"
}
]
}
```
------
## AWS 管理ポリシーに対する HealthOmics の更新
このサービスがこれらの変更の追跡を開始してからの HealthOmics の AWS マネージドポリシーの更新に関する詳細を表示します。このページの変更に関する自動アラートについては、HealthOmics ドキュメント履歴ページの RSS フィードにサブスクライブしてください。
| 変更 | 説明 | 日付 |
| --- | --- | --- |
| AmazonOmicsFullAccess - 新しいポリシーが追加されました | HealthOmics は、すべてのアクションとリソースへのフルアクセスをユーザーに付与する新しいポリシーを追加しました。詳細については、「[AmazonOmicsFullAccess](#security-iam-awsmanpol-AmazonOmicsFullAccess)」を参照してください。 | 2023 年 2 月 23 日 |
| HealthOmics が変更の追跡を開始しました | HealthOmics は、 AWS 管理ポリシーの変更の追跡を開始しました。 | 2022 年 11 月 29 日 |
| AmazonOmicsReadOnlyAccess - 新しいポリシーが追加されました | HealthOmics は、アクセスを読み取り専用に制限する新しいポリシーを追加しました。詳細については、[AmazonOmicsReadOnlyAccess](#security-iam-awsmanpol-AmazonOmicsReadOnlyAccess) を参照してください。 | 2022 年 11 月 29 日 |
# AWS HealthOmics ID とアクセスのトラブルシューティング
次の情報は、AWS HealthOmics と IAM の使用時に発生する可能性がある一般的な問題の診断と修正に役立ちます。
**Topics**
+ [HealthOmics でアクションを実行する権限がない](#security_iam_troubleshoot-no-permissions)
+ [iam:PassRole を実行する権限がありません](#security_iam_troubleshoot-passrole)
+ [自分の 以外のユーザーに HealthOmics リソース AWS アカウント へのアクセスを許可したい](#security_iam_troubleshoot-cross-account-access)
## HealthOmics でアクションを実行する権限がない
アクションを実行する権限がないというエラーが表示された場合は、そのアクションを実行できるようにポリシーを更新する必要があります。
次のエラー例は、`mateojackson` IAM ユーザーがコンソールを使用して、ある `my-example-widget` リソースに関する詳細情報を表示しようとしたことを想定して、その際に必要な `omics:GetWidget` アクセス許可を持っていない場合に発生するものです。
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: omics:GetWidget on resource: my-example-widget
```
この場合、`omics:GetWidget` アクションを使用して `my-example-widget` リソースへのアクセスを許可するように、`mateojackson` ユーザーのポリシーを更新する必要があります。
サポートが必要な場合は、 AWS 管理者にお問い合わせください。サインイン認証情報を提供した担当者が管理者です。
## iam:PassRole を実行する権限がありません
`iam:PassRole` アクションを実行する権限がないというエラーが表示された場合は、AWS HealthOmics にロールを渡すことができるようにポリシーを更新する必要があります。
一部の AWS のサービス では、新しいサービスロールまたはサービスにリンクされたロールを作成する代わりに、既存のロールをそのサービスに渡すことができます。そのためには、サービスにロールを渡すアクセス許可が必要です。
次の例のエラーは、 という IAM ユーザーがコンソールを使用して `marymajor` AWS HealthOmics でアクションを実行しようとすると発生します。ただし、このアクションをサービスが実行するには、サービスロールから付与されたアクセス許可が必要です。Mary には、ロールをサービスに渡すアクセス許可がありません。
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
この場合、Mary のポリシーを更新してメアリーに `iam:PassRole` アクションの実行を許可する必要があります。
サポートが必要な場合は、 AWS 管理者にお問い合わせください。サインイン資格情報を提供した担当者が管理者です。
## 自分の 以外のユーザーに HealthOmics リソース AWS アカウント へのアクセスを許可したい
他のアカウントのユーザーや組織外の人が、リソースにアクセスするために使用できるロールを作成できます。ロールの引き受けを委託するユーザーを指定できます。リソースベースのポリシーまたはアクセスコントロールリスト (ACL) をサポートするサービスの場合、それらのポリシーを使用して、リソースへのアクセスを付与できます。
詳細については、以下を参照してください:
+ AWS HealthOmics がこれらの機能をサポートしているかどうかを確認するには、「」を参照してください[が IAM と AWS HealthOmics 連携する方法](security_iam_service-with-iam.md)。
+ 所有 AWS アカウント している のリソースへのアクセスを提供する方法については、[「IAM ユーザーガイド」の「所有 AWS アカウント している別の の IAM ユーザーへのアクセスを提供する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)」を参照してください。 **
+ リソースへのアクセスをサードパーティーに提供する方法については AWS アカウント、*IAM ユーザーガイド*の[「サードパーティー AWS アカウント が所有する へのアクセスを提供する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)」を参照してください。
+ ID フェデレーションを介してアクセスを提供する方法については、*IAM ユーザーガイド* の [外部で認証されたユーザー (ID フェデレーション) へのアクセスの許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) を参照してください。
+ クロスアカウントアクセスにおけるロールとリソースベースのポリシーの使用方法の違いについては、「*IAM ユーザーガイド*」の「[IAM でのクロスアカウントのリソースへのアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)」を参照してください。
# のコンプライアンス検証 AWS HealthOmics
サードパーティーの監査者は、複数のコンプライアンスプログラムの一環として AWS HealthOmics のセキュリティと AWS コンプライアンスを評価します。これには、HIPAA、FedRAMP などが含まれます。次の表は、HealthOmics サービスのコンプライアンス証明書を示しています。
| 証明書 | リンク |
| --- | --- |
| HIPAA | [ HIPAA 対応サービスリファレンス](https://aws.amazon.com/compliance/hipaa-eligible-services-reference) |
| HiTrust-CSF | [ Health Information Trust Alliance 共通セキュリティフレームワーク ](https://aws.amazon.com/compliance/services-in-scope/HITRUST-CSF/) |
| FedRAMP Moderate (East/West) | [ 連邦リスク認可管理プログラム](https://aws.amazon.com/compliance/services-in-scope/FedRAMP) |
| ISO/CSA スター | [ ISO および CSA STAR 認定](https://aws.amazon.com/compliance/iso-certified/) |
| C5 | [ クラウドコンピューティングコンプライアンスコントロールカタログ](https://aws.amazon.com/compliance/services-in-scope/C5) |
| DoD CC SRG IL2 | [ Department of Defense Cloud Computing セキュリティ要件ガイド](https://aws.amazon.com/compliance/services-in-scope/DoD_CC_SRG) |
| ENS High | [ Esquema Nacional de Seguridad](https://aws.amazon.com/compliance/services-in-scope//ENS-High) |
| FINMA | [ スイス金融市場監督局](https://aws.amazon.com/compliance/services-in-scope/FINMA) |
| ISMAP | [ 情報システムのセキュリティ管理および評価プログラム](https://aws.amazon.com/compliance/services-in-scope/ISMAP/) |
| OSPAR | [ 外部委託サービスプロバイダーの監査レポート](https://aws.amazon.com/compliance/services-in-scope/OSPAR/) |
| PCI | [ Payment Card Industry データセキュリティ標準](https://aws.amazon.com/compliance/services-in-scope/PCI/) |
| ピン留め | [ 銀行関連付け CCI - サードパーティー資格](https://aws.amazon.com/compliance/services-in-scope/pinakes/) |
| PiTuKri | [ クラウドサービスの情報セキュリティを評価するための基準](https://aws.amazon.com/compliance/services-in-scope/PiTuKri/) |
| SOC 1、2、3 | [ システムおよび組織のコントロール](https://aws.amazon.com/compliance/services-in-scope/SOC/) |
特定のコンプライアンスプログラムの対象となるすべての AWS サービスのリストについては、「コンプライアンス[プログラムによる AWS 対象範囲内のサービスコンプライアンス](https://aws.amazon.com/compliance/services-in-scope/)」を参照してください。一般的な情報については、「[AWS コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)」を参照してください。
を使用して、サードパーティーの監査レポートをダウンロードできます AWS Artifact。詳細については、[「Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)」を参照してください。
HealthOmics データストアは、内部ファイルの命名とリソースのタグ付けにサンプル ID を使用します。データを取り込む前に、サンプル ID に PHI データが含まれているかどうかを確認します。その場合は、データを取り込む前にサンプル ID を変更します。詳細については、 AWS [HIPAA コンプライアンス](https://aws.amazon.com/compliance/hipaa-compliance)ウェブページのガイダンスを参照してください。
を使用する際のお客様のコンプライアンス責任 AWS HealthOmics は、お客様のデータの機密性、貴社のコンプライアンス目的、適用される法律および規制によって決まります。 AWS では、コンプライアンスに役立つ以下のリソースを提供しています。
+ 「[セキュリティ＆コンプライアンスクイックリファレンスガイド](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance)」 – これらのデプロイガイドには、アーキテクチャ上の考慮事項の説明と、 AWSでセキュリティとコンプライアンスに重点を置いたベースライン環境をデプロイするための手順が記載されています。
+ [Architecting for HIPAA Security and Compliance ホワイトペーパー ](https://docs.aws.amazon.com/whitepapers/latest/architecting-hipaa-security-and-compliance-on-aws/architecting-hipaa-security-and-compliance-on-aws.html) – このホワイトペーパーでは、企業が AWS を使用して HIPAA 準拠のアプリケーションを作成する方法について説明します。
+ [AWS コンプライアンスリソース](https://aws.amazon.com/compliance/resources/) – このワークブックとガイドのコレクションは、お客様の業界や地域に適用される場合があります。
+ [「 デベロッパーガイド」の「ルールによるリソースの評価](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)」 – AWS Configでは、リソース設定が内部プラクティス、業界ガイドライン、および規制にどの程度準拠しているかを評価します。 *AWS Config *
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) – この AWS サービスは、 内のセキュリティ状態を包括的に把握 AWS し、セキュリティ業界標準とベストプラクティスへの準拠を確認するのに役立ちます。
# HealthOmics の耐障害性
AWS グローバルインフラストラクチャは、 AWS リージョン およびアベイラビリティーゾーンを中心に構築されています。 は、低レイテンシー、高スループット、高度に冗長なネットワークで接続された、物理的に分離および分離された複数のアベイラビリティーゾーン AWS リージョン を提供します。アベイラビリティーゾーンでは、ゾーン間で中断することなく自動的にフェイルオーバーするアプリケーションとデータベースを設計および運用することができます。アベイラビリティーゾーンは、従来の単一または複数のデータセンターインフラストラクチャよりも可用性が高く、フォールトトレラントで、スケーラブルです。
AWS リージョン およびアベイラビリティーゾーンの詳細については、[AWS 「 グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)」を参照してください。
グローバル AWS インフラストラクチャに加えて、AWS HealthOmics には、データの耐障害性とバックアップのニーズをサポートするのに役立つ機能がいくつか用意されています。
# AWS HealthOmics およびインターフェイス VPC エンドポイント (AWS PrivateLink)
VPC と の間にプライベート接続を確立するには、*インターフェイス VPC エンドポイント* AWS HealthOmics を作成します。インターフェイスエンドポイントは、インターネットゲートウェイ[AWS PrivateLink](https://aws.amazon.com/privatelink)、NAT デバイス、VPN 接続、または AWS Direct Connect 接続なしで HealthOmics API オペレーションにプライベートにアクセスするために使用できるテクノロジーである を利用しています。VPC 内のインスタンスは、パブリック IP アドレスがなくても HealthOmics API オペレーションと通信できます。VPC と HealthOmics 間のトラフィックは Amazon ネットワーク外に流れません。
各インターフェースエンドポイントは、サブネット内の 1 つ以上の [Elastic Network Interface](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) によって表されます。
詳細については、「Amazon VPC ユーザーガイド」の「[インターフェイス VPC エンドポイント (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html)」を参照してください。
VPC エンドポイントポリシーは、イスラエル (テルアビブ) を除くすべてのリージョンの HealthOmics でサポートされています。デフォルトでは、HealthOmics へのフルアクセスはエンドポイントを介して許可されます。
## HealthOmics VPC エンドポイントに関する考慮事項
HealthOmics のインターフェイス VPC エンドポイントを設定する前に、*Amazon VPC ユーザーガイド*の[インターフェイスエンドポイントのプロパティと制限](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#vpce-interface-limitations)を確認してください。
HealthOmics は、VPC からのすべての HealthOmics Storage API アクションの呼び出しをサポートしています。
デフォルトでは、VPC エンドポイントポリシーは HealthOmics ではサポートされていませんが、HealthOmics Storage オペレーションの完全な HealthOmics アクセス用の VPC エンドポイントを作成できます。詳細については、「*Amazon VPC ユーザーガイド*」の「[VPC エンドポイントによるサービスのアクセスコントロール](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html)」を参照してください。
## HealthOmics 用のインターフェイス VPC エンドポイントの作成
Amazon VPC コンソールまたは AWS Command Line Interface () を使用して、HealthOmics サービスの VPC エンドポイントを作成できますAWS CLI。詳細については、「Amazon VPC ユーザーガイド」の[インターフェイスエンドポイントの作成](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#create-interface-endpoint)を参照してください。
次のサービス名を使用して HealthOmics の VPC エンドポイントを作成します。
+ com.amazonaws.*region*.storage-omics
+ com.amazonaws.*region*.control-storage-omics
+ com.amazonaws.*region*.analytics-omics
+ com.amazonaws.*region*.workflows-omics
+ com.amazonaws.*region*.tags-omics
米国東部 (バージニア北部) および米国西部 (オレゴン) リージョンは FIPS AWS PrivateLink エンドポイントをサポートしています。これらのリージョンでは、次のサービス名を使用することもできます。
+ com.amazonaws.*region*.storage-omics-fips
+ com.amazonaws.*region*.control-storage-omics-fips
+ com.amazonaws.*region*.analytics-omics-fips
+ com.amazonaws.*region*.workflows-omics-fips
+ com.amazonaws.*region*.tags-omics-fips
エンドポイントのプライベート DNS を有効にする場合、 などのリージョンのデフォルト DNS 名を使用して HealthOmics に API リクエストを行うことができます`omics.us-east-1.amazonaws.com`。
詳細については、「Amazon VPC ユーザーガイド**」の「[インターフェイスエンドポイントを介したサービスへのアクセス](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#access-service-though-endpoint)」を参照してください。
## HealthOmics の VPC エンドポイントポリシーの作成
HealthOmics へのアクセスを制御するエンドポイントポリシーを VPC エンドポイントにアタッチできます。このポリシーでは、以下の情報を指定します。
+ アクションを実行できるプリンシパル
+ 実行可能なアクション
+ アクションを実行できるリソース
詳細については、「Amazon VPC ユーザーガイド**」の「[VPC エンドポイントによるサービスのアクセスコントロール](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html)」を参照してください。
**例: HealthOmics アクションの VPC エンドポイントポリシー。**
HealthOmics のエンドポイントポリシーの例を次に示します。このポリシーは、エンドポイントにアタッチされると、すべてのリソースのすべてのプリンシパルに対して HealthOmics アクションへのアクセスを許可します。
------
#### [ API ]
```
{
"Statement":[
{
"Principal":"*",
"Effect":"Allow",
"Action":[
"omics:List*"
],
"Resource":"*"
}
]
}
```
------
#### [ AWS CLI ]
```
aws ec2 modify-vpc-endpoint \
--vpc-endpoint-id vpce-id \
--region us-west-2 \
--policy-document \
"{\"Statement\":[{\"Principal\":\"*\",\"Effect\":\"Allow\",\"Action\":[\"omics:List*\"],\"Resource\":\"*\"}]}"
```
------
## Amazon S3 URIs を使用してリードセットにアクセスするための特別な考慮事項
プライベート接続を使用しているときに Amazon S3 URIs を介して読み取りセットにアクセスするには、シーケンスストアで PrivateLink インターフェイスエンドポイントを設定します。設定後、エンドポイントの形式は次のとおりです。
```
com.amazonaws.region.storage-omics
com.amazonaws.region.control-storage-omics
```
ゲートウェイエンドポイントを使用するには、[Amazon S3 のゲートウェイエンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html)ガイドに従ってゲートウェイエンドポイントを設定します。HealthOmics は Amazon S3 バケットを所有しているため、バケットポリシーを作成または調整する必要はありません。ゲートウェイエンドポイントは、データにアクセスするユーザーまたはロールにアタッチされたポリシーに依存しますが、より制限の厳しいポリシーでエンドポイントを設定することもできます。これらのポリシーには、Amazon S3 アクセスポイント ARN および Amazon S3 アクションに基づくアクセスの制限を含めることができます。