本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 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，请参阅按合规计划提供的[范围内的AWSAWS 服务按合规计划](https://aws.amazon.com/compliance/services-in-scope/)。 + **云端安全**-您的责任由您使用的 AWS 服务决定。您还需要对其他因素负责，包括您的数据的敏感性、您公司的要求以及适用的法律法规。 本文档可帮助您了解在使用 AWS 时如何应用分担责任模型 HealthOmics。以下主题向您展示如何配置 AWS HealthOmics 以满足您的安全与合规目标。您还将学习如何使用其他 AWS 服务来帮助您监控和保护您的 AWS HealthOmics 资源。 **Topics** + [中的数据保护 AWS HealthOmics](data-protection.md) + [中的身份和访问管理 HealthOmics](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 Security Blog* 上的 [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) 博客文章。 出于数据保护目的，我们建议您保护 AWS 账户 凭证并使用 AWS IAM Identity Center 或 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 中的敏感数据。 + 如果您在 AWS 通过命令行界面或 API 进行访问时需要经过 FIPS 140-3 验证的加密模块，请使用 FIPS 端点。有关可用的 FIPS 端点的更多信息，请参阅《美国联邦信息处理标准（FIPS）第 140-3 版》[https://aws.amazon.com/compliance/fips/](https://aws.amazon.com/compliance/fips/)。 强烈建议您切勿将机密信息或敏感信息（如您客户的电子邮件地址）放入标签或自由格式文本字段（如**名称**字段）。这包括您 AWS 服务 使用控制台、API HealthOmics 或与 AWS 或其他机构 AWS CLI合作时 AWS SDKs。在用于名称的标签或自由格式文本字段中输入的任何数据都可能会用于计费或诊断日志。如果您向外部服务器提供 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 密钥管理服务](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)。 所有 HealthOmics 数据存储（存储和分析）都支持使用客户托管密钥。创建数据存储后，无法更改加密配置。如果数据存储使用的是 AWS 拥有的密钥，则会将其表示为， AWS\$1OWNED\$1KMS\$1KEY 并且您将看不到用于静态加密的特定密钥。 对于 HealthOmics Workflows，临时文件系统不支持客户管理的密钥；但是，使用 XTS-AES-256 分组密码加密算法对所有数据进行静态加密，以加密文件系统。用于启动工作流程运行的 IAM 用户和角色还必须有权访问用于工作流程输入和输出存储桶的 AWS KMS 密钥。工作流程不使用授权， AWS KMS 加密仅限于输入和输出 Amazon S3 存储桶。同时用于工作流程的 IAM 角色还 APIs 必须有权访问所使用的 AWS KMS 密钥以及输入和输出 Amazon S3 存储桶。您可以使用 IAM 角色和权限来控制访问权限或 AWS KMS 策略。要了解更多信息，请参阅的[身份验证和访问控制 AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/control-access.html)。 当你 AWS Lake Formation 与 HealthOmics Analytics 一起使用时，与 Lake Formation 关联的任何解密权限也会被授予输入和输出 Amazon S3 存储桶。有关如何 AWS Lake Formation 管理权限的更多信息可以在[AWS Lake Formation 文档](https://docs.aws.amazon.com/lake-formation/latest/dg/register-encrypted.html)中找到。 HealthOmics Analytics 授予 Lake Formation kms: Decrypt 读取亚马逊 S3 存储桶中加密数据的权限。只要您有权通过 Lake Formation 查询数据，您就可以读取加密的数据。对数据的访问是通过 Lake Formation 中的数据访问控制来控制的，而不是通过 KMS 密钥策略进行的。要了解更多信息，请参阅 Lake Formation 文档中的[AWS 集成 AWS 服务请求](https://docs.aws.amazon.com/lake-formation/latest/dg/access-control-underlying-data.html)。 ### AWS 拥有的密钥 默认情况下， HealthOmics 用于 AWS 拥有的密钥 自动加密静态数据，因为这些数据可能包含敏感信息，例如个人身份信息 (PII) 或 Protected Health 信息 (PHI)。 AWS 拥有的密钥 未存储在您的账户中。它们是 AWS 拥有和管理的 KMS 密钥集合的一部分，可在多个 AWS 账户中使用。 AWS 服务可以 AWS 拥有的密钥 用来保护您的数据。您无法查看、管理 AWS 拥有的密钥、访问或审核其使用情况。但是无需执行任何工作或更改任何计划即可保护用于加密数据的密钥。 您无需支付月费或使用费 AWS 拥有的密钥，也不计入您账户的 AWS KMS 配额。有关更多信息，请参阅 [AWS 托管式密钥](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#AWS-owned-cmk)。 ### 客户自主管理型密钥 HealthOmics 支持使用您创建、拥有和管理的对称客户托管密钥，在现有 AWS 拥有的加密基础上添加第二层加密。由于您可以完全控制这层加密，因此可以执行以下任务： + 建立和维护密钥政策、IAM Policy 和授权 + 轮换密钥加密材料 + 启用和禁用密钥政策 + 添加 标签 + 创建密钥别名 + 安排密钥删除 您还可以使用 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)密钥的步骤进行操作。 密钥政策控制对客户托管密钥的访问。每个客户托管式密钥必须只有一个密钥策略，其中包含确定谁可以使用密钥以及如何使用密钥的声明。创建客户托管密钥时，可以指定密钥策略。有关更多信息，请参阅 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 密钥的访问权限。此密钥允许用户访问所需的 [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 中授予操作权限。 + km DescribeKey s：提供验证密钥所需的客户托管密钥详细信息。这是所有操作所必需的。 + kms：GenerateDataKey 为所有写入操作提供对静态加密资源的访问权限。此外，此操作还提供客户托管密钥的详细信息，服务可以使用这些详细信息来验证呼叫者是否有权使用密钥。 + KMS: Decrypt 提供对加密资源的读取或搜索操作的访问权限。 要将客户托管密钥用于 HealthOmics 存储资源，必须在密钥策略中允许 HealthOmics 服务主体和调用主体。这允许服务验证呼叫者是否有权访问密钥，并使用服务主体使用客户托管密钥执行商店管理。对于 HealthOmics 存储，服务主体的密钥策略必须允许以下 API 操作： + km DescribeKey s：提供验证密钥所需的客户托管密钥详细信息。这是所有操作所必需的。 + 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 策略的权限。 您可以使用 k [ms: 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** + [分析 API 权限](#analytics-permissions) + [存储 API 权限](#storage-permissions) + [如何在 AWS KMS 中 HealthOmics 使用授权](#grants-kms) + [监控您的加密密钥 AWS HealthOmics](#monitoring-kms) #### 分析 API 权限 要进行 HealthOmics 分析，创建商店的 IAM 用户或角色必须具有 kms:CreateGrant kms:GenerateDataKey、、 kms:解密和 kms:DescribeKey 权限以及必要的 HealthOmics 权限。 #### 存储 API 权限 对于 HealthOmics 存储 APIs，调用以下 API 操作的 IAM 用户或角色需要列出的权限： **CreateReferenceStore, CreateSequenceStore** 要创建商店，IAM 调用者必须拥有`kms:DescribeKey`权限和必要的 HealthOmics 权限。 HealthOmics 服务主体调用`kms:GenerateDataKeyWithoutPlaintext`对数据加载和访问进行访问验证检查。 **StartReadSetImportJob, StartReferenceImportJob** 要启动数据导入任务，IAM 调用者必须拥有`kms:Decrypt`存储上用于导入的 KMS 密钥的`kms:Decrypt`权限，以及包含要导入的对象的 Amazon S3 存储桶的权限。`kms:GenerateDataKey`此外，传入调用的角色必须对包含要导入的对象的 Amazon S3 存储桶拥有`kms:Decrypt`权限。IAM 调用者还必须拥有将角色传递给任务的权限。 **CreateMultipartReadSetUpload, UploadReadSetPart, CompleteMultipartReadSetUpload** 要完成分段上传，IAM 调用者必须拥有`kms:Decrypt`和`kms:GenerateDataKey`才能创建、上传和完成分段上传。 **StartReadSetExportJob** 要启动数据导出任务，IAM 调用者必须拥有`kms:Decrypt`存储上的 KMS 密钥从中导出的`kms:Decrypt`权限`kms:GenerateDataKey`和接收对象的 Amazon S3 存储桶的权限。此外，传入调用的角色必须拥有接收对象的 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 拥有的密钥 配置设置此权限。 #### 如何在 AWS KMS 中 HealthOmics 使用授权 HealthOmics Analytics 需要[获得授权](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)才能使用您的客户托管的 KMS 密钥。 HealthOmics 工作流程不需要或不使用赠款。 HealthOmics 存储使用直接来自服务主体的客户托管密钥，因此请勿使用授权。当您创建使用客户托管密钥加密的分析存储时， HealthOmics Analytics 会通过向 AWS KMS 发送[CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html)请求来代表您创建授权。AWS KMS 中的赠款用于授予对客户账户中的 KMS 密钥的 HealthOmics 访问权限。 不建议撤销或撤销 HealthOmics 分析代表您创建的资助。如果您撤销或取消授予在您的账户中使用 AWS KMS 密钥的 HealthOmics 权限，则 HealthOmics 无法访问这些数据、加密推送到数据存储的新资源或在提取时对其进行解密。 当您撤销或撤销的授予时 HealthOmics，更改会立即生效。要撤消访问权限，我们建议您删除数据存储而不是撤消授权。当您删除数据存储时， HealthOmics会代表您停用授权。 #### 监控您的加密密钥 AWS HealthOmics 使用客户托管密钥时，您可以使用 CloudTrail 来跟踪 AWS KMS 代表您 AWS HealthOmics 发送的请求。日志中的日志条目在 UserA CloudTrail gent 字段中显示 HealthOmics .Amazonaws.com，以明确区分由发出的请求。 HealthOmics 以下示例是 CreateGrant、 GenerateDataKey、Decrypt 和 DescribeKey 监视 AWS KMS 操作 CloudTrail 的事件，这些操作被调用 HealthOmics 以访问由您的客户托管密钥加密的数据。 下文还展示了 CreateGrant 如何使用允许 HealthOmics 分析访问客户提供的 KMS 密钥，从而 HealthOmics 能够使用该 KMS 密钥加密所有静态客户数据。 您无需创建自己的赠款。 HealthOmics 通过向 AWS KMS 发送 CreateGrant 请求来代表您创建资助。中的授权 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 文档。 有关[安全最佳实践](https://docs.aws.amazon.com/kms/latest/developerguide/best-practices.html)的更多信息， AWS KMS 请参阅文档。 ## 传输中加密 AWS HealthOmics 使用 TLS 1.2\$1 对通过公共端点和后端服务传输的数据进行加密。 # 中的身份和访问管理 HealthOmics AWS Identity and Access Management (IAM) AWS 服务 可帮助管理员安全地控制对 AWS 资源的访问权限。IAM 管理员控制谁可以*通过身份验证*（登录）和*授权*（拥有权限）使用 AWS HealthOmics 资源。您可以使用 IAM AWS 服务 ，无需支付额外费用。 **Topics** + [受众](#security_iam_audience) + [使用身份进行身份验证](#security_iam_authentication) + [使用策略管理访问](#security_iam_access-manage) + [如何 AWS HealthOmics 与 IAM 配合使用](security_iam_service-with-iam.md) + [基于身份的策略示例 AWS HealthOmics](security_iam_id-based-policy-examples.md) + [AWS 的托管策略 AWS HealthOmics](security-iam-awsmanpol.md) + [对 AWS HealthOmics 身份和访问进行故障排除](security_iam_troubleshoot.md) ## 受众 您的使用方式 AWS Identity and Access Management (IAM) 因您的角色而异： + **服务用户**：如果您无法访问功能，请从管理员处请求权限（请参阅[对 AWS HealthOmics 身份和访问进行故障排除](security_iam_troubleshoot.md)） + **服务管理员**：确定用户访问权限并提交权限请求（请参阅[如何 AWS HealthOmics 与 IAM 配合使用](security_iam_service-with-iam.md)） + **IAM 管理员**：编写用于管理访问权限的策略（请参阅[基于身份的策略示例 AWS HealthOmics](security_iam_id-based-policy-examples.md)） ## 使用身份进行身份验证 身份验证是您 AWS 使用身份凭证登录的方式。您必须以 IAM 用户身份进行身份验证 AWS 账户根用户，或者通过担任 IAM 角色进行身份验证。 您可以使用来自身份源的证书 AWS IAM Identity Center （例如（IAM Identity Center）、单点登录身份验证或 Google/Facebook 证书，以联合身份登录。有关登录的更多信息，请参阅《AWS 登录 用户指南》**中的[如何登录您的 AWS 账户](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)。 对于编程访问， AWS 提供 SDK 和 CLI 来对请求进行加密签名。有关更多信息，请参阅*《IAM 用户指南》*中的[适用于 API 请求的AWS 签名版本 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)。 ### AWS 账户 root 用户 创建时 AWS 账户，首先会有一个名为 AWS 账户 *root 用户的*登录身份，该身份可以完全访问所有资源 AWS 服务 和资源。我们强烈建议不要使用根用户进行日常任务。有关需要根用户凭证的任务，请参阅《IAM 用户指南》**中的[需要根用户凭证的任务](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)。 ### 联合身份 作为最佳实践，要求人类用户使用与身份提供商的联合身份验证才能 AWS 服务 使用临时证书进行访问。 *联合身份是指*来自您的企业目录、Web 身份提供商的用户 Directory Service ，或者 AWS 服务 使用来自身份源的凭据进行访问的用户。联合身份代入可提供临时凭证的角色。 要集中管理访问权限，建议使用。 AWS IAM Identity Center有关更多信息，请参阅《AWS IAM Identity Center 用户指南》**中的[什么是 IAM Identity Center？](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 用户指南*[中的要求人类用户使用身份提供商的联合身份验证才能 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 角色（控制台）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)或调用 AWS CLI 或 AWS API 操作来代入角色。有关更多信息，请参阅《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 通过创建策略并将其附加到 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)。 基于身份的策略可以是*内联策略*（直接嵌入到单个身份中）或*托管策略*（附加到多个身份的独立策略）。要了解如何在托管策略和内联策略之间进行选择，请参阅*《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)。 + **服务控制策略 (SCPs)**-在中指定组织或组织单位的最大权限 AWS Organizations。有关更多信息，请参阅《AWS Organizations 用户指南》**中的[服务控制策略](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)。 + **资源控制策略 (RCPs)**-设置账户中资源的最大可用权限。有关更多信息，请参阅《*AWS Organizations 用户指南》*中的[资源控制策略 (RCPs)](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)。 ### 多个策略类型 当多个类型的策略应用于一个请求时，生成的权限更加复杂和难以理解。要了解在涉及多种策略类型时如何 AWS 确定是否允许请求，请参阅 *IAM 用户指南*中的[策略评估逻辑](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)。 # 如何 AWS HealthOmics 与 IAM 配合使用 在使用 IAM 管理对 AWS 的访问权限之前 HealthOmics，请先了解有哪些 IAM 功能可用于 AWS HealthOmics。 **您可以搭配使用的 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) | 否 | | [ACLs](#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 *用户指南中的与 IAM* [配合使用的AWS 服务](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)。 # 防止跨服务混淆代理 混淆代理问题是一个安全性问题，即不具有某操作执行权限的实体可能会迫使具有更高权限的实体执行该操作。在中 AWS，跨服务模仿可能会导致混乱的副手问题。一个服务（*呼叫服务*) 调用另一项服务（*所谓的服务*)时，可能会发生跨服务模拟。可以操纵调用服务以使用其权限对另一个客户的资源进行操作，否则该服务不应有访问权限。为了防止这种情况， AWS 提供可帮助您保护所有服务的服务委托人数据的工具，这些服务委托人有权限访问账户中的资源。 我们建议在资源策略中使用[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)全局条件上下文密钥来限制 AWS HealthOmics 向该资源提供的其他服务的权限。 为防止所担任的角色出现混淆副手问题 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 **支持策略操作：**是 管理员可以使用 AWS JSON 策略来指定谁有权访问什么。也就是说，哪个**主体**可以对什么**资源**执行**操作**，以及在什么**条件**下执行。 JSON 策略的 `Action` 元素描述可用于在策略中允许或拒绝访问的操作。在策略中包含操作以授予执行关联操作的权限。 要查看 HealthOmics 操作列表，请参阅《*服务授权参考*》 HealthOmics 中的 [AWS 定义的操作](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 **支持策略资源：**是 管理员可以使用 AWS JSON 策略来指定谁有权访问什么。也就是说，哪个**主体**可以对什么**资源**执行**操作**，以及在什么**条件**下执行。 `Resource` JSON 策略元素指定要向其应用操作的一个或多个对象。作为最佳实践，请使用其 [Amazon 资源名称（ARN）](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html)指定资源。对于不支持资源级权限的操作，请使用通配符 (\$1) 指示语句应用于所有资源。 ``` "Resource": "*" ``` 要查看 HealthOmics 资源类型及其列表 ARNs，请参阅《*服务授权参考*》 HealthOmics 中的 [AWS 定义的资源](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awshealthomics.html.html#awshealthomics-resources-for-iam-policies)。要了解您可以使用哪些操作来指定每种资源的 ARN，请参阅 [AWS 定义的操作](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awshealthomics.html#awshealthomics-actions-as-permissions)。 HealthOmics 要查看 AWS HealthOmics 基于身份的策略的示例，请参阅。[基于身份的策略示例 AWS HealthOmics](security_iam_id-based-policy-examples.md) ## 的策略条件密钥 HealthOmics 中不支持策略条件密钥 HealthOmics。 ## 中的访问控制列表 (ACLs) HealthOmics **支持 ACLs：**否 访问控制列表 (ACLs) 控制哪些委托人（账户成员、用户或角色）有权访问资源。 ACLs 与基于资源的策略类似，尽管它们不使用 JSON 策略文档格式。 ## 基于属性的访问控制 (ABAC) HealthOmics **支持 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)中提供标签信息。 如果某个服务对于每种资源类型都支持所有这三个条件键，则对于该服务，该值为**是**。如果某个服务仅对于部分资源类型支持所有这三个条件键，则该值为**部分**。 有关 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)和[使用 IAM 的。AWS 服务](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)。 有关 AWS HealthOmics 定义的操作和资源类型（包括每种资源类型的格式）的详细信息，请参阅《*服务授权参考*》 HealthOmics 中的 [AWS 操作、资源和条件密钥](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) ## 策略最佳实践 基于身份的策略决定是否有人可以在您的账户中创建、访问或删除 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 Access Analyzer 验证您的 IAM 策略，以确保权限的安全性和功能性**：IAM Access Analyzer 会验证新策略和现有策略，以确保策略符合 IAM 策略语言（JSON）和 IAM 最佳实践。IAM Access Analyzer 提供 100 多项策略检查和可操作的建议，以帮助您制定安全且功能性强的策略。有关更多信息，请参阅《IAM 用户指南》**中的[使用 IAM Access Analyzer 验证策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html)。 + **需要多重身份验证 (MFA**)-如果 AWS 账户您的场景需要 IAM 用户或根用户，请启用 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 托管策略中定义的权限，则更新会影响该策略所关联的所有委托人身份（用户、组和角色）。 AWS 最有可能在启动新的 API 或现有服务可以使用新 AWS 服务 的 API 操作时更新 AWS 托管策略。 有关更多信息，请参阅《IAM 用户指南》**中的 [AWS 托管式策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)。 ## AWS 托管策略： AmazonOmicsFullAccess 您可以将该`AmazonOmicsFullAccess`策略附加到您的 IAM 身份，以授予其完全访问权限 HealthOmics。 此策略授予对所有 HealthOmics 操作的完全访问权限。当您创建注释或变体存储时，Omics 还将通过资源访问管理器 (RAM) 控制台中的资源共享邀请向您提供访问该存储的权限。有关通过 Lake Formation 邀请资源共享的更多信息，请参阅 Lake Formati [on 中的跨账户数据共享](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 身份。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "omics:Get*", "omics:List*" ], "Resource": "*" } ] } ``` ------ ## HealthOmics AWS 托管策略的更新 查看 HealthOmics 自该服务开始跟踪这些更改以来 AWS 托管策略更新的详细信息。要获得有关此页面变更的自动提醒，请订阅 “ HealthOmics 文档历史记录” 页面上的 RSS feed。 | 更改 | 描述 | 日期 | | --- | --- | --- | | 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 身份和访问进行故障排除 使用以下信息来帮助您诊断和修复在使用 AWS HealthOmics 和 IAM 时可能遇到的常见问题。 **Topics** + [我无权在以下位置执行操作 HealthOmics](#security_iam_troubleshoot-no-permissions) + [我无权执行 iam：PassRole](#security_iam_troubleshoot-passrole) + [我想允许我以外的人 AWS 账户 访问我的 HealthOmics 资源](#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 ``` 在此情况下，必须更新 `mateojackson` 用户的策略，以允许使用 `omics:GetWidget` 操作访问 `my-example-widget` 资源。 如果您需要帮助，请联系您的 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 管理员。您的管理员是提供登录凭证的人。 ## 我想允许我以外的人 AWS 账户 访问我的 HealthOmics 资源 您可以创建一个角色，以便其他账户中的用户或您组织外的人员可以使用该角色来访问您的资源。您可以指定谁值得信赖，可以代入角色。对于支持基于资源的策略或访问控制列表 (ACLs) 的服务，您可以使用这些策略向人们授予访问您的资源的权限。 要了解更多信息，请参阅以下内容： + 要了解 AWS 是否 HealthOmics 支持这些功能，请参阅[如何 AWS HealthOmics 与 IAM 配合使用](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 用户指南*中的向第三方提供](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)访问权限。 AWS 账户 + 要了解如何通过身份联合验证提供访问权限，请参阅《IAM 用户指南》**中的[为经过外部身份验证的用户（身份联合验证）提供访问权限](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-脑脊液 | [健康信息信托联盟共同安全框架](https://aws.amazon.com/compliance/services-in-scope/HITRUST-CSF/) | | FedRAMP 中等（东部/西部） | [联邦风险和授权管理计划](https://aws.amazon.com/compliance/services-in-scope/FedRAMP) | | ISO/CSA STAR | [ISO 和 CSA STAR 认证](https://aws.amazon.com/compliance/iso-certified/) | | C5 | [云计算合规性控制目录](https://aws.amazon.com/compliance/services-in-scope/C5) | | 国防部 CC SRG IL2 | [国防部云计算安全要求指南](https://aws.amazon.com/compliance/services-in-scope/DoD_CC_SRG) | | ENS High | [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 | [支付卡行业数据安全标准](https://aws.amazon.com/compliance/services-in-scope/PCI/) | | Pinakes | [银行协会 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 范围内服务 AWS 按合规计划](https://aws.amazon.com/compliance/services-in-scope/)。有关常规信息，请参阅 [AWS 合规性计划](https://aws.amazon.com/compliance/programs/)、、。 您可以使用下载第三方审计报告 AWS Artifact。有关更多信息，请参阅中的 “[下载报告” 中的 “ 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上部署基于安全性和合规性的基准环境的步骤。 + [HIPAA 安全与合规架构白皮书 — 本白皮书](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 合AWS 规资源](https://aws.amazon.com/compliance/resources/) — 此工作簿和指南集可能适用于您的行业和所在地区。 + [使用*AWS Config 开发人员指南*中的规则评估资源](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) — 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 终端节点在您 AWS HealthOmics 的 VPC* 之间建立私有连接。接口终端节点由一项技术提供支持，无需互联网网关[AWS PrivateLink](https://aws.amazon.com/privatelink)、NAT 设备、VPN 连接或 AWS Direct Connect 连接，即可使用该技术私密访问 HealthOmics API 操作。您的 VPC 中的实例不需要公有 IP 地址即可与 HealthOmics API 操作通信。您的 VPC 和 VPC 之间的流量 HealthOmics 不会流出 Amazon 网络之外。 每个接口端点均由子网中的一个或多个[弹性网络接口](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html)表示。 有关更多信息，请参阅 A *mazon VPC 用户指南中的接口 VPC* [终端节点 (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html)。 除以色列（特拉维夫） HealthOmics 以外的所有地区均支持 VPC 终端节点策略。默认情况下，允许通过终端节点进行完全访问。 HealthOmics ## HealthOmics VPC 终端节点的注意事项 在为设置接口 VPC 终端节点之前 HealthOmics，请务必查看 *Amazon VPC 用户指南*中的[接口终端节点属性和限制](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#vpce-interface-limitations)。 HealthOmics 支持从您的 VPC 调用所有 HealthOmics 存储 API 操作。 HealthOmics 默认情况下不支持 VPC 终端节点策略，但您可以创建 VPC 终端节点以实现 HealthOmics 存储操作的完全 HealthOmics 访问权限。有关更多信息，请参阅《Amazon VPC User Guide》**中的 [Controlling access to services with VPC endpoints](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html)。 ## 为创建接口 VPC 终端节点 HealthOmics 您可以使用 Amazon VPC 控制台或 AWS Command Line Interface (AWS CLI) 为 HealthOmics 服务创建 VPC 终端节点。有关更多信息，请参阅《Amazon VPC User Guide》**中的 [Creating an interface endpoint](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 美国东部（弗吉尼亚北部）和美国西部（俄勒冈）区域支持 AWS PrivateLink FIPS 终端节点。对于这些区域，您还可以使用以下服务名称： + 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)。 ## 为创建 VPC 终端节点策略 HealthOmics 您可以为 VPC 端点附加控制对 HealthOmics 的访问的端点策略。该策略指定以下信息： + 可执行操作的主体 + 可执行的操作 + 可对其执行操作的资源 有关更多信息，请参阅《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 要在使用私有连接 URIs 时通过 Amazon S3 访问读取集，请在序列存储上设置 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 操作的访问限制。