Cada día se incrementa la necesidad de mantener segura toda la data de la base de datos, la cual puede implementarse usando diveros mecanismos de seguridad que nos trae SQL Server 2005. Por ejemplo, para encriptar (ya sé, es cifrar, no encriptar) cierta data como los números de tarjeta de crédito de nuestros clientes, en SQL Server 2005, podemos hacerlo mediante encriptación simétrica y/o asimétrica, certificados, etc, lo cual no podía realizarse en SQL Server 2000, a menos que se use ciertas herramientas de terceros como NetLib Encryptionizer, XP_CRYPT, o algún script.
Ahora, sabiendo que para la mayoría de nosotros, la seguridad de nuestra base de datos es lo último por la que nos preucupamos, y suponiendo que éste no es el caso, podríamos encriptar toda la data sensible para que no sea robada o no hacer vulnerable nuestro sistema de base de datos. En fin, con todo esto podríamos "encriptar" sólo cierta data que nosotros consideremos necesarias.
Te pregunto: ¿Alguna vez te has preucupado por asegurar tus backup files?. La primera respuesta podría ser un NO, sin embargo, estoy seguro que muchos dirán que SI, valiéndose en haber creado backups con cierto password complejo. Claro, esto está muy bien!. Pero realmente con esto estás evitando que roben tu data?. En el caso que yo tenga acceso a tus backups, yo no podría hacer uso de ellos a menos que tenga un password, vale?. Bien!, no cantes victoria!!!, porque yo podría sacarle mucho provecho a tus backups?, Cómo?, ps fácil!. Sigue leyendo....
Te cuento que los backup nativos de SQL Server se almacenan como texto plano, esto quiere decir, que dependiendo del tipo de dato que se use en las tablas, la data de la base de datos puede ser leído abriendo los backup files con nuestro querido notepad, o cualquier otro editor de texto. Veámos un ejemplo al respecto. He creado una base de datos "DB_Demo" con una tabla CreditCard.
1: CREATE TABLE [dbo].[CreditCard]
2: (
3: [CreditCardID] [int] PRIMARY KEY IDENTITY(1,1) NOT NULL,
4: [CardType] [nvarchar](50) NOT NULL,
5: [CardNumber] [nvarchar](25) NOT NULL,
6: [ExpMonth] [tinyint] NOT NULL,
7: [ExpYear] [smallint] NOT NULL,
8: [ModifiedDate] [datetime] NOT NULL DEFAULT (getdate()),
9:
10: )
Ahora pasamos a llenar con data la tabla que hemos creado (Debes tener la base de datos AdventureWorks).
1: INSERT INTO CreditCard
2: SELECT CardType,CardNumber,ExpMonth,ExpYear,ModifiedDate
3: FROM AdventureWorks.Sales.CreditCard
Debemos tener una tabla con la siguiente data:
Además vamos a crear un stored procedure:
1: CREATE PROCEDURE dbo.getCreditCardbyCardType
2: @CardType NVARCHAR(50)
3: AS
4: BEGIN
5: SELECT CreditCardID CardType,CardNumber,ModifiedDate
6: FROM dbo.CreditCard
7: WHERE CardType=@CardType
8: END
Entonces, ahora vamos generar un backup de la base de datos DB_Demo. Luego de esto, pasamos a abrir el archivo usando el notepad. Al curiosear la data, podemos apreciar cosas como la que vemos en la imagen, todo el código T-SQL de el stored procedure que habíamos creado.
Y como no hemos encriptado los datos de la tabla, podemos también verla fácilmente. Se puede apreciar en la imagen el número de tarjeta de crédito de varios clientes.
También se puede ver el nombre del servidor, el nombre de la instancia SQL Server, y más.... Todo estos datos puede ser manipulado por un instruso (en este caso yo), para llevar acabo sus "instintos oscuros".
Ahora que ya se sabe que nuestra data puede ser leído de los backup files, la pregunta es: ¿Cómo aseguramos esto?. Claro!!!, debemos encriptar el backup file!!! :D. Siento decirte que no existe, en SQL Server, alguna manera nativa de llevar acabo esto. SQL Server no ofrece funcionalidad alguna para encriptar los backups. Y entonces que se puede hacer?, o ¿Qué medidas tomar?.
Lo que se podría hacer para evitar que otros lean el T-SQL de los Stored Procedures u otros objetos de base de datos, es encriptándolo:
1: CREATE PROCEDURE dbo.getCreditCardbyCardType
2: @CardType NVARCHAR(50)
3: WITH ENCRYPTION
4: AS
5: BEGIN
6: SELECT CreditCardID CardType,CardNumber,ModifiedDate
7: FROM dbo.CreditCard
8: WHERE CardType=@CardType
9: END
También podemos encriptar los números de tarjeta de crédito, y otros datos que consideremos sensible. Además, podemos tomar otras medidas de seguridad como Seguridad a Nivel de Archivos, es decir, limitar el acceso a los backup files mediante ciertos permisos, esto le agregaría algo más de seguridad, claro, sin eliminar la necesidad de encriptar la data y objetos de base de datos. A pesar de todo esto, lo ideal sigue siendo, obviamente, encriptar los backup files, pero como ya dije, SQL Server no ofrece funcionalidad alguna para realizarlo, así que podriamos usar ciertos productos de terceros como Idera's SQLsafe, Quest's SQL LiteSpeed o Red-Gate's SQL Backup.
Por ejemplo, con Idera's SQLsafe, podemos encriptar los backup files usando varios algoritmos de cifrado como DES, RC2, TripleDES y Rijndael.
En fin, ya sabemos que los backup files pueden ser leídas fácilmente, como también, algunas de las medidas a tomar para agregarle seguridad, los productos que usar para encriptarlos, y asi prevenir situaciones "inesperadas" y/o "desastrosas".
Saludos, espero les haya sido útil este post! 
.
Percy Reyes,