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

Mit Clean Rooms ML können bestimmte Ressourcen, die von einer Person erstellt wurden AWS-Konto , von einer anderen AWS-Konto Person sicher in ihrem Konto abgerufen werden. Wenn ein Kunde in AWS-Konto A eine ConfiguredAudienceModel Ressource StartAudienceGenerationJob anruft, die AWS-Konto B gehört, erstellt Clean Rooms ML zwei Ressourcen ARNs für den Job. Eine ARN in AWS-Konto A und eine weitere in AWS-Konto B. Sie ARNs sind bis auf ihre identisch AWS-Konto.

Clean Rooms ML erstellt zwei ARNs für den Auftrag, um sicherzustellen, dass beide Konten ihre eigenen IAM Richtlinien auf die Jobs anwenden können. Beispielsweise können beide Konten eine tagbasierte Zugriffskontrolle verwenden und Richtlinien ihrer AWS Organisation anwenden. Der Job verarbeitet Daten von 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 den GetDelete, und für Export APIs den Job aufrufen und ARN dabei ihre eigene AWS-Konto ID verwenden.

Keiner AWS-Konto kann auf den Job zugreifen, wenn er ARN mit der anderen AWS-Konto ID verwendet wird.

Der Name des Jobs muss innerhalb eines eindeutig sein AWS-Konto. Der Name in AWS-Konto B ist $accountA-$name. Dem von AWS-Konto A ausgewählten Namen wird A vorangestellt, wenn der Job in AWS-Konto B angezeigt wird. AWS-Konto

Damit ein Cross-Account StartAudienceGenerationJob erfolgreich ist, muss AWS-Konto B diese Aktion sowohl für den neuen Job in B als auch für den Job in AWS-Konto B zulassen. Dabei ConfiguredAudienceModel muss eine Ressourcenrichtlinie verwendet werden, die dem folgenden Beispiel ähnelt: AWS-Konto

{
    "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 AWS Clean Rooms ML verwendenAPI, um ein konfiguriertes Lookalike-Modell mit dem Wert manageResourcePolicies true zu erstellen, AWS Clean Rooms erstellt diese Richtlinie für Sie.

Darüber hinaus benötigt die Identitätsrichtlinie des Anrufers in AWS-Konto A eine StartAudienceGenerationJob entsprechende Genehmigung. arn:aws:cleanrooms-ml:us-west-1:AccountA:audience-generation-job/* Es gibt also drei IAM AktionsressourcenStartAudienceGenerationJob: den AWS-Konto A-Job, den AWS-Konto B-Job und den AWS-Konto ConfiguredAudienceModel B-Job.

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

Wenn Sie anderen Mitgliedern einer AWS Clean Rooms Kollaboration Berechtigungen gewähren, sollte die Ressourcenrichtlinie den Bedingungsschlüssel enthalten. cleanrooms-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.

Wenn Ihre konfigurierte Ressourcenrichtlinie für das Lookalike-Modell AWS Clean Rooms verwaltet wird (der manageResourcePolicies Parameter ist CreateConfiguredAudienceModelAssociation angefordert), wird dieser Bedingungsschlüssel 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 gibt niemals Amazon S3 oder AWS Glue Standorte für mehrere Konten preis. Der Speicherort der Trainingsdaten, der konfigurierte Speicherort für die Ausgabe eines Lookalike-Modells und der Standort der Jobstartdaten für die Lookalike-Segmentgenerierung 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.