Seguridad en Azure Database for PostgreSQL: Servidor flexible

Artículo
04/15/2024

SE APLICA A: Azure Database for PostgreSQL: servidor flexible

Hay varios niveles de seguridad disponibles para ayudar a proteger los datos en la instancia de Azure Database for PostgreSQL con la opción Servidor flexible. En este artículo se describen esas opciones de seguridad.

Protección y cifrado de información

Azure Database for PostgreSQL con la opción Servidor flexible cifra los datos de dos maneras:

Datos en tránsito: Azure Database for PostgreSQL con la opción Servidor flexible cifra los datos en tránsito con Capa de sockets seguros y Seguridad de la capa de transporte (SSL/TLS). El cifrado se aplica de forma predeterminada. Para obtener información más detallada sobre la seguridad de la conexión con SSL\TLS consulte esta documentación. Para una mayor seguridad, puede optar por habilitar la Autenticación SCRAM en el Servidor flexible de Azure Database for PostgreSQL.

Aunque no es muy recomendable, si es necesario, debido a la incompatibilidad de cliente heredado, usted tiene una opción para deshabilitar TLS\SSL para conexiones al Servidor flexible de Azure Database for PostgreSQL actualizando el parámetro de servidor require_secure_transport a OFF. También puede establecer la versión de TLS estableciendo los parámetros de servidor ssl_max_protocol_version.
Datos en reposo: Azure Database for PostgreSQL con la opción Servidor flexible usa el módulo criptográfico con validación FIPS 140-2 para el cifrado del almacenamiento. Los datos se cifran en el disco, incluidas las copias de seguridad y los archivos temporales que se crean mientras se ejecutan las consultas.

El servicio usa el cifrado AES de 256 bits que se incluye en el cifrado de almacenamiento de Azure y las claves las administra el sistema. Todo esto se diferencia poco de lo que ofrecen otras tecnologías de cifrado en reposo como el cifrado de datos transparente en las bases de datos de SQL Server u Oracle. El cifrado de almacenamiento siempre está activado y no se puede deshabilitar.

Seguridad de las redes

Cuando se ejecuta Azure Database for PostgreSQL: servidor flexible, tiene dos opciones de red principales:

Acceso privado: el servidor se puede implementar en Azure Virtual Network. Las redes virtuales de Azure ayudan a proporcionan una comunicación de red privada y segura. Los recursos de una red virtual se pueden comunicar mediante direcciones IP privadas. Para más información, consulte la introducción a las redes para Azure Database for PostgreSQL con la opción Servidor flexible.

Las reglas de seguridad de grupos de seguridad de red permiten filtrar el tipo de tráfico de red que puede fluir dentro y fuera de las interfaces de red y las subredes de redes virtuales. Para más información, consulte la introducción a los grupos de seguridad de red.
Acceso público: se accede al servidor a través de un punto de conexión público. El punto de conexión público es una dirección DNS que se puede resolver públicamente. Su acceso está protegido por un firewall que bloquea todas las conexiones por defecto.

Las reglas de firewall de IP otorgan acceso a los servidores según la dirección IP de origen de cada solicitud. Para más información, consulte la introducción a las reglas de firewall.

Soporte técnico de Microsoft Defender para la nube

Microsoft Defender para bases de datos relacionales de código abierto detecta actividades anómalas que indican intentos poco habituales y posiblemente dañinos de acceder a sus bases de datos o de aprovechar sus vulnerabilidades. Defender for Cloud proporciona alertas de seguridad sobre actividades anómalas para que pueda detectar posibles amenazas y responder a estas a medida que se producen. Cuando habilita este plan, Defender for Cloud proporciona alertas cuando detecta patrones anómalos de acceso y consulta a la base de datos y actividades sospechosas en la base de datos.

Estas alertas aparecen en la página de alertas de seguridad de Defender for Cloud e incluyen:

Detalles de la actividad sospechosa que las desencadenó.
La táctica de MITRE ATT&CK asociada
Acciones recomendadas para investigar y mitigar la amenaza.
Opciones para continuar las investigaciones con Microsoft Sentinel.

Microsoft Defender for Cloud y Ataques por fuerza bruta

Un ataque por fuerza bruta se encuentra entre los métodos de piratería más comunes y con más éxito, a pesar de ser métodos de piratería menos sofisticados. La teoría en la que se basa un ataque de este tipo es que si se realizan infinitos intentos para adivinar una contraseña, al final se acierta. Cuando Microsoft Defender for Cloud detecta un ataque por fuerza bruta, desencadena una alerta para que sepa que se ha producido un ataque de este tipo. También puede separar un ataque por fuerza bruta sencillo del ataque por fuerza bruta en un usuario válido o un ataque de fuerza bruta con éxito.

Para recibir alertas del plan Microsoft Defender, primero tendrá que habilitarlo como se muestra en la siguiente sección.

Habilitar la seguridad mejorada con Microsoft Defender for Cloud

En Azure Portal, vaya al menú Seguridad en el panel izquierdo.
Seleccione Microsoft Defender for Cloud.
En el panel derecho, seleccione Habilitar.

Nota:

Si tiene habilitada la característica "bases de datos relacionales de código abierto" en el plan de Microsoft Defender, observará que Microsoft Defender se habilita automáticamente de manera predeterminada para el recurso de servidor flexible de Azure Database for PostgreSQL.

Administración de acceso

La mejor manera de administrar los permisos de acceso a la base de datos de Azure Database for PostgreSQL con la opción Servidor flexible a gran escala es mediante el uso del 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. También es posible conceder la pertenencia a un rol a otro rol, permitiendo así al rol miembro utilizar privilegios asignados a otro rol. Azure Database for PostgreSQL con la opción Servidor flexible permite conceder permisos directamente a los usuarios de la base de datos. Como procedimiento de seguridad recomendado, es conveniente crear roles con conjuntos específicos de permisos en función de los requisitos mínimos de aplicación y acceso. Después, puede asignar los roles adecuados a cada usuario. Los roles se usan para aplicar un modelo de privilegios mínimos para acceder a los objetos de base de datos.

La instancia de Azure Database for PostgreSQL con la opción Servidor flexible se creó con los tres roles predeterminados definidos. Puede ver estos roles con la ejecución del comando: .

SELECT rolname FROM pg_roles;

azure_pg_admin
azuresu
Rol de administrador

Al crear la instancia de Azure Database for PostgreSQL con la opción Servidor flexible, debe proporcionar las credenciales de un rol Administrador. Este rol de administrador se puede usar para crear más roles de PostgreSQL.
Por ejemplo, a continuación, se puede crear un rol o usuario de ejemplo denominado demouser.

postgres=> CREATE USER demouser PASSWORD 'password123';

La aplicación nunca debe usar el rol Administrador.

En entornos PaaS basados en la nube, el acceso a una cuenta de superusuario de Azure Database for PostgreSQL con la opción Servidor flexible 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.

Nota:

Un número de permisos solo de superusuario, como la creación de determinadas conversiones implícitas, no están disponibles con Azure Database for PostgreSQL con la opción Servidor flexible, ya que el rol azure_pg_admin no se alinea con los permisos del rol de superusuario de PostgreSQL.

Puede auditar periódicamente la lista de roles del servidor. Por ejemplo, puede conectarse mediante el cliente psql y consultar la tabla pg_roles, que enumera todos los roles junto con privilegios, como crear roles adicionales, crear bases de datos, replicación, etc.

postgres=> \x
Expanded display is on.
postgres=> 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

El registro de auditoría en el Servidor Flexible de Azure Database for PostgreSQL también está disponible con el Servidor Flexible de Azure Database for PostgreSQL para realizar un seguimiento de la actividad en sus bases de datos.

Controlar el acceso al esquema

Las bases de datos recién creadas en Azure Database for PostgreSQL con la opción Servidor flexible tendrán un conjunto predeterminado de privilegios en el esquema público de la base de datos que permite a todos los usuarios y roles de base de datos crear objetos. Para limitar mejor el acceso de los usuarios de la aplicación a las bases de datos que cree en la instancia de Azure Database for PostgreSQL con la opción Servidor flexible, se recomienda revocar estos privilegios públicos predeterminados. Después de hacerlo, puede conceder privilegios específicos para los usuarios de base de datos de forma más detallada. Por ejemplo:

Para evitar que los usuarios de la base de datos de aplicaciones creen objetos en el esquema público, revoque los privilegios de creación al esquema public del rol public.
```
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
```
A continuación, cree una 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;
```
Creación de un rol personalizado para 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;

Crear el usuario de la base de datos

CREATE USER user1 PASSWORD 'Password_to_change'

Asignación de roles, con su conexión y selección de privilegios para el usuario
```
GRANT Test_db_user TO user1;
```

En este ejemplo, el usuario user1 puede conectarse y tiene todos los privilegios en nuestra base de datos de prueba Test_db, pero no en ninguna otra base de datos del servidor. En lugar de conceder a este usuario/rol TODOS los privilegios en esa base de datos y sus objetos, es más recomendable proporcionar permisos más selectivos, como SELECT, INSERT, EXECUTE, etc. Para obtener más información sobre los privilegios en las bases de datos de PostgreSQL, consulte los comandos GRANT y REVOKE en la documentación de PostgreSQL.

Cambios de PostgreSQL 16 con seguridad basada en roles

En la base de datos PostgreSQL un rol puede tener muchos atributos que definen sus privilegios, uno de ellos es el atributo CREATEROLE, que es importante para la administración de usuarios y roles en la base de datos PostgreSQL. En PostgreSQL 16 se han incluido cambios significativos en este atributo. En PostgreSQL 16, los usuarios con el atributo CREATEROLE ya no tienen la capacidad de entregar la pertenencia a cualquier 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 no-super usuario la capacidad de aprovisionar nuevos usuarios, sin embargo, solo pueden dar de baja a los usuarios que ellos mismos crearon. Los intentos de dar de baja usuarios que no hayan sido creados por un usuario con el atributo CREATEROLE darán lugar a un error.

PostgreSQL 16 también introdujo nuevos y mejorados roles integrados. El nuevo rol pg_use_reserved_connections en PostgreSQL 16 permite el uso de ranuras de conexión reservadas a través de reserved_connections. El rol pg_create_subscription permite a los superusuarios crear suscripciones.

Seguridad de nivel de fila

Seguridad de nivel de fila (RLS) es una característica de seguridad de Azure Database for PostgreSQL con la opción Servidor flexible que permite a los administradores de bases de datos definir directivas para controlar cómo se muestran y funcionan las filas de datos específicas para uno o varios roles. La seguridad de nivel de fila es un filtro adicional que se puede aplicar a una tabla de base de datos de Azure Database for PostgreSQL con la opción Servidor flexible. 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 reducen 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, especificarlo para todos los comandos. Los casos de uso para la seguridad de nivel de fila incluyen implementaciones que cumplen con PCI, entornos clasificados y aplicaciones de alojamiento compartido / multi inquilino.

Solo los usuarios con derechos SET ROW SECURITY pueden aplicar derechos de seguridad de fila a una tabla. El propietario de la tabla puede establecer la seguridad de filas en una tabla. Al igual que OVERRIDE ROW SECURITY, esto es actualmente un derecho implícito. La seguridad a nivel de fila no anula los permisos GRANT existentes, sino que agrega un nivel de control más detallado. Por ejemplo, establecer ROW SECURITY FOR SELECT para permitir que un usuario determinado proporcione filas solo concedería acceso a ese usuario si el usuario también tiene privilegios SELECT en la columna o tabla en cuestión.

He aquí un ejemplo que muestra cómo crear una directiva que garantice que solo los miembros del rol "administrador " creada a medida puedan acceder únicamente 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 cláusula USING agrega implícitamente una cláusula WITH CHECK, asegurando que los miembros del rol de administrador no puedan realizar SELECT, DELETE, u UPDATE operaciones 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 comando DROP POLICY, como en este ejemplo:



DROP POLICY account_managers ON accounts;

Aunque es posible que haya quitado la directiva, el administrador de roles todavía no puede ver ningún dato que pertenezca a ningún otro administrador. Esto se debe a que 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 en el ejemplo siguiente:

ALTER TABLE accounts DISABLE ROW LEVEL SECURITY;

Omitir Seguridad de nivel de fila

PostgreSQL tiene permisos BYPASSRLS y NOBYPASSRLS, que se pueden asignar a un rol; NOBYPASSRLS se asigna de forma predeterminada. Con los servidores recién aprovisionados en Azure Database for PostgreSQL con la opción Servidor flexible pasando el privilegio de seguridad de nivel de fila (BYPASSRLS) se implementa de la siguiente manera:

En el caso de los servidores con Postgres 16 y versiones posteriores, seguimos el comportamiento estándar de PostgreSQL 16. Los usuarios no administrativos creados por el rol Administrador azure_pg_admin permiten crear roles con el atributo o privilegio BYPASSRLS según sea necesario.
Para los servidores de Postgres 15 y versiones posteriores , se puede usar el usuario azure_pg_admin para realizar tareas administrativas que requieran privilegios BYPASSRLS, pero no se pueden crear usuarios que no sean administradores con privilegios BypassRLS, ya que el rol Administrador no tiene privilegios de superusuario, como es habitual en los servicios PaaS PostgreSQL basados en la nube.

Actualización de contraseñas

Para una mayor seguridad, es una buena práctica rotar periódicamente la contraseña de administrador y las contraseñas de los usuarios de la base de datos. Se recomienda utilizar contraseñas seguras con mayúsculas, minúsculas, números y caracteres especiales.

Uso de SCRAM

El Mecanismo de autenticación de respuesta a desafíos cifrados (SCRAM) mejora notablemente la seguridad de la autenticación de usuario basada en contraseña mediante la adición de varias características de seguridad clave que impiden ataques de tabla arco iris, ataques de tipo "man in the middle" y ataques de contraseña almacenados, al mismo tiempo que se agrega compatibilidad con varios algoritmos hash y contraseñas que contienen caracteres no ASCII.

Si su controlador de cliente admite SCRAM, puede configurar el acceso a Azure Database for PostgreSQL: servidor flexible mediante SCRAM como scram-sha-256 frente al valor predeterminado md5.

Restablecimiento de la contraseña del administrador

Siga la guía de procedimientos para restablecer la contraseña de administrador.

Actualización de la contraseña de usuario de base de datos

Puede usar las herramientas de cliente para actualizar las contraseñas de usuario de base de datos.
Por ejemplo,

postgres=> ALTER ROLE demouser PASSWORD 'Password123!';
ALTER ROLE