La creación de reflejo de la base de datos de SQL Server permite mantener una copia, o reflejo, de una base de datos de SQL Server en un servidor en espera. El reflejo garantiza que en todo momento existen dos copias distintas de los datos, lo que proporciona una alta disponibilidad y una completa redundancia de datos. El proveedor de datos de .NET para SQL Server ofrece compatibilidad implícita con la creación de reflejo de la base de datos; así el desarrollador no tiene que realizar ninguna acción ni escribir ningún código una vez que se ha configurado para una base de datos de SQL Server. Además, el objeto SqlConnection admite un modo de conexión explícita que permita proporcionar el nombre de un servidor asociado de conmutación por error en la propiedad ConnectionString.
La siguiente secuencia simplificada de eventos tiene lugar para un objeto SqlConnection que identifica una base de datos configurada para el reflejo: 1. La aplicación cliente se conecta correctamente a la base de datos principal y el servidor devuelve el nombre del servidor asociado, el cual se almacena en caché en el cliente.
2. Si el servidor que contiene la base de datos principal da error o se interrumpe la conectividad, se pierde el estado de la conexión y de la transacción. La aplicación cliente intenta restablecer la conexión a la base de datos principal pero no lo consigue.
3. La aplicación cliente intenta entonces de forma transparente establecer una conexión a la base de datos de reflejo del servidor asociado. Si lo consigue, la conexión se redirecciona a la base de datos de reflejo, que se convierte entonces en la nueva base de datos principal.
El documento nos menciona varias capas tecnológicas,
que los técnicos al momento de la selección de software entran en discusión,
porque cada uno tiene su preferido. Pero ya muy aparte de las preferenciashabla de SQL Server y Oracle que se comparan
entre ellos su capacidad de soportar aplicaciones, su mercado y su nivel
empresarial.
Muchas aplicaciones se basan más en las
bases de datos de Oracle, esto es en base a los puntos de vista de la
seguridad, la fiabilidad y entre otros.
Nos dice que Analistas muy importantes
comparan las bases de datos de Oraclea SQLy encontraron que es más rápido, fiable y más
económico. Encontraron que Oracle es un 47 por ciento más rápido que cualquier
servidor de SQL y hasta cuesta 20% menos. Oracle también agilizado la instalación
y la gestión de datos a si como automatizar el almacenamiento y la memoria.
La
elección de una aplicación empresarial que está diseñado exclusivamente para
una sola base
de datos debe ser atractivo debido a que la aplicación puede ser optimizado
para tomar ventaja
de todo lo que la base de datos Oracle tiene para ofrecer, entregar más potente
•es un conjunto de tecnologías destinadas a la copia y distribución de datos y objetos de base de datos desde una base de datos a otra, para luego sincronizar ambas bases de datos y mantener su coherencia.
Esta técnica permite a la base de datos realizar un espejo en línea sobre otra base de datos que puede estar localmente en otro servidor o con acceso remoto utilizando Internet. Esta característica satisface los requerimientos de sucursales donde necesitan tener en línea y en otro servidor principal, las transacciones de todas las sucursales, en caso que no este disponible la conexión se suspende la replicación y la base de datos de la sucursal no se paraliza. Al restablecerse la conexión se actualizan las transacciones en la cola de replicación. Antiguamente estos requerimientos eran solventados por procesos de transmisión de datos al finalizar el día mediante el protocolo FTP.
Modelo de Replicacion
El modelo de Replicación que usa SQL es el de “Publicador – Suscriptorâ€. Este modelo consiste en Publicadores,Suscriptores y Distribuidores; las publicaciones y los artÃculos, y las suscripciones por tirón o empuje. Además incorpora agentes de administración como Agente de Instantánea, Agente Lector de Registro, Agente de Distribución, y Agente de Mezcla. Todos los agentes pueden funcionar debajo del agente del servidor del SQL y se pueden administrar completamente por el Administrador del Servidor de SQL.
Beneficios de la réplica de Datos en un DBMS
Disponibilidad.-El modo en que la replicación incrementa la disponibilidad de los datos para los usuarios y aplicaciones.
· Fiabilidad.- Al haber múltiples copias de los datos disponibles en el sistema, se dispone de un mecanismo excelente de recuperación cuando existan fallos en nodos.
· Rendimiento.- Se mejora para las transacciones de consulta cuando se introduce la replicación en un sistema que estuviera aquejado de sobrecarga de recursos centralizados.
· Reducción de la carga.- Modo en que se utiliza la replicación para distribuir datos en ubicaciones remotas
· Copia de seguridad:En condiciones normales, una base de datos replicada de forma correcta es válida como copia de seguridad.Además se puede realizar copias de seguridad usando un servidor esclavo para así no interferir al servidor maestro.
· Mejorar la escalabilidad:Podríamos configurar nuestras aplicaciones para balancear las consultas de lectura (SELECT) entre los servidores replicados.
· Alta disponibilidad:En aplicaciones y entornos en donde sólo se requieren lecturas, podríamos configurar nuestras aplicaciones para balancear las consultas de lectura (SELECT) entre los servidores replicados de manera que si uno se cae se continue prestando servicio.
· Las replicas locales constituyen una ayuda especialmente útil cuando se desea trabajar en una computadora que en ocasiones no estará conectada a la red donde se encuentra el servidor en el que reside el curso.
Permite distribuir datos entre diferentes ubicaciones y entre usuarios remotos o móviles mediante redes locales y de área extensa, conexiones de acceso telefónico, conexiones inalámbricas e Internet.
La réplica exacta de las bases de datos permite también eliminar los paros diarios para las copias de seguridad y en general, todos los paros planificados, tales como los necesarios para mantenimientos o cambios de versiones del sistema operativo.
Ejemplo:
MySQL: Replicación de bases de datos en MySQL
Introducción.
El proceso de replicación de una base de datos consiste en replicar las consultas de actualización (tanto DML como DDL) en una base de datos maestra (master) sobre una o varias bases de datos esclavas (slave), de manera que tengamos una copia de las mismas a lo largo del tiempo.
MySQL soporta replicación unidireccional asíncrona, es decir, las consultas de actualización ejecutadas en el maestro son replicadas en los servidores esclavos. Esta replicación se realiza de forma transparente. Además es instantánea si los servidores esclavos están levantandos y en estado de replicación.
Antes de continuar hay que tener claro que las modificaciones de datos siempre deben realizarse en el maestro, si quereis poder modificar los datos en cualquier base de datos tendreis que iros a otras soluciones como MySQL Cluster.
Atención:
El presente documento se centra en un escenario en donde la replicación se realiza desde cero, es decir, el maestro y el esclavo no estaban configurados previamente para realizar replicaciones.
Debe saber que si por algún motivo hay errores en la replicación hay que realizar otros pasos y tener más conocimientos más profundos de como funciona todo esto.. En estos casos, deberá documentarse más o recurrir a expertos.. si lo desea puede llamarnos.
¿Para qué nos puede interasar replicar bases de datos?
La replicación es útil para:
Copia de seguridad:En condiciones normales, una base de datos replicada de forma correcta es válida como copia de seguridad.
Además se puede realizar copias de seguridad usando un servidor esclavo para así no interferir al servidor maestro.
Mejorar la escalabilidad:Podríamos configurar nuestras aplicaciones para balancear las consultas de lectura (SELECT) entre los servidores replicados.
Podríamos usar herramientas como MySQL Proxy para balancear las consultas de lectura entre los servidores replicados y enviar las consultas de actualización de datos al maestro.
Alta disponibilidad:En aplicaciones y entornos en donde sólo se requieren lecturas, podríamos configurar nuestras aplicaciones para balancear las consultas de lectura (SELECT) entre los servidores replicados de manera que si uno se cae se continue prestando servicio.
Conceptos necesarios de conocer relacionados con la replicación en MySQL
A continuación exponemos algunos conceptos necesarios para comprender algo mejor todo esto...
El Log Binario
El log binario es un archivo binario gestionado por el servidor de base de datos en el que se registran todas las sentencias SQL de modificación de datos o estructura.
En el caso de la replicación es importante saber que cada servidor esclavo se conecta al servidor maestro y le solicita que le envie las sentencias registradas en los logs binarios a partir de una posición, para ello, cada esclavo mantiene un archivo a modo de índice en donde registra la posición actual de la replicación.
Gracias a esto, podemos detener el esclavo (STOP SLAVE), que haya un corte de red, etc.. de manera que cuando se vuelva a iniciar la replicación (START SLAVE) o se reestablezca la comunicación... Pase el tiempo que pase) el esclavo solicitará al maestro todas las sentencias a ejecutar desde su estado actual y las irá ejecutando secuencialmente de manera que en cuestión de segundos ambos servidores tendrán las bases de datos con el mismo contenido y estructura.
Master
(Solicita Log Binario desde la posición X) « « « « « « « « « « « « « « « «
El log binario por defecto está ubicado en la carpeta <MYSQL_HOME>/data y se llama igual que la máquina con el sufijo -bin y un número como extensión. Ejemplos: pccarlos-bin.00001, pccarlos-bin.00002, pccarlos-bin.00003
Pasos para poner en marcha la replicación
A continuación vamos a exponer los pasos a realizar la replicación de una base de datos bd_autentia en un único servidor esclavo. Si quisieramos configurar más esclavos, los pasos a realizar serían los mismos sobre cada uno de los esclavos.
Creamos de un usuario MySQL en el servidor maestro con privilegios de replicación
El servidor esclavo se autenticará frente al servidor maestro como un usuario normal.
Para crear el usuario debemos ejecutar desde la consola de comandos de mysql las siguientes sentencias SQL:
CREATE USER '<replication_user>'@'<slave_address>' IDENTIFIED BY '<replication_user_password>'
GRANT REPLICATION SLAVE ON *.* TO '<replication_user>'@'<slave_address>'
Con la sentencia anterior el usuario sólo tendría permiso de acceso desde la máquina <slave_address>, en caso de no requerir esta medida de seguridad puedes sustituir el comodin % por el parámetro <slave_address>.
Configuración del servidor maestro
Deberemos agregar las siguientes lineas al final del archivo de configuración del servidor MySQL, por defecto: <MySQL_HOME>/my.ini
# Identificador único del servidor MySQL dentro de todos los servidores implicados en la replicación.
server-id=1
# Al especificar el parámetro log-bin estamos activando el log binario.
# No especificamos un valor para el parámetro de configuración (por defecto será <nombre_maquina>-bin).
log-bin=
# El log binario sólo tendrá las actualizaciones realizadas sobre la base de datos "bd_autentia"
# Si además quisieramos replicar otras bases de datos, duplicariamos este parámetro para cada base de datos.
binlog-do-db=bd_autentia
Configuración del servidor esclavo
Deberemos agregar las siguientes lineas al final del archivo de configuración del servidor MySQL, por defecto: <MySQL_HOME>/my.ini
# Identificador único del servidor MySQL dentro de todos los servidores implicados en la replicación.
server-id=2
# Nombre del archivo binario que almacena las instrucciones pendientes de ejecutar, por defecto: <host_name>-relay-bin.index
relay-log=
# Nombre o dirección IP del maestro.
master-host=<master_address>
# El esclavo se conecta a través de un usuario al maestro. Identificador del usuario
master-user=<replication_user>
# El esclavo se conecta a través de un usuario al maestro. Contraseña del usuario
master-password=<replication_user_password>
# Número de segundos que esperará el esclavo para reintentar conectarse al maestro en caso de una perdida de conexión.
master-connect-retry=50
# Número de reintentos de reconexión
master-retry-count=5000
Realizamos una copia de seguridad de la base de datos del maestro sobre el servidor el esclavo
Desde la consola ejecutamos los siguientes comandos:
[maestro]: <MYSQL_HOME>/bin/mysql -u root --password=<contraseña> -e "FLUSH TABLES WITH READ LOCK" Para limpiar las caches y bloquear el acceso de cualquier aplicacion a la base de datos.
[maestro]: <MYSQL_HOME>/bin/mysqldump --u root --password=<contraseña> --opt bd_autentia > backup.sql Realizamos una copia completa de la base de datos en el archivo backup.sql.
[esclavo]: <MYSQL_HOME>/bin/mysql --user=root --password=<contraseña> bd_autentia < backup.sql Para restaurar la copia de seguridad en el esclavo.
[esclavo]: <MYSQL_HOME>/bin/mysqladmin -u root --password=<contraseña> shutdown Detenemos el servidor esclavo
[maestro]: <MYSQL_HOME>/bin/mysqladmin -u root --password=<contraseña> shutdown Detenemos el servidor maestro (Se desbloquearán las tablas de las bases de datos previamente bloquadas)
[esclavo]: <MYSQL_HOME>/bin/mysqld-nt --defaults-file="<MYSQL_HOME>\my.ini" MySQL Iniciamos el servidor el cual tomará la nueva configuración.
[maestro]: <MYSQL_HOME>/bin/mysqld-nt --defaults-file="<MYSQL_HOME>\my.ini" MySQL Iniciamos el servidor el cual tomará la nueva configuración.
Probando la replicación
En el servidor esclavo ejecute el comando SHOW SLAVE STATUS y observe que el mensaje que le muestra es un mensaje que indica que está esperando eventos del maestro...
Modifique algo en el maestro y verifique que instantaneamente se replica en el esclavo.
Detenga el esclavo durante un tiempo, realize cambios (cree tablas, modifique registros..) en el maestro e inicie el esclavo. En cuestion de milisegundos ambas bases de datos deberían de ser iguales.
Diferencia entre Replica y Espejeo
Espejo: Esta guardado guardado en el disco
Replica: No esta guardado en el disco si no en los servidores
Se conoce como copia espejo (en inglés data mirroring) al procedimiento de protección de datos y de acceso a los mismos en los equipos informáticos implementado en la tecnología de RAID1.
Consiste en la idea básica de tener dos discos duros conectados. Uno es el principal y en el segundo se guarda la copia exacta del principal, almacenando cualquier cambio que se haga en tiempo real en las particiones, directorios, etc, creando imágenes exactas, etc.
De esta forma se consigue tener 2 discos duros idénticos y que permiten, si todo está bien configurado, que ante el fallo del disco principal, el secundario tome el relevo, impidiendo la caída del sistema y la pérdida de los datos almacenados.
En el "mirroring" en una base de datos tenemos un servidor principal/primario que mantiene la copia activa de la base de datos (BD accesible). Otro servidor de espejo que mantiene una copia de la base de datos principal y aplica todas las transacciones enviadas por el Servidor Principal (en el que no se podrá acceder a la BD). Y un servidor testigo/arbitro que permite recuperaciones automáticas ante fallos, monitoriza el servidor principal y el de espejo para en caso de caída cambiar los roles (servidor opcional, no es obligatorio).
Beneficios del espejeo
Además de proporcionaruna copia adicional delosdatos con el finderedundancia en caso defallo de hardware, la duplicación de discopuede permitir quecada discoseaccedapor separadopara los propósitosde lectura. En determinadascircunstancias estopuede mejorarsignificativamente el rendimientoya que el sistemapuede elegirpara cadalectura que discopuedebuscarmásrápidamente alos datos requeridos.Esto es especialmenteimportantecuandohay varias tareasque compiten porlos datosen el mismo disco, y el "trashing"(dondeel cambio entretareasocupamás tiempo quela tarea en sí) se puede reducir. Estaesuna consideración importante enlas configuraciones de hardwarequefrecuentemente tienen acceso alosdatos en el disco.
Enalgunas implementaciones, eldisco reflejadose puede dividirfueray se utilizapara lacopia de seguridadde datos, permitiendo que elprimer discopara permanecer activos. Sin embargo,la fusión de losdos discossepuede requerir unperíodo de sincronizaciónen su casoescribirla actividadI/Ohaocurridocon eldisco duplicado.
Creación de espacios de disco con espejo
Una vez preparados los discos, para crear el RAID, y si hemos seguido la misma estructura de mi ejemplo, usaremos las siguientes órdenes, suponiendo que los discos nos los ha identificado como sda, sdb, sdc y sdd:
La primera orden nos creará un RAID de tipo RAID1 con sólo 2 componentes activos, empleando para ello la primera partición de cada disco. Como le indicamos menos dispositivos de raid (2) que dispositivos físicos, lo que hace es poner los otros dos como spares.
La segunda orden nos creará un RAID5 con la tercera partición de todos los discos indicados. En este caso, el parámetro --raid-devices=4 es superfluo y se podría omitir, ya que si no decimos nada sobreentiende que queremos usar todos los discos.
Recomendaciones
Use una copia de seguridad completa muy reciente o una copia de seguridad diferencial reciente de la base de datos principal.
Si se programa un trabajo de copia de seguridad de registros para que se ejecute muy a menudo en la base de datos principal, puede que sea necesario deshabilitar el trabajo de copia de seguridad hasta que se haya iniciado la creación de reflejo.
Si es posible, la ruta de acceso (incluida la letra de unidad) de la base de datos reflejada debería ser idéntica a la de la base de datos principal. Si las rutas de acceso de archivo deben ser diferentes (por ejemplo, si la base de datos principal se encuentra en la unidad 'F:' pero el sistema reflejado no tiene unidad F:), se debe incluir la opción MOVE en RESTORE STATEMENT.
Ejemplo
Configurar Mirroring en SQL Server
Database Mirroring aparece en la versión 2005 y es la evolución de Log Shipping. Tal como su nombre lo indica, sirve para tener una base de datos “espejada” en otro servidor. Puede trabajar de 3 Formas:
modos de funcionamiento | Fuente: guillesql.es
De foma más simple, la principal diferencia entre la configuración síncrona o asíncrona es:
De modo síncrono, el servidor principal espera a que las transacciones hagan commit en el servidor espejo para poder continuar.
De modo asíncrono, el servidor principal trabaja sin esperar al secundario.
Algunas diferencias entre LogShipping y Mirroring (Hay muchas más, pero aquí están las que más me llaman la atención):
Database Mirroring es capaz de configurar una conexión segura entre ambos puntos.
Database Mirroring provee la capacidad de hacer failover automático.
Log Shipping no hace ninguna de las dos anteriores.
Para configurar Database Mirroring se puede hacer a través del asistente o se puede hacer a través de instrucciones en t-sql. En este caso, utilizaremos el asistente para ahorrar tiempo.
Antes de partir la configuración nos debemos asegurar que la base de datos esté en modo de recuperación Full y debemos crear un respaldo de la base de datos del servidor primario y restaurarla con la opción WITH NORECOVERY en el servidor que será espejo.
Esta configuración requiere algunas configuraciones en el firewall de ambos equipos. En el servidor principal y en el espejo se debe abrir el puerto TCP 5022. Ahora, si se decide usar otro puerto, hay que estar seguro que el puerto está disponible y se puede abrir para las conexiones.
Una vez que se tiene la configuración previa lista, se hace el asistente que permitirá configurar el mirroring
Abrir asistente
En la ventana principal se debe iniciar el asistente
Ventana Principal
Se inicia el asistente
Inicio del asistente
Se puede o no configurar un testigo. El testigo servirá para poder tener un failover automático. En este artículo no configuraré un testigo.
Configuracion del testigo
Configuración del equipo principal. Se puede cambiar el puerto (pero recuerden que ya habíamos abierto el puerto 5022). Además, se puede seleccionar si se quiere cifrar o no la conexión.
Configuracion del primario
Para la configuración del secundario es necesario conectarse antes (recordar abrir el puerto 1422 en el secundario). La ventana de configuración es exactamente igual al primario.
Configuracion del Secundario
El servicio debe estar configurado con una cuenta de dominio. Se debe indicar la cuenta del servicio del servidor primario y del espejo.
Cuentas de servicio
Para Finalizar:
Finalizar
Al momento de finalizar, se inicia el proceso de configuración del mirroring. Si aparece este mensaje, es porque está todo bien
Progreso de Configuracion
Al terminar el asistente, aparecerá una ventana así en la cual nos preguntará si queremos iniciar Mirroring al tiro o no. En mi caso, no configuré el testigo, por lo que no activaré el mirroring para hacer una configuración antes de partir.
Iniciar mirroring
Antes de comenzar el mirroring, lo configuré como asíncrono y luego inicié el mirroring
Mirroring Funcionando
Ejemplo
ESPEJEO
Es una configuración donde dos o tres servidores de dase de datos, ejecutándose en equipos independientes, cooperan para mantener copias de la base de datos y archivo de registro de transacciones (log). Es decir, tanto el servidor primario como el servidor espejo mantienen una copia de la base de datos y el registro de transacciones
1 . Servidor Principal
Conecta las aplicaciones y recibe las transacciones
2 . Servidor Mirror(Esclavo)
Recibe los logs de transacciones del Servidor Principal y las aplica en la base de datos reflejada
3 . Servidor Witness (Opcional)
Monitoriza el estado en que se encuentran los servidores Principal y Mirror
1.- CREAMOS UNA BASE DE DATOS LLAMADA PC, CREAMOS UNA TABLA LLAMADA pc
2.- AQUÍ SE CREA EL LOG BINARIO DEL ARCHIVO MY.INI
3.- AQUÍ SE APAGAMOS Y PRENDIMOS MYSQL PARA REINICIARLO PARA QUE APLIQUE LOS CAMBION RECIEN ESTABLECIDOS.
4.- AQUÍ SE PONEN LOS COMANDOS PARA REPLICAR EL SERVIDOR ESCLAVO , TAMBIEN SE CREA EL USUARIO QUE VAMOS AUTILIZAR PARA REALIZAR LA REPLICACION, ASI MISMO SE LE ASIGNAN TODOS LOS PRIVILEGIOS AL USUARIO CREADO.
5.-DENTRO DEL CODIGO SE LE ASIGNAN LOS PERMISOS A LA BASE DE DATOS CREADA, AHORA CON EL COMANDO SHOW MASTER STATUS SE MUESTRA EL STATUS DEL SERVIDOR MASTER.
6.- SE CREA EL BACKUP DE LA BASE DE DATOS, ES DECIR, LA COPIA DE RESERVA PARA RESPALDAR LA INFORMACION DE LA BASE DE DATOS.
7.- AQUÍ SE MUESTRA CUANDO SE CREO EL ARCHIVO RESERVA.SQL
8.- SE CREA LA BASE DE DATOS EN LA OTRA COMPUTADORA QUE ES EL SERVIDOR ESCLAVO.
9.- ABRIMOS EL ARCHIVO RESERVA.SQL QUE SE ENCUENDRA EN EL DISCO LOCAL EN LA BASE DE DATOS CREADA EN LA COMPUTADORA ESCLAVO.
10.- AQUÍ SE ASIGNA EN EL ESCLAVO LOS DATOS DEL SERVIDOR MAESTRO
11.- SE APAGA Y SE PRENDE MYSQL PARA QUE APLIQUE LOS CAMBIOS REALIZADOS.
12.- PARAMOS EL SERVIDOR ESCLAVO PARA DARLE LA CONFIGURACION NECESARIA PARA QUE FUNCIONE CORRECTAMENTE, SE CREA LA INSTRUCCIÓN CHANGE MASTER CON UNA IP , USUARIO, PASSWORD Y EL ARCHIVO LOG QUE SE CREO EN EL MASTER Y LA POSICION DEL ARCHIVO.
13.- INICIAMOS EL SERVIDOR Y UTILIZAMOS LA BASE DE DATOS CREADA EN ESTE CASO pc.
14.- AQUÍ SE LE INSERTAN DATOS A LA TABLA PC.
15.- POR ULTIMO SE MUESTRA EL DATO QUE INGRESAMOS A LA TABLA PC CON LA SENTENCIA SELECT * FROM.
En el articulo del niño, no se puede creer que una pagina gubernamental pueda hackearlo un niño de tan solo 12 años, se nota como las soluciones de los problemas de seguridad no esta muy actualizado. deberiamos de enfocarnos mas en la seguridad de las bases de datos.
Problemas
Inundacion Servidores con peticiones de acceso para bloquearlos
alteracion de informacion para cambiar pagina de inicio
1.- Nombre de usuario/password en blanco, por defecto o débil.
No es nada raro conseguir en el día a día pares de usuario/password como sa/1234, esta el la primera línea de defensa y un punto fundamental de la armadura de nuestras bases de datos.
SOLUCION: Es importante hacer revisiones periódicas de credenciales. y cambios Continuos de Contrasenas.
2.- Inyecciones SQL.
Cuando la plataforma de base de datos falla para desinfectar las entradas, los atacantes son capaces de ejecutar las inyecciones SQL de forma similar a como lo hacen en los ataques basados en Web, lo que les permite elevar sus privilegios y obtener acceso a una amplia gama de funcionalidades. Muchos de los proveedores han dado a conocer soluciones para evitar estos problemas, pero no servirá de mucho si los parches no se aplican o no se toman los correctivos correspondientes.
SOLUCION: Se pueden evitar estos ataques en muchos lenguajes distintos, e incluso hay lenguajes que por defecto hay que complicarse para que exista este fallo de seguridad, pero lo que tenemos que saber es que donde hay una consulta SQL puede haber una brecha de seguridad, por lo que recomiendo prestar un mínimo de atención con estos ataques que están tan de moda, y si alguno quiere comentar como hacerlo de otra forma o con otro lenguaje puede hacerlo en los comentarios, o comentar donde hay otros ejemplos.
3.- Preferencia de privilegios de usuario por privilegios de grupo.
Las organizaciones necesitan garantizar que los privilegios no se les den a los usuarios por asignación directa quien finalmente los recogerá como conserjes recogen las llaves en sus llaveros. Rothacker recomienda que los usuarios sólo reciban privilegios por parte de grupos o funciones y sean manejados colectivamente. De esta forma será más fácil eliminar derechos a un usuario con simplemente eliminarlo del grupo, sin que queden derechos ocultos u olvidados asignados a dicho usuario.
SOLUCION: Rothacker recomienda que los usuarios sólo reciban privilegios por parte de grupos o funciones y sean manejados colectivamente. De esta forma será más fácil eliminar derechos a un usuario con simplemente eliminarlo del grupo, sin que queden derechos ocultos u olvidados asignados a dicho usuario.
4.- Características de base de datos innecesariamente habilitadas.
Cada instalación de base de datos viene con paquetes adicionales de todas las formas y tamaños que en su mayoría rara vez son utilizados por una sola organización
SOLUCION:. Dado que el nombre del juego en materia de seguridad de base de datos es el de reducir las superficies de ataque, las empresas necesitan buscar los paquetes que no utilizan y desactivarlos. Esto no sólo reduce los riesgos de ataques (0)day a través de estos vectores, sino que también simplifica la gestión de parches.
5.- Configuración de seguridad ineficiente.
Del mismo modo, las bases de datos tienen una gran cantidad opciones de configuración y consideraciones diferentes a disposición de los administradores para ajustar el rendimiento y funcionalidades mejoradas.
SOLUCION:.Las organizaciones necesitan conseguir y desactivar aquellas configuraciones inseguras que podrían estar activadas por defecto para mayor comodidad de los DBA o desarrolladores de aplicaciones. Las configuraciones de bases de datos en producción y desarrollo deben ser radicalmente diferentes.
7.- Escalada de privilegios
Del mismo modo, las bases de datos con frecuencia exponen vulnerabilidades comunes que permiten a un atacante escalar privilegios en una cuenta de privilegios bajos hasta tener acceso a los derechos de un administrador.
SOLUCIONES: A medida que estas vulnerabilidades son descubiertas, los proveedores las corrigen y los administradores deben mantener las actualizaciones y parches actualizados.
8.- Ataque de denegación de servicio
El caso del SQL Slammer es siempre un ejemplo muy esclarecedor de cómo los atacantes pueden utilizar las vulnerabilidades de los DBMS para derribar los servidores de base de datos a través de un alto flujo de tráfico. Aún más ilustrativo es el hecho de que cuando el Slammer atacó en 2003, un parche ya estaba por ahí que se dirigió a corregir la vulnerabilidad por la que se generó su ataque. Hoy en día siete años más tarde, SQL Slammer todavía está dando dolores de cabeza en los servidores no actualizados.
9.- Bases de datos sin actualizar
Esto podría sonar repetitivo, pero vale la pena repetirlo. Los administradores de base de datos a veces no aplican un parche en el momento oportuno porque tienen miedo de este dañe sus bases de datos. Pero el riesgo de ser hackeado hoy es mucho más alto que el riesgo de aplicar un parche que descomponga la base de datos. Además exixten ante esos temores los backups y las réplicas. Quizás este punto pudo haber sido válido hace cinco años, pero los proveedores ahora
Sin encriptar los datos sensibles en reposo y en movimiento
10.- Datos sensibles sin cifrar, tanto en reposo como en movimiento.
Tal vez sea una obviedad, pero las organizaciones no deben almacenar los datos sensibles en texto plano en una tabla. Y todas las conexiones a la base de datos siempre que manejen datos sensibles deben utilizar el cifrado.
