# 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. Aunque ambos servicios utilizan AWS Identity and Access Management (IAM) para implementar sus respectivas políticas de seguridad, los modelos de seguridad de DAX y DynamoDB son distintos. *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](security-iam.md).) 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](security-iam.md). 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*. Podría crear un rol de servicio denominado *DAXServiceRole* y asociarlo con *DAXCluster01*. La política para *DAXServiceRole* definiría las acciones de DynamoDB que *DAXCluster01* podría llevar a cabo en nombre de los usuarios que interaccionen con *DAXCluster01*. Cuando se crea un rol de servicio, es preciso especificar una relación de confianza entre *DAXServiceRole* y el servicio DAX propiamente dicho. Una relación de confianza determina qué entidades pueden asumir un rol y utilizar sus permisos. A continuación se muestra un ejemplo de documento de relación de confianza para *DAXServiceRole*: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "dax.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ------ Esta relación de confianza permite que un clúster de DAX asuma *DAXServiceRole* y lleve a cabo llamadas al API de DynamoDB en su nombre. Las acciones de la API de DynamoDB permitidas se describen en un documento de la política de IAM que se adjunta a *DAXServiceRole*. A continuación se muestra el ejemplo de documento de política. ------ #### [ JSON ] **** ``` { "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** DAX apoya los mecanismos para evitar el problema del suplente confuso durante el acceso entre servicios. Para obtener más información, consulte [El problema del suplente confuso](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) 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. En primer lugar, crearía la política de IAM (*AliceAccessPolicy*) que define los clústeres de DAX y las acciones del API de DAX a los que el destinatario puede obtener acceso. 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*. ------ #### [ JSON ] **** ``` { "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. ![\[Visión general de alto nivel de un escenario de una política de IAM para utilizar DAX.\]](http://docs.aws.amazon.com/es_es/amazondynamodb/latest/developerguide/images/dax-access-control-scenario.png) 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 ![\[Visión general de una política de IAM que permite el acceso directo a una tabla, pero bloquea el acceso indirecto mediante un cluster de DAX.\]](http://docs.aws.amazon.com/es_es/amazondynamodb/latest/developerguide/images/dax-access-control-ddb-only.png) 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`. ------ #### [ JSON ] **** ``` { "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: ------ #### [ JSON ] **** ``` { "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 ![\[Una política de IAM que concede acceso tanto a una tabla de DynamoDB como a un clúster de DAX.\]](http://docs.aws.amazon.com/es_es/amazondynamodb/latest/developerguide/images/dax-access-control-ddb-and-dax.png) 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: ------ #### [ JSON ] **** ``` { "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 `GetItem`, `BatchGetItem`, `Query` y `Scan` 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: ------ #### [ JSON ] **** ``` { "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: ------ #### [ JSON ] **** ``` { "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`. ------ #### [ JSON ] **** ``` { "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: ------ #### [ JSON ] **** ``` { "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`. ------ #### [ JSON ] **** ``` { "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`. ![\[Un escenario en el que un usuario puede acceder a una tabla a través de un clúster de DAX sin acceso directo a DynamoDB.\]](http://docs.aws.amazon.com/es_es/amazondynamodb/latest/developerguide/images/dax-access-control-dax-only.png) 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: ------ #### [ JSON ] **** ``` { "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`. ------ #### [ JSON ] **** ``` { "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, cuando se configura el control de acceso para la política de acceso de usuario y la política de acceso de clúster de DAX, es preciso comprender perfectamente todos los permisos de acceso que se conceden, con el fin de asegurarse de cumplir el principio de mínimos privilegios. 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.