Sicheres Speichern und Bereitstellen von Dateien für mehrere Clients


8

Wir arbeiten an einer Web-App, mit der unsere Benutzer (unter anderem) ihre Dateien hochladen können. Wir können diese Dateien jedoch nicht auf unserem VPS speichern, da der Speicherplatz begrenzt ist. Daher haben wir uns für S3 entschieden.

Das Hauptproblem ist, dass wir sicherstellen müssen, dass Benutzer nur auf ihre eigenen Daten zugreifen können. Daher behalten wir die Liste der Dateien in unserer Datenbank und die Liste der Benutzer, die Zugriff darauf haben. Unser Server kann leicht entscheiden, ob ein Benutzer Zugriff auf eine Datei hat oder nicht. Aber wie sollen die Dateien tatsächlich den Benutzern bereitgestellt werden?

Es gibt einige Möglichkeiten, die ich bereits in Betracht gezogen habe, aber keine davon scheint tatsächlich die beste zu sein.

1. Generieren (Ablaufen) signierter URLs mit PHP

Dies ist ein wirklich einfacher Ansatz, der auch schnell ist, aber zu sehr, sehr hässlichen und langen URLs führt.

Hier erfahren Sie, wie es geht .

2. Verschleierte URLs

Das bedeutet , dass wir halten die Dateien öffentlich für Lese auf S3, aber alle werden die Dateien in schwer gespeicherten Ordnern zu erraten wie: 24fa0b8ef0ebb6e99c64be8092d3ede20000. Vielleicht ist dies jedoch nicht der sicherste Weg. Selbst wenn Sie niemals einen Ordnernamen erraten können, nachdem Sie ihn kennen (weil Sie tatsächlich Zugriff darauf haben), können Sie diesen Link für jeden (für jede nicht autorisierte Person) freigeben.

3. Laden Sie die Dateien über unseren Server herunter

Dies bedeutet, dass die Dateien nicht direkt von S3 bereitgestellt werden, sondern dass unser Server sie zuerst sicher liest und bereitstellt. Das wollen wir wirklich nicht :)

4. Überprüfen des Referrers

Die Lösung für verschleierte URLs kann verbessert werden, indem "sichergestellt" wird, dass die Anforderung von unserem Server stammt (Sie können S3 einrichten, um den Referrer zu überprüfen). Dies wäre jedoch eine sehr unzuverlässige Lösung, da nicht alle Browser die Referrer-Daten senden und diese auch gefälscht werden können.

Was ist eine gute Möglichkeit, Dateien aus Amazon S3 sicher für verschiedene Clients bereitzustellen?


1
Warum interessiert dich die hässliche / lange URL? Sie lassen den Benutzer es nicht eingeben, oder?
Ceejayoz

Ich glaube wirklich, dass URLs Teil der Benutzererfahrung sind, und wir wollen sie nicht zu lang und hässlich :)
Tamás Pap

2
Sicherheit und Stabilität sollten in diesem Fall hübsche URLs übertreffen, würde ich sagen. Dies sind keine Permalinks zu Blog-Posts.
Ceejayoz

Antworten:


12

Dies grenzt für Sie wirklich an "Do my System Architecture", aber Ihre vier Ideen sind interessante Fallstudien zur variablen Sicherheit. Lassen Sie uns also Ihre Optionen ausführen und sehen, wie sie sich auswirken:


4. Überprüfen des Referrers

Der Referrer wird vom Kunden bereitgestellt. Das Vertrauen in die vom Client bereitgestellten Authentifizierungs- / Autorisierungsdaten macht die Sicherheit so gut wie ungültig (ich kann nur behaupten, von dem Ort gesendet worden zu sein, von dem Sie erwarten, dass ich von dort komme). Fazit
: TERRIBAD- Idee - trivial zu umgehen.


3. Laden Sie die Dateien über unseren Server herunter

Keine schlechte Idee, solange Sie bereit sind, die Bandbreite dafür aufzuwenden, und Ihr Server zuverlässig ist.
Unter der Annahme, dass Sie das Sicherheitsproblem für Ihren normalen Server / Ihre normale App bereits gelöst haben, ist dies die sicherste der von Ihnen vorgestellten Optionen.
Urteil: Gute Lösung. Sehr sicher, aber möglicherweise nicht optimal, wenn die Bandbreite eine Rolle spielt.


2. Verschleierte URLs

Sicherheit durch Dunkelheit ? "Ja wirklich?" Nein,
ich werde es nicht einmal analysieren. Einfach nein. Fazit
: Wenn # 4 TERRIBAD war, ist dies TERRIWORSE, weil die Leute nicht einmal die Mühe machen müssen, einen Referrer-Header zu fälschen . Errate die Saite und gewinne einen Preis für alle Daten!


1. Generieren (Ablaufen) signierter URLs mit PHP

Diese Option hat einen ziemlich niedrigen Saugquotienten.
Jeder kann auf die URL klicken und die Daten abrufen, was ein Sicherheits-Nein-Nein ist. Sie können dies jedoch verringern, indem Sie den Link ablaufen lassen (solange die Lebensdauer des Links kurz genug ist, ist das Schwachstellenfenster klein).
Das Ablaufen der URL kann einige Benutzer stören, die lange Zeit am Download-Link festhalten möchten oder die den Link nicht rechtzeitig erhalten - das ist ein bisschen nervig, aber es kann sich lohnen .
Fazit : Nicht so gut wie # 3, aber wenn Bandbreite ein Hauptanliegen ist, ist es sicherlich besser als # 4 oder # 2.


Was würde ich tun?

Angesichts dieser Optionen würde ich mit # 3 fortfahren - Die Dateien über Ihren eigenen Front-End-Server weiterleiten und die Art und Weise authentifizieren, wie Ihre App normalerweise funktioniert. Vorausgesetzt, Ihre normale Sicherheit ist ziemlich anständig, ist dies unter Sicherheitsgesichtspunkten die beste Option.
Ja, dies bedeutet mehr Bandbreitennutzung auf Ihrem Server und mehr Ressourcen für Vermittler - aber dafür können Sie immer nur ein kleines bisschen mehr verlangen.


Dies ist eine wirklich hilfreiche Analyse, und ich bin sehr dankbar dafür. Ein weiterer großer Vorteil von # 3 ist, dass wir - da sich die URL zu einer Datei nie ändert - das Browser-Caching stark nutzen können. Nochmals vielen Dank für Ihre Zeit.
Tamás Pap

@TamasPap, das ist ein Vorteil von # 3, um sicher zu sein - wie groß ein Vorteil ist, hängt davon ab, wie aggressiv Sie das Caching konfigurieren können (und wie oft Benutzer von "neuen" Computern auf diese Dateien zugreifen).
voretaq7

4

Verwenden Sie vorsignierte Abfragen von Amazon S3 , um die S3-Objekte direkt an Benutzer zu senden, nachdem Sie die gewünschte Benutzerüberprüfung durchgeführt haben. Diese Methode erstellt eine zeitlich begrenzte URL, zu der Sie Benutzer umleiten können.


0

Es gibt auch einen anderen Weg.

Sie können einen AWS CloudFront auf Ihren S3-Bucket verweisen und signierte Cookies verwenden, um Ihren Endbenutzern Inhalte sicher bereitzustellen.

Endbenutzer müssen sich bei Ihrem Server anmelden, um die signierten Cookies zu erhalten, die dann beim Zugriff auf eine Datei an CDN gesendet werden.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.