Şifreleme genellikle bir güvenlik konusu olsa da gizlilik için de önemlidir. Şifrelemenin amacı, şifrelenmiş bilgilerin başkaları tarafından okunmasını engellemektir. Ancak bilgilerinizi başkalarının okumasını engellemek, gizli tutmanın bir yoludur. Bir kullanıcının bunu kendi başına yapabileceği işlemler genellikle sınırlıdır ancak kullandığı hizmetin sağlayıcısı olarak sizin yardımınızla şifreleme, kullanıcıya ait verileri muhafaza etmeye yardımcı olabilir.
Kullanıcı gizliliğine yardımcı olmak için şifreleme uygulamak için kullanılabilecek üç yöntem vardır: aktarım sırasında şifreleme, kullanımda olmayan verilerin şifrelenmesi ve uçtan uca şifreleme:
- Aktarım sırasında şifreleme, verilerin kullanıcı ile siteniz (yani HTTPS) arasında şifrelenmesini sağlar. Büyük olasılıkla HTTPS'yi siteleriniz için ayarlamışsınızdır. Ancak sitelerinize aktarılan tüm verilerin şifrelendiğinden emin misiniz? Yönlendirme ve HSTS, aşağıda açıklandığı gibi HTTPS kurulumunuzun bir parçası olmalıdır.
- Aktif olmayan verilerin şifrelenmesi, sunucularınızda depolanan verilerin şifrelenmesidir. Bu, veri ihlallerine karşı koruma sağlar ve güvenlik yaklaşımınızın önemli bir parçasıdır.
- Uçtan uca şifreleme, istemcideki verilerin sunucunuza ulaşmadan önce şifrelenmesidir. Bu şekilde, kullanıcı verileri sizden bile korunur: Kullanıcılarınızın verilerini saklayabilirsiniz ancak okuyamazsınız. Bu, uygulanması zor ve her tür uygulama için uygun değildir. Ancak kendilerinden başka hiç kimse verilerini göremez. Bu nedenle, kullanıcı gizliliğine büyük ölçüde yardımcı olur.
HTTPS
İlk hamle, web hizmetinizi HTTPS üzerinden sunmaktır. Büyük olasılıkla bunu zaten yapmışsınızdır, ancak yapmadıysanız önemli bir adımdır. HTTPS, tarayıcının bir sunucudan web sayfalarını istemek için kullandığı ancak SSL ile şifrelenen protokol HTTP'dir. Bu, dışarıdan bir saldırganın HTTPS isteği şifrelenmiş olduğundan, gönderen (kullanıcınız) ve alıcı (siz) arasındaki bir HTTPS isteğini okuyamayacağı veya engelleyemeyeceği, dolayısıyla isteği okuyamayacağı veya değiştiremeyeceği anlamına gelir. Bu, aktarım sırasında şifrelemedir: Veriler kullanıcıdan size veya sizden kullanıcıya taşınırken. Aktarım sırasında HTTPS şifrelemesi, kullanıcının İSS'sinin veya kullandığı kablosuz ağın sağlayıcısının da hizmetinizle olan ilişkisi kapsamında size gönderdiği verileri okumasını da engeller. Bu durum hizmetinizin özelliklerini de etkileyebilir: Mevcut JavaScript API'lerinin birçok kullanımı web sitesinin HTTPS üzerinden sunulmasını gerektirir. MDN'nin daha kapsamlı bir listesi vardır ancak güvenli bir bağlama geçilen API'ler arasında Service Worker'lar, push bildirimleri, web paylaşımı, web şifreleme ve bazı cihaz API'leri bulunur.
Web sitenizi HTTPS üzerinden sunmak için bir SSL sertifikasına ihtiyacınız vardır. Bu dosyalar Let's Encrypt aracılığıyla ücretsiz olarak oluşturulabilir veya kullanıyorsanız barındırma hizmetiniz tarafından sağlanabilir. Web hizmetinize "prox" gönderen ve HTTPS, önbelleğe alma ve CDN hizmetleri sağlayabilen bir üçüncü taraf hizmeti de kullanabilirsiniz. Cloudflare ve Fastly gibi çok sayıda hizmet örneği bulunur. Tam olarak hangisinin kullanılacağı mevcut altyapınıza bağlıdır. Geçmişte HTTPS'nin uygulanması zahmetli veya pahalıydı. Bu nedenle yalnızca ödeme sayfalarında veya özellikle güvenli kaynaklarda kullanılıyordu. Ancak ücretsiz olarak sunulan sertifikalar, standart iyileştirmeler ve tarayıcıların daha fazla çoğalması tüm bu engelleri ortadan kaldırdı.
Yapılması gerekenler
- Sunucularınızda her şey için (hangi yöntemi seçerseniz seçin) HTTPS'yi etkinleştirin.
- Sunucularınızın önünde Cloudflare gibi bir proxy kullanma seçeneğini değerlendirin (işlemi httpsiseasy.com/ adresinde bulabilirsiniz).
- Let's Encrypt, kendi Let's Encrypt SSL sertifikanızı oluşturma sürecinde size yol gösterecektir.
- İsterseniz kendi sertifikanızı oluşturmak ve istediğiniz sertifika yetkilisi (CA) tarafından imzalanmasını sağlamak için doğrudan OpenSSL'yi de kullanabilirsiniz (HTTPS'yi etkinleştir bölümünde, bunu nasıl yapacağınız ayrıntılı olarak açıklanmıştır).
Hangi yaklaşımı seçeceğiniz işletme ile ilgili kazanımlara bağlıdır. SSL bağlantısını sizin için bir üçüncü tarafın yönetmesi en kolay uygulamadır ve yük dengeleme, önbelleğe alma ve analiz gibi başka avantajlar da sunar. Ancak bu, kontrolün söz konusu üçüncü tarafa devredildiği açık bir şekilde, üçüncü tarafın hizmetlerine yönelik kaçınılmaz bir bağımlılığı da (ve kullandığınız hizmetlere ve trafik seviyenize bağlı olarak olası ödemeleri) beraberinde getirir.
Eskiden SSL işlemi, sertifikaların oluşturulması ve bir CA tarafından imzalanmasıyla yürütülürdü, ancak sağlayıcınız tarafından destekleniyorsa veya sunucu ekibiniz teknik olarak bunun için yeterli teknik bilgiye sahipse ve ücretsizse Let's Encrypt kullanımı daha kolay olabilir. Bulut barındırmadan daha üst düzeyde bir şey kullanıyorsanız sağlayıcınızın hizmet olarak SSL sunması da yaygın bir davranıştır. Bu yüzden kontrol etmenizi öneririz.
Neden
Güvenlik, gizlilik hikayenizin bir parçasıdır: Kullanıcı verilerini parazite karşı güvende tuttuğunuzu gösterebilmeniz güven oluşturmaya yardımcı olur. HTTPS kullanmıyorsanız siteleriniz de tarayıcılar tarafından "güvenli değil" olarak işaretlenir (ve bir süredir bu durumda). Mevcut JavaScript API'leri genellikle yalnızca HTTPS sayfalarında ("güvenli kaynaklar") kullanılabilir. Ayrıca kullanıcılarınızı İSS'leri tarafından görülmekte olan web kullanımlarına karşı da korur. Bu kesinlikle en iyi uygulamalardan biridir. Şu anda web siteleri için HTTPS'yi kullanmamak için neredeyse hiç neden yoktur.
Tarayıcılar bir HTTP (güvenli değil) sayfasını nasıl sunar?
HTTPS'ye yönlendir
Siteniz hem http: hem de https: URL'lerinde kullanılabiliyorsa, tüm http URL erişimlerini https'ye yönlendirmeniz gerekir. Yukarıdaki nedenlerden dolayı bu işlem uygulanır ve aynı zamanda sitenizin popüler hale gelmesi durumunda whynohttps.com sitesinde gösterilmemesini sağlar. Bunun nasıl yapılacağı büyük ölçüde altyapınıza bağlıdır. AWS'de barındırılıyorsanız Klasik veya Uygulama yük dengeleyicisini kullanabilirsiniz. Google Cloud da buna benzer. Azure'da Front Door oluşturabilirsiniz. Express with Node'da request.secure öğesini; Nginx'te tüm bağlantı noktası 80'i yakalayıp 301'i döndürebilir ve Apache'de rewriteRule kullanabilirsiniz. Bir barındırma hizmeti kullanıyorsanız bu hizmetler büyük olasılıkla sizin için HTTPS URL'lerine yönlendirmeyi otomatik olarak halledecektir: Netlify, Firebase, GitHub Pages ve diğer birçok sayfa.
HSTS
HSTS, "HTTP Strict-Transport-Security"nin kısaltmasıdır ve hizmetiniz için bir tarayıcıyı sonsuza kadar HTTPS kullanacak şekilde kilitlemenin bir yoludur. HTTPS'ye taşıma işleminden memnun olduğunuzda veya bunu zaten yaptıysanız giden yanıtlarınıza bir Strict-Transport-Security HTTP yanıt üstbilgisi ekleyebilirsiniz. Sitenize daha önce erişen bir tarayıcı, bu üst bilgiyi gördüğünü kaydeder ve daha sonra, HTTP isteğinde bulunsanız bile bu siteye otomatik olarak HTTPS biçiminde erişir. Bu işlem, yönlendirmenizin yukarıdaki şekilde yapılmasını önler: Tarayıcı, HTTPS kullanmak için hizmetinize gönderilen tüm istekleri sessizce "yükseltir".
Benzer şekilde, sayfalarınızla birlikte bir Upgrade-Insecure-Requests üstbilgisi de sunabilirsiniz. Bu işlem, Strict-Transport-Security ürününden farklı, ancak onunla ilgili bir şey yapar. Upgrade-Insecure-Requests: 1 eklerseniz bu sayfadan diğer kaynaklara (resimler, komut dosyaları) yapılan istekler, bağlantı http olsa bile https olarak istenir. Ancak tarayıcı sayfanın kendisini https olarak yeniden istemez ve bir dahaki sefere bunu hatırlamaz. Pratikte, Yükseltme-Güvenli Olmayan-İstekler, çok sayıda bağlantısı olan mevcut bir siteyi HTTPS'ye
dönüştüriyorsanız ve içerikteki bağlantı URL'lerini dönüştürmek zorsa yararlıdır, ancak mümkün olduğunda içeriği değiştirmek daha iyidir.
HSTS, temel olarak bir güvenlik özelliğidir: sitenizi daha önce ziyaret etmiş kullanıcılar için HTTPS'ye "kilitler". Ancak, yukarıda da belirtildiği gibi gizlilik için HTTPS iyidir, HSTS ise HTTPS için iyidir. Benzer şekilde, tüm içeriğinizi güncelliyorsanız Yükseltme-Güvenli Olmayan-İstekler gerçekten gerekli değildir, ancak sitenizin her zaman HTTPS olmasını sağlamak üzere derinlemesine savunma eklemek için yararlı bir "kayış ve parantez" yaklaşımıdır.
Yapılması gerekenler
Giden yanıtlarınıza HSTS üstbilgisini ekleyin:
Strict-Transport-Security: max-age=300; includeSubDomains
Max-age parametresi, tarayıcının HTTPS yükseltmesini ne kadar süre (saniye cinsinden) hatırlayacağını ve zorunlu kılacağını belirtir. (Burada, süreyi 300 saniye, yani beş dakika olarak ayarladık.) En sonunda bu sayının 6.3072.000 olmasını istersiniz. Bu iki yıl değeri, hstspreload.org'un önerdiği sayıdır ancak sorunlar varsa kurtarması oldukça zordur. Bu nedenle, başta düşük bir sayıyla (300) bunu ayarlamanız, hiçbir şeyin çalışmadığından emin olmak için test yapmanız ve daha sonra sayıyı aşamalar halinde artırmanız önerilir.
Giden yanıtlarınıza Upgrade-Insecure-Requests üstbilgilerini ekleyin:
Upgrade-Insecure-Requests: 1
Content-Security-Policy: upgrade-insecure-requests
Uçtan uca şifreleme
Kullanıcı verilerini gizli tutmanın iyi bir yolu, bu verileri kullanıcı dışında hiç kimseye (siz de dahil) göstermemektir. Bu, güven açısından çok faydalı olur: Kullanıcılarınızın verileri elinizde değilse bu verilerle istemedikleri hiçbir şeyi yapamayacağınız da açıktır. Bunu yapmanın bir yolu, tüm verileri istemci tarafında depolayarak kullanıcı verilerinin cihazdan dışarı çıkmamasına izin vermektir. Bu yaklaşım işe yarar ancak yalnızca istemci taraflı uygulamalarda bazı sınırlamalar vardır: Tarayıcı verilerinin depolanması sınırlı olabilir ve bazı tarayıcılarda çok az uyarıyla veya hiç uyarı almadan temizlenebilir. Dizüstü bilgisayar ve cep telefonu gibi iki cihazdan verilerinize erişmek de zor veya imkansızdır. Bu nedenle, verileri sunucuya normal şekilde göndermek, ancak yalnızca kullanıcının bildiği bir anahtarla şifrelemek, böylece sunucunun erişememesi (çünkü şifresini çözemeyeceği için) ancak depolayabilmesi yararlı olabilir.
İşleyiş şekli
Bu yaklaşım, "uçtan uca şifreleme" veya "e2e" olarak adlandırılan mesajlaşma uygulamaları tarafından sıklıkla kullanılır. Bu şekilde, birbirinin anahtarlarını bilen iki kişi mesajlarını şifreleyip şifrelerini çözebilir ve mesajlaşma sağlayıcısı aracılığıyla bu mesajları gönderebilir ancak mesajlaşma sağlayıcı (bu anahtarlara sahip olmayan) mesajları okuyamaz. Çoğu uygulama, mesajlaşma uygulaması değildir ancak verileri yerel olarak depolamak ve aynı zamanda sunucuya şifrelenmiş olarak göndermek için iki yaklaşımın (yalnızca istemci tarafında veri deposu ve istemcinin bildiği bir anahtarla veri şifreleme) birleştirilmesi mümkündür. Bu yaklaşımın sınırlamaları olduğunu unutmamak önemlidir: Bu yöntem tüm hizmetler için mümkün değildir. Özellikle, servis sağlayıcı olarak kullanıcının depoladıklarına erişmeniz gerektiğinde kullanılamaz. Bu serinin 2. bölümünde açıklandığı gibi, minimum veri toplama ilkesine uymak en iyi yöntemdir ve mümkünse veri toplamaktan kaçının. Kullanıcının veri depolamaya ihtiyacı varsa ancak hizmeti sağlamak için o verilere erişmeniz gerekmiyorsa uçtan uca şifreleme faydalı bir alternatiftir. Hizmet sunmak için kullanıcının neleri depoladığını görmeyi gerektiren hizmetler sunuyorsanız uçtan uca şifreleme uygun olmaz. Ancak bunu yapmazsanız web hizmetinizin istemci taraflı JavaScript'inin, sunucuya gönderdiği tüm verileri şifrelemesini ve aldığı verilerin şifresini çözmesini sağlayabilirsiniz.
Örnek: Excalidraw
Excalidraw bu işlemi yapar ve bir blog yayınında bunun nasıl yapılacağını açıklar. Sunucuda, rastgele seçilen bir anahtarla şifrelenen çizimleri depolayan bir vektör çizim uygulamasıdır. Excalidraw'un bu uçtan uca şifrelemeyi nispeten az kodla uygulayabilmesinin nedenlerinden biri, kriptografik kitaplıkların artık tüm modern tarayıcılarda desteklenen bir dizi JavaScript API'si olan window.crypto ile yerleşik olarak bulunmasıdır. Kriptografi zordur ve algoritmaları
uygulamak için pek çok uç durum söz konusudur. Burada ağır işleri tarayıcının yapması, şifrelemeyi web geliştiricileri için daha erişilebilir hale getirir ve böylece, şifrelenmiş veriler aracılığıyla gizliliğin uygulanmasını kolaylaştırır. Excalidraw'un yazmada belirttiği gibi, şifreleme anahtarı istemci tarafında kalır, çünkü URL parçasının bir parçasıdır: Bir tarayıcı https://example.com/path?param=1#fraghere URL'sini ziyaret ettiğinde, URL'nin yolu (/path) ve parametreler (param=1) sunucuya
(example.com) iletilir, ancak parça (fraghere) iletilmez ve böylece sunucu, bunu hiçbir zaman görmez. Bu durum, şifrelenmiş veriler sunucudan geçse bile şifreleme anahtarının geçmeyeceği ve böylece veriler uçtan uca şifrelendiğinden gizliliğin korunacağı anlamına gelir.
Sınırlamalar
Kullanıcı verilerini şifreleme yaklaşımı kusursuz değildir. Kullanıcılarınıza karşı güveninizi güçlendirir ancak tamamen yerini alamaz. Kullanıcılarınızın hizmetinize güvenmesi gerekir, çünkü her zaman istemci taraflı JavaScript'i, verileri açıkça şifrelemeyen, fark edilmeyecek kadar benzer bazı JavaScript'lerle değiştirebilirsiniz. Bunun yanı sıra, kullanıcı olarak kullandığınız bir web sitesinin bunu yapıp yapmadığını tespit etmek de son derece zordur. Pratikte, kullanıcılarınızın veri sağlayıcısına çok fazla güven duymanız ve onları kötüye kullanma konusunda kasıtlı bir şekilde güven vermemeniz gerekir.
Uçtan uca şifrelemenin hedeflerinden birinin de site sahibi olarak sizin, verileri okumanızı engellemek olduğunu unutmamak da önemlidir. Bu, gizlilik açısından iyidir ancak sorun olduğunda yardımcı olamayacağınız anlamına da gelir. Özetle, uçtan uca şifreleme kullanan bir hizmet, şifreleme anahtarlarından kullanıcının sorumlu olmasını sağlar. (Bu, bariz veya açık olmayabilir ancak bir kişinin anahtara sahip olması gerekir ve veriler sizden gizliyse bu kişi siz değilsinizdir.) Bu anahtarlar kaybolursa yardımcı olmak için hiçbir şey yapmanız gerekmez ve muhtemelen bu anahtarlarla şifrelenen veriler de kaybolabilir. Burada gizlilik ile kullanılabilirlik arasında çok iyi bir denge vardır: Verileri şifreleme kullanan herkesten gizli tutun ancak kullanıcıları kendi anahtarlarını güvenli bir şekilde yöneten kriptoloji uzmanı olmak zorunda bırakmayın.
Aktif olmayan verilerin şifrelenmesi
Kullanıcılarınızın aktarım halindeki verilerini şifrelemenin yanı sıra, sunucuda sakladığınız verileri şifrelemeniz de önemlidir. Depolanan verilerinize yetkisiz erişim elde eden kişiler şifrelenmiş verilere sahip olacağından, bu verilerin şifresini çözebilecek anahtarlara sahip olmayacağını umduğumuzdan bu, veri ihlallerine karşı koruma sağlamaya yardımcı olur. Aktif olmayan verileri şifrelemek için iki farklı ve birbirini tamamlayan iki yaklaşım vardır: sizin eklediğiniz şifreleme ve bulut depolama sağlayıcınızın eklediği şifreleme (bulut depolama alanı sağlayıcısı kullanıyorsanız). Depolama alanı sağlayıcısı şifrelemesi, yazılımınız üzerinden gerçekleştirilen veri ihlallerine karşı çok fazla koruma sağlamaz (çünkü depolama alanı sağlayıcısı şifrelemesi, hizmeti kullanan bir kullanıcı olarak size karşı genellikle şeffaftır) ancak sağlayıcının altyapısında meydana gelen ihlallere karşı yardımcı olur. Bu özelliğin etkinleştirilmesi genellikle basittir ve bu nedenle dikkate değer. Bu alan hızla değişir ve bu konuda en iyi öneri güvenlik ekibiniz (veya ekibinizdeki güvenlik konusunda deneyimli mühendisler) verir. Ancak tüm bulut depolama alanı sağlayıcıları; varsayılan olarak Azure Storage ve Google Cloud Storage'ı ayarlayarak blok depolama Amazon S3, veritabanı veri depolaması için ise AWS RDS, Azure SQL ve diğerleri için kullanımda olmayan verilerin şifrelenmesini sağlar. Bulut depolama alanı sağlayıcınızla bu sorunu kontrol edin (kullanıyorsanız). Kullanıcı verilerini veri ihlallerinden korumaya yardımcı olmak için aktif olmayan verilerin şifrelenmesini kendiniz yapmak daha zordur. Çünkü şifreleme anahtarlarının güvenli bir şekilde yönetilmesi ve saldırganların kullanımına sunmadan kodlara kullanılabilir hale getirilmesi lojistik açısından zorlu bir süreçtir. Bu düzeydeki güvenlik sorunlarıyla ilgili tavsiye almak için en iyi yer bu değildir. Bu konuda güvenlik konusunda bilgili mühendisleriniz veya özel ekibinizle ya da harici güvenlik kurumlarıyla görüşün.