Sağlık Siteleri için HIPAA Web Güvenliği Kontrol Listesi

Göremediğinizi koruyamazsınız. Herhangi bir şeyi sertleştirmeden önce, PHI saklayan, işleyen veya ileten her web bağlantılı sistemi haritalayın. Bu kapsam belirleme çalışması HIPAA'nın Risk Analizi standardı (§164.308(a)(1)) tarafından zorunlu kılınmış olup sonraki her adımın temelini oluşturur.

• Sağlık uygulamanızla ilişkili her genel alan adını, alt alan adını ve API uç noktasını listeleyin.
• PHI kabul eden veya döndüren uç noktaları etiketleyin (hasta portalları, randevu formları, laboratuvar sonuç sayfaları, fatura sayfaları).
• Teknoloji yığınını belgeleyin: web sunucu yazılımı ve sürümü, uygulama çerçevesi, CDN ve üçüncü taraf entegrasyonlar.
• Tüm ortamları (üretim, hazırlama, geliştirme) belirleyin ve hazırlama/geliştirme ortamlarının hiçbir zaman gerçek PHI içermediğini doğrulayın.
• SSL/TLS sonlandırmasının nerede gerçekleştiğini kaydedin — yük dengeleyici, CDN kenarı veya kaynak sunucu — şifrelemenin uçtan uca zorunlu kılındığından emin olun.

Varsayılan bir web sunucusu kurulumu, güvenlik için değil uyumluluk için tasarlanmıştır. Saldırganlar sunucu yazılımını parmak iziyle tespit eder ve bilinen varsayılan davranışları istismar eder. Sunucuyu yalnızca uygulamanızın ihtiyaç duyduğu şeyle sınırlandırmak, saldırı yüzeyini dramatik biçimde azaltır; bu, HIPAA'nın bütünlük ve erişim kontrolüne ilişkin Teknik Güvenceler gereksinimi kapsamında temel bir zorunluluktur.

• Varsayılan içeriği kaldırın: Varsayılan dizin sayfalarını, belgelendirme dizinlerini ve örnek betikleri silin (Apache'de /manual, varsayılan IIS karşılama sayfaları gibi).
• Kullanılmayan modülleri devre dışı bırakın: Apache'de mod_status, mod_info ve mod_userdir'i açıkça gerekmedikçe devre dışı bırakın. Nginx'te kullanılmayan upstream modülleri derleme zamanında kaldırın.
• HTTP yöntemlerini kısıtlayın: Yalnızca GET, POST ve HEAD'e izin verin. API'niz gerektirmedikçe TRACE, OPTIONS, PUT, DELETE ve CONNECT'i açıkça reddledin.
• Server başlığını gizleyin: Sürüm ifşasını önlemek için ServerTokens Prod (Apache) veya server_tokens off (Nginx) ayarlayın.
• X-Powered-By başlığını gizleyin: Arka uç teknolojinizi (PHP, ASP.NET vb.) gizlemek için bu başlığı kaldırın veya yanıltıcı bir değere ayarlayın.
• Dizin listelemeyi kapatın: Dizin içeriklerinin hiçbir zaman açığa çıkmaması için Options -Indexes (Apache) veya autoindex off (Nginx) kullandığınızdan emin olun.
• Web sunucusunu ayrıcalıksız bir kullanıcı olarak çalıştırın: İşlem root olarak çalışmamalıdır. Minimum işletim sistemi izinlerine sahip özel bir hizmet hesabı kullanın.
• İstek boyutunu sınırlayın: Hizmet reddi risklerini azaltmak için LimitRequestBody (Apache) veya client_max_body_size (Nginx) değerini uygulamanızın gerektirdiği minimum değere ayarlayın.
• Bağlantı zaman aşımlarını yapılandırın: Yavaş-loris tarzı saldırılara karşı direnç sağlamak için KeepAliveTimeout ve Timeout değerlerini makul düşük değerlere ayarlayın.
• Sensagraph, açık sunucu başlıklarınızı sürekli tarar ve bilgi ifşası sorunlarını otomatik olarak işaretler.

HIPAA, ePHI'nin iletim sırasında şifrelenmesini açıkça zorunlu kılar (§164.312(e)(1)). TLS bu mekanizmadır; ancak eski protokol sürümlerine veya zayıf şifrelere izin veren yanlış yapılandırılmış bir TLS kurulumu, sahte bir güvenlik hissi yaratır. Modern saldırganlar, oturum trafiğini deşifre etmek veya sürüm düşürme saldırıları gerçekleştirmek için zayıf TLS'den yararlanır.

• TLS 1.2'yi minimum olarak zorunlu kılın: SSL 2.0, SSL 3.0, TLS 1.0 ve TLS 1.1'i sunucu düzeyinde devre dışı bırakın. Bunlar kullanımdan kaldırılmış ve zafiyetlidir (POODLE, BEAST, DROWN).
• TLS 1.3'ü tercih edin: Sunucunuzda ve istemciye yönelik yük dengeleyicide TLS 1.3 desteğini etkinleştirin; varsayılan olarak ileri gizlilik sağlar ve birçok eski el sıkışma güvenlik açığını ortadan kaldırır.
• Güçlü şifre paketleri kullanın: Yalnızca AES-128-GCM, AES-256-GCM ve CHACHA20-POLY1305 gibi AEAD şifrelerine izin verin. RC4, 3DES, DES ile NULL veya EXPORT şifre paketlerini devre dışı bırakın.
• Mükemmel İleri Gizlilik (PFS) uygulayın: Sunucunun özel anahtarının ele geçirilmesinin geçmiş oturumları ifşa etmemesi için ECDHE ve DHE anahtar değişim algoritmalarını tercih edin.
• 2048 bit veya daha büyük RSA anahtarı kullanın (veya EC P-256+): 2048 bitten kısa anahtarlar artık güvenli kabul edilmemektedir.
• TLS sıkıştırmasını devre dışı bırakın: TLS düzeyindeki sıkıştırma, CRIME saldırısına karşı savunmasızdır; kapalı olduğundan emin olun.
• OCSP Zımbalama (Stapling) yapılandırın: Sertifika iptal durumunun istemci IP'sini sertifika otoritelerine sızdırmadan verimli biçimde iletilmesi için sunucunuzda OCSP zımbalamayı etkinleştirin.
• Tüm HTTP trafiğini HTTPS'ye yönlendirin: PHI işleyen her alan adı ve alt alan adı için 80 numaralı porttan 443 numaralı porta 301 kalıcı yönlendirme uygulayın.
• Tam sertifika zincirini doğrulayın: Bazı istemcilerde güven zinciri hatalarını önlemek için ara sertifikaların sunucunun sertifika paketine doğru şekilde dahil edildiğinden emin olun.
• Sensagraph, her taramada TLS protokol sürümlerinizi, şifre paketi gücünüzü ve sertifika zinciri geçerliliğinizi kontrol eder.

HTTP güvenlik başlıkları, hafif ama yüksek etkili bir savunma katmanıdır. Tarayıcılara sayfalarınızı işlerken nasıl davranmaları gerektiğini bildirerek, PHI'yi açığa çıkarabilecek siteler arası betik çalıştırma, tıklama hırsızlığı, MIME koklama ve protokol sürüm düşürme gibi saldırı sınıflarını tamamen engeller. Pek çok HIPAA denetçisi artık teknik güvence değerlendirmelerinin bir parçası olarak başlık yapılandırmasını incelemektedir.

• Strict-Transport-Security (HSTS): Strict-Transport-Security: max-age=31536000; includeSubDomains; preload ayarlayın. Bu, tarayıcıları yalnızca HTTPS kullanmaya zorlar ve SSL soyma saldırılarını önler. Kararlı olduğu onaylandıktan sonra hstspreload.org adresindeki HSTS ön yükleme listesine gönderin.
• Content-Security-Policy (CSP): Betikler, stiller, görseller ve çerçeveler için yalnızca kendi kaynaklarınızı beyaz listeye alan katı bir politika tanımlayın. Content-Security-Policy: default-src 'self' ile başlayın ve yalnızca gerektiğinde genişletin. İhlalleri yakalamak için bir raporlama uç noktası (report-uri veya report-to) kullanın.
• X-Frame-Options: Kullanıcıları PHI'yi kötü amaçlı bir çerçeveye göndermesi için kandırabilecek tıklama hırsızlığı saldırılarını önlemek adına DENY veya SAMEORIGIN olarak ayarlayın.
• X-Content-Type-Options: Betik enjeksiyonuna yol açabilecek MIME koklama davranışını durdurmak için X-Content-Type-Options: nosniff ayarlayın.
• Referrer-Policy: Sorgu dizelerinde PHI içerebilecek hasta URL'lerinin Referer başlığı aracılığıyla üçüncü taraf sitelere sızmasını önlemek için no-referrer veya strict-origin-when-cross-origin olarak ayarlayın.
• Permissions-Policy (eski adıyla Feature-Policy): Uygulamanızın kullanmadığı tarayıcı özelliklerini devre dışı bırakın: Permissions-Policy: geolocation=(), microphone=(), camera=().
• Cross-Origin-Opener-Policy (COOP): Tarama bağlamınızı izole etmek ve Spectre tarzı yan kanal saldırılarını azaltmak için Cross-Origin-Opener-Policy: same-origin ayarlayın.
• Cross-Origin-Resource-Policy (CORP): Çapraz kaynaklı okumaları önlemek için PHI içeren API yanıtlarında Cross-Origin-Resource-Policy: same-origin ayarlayın.
• Gereksiz başlıkları kaldırın: X-Powered-By, X-AspNet-Version ve X-AspNetMvc-Version başlıklarının tüm yanıtlarda bulunmadığından emin olun.
• Sensagraph, her taramada tüm HTTP yanıt başlıklarını denetler ve eksik ya da yanlış yapılandırılmış güvenlik başlıklarını en iyi uygulama temel çizgilerine göre işaretler.

Süresi dolmuş veya iptal edilmiş bir sertifika, şifreli aktarımı bozar ve hastaların güvenilmez bir site işareti olarak yorumladığı tarayıcı uyarılarını tetikler. Daha da kötüsü, kullanıcıları uyarıları atlayarak PHI'yi güvensiz bir bağlantı üzerinden iletmeye zorlayabilir. Sertifika yönetimi, HIPAA denetçilerinin süregelen risk yönetimi programının bir parçası olarak değerlendirdiği operasyonel bir kontroldür.

• Tüm sertifika son kullanma tarihlerini takip edin: Kullanımdaki her sertifikanın — alt alan adlarındakiler, dahili hizmetler ve yük dengeleyiciler dahil — merkezi bir envanterini tutun.
• Yenilemeyi otomatikleştirin: Sertifikaları son kullanma tarihinden en az 30 gün önce yenilemek için ACME tabanlı otomasyon kullanın (örneğin Let's Encrypt ile Certbot veya CA'nızın API'si). Tek süreç olarak manuel yenilemeye güvenmeyin.
• Son kullanma için uyarı kurun: Son kullanma tarihinden 60, 30 ve 7 gün önce izleme uyarıları ayarlayın. 7 gün içinde süresi dolacak bir sertifikayı olay olarak ele alın.
• Yalnızca güvenilir CA'lardan sertifika kullanın: Sertifikaların kamuya açık güvenilir bir Sertifika Otoritesi tarafından verildiğinden emin olun. Kendinden imzalı sertifikalar, hastalara yönelik sistemler için kabul edilemez.
• Güvenliği ihlal edilmiş sertifikaları derhal iptal edin ve değiştirin: Özel bir anahtar herhangi bir şekilde açığa çıkarsa (sunucu ihlali, bir depoya yanlışlıkla gönderim), sertifikayı saatler içinde iptal edin ve anahtarı döndürün.
• SAN'ların tüm sunulan alan adlarıyla eşleştiğini kontrol edin: Konu Alternatif Adları'nın www ve www olmayan varyantlar dahil uygulamanızın yanıt verdiği her ana bilgisayar adını kapsadığını doğrulayın.
• Sensagraph, her taramada sertifika geçerliliğini ve son kullanma tarihini izler; sertifikalar son kullanma tarihine yaklaştığında veya zincir hataları bulunduğunda uyarı verir.

Bilgi ifşası — yazılım sürümlerini, dahili yolları, yığın izlerini veya URL'lerdeki hasta tanımlayıcılarını sızdırmak — saldırganlara ortamınızın bir haritasını verir; PHI açığa çıkarsa HIPAA ihlali teşkil edebilir. Bu adım, uygulamanızın normal ve hata koşullarında kendisi hakkında ifşa ettiği bilgileri en aza indirmeye odaklanır.

• Özel hata sayfaları yapılandırın: Varsayılan 400, 403, 404, 500 hata sayfalarını sunucu, çerçeve veya dosya yolu bilgisi göstermeyen özel sayfalarla değiştirin.
• Üretimdeki yığın izlerini devre dışı bırakın: display_errors = Off (PHP), hata ayıklama modunun devre dışı olduğundan emin olun (Django, Rails, Node) ve istisnaların yalnızca sunucu tarafında günlüğe kaydedildiğinden, hiçbir zaman tarayıcıya işlenmediğinden emin olun.
• PHI için sorgu dizelerini denetleyin: Hasta tanımlayıcılarının, kayıt numaralarının ve randevu kimliklerinin hiçbir zaman düz metin URL parametreleri olarak geçirilmediğinden emin olun; zira bunlar sunucu günlüklerinde, tarayıcı geçmişinde ve Referer başlığında görünür.
• robots.txt'yi güvence altına alın: Hassas yolları (yönetici panelleri, API uç noktaları, hasta veri dizinleri) robots.txt dosyasına listelemeyin — bu dosya kamuya açıktır ve saldırganlar için bir yol haritası işlevi görür.
• Üçüncü taraf betikleri ve analizleri gözden geçirin: Sitenizde bulunan her harici JavaScript etiketi potansiyel bir veri sızıntısıdır. Tüm üçüncü taraf etiketleri denetleyin; analiz araçlarının PHI'yi anonimleştirmek veya dışlamak üzere yapılandırıldığından emin olun.
• CORS'u devre dışı bırakın veya kısıtlayın: API'niz CORS kullanıyorsa yalnızca belirli güvenilir kaynaklara izin verin. PHI döndüren uç noktalarda hiçbir zaman Access-Control-Allow-Origin: * kullanmayın.
• Web kökünden yedek ve geçici dosyaları kaldırın: Genel bir dizinde bırakılan .bak, ~, .swp ve .old gibi dosyalar, kaynak kod veya yapılandırma verilerini açığa çıkarabilir.

HIPAA'nın Erişim Kontrolü standardı (§164.312(a)(1)), yalnızca yetkili kullanıcıların ePHI'ya erişmesini zorunlu kılar. Zayıf kimlik doğrulama, sağlık veri ihlallerinde tutarlı biçimde en başta gelen vektördür. Bu adım, web uygulamasına ve sunucu erişim katmanına özgü kontrollere odaklanır.

• Çok Faktörlü Kimlik Doğrulama (MFA) gerektirin: PHI'ya erişebilen tüm hesaplar için — klinik personel, yönetici kullanıcılar ve üretim erişimi olan geliştiriciler — MFA'yı zorunlu kılın.
• Yalnızca HTTPS oturumu tanımlama bilgileri zorunlu kılın: Oturum tanımlama bilgilerinin hiçbir zaman düz HTTP üzerinden iletilmemesi için tüm oturum çerezlerinde Secure bayrağını ayarlayın.
• Oturum tanımlama bilgilerinde HttpOnly ayarlayın: XSS tabanlı oturum ele geçirmeyi azaltmak için HttpOnly bayrağını ayarlayarak JavaScript'in oturum çerezlerini okumasını engelleyin.
• SameSite çerez özniteliği kullanın: CSRF riskini azaltmak için oturum tanımlama bilgilerinde SameSite=Strict veya SameSite=Lax ayarlayın.
• Hesap kilitleme ve hız sınırlama uygulayın: Belirli sayıda başarısız oturum açma denemesinden sonra hesapları kilitleyin ve kaba kuvvet saldırılarına direnç sağlamak için kimlik doğrulama uç noktalarını hız sınırlamasına tabi tutun.
• Yönetim ve yönetici arayüzlerine IP'ye göre erişimi kısıtlayın: Yönetici panellerini (/admin, /wp-admin, sunucu yönetim portları) bilinen ofis veya VPN IP aralıklarıyla güvenlik duvarı veya ağ katmanında kısıtlayın.
• Parola tabanlı SSH'yi devre dışı bırakın; anahtar tabanlı kimlik doğrulama kullanın: Sunucu erişimi için sshd_config dosyasında PasswordAuthentication yes'i devre dışı bırakın ve SSH anahtar çiftleri gerektirin.
• Veritabanı hesaplarına en az ayrıcalık ilkesini uygulayın: Web uygulamasının veritabanı kullanıcısı, yalnızca gerekli tablolarda SELECT/INSERT/UPDATE iznine sahip olmalıdır — hiçbir zaman tam DBA ayrıcalıklarına sahip olmamalıdır.
• Oturum zaman aşımı uygulayın: HIPAA'nın otomatik oturum kapatma standardıyla (§164.312(a)(2)(iii)) tutarlı bir hareketsizlik süresinden sonra kimliği doğrulanmış oturumları otomatik olarak sonlandırın. 15–30 dakika, sağlık sektöründe yaygın bir ölçüttür.

HIPAA Güvenlik Kuralı, tek seferlik bir onay kutusu değildir — süregelen risk yönetimi gerektirir (§164.308(a)(1)(ii)(A)). Yapılandırma kayması, bağımlılık güncellemeleri ve yeni saldırı teknikleri, bugün sertleştirilen bir sunucunun gelecek ay savunmasız hale gelebileceği anlamına gelir. Sürekli izleme ve titiz belgeleme, bir güvenlik kontrol listesini denetlenebilir bir uyumluluk programına dönüştüren şeydir.

• Düzenli otomatik güvenlik taramaları çalıştırın: Tüm üretim alan adlarına karşı en az haftalık taramalar planlayın ve her dağıtımdan sonra otomatik olarak tarama tetikleyin. Sensagraph, her çalıştırmada TLS yapılandırması, HTTP başlıkları, sertifika durumu ve bilgi ifşası sorunlarını kontrol eden sürekli otomatik tarama sağlar.
• Tüm yapılandırma değişikliklerinin denetim günlüğünü tutun: Sunucu yapılandırması, TLS ayarları, güvenlik duvarı kuralları ve güvenlik başlıklarındaki her değişiklik; bir zaman damgasıyla, değişikliği yapan kişiyle ve nedeniyle birlikte günlüğe kaydedilmelidir. Mümkün olan her yerde sürüm kontrollü altyapı-kod (Terraform, Ansible) kullanın.
• En az yılda bir kez resmi bir risk analizi yapın: Tanımlanan riskleri, olasılıklarını ve etkilerini ile bunları azaltmak için uygulanan kontrolleri belgeleyin. PHI'ya dokunan yeni sistemler veya hizmetler eklediğinizde bu belgeyi güncelleyin.
• Olay müdahale planınızı test edin: TLS sertifikasının sona ermesini, yanlış yapılandırılmış bir başlık aracılığıyla veri açıklanmasını veya bir sunucu bilgi ifşası bulgusunu simüle edin. Ekibinizin olayı tanımlayabildiğini, müdahale edebildiğini ve tanımlı SLA'lar dahilinde belgeleyebildiğini onaylayın.
• Periyodik sızma testleri yapın: PHI işleyen web uygulamasını ve sunucu katmanlarını özellikle hedef alan nitelikli üçüncü taraf sızma testlerini (en az yılda bir veya önemli değişikliklerden sonra) yaptırın.
• Güvenlik politikalarını gözden geçirin ve güncelleyin: Kabul Edilebilir Kullanım Politikası, Parola Politikası ve Olay Müdahale Planı'nın en az yılda bir gözden geçirildiğinden ve mevcut teknik kontrolleri yansıttığından emin olun.
• Tüm bulgular için giderimi takip edin: Bir tarama veya sızma testi tarafından bulunan her güvenlik açığına bir sahip, bir önem derecesi ve bir giderme son tarihi atanmalıdır. Ne zaman düzeltildiğini belgeleyin ve kapatmayı yeniden doğrulayın.
• Dosyada bir İş Ortağı Sözleşmesi (BAA) bulundurun: PHI'ya dokunan hizmeti olan her üçüncü taraf satıcı için (barındırma, CDN, analiz) imzalı bir BAA'nın mevcut olduğundan ve yıllık olarak gözden geçirildiğinden emin olun.