Denetime Ramak Kala Bir Gizemin Aydınlatılması

Özellikle son aylarda farklı birçok şirketle oldukça hummalı bir şekilde güvenlik konulu toplantılar ve çalışmalar yapıyoruz. Bunun tek nedeni hiç durmadan ve çeşitli katmanlarda ortaya çıkan donanım ve yazılım açıklarının yanısıra, çeşitli kurumlar tarafından uygulanan harici denetimler ve bu çerçevede ortaya çıkan ihtiyaçlar oluyor. Tabii olarak veritabanları da tüm bu kaosun merkezinde oluyor.

Bakım ve Destek Anlaşması kapsamında danışmanlık hizmeti verdiğim birçok şirkette özellikle son zamanlarda Ernst & Young, KPMG, PWC, PCI gibi uluslararası firmaların yanısıra Finansbank, Abank, TEB, Akbank gibi bankaların çeşitli denetimleri gerçekleşiyor. Yıllardır çok çeşitli kurumlarda, defalarca denetime tabi tutulunca ne zaman, nereden bulgu geleceğini biliyorsunuz. Bu nedenle destek verdiğim ortamlarda varsayılan olarak bu noktalar için zaten gerekli müdahalelerde bulunurum. Fakat bazı tedbirler ancak yeri geldiğinde, gerçekten gerekiyorsa ve yönetimin de desteğiyle alınabiliyor. Örneğin veritabanına gelen işlemlerin kayıt altına alınması gibi. Çünkü bu, ek maliyetler doğurabilecek ve koordinasyon gerektiren bir hamle.

Bir müşterimin geçireceği denetim dolayısıyla Microsoft SQL Server veritabanı ortamındaki bazı kritik tablolarında gerçekleşen kayıt okuma ve değişiklik işlemlerinin kayıt altına alınması gerekiyordu. Yani mesela bir tablodaki kayıt ne zaman, nasıl ve kim tarafından okunmuş veya değiştirilmiş gibi. Bu kapsamda yapılmak istenen kayıt altına alma işleminin hacmi, kapsamı, denetim firmasının ve müşterimin beklentisi, müşterimin ortamı, olanakları ve bütçesi gibi kriterleri değerlendirerek kendilerine bazı tavsiyelerde bulundum. Sonuç itibariyle Microsoft SQL Server'ın önceden başka ortamlarda da (bir banka dahil) kullanmış olduğum bir özelliği olan Database Audit özelliğini kullanmaya karar verdik.

Database Audit özelliğini devreye aldıktan sonra bir şey dikkatimi çekti, SQL cümlecikleri (statement) nedense kırpılmış şekilde kaydediliyordu. Önceden böyle bir durumla hiç karşılaşmamıştım ve buna bir türlü anlam veremedim. 

"statement" alanındaki SQL cümleciği kırpılmış olarak kaydediliyor

Gayet farkındayım ki Windows Application Log dosyasını bu amaçla kullanmak muhteşem bir karar değil; ama Database Audit'in ve diğer benzer mekanizmaların ürettiği kayıtları toplayacak olan uygulamanın bize sunduğu seçeneklerdeki kısırlık nedeniyle Database Audit'in ürettiği kayıtları doğrudan Windows Application Log'una kaydetmek birçok açıdan en mantıklı seçenekti ve ben de bunu uyguladım. Önceki tecrübelerimde Database Audit tarafından üretilen kayıtları doğrudan dosyalara kaydettiğim için ve bir ihtimal yaşadığımız bu sorunun üretilen kayıtların Windows Application Log dosyasına kaydedilmesiyle ilgili olabileceği ihtimaline karşın test etmek için yine bir dosyaya kaydetmeyi de denedim; fakat maalesef sonuç yine aynıydı! SQL cümlecikleri kırpılarak kaydediliyordu.

Testlerden sonra hemen Microsoft'un dokümantasyonunu inceledim ve bu konuda yazılmış olabilecek olası yazıları aradım; fakat konuyla ilgili bir bilgiye ulaşamadım.

Bakım ve Destek Anlaşması kapsamındaki müşterilerimin doğrudan Microsoft ile anlaşması olsun veya olmasın senede 2 defa ücretsiz Microsoft'a çağrı (Case) açılması ve tarafımca bunun takibinin yapılması hakkı da oluyor. Bu kapsamda müşterime bunun belki Database Audit özelliği ile ilgili bir ürün hatası olabileceğini ve dilerlerse Microsoft'a çağrı açabileceğimi söyledim; fakat bunun öncesinde daha hızlı sonuç alabilme ümidiyle şansımı bir de Microsoft'un ilgili forumlarında denemek istedim ve sorumu sorup beklemeye başladım. Bir süre sonra beklediğim cevaplar geldi!

1 günlük bekleyişten sonra gelen cevap ve yanan ampul.

İyiki de sormuşum, hiç Microsoft'un çağrı süreciyle vakit kaybetmeden sağolsun Tom Philips'ten sorunumuzu aydınlatacak cevabı almıştım. Belli ki ilk incelememde dokümantasyondaki ve sorunumun cevabı olan bu kritik bu sayfayı ıskalamışım:

Microsoft dokümantasyonu

Özetlemek gerekirse öncedeki Database Audit tecrübelerimde belli ki hiç 4000 karakteri geçen SQL cümleciğine denk gelmemişim veya dikkatimi çekmemiş ve bu nedenle bu davranışı fark edememişim. Halbuki bu durum Database Audit ile ilgili bir sorun değil, özelliğin doğal çalışma mekanizmasıymış. Bir SQL cümleciği 4000 karakteri geçiyorsa Database Audit bu cümleciği "sequence_no" adı altında artan sayı değeriyle cümleciğin sonuna kadar parçalara bölüyormuş. SQL cümleciğinin tamamını okumak için "event_time", "action_id" ve "session_id" alanlarındaki değerleri takip edebilirmişim. Evet, çok pratik değil; fakat nihayetinde bu bir ürün hatası da değil!

Bu gizemi de aydınlattıktan sonra içimiz rahatladı, çünkü şirketin tabi olacağı denetime çok az bir süre kalmıştı ve sorunumuz için muhakkak bir çözüm üretmemiz gerekiyordu. Eğer bu özelliği zamanında hayata geçiremezsek ve SQL cümleciklerinin bu durumunu denetim firmasına açıklayamazsak bu konuda bulgu çıkabilir ve nahoş sonuçlara neden olabilirdi.

Ekrem Önsoy
Microsoft SQL Server Danışmanı
www.ekremonsoy.com

İş sürekliliği ve şirket imajınıza etkisi

Bu Pazar sabahı neredeyse gün ağarana kadar bakım ve destek anlaşmamız olan çeşitli müşteri ortamlarında Windows güncellemeleri uyguladık. Bu Microsoft SQL Server ortamlarının bazılarında iş sürekliliğini sağlayan Always On Availability Groups veya Failover Clustering gibi teknolojiler kullanılırken, bazıları ise "Stand-alone" tabir edilen, yani iş sürekliliği olmayan ortamlardı.

İş sürekliliği altyapısı olan ortamlardaki Windows güncellemelerinden kaynaklanan kesinti süreleri ortalama 5-8 saniye ile sonlanırken, iş sürekliliği olmayan ortamlarda bu süre 5-10 dakikalara kadar çıktı. İş sürekliliği olmayan ortamlar için bu nispeten belirsiz bir süre, çünkü güncellemeden kaynaklı çıkabilecek olası bir sorun, böyle bir ortamdaki kesinti süresini çok daha fazla uzatabilir. Halbuki iş sürekliliği olan bir ortamda güncellemeler önce pasif olan sunucularda uygulandığı için herhangi bir aksilik güncellemeler henüz canlı sisteme uygulanmadan büyük ihtimalle fark edilir. Gerekiyorsa pasif olan sunucu tamamen yeniden kurulabilir, ama sonuç itibariyle doğru kurgulanmış bir canlı sistemde herhangi bir kesinti oluşmadan sorun atlatılmış olur.

Peki iş sürekliliği kimler için gerekli? Bugüne kadar birçok sektörden birçok şirketle çalışma şansı buldum ve gördüm ki, iş sürekliliği "şu sektörler için olmazsa olmaz, bu sektörler için olmasa da olur" denilerek genelleme yapılabilecek bir konu değil. Örneğin bazı sağlık veya finans kurumları 7/24 hizmet verirken, bazıları 5/8 hizmet verebiliyor. İş sürekliliği, bir şirketin verdiği hizmetler ve hedefleri kapsamında seçilebilecek bir yöntem. Bununla birlikte, eğer bir şirket 7/24 hizmet veriyorsa iş sürekliliğini muhakkak ciddiye almalıdır diye düşünüyorum.

Mesela küçük bir test yapalım. IT veya Sistem Yöneticisi olarak yönetiminizde olan veritabanı ortamlarınız için şu sorulara nasıl yanıt verirdiniz? 

"Tahammül edebileceğiniz en uzun veritabanı kesinti süresi nedir?"

"Canlı veritabanı ortamınızdaki olası bir sorun/kesinti hakkında son kullanıcılar tarafından mı haberdar ediliyorsunuz?"

"Canlı veritabanı ortamınızda bir kesinti oluşması durumunda, veritabanlarınızı en kısa ne kadar sürede tekrar çalışır duruma getirebilirsiniz?"

Tabii ki bu konudaki sorular bunlarla sınırlı değil, hatta bunlar sadece bir başlangıç; ama iyi bir başlangıç.

İş sürekliliğinden ayrı olarak bu sabahki çalışma kapsamında kesinti yaşanan ortamların bazılarında kesinti nedeniyle alınan hataların doğrudan son kullanıcıya yansıtıldığını gördüm. Bir son kullanıcı gözüyle böyle bir durumun bir şirketin imajı açısından hiç de hoş olmadığını düşünüyorum. Bir profesyonel gözüyle de veritabanı ile ilgili hataların doğrudan son kullanıcılara ve potansiyel saldırganlara alenen ifşa edilmesini güvenlik açısından hiç doğru bulmuyorum. Bu sorun, iş sürekliliği olsun veya olmasın her halükarda gerçekleşebiliyor. Tabii iş sürekliliği olan ortamlarda bu sorun birkaç saniye sürerken, diğer ortamlarda uzun dakikalar boyunca sürebiliyor.

İş sürekliliği şansa bırakılacak kadar ucuz bir konu değil. Bazı ortamlardaki 10 dakikalık kesintinin sadece maddi bedeli dudak uçuklatacak kadar yüklü olabiliyor.

Az kesintili, bol huzurlu günler dilerim.

Ekrem Önsoy
Microsoft SQL Server Danışmanı
www.ekremonsoy.com