Förbättrade data säkerhet i SQL Server 2005


Förbättrade data säkerhet i SQL Server 2005, Säker design, standard och distribution med SQL Server 2005. Nya granulat behörigheter Separation av användare, schema Proxy står för särskilda rättigheter.

Säkerhet och dataintegritet har alltid varit två av de mest grundläggande skälen att lagra data i en relationsdatabas. Det var sant när SQL Server 2000 släpptes, men världen av data-säkerhet har förändrats i allt hemskare sätt sedan dess ..

Som en följd av detta har Microsoft pratat mycket om säkerhetsfrågor som de har brottats med under konstruktions-och utvecklingsstadier av SQL Server  2005. Du kan läsa alla detaljer i SQL Server-webbplats, men följande tre punkter sammanfattar företagets trorvardig Initiative:

  • Secure by design
  • Säker som standard
  • Säker i utbyggnaden

Microsoft har genomfört omfattande hot modellering och säkerhet analys för att identifiera de hot databasservrar, vilket resulterar i en SQL Server 2005 som är säker avsiktligt. Det betyder att du behöver en djupare förståelse av säkerhet än någonsin tidigare, men du har en stor uppsättning verktyg för att tillämpa kunskaperna.

Säkra som standard innebär att SQL Server 2005 är säker ur lådan när du installerar den med standardinställningarna. Funktioner som inte är nödvändiga med en grundläggande databasserver kvar avinstalleras. Den största effekten är att du måste tillbringa mycket tid efter den ursprungliga installationen vrida på de funktioner du behöver och installera ytterligare komponenter. Det betyder också att eftersom du måste göra arbetet med att jaga funktionen och installera den eller slår på den kommer de flesta installationer har en mindre attack yta.

Service Installed Running
Analysis Services No
CLR Integration Yes No
Database Mirroring Yes No
Debugging Yes No
Integration Services No
Notification Services No
Replication No
Reporting Services No
Service Broker Yes No
SQLeMail Yes No
SQLMail Yes No

Trygga i utbyggnaden innebär att Microsoft arbetar för att ge all information och verktyg du behöver för att fatta intelligenta beslut om distribution av SQL Server 2005 säkert. Som du ser finns det många mer säkerhet valmöjligheter än någonsin tidigare, och gör fel val kan alltför lätt kringgå säkerhetsfunktioner. Microsoft ger också verktyg för att hantera säkerhet över tiden. Till exempel kan du installera uppdaterar nu automatiskt. Dessa initiativ har praktiska konsekvenser för administratörer.

Lösenordspolicy: Det första steget i en attack är att få tillgång till servern, utnyttja eventuella svagheter i säkerheten. SQL Server 2005 har många funktioner som gör det säkrare och lättare att låsa ner efter första installationen. En stor förändring är att om du väljer att fortsätta använda inloggningar på SQL Server, kan du binda lösenordspolicy till Windows säkerhet. Detta kräver Windows Server 2003, innebär men ni äntligen kan tvinga lösenord styrka och politik löper ut utan att förlita sig på egenutvecklade lösningar.

Granulärt Behörigheter: Förmodligen den mest genomgripande förändring av SQL Server 2005 säkerhetsinfrastruktur är den nya, mycket granulat tillstånd modell. Tidigare versioner av SQL Server krävs ofta en admin att ge en användare medlemskap i en fast server roll som hade tillstånd alldeles för stor för enkla uppgifter. Detta strider mot principen om minst privilegium och öppnar dörren för missbruk både av användaren och angripare. Förmodligen den mest flagranta exemplet är att revision användas för att begära system admin (SA) privilegier.

SQL Server använder fortfarande den grundläggande bidrag, förneka, och återkalla tillstånd stater i tidigare versioner. Dessutom använder de allmänna behörigheter ordningen ännu en stipendiat som får ett tillstånd antingen på servern eller databasen nivå och en SecurAble som representerar ett objekt, t.ex. en tabell eller hela databasen som behöver skydd. Men en inloggning kan nu ha tillstånd beviljats.

Det finns stora förändringar i nivån på och typen av tillstånd finns tillgängliga, liksom en hierarki av behörigheter som du kan till exempel ge svepande behörigheter till en användare i databasen nivå och sedan kirurgiskt avlägsna liknande närstående rättigheter på bordet nivå. (Se sidofältet “Tillstånd typer” för mer information.)

En av fördelarna med den nyligen granulat tillstånd system är att metadata skyddas nu och data. I tidigare versioner var en användare med tillgång till ett databas kunna se hela strukturen av databasen, oavsett om hon kunde ta del av uppgifterna i den, eller köra något lagrade procedurer. Nu SQL Server 2005 undersöker de behörigheter en huvudmannen har i databasen och kommer bara att visa en katalog bild av objektet, om huvudmannen är ägare eller har någon behörighet inom objektet. Det finns också ett VISA DEFINITION tillstånd som kan ge tillstånd att visa metadata information även utan andra behörigheter i objektet.

Proxy-konton: Precis som SQL Server 2000 har SQL Server 2005 ursprungligen enda SQL Agent proxy konto för att komma åt resurser i nätverket. Men som med tillstånd, ger SQL Server 2005 en mycket mer detaljerad system för fördelning av rättigheter till användare och roller för att utföra SQL Agent jobb. Microsoft har även lagt till ytterligare delsystem du kan använda proxy konton med, även om T-SQL delsystemet fortfarande kör enligt ägaren som den gjorde i SQL Server 2000.

Ledamöter av SA roll, naturligtvis, kan fortfarande göra vad de vill i något av delsystemen. Bevilja någon annan användare rättigheter att använda delsystem kräver att minst en proxy-konto, som kan ge rättigheter till en eller flera delsystem.

Figur 2 visar hur en proxy-konto, MyProxy är tilldelad flera huvudmän-här en användare och en roll. Fullmakten konto använder en referens, som förbinder den med ett konto, vanligtvis en domän konto med behörigheter i operativsystemet behövs för att utföra oberoende uppgifter som krävs av delsystemet. Varje proxy kan ha ett eller flera delsystem i samband med att bevilja den huvudansvarige möjligheten att köra dessa delsystem.

SQL Agent Proxy Account : Det börjar genom att skapa en referens-ett databasobjekt som i detta fall, utgör en länk till operativsystemet konto med rätten att utföra den önskade åtgärder i delsystem. Då lägger en proxy konto, MyProxy, det är verkligen bara en vänlig namn för certifieringen. Därefter tilldelar den proxyn att två huvudmän, i detta fall en SQL Server inloggning och en egen roll. Slutligen associerar fullmakt med alla de fyra SQL Agent delsystem.

CREATE CREDENTIAL MyCredential WITH IDENTITY = ‘MyDOMAINuser1’

GO

msdb..sp_add_proxy @proxy_name = ‘MyProxy’, @credential_name = ‘MyCredential’

GO

msdb..sp_grant_login_to_proxy @login_name = ‘MyLogin’, @proxy_name = ‘MyProxy’

GO

msdb..sp_grant_login_to_proxy @login_name = ‘MyRole’, @proxy_name = ‘MyProxy’

GO

sp_grant_proxy_to_subsystem @proxy_name = ‘MyProxy’, @subsystem_name = ‘ActiveScripting’

GO

sp_grant_proxy_to_subsystem @proxy_name = ‘MyProxy’, @subsystem_name = ‘CmdExec’

GO

sp_grant_proxy_to_subsystem @proxy_name = ‘MyProxy’, @subsystem_name = ‘ANALYSISQUERY’

GO

sp_grant_proxy_to_subsystem @proxy_name = ‘MyProxy’, @subsystem_name = ‘DTS’

GO

En proxy är inte ett sätt att kringgå säkerheten i operativsystemet. Om referensen används med en proxy inte har ett särskilt tillstånd i Windows, som att skriva till en katalog i nätverket kommer fullmakt har inte det heller. Du kan också använda en proxyserver för att bevilja begränsade utförandet rättigheter xp_cmdshell, eftersom det är en favorit verktyg som används av angripare att nått ut till nätet när de äventyrar en SQL Server installation. Fullmakten ger något skydd eftersom även om huvudmannen har obegränsade rättigheter på nätet som gör en domän administratör, alla kommandon som görs via proxy har endast de begränsade rättigheter credential konto.

Användare / Schema Separation: SQL Server har länge stött full server.database.owner.object syntax finns i SQL-specifikationen för fullt namnge objekt, så här:

SELECT * FROM MySERVER.Northwind.dbo.Customers                   enkel eller hur.

I detta fall är servern myserver är databasen Northwind, är ägare dbo, och föremål för intresse är Kunder bordet. Om du har följt Microsofts råd i versioner med hjälp av SQL Server 2000, alla dina användardefinierade objekt ägs av dbo skapar databas ägaren, som automatiskt blir ägare när en medlem i SA fast servern roll objektet.

Om SELECT-uttrycket du nyss såg körs på myserver rutan och Northwind är den aktuella databasen, kan du lämna bort alla prefix och verkställa detta uttalande i stället:

SELECT * FROM Customers

Detta beror på att SQL Server automatiskt ser ut i den aktuella servern i den aktiva databasen och sedan använder antingen den aktuella användaren eller dbo som ägare av objektet.

Enkelheten i denna typ av objekt hänvisning motsäger en viktig förenkling i versioner med hjälp av SQL Server 2000: Trots vad jag sa i de senaste två punkterna, “dbo” i den första SELECT-uttrycket syftar inte till objektets ägare utan objektets schemat. Ett schema är en abstraktion definieras i ANSI SQL specifikation som en sorts hink objekt som äger andra objekt. Hittills användare och scheman var i huvudsak samma sak. När du skapat en ny användare skulle SQL Server skapar ett schema med samma namn och tilldela varje objekt som ägs av användaren för schemat.

I SQL Server 2005-användare behöver i allmänhet inte egna objekt. Istället en eller flera användare eller roller egna scheman, som i sin tur innehåller objekt.

Förutom att vara en ren tillämpning av ANSI SQL, separation av användare från scheman är viktigt av tre skäl. För det första underlättar det objekt som ägs av flera användare eller roller, vilket gör det lättare att administrera nivåer av tillstånd beviljas dessa huvudmän. För det andra är det en administratör livet mycket lättare när en användare som äger objektet lämnar företaget eller har ett byte av jobb ansvar och inte längre är nödvändigt att äga en uppsättning databasobjekt. Inte längre behöver du noggrant lägga till en ny ägare och släppa den gamla ägaren från varje objekt. Nu kan du göra dessa förändringar en tid på schemat och göras med den, vilket gör ägande ledningen på ett kick.

Den tredje fördelen avser återigen minst privilegium. Förr i tiden kan en användare eller roll behövt förhöjd behörighet att arbeta med objekt som ägs av dbo, privilegier som normalt går långt utöver vad som kan behövas för användarna att ändra sitt liten del av en databas. I SQL Server 2005 kan du skapa vilken scheman du behöver för att täcka databasen mål och tilldela äganderätten till varje schema bara till användare och roller som kräver det att göra sitt jobb.

Utförande Bakgrund: SQL Server 2005 ger också mycket mer detaljerade och flexibla behörigheter om verkställighet sammanhang för lagrade procedurer och användardefinierade funktioner, förutom inline bord undervärderat funktioner. Som en del av en CREATE FÖRFARANDE kan du ange säkerheten sammanhang i vilket förfarandet kommer att pågå, om det är i samband med den som ringer (det enda alternativet i SQL Server 2000 och tidigare versioner), som en viss användare, som användaren som skapade förfarandet, eller som ägare. Användaren sammanhang som orsakar den lagrade proceduren för att köra behöver fortfarande få köra tillstånd, men när det förfarande som körs det under angivna säkerheten sammanhang.

Säkerheten samband med T-SQL kod blir kritisk med brutna ägande kedjor, när ägaren av förfarandet inte äger alla objekt tillgängliga för förfarandet. Genom att ange ett utförande sammanhang och därigenom styra användaren under vilken SQL Server kontrollerar denna ägarkedja har du en stor flexibilitet med hur du och hantera objekt ägande.

Det förfarande eller funktion avrättning sammanhang är satt som en del av CREATE FÖRFARANDE uttalande använda MED EXECUTE syntax

CREATE PROC GetCustomersInCountry

    @Country nvarchar(15)

WITH EXECUTE AS ‘User1’

AS

    BEGIN

        SELECT * FROM Customers

        WHERE Country=@Country

    END

GO

GRANT EXECUTE ON GetCustomersInCountry TO User2

GO

När förfarandet har skapats kan användare2 köra proceduren men User1, som anges i EXECUTE AS klausul, måste ha den behörighet som krävs på tabellen Kunder. Om förfarandet uppmanar andra lagrade procedurer, skulle SQL Server genomdriva liknande ägande regler genom att använda User1, snarare än användare2.

Du kan använda någon av fyra former av EXECUTE AS uttalande: EXECUTE AS ringer kan användas när du har en obruten ägarkedja eller om du har god kontroll över ägandet förvaltning.

EXECUTE Som användare = ‘User1 “eller den kortare versionen EXECUTE AS User1” används när du har centraliserat ägande i User1. Detta förenklar ägande förvaltning genom att inte kräva att hantera många användare och ägare.

EXECUTE som egenföretagare är en genväg för den användare som skapade förfarandet. Den faktiska användar-ID sparas i katalogen. Denna form antagligen inte kommer att användas ofta eftersom det skulle vara lätt att splittra ägandet beroende på hur du loggar in på SQL Server.

EXECUTE som ägare kan användas när säkerheten sammanhang bör den nuvarande ägaren av förfarandet, som inte kan en roll. Om det inte finns någon kvalificerad ägare, ägare av modulens schema används som säkerhet sammanhang.

När du använder EXECUTE AS User1 “form, måste användaren verkställande förfarandet uppfylla minst ett av följande villkor för att förhindra användning av genomförandet sammanhang för att kringgå säkerheten:

Han måste vara en sysadmin eller db_owner

Han måste ha Control Server behörigheter på servern eller i databasen

Han måste ha PERSONIFIERA tillstånd för användarnamn

Den svåraste delen av förvaltningen av utvecklare och administratörer som skapar förfaranden verkställa sammanhang växlar först bygga upp en solid ägare grund att ändra utförandet sammanhang. Med den grunden på plats kommer du att kunna hålla god kontroll över vem som kan göra vad i enlighet med principen om minst privilegium.

Kryptering: Det är tveksamt huruvida uppgifter lagras i en säker databas på en säker server på ett säkert nätverk måste krypteras. Trots allt, om ingen obehörig användare kan komma åt data, varför bry sig med hjälp av många bearbetningscykler krävs för kryptering, särskilt för många fält i en stor tabell?

Problemet är att enligt säkerhetsprincipen försvar på djupet, måste man anta att angripare kommer tränga igenom alla murar försvar du resa runt en värdefull resurs. Varje skyddslager gör det mindre sannolikt att en angripare kommer att vinna ett pris, och datakryptering är en slutlig nivå av skydd mot databasen angripare.

SQL Server 2000 och tidigare inte lämnade datakryptering i databasen, men du kan göra det själv, med hjälp av externa COM-komponenter, till exempel. Utomstående krypteringsprodukter är också tillgängliga för dig att använda. SQL Server 2005 ger fullt, interna stöd för kryptering av data med hjälp av anpassade nycklar, digitala certifikat, eller passera fraser.

Datakryptering är lätt nog att använda mogna kryptering bibliotek, såsom de som byggts in. NET basklass biblioteket och Win32 CryptoAPI. Det svåra är att hantera nycklar och lagra dem på ett säkert och hemligt. SQL Server 2005 kan ge central förvaltning för dig eller du kan ta på jobbet själv. I överensstämmelse med den nya granularitet tillstånd, men även enskilda användare kan kryptera data så att bara de kan dekryptera det.

Säg att du har en tabellen Kunder med ett Social Security Number fältet kallas SSN. Detta är den typ av data som du har en stark skyldighet att skydda. Eftersom det kommer att hålla chiffertext är SSN området definieras som en varbinary (60) område. I detta fall ska jag använda ett certifikat som genererats av SQL Server och symmetriska nycklar. Eftersom kryptering finns helt inom SQL Server, som hanterar nycklarna, finns det ingen anledning att vidarebefordra nyckeln över nätverket, som möjliggör en säker användning av symmetriska nycklar.

Det första steget i krypteringen processen är att skapa huvudnyckel som används i databasen för kryptering, ett digitalt certifikat, och den symmetriska nyckeln som används för datakryptering

Skapa Huvudnyckel:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘myPassword’

GO

CREATE CERTIFICATE myCert AUTHORIZATION User1

    WITH SUBJECT = ‘User1Cert’

GO

CREATE SYMMETRIC KEY User1Key

    AUTHORIZATION User1

    WITH ALGORITHM = TRIPLE_DES

    ENCRYPTION BY CERTIFICATE User1Cert

GO

Du kan sedan använda symmetriska nycklar för att kryptera data i SSN området

Öppna symmetrisk nyckel

OPEN SYMMETRIC KEY User1Key USING CERTIFICATE User1Cert

GO

INSERT INTO Customers

    VALUES(1, EncryptByKey(Key_GUID(‘User1Key’), ‘987-65-4321’))

INSERT INTO Customers

    VALUES(2, EncryptByKey(Key_GUID(‘User1Key’), ‘123-45-6789’))

CLOSE ALL SYMMETRIC KEYS

För enkelhetens skull använder detta exempel bara Kund-id primärnyckeln och den krypterade SSN området, och ignorerar uppgifter för andra fält i tabellen.

Koden i Figur 7 använder den nya T-SQL EncryptByKey funktion för att kryptera data in med hjälp av User1Key skapade tidigare. Du kan också använda EncryptByCert att kryptera data med hjälp av ett certifikat eller EncryptByPassphrase att använda en fras som SQL Server använder för att skapa en nyckel. Alla användare som försöker läsa data, även med full tillgång tillstånd på bordet, inte kommer att kunna läsa krypterade data.

Hämta och dekryptera data följer liknande steg, med hjälp av DecryptByKey funktionen, som visas här:

OPEN SYMMETRIC KEY User1Key

    USING CERTIFICATE User1Cert

GO

SELECT CustID, CONVERT(varchar, DecryptByKey(SSN)) as SocialSecurity

    FROM Customers

CLOSE ALL SYMMETRIC KEYS

Konvertera funktionsanropet är nödvändigt eftersom DecryptByKey återvänder varbinary data snarare än textdata.

Detta enkla exempel repor knappt ytan av kryptering funktioner som finns i SQL Server 2005. Som antyds av koden kan du skapa en fullständig hierarki av nycklar som säkra objekt och nycklar under den. Du kan även skapa obegränsat nycklar och certifikat som är förknippade med olika användare och roller.

Slutsats

Som en administratör med ansvar för säkerheten för ditt databasservrar du verkligen kommer att gilla SQL Server 2005. Naturligtvis kommer migrera befintliga databaser ta del arbete ur ett säkerhetsperspektiv, en förändring är närmare besläktade med övergången från SQL Server från 6,5 till 7,0 i stället för SQL Server 7.0 till 2000. Men med granulat behörigheter systemet, SQL Agent proxy konton, datakryptering, genomförande sammanhang, och andra förändringar jag har behandlas här, har du alla verktyg som behövs för att göra din databasservrar man motståndskraftig mot dagens typ av angrepp.

Tillstånd Typer

Följande är några av de nya behörigheter kan du ställa in i SQL Server 2005 och vad de åstadkommer.

KONTROLL ger ägare-liknande tillstånd som effektivt ge alla definierade behörigheter till objektet och alla objekt i dess tillämpningsområde, inklusive möjligheten att ge andra stipendiaterna några behörigheter. Control Server bidrag motsvarande sa privilegier.

FÖRÄNDRA ger tillstånd att ändra några av egenskaperna hos den SecurAble objekt, förutom att byta ägare. Det ger i sig behörighet att ändra, skapa eller DROP SecurAble föremål inom samma räckvidd. Till exempel beviljande ALTER behörigheter för ett databas bidrag som användare behörighet att ändra sitt bord. Beviljande ALTER TRACE bidrag revision behörigheter.

Ändra några <securable objekt> medför behörighet att ändra några objektet i den angivna typen. Till exempel ger inställningen förändra någon MONTERING sig rätten att ändra någon. NET församling i databasen, medan på servernivå beviljande ändra någon LOGGA låter användaren ändra alla inloggning på servern.

PERSONIFIERA <login eller user> ger tillstånd att imitera den angivna användaren eller logga in. Detta tillstånd är nödvändigt att byta utförande sammanhang för lagrade procedurer.

Ta Egendomsrätt ger tillstånd till den behörige att ta ansvar för SecurAble objekt.

Från Ali Khan MS SQL DBA – MCITP www.addarr.com

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s