Gündelik Mesajlardan Sistem Güvenliğine
“Kargonuz teslim edilemedi, şu bağlantıya tıklayın” diyen bir mesaj aldığınızı düşünün. Beklediğiniz bir teslimat varsa mesaj inandırıcı gelebilir; aynı yöntem banka, ödeme sağlayıcısı veya ekip arkadaşı adına da kullanılabilir. Siber tehditlere karşı korunma, bu temasları tanımayı hesap, uygulama ve yedek güvenliğiyle birleştirmeyi gerektirir.
Bu rehber, küçük ekiplerin uygulayabileceği önlemlere odaklanır: mesajları bağımsız kanaldan doğrulamak, kritik hesapları korumak, yamaları riskle önceliklendirmek ve geri yüklenebilir yedekler hazırlamak. SMTP güvenliği, oturum çerezleri ve izleme gibi teknik kontrollerin neyi sağladığını ve hangi sorunları tek başına çözmediğini de ele alır.
Genişleyen Altyapıda Riski Görünür Kılmak
Bulut servisleri, SaaS hesapları, API’ler, mobil uygulamalar ve uzaktan bağlanan cihazlar farklı erişim noktaları oluşturur. Daha fazla bileşen kullanmak tek başına ihlal yaşanacağı anlamına gelmez; ancak her bileşenin sahibi, güncellemesi, erişim yetkisi ve kaydı yönetilmelidir. Kullanılmayan bir entegrasyon veya unutulmuş yönetici hesabı, bu envanterde kolayca gözden kaçabilir.
Önce hangi sistemin hangi veri ve hizmete eriştiğini çıkarın. Açıkta bırakılmış API anahtarlarını, gereksiz izinleri, güvensiz varsayılan ayarları ve destek süresi dolmuş yazılımları belirleyin. Otomasyonları kapatmak yerine yetkilerini görevleriyle sınırlayın; kullanılmayan entegrasyonları ve kimlik bilgilerini kaldırın. Her bulguya bir sorumlu ve riskine uygun düzeltme tarihi atayın.
Kimlik Avı Mesajlarını Doğrulamak
Gönderenin yalnızca görünen adına değil tam adresine ve alan adına bakın. Benzer harfler, beklenmedik ekler ve acele para/parola talepleri inceleme gerektirir. Ancak düzgün yazılmış bir mesaj veya tanıdık adres güvenilirlik kanıtı değildir; gerçek hesap ele geçirilmiş olabilir. İsteği mesajdaki bağlantı ya da telefonla değil, bilinen yer imi, uygulama veya bağımsız iletişim kanalı üzerinden doğrulayın.
Gönderen Doğrulaması ve Taşıma Güvenliği
SPF ve DKIM alan adı doğrulamasına, DMARC ise hizalama ve başarısız doğrulamaların nasıl ele alınacağına yardımcı olur; benzer alan adları veya ele geçirilmiş gerçek hesaplarla yapılan saldırıları tek başına engellemez. MTA-STS, TLS-RPT ve DANE/TLSA ile SMTP güvenliği farklı bir katmandır: MTA-STS, enforce modundaki bir politikaya uyan göndericilerde TLS ve sunucu sertifikası doğrulamasını zorunlu kılar; DANE/TLSA doğrulanmış DNSSEC kayıtlarıyla taşıma güvenliğini destekler. TLS-RPT ise sorunları raporlar, şifreleme sağlamaz. Bunlar uçtan uca mesaj şifrelemesi değildir ve mesaj içeriğinin güvenilir olduğunu kanıtlamaz.
Şüpheli İçeriği Güvenli Biçimde İncelemek
Zararlı ek ve bağlantı filtreleri, e-posta güvenlik servisinin yalıtılmış analiz ortamı ve kolay bir bildirim kanalı birlikte kullanılabilir. Kullanıcıdan şüpheli bağlantıyı kendi cihazında deneyerek kontrol etmesini istemeyin. Gizli belge veya erişim token’ı taşıyan URL’leri herkese açık tarama servislerine yüklemeyin; kurumun onaylı analiz sürecini kullanın. Filtrelerin kaçırabileceği mesajlar için ekip üyelerinin nasıl bildirim yapacağını önceden belirleyin.
Web Uygulamasını ve Oturumları Korumak
Uygulama, eklenti, çerçeve ve işletim sistemi güncellemelerini envantere bağlayın. Rutin bir test ve dağıtım takvimi oluşturun; aktif olarak istismar edilen veya internete açık kritik bileşenleri etkileyen zafiyetleri sıradaki rutin tarihe bırakmayın. Üretici duyuruları ve CISA’nın bilinen istismar edilen zafiyetler kataloğu önceliklendirmeye yardımcı olabilir. Güncellemenin uygulanmasını, işlevini ve gerektiğinde sürümle uyumlu geri dönüş yolunu doğrulayın.
Sertifika Yenilemesini İzlemek
Süresi dolan veya yanlış alan adı için sunulan sertifika bağlantı hatalarına ve kesintiye yol açabilir. Yenilemeyi otomatikleştirirken dışarıdan görünen sertifikanın gerçekten yenilendiğini de izleyin; yalnızca görevin çalışmış görünmesi yeterli değildir. SSL sertifika yenileme ve uyarı düzeni bunun planlanmasına yardımcı olabilir. Geçerli TLS sertifikası, uygulamanın açık içermediğini veya bir mesajın güvenilir olduğunu göstermez.
Oturum Çerezlerinin Ayrı Görevleri
SameSite, çerezin siteler arası isteklere eklenmesini sınırlar ve bazı CSRF saldırılarını azaltabilir; çerez hırsızlığını genel olarak önleyen bir mekanizma değildir. Strict bazı dış bağlantı ve giriş akışlarını bozabilir; Lax güvenli yöntem kullanan üst düzey gezinmelere izin verir. None gerekiyorsa Secure da gerekir. Secure çerezi HTTPS aktarımıyla sınırlar; HttpOnly JavaScript’in çerez değerini okumasını engeller, fakat tarayıcının isteklerde göndermesini durdurmaz. Uygun CSRF token/origin kontrolleri ve XSS önlemleri ayrıca gerekir. SameSite, Secure ve HttpOnly rehberindeki ayarları gerçek oturum ve üçüncü taraf giriş akışlarınızla test edin.
Gereksiz uçları kapatın; yönetici işlevlerini güçlü kimlik doğrulama, görev bazlı yetki ve uygun ağ kısıtlarıyla koruyun. Panelin adresini değiştirmek keşif gürültüsünü azaltabilir, ancak erişim kontrolü sağlamaz. İnternete kapalı veya IP ile sınırlı bir panelde de kullanıcı ve işlem yetkilendirmesi gerekir. Yönetici girişleri ile yetki değişikliklerini denetlenebilir şekilde kaydedin.
Fidye Yazılımına Karşı Yedek ve Kurtarma
Fidye yazılımı, erişebildiği canlı veriyle birlikte bağlı ve yazılabilir yedekleri de etkileyebilir. Ayrı erişim kimlikleri, çevrimdışı veya yalıtılmış kopyalar ve değişmezlik bu riske farklı yönlerden karşılık verir. S3 Object Lock ile yedek korumasında kilit tüm dosya adına değil belirli nesne sürümüne uygulanır ve Versioning gerektirir. Compliance modunda hesap kullanıcıları korunan sürümü süre dolmadan silemez veya koruma süresini kısaltamaz; governance modunda özel bypass yetkisi ve isteğiyle koruma aşılabilir. Basit silme isteği bir delete marker oluşturabilir; korunan sürüm varlığını sürdürür. Geri dönüş için doğru sürüme, erişim izinlerine ve şifreleme anahtarlarına ulaşabilmek gerekir. Değişmez yedek, veri sızdırma tehdidini ortadan kaldırmaz.
Üretim verisini silmeden, yedeği yalıtılmış bir kurtarma ortamına yükleyin; üretim yazmaları, e-posta, ödeme ve zamanlanmış dış işler kapalı olsun. Dosyayı açmanın yanında veri tutarlılığını, uygulamanın çalışmasını ve ihtiyaç duyulan anahtarları doğrulayın. Aylık küçük prova bir başlangıç örneğidir; sıklığı değişikliklere, kabul edilebilir veri kaybına ve kesinti süresine göre belirleyin. Yedek yönetim hesaplarını MFA ile koruyun, görevleri ayırın ve desteklenen kritik işlemler için ikinci onayı değerlendirin.
Altyapı, Loglar ve Alarm Sorumluluğu
Gecikme, hata kodları veya giriş denemelerindeki değişiklikler araştırma sinyali olabilir; tek başına saldırı kanıtı değildir. Başarısız yönetici girişleri, yeni anahtarlar, yetki değişiklikleri ve beklenmedik veri erişimleri gibi olayları normal davranışla karşılaştırın. Ülke/ASN değişimini VPN ve seyahat bağlamıyla değerlendirin. Her alarma sorumlu, inceleme adımı ve gerekiyorsa üst sorumluya bildirim yolu ekleyin; kayıtların gerçekten toplandığını ve alarm sisteminin çalıştığını da izleyin. Loglarda parola veya erişim token’ı tutmayın.
Size ait veya incelemeye yetkili olduğunuz sistemlerin açık portlarını ve yönetim arayüzlerini envanterle karşılaştırın. Gereksiz servisleri kapatın; uzaktan yönetim için uygun ağ sınırı, MFA ve desteklenen güçlü kimlik doğrulama kullanın. SSH anahtarları da korunmalı, görevle sınırlandırılmalı ve gerektiğinde iptal edilmelidir. Çalışan cihazlarının işletim sistemi, tarayıcı ve eklentilerini güncel tutmak da bu erişim zincirinin parçasıdır.
Parola, MFA ve Hesap Kurtarma
Her hesap için benzersiz ve uzun parola kullanın; parola yöneticisi güçlü rastgele parolaları saklamayı kolaylaştırır. Parola tümcesi seçiyorsanız kişisel bilgiler, bilinen alıntılar ve tahmin edilebilir kelime dizilerinden kaçının. E-posta, bulut konsolu, yönetim ve yedek hesaplarında MFA’yı etkinleştirin. MFA ele geçirilmiş bir parolanın kullanımını zorlaştırabilir; uygulamanın kendisinin ele geçirilmesini veya aktif oturumun çalınmasını tek başına engellemez.
Have I Been Pwned gibi servislerde adresinizin görünmesi, bir veri kümesinde bulunduğuna işaret eder; mevcut parolanızın ele geçirildiğini tek başına kanıtlamaz. Hangi verilerin açığa çıktığını inceleyin; sızdığı bilinen veya yeniden kullanılan parolaları ilgili tüm hesaplarda değiştirin ve şüpheli oturumları değerlendirin. Sonuç çıkmaması da güvenlik garantisi değildir. OWASP Top 10, web uygulaması risk kategorileri için farkındalık kaynağıdır; belirli bir yazılımın tüm bilinen açıklarını listeleyen tarayıcı veya eksiksiz denetim değildir.
Desteklenen hesaplarda WebAuthn tabanlı passkey veya güvenlik anahtarı gibi kimlik avına dayanıklı yöntemleri değerlendirin. SMS ve uygulamanın ürettiği tek kullanımlık kodlar ek koruma sağlar, fakat sahte giriş sayfasında kullanıcıdan alınarak aktarılabilir; TOTP kodu kimlik avına dayanıklı sayılmaz. Kurtarma yollarını, yedek doğrulayıcıları ve iptal işlemlerini de koruyun. Önceki NIST dijital kimlik rehberinin devamı olan güncel SP 800-63B-4 rehberi parola, doğrulayıcı ve kimlik avı direncinin ayrı rollerini açıklar.
Kod, Bağımlılık ve Gizli Anahtar Yönetimi
Girdilerin türünü, uzunluğunu ve iş kuralına uygunluğunu doğrulayın; SQL için parametreli sorgu, HTML çıktısı için bağlama uygun kodlama ve her işlem için yetkilendirme uygulayın. Dosya yüklemelerinde uzantı, boyut ve gerçek içeriği birlikte değerlendirin; istemcinin bildirdiği MIME türüne tek başına güvenmeyin. Dosyaları sunucunun ürettiği rastgele dosya adlarıyla, çalıştırılamayacak ve uygun erişim denetimi bulunan alanda saklayın. Kullanıcıya gereksiz iç ayrıntı göstermeyen hatalar üretirken, inceleme için gerekli teknik bilgiyi korumalı loglarda tutun.
Gizli anahtarları kaynak kod deposunda tutmayın; erişimi kısıtlı bir secret yöneticisi ve destekleniyorsa kısa ömürlü servis kimlikleri kullanın. Bir değeri ortam değişkenine koymak onu kendiliğinden güvenli veya kısa ömürlü yapmaz; sona erme ve iptal mekanizması kimlik sağlayıcısında uygulanmalıdır. Bağımlılık sürümlerini ve kaynaklarını izleyin, tarama sonuçlarını değerlendirin ve güncellemeleri doğrulayın. Sürümü sabitlemek tek başına güvenlik sağlamaz; bilinen zafiyeti de sabitleyebilir.
Erişim Sorumluluğu ve Olay Bildirimi
Ortak insan hesapları yerine kişiye ait hesaplar kullanın; servis kimliklerini insan erişiminden ayırın. Geçici yetkinin bitişini belirleyin, görev değişikliği veya ayrılışta erişimi gecikmeden kaldırın. Periyodik inceleme bunlara ek kontrol sağlar; ayrılan kişinin hesabını bir sonraki aylık incelemeye bırakmayın. Yetki listesinin ve müdahale belgelerinin erişimini de ilgili kişilerle sınırlayın.
Şüpheli bir dosya açıldıysa veya bir sayfaya kimlik bilgisi girildiyse bunu belirlenmiş olay sorumlusuna hızla bildirin. Mesajı, zamanı ve gözlenen davranışı koruyun; rastgele temizleme veya yeniden kurulumla kanıtları yok etmeyin. Etkilenen sistemleri olay planına göre yalıtın; hesap ve oturum iptallerini güvenilir bir cihazdan koordine edin. Veri sızıntısı ihtimalinde etkilenen veri ve bildirim yükümlülüklerini ayrıca değerlendirin. Amaç kişiyi suçlamak değil, olayın kapsamını anlayıp zararı sınırlamaktır.
Kontrolleri Günlük İşe Yerleştirmek
Yeni entegrasyon açarken erişim sahibini ve gerekli izinleri belirleyin; yeni eklentide destek ve güncelleme durumunu kontrol edin. Kritik işlem isteyen mesajları bağımsız kanaldan doğrulayın. Güvenlik anahtarı kullanırken her girişte kod yazılmaması güvenlik eksikliği değildir; yöntemin ve kurtarma sürecinin doğru kurulduğunu denetleyin. Bu kontrolleri işe alım, dağıtım ve erişim değişikliği akışlarının parçası yapın.
Ödeme, yönetim, dosya yükleme ve anahtar yönetimi gibi yüksek etkili alanlara ek inceleme ve izleme ayırın. Diğer alanlarda da temel yetkilendirme, güncelleme ve kayıt kontrollerini sürdürün; daha düşük öncelik korumasız bırakmak anlamına gelmez. Fazladan hassas veri kaydetmek yerine, hangi olayın hangi karara yardımcı olacağını belirleyin.
Öncelikli Üç Adım
İlk olarak kritik hesaplarda benzersiz kimlik bilgileri, MFA ve güvenilir kurtarma yollarını kontrol edin. İkinci olarak internete açık bileşenlerin ve aktif istismar riski taşıyan güncellemelerin listesini çıkarıp sorumlularını belirleyin. Üçüncü olarak ayrı erişimle korunan yedekten yalıtılmış bir geri yükleme yapın ve sonucu kaydedin. E-posta, çerez, sertifika ve izleme kontrollerini bu temel düzenin devamına yerleştirin.
Her adım için sahibi, tamamlanma tarihi ve başarı ölçütü belli olsun. Örneğin “yedek mevcut” yerine “uygulama ve veri doğrulamasıyla geri yükleme tamamlandı” sonucu arayın. Olay planını masa başı senaryoyla deneyin; kimin karar vereceğini, hangi erişimin iptal edileceğini ve hizmetin ne zaman güvenle geri açılacağını önceden netleştirin.
Siber tehditlere karşı dayanıklılık, önleme ile kurtarmayı birlikte planlamayı gerektirir. Kontrolleri sistem değiştikçe gözden geçirin; bulguları, düzeltmeleri ve tatbikat sonuçlarını izleyin. Böylece güvenlik tek seferlik bir temizlikten, sorumluları ve doğrulama adımları olan sürekli bir işe dönüşür.
