SSAS Tabular Mode Üzerinde Customdata() Ve Username() Fonksiyonlarının Güvenliğe Etkisi

10/04/2014 Okuma süresi: 10dk, 12sn

Bilindiği üzere SQL Server ailesinin analitik çözümü olan SSAS (SQL Server Analysis Services) üzerinde BigData çözümü olarak in-memory çalışan tabular mod özelliği SQL Server 2012 ile getirilmişti.

Tabular mode yapısı itibarıyla in-memory çalışmakta ve multidimensional mod’dan farklı olarak hücresel değil satır bazında yetkilendirmesi bulunmaktadır. Bunun anlamı multidimensional mod’da oluşturacağınız güvenlik altyapısında kullanıcılar şu satırları ve/veya şu kolonları göremesin diyebilirken, tablar mod üzerinde sadece şu kurallara uyan satırları göremesin diyebilirsiniz. Tabular modu kullanırken gözönünde bulundurulması gereken önemli konulardan bir tanesi de budur.

Tabular mod üzerinde oluşturduğunuz yetkilendirme rollerinin davranışlarını belirlerken CustomData() veya UserName() fonksiyonlarının kullanılması gerekmektedir.

CustomData() fonksiyonu Tabular Moda kurulan bağlantıda bir özellik olarak gönderildiğinde Tabular Mode üzerindeki CustomData() fonksiyonu bu değeri döndürmektedir. Örneğin aşağıdaki bağlantı cümlesinde CustomData değeri mydomain\ahmetoz olarak belirtilmiş ve bunun sonucu olarak da Tabular Mod üzerinde CustomData() fonksiyonu “mydomain\ahmetoz” değerini döndürecektir.

Provider=MSOLAP.5;Integrated Security=SSPI;Persist Security Info=True;Initial Catalog=<SSAS Database Adı>;Data Source=<Sunucu Adı veya IP>;MDX Compatibility=1;Safety Options=2;MDX Missing Member Mode=Error;CustomData=mydomain\ahmetoz

CustomData() Fonksiyonu ve CustomData Özelliği ile Güvenlik Modelinin Kurgulanması

CustomData() fonksiyonuna bağımlı olarak kurgulanacak yetkilendirme altyapısında biraz daha dikkatli olmak gereklidir. Bağlantı cümlesinin içerisine kolaylıkla eklenebilen bir özellik olduğundan dolayı kurgulamış olduğunuz güvenlik altyapınız rahatlıkla aşılabilecektir.

CustomData() fonksiyonu kullanılırken şöyle bir model izlenebilir;

Resim-1

Bu modelin uygulanabilmesi için şu şartların sağlanması tavsiye edilir;

İstemci uygulamayı kullanan kullanıcının Tabular Mod Veritabanına doğrudan erişim yetkisi olmamalıdır.
İstemci uygulama arka planda Windows domain’inde kayıtlı bir servis kullanıcısının yetkisiyle çalışır yani veritabanı bağlantısı istemci uygulamayı kullanan kullanıcının güvenlik bilgileriyle değil, bir servis kullanıcısının güvenlik bilgileriyle bağlantı kurulur.
Söz konusu servis kullanıcısının Tabular Mod Veritabanına tam yetkiyle erişim hakkı bulunmaktadır. Burada dikkat edilmesi gereken konu sadece veritabanına tam yetkili olmalıdır.
İstemci uygulama kendisini çağıran kullanıcının kullanıcı adını tanıyıp bağlantı cümlesinin içerisine CustomData özelliğini otomatik ekleyebilmelidir. Örn: Sharpoint Performance Point veya kendi yazdığınız bir ASP.NET uygulaması v.s.

CustomData ile kullanılan güvenlik modelinin aşağıdaki koşulları sağlamaması durumunda sisteminizde muhtemel güvenlik açıkları oluşacaktır;

İstemci uygulamayı çağıran kullanıcının aslında Tabular mod’a erişim yetkisi bulunmamalıdır. Yani Tabular mod modelinizdeki güvenlik rollerinde istemci uygulamayı kullanan kullanıcıya doğrudan yetki vermemelisiniz.
İstemci uygulama bir servis kullanıcısı hesabının yetkileriyle çalışır ve bu servis kullanıcısı Tabular Mod veritabanında bir role üye olmalıdır. Tabular mod yetkilendirme yapısı gereği kullanıcının üst seviyedeki yetkisi geçerli olduğu için servis kullanıcısı daha geniş yetkilere sahip olan farklı bir role üye olmamalı veya tüm Tabular Mod veritabanlarına admin seviyesinde erişim yetkisinin tanımlandığı Security listesine üye olmamalıdır.
İstemci uygulama bağlantı cümlesine CustomData özelliğini ekleyebilir ve istemci uygulamayı çalıştıran kullanıcının adını CustomData özelliğine atayabilme yeteneğine sahip olmalıdır
İstemci uygulamayı çağıran kullanıcı uygulamanın bağlantı katmanına müdahale edememelidir. Örneğin bağlantı cümlesini elle kendisi düzenleyememelidir.

UserName() Fonksiyonu ve EffectiveUserName Özelliği ile Güvenlik Modelinin Kurgulanması

Yetkilendirme modelinde UserName() fonksiyonu Tabular Mod’a bağlanan kullanıcının doğrudan kullanıcı adını belirtir. Dolayısıyla uygulamanızın bir şekilde kendisini çağıran kullanıcıyı Tabular Mod’a tanıtabilmesi gerekmektedir.

Bu iki şekilde olur;

Bağlantı cümlesindeki EffectiveUserName özelliği ve
Kerberos bileti ile güvenlik

EffectiveUserName Özelliği

EffectiveUserName özelliği CustomData() fonksiyonunu anlatırken belirttiğimiz bağlantı cümlesinin bir benzeri olarak aşağıdaki gibi oluşturulduğunda Tabular Mod üzerindeki UserName() fonksiyonu belirtilen kullanıcının bilgilerini dönmeye başlar

Resim-2

Bu güvenlik modelinin daha çok geliştirmeler sırasında kullanılması tavsiye edilir. Bir bağlantı cümlesinde EffectiveUserName özelliğinin kullanılabilmesi için bağlantıyı kuran kullanıcının SSAS üzerinde Security listesine üye olması gerekir. Bu da demektir ki bağlantıyı kuran kullanıcı tüm Tabular Mod veritabanlarının yöneticisi olmalıdır.

Zaman zaman geçici durumlarda bu yöntemin kullanılması gerekse bile bu yöntem üzerinde bir güvenlik katmanı oluşturulmamalıdır.

Bu güvenlik modelinin uygulanabilmesi için şu şartların sağlanması gereklidir;

İstemci uygulamayı çağıran kullanıcının aslında Tabular mod’a erişim yetkisi bulunmamaktadır
İstemci uygulama bir servis kullanıcısı hesabının yetkileriyle çalışır
İstemci uygulama bağlantı cümlesinde EffectiveUserName özelliğini çağıran kullanıcının domain adını ayarlama yeteneğine sahiptir
İstemci uygulamayı çağıran kullanıcı uygulamanın bağlantı katmanına müdahale edememelidir. Örneğin bağlantı cümlesini elle kendisi düzenleyememelidir.
İstemci uygulamanın çalıştığı servis kullanıcısının SSAS Servisinde Admin seviyesinde yetkisi bulunmaktadır

Kerberos Bileti ile Güvenlik

Kerberos Active Directory üzerine kurgulanmış bir güvenlik protokolüdür. Kullanıcının güvenlik haklarının Windows domainindeki sunucular arasında tanıtılmasını sağlayan bir güvenlik protokolüdür.

Kerberos protokolü ile güvenlik modelinden bahsedebilmek için bir Active Directory üzerinde bulunan en az iki sunucudan bahsetmemiz gerekir.

Buna güncel hayattan örnek vermek gerekirse;

Örneğin Sharepoint üzerinde yayınladığınız bir PowerPivot belgesi kullanıcılar tarafından Refresh edilmek istendiğinde PowerPivot dokümanındaki veri kaynaklarına gerekli güvenlik haklarının atlatılması (hop) ve gerekli verilerin çekilebilmesi için kerberos bileti ile yapılandırmasının yapılması gerekmektedir.

Resim-3

Yukarıdaki resimde belirtilen senaryoda adım adım gerçekleşenleri anlatmak gerekirse;

Domain Kullanıcısı uygulama sunucusuna uygulamayı kullanmak üzere talepte (request) bulunur
Uygulama sunucusu kullanıcının güvenlik haklarını tanıyarak üzerinde barındırdığı Uygulama’ya transfer eder
Uygulama’da yapılan konfigürasyon gereği başka bir sunucuda bulunan veritabanına kullanıcının yetkileriyle bağlanır ve kullanıcının yetkilerini doğrular

Bu şekilde bir senaryodaki iş ihtiyacının teknik olarak domain üzerindeki adımları sırasıyla şu şekildedir

Resim-4

Kerberos konfigürasyonunda yetki doğrulamaları Domain’i yöneten sunucu tarafından yapılmaktadır. Dolayısıyla bir sunucudan başka bir sunucuya yapılan yetki transferlerini yöneten de Domain Controller sunucusudur. Bu işlemi gerçekleştirebilmesi için domain Controller sunucusuna bazı bilgilerin tanıtılması gerekmektedir.

Bu tanımlamalardan önce şu kavramlara açıklık getirilmelidir;

İstemci sunucu (Client) : başka bir kullanıcı adına davranan ve yanıt veren sunucudan bilgi talep edecek olan sunucudur. Yukarıdaki örnekte Uygulama Sunucusu istemci sunucudur.
Yanıt Veren Sunucu (Server): Bilgi talep edilen ve yanıt dönecek olan sunucudur

Yetkilerin bir sunucudan diğerine atlatılması( hop) işlemini doğrulayacak olan Domain Controller sunucusunda her bir hop işlemi için gerekli tanımlamalar yapılması gerekmektedir.

Bu tanımlamayı yaparken Domain Controller sunucusunun şu bilgilere ihtiyacı olacaktır;

Servis Asıl Adı (Service Principal Name – SPN): Bir Domain Controller sunucusunun kerberos protokolünü uygulayabilmesi için domain üzerinde hop yapmaya izin vereceği uygulama servisini tanıması gerekir. Bizim Örneğimizde Veritabanı sunucusu üzerindeki bir servis için SPN tanımı yapılması gerekmektedir. Bu Servisin SSAS Tabular Mod olduğunu varsayalım. SPN tanımının yapılabilmesi Domain Controller sunucusuna;
- Yanıt Veren sunucu kim olduğu
- Yanıt Veren sunucu üzerindeki uygulama/servis ne olduğu
- Yanıt Veren sunucu üzerinde çalışan uygulama/servis hangi servis kullanıcısıyla çalıştığı bilgilerinin tanıtılması gerekmektedir. Bunu komut örnekleriyle aşağıda daha detaylı olarak tanıtacağız.

SPN tanımlamalarında dikkat edilmesi gereken birçok nokta bulunmakla beraber burada sadece ihtiyacımız olanlardan bahsedeceğiz. SPN tanımlaması Windows Domain’i üzerinde gerekli yetkilere sahip sistem yöneticileri tarafından yapılabilir.

ÖNEMLİ

Buradaki tanımlamalar çok özel tanımlamalar olup sadece kavramı açıklamak adına yapılmaktadır. Sistem ihtiyaçlarınız ve uygulama mimariniz bu tanımlamaların farklı şekilde yapılmasını gerekli kılabilir. Kerberos ile ilgili daha detaylı bilgiye http://msdn.microsoft.com/tr-TR/library/Aa378747.aspx linkinden, SPN ile ilgili http://msdn.microsoft.com/en-us/library/cc280459.aspx linkinden ulaşabilirsiniz.

SPN Tanımlama adımları

Öncelikle SPN’i tanımlayacağınız domain kullanıcısı üzerinde herhangi bir SPN tanımı olup olmadığını kontrol ediniz

C:\Windows\system32>setspn -l sp-excpo <Enter Tuşuna Basın>

Registered ServicePrincipalNames for CN=Excel Service Application,OU=SPApplicationPools,DC=kscustomer,DC=local:

Yukarıdaki gibi bir yanıt olıyorsanız servis kullanıcısı üzerinde herhangi bir SPN tanımı yapılmamış demektir. Önemle belirtmek gerekir ki bir kullanıcı üzerine yapılmış bir SPN tanımı başka bir kullanıcı için yapılamaz. Domain Controller bu işleme izin vermeyecektir.

Yanıt Veren Sunucu (Server) üzerindeki SSAS servisine SPN tanımı yapmak için;

C:\Windows\system32>setspn -s MSOLAPSvc.3/KSPORTALMPDB01 sp-excpo <Enter Tuşuna Basın>

Checking domain DC=kscustomer,DC=local

Registering ServicePrincipalNames for CN=Excel Service Application,OU=SPApplicat

ionPools,DC=kscustomer,DC=local

MSOLAPSvc.3/KSPORTALMPDB01

Updated object

Yukarıdaki komutu çalıştırdığınızda yine yukarıda dönen yanıtı almış olacaksınız.

Bir SPN tanımının yapısı şu şekildedir;

SPN tanımı bir domain kullanıcısı üzerine yapılmalıdır. Bunun anlamı hangi servis tipinin hangi sunucuda hangi servis kullanıcısıyla çalıştığını Domain Controller sunucusuna tanımlamaktır. Eğer SPN tanımı doğru bir şekilde yapılmazsa (örneğin mükerrer SPN tanımları olmamalıdır) kerberos doğrulama protokolü sizleri doğrulamayacaktır.

Bu tanım doğru yapıldığında Yanıt Veren Sunucu’daki SSAS servisini Domain Controller sunucuna tanıtmış oluyoruz.

Şimdi ise İstemci Sunucu (Client) üzerindeki uygulama/servis ‘i çalıştıran servis kullanıcısına sözkonusu SPN’e Delegation yetkisi vermek gerekmektedir. Domain Controller makinesi üzerinde Domain Users and Computers konsolundan ilgili kullanıcıyı seçerek yapmalısınız.

Resim-5

Eğer kullanıcı ekranı üzerinde Delegation tabını görmüyorsanız, delegation vereceğiniz servis kullanıcısı için dummy bir SPN tanımı yapmanız gerekmektedir.

Örnek;

C:\Windows\system32>setspn -s DUMMY/SPN1 sp-Supusr

Checking domain DC=kscustomer,DC=local

Registering ServicePrincipalNames for CN=Super User Account,OU=SPApplicationPool

s,DC=kscustomer,DC=local

DUMMY/SPN1

Updated object

Yukarıdaki işlemden sonra söz konusu kullanıcı ekranında Delegation tabının açılması gerekmektedir.

Resim-6

Daha önceki senaryomuzu tazelemek gerekirse, kullanıcı uygulama sunucusundan talepte bulunuyor, uygulama sunucusu da kullanıcının yetkileriyle veritabanı sunucusuna bağlantı kuruyor, bu esnada kerberos bileti kullanıyor. Bu yukarıda yaptığımız SPN ve Delegation tanımları sayesinde senaryomuz geçerli olacaktır.

Bu konuyla ilgili sorularınızı alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.

Referanslar

www.mshowto.org

Bu İçeriğe Tepkin Ne Oldu?