Sağlık kuruluşlarında iki kısıt aynı anda çalışıyor. Bir yanda işlenen verinin özel nitelikli kişisel veri olması, diğer yanda sistemin durmasının doğrudan hasta hizmetini etkilemesi. Diğer sektörlerde bu ikisinden biri baskın olur; burada ikisinden de taviz verilemiyor.
Altyapıyı zorlayan ne
Birincisi kesinti toleransının düşüklüğü. Hasta kabul, randevu ve görüntüleme sistemleri çalışmadığında iş durmuyor, hizmet duruyor. Bu, felaket kurtarma hedeflerinin sıkı belirlenmesini ve daha önemlisi bu hedeflerin kâğıt üzerinde değil, gerçekten ölçülmüş olmasını gerektiriyor.
İkincisi erişim kayıtları. Kimin hangi hasta kaydına ne zaman eriştiği kayıt altında olmalı. Bu, log hacmini ciddi biçimde büyütüyor ve log'ların saklanması, aranabilir olması ve bütünlüğünün korunması ayrı bir altyapı işi haline geliyor.
Üçüncüsü veri hacminin karakteri. Görüntüleme verisi büyük, uzun süre saklanması gerekiyor ve eski kayıtlara nadiren ama mutlaka erişiliyor. Bu, sıcak ve soğuk depolamanın ayrıştırılmasını gerektiren tipik bir durum; her şeyi en hızlı katmanda tutmak gereksiz maliyet üretiyor.
Dördüncüsü saat dışı destek. Sağlık kuruluşlarının çalışma saati kavramı diğer sektörlerdekinden farklı. Bu yüzden kritik olaylarda 7 gün 24 saat kapsam varsayılan bir gereksinim oluyor; destek işleyişimiz bu kapsamı içeriyor.
Mevzuat tarafı
KVKK sağlık verisini özel nitelikli kişisel veri sayıyor ve bu kategori için daha sıkı bir işleme rejimi öngörüyor. Altyapı tarafındaki pratik karşılığı şu: erişimin daraltılması, şifrelemenin hem taşınırken hem beklerken uygulanması, erişim kayıtlarının tutulması ve saklama süresi dolduğunda imhanın gerçekten yapılması.
Bizde veri taşınırken TLS 1.3, beklerken disk düzeyinde AES-256 ile şifreleniyor; anahtar yönetimi merkezî yürütülüyor ve anahtar döngüsü tanımlı. Veriler Türkiye'deki veri merkezlerimizde, kendi donanımımız üzerinde duruyor ve yurt dışına çıkmıyor. Bunun ne anlama geldiğini ve nerede tek başına yetmediğini veri egemenliği yazımızda ele aldık.
VERBİS tarafında kayıt yükümlülüğü Kurul'un belirlediği eşiklere göre değişiyor. Yükümlülük doğduğunda önemli olan nokta, sicildeki beyanların gerçek işleme faaliyetleriyle tutarlı olması; envanterle uyuşmayan bir kayıt denetimde başlı başına bulgu üretiyor.
Kapsamımızda ne var
Sunucular tek bir fiziksel makineye bağlı değil; birden fazla düğümden oluşan yedekli bir küme üzerinde çalışıyor ve bir düğüm devre dışı kaldığında iş yükleri diğerlerinde devam ediyor. Bu davranışı planlı tatbikatlarla, sistem gerçek yük altındayken test ediyoruz.
Felaket kurtarma tarafında hedeflediğimiz değerler RPO 15 dakika, RTO kritik sunucular için 1 saat. Bunlar hedef niteliğinde ve kapsam sözleşmede tanımlanıyor. İki ölçütün ne anlama geldiğini RTO ve RPO nedir sayfasında, hizmetin kapsamını Disaster Recovery as a Service sayfasında bulabilirsiniz.
Yedekler ayrı bir depolama sisteminde, saklama süresi boyunca değiştirilemez biçimde tutuluyor; fidye yazılımı bulaşması halinde bile silinemez veya şifrelenemez. Uyum çalışmasında verdiğimiz destek uyumluluk yönetimi sayfasında.
Saklama ve imha
Sağlık tarafında verinin uzun süre saklanması gerekiyor ama süresiz değil. Saklama süresi dolduğunda imhanın gerçekten yapılmış olması, denetimde en sık sorulan ve en sık cevapsız kalan konulardan biri.
Buradaki teknik zorluk şu: veri tek bir yerde durmuyor. Üretim veri tabanından silinen bir kayıt yedeklerde, log'larda ve arşivlerde yaşamaya devam edebiliyor. Değiştirilemez yedek politikası ile imha yükümlülüğü ilk bakışta çelişiyor gibi görünüyor; çözüm, saklama süresinin veri kategorisine göre baştan tanımlanması ve yedek saklama süresinin bununla uyumlu kurulması oluyor.
Bu yüzden yedekleme planını ve saklama süresini sözleşme aşamasında, veri kategorileriyle birlikte belirliyoruz. Süre dolduğunda imha turunun çalıştığına dair kayıt üretiliyor; denetçi politikayı değil, politikanın uygulandığına dair kanıtı arıyor.
Nereden başlanır
İlk adım veri envanteri: hangi verinin nerede tutulduğu, kimin eriştiği ve nereye aktarıldığı. Sağlık tarafında bu çalışmanın en çok sürpriz üreten kısmı, verinin üretim veri tabanı dışında yedeklerde, log'larda ve üretimden kopyalanmış test ortamlarında da bulunması oluyor. Test ortamı genelde daha gevşek yetkilendirildiği için burası öncelikli kapatılması gereken bir açık.
İkinci adım geri dönüşü ölçmek. Yedeğin alınmış olması ondan dönülebileceğini garanti etmiyor; en kritik sistem için bir geri yükleme denemesi yapıp süreyi ölçmek, hedeflerin gerçekçi olup olmadığını tartışmasız gösteriyor.
Geçişin nasıl planlandığını geçiş süreci sayfasında, mimarinin nasıl göründüğünü felaket kurtarma topolojisi sayfasında bulabilirsiniz. Diğer sektörler için çözümler sayfasına bakın.
Sağlık tarafında geçişi planlarken en çok dikkat ettiğimiz şey, kesim penceresinin hasta hizmetini etkilemeyecek bir zamana denk gelmesi. Bu, çoğu zaman gece saatlerinde ve hafta içi değil hafta sonu anlamına geliyor. Pencere ve geri dönüş planı yazılı olarak önceden paylaşılıyor; kimse geçiş gecesi sürprizle karşılaşmıyor. Mimarinin nasıl göründüğünü referans mimariler bölümünde, destek işleyişini destek ve hizmet seviyeleri sayfasında bulabilirsiniz.