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 Get
Delete
, 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 ConfiguredAudienceModel
B.
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
StartAudienceGenerationJob
Kann 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.