Compartir a través de

Seguridad en Azure Database for PostgreSQL: Servidor flexible

  • Artículo

SE APLICA A: Azure Database for PostgreSQL con 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.

A medida que las organizaciones dependen cada vez más de los datos almacenados en bases de datos para impulsar actividades críticas relacionadas con la toma de decisiones que a su vez impulsan una ventaja competitiva, la necesidad de medidas de seguridad de base de datos sólidas nunca ha sido más importante. Un error de seguridad puede desencadenar consecuencias catastróficas, incluida la exposición de datos confidenciales, que perjudican la reputación de la organización.

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 mediante la actualización del 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 modo Galois/Counter Mode (GCM) con 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

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

Captura de pantalla del Azure portal que muestra cómo habilitar Cloud Defender.

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 del servidor flexible de Azure Database for PostgreSQL: Se crea con los tres roles predeterminados definidos, además de los roles integrados que crea PostgreSQL. Puede ver estos roles con la ejecución del comando: .

SELECT rolname FROM pg_roles;

A continuación se muestran los 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"


 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.

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 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, se ha habilitado la capacidad de crear comandos CAST en el servidor flexible de Azure Database for PostgreSQL. Para ejecutar la instrucción CREATE CAST, el usuario debe ser miembro del grupo azure_pg_admin. Tenga en cuenta que actualmente no es posible quitar un elemento CAST una vez que se haya creado.

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 propiedad del esquema público en PostgreSQL 15

Desde la versión 15 de Postgres, se ha cambiado la propiedad del esquema público al nuevo rol de pg_database_owner. Permite que todos los propietarios de la base de datos posean el esquema público de la base de datos.
Puede encontrar más información en Notas de la versió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.

Importante

El Servidor flexible de Azure Database for PostgreSQL no permite que a los usuarios se les conceda el atributo pg_write_all_data, lo que permite al usuario escribir todos los datos (tablas, vistas, secuencias), como si tuvieran 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 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.

Este es un ejemplo que muestra cómo crear una directiva que garantice que solo los miembros del rol "administrador " creado 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.

En la autenticación SCRAM, el cliente participa en el trabajo de cifrado para generar la prueba de identidad. Por lo tanto, la autenticación SCRAM descarga parte del coste de cálculo en sus clientes, que en la mayoría de los casos son servidores de aplicaciones. Por consiguiente, adoptar SCRAM, además de ofrecer un algoritmo hash más seguro, ofrece también protección contra ataques de denegación de servicio distribuido (DDoS) contra PostgreSQL, ya que evita una sobrecarga del CPU del servidor para calcular hashes de contraseña.

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,

ALTER ROLE demouser PASSWORD 'Password123!';
ALTER ROLE

Compatibilidad con Azure Policy

Azure Policy ayuda a aplicar los estándares de la organización y a evaluar el cumplimiento a gran escala. Mediante su panel de cumplimiento, proporciona una vista agregada para evaluar el estado general del entorno, con la posibilidad de explorar en profundidad hasta el nivel de recurso y directiva. También ayuda al cumplimiento de los recursos gracias a la corrección masiva de los recursos existentes y la corrección automática de nuevos recursos.

Definiciones de directiva integradas

Microsoft desarrolla y prueba directivas integradas, lo que garantiza que cumplen los estándares comunes y los procedimientos recomendados; además, se implementan rápidamente sin necesidad de una configuración adicional, lo que hace que sean idóneas para los requisitos de cumplimiento estándar. Las directivas integradas suelen abarcar estándares y marcos de cumplimiento ampliamente reconocidos.

En la sección siguiente se proporciona un índice de definiciones de directivas integradas de Azure Policy para Azure Database for PostgreSQL con servidor flexible. Use el vínculo de la columna Origen para ver el origen en el repositorio de GitHub de Azure Policy.

Nombre (Azure Portal) Descripción Efectos Versión (GitHub)
Debería aprovisionarse un administrador de Microsoft Entra para servidores flexibles de PostgreSQL Permite aprovisionar un administrador de Microsoft Entra para el servidor flexible de PostgreSQL a fin de habilitar la autenticación de Microsoft Entra. La autenticación de Microsoft Entra permite la administración simplificada de permisos y la administración centralizada de identidades de usuarios de base de datos y otros servicios de Microsoft AuditIfNotExists, Disabled 1.0.0
La auditoría con PgAudit debería habilitarse para servidores flexibles de PostgreSQL Esta directiva ayuda a auditar cualquier servidor flexible de PostgreSQL en su entorno que no esté habilitado para usar pgaudit. AuditIfNotExists, Disabled 1.0.0
La limitación de conexiones debe estar habilitada para los servidores flexibles PostgreSQL Esta directiva permite realizar una auditoría de los servidores flexibles de PostgreSQL del entorno sin la limitación de conexiones habilitada. Esta configuración habilita la limitación de conexiones temporales por IP si hay demasiados errores de inicio de sesión con una contraseña no válida. AuditIfNotExists, Disabled 1.0.0
Implementación de la configuración de diagnóstico para servidores flexibles de PostgreSQL en las áreas de trabajo de Log Analytics Implementa la configuración de diagnóstico para que los servidores flexibles de PostgreSQL transmitan a un área de trabajo regional de Log Analytics cuando se crea o actualiza cualquier servidor flexible de PostgreSQL al que le falte esta configuración de diagnóstico. DeployIfNotExists, Disabled 1.0.0
Las desconexiones se deben registrar para los servidores flexibles de PostgreSQL. Esta directiva ayuda a realizar una auditoría de los servidores flexibles de PostgreSQL del entorno sin habilitar la opción log_disconnections. AuditIfNotExists, Disabled 1.0.0
La aplicación de la conexión SSL debe estar habilitada para los servidores flexibles PostgreSQL Azure Database for PostgreSQL permite conectar el servidor flexible de Azure Database for PostgreSQL a las aplicaciones cliente mediante la Capa de sockets seguros (SSL). Aplicar conexiones SSL entre el servidor flexible de base de datos y las aplicaciones cliente ayuda a proteger contra los ataques de tipo "Man in the middle" mediante el cifrado del flujo de datos entre el servidor y la aplicación. Esta configuración exige que SSL esté siempre habilitado para el acceso al servidor flexible de PostgreSQL. AuditIfNotExists, Disabled 1.0.0
La copia de seguridad con redundancia geográfica debe estar habilitada para los servidores flexibles de Azure Database for PostgreSQL Los servidores flexibles de Azure Database for PostgreSQL le permiten elegir la opción de redundancia para el servidor de bases de datos. Se puede establecer en un almacenamiento de copia de seguridad con redundancia geográfica donde los datos no solo se almacenan dentro de la región en la que se hospeda el servidor, sino que también se replican en una región emparejada para proporcionar la opción de recuperación en caso de que se produzca un error en la región. La configuración de almacenamiento con redundancia geográfica para copia de seguridad solo se permite durante la creación del servidor. Audit, Disabled 1.0.0
Los puntos de control del registro se deben habilitar para los servidores flexibles de PostgreSQL Esta directiva ayuda a realizar una auditoría de los servidores flexibles de PostgreSQL del entorno sin habilitar la opción log_checkpoints. AuditIfNotExists, Disabled 1.0.0
Las conexiones del registro deben estar habilitadas para los servidores flexibles de PostgreSQL Esta directiva ayuda a realizar una auditoría de los servidores flexibles de PostgreSQL del entorno sin habilitar la opción log_connections. AuditIfNotExists, Disabled 1.0.0
Los servidores flexibles de PostgreSQL deben usar claves administradas por el cliente para cifrar los datos en reposo. Use claves administradas por el cliente para administrar el cifrado en reposo de los servidores flexibles de PostgreSQL. De manera predeterminada, los datos se cifran en reposo con claves administradas por el servicio, pero las claves administradas por el cliente suelen ser necesarias para cumplir estándares de cumplimiento normativo. Las claves administradas por el cliente permiten cifrar los datos con una clave de Azure Key Vault creada por el usuario y propiedad de este. Usted tiene control y responsabilidad totales del ciclo de vida de la clave, incluidos la rotación y administración. Audit, Deny, Disabled 1.0.0
Los servidores flexibles de PostgreSQL deben ejecutar TLS versión 1.2 o posterior Esta directiva ayuda a auditar cualquier servidor flexible de PostgreSQL en su entorno que se ejecute con la versión de TLS inferior a la 1.2. AuditIfNotExists, Disabled 1.0.0
El punto de conexión privado debe estar habilitado para servidores flexibles PostgreSQL Las conexiones de punto de conexión privado garantizan una comunicación segura al permitir la conectividad privada con Azure Database for PostgreSQL. Configure una conexión de punto de conexión privado para permitir el acceso al tráfico que solo proviene de redes conocidas y evitar el acceso desde todas las demás direcciones IP, incluido desde Azure. AuditIfNotExists, Disabled 1.0.0

Definiciones de directiva personalizadas

Las directivas personalizadas se pueden adaptar de forma precisa para que coincidan con los requisitos específicos de su organización, incluidas las directivas de seguridad únicas o los mandatos de cumplimiento. Con las directivas personalizadas, tiene control total sobre la lógica y los parámetros de la directiva, lo que permite definiciones de directivas sofisticadas y específicas.

Contenido relacionado