Mrkněte na obrázek! SQL Server 2012 konečně podporuje servisní účty (service accounts). A nejenom že je podporuje, ale rovnou to nabízí jako výchozí možnost.
Tahle fíčura je ve Windows od verze 6.0, tedy od Windows Vista a Windows 2008. Obrázek je sice z Windows Server 2012, ale takhle se to bude chovat i na Windows 2008/R2.
Prostě každá služba může běžet pod svým vlastním lokálním účtem. Pro každou službu systém vytváří jakýsi virtuální účet stejného jména. Služby mají jména unikátní, tak proč ne, že? Když máte například službu BITS, tak ona má automaticky k dispozici účet NT SERVICE\BITS. Služba Print Spooler má účet NT SERVICE\Spooler.
Pro zajímavost, SIDy domény NT SERVICE jsou S-1-5-80-.
Jaké to má vlastnosti?
Na lokálním stroji to běží pouze jako člen skupiny Users. Je to tedy podobné jako obecnější Network Service. Výhoda oproti Network Service je místní izolace. Když dvě služby běží pod stejným účtem, například právě Network Service, mohou se vzájemě ovlivňovat, přistupovat si do paměti apod. Takže si mohou třeba vykrádat data.
Takže pokud dáte službu pod její vlastní účet, máte ji izolovanou. Kvůli tomu se dřív musely vytvářet služební účty v Active Directory, teďka už to z tohohle důvodu nepotřebujete.
To znamená místní izolace.
Ze síťového pohledu je to ale starý dobrý Network Service. Kerberos tikety (TGS) to přijímá pro účet počítače. Pokud daná služba potřebuje jít sama do sítě, tak zase použije účet počítače, na kterém běží. Pokud nastavujete delegaci, musíte ji povolit pro účet počítače. Má to taky výhodu, že účty počítačů si, na rozdíl od AD uživatelských účtů, mohou samy registrovat SPN a nemusíte jim nic dodatečně povolovat.
Takže ze síťového pohledu tu izolace není. Dvě služby běžící pod různými servisními účty (NT SERVICE) na stejném počítači budou v síti vidět pod stejným účtem počítače. Takže tu ještě stále zůstává prostor pro Active Directory servisní účty.
Jenže právě v případě SQL Serveru to ovykle nepotřebujete. Na přední straně mě izolace nezajímá, protože SPN (Service Principal Name) je specifické přesně podle instance (něco jako MSSQLSVC\servername:1433 pro TCP nebo MSSQLSVC\servername:INSTANCE pro named pipes). Na zadní straně mě to nejspíš taky nezajímá, protože případů, kdy SQL Server potřebuje sám chodit do sítě je minimum.
Pravidla pro Windows Firewall
Ještě jedna nenápadná výhoda. Konečně se ta služba instaluje se servisní identitou, takže pro ni můžete vytvářet pravidla ve firewallu. Cože?
No Windows Firewall přece umí omezit pravidlo nejen podle diskové .EXEservice isolation nebo service hardening. Jenže tohle u staršího SQL Server 2008/R22 nefungovalo. EXE cesta ano, ale ne výběr služby - tedy vybrat to šlo, ale pak to nefungovalo :-) Důvod?
Když na Windows Vista a novější nainstalujete službu, při instalaci jí musíte nechat nastavit typ SIDu. Každá služba má svůj SID. Ale ten SID má ještě něco, co se jmenuje . Zkuste si v příkazové řádce třeba::
sc qsidtype bits
sc qsidtype netlogon
sc qsidtype bfe
Ve výsledku uvidíte položku SERVICE_SID_TYPE s hodnotou NONE, UNRESTRICTED, nebo RESTRICTEDD. Významy unrestricted a restricted bych si nechal na příště. Zde jen poznamenejme, že pokud má služba none, nejde pro ni udělat service hardening pravidlo ve Windows Firewalll.
Aplikace a jejich instalace, které na to nejsou nachystané, se instalují výchozně s NONE. Sice se to dá později ručně přepnout pomocí:
sc sidtypee
ale není to výchozí. Takže se rozlučte se service isolation pravidly explicitně pro klientské služby DPM 2007, DPM 2010, SCOM 2007, SCCM 2007 a třeba právě SQL Server 2008 R2 a starší.
Zato SQL Server 2012 si už konečně při instalaci nastavuje svůj SID type na UNRESTRICTED a tím pádem lze vytváře service hardening pravidla.