Yüklemeler için istemci tarafı şifreleme vs sunucu tarafı şifreleme

Yüklenen belgeler için şifreleme tercihleri neden önemli

Uygulamanız insanlara dosya yükletiyorsa, yalnızca “belge” saklamıyorsunuz. Genellikle kullanıcının ikinci bir kimliğini saklıyorsunuz: imzalı sözleşmeler, pasaport veya ehliyet fotoğrafları, tıbbi formlar ve laboratuvar sonuçları. Dosyalar küçük olabilir ama onlarla ilişkili riskler öyle değil.

Sızan bir sözleşme yasal ve mali sonuçlar doğurabilir: fiyatlar açığa çıkabilir, imzalar kopyalanabilir ve anlaşmazlıklar çabucak kötüleşir. Çalınan bir kimlik taraması kimlik hırsızlığına ve hesap ele geçirmelerine yol açabilir. Tıbbi belgeler, kullanıcıların beklemediği özel sağlık bilgilerini açığa çıkarabilir. Bir hata yıllarca güveni zedeleyebilir.

Ekipler sıklıkla “şifrelenmiş depolama” derken farklı şeyleri kastediyor. Bazen upload bağlantısının şifrelenmiş (HTTPS) olduğunu kastediyorlar. Bazen dosyanın disk üzerinde şifrelendiğini (at-rest şifreleme) kastediyorlar. Bazen de dosyanın kullanıcının cihazından ayrılmadan önce şifrelendiğini, sunucunun düz metni hiç görmediğini kastediyorlar (istemci tarafı şifreleme). Bunlar birbirinin yerine kullanılamaz. Farklı başarısızlıklara karşı farklı korumalar sağlarlar.

Güvenlik tercihleri günlük kullanılabilirliği ve desteği de şekillendirir. Daha fazla gizlilik daha fazla sürtünme anlamına gelebilir: bir dosyayı görüntülemek için ekstra adımlar, paylaşmanın zorlaşması, sınırlı arama ve önizlemeler, birisi cihazını veya anahtarını kaybettiğinde can sıkıcı kurtarma süreçleri. Daha kolay erişim ise dizinleme, antivirüs taraması, önizlemeler ve parola sıfırlamalarını mümkün kılar; fakat aynı zamanda sunucunuzun (ve onu ele geçirenlerin) görebileceği şeyleri artırır.

Küçük bir klinikte sigorta kimlikleri ve tıbbi PDF’leri yüklediğini hayal edin. Personel doğru dosyayı hızlıca bulmak istiyor, ama klinik aynı zamanda bir yönetici hesabı ele geçirilirse hasarı azaltmak istiyor. “Doğru” model, hangi hatanın en çok zarar vereceğine ve kullanıcıların hangi rahatsızlığa katlanacağına bağlıdır.

Hızlı tanımlar: istemci tarafı vs sunucu tarafı şifreleme

Pratik soru basit: dosya ne zaman şifreleniyor ve kim daha sonra onu deşifre edebiliyor?

Sunucu tarafı şifreleme demek, dosyanın backend’inize okunabilir halde ulaştığı ve sunucunuzun kaydetmeden önce onu şifrelediği anlamına gelir. Buna at-rest şifreleme denir: biri bir diski çalarsa veya bir depolama bucket’ına ham erişim elde ederse, veriyi karışık görür. Sunucunuz gerektiğinde dosyayı yine de deşifre edebilir.

İstemci tarafı şifreleme demek, dosyanın kullanıcı cihazında (tarayıcı veya mobil) yüklemeden önce şifrelendiği anlamına gelir. Sunucunuz yalnızca şifrelenmiş veriyi saklar. Normal çalışmada sunucu, deşifre anahtarına erişmediği sürece belgeyi okuyamaz.

Gerçek ayrım anahtar sahipliğidir:

• Sunucu tarafı şifrelemede anahtarlar backend tarafından yönetilir (çoğunlukla bir anahtar yönetim servisiyle) ve backend dosyaları yetkili kullanıcılar için deşifre eder.
• İstemci tarafı şifrelemede anahtarlar kullanıcıda, kullanıcının cihazında veya istemci tarafı bir sırda tutulur ve backend esasen depolama ve erişim kurallarını uygular.

Her iki modelde de kimlik doğrulama ve izinlere hâlâ ihtiyaç vardır. Şifreleme erişim kontrolünün yerini almaz.

Birçok kişi “uçtan uca şifreleme” ifadesini şöyle tanımlar: dosya gönderenin cihazında şifrelenir, sunucuda şifreli kalır ve yalnızca onaylı alıcının cihazında deşifre edilir. Bu gizliliği artırabilir, ama sunucu tarafı önizleme, tam metin arama, virüs taraması ve kolay kurtarma gibi özellikleri zorlaştırır; yoksa tehdit modelinizi değiştirmeniz gerekir.

Tehdit modelleri: aslında neyi engellemeye çalışıyorsunuz

Şifreleme, hangi riskleri azaltmak istediğiniz net olduğunda yardımcı olur. “Sadece amaçlanan kullanıcı dosyayı okuyabilsin” demek ile “depolama sızdırılırsa zarar azalsın” demek farklı seçimlere götürür.

Sözleşmeler, kimlikler veya tıbbi belgeler saklayan uygulamalar için yaygın tehditler şunlardır:

• Çalınmış veya yeniden kullanılmış parolalar (hesap ele geçirme)
• Destek, yönetici veya yüklenici gibi içerden erişimin olması gerektiğinden daha geniş olması
• Ele geçirilmiş bulut hesabı veya yanlış yapılandırılmış depolama bucket’ı
• Veritabanı veya yedeklerdeki bir hata ya da sızıntı
• Kullanıcının cihazındaki kötü amaçlı yazılım

Ayrıca maruziyetin nerede olabileceğini ayırmak faydalıdır:

• Taşıma sırasında: dosyanın cihazdan sunucuya giderken geçtiği yol
• Dinlenmede: nesne depolama, veritabanı satırları, yedekler, loglar
• Görüntüleme/işleme sırasında: önizlemeler, OCR, arama, dönüşümler

İşte temel fark. Sunucu tarafı şifreleme ile sisteminiz deşifre edebilir, bu yüzden önizleme, tarama ve indeksleme yapabilir. İstemci tarafı şifreleme ile sunucu yalnızca şifrelenmiş veriyi tutar ve kullanıcı anahtarlarına erişmediği sürece içeriği okuyamaz. Bu genellikle sunucu ihlallerinin ve içeriden gelen risklerin etkisini azaltır.

Şifreleme her şeyi durdurmaz. Bir cihaz enfekteyse, kötü yazılım şifrelemeden önce veya deşifre edildikten sonra dosyayı ele geçirebilir. Birisi bir belgeyi görebiliyorsa ekran görüntüsü alabilir, yeniden paylaşabilir veya yazdırabilir.

Hangi model hangi tehdide karşı korur (ve korumaz)

Bu yaklaşımları karşılaştırmanın yararlı bir yolu: herhangi bir noktada kim dosyayı düz metin halinde görebiliyor? Bu cevap ihlal etkisini, içeriden gelen riski ve yedeklerin güvenliğini belirler.

Sunucu tarafı şifreleme ile bir sunucu ihlali hâlâ çok şeyi açığa çıkarabilir. Backend genellikle önizleme oluşturmak, antivirüs taraması çalıştırmak, aramayı desteklemek veya paylaşımı yönetmek için deşifre anahtarlarına (veya anahtarları talep etme yeteneğine) sahiptir. En kötü durumda, hem veri hem anahtar erişimini ele geçiren bir saldırgan her şeyi deşifre edebilir.

İstemci tarafı şifreleme ile altyapınızı ele geçiren bir saldırgan genellikle yalnızca şifrelenmiş blob’ları çalar. Kullanıcı anahtarları yoksa bu blob’lar çok daha az işe yarar.

İçeriden erişim farkın en görünür olduğu yerdir. Sunucu tarafı şifrelemede ayrıcalıklı bir çalışan, bulut yöneticisi veya ele geçirilmiş bir destek hesabı genellikle uygulamayı taklit ederek veya depolamayı sorgulayarak belgelere erişebilir. İstemci tarafı şifrelemede altyapınız dosyaları depolayıp taşıyabilir, ancak anahtarlar sağlanmadıkça bunları okuyamaz.

İstemci tarafı şifreleme, ele geçirilmiş bir cihazı düzeltmez. Kimlik ve tıbbi PDF’ler gibi yüksek riskli yüklemeler için cihaz güvenliği ve hesap koruması, depolama şifrelemesi kadar önemlidir.

Ayrıca maruziyetin “dosya deposu” dışındaki yerlerde olduğunu gözden kaçırmayın. Birçok vaka şu yollardan olur:

• Deşifre edilmiş dosyaları veya anahtarları yakalayan yedekler ve snapshot’lar
• Dosya adlarını, meta verileri veya çıkarılmış metni kaydeden loglar
• Küçük resimler, önizlemeler ve arama dizinleri
• E-postaya, sohbete veya ticket araçlarına yapılan dışa aktarımlar
• Yükleme veya dönüştürme sırasında oluşturulan geçici dosyalar

Kullanıcıların hemen fark edeceği UX ödünleri

En büyük fark matematik değil. Kullanıcıların neleri kolayca yapabildiği ve nelerin zorlaştığıdır.

Sunucu tarafı şifreleme çoğunlukla görünmez hissi verir. Kullanıcı giriş yapar, yükler ve anında önizleme görür. Destek erişimi sıfırlayabilir. Birisi hasta olduğunda yöneticiler genellikle izinleri yeniden atayabilir.

İstemci tarafı şifreleme onboarding ve günlük işi değiştirir. Kullanıcılar daha güçlü bir parola, cihazda saklanan yerel bir anahtar veya ekstra bir açma adımı ile karşılaşabilir. Cihaz değiştirme, tarayıcı temizleme veya uygulamayı yeniden yükleme erişimi kırabilir; anahtar yedekleme ve kurtarmayı planlamadıysanız bu büyük sorun olur.

Hesap kurtarma ekipleri şaşırtır. Sadece kullanıcı anahtarı varsa, “parolayı unuttum” bir anda “erişim kayboldu”ya dönüşebilir. Bir kurtarma anahtarı veya emanet akışı ekleyebilirsiniz, ama bunun ne anlama geldiğini dürüstçe açıklamanız gerekir.

Paylaşım da daha karmaşık hale gelir. Sunucu tarafı şifrelemede paylaşım çoğunlukla izinlerdir. İstemci tarafı şifrelemede paylaşım genellikle anahtar paylaşmayı içerir; iptal ve eski kopyalarla ne yapılacağı gibi sorular çıkar.

Arama ve kullanım kolaylığı özellikleri bir yerde deşifre etmeyi zorunlu kılabilir. Tam metin arama, önizlemeler ve OCR sunucunun dosyayı okuyabilmesini gerektirir. Eğer uçtan uca tarzı gizlilik istiyorsanız, istemci tarafı OCR, yerel indeksleme veya sınırlı arama (ör. sadece dosya adları ve etiketler) gibi çözümler gerekebilir.

Örnek: bir klinik laboratuvar PDF’leri yüklüyor ve taramalarda hasta isimlerini bulmak için OCR istiyor. Sunucu tarafı şifreleme hızlı OCR ve aramayı destekler. İstemci tarafı şifreleme bu işi cihazlara kaydırır; bu web ve mobil arasında desteklemeyi daha yavaş ve zor hale getirir.

Belge türüne göre ihtiyaçlar: sözleşmeler, kimlikler ve tıbbi kayıtlar

En iyi seçim dosya türünden çok iş akışına bağlıdır: kim okumalı, ne kadar hızlı, ne sıklıkla ve ne kadar süreyle?

Sözleşmeler

Sözleşmeler genellikle inceleme, redline, onay ve denetim izi içerir. Ekipler güvenilir arama, paylaşım ve saklama kuralları da ister.

Ürününüz iş içinde işbirliği sağlıyorsa, sunucu tarafı şifreleme pratik bir varsayılan olur çünkü sistem önizlemeler oluşturabilir, arama yapabilir ve rol tabanlı erişimi kullanıcıların anahtar yönetmesi gerekmeden uygulayabilir.

İstemci tarafı şifreleme, uygulama çoğunlukla bir kasa olarak çalışıyorsa (ör. yalnızca nihai imzalı PDF’leri küçük bir yönetici grubuna saklamak) uygun olabilir. Ancak bu durumda yerleşik kolaylıklarda zayıflama olur; istemci tarafı araçlar eklemeniz gerekir.

Kimlikler (pasaport, ehliyet)

Kimlikler yüksek risk taşır ama genellikle kısa ömürlüdür. Birçok ekip kişiyi doğrulamak için kısa süreliğine bunlara ihtiyaç duyar, sonra siler. İş akışı hızlı görüntüleme ve sıkı işlem kuralları gerektirir, işbirliği değil.

Yaygın yaklaşım, sunucu tarafı şifrelemeyi sıkı erişim kontrolü, güçlü denetim kayıtları ve kısa saklama ile eşleştirmektir. Personelin ID’leri hiç görmemesi gerekiyorsa istemci tarafı şifreleme uygun olabilir, ama o zaman doğrulamayı tamamlamak için başka yöntem gerekir.

Tıbbi belgeler

Tıbbi kayıtlar daha güçlü gizlilik beklentileri taşır. Kullanıcılar genellikle yalnızca gerekli en az kişi tarafından görülmesini varsayar.

İstemci tarafı şifreleme sunucu ihlali veya yönetici kötüye kullanımında maruziyeti azaltabilir. Fakat parola sıfırlama, cihaz değişimleri ve acil erişim gibi pratik konuları zorlaştırır. Bu konular iş akışını ve operasyonu etkileyebilir.

Karar vermeden önce her belge türünü şu açılardan haritalayın:

• Kim okumalı (ve nereden)?
• Ne kadar hızlı açılmalı?
• Ne kadar süre saklanmalı?
• Hangi ürün özellikleri önemli (önizleme, arama, otomatik silme)?

Nasıl seçilir: adım adım karar süreci

Sakladığınız şeyleri ve kimlerin onlara dokunduğunu yazmakla başlayın. "uploads" adlı bir klasör politika değildir.

Adım 1: sadece “kullanıcılar” değil, erişimi haritalayın

Rolleri listeleyin ve iki soruyu cevaplayın: kim dosyayı açabilmeli, ve kim asla açmamalı (yöneticiler dahil)? Saklama süresini de burada belirleyin.

Adım 2: tehdit varsayımlarınızı seçin

Neyi savunduğunuz konusunda doğrudan olun.

• İçeriden gelen risk en önemli endişe ise, istemci tarafı şifreleme daha çekici olur.
• Cihaz kaybı ve parola sıfırlamalar sık oluyorsa, kurtarma karmaşıklığına katlanmanız gerekir.

Sonra deneyimi zorlayın:

1. Kurtarma ve destek: Birisi parolayı unutursa veya telefonu kaybederse ne olur? Erişimi kurtarmanız gerekiyorsa, saf istemci tarafı şifreleme uygun olmayabilir.

2. Olmazsa olmaz özellikler: Önizlemeler, arama, OCR, e-imzalama veya API tabanlı işlem gerekli mi? Bu özelliklerin çoğu sunucunun dosyayı okuyabilmesini kolaylaştırır.

3. Denetim ve uyumluluk: Kim, ne zaman ve neyi görüntülediğine dair temiz kayıtlar gerekir mi? Her iki model de erişimi kaydedebilir ama istemci tarafı tasarımlar yardım reddi gibi durumları önceden ele almalı.

Çoğu ekip hibrit bir yol seçer: çoğu belge için sunucu tarafı şifreleme, ve “personel asla görüntüleyemez” şeklinde tanımlanan küçük bir belge seti için istemci tarafı şifreleme.

Kaçınılması gereken yaygın hatalar ve tuzaklar

En büyük tuzak şifrelemeyi tüm hikaye olarak görmek. Gizlilik ve uyumluluk ayrıca kimin verilere erişebildiğine, erişimin nasıl onaylandığına, neyin günlüklenip ne kadar süre saklandığına ve silme taleplerinin nasıl ele alındığına bağlıdır.

İkinci büyük hata, kurtarma planı olmadan istemci tarafı şifreleme inşa etmektir. Bir kullanıcı cihazını kaybederse, parola unutulursa veya şirketten ayrılırsa erişimi geri getirebiliyor musunuz? "Yardım edemeyiz" kişisel bir kasa için kabul edilebilir olabilir, ama iş uygulamalarında genellikle başarısız olur.

Bu hatalar gerçek sızıntılara ve iş akışı kaçışlarına neden olur:

• Yöneticilere gizli bir "her şeyi görüntüle" yolu vermek veya desteğin kullanıcıları taklit etmesine izin vermek, sıkı günlükleme ve ikinci kişinin onayı olmadan.
• Tarayıcıda veya uygulamada deşifre edip kopyalar bırakmak (önizleme önbellekleri, geçici indirmeler, senkronize klasörler).
• "Güvenli" belgeleri daha sonra güvensiz kanallarla göndermek (e-postaya PDF eklemek, ekran görüntüsü yapıp sohbette paylaşmak, dosyayı ticket’a eklemek).
• Güvenli akışı öyle zorlaştırmak ki kullanıcılar kişisel sürücülere geçer veya ekranın fotoğrafını çeker.
• "At-rest şifreleme"nin otomatik olarak onay, erişim geçmişi, saklama ve ihlal bildirim gereksinimlerini karşıladığını varsaymak.

Örnek: bir klinik intake formlarını şifreler, sonra personel faturalama raporu oluşturur ve yerel olarak şifresiz bir klasör yaratır. Bu klasör paylaşılan bir sürücüye yedeklenir. Sızıntı iş akışında olur, kriptoda değil.

Kararlaştırmadan önce kısa kontrol listesi

Bir cümle yazın: bu dosyaları kim okumalı ve kim asla, hatta sunucularınıza erişim olsa bile, okuyamamalı?

Sonra kontrol edin:

• Kim deşifre edebilir ve ne zaman? Tam roller ve koşulları listeleyin. Politikanız "yalnızca yükleyen" diyorsa, paylaşılan anahtarlarla arka kapı eklemeyin.
• Hızlıca erişimi iptal edebilir misiniz? İşten ayrılma gerçek testi yapar. Erişim bir hesaba, cihaza veya gruba mı bağlı?
• Cihaz kaybı veya parola sıfırlamadan sonra ne olur? Kurtarmaya ihtiyacınız varsa, bunu güçlü onaylarla koruyun.
• Önizleme, antivirüs tarama veya OCR gerekiyor mu? Evetse, deşifre işleminin nerede gerçekleşeceğini ve kimin tetikleyebileceğini planlayın.
• Denetim kayıtlarınız yeterince ayrıntılı mı? "Görüntülendi" ile "indirildi" arasındaki farkı tanımlayın ve kullanıcı, zaman, cihaz ve nedeni yakalayın.

Örnek senaryo: kimlikler ve tıbbi PDF’leri saklayan küçük bir ekip

Küçük bir klinikte personel hasta yönlendirmelerini (PDF) ve sigorta kimliklerinin fotoğraflarını yükler. Amaç belgeleri doğru kişilere hızlıca ulaştırmak ve cihaz kaybı, hesap ele geçirilmesi veya bulut hatalarından kaynaklanan hasarı azaltmaktır.

Bir uygulanabilir yaklaşım, sıkı rollere sahip sunucu tarafı şifrelemedir. Dosyalar dinlenmede şifrelenir ve erişim izinleriyle kontrol edilir: ön büro yükleyebilir, faturalama kimlikleri görebilir, klinisyenler yönlendirmeleri görüntüleyebilir. Bu günlük işlerde kolaylık sağlar çünkü personel ekstra adımlara gerek kalmadan belgeleri masaüstünde veya mobilde açabilir ve yöneticiler izinleri devre dışı bırakabilir.

Diğer bir yaklaşım en hassas öğeler için istemci tarafı şifreleme kullanmaktır. Dosya cihazda şifrelenir ve sunucu yalnızca şifreli veriyi saklar. Bu, sunucu ihlali ve içeriden gelen riski küçültebilir; fakat operasyonları değiştirir:

• Parola sıfırlamalar sunucu tarafı şifrelemede normal şekilde erişimi geri getirir; istemci tarafı şifrelemede kullanıcılar anahtar yedeklenmemişse kilitlenebilir.
• Personel değişiminde sunucu tarafı şifrelemeyle işleri devretmek daha basittir; istemci tarafı şifrelemede anahtarların aktarılması veya emanetlenmesi için plan gerekir.

Kullanıcılar paylaşma, mobil erişim ve kaybolan telefondan sonra kurtarma konusunda sürtünme hissedebilir. Bu ayrıntılar şifreleme modelinden en az onun kendisi kadar önemlidir.

Sonraki adımlar: karar verin, politikayı dokümante edin ve uygulayın

Tehdit varsayımlarınızı açık bir dille yazmakla başlayın. Riskinizi karşılayan en basit yaklaşımı seçin, sonra gerçekten belgelerin gerektirdiği yerde sıkılaştırın.

Kararı kısa bir iç kural setine koyun ki insanlar ona uyabilsin:

• Hangi dosya türleri nerede saklanabilir
• Kim erişebilir ve paylaşabilir, ve erişim nasıl onaylanır
• Saklama ve silme kuralları
• Parola sıfırlama ve cihaz kaybından sonra kurtarma nasıl olur
• Dışa aktarımlar (indirmeler, e-posta, mesajlaşma) nasıl ele alınır ve ne zaman engellenir

Sonra uygulamayı bu kurallar etrafında tasarlayın: rol kontrolleri, denetlenmiş eylemler (görüntüleme, indirme, paylaşma), güvenli önizlemeler ve dikkatli anahtar yönetimi.

Eğer AppMaster (appmaster.io) gibi no-code bir platform üzerine inşa ediyorsanız, rolleri ve onay akışlarını erken modellemek işe yarar; sonra gereksinimler değiştikçe tüm uygulamayı baştan yazmak zorunda kalmadan ayarlama yapabilirsiniz. Önemli olan, gerçek kullanıcılar için güvenli yolu kolay yol haline getirmektir.