Açık S3 bucket nedeniyle 86.000’den fazla tıbbi kayıt ve PII’nin açığa çıktığı ‘hemşirelerin Uber’i’ ESHYFT olayı

 (websiteplanet.com)
1 puan yazan GN⁺ 2025-03-14 | 1 yorum | WhatsApp'ta paylaş
  • New Jersey merkezli HealthTech şirketi ESHYFT ile ilişkili açık bir veritabanında 86.341 kayıt ve 108,8 GB veri açığa çıktı; platform 29 eyalette sağlık kuruluşları ile hemşirelik personelini buluşturuyor
  • Açığa çıkan veriler arasında profil ve yüz görselleri, aylık çalışma takvimi CSV dosyaları, mesleki sertifikalar, vardiya atama sözleşmeleri, özgeçmişler ve ek PII yer alıyor
  • Bazı dosyalar, devamsızlık veya hastalık izni gerekçesini belgelemek için uygulamaya yüklenmiş tıbbi belgeler gibi görünüyor; bunlarda teşhis, reçete ve tedavi bilgileri bulunduğundan HIPAA kapsamında düzenlemeye tabi olabilir
  • Araştırmacının sorumlu açıklama bildiriminin ardından veritabanına erişim bir aydan uzun süre sonra kısıtlandı; ancak yönetim sorumlusu, maruz kalma süresi ve üçüncü taraf erişimi doğrulanmadı
  • Sağlık personeli platformlarının hassas veriler için şifreleme, düzenli güvenlik denetimleri, asgari saklama ve anonimleştirme, hassasiyet düzeyine göre ayrılmış depolama, MFA, ihlal müdahale planı ve bildirim kanalları bulundurması gerekiyor

ESHYFT’nin açık veritabanında tespit edilen sızıntı

  • Siber güvenlik araştırmacısı Jeremiah Fowler, parola koruması veya şifreleme bulunmayan bir veritabanı keşfetti ve bunu Website Planet ile paylaştı
  • Veritabanında ESHYFT’ye ait göründüğü belirtilen 86.341 kayıt vardı ve toplam boyutu 108,8 GB idi
  • Veritabanı adı ve iç belgeler, kayıtların ESHYFT’ye ait olduğunu gösteriyordu ve belgelerin çoğu “App” klasörü içindeydi
  • ESHYFT, sağlık kuruluşları ile sağlık personelini buluşturan bir mobil uygulama platformu işleten New Jersey merkezli bir HealthTech şirketi
    • Hedeflenen personel arasında Certified Nursing Assistants (CNA), Licensed Practical Nurses (LPN) ve Registered Nurses (RN) bulunuyor
    • Uygulama Apple App Store ve Google Play Store’da sunuluyor
    • Google Play Store’a göre indirme sayısı 50.000’in üzerinde
    • Apple artık kullanıcı istatistikleri sunmuyor

Açığa çıkan dosyalar ve sağlık bilgilerinin hassasiyeti

  • Sınırlı örnek incelemesinde çeşitli dosya türleri bulundu
    • Kullanıcı profili veya yüz görselleri
    • Aylık çalışma takvimi kayıtlarını içeren .csv dosyaları
    • Mesleki sertifikalar
    • Vardiya atama sözleşmeleri
    • CV’ler, özgeçmişler ve ek kişisel tanımlayıcı bilgiler (PII)
  • Tek bir elektronik tablo belgesinde 800.000’den fazla kayıt bulunuyordu
    • Hemşire iç kimliği
    • Tesis adı
    • Vardiya saatleri ve tarihleri
    • Çalışma saatleri gibi bilgiler
  • Uygulamaya yüklenmiş gibi görünen tıbbi belgeler de tespit edildi
    • Bunlar, bireysel hemşirelerin işe gelememe veya hastalık izni nedenlerini belgelemek için yüklenmiş dosyalar olabilir
    • Tıbbi raporlarda teşhis, reçete ve tedavi bilgileri yer alıyordu
    • Bu bilgiler HIPAA düzenleme kapsamına girebilir

Bildirim sonrası adımlar ve süren belirsizlikler

  • Araştırmacı ESHYFT’ye derhal sorumlu açıklama bildirimi gönderdi
  • Veritabanına açık erişim bir aydan uzun süre sonra kısıtlandı
  • ESHYFT’nin yanıtı şu oldu: “Thank you! we’re actively looking into this and working on a solution”
  • Hâlâ doğrulanmayan bazı noktalar var
    • Veritabanının doğrudan ESHYFT tarafından mı sahiplenilip yönetildiği, yoksa üçüncü taraf bir yüklenici tarafından mı yönetildiği
    • Araştırmacı bulmadan önce ne kadar süre açıkta kaldığı
    • Başkalarının erişip erişmediği
  • Ek erişim veya şüpheli faaliyetler yalnızca kurum içi adli bilişim denetimi ile tespit edilebilir

Sağlık personeli platformları büyüdükçe artan güvenlik yükü

  • ESHYFT, hemşirelerin kendi programlarına uygun vardiyaları seçmesini sağladığını ve sağlık kuruluşlarına doğrulanmış W-2 hemşirelik personeline erişim sunduğunu belirtiyor
  • Platform ABD’de 29 eyalette hizmet veriyor
    • AL, AZ, AR, CA, CT, DE, FL, GA, IL, IN, IA, KS, KY, MD, MI, MN, MO, NE, NJ, OH, PA, RI, SC, TN, VT, VA, WA, WI, WV
  • Health Resources & Services Administration (NCHWA) raporu, ABD genelinde kayıtlı hemşire açığının 2027’ye kadar %10’a ulaşacağını öngörüyor
  • Sağlık personeline yönelik talep arttıkça ESHYFT gibi platformlar iş gücü açığını kapatmada rol oynuyor
  • Sahada çalışan hemşirelik personelinin de çevrimiçi teknolojilerle entegre olması, HealthTech şirketleri için daha güçlü gizlilik korumalarını gerekli kılıyor
  • Hastaneler ve sağlık çalışanları veri depolama, bakım yönetimi ve istihdam için teknolojiye daha fazla bağımlı hale geldikçe sektör genelindeki siber güvenlik yükü de artıyor
  • Hastaneler kritik altyapı olarak kabul ediliyor ve son yıllarda birçok ağ ciddi fidye yazılımı saldırıları yaşadı

Olası riskler ve gerekli güvenlik önlemleri

  • Hemşirelik profesyonellerinin kişisel tanımlayıcı bilgileri, maaş bilgileri ve çalışma geçmişinin açığa çıkması hem bireyler hem de onları istihdam eden sağlık kuruluşları için risk oluşturabilir
  • Sürücü belgesi veya Social Security kartı gibi kimlik taramalarının adres ve iletişim bilgileriyle birleşmesi, kimlik hırsızlığı veya finansal dolandırıcılık için kötüye kullanılabilir
  • Kişisel ve mesleki bilgilerin sızması, gerçek verilerden yararlanan hedefli phishing saldırılarına yol açabilir
    • Bu saldırılar, mağdurları sahte iş teklifleriyle kandırabilir veya ek kişisel ve finansal bilgileri açıklamaya zorlayabilir
    • Ancak bu, ESHYFT verilerinin veya kullanıcı verilerinin fiilen dolandırıcılık ya da kötüye kullanım için kullanıldığı anlamına gelmiyor
  • HealthTech şirketleri ve sağlık yazılımı sağlayıcıları şu önlemleri değerlendirmeli
    • Hassas veriler için zorunlu şifreleme protokolleri
    • İç altyapı zafiyetlerini tespit etmeye yönelik düzenli güvenlik denetimleri
    • Hassas verilerin depolanmasını sınırlama ve mümkün olduğunda anonimleştirme
    • Artık kullanılmayan veriler için son kullanma tarihi belirleme
    • Belgeleri hassasiyet düzeyine göre ayrı depolama
  • Bu vakada kullanıcı dosyalarının hassasiyet temelinde ayrılmadan tek bir klasöre yüklenmiş olduğu görülüyor
    • Kullanıcı profil görselleri düşük hassasiyetli olabilir
    • Tıbbi muayene kanıtları yüksek hassasiyetli olabilir
    • Teorik olarak bu iki belge türü aynı klasörde tutulmamalı
  • Hassas verilerin ayrıştırılması ve şifrelenmesi, kazara sızıntı veya kötü niyetli saldırı durumunda ek koruma katmanları sağlar
  • Hassas bilgi veya belgelere erişebilen uygulamalarda MFA gerekli
    • Kullanıcı adı ve parola gibi kimlik bilgileri ele geçirilse bile uygulamaya veya kullanıcı paneline doğrudan erişimi zorlaştırır
  • HealthTech şirketlerinin veri ihlali müdahale planı ve olası güvenlik olaylarını bildirmek için özel bir iletişim kanalı bulundurması gerekiyor
    • Yalnızca müşteri desteği veya satış iletişim noktaları bulunursa, veri ihlali durumunda harekete geçmesi gereken kilit kişilere iletim gecikebilir
    • Hassas veriler kamuya açık şekilde sızdığında azaltma ve kurtarma sürecindeki gecikmeler kritik olabilir
  • Veri olayının ardından, doğrudan etkilenmiş olabilecek kullanıcılara zamanında ve sorumlu bir bildirim yapılmalı
  • Kullanıcılara, ilgili uygulama veya hizmetle bağlantılı phishing girişimlerini nasıl tanıyacakları konusunda rehberlik edilmeli
  • Bu durum, Shiftster LLC dba ESHYFT, yüklenicileri veya iştiraklerinin yasa dışı bir eylemde bulunduğu anlamına gelmez; ayrıca kurum içi verilerin veya kullanıcı verilerinin yakın bir tehlike altında olduğu iddiası da değildir

İlgili okumalar

1 yorum

 
GN⁺ 2025-03-14
Hacker News yorumları

  • Geçenlerde bu şirketin iş teklif etmeden önce kredi raporuna bakarak kişinin ne kadar borcu olduğunu, yani ne kadar çaresiz olduğunu değerlendirdiğini ve sonra bu bilgiyi kullanarak teklif edilen saatlik ücreti aşağı çektiğini duydum.
    Bu sızıntı yüzünden başlarına bir iş gelirse, daha fazlasını bile hak ediyor gibi görünüyorlar.

    • Kaynağını hatırlamıyorum ama “hemşireler için Uber” benzeri hizmetleri ele alan bir podcast dinlemiştim; hemşirelerin aleyhine her türlü şeyi yaptıklarını söylüyordu.
      Bir çağrı aldığınızda konum izleme uygulamasını açmanız gerekiyor; trafiğe takılsanız ya da telefon sinyali kesilse bile ceza puanı birikiyor ve bu ceza puanları ücretin düşmesine yol açıyor.
      Zaten hasta sayısının çok fazla, yardımcı personelin yetersiz olduğu ve 12 saatlik vardiyadan sonra bile kayıt tutmak zorunda kalınan kötü hemşirelik koşullarını silaha dönüştürmek gibi. Eşim hemşire olduğu için bu bana daha gerçekçi geliyor.
    • Hemşire ücretlerinin baskılanmasını ele alan sunum burada: https://pluralistic.net/2025/02/26/ursula-franklin/
    • Hemşire açığı bu kadar ciddiyken hemşirelerin neden böyle hizmetleri kullandığını merak ediyorum.
      Özellikle deneyimli bir hemşireyseniz ücreti kıran berbat bir uygulamayı kullanmak için hiçbir neden yok; neredeyse her sağlık kuruluşunda hemen işe alınabilmeniz gerekir ve RN iseniz uzaktan sağlık hizmetleri seçenekleri de geniş görünüyor.
    • Hemşire ücretlerini tahmin etme yöntemi olarak berbat görünüyor.
      Kişinin eşi olabilir, ebeveynleri kredi kartı borcunu ödüyor olabilir, kredi notu kötü olan biri bunu pek umursamıyor olabilir ya da aileden parası olabilir.
      Borcu az olsa da işe çaresizce ihtiyaç duyabilir; bunun gerçekten işe yarayıp yaramadığını merak ediyorum.

  • Gizlilik politikasının Data Security bölümünde, toplanan ve saklanan bilgilerin bütünlüğünü ve güvenliğini artırmak için fiziksel, idari ve teknik koruma önlemleri kullandıkları; ancak hiçbir güvenliğin kusursuz ya da sızılmaz olmadığı ve sızıntı, erişim, ifşa, değiştirme veya imhaya karşı garanti vermedikleri yazıyor.
    Özellikle bu hizmetin HIPAA kapsamındaki korunan sağlık bilgilerini saklamak veya korumak için tasarlanmadığını söylüyorlar; ama “Bunu HIPAA uyumlu bir sistem olarak yapmadık, üzgünüz” demekle sorumluluğun ortadan kalkıp kalkmayacağını bilmiyorum.
    0: https://eshyft.com/wp-content/uploads/2019/06/ESHYFT-Privacy...

    • HIPAA, sağlık hizmeti sağlayıcılarının verilerine değil, hasta verilerine uygulanır.
      Makalede, hemşirelerin işe gelmeme veya hastalık izni gerekçelerini kanıtlamak için tanı, reçete ve tedavi bilgileri içeren tıbbi belgeleri uygulamaya yüklediği görülüyor; bunun korunan sağlık bilgisi sayılabileceği belirtiliyor.
      Bu şirketin HIPAA kapsamına girip girmemesi, bir covered entity ya da business associate olup olmamasına bağlı; gizlilik politikasına bakınca Business Associate Agreement yapmış olma ihtimalleri düşük görünüyor.
      Ek olarak HIPAA’nın kendisi de güvenlik standardı olarak ideal değil; büyük şirketler Gmail’in HIPAA uyumlu olduğu gerekçesiyle büyük miktarda korunan sağlık bilgisini oradan gönderip alabiliyor.
      0: https://www.hhs.gov/hipaa/for-professionals/covered-entities...
    • HIPAA yalnızca covered entity denen belirli taraflara uygulanır.
      Kabaca sigorta kabul eden sağlık hizmeti sağlayıcıları veya sigorta şirketleri buna girer; sigorta kabul etmeyen sağlık hizmeti sağlayıcılarının HIPAA’ya uyması gerekmez.
      Burada ESHYFT yalnızca iş gücü sağlayan bir şirket gibi göründüğünden HIPAA ile doğrudan ilgili görünmüyor; personel takviyesi hizmeti veren büyük danışmanlık şirketlerinden pek farklı değil.
    • HIPAA, uyduruk kullanım şartlarına göre belirlenmez; ya uygulanır ya da uygulanmaz.
      Ancak kapsamı beklenenden daha dar ve cezaları da zayıf. Facebook’un izleme pikseli gibi şeyler kurdurarak kişisel sağlık verilerini çekip alması durumunda bile bunun yasa ihlali olmama ihtimali yüksek; muhtemelen ancak sızıntıyı yaratan tarafa talepte bulunulabilir.
      Bu olayda da HIPAA ile zararı sınırlamak kolay görünmüyor. Bir doktorun hasta verilerini Google Drive’a yükleyip bunların Google’ın taşeronları veya bir hack yüzünden sızmasına daha çok benziyor.
      ESHYFT hizmeti için HIPAA’nın koruduğu veriler ne gerekli ne de faydalı olduğundan, HIPAA ihlali iddiasıyla kolayca kazanmak zor görünüyor; ancak başka tazminat sorumlulukları hâlâ mümkün.
    • Doğrudan sağlık hizmeti sağlayıcısı değillerse böyle bir sorumsuzluk savunması işe yarayabilir. Bu, bunu desteklediğim anlamına gelmiyor.

  • Sağlık çalışanlarının sahip olduğu otorite yüzünden kafa karıştırıcı olabilir ama doktorlara veya hastanelere Sosyal Güvenlik numaranızı kesinlikle vermemek daha iyi.
    Buna ihtiyaçları yok. Kimlik kontrolü de kimliği taramak veya fotoğrafını çekmek anlamına gelmez.
    Doktorlar, hastaneler ve klinikler bilgi güvenliği açısından en kötü gruplardan biridir; eğitimleri de neredeyse yoktur, hata yaptıklarında cezalar hafiftir ve bu tür bilgiler sonuçta daha çok faturayı ödemediğinizde sizi takip etmek için kullanılır.

    • ABD’de HIPAA fiilen en güçlü mahremiyet koruma yasası olduğu için, bilgi sızıntısı olduğunda sağlık hizmeti sağlayıcıları kadar ağır ceza alabilecek grup da az görünüyor.
    • Sosyal Güvenlik numarası olmadan randevu vermeyeceklerini söylerlerse ne yapmak gerekir, merak ediyorum.

  • S3 bucket’ın ne kadar eski olduğunu merak ediyorum. AWS bir noktadan itibaren yeni S3 bucket’ları varsayılan olarak özel yapmaya başladı.
    Öyleyse ya eski bir bucket’tır ya da mobil uygulamada/hizmette dosya yükleme/indirme çalışmadığı için pervasızca herkese açık bırakılmış olma ihtimali yüksek.

    • Bir web geliştiricisi web sitesinde varlıkları kullanmak için bunu açmış ve aynı bucket içindeki diğer hassas verileri düşünmemiş olabilir.

  • Başlıkta gerçek şirket adı yerine neden “hemşireler için Uber” yazdıklarını merak ediyorum.

    • Makaleye göre adı ESHYFT. AliExpress’te görebileceğiniz bir elektronik ürün markası gibi geliyor ama kalitesi daha da düşük görünüyor.
    • Yalnızca şirket adından anlaşılamayacak şekilde, bu şirketin ne kadar dandik olduğunu hemen anlatıyor.

  • Geçen hafta Firebase’i suçluyorlardı, bu kez AWS’i mi suçlayacaklar acaba diye düşünüyorum.
    Sabahın 3’ünde arkadaşlara göstermek için alelacele bir şey yaparken uygulanan güvenlik prosedürleri, kişisel olarak tanımlanabilir bilgileri barındıran bir ürüne aynen uygulanmamalı. Temel veri güvenliğini operatörün bizzat hayata geçirmesi gerekir.

    • Temel veri güvenliğini uygulamak gerektiği doğru, ama platform da elinden geldiğince yardımcı olmalı.
      Geliştiriciyi yalnızca varsayılanları izlese bile güvenli olacak bir başarı tuzağına düşürmeli.
      Bu durumda S3 bucket’ları varsayılan olarak gizli ve şifreli olmalı; geliştiricinin bunu açıkça kapatması gereken bir yapı olmalı. Şu an böyle olabilir, ama geçmişte değildi.

  • Sağlık sektörü baştan sona bozuk, çevresindeki teknoloji şirketleri de beceriksiz görünüyor.
    Ucuz, şirket mülkiyetindeki hastaneler hemşireleri W2 çalışanı olarak işe almak istemediği için hemşirelik işi Uber’leşiyor; hastanelerin cimriliği de böyle berbat uygulama seçimlerine yol açmış olabilir.
    Onay veren yöneticiye komisyon gitmiş de olabilir; ESHYFT’in bu olay yüzünden iflas etmesi gerekir, ama gerçekte hiçbir şey olmayacak gibi görünmesi daha olası.

    • İflas tek başına yetmez; cezai ihmal de sorgulanmalı.
      Yöneticiler hapse girmediği sürece böyle şeyler devam edecek. Muhtemelen birileri bilgi güvenliğine yatırım yapmadan bu işten büyük para kazandı.
      Tasarruf edilen maliyetin bedelini kârla ilgisi olmayan insanlar ödedi; birkaç yıl sonra o yöneticiler başarılı şirket nasıl kurulur diye konferanslara çıkabilir.
      Bu tür davranışların hiçbir sonucu olmazsa, kamunun özel çıkarların bedelini ödemesi sürer.
    • Bu tür uygulamalar bir ölçüde bağımsız hastanelerin ve sağlık hizmeti sağlayıcılarının ayakta kalmasını sağlıyor.
      Büyük sağlık sistemlerinin kendi float hemşire havuzları veya kurum içi teklif sistemleri var.
      İzin ve açık pozisyon karşılama sistemlerine erişim sağlayabilmek, büyük sistemlere satılırken ikna edici noktalardan biri de oluyor.
    • Komisyon meselesi özellikle merakımı çekiyor. Böyle bir olasılığa katılıyorum, ama bunu pratikte nasıl kökünden söküp atabileceğimizi bilmiyorum.
      Yanlışı bilenler zaten bundan faydalanan kişiler olduğu için düzeltmeye yönelik neredeyse hiç teşvik yok.

  • Hâlâ bu tür şeylerde harekete geçebilecek işleyen düzenleyici kurumlar varmış gibi mi yapıyoruz, diye düşünüyorum.

    • Böyle şeyleri ortaya çıkarmak için en çok çalışan kişiyi hemen kovunca hükümet gerçekten daha verimli hâle geliyor.

  • Bu işlerin neden sürekli tekrarlandığını anlamıyorum. Her ay açık bir S3 bucket üzerinden yeni bir sızıntı çıkıyor gibi.

    • Olgunlaşmamış sistemlere sahip yeni şirketler, eski şirketlerde genç bir geliştiricinin kendi alanında ayrı yürüttüğü yan işler, kötü varsayılan ayarlar gibi nedenler olabilir.
      Daha önemlisi, büyük ölçekte sürekli tarama yapmaya güçlü motivasyonu olan çok sayıda insanın bulunması. Bugünlerde GitHub’ı, IP’leri, alan adlarını ve genel olarak interneti taramak çok kolay; “yanlış S3 yapılandırması” tespiti de herkesin kullanabileceği script düzeyinde, ileri programlama becerisi gerektirmiyor.
    • S3’ün ve AWS’in büyük kısmının tasarımı berbat; yeni bir proje ayağa kaldırırken çalışır gibi görünen bir erişim politikası arayıp kopyalıyorsunuz.
      O politika daha sonra üretim ortamına uygun olmayabiliyor. Bunun doğru olduğunu söylemiyorum; işlerin gerçekte böyle geliştiğini söylüyorum.

  • Altyapıyı kuran kişi bunu aşırı yorgunken inşa ettiyse ve sabah bu olayı görerek uyandıysa gerçekten çok üzücü bir durum.