La versión Community Technical Preview (CTP) de SQL Server 2016 nos ha brindado la oportunidad de probar algunas de las nuevas funciones que estarán disponibles en la próxima versión.
Enmascaramiento dinámico de datos
Esta función le permite proteger los datos confidenciales de los usuarios que no están autorizados a verlos ocultando parte o la totalidad del contenido de una columna. Por ejemplo, puede exponer parte de un número de tarjeta de crédito para permitir que el personal de la mesa de ayuda vea los últimos cuatro dígitos; puede optar por ocultar completamente los datos contenidos en una columna de salario.
Si está utilizando SQL Server CTP 2.0, debe ejecutar este comando para habilitar el enmascaramiento dinámico de datos:
DBCC TRACEON(209,219,-1)
No use este comando si está usando una versión posterior del CTP, ya que esto desactivará el enmascaramiento dinámico de datos. (Si está utilizando CTP 2.0 y no ejecute este comando DBCC o está ejecutando CTP2.1+ y hace ejecute este comando, obtendrá el error "Sintaxis incorrecta cerca de 'enmascarado'" al intentar definir una máscara dinámica para una columna.
El siguiente SQL crea una tabla que utiliza el enmascaramiento dinámico de datos para ocultar el contenido de tres columnas. El contenido de la CreditCard columna están parcialmente expuestas. Lo que se expone en el Phone la columna se deja a la máscara de datos dinámicos. El valor predeterminado para una columna de cadena es "xxxx". El valor predeterminado para una columna numérica es "0". El Email columna utiliza una máscara de datos dinámica específicamente orientada al contenido de esa columna.
CREATE TABLE Customer
(ID int IDENTITY PRIMARY KEY,
Name varchar(100) NOT NULL,
CreditCard varchar(9) MASKED WITH (FUNCTION = 'partial(0,"xxxxx",4)') NULL,
Phone varchar(12) MASKED WITH (FUNCTION = 'default()') NULL,
Email varchar(100) MASKED WITH (FUNCTION = 'email()') NULL);
INSERT INTO Customer VALUES('A Name', '111222333', '01937 860000',
'someone@somedomain')
Usando isql programa incluido en nuestra distribución de controladores ODBC de SQL Server, iniciamos sesión con una cuenta de SQL Server que no está autorizada para ver el contenido de una columna enmascarada:
$ /usr/local/easysoft/unixODBC/bin/isql.sh -v SQLSERVER_2016 myuser mypassword +---------------------------------------+ | Connected! | | | | sql-statement | | help [tablename] | | quit | | | +---------------------------------------+ SQL> select * from customer +----+-------+-----------+-------+---------------+ | ID | Name | CreditCard| Phone | Email | +----+-------+-----------+-------+---------------+ | 1 | A Name| xxxxx2333 | xxxx | [email protected] | +----+-------+-----------+-------+---------------+
Luego iniciamos sesión con una cuenta que tiene suficientes privilegios:
$ /usr/local/easysoft/unixODBC/bin/isql.sh -v SQLSERVER_2016 sa mypassword +---------------------------------------+ | Connected! | | | | sql-statement | | help [tablename] | | quit | | | +---------------------------------------+ SQL> select * from customer +----+-------+-----------+--------------+------------------------+ | ID | Name | CreditCard| Phone | Email | +----+-------+-----------+--------------+------------------------+ | 1 | A Name| 111222333 | 01937 860000 | [email protected] | +----+-------+-----------+--------------+------------------------+
Compatibilidad con JSON
La notación de objetos de JavaScript (JSON) es un formato de texto que facilita el intercambio de datos. A medida que más desarrolladores de aplicaciones adoptan JSON como su formato de datos preferido, crece la necesidad de bases de datos compatibles con JSON. Como consecuencia, varias bases de datos NoSQL han elegido JSON como su formato de datos principal. Una de esas bases de datos es MongoDB.
En nuestras máquinas de prueba, usamos la compatibilidad con JSON de SQL Server 2016 para intercambiar datos entre SQL Server y MongoDB.
Usamos el programa de copia masiva (bcp) incluido en la distribución de nuestro controlador ODBC de SQL Server para exportar los datos del cliente que creamos anteriormente en formato JSON. (El comando bcp se conecta a SQL Server como "sa" y, por lo tanto, se exponen los datos en las columnas enmascaradas).
$ cd /usr/local/easysoft/sqlserver/bcp
$ ./bcp "select * from customer for json auto" queryout customer.json -U sa -c
Password:
Starting copy...
1 row successfully bulk-copied to host file. Total received: 1
Clock Time (ms.) Total : 12129 Average : 0.082 rows per second
$ more customer.json
[{"ID":1,"Name":"A Name","CreditCard":"111222333","Phone":"01937 860000",
"Email":"someone@somedomain"}]
Luego importamos los datos JSON a MongoDB:
$ cd /opt/mongodb-linux-x86_64-ubuntu1404-3.0.7/bin $ ./mongoimport --db=SQLServer --collection=Customer --file=customer.json --jsonArray $ connected to: localhost imported 1 document
$ ./mongo
MongoDB shell version: 3.0.7
connecting to: test
> use SQLServer
switched to db SQLServer
> db.Customer.find()
{ "_id" : ObjectId("56334017f6df768ab87f2e8c"), "ID" : 1, "Name" :
"A Name", "CreditCard" : "111222333", "Phone" : "01937 860000",
"Email" : "someone@somedomain" }
>
Seguridad a nivel de fila
Con su función de seguridad de nivel de fila, SQL Server 2016 puede restringir el acceso a los datos de fila en función de un inicio de sesión de SQL Server. La seguridad de nivel de fila es transparente para los usuarios de SQL Server; no saben que las filas que no están autorizados a ver se están filtrando de los resultados de sus consultas.
Para probar esta función con nuestro controlador ODBC de SQL Server, reproducimos el ejemplo de seguridad de nivel de fila de Microsoft. Hicimos esto en una base de datos que tenía usuarios de SQL Server llamados "Ventas1" y "Ventas2", que tenían SELECT privilegios.
Creamos y completamos una tabla con algunos datos de ventas. El SalesRep La columna almacena el nombre de usuario del representante de ventas correspondiente.
CREATE TABLE Sales ( OrderID int, SalesRep sysname, Product varchar(10), Qty int ); INSERT Sales VALUES (1, 'Sales1', 'Valve', 5), (2, 'Sales1', 'Wheel', 2), (3, 'Sales1', 'Valve', 4), (4, 'Sales2', 'Bracket', 2), (5, 'Sales2', 'Wheel', 5), (6, 'Sales2', 'Seat', 5);
La seguridad a nivel de fila se implementa con una función con valores de tabla que devuelve una sola fila, si el usuario tiene el acceso adecuado, o ningún resultado. En el siguiente ejemplo, la función con valores de tabla devuelve una fila si SalesRep columna es la misma que la del usuario que ejecuta la consulta.
CREATE SCHEMA Security;
CREATE FUNCTION Security.fn_securitypredicate(@SalesRep AS sysname)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS fn_securitypredicate_result
WHERE @SalesRep = USER_NAME();
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.fn_securitypredicate(SalesRep)
ON dbo.Sales
WITH (STATE = ON);
Utilizamos el controlador ODBC de SQL Server para conectarnos a la base de datos como usuario de Sales2. La seguridad a nivel de fila garantiza que este usuario solo pueda ver las ventas realizadas por el usuario Ventas2.
$ /usr/local/easysoft/unixODBC/bin/isql.sh -v SQLSERVER_2016 Sales2 mypassword +---------------------------------------+ | Connected! | | | | sql-statement | | help [tablename] | | quit | | | +---------------------------------------+ SQL> select * from Sales +------------+----------+-----------+-------+ | OrderID | SalesRep | Product | Qty | +------------+----------+-----------+-------+ | 4 | Sales2 | Bracket | 2 | | 5 | Sales2 | Wheel | 5 | | 6 | Sales2 | Seat | 5 | +------------+----------+-----------+-------+ SQL> select * from Sales where OrderID = 1 +------------+----------+-----------+-------+ | OrderID | SalesRep | Product | Qty | +------------+----------+-----------+-------+ | | | | | +------------+----------+-----------+-------+
R en base de datos
Con la compra de Revolution Analytics por parte de Microsoft, un proveedor de software y servicios para el lenguaje de programación R, pueden integrar R con SQL Server. SQL Server 2016 será la primera versión de la base de datos que incorporará R, lo que permitirá que el código R se ejecute dentro del motor de la base de datos de SQL Server.
Si tiene una versión anterior de SQL Server, la alternativa es extraer datos de SQL Server a R mediante ODBC. El paquete RODBC proporcionó una interfaz ODBC para R. Construimos RODBC contra el administrador de controladores unixODBC incluido en la distribución de nuestro controlador de SQL Server y luego recuperamos algunos datos de SQL Server de R:
# export ODBC_LIBS=/usr/local/easysoft/unixODBC/lib
# export ODBC_INCLUDE=/usr/local/easysoft/unixODBC/include
# R CMD INSTALL RODBC_1.3-12.tar.gz
$ R
> library("RODBC")
> ch <- odbcConnect("SQLSERVER_2016")
> sqlQuery(ch, paste("SELECT * from Customer"))
ID Name CreditCard Phone Email
1 1 A Name 111222333 01937 860000 someone@somedomain
