Not
Åtkomst till denna sida kräver auktorisation. Du kan prova att logga in eller byta katalog.
Åtkomst till denna sida kräver auktorisation. Du kan prova att byta katalog.
Det finns inget enda korrekt sätt att skapa ett säkert SQL Server-klientprogram. Varje program är unikt i sina krav, distributionsmiljö och användarpopulation. Ett program som är ganska säkert när det distribueras kan bli mindre säkert över tid. Det är omöjligt att med noggrannhet förutsäga vilka hot som kan uppstå i framtiden.
SQL Server, som en produkt, har utvecklats över många versioner för att införliva de senaste säkerhetsfunktionerna som gör det möjligt för utvecklare att skapa säkra databasprogram. Säkerhet kommer dock inte förinstallerad; det kräver kontinuerlig övervakning och uppdatering.
Vanliga hot
Utvecklare måste förstå säkerhetshot, de verktyg som tillhandahålls för att motverka dem och hur man undviker självförvållade säkerhetshål. Säkerhet kan bäst ses som en kedja, där en paus i en länk äventyrar helhetens styrka. Följande lista innehåller några vanliga säkerhetshot som beskrivs mer detaljerat i avsnitten i det här avsnittet.
SQL-injektion
SQL-inmatning är den process genom vilken en obehörig användare anger Transact-SQL-instruktioner i stället för giltiga indata. Om indata skickas direkt till servern utan att verifieras och om programmet oavsiktligt kör den inmatade koden kan attacken skada eller förstöra data. Du kan förhindra SQL Server-inmatningsattacker genom att använda lagrade procedurer och parametriserade kommandon, undvika dynamisk SQL och begränsa behörigheter för alla användare.
Utökade privilegier
Privilegieförhöjningsattacker uppstår när en användare kan överta behörigheterna för ett betrott konto, till exempel en ägare eller administratör. Kör alltid under minst privilegierade användarkonton och tilldela endast nödvändiga behörigheter. Undvik att använda administrativa konton eller ägarkonton för att köra kod. Detta begränsar mängden skada som kan uppstå om en attack lyckas. När du utför uppgifter som kräver ytterligare behörigheter ska du endast använda procedursignering eller personifiering under uppgiftens varaktighet. Du kan signera lagrade procedurer med certifikat eller använda personifiering för att tillfälligt tilldela behörigheter.
Avsökning och intelligent observation
En avsökningsattack kan använda felmeddelanden som genereras av ett program för att söka efter säkerhetsrisker. Implementera felhantering i all procedurkod för att förhindra att SQL Server-felinformation returneras till slutanvändaren.
Authentication
En anslutningssträngsinmatningsattack kan inträffa när du använder SQL Server-inloggningar om en anslutningssträng som baseras på användarindata skapas vid körning. Om anslutningssträngen inte kontrolleras för giltiga nyckelordspar kan en angripare infoga extra tecken, eventuellt komma åt känsliga data eller andra resurser på servern. Använd Windows-autentisering när det är möjligt. Om du måste använda SQL Server-inloggningar, använd SqlConnectionStringBuilder för att skapa och verifiera anslutningssträngar vid körning.
Passwords
Många attacker lyckas eftersom en inkräktare kunde hämta eller gissa ett lösenord för en privilegierad användare. Lösenord är din första försvarslinje mot inkräktare, så det är viktigt att ange starka lösenord för systemets säkerhet. Skapa och tillämpa lösenordsprinciper för autentisering i blandat läge.
Tilldela alltid ett starkt lösenord till sa kontot, även när du använder Windows-autentisering.
I det här avsnittet
Skriva säker dynamisk SQL i SQL Server
Beskriver tekniker för att skriva säker dynamisk SQL med lagrade procedurer.