Bu tür düzenlemeler ve kanunlar vatandaşlar olarak hepimizin yararına olmakla birlikte gerek bilinçlendirme, gerekse varolan güvenlik düzeneklerimizi tekrar gözden geçirip daha da sağlamlaştırma fırsatı sunma açısından bir bakıma iyi de oluyor bence.
Malum güvenlik ciddi bir konu, fakat çok da maliyetli olabiliyor. Elbette her şirketin şartları, imkanları ve bütçesi farklı. Bazı çözümler çok güzel de olsa, gerek lisanslama gerekse yetkin personel maliyetleri açısından "güzelden soğutuyor". Bu nedenle çözümler zaman zaman şartları zorlayarak, ama genelde de eldeki imkanları kullanarak oluşturuluyor. Şahsen ben eldeki imkanları kullanarak bir şeyler üretmekten çok keyif alırım, bu yazımda özetle bahsedeceğim çözümler de bu bakış açısıyla üretilmiş çözümler. Ayrıca vurgulamakta fayda var, güvenlik sadece teknik önlemlerden ibaret değildir, buna da değineceğim.
Bu konularda hala hiçbir adım atmayan birçok şirket var, ne yazık ki bunlar çoğunlukta. Bazılarının kısmen de olsa bir şeyler yaptığını, azınlık bir kesimin ise iyi hazırlandığını görüyorum.
Bu yazımda başlık başlık ve kısa özetlerle benim yönettiğim Microsoft SQL Server ortamlarında ne gibi önlemler aldığıma, ilgili yöneticilere neler önerdiğime değineceğim.
1- Ortamlarınızı ayırın:
Canlı (live/prod), test (pre-prod/QA/UAT), geliştirme (dev) ortamlarınızı mümkünse ayırın. Geliştirme ortamlarınızdaki verileri tazelerken muhakkak kritik verileri karartın/maskeleyin. Yazılımcılar geliştirme ortamlarında istedikleri testleri yapabilsinler, ki azami oranda canlı ortamda yetkiye ihtiyaçları olmasın.
2- Kod yaygınlaştırma:
Veritabanına kod taşıma işini uygulamalar aracılığıyla gerçekleştirin, eğer bütçeniz yoksa da birinci öncelikli ve ikinci öncelikli kişiler belirleyin, test ve canlı ortamlara kod taşımalarını sadece bu arkadaşlar gerçekleştirsin.
3- Tüm uygulama/vekil kullanıcı bilgilerini kasaya koyun:
Uygulama/vekil kullanıcı bilgileri sağda, solda gezmemeli; Excel dokümanlarında veya postit'lerde veya metin dosyalarında saklanmamalı. Hem güvenlik açısından, hem de operasyonel açıdan kullanıcı adı, şifre ve diğer ayrıntılarının çok güvenlikli bir uygulama ile saklanması gerekiyor. Bu uygulamaya erişim yetkisinin çok sınırlı, ama yeterli sayıda kişide bulunması gerekiyor. Bu kişilerin kimler olduğu da ilgili yöneticiler tarafından bilinmeli, ki gerektiğinde kime ulaşılacağı net olsun.
4- Görevler ayrılığı ilkesi:
Sistem Yöneticisi veya Ağ Yöneticisi bir arkadaşın veritabanında ne işi var? Nasıl ki evimizin anahtarının sadece ilgili kişilerde olmasını istiyorsak, veritabanımıza giriş hakkının da sadece ilgili kişilerde olmasını isteriz.5- Uygulama/vekil kullanıcılara sınırlama:
Uygulamalarımız için oluşturduğumuz ve adına uygulama/vekil kullanıcı diyebileceğimiz kullanıcıları gerçek kullanıcılar kullanamamalı. Örneğin cep telefonu uygulamaları için oluşturup kullandığımız "mobile_user" kullanıcısını yazılımcı bir arkadaş SQL Server Management Studio uygulamasını kullanarak veritabanına bağlanamamalı. Uygulama/vekil kullanıcıları veritabanına sadece belirli uygulama sunucularından bağlanabilmeli.
6- Anonim kullanıcıya hayır:
Birçok ortamda şirketteki tüm çalışanların "sa", "master", "admin" gibi anonim kullanıcıları kullandıkları kimse için bir sır olmasa gerek? Eğer bilgisayar isimleri de tanımlanabilir bir kodlama ile oluşturulmamışsa, ortamda bir Domain yoksa hangi işlemi hangi kullanıcı gerçekleştirmiş bulmak neredeyse imkansız oluyor. Özellikle kritik işlemlerin kimler tarafından, nasıl gerçekleştirildiğinin izini bulabilmek için tüm işlemleri birbirinden ayırt edebilmeniz gerekiyor. Bunun için de her gerçek kullanıcının hesap bilgilerini sadece kendisinin bildiği eşsiz kullanıcıları olması gerekiyor. Veritabanına erişimi olacak tüm şirket çalışanlarına kendi kullanıcısının mesuliyetinin kendisine ait olduğu net olarak anlatılmalı ve bu madde ilgili yaptırım ifadeleriyle işe giriş sözleşmesine de eklenmeli.
7- Sadece gerektiği kadar yetki:
Ne denirse densin, bazı ortamlarda çeşitli sebeplerle 1. maddede bahsini ettiğim ortamlar ayrılığı gerçekleştirilmiyor. Durum her ne olursa olsun örneğin bir yazılımcının yeni veritabanı oluşturmaya, varolan veritabanını veya tabloları silmeye ne sıklıkta ihtiyacı olur? Neredeyse senede 1-2 kere. Bir yazılımcının temel ihtiyaçları SP/Function/Trigger/Table gibi nesneleri oluşturmak ve değiştirmektir, ayrıca Select ve DML yetkisine ihtiyaç duyar; yani temel olarak ihtiyaçları aslında veritabanı seviyesindedir, sunucu seviyesinde değil. Gereğinden fazla gücünüz olması durumunda, hata yapma şansınız da artmış olur. Misal son model bir Ferrari ile mi hız kazası yapmanız daha olasıdır, yoksa 1.0 motorlu bir Kia Picanto ile mi? Eğer çalışanın ihtiyacı Kia Picanto ise, ona Ferrari vermeyin, ki kaza yapabilemesin.Özellikle yeni çalışmaya başladığımız şirketlerde yetki kısıtlaması çalışması yaparken bazı arkadaşlar tarafından ilk önce ciddi tepkilerle karşılaşabiliyoruz, fakat daha sonra gerçekten ne yapmaya çalıştığımızı fark ettiklerinde onlar da çok memnun oluyorlar. Araç sürerken emniyet kemerinin takılması gerektiği gibi, maksat hem veriyi korumak, hem de çalışanı.
8-Hassas verilerinizi maskeleyin:
Gerek gerçek kişilerin kimliklerini ifşa edebilecek, gerekse şirket için hassas olan verileri doğrudan veritabanı seviyesinde maskeleyin. Bunu SQL Server 2016 ile birlikte gelen Dynamic Data Masking özelliği ile gerçekleştirebilirsiniz. SQL Server'ın Standard Edition'ında bile var bu özellik. Hiç bir kesinti veya uygulama tarafında kod değişikliği gerektirmeyen bir işlem bu. Sadece öncesinde ilgili yöneticiler ve çalışanlarla birkaç toplantı düzenleyip, hassas verileri tanımlayıp, belirleyip, tüm çalışanları bilgilendirip, öyle aksiyon almak gerekiyor.
9-Verilerinizi yedekleyin, fakat yedeklerken güvenliği ihmal etmeyin:
Mümkünse veritabanlarınızı şifreleyerek yedekleyin. Örneğin bunun için Transparent Data Encryption da kullanabilirsiniz. Böylece kötü niyetli kişiler bir şekilde yedek dosyalarınıza erişse bile, elde ettikleri veritabanlarını açamazlar.
Ayrıca Disaster Recovery (DR) Site'ınızda da benzer güvenlik önlemlerini aldığınızdan emin olun. Örneğin bir keresinde bir müşterimin canlı ortamına erişemeyen saldırganların DR ortamına saldırdıklarını fark etmiş ve ilgili kişilere bilgi verip açıkları kapattırmıştım.
10-Veritabanı sunucunuza art arda yapılan hatalı giriş denemelerini denetleyin ve bu denemelerden haberdar olun:
Eğer veritabanı sunucunuza art arda erişilmeye çalışılıyorsa ve bol bol hata alınıyorsa ya bir veritabanınız herhangi bir sebeple erişilemez duruma gelmiştir, ya bir kullanıcınızın hesabı bloke olmuştur ya da sunucunuza içeriden veya dışarıdan "brute force" yöntemiyle erişilmeye çalışılıyordur.
Ben bu kontrolü yaparak son 2 sene içerisinde en az 3-4 kere kötü niyetli saldırı girişimini fark ettim ve bu sayede gerekli önlemleri alarak ilgili sunucuların açıklarını kapatabildik.
 |
| Kangal: Çoklu hatalı giriş denetimi |
11- Veritabanı sunucunuza yapılan başarılı girişleri denetleyin:
Sadece başarısız giriş denemelerini değil, başarılı girişleri de kontrol etmemiz gerekiyor, ki eğer bir çalışanın veya uygulama/vekil kullanıcının bilgileri kötü niyetli birisinin eline geçerse ve veritabanına bağlanırsa haberimiz olsun. Aksi durumda bağlantı kurulan veritabanı sunucusundaki erişim sağlanan tüm veriler peyderpey çalınır ve ruhunuz duymaz.
Bu kontrol için örneğin Microsoft Azure'da Advanced Threat Detection diye bir yöntem var, fakat on-prem sunucular için henüz benzer bir teknik sunmuyor bize Microsoft. Microsoft'un Güvenlik Zirvesi'nde Advanced Threat Detection ile ilk karşılaştığımda on-prem'e bunu nasıl uyarlarım diye düşündüm. İlk aklıma gelen prototip verimli çalışmıyordu, fakat o prototipin son versiyonu şu anda tüm müşterilerimin ortamlarında çok verimli bir şekilde çalışıyor. Aşağıda bir örnek paylaşıyorum:
 |
| Kangal: Anormal bağlantı denetimi |
12-Özellikle hassas verilerinizdeki değişiklikleri kayıt altına alın:
Eğer bu işe ayırabilecek ciddi bir bütçeniz varsa zaten bir güvenlik ekibiniz de vardır ve IBM Guardium veya Imperva gibi milyon dolarlık seçeneklere bakıyorsunuzdur. Fakat bütçeniz nispeten dar ise SQL Server 2016 Service Pack 1 ile artık Standard Edition'da bile kullanılabilen SQL Server Database Auditing özelliğinden faydalanabilirsiniz. Database Auditing'i tek başına kullandığınızda raporlama açısından ciddi zorluklar yaşarsınız, hiç pratik değildir ve log yönetimi çok çok sıkıntılıdır; fakat Database Auditing'i oldukça uygun bir lisans maliyeti olan CryptoLog gibi bir uygulama ile birleştirdiğinizde çok daha verimli bir sonuç elde edersiniz.
13- Toplu veri sorgulamalarından ve değişikliklerinden haberdar olun:
Kullanıcılarınız veritabanı sunucunuzdaki verileri toplu bir şekilde sorguladığında veya toplu bir değişiklik (Update/Delete gibi) yaptığında bundan haberdar olmak istemek için birden fazla nedeniniz var. Tabii ki öncelikli nedenini güvenlik. Özellikle finansal verilerde yapılacak toplu bir değişiklik çok can yakabilir veya kötü niyetli biri verilerinizi şifreleyip fidye isteyebilir*.
* Bu gibi senaryoların geri dönüş seçenekleri mevcut, fakat uzun bir konu.
 |
| Kangal: Toplu sorgulama denetimi |
14- Eğer zorunda değilseniz SQL Authentication değil, Windows Authentication kullanın:
Microsoft'a göre SQL Authentication uzun süredir "Deprecated" bir özellik, yani bir süre sonra kaldırılacak; fakat bu durum uzun yıllardır böyle ve ben yakın zamanda da kaldırılacağını düşünmüyorum. Microsoft'un bu özelliği kaldırmak istemesinin nedeni de güvenlik. Fikir de şu, zaten bir Domain/Local hesabımız var, veritabanına bağlanırken de bunu kullanalım. Ayrı ayrı kullanıcıların ve şifrelerin olması, insanların kullanıcı hesaplarının ayrıntılarını kolay ulaşılabilecek şekilde sağa sola not etmesine neden oluyor. Haliyle bu da ciddi bir güvenlik açığına neden oluyor.
Tabii SQL Authentication ihtiyacı birçok senaryo için hala bir gerçek, fakat olabildiğince bilinçli olmakta ve Windows Authentication kullanmakta fayda var.
15-Yerel Güvenlik Politikası'nı kullanın:
Hem yeni Login'ler oluştururken, hem de varolan Login'leriniz için Windows işletim seviyesindeki Yerel Güvenlik Politikalarından faydalanın. Bu sayede kullanıcılarınızın Login şifrelerinin belli bir uzunlukta ve zorlukta belirlenmesini sağlayabilir, kullanıcılarınıza belli süreler içerisinde şifrelerini değiştirmesini zorlayabilirsiniz.
Not: Şifrelerin sıklıkla değiştirilmesinin de kendi başına bir güvenlik açığına neden olduğuna dair bazı görüşler var, şahsen ben de bu görüşlerin kısmen de olsa doğruluk payı olduğunu düşünüyorum. Örneğin 30 günde bir şifre değiştirmek zorunda kalan sıradan bir kullanıcının her 30 günde bir değişen bu karışık şifreyi nerede tutması bekleniyor? Aklında tutamayacağı aşikar. Ya telefonuna not ediyor, ya da bilgisayarının masaüstünde duran bir metin dosyasına. Yani güvenlikte aşırıya kaçıp, güvenlik önleminin bir başka güvenlik açığına dönüşmemesini sağlamak gerekiyor.
16-Rutin Login şifre testleri uygulayın:
Özellikle herhangi bir nedenle Windows Yerel Güvenlik Politikasının uygulanmadığı kullanıcılar için bu denetimin yapılmasında fayda var. Bu denetim sayesinde birçok ortamda örneğin şifresi 111111 olan kullanıcı tespit ettim.
 |
| Kangal: Güçsüz şifre denetimi |
17-Veritabanı ve uygulama sunucularına RDP yetkisi:
Sadece sistem yöneticilerinin ve veritabanı yöneticilerinin veritabanı sunucusuna RDP yetkisi olabilir, o kadar. Bu yetki de rutin olarak değil, sadece gerektiğinde kullanılmalıdır. Veritabanı yönetiminin rutin olarak veritabanı sunucusuna RDP yaparak uygulanması iyi bir pratik değildir, çünkü çalıştırdığımız uygulamalar çeşitli nedenlerle "crash" olabilir, hiç beklemediğimiz şekilde yüksek CPU ve RAM tüketebilir, bunlar da işletim sisteminin kararsız çalışmasına neden olabilir ve böyle bir şeyin olmasını istemeyiz.
RDP yetkisinin sınırlandırılmasının bir başka amacı ise veritabanı dosyalarının kopyalama yöntemiyle şirket dışına çıkarılamaması ve kopyalanamamasının sağlanmasıdır.
18-Güvenlik konusunda bilinç:
Sonuç itibariyle en zayıf halkanız kadar güçlüsünüzdür. Şirket çalışanlarının veritabanı yöneticisinden çaycısına, yazılım mühendisinden şirket girişindeki danışmanlığa kadar bilinçli olması gerekiyor, ki mesela şirketin bahçesinde bulunan bir USB bellek ağdaki bir bilgisayara takılmasın, şifreler paylaşılmasın, yetkisiz kişiler yetkili olmadıkları departmanlara fiziksel olarak giremesin.
Eğer Microsoft SQL Server veritabanı sunucularınızın yeni versiyonlara yükseltilmesi ve güvenlik gibi konularda desteğe ihtiyacınız olursa bana ulaşabilirsiniz.
Ekrem Önsoy
Microsoft SQL Server Danışmanı
www.ekremonsoy.com
Hiç yorum yok:
Yorum Gönder