IAMVerhaltensweisen für AWS Clean Rooms ML - AWS Clean Rooms

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.

IAMVerhaltensweisen für AWS Clean Rooms ML

Kontoübergreifende Jobs

Clean Rooms ML erlaubt bestimmte Ressourcen, die von einem erstellt werden AWS-Konto damit ein anderer in seinem Konto sicher darauf zugreifen kann AWS-Konto. Wenn ein Kunde in AWS-Konto A ruft eine ConfiguredAudienceModel Ressource StartAudienceGenerationJob auf, die gehört AWS-Konto B, Clean Rooms ML erstellt zwei ARNs für den Job. Eins ARN in AWS-Konto A und noch eins rein AWS-Konto B. Sie ARNs sind identisch bis auf ihre AWS-Konto.

Clean Rooms ML erstellt zwei ARNs für den Job, um sicherzustellen, dass beide Accounts ihre eigenen IAM Richtlinien auf die Jobs anwenden können. Zum Beispiel können beide Konten die Tag-basierte Zugriffskontrolle nutzen und Richtlinien aus ihren eigenen Konten anwenden AWS Organisation. Der Job verarbeitet Daten aus beiden Konten, sodass beide Konten den Job und die zugehörigen Daten löschen können. Keines der Konten kann das andere Konto daran hindern, den Job zu löschen.

Es gibt nur eine Auftragsausführung und beide Konten können den Job sehen, wenn sie aufrufenListAudienceGenerationJobs. Beide Konten können das GetDelete, und Export APIs für den Job aufrufen, indem sie das ARN mit ihren eigenen verwenden AWS-Konto ID.

Keiner von beiden AWS-Konto kann auf den Job zugreifen, wenn er ARN zusammen mit dem anderen verwendet wird AWS-Konto ID.

Der Name des Jobs muss innerhalb eines eindeutig sein AWS-Konto. Der Name in AWS-Konto B ist $accountA-$name. Der Name wurde gewählt von AWS-Konto A hat das Präfix AWS-Konto A, wenn der Job in angesehen wird AWS-Konto B.

Damit ein Cross-Account-Betrieb erfolgreich StartAudienceGenerationJob ist, AWS-Konto B muss diese Maßnahme sowohl für den neuen Job als auch für AWS-Konto B und dann ConfiguredAudienceModel rein AWS-Konto B verwendet eine Ressourcenrichtlinie, die dem folgenden Beispiel ähnelt:

{ "Version": "2012-10-17", "Statement": [ { "Sid": "Clean-Rooms-<CAMA ID>", "Effect": "Allow", "Principal": { "AWS": [ "accountA" ] }, "Action": [ "cleanrooms-ml:StartAudienceGenerationJob" ], "Resource": [ "arn:aws:cleanrooms-ml:us-west-1:AccountB:configured-audience-model/id", "arn:aws:cleanrooms-ml:us-west-1:AccountB:audience-generation-job/*" ], // optional - always set by AWS Clean Rooms "Condition":{"StringEquals":{"cleanrooms-ml:CollaborationId":"UUID"}} } ] }

Wenn Sie die verwenden AWS Clean Rooms ML API, um ein konfiguriertes Lookalike-Modell zu erstellen, das auf true manageResourcePolicies gesetzt ist, AWS Clean Rooms erstellt diese Richtlinie für Sie.

Zusätzlich die Identitätsrichtlinie des Anrufers AWS-Konto A benötigt eine StartAudienceGenerationJob Genehmigung für. arn:aws:cleanrooms-ml:us-west-1:AccountA:audience-generation-job/* Es gibt also drei IAM AktionsressourcenStartAudienceGenerationJob: die AWS-Konto Ein Job, der AWS-Konto B Job, und der AWS-Konto ConfiguredAudienceModelB.

Warnung

Das Tool AWS-Konto der den Job gestartet hat, erhält eine AWS CloudTrail Auditprotokollereignis über den Job. Das Tool AWS-Konto der ConfiguredAudienceModel besitzt, erhält keine AWS CloudTrail Ereignis im Audit-Protokoll.

Jobs taggen

Wenn Sie den childResourceTagOnCreatePolicy=FROM_PARENT_RESOURCE Parameter von festlegenCreateConfiguredAudienceModel, haben alle Jobs zur Generierung von Lookalike-Segmenten in Ihrem Konto, die anhand dieses konfigurierten Lookalike-Modells erstellt wurden, standardmäßig dieselben Tags wie das konfigurierte Lookalike-Modell. Das konfigurierte Lookalike-Modell ist das übergeordnete Modell und der Job zur Generierung von Lookalike-Segmenten ist das untergeordnete Modell.

Wenn Sie einen Job in Ihrem eigenen Konto erstellen, haben die Anforderungs-Tags des Jobs Vorrang vor den übergeordneten Tags. Jobs, die von anderen Konten erstellt wurden, erzeugen niemals Stichwörter in Ihrem Konto. Wenn Sie einen Job einrichten childResourceTagOnCreatePolicy=FROM_PARENT_RESOURCE und ein anderer Account erstellt, gibt es zwei Kopien des Jobs. Die Kopie in Ihrem Konto enthält die übergeordneten Ressourcen-Tags und die Kopie im Konto des Jobeinreichers enthält Stichwörter aus der Anfrage.

Mitarbeiter werden validiert

Bei der Erteilung von Berechtigungen an andere Mitglieder eines AWS Clean Rooms Bei der Zusammenarbeit sollte die Ressourcenrichtlinie den Bedingungsschlüssel enthaltencleanrooms-ml:CollaborationId. Dadurch wird erzwungen, dass der collaborationId Parameter in der StartAudienceGenerationJobAnfrage enthalten ist. Wenn der collaborationId Parameter in der Anfrage enthalten ist, überprüft Clean Rooms ML, ob die Kollaboration existiert, dass der Jobeinreicher ein aktives Mitglied der Kollaboration ist und der Besitzer des konfigurierten Lookalike-Modells ein aktives Mitglied der Kollaboration ist.

Wann AWS Clean Rooms verwaltet Ihre konfigurierte Ressourcenrichtlinie für das Lookalike-Modell (der manageResourcePolicies Parameter ist CreateConfiguredAudienceModelAssociation auf Anfrage). Dieser Bedingungsschlüssel wird TRUE in der Ressourcenrichtlinie festgelegt. Daher müssen Sie den collaborationId in StartAudienceGenerationJobangeben.

Kontoübergreifender Zugriff

StartAudienceGenerationJobKann nur kontenübergreifend aufgerufen werden. Alle anderen Clean Rooms ML APIs können nur mit Ressourcen in Ihrem eigenen Konto verwendet werden. Dadurch wird sichergestellt, dass Ihre Trainingsdaten, die Konfiguration eines Lookalike-Modells und andere Informationen vertraulich bleiben.

Clean Rooms ML enthüllt niemals Amazon S3 oder AWS Glue Standorte auf allen Konten. Der Speicherort der Trainingsdaten, der konfigurierte Speicherort für die Ausgabe eines Lookalike-Modells und die Position der Startdaten für die Erstellung von Lookalike-Segmenten sind nicht für alle Konten sichtbar. Sofern die Abfrageprotokollierung in der Kollaboration nicht aktiviert ist, ist es nicht kontenübergreifend sichtbar, ob die Ausgangsdaten aus einer SQL Abfrage stammen, und die Abfrage selbst. Wenn es sich Get um einen Job zur Zielgruppengenerierung handelt, der von einem anderen Account eingereicht wurde, zeigt der Service den Ausgangsort nicht an.