Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# IAM-Berechtigungen für HealthOmics
Sie können AWS Identity and Access Management (IAM) verwenden, um den Zugriff auf die HealthOmics API und Ressourcen wie Stores und Workflows zu verwalten. Für Benutzer und Anwendungen in Ihrem Konto, die diese verwenden HealthOmics, verwalten Sie die Berechtigungen in einer Berechtigungsrichtlinie, die Sie auf IAM-Benutzer, -Gruppen oder -Rollen anwenden können.
Um die Berechtigungen für Benutzer und Anwendungen in Ihren Konten zu verwalten, [verwenden Sie die Richtlinien, die HealthOmics Ihnen zur Verfügung stehen](permissions-user.md), oder schreiben Sie Ihre eigenen. Die HealthOmics Konsole verwendet mehrere Dienste, um Informationen über die Konfiguration und die Auslöser Ihrer Funktion abzurufen. Sie können die bereitgestellten Richtlinien unverändert oder als Ausgangspunkt für restriktivere Richtlinien verwenden.
HealthOmics verwendet [IAM-Dienstrollen](permissions-service.md), um in Ihrem Namen auf andere Dienste zuzugreifen. Sie würden beispielsweise eine Servicerolle erstellen oder auswählen, wenn Sie einen Workflow ausführen, der Daten aus Amazon S3 liest. Für einige Funktionen müssen Sie auch [Berechtigungen für Ressourcen in anderen Diensten konfigurieren](permissions-resource.md). Überprüfen Sie diese Anforderungen, bevor Sie mit der Arbeit beginnen HealthOmics
Weitere Informationen zu IAM finden Sie unter [Was ist IAM?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) im *IAM-Benutzerhandbuch*.
**Topics**
+ [Identitätsbasierte IAM-Richtlinien für HealthOmics](permissions-user.md)
+ [Servicerollen für AWS HealthOmics](permissions-service.md)
+ [Amazon-ECR-Berechtigungen](permissions-ecr.md)
+ [HealthOmics Berechtigungen für Ressourcen](permissions-resource.md)
+ [Berechtigungen für den Datenzugriff mit Amazon S3 URIs](s3-sharing.md)
# Identitätsbasierte IAM-Richtlinien für HealthOmics
Um Benutzern in Ihrem Konto Zugriff auf zu gewähren HealthOmics, verwenden Sie identitätsbasierte Richtlinien in AWS Identity and Access Management (IAM). Identitätsbasierte Richtlinien können direkt für IAM-Benutzer oder für IAM-Gruppen und -Rollen gelten, die einem Benutzer zugeordnet sind. Sie können auch Benutzern in einem anderen Konto die Berechtigung erteilen, eine Rolle in Ihrem Konto zu übernehmen und auf Ihre HealthOmics-Ressourcen zuzugreifen.
Um Benutzern die Erlaubnis zu erteilen, Aktionen an einer Workflow-Version auszuführen, müssen Sie den Workflow und die spezifische Workflow-Version zur Ressourcenliste hinzufügen.
Die folgende IAM-Richtlinie ermöglicht einem Benutzer den Zugriff auf alle HealthOmics API-Aktionen und die Übergabe von [Servicerollen](permissions-service.md) an HealthOmics.
**Example Richtlinie für Benutzer:**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"omics:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "omics.amazonaws.com"
}
}
}
]
}
```
Wenn Sie diese Dienste verwenden HealthOmics, interagieren Sie auch mit anderen AWS Diensten. Um auf diese Dienste zuzugreifen, verwenden Sie die verwalteten Richtlinien, die von den einzelnen Diensten bereitgestellt werden. Um den Zugriff auf eine Teilmenge von Ressourcen zu beschränken, können Sie die verwalteten Richtlinien als Ausgangspunkt verwenden, um Ihre eigenen restriktiveren Richtlinien zu erstellen.
****
+ [AmazonS3 FullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonS3FullAccess) — Zugriff auf Amazon S3-Buckets und Objekte, die von Jobs verwendet werden.
+ [Amazon EC2 ContainerRegistryFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryFullAccess) — Zugriff auf Amazon ECR-Registries und Repositorys für Workflow-Container-Images.
+ [AWSLakeFormationDataAdmin](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSLakeFormationDataAdmin)— Zugriff auf Lake Formation Formation-Datenbanken und -Tabellen, die von Analytics-Stores erstellt wurden.
+ [ResourceGroupsandTagEditorFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/ResourceGroupsandTagEditorFullAccess)— Taggen Sie HealthOmics Ressourcen mit HealthOmics Tagging-API-Vorgängen.
Die oben genannten Richtlinien erlauben es einem Benutzer nicht, IAM-Rollen zu erstellen. Damit ein Benutzer mit diesen Berechtigungen einen Job ausführen kann, muss ein Administrator die Servicerolle erstellen, die die HealthOmics Berechtigung zum Zugriff auf Datenquellen gewährt. Weitere Informationen finden Sie unter [Servicerollen für AWS HealthOmics](permissions-service.md).
## Definieren Sie benutzerdefinierte IAM-Berechtigungen für Läufe
Sie können jeden Workflow, jede Ausführung oder jede Ausführungsgruppe, auf die in der `StartRun` Anfrage verwiesen wird, in eine Autorisierungsanfrage aufnehmen. Führen Sie dazu die gewünschte Kombination von Workflows, Läufen oder Ausführungsgruppen in der IAM-Richtlinie auf. Sie können beispielsweise die Verwendung eines Workflows auf einen bestimmten Lauf oder eine bestimmte Ausführungsgruppe beschränken. Sie können auch angeben, dass ein Workflow nur mit einer Ausführungsgruppe verwendet werden soll.
Im Folgenden finden Sie ein Beispiel für eine IAM-Richtlinie, die einen einzelnen Workflow mit einer einzigen Ausführungsgruppe ermöglicht.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"omics:StartRun"
],
"Resource": [
"arn:aws:omics:us-west-2:123456789012:workflow/1234567",
"arn:aws:omics:us-west-2:123456789012:runGroup/2345678"
]
},
{
"Effect": "Allow",
"Action": [
"omics:StartRun"
],
"Resource": [
"arn:aws:omics:us-west-2:123456789012:run/*",
"arn:aws:omics:us-west-2:123456789012:runGroup/2345678"
]
},
{
"Effect": "Allow",
"Action": [
"omics:GetRun",
"omics:ListRunTasks",
"omics:GetRunTask",
"omics:CancelRun",
"omics:DeleteRun"
],
"Resource": [
"arn:aws:omics:us-west-2:123456789012:run/*"
]
}
]
}
```
------
# Servicerollen für AWS HealthOmics
Eine Servicerolle ist eine AWS Identity and Access Management (IAM) -Rolle, die einem AWS Service Berechtigungen für den Zugriff auf Ressourcen in Ihrem Konto gewährt. Sie stellen eine Servicerolle bereit, AWS HealthOmics wenn Sie einen Importjob starten oder einen Lauf starten.
Die HealthOmics Konsole kann die erforderliche Rolle für Sie erstellen. Wenn Sie die HealthOmics API zur Verwaltung von Ressourcen verwenden, erstellen Sie die Servicerolle mithilfe der IAM-Konsole. Weitere Informationen finden Sie unter [Eine Rolle erstellen, um Berechtigungen an eine zu delegieren](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html). AWS-Service
Für Servicerollen muss die folgende Vertrauensrichtlinie gelten.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "omics.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Die Vertrauensrichtlinie ermöglicht es dem HealthOmics Dienst, die Rolle zu übernehmen.
**Topics**
+ [Beispiel für IAM-Dienstrichtlinien](#permissions-service-samplepolicies)
+ [CloudFormation Beispielvorlage](#permissions-service-sampletemplates)
## Beispiel für IAM-Dienstrichtlinien
In diesen Beispielen IDs sind Ressourcennamen und Konten Platzhalter, die Sie durch tatsächliche Werte ersetzen müssen.
Das folgende Beispiel zeigt die Richtlinie für eine Servicerolle, die Sie zum Starten eines Laufs verwenden können. Die Richtlinie gewährt Berechtigungen für den Zugriff auf den Amazon S3 S3-Ausgabespeicherort, die Workflow-Protokollgruppe und den Amazon ECR-Container für den Lauf.
**Anmerkung**
Wenn Sie Call Caching für den Lauf verwenden, fügen Sie den Amazon S3 S3-Speicherort für den Run-Cache als Ressource zu den S3-Berechtigungen hinzu.
**Example Richtlinie für Servicerollen zum Starten eines Laufs**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket1/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket1"
]
},
{
"Effect": "Allow",
"Action": [
"logs:DescribeLogStreams",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": [
"arn:aws:logs:us-east-1:123456789012:log-group:/aws/omics/WorkflowLog:log-stream:*"
]
},
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup"
],
"Resource": [
"arn:aws:logs:us-east-1:123456789012:log-group:/aws/omics/WorkflowLog:*"
]
},
{
"Effect": "Allow",
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer",
"ecr:BatchCheckLayerAvailability"
],
"Resource": [
"arn:aws:ecr:us-east-1:123456789012:repository/*"
]
}
]
}
```
Das folgende Beispiel zeigt die Richtlinie für eine Servicerolle, die Sie für einen Store-Importjob verwenden können. Die Richtlinie gewährt Berechtigungen für den Zugriff auf den Amazon S3-Eingabespeicherort.
**Example Servicerolle für den Job „Reference Store“**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket"
]
}
]
}
```
## CloudFormation Beispielvorlage
Die folgende CloudFormation Beispielvorlage erstellt eine Servicerolle, die den HealthOmics Zugriff auf Amazon S3 S3-Buckets mit einem `omics-` Präfix und das Hochladen von Workflow-Protokollen ermöglicht.
**Example Berechtigungen für Referenzspeicher, Amazon S3 und CloudWatch Logs**
```
Parameters:
bucketName:
Description: Bucket name
Type: String
Resources:
serviceRole:
Type: AWS::IAM::Role
Properties:
Policies:
- PolicyName: read-reference
PolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Action:
- omics:*
Resource: !Sub arn:${AWS::Partition}:omics:${AWS::Region}:${AWS::AccountId}:referenceStore/*
- PolicyName: read-s3
PolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Action:
- s3:ListBucket
Resource: !Sub arn:${AWS::Partition}:s3:::${bucketName}
- Effect: Allow
Action:
- s3:GetObject
- s3:PutObject
Resource: !Sub arn:${AWS::Partition}:s3:::${bucketName}/*
- PolicyName: upload-logs
PolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Action:
- logs:DescribeLogStreams
- logs:CreateLogStream
- logs:PutLogEvents
Resource: !Sub arn:${AWS::Partition}:logs:${AWS::Region}:${AWS::AccountId}:loggroup:/aws/omics/WorkflowLog:log-stream:*
- Effect: Allow
Action:
- logs:CreateLogGroup
Resource: !Sub arn:${AWS::Partition}:logs:${AWS::Region}:${AWS::AccountId}:loggroup:/aws/omics/WorkflowLog:*
AssumeRolePolicyDocument: |
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"sts:AssumeRole"
],
"Effect": "Allow",
"Principal": {
"Service": [
"omics.amazonaws.com"
]
}
}
]
}
```
# Amazon-ECR-Berechtigungen
Bevor der HealthOmics Service einen Workflow in einem Container aus Ihrem privaten Amazon ECR-Repository ausführen kann, erstellen Sie eine Ressourcenrichtlinie für das Repository. Die Richtlinie erteilt dem HealthOmics Service die Erlaubnis, den Container zu verwenden. Sie fügen diese Ressourcenrichtlinie jedem privaten Repository hinzu, auf das der Workflow verweist.
**Anmerkung**
Das private Repository und der Workflow müssen sich in derselben Region befinden.
Wenn der Workflow und das Repository von unterschiedlichen AWS Konten verwaltet werden, müssen Sie kontenübergreifende Berechtigungen konfigurieren.
Sie müssen keinen zusätzlichen Repository-Zugriff für gemeinsam genutzte Workflows gewähren. Sie können jedoch Richtlinien erstellen, die bestimmten Workflows den Zugriff auf das Container-Image erlauben oder verweigern.
Um die Amazon ECR-Pull-Through-Cache-Funktion verwenden zu können, müssen Sie eine Registrierungsberechtigungsrichtlinie erstellen.
In den folgenden Abschnitten wird beschrieben, wie Amazon ECR-Ressourcenberechtigungen für diese Szenarien konfiguriert werden. Weitere Informationen zu Berechtigungen in Amazon ECR finden Sie unter [Private Registrierungsberechtigungen in Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry-permissions.html).
**Topics**
+ [Erstellen Sie eine Ressourcenrichtlinie für das Amazon ECR-Repository](#permissions-resource-policy)
+ [Workflows mit kontenübergreifenden Containern ausführen](#permissions-cross-account-containers)
+ [Amazon ECR-Richtlinien für gemeinsame Workflows](#permissions-shared-workflows)
+ [Richtlinien für den Amazon ECR-Pull-Through-Cache](#permissions-ecr-ptc)
## Erstellen Sie eine Ressourcenrichtlinie für das Amazon ECR-Repository
Erstellen Sie eine Ressourcenrichtlinie, damit der HealthOmics Service einen Workflow mithilfe eines Containers im Repository ausführen kann. Die Richtlinie gewährt dem HealthOmics Service Principal die Erlaubnis, auf die erforderlichen Amazon ECR-Aktionen zuzugreifen.
Gehen Sie wie folgt vor, um die Richtlinie zu erstellen:
1. Öffnen Sie die Seite [mit den privaten Repositorys](https://console.aws.amazon.com/ecr/private-registry/repositories) in der Amazon ECR-Konsole und wählen Sie das Repository aus, auf das Sie Zugriff gewähren möchten.
1. **Wählen Sie in der Seitenleiste die Option Berechtigungen aus.**
1. Wählen Sie **Bearbeiten** aus.
1. Wählen Sie **Richtlinien-JSON bearbeiten** aus.
1. Fügen Sie die folgende Richtlinienerklärung hinzu und wählen Sie dann **Speichern** aus.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "omics workflow access",
"Effect": "Allow",
"Principal": {
"Service": "omics.amazonaws.com"
},
"Action": [
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"ecr:BatchCheckLayerAvailability"
],
"Resource": "*"
}
]
}
```
------
## Workflows mit kontenübergreifenden Containern ausführen
Wenn der Workflow und der Container von unterschiedlichen AWS Konten verwaltet werden, müssen Sie die folgenden kontoübergreifenden Berechtigungen konfigurieren:
1. Aktualisieren Sie die Amazon ECR-Richtlinie für das Repository, um dem Konto, das für den Workflow verantwortlich ist, ausdrücklich die Erlaubnis zu erteilen.
1. Aktualisieren Sie die Servicerolle für das Konto, dem der Workflow gehört, um ihm Zugriff auf das Container-Image zu gewähren.
Das folgende Beispiel zeigt eine Amazon ECR-Ressourcenrichtlinie, die Zugriff auf das Konto gewährt, dem der Workflow gehört.
In diesem Beispiel:
+ Workflow-Konto-ID: 111122223333
+ Konto-ID des Container-Repositorys: 444455556666
+ Name des Containers: samtools
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "omics.amazonaws.com"
},
"Action": [
"ecr:BatchCheckLayerAvailability",
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Resource": "*"
},
{
"Sid": "AllowAccessToTheServiceRoleOfTheAccountThatOwnsTheWorkflow",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/DemoCustomer"
},
"Action": [
"ecr:BatchCheckLayerAvailability",
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Resource": "*"
}
]
}
```
------
Um die Einrichtung abzuschließen, fügen Sie der Servicerolle des Accounts, dem der Workflow gehört, die folgende Richtlinienanweisung hinzu. Die Richtlinie gewährt der Servicerolle die Erlaubnis, auf das Container-Image „samtools“ zuzugreifen. Achten Sie darauf, die Kontonummern, den Container-Namen und die Region durch Ihre eigenen Werte zu ersetzen.
```
{
"Sid": "CrossAccountEcrRepoPolicy",
"Effect": "Allow",
"Action": ["ecr:BatchCheckLayerAvailability", "ecr:BatchGetImage", "ecr:GetDownloadUrlForLayer"],
"Resource": "arn:aws:ecr:us-west-2:444455556666:repository/samtools"
}
```
## Amazon ECR-Richtlinien für gemeinsame Workflows
**Anmerkung**
HealthOmics ermöglicht einem gemeinsam genutzten Workflow automatisch den Zugriff auf das Amazon ECR-Repository im Konto des Workflow-Besitzers, während der Workflow im Konto des Abonnenten ausgeführt wird. Sie müssen keinen zusätzlichen Repository-Zugriff für gemeinsam genutzte Workflows gewähren. Weitere Informationen finden Sie unter [ HealthOmics Workflows teilen](https://docs.aws.amazon.com/omics/latest/dev/sharing-workflows.html).
Standardmäßig haben Abonnenten keinen Zugriff auf das Amazon ECR-Repository, um die zugrunde liegenden Container zu verwenden. Optional können Sie den Zugriff auf das Amazon ECR-Repository anpassen, indem Sie der Ressourcenrichtlinie des Repositorys Bedingungsschlüssel hinzufügen. Die folgenden Abschnitte enthalten Beispielrichtlinien.
### Beschränken Sie den Zugriff auf bestimmte Workflows
Sie können einzelne Workflows in einer Bedingungserklärung auflisten, sodass nur diese Workflows Container im Repository verwenden können. Der **SourceArn**Bedingungsschlüssel gibt den ARN des gemeinsam genutzten Workflows an. Das folgende Beispiel erteilt dem angegebenen Workflow die Erlaubnis, dieses Repository zu verwenden.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "OmicsAccessPrincipal",
"Effect": "Allow",
"Principal": {
"Service": "omics.amazonaws.com"
},
"Action": [
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"ecr:BatchCheckLayerAvailability"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:SourceArn": "arn:aws:omics:us-east-1:111122223333:workflow/1234567"
}
}
}
]
}
```
------
### Beschränken Sie den Zugriff auf bestimmte Konten
Sie können Abonnentenkonten in einer Bedingungserklärung auflisten, sodass nur diese Konten berechtigt sind, Container im Repository zu verwenden. Der **SourceAccount**Bedingungsschlüssel gibt den AWS-Konto des Abonnenten an. Das folgende Beispiel erteilt dem angegebenen Konto die Erlaubnis, dieses Repository zu verwenden.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "OmicsAccessPrincipal",
"Effect": "Allow",
"Principal": {
"Service": "omics.amazonaws.com"
},
"Action": [
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"ecr:BatchCheckLayerAvailability"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333"
}
}
}
]
}
```
------
Sie können Amazon ECR-Berechtigungen auch bestimmten Abonnenten verweigern, wie in der folgenden Beispielrichtlinie dargestellt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "OmicsAccessPrincipal",
"Effect": "Allow",
"Principal": {
"Service": "omics.amazonaws.com"
},
"Action": [
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"ecr:BatchCheckLayerAvailability"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:SourceAccount": "111122223333"
}
}
}
]
}
```
------
## Richtlinien für den Amazon ECR-Pull-Through-Cache
Um den Amazon ECR-Pull-Through-Cache zu verwenden, erstellen Sie eine Registrierungsberechtigungsrichtlinie. Sie erstellen auch eine Repository-Erstellungsvorlage, die die Berechtigungen für die Repositorys definiert, die vom Amazon ECR-Pull-Through-Cache erstellt wurden.
Die folgenden Abschnitte enthalten Beispiele für diese Richtlinien. Weitere Informationen zum Pull-Through-Cache finden Sie unter [Synchronisieren einer Upstream-Registrierung mit einer privaten Amazon ECR-Registrierung](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-private.html) im *Amazon Elastic Container Registry-Benutzerhandbuch*.
### Richtlinie für Registrierungsberechtigungen
Um den Amazon ECR-Pull-Through-Cache zu verwenden, erstellen Sie eine Registrierungsberechtigungsrichtlinie. Die Richtlinie für Registrierungsberechtigungen ermöglicht die Kontrolle über Replikations- und Pull-Through-Cache-Berechtigungen.
Für die kontenübergreifende Replikation müssen Sie ausdrücklich zulassen, AWS-Konto dass jeder Benutzer seine Repositorys in Ihre Registrierung replizieren kann.
Wenn Sie eine Pull-Through-Cache-Regel erstellen, kann jeder IAM-Prinzipal, der über die Berechtigung zum Abrufen von Bildern aus einer privaten Registrierung verfügt, standardmäßig auch die Pull-Through-Cacheregel verwenden. Sie können Registrierungsberechtigungen verwenden, um diese Berechtigungen weiter auf bestimmte Repositorys einzuschränken.
Fügen Sie dem Konto, dem das Container-Image gehört, eine Registrierungsberechtigungsrichtlinie hinzu.
Im folgenden Beispiel ermöglicht die Richtlinie dem HealthOmics Dienst, Repositorys für jede Upstream-Registrierung zu erstellen und Upstream-Pull-Anfragen von den erstellten Repositorys aus zu initiieren.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPTCinRegPermissions",
"Effect": "Allow",
"Principal": {
"Service": "omics.amazonaws.com"
},
"Action": [
"ecr:CreateRepository",
"ecr:BatchImportUpstreamImage"
],
"Resource": [
"arn:aws:ecr:us-east-1:123456789012:repository/ecr-public/*",
"arn:aws:ecr:us-east-1:123456789012:repository/docker-hub/*"
]
}
]
}
```
------
### Vorlage für die Erstellung eines Repository
Um den Pull-Through-Cache in verwenden zu können HealthOmics, muss das Amazon ECR-Repository über eine Vorlage für die Repository-Erstellung verfügen. Die Vorlage definiert die Konfigurationseinstellungen für die privaten Repositorys, die für eine Upstream-Registrierung erstellt wurden.
Jede Vorlage enthält ein Repository-Namespace-Präfix, das Amazon ECR verwendet, um neue Repositorys einer bestimmten Vorlage zuzuordnen. In Vorlagen kann die Konfiguration für alle Repository-Einstellungen festgelegt werden, einschließlich ressourcenbasierter Zugriffsrichtlinien, Unveränderlichkeit von Tags, Verschlüsselung und Lebenszyklusrichtlinien. Weitere Informationen finden Sie unter [Vorlagen für die Erstellung von Repositorys](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-creation-templates.html) im *Amazon Elastic Container Registry-Benutzerhandbuch*.
Im folgenden Beispiel ermöglicht die Richtlinie dem HealthOmics Service, Upstream-Pull-Anfragen von den Upstream-Repositorys zu initiieren.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PTCRepoCreationTemplate",
"Effect": "Allow",
"Principal": {
"Service": "omics.amazonaws.com"
},
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Resource": "*"
}
]
}
```
------
### Richtlinien für den kontenübergreifenden Zugriff auf Amazon ECR
Für den kontoübergreifenden Zugriff aktualisiert der Eigentümer des privaten Repositorys die Registrierungsberechtigungsrichtlinie und die Vorlage für die Erstellung des Repositorys, um den Zugriff für das andere Konto und die Ausführungsrolle dieses Kontos zu ermöglichen.
Fügen Sie in der Registrierungsberechtigungsrichtlinie eine Richtlinienerklärung hinzu, um der Ausführungsrolle des anderen Kontos den Zugriff auf die Amazon ECR-Aktionen zu ermöglichen:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCrossAccountPTCinRegPermissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/RUN_ROLE"},
"Action": [
"ecr:CreateRepository",
"ecr:BatchGetImage",
"ecr:BatchImportUpstreamImage"
],
"Resource": "arn:aws:ecr:us-east-1:123456789012:repository/path/*"
}
]
}
```
------
Fügen Sie in der Vorlage für die Repository-Erstellung eine Richtlinienerklärung hinzu, damit die Run-Rolle des anderen Accounts auf die neuen Container-Images zugreifen kann. Optional können Sie Bedingungsanweisungen hinzufügen, um den Zugriff auf bestimmte Workflows zu beschränken:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCrossAccountPTCinRepoCreationTemplate",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/RUN_ROLE"},
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:SourceArn": "arn:aws:omics:us-east-1:444455556666:workflow/WORKFLOW_ID",
"aws:SourceAccount": "111122223333"
}
}
}
]
}
```
------
Fügen Sie Berechtigungen für zwei zusätzliche Aktionen (CreateRepository und BatchImportUpstreamImage) in der Ausführungsrolle hinzu und geben Sie die Ressource an, auf die die Ausführungsrolle zugreifen kann.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CrossAccountPTCRunRolePolicy",
"Effect": "Allow",
"Action": [
"ecr:CreateRepository",
"ecr:BatchImportUpstreamImage",
"ecr:BatchCheckLayerAvailability",
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage"
],
"Resource": "arn:aws:ecr:us-east-1:123456789012::repository/{path}/*"
}
]
}
```
------
# HealthOmics Berechtigungen für Ressourcen
AWS HealthOmics erstellt in Ihrem Namen Ressourcen in anderen Diensten und greift auf diese zu, wenn Sie einen Job ausführen oder einen Shop erstellen. In einigen Fällen müssen Sie Berechtigungen in anderen Diensten konfigurieren, um auf Ressourcen zuzugreifen oder den Zugriff darauf HealthOmics zu ermöglichen.
Informationen zu Ressourcenberechtigungen im Zusammenhang mit Amazon ECR finden Sie unter[Amazon-ECR-Berechtigungen](permissions-ecr.md).
## Lake-Formation-Berechtigungen
Bevor Sie Analysefunktionen in verwenden HealthOmics, konfigurieren Sie die Standard-Datenbankeinstellungen in Lake Formation.
**So konfigurieren Sie Ressourcenberechtigungen in Lake Formation**
1. Öffnen Sie die Seite mit den [Datenkatalogeinstellungen](https://console.aws.amazon.com/lakeformation/home#default-permission-settings) in der Lake Formation Formation-Konsole.
1. Deaktivieren Sie die IAM-Zugriffskontrollanforderungen für Datenbanken und Tabellen unter **Standardberechtigungen für neu erstellte Datenbanken und** Tabellen.
1. Wählen Sie **Speichern**.
HealthOmics Analytics akzeptiert auto Daten, wenn Ihre Servicerichtlinie über die richtigen RAM-Berechtigungen verfügt, wie im folgenden Beispiel.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"omics:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ram:AcceptResourceShareInvitation",
"ram:GetResourceShareInvitations"
],
"Resource": "*"
}
]
}
```
------
# Berechtigungen für den Datenzugriff mit Amazon S3 URIs
Sie können mithilfe von HealthOmics API-Operationen oder Amazon S3 S3-API-Vorgängen auf Sequenzspeicherdaten zugreifen.
Für den HealthOmics API-Zugriff werden die HealthOmics Berechtigungen über eine IAM-Richtlinie verwaltet. Für S3 Access sind jedoch zwei Konfigurationsebenen erforderlich: die ausdrückliche Genehmigung in der S3-Zugriffsrichtlinie des Stores und eine IAM-Richtlinie. Weitere Informationen zur Verwendung von IAM-Richtlinien mit HealthOmics finden Sie unter [Servicerollen](permissions-service.md) für. HealthOmics
Es gibt drei Möglichkeiten, die Fähigkeit, Objekte mit Amazon S3 zu lesen, gemeinsam zu nutzen APIs:
1. Richtlinienbasiertes Teilen — Für diese gemeinsame Nutzung muss der IAM-Prinzipal sowohl in der S3-Zugriffsrichtlinie aktiviert als auch eine IAM-Richtlinie geschrieben und an den IAM-Prinzipal angehängt werden. Weitere Informationen finden Sie im nächsten Thema.
1. Vorsigniert URLs — Sie können auch eine gemeinsam nutzbare vorsignierte URL für eine Datei im Sequenzspeicher generieren. Weitere Informationen zum Erstellen von Presigned URLs mit Amazon S3 finden Sie unter [Using presigned URLs](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html) in der Amazon S3 S3-Dokumentation. Die S3-Zugriffsrichtlinie für Sequence Store unterstützt Anweisungen zur [Einschränkung der Funktionen vorsignierter URLs](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html#PresignedUrlUploadObject-LimitCapabilities).
1. Angenommene Rollen — Erstellen Sie eine Rolle innerhalb des Kontos des Datenbesitzers, die über eine Zugriffsrichtlinie verfügt, die es Benutzern ermöglicht, diese Rolle anzunehmen.
**Topics**
+ [Auf Richtlinien basierendes Teilen](#policy-based-sharing)
+ [Beispiel für eine Einschränkung](#example-restriction)
## Auf Richtlinien basierendes Teilen
Wenn Sie über eine direkte S3-URI auf Sequenzspeicherdaten zugreifen, HealthOmics werden erweiterte Sicherheitsmaßnahmen für die zugehörige S3-Bucket-Zugriffsrichtlinie bereitgestellt.
Die folgenden Regeln gelten für neue S3-Zugriffsrichtlinien. Für bestehende Richtlinien gelten die Regeln, wenn Sie die Richtlinie das nächste Mal aktualisieren:
+ Die S3-Zugriffsrichtlinien unterstützen die folgenden [Richtlinienelemente](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)
+ Version, ID, Aussage, Sid, Wirkung, Prinzip, Aktion, Ressource, Zustand
+ Die S3-Zugriffsrichtlinien unterstützen die folgenden [Bedingungsschlüssel](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazons3.html#amazons3-policy-keys):
+ s3:ExistingObjectTag/, s3: prefix, s3: signatureversion, s3: TlsVersion
+ Richtlinien unterstützen auch aws: PrincipalArn mit den folgenden Bedingungsoperatoren: und ArnEquals ArnLike
Wenn Sie versuchen, eine Richtlinie hinzuzufügen oder zu aktualisieren, sodass sie ein Element oder eine Bedingung enthält, die nicht unterstützt wird, lehnt das System die Anfrage ab.
**Topics**
+ [Standardmäßige S3-Zugriffsrichtlinie](#default-access-policy)
+ [Anpassen der Zugriffsrichtlinie](#customize-access-policy)
+ [IAM-Richtlinie](#iam-policy)
+ [Tag-basierte Zugriffskontrolle](#tag-based-access)
### Standardmäßige S3-Zugriffsrichtlinie
Wenn Sie einen Sequenzspeicher erstellen, HealthOmics wird eine standardmäßige S3-Zugriffsrichtlinie erstellt, die dem Root-Konto des Datenspeicher-Besitzers die folgenden Berechtigungen für alle zugänglichen Objekte im Sequenzspeicher gewährt: S3: GetObjectGetObjectTagging, S3 und S3:ListBucket. Die erstellte Standardrichtlinie lautet:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":
[
{
"Effect": "Allow",
"Principal":
{
"AWS": "arn:aws:iam::111111111111:root"
},
"Action":
[
"s3:GetObject",
"s3:GetObjectTagging"
],
"Resource": "arn:aws:s3:us-west-2:222222222222:accesspoint/111111111111-1234567890/object/111111111111/sequenceStore/1234567890/*"
},
{
"Effect": "Allow",
"Principal":
{
"AWS": "arn:aws:iam::111111111111:root"
},
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:us-west-2:222222222222:accesspoint/111111111111-1234567890/111111111111/sequenceStore/1234567890/*"
}
]
}
```
------
### Anpassen der Zugriffsrichtlinie
Wenn die S3-Zugriffsrichtlinie leer ist, ist kein S3-Zugriff zulässig. Wenn es eine bestehende Richtlinie gibt und Sie den S3-Zugriff entfernen müssen, verwenden Sie diese Option, `deleteS3AccessPolicy` um den gesamten Zugriff zu entfernen.
Um Einschränkungen für das Teilen hinzuzufügen oder anderen Konten Zugriff zu gewähren, können Sie die Richtlinie mithilfe der `PutS3AccessPolicy` API aktualisieren. Aktualisierungen der Richtlinie dürfen nicht über das Präfix für den Sequenzspeicher oder die angegebenen Aktionen hinausgehen.
### IAM-Richtlinie
Um einem Benutzer oder IAM-Prinzipal mithilfe von Amazon S3 Zugriff zu gewähren APIs, muss zusätzlich zu den Berechtigungen in der S3-Zugriffsrichtlinie eine IAM-Richtlinie erstellt und an den Principal angehängt werden, um Zugriff zu gewähren. Eine Richtlinie, die den Zugriff auf die Amazon S3 S3-API ermöglicht, kann auf Sequenzspeicher-Ebene oder auf Leseset-Ebene angewendet werden. Auf der Read-Set-Ebene können die Berechtigungen entweder durch das Präfix oder mithilfe von Ressourcen-Tag-Filtern für Proben- oder Betreff-ID-Muster eingeschränkt werden.
Wenn der Sequenzspeicher einen vom Kunden verwalteten Schlüssel (CMK) verwendet, muss der Principal auch über die Rechte verfügen, den KMS-Schlüssel für die Entschlüsselung zu verwenden. Weitere Informationen finden Sie unter [Kontoübergreifender KMS-Zugriff im Entwicklerhandbuch](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html). AWS Key Management Service
Das folgende Beispiel gewährt einem Benutzer Zugriff auf einen Sequenzspeicher. Sie können den Zugriff mit zusätzlichen Bedingungen oder ressourcenbasierten Filtern verfeinern.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:root"
},
"Action":
[
"s3:GetObject",
"s3:GetObjectTagging"
],
"Resource": "arn:aws:s3:us-west-2:222222222222:accesspoint/111111111111-1234567890/object/111111111111/sequenceStore/1234567890/*",
"Condition": {
"StringEquals": {
"s3:ExistingObjectTag/omics:readSetStatus": "ACTIVE"
}
}
},
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:root"
},
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:us-west-2:222222222222:accesspoint/111111111111-1234567890",
"Condition": {
"StringLike": {
"s3:prefix": "111111111111/sequenceStore/1234567890/*"
}
}
}
]
}
```
------
### Tag-basierte Zugriffskontrolle
Um die tagbasierte Zugriffskontrolle verwenden zu können, muss der Sequenzspeicher zunächst aktualisiert werden, um die zu verwendenden Tagschlüssel weiterzugeben. Diese Konfiguration wird bei der Erstellung oder Aktualisierung des Sequenzspeichers festgelegt. Sobald die Tags weitergegeben wurden, können Tag-Bedingungen verwendet werden, um weitere Einschränkungen hinzuzufügen. Die Einschränkungen können in der S3-Zugriffsrichtlinie oder in der IAM-Richtlinie festgelegt werden. Im Folgenden finden Sie ein Beispiel für eine tabulatorbasierte S3-Zugriffsrichtlinie, die festgelegt werden würde:
```
{
"Sid": "tagRestrictedGets",
"Effect": "Allow",
"Principal":
{
"AWS": "arn:aws:iam:::root"
},
"Action":
[
"s3:GetObject",
"s3:GetObjectTagging"
],
"Resource": "arn:aws:s3:us-west-2:222222222222:accesspoint/111111111111-1234567890/object/111111111111/sequenceStore/1234567890/*",
"Condition":
{
"StringEquals":
{
"s3:ExistingObjectTag/tagKey1": "tagValue1",
"s3:ExistingObjectTag/tagKey2": "tagValue2"
}
}
}
```
## Beispiel für eine Einschränkung
Szenario: Erstellung einer Freigabe, bei der der Dateneigentümer die Möglichkeit eines Benutzers einschränken kann, „zurückgezogene“ Daten herunterzuladen.
In diesem Szenario verwaltete ein Datenbesitzer (Konto \$1111111111111) einen Datenspeicher. Dieser Dateneigentümer gibt die Daten an eine Vielzahl von Drittbenutzern weiter, darunter auch an einen Forscher (Konto \$1999999999999). Im Rahmen der Datenverwaltung erhält der Dateneigentümer regelmäßig Anfragen zum Widerruf der Daten eines Teilnehmers. Um diesen Widerruf zu verwalten, schränkt der Dateneigentümer bei Erhalt der Anfrage zunächst den direkten Download-Zugriff ein und löscht die Daten schließlich gemäß seinen Anforderungen.
Um diesem Bedarf gerecht zu werden, richtet der Dateneigentümer einen Sequenzspeicher ein und jeder Lesesatz erhält eine Markierung für „Status“, die auf „zurückgezogen“ gesetzt wird, wenn die Auszahlungsanforderung eingeht. Bei Daten, bei denen das Tag auf diesen Wert gesetzt ist, soll sichergestellt werden, dass kein Benutzer „GetObject“ für diese Datei ausführen kann. Um dieses Setup durchzuführen, muss der Dateneigentümer sicherstellen, dass zwei Schritte unternommen werden.
Schritt 1. Stellen Sie für den Sequenzspeicher sicher, dass das Status-Tag aktualisiert wird, damit es weitergegeben werden kann. Dies erfolgt durch Hinzufügen des Schlüssels „Status“ in die Befehlszeile `propogatedSetLevelTags` beim Aufrufen oder `createSequenceStore` `updateSequenceStore.`
Schritt 2. Aktualisieren Sie die S3-Zugriffsrichtlinie des Stores, um GetObject auf Objekte zu beschränken, deren Status-Tag auf „zurückgezogen“ gesetzt ist. Dies geschieht, indem die Zugriffsrichtlinie des Shops mithilfe der `PutS3AccesPolicy` API aktualisiert wird. Die folgende Richtlinie würde es Kunden ermöglichen, die zurückgezogenen Dateien weiterhin zu sehen, wenn sie Objekte anbieten, sie aber daran hindern, darauf zuzugreifen:
+ Aussage 1 (restrictedGetWithdrawal): Das Konto 999999999999 kann keine zurückgezogenen Objekte abrufen.
+ Aussage 2 (ownerGetAll): Konto 111111111111, der Datenbesitzer, kann alle Objekte abrufen, auch Objekte, die zurückgezogen wurden.
+ Aussage 3 (everyoneListAll): Alle gemeinsam genutzten Konten, 111111111111 und 999999999999, können den Vorgang für das gesamte Präfix ausführen. **ListBucket**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":
[
{
"Sid": "restrictedGetWithdrawal",
"Effect": "Allow",
"Principal":
{
"AWS": "arn:aws:iam::999999999999:root"
},
"Action":
[
"s3:GetObject",
"s3:GetObjectTagging"
],
"Resource": "arn:aws:s3:us-west-2:222222222222:accesspoint/111111111111-1234567890/object/111111111111/sequenceStore/1234567890/*",
"Condition":
{
"StringNotEquals":
{
"s3:ExistingObjectTag/status": "withdrawn"
}
}
},
{
"Sid": "ownerGetAll",
"Effect": "Allow",
"Principal":
{
"AWS": "arn:aws:iam::111111111111:root"
},
"Action":
[
"s3:GetObject",
"s3:GetObjectTagging"
],
"Resource": "arn:aws:s3:us-west-2:222222222222:accesspoint/111111111111-1234567890/object/111111111111/sequenceStore/1234567890/*",
"Condition":
{
"StringEquals":
{
"s3:ExistingObjectTag/omics:readSetStatus": "ACTIVE"
}
}
},
{
"Sid": "everyoneListAll",
"Effect": "Allow",
"Principal":
{
"AWS": [
"arn:aws:iam::111111111111:root",
"arn:aws:iam::999999999999:root"
]
},
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:us-west-2:222222222222:accesspoint/111111111111-1234567890",
"Condition":
{
"StringLike":
{
"s3:prefix": "111111111111/sequenceStore/1234567890/*"
}
}
}
]
}
```
------