Wenn wir Dateien in Ihrem S3-Bucket speichern sollen, empfehlen wir, die Zugangsdaten in einem Template in Ihrem Konto zu speichern. Wir speichern dieses Template verschlüsselt in unserer Datenbank.

Die zur Entschlüsselung erforderlichen Schlüssel werden von einem anderen Systembenutzer in den Prozessspeicher eingespeist. Selbst wenn es jemandem gelänge, den Benutzer auszunutzen, unter dem unsere API- oder Website-Prozesse laufen, könnte diese Person daher nicht auf die Schlüssel zugreifen. Falls sie versuchen würde, unseren Code so zu ändern, dass die Zugangsdaten angezeigt oder gesendet werden, müsste sie den Dienst neu starten (für diesen Benutzer nicht zulässig) und auf die Schlüsseldateien zugreifen (ebenfalls nicht zulässig).

Wenn sich jemand Root-Zugriff auf unsere Server verschafft, sieht die Situation anders aus. Deshalb setzen wir Firewalls und geschützte SSH-Schlüssel ein und beschränken unsere sudo-Berechtigungen. Doch wie Ihnen jeder Experte bestätigen wird, ist 100 % Sicherheit ein Mythos, und es ist besser, sich auf den schlimmsten Fall vorzubereiten.

Daher empfehlen wir, IAM-Richtlinien zu erstellen, die für Ihre Buckets nur über Put- und List-Berechtigungen verfügen (eine aktuelle und genaue Liste der erforderlichen Berechtigungen finden Sie in der S3-Store-Dokumentation), und Transloadit damit ausschließlich Schreibzugriff zu gewähren. Sollten Ihre Zugangsdaten jemals gestohlen werden und die Kriminellen sie auch entschlüsseln können, könnten sie diesem bestimmten Bucket dennoch nur weitere Dateien hinzufügen, bis wir dies bemerken und eingreifen.

Wie bereits erwähnt, ist 100 % Sicherheit ein Mythos. Unsere Sicherheitsphilosophie besteht jedoch darin, es allen so schwer wie möglich zu machen, Zugriff auf Ihre Zugangsdaten und die zu ihrer Entschlüsselung erforderlichen Schlüssel zu erhalten. Sollte dies dennoch gelingen, sollen diese so nutzlos wie möglich sein.