Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Comportamientos de IAM para ML AWS Clean Rooms

Trabajos entre cuentas

Clean Rooms ML permite que otra Cuenta de AWS persona acceda de forma segura Cuenta de AWS a determinados recursos creados por una persona en su cuenta. Cuando un cliente de Cuenta de AWS A recurre StartAudienceGenerationJob a un ConfiguredAudienceModel recurso propiedad de Cuenta de AWS B, Clean Rooms ML crea dos ARNs para esa tarea. Un ARN en Cuenta de AWS A y otro en B. Cuenta de AWS ARNs Son idénticos excepto por sus. Cuenta de AWS

Clean Rooms ML crea dos ARNs para el trabajo a fin de garantizar que ambas cuentas puedan aplicar sus propias políticas de IAM a los trabajos. Por ejemplo, ambas cuentas pueden usar el control de acceso basado en etiquetas y aplicar las políticas de su AWS organización. El trabajo procesa los datos de ambas cuentas, de modo que ambas cuentas pueden eliminar el trabajo y sus datos asociados. Ninguna de las dos cuentas puede impedir que la otra elimine el trabajo.

Solo hay una ejecución de trabajo y ambas cuentas pueden ver la tarea cuando llaman a ListAudienceGenerationJobs. Ambas cuentas pueden llamar al GetDelete, y Export APIs estar trabajando usando el ARN con su propia Cuenta de AWS identificación.

Ninguno de los dos Cuenta de AWS puede acceder al trabajo cuando se utiliza un ARN con el otro Cuenta de AWS ID.

El nombre del trabajo debe ser único dentro de una Cuenta de AWS. El nombre en Cuenta de AWS B es$accountA-$name. El nombre elegido por Cuenta de AWS A lleva el prefijo Cuenta de AWS A cuando el trabajo se visualiza en B. Cuenta de AWS

Para que una cuenta cruzada StartAudienceGenerationJob tenga éxito, Cuenta de AWS B debe permitir esa acción tanto en el nuevo trabajo de B como ConfiguredAudienceModel en el de Cuenta de AWS Cuenta de AWS B mediante una política de recursos similar a la del siguiente ejemplo:

{
    "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"}}
        }
    ]
}

Si utilizas la API de AWS Clean Rooms ML para crear un modelo similar manageResourcePolicies configurado con el valor true, AWS Clean Rooms crea esta política automáticamente.

Además, la política de identidad de la persona que llama en Cuenta de AWS A necesita StartAudienceGenerationJob permiso. arn:aws:cleanrooms-ml:us-west-1:AccountA:audience-generation-job/* Por lo tanto, hay tres recursos de acción de IAMStartAudienceGenerationJob: el trabajo Cuenta de AWS A, el trabajo Cuenta de AWS B y el Cuenta de AWS trabajo B. ConfiguredAudienceModel

Etiquetado de trabajos

Al establecer el parámetro childResourceTagOnCreatePolicy=FROM_PARENT_RESOURCE de CreateConfiguredAudienceModel, todos los trabajos de generación de segmentos similares de su cuenta que se creen a partir de ese modelo similar configurado tendrán de forma predeterminada las mismas etiquetas que el modelo similar configurado. El modelo similar configurado es el principal y el trabajo de generación de segmentos similares es el secundario.

Si está creando un trabajo en su propia cuenta, las etiquetas de solicitud del trabajo anulan las etiquetas principales. Los trabajos creados por otras cuentas nunca crean etiquetas en su cuenta. Si establece childResourceTagOnCreatePolicy=FROM_PARENT_RESOURCE y otra cuenta crea un trabajo, hay dos copias del trabajo. La copia de su cuenta tiene las etiquetas del recurso principal y la copia de la cuenta del remitente del trabajo tiene las etiquetas de la solicitud.

Validación de colaboradores

Al conceder permisos a otros miembros de una AWS Clean Rooms colaboración, la política de recursos debe incluir la clave de condicióncleanrooms-ml:CollaborationId. Esto exige que el collaborationId parámetro esté incluido en la StartAudienceGenerationJobsolicitud. Cuando el parámetro collaborationId se incluye en la solicitud, Clean Rooms ML valida que la colaboración existe, que el remitente del trabajo es un miembro activo de la colaboración y que el propietario del modelo similar configurado es un miembro activo de la colaboración.

Cuando AWS Clean Rooms administre la política de recursos del modelo similar configurada (el manageResourcePolicies parámetro está TRUE en la CreateConfiguredAudienceModelAssociation solicitud), esta clave de condición se establecerá en la política de recursos. Por lo tanto, debe especificar la entradacollaborationId. StartAudienceGenerationJob

Acceso entre cuentas

Solo se puede llamar a StartAudienceGenerationJob entre cuentas. El resto de Clean Rooms ML solo se APIs pueden utilizar con los recursos de su propia cuenta. Esto garantiza que sus datos de entrenamiento, la configuración del modelo similar y otra información permanezcan privados.

Clean Rooms ML nunca revela Amazon S3 ni AWS Glue las ubicaciones de las cuentas. La ubicación de los datos de entrenamiento, la ubicación de salida del modelo similar configurado y la ubicación inicial del trabajo de generación de segmentos similar nunca están visibles entre cuentas. A menos que el registro de consultas esté habilitado en la colaboración, las cuentas no pueden ver si los datos iniciales provienen de una consulta SQL o la consulta en sí. Si Get un trabajo de generación de audiencia enviado por otra cuenta, el servicio no mostrará la ubicación inicial.