Control de acceso a DAX - Amazon DynamoDB

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.

Control de acceso a DAX

DynamoDB Accelerator (DAX) está diseñado para funcionar conjuntamente con DynamoDB, con el fin de agregar de forma transparente una capa de almacenamiento en caché a las aplicaciones. Sin embargo, DAX y DynamoDB tienen mecanismos distintos de control de acceso. Ambos servicios utilizan AWS Identity and Access Management (IAM) para implementar sus políticas de seguridad respectivas, pero los modelos de seguridad de DAX y DynamoDB son diferentes.

Recomendamos encarecidamente que conozca ambos modelos de seguridad para poder implementar las medidas de seguridad adecuadas en las aplicaciones que utilizan DAX.

En esta sección se describen los mecanismos de control de acceso proporcionados por DAX y se facilitan ejemplos de políticas de IAM que puede adaptar a sus necesidades.

Con DynamoDB, puede crear políticas de IAM que limiten las acciones que el usuario puede llevar a cabo con los recursos de DynamoDB individuales. Por ejemplo, puede crear un rol de usuario que únicamente permita al usuario realizar acciones de solo lectura en una tabla de DynamoDB determinada. (Para obtener más información, consulte Identity and Access Management en Amazon DynamoDB). En comparación, el modelo de seguridad de DAX se centra en la seguridad del clúster y en la capacidad de éste para llevar a cabo las acciones de la API de DynamoDB en su nombre.

aviso

Si está utilizando los roles y las políticas de IAM para restringir el acceso a los datos de las tablas de DynamoDB, el uso de DAX puede alterar esas políticas. Por ejemplo, un usuario podría tener acceso a una tabla de DynamoDB mediante DAX aunque no tuviese acceso explícito a ella si el acceso se llevase a cabo directamente a través de DynamoDB. Para obtener más información, consulte Identity and Access Management en Amazon DynamoDB.

DAX no aplica la separación de nivel de usuario de los datos en DynamoDB. En lugar de ello, los usuarios heredan los permisos de la política de IAM del clúster de DAX cuando obtienen acceso a ese clúster. Por lo tanto, al obtener acceso a las tablas de DynamoDB a través de DAX, los únicos controles de acceso que surten efecto son los permisos de la política de IAM del clúster de DAX. No se reconoce ningún otro permiso.

Si requiere aislamiento, recomendamos crear clústeres de DAX adicionales y que defina en consecuencia el alcance la política IAM para cada clúster. Por ejemplo, podría crear varios clústeres de DAX y permitir que cada uno de ellos obtenga acceso a una sola tabla.

Rol de servicio de IAM para DAX

Al crear un clúster de DAX, es preciso asociarlo con un rol de IAM. Esto es lo que se denomina rol de servicio del clúster.

Supongamos que desea crear un nuevo clúster de DAX denominado DAXCluster01. Puede crear un rol de servicio denominado DAX y asociarlo a ServiceRole DAXcluster01. La política de DAX ServiceRole definiría las acciones de DynamoDB que DAXcluster01 podría realizar en nombre de los usuarios que interactúan con DAXcluster01.

Al crear un rol de servicio, debe especificar una relación de confianza entre DAX y el propio servicio de DAX. ServiceRole Una relación de confianza determina qué entidades pueden asumir un rol y utilizar sus permisos. El siguiente es un ejemplo de documento de relación de confianza para DAX: ServiceRole

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "dax.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }

Esta relación de confianza permite a un clúster de DAX asumir el DAX ServiceRole y realizar llamadas a la API de DynamoDB en su nombre.

Las acciones de la API de DynamoDB que están permitidas se describen en un documento de política de IAM que se adjunta al DAX. ServiceRole A continuación se muestra el ejemplo de documento de política.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "DaxAccessPolicy", "Effect": "Allow", "Action": [ "dynamodb:DescribeTable", "dynamodb:PutItem", "dynamodb:GetItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:BatchGetItem", "dynamodb:BatchWriteItem", "dynamodb:ConditionCheckItem" ], "Resource": [ "arn:aws:dynamodb:us-west-2:123456789012:table/Books" ] } ] }

Esta política permite a DAX realizar todas las acciones de la API de DynamoDB necesarias en una tabla de DynamoDB. La acción dynamodb:DescribeTable es necesaria para que DAX mantenga metadatos sobre la tabla, y las demás son acciones de lectura y escritura realizadas en los elementos de la tabla. La tabla, denominada Books, está en la región us-west-2 y es propiedad del ID de cuenta de AWS 123456789012.

nota

El DAX admite mecanismos para evitar el confuso problema de los adjuntos durante el acceso entre servicios. Para obtener más información, consulte El problema del suplente confuso en la Guía del usuario de IAM.

Política de IAM que permite el acceso a un clúster de DAX

Después de crear un clúster de DAX, es preciso conceder permisos a un usuario, para que este pueda obtener acceso al clúster de DAX.

Por ejemplo, supongamos que desea conceder acceso a DAXCluster01 a una usuaria cuyo nombre es Alice. Primero debe crear una política de IAM (AliceAccessPolicy) que defina los clústeres de DAX y las acciones de la API de DAX a las que puede acceder el destinatario. Posteriormente, le concedería acceso adjuntando esta política a la usuaria Alice.

El siguiente documento de política concede acceso pleno al destinatario en DAXCluster01.

{ "Version": "2012-10-17", "Statement": [ { "Action": [ "dax:*" ], "Effect": "Allow", "Resource": [ "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01" ] } ] }

El documento de política permite acceder al clúster de DAX, pero no concede ningún permiso de DynamoDB. (Los permisos de DynamoDB los concede la función del servicio de DAX).

Para la usuaria Alice, primero habría que crear AliceAccessPolicy con el documento de política que se muestra más arriba. Posteriormente, se adjuntaría la política a Alice.

nota

En lugar de adjuntar la política a un usuario, podría adjuntarla a un rol de IAM. De ese modo, todos los usuarios que asuman ese rol tendrían los permisos definidos en la política.

La política de usuario, junto con la función del servicio de DAX, determinan los recursos de DynamoDB y las acciones de la API a los que el destinatario puede obtener acceso a través de DAX.

Caso práctico: acceso a DynamoDB y DAX

El siguiente escenario puede ayudarle a entender mejor sobre las políticas de IAM para usarlas con DAX. (Durante el resto de esta sección haremos referencia a este escenario). En el siguiente diagrama se muestra información general sobre el escenario.

En este escenario, existen las siguientes entidades:

  • Un usuario (Bob).

  • Un rol de IAM (BobUserRole). Bob asume este rol en tiempo de ejecución.

  • Una política de IAM (BobAccessPolicy). Esta política se asocia a BobUserRole. BobAccessPolicy define los recursos de DynamoDB y DAX a los que BobUserRole está autorizado a acceder.

  • Un clúster DAX (DAXCluster01).

  • Una función del servicio de IAM (DAXServiceRole). Este rol le permite a DAXCluster01 acceder a DynamoDB.

  • Una política de IAM (DAXAccessPolicy). Esta política se asocia a DAXServiceRole. DAXAccessPolicy define los recursos y las API de DynamoDB a los que DAXCluster01 está autorizado a acceder.

  • Una tabla de DynamoDB (Books).

La combinación de instrucciones de política en BobAccessPolicy y DAXAccessPolicy determina lo que Bob puede hacer con la tabla Books. Por ejemplo, Bob podría acceder a Books directamente (a través del punto de enlace de DynamoDB), indirectamente (mediante el clúster de DAX) o de las dos maneras. Además, Bob podría ser capaz de leer datos de Books, de escribir datos en Books o de ambas cosas.

Acceso a DynamoDB, pero no con DAX

Es posible permitir el acceso directo a una tabla de DynamoDB, pero impedir el acceso indirecto a través de un clúster de DAX. Para el acceso directo a DynamoDB, los permisos para BobUserRole están determinados por la BobAccessPolicy (que se asocia al rol).

Acceso de solo lectura a DynamoDB (solamente)

Bob puede acceder a DynamoDB con BobUserRole. La política de IAM asociada a este rol (BobAccessPolicy) determina las tablas de DynamoDB a las que BobUserRole puede acceder y a las API que BobUserRole puede invocar.

Supongamos que vamos a usar el documento de política siguiente para BobAccessPolicy.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] }

Cuando este documento se asocie a BobAccessPolicy, permitirá que BobUserRole obtenga acceso al punto de enlace de DynamoDB y lleve a cabo operaciones de solo lectura en la tabla Books.

DAX no aparece en esta política, por lo que acceder a través de DAX está denegado.

Acceso de lectura y escritura a DynamoDB (solamente)

Si BobUserRole requiere acceso de lectura y escritura a DynamoDB, la siguiente política lo permitiría:

{ "Version": "2012-10-17", "Statement": [ { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem", "dynamodb:ConditionCheckItem" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] }

Tampoco en este caso aparece DAX en la política, por lo que el acceso a través de DAX está denegado.

Acceder a DynamoDB y DAX

Para permitir el acceso a un clúster de DAX, debe incluir las acciones específicas de DAX en una política de IAM.

Las siguientes acciones específicas de DAX se corresponden con sus homólogas de nombres parecidos de la API de DynamoDB:

  • dax:GetItem

  • dax:BatchGetItem

  • dax:Query

  • dax:Scan

  • dax:PutItem

  • dax:UpdateItem

  • dax:DeleteItem

  • dax:BatchWriteItem

  • dax:ConditionCheckItem

Lo mismo sucede para la clave de condición dax:EnclosingOperation.

Acceso de solo lectura a DynamoDB y acceso de solo lectura a DAX

Supongamos que Bob requiere acceso de solo lectura a la tabla Books tanto desde DynamoDB como desde DAX. La siguiente política (asociada a BobUserRole) concedería este acceso:

{ "Version": "2012-10-17", "Statement": [ { "Sid": "DAXAccessStmt", "Effect": "Allow", "Action": [ "dax:GetItem", "dax:BatchGetItem", "dax:Query", "dax:Scan" ], "Resource": "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01" }, { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] }

La política contiene una instrucción para el acceso a DAX (DAXAccessStmt) y otra para el acceso a DynamoDB (DynamoDBAccessStmt). Estas instrucciones permitirían que Bob envíe solicitudes GetItemBatchGetItemQueryScan a DAXCluster01.

Sin embargo, la función del servicio de DAXCluster01 también requeriría acceso de solo lectura a la tabla Books en DynamoDB. La siguiente política de IAM, asociada a DAXServiceRole, permitiría cumplir este requisito:

{ "Version": "2012-10-17", "Statement": [ { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] }

Acceso de lectura y escritura a DynamoDB y acceso de solo lectura con DAX

Para un rol de usuario determinado, puede proporcionar acceso de lectura y escritura a una tabla de DynamoDB y también permitir el acceso de solo lectura a través de DAX.

En el caso de Bob, la política de IAM para BobUserRole tendría que permitir las acciones de lectura y escritura de DynamoDB en la tabla Books y, además, admitir las acciones de solo lectura a través de DAXCluster01.

El siguiente ejemplo de documento de política para BobUserRole concedería este acceso:

{ "Version": "2012-10-17", "Statement": [ { "Sid": "DAXAccessStmt", "Effect": "Allow", "Action": [ "dax:GetItem", "dax:BatchGetItem", "dax:Query", "dax:Scan" ], "Resource": "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01" }, { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem", "dynamodb:DescribeTable", "dynamodb:ConditionCheckItem" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] }

Además, DAXServiceRole requeriría una política de IAM que permitiese que DAXCluster01 realizase acciones de solo lectura en la tabla Books.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:DescribeTable" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] }

Acceso de lectura y escritura a DynamoDB y acceso de lectura y escritura a DAX

Ahora, supongamos que Bob requiere acceso de lectura y escritura a la tabla Books, ya sea directamente desde DynamoDB o indirectamente desde DAXCluster01. La siguiente política, asociada a BobAccessPolicy, concedería este acceso:

{ "Version": "2012-10-17", "Statement": [ { "Sid": "DAXAccessStmt", "Effect": "Allow", "Action": [ "dax:GetItem", "dax:BatchGetItem", "dax:Query", "dax:Scan", "dax:PutItem", "dax:UpdateItem", "dax:DeleteItem", "dax:BatchWriteItem", "dax:ConditionCheckItem" ], "Resource": "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01" }, { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem", "dynamodb:DescribeTable", "dynamodb:ConditionCheckItem" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] }

Además, DAXServiceRole requeriría una política de IAM que permitiese que DAXCluster01 realizase acciones de lectura y escritura en la tabla Books.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem", "dynamodb:DescribeTable" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] }

Acceso a DynamoDB a través de DAX, pero sin acceso directo a DynamoDB

En este caso, Bob puede obtener acceso a la tabla Books a través de DAX, pero no tiene acceso directo a la tabla Books en DynamoDB. Por lo tanto, cuando Bob recibe acceso a DAX, también recibe acceso a una tabla de DynamoDB a la que, de otro modo, no podría obtener acceso. Al configurar una política de IAM para la función del servicio de DAX, recuerde que cualquier usuario a quien se conceda acceso al clúster de DAX mediante la política de acceso de usuario recibe también acceso a las tablas especificadas en esa política. En este caso, BobAccessPolicy obtiene acceso a las tablas especificadas en DAXAccessPolicy.

Si está utilizando los roles y las políticas de IAM para restringir el acceso a los datos y las tablas de DynamoDB, el uso de DAX puede alterar las políticas. En la política siguiente, Bob tiene acceso a una tabla de DynamoDB a través de DAX, aunque no tiene acceso explícito directo a esa misma tabla en DynamoDB.

El siguiente documento de política (BobAccessPolicy), asociado a BobUserRole, concedería este acceso:

{ "Version": "2012-10-17", "Statement": [ { "Sid": "DAXAccessStmt", "Effect": "Allow", "Action": [ "dax:GetItem", "dax:BatchGetItem", "dax:Query", "dax:Scan", "dax:PutItem", "dax:UpdateItem", "dax:DeleteItem", "dax:BatchWriteItem", "dax:ConditionCheckItem" ], "Resource": "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01" } ] }

En esta política de acceso, no hay permisos para obtener acceso a DynamoDB directamente.

Junto con BobAccessPolicy, la siguiente DAXAccessPolicy concede acceso a BobUserRole a la tabla Books de DynamoDB incluso si BobUserRole no puede acceder directamente a la tabla Books.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem", "dynamodb:DescribeTable", "dynamodb:ConditionCheckItem" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] }

Como se muestra en este ejemplo, al configurar el control de acceso para la política de acceso de los usuarios y la política de acceso a los clústeres del DAX, debe comprender perfectamente el end-to-end acceso para asegurarse de que se respeta el principio del mínimo privilegio. Además, debe asegurarse de que, al conceder a un usuario acceso a un clúster de DAX, no se alteren las políticas de control de acceso establecidas previamente.