CLR Strict Security na SQL Server 2017

Jak může mít sestavení CLR vytvořené pomocí PERMISSION_SET =SAFE přístup k externím systémovým prostředkům, volání nespravovaného kódu a získávání oprávnění správce systému?

Důvodem jsou bezpečnostní změny provedené v .NET Framework, počínaje verzí 4.5 (věřím).

Dokumentace MSDN pro Základy zabezpečení přístupu ke kódu uvádí:

.NET Framework poskytuje mechanismus pro vynucení různých úrovní důvěry v různém kódu spuštěném ve stejné aplikaci s názvem Code Access Security (CAS). Zabezpečení přístupu ke kódu v .NET Framework by nemělo být používáno jako mechanismus pro vynucení hranic zabezpečení na základě původu kódu nebo jiných aspektů identity. Aktualizujeme naše pokyny, aby odrážely, že Zabezpečení přístupu ke kódu a Transparentní bezpečnostní kód nebudou podporovány jako bezpečnostní hranice s částečně důvěryhodným kódem, zejména kódem neznámého původu. Nedoporučujeme načítat a spouštět kód neznámého původu bez zavedení alternativních bezpečnostních opatření.

A pak ukáže na stránku pro změny zabezpečení v rozhraní .NET Framework, která uvádí:

Nejdůležitější změnou zabezpečení v .NET Framework 4.5 je silné pojmenování.

Což pak ukazuje na dokumentaci pro Enhanced Strong Naming, která uvádí:

Klíče se silným názvem se skládají z podpisového klíče a klíče identity. Sestavení je podepsáno podpisovým klíčem a identifikováno identifikačním klíčem. Před .NET Framework 4.5 byly tyto dva klíče totožné. Počínaje rozhraním .NET Framework 4.5 zůstává klíč identity stejný jako v dřívějších verzích rozhraní .NET Framework, ale podpisový klíč je vylepšen silnějším hashovacím algoritmem. Kromě toho je podpisový klíč podepsán identifikačním klíčem pro vytvoření protipodpisu.

TAKÉ dokumentace pro pokyny k bezpečnému kódování uvádí:

Zabezpečení přístupu ke kódu a transparentní kód zabezpečení nebudou podporovány jako hranice zabezpečení s částečně důvěryhodným kódem. Nedoporučujeme načítat a spouštět kód neznámého původu bez zavedení alternativních bezpečnostních opatření...

Model zabezpečení pro .NET se tedy před lety změnil, ale SQL Server (až do SQL Server 2017) mohl nadále používat starý model zabezpečení. Zdá se, že počínaje SQL Serverem 2017 bylo učiněno rozhodnutí již nadále nepodporovat starý model zabezpečení.

Mám podezření, že povolení starého modelu zabezpečení bylo:

• zabránění tomu, aby SQL Server (alespoň funkce/komponenty související s CLR) byl založen na novějších verzích rozhraní .NET Framework a

• zodpovědný za náhlé odstranění SQLCLR jako podporované funkce z Azure SQL Database (podpora byla přidána koncem roku 2014 se spuštěním verze 12, ale poté byla 15. dubna 2016 zcela odstraněna).

Takže ano, tohle je trochu na hovno. Znamená to (alespoň v tuto chvíli) to, že je potřeba nejprve vytvořte certifikát nebo asymetrický klíč (který byl použit k podepsání jakýchkoli sestav, která mají být načtena) do [master] k vytvoření přihlášení z a poté udělení UNSAFE ASSEMBLY k tomu Přihlášení. Toto je stejná sekvence událostí, kterou je třeba provést při načítání EXTERNAL_ACCESS a UNSAFE Sestavení, ale nyní je bohužel potřeba provést ještě pro SAFE Sestavy.

V současné době neexistuje žádný mechanismus, který by to zvládl zcela přenosným způsobem (tj. nespoléhal se na externí soubory) a nelze jej zpracovat pomocí sady Visual Studio / SSDT bez ručního zásahu. To už tak trochu bylo, ale alespoň bylo možné vytvořit nastavení, které by to zvládlo zcela přenosným způsobem (tj. zcela obsažené ve skriptu .sql):podrobnosti viz Stairway to SQLCLR Level 7:Development and Security (toto je článek, který jsem napsal).

Je možné vytvořit certifikát z hex bajtů (tj. FROM BINARY = 0x... ), ale to nefunguje s Visual Studio (které se spoléhá na MSBuild) / SSDT, protože použití certifikátu vyžaduje použití signtool a MSBuild používá sn .

Aby to bylo funkční tak, aby fungoval proces publikování Visual Studio / MSBuild / SSDT (což by zase znamenalo, že kdokoli by byl schopen vytvořit zcela samostatný skript .sql schopný vytvořit asymetrický klíč, aniž by se spoléhal na externí soubor), CREATE ASYMMETRIC KEY příkaz musí být vylepšen, aby bylo možné vytvořit z binárního řetězce. Tento návrh jsem učinil na Microsoft Connect – Povolit vytvoření asymetrického klíče z binárního řetězce hex bajtů stejně jako CREATE CERTIFICATE – tak jej prosím podpořte :-).

Alternativně (pro tuto chvíli, dokud MS, doufejme, nevytvoří lepší metodu, jako jsou mé návrhy asymetrického klíče), můžete vyzkoušet kteroukoli ze dvou technik, které popisuji v následujících příspěvcích na blogu (obě fungují plně s SSDT):

• SQLCLR vs. SQL Server 2017, část 2:„Přísné zabezpečení CLR“ – řešení 1
• SQLCLR vs. SQL Server 2017, část 3:„Přísné zabezpečení CLR“ – řešení 2

Jako poslední resort, můžete zvážit následující přístup:

1. DOČASNĚ nastavte [master] Databáze TRUSTWORTHY ON

   Pro další krok (tj. CREATE ASSEMBLY ) pro úspěšné provedení přihlášení, které je vlastníkem databáze (tj. stejné SID, jaké používá [dbo] Uživatel [master] ) musí mít UNSAFE ASSEMBLY povolení. Pokud [master] je ve vlastnictví sa nebo jakýkoli jiný správce systému, pak má všechna oprávnění a tento požadavek byl splněn. Ale pokud [master] je vlastněno málo privilegovaným přihlášením ("nejlepší postup"), pak budete muset provést následující příkaz, aby CREATE ASSEMBLY fungovat, když TRUSTWORTHY je ON :

   EXEC (N'USE [master]; GRANT UNSAFE ASSEMBLY TO [{DB_Owner_Login}];');
   

2. Vytvořte sestavení v [master]
3. Vytvořte asymetrický klíč ze sestavy
4. Uvolněte sestavu
5. nastavte [master] Databáze TRUSTWORTHY OFF
6. Vytvořte přihlášení z asymetrického klíče
7. Udělte UNSAFE ASSEMBLY k tomuto přihlášení (toto nahrazuje nutnost, aby DB, kde se sestavení načítá, bylo nastaveno na TRUSTWORTHY ON a pro jeho vlastníka Přihlaste se a získejte UNSAFE ASSEMBLY povolení).

Upozorňujeme, že neudělal(a) zahrnout zde jako možnost novou funkci „Trusted Assembly“. Důvod, proč nebyl zmíněn, je ten, že má mnohem více nedostatků než výhod, nemluvě o tom, že je v první řadě zcela zbytečný vzhledem k tomu, že stávající funkcionalita již řešila situaci, kterou měla "Trusted Assemblies" řešit. Úplné podrobnosti a ukázku správného způsobu, jak zacházet se stávajícími nepodepsanými sestaveními, naleznete v části:SQLCLR vs. SQL Server 2017, část 4:„Důvěryhodná sestavení“ – Zklamání.