Sqlserver
 sql >> Datenbank >  >> RDS >> Sqlserver

SQL-Server 2016

Die Community Technical Preview (CTP)-Version von SQL Server 2016 hat uns die Gelegenheit gegeben, einige der neuen Funktionen auszuprobieren, die in der kommenden Version verfügbar sein werden.

Dynamische Datenmaskierung

Mit dieser Funktion können Sie vertrauliche Daten vor Benutzern schützen, die nicht berechtigt sind, sie anzuzeigen, indem einige oder alle Inhalte einer Spalte verdeckt werden. Beispielsweise können Sie einen Teil einer Kreditkartennummer offenlegen, damit Helpdesk-Mitarbeiter die letzten vier Ziffern sehen können. Sie können sich dafür entscheiden, die in einer Gehaltsspalte enthaltenen Daten vollständig zu verdecken.

Wenn Sie SQL Server CTP 2.0 verwenden, müssen Sie diesen Befehl ausführen, um die dynamische Datenmaskierung zu aktivieren:

DBCC TRACEON(209,219,-1)

Verwenden Sie diesen Befehl nicht, wenn Sie eine neuere Version des CTP verwenden, da dadurch die dynamische Datenmaskierung deaktiviert wird. (Wenn Sie CTP 2.0 verwenden und nicht führen Sie diesen DBCC-Befehl aus oder Sie führen CTP2.1+ aus und Sie tun Wenn Sie diesen Befehl ausführen, erhalten Sie den Fehler „Falsche Syntax in der Nähe von ‚masked‘“, wenn Sie versuchen, eine dynamische Maske für eine Spalte zu definieren.

Die folgende SQL erstellt eine Tabelle, die dynamische Datenmaskierung verwendet, um den Inhalt von drei Spalten zu verschleiern. Der Inhalt der CreditCard Spalte sind teilweise freigelegt. Was im Phone angezeigt wird Spalte bleibt der dynamischen Datenmaske überlassen. Der Standardwert für eine Zeichenfolgenspalte ist "xxxx". Der Standardwert für eine numerische Spalte ist "0". Die Email Spalte verwendet eine dynamische Datenmaske, die speziell auf den Inhalt dieser Spalte ausgerichtet ist.

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

Mit isql Programm, das in unserer SQL Server ODBC-Treiberverteilung enthalten ist, melden wir uns mit einem SQL Server-Konto an, das nicht berechtigt ist, den Inhalt einer maskierten Spalte anzuzeigen:

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

Wir melden uns dann mit einem Konto an, das über ausreichende Berechtigungen verfügt:

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

JSON-Unterstützung

JavaScript Object Notation (JSON) ist ein Textformat, das den Austausch von Daten erleichtert. Da immer mehr Anwendungsentwickler JSON als bevorzugtes Datenformat übernehmen, wächst der Bedarf an JSON-freundlichen Datenbanken. Infolgedessen haben mehrere NoSQL-Datenbanken JSON als primäres Datenformat gewählt. Eine solche Datenbank ist MongoDB.

Auf unseren Testmaschinen haben wir die JSON-Unterstützung von SQL Server 2016 verwendet, um Daten zwischen SQL Server und MongoDB auszutauschen.

Wir haben das Massenkopierprogramm (bcp) verwendet, das in der Distribution unseres SQL Server-ODBC-Treibers enthalten ist, um die zuvor erstellten Kundendaten im JSON-Format zu exportieren. (Der bcp-Befehl stellt eine Verbindung mit SQL Server als „sa“ her, sodass die Daten in den maskierten Spalten verfügbar gemacht werden.)

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

Anschließend haben wir die JSON-Daten in MongoDB importiert:

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

Sicherheit auf Zeilenebene

Mit seiner Sicherheitsfunktion auf Zeilenebene ist SQL Server 2016 in der Lage, den Zugriff auf Zeilendaten basierend auf einer SQL Server-Anmeldung einzuschränken. Sicherheit auf Zeilenebene ist für SQL Server-Benutzer transparent, sie wissen nicht, dass Zeilen, für deren Anzeige sie nicht autorisiert sind, aus ihren Abfrageergebnissen herausgefiltert werden.

Um diese Funktion mit unserem SQL Server-ODBC-Treiber zu testen, haben wir Microsofts Sicherheitsbeispiel auf Zeilenebene reproduziert. Wir haben dies in einer Datenbank mit SQL Server-Benutzern namens „Sales1“ und „Sales2“ durchgeführt, die SELECT haben Privilegien.

Wir haben eine Tabelle mit einigen Verkaufsdaten erstellt und gefüllt. Der SalesRep Spalte speichert den Benutzernamen des jeweiligen Außendienstmitarbeiters.

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

Die Sicherheit auf Zeilenebene wird mit einer Tabellenwertfunktion implementiert, die entweder eine einzelne Zeile zurückgibt, wenn der Benutzer über den entsprechenden Zugriff verfügt, oder keine Ergebnisse. Im folgenden Beispiel gibt die Tabellenwertfunktion eine Zeile zurück, wenn SalesRep Spalte ist derselbe wie der Benutzer, der die Abfrage ausführt.

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

Wir haben den SQL Server ODBC-Treiber verwendet, um als Sales2-Benutzer eine Verbindung zur Datenbank herzustellen. Die Sicherheit auf Zeilenebene stellt sicher, dass dieser Benutzer nur Verkäufe sehen kann, die vom Benutzer Sales2 getätigt wurden.

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

Datenbankinternes R

Durch den Kauf von Revolution Analytics durch Microsoft, einem Anbieter von Software und Diensten für die Programmiersprache R, können sie R mit SQL Server integrieren. SQL Server 2016 wird die erste Version der Datenbank sein, die R enthält, sodass R-Code innerhalb der SQL Server-Datenbank-Engine ausgeführt werden kann.

Wenn Sie über eine frühere Version von SQL Server verfügen, besteht die Alternative darin, Daten aus SQL Server mithilfe von ODBC in R zu extrahieren. Das RODBC-Paket stellte eine ODBC-Schnittstelle für R bereit. Wir haben RODBC für den unixODBC-Treibermanager erstellt, der in der Distribution unseres SQL Server-Treibers enthalten ist, und dann einige SQL Server-Daten von R:

abgerufen
# 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