'Sahibinin' veritabanının amacı nedir?

Bugün, bir hizmet brokeri sorununu giderirken, veritabanı sahibinin, şirketten ayrılan bir çalışanın Windows girişi olduğunu öğrendim. Girişi kaldırıldı ve bu nedenle sorgu bildirimleri başarısız oldu.

Sözde bununla başa çıkmak için en iyi uygulama veritabanı sahibi yapmaktır. Bunu değiştirdik ve bu sırada sırayı temizledi.

Benim (çok basit) sorum: veritabanı sahibi nedir ve amacı nedir?

Bir taraftaki 'dbo' (bir kullanıcı) ve 'db_owner' (sabit bir rol) veritabanı kavramları ile diğer taraftaki 'veritabanı sahibi' kavramının arasında bazı karışıklıklar var. 'Dbo' ve 'db_owner' genellikle 'veritabanı sahibi' olarak adlandırılır. Ne soruyorsanız, veritabanının sahibi olan sunucu sorumlusu olarak veritabanı sahibi hakkında konuşuyorsunuz.

Teori şöyle devam eder: izin verilebilecek herhangi bir şey 'güvence altına alınabilir' . Tüm güvenlik görevlilerinin sahibi var. Bir güvenilirin sahibi, güvenilirler üzerinde mutlak kontrole sahiptir ve hiçbir imtiyazın reddedilemez. Eşgörünüm düzeyi güvenceleri, sunucu yöneticilerine aittir (girişler). Veri tabanı düzeyinde güvenlik altına alınabilirler, veritabanı yöneticilerine (kullanıcılar) aittir. Müdür iki lezzetle gelir: birincil (kimlik) ve ikincil (üyelik). Sunucu düzeyinde güvenilirler, varsayılan olarak şu anda oturum açmış olan birincil sunucu sorumlusuna aittir. Veritabanı düzeyinde güvenlik altına alınabilirler, varsayılan olarak şema sahibinin sahip olduğu şemaya bağlı nesneler dışında, geçerli veritabanı sorumlusu tarafından varsayılan olarak aittir. Tüm güvenilirler, farklı bir sahibini zorlamak için oluşturma anında YETKI madde maddesini destekler.ALTER AUTHORIZATION daha sonra güvenilir olanların sahibini değiştirmek için kullanılabilir.

Veri tabanı bir sunucu düzeyinde güvence altına alınabildiği için, varsayılan olarak, CREATE DATABASE ifadesini yayınlayan birincil sorumlusuna ait olacağını takip eder. Yani. Ayrılan çalışanın NT girişi.

Bu yüzden sorunuz gerçekten " Güvenilebilirlerin neden bir sahibine ihtiyacı var? " Çünkü sahibi güven kökenidir. Nesne üzerindeki izni veren, reddeden ve iptal eden sahibidir. Bir güvenlik sistemi güvence sahibi olmadan tasarlanabilir mi? Muhtemelen evet, ancak mevcut modelde sahiplerin rolünü değiştirmek için bir mekanizma olması gerekecekti. Örneğin, baba güvence sahiplerinin hiçbir sahibine sahip olmadığını düşünün (örneğin, güvenilebilir olana sahip olmak yerine, orijinal yaratıcıya sadece üzerinde KONTROL verilir) , kendisi de dahil olmak üzere herkes için güvenli ve oluşturulabilir bir erişim oluşturmak mümkün olabilir . Bir mal sahibinin ihtiyacı bu sorunu çözüyor çünkü mal sahibi kendini kilitleyemiyor.

CREATE DATABASE'in orijinal NT oturum açma sistemine ait güvenli bir veri tabanı (veritabanı) oluşturmasının az bilinen bir etkisi daha önce çok yakılmıştı. Kurallar her güvenilir için aynıdır, ancak bazı faktörler DATABASE sahibinin sorunlarını şiddetlendirir:

• diğer sunucu seviyesindeki güvenlik sertifikaları (uç nokta, sunucu rolü, giriş) nadiren kullanılır, taşınır vb.
• veritabanı düzeyinde güvenlik altına alınabilirler genellikle dbo(veritabanı sorumlusu) veya başka bir veritabanı sorumlusu tarafından sahip olunması ile sona erer ve bu nedenle sahibi veritabanında bulunur
• Veri tabanı sahipliği varsayılan NT birincil sorumlusuna sahipse, bir sınırlama sorunu yaratır (sahibi AD tarafından yönetilen bir NT SID'sidir ve veritabanı dosyalarıyla birlikte gitmez, NT hesabı vb.
• En önemli şey: veritabanı sahibinin, özellikle de önemli yan etkileri vardır EXECUTE AS context. Bu sonraki sorun çoğu kullanıcıyı yakan şeydir. Service Broker, EXECUTE AS'yi (ileti tesliminde açık bir EXECUTE AS içeriğinin yanı sıra açık bir etkinliğe sahip olan sıra etkinleştirme özelliğine sahiptir) kapsamlı bir şekilde kullandığından, genellikle bu sorunu ilk keşfeden Servis Aracısı kullanıcılarıdır.

BTW, orijinal probleminizi araştırıp çözdüğünüz için Kudos :)

Veri tabanı owner, SQL Sever 2005'te (uygun) şemaların tanıtılmasından önceki bir döneme ait.

Temel olarak bir veritabanı sahibi , veritabanının varsayılanıdır dbo(veritabanı sahibi) ve veritabanının kendisi bir veritabanı nesnesidir .

Gönderen SQL Server 2000 docs ...

dboVeritabanındaki tüm faaliyetleri gerçekleştirmek için izinleri ima olan bir kullanıcıdır.

SQL Server'ın önceki sürümlerinde, bir şema bir nesneye "sahip olamadığında" ( veya tüm nesnelerin, tabloların, görünümlerin vb. Ait olduğu dbove başka şemalar olmadığı belirtilmelidir ) bir "user" sahibi olmak ... bir şeyin neden veritabanına sahip olması gerektiğini söylemeden devam etmelidir (veya genel olarak izinler oldukça zor olabilir).

Yani, teknik SQL Server eski sürümleri (veya yükseltilmiş veritabanları) 'de bunun ile ... "dbo.Foo" tablosu oldu "Foo" tablosu değildi dbosahibi olmak.

SQL Server 2005'in gelişmesiyle, şemaya sahip olduğunuz "bar" adlı bir şemaya ve "Foo" adlı bir şemaya sahip olduğunuzu söyleyen veritabanı nesnelerine sahip olabilirsiniz bar.Foo...

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

İşin zor yanı , veritabanını yaratan kullanıcının otomatik olarak çalışanın iadesi ile ilgili sorunlara yol açan sahibi olarak ayarlanmasıdır .

Bu nedenle, bunu sahesaba değiştirmek veya belki de (benim deneyimime göre) bir kuruluşun ops / IT ekibi tarafından yönetilebilecek bir etki alanı hesabına değiştirmek en iyi yöntemdir .

Bu makale , eski "mal sahibi" ile iş yapma şekli ile yeni "şema" tabanlı mülkiyet sistemi arasındaki farkı ortaya koymaktadır.

Sahipler ve şema arasındaki farkı anlamak için, biraz zamana, nesne sahipliğini gözden geçirelim. Bir nesne SQL Server 2000'de veya daha önce oluşturulduğunda, nesnenin bir sahibi olması gerekir. Çoğu zaman, sahibi "dbo", veritabanı sahibi olarak da bilinir.