Dela via


Säker dataåtkomst

Om du vill skriva säker ADO.NET kod måste du förstå de säkerhetsmekanismer som är tillgängliga i det underliggande datalagret eller databasen. Du måste också ta hänsyn till säkerhetskonsekvenserna av andra funktioner eller komponenter som ditt program kan innehålla.

Autentisering, auktorisering och behörigheter

När du ansluter till Microsoft SQL Server kan du använda Windows-autentisering, även kallat Integrerad säkerhet, som använder identiteten för den aktuella aktiva Windows-användaren i stället för att skicka ett användar-ID och lösenord. Användning av Windows-autentisering rekommenderas starkt eftersom användarautentiseringsuppgifter inte exponeras i anslutningssträng. Om du inte kan använda Windows-autentisering för att ansluta till SQL Server kan du överväga att skapa anslutningssträng vid körning med hjälp av SqlConnectionStringBuilder.

De autentiseringsuppgifter som används för autentisering måste hanteras på olika sätt baserat på typ av program. I ett Windows Forms-program kan användaren till exempel uppmanas att ange autentiseringsinformation, eller så kan användarens Windows-autentiseringsuppgifter användas. Ett webbprogram kommer dock ofta åt data med hjälp av autentiseringsuppgifter som tillhandahålls av själva programmet i stället för av användaren.

När användarna har autentiserats beror omfattningen av deras åtgärder på de behörigheter som har beviljats dem. Följ alltid principen om lägsta behörighet och bevilja endast behörigheter som är absolut nödvändiga.

Mer information finns i resurserna nedan.

Resurs beskrivning
Skydda Anslut ionsinformation Beskriver rekommenderade säkerhetsmetoder och tekniker för att skydda anslutningsinformation, till exempel att använda skyddad konfiguration för att kryptera anslutningssträng.
Rekommendationer för strategier för dataåtkomst Ger rekommendationer för att komma åt data och utföra databasåtgärder.
Anslut ion String Builders Beskriver hur du skapar anslutningssträng från användarindata vid körning.
Översikt över SQL Server Security Beskriver SQL Server-säkerhetsarkitekturen.

Parametriserade kommandon och SQL-inmatning

Med hjälp av parametriserade kommandon skyddar du mot SQL-inmatningsattacker, där en angripare "matar in" ett kommando i en SQL-instruktion som äventyrar säkerheten på servern. Parametriserade kommandon skyddar mot en SQL-inmatningsattack genom att se till att värden som tas emot från en extern källa endast skickas som värden och inte som en del av Transact-SQL-instruktionen. Därför körs inte Transact-SQL-kommandon som infogas i ett värde i datakällan. I stället utvärderas de enbart som ett parametervärde. Utöver säkerhetsfördelarna ger parametriserade kommandon en praktisk metod för att organisera värden som skickas med en Transact-SQL-instruktion eller till en lagrad procedur.

Mer information om hur du använder parametriserade kommandon finns i följande resurser.

Resurs beskrivning
DataAdapter-parametrar Beskriver hur du använder parametrar med en DataAdapter.
Ändra data med lagrade procedurer Beskriver hur du anger parametrar och hämtar ett returvärde.
Hantera behörigheter med lagrade procedurer i SQL Server Beskriver hur du använder lagrade SQL Server-procedurer för att kapsla in dataåtkomst.

Skriptexploateringar

En skriptexploatering är en annan form av inmatning som använder skadliga tecken som infogas på en webbsida. Webbläsaren verifierar inte de infogade tecknen och bearbetar dem som en del av sidan.

Mer information finns i resurserna nedan.

Resurs beskrivning
Översikt över skriptexploateringar Beskriver hur du skyddar mot sårbarheter i skript och SQL-uttryck.

Avsökningsattacker

Angripare använder ofta information från ett undantag, till exempel namnet på servern, databasen eller tabellen, för att montera ett angrepp på systemet. Eftersom undantag kan innehålla specifik information om ditt program eller din datakälla kan du skydda programmet och datakällan bättre genom att endast exponera viktig information för klienten.

Mer information finns i resurserna nedan.

Resurs beskrivning
Hantera och utlösa undantag i .NET Beskriver de grundläggande formerna för try/catch/slutligen strukturerad undantagshantering.
Metodtips för undantag Beskriver metodtips för hantering av undantag.

Skydda Microsoft Access och Excel-datakällor

Microsoft Access och Microsoft Excel kan fungera som ett datalager för ett ADO.NET program när säkerhetskraven är minimala eller obefintliga. Deras säkerhetsfunktioner är effektiva för avskräckning, men bör inte förlita sig på att göra mer än att avskräcka från inblandning av oinformerade användare. De fysiska datafilerna för Access och Excel finns i filsystemet och måste vara tillgängliga för alla användare. Detta gör dem sårbara för attacker som kan leda till stöld eller dataförlust eftersom filerna enkelt kan kopieras eller ändras. När robust säkerhet krävs använder du SQL Server eller en annan serverbaserad databas där de fysiska datafilerna inte kan läsas från filsystemet.

Mer information om hur du skyddar Access- och Excel-data finns i följande resurser.

Resurs beskrivning
Säkerhetsöverväganden och vägledning för Åtkomst 2007 Beskriver säkerhetstekniker för Access 2007 som krypterar filer, administrerar lösenord, konverterar databaser till de nya ACCDB- och ACCDE-formaten och använder andra säkerhetsalternativ.
Introduktion till Access 2010-säkerhet Ger en översikt över de säkerhetsfunktioner som erbjuds av Access 2010.

Enterprise Services

COM+ innehåller en egen säkerhetsmodell som förlitar sig på Windows-konton och process-/tråd-personifiering. Namnområdet System.EnterpriseServices innehåller omslutningar som gör att .NET-program kan integrera hanterad kod med COM+-säkerhetstjänster via ServicedComponent klassen.

Mer information finns i resursen nedan.

Resurs beskrivning
Rollbaserad säkerhet Beskriver hur du integrerar hanterad kod med COM+-säkerhetstjänster.

Samverka med ohanterad kod

.NET Framework tillhandahåller interaktion med ohanterad kod, inklusive COM-komponenter, COM+-tjänster, externa typbibliotek och många operativsystemtjänster. Att arbeta med ohanterad kod innebär att gå utanför säkerhetsperimetern för hanterad kod. Både din kod och all kod som anropar den måste ha ohanterad kodbehörighet (SecurityPermission med flaggan UnmanagedCode angiven). Ohanterad kod kan medföra oavsiktliga säkerhetsrisker i ditt program. Därför bör du undvika att samverka med ohanterad kod om det inte är absolut nödvändigt.

Mer information finns i resurserna nedan.

Resurs beskrivning
Samverka med ohanterad kod Innehåller ämnen som beskriver hur du exponerar COM-komponenter för .NET Framework och hur du exponerar .NET Framework-komponenter för COM.
Avancerad COM-samverkan Innehåller avancerade ämnen som primära interop-sammansättningar, trådning och anpassad marshalling.

Se även