Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
La administración del acceso a los recursos de Azure Database for PostgreSQL es una parte importante del mantenimiento de la seguridad y el cumplimiento. En este artículo se explica cómo usar roles de PostgreSQL y características de Azure para controlar los permisos e implementar procedimientos recomendados para la administración de acceso.
Administración de roles
La mejor manera de administrar los permisos de acceso a bases de datos de Azure Database for PostgreSQL a escala es mediante el concepto de roles. Un rol puede ser un usuario de base de datos o un grupo de bases de datos de usuarios. Los roles pueden poseer los objetos de base de datos y asignar privilegios de esos objetos a otros roles para controlar quién tiene acceso a qué objetos. Puede conceder pertenencia a un rol a otro rol, lo que permite que el rol miembro use privilegios asignados a otro rol. Azure Database for PostgreSQL permite conceder permisos directamente a los usuarios de la base de datos. Como práctica de seguridad recomendada, cree roles con conjuntos específicos de permisos en función de los requisitos mínimos de aplicación y acceso. Asigne los roles adecuados a cada usuario. Use roles para aplicar un modelo de privilegios mínimos para acceder a objetos de base de datos.
Además de los roles integrados que crea PostgreSQL, la instancia de Azure Database for PostgreSQL incluye tres roles predeterminados. Para ver estos roles, ejecute el siguiente comando:
SELECT rolname FROM pg_roles;
Los roles son:
azure_pg_adminazuresu- Rol de administrador
Al crear la instancia de Azure Database for PostgreSQL, se proporcionan credenciales para un rol de administrador. Use este rol de administrador para crear más roles de PostgreSQL.
Por ejemplo, puede crear un usuario o un rol denominado demouser.
CREATE USER demouser PASSWORD password123;
No use el rol de administrador para la aplicación.
En entornos PaaS basados en la nube, el acceso a una cuenta de super usuario de Azure Database for PostgreSQL está restringido a las operaciones del plano de control solo por parte de los operadores en la nube. Por tanto, la cuenta azure_pg_admin existe como una cuenta pseudo-superusuario. El rol Administrador es un miembro del rol azure_pg_admin.
Sin embargo, la cuenta de administrador del servidor no forma parte del rol azuresu, que tiene privilegios de super usuario y se utiliza para realizar operaciones en el plano de control. Como este servicio es un servicio PaaS administrado, solo Microsoft forma parte del rol de superusuario.
Puede auditar periódicamente la lista de roles del servidor.
Por ejemplo, puede conectarse mediante el psql cliente y consultar la pg_roles tabla, que enumera todos los roles junto con privilegios como crear otros roles, crear bases de datos, replicación, etc.
select * from pg_roles where rolname='demouser';
-[ RECORD 1 ]--+---------
rolname | demouser
rolsuper | f
rolinherit | t
rolcreaterole | f
rolcreatedb | f
rolcanlogin | f
rolreplication | f
rolconnlimit | -1
rolpassword | ********
rolvaliduntil |
rolbypassrls | f
rolconfig |
oid | 24827
Importante
Recientemente, Azure Database for PostgreSQL habilitó la capacidad de crear comandos CAST. Para ejecutar la CREATE instrucción CAST, el usuario debe ser miembro del grupo de azure_pg_admin. Actualmente, no se puede quitar un CAST después de crearlo.
Azure Database for PostgreSQL solo admite comandos CAST que usan las opciones WITH FUNCTION y WITH INOUT. La opción WITHOUT FUNCTION no se admite.
El registro de auditoría en Azure Database for PostgreSQL también está disponible con Azure Database for PostgreSQL para realizar un seguimiento de la actividad de las bases de datos.
Controlar el acceso al esquema
Las bases de datos recién creadas en Azure Database for PostgreSQL incluyen un conjunto predeterminado de privilegios en el esquema público de la base de datos que concede a todos los usuarios y roles de base de datos la capacidad de crear objetos. Para limitar mejor el acceso de usuario de la aplicación a las bases de datos que cree en la instancia de Azure Database for PostgreSQL, considere la posibilidad de revocar estos privilegios públicos predeterminados. Después de revocar estos privilegios, conceda privilegios específicos a los usuarios de base de datos de forma más detallada. Por ejemplo:
Revoque los privilegios de creación al
publicesquema delpublicrol para evitar que los usuarios de la base de datos de la aplicación creen objetos en el esquema público.REVOKE CREATE ON SCHEMA public FROM PUBLIC;Cree una nueva base de datos.
CREATE DATABASE Test_db;Revocar todos los privilegios del esquema PÚBLICO en esta nueva base de datos.
REVOKE ALL ON DATABASE Test_db FROM PUBLIC;Cree un rol personalizado para los usuarios de la base de datos de aplicaciones.
CREATE ROLE Test_db_user;Asigne a los usuarios de la base de datos con este rol la capacidad de conectarse a la base de datos.
GRANT CONNECT ON DATABASE Test_db TO Test_db_user; GRANT ALL PRIVILEGES ON DATABASE Test_db TO Test_db_user;Creación de un usuario de base de datos.
CREATE USER user1 PASSWORD 'Password_to_change'Asigne el rol, con sus privilegios de conexión y selección, al usuario.
GRANT Test_db_user TO user1;
En este ejemplo, el usuario user1 puede conectarse y tiene todos los privilegios en la base de datos de prueba Test_db, pero no en ninguna otra base de datos del servidor. En lugar de conceder a este usuario o rol TODOS LOS PRIVILEGIOS en esa base de datos y sus objetos, considere la posibilidad de proporcionar permisos más selectivos, como SELECT, INSERT, EXECUTE, y otros. Para obtener más información sobre los privilegios en las bases de datos PostgreSQL, consulte los comandos CONCESIÓN y REVOCAR en la documentación de PostgreSQL.
Cambios de propiedad del esquema público en Azure Database for PostgreSQL
En PostgreSQL 15 y versiones posteriores, la propiedad del esquema público cambió al nuevo pg_database_owner rol, lo que permite a los propietarios de la base de datos controlarlo. Para más información, consulte las notas de la Versión de PostgreSQL.
Sin embargo, en Azure Database for PostgreSQL, este cambio no se aplica. El esquema público es propiedad del azure_pg_admin rol en todas las versiones de PostgreSQL admitidas. Este comportamiento del servicio administrado proporciona seguridad y coherencia.
Cambios de PostgreSQL 16 con seguridad basada en roles
En PostgreSQL, el rol de base de datos puede tener muchos atributos que definen sus privilegios. Uno de estos atributos es el atributo CREATEROLE, que es importante para la administración de bases de datos postgreSQL de usuarios y roles. En PostgreSQL 16, se introdujeron cambios significativos en este atributo.
En PostgreSQL 16, los usuarios con el atributo CREATEROLE ya no tienen la capacidad de entregar la pertenencia a ningún rol a cualquier persona. En su lugar, al igual que otros usuarios sin este atributo, solo pueden entregar pertenencias a roles para los que poseen ADMIN OPTION. Además, en PostgreSQL 16, el atributo CREATEROLE todavía permite a un usuario no administrador la capacidad de aprovisionar nuevos usuarios. Sin embargo, solo pueden quitar usuarios creados por ellos mismos. Los intentos de quitar usuarios producen un error cuando un usuario no lo creó con el atributo CREATEROLE .
PostgreSQL 16 también presenta un rol integrado nuevo y mejorado. El rol pg_create_subscription permite a los super usuarios crear suscripciones.
En el servidor flexible de Azure Database for PostgreSQL, el rol azure_pg_admin es un rol restringido administrado por el sistema y no puede modificarse por los usuarios. Los intentos de modificarlo, como concederle otro rol, producirán un error similar al siguiente:
GRANT <db_user> TO azure_pg_admin;
ERROR: permission denied to alter restricted role "azure_pg_admin"
Se trata de una protección integrada para evitar cambios en roles administrativos críticos. Si necesita asignar privilegios o roles, considere la posibilidad de crear un rol personalizado en su lugar y conceder los permisos necesarios a ese rol.
Control mejorado para azure_pg_admin
En PostgreSQL 16, se implementa una estructura de jerarquía de roles estricta para los usuarios con el privilegio CREATEROLE, específicamente relacionado con la concesión de roles. Para mejorar la flexibilidad administrativa y abordar una limitación introducida en PostgreSQL 16, Azure Database for PostgreSQL mejora las funcionalidades del rol de azure_pg_admin en todas las versiones de PostgreSQL. Con esta actualización, los miembros del rol de azure_pg_admin pueden administrar roles y acceder a objetos propiedad de cualquier rol no restringido, incluso si esos roles también son miembros de azure_pg_admin. Esta mejora garantiza que los usuarios administrativos mantengan un control coherente y completo sobre la administración de roles y permisos, lo que proporciona una experiencia perfecta y confiable sin necesidad de acceso de super usuario.
Importante
Azure Database for PostgreSQL no permite que a los usuarios se les conceda pg_write_all_data atributo, lo que permite al usuario escribir todos los datos (tablas, vistas, secuencias), como si tuviera derechos, INSERT, UPDATE y DELETE en esos objetos y derechos USAGE en todos los esquemas, incluso sin tener que concederlo explícitamente. Como solución alternativa recomendada para conceder permisos similares en un nivel más finito por base de datos y objeto.
Seguridad a nivel de fila
La seguridad de nivel de fila (RLS) es una característica de seguridad de Azure Database for PostgreSQL que permite a los administradores de bases de datos definir directivas que controlan cómo se muestran y funcionan las filas de datos específicas para uno o varios roles. La seguridad de nivel de fila agrega un filtro adicional a una tabla de base de datos de Azure Database for PostgreSQL. Cuando un usuario intenta realizar una acción en una tabla, este filtro se aplica antes de los criterios de consulta u otro filtrado, y los datos se limitan o rechazan según la directiva de seguridad. Puede crear directivas de seguridad de nivel de fila para comandos específicos como SELECT, INSERT, UPDATE, y DELETE, o especificarlo para todos los comandos. Los casos de uso de la seguridad a nivel de fila incluyen implementaciones que cumplen con la normativa PCI, entornos clasificados y aplicaciones de alojamiento compartido o multi inquilino.
Solo los usuarios con SET ROW SECURITY derechos pueden aplicar derechos de seguridad de fila a una tabla. El propietario de la tabla puede establecer la seguridad de fila en una tabla. Al igual que OVERRIDE ROW SECURITY, este derecho es actualmente un derecho implícito. La seguridad de nivel de fila no invalida los GRANT permisos existentes. Agrega un nivel de control más preciso. Por ejemplo, establecer ROW SECURITY FOR SELECT para permitir que un usuario determinado acceda a las filas solo concede a ese usuario acceso si el usuario también tiene SELECT privilegios en la columna o tabla en cuestión.
En el ejemplo siguiente se muestra cómo crear una directiva que garantiza que solo los miembros del rol de administrador creados personalizados solo puedan acceder a las filas de una cuenta específica. El código del ejemplo siguiente se ha compartido en la documentación de PostgreSQL.
CREATE TABLE accounts (manager text, company text, contact_email text);
ALTER TABLE accounts ENABLE ROW LEVEL SECURITY;
CREATE POLICY account_managers ON accounts TO managers
USING (manager = current_user);
La USING cláusula añade implícitamente una WITH CHECK cláusula, lo que garantiza que los miembros del rol de administrador no puedan realizar operaciones de SELECT, DELETE o UPDATE en filas que pertenezcan a otros administradores, y no puedan INSERT nuevas filas que pertenezcan a otro administrador.
Puede quitar una directiva de seguridad de fila mediante el DROP POLICY comando, como se muestra en este ejemplo:
DROP POLICY account_managers ON accounts;
Aunque puede quitar la directiva, el administrador de roles todavía no puede ver ningún dato que pertenezca a ningún otro administrador. Esta restricción existe porque la directiva de seguridad de nivel de fila todavía está habilitada en la tabla de cuentas. Si la seguridad de nivel de fila está habilitada de forma predeterminada, PostgreSQL usa una directiva de denegación predeterminada.
Puede deshabilitar la seguridad de nivel de fila, como se muestra en el ejemplo siguiente:
ALTER TABLE accounts DISABLE ROW LEVEL SECURITY;
Omite la seguridad a nivel de fila
PostgreSQL tiene permisos BYPASSRLS y NOBYPASSRLS, que puede asignar a un rol. NOBYPASSRLS se asigna de forma predeterminada. Con los servidores recién aprovisionados en Azure Database for PostgreSQL, se implementa el privilegio de seguridad de nivel de fila (BYPASSRLS) como se indica a continuación:
En el caso de los servidores con versiones posteriores y postgres 16, seguimos el comportamiento estándar de PostgreSQL 16. Los usuarios no administrativos creados por el rol de administrador azure_pg_admin le permiten crear roles con el atributo o privilegio BYPASSRLS según sea necesario.
En el caso de los servidores con versiones anteriores y Postgres 15, puede usar el usuario de azure_pg_admin para realizar tareas administrativas que requieran el privilegio BYPASSRLS. Sin embargo, no puede crear usuarios que no sean administradores con el privilegio BypassRLS, ya que el rol de administrador no tiene privilegios de superusuario, como habitual en los servicios De PostgreSQL basados en la nube.