Geçen ay İstanbul’da bir müşteri toplantısından çıkınca küçücük bir dosya paylaşma meselesi yüzünden epey düşündüm aslında. Elimde sadece birkaç log dosyası vardı. Hani öyle devlet sırrı değil… ama yanlış elde kalırsa baş ağrıtacak türden şeyler. İşin aslı şu ki, çoğumuz kodu korurken aşırı titiz davranıyoruz — şifreleme, MFA, erişim kontrolü, denetim kayıtları, her şey yerli yerinde oluyor. Sonra konu bir dosya göndermeye gelince, nedense “en hızlısı hangisi” diye bakıyoruz. Garip. Ama gerçek.
Bakın şimdi, dosya paylaşımında asıl mesele sadece “şifreli mi?” sorusu değil. O kelime tek başına biraz sis perdesi gibi çalışıyor zaten. Şifreli olabilir, evet — ama nerede çözüldüğü önemli. Eğer dosya sunucu tarafında açılıyorsa, servis sağlayıcı teoride içeriği görebiliyor. Eğer uçtan uca şifreleme varsa, iş değişiyor. Bu ayrım küçük görünür ama pratikte dağ kadar fark yaratıyor.
Şifreleme Var Demek Yetmiyor
“Encrypted” ibaresi kulağa güven veriyor, kabul. Ama güvenlik dünyasında (söylemesi ayıp) bu kelime bazen fazla iş yapıyor — adeta tek başına bütün yükü omuzlamaya çalışan bir adam gibi, yorulana kadar. HTTPS/TLS ile taşınan veri yolda korunuyor, tamam. Fakat veri sunucuya ulaşınca çözülürse hikaye orada bitmez, çünkü arada bir ara durak oluşmuş oluyor ve bu durak bazen çok şey ifade ediyor.
Şimdi gelelim işin can alıcı noktasına.
Geçen sene Berlin’de bir ekiple yaptığım görüşmede buna benzer bir vakayı masaya yatırmıştık. Takım, build çıktısını kısa süreliğine paylaşıyor sanıyordu. Meğer servis varsayılan olarak dosyaları günlerce tutuyormuş. Kimse fark etmemiş bile! Yani “biz zaten şifreli gönderiyoruz” rahatlığı bazen biraz fazla iyimser kalıyor.
In-transit şifreleme ne sağlar?
Bir şey dikkatimi çekti: Şunu sağlıyor: dosyanın cihazınızdan sunucuya, sunucudan alıcıya giderken korunmasını. Günlük hayattan benzeteyim — mektubu zarf içine koyup postaya vermek gibi düşünün. Sokakta kimse içini kolay kolay okuyamıyor. Güzel tarafı bu.
Gel gelelim zarf postaneye varınca açılabiliyor. İşte burada risk başlıyor. Servis sağlayıcının altyapısı ele geçirilirse ya da içeriden biri yetkisini kötüye kullanırsa, problem büyüyebilir. Açık konuşayım: çoğu gündelik kullanım için bu seviye idare eder. Tahmin eder misiniz? Ama API anahtarı veya müşteri sözleşmesi gönderiyorsanız, “idare eder” pek tatmin etmiyor açıkçası.
Şu soruyu sorun: Dosya yolda mı korunuyor, yoksa uçtan uca mı kilitleniyor? Aradaki fark bazen yalnızca teknik bir detay değil… doğrudan risk seviyesi.
E2EE neden daha sıkı bir standart?
Uçtan uca şifrelemede dosya sizin cihazınızda kilitlenip alıcının cihazında açılıyor. Aradaki servis anahtarı görmüyor bile. Bana hep mühürlü koli mantığını hatırlatıyor bu — koli teslim noktalarından geçiyor (en azından benim deneyimim böyle). Kimse içine bakamıyor, en azından normal şartlarda.
Bunu test ettiğimde dikkatimi çeken şu oldu: E2EE olan servislerde kullanıcı deneyimi bazen biraz hantal olabiliyor (buna dikkat edin). Anahtar yönetimi zorlaşıyor, kurtarma senaryoları karışıyor. Ekip içinde “kim neyi nasıl açacak” konusu uzayıp gidebiliyor. Kağıt üstünde süper; pratikte ise ufak pürüzler çıkıyor. Kaçınılmaz biraz. Daha fazla bilgi için Anthropic kendi çiplerini mi tasarlıyor? Asıl mesele başka yazımıza bakabilirsiniz.
İşte tam da bu noktada devreye giriyor.
| Konu | In-Transit Şifreleme | Uçtan Uca Şifreleme |
|---|---|---|
| Veri yolda korunur mu? | Evet | Evet |
| Sunucu veriyi okuyabilir mi? | Evet, teorik olarak | Hayır |
| Kullanım kolaylığı | Daha rahat | Bazen daha karmaşık |
| Sensitif veri için uygunluk | Sınırlı | Daha güçlü seçenek |
Kalan Dosya da Tehlike Yaratır mı? Evet.
Yaratır. Hatta bayağı yaratır. Çünkü sorun sadece kimin görebileceği değil — o verinin ne kadar süre ortada kaldığı da aynı derecede kritik bir mesele. Bir dosyayı yükleyip yıllarca orada bırakıyorsanız, farkında olmadan saldırı yüzeyini büyütmüş oluyorsunuz. Bana göre bu konu hala hafife alınıyor. Bu ne anlama geliyor? Ciddi ciddi.
2024’te Kadıköy’de birlikte çalıştığım küçük bir startup ekibi vardı; günlük operasyon loglarını “sonra lazım olur” diye bulutta tutuyorlardı. Üç ay sonra eski loglardan birinin beklenmedik biçimde hassas IP adresleri ve internal endpoint’ler içerdiği ortaya çıktı. Kimse kötü niyetli değildi, iyi niyetli insanlar bunlar — ama risk oradaydı, kapıda bekliyordu. Bazen ihlal için büyük saldırılar gerekmez; unutulmuş bir klasör yeter de artar bile.
Neden geçici saklama iyi fikir?
Ephemeral storage tam burada devreye giriyor. Dosyanın otomatik silinmesi — ister indirilince ister 24 saat sonra — maruziyet süresini ciddi biçimde kısaltıyor ve bu küçük detay düşündüğünüzden çok daha büyük fark yaratıyor (ki bu çoğu kişinin gözünden kaçıyor). Mesela debug çıktıları, build paketleri ve kısa süreli onay dosyaları için çok mantıklı bir yaklaşım bu. Microsoft Foundry Mart 2026 Güncellemesi: Asıl Büyük Değişim Bu yazımızda bu konuya da değinmiştik.
Bence, Neyse, uzatmayalım: her dosyanın ömür boyu yaşaması gerekmiyor. Hatta çoğu zaman gereksiz yere tutulması zararlı. Bir servisin güvenliği yalnızca kapısındaki kilide bakarak anlaşılmaz; içeride ne kadar eşya bıraktığınıza da bakmanız gerekiyor.
Erişim Kontrolü ve İz Kayıtları Neden Önemli?
Açık konuşayım, İyi bir paylaşım aracını güvenli yapan şeylerden biri de — bence en önemlilerinden biri — erişim yönetimi. Parola koruması var mı? Belirli e-posta adreslerine izin veriyor mu? Kim açtı, ne zaman açtı gösterebiliyor mu? Bu sorular çok temel görünüyor ama kurumsal ortamda hayat kurtarıyor, gerçekten.
Vallahi, Açık konuşayım: tek linkle herkese açık paylaşım modeli hala birçok ekipte kullanılıyor. Bu bana biraz vahşi batı gibi geliyor. Küçük projede sorun olmayabilir. Ama enterprise seviyede işler değişiyor — orada SSO desteği olmayan ya da denetim kaydı vermeyen araçlar direkt eleniyor zaten.
- MFA desteği: Hesap ele geçirilmesini zorlaştırıyor.
- SSO entegrasyonu: Kurumsal kimlik yönetimini düzenliyor.
- Erişim sınırı: Sadece belirlenen kişiler görüyor.
- Audit log: Kim ne yaptı, sonradan takip edilebiliyor.
- Zaman sınırlı bağlantılar: Link sonsuza dek ortalıkta dolaşmıyor.
Küçük ekip ile büyük kurum aynı şeyi mi ister?
Hayır, tabii ki istemez. Bir startup için hız genellikle öncelik — ekip az, süreçler hafif, herkes birbirini tanıyor. Ama finans, sağlık ya da kurumsal SaaS ürünlerinde çalışan büyük ekiplerde ufak bir gevşeklik bile ciddi masraf çıkarabiliyor. Ben kendi projelerimde artık şu çizgiyi net koyuyorum: içerikte müşteri verisi varsa ve iz kaydı yoksa, içim rahat etmiyor. E peki, sonuç ne oldu? Bu kadar basit. CI, On Bir Dili Görmezse İşiniz Yarıda Kalır yazımızda bu konuya da değinmiştik.
Peki Hangi Veri İçin Ne Seçilmeli?
Şunu söyleyeyim, Lafı gevelemeden söyleyeyim: her veri aynı düzeyde korunmak zorunda değil. Geliştirme sırasında çıkan build çıktısı ile müşteri sözleşmesini aynı sepete atmak doğru değil. Burada pratik düşünmek gerekiyor — güvenlik takıntısı yapmak değil tabi, ama ciddiyeti de bırakmamak lazım.
# Basit karar mantığı
if veri_tipi in ["API key", "müşteri dosyası", "kimlik belgesi"]:
tercih = "uçtan uca şifreleme + süre sınırlı saklama"
elif veri_tipi in ["log", "build output", "geçici taslak"]:
tercih = "in-transit şifreleme + otomatik silme"
else:
tercih = "risk değerlendirmesi yap"Bakın, Bazı ekipler tüm hassas işleri tek araçta toplamaya çalışıyor ve sonra şaşırıyorlar (kendi tecrübem). Aslında — dur bir saniye — önce araç değil süreç düşünmek gerekiyor. E peki, sonuç ne oldu? Araç sadece zincirin halkasıdır; yanlış halka seçilirse bütün zincir bozuluyor zaten.
Sorun genelde teknoloji mi oluyor?
Bazen teknoloji suçlu değil. İnsan alışkanlığı suçlu. “Nasıl olsa kısa süre kalacak” diyerek başlayan işler aylarca sürüyor, bazen yıllarca (şaşırtıcı ama gerçek). Ya da linki alan kişi ekran görüntüsü alıp başka yere taşıyor — bunu önleyemiyorsunuz, en gelişmiş sistemle bile. Yani kontrol ettiğinizi sandığınız alan, sandığınızdan çok daha dar olabiliyor. Bu yüzden güvenliği sadece platforma bırakmak yerine kullanım disiplinine de yaymak gerekiyor.
Editör Masasından Birkaç Pratik Not
Şöyle ki, Bu konuyu yazarken aklıma geçen hafta gelen başka bir örnek düştü. Ankara’dan tanıştığım bağımsız bir geliştirici arkadaşım kendi müşterileriyle paylaştığı zip dosyalarını hep tek kullanımlık linkle gönderiyordu. “Başta uğraştırıyor ama sonra kafam rahat” dediğinde hak verdim açıkçası. Çünkü güvenlik bazen ekstra adım istiyor — ama o adım sonradan bin adımlık dertten kurtarıyor.
E tabi her şey güllük gülistanlık değil. Bazı araçlar güvenliği artırırken kullanıcı deneyimini göme gidiyor. Kullanıcı parolasını unutuyor, anahtar süresi doluyor, paylaşılan link gereksiz yere kırılıyor… Bu noktada ürün tasarımının biraz daha pişmesi lazım. Kağıt üstünde harika olan çözümün sahada tökezlediğini çok gördüm (yanlış duymadınız). Çooook.
Neye dikkat etmeli?
- Datanın nerede çözüldüğünü öğrenin.
- Saklama süresini mutlaka kontrol edin.
- MFA ve SSO var mı bakın.
- Erişim loglarını inceleyin.
- Kritik veriler için link paylaşımı yerine sınırlı erişim düşünün. — bunu es geçmeyin
Bir de şu var: güvenlik kontrolleri ne kadar güçlenirse güçlensin, kullanıcının yanlış klasöre sürüklediği tek bir dosya bütün planı bozabiliyor. İşte tam burada basit eğitimler devreye giriyor ve düşündüğünüzden çok işe yarıyor. Teknik önlem kadar davranışsal alışkanlık da önemli. Hatta bazen daha önemli.
Sıkça Sorulan Sorular
TLS ile E2EE arasındaki temel fark nedir?
TLS veriyi aktarım sırasında korur; E2EE ise veriyi gönderen cihazda kilitleyip yalnızca alıcı cihazda açar.
Kısacası TLS yol güvenliği sağlar, E2EE ise içeriğin kendisini korur.
Hassas dosyalarda E2EE daha sıkı tercihtir.
Dosyam sunucuda kısa süre kalsa bile risk var mı?
Evet var.
Kısa süre bile olsa yanlış yapılandırma, yetkisiz erişim veya kayıtların sızması ihtimali bulunur.
Maruziyet süresi azaldıkça risk düşer ama sıfırlanmaz.
Küçük ekipler için hangi yaklaşım daha mantıklı?
Küçük ekiplerde hız önemli olduğu için in-transit şifreleme yeterli olabilir;
ama gizlilik içeren belgelerde geçici saklama ve mümkünse E2EE daha doğru olur.
Yani işin ağırlığına göre seçim yapmak lazım.
Aynı araç hem günlük hem hassas işler için kullanılabilir mi?
Kullanılabilir ama politika şarttır.
Her dosya aynı kuralla gitmemeli;
API anahtarlarıyla sıradan dokümanları aynı şekilde ele almak iyi fikir değildir.
Etraflı okumak isteyenler aşağıdaki yazılara da göz atabilir:
Azure Storage’ta Sessiz Güç: Container, Tier ve SAS
Mythos Güvenlikte Eşiği Aştı: Şimdi Ne Değişiyor?
Sıkça Sorulan Sorular Yapılan Paylaşımlar Gerçekten Siliniyor mu?
“Maybe”? No back to Turkish please by continue because must final clean html only not possible now
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
