Tedarikçi Veritabanınıza Bağlandığında Sorumluluk Kimde?

Bir tedarikçi danışmanı, kendi dizüstü bilgisayarından üretim veritabanınıza bağlanıyor. Bağlantı bilgileri iki yıl önce bir e-postayla paylaşıldı. O danışman artık o firmada çalışmıyor olabilir; bunu bilmiyorsunuz çünkü hesap hala açık. Bu yazı, kurumların en az görünürlüğe sahip olduğu erişim türünü ve sorumluluğun gerçekte kimde kaldığını ele alıyor.

Üçüncü Tarafın Payı Büyüyor

Veri ihlali analizlerinde üçüncü taraf erişiminin payı son yıllarda belirgin biçimde arttı. Yaygın olarak takip edilen sektör raporlarında, ihlallerin üçte birine yakınının bir tedarikçi, hizmet sağlayıcı veya iş ortağı erişimiyle ilişkili olduğu bildiriliyor ve bu oran birkaç yıl öncesine göre iki katına çıkmış durumda. Tek bir tedarikçinin ihlal edilmesi, ortalama olarak birden fazla müşteri kurumunu birlikte etkiliyor.

Bu sayıların veritabanı tarafındaki karşılığı şudur: üretim veritabanına bağlanabilen kişilerin bir kısmı kurum çalışanı değildir, kurumun kimlik sisteminde yönetilmez, kurumun eğitiminden geçmez ve kurumun işten ayrılma sürecine tabi değildir. Yine de o veritabanındaki kişisel verinin sorumlusu kurumdur.

Sorumluluk Devredilemez

Veri koruma mevzuatının bu konudaki duruşu nettir ve kurumların en çok yanıldığı nokta buradadır. Veriyi işleyen taraf bir tedarikçi olsa bile, verinin sorumlusu olan kurum sorumluluktan kurtulmaz. Kişisel Verilerin Korunması Kanunu, veri güvenliğine ilişkin yükümlülüklerde veri sorumlusu ile veri işleyenin müştereken sorumlu olduğunu düzenler.

İşleyen tarafın da kendi yükümlülükleri vardır ve bunlar somuttur: yalnızca verilen talimat doğrultusunda işlemek, uygun güvenlik önlemlerini almak, işleme kayıtlarını tutmak, onaylanmış alt işleyenler dışında kimseyle çalışmamak, bir olay olduğunda gecikmeksizin bildirmek ve sözleşme bittiğinde veriyi silmek veya iade etmek. Ayrıca işleyen, kendi alt işleyenlerinin davranışından da sorumludur; zincirin aşağısındaki bir hata yukarıya doğru sorumluluk üretir.

Pratik sonuç şudur: "o değişikliği tedarikçi yaptı" cümlesi bir denetimde savunma değildir. Denetçinin soracağı soru değişikliği kimin yaptığı değil, kurumun ona nasıl izin verdiği ve ne yaptığını nasıl bildiğidir.

Tedarikçinin Veritabanınıza Ulaştığı Beş Yol

Bu yolların çoğu bir güvenlik istisnası olarak değil, işin normal parçası olarak kurulmuştur. Görünmez olmalarının sebebi de budur.

Bu beş yolun ortak özelliği, hiçbirinin kurumun değişiklik yönetimi sürecine girmemesidir. Süreç iç ekipler için tasarlanmıştır; tedarikçi erişimi ayrı bir dünyada, satın alma ve sözleşme tarafında yaşar. İki taraf birbirine hiç değmez.

Sözleşmenin Vaat Ettiği, Ortamın Sağladığı

Veri işleme sözleşmelerinde standart hale gelmiş taahhütler vardır. Aşağıdaki tablo, her taahhüdün karşılığının teknik ortamda gerçekten üretilip üretilmediğini sorar. Bu, denetimden önce yapılabilecek en yararlı egzersizdir.

Bu tablonun sağ sütununu doldurmaya çalışan kurumların çoğu, ilk satırda takılır. Tedarikçinin yaptığı işler bir talep kaydına bağlanmadığında, geri kalan dört satırın hiçbiri üretilemez; çünkü hepsi o kayda dayanır.

Çalışan Model: Süreli, Talebe Bağlı, Kayıtlı

Tedarikçi erişimini yönetmenin işe yarayan biçimi, kalıcı bir hesap vermek yerine erişimi işe bağlamaktır. Dört bileşeni vardır.

Süreli. Her tedarikçi hesabının bir son kullanma tarihi olur ve tarih geldiğinde erişim kendiliğinden kapanır. Uzatma bir karardır ve o kararın da kaydı olur. Tarihsiz hesap, kalıcı hesaptır.

Talebe bağlı. Tedarikçi doğrudan üretime bağlanmak yerine, yapılacak işi bir talep olarak gönderir. Talebi kurum içinden biri onaylar. Böylece "yalnızca verilen talimat doğrultusunda işleme" taahhüdü bir cümle olmaktan çıkıp bir kayda dönüşür.

Kayıtlı. Çalıştırılan metin, zamanı, etkilenen satır sayısı ve sonucu saklanır. Bu kayıt, ileride bir uyuşmazlık çıktığında iki tarafı da korur: kurum ne olduğunu gösterebilir, tedarikçi de kendisine atfedilen bir işi yapmadığını.

Maskeli. Tedarikçinin bir hatayı incelemek için veriye bakması gerekiyorsa, dönen sonuçta hassas kolonlar maskelenir. Hata ayıklamak için gereken şey genellikle verinin şekli ve ilişkileridir; müşterinin kimlik numarası değildir.

SQL Change Guard bu dört bileşeni aynı akış içinde üretir: tedarikçi talebi açar, kurum içinden onaylanır, çalıştırma onaya bağlı olarak açılır, çalıştırılan metin ve sonucu kaydedilir ve veri okuma taleplerinde hassas kolonlar sonuç kümesinde maskelenir. Tedarikçiye üretim sunucusunun parolasını vermek gerekmez.

Sözleşme Bittiğinde: En Çok Atlanan Adım

Tedarikçi ilişkisi bittiğinde yapılması gerekenler listesi genellikle finansal kalemlerle doludur: son fatura, teminat iadesi, teslim tutanağı. Teknik erişimin kapatılması bu listede ya yoktur ya da en altta durur.

Sonuç, kurumların üzerinde en az konuştuğu risk kalemidir: yıllar önce bitmiş bir projeden kalma, hala açık ve hala yetkili bir hesap. Bu hesabın kime ait olduğu, kimin bildiği ve o firmanın hala var olup olmadığı bilinmez. Böyle bir hesabın kötüye kullanılması için saldırganın kuruma hiç dokunması gerekmez; tedarikçi tarafındaki bir ihlal yeterlidir.

Bu adımın atlanmamasının tek güvenilir yolu, kapatmayı bir hatırlatmaya değil bir tarihe bağlamaktır. Erişim varsayılan olarak kapanır; açık kalması için bir kararın yenilenmesi gerekir. Böylece unutmanın sonucu erişimin açık kalması değil, kapanması olur.

Sık Sorulan Sorular

Tedarikçiyle veri işleme sözleşmemiz var. Bu yeterli değil mi?

Sözleşme gereklidir ve hukuki koruma sağlar, ancak bir kontrol değildir. Sözleşme tedarikçinin ne yapacağını söyler; ne yaptığını göstermez. Denetimde istenen, sözleşme metni değil taahhütlerin uygulandığını gösteren kayıttır. Ayrıca kişisel veri güvenliği yükümlülüklerinde sorumluluk müşterektir; tedarikçinin bir eksiği, kurumun sorumluluğunu ortadan kaldırmaz.

Tedarikçi erişimini tamamen kesebilir miyiz?

Çoğu durumda hayır ve zorlandığında sonuç kötüleşir. Bir ürünün desteği, kendi veritabanına bakabilmeyi gerektirir; erişim tamamen kesildiğinde destek süresi uzar ve kesinti maliyeti artar. Daha da kötüsü, resmi yol kapandığında gayriresmi yol açılır: kurum çalışanı kendi ekranını paylaşır, kendi hesabıyla girer ve tedarikçinin söylediklerini yazar. Bu durumda kayıt daha da kötüleşir, çünkü işlem artık bir kurum çalışanına atfedilmiştir. Hedef erişimi kesmek değil, erişimi süreli, talebe bağlı ve kayıtlı hale getirmektir.

Ürünün kendi güncelleme aracı şemayı değiştiriyor. Bunu nasıl yöneteceğiz?

Aracın çalışmasını engellemek genellikle mümkün değildir, ancak sonucu görünmez olmak zorunda değildir. İki pratik adım vardır. Birincisi, güncellemeyi bir değişiklik kaydı olarak açmak: hangi sürüme geçiliyor, ne zaman, kimin onayıyla. İkincisi, güncelleme öncesi ve sonrası nesne tanımlarını karşılaştırmak. Böylece sürüm notunda yazmayan değişiklikler de görünür hale gelir ve bir sorun çıktığında neyin değiştiği bilinir. Bu, aracı kontrol etmez ama sonucunu kayda alır.

Tedarikçinin kendi personelini biz nasıl takip edelim?

Tedarikçinin insan kaynakları süreçlerini takip edemezsiniz ve buna gerek de yoktur. Yapılması gereken, erişimi kişiye değil işe bağlamaktır. Tedarikçi tarafında kimin çalıştığı değişse bile, her işlem bir talebe ve o talebi onaylayan kurum çalışanına bağlıysa zincir kopmaz. Kalıcı hesap verildiğinde ise zincir tamamen tedarikçinin iç disiplinine bağlı hale gelir ve kurumun görünürlüğü sıfırlanır.

Nereden başlamak gerekir?

Tek bir listeyle: üretim veritabanlarına erişebilen ve kurum çalışanı olmayan tüm hesaplar. Her satıra üç bilgi yazın: hangi tedarikçi, hangi proje kapsamında, son kullanma tarihi ne. Üçüncü sütunun büyük ölçüde boş kalması beklenen sonuçtur ve tartışmayı kendiliğinden başlatır. Ardından tarihi olmayan hesapları kapatmak yerine önce bir tarih verin; kapatma kararını sahibiyle birlikte alın.