Biri bizimki gibi bir hizmet üzerinden şirket kurduğunda; bir pasaport taraması, bir adres kanıtı ve zamanla, bir tüzel kişiliği kimin kontrol ettiğini topluca anlatan bir dizi kurumsal belge teslim eder. Bu paket, tipik bir SaaS uygulamasının sakladığı şeylerin çoğundan daha hassastır.
Bu yazı, onu nasıl korumayı düşündüğümüzü anlatıyor. Bilinçli olarak temenni değil, pratik.
İşe sınırı doğru yere çizerek başlayın
Çoğu uygulamadaki içgüdü, çevreyi güvenlik sınırı saymaktır: girişi geç, uygulamanın sana gösterdiğini gör.
Belge iş akışları için bu yanlış sınırdır. Doğru sınır belgenin kendisidir. Bir kurumsal belgenin her okunması, ister müşteriden ister personelden ister başka bir sistemden gelsin, yetkilendirilen ve kaydedilen bir olay olmalıdır.
Bunu kabul ettiğinizde birkaç tasarım kararı ardından gelir.
Saklama: şifreleyin, ama bunun ne kazandırdığı konusunda net olun
"Beklemede şifreli" ifadesi tek başına neredeyse anlamsızdır; çünkü bir sunucudaki tam disk şifrelemesinden, yönetilen anahtarla nesne bazlı şifrelemeye kadar her şeyi anlatabilir.
Tam disk şifrelemesi tek bir şeye karşı korur: birinin diski fiziksel olarak ele geçirmesine. Bu gerçek bir tehdittir ve en olası olanı değildir. Daha olası hata, ele geçirilmiş bir uygulama hesabı veya yanlış yapılandırılmış bir depolama kovasıdır; disk şifrelemesi ikisi için de hiçbir şey yapmaz — uygulama düz metni gayet mutlu bir şekilde okur.
Yapmaya değer olanlar:
- Nesneleri tek tek, anahtarları uygulama dışında yönetilen şekilde şifreleyin.
- Anahtar yönetimi sınırını depolama sınırından ayrı tutun; böylece bir depolama ihlali otomatik olarak bir anahtar ihlali olmaz.
- Anahtar kullanımını loglayın. Şifre çözme işlemlerindeki ani artış, istediğiniz bir sinyaldir.
Teslim: kalıcı bağlantı olmasın
Bir belgenin sızmasının en yaygın yolu bir ihlal değildir. Bir bağlantıdır.
Bir belgeye kalıcı olarak çözümlenen bir URL, kılık değiştirmiş bir hamiline yazılı belgedir. İletilir, destek talebine yapıştırılır, tarayıcı geçmişine kaydedilir ve kimsenin düşünmediği bir yere eşitlenir.
Denetimli teslim şu demektir:
- Kalıcı genel URL yok. Erişim, erişim anında yetkilendirilen bir talep üzerinden gider.
- Süre sonu. Her geçici bağlantının ömrü kısadır ve tek amaçlıdır.
- Hesap başına değil, belge başına açık izin. Müşteri olmak, hesapla ilişkili her belgeye hak sahibi olmak demek değildir.
- Kaydedilen erişim. Kim neyi ne zaman açtı.
Son madde insanların atladığı maddedir ve bir olaydan sonra en çok önem taşıyandır. Erişim logları olmadan, sorulacak tek soruyu yanıtlayamazsınız: gerçekte ne açığa çıktı?
Roller: insanların ne olduğunu değil, ne yaptığını modelleyin
Rol tabanlı erişim denetimi, uygulaması kolay olduğu için bir avuç kaba role kaymaya eğilimlidir — yönetici, personel, müşteri. Sonuç olarak çoğu personel hesabı, herhangi bir tek görevin gerektirdiğinden çok daha fazla erişim biriktirir.
Daha faydalı bir model görevlerden başlar. Bir kimlik belgesini inceleyen kişinin, üzerinde çalıştığı dosya için o belgeyi görmesi gerekir. Arşivde gezinmesi gerekmez. Erişimi koleksiyona değil dosyaya sınırlamak, muazzam miktarda kalıcı riski ortadan kaldırır.
Uygulanmaya değer iki kural:
- Erişim, bir hesabın kalıcı özelliği olarak değil, bir amaç ve bir kapsam için verilir.
- Yükseltilmiş erişim varsayılan olarak geçicidir ve kimsenin geri almayı hatırlamasına gerek kalmadan sona erer.
Saklama süresi: silmek tasarımın parçasıdır
Her şeyi tutmaya doğru güçlü bir çekim vardır. Depolama ucuzdur ve silinen veri arada bir faydalı çıkar.
Ama artık elinizde olmayan belgeler açığa çıkamaz. Saklama süresi yalnızca bir uyum yükümlülüğü değil, bir güvenlik kontrolüdür.
Bu, belge türü başına gerçekte ne kadar süreyle ihtiyaç duyduğunuza karar vermek — toplanma amacına ve geçerli kayıt tutma yükümlülüğüne dayanarak — ve ardından silmeyi, birinin çalıştırmayı hatırladığı periyodik bir temizlik yerine otomatik bir süreç olarak uygulamak demektir.
Yedekler: korumayı unuttuğunuz kopya
Yedekler sıklıkla en zayıf halkadır; çünkü geri getirilebilirlik için tasarlanırlar ve geri getirilebilirlik, kısıtlı erişimin tam tersidir.
Dürüstçe yanıtlanmaya değer sorular:
- Yedekler, üretimden farklı bir anahtarla mı şifreleniyor?
- Kim geri yükleme yapabilir ve bu işlem loglanıyor mu?
- Saklama politikası yedekler için de geçerli mi, yoksa silinen belgeler orada süresiz mi kalıyor?
- Geri yükleme gerçekten test edildi mi, yoksa çalıştığı varsayılıyor mu?
Hiç geri yüklemediğiniz bir yedek, bir kurtarma planı değil, bir varsayımdır.
Kurtarma: sıkıcı kısımların provasını yapın
Felaket kurtarma planlaması dramatik senaryoya odaklanma — bir bölge çöker — ve çok daha olası olan sıradan senaryoyu atlama eğilimindedir: kötü bir dağıtım bir tabloyu bozar ya da biri yanlış kayıtları siler.
Faydalı egzersiz, sıradan durumda ne olacağını somut olarak yazmaktır. Sorun ne kadar sürede fark edilir? Geri yükleme kararı nasıl ve kim tarafından verilir? Bu süreçte ne kadar veri kaybedilir? Müşterilere ne, ne zaman söylenir?
Bu soruların bir yerde yazılı cevabı yoksa, kurtarma planı bir plan değil, bir şemadır.
Bunun Dorsko'daki yeri
Dorsko'nun yayındaki platformları bugün kurumsal belgeleri işliyor ve burada anlatılan kontroller, tasarımda hedeflediklerimiz: iletimde ve beklemede şifreleme, okumaları loglanan rol tabanlı erişim, açık bağlantılar yerine denetimli teslim, tanımlı saklama süreleri ve yedekleme-kurtarma prosedürleri.
Yukarıda anlatılanların bir kısmı — özellikle depolamadan ayrılmış anahtar yönetimi ve ölçekte şifreli yedek rotasyonu — bugün üretimde çalışan bir şey değil, bulut altyapı yol haritasının parçası. Bu sitede baştan sona hangisinin hangisi olduğu konusunda dikkatli olmaya çalıştık.