Sqlserver
 sql >> Database >  >> RDS >> Sqlserver

SQL Server 2016

La versione Community Technical Preview (CTP) di SQL Server 2016 ci ha dato l'opportunità di provare alcune delle nuove funzionalità che saranno disponibili nella prossima versione.

Mascheramento dinamico dei dati

Questa funzione consente di proteggere i dati riservati dagli utenti che non sono autorizzati a vederli oscurando alcuni o tutti i contenuti di una colonna. Ad esempio, potresti esporre parte del numero di una carta di credito per consentire al personale dell'help desk di vedere le ultime quattro cifre; potresti scegliere di oscurare completamente i dati contenuti in una colonna salariale.

Se utilizzi SQL Server CTP 2.0, devi eseguire questo comando per abilitare il mascheramento dinamico dei dati:

DBCC TRACEON(209,219,-1)

Non utilizzare questo comando se stai utilizzando una versione successiva del CTP, poiché ciò disabiliterà il mascheramento dinamico dei dati. (Se stai utilizzando CTP 2.0 e non esegui questo comando DBCC o stai eseguendo CTP2.1+ e fai esegui questo comando, otterrai l'errore "Sintassi errata vicino a 'mascherato'" quando tenti di definire una maschera dinamica per una colonna.

L'SQL seguente crea una tabella che utilizza il data masking dinamico per oscurare il contenuto di tre colonne. Il contenuto della CreditCard colonna sono parzialmente a vista. Cosa viene esposto nel Phone la colonna viene lasciata alla maschera di dati dinamici. L'impostazione predefinita per una colonna stringa è "xxxx". L'impostazione predefinita per una colonna numerica è "0". L'Email colonna utilizza una maschera di dati dinamici specificamente orientata al contenuto di quella colonna.

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 programma incluso nella nostra distribuzione di driver ODBC di SQL Server, accediamo con un account SQL Server che non è autorizzato a visualizzare il contenuto di una colonna mascherata:

$ /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] |
+----+-------+-----------+-------+---------------+

Quindi accediamo con un account che dispone di privilegi sufficienti:

$ /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] |
+----+-------+-----------+--------------+------------------------+

Supporto JSON

JavaScript Object Notation (JSON) è un formato di testo che facilita lo scambio di dati. Poiché sempre più sviluppatori di applicazioni adottano JSON come formato di dati preferito, cresce la necessità di database compatibili con JSON. Di conseguenza, diversi database NoSQL hanno scelto JSON come formato dati principale. Uno di questi database è MongoDB.

Sulle nostre macchine di prova, abbiamo utilizzato il supporto JSON di SQL Server 2016 per scambiare dati tra SQL Server e MongoDB.

Abbiamo utilizzato il programma di copia in blocco (bcp) incluso nella distribuzione del nostro driver ODBC di SQL Server per esportare i dati dei clienti che abbiamo creato in precedenza in formato JSON. (Il comando bcp si connette a SQL Server come "sa" e quindi i dati nelle colonne mascherate vengono esposti.)

$ 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"}]

Abbiamo quindi importato i dati JSON in 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" }
>

Sicurezza a livello di riga

Con la sua funzionalità di sicurezza a livello di riga, SQL Server 2016 è in grado di limitare l'accesso ai dati di riga in base a un account di accesso di SQL Server. La sicurezza a livello di riga è trasparente per gli utenti di SQL Server, non sono consapevoli del fatto che le righe che non sono autorizzati a visualizzare vengono filtrate dai risultati delle query.

Per provare questa funzionalità con il nostro driver ODBC di SQL Server, abbiamo riprodotto l'esempio di sicurezza a livello di riga di Microsoft. L'abbiamo fatto in un database che aveva utenti SQL Server denominati "Sales1" e "Sales2", che hanno SELECT privilegi.

Abbiamo creato e popolato una tabella con alcuni dati di vendita. Il SalesRep la colonna memorizza il nome utente del rappresentante di vendita pertinente.

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 sicurezza a livello di riga viene implementata con una funzione con valori di tabella che restituisce una singola riga, se l'utente dispone dell'accesso appropriato, o nessun risultato. Nell'esempio seguente, la funzione con valori di tabella restituisce una riga se SalesRep la colonna è la stessa dell'utente che esegue la query.

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);

Abbiamo utilizzato il driver ODBC di SQL Server per la connessione al database come utente Sales2. La sicurezza a livello di riga garantisce che questo utente possa vedere solo le vendite effettuate dall'utente 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 nel database

Con l'acquisto da parte di Microsoft di Revolution Analytics, un fornitore di software e servizi per il linguaggio di programmazione R, sono in grado di integrare R con SQL Server. SQL Server 2016 sarà la prima versione del database a incorporare R, consentendo l'esecuzione del codice R all'interno del motore di database di SQL Server.

Se si dispone di una versione precedente di SQL Server, l'alternativa consiste nell'estrarre i dati da SQL Server in R utilizzando ODBC. Il pacchetto RODBC ha fornito un'interfaccia ODBC per R. Abbiamo creato RODBC rispetto a unixODBC Driver Manager incluso nella distribuzione del nostro driver di SQL Server e quindi abbiamo recuperato alcuni dati di SQL Server da 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