Administración de acceso en Azure HorizonDB (versión preliminar)

La administración del acceso a su Azure HorizonDB 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 a escala los permisos de acceso a la base de datos de Azure HorizonDB 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 HorizonDB 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, el clúster de Azure HorizonDB incluye tres roles predeterminados. Para ver estos roles, ejecute el siguiente comando:

SELECT rolname FROM pg_roles;

Los roles son:

• azure_pg_admin
• azuresu
• administrator role

Al crear el clúster de Azure HorizonDB, se proporcionan credenciales de un administrator role. Úselo administrator role para crear más roles de PostgreSQL.

Por ejemplo, puede crear un usuario o un rol denominado exampleuser.

CREATE USER exampleuser 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 superusuario de HorizonDB Azure solo está restringido a las operaciones del plano de control. El rol azuresu tiene privilegios de superusuario, pero la cuenta de administrador del clúster de HorizonDB Azure no forma parte del rol de azuresu.

El rol azure_pg_admin actúa como una cuenta de pseudo superusuario. La cuenta de administrador que configuraste al crear el clúster pertenece al rol azure_pg_admin.

Puede auditar periódicamente la lista de roles del clúster.

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

Controlar el acceso al esquema

Las bases de datos recién creadas en Azure HorizonDB 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 HorizonDB de Azure, 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:

• Revocar los privilegios de creación al esquema public del rol public 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, user user1 puede conectarse y tiene todos los privilegios de la base de datos de prueba Test_db, pero no ninguna otra base de datos del clúster. 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 HorizonDB

En Azure HorizonDB, el esquema público es propiedad del rol azure_pg_admin en todas las versiones de PostgreSQL compatibles.

Control mejorado para azure_pg_admin

En Azure HorizonDB, el rol azure_pg_admin es un rol restringido gestionado por el sistema que no se puede modificar. Si intenta modificarlo, por ejemplo, concediéndole otro rol, obtendrá un error similar al siguiente:

GRANT <db_user> TO azure_pg_admin;
ERROR: permission denied to alter restricted role "azure_pg_admin"

Esta restricción es 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.

Azure HorizonDB mejora las funcionalidades del azure_pg_admin rol en todas las versiones de PostgreSQL. Los miembros del azure_pg_admin rol pueden administrar roles y tener acceso a objetos propiedad de cualquier rol no restringido, incluso si esos roles también son miembros de azure_pg_admin. Esta característica 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 superusuario.

Seguridad a nivel de fila

Seguridad de nivel de fila (RLS) es una característica de seguridad de Azure HorizonDB que permite a los administradores de bases de datos definir directivas que controlan cómo se muestran y cómo se puede operar con filas específicas de datos para uno o varios roles. La seguridad de nivel de fila agrega un filtro adicional a una tabla de base de datos de HorizonDB Azure. 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 incluye BYPASSRLS y NOBYPASSRLS permisos que puede asignar a un rol. De forma predeterminada, se asigna el permiso NOBYPASSRLS. En Azure HorizonDB, el privilegio de omitir la seguridad de nivel de fila (BYPASSRLS) funciona de la siguiente manera:

• Los usuarios no administrativos creados por el azure_pg_admin rol de administrador pueden crear roles con el BYPASSRLS atributo o privilegio según sea necesario.

• Use el azure_pg_admin usuario para realizar tareas administrativas que requieran el BYPASSRLS privilegio.

Contenido relacionado

• Proteja su Azure HorizonDB (versión preliminar)