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.
Acceso a la base de datos mediante el control de acceso basado en roles
Puede restringir el acceso a las acciones que los usuarios pueden realizar en las bases de datos mediante el control de acceso basado en roles (RBAC) en Amazon DocumentDB (compatible con MongoDB). RBACfunciona mediante la concesión de uno o más roles a un usuario. Estos roles determinan las operaciones que un usuario puede realizar en los recursos de la base de datos. Actualmente, Amazon DocumentDB admite tanto roles integrados que se centran en el nivel de base de datos, como read
, readWrite
, readAnyDatabase
, clusterAdmin
, y roles definidos por el usuario que se pueden limitar a acciones específicas y recursos granulares, como colecciones, en función de sus requisitos.
Los casos de uso más comunes RBAC incluyen la aplicación de privilegios mínimos mediante la creación de usuarios con acceso de solo lectura a las bases de datos o colecciones de un clúster, y los diseños de aplicaciones multiusuario que permiten a un solo usuario acceder a una base de datos o colección determinada de un clúster.
nota
Todos los nuevos usuarios creados antes del 26 de marzo de 2020 han recibido los roles dbAdminAnyDatabase
, readWriteAnyDatabase
, y clusterAdmin
. Se recomienda volver a evaluar todos los usuarios existentes y modificar los roles según sea necesario para aplicar los privilegios mínimos para los clústeres.
Temas
RBACconceptos
Los siguientes son términos y conceptos importantes relacionados con el control de acceso basado en roles. Para obtener más información sobre los usuarios de Amazon DocumentDB, consulteAdministración de usuarios de Amazon DocumentDB.
-
Usuario: entidad individual que puede autenticarse en la base de datos y realizar operaciones.
-
Contraseña: secreto que se utiliza para autenticar al usuario.
-
Rol: autoriza a un usuario a realizar acciones en una o más bases de datos.
-
Base de datos de administración: la base de datos en la que se almacenan los usuarios y en la que se autoriza su uso.
-
Base de datos (
db
): el espacio de nombres dentro de los clústeres que contiene colecciones para almacenar documentos.
El comando siguiente crea un usuario llamado sample-user
.
db.createUser({user: "sample-user", pwd: "abc123", roles: [{role: "read", db: "sample-database"}]})
En este ejemplo:
-
user: "sample-user"
: indica el nombre de usuario. -
pwd: "abc123"
: indica la contraseña del usuario. -
role: "read", "db: "sample-database"
: indica que elsample-user
de usuario tendrá permisos de lectura ensample-database
.
![Ejemplo de código que muestra un createUser comando que indica el nombre de usuario, la contraseña y los permisos.](images/rbac-createuser-command.png)
El siguiente ejemplo muestra el resultado después de obtener el usuario sample-user
con db.getUser(sample-user)
. En este ejemplo, el usuario sample-user
reside en la base de datos del admin
pero tiene el rol de lectura para la base de datos sample-database
.
![Ejemplo de salida de código que muestra el resultado del createUser comando que define el nuevo ID de usuario, la base de datos de administración a la que está asignado el nuevo usuario y los permisos de rol aplicados al usuario.](images/rbac-createuser-output-json.png)
Al crear usuarios, si omite el campo db
al especificar el rol, Amazon DocumentDB atribuirá implícitamente el rol a la base de datos en la que se está emitiendo la conexión. Por ejemplo, si la conexión se emite contra la base de datos sample-database
y ejecuta el siguiente comando, el usuario sample-user
se creará en la base de datos del admin
y tendrá permisos readWrite
para la base de datos sample-database
.
db.createUser({user: "sample-user", pwd: "abc123", roles: ["readWrite"]})
La salida de esta operación será similar a lo que se indica a continuación.
{
"user":"sample-user",
"roles":[
{
"db":"sample-database",
"role":"readWrite"
}
]
}
La creación de usuarios con roles cuyo ámbito se encuentra en todas las bases de datos (por ejemplo, readAnyDatabase
) requiere que esté en el contexto de la base de datos de admin
al crear el usuario o que indique explícitamente la base de datos para el rol al crear el usuario. Para emitir comandos contra la base de datos del admin
, puede utilizar el comando use admin
. Para obtener más información, consulte Comandos comunes.
Cómo empezar con las funciones RBAC integradas
Para ayudarle a comenzar con el control de acceso basado en roles, esta sección le guía a través de un escenario de ejemplo de aplicación de privilegios mínimos mediante la creación de roles para tres usuarios con funciones de trabajo diferentes.
-
user1
es un nuevo administrador que necesita poder ver y acceder a todas las bases de datos de un clúster. -
user2
es un nuevo empleado que necesita acceso a una sola base de datos,sample-database-1
, en ese mismo clúster. -
user3
es un empleado existente que necesita ver y tener acceso a una base de datos diferente,sample-database-2
, a la que no tenían acceso antes, en el mismo clúster.
En un momento posterior, tanto user1
como user2
abandonan la empresa y por lo tanto su acceso debe ser revocado.
Para crear usuarios y otorgar roles, el usuario con el que se autentique en el clúster debe tener un rol asociado que pueda realizar acciones para createUser
y grantRole
. Por ejemplo, los roles admin
y userAdminAnyDatabase
pueden otorgar tales habilidades, por ejemplo. Para ver las acciones por rol, consulte Acceso a la base de datos mediante el control de acceso basado en roles.
nota
En Amazon DocumentDB, todas las operaciones de usuario y rol (por ejemplo, create
, get
, drop
, grant
, revoke
, etc.) se realizan implícitamente en la base de datos de admin
, independientemente de que se estén ejecutando o no comandos contra la base de datos admin
.
En primer lugar, para comprender cuáles son los usuarios y roles actuales en el clúster, puede ejecutar el comando show users
, como en el ejemplo siguiente. Verá dos usuarios serviceadmin
y el usuario principal del clúster. Estos dos usuarios siempre existen y no se pueden eliminar. Para obtener más información, consulte Administración de usuarios de Amazon DocumentDB.
show users
Para user1
, cree un rol con acceso de lectura y escritura a todas las bases de datos de todo el clúster con el siguiente comando.
db.createUser({user: "user1", pwd: "abc123", roles: [{role: "readWriteAnyDatabase", db: "admin"}]})
La salida de esta operación será similar a lo que se indica a continuación.
{
"user":"user1",
"roles":[
{
"role":"readWriteAnyDatabase",
"db":"admin"
}
]
}
Para user2
, cree un rol con acceso de sólo lectura a la base de datos sample-database-1
con el siguiente comando.
db.createUser({user: "user2", pwd: "abc123", roles: [{role: "read", db: "sample-database-1"}]})
La salida de esta operación será similar a lo que se indica a continuación.
{
"user":"user2",
"roles":[
{
"role":"read",
"db":"sample-database-1"
}
]
}
Para simular el escenario en que user3
es un usuario existente, primero cree el usuario user3
y a continuación asigne un nuevo rol a user3
.
db.createUser({user: "user3", pwd: "abc123", roles: [{role: "readWrite", db: "sample-database-1"}]})
La salida de esta operación será similar a lo que se indica a continuación.
{ "user":"user3", "roles":[ { "role":"readWrite", "db":"sample-database-1" } ] }
Ahora que se ha creado el usuario user3
, asigne a user3
el rol read
a sample-database-2
.
db.grantRolesToUser("user3", [{role: "read", db: "sample-database-2"}])
Por último, tanto user1
como user2
abandonan la empresa y su acceso al clúster debe revocarse. Puede hacer esto dejando caer a los usuarios, de la siguiente manera.
db.dropUser("user1") db.dropUser("user2")
Para asegurarse de que todos los usuarios tienen los roles adecuados, puede enumerar todos los usuarios con el siguiente comando.
show users
La salida de esta operación será similar a lo que se indica a continuación.
{
"_id":"serviceadmin",
"user":"serviceadmin",
"db":"admin",
"roles":[
{
"db":"admin",
"role":"root"
}
]
}
{
"_id":"master-user",
"user":"master-user",
"db":"admin",
"roles":[
{
"db":"admin",
"role":"root"
}
]
}
{
"_id":"user3",
"user":"user3",
"db":"admin",
"roles":[
{
"db":"sample-database-2",
"role":"read"
},
{
"db":"sample-database-1",
"role":"readWrite"
}
]
}
Cómo empezar con las funciones RBAC definidas por el usuario
Para ayudarle a comenzar con roles definidos por el usuario, esta sección le guía a través de un escenario de ejemplo de aplicación de privilegios mínimos mediante la creación de roles para tres usuarios con funciones distintas.
En este ejemplo, se aplica lo siguiente:
-
user1
es un nuevo administrador que necesita poder ver y acceder a todas las bases de datos de un clúster. -
user2
es un nuevo empleado que necesita acceso a la acción ´encontrar´ en una sola base de datos,sample-database-1
, en ese mismo clúster. -
user3
es un empleado existente que necesita ver y tener acceso a una colección específica, col2 en una base de datos distinta,sample-database-2
a la que no tenía acceso antes, en el mismo clúster. -
Para
user1
, cree un rol con acceso de lectura y escritura a todas las bases de datos de todo el clúster con el siguiente comando.
db.createUser( { user: "user1", pwd: "abc123", roles: [{role: "readWriteAnyDatabase", db: "admin"}] } )
La salida de esta operación será similar a lo que se indica a continuación.
{ "user":"user1", "roles":[ { "role":"readWriteAnyDatabase", "db":"admin" } ] }
Para user2
, cree un rol con privilegios de “búsqueda” para todas las colecciones de la base de datos sample-database-1
con el siguiente comando. Tenga en cuenta que este rol garantizaría que los usuarios asociados solo puedan ejecutar consultas de búsqueda.
db.createRole( { role: "findRole", privileges: [ { resource: {db: "sample-database-1", collection: ""}, actions: ["find"] }], roles: [] } )
La salida de esta operación será similar a lo que se indica a continuación.
{ "role":"findRole", "privileges":[ { "resource":{ "db":"sample-database-1", "collection":"" }, "actions":[ "find" ] } ], "roles":[ ] }
A continuación, cree el usuario (user2
) y adjunte el rol findRole
creado recientemente al usuario.
db.createUser( { user: "user2", pwd: "abc123", roles: [] }) db.grantRolesToUser("user2",["findRole"])
Para simular el escenario en el que user3
se encuentra un usuario existente, primero cree el usuario yuser3
, a continuación, cree un nuevo rol denominado al collectionRole que asignaremos en el siguiente paso. user3
Ahora puede asignar un nuevo rol al user3
. Este nuevo rol permitirá al user3
insertar, actualizar, eliminar y acceder a una colección específica col2 en la sample-database-2
.
db.createUser( { user: "user3", pwd: "abc123", roles: [] }) db.createRole( { role: "collectionRole", privileges: [ { resource: {db: "sample-database-2", collection: "col2"}, actions: ["find", "update", "insert", "remove"] }], roles: [] } )
La salida de esta operación será similar a lo que se indica a continuación.
{ "role":"collectionRole", "privileges":[ { "resource":{ "db":"sample-database-2", "collection":"col2" }, "actions":[ "find", "update", "insert", "remove" ] } ], "roles":[ ] }
Ahora que se ha creado el usuario user3
, asigne a user3
el rol collectionFind
.
db.grantRolesToUser("user3",["collectionRole"])
Por último, tanto user1
como user2
abandonan la empresa y su acceso al clúster debe revocarse. Puede hacer esto dejando caer a los usuarios, de la siguiente manera.
db.dropUser("user1") db.dropUser("user2")
Para asegurarse de que todos los usuarios tienen los roles adecuados, puede enumerar todos los usuarios con el siguiente comando.
show users
La salida de esta operación será similar a lo que se indica a continuación.
{ "_id":"serviceadmin", "user":"serviceadmin", "db":"admin", "roles":[ { "db":"admin", "role":"root" } ] } { "_id":"master-user", "user":"master-user", "db":"admin", "roles":[ { "db":"admin", "role":"root" } ] } { "_id":"user3", "user":"user3", "db":"admin", "roles":[ { "db":"admin", "role":"collectionRole" } ] }
Conexión a Amazon DocumentDB como un usuario
Cuando se conecta a un clúster de Amazon DocumentDB, se conecta en el contexto de una base de datos determinada. De forma predeterminada, si no especifica una base de datos en la cadena de conexión, se conectará automáticamente al clúster en el contexto de la base de datos de test
. Todos los comandos de nivel de recopilación como insert
y find
se emiten contra colecciones en la base de datos test
.
Para ver la base de datos en la que se encuentra o, en otras palabras, en la que está emitiendo comandos, utilice el comando db
del intérprete de comandos mongo, de la siguiente manera.
Consulta:
db
Salida:
test
Aunque la conexión predeterminada puede estar en el contexto de la base de datos de test
, eso no significa necesariamente que el usuario asociado a la conexión esté autorizado a realizar acciones en la base de datos de test
. En el escenario de ejemplo anterior, si se autentica como el usuario user3
, que tiene el rol readWrite
de la base de datos sample-database-1
, el contexto predeterminado de la conexión es la base de datos de test
. Sin embargo, si intenta insertar un documento en una colección de la base de datos de test
, recibirá un mensaje de error Authorization failure (Error de autorización). Esto se debe a que ese usuario no está autorizado a realizar ese comando en esa base de datos, como se muestra a continuación.
Consulta:
db
Salida:
test
Consulta:
db.col.insert({x:1})
Salida:
WriteCommandError({ "ok" : 0, "code" : 13, "errmsg" : "Authorization failure" })
Si cambia el contexto de la conexión a la base de datos sample-database-1
, puede escribir en la colección para la que el usuario tiene la autorización para hacerlo.
Consulta:
use sample-database-1
Salida:
switched to db sample-database-1
Consulta:
db.col.insert({x:1})
Salida:
WriteResult({ "nInserted" : 1})
Cuando se autentica en un clúster con un usuario determinado, también puede especificar la base de datos en la cadena de conexión. Al hacerlo, se elimina la necesidad de realizar el comando use
después de que el usuario haya sido autenticado en la base de datos del admin
.
La siguiente cadena de conexión autentica al usuario en la base de datos admin
, pero el contexto de la conexión estará en la base de datos sample-database-1
.
mongo "mongodb://user3:abc123@sample-cluster.node.us-east-1.docdb.amazonaws.com:27017/sample-database-2"
Comandos comunes
Esta sección proporciona ejemplos de comandos comunes que utilizan el control de acceso basado en roles en Amazon DocumentDB. Debe estar en el contexto de la base de datos del admin
para crear y modificar usuarios y roles. Puede utilizar el comando use admin
para cambiar a la base de datos del admin
.
nota
Las modificaciones a los usuarios y roles se producirán implícitamente en la base de datos del admin
. La creación de usuarios con roles que tienen un ámbito en todas las bases de datos (por ejemplo, readAnyDatabase
) requiere que esté en el contexto de la base de datos del admin
(es decir, use
admin
) al crear el usuario, o que indique explícitamente la base de datos para el rol al crear el usuario (como se muestra en el Ejemplo 2 en este ).
Ejemplo 1: crear un usuario con el rol read
para la base de datos foo
.
db.createUser({user: "readInFooBar", pwd: "abc123", roles: [{role: "read", db: "foo"}]})
La salida de esta operación será similar a lo que se indica a continuación.
{
"user":"readInFooBar",
"roles":[
{
"role":"read",
"db":"foo"
}
]
}
Ejemplo 2: crear un usuario con acceso de lectura en todas las bases de datos.
db.createUser({user: "readAllDBs", pwd: "abc123", roles: [{role: "readAnyDatabase", db: "admin"}]})
La salida de esta operación será similar a lo que se indica a continuación.
{
"user":"readAllDBs",
"roles":[
{
"role":"readAnyDatabase",
"db":"admin"
}
]
}
Ejemplo 3: otorgar el rol read
a un usuario existente en una nueva base de datos.
db.grantRolesToUser("readInFooBar", [{role: "read", db: "bar"}])
Ejemplo 4: actualizar el rol de un usuario.
db.updateUser("readInFooBar", {roles: [{role: "read", db: "foo"}, {role: "read", db: "baz"}]})
Ejemplo 5: revocar el acceso a una base de datos de un usuario.
db.revokeRolesFromUser("readInFooBar", [{role: "read", db: "baz"}])
Ejemplo 6: describir un rol integrado.
db.getRole("read", {showPrivileges:true})
La salida de esta operación será similar a lo que se indica a continuación.
{
"role":"read",
"db":"sample-database-1",
"isBuiltin":true,
"roles":[
],
"inheritedRoles":[
],
"privileges":[
{
"resource":{
"db":"sample-database-1",
"collection":""
},
"actions":[
"changeStream",
"collStats",
"dbStats",
"find",
"killCursors",
"listCollections",
"listIndexes"
]
}
],
"inheritedPrivileges":[
{
"resource":{
"db":"sample-database-1",
"collection":""
},
"actions":[
"changeStream",
"collStats",
"dbStats",
"find",
"killCursors",
"listCollections",
"listIndexes"
]
}
}
Ejemplo 7: eliminar un usuario del clúster.
db.dropUser("readInFooBar")
La salida de esta operación será similar a lo que se indica a continuación.
true
Ejemplo 8: crear un rol con acceso de lectura y escritura a una colección específica
db.createRole( { role: "collectionRole", privileges: [ { resource: {db: "sample-database-2", collection: "col2"}, actions: ["find", "update", "insert", "remove"] }], roles: [] } )
La salida de esta operación será similar a lo que se indica a continuación.
{ "role":"collectionRole", "privileges":[ { "resource":{ "db":"sample-database-2", "collection":"col2" }, "actions":[ "find", "update", "insert", "remove" ] } ], "roles":[ ] }
Ejemplo 9: crear un usuario y asignar un rol definido por el usuario
db.createUser( { user: "user3", pwd: "abc123", roles: [] }) db.grantRolesToUser("user3",["collectionRole"])
Ejemplo 10: otorgar privilegios adicionales a un rol definido por el usuario
db.grantPrivilegesToRole( "collectionRole", [ { resource: { db: "sample-database-1", collection: "col1" }, actions: ["find", "update", "insert", "remove"] } ] )
Ejemplo 11: eliminar privilegios de un rol definido por el usuario
db.revokePrivilegesFromRole( "collectionRole", [ { resource: { db: "sample-database-1", collection: "col2" }, actions: ["find", "update", "insert", "remove"] } ] )
Ejemplo 12: actualizar un rol definido por el usuario existente
db.updateRole( "collectionRole", { privileges: [ { resource: {db: "sample-database-3", collection: "sample-collection-3"}, actions: ["find", "update", "insert", "remove"] }], roles: [] } )
Diferencias funcionales
En Amazon DocumentDB, las definiciones de usuario y rol se almacenan en la base de datos del admin
y los usuarios se autentican en la base de datos del admin
. Esta funcionalidad difiere de la MongoDB Community Edition, pero es consistente con MongoDB Atlas.
Amazon DocumentDB también admite flujos de cambios, lo que brinda una secuencia en orden cronológico de los eventos de actualización que se producen dentro de las colecciones de su clúster. La acción listChangeStreams
se aplica en el nivel de clúster (es decir, en todas las bases de datos) y la acción modifyChangeStreams
puede aplicarse en el nivel de base de datos y en el nivel de clúster.
Límites
La siguiente tabla contiene los límites del control de acceso basado en roles en Amazon DocumentDB.
Descripción | Límite |
---|---|
Número de usuarios por clúster | 1 000 |
Número de roles asociados a un usuario | 1 000 |
Número de roles definidos por el usuario | 100 |
Número de recursos asociados a un privilegio | 100 |
Acceso a la base de datos mediante el control de acceso basado en roles
Con el control de acceso basado en roles, puede crear un usuario y otorgarle uno o más roles para determinar qué operaciones puede realizar el usuario en una base de datos o clúster.
A continuación se muestra una lista de roles integrados que se admiten actualmente en Amazon DocumentDB.
nota
En Amazon DocumentDB 4.0 y 5.0, los comandos ListCollection
y ListDatabase
pueden usar, de forma opcional, los parámetros authorizedCollections
y authorizedDatabases
para enumerar las colecciones y bases de datos a las que el usuario tiene permiso para acceder, con los roles listCollections
y listDatabase
, respectivamente. Ahora, los usuarios pueden eliminar sus propios cursores sin necesitar el rol KillCursor
.