Las organizaciones dependen de los datos, y las bases de datos son el lugar donde se almacenan dichos datos. Las bases de datos son el corazón que bombea estos datos por toda la organización, manteniéndolos vivos. Pero a medida que los volúmenes de datos se disparan y las regulaciones se endurecen, tratar la seguridad de las bases de datos como un conjunto de tareas técnicas aisladas es una receta para el desastre.
Sin embargo, muchas empresas siguen tratando la seguridad de las bases de datos como un conjunto de pequeñas tareas técnicas aisladas, en lugar de como un proceso estructurado con una evaluación continua. Esta lista de verificación para la evaluación de la seguridad de las bases de datos le ayudará a salvar esa brecha con un proceso estructurado y una evaluación continua. Transformemos las buenas intenciones en actividades organizadas y orientadas a los resultados.
Este artículo está organizado por objetivos estratégicos, con una lista de verificación práctica para ayudarle a proteger eficazmente sus datos.
¿Por Qué Evaluar?
La seguridad de las bases de datos protege sus datos críticos y confidenciales. Es la línea de defensa más íntima y última que se interpone entre sus datos y todas las amenazas y actores maliciosos dentro y fuera de su organización. Esa es la línea que no debe fallar.
Por lo tanto, es fundamental garantizar que la seguridad de las bases de datos sea eficaz y funcione correctamente para detectar y prevenir infracciones de amenazas del mundo real.
También es importante optimizar su inversión para no perder tiempo y dinero en esfuerzos ineficaces. Lo prudente es continuar con sus prácticas de seguridad actuales si proporcionan una protección eficaz. Una evaluación puede ayudarle a determinar si es ventajoso cambiar las inversiones a otras prácticas que produzcan mejores resultados.
Una revisión anual es la frecuencia mínima necesaria para realizar una evaluación y actualizar lo que sea necesario. Sin ella, es poco probable que su seguridad funcione bien y quedará expuesto.
La Checklist
1. Eficacia General de la Seguridad
Existen reglas básicas que le ayudarán a determinar rápidamente si la seguridad de su base de datos funciona correctamente. Es un buen punto de partida para evaluar si su sistema de seguridad de bases de datos funciona o no.
A. Visibilidad
Pregunta clave: ¿Tiene visibilidad de lo que ocurre en su base de datos?
Considere estas preguntas básicas:
- ¿Tiene una lista de los usuarios, programas e IP que se han conectado a su base de datos durante el último mes?
- ¿Tiene la lista de personas que accedieron a datos confidenciales en la última semana?
- ¿Sabe cuántos datos confidenciales se extrajeron ayer?
La visibilidad es fundamental. Si no tiene idea de lo que ocurre en su base de datos, esta no puede ser segura. Es imposible proteger lo que no se puede ver.
B. Falsos Positivos
Pregunta clave: ¿Su sistema de seguridad genera alertas falsas positivas?
Puede parecer contradictorio, pero un número reducido de falsos positivos es un buen indicador de que el sistema de seguridad funciona correctamente. Si su sistema es demasiado «silencioso», es probable que no esté haciendo su trabajo y que no detecte un ataque real. Debemos evitar un número excesivo de falsos positivos. Son ineficaces y provocan fatiga por alertas. Sin embargo, una pequeña cantidad regular de eventos realistas indica que todo funciona correctamente.
Si su seguridad es pasiva por diseño (no está pensada para enviar alertas), debería considerar la posibilidad de incorporar componentes activos. Las medidas pasivas por sí solas no pueden detectar ni responder a los ataques, lo que le deja expuesto.
Un sistema de seguridad saludable debe mostrar «signos de vida» y generar alertas relevantes con una buena relación señal-ruido, no solo eventos aleatorios.
C. Investigación Forense
Pregunta clave: ¿Su equipo lleva a cabo investigaciones forenses ocasionales en respuesta a incidentes?
Todos los entornos tienen eventos que requieren investigación de vez en cuando. Si su equipo de seguridad nunca lleva a cabo investigaciones forenses para descartar un ataque o una brecha, entonces no tiene una seguridad eficaz.
Al igual que con los falsos positivos, si todo parece funcionar siempre a la perfección, entonces sus sistemas de seguridad no están funcionando.
2. Listas de Activos
Un paso básico en cualquier operación de seguridad es mantener listas de activos: qué estamos protegiendo y quién tiene acceso a ello. Es esencial mantener estas listas actualizadas y garantizar que el acceso se revise y apruebe.
A. Detección de Bases de Datos
El primer paso es disponer de un inventario actualizado de todas las bases de datos de la red. Debe enumerar tanto las bases de datos de producción como las que no lo son e identificar cuáles contienen información confidencial.
Verificación: ¿Ha realizado recientemente un análisis de la red para detectar nuevas instancias? También es aconsejable mantenerse en contacto con los equipos de administradores de bases de datos (DBA) para ayudar a controlar la proliferación de datos.
B. Identificación de Datos Sensibles
Dentro de la lista de bases de datos confidenciales, es necesario identificar las tablas y columnas que contienen información confidencial. Esta información cambia con el tiempo a medida que evolucionan las aplicaciones, por lo que consultar ocasionalmente con los distintos equipos le garantizará saber siempre dónde se encuentran los activos críticos.
Verificación: ¿Se ha puesto en contacto recientemente con el equipo jurídico para preguntar sobre los nuevos requisitos en materia de datos confidenciales? ¿Se ha mantenido en contacto con los administradores de bases de datos y los equipos de aplicaciones sobre los datos potencialmente confidenciales que gestionan?
C. Cuentas de Administrador (DBA)
Las cuentas DBA suponen una amenaza tanto de abuso interno como de robo de credenciales. Estas cuentas, que son un objetivo muy valioso para los piratas informáticos, deben ser supervisadas cuidadosamente. Un primer paso es mantener una lista actualizada de todas las cuentas con privilegios en las bases de datos. Esto incluye tanto las cuentas individuales como las compartidas.
Verificación: Asegúrese de que las cuentas con privilegios antiguas se cierran, que las contraseñas se cambian periódicamente y que todas estas cuentas se supervisan (véase más abajo). Se recomienda realizar un análisis para localizar las cuentas con privilegios confidenciales (como «alter user», «select any table», etc.).
D. Cuentas de Aplicaciones
Las cuentas de aplicaciones son las más activas de la base de datos, responsables de casi toda la actividad SQL y los accesos a datos sensibles.
Es imprescindible saber qué aplicaciones acceden a bases de datos sensibles. El panorama de las aplicaciones está en constante evolución y, con el tiempo, es habitual que se desarrollen nuevas aplicaciones y que las antiguas obtengan acceso a más datos.
Verificación: Realice revisiones periódicas para identificar qué aplicaciones se conectan a bases de datos sensibles y asegúrese de que solo las aplicaciones necesarias y autorizadas mantengan el acceso a los datos críticos.
E. Otras Cuentas
A veces, las bases de datos tienen otras cuentas que no son aplicaciones ni administradores. Estas cuentas están sujetas a los requisitos de privilegios mínimos (véase más abajo). Es esencial mantener una lista de estas cuentas, documentar su justificación y asegurarse de que tengan un acceso mínimo a los datos y ningún privilegio del sistema.
Verificación: Asegúrese de tener una lista actualizada de todas las cuentas de la base de datos, las cuentas activas que se utilizan habitualmente y una clasificación de cada cuenta por tipo. Revise cuidadosamente los privilegios y el acceso de las cuentas que no sean de DBA o de aplicaciones.
F. Personas con Acceso a los Datos
Es esencial mantener una lista actualizada de todas las personas con acceso a datos confidenciales. Esta lista debe incluir a los DBA con privilegios del sistema, los desarrolladores con cuentas en la base de datos de producción, los administradores de aplicaciones con acceso a la cuenta de la aplicación, etc.
Verificación: Compilar o verificar esta lista no es una tarea trivial. Sin embargo, puede elaborarla combinando dos métodos. En primer lugar, identifique las cuentas que tienen acceso a los datos en función de los privilegios del sistema o de los permisos concedidos. En segundo lugar, compruebe que se tienen en cuenta todos los programas y direcciones IP utilizados por esas cuentas confidenciales. Por ejemplo, asegúrese de que todos los programas y direcciones IP utilizados por la cuenta de la aplicación pertenecen a la aplicación o a una de las personas de su lista con acceso a esa cuenta.
3. Listas de Amenazas, Riesgos y Controles
Una práctica de seguridad fundamental consiste en identificar los riesgos y asignar controles. En el mundo de las bases de datos, es habitual que la lista de riesgos sea imprecisa y que muchos de esos riesgos carezcan de un control adecuado. Es fundamental asegurarse de que la lista de riesgos sea realista y esté actualizada. Es igualmente importante abordar cada uno de ellos.
A. Amenazas y Riesgos
Asegúrese de tener una lista actualizada de las amenazas que considera que suponen un riesgo realista. Tenga en cuenta lo siguiente:
- Inyección SQL y otros fallos de las aplicaciones.
- Abuso por parte de los administradores (el 20 % de las infracciones son cometidas por actores internos).
- Robo de credenciales.
- Ransomware.
- Robo de datos.
- Modificación no autorizada.
B. Controles
Asegúrese de disponer de controles contra cada amenaza. Dado que la seguridad de las bases de datos es la última línea de defensa, los riesgos no abordados son una preocupación importante.
4. Controles Pasivos
Los controles pasivos son medidas que se adoptan porque son buenas prácticas, pero es imposible medir su contribución real a la seguridad. Por ejemplo, las políticas de contraseñas que exigen una cierta complejidad. Es imposible saber si evitan un ataque o aportan un valor significativo a la seguridad. Se trata de una buena práctica pasiva que seguimos porque creemos que es una buena idea.
Debido a su naturaleza pasiva, estas buenas prácticas requieren una validación y pruebas periódicas para garantizar que siguen vigentes y funcionan según lo previsto.
A. Política de Contraseñas
Las políticas de contraseñas plantean un delicado equilibrio que debe revisarse periódicamente. Por un lado, exigir una rotación frecuente y contraseñas seguras elimina los riesgos de adivinar contraseñas y explotar credenciales antiguas o robadas. Por otro lado, estas políticas llevan a los usuarios a anotar sus contraseñas, lo que aumenta el riesgo de seguridad de que se roben las credenciales.
Por lo tanto, al revisar las políticas de contraseñas, no solo debe asegurarse de que funcionen según lo previsto, sino también de que se mitigue el comportamiento de los usuarios.
Verificación: pruebe las políticas de contraseñas para asegurarse de que funcionan según lo previsto. Compruebe el comportamiento de los usuarios en respuesta a las políticas y cómo gestionan sus contraseñas.
B. Mínimo Privilegio
El principio del mínimo privilegio exige que los usuarios solo tengan los privilegios necesarios para realizar sus tareas. Sin embargo, en las bases de datos, este principio es ineficaz contra los usuarios principales: los administradores de bases de datos y la aplicación.
Para otros usuarios de las bases de datos, es fundamental validar que no tengan derechos excesivos. Por ejemplo, estos usuarios rara vez necesitan modificar datos. Muchas veces, no necesitan acceder a todos los datos. Esto requiere una revisión cuidadosa y periódica (al menos una vez al año) y un proceso de control de cambios que garantice que todos los cambios sean aprobados.
Verificación: Asegúrese de que los usuarios no tengan privilegios excesivos y de que el proceso de control de cambios sea eficaz. El control y la revisión de los cambios son fundamentales para garantizar que los cambios en los privilegios se validen y aprueben.
C. Control de Cambios
En las bases de datos se producen muchos cambios. Desde cambios en la configuración hasta cambios en el esquema, cambios en los usuarios, permisos y mucho más. Es esencial contar con un proceso de control de cambios para que estos se revisen y aprueben.
Por diversas razones, a veces se producen cambios fuera del proceso de control de cambios. Además, los cambios pueden ser maliciosos, indicativos de un ataque. Por lo tanto, se recomienda añadir un componente activo de revisión de cambios que supervise regularmente los cambios, lo que le permitirá cerrar el ciclo de su proceso de control de cambios.
Verificación: Asegúrese de que dispone de un proceso de control de cambios que todos sigan. Asegúrese también de disponer de una solución de supervisión independiente que le garantice estar al tanto de todos los cambios, ya sean iniciados por el control de cambios o no.
D. Cifrado
El cifrado tiene tres áreas de aplicación en las bases de datos: cifrado de datos en tránsito, cifrado de datos en reposo y cifrado de copias de seguridad.
El cifrado de datos en tránsito (cifrado de red) es fácil de activar y debe estar habilitado. Tiene una sobrecarga baja, protege la comunicación de red con la base de datos y no hay prácticamente ninguna razón para no utilizarlo.
El cifrado de datos en reposo tiene múltiples variaciones. Se puede cifrar a nivel de disco físico, a nivel de sistema de archivos, a nivel de base de datos (TDE) y a nivel de columna. Cada nivel tiene sus propias ventajas y desventajas, pero el principal problema es que este tipo de cifrado es complicado de configurar y gestionar.
El cifrado de datos en reposo se utiliza principalmente cuando lo exigen los requisitos de cumplimiento normativo. Solo es eficaz contra el robo de archivos o unidades físicas. Es ineficaz contra las consultas SQL de los usuarios conectados a la base de datos, que es el método principal para el robo de datos.
Se recomienda encarecidamente el cifrado de las copias de seguridad, y debe asegurarse de que todas las copias de los datos fuera de la base de datos sean seguras.
Verificación: compruebe que el cifrado de la red está activado y que nadie puede conectarse sin cifrado. Asegúrese de que sus copias de seguridad están cifradas. Si no está cifrando los datos en reposo, compruebe que sus requisitos de cumplimiento normativo no lo exigen.
E. Copia de Seguridad
Hacer una copia de seguridad de la base de datos es necesario por razones operativas, pero con la amenaza del ransomware, ahora es aún más crítico. Aunque es casi seguro que se hace una copia de seguridad de la base de datos, no es del todo obvio que las copias de seguridad se hagan correctamente.
A menudo, se descubre que las copias de seguridad eran defectuosas justo cuando se necesitan. Puede tratarse de un archivo que falta, configuraciones incorrectas o varios otros problemas que impiden una restauración satisfactoria.
Es fundamental verificar periódicamente que sus copias de seguridad funcionan y le permiten recuperar correctamente la base de datos.
Verificación: Intente restaurar una copia de seguridad reciente y asegúrese de que la base de datos se inicia y funciona como se espera.
F. Versión y Parche de la Base de Datos
Aunque mantener la última versión y el último parche se considera una buena práctica de seguridad general, no siempre es práctico con las bases de datos. Esto se debe a que aplicar parches o actualizar una base de datos puede tener consecuencias de gran alcance, provocando fallos inesperados en las aplicaciones. Cualquier parche o actualización debe probarse cuidadosamente de antemano para minimizar este riesgo. Además, la aplicación de parches requiere un tiempo de inactividad que puede ser difícil de coordinar.
Sin embargo, debe asegurarse de que el proveedor siga admitiendo la versión de su base de datos. El nivel de parche también debe ser razonablemente reciente y no presentar vulnerabilidades importantes. Las actualizaciones y los parches deben realizarse, pero con un calendario realista o cuando surja una necesidad imperiosa.
Verificación: asegúrese de que su base de datos siga siendo compatible con el proveedor y considere la posibilidad de actualizarla si se acerca su fecha de fin de vida útil. Compruebe que el nivel de parche no sea demasiado antiguo y consulte una base de datos CVE para verificar que no presente vulnerabilidades significativas.
G. Conectividad de Red Limitada
Las bases de datos deben ser accesibles desde los servidores de aplicaciones, las máquinas DBA y las máquinas de un número limitado de otros usuarios que las utilizan. Deben estar lo más aisladas posible de Internet y también lo más aisladas posible de otros ordenadores de la red corporativa. El objetivo es restringir el acceso al número limitado de subredes o dispositivos dentro de la red corporativa que se conectan a la base de datos.
Las configuraciones de red tienden a cambiar, por lo que es fundamental asegurarse de vez en cuando de que la base de datos no se ha conectado accidentalmente a una red no deseada.
Verificación: asegúrese de que no se puede hacer ping a Internet desde el servidor de la base de datos. Además, compruebe desde varios ordenadores de la red corporativa si pueden hacer ping a la base de datos o conectarse al puerto de la base de datos.
H. Herramientas y Aplicaciones de Bases de Datos
Puede existir una vulnerabilidad en las herramientas o aplicaciones que se conectan a la base de datos. Aparte de las aplicaciones principales que gestionan los datos, a menudo se accede a las bases de datos desde diversas aplicaciones para el análisis de datos, la elaboración de informes y otras tareas. También se accede a las bases de datos desde diversas herramientas para la administración, el ajuste del rendimiento, la supervisión, la seguridad, etc.
Verificación: obtenga una lista de todas las herramientas y aplicaciones que se conectan a la base de datos. Asegúrese de que las cuentas que utilizan solo tengan los privilegios mínimos necesarios. Compruebe estas herramientas una por una para asegurarse de que tienen los parches más recientes. Consulte una base de datos CVE para verificar que no tienen vulnerabilidades peligrosas conocidas.
I. Evaluación de Vulnerabilidades
El análisis de evaluación de vulnerabilidades no es muy útil en las bases de datos. Sin embargo, si ha adquirido una solución de análisis de vulnerabilidades, asegúrese de analizar todas sus bases de datos.
Verificación: si dispone de una solución de evaluación de vulnerabilidades, asegúrese de haber realizado recientemente un análisis satisfactorio.
J. Prueba de Penetración
Las pruebas de penetración son un concepto poderoso que ayuda a identificar debilidades y vulnerabilidades de seguridad. Desafortunadamente, hoy en día suelen ser un producto básico, que carece tanto del talento como de la inspiración necesarios para alcanzar su noble objetivo. En lo que respecta a las bases de datos, las pruebas de penetración comerciales suelen ser aún más débiles.
Sin embargo, es probable que su organización cuente con el talento suficiente para hacerlo internamente, y ni siquiera requerirá un presupuesto. Aunque sus administradores de bases de datos no son expertos en seguridad, conocen a la perfección tanto las bases de datos como sus operaciones. Solo se necesita un cambio de perspectiva impulsado por orientación, ejemplos y un poco de imaginación.
Rete a su equipo de administradores de bases de datos a que jueguen al equipo rojo durante un día. Ni siquiera tienen por qué jugar al equipo rojo. Simplemente pueden reflexionar sobre cómo robarían datos, dado todo lo que saben sobre el entorno.
Aunque podría tratarse de un ataque tecnológico, no tiene por qué serlo. Podrían acercarse a un ordenador sin vigilancia a la hora del almuerzo, leer un archivo de contraseñas de una unidad de red, manipular a un ingeniero junior del servicio de asistencia técnica, y mucho más.
Verificación: Intente jugar al desafío «¿cómo podría robar datos hoy si quisiera?» con el equipo de DBA.
K. Educación y Formación
Al final, la seguridad suele depender de las personas. El personal es el eslabón más débil de la cadena de seguridad. Invertir en su personal da muy buenos resultados.
Tenga en cuenta estos aspectos de la educación y la formación del personal:
- Creación de defensas. ¿Saben sus desarrolladores, administradores de bases de datos y demás personal relacionado con las bases de datos cómo crear código seguro (por ejemplo, utilizar variables de enlace), bases de datos seguras y mucho más?
- Prueba de defensas. ¿Saben sus probadores de control de calidad, desarrolladores, administradores de bases de datos y demás personal relacionado con las bases de datos cómo detectar fallos de seguridad? ¿Saben siquiera cómo son para poder reconocerlos? Por ejemplo, un error en la base de datos puede revelar información que dé lugar a un ataque. O que si ciertos caracteres (como la etiqueta) producen un error, puede sugerir una posible vulnerabilidad de inyección SQL.
- Autoprotección y concienciación. ¿Saben sus administradores de bases de datos y demás personal relacionado con las bases de datos cómo identificar y evitar un ataque de phishing? ¿Pueden protegerse a sí mismos y a sus terminales para no proporcionar un punto de entrada a los piratas informáticos?
- Datos confidenciales. ¿El personal de bases de datos es consciente de los datos que usted considera confidenciales? ¿Saben cómo manejar y proteger los datos confidenciales de acuerdo con sus políticas y normas?
La tecnología puede proteger los datos, pero son las personas las que los defienden. Incluso las mejores políticas fracasan cuando los equipos no entienden por qué existen.
La cultura de la seguridad no se construye de la noche a la mañana, sino que se va consolidando con el tiempo. La formación continua y los debates sobre seguridad pueden crear una cultura de la seguridad en la que esta se integre en todo desde el principio.
5. Controles Activos
Los controles activos son controles que reaccionan ante la actividad. También pueden tomar medidas, pero siempre proporcionan información. Por ejemplo, pueden generar alertas e informes sobre la actividad que se ha producido. También pueden proporcionar capacidades preventivas y bloquear la actividad antes de que se produzca.
Dado que la seguridad de una base de datos consiste, en última instancia, en controlar la actividad, estas son las herramientas principales y más eficaces a su disposición. Los controles pasivos tienen como objetivo dificultar la ejecución de los ataques, pero solo los controles activos pueden detectarlos o bloquearlos.
Hay muchas formas de analizar la actividad para lograr controles eficaces, pero los siguientes aspectos principales deben cubrirse de alguna manera.
A. Control de DBA
Los DBA y otras cuentas con privilegios tienen acceso ilimitado a todos los datos de la base de datos. Estas cuentas suponen una amenaza tanto por el abuso interno como por el robo de credenciales, por lo que controlarlas es de suma importancia.
Estas cuentas son difíciles de controlar por varias razones, entre las que destaca el hecho de que los DBA suelen gestionar los controles de seguridad. Por lo tanto, las soluciones que controlan a los DBA deben ser resistentes a la manipulación de los DBA, como desactivar la auditoría o eliminar los datos de auditoría.
Existen diversos controles de actividad contra los DBA, como por ejemplo:
- Controles de detección. Por ejemplo, informar sobre la actividad de los DBA.
- Controles preventivos. Por ejemplo, impedir el acceso de los DBA a datos confidenciales.
- Controles de separación de funciones. Por ejemplo, ciertas tareas requieren que los DBA dispongan de un código de autorización del personal de seguridad.
Verificación: evalúe la eficacia de sus controles sobre los DBA y las cuentas con privilegios. Asegúrese de controlar todas estas cuentas (enumeradas en la sección 2c). Considere si sería capaz de detectar o prevenir un abuso de privilegios por parte de un DBA. Considere si sería capaz de detectar o prevenir actividades maliciosas desde una cuenta privilegiada robada.
B. Control de Cuentas de Aplicaciones
Las aplicaciones ejecutan la mayor parte de la actividad SQL de la base de datos. Son difíciles de controlar debido a los miles de millones de SQL que ejecutan. Sin embargo, la cuenta de la aplicación tiene acceso a todos los datos y supone una amenaza significativa que no se puede ignorar.
El riesgo de la cuenta de la aplicación se origina en tres fuentes principales:
- Las vulnerabilidades de las aplicaciones, como la inyección SQL, suponen una amenaza importante y bien conocida que no debe ignorarse. Estas amenazas deben detectarse en lugar de prevenirse. Esto se debe a que los controles preventivos de la actividad de las aplicaciones pueden provocar fallos inesperados en las mismas, con el consiguiente riesgo de corrupción de los datos.
- Abuso de la cuenta de la aplicación por parte de un administrador de aplicaciones, desarrollador u otro actor interno. Los actores internos son responsables de más del 20 % de las violaciones de datos.
- Robo de credenciales de la aplicación. Las credenciales de las aplicaciones son especialmente vulnerables, ya que se almacenan en la propia aplicación.
Verificación: asegúrese de que dispone de controles para detectar exploits de vulnerabilidades de aplicaciones (como la inyección SQL). Compruebe que puede detectar o prevenir el uso indebido de cuentas de aplicaciones, como el abuso por parte de un administrador de aplicaciones o el robo de credenciales por parte de un hacker.
C. Control de los Usuarios con Acceso a la Producción
Las bases de datos suelen tener usuarios distintos de los administradores de bases de datos o la aplicación. Estos usuarios deben tener los privilegios mínimos necesarios, pero suelen tener acceso a datos confidenciales. Independientemente de los permisos concedidos, la escalada de privilegios es un riesgo para cualquier persona con acceso a la base de datos.
Por lo tanto, es una buena práctica supervisar a todos los usuarios de la base de datos. Ya sean desarrolladores, analistas de datos o cualquier otra persona, todas las cuentas suponen un riesgo de uso indebido y robo.
Verificación: asegúrese de que dispone de controles de detección o prevención para todos los usuarios de la base de datos. Compruebe que esta lista esté actualizada e incluya todas las cuentas que necesita controlar.
D. Control de Datos Confidenciales
El acceso a datos confidenciales es la actividad más sensible de la base de datos. El control de esta actividad es fundamental para un control eficaz de las actividades. Aunque es fundamental, puede resultar complicado de llevar a cabo debido al volumen potencialmente elevado de actividad SQL.
Verificación: asegúrese de disponer de una lista actualizada de todas las tablas confidenciales. Valide que dispone de controles eficaces que señalen el acceso sospechoso a información confidencial.
E. Controles Detectivos y Preventivos
Los controles de actividad detectivos y preventivos tienen sus propias ventajas e inconvenientes. Los controles preventivos detienen la actividad maliciosa, mientras que los controles detectivos son más sensibles y más propensos a detectar un ataque o una infracción.
Prevenga lo que pueda y detecte el resto: con la combinación adecuada de controles detectivos y preventivos, puede intentar prevenir en la medida de lo posible y detectar los ataques que no puede detener.
Verificación: asegúrese de que dispone de suficientes controles detectivos para alertarle de una infracción o un intento de infracción. Intente aumentar el número de controles preventivos tanto como sea posible sin falsos positivos.
F. Control de Sesiones Cifradas
Las sesiones cifradas suponen una amenaza específica, ya que muchas soluciones de control de actividad no pueden supervisarlas. Un cliente de base de datos puede solicitar una sesión cifrada, independientemente de si la base de datos exige el cifrado o no. Por lo tanto, es imprescindible asegurarse de que su solución de control de actividad actual pueda gestionar sesiones cifradas.
Verificación: asegúrese de que puede controlar las sesiones conectadas con cifrado (SSL).
G. Detección de Anomalías
Las bases de datos ejecutan miles de millones de SQL, lo que hace imposible revisar cada uno de ellos manualmente. Por lo tanto, es imprescindible contar con una automatización que pueda detectar actividades sospechosas o anómalas.
La detección de anomalías también es necesaria para identificar pequeños cambios en el perfil de actividad que pasarían desapercibidos en una revisión humana. Por ejemplo, cuando un usuario se conecta desde una dirección IP diferente.
Pero, ¿qué es una anomalía? Una anomalía puede ser cualquier cambio en el perfil de comportamiento de la actividad de la base de datos. Por ejemplo, un usuario que se conecta desde una ubicación diferente, accede a datos diferentes, ejecuta SQL diferentes o recupera más filas. La detección de anomalías debe adaptarse a la base de datos específica para que solo se centre en los cambios que no se producen con frecuencia.
Cuando se activan las alertas de anomalías, es posible que se produzcan algunos falsos positivos de vez en cuando. Esto es señal de que el sistema de seguridad está activo y funciona correctamente, y que está calibrado con la sensibilidad suficiente para detectar los inevitables cambios ocasionales en el perfil de actividad.
A medida que cambia el perfil de actividad de la base de datos, es necesario ajustar las anomalías de vez en cuando para que sigan cubriendo toda la actividad y mantengan la sensibilidad suficiente.
Verificación: asegúrese de que dispone de mecanismos para controlar grandes volúmenes de actividad. Compruebe que recibe alertas sobre pequeños cambios en el perfil de actividad. Compruebe que recibe alertas falsas positivas relevantes de vez en cuando. Asegúrese de ajustar las anomalías para que se adapten al perfil de actividad actual de su base de datos. Confirme que cubre toda la actividad de la base de datos.
H. Capacidades Forenses
Cuando se produce un incidente de seguridad o una infracción, se le pedirá que lleve a cabo una investigación forense para averiguar qué ha ocurrido. Sin embargo, si espera hasta ese momento, es poco probable que disponga de la información necesaria para la investigación.
Por lo tanto, es imprescindible realizar pequeñas investigaciones de forma rutinaria para descartar eventos falsos positivos ocasionales. Esa es la única manera de asegurarse de que dispone de todos los datos y capacidades necesarios para cuando llegue el momento.
Verificación: asegúrese de realizar investigaciones forenses de forma rutinaria para descartar falsos positivos. Verifique que dispone de toda la información y las capacidades necesarias para investigar cualquier evento.
6. Controles Fuera de Producción
Las bases de datos fuera de producción existen en entornos utilizados para desarrollo, pruebas (control de calidad), formación y otros fines. Estas bases de datos suelen contener datos confidenciales copiados de la producción y suponen una amenaza importante porque:
- Rara vez son seguras.
- Muchas personas que acceden a ellas regularmente no tienen autoridad para ver datos confidenciales.
- Estos entornos tienen versiones de software, configuraciones y controles de seguridad fluidos. Los entornos de desarrollo y pruebas cambian constantemente.
Las bases de datos que no son de producción son una pesadilla para la seguridad. Suponen una amenaza tanto interna como externa. La solución más realista para protegerlas es asegurarse de que no contengan información confidencial. El proceso de eliminación de datos confidenciales se denomina enmascaramiento de datos, también conocido como ofuscación, anonimización y otros términos.
A. Localizar Datos Confidenciales Fuera de la Producción
Localizar todos los datos confidenciales fuera de la producción puede ser un reto. Sin embargo, es imprescindible obtener y mantener una lista de todos estos entornos. Existen tres métodos principales, y recomendamos utilizar una combinación de ellos:
- Escaneo de red. Localice todas las bases de datos de la red y haga un recuento de cada una de ellas (de producción y no destinadas a la producción).
- Pregunte a los administradores de bases de datos de producción. Cuando se copian datos fuera de producción, normalmente lo hace el administrador de bases de datos de producción responsable de esa base de datos. Es probable que sepan dónde se copian los datos.
- Pregunte a los equipos de desarrollo/control de calidad. Estos equipos son los principales usuarios de los datos fuera de producción y es probable que sepan dónde se encuentran.
Verificación: asegúrese de saber dónde se encuentran los datos confidenciales fuera de las bases de datos de producción (pruebas, desarrollo, formación, etc.). Es algo que cambia con el tiempo y requiere un redescubrimiento ocasional.
B. Enmascarar las Bases de Datos Confidenciales Fuera de Producción
Los datos fuera de producción deben enmascararse. El enmascaramiento plantea varios retos, como por ejemplo:
- Localizar los datos confidenciales dentro de las bases de datos.
- Diseñar una política de enmascaramiento que equilibre el ocultamiento de la información confidencial y la conservación de su utilidad para los equipos de control de calidad o desarrollo.
- Conseguir que el proceso de enmascaramiento funcione bien y de forma eficiente.
Verificación: asegúrese de localizar todos los datos confidenciales dentro de esas bases de datos. Asegúrese de que los datos estén correctamente enmascarados y no expongan información confidencial. Valide con el equipo de desarrollo o control de calidad que están utilizando los datos enmascarados y que están satisfechos con ellos. Debido a problemas de calidad de los datos, esos equipos suelen volver a utilizar los datos originales.
Reflexiones Finales
Puede parecer que la seguridad de las bases de datos se compone de muchas piezas, pero es imperativo abordar al menos algunos de cada objetivo estratégico. Es mejor hacer un poco de todo que alcanzar algunos objetivos por completo e ignorar otros.
Esta lista de verificación es su hoja de ruta hacia un programa de seguridad estructurado. Al abordar estos objetivos anualmente, usted cambia su defensa de una lista de tareas reactivas a un proceso proactivo, organizado y continuo. Comience la evaluación hoy mismo: sus datos no pueden esperar.
Si tiene alguna idea, pregunta o necesita ayuda adicional, no dude en ponerse en contacto con nosotros. ¡Estamos aquí para ayudarte!
Comentarios
Sugerencia de IA
¿Preguntas?
Si tenes alguna pregunta o comentario, no dude en hacérnoslo saber. Estaremos encantados de escucharles
