Den TRUSTWORTHY egenskab for en database (når den er sat til ON ) erklærer i det væsentlige til SQL Server, at kode, der er indeholdt i den pågældende database, og som udføres i en efterlignet kontekst, skal have tilladelse til at nå uden for denne database, mens den efterlignede sikkerhedskontekst bibeholdes. Det giver også mulighed for alle SQLCLR samler i den database, der skal indstilles til EXTERNAL_ACCESS og UNSAFE , uanset om koden når uden for serveren eller ej (udenfor betydning:netværksadgang, filsystemadgang, registreringsdatabaseadgang, miljøadgang osv.).
Det er et ret generisk middel til at tillade dette, da det dækker al kode i databasen. Brug af certifikater og/eller asymmetriske nøgler til at signere moduler – procs og/eller samlinger – giver mulighed for mere detaljeret kontrol over, hvilken kode der har hvilke tilladelser.
Indstilling af en database til TRUSTWORTHY gør det også muligt for enhver proces, der starter i denne database, at nå op til serverniveau og/eller over til andre databaser. Normalt er en proces begrænset / i karantæne til den database, hvor den startede. Hvis databasen ejes af "sa"-logonet, vil enhver proces, der startes i den database og kører som "dbo", faktisk have "sa"-privilegier (yikes!).
I stedet for at prøve at beskrive her, i mængden af detaljer, der kræves for fuldt ud at kommunikere detaljerne om personefterligning, udvide nævnte personefterligning, underskrive moduler osv., anbefaler jeg, at du læser følgende ressourcer om dette emne:
- VENLIGST, venligst , stop venligst med at bruge personefterligning, TRUSTWORTHY og Cross-DB Ownership Chaining
- Retningslinjer for brug af TRUSTWORTHY-databaseindstillingen i SQL Server
- Udvidelse af databaseefterligning ved at bruge EXECUTE AS
Dette er et meget informativt dokument, der dækker de fleste aspekter af dette emne, og der henvises også til den side, der er linket til ovenfor. - Trappe til SQLCLR Niveau 4:Sikkerhed (EKSTERNE og USIKRE forsamlinger)
Dette er en artikel, jeg skrev som en del af en serie om SQLCLR, der har eksempler, der illustrerer forskellene mellem TRUSTWORTHY-metoden og den Signed Assembly-baserede login-metode; Gratis registrering er påkrævet.
Du bør undgå at indstille din database til TRUSTWORTHY så meget som muligt. Hvis du virkelig skal have multithreading / async opkald OG hvis du har kildekoden og kompilerer samlingen, så kan jeg ikke komme i tanke om en grund til at bruge SET TRUSTWORTHY ON mulighed. I stedet bør du underskrive forsamlingen med en adgangskode og brug følgende kommandoer til at opsætte den foretrukne metode til at tillade EXTERNAL_ACCESS og UNSAFE samlinger:
USE [master];
CREATE ASYMMETRIC KEY [ClrPermissionsKey]
AUTHORIZATION [dbo]
FROM EXECUTABLE FILE = 'C:\path\to\my\assembly.dll';
CREATE LOGIN [ClrPermissionsLogin]
FROM ASYMMETRIC KEY [ClrPermissionsKey];
GRANT UNSAFE ASSEMBLY TO [ClrPermissionsLogin];
Når det er på plads, kan du gå til databasen, hvor din samling er blevet indlæst og køre:
ALTER ASSEMBLY [MyAssembly] WITH PERMISSION_SET = UNSAFE;
Eller du kunne have inkluderet WITH PERMISSION_SET = UNSAFE i slutningen af CREATE ASSEMBLY kommando.