Wie paranoid sollte ich über meine Azure-Anwendung binäre Dateien gestohlen werden?

8

Ich muss eine große Anwendung nach Windows Azure migrieren. Die Anwendung hängt von einer Bibliothek eines Drittanbieters ab, die einen Aktivierungsschlüssel benötigt, der in einer speziellen Binärdatei auf dem Rolleninstanz-Dateisystem gespeichert ist.

Offensichtlich muss dieser Schlüssel entweder in das Rollenpaket aufgenommen oder irgendwo gespeichert werden, wo die Rolle ihn holen kann. Der Aktivierungsschlüssel ist nicht an den Computer gebunden (da ich keine Ahnung habe, wo genau eine Rolle in der Cloud ausgeführt wird), damit jeder eine Kopie dieser Bibliothek erstellen kann.

Da Azure-Rollen irgendwo unter unserer Kontrolle laufen, fühle ich mich etwas paranoid, weil der Schlüssel gestohlen und allgemein verfügbar gemacht wird.

Wie bewerte ich, wie wahrscheinlich es ist, eine Binärdatei zu stehlen, die in Azure-Rolle enthalten ist? Wie lindere ich solche Risiken?

    
sharptooth 02.06.2011, 10:15
quelle

2 Antworten

2

Wenn du solche Fragen stellst, musst du deine Angreifer unterscheiden:

  • A2) Schurken-Internet-Hacker
  • A3) Ein Entwickler in Ihrer Organisation
  • A4) Eine Person in Ihrer Organisation, die Bereitstellungen durchführt

Ihre Rolle Binaries sind nicht zugänglich für A2, aber sie sind sehr zugänglich für A3 und A4.

Wie in einer anderen Antwort erwähnt, können Sie Ihre Geheimnisse in der Rollenkonfigurationsdatei speichern. Diese Geheimnisse sind jedoch immer noch für A4 zugänglich (jeder mit Zugriff auf das Portal).

Um sich gegen A4 zu verteidigen, möchten Sie die Geheimnisse in der Rollenkonfigurationsdatei mit einem Schlüssel verschlüsseln, der in den Rollen-Binärdateien oder der Rollenkonfiguration nicht vorhanden ist. Dann entschlüsseln Sie in Ihren Rolle-Binärdateien die verschlüsselte Rolleneinstellung mit dem Entschlüsselungsschlüssel.

Der Schlüssel zum Verschlüsseln der Geheimnisse ist ein Zertifikat, das das Azure SDK für Sie installiert. Sie finden einen Beitrag zum Einrichten von Zertifikaten für azurblaue hier .

Zusammenfassend können Sie für Secrets, in denen Sie sich gegen Personen in Ihrer Organisation verteidigen müssen, die Bereitstellungen vornehmen / Zugriff auf Ihre Konfigurationsdateien haben, Folgendes tun:

Lassen Sie eine vertrauenswürdige Partei Folgendes tun:

  • Generieren Sie ein Zertifikat / einen privaten Schlüssel
  • Verschlüsseln Sie Geheimnisse mit dem Zertifikat und speichern Sie die verschlüsselten Einstellungen in Ihren Konfigurationsdateien
  • Laden Sie das Zertifikat / den privaten Schlüssel zu Ihrem Dienst hoch.

Ändern Sie dann Ihren Service zu:

  • Lassen Sie das Service-Modell das Zertifikat / PrivateKey installieren
  • Laden Sie in Ihrer Anwendung den privaten Schlüssel zum Entschlüsseln von geheimen Schlüsseln
  • Lassen Sie Ihre Anwendung die verschlüsselten Einstellungen aus der Rollenkonfiguration laden und entschlüsseln Sie sie mit dem privaten Schlüssel.
Igor Dvorkin 04.06.2011 06:15
quelle
2

Was die Sicherheit betrifft, ist das standardmäßig immer verbesserte Azure-Betriebssystem wahrscheinlich weitaus sicherer als ein selbst konfigurierter Host, es sei denn, Ihr Team ist in diesem Bereich extrem leistungsfähig. Zumindest schätzen wir (nach meinem Unternehmen Lokad) die Situation zwei Jahre nach der vollständigen Migration zu Windows Azure im Vergleich zu unserer vorherigen selbst gehosteten Situation.

Wenn Sie über Anmeldeinformationen verfügen, z. B. Lizenzschlüssel, ist die logische Role-Konfigurationsdatei der logischste Ort, um sie zu platzieren - nicht die Binärdateien der Rolle. Sie können natürlich die spezielle Datei innerhalb der VM nach Bedarf neu generieren, aber auf diese Weise verteilen Sie Ihre Anmeldeinformationen nicht intern, während Sie Ihre Binärversionen archivieren.

    
Joannes Vermorel 02.06.2011 12:44
quelle