Tables optimisées pour la mémoire + Colonne Chiffrement et Identité

Question

Je me demandais s'il était possible d'avoir un Memory Optimized Table toujours chiffré et si sa clé primaire était automatiquement amorcée? Par exemple, je veux créer:

CREATE TABLE Foo 
(
    [Id] [int] Identity(1,1) NOT NULL, 
    [Bar] NVARCHAR(MAX) NOT NULL, 
    CONSTRAINT [PK_Foo] PRIMARY KEY NONCLUSTERED ([Id] ASC) 
) 
WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_ONLY) 
GO 

Table assez simple et est d'abord créé bien cependant, lorsque je tente de chiffrer la colonne Bar je reçois l'exception suivante.

21 avril 2017 09:23:00 [Erreur] WorkitemExecution: Message: Inner exception: System.Data.SqlClient.SqlException Détails: Impossible d'insérer valeur explicite pour la colonne d'identité dans la table 'Foo' quand IDENTITY_INSERT est défini sur OFF ..

J'ai également essayé de définir SET IDENTITY_INSERT Foo ON après l'instruction create table mais toujours pas de chance.

La lecture de la documentation ne semble pas suggérer que ce n'est pas possible mais peut-être que j'ai raté quelque chose? Si cela n'est pas possible, j'ai une autre approche qui, je le sais, fonctionnera.

Je suppose que ma question en résumé est .. "Les tables de tables optimisées pour la mémoire sont toujours cryptées avec une colonne d'identité".

Answer 1

Vous ne pouvez pas crypter des colonnes d'identité à l'aide de l'option Toujours crypté, qu'elles soient stockées dans des tables optimisées pour la mémoire ou dans des tables normales. Dans le flux normal de traitement des requêtes Always Encrypted, les valeurs insérées dans les colonnes cryptées sont créées et chiffrées côté client. Notez que seul le client possède des clés de chiffrement et peut chiffrer/déchiffrer des données. SQL Server, par conception, n'a pas accès aux clés de chiffrement et ne peut pas effectuer d'opérations de chiffrement. Les valeurs de colonne d'identité sont générées côté serveur, de sorte qu'elles ne correspondent pas au flux de travail ci-dessus.

Il serait utile de comprendre pourquoi vous essayez de chiffrer votre colonne d'identité. Toujours chiffré est conçu pour être utilisé pour protéger les données sensibles. Les identifiants générés automatiquement ne sont généralement pas considérés comme des informations sensibles.

Merci,

Jakub

Answer 2

Même après votre cryptage par l'assistant a échoué, vous devriez avoir un et CEK créé CMK pour vous. Vous pouvez vérifier le nom du CEK qui a été créé en naviguant vers YourDb -> Sécurité -> Clés toujours cryptées -> Clés de cryptage de colonne dans l'explorateur d'objet SSMS. Dans mon cas, le nom de CEK était CEK_Auto1

Si vous ne trouvez pas de clé de chiffrement de colonne à l'emplacement ci-dessus, vous pouvez en créer une nouvelle en suivant les étapes décrites dans Provisioning Column Master Keys (nouvelle clé principale de colonne) et provisionnement colonne des clés de chiffrement (Nouveau chiffrement de la colonne de clé) dans this article

Vous devriez être en mesure de créer la table comme suit

CREATE TABLE Foo 
(
    [Id] [int] Identity(1,1) NOT NULL, 
    [Bar] NVARCHAR(MAX) COLLATE Latin1_General_BIN2 ENCRYPTED WITH (COLUMN_ENCRYPTION_KEY = [CEK_Auto1], ENCRYPTION_TYPE = Deterministic, ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256') NULL, 
    CONSTRAINT [PK_Foo] PRIMARY KEY NONCLUSTERED ([Id] ASC) 
) 
WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_ONLY) 
GO