Soru Birden fazla müşteri için dosyaları güvenli bir şekilde saklamak ve sunmak


Kullanıcılarımızın dosyalarını yükleyebileceği bir web uygulaması üzerinde çalışıyoruz. Ancak bu dosyaları VPS'imizde depolayamayız çünkü depolama alanı sınırlı olduğundan S3 ile çalışmaya karar verdik.

Asıl sorun, kullanıcıların sadece kendi verilerine erişebilmelerini sağlamamız gerektiğidir. Bu nedenle, veritabanımızdaki dosyaların listesini ve bunlara erişen kullanıcıların listesini tutuyoruz. Sunucumuz, bir kullanıcının bir dosyaya erişip erişemediğine kolayca karar verebilir. Ama aslında dosyalara kullanıcılara nasıl servis yapılır?

Daha önce düşündüğüm bazı olasılıklar var, ancak bunların hiçbiri aslında en iyisi değil.

1. PHP ile imzalı URL'leri üretme (son kullanma tarihi)

Bu gerçekten basit bir yaklaşım, aynı zamanda hızlı ama çok çirkin ve uzun URL'ler ile sonuçlanır.

İşte nasıl yapılacağı.

2. Kısaltılmış URL'ler

Bu, S3 üzerinde okumak için dosyaları kamuya açık tuttuğumuz anlamına gelir, ancak tüm dosyalar aşağıdaki gibi adlandırılmış klasörleri tahmin etmekte zorlanır: 24fa0b8ef0ebb6e99c64be8092d3ede20000. Ancak, belki bu gitmek için en güvenli yol değildir. Bir klasör adını asla tahmin edemeseniz bile, bunu bildiğinizden (aslında ona erişebildiğiniz için), bu bağlantıyı herhangi bir kişi ile (yetkili olmayan kişilerle) paylaşabilirsiniz.

3. Dosyaları sunucumuzdan indirin

Bu, dosyaların doğrudan S3 tarafından sunulmadığı anlamına gelir, ancak önce sunucumuz bunu güvenli bir şekilde okur ve ona hizmet eder. Bunu gerçekten istemiyoruz :)

4. Yönlendirmeyi kontrol etme

Objektif URL'ler Çözüm, sunucumuzdan isteğin "yapıldığından" emin olunmasıyla geliştirilebilir (yönlendirmeyi kontrol etmek için S3'ü ayarlayabilirsiniz). Ancak bu, çok güvenilir olmayan bir çözüm olacaktır çünkü tüm tarayıcılar yönlendiren verilerini göndermez ve aynı zamanda sahte de olabilir.

Amazon S3'ten farklı istemciler için güvenli bir şekilde dosya sunmanın iyi bir yolu nedir?


8
2018-05-10 15:50


Menşei


Çirkin / uzun URL’yi neden önemsiyorsunuz? Kullanıcıyı yazmıyorsun, değil mi? - ceejayoz
URL'lerin kullanıcı deneyiminin bir parçası olduğuna gerçekten inanıyorum ve onları çok uzun ve çirkin istemiyoruz :) - Tamás Pap
Güvenlik ve istikrar, bu durumda güzel URL'leri koymalıdır. Bunlar, blog yayınlarının permalinkleri değildir. - ceejayoz


Cevaplar:


Bu, sizin için "Sistem mimarisi yap" ı gerçekten sınırlıyor, ancak dört fikriniz değişken güvenlikteki ilginç vaka çalışmalarıdır, bu yüzden seçeneklerinizi yönetelim ve nasıl ücret aldıklarını görelim:


4. Yönlendirmeyi kontrol etme

Yönlendiren müşteri tarafından sağlanır. İstemci tarafından sağlanan kimlik doğrulama / yetkilendirme verisine güvenmek neredeyse güvenliği engeller (sadece gelmemi istediğin yerden gönderilebileceğini iddia edebilirim).
Karar:  TERRIBAD fikir - bypass için önemsiz.


3. Dosyaları sunucumuzdan indirin

Olması için bant genişliğini harcamak istediğiniz sürece ve sunucunuz güvenilir olduğundan, kötü bir fikir değil.
Normal sunucunuz / uygulamanızın güvenlik sorununu çözdüğünüz varsayımına dayanarak, sunduğunuz seçeneklerin en güvenli olanı budur.
Karar: Güzel çözüm. Bant genişliği bir faktör ise, çok güvenli, ama muhtemelen optimal değil.


2. Kısaltılmış URL'ler

Belirsizlik yoluyla güvenlik? Gerçekten mi? Yok hayır.
Bunu analiz etmeyeceğim bile. Sadece hayır.
Karar: # 4 ise TERRIBAD bu TERRIWORSE çünkü insanlar bir refakatçi başlığı kurma çabasından bile geçmezler. Dizeyi tahmin et ve kazan bir ödültüm veriler!


1. PHP ile imzalı URL'leri üretme (son kullanma tarihi)

Bu seçenek oldukça düşük bir emiş katsayısına sahiptir.
Herkes URL'yi tıklayabilir ve veriyi gizleyebilir, bu bir güvenlik no-no'dur, ancak bağlantıyı süresinin dolmasını sağlayarak bu sorunu hafifletirsiniz (bağlantı ömrü, güvenlik açığı penceresinin yeterince kısa olması koşuluyla).
URL süresi doldu Mayıs ayı İndirme bağlantısına uzun süre dayanmak isteyen veya bağlantıyı zamanında almayan bazı kullanıcılar rahatsızlık veriyor. Bu, Kullanıcı Deneyimi'nin bir kısmının berbat olmasına rağmen, buna değer olabilir.
Karar: # 3 kadar iyi değil, ancak bant genişliği büyük bir endişe ise # 4 veya # 2'den daha iyi.


Ne yapardım?

Bu seçenekler göz önüne alındığında, # 3 ile giderdim - Dosyaları kendi ön uç sunucunuzdan geçirin ve uygulamanızın normalde yaptığı yolu doğrulayın. Normal güvenliğinizin oldukça iyi olduğunu varsayarsak bu, güvenlik açısından en iyi seçenektir.
Evet, bu, sunucunuzda daha fazla bant genişliği kullanımı ve aracıyı yürüten daha fazla kaynak anlamına gelir - ancak bunun için her zaman biraz daha fazla şarj edebilirsiniz.


11
2018-05-10 20:11



Bu gerçekten faydalı bir analiz ve bunun için çok minnettarım. # 3'ün bir diğer büyük faydası, bir dosyanın URL'sinin hiçbir zaman değişmemesi nedeniyle tarayıcıda önbelleğe alma işlemlerini çok fazla kullanabilmemizdir. Zaman ayırdığınız için tekrar teşekkür ederim. - Tamás Pap
@TamasPap'in # 3 avantajı olduğundan emin olun - ne kadar büyük bir avantaj, ne kadar agresif bir şekilde önbelleğe almayı yapılandırabileceğinizi (ve insanların bu dosyalara ne sıklıkla "yeni" makinelerden eriştiğine bağlıdır). - voretaq7


kullanım Amazon S3 önceden imzalanmış sorgular S3 nesnelerini, istediğiniz kullanıcı doğrulama işlemini yaptıktan sonra doğrudan kullanıcılara sunmak. Bu yöntem, kullanıcıları yönlendirebileceğiniz, zaman sınırlı bir URL oluşturur.


2
2018-05-10 23:31