Not
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
gäller för:
SQL ServerAzure SQL DatabaseAzure SQL Managed Instance
Den här artikeln innehåller information om hur du utvecklar .NET Framework-program med Always Encrypted eller Always Encrypted med säkra enklaver och .NET Framework Data Provider för SQL Server (System.Data.SqlClient).
Anmärkning
Användning av .NET Framework-dataprovidern för SQL Server (System.Data.SqlClient) rekommenderas inte för ny utveckling. Mer information finns i System.Data.SqlClient.
Always Encrypted gör att klientprogram kan kryptera känsliga data och aldrig avslöja data eller krypteringsnycklar till SQL Server eller Azure SQL Database. En Always Encrypted-aktiverad drivrutin, till exempel .NET Framework Data Provider för SQL Server, uppnår detta genom att transparent kryptera och dekryptera känsliga data i klientprogrammet. Drivrutinen avgör automatiskt vilka frågeparametrar som motsvarar känsliga databaskolumner (skyddade med Always Encrypted) och krypterar värdena för dessa parametrar innan data skickas till SQL Server eller Azure SQL Database. På samma sätt avkrypterar drivrutinen på ett transparent sätt data som hämtats från krypterade databaskolumner i förfrågningsresultat. Mer information finns i Utveckla program med Always Encrypted och Utveckla program med Always Encrypted med säkra enklaver.
Anmärkning
.NET Framework Data Provider för SQL Server (System.Data.SqlClient) stöder inte användning av VBS-enklaver utan attestering.
Förutsättningar
- Konfigurera Always Encrypted i databasen. Detta innebär etablering av Always Encrypted-nycklar och konfiguration av kryptering för valda databaskolumner. Om du inte redan har en databas med Always Encrypted konfigurerad följer du anvisningarna i Självstudie: Komma igång med Always Encrypted.
- Om du använder Always Encrypted med säkra enklaver kan du läsa Utveckla program med Always Encrypted med säkra enklaver för fler krav.
- Kontrollera att .NET Framework version 4.6.1 eller senare är installerad på utvecklingsdatorn. Mer information finns i .NET Framework 4.6. Du måste också se till att .NET Framework version 4.6 eller senare har konfigurerats som .NET Framework-målversion i utvecklingsmiljön. Om du använder Visual Studio kan du läsa Så här: Rikta in dig på en version av .NET Framework.
Anmärkning
Stödnivån för Always Encrypted i vissa versioner av .NET Framework varierar. Always Encrypted API-referenser visas i följande avsnitt.
Aktivera Always Encrypted för programfrågor
Det enklaste sättet att aktivera kryptering av parametrar och dekrypteringen av frågeresultat för de krypterade kolumnerna är genom att ange värdet för nyckelordet Kolumnkrypteringsinställning för anslutningssträng till aktiverad.
Följande är ett exempel på en anslutningssträng som aktiverar Always Encrypted:
string connectionString = "Data Source=server63; Initial Catalog=Clinic; Integrated Security=true; Column Encryption Setting=enabled";
SqlConnection connection = new SqlConnection(connectionString);
Följande är ett motsvarande exempel med egenskapen SqlConnectionStringBuilder.ColumnEncryptionSetting.
SqlConnectionStringBuilder strbldr = new SqlConnectionStringBuilder();
strbldr.DataSource = "server63";
strbldr.InitialCatalog = "Clinic";
strbldr.IntegratedSecurity = true;
strbldr.ColumnEncryptionSetting = SqlConnectionColumnEncryptionSetting.Enabled;
SqlConnection connection = new SqlConnection(strbldr.ConnectionString);
Always Encrypted kan också aktiveras för enskilda frågor. Se avsnittet Kontrollera prestandapåverkan för Always Encrypted nedan. Det räcker inte att aktivera Always Encrypted för att kryptering eller dekryptering ska lyckas. Du måste också se till att:
- Applikationen har behörigheterna VIEW ANY COLUMN MASTER KEY DEFINITION och VIEW ANY COLUMN ENCRYPTION KEY DEFINITION, vilka krävs för att få åtkomst till metadata om Always Encrypted nycklar i databasen. Mer information finns i avsnittet Behörigheter i Always Encrypted (Databasmotor).
- Programmet kan komma åt kolumnhuvudnyckeln som skyddar kolumnkrypteringsnycklarna och krypterar de efterfrågade databaskolumnerna.
Aktivera Always Encrypted med säkra enklaver
Från och med .NET Framework version 4.7.2 stöder drivrutinen Always Encrypted med säkra enklaver.
Allmän information om klientdrivrutinsrollen i enklaverberäkningar och enklavattestering finns i Utveckla program med Always Encrypted med säkra enklaver.
Så här konfigurerar du ditt program:
Aktivera Always Encrypted för dina programfrågor, enligt beskrivningen i föregående avsnitt.
Integrera NuGet-paketet Microsoft.SqlServer.Management.AlwaysEncrypted.EnclaveProviders med ditt program. NuGet är ett bibliotek med leverantörer av enklaver som implementerar logiken på klientsidan för attesteringsprotokoll och för att upprätta en säker kanal med en säker enklav.
Uppdatera programkonfigurationen (till exempel i web.config eller app.config) för att definiera mappningen mellan en enklavtyp, konfigurerad för databasen och en enklavprovider.
- Om du använder SQL Server och Host Guardian Service (HGS) måste du mappa VBS-enklavertypen till klassen Microsoft.SqlServer.Management.AlwaysEncrypted.EnclaveProviders.HostGuardianServiceEnclaveProvider från NuGet-paketet.
- Om du använder Azure SQL Database och Microsoft Azure Attestation måste du mappa SGX-enklavertypen till klassen Microsoft.SqlServer.Management.AlwaysEncrypted.EnclaveProviders.AzureAttestationEnclaveProvider från NuGet-paketet.
Detaljerade anvisningar för hur du redigerar programkonfigurationen finns i Självstudie: Utveckla ett .NET Framework-program med Always Encrypted med säkra enklaver.
Ange nyckelordet
Enclave Attestation URLi databasanslutningssträngen till en attesterings-URL (en attesteringstjänstslutpunkt). Du måste hämta en attesterings-URL för din miljö från administratören för attesteringstjänsten.- Om du använder SQL Server och Host Guardian Service (HGS) kan du läsa Fastställa och dela HGS-attesterings-URL:en.
- Om du använder Azure SQL Database och Microsoft Azure Attestation kan du läsa Fastställ attesterings-URL för din attesteringsprincip.
En stegvis självstudie finns i Självstudie: Utveckla ett .NET Framework-program med Always Encrypted med säkra enklaver
Hämta och ändra data i krypterade kolumner
När du aktiverar Always Encrypted för programfrågor kan du använda standard-ADO.NET-API:er (se Hämta och ändra data i ADO.NET) eller .NET Framework Data Provider för SQL Server-API :er som definierats i namnområdet System.Data.SqlClient för att hämta eller ändra data i krypterade databaskolumner. Förutsatt att programmet har nödvändiga databasbehörigheter och kan komma åt kolumnhuvudnyckeln krypterar .NET Framework-dataprovidern för SQL Server alla frågeparametrar som riktar sig mot krypterade kolumner och dekrypterar data som hämtats från krypterade kolumner och returnerar oformaterade värden för .NET-typer, vilket motsvarar de SQL Server-datatyper som angetts för kolumnerna i databasschemat. Om Always Encrypted inte är aktiverat misslyckas frågor med parametrar som riktar sig mot krypterade kolumner. Frågor kan fortfarande hämta data från krypterade kolumner, så länge frågan inte har några parametrar för krypterade kolumner. .NET Framework-dataprovidern för SQL Server försöker dock inte dekryptera några värden som hämtats från krypterade kolumner och programmet tar emot binära krypterade data (som bytematriser).
Tabellen nedan sammanfattar beteendet för frågor, beroende på om Always Encrypted är aktiverat eller inte:
| Frågeegenskaper | Always Encrypted är aktiverat och programmet kan komma åt nycklar och nyckelmetadata | Always Encrypted är aktiverat och programmet kan inte komma åt nycklar eller nyckelmetadata | Always Encrypted är inaktiverat |
|---|---|---|---|
| Frågor med parametrar som riktar sig till krypterade kolumner. | Parametervärden krypteras transparent. | Error | Error |
| Frågor som hämtar data från krypterade kolumner, utan parametrar som riktar sig till krypterade kolumner. | Resultat från krypterade kolumner dekrypteras transparent. Programmet tar emot oformaterade värden för .NET-datatyper som motsvarar de SQL Server-typer som konfigurerats för de krypterade kolumnerna. | Error | Resultat från krypterade kolumner dekrypteras inte. Programmet tar emot krypterade värden som bytematriser (byte[]). |
I följande exempel visas hur du hämtar och ändrar data i krypterade kolumner. Exemplen förutsätter att måltabellen har schemat nedan. Kolumnerna SSN och BirthDate krypteras.
CREATE TABLE [dbo].[Patients]([PatientId] [int] IDENTITY(1,1),
[SSN] [char](11) COLLATE Latin1_General_BIN2
ENCRYPTED WITH (ENCRYPTION_TYPE = DETERMINISTIC,
ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256',
COLUMN_ENCRYPTION_KEY = CEK1) NOT NULL,
[FirstName] [nvarchar](50) NULL,
[LastName] [nvarchar](50) NULL,
[BirthDate] [date]
ENCRYPTED WITH (ENCRYPTION_TYPE = RANDOMIZED,
ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256',
COLUMN_ENCRYPTION_KEY = CEK1) NOT NULL
PRIMARY KEY CLUSTERED ([PatientId] ASC) ON [PRIMARY])
GO
Infoga ett dataexempel
I det här exemplet infogas en rad i tabellen Patienter. Observera följande:
- Det finns inget specifikt för kryptering i exempelkoden. .NET Framework-dataprovidern för SQL Server identifierar och krypterar automatiskt parametrarna paramSSN och paramBirthdate som riktar sig mot krypterade kolumner. Detta gör krypteringen transparent för programmet.
- Värdena som infogas i databaskolumner, inklusive de krypterade kolumnerna, skickas som SqlParameter-objekt . Att använda SqlParameter är valfritt när du skickar värden till icke-krypterade kolumner (även om det rekommenderas starkt eftersom det hjälper till att förhindra SQL-injektion). Det krävs dock för värden som är avsedda för krypterade kolumner. Om värdena som infogats i SSN- eller BirthDate-kolumnerna skickades som literaler inbäddade i frågeutsatsen skulle frågan misslyckas eftersom .NET Framework-dataprovidern för SQL Server inte skulle kunna fastställa värdena i målkrypterade kolumner, så det skulle inte kryptera värdena. Därför skulle servern avvisa dem som inkompatibla med de krypterade kolumnerna.
- Datatypen för parametern som riktar sig till SSN-kolumnen är inställd på en ANSI-sträng (icke-Unicode), som mappar till datatypen char/varchar SQL Server. Om parametertypen har angetts till en Unicode-sträng (sträng), som mappar till nchar/nvarchar, skulle frågan misslyckas eftersom Always Encrypted inte stöder konverteringar från krypterade nchar/nvarchar-värden till krypterade tecken/varchar-värden. Mer information om datatypsmappningar finns i SQL Server-datatypsmappningar .
- Datatypen för parametern som infogas i kolumnen BirthDate anges uttryckligen till SQL Server-måldatatypen med sqlparameter.SqlDbType-egenskapen, i stället för att förlita sig på implicit mappning av .NET-typer till SQL Server-datatyper som används när du använder egenskapen SqlParameter.DbType. Som standard mappar DateTime Structure till datatypen datetime SQL Server. Eftersom datatypen för kolumnen BirthDate är datum och Always Encrypted inte stöder en konvertering av krypterade datetime-värden till krypterade datumvärden, skulle standardmappningen resultera i ett fel.
string connectionString = "Data Source=server63; Initial Catalog=Clinic; Integrated Security=true; Column Encryption Setting=enabled";
using (SqlConnection connection = new SqlConnection(strbldr.ConnectionString))
{
using (SqlCommand cmd = connection.CreateCommand())
{
cmd.CommandText = @"INSERT INTO [dbo].[Patients] ([SSN], [FirstName], [LastName], [BirthDate]) VALUES (@SSN, @FirstName, @LastName, @BirthDate);";
SqlParameter paramSSN = cmd.CreateParameter();
paramSSN.ParameterName = @"@SSN";
paramSSN.DbType = DbType.AnsiStringFixedLength;
paramSSN.Direction = ParameterDirection.Input;
paramSSN.Value = "795-73-9838";
paramSSN.Size = 11;
cmd.Parameters.Add(paramSSN);
SqlParameter paramFirstName = cmd.CreateParameter();
paramFirstName.ParameterName = @"@FirstName";
paramFirstName.DbType = DbType.String;
paramFirstName.Direction = ParameterDirection.Input;
paramFirstName.Value = "Catherine";
paramFirstName.Size = 50;
cmd.Parameters.Add(paramFirstName);
SqlParameter paramLastName = cmd.CreateParameter();
paramLastName.ParameterName = @"@LastName";
paramLastName.DbType = DbType.String;
paramLastName.Direction = ParameterDirection.Input;
paramLastName.Value = "Abel";
paramLastName.Size = 50;
cmd.Parameters.Add(paramLastName);
SqlParameter paramBirthdate = cmd.CreateParameter();
paramBirthdate.ParameterName = @"@BirthDate";
paramBirthdate.SqlDbType = SqlDbType.Date;
paramBirthdate.Direction = ParameterDirection.Input;
paramBirthdate.Value = new DateTime(1996, 09, 10);
cmd.Parameters.Add(paramBirthdate);
cmd.ExecuteNonQuery();
}
}
Exempel på hämtning av klartextdata
I följande exempel visas filtrering av data baserat på krypterade värden och hämtning av klartextdata från krypterade kolumner. Observera följande:
- Värdet som används i WHERE-satsen för att filtrera på SSN-kolumnen måste skickas med hjälp av SqlParameter, så att .NET Framework-dataprovidern för SQL Server transparent kan kryptera den innan den skickas till databasen.
- Alla värden som skrivs ut av programmet är i klartext, eftersom .NET Framework Data Provider för SQL Server transparent dekrypterar data som hämtats från kolumnerna SSN och BirthDate.
Anmärkning
Frågor kan utföra likhetsjämförelser på kolumner om de krypteras med deterministisk kryptering. Mer information finns i Välja deterministisk eller slumpmässig kryptering.
string connectionString = "Data Source=server63; Initial Catalog=Clinic; Integrated Security=true; Column Encryption Setting=enabled";
using (SqlConnection connection = new SqlConnection(strbldr.ConnectionString))
{
using (SqlCommand cmd = connection.CreateCommand())
{
cmd.CommandText = @"SELECT [SSN], [FirstName], [LastName], [BirthDate] FROM [dbo].[Patients] WHERE SSN=@SSN";
SqlParameter paramSSN = cmd.CreateParameter();
paramSSN.ParameterName = @"@SSN";
paramSSN.DbType = DbType.AnsiStringFixedLength;
paramSSN.Direction = ParameterDirection.Input;
paramSSN.Value = "795-73-9838";
paramSSN.Size = 11;
cmd.Parameters.Add(paramSSN);
using (SqlDataReader reader = cmd.ExecuteReader())
{
if (reader.HasRows)
{
while (reader.Read())
{
Console.WriteLine(@"{0}, {1}, {2}, {3}", reader[0], reader[1], reader[2], ((DateTime)reader[3]).ToShortDateString());
}
Exempel på hämtning av krypterade data
Om Always Encrypted inte är aktiverat kan en fråga fortfarande hämta data från krypterade kolumner, så länge frågan inte har några parametrar för krypterade kolumner.
I följande exempel visas hur du hämtar binära krypterade data från krypterade kolumner. Observera följande:
- Eftersom Always Encrypted inte är aktiverat i anslutningssträngen returnerar frågan krypterade värden för SSN och BirthDate som bytematriser (programmet konverterar värdena till strängar).
- En fråga som hämtar data från krypterade kolumner med Always Encrypted inaktiverad kan ha parametrar, så länge ingen av parametrarna riktar sig mot en krypterad kolumn. Ovanstående fråga filtreras efter LastName, som inte är krypterad i databasen. Om frågan filtreras efter SSN eller BirthDate misslyckas frågan.
string connectionString = "Data Source=server63; Initial Catalog=Clinic; Integrated Security=true";
using (SqlConnection connection = new SqlConnection(connectionString))
{
connection.Open();
using (SqlCommand cmd = connection.CreateCommand())
{
cmd.CommandText = @"SELECT [SSN], [FirstName], [LastName], [BirthDate] FROM [dbo].[Patients] WHERE [LastName]=@LastName";
SqlParameter paramLastName = cmd.CreateParameter();
paramLastName.ParameterName = @"@LastName";
paramLastName.DbType = DbType.String;
paramLastName.Direction = ParameterDirection.Input;
paramLastName.Value = "Abel";
paramLastName.Size = 50;
cmd.Parameters.Add(paramLastName);
using (SqlDataReader reader = cmd.ExecuteReader())
{
if (reader.HasRows)
{
while (reader.Read())
{
Console.WriteLine(@"{0}, {1}, {2}, {3}", BitConverter.ToString((byte[])reader[0]), reader[1], reader[2], BitConverter.ToString((byte[])reader[3]));
}
}
}
Undvik vanliga problem vid frågor om krypterade kolumner
I det här avsnittet beskrivs vanliga felkategorier när du kör frågor mot krypterade kolumner från .NET-program och några riktlinjer för hur du undviker dem.
Konverteringsfel av datatyp som inte stöds
Always Encrypted stöder få konverteringar för krypterade datatyper. Se Always Encrypted för en detaljerad lista över typkonverteringar som stöds. Gör följande för att undvika datatypkonverteringsfel:
- Ange vilka typer av parametrar som är avsedda för krypterade kolumner, så att SQL Server-datatypen för parametern antingen är exakt samma som typen av målkolumn eller en konvertering av SQL Server-datatypen för parametern till måltypen för kolumnen stöds. Du kan använda önskad mappning av .NET-datatyper till specifika SQL Server-datatyper med hjälp av egenskapen SqlParameter.SqlDbType.
- Kontrollera att precisionen och skalan för parametrar som riktar sig mot kolumner för decimal- och numeriska SQL Server-datatyper är samma som precisionen och skalan som konfigurerats för målkolumnen.
- Kontrollera att precisionen för parametrar som riktar sig till kolumner med datetime2, datetimeoffset eller tidpunkten för SQL Server-datatyper inte är större än precisionen för målkolumnen (i frågor som ändrar värden i målkolumnen).
Fel som beror på att klartext skickas i stället för krypterade värden
Alla värden som är inriktade på en krypterad kolumn måste krypteras i programmet. Ett försök att infoga/ändra eller filtrera efter ett oformaterat värde i en krypterad kolumn resulterar i ett fel som liknar detta:
System.Data.SqlClient.SqlException (0x80131904): Operand type clash: varchar is incompatible with varchar(8000) encrypted with (encryption_type = 'DETERMINISTIC', encryption_algorithm_name = 'AEAD_AES_256_CBC_HMAC_SHA_256', column_encryption_key_name = 'CEK_Auto1', column_encryption_key_database_name = 'Clinic') collation_name = 'SQL_Latin1_General_CP1_CI_AS'
Om du vill förhindra sådana fel kontrollerar du att:
- Always Encrypted är aktiverat för programfrågor som riktar sig till krypterade kolumner (för anslutningssträngen eller i SqlCommand-objektet för en specifik fråga).
- Du använder SqlParameter för att skicka data som riktar sig mot krypterade kolumner. I följande exempel visas en fråga som felaktigt filtreras av en literal/konstant i en krypterad kolumn (SSN)(i stället för att skicka literalen inuti ett SqlParameter-objekt).
using (SqlCommand cmd = connection.CreateCommand())
{
cmd.CommandText = @"SELECT [SSN], [FirstName], [LastName], [BirthDate] FROM [dbo].[Patients] WHERE SSN='795-73-9838'";
cmd.ExecuteNonQuery();
}
Arbeta med lagring av kolumnhuvudnycklar
För att kryptera ett parametervärde eller dekryptera data i frågeresultat måste .NET Framework Data Provider för SQL Server hämta en kolumnkrypteringsnyckel som är konfigurerad för målkolumnen. Kolumnkrypteringsnycklar lagras i krypterat formulär i databasmetadata. Varje kolumnkrypteringsnyckel har en motsvarande kolumnhuvudnyckel som användes för att kryptera kolumnkrypteringsnyckeln. Databasmetadata lagrar inte kolumnhuvudnycklarna och innehåller bara information om ett nyckelarkiv som innehåller en viss kolumnhuvudnyckel och platsen för nyckeln i nyckelarkivet.
För att få ett klartextvärde för en kolumnkrypteringsnyckel hämtar .NET Framework Data Provider för SQL Server först metadata om både kolumnkrypteringsnyckeln och dess motsvarande kolumnhuvudnyckel, och sedan använder den informationen i metadata för att kontakta nyckelarkivet, som innehåller kolumnhuvudnyckeln, och för att dekryptera den krypterade kolumnkrypteringsnyckeln. .NET Framework-dataprovidern för SQL Server kommunicerar med ett nyckellager med hjälp av en kolumnnyckellagringsprovider – som är en instans av en klass som härletts från SqlColumnEncryptionKeyStoreProvider-klass.
Processen för att hämta en kolumnkrypteringsnyckel:
Om Always Encrypted är aktiverat för en fråga anropar .NET Framework Data Provider för SQL Server i bakgrunden sys.sp_describe_parameter_encryption för att hämta krypteringsmetadata för parametrar som riktar sig mot krypterade kolumner, om frågan har parametrar. För krypterade data i resultatet av en fråga bifogar SQL Server automatiskt krypteringsmetadata. Informationen om kolumnhuvudnyckeln innehåller:
- Namnet på en nyckellagringsprovider som kapslar in ett nyckelarkiv som innehåller kolumnhuvudnyckeln.
- Nyckelsökvägen som anger platsen för kolumnhuvudnyckeln i nyckelarkivet.
Informationen om kolumnkrypteringsnyckeln innehåller:
- Det krypterade värdet för en kolumnkrypteringsnyckel.
- Namnet på algoritmen som användes för att kryptera kolumnkrypteringsnyckeln.
.NET Framework-dataprovidern för SQL Server använder namnet på kolumnnyckellagringsprovidern för att leta upp providerobjektet (en instans av en klass som härleds från SqlColumnEncryptionKeyStoreProvider Class) i en intern datastruktur.
För att dekryptera kolumnkrypteringsnyckeln anropar .NET Framework Data Provider för SQL Server SqlColumnEncryptionKeyStoreProvider.DecryptColumnEncryptionKey-metoden, skickar kolumnens huvudnyckelsökväg, det krypterade värdet för kolumnkrypteringsnyckeln och namnet på krypteringsalgoritmen som används för att skapa krypteringsnyckeln för krypterad kolumn.
Använda inbyggda huvudnyckellagringsprovider för kolumner
.NET Framework-dataprovidern för SQL Server levereras med följande inbyggda huvudnyckellagringsprovider för kolumner, som är förregistrerade med de specifika providernamnen (används för att leta upp providern).
| Class | Description | Providernamn (sökning) |
|---|---|---|
| SqlColumnEncryptionCertificateStoreProvider-klass | En leverantör för Windows-certifikatsbutik. | MSSQL_CERTIFICATE_STORE |
|
SqlColumnEncryptionCngProvider-klass Obs! Den här providern är tillgänglig i .NET Framework 4.6.1 och senare versioner. |
En provider för ett nyckelarkiv som har stöd för Microsoft Cryptography API: Next Generation (CNG) API. Vanligtvis är ett lager av den här typen en maskinvarusäkerhetsmodul – en fysisk enhet som skyddar och hanterar digitala nycklar och tillhandahåller krypteringsbearbetning. | MSSQL_CNG_STORE |
|
SqlColumnEncryptionCspProvider-klass Obs! Den här providern är tillgänglig i .NET Framework 4.6.1 eller senare versioner. |
En provider för ett nyckelarkiv som stöder Microsoft Cryptography API (CAPI). Vanligtvis är ett lager av den här typen en maskinvarusäkerhetsmodul – en fysisk enhet som skyddar och hanterar digitala nycklar och tillhandahåller krypteringsbearbetning. | MSSQL_CSP_PROVIDER |
Du behöver inte göra några programkodändringar för att använda dessa leverantörer, men observera följande:
- Du (eller din DBA) måste se till att providernamnet, som konfigurerats i kolumnens huvudnyckelmetadata, är korrekt och att kolumnhuvudnyckelsökvägen överensstämmer med det nyckelsökvägsformat som är giltigt för en viss provider. Vi rekommenderar att du konfigurerar nycklarna med hjälp av verktyg som SQL Server Management Studio, som automatiskt genererar giltiga providernamn och nyckelsökvägar när du utfärdar instruktionen CREATE COLUMN MASTER KEY (Transact-SQL). Mer information finns i Konfigurera Always Encrypted med SQL Server Management Studio och Konfigurera Always Encrypted med PowerShell.
- Se till att ditt program kan komma åt nyckeln i nyckelarkivet. Detta kan innebära att du beviljar programmet åtkomst till nyckeln och/eller nyckelarkivet, beroende på nyckelarkivet, eller att utföra andra viktiga lagringsspecifika konfigurationssteg. Om du till exempel vill komma åt ett nyckellager som implementerar CNG eller CAPI (till exempel en maskinvarusäkerhetsmodul) måste du se till att ett bibliotek som implementerar CNG eller CAPI för din butik är installerat på programdatorn. Mer information finns i Skapa och lagra kolumnhuvudnycklar för Always Encrypted.
Använda Azure Key Vault-provider
Azure Key Vault är ett praktiskt alternativ för att lagra och hantera kolumnhuvudnycklar för Always Encrypted (särskilt om dina program finns i Azure). .NET Framework-dataprovidern för SQL Server innehåller inte någon inbyggd kolumnnyckellagringsprovider för Azure Key Vault, men den är tillgänglig som ett NuGet-paket som du enkelt kan integrera med ditt program. Mer information finns i:
- Microsoft.SqlServer.Management.AlwaysEncrypted.AzureKeyVaultProvider
- Always Encrypted – Skydda känsliga data i SQL Database med datakryptering och lagra dina krypteringsnycklar i Azure Key Vault
Implementera en leverantör för nyckellagring av anpassad kolumnhuvudnyckel
Om du vill lagra kolumnhuvudnycklar i ett nyckelarkiv som inte stöds av en befintlig provider kan du implementera en anpassad provider genom att utöka klassen SqlColumnEncryptionCngProvider och registrera providern med hjälp av metoden SqlConnection.RegisterColumnEncryptionKeyStoreProviders .
public class MyCustomKeyStoreProvider : SqlColumnEncryptionKeyStoreProvider
{
public override byte[] EncryptColumnEncryptionKey(string masterKeyPath, string encryptionAlgorithm, byte[] columnEncryptionKey)
{
// Logic for encrypting a column encrypted key.
}
public override byte[] DecryptColumnEncryptionKey(string masterKeyPath, string encryptionAlgorithm, byte[] EncryptedColumnEncryptionKey)
{
// Logic for decrypting a column encrypted key.
}
}
class Program
{
static void Main(string[] args)
{
Dictionary\<string, SqlColumnEncryptionKeyStoreProvider> providers =
new Dictionary\<string, SqlColumnEncryptionKeyStoreProvider>();
providers.Add("MY_CUSTOM_STORE", customProvider);
SqlConnection.RegisterColumnEncryptionKeyStoreProviders(providers);
providers.Add(SqlColumnEncryptionCertificateStoreProvider.ProviderName, customProvider);
SqlConnection.RegisterColumnEncryptionKeyStoreProviders(providers);
// ...
}
}
Använda kolumnhuvudnyckellagringsproviders för programmatisk nyckeletablering
Vid åtkomst till krypterade kolumner söker .NET Framework Data Provider för SQL Server automatiskt efter och anropar den rätta kolumnhuvudnyckellagringsleverantören för att dekryptera kolumnkrypteringsnycklar. Normalt anropar din normala programkod inte kolumnhuvudnyckellagringsprovidrar direkt. Du kan dock instansiera och anropa en provider explicit för att programmatiskt etablera och hantera Always Encrypted-nycklar: för att generera en krypterad kolumnkrypteringsnyckel och dekryptera en kolumnkrypteringsnyckel (till exempel som huvudnyckelrotation för delkolumner). Mer information finns i Översikt över nyckelhantering för Always Encrypted. Du kan bara implementera dina egna nyckelhanteringsverktyg om du använder en anpassad nyckellagringsprovider. När du använder nycklar som lagras i nyckellager, för vilka inbyggda leverantörer finns, och eller i Azure Key Vault, kan du använda befintliga verktyg, till exempel SQL Server Management Studio eller PowerShell, för att hantera och etablera nycklar. Exemplet nedan visar hur du genererar en kolumnkrypteringsnyckel och använder SqlColumnEncryptionCertificateStoreProvider-klassen för att kryptera nyckeln med ett certifikat.
using System.Security.Cryptography;
static void Main(string[] args)
{
byte[] EncryptedColumnEncryptionKey = GetEncryptedColumnEncryptionKey();
Console.WriteLine("0x" + BitConverter.ToString(EncryptedColumnEncryptionKey).Replace("-", ""));
Console.ReadKey();
}
static byte[] GetEncryptedColumnEncryptionKey()
{
int cekLength = 32;
String certificateStoreLocation = "CurrentUser";
String certificateThumbprint = "698C7F8E21B2158E9AED4978ADB147CF66574180";
// Generate the plaintext column encryption key.
byte[] columnEncryptionKey = new byte[cekLength];
RNGCryptoServiceProvider rngCsp = new RNGCryptoServiceProvider();
rngCsp.GetBytes(columnEncryptionKey);
// Encrypt the column encryption key with a certificate.
string keyPath = String.Format(@"{0}/My/{1}", certificateStoreLocation, certificateThumbprint);
SqlColumnEncryptionCertificateStoreProvider provider = new SqlColumnEncryptionCertificateStoreProvider();
return provider.EncryptColumnEncryptionKey(keyPath, @"RSA_OAEP", columnEncryptionKey);
}
Kontrollera prestandapåverkan för Always Encrypted
Eftersom Always Encrypted är en krypteringsteknik på klientsidan observeras de flesta prestandakostnaderna på klientsidan, inte i databasen. Förutom kostnaden för krypterings- och dekrypteringsåtgärder är de andra källorna till prestandakostnader på klientsidan:
- Extra rundresor till databasen för att hämta metadata för frågeparametrar.
- Anropar ett huvudnyckelarkiv för kolumner för att få åtkomst till en kolumnhuvudnyckel.
I det här avsnittet beskrivs de inbyggda prestandaoptimeringarna i .NET Framework-providern för SQL Server och hur du kan styra effekten av ovanstående två faktorer på prestanda.
Styr rundturer för att hämta metadata för frågeparametrar
Om Always Encrypted är aktiverat för en anslutning anropar .NET Framework-dataprovidern för SQL Server som standard sys.sp_describe_parameter_encryption för varje parametriserad fråga och skickar frågeutsatsen (utan parametervärden) till SQL Server. sys.sp_describe_parameter_encryption analyserar frågeutstrukturen för att ta reda på om några parametrar behöver krypteras, och i så fall returnerar den krypteringsrelaterad information som gör det möjligt för .NET Framework Data Provider för SQL Server att kryptera parametervärden. Ovanstående beteende säkerställer en hög transparensnivå för klientprogrammet. Programmet (och programutvecklaren) behöver inte vara medvetna om vilka frågor som har åtkomst till krypterade kolumner, så länge värdena för krypterade kolumner skickas till .NET Framework Data Provider för SQL Server i SqlParameter-objekt.
Cachelagring av frågemetadata
I .NET Framework 4.6.2 och senare cachelagrar .NET Framework-dataprovidern för SQL Server resultatet av sys.sp_describe_parameter_encryption för varje frågeuttryck. Så om samma frågeuttryck körs flera gånger anropar drivrutinen bara sys.sp_describe_parameter_encryption en gång. Cachelagring av krypteringsmetadata för frågeinstruktioner minskar avsevärt prestandakostnaden för att hämta metadata från databasen. Cachelagring är aktiverat som standard. Du kan inaktivera cachelagring av parametermetadata genom att ange egenskapen SqlConnection.ColumnEncryptionQueryMetadataCacheEnabled till false, men det rekommenderas inte förutom i sällsynta fall som den som beskrivs nedan:
Överväg en databas som har två olika scheman: s1 och s2. Varje schema innehåller en tabell med samma namn: t. Definitionerna för tabellerna s1.t och s2.t är identiska, förutom krypteringsrelaterade egenskaper: En kolumn med namnet c, i s1.t krypteras inte och krypteras i s2.t. Databasen har två användare: u1 och u2. Standardschemat för u1 användarna är s1. Standardschemat för u2 är s2. Ett .NET-program öppnar två anslutningar till databasen, personifierar u1 användaren på en anslutning och u2 användaren på en annan anslutning. Programmet skickar en fråga med en parameter som riktar sig mot c kolumnen över anslutningen för användaren u1 (frågan anger inte schemat, så standardanvändarschemat antas). Därefter skickar programmet samma fråga över anslutningen för u2 användaren. Om cachelagring av frågemetadata är aktiverad fylls cacheminnet efter den första frågan med metadata som anger c kolumnen. Frågeparametermålen krypteras inte. Eftersom den andra frågan har samma frågeuttryck används informationen som lagras i cacheminnet. Därför skickar drivrutinen frågan utan att kryptera parametern (vilket är felaktigt, eftersom målkolumnen s2.t.c är krypterad), vilket läcker parameterns klartextvärde till servern. Servern identifierar den inkompatibiliteten och tvingar drivrutinen att uppdatera cachen, så programmet skickar frågan transparent igen med det korrekt krypterade parametervärdet. I sådana fall bör cachelagring inaktiveras för att förhindra läckage av känsliga värden till servern.
Ange Always Encrypted på frågenivå
Om du vill kontrollera prestandapåverkan vid hämtning av krypteringsmetadata för parametriserade frågor kan du aktivera Always Encrypted för enskilda frågor i stället för att konfigurera den för anslutningen. På så sätt kan du se till att sys.sp_describe_parameter_encryption endast anropas för frågor som du vet har parametrar som riktar sig till krypterade kolumner. Observera dock att genom att göra det minskar du transparensen för kryptering: om du ändrar krypteringsegenskaperna för dina databaskolumner kan du behöva ändra koden för ditt program för att justera det med schemaändringarna.
Anmärkning
Inställningen Always Encrypted på frågenivå har begränsade prestandafördelar i .NET 4.6.2 och senare versioner, som implementerar cachelagring av metadata för parameterkryptering.
För att styra Always Encrypted-beteendet för enskilda frågor måste du använda den här konstruktorn för SqlCommand och SqlCommandColumnEncryptionSetting. Här följer några användbara riktlinjer:
- Om ett klientprogram skickar de flesta frågor via en databasanslutning som får åtkomst till krypterade kolumner:
- Ange nyckelordet Kolumnkrypteringsinställning för anslutningssträng till Aktiverad.
- Ange SqlCommandColumnEncryptionSetting.Disabled för enskilda frågor som inte har åtkomst till några krypterade kolumner. Detta inaktiverar både anropande sys.sp_describe_parameter_encryption samt ett försök att dekryptera alla värden i resultatuppsättningen.
- Ange SqlCommandColumnEncryptionSetting.ResultSet för enskilda frågor som inte har några parametrar som kräver kryptering, men hämtar data från krypterade kolumner. Detta inaktiverar anrop av sys.sp_describe_parameter_encryption och parameterkryptering. Frågan kommer att kunna dekryptera resultatet från krypteringskolumner.
- Om de flesta frågor som ett klientprogram skickar via en databasanslutning inte har åtkomst till krypterade kolumner:
- Ange nyckelordet Kolumnkrypteringsinställning i den anslutningssträngen till Inaktiverad.
- Ange SqlCommandColumnEncryptionSetting.Enabled för enskilda frågor som har parametrar som behöver krypteras. Detta möjliggör både anrop av sys.sp_describe_parameter_encryption och dekryptering av eventuella frågeresultat som hämtats från krypterade kolumner.
- Ange SqlCommandColumnEncryptionSetting.ResultSet för frågor som inte har några parametrar som kräver kryptering, men som hämtar data från krypterade kolumner. Detta inaktiverar anrop av sys.sp_describe_parameter_encryption och parameterkryptering. Frågan kommer att kunna dekryptera resultatet från krypteringskolumner.
I exemplet nedan är Always Encrypted inaktiverat för databasanslutningen. Den fråga som applikationen skickar har en parameter som riktar sig mot kolumnen LastName, som inte är krypterad. Frågan hämtar data från kolumnerna SSN och BirthDate som båda är krypterade. I sådana fall krävs inte att anropa sys.sp_describe_parameter_encryption för att hämta krypteringsmetadata. Dekrypteringen av frågeresultatet måste dock aktiveras, så att programmet kan ta emot klartextvärden från de två krypterade kolumnerna. SqlCommandColumnEncryptionSetting.ResultSet-inställningen används för att säkerställa detta.
string connectionString = "Data Source=server63; Initial Catalog=Clinic; Integrated Security=true";
using (SqlConnection connection = new SqlConnection(connectionString))
{
connection.Open();
using (SqlCommand cmd = new SqlCommand(@"SELECT [SSN], [FirstName], [LastName], [BirthDate] FROM [dbo].[Patients] WHERE [LastName]=@LastName",
connection, null, SqlCommandColumnEncryptionSetting.ResultSetOnly))
{
SqlParameter paramLastName = cmd.CreateParameter();
paramLastName.ParameterName = @"@LastName";
paramLastName.DbType = DbType.String;
paramLastName.Direction = ParameterDirection.Input;
paramLastName.Value = "Abel";
paramLastName.Size = 50;
cmd.Parameters.Add(paramLastName);
using (SqlDataReader reader = cmd.ExecuteReader())
{
if (reader.HasRows)
{
while (reader.Read())
{
Console.WriteLine(@"{0}, {1}, {2}, {3}", reader[0], reader[1], reader[2], ((DateTime)reader[3]).ToShortDateString());
}
}
}
}
}
Cachelagring av kolumnkrypteringsnyckel
För att minska antalet anrop till ett nyckellager för kolumnhuvudnycklar för att dekryptera kolumnkrypteringsnycklar cachelagrar .NET Framework Data Provider för SQL Server kolumnkrypteringsnycklarna i klartext i minnet. När drivrutinen har tagit emot det krypterade kolumnkrypteringsnyckelvärdet från databasmetadata försöker den först hitta den okrypterade kolumnkrypteringsnyckeln som motsvarar det krypterade nyckelvärdet. Drivrutinen anropar nyckelarkivet som innehåller kolumnhuvudnyckeln, endast om det inte kan hitta krypteringsnyckelvärdet för krypterad kolumn i cacheminnet.
Anmärkning
I .NET Framework 4.6 och 4.6.1 avlägsnas aldrig kolumnkrypteringsnyckelposterna i cacheminnet. Det innebär att drivrutinen endast kontaktar nyckelarkivet en gång under programmets livslängd för en viss krypterad kolumnkrypteringsnyckel.
I .NET Framework 4.6.2 och senare avlägsnas cacheposterna efter ett konfigurerbart time-to-live-intervall av säkerhetsskäl. Standardvärdet för time to live är 2 timmar. Om du har strängare säkerhetskrav för hur länge kolumnkrypteringsnycklar kan cachelagras i klartext i programmet kan du ändra det med egenskapen SqlConnection.ColumnEncryptionKeyCacheTtl.
Aktivera extra skydd för en komprometterad SQL Server
Som standard förlitar sig .NET Framework Data Provider för SQL Server på databassystemet (SQL Server eller Azure SQL Database) för att tillhandahålla metadata om vilka kolumner i databasen som krypteras och hur. Krypteringsmetadata gör det möjligt för .NET Framework Data Provider för SQL Server att kryptera frågeparametrar och dekryptera frågeresultat utan indata från programmet, vilket avsevärt minskar antalet ändringar som krävs i programmet. Men om SQL Server-processen komprometteras och en angripare manipulerar metadata som SQL Server skickar till .NET Framework Data Provider för SQL Server kan angriparen stjäla känslig information. I det här avsnittet beskrivs API:er som hjälper till att ge en extra skyddsnivå mot den här typen av angrepp, till priset av minskad transparens.
Tvinga parameterkryptering
Innan .NET Framework-dataprovidern för SQL Server skickar en parametriserad fråga till SQL Server ber den SQL Server (genom att anropa sys.sp_describe_parameter_encryption) att analysera frågeutsatsen och ange information om vilka parametrar i frågan som ska krypteras. En komprometterad SQL Server-instans kan vilseleda .NET Framework Data Provider för SQL Server genom att skicka metadata som anger att parametern inte riktar sig mot en krypterad kolumn, även om kolumnen är krypterad i databasen. Därför krypterar .NET Framework-dataprovidern för SQL Server inte parametervärdet och skickar det som klartext till den komprometterade SQL Server-instansen.
För att förhindra en sådan attack kan ett program ange egenskapen SqlParameter.ForceColumnEncryption för parametern till true. Detta gör att .NET Framework-dataprovidern för SQL Server genererar ett undantag, om metadata som den har tagit emot från servern anger att parametern inte behöver krypteras.
Även om användningen av egenskapen SqlParameter.ForceColumnEncryption bidrar till att förbättra säkerheten, minskar det också transparensen för kryptering till klientprogrammet. Om du uppdaterar databasschemat för att ändra uppsättningen krypterade kolumner kan du också behöva göra programändringar.
Följande kodexempel visar hur du använder egenskapen SqlParameter.ForceColumnEncryption för att förhindra att personnummer skickas i klartext till databasen.
SqlCommand cmd = _sqlconn.CreateCommand();
// Use parameterized queries to access Always Encrypted data.
cmd.CommandText = @"SELECT [SSN], [FirstName], [LastName], [BirthDate] FROM [dbo].[Patients] WHERE [SSN] = @SSN;";
SqlParameter paramSSN = cmd.CreateParameter();
paramSSN.ParameterName = @"@SSN";
paramSSN.DbType = DbType.AnsiStringFixedLength;
paramSSN.Direction = ParameterDirection.Input;
paramSSN.Value = ssn;
paramSSN.Size = 11;
paramSSN.ForceColumnEncryption = true;
cmd.Parameters.Add(paramSSN);
SqlDataReader reader = cmd.ExecuteReader();
Konfigurera betrodda huvudnyckelsökvägar för kolumner
Krypteringsmetadata, SQL Server returnerar för frågeparametrar som riktar sig mot krypterade kolumner och för de resultat som hämtas från krypteringskolumner, innehåller nyckelsökvägen för kolumnhuvudnyckeln som identifierar nyckelarkivet och platsen för nyckeln i nyckelarkivet. Om SQL Server-instansen komprometteras kan den skicka nyckelsökvägen som dirigerar .NET Framework-dataprovidern för SQL Server till den plats som kontrolleras av en angripare. Detta kan leda till läckage av autentiseringsuppgifter för nyckelarkivet i fråga om de nyckelarkiv som kräver autentisering av applikationen.
För att förhindra sådana attacker kan programmet ange listan över betrodda nyckelsökvägar för en viss server med hjälp av egenskapen SqlConnection.ColumnEncryptionTrustedMasterKeyPaths. Om the.NET Framework Data Provider för SQL Server tar emot en nyckelsökväg utanför listan över betrodda nyckelsökvägar utlöser den ett undantag.
Även om inställningen av betrodda nyckelsökvägar förbättrar säkerheten för ditt program, måste du ändra koden eller/och konfigurationen av programmet, när du roterar din kolumnhuvudnyckel (när kolumnhuvudnyckelns sökväg ändras).
I följande exempel visas hur du konfigurerar huvudnyckelsökvägar för betrodda kolumner:
// Configure trusted key paths to protect against fake key paths sent by a compromised SQL Server instance
// First, create a list of trusted key paths for your server
List<string> trustedKeyPathList = new List<string>();
trustedKeyPathList.Add("CurrentUser/my/425CFBB9DDDD081BB0061534CE6AB06CB5283F5Ea");
// Register the trusted key path list for your server
SqlConnection.ColumnEncryptionTrustedMasterKeyPaths.Add(serverName, trustedKeyPathList);
Kopiera krypterade data med hjälp av SqlBulkCopy
Med SqlBulkCopy kan du kopiera data, som redan är krypterade och lagrade i en tabell, till en annan tabell, utan att dekryptera data. Så här gör du:
- Kontrollera att krypteringskonfigurationen för måltabellen är identisk med konfigurationen av källtabellen. I synnerhet måste båda tabellerna ha samma kolumner krypterade och kolumnerna måste krypteras med samma krypteringstyper och samma krypteringsnycklar. Obs! Om någon av målkolumnerna krypteras på ett annat sätt än motsvarande källkolumn kan du inte dekryptera data i måltabellen efter kopieringsåtgärden. Data kommer att skadas.
- Konfigurera båda databasanslutningarna, till källtabellen och till måltabellen, utan Always Encrypted aktiverat.
- Ange alternativet AllowEncryptedValueModifications (se SqlBulkCopyOptions). Obs! Var försiktig när du anger AllowEncryptedValueModifications eftersom detta kan leda till att databasen skadas eftersom .NET Framework-dataprovidern för SQL Server inte kontrollerar om data verkligen är krypterade eller om de är korrekt krypterade med samma krypteringstyp, algoritm och nyckel som målkolumnen.
Alternativet AllowEncryptedValueModifications är tillgängligt i .NET Framework 4.6.1 och senare versioner.
Här är ett exempel som kopierar data från en tabell till en annan. Kolumnerna SSN och BirthDate antas vara krypterade.
static public void CopyTablesUsingBulk(string sourceTable, string targetTable)
{
string sourceConnectionString = "Data Source=server63; Initial Catalog=Clinic; Integrated Security=true";
string targetConnectionString = "Data Source= server64; Initial Catalog=Clinic; Integrated Security=true";
using (SqlConnection connSource = new SqlConnection(sourceConnectionString))
{
connSource.Open();
using (SqlCommand cmd = new SqlCommand(string.Format("SELECT [PatientID], [SSN], [FirstName], [LastName], [BirthDate] FROM {0}", sourceTable), connSource))
{
using (SqlDataReader reader = cmd.ExecuteReader())
{
SqlBulkCopy copy = new SqlBulkCopy(targetConnectionString, SqlBulkCopyOptions.KeepIdentity | SqlBulkCopyOptions.AllowEncryptedValueModifications);
copy.EnableStreaming = true;
copy.DestinationTableName = targetTable;
copy.WriteToServer(reader);
}
}
}
Always Encrypted API-referensen
Namnområde:System.Data.SqlClient
Assembly: System.Data (i System.Data.dll)
| Namn | Description | Introducerades i .NET-version |
|---|---|---|
| SqlColumnEncryptionCertificateStoreProvider-klass | En nyckellagringsleverantör för Windows Certificate Store. | 4,6 |
| SqlColumnEncryptionCngProvider-klass | En leverantör av nyckellagring för Microsoft Cryptography API: Next Generation (CNG). | 4.6.1 |
| SqlColumnEncryptionCspProvider-klass | En nyckellagerleverantör för Microsoft CAPI-baserade kryptografiska tjänstleverantörer (CSP). | 4.6.1 |
| SqlColumnEncryptionKeyStoreProvider-klass | Basklass för nyckellagringsleverantörer. | 4,6 |
| SqlCommandColumnEncryptionSetting Enumeration | Inställningar för att aktivera kryptering och dekryptering för en databasanslutning. | 4,6 |
| SqlConnectionColumnEncryptionSetting Enumeration | Inställningar för att styra beteendet för Always Encrypted för enskilda frågor. | 4,6 |
| SqlConnectionStringBuilder.Kolumnkrypteringsinställningsegenskap | Hämtar och anger Always Encrypted i anslutningssträngen. | 4,6 |
| SqlConnection.ColumnEncryptionQueryMetadataCacheEnabled-egenskapen | Aktiverar och inaktiverar cachelagring av metadata för krypteringsfråga. | 4.6.2 |
| SqlConnection.ColumnEncryptionKeyCacheTtl-egenskap | Hämtar och anger livstid för poster i kolumnkrypteringsnyckelns cacheminne. | 4.6.2 |
| SqlConnection.ColumnEncryptionTrustedMasterKeyPaths-egenskapen | Gör att du kan ange en lista över betrodda nyckelsökvägar för en databasserver. Om drivrutinen under bearbetningen av en programfråga tar emot en nyckelsökväg som inte finns med i listan misslyckas frågan. Den här egenskapen ger extra skydd mot säkerhetsattacker som omfattar en komprometterad SQL Server som tillhandahåller falska nyckelsökvägar, vilket kan leda till läckande autentiseringsuppgifter för nyckelarkivet. | 4,6 |
| SqlConnection.RegisterColumnEncryptionKeyStoreProviders Method | Gör att du kan registrera anpassade nyckellagringsleverantörer. Det är ett uppslagsverk som mappar nyckellagringsleverantörsnamn till nyckellagringsleverantörsimplementationer. | 4,6 |
| SqlCommand-konstruktor (String, SqlConnection, SqlTransaction, SqlCommandColumnEncryptionSetting) | Gör att du kan styra beteendet för Always Encrypted för enskilda frågor. | 4,6 |
| SqlParameter.ForceColumnEncryptionProperty | Framtvingar kryptering av en parameter. Om SQL Server informerar drivrutinen om att parametern inte behöver krypteras misslyckas frågan med parametern . Den här egenskapen ger extra skydd mot säkerhetsattacker som innebär att en komprometterad SQL Server tillhandahåller felaktiga krypteringsmetadata till klienten, vilket kan leda till att data avslöjas. | 4,6 |
Nyckelord för ny anslutningssträng : Column Encryption Setting=enabled |
Aktiverar eller inaktiverar Always Encrypted-funktioner för anslutningen. | 4,6 |