Son güncelleme: 27.07.2026
Bir uygulama, her kullanıcıyı doğru şekilde kimlik doğrulasa bile kişisel verileri yanlış kişilere ifşa edebilir.
Bu, Kişisel Verileri Koruma Kurumu tarafından 22 Temmuz 2026 tarihinde Global Bilgisayar Kontrol Sistemleri San. ve Tic. A.Ş. hakkında yayımlanan kamuya açık veri ihlali bildiriminin ortaya koyduğu temel risktir.
Bildirime göre bir saldırgan, veri sorumlusunun uygulama altyapısındaki bir yetkilendirme zafiyetinden yararlanarak yetkisiz erişim sağlamıştır. Bir uç nokta, tek bir çağrıda 1.000 adede kadar temel profil kaydı döndürebiliyordu. Duyurulan ihlal; kullanıcılar, personel ve hastalar dahil olmak üzere 1.022 kişiyi etkilemiştir.
Bildirim önemli olmakla birlikte teknik açıdan sınırlıdır. Uç noktanın bir API olduğunu belirtmemekte, başarısız olan yetkilendirme mantığını açıklamamakta, yetkisiz erişimin süresini vermemekte veya saldırganın kayıtları sadece görüntülediğini mi yoksa kopyalarını aldığını mı belirtmemektedir.
Bu nedenle kuruluşlar, bu özel olaya kesin bir OWASP sınıflandırması atamaktan kaçınmalıdır. Daha faydalı ders ise daha kapsamlıdır: Kimlik doğrulama, yanıt boyutu sınırları ve kullanıcı rolü alanları; her nesne, işlev, özellik ve iş bağlamı için yetkilendirme uygulanmadığı sürece kişisel verileri korumaz.
Özellikle KVKK soruşturması devam ederken, doğrulanmış gerçekler ile teknik yorum arasındaki ayrım önem taşımaktadır.
| Issue | What the public notice says |
|---|---|
| Data controller | Global Bilgisayar Kontrol Sistemleri San. ve Tic. A.Ş. |
| Cause of the breach | A cyberattack exploiting an authorization vulnerability in the controller’s application infrastructure. |
| Result | Unauthorized access. |
| Technical interface | The notice refers to an “endpoint” and a “single call,” but does not expressly identify it as an API. |
| Record-return limit | The endpoint did not use pagination and could return no more than 1,000 basic-profile records in one call. |
| Announced scope | Less than 1% of the total database’s basic-profile data was affected. |
| Affected groups | Employees, users and patients. |
| Affected data | Name and surname, telephone number, email address and users’ roles in the system. |
| Number of affected people | 1,000 standard users and 22 personnel, totalling 1,022 people. |
| Regulatory status | The Board decided on 22 July 2026, through Decision No. 2026/1492, to publish the breach notice. |
| Investigation status | The KVKK Authority’s examination was continuing when the notice was published. |
Bildirim şunları açıklamamaktadır:
Bu noktalar kısa açıklamadan çıkarılmamalıdır. Özellikle "uç nokta" (endpoint) ve "çağrı" (call) kelimeleri API terminolojisiyle uyumludur ancak etkilenen arayüzün kesin olarak bir API olduğunu kanıtlamaz.
Yetkilendirme, tanımlanmış bir kullanıcının, hizmetin veya cihazın neleri yapabileceğini belirler.
Bir uygulamada bu izinler doğru şekilde uygulanmadığında yetkilendirme açığı oluşur. Bir kişi sisteme yasal olarak giriş yapmış olsa bile şunları yapabilir:
Yetkilendirme normalde sunucu tarafında her ilgili istek için uygulanmalıdır. Bir düğmeyi gizlemek, menü seçeneğini kaldırmak veya tarayıcı ya da mobil uygulamadaki kısıtlamalara güvenmek yetersizdir çünkü istemci tarafındaki kontroller genellikle atlatılabilir.
Kimlik doğrulama ve yetkilendirme farklı sorunları çözer.
| Security question | Control |
|---|---|
| “Who are you?” | Authentication |
| “Are you allowed to perform this action?” | Authorization |
| “Are you allowed to access this particular record?” | Object-level authorization |
| “Are you allowed to receive these fields?” | Property- or field-level authorization |
| “Are you allowed to perform this action in the present role, organization and business context?” | Function-, role- or context-level authorization |
Çok faktörlü kimlik doğrulama, hesap ele geçirme işlemlerini zorlaştırabilir. Ancak, düzgün bir şekilde kimliği doğrulanmış bir hesabın bozuk bir yetkilendirme kuralını istismar etmesini engellemez.
Benzer şekilde, geçerli bir oturum belirteci yalnızca uygulamanın kullanıcının kimliğini kabul ettiğini kanıtlar. Bu belirteçle yapılan her isteğin izin verilebilir olduğunu kanıtlamaz.
2026 tarihli kamuoyu duyurusu, güvenlik açığını sınıflandırmak için yeterli ayrıntı sağlamamaktadır. Yine de API'ler veya benzer uygulama uç noktaları çalıştıran kuruluşlar, tekrarlayan çeşitli yetkilendirme hatalarına karşı test yapmalıdır.
Bir uygulama; kullanıcı, hasta, sipariş, dosya veya başka bir kayıt için bir tanımlayıcı alır ancak talep edenin o belirli nesneye erişim yetkisi olup olmadığını doğrulamaz.
Örneğin, şunu değiştirmek:
/patients/4812şuna:
/patients/4813her iki kayıt da mevcut olduğu için başka bir hastanın bilgilerini döndürmemelidir.
Kontrol mekanizması, talep edenin sadece giriş yapıp yapmadığını değil, talep eden ile talep edilen nesne arasındaki ilişkiyi değerlendirmelidir.
Standart bir kullanıcı; yönetici, klinisyen, destek personeli veya başka bir ayrıcalıklı rol için tasarlanmış bir işlevi çağırabilir.
Bu durum, arayüz işlevi gizlediğinde ancak sunucu rol kısıtlamasını bağımsız olarak uygulamadığında ortaya çıkabilir.
Bir kullanıcı bir nesneye erişme yetkisine sahiptir ancak rolü için gereksiz olan alanları alır.
Örneğin, randevu planlayan bir kullanıcı hastanın adına ve randevu saatine ihtiyaç duyabilir ancak klinik notlara, kimlik belgesi ayrıntılarına veya dahili risk işaretlerine ihtiyaç duymaz.
Alan düzeyi kısıtlamalar, yanıt oluşturulmadan önce uygulanmalıdır. Tüm alanları istemciye gönderip sadece arayüzde gizlemek, etkili bir koruma sağlamaz.
Bir sistem; standart kullanıcı, çalışan, klinisyen, yönetici veya destek operatörü gibi roller içerebilir ancak bu rolleri uç noktalar genelinde tutarsız bir şekilde uygulayabilir.
Veritabanındaki bir rol etiketi, tek başına bir erişim denetimi değildir. Korunan her işlem, rolü ve diğer tüm ek koşulları belirli bir izne eşlemelidir.
Çok kiracılı sistemlerde yetkilendirme, bir müşterinin kullanıcılarının başka bir müşterinin kayıtlarına erişmesini engellemelidir.
Yalnızca kayıt tanımlayıcısına göre filtreleme yapmak ve ilgili kiracı veya organizasyon tanımlayıcısını zorunlu tutmamak, müşteriler arası veri sızıntısına yol açabilir.
Roller, sağlık hizmetleri ve diğer hassas ortamlar için genellikle tek başına çok kapsamlı kalır.
Bir klinisyenin rolü, hasta bilgilerine erişim için genel bir yetki tanımlayabilir; ancak erişim yine de aktif bir tedavi ilişkisine, atanan departmana, konuma, acil durum erişim prosedürüne veya belgelenmiş başka bir bağlama bağlı olabilir.
Maksimum yanıt boyutu, kaynak tüketimini azaltabilir ve bazı durumlarda tek bir istekte dönen veri miktarını sınırlayabilir. Ancak bu bir yetkilendirme denetimi değildir.
1.000 kayıtlık bir sınır, temel soruyu yanıtlamaz: İstekte bulunan kişinin bu kayıtları görmeye yetkisi var mıydı?
Hukuka aykırı olarak ifşa edilen tek bir kayıt bile kişisel veri güvenliği ihlali teşkil edebilir. Etkinin ciddiyeti, veritabanının ne kadarının etkilendiğinden daha fazlasına bağlıdır. İlgili faktörler şunları içerebilir:
Yanıt boyutu sınırları, sayfalama, hız sınırlamaları ve sorgu maliyeti kontrolleri, derinlemesine savunma önlemleri olarak faydalı olmaya devam eder. Ancak bunlar yetkilendirmenin yerini almamalı, onunla birlikte çalışmalıdır.
Güvenli bir uç nokta genel olarak şunları belirlemelidir:
Kamuya yapılan bildirimde etkilenen veriler olarak isimler, telefon numaraları, e-posta adresleri ve sistem rolleri listelenmiştir. Tanıların, tıbbi kayıtların, tedavi detaylarının veya diğer sağlık bilgilerinin erişime açıldığı belirtilmemiştir.
Olay raporlanırken bu sınırlama korunmalıdır.
Bununla birlikte, olası zararı değerlendirirken bağlam hala önemlidir. Kimliği belirlenmiş bir kişiyi bir hasta grubu, sağlıkla ilgili bir hizmet veya belirli bir sistemle ilişkilendirmek, aynı iletişim bilgilerini bu bağlam olmadan ifşa etmekten daha hassas olabilir. Bu durum, ikna edici kimlik avı mesajlarını, taklit girişimlerini veya birey hakkında istenmeyen çıkarımları destekleyebilir.
Bu nedenle kuruluşlar, hem ifşa edilen alanları hem de bu alanların aşağıdakilerle birleştirildiğinde neyi ortaya koyduğunu değerlendirmelidir:
Hasta odaklı sistemlerde yetkilendirme tasarımı, kullanıcının ilgili hasta ile meşru bir ilişkisi olup olmadığını da dikkate almalıdır. "Personel" veya "sağlık uzmanı" gibi geniş bir role sahip her çalışana tüm hasta kayıtlarına erişim izni vermek, nadiren yeterli bir en az yetki modelidir.
Olası kontroller şunlardır:
Uygun model; uygulamaya, ilgili sektör kurallarına ve operasyonel gereksinimlere bağlıdır.
Yetkilendirme kontrolleri; kodlama hataları, yapılandırma değişiklikleri, belgelenmemiş uç noktalar veya uygulama sürümleri arasındaki tutarsız kurallar nedeniyle başarısız olabilir. Bu nedenle, hem erken tespit hem de daha sonraki ihlal değerlendirmesi için günlükleme ve izleme gereklidir.
İlgili günlükler şunları içerebilir:
Günlükler, yanıtta yer alan hassas verileri gereksiz yere kopyalamamalıdır. Ayrıca yetkisiz değişikliklere karşı korunmalı ve kuruluşun risk değerlendirmesi, yasal gereklilikleri ve olay müdahale ihtiyaçlarıyla uyumlu bir süre boyunca saklanmalıdır.
Faydalı tespit senaryoları şunlardır:
İzleme, her rol için beklenen davranışa dayalı olmalıdır. Yetkili bir raporlama hizmeti için olağan olan bir istek hacmi, standart bir kullanıcı için oldukça anormal olabilir.
Yetkisiz erişimden şüphelenildiğinde, kurumun maruziyeti, olayı anlamak için gereken kanıtları yok etmeden sınırlaması gerekir.
Pratik bir müdahale süreci aşağıdaki aşamaları içermelidir.
Uyarının ne zaman alındığını, kurumun olası bir kişisel veri ihlalinden ilk ne zaman haberdar olduğunu, olayın ne zaman doğrulandığını ve her bir kararı kimin verdiğini kaydedin.
KVKK bildirim süresi, veri sorumlusunun ihlali öğrendiği ana bağlıdır. Bu durum, belgelenmiş bir keşif zaman çizelgesini özellikle önemli kılar.
Olayın türüne bağlı olarak, sınırlama şunları içerebilir:
Acil durum değişiklikleri belgelenmeli ve test edilmelidir. Aceleyle yapılan bir yama, yeni bir güvenlik açığı yaratabilir veya kanıtları ortadan kaldırabilir.
Günlükler (loglar) dönmeden veya sistemler yeniden oluşturulmadan önce, aşağıdakileri koruma altına alın:
Kanıtlar; bütünlüğü, erişim geçmişini ve uygun durumlarda gözetim zincirini koruyacak şekilde ele alınmalıdır.
Soruşturma şunlar arasında ayrım yapmalıdır:
İndirme işleminin gerçekleştiğine dair kanıt bulunmaması, verilerin görülmediği anlamına gelmez. Sonuç; mevcut günlükler, yanıt kayıtları, saldırgan etkinliği ve izleme ortamının sınırlamaları temel alınarak oluşturulmalıdır.
Normal erişimi yeniden sağlamadan önce uç noktayı şu açılardan test edin:
Aynı yetkilendirme hatasının sonraki sürümlerde tekrar ortaya çıkmaması için regresyon testleri eklenmelidir.
6698 sayılı Kanun'un 12. maddesi, veri sorumlularının kişisel verilerin hukuka aykırı olarak işlenmesini ve erişilmesini önlemek, verilerin korunmasını sağlamak amacıyla gerekli teknik ve idari tedbirleri almasını zorunlu kılar.
12. maddenin 5. fıkrası uyarınca, işlenen kişisel verilerin kanuni olmayan yollarla başkaları tarafından elde edilmesi halinde, veri sorumlusu durumu en kısa sürede ilgili kişiye ve Kişisel Verileri Koruma Kurulu'na bildirmelidir.
Kurul'un 2019/10 sayılı kararı, "en kısa sürede" ifadesini, veri sorumlusunun ihlali öğrendiği andan itibaren gecikmeksizin ve en geç 72 saat içinde Kurul'a bildirimde bulunulması gerektiği şeklinde yorumlamaktadır.
Tüm bilgilerin hemen sağlanamadığı durumlarda, veri sorumlusu bilgileri aşamalı olarak ve makul olmayan bir gecikme olmaksızın sunabilir. Haklı bir gerekçeyle 72 saat içinde bildirimde bulunamayan veri sorumlusu, gecikmenin nedenini açıklamak zorundadır.
Karar ayrıca veri sorumlularının şunları yapmasını gerektirir:
Etkilenen kişilere, kimlikleri belirlendikten sonra makul bir süre içinde bilgi verilmelidir. İletişim bilgileri mevcutsa, bildirim doğrudan yapılmalıdır. Doğrudan iletişim mümkün değilse, veri sorumlusunun web sitesinde yayınlama gibi başka uygun bir yöntem kullanılabilir.
2019/271 sayılı Karar uyarınca, etkilenen kişilere yapılacak bildirim açık ve anlaşılır bir dille hazırlanmalı ve en azından şunları içermelidir:
Temmuz 2026 tarihli bildirim, veri sorumlusunun ihlali keşfettiği tarihi, bildirim tarihini veya etkilenen kişilere doğrudan ulaşılıp ulaşılmadığını açıklamamaktadır. Bu nedenle, bildirim zamanlamasının veya iletişim uyumluluğunun değerlendirilmesi için yeterli bilgi sunmamaktadır.
Kuruluşlar, adli bilişim analizinin tamamlanmamış olması gerekçesiyle Kurul'a yapılacak ilk bildirimi geciktirmemelidir. Kademeli bildirim mekanizması, veri sorumlusunun bildirime tabi bir ihlalin gerçekleştiğini bildiği ancak ihlalin tam nedenini veya kapsamını henüz belirleyemediği durumlar için mevcuttur.
Açıklanan kayıt sınırı ve veritabanının genelinde etkilenen yüzde, kapsam hakkında faydalı bilgiler sunsa da, bildirimin merkezindeki kontrol hatasının göz ardı edilmesine neden olmamalıdır.
10, 100 veya 1.000 kayıt döndüren bir uç nokta, yine de talep edenin her bir kaydı ve döndürülen her bir alanı almaya yetkili olup olmadığına karar vermelidir. Kimlik doğrulama, sayfalama ve hız sınırlama bu kararı veremez.
Müşteri, çalışan veya hasta bilgilerini işleyen kuruluşlar, yetkilendirmeyi ayrı bir güvenlik katmanı olarak test etmelidir. Bu, yalnızca kimin giriş yapabildiğini değil; her kullanıcının hangi rol altında, hangi kuruluş için, hangi kişiyle ilişkili olarak ve hangi operasyonel bağlamda nelere erişebildiğini test etmek anlamına gelir.
Bu olayla ilgili nihai düzenleyici sonuçlar henüz bilinmemektedir. KVKK Kurumu incelemesini tamamlayana veya daha sonra bir karar yayınlayana kadar, teknik neden yalnızca kamuoyu duyurusunda doğrulanan düzeyde tanımlanmalıdır: uygulama altyapısındaki bir yetkilendirme zafiyetinin istismar edilmesi sonucu yetkisiz erişim.
Kooch Cybersecurity & Compliance, kuruluşların uygulama güvenliği, erişim yönetişimi, olay müdahalesi ve KVKK yükümlülüklerinin pratikte nasıl bağlantılı olduğunu incelemelerine yardımcı olur.
Bu süreç; erişim kontrolü belgelerinin, olay müdahale süreçlerinin, veri işleyen düzenlemelerinin, kanıt saklama politikalarının ve bir KVKK/GDPR Boşluk Analizi veya devam eden uyumluluk çalışmaları yoluyla tanımlanan gizlilik etkilerinin gözden geçirilmesini içerebilir. Ürüne özel zafiyet testleri, uygun niteliklere sahip uygulama güvenliği uzmanlarıyla koordinasyon gerektirebilir.
