La version Community Technical Preview (CTP) de SQL Server 2016 nous a donné l'occasion d'essayer certaines des nouvelles fonctionnalités qui seront disponibles dans la prochaine version.
Masquage dynamique des données
Cette fonctionnalité vous permet de protéger les données confidentielles des utilisateurs qui ne sont pas autorisés à les voir en masquant tout ou partie du contenu d'une colonne. Par exemple, vous pouvez exposer une partie d'un numéro de carte de crédit pour permettre au personnel du service d'assistance de voir les quatre derniers chiffres; vous pouvez choisir de masquer complètement les données contenues dans une colonne de salaire.
Si vous utilisez SQL Server CTP 2.0, vous devez exécuter cette commande pour activer le masquage dynamique des données :
DBCC TRACEON(209,219,-1)
N'utilisez pas cette commande si vous utilisez une version ultérieure du CTP, car cela désactivera le masquage dynamique des données. (Si vous utilisez CTP 2.0 et que vous ne le faites pas exécutez cette commande DBCC ou vous exécutez CTP2.1+ et vous faites exécutez cette commande, vous obtiendrez l'erreur "Syntaxe incorrecte proche de 'masqué'" lors de la tentative de définition d'un masque dynamique pour une colonne.
Le SQL suivant crée une table qui utilise le masquage dynamique des données pour masquer le contenu de trois colonnes. Le contenu de la CreditCard colonne sont partiellement exposés. Ce qui est exposé dans le Phone La colonne est laissée au masque de données dynamique. La valeur par défaut pour une colonne de chaîne est "xxxx". La valeur par défaut pour une colonne numérique est "0". Le Email colonne utilise un masque de données dynamique spécifiquement adapté au contenu de cette colonne.
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')
Utiliser le isql programme inclus dans notre distribution de pilote ODBC SQL Server, nous nous connectons avec un compte SQL Server qui n'est pas autorisé à afficher le contenu d'une colonne masquée :
$ /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] | +----+-------+-----------+-------+---------------+
Nous nous connectons ensuite avec un compte disposant des privilèges suffisants :
$ /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] | +----+-------+-----------+--------------+------------------------+
Prise en charge de JSON
JavaScript Object Notation (JSON) est un format de texte qui facilite l'échange de données. Alors que de plus en plus de développeurs d'applications adoptent JSON comme format de données préféré, le besoin de bases de données compatibles avec JSON augmente. En conséquence, plusieurs bases de données NoSQL ont choisi JSON comme format de données principal. L'une de ces bases de données est MongoDB.
Sur nos machines de test, nous avons utilisé le support JSON de SQL Server 2016 pour échanger des données entre SQL Server et MongoDB.
Nous avons utilisé le programme de copie en bloc (bcp) inclus dans la distribution de notre pilote ODBC SQL Server pour exporter les données client que nous avons créées précédemment au format JSON. (La commande bcp se connecte à SQL Server en tant que "sa" et les données des colonnes masquées sont donc exposées.)
$ 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"}]
Nous avons ensuite importé les données JSON dans 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" }
>
Sécurité au niveau des lignes
Grâce à sa fonction de sécurité au niveau des lignes, SQL Server 2016 est capable de restreindre l'accès aux données de ligne en fonction d'une connexion SQL Server. La sécurité au niveau des lignes est transparente pour les utilisateurs de SQL Server, ils ne savent pas que les lignes qu'ils ne sont pas autorisés à voir sont filtrées à partir de leurs résultats de requête.
Pour essayer cette fonctionnalité avec notre pilote ODBC SQL Server, nous avons reproduit l'exemple de sécurité au niveau des lignes de Microsoft. Nous l'avons fait dans une base de données qui avait des utilisateurs SQL Server nommés "Sales1" et "Sales2", qui ont SELECT privilèges.
Nous avons créé et rempli un tableau avec des données sur les ventes. Le SalesRep la colonne stocke le nom d'utilisateur du représentant commercial concerné.
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 sécurité au niveau de la ligne est implémentée avec une fonction de table qui renvoie soit une seule ligne, si l'utilisateur dispose de l'accès approprié, soit aucun résultat. Dans l'exemple suivant, la fonction de table renvoie une ligne si le SalesRep colonne est la même que celle de l'utilisateur exécutant la requête.
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);
Nous avons utilisé le pilote ODBC SQL Server pour nous connecter à la base de données en tant qu'utilisateur Sales2. La sécurité au niveau de la ligne garantit que cet utilisateur ne peut voir que les ventes effectuées par l'utilisateur Sales2.
$ /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 dans la base de données
Avec l'achat par Microsoft de Revolution Analytics, un fournisseur de logiciels et de services pour le langage de programmation R, ils sont en mesure d'intégrer R à SQL Server. SQL Server 2016 sera la première version de la base de données à intégrer R, permettant au code R d'être exécuté dans le moteur de base de données SQL Server.
Si vous disposez d'une version antérieure de SQL Server, l'alternative consiste à extraire les données de SQL Server dans R à l'aide d'ODBC. Le package RODBC a fourni une interface ODBC pour R. Nous avons construit RODBC avec le gestionnaire de pilotes unixODBC inclus dans la distribution de notre pilote SQL Server, puis avons récupéré certaines données SQL Server à partir 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
