sql >> Base de Datos >  >> RDS >> PostgreSQL

Cómo proteger su base de datos PostgreSQL - 10 consejos

Una vez que haya terminado el proceso de instalación de su servidor de base de datos PostgreSQL, es necesario protegerlo antes de pasar a producción. En esta publicación, le mostraremos cómo fortalecer la seguridad en torno a su base de datos para mantener sus datos seguros y protegidos.

1. Control de autenticación de clientes

Al instalar PostgreSQL, se crea un archivo llamado pg_hba.conf en el directorio de datos del clúster de la base de datos. Este archivo controla la autenticación del cliente.

A partir de la documentación oficial de postgresql, podemos definir el archivo pg_hba.conf como un conjunto de registros, uno por línea, donde cada registro especifica un tipo de conexión, un rango de dirección IP del cliente (si es relevante para el tipo de conexión), un nombre de base de datos, un nombre de usuario y el método de autenticación que se usará para las conexiones que coincidan con estos parámetros. El primer registro con un tipo de conexión, dirección de cliente, base de datos solicitada y nombre de usuario coincidentes se usa para realizar la autenticación.

Así que el formato general será algo como esto:

# TYPE  DATABASE        USER            ADDRESS                 METHOD

Un ejemplo de configuración puede ser el siguiente:

# Allow any user from any host with IP address 192.168.93.x to connect
# to database "postgres" as the same user name that ident reports for
# the connection (typically the operating system user name).
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
 host     postgres              all             192.168.93.0/24         ident
# Reject any user from any host with IP address 192.168.94.x to connect
# to database "postgres
# TYPE  DATABASE        USER            ADDRESS                 METHOD
 host     postgres              all             192.168.94.0/24         reject

Hay muchas combinaciones que puede hacer para refinar las reglas (la documentación oficial describe cada opción en detalle y tiene algunos ejemplos geniales), pero recuerde evitar reglas que sean demasiado permisivas, como permitir el acceso a líneas usando DATABASE all o ADDRESS 0.0.0.0/0.

Para garantizar la seguridad, incluso si olvida agregar una regla, puede agregar la siguiente fila en la parte inferior:

# TYPE  DATABASE        USER            ADDRESS                 METHOD
 host     all              all             0.0.0.0/0         reject

Como el archivo se lee de arriba a abajo para encontrar reglas coincidentes, de esta manera se asegura de que para otorgar el permiso deberá agregar explícitamente la regla coincidente anterior.

2. Configuración del servidor

Hay algunos parámetros en postgresql.conf que podemos modificar para mejorar la seguridad.

Puede usar el parámetro listen_address para controlar qué ips podrán conectarse al servidor. Esta es una buena práctica para permitir conexiones solo desde las IP conocidas o su red, y evitar valores generales como "*", "0.0.0.0:0" o "::", que le indicarán a PostgreSQL que acepte la conexión desde cualquier IP.

Cambiar el puerto en el que escuchará postgresql (por defecto 5432) también es una opción. Puede hacerlo modificando el valor del parámetro del puerto.

Es importante tener en cuenta parámetros como work_mem, maintenance_work_mem, temp_buffer, max_prepared_transactions, temp_file_limit en caso de que tenga un ataque de denegación de servicio. Estos son parámetros de declaración/sesión que se pueden configurar en diferentes niveles (db, usuario, sesión), por lo que administrarlos de manera inteligente puede ayudarnos a minimizar el impacto del ataque.

3. Gestión de usuarios y roles

La regla de oro para la seguridad con respecto a la administración de usuarios es otorgar a los usuarios la cantidad mínima de acceso que necesitan.

Manejar esto no siempre es fácil y puede complicarse mucho si no se hace bien desde el principio.

Una buena manera de mantener los privilegios bajo control es utilizar la estrategia de rol, grupo y usuario.

En postgresql todo se considera un rol, pero vamos a hacer algunos cambios en esto.

En esta estrategia crearás tres tipos o roles diferentes:

  • rol rol (identificado por el prefijo r_)
  • rol de grupo (identificado por el prefijo g_)
  • función de usuario (generalmente nombres personales o de aplicaciones)

Los roles (r_ roles) serán los que tendrán los privilegios sobre los objetos. Los roles de grupo (g_ roles) se otorgarán con los r_ roles, por lo que serán una colección de r_ roles. Y finalmente, los roles de usuario se otorgarán con uno o más roles de grupo y serán los que tengan el privilegio de inicio de sesión.

Vamos a mostrar un ejemplo de esto. Crearemos un grupo de solo lectura para example_schema y luego se lo otorgaremos a un usuario:

Creamos el rol de solo lectura y le otorgamos los privilegios del objeto

CREATE ROLE r_example_ro NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;
GRANT USAGE ON SCHEMA example to r_example_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA example to r_example_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA example GRANT SELECT ON TABLES TO r_example_ro;

Creamos el grupo de solo lectura y otorgamos el rol a ese grupo

CREATE ROLE g_example_ro NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION';
GRANT r_example_ro to g_example_ro;

Creamos el rol app_user y lo hacemos "unirse" al grupo de solo lectura

CREATE ROLE app_user WITH LOGIN ;
ALTER ROLE app_user WITH PASSWORD 'somePassword' ;
ALTER ROLE app_user VALID UNTIL 'infinity' ;
GRANT g_example_ro TO app_user;

Con este método, puede administrar la granularidad de los privilegios y puede otorgar y revocar fácilmente grupos de acceso a los usuarios. Recuerde otorgar privilegios de objeto solo a los roles en lugar de hacerlo directamente para los usuarios y otorgar el privilegio de inicio de sesión solo a los usuarios.

Esta es una buena práctica para revocar explícitamente los privilegios públicos sobre los objetos, como revocar el acceso público a una base de datos específica y otorgarlo solo a través de un rol.

REVOKE CONNECT ON my_database FROM PUBLIC;
GRANT CONNECT ON my_database TO r_example_ro;

Restrinja el acceso de SUPERUSUARIO, permita conexiones de superusuario solo desde el dominio localhost/unix.

Use usuarios específicos para diferentes propósitos, como usuarios de aplicaciones específicas o usuarios de respaldo, y limite las conexiones para ese usuario solo desde las direcciones IP requeridas.

4. Gestión de superusuarios

Mantener una política de contraseñas segura es imprescindible para mantener sus bases de datos seguras y evitar los hackeos de contraseñas. Para una política sólida, use preferentemente caracteres especiales, números, mayúsculas y minúsculas y tenga al menos 10 caracteres.

También existen herramientas de autenticación externas, como LDAP o PAM, que pueden ayudarlo a garantizar la política de caducidad y reutilización de su contraseña, y también manejar el bloqueo de cuentas en caso de errores de autenticación.

5. Cifrado de datos (en conexión ssl)

PostgreSQL tiene soporte nativo para usar conexiones SSL para encriptar comunicaciones cliente/servidor para mayor seguridad. SSL (Secure Sockets Layer) es la tecnología de seguridad estándar para establecer un enlace encriptado entre un servidor web y un navegador. Este enlace garantiza que todos los datos transmitidos entre el servidor web y los navegadores permanezcan privados e integrales.

Como los clientes de postgresql envían consultas en texto sin formato y los datos también se envían sin cifrar, es vulnerable a la suplantación de identidad de la red.

Puede habilitar SSL activando el parámetro ssl en postgresql.conf.

El servidor escuchará tanto las conexiones normales como las SSL en el mismo puerto TCP y negociará con cualquier cliente que se conecte si debe usar SSL. De manera predeterminada, esto es a elección del cliente, pero tiene la opción de configurar el servidor para que requiera el uso de SSL para algunas o todas las conexiones mediante el archivo de configuración pg_hba descrito anteriormente.

6. Cifrado de datos en reposo (pg_crypto)

Hay dos tipos básicos de cifrado, unidireccional y bidireccional. En cierto modo, nunca se preocupa por descifrar los datos en un formato legible, pero solo desea verificar que el usuario sepa cuál es el texto secreto subyacente. Esto se usa normalmente para las contraseñas. En el cifrado bidireccional, desea la capacidad de cifrar datos y permitir que los usuarios autorizados los descifren en una forma significativa. Datos como tarjetas de crédito y SSN entrarían en esta categoría.

Para el cifrado unidireccional, la función de cifrado empaquetada en pgcrypto proporciona un nivel adicional de seguridad por encima de la forma md5. La razón es que con md5, puede saber quién tiene la misma contraseña porque no hay sal (en criptografía, una sal son datos aleatorios que se usan como entrada adicional para una función unidireccional que "hashea" datos, una contraseña o frase de contraseña), por lo que todas las personas con la misma contraseña tendrán la misma cadena md5 codificada. Con crypt, serán diferentes.

Para los datos que le interesa recuperar, no desea saber si las dos piezas de información son iguales, pero no conoce esa información y desea que solo los usuarios autorizados puedan recuperarla. Pgcrypto proporciona varias formas de lograr esto, por lo que para obtener más información sobre cómo usarlo, puede consultar la documentación oficial de postgresql en https://www.postgresql.org/docs/current/static/pgcrypto.html.

7. Registro

Postgresql proporciona una amplia variedad de parámetros de configuración para controlar qué, cuándo y dónde iniciar sesión.

Puede habilitar la conexión/desconexión de sesiones, consultas de ejecución prolongada, tamaños de archivos temporales, etc. Esto puede ayudarlo a obtener un mejor conocimiento de su carga de trabajo para identificar comportamientos extraños. Puede obtener todas las opciones para iniciar sesión en el siguiente enlace https://www.postgresql.org/docs/9.6/static/runtime-config-logging.html

Para obtener información más detallada sobre su carga de trabajo, puede habilitar el módulo pg_stat_statements, que proporciona un medio para realizar un seguimiento de las estadísticas de ejecución de todas las declaraciones SQL ejecutadas por un servidor. Existen algunas herramientas de seguridad que pueden ingerir los datos de esta tabla y generarán una lista blanca de sql para ayudarlo a identificar las consultas que no siguen los patrones esperados.

Para más información https://www.postgresql.org/docs/9.6/static/pgstatstatements.html.

Descargue el documento técnico hoy Gestión y automatización de PostgreSQL con ClusterControl Obtenga información sobre lo que necesita saber para implementar, monitorear, administrar y escalar PostgreSQLDescargar el documento técnico

8. Auditoría

La extensión de auditoría de PostgreSQL (pgAudit) proporciona un registro detallado de auditoría de sesiones y/o de objetos a través de la función de registro estándar de PostgreSQL.

El registro de declaraciones básico puede ser proporcionado por la función de registro estándar con log_statement =all. Esto es aceptable para el monitoreo y otros usos, pero no brinda el nivel de detalle que generalmente se requiere para una auditoría. No es suficiente tener una lista de todas las operaciones realizadas contra la base de datos. También debe ser posible encontrar declaraciones particulares que sean de interés para un auditor. La función de registro estándar muestra lo que solicitó el usuario, mientras que pgAudit se enfoca en los detalles de lo que sucedió mientras la base de datos satisfacía la solicitud.

9. parches

Consulte la página de información de seguridad de PostgreSQL con regularidad y frecuencia para obtener actualizaciones y parches de seguridad críticos.

Tenga en cuenta que los errores de seguridad del sistema operativo o de las bibliotecas también pueden provocar una fuga de la base de datos, así que asegúrese de mantener actualizados los parches para estos.

ClusterControl proporciona un informe operativo que le brinda esta información y ejecutará los parches y las actualizaciones por usted.

10. Seguridad a nivel de fila

Además del sistema de privilegios estándar de SQL disponible a través de GRANT, las tablas pueden tener políticas de seguridad de filas que restringen, por usuario, qué filas pueden ser devueltas por consultas normales o insertadas, actualizadas o eliminadas por comandos de modificación de datos. Esta función también se conoce como seguridad de nivel de fila.

Cuando la seguridad de filas está habilitada en una tabla, todos los accesos normales a la tabla para seleccionar filas o modificar filas deben estar permitidos por una política de seguridad de filas.

Aquí hay un ejemplo simple de cómo crear una política en la relación de la cuenta para permitir que solo los miembros de la función de administradores accedan a las filas y solo a las filas de sus cuentas:

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);

Puede obtener más información sobre esta característica en la documentación oficial de postgresql https://www.postgresql.org/docs/9.6/static/ddl-rowsecurity.html

Si desea obtener más información, aquí hay algunos recursos que pueden ayudarlo a fortalecer mejor la seguridad de su base de datos...

  • https://www.postgresql.org/docs/9.6/static/auth-pg-hba-conf.html
  • https://www.postgresql.org/docs/9.6/static/ssl-tcp.html
  • https://www.postgresql.org/docs/current/static/pgcrypto.html
  • http://www.postgresonline.com/journal/archives/165-Encrypting-data-with-pgcrypto.html
  • https://github.com/pgaudit/pgaudit
  • https://www.postgresql.org/docs/9.6/static/pgstatstatements.html

Conclusión

Si sigue los consejos anteriores, su servidor estará más seguro, pero esto no significa que sea irrompible.

Por tu propia seguridad te recomendamos que utilices una herramienta de test de seguridad como Nessus, para saber cuáles son tus principales vulnerabilidades e intentar solucionarlas.

También puede monitorear su base de datos con ClusterControl. Con esto puedes ver en tiempo real lo que sucede dentro de tu base de datos y analizarlo.