Integration Services (IS) kullanarak proje geliştirirken Protection Level birçoğumuzun başına ara ara sorun olmuştur. Proje esnasında bir başka developer’ a projeyi gönderirseniz kendi ortamında açamayabilir ya da açar fakat Connection String’ lerde şifre yoktur. Development ortamından production sisteme koymak isterseniz farklı bir user açar yine bu tip bir başka sorunla karşılaşabilirsiniz.
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.
Resim-1
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.
Referanslar
Bu konuyla ilgili sorularınızı alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.
