Delen via

Beperkingen voor CLR-integratieprogrammeermodellen

Applies to:SQL ServerAzure SQL Managed Instance

Wanneer u een beheerde opgeslagen procedure of een ander beheerd databaseobject bouwt, voert SQL Server bepaalde codecontroles uit die moeten worden overwogen. Deze controles worden uitgevoerd op de beheerde codeassembly wanneer deze voor het eerst in de database zijn geregistreerd, met behulp van de CREATE ASSEMBLY-instructie en ook tijdens runtime. De beheerde code wordt ook gecontroleerd tijdens runtime omdat er in een assembly mogelijk codepaden zijn die nooit daadwerkelijk tijdens runtime worden bereikt.

These code checks provide flexibility for registering third-party assemblies especially, so that an assembly isn't blocked where there's unsafe code designed to run in a client environment, but would never be executed in the hosted common language runtime (CLR). De vereisten waaraan de beheerde code moet voldoen, zijn afhankelijk van of de assembly is geregistreerd als SAFE, EXTERNAL_ACCESSof UNSAFE. SAFE is het strengste beveiligingsniveau.

Naast beperkingen die worden ingesteld voor de beheerde codeassembly's, zijn er ook beveiligingsmachtigingen voor code die worden verleend. De CLR ondersteunt een beveiligingsmodel met de naam Code Access Security (CAS) voor beheerde code. In dit model worden machtigingen verleend aan assembly's op basis van de identiteit van de code. SAFE, EXTERNAL_ACCESSen UNSAFE assembly's hebben verschillende CAS-machtigingen. Zie clr-integratiecodetoegangsbeveiliging voor meer informatie.

If the publisher policy is set, CREATE ASSEMBLY fails.

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.

ASSEMBLY-controles MAKEN

Wanneer de CREATE ASSEMBLY-instructie wordt uitgevoerd, worden de volgende controles uitgevoerd voor elk beveiligingsniveau. Als een controle mislukt, mislukt CREATE ASSEMBLY met een foutbericht.

Globaal (elk beveiligingsniveau)

Alle assembly's waarnaar wordt verwezen, moeten voldoen aan een of meer van de volgende criteria:

  • De assembly is al geregistreerd in de database.

  • De assembly is een van de ondersteunde assembly's. Zie Ondersteunde .NET Framework-bibliothekenvoor meer informatie.

  • U gebruikt CREATE ASSEMBLY FROM <location>en alle assembly's waarnaar wordt verwezen en de bijbehorende afhankelijkheden zijn beschikbaar in <location>.

  • U gebruikt CREATE ASSEMBLY FROM <bytes ...>en alle verwijzingen worden opgegeven via door spaties gescheiden bytes.

EXTERNAL_ACCESS

Alle EXTERNAL_ACCESS assembly's moeten voldoen aan de volgende criteria:

  • Statische velden worden niet gebruikt voor het opslaan van gegevens. Statische velden met het kenmerk Alleen-lezen zijn toegestaan.

  • De PEVerify-test wordt doorstaan. Het PEVerify-hulpprogramma (peverify.exe), waarmee wordt gecontroleerd of de algemene tussentaalcode (CIL) en de bijbehorende metagegevens voldoen aan de veiligheidsvereisten van het type, wordt geleverd met de .NET Framework SDK.

  • Synchronisatie, bijvoorbeeld met de klasse SynchronizationAttribute, wordt niet gebruikt.

  • Finalizer-methoden worden niet gebruikt.

De volgende aangepaste kenmerken zijn niet toegestaan in EXTERNAL_ACCESS assembly's:

  • System.ContextStaticAttribute
  • System.MTAThreadAttribute
  • System.Runtime.CompilerServices.MethodImplAttribute
  • System.Runtime.CompilerServices.CompilationRelaxationsAttribute
  • System.Runtime.Remoting.Contexts.ContextAttribute
  • System.Runtime.Remoting.Contexts.SynchronizationAttribute
  • System.Runtime.InteropServices.DllImportAttribute
  • System.Security.Permissions.CodeAccessSecurityAttribute
  • System.Security.SuppressUnmanagedCodeSecurityAttribute
  • System.Security.UnverifiableCodeAttribute
  • System.STAThreadAttribute
  • System.ThreadStaticAttribute

SAFE

  • Alle EXTERNAL_ACCESS assemblyvoorwaarden worden gecontroleerd.

Runtime checks

Tijdens runtime wordt de codeassembly gecontroleerd op de volgende voorwaarden. Als een van deze voorwaarden wordt gevonden, mag de beheerde code niet worden uitgevoerd en wordt er een uitzondering gegenereerd.

UNSAFE

U kunt een assembly niet expliciet laden door de methode System.Reflection.Assembly.Load() aan te roepen vanuit een bytematrix of impliciet met behulp van Reflection.Emit naamruimte.

EXTERNAL_ACCESS

Alle UNSAFE voorwaarden worden gecontroleerd.

Alle typen en methoden die zijn geannoteerd met de volgende HPA-waarden (Host Protection Attribute) in de ondersteunde lijst met assembly's, zijn niet toegestaan.

  • SelfAffectingProcessMgmt
  • SelfAffectingThreading
  • Synchronization
  • SharedState
  • ExternalProcessMgmt
  • ExternalThreading
  • SecurityInfrastructure
  • MayLeakOnAbort
  • UI

Zie Hostbeveiligingskenmerken en CLR-integratieprogrammeringvoor meer informatie over HPA's en een lijst met niet-toegestane typen en leden in de ondersteunde assembly's.

SAFE

Alle EXTERNAL_ACCESS voorwaarden worden gecontroleerd.

Related content