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 programmet 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 för lokala databaser eftersom användarautentiseringsuppgifter inte exponeras i niska veze. Om du inte kan använda Windows-autentisering för att ansluta till SQL Server kan du överväga att skapa niska veze vid körning med hjälp av SqlConnectionStringBuilder.
Viktigt!
Microsoft rekommenderar att du använder det säkraste tillgängliga autentiseringsflödet. Om du ansluter till Azure SQL är hanterade identiteter för Azure-resurser den rekommenderade autentiseringsmetoden.
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 anslutningsinformation | Beskriver metodtips och tekniker för säkerhet för att skydda anslutningsinformation, till exempel att använda skyddad konfiguration för att kryptera niska veze. |
| Byggare av anslutningssträngar | Beskriver hur du skapar niska veze från användarindata vid körning. |
| Säkerhet för SQL Server Database Engine och Azure SQL Database | Innehåller länkar som hjälper dig att hitta information om säkerhet och skydd i SQL Server Database Engine och Azure SQL Database. |
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. |
| Lagrade procedurer (databasmotor) | Beskriver fördelarna med att använda lagrade procedurer och de olika typerna av lagrade procedurer. |
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.
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.
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 Interoperating with Unmanaged Code (Samverka med ohanterad kod).