SSIS’ de Protection Level Nedir?

Integration Services kullanarak proje geliştirirken hepimizin başına zaman zaman sorun olmuştur Protection Level. Proje geliştirirken bir başka developer’ a projeyi gönderirsiniz kendi ortamında açamayabilir ya da açar fakat connection string’ lerde şifreleri yoktur! Geliştirme ortamından taşır production sisteme koymak istersiniz farklı bir user açar yine bu tip bir başka sorunla karşılaşırsınız.

SSIS içerisindeki Protection Level property’ si kullanılarak paketler/proje içerisindeki sensitive olarak nitelendirilen bilgiler korunmuş olur. Ne tür bilgiler sensitive olarak değerlendirilir?

Connection string’ lerdeki şifreler yada seçiminize göre connection string‘ lerin tamamı sensitive bilgilerdir.
Sensitive olarak belirtilmiş herhangi bir variable sensitive bilgidir.
Kullandığımız her hangi bir task’ in çıktısı olan XML dosyaları yine sensitive bilgilerdir.

SSIS’ de bir proje oluşturduğumuzda default olarak Protection Level EncryptSensitiveWithUserKey olarak gelir. İsterseniz proje property’ lerinden bunu değiştirebilirsiniz.

Default

Bunun dışında proje geliştirirken herhangi bir zaman control flow içerisinden paket property’ lerine giderek aşağıdaki seçeneklerden birini seçebilirsiniz.

DontSaveSensitive: Her hangi bir şekilde encryption yapmaz. Sensitive olarak nitelendirilen bilgiyi kaydetmeyerek bilgiye ulaşımı engeller. Connection string’ lerinizdeki şifre alanının boş geldiğini göreceksiniz. Save my password seçeneğini seçmiş bile olsanız bunu yapar. Connection’ larda kullandığınız şifreleri tekrar girmek çözümlerden birisidir. Fakat paketi kapatıp tekrar açtığınızda yine boş gelecektir. Bir diğer çözüm bunları configuration’ lara kaydetmek olabilir. Eğer Package Deployment Model kullanıyorsanız ikinci çözümü uygulamak, defalarca elinizle girmemeniz için bir yöntem olabilir. Son çözüm olarak environment variable’ lar içerisinde tutmak olabilir. Bunun için Project Deployment Model kullanıyor olmanız gerekli. Bunun dışında Windows Authentication yapmak gibi çözümlerde olabilir ama ileride başınızı ağrıtmaması istiyorsanız best practice’ lere yakın durun derim.

EncryptSensitiveWithUserKey: Paketler Default olarak bu seçenek ile oluşturulur. Paketteki sensitive bilgiyi oluşturduğunuz user account bilgilerini kullanarak bunları encrypt  eder. Projeyi bir başkasına gönderdiğinizde aynı account ile açmıyorsa yaşadığınız problemin kaynağı burası olabilir. Active Directory’ de SSISDev kullanıcı ile development yaptınız diyelim. SSISProd kullanıcısı ile paketleri çalıştırırken sorun yaşayacaksınız demektir. Sensitive bilgiler yine boş gelecektir.

EncryptSensitiveWithPassword: Paket içerisindeki sensitive bilgileri sizin belirlediğiniz bir şifre kombinasyonu ile encrypt eder. Birden fazla kullanıcı paketler üzerinde geliştirme yapıyorsa bu seçenek diğerlerine göre daha uygun olacaktır. SSIS, paketi her açmanızda size bu şifreyi soracaktır. Eğer şifreyi yanlış girerseniz sensitive bilgiler boş gelecektir. Onun dışında geliştirme ortamına ulaşımınız halen var olacaktır.

EncryptAllWithPassword: Yine sizin belirlediğiniz bir şifre ile paketin tamamını şifreleyerek sensitive ya da değil her hangi bir bilgiye ulaşmayı engeller. Paketi açarken şifreyi girmezseniz paketi açamazsınız. Eğer şifreyi unutursanız paketi yeniden dizayn etmek zorunda kalabilirsiniz!

 EncryptAllWithUserKey: Paketin tamamını onu oluşturan user account ile şifreler. Yukarıdaki ile aynı şekilde eğer account giderse paketi açmak için yapabileceğiniz bir şey yok demektir.

ServerStorage: Paketin tamamını SQL Server role’ leri kullanarak korunur. msdb‘ ye ya da SSISDB Catalog‘ a deployment yaptıysanız SQL Server bunu destekler. Fakat file sisteme deployment yaptıysanız bunu desteklemez. Sensitive bilgileri tutarken server’ a güvenmiş oluyorsunuz. O rollere yetkisi olan account’ lar sensitive veriyi görebilir. Bu yukarıdaki seçeneklerden olan şifreyi bilenin paketi açmasından farklı değildir. Bu aynı zamanda rolleri daha dikkatli yönetmemiz gerektiği anlamına geliyor.

Development safhasında duruma göre EncryptSensitiveWithUserKey, DontSaveSensitive yada EncryptAllWithUserKey seçilebilir. Production için deployment yapacağınızda artık developer’ ların account’ ları yerine EncryptSensitiveWithPassword yada EncryptAllWithPassword seçeneği daha makul olacaktır.

Reklamlar
Bu yazı SSIS içinde yayınlandı ve , olarak etiketlendi. Kalıcı bağlantıyı yer imlerinize ekleyin.

2 Responses to SSIS’ de Protection Level Nedir?

  1. Geri bildirim: SSIS’te hassas veri ya da tüm paket güvenliği | Veri Yönetimi Departmanından Haberler

  2. Geri bildirim: Integration Services 2012′ ye Güncelleme | Business Intelligence Tips

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Google+ fotoğrafı

Google+ hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Connecting to %s