it-swarm-eu.dev

Jaký je účel databáze „vlastník“?

Dnes jsem při řešení problému s zprostředkovatelem služeb zjistil, že vlastníkem databáze je přihlašovací jméno Windows zaměstnance zaměstnance, který opustil společnost. Jeho přihlašovací jméno bylo odstraněno, takže oznámení dotazů selhala.

Nejlepší postup pro řešení tohoto problému je, aby se z něj stal vlastník databáze. Změnili jsme to a to vyklidilo frontu.

Moje (velmi elementární) otázka: Co je vlastník databáze a jaký je jeho účel?

53
8kb

Tam je nějaký zmatek mezi databázovými koncepty 'dbo' (uživatel) a 'db_owner' (pevná role) na jedné straně a pojmem instance 'vlastník databáze' na druhé straně. 'Dbo' a 'db_owner' se často nazývají 'vlastník databáze'. V tom, o co žádáte, mluvíte o vlastníkovi databáze jako o vedoucím serveru, který vlastní databázi.

Teorie vypadá takto: cokoli, na které lze udělit oprávnění, je 'zabezpečitelné' . Všechny cenné papíry mají majitele. Majitel cenného papíru má absolutní kontrolu nad obchodovatelným cenným papírem a nelze mu odepřít jakoukoli výsadu. Cenné papíry na úrovni instance jsou vlastněny serverem principy (přihlášení). Cenné papíry na úrovni databáze jsou vlastnictvím principů databáze (uživatelů). Ředitel má dvě varianty: primární (identita) a sekundární (členství). Cenné papíry na úrovni serveru jsou ve výchozím nastavení ve vlastnictví aktuálně přihlášeného hlavního serveru. Cenné papíry na úrovni databáze jsou ve výchozím nastavení vlastněny současným hlavním ředitelem databáze, s výjimkou objektů vázaných na schéma, které ve výchozím nastavení vlastní vlastník schématu. Všechny zabezpečovací prvky podporují klauzuli AUTHORIZACE v době vytvoření, aby vynutily jiného vlastníka. ALTER AUTHORIZATION lze později použít ke změně vlastníka jakéhokoli zabezpečitelného.

Protože databáze je zabezpečitelná na úrovni serveru, znamená to, že bude ve výchozím nastavení vlastněna primární hlavní osobou, která vydala příkaz CREATE DATABASE. Tj. NT přihlášení odešlého zaměstnance.

Vaše otázka tedy zní „ Proč cenné papíry potřebují vlastníka? “. Protože majitel je kořenem důvěry. Je to vlastník, který uděluje, zakazuje a odvolává povolení k objektu. Lze bezpečnostní systém navrhnout bez majitelů cenných papírů? Pravděpodobně ano, ale musel by existovat nějaký mechanismus, který nahradí roli, kterou hrají vlastníci v současném modelu. Například se domnívejte, že cenné papíry pro táty nemají vlastníka (např. Místo toho, aby vlastnily zabezpečitelné cenné papíry, původnímu tvůrci je právě uděleno OVLÁDÁNÍ nad ním), bylo by možné vytvořit zabezpečitelné a zrušit přístup k němu všichni , včetně sebe. Tento problém obchází požadavek vlastníka, protože se nemůže sám zamknout.

Málo známý vedlejší účinek CREATE DATABASE vytvoření zabezpečitelného (databáze), který je ve vlastnictví původního NT přihlášení, mnohokrát shořel. Pravidla jsou stejná pro všechny zabezpečitelné, ale některé faktory zhoršují problémy majitelů DATABASE:

  • ostatní zabezpečovací prvky na úrovni serveru (koncový bod, role serveru, přihlášení) se používají zřídka, pohybují se kolem atd.
  • cenné papíry na úrovni databáze obvykle končí tím, že jsou vlastněny dbo (hlavní databázový server) nebo jiným hlavním databázovým agentem, a proto je vlastník obsažen v databázi
  • Mít výchozí nastavení vlastnictví databáze pro primární primární NT vytvoří problém s omezením (vlastník je NT SID spravovaný službou AD a necestuje s databázovými soubory, účet NT může být thumbstoned atd. Atd.)
  • nejdůležitější věc: vlastník databáze má důležité vedlejší účinky, konkrétně EXECUTE AS context . Tento pozdější problém je to, co spálí většinu uživatelů. Protože Service Broker rozsáhle využívá EXECUTE AS (doručování zpráv má implicitní kontext EXECUTE AS, stejně jako aktivaci fronty, která má explicitní), jsou obvykle uživatelé Service Broker, kteří tento problém objevují jako první.

BTW, Kudos za prozkoumání a vyřešení vašeho původního problému :)

59
Remus Rusanu

Databáze owner je trochu házení zpět do doby, než byly (správné) schémata zavedeny v SQL Sever 2005.

V zásadě je vlastníkem databáze výchozí dbo (vlastník databáze) databáze, přičemž samotná databáze je databázový objekt .

Z SQL Server 20 dokumentů ...

dbo je uživatel, který implikoval oprávnění k provádění všech činností v databázi.

V dřívějších verzích serveru SQL, kdy schéma nemohlo „vlastnit“ objekt ( nebo spíše by mělo být uvedeno, že všechny objekty, tabulky, pohledy atd. Byly vlastněny dbo a tam nebyli žádná jiná schémata) bylo nutné, aby to „uživatel“ vlastnil ... mělo by být samozřejmé, proč něco potřebuje vlastnit databázi (nebo jinak oprávnění v obecně by bylo docela obtížné.)

Takže technicky ve starších verzích serveru SQL (nebo upgradovaných databází) to nebyla tabulka „Foo“, byla to tabulka „dbo.Foo“ ... s vlastníkem dbo.

S příchodem serveru SQL Server 2005 můžete mít databázové objekty vlastněné schématem, jako je například schéma s názvem „bar“ a tabulka s názvem „Foo“ ... to se stane bar.Foo jako v ...

SELECT * FROM bar.Foo WHERE etc = 'blah`;

Ošidná část přichází s tím, že uživatel vytváří databáze je automaticky nastavena jako vlastník , což vede k problémy s obratem zaměstnance atd.

Proto je nejlepší postup buď tento účet změnit na účet sa, nebo snad (podle mých zkušeností) na účet domény, který může spravovat tým ops/IT organizace.

Tento článek poskytuje přehled o rozdílu mezi staršími způsoby „vlastníka“ a novějším vlastnickým systémem založeným na „schématu“.

Abychom porozuměli rozdílu mezi vlastníky a schématy, věnujme trochu času kontrole vlastnictví objektu. Při vytvoření objektu v SQL Server 2000 nebo starší, musí mít objekt vlastníka. Většinou je vlastníkem „dbo“, také známý jako vlastník databáze.

14
Justin Jenkins