Toegangsbeveiliging voor CLR-integratiecode

Applies to:SQL Server

De Common Language Runtime (CLR) ondersteunt een beveiligingsmodel met de naam codetoegangsbeveiliging voor beheerde code. In dit model worden machtigingen verleend aan assembly's op basis van de identiteit van de code. Zie Code Access Securityvoor meer informatie.

Het beveiligingsbeleid dat bepaalt welke machtigingen aan assembly's worden verleend, wordt op drie verschillende plaatsen gedefinieerd:

• Machine policy: This policy is in effect for all managed code running in the machine on which SQL Server is installed.

• User policy: This policy is in effect for managed code hosted by a process. Voor SQL Server is het gebruikersbeleid specifiek voor het Windows-account waarop de SQL Server-service wordt uitgevoerd.

• Host policy: This policy is set up by the host of the CLR (in this case, SQL Server) that is in effect for managed code running in that host.

Het beveiligingsmechanisme voor codetoegang dat door de CLR wordt ondersteund, is gebaseerd op de veronderstelling dat de runtime zowel volledig vertrouwde als gedeeltelijk vertrouwde code kan hosten. De resources die worden beveiligd door clr-codetoegangsbeveiliging, worden doorgaans verpakt door beheerde toepassingsprogrammeringsinterfaces waarvoor de bijbehorende machtiging is vereist voordat toegang tot de resource wordt toegestaan. De vraag naar de machtiging wordt alleen voldaan als alle bellers (op assemblyniveau) in de aanroepstack de bijbehorende resourcemachtiging hebben.

De set beveiligingsmachtigingen voor codetoegang die worden verleend aan beheerde code bij uitvoering in SQL Server, is het snijpunt van de set machtigingen die zijn verleend door de vorige drie beleidsniveaus. Zelfs als SQL Server een set machtigingen verleent aan een assembly die in SQL Server is geladen, kan de uiteindelijke set machtigingen die aan gebruikerscode worden gegeven, verder worden beperkt door het beleid op gebruikers- en computerniveau.

Beveiliging van codetoegang wordt niet meer ondersteund

CLR maakt gebruik van CAS (Code Access Security) in .NET Framework, dat niet meer wordt ondersteund als een beveiligingsgrens. Een CLR-assembly die is gemaakt met PERMISSION_SET = SAFE kan mogelijk toegang krijgen tot externe systeembronnen, onbeheerde code aanroepen en sysadmin-bevoegdheden verkrijgen. In SQL Server 2017 (14.x) en latere versies verbetert de sp_configure optie, strikte beveiliging, de beveiliging van CLR-assembly's. clr strict security is standaard ingeschakeld en behandelt SAFE en EXTERNAL_ACCESS assembly's alsof ze zijn gemarkeerd als UNSAFE. De optie clr strict security kan worden uitgeschakeld voor achterwaartse compatibiliteit, maar wordt niet aanbevolen.

We raden aan alle assembly's te ondertekenen met een certificaat of asymmetrische sleutel, waarbij een bijbehorende login UNSAFE ASSEMBLY machtigingen heeft in de master-database. SQL Server-beheerders kunnen ook assembly's toevoegen aan een lijst met assembly's, die de Database Engine moet vertrouwen. For more information, see sys.sp_add_trusted_assembly.

Machtigingensets op hostbeleidsniveau van SQL Server

De set beveiligingsmachtigingen voor codetoegang die zijn verleend aan assembly's op het niveau van het SQL Server-hostbeleid, wordt bepaald door de machtigingenset die is opgegeven bij het maken van de assembly. There are three permission sets: SAFE, EXTERNAL_ACCESS, and UNSAFE (specified using the PERMISSION_SET option of CREATE ASSEMBLY).

SQL Server levert een beveiligingsbeleidsniveau op hostniveau aan de CLR tijdens het hosten ervan. Dit beleid is een extra beleidsniveau onder de twee beleidsniveaus die altijd van kracht zijn. Dit beleid wordt ingesteld voor elk toepassingsdomein dat door SQL Server wordt gemaakt. Dit beleid is niet bedoeld voor het standaardtoepassingsdomein dat van kracht zou zijn wanneer SQL Server een exemplaar van de CLR maakt.

Het beleid op hostniveau van SQL Server is een combinatie van vast SQL Server-beleid voor systeemassembly's en door de gebruiker opgegeven beleid voor gebruikersassembly's.

Het vaste beleid voor CLR-assembly's en SQL Server-systeemassembly's verleent deze volledige vertrouwensrelatie.

Het door de gebruiker opgegeven gedeelte van het SQL Server-hostbeleid is gebaseerd op de assembly-eigenaar die een van de drie machtigingsbuckets voor elke assembly opgeeft. Zie de .NET Framework SDK voor meer informatie over de volgende beveiligingsmachtigingen.

SAFE

Alleen interne berekeningen en lokale gegevenstoegang zijn toegestaan. SAFE is de meest beperkende machtigingenset. Code die wordt uitgevoerd door een assembly met SAFE machtigingen heeft geen toegang tot externe systeembronnen, zoals bestanden, het netwerk, omgevingsvariabelen of het register.

SAFE assembly's beschikken over de volgende machtigingen en waarden:

EXTERNAL_ACCESS

EXTERNAL_ACCESS assembly's dezelfde machtigingen hebben als SAFE assembly's, met de extra mogelijkheid om toegang te krijgen tot externe systeembronnen, zoals bestanden, netwerken, omgevingsvariabelen en het register.

EXTERNAL_ACCESS assembly's hebben ook de volgende machtigingen en waarden:

UNSAFE

UNSAFE staat assembly's onbeperkte toegang tot resources toe, zowel binnen als buiten SQL Server. Code die vanuit een UNSAFE assembly wordt uitgevoerd, kan ook onbeheerde code aanroepen.

UNSAFE assembly's worden FullTrustgegeven.

Aanbevolen machtigingsinstellingen

SAFE is de aanbevolen machtigingsinstelling voor assembly's die reken- en gegevensbeheertaken uitvoeren zonder toegang te krijgen tot resources buiten SQL Server.

EXTERNAL_ACCESS wordt aanbevolen voor assembly's die toegang hebben tot resources buiten SQL Server. EXTERNAL_ACCESS assembly's standaard uitvoeren als het SQL Server-serviceaccount. Het is mogelijk dat EXTERNAL_ACCESS code expliciet de beveiligingscontext voor Windows-verificatie van de beller imiteert. Omdat de standaardinstelling is om uit te voeren als het SQL Server-serviceaccount, mag u alleen toestemming geven voor het uitvoeren van EXTERNAL_ACCESS worden verleend aan aanmeldingen die worden vertrouwd om te worden uitgevoerd als het serviceaccount.

Vanuit beveiligingsperspectief zijn EXTERNAL_ACCESS en UNSAFE assembly's identiek. EXTERNAL_ACCESS assembly's bieden echter verschillende betrouwbaarheids- en robuustheidsbeveiligingen die zich niet in UNSAFE assembly's.

Als u UNSAFE opgeeft, kan de code in de assembly illegale bewerkingen uitvoeren op de SQL Server-procesruimte, waardoor de robuustheid en schaalbaarheid van SQL Server mogelijk worden aangetast. Zie CLR-integratieassembly's beherenvoor meer informatie over het maken van CLR-assembly's in SQL Server.

Toegang tot externe resources

Als een door de gebruiker gedefinieerd type (UDT), opgeslagen procedure of een ander type constructassembly is geregistreerd bij de SAFE machtigingenset, heeft beheerde code die in de constructie wordt uitgevoerd, geen toegang tot externe resources. Als echter de EXTERNAL_ACCESS of UNSAFE machtigingensets zijn opgegeven en beheerde code toegang probeert te krijgen tot externe resources, past SQL Server de volgende regels toe:

Samenvatting van machtigingenset

De volgende grafiek bevat een overzicht van de beperkingen en machtigingen die zijn verleend aan de SAFE, EXTERNAL_ACCESSen UNSAFE machtigingensets.

Related content

• CLR-integratiebeveiliging
• hostbeveiligingskenmerken en het programmeren van CLR-integraties
• beperkingen voor CLR-integratieprogrammeermodel
• CLR-integratiearchitectuur - door CLR gehoste omgeving