REST-APIs und Sicherheit auf Nachrichtenebene

Question

REST-APIs und Sicherheit auf Nachrichtenebene

8

Ich muss die Sicherheit auf Nachrichtenebene in einer REST-API implementieren und einige Bedenken und Fragen haben. Ich habe die Antwort hier gefunden: Sicherheit auf Nachrichtenebene in Rest-Webdiensten

nur teilweise hilfreich.

Wir unterstützen derzeit die Standard-SSL-Transportsicherheit und verschiedene Authentifizierungsmethoden einschließlich:

Grundlegende HTTP-Authentifizierung (wird von einigen Netzwerkausrüstungsdiensten benötigt, die Sprechen Sie mit unseren APIs)
HMAC mit Pre-Shared-Secrete-Schlüssel in den SHA1- und SHA256-Varianten.
Die Client-Identität wird an die TLS-Ebene gesendet.
SAML 2.0

Warum wir Sicherheit auf Nachrichtenebene benötigen, weil:

Zu den Kundenindustrien zählen unter anderem das Gesundheitswesen, die Finanz- und die Regierungsbehörden, und sie missbilligen oft nur SSL.
Müssen die Sicherheit von Ende zu Ende garantieren. Durch Reverse-Proxies, SSL-Beschleuniger usw. ...
Einige Daten, die über die Dienste übertragen werden, enthalten sehr vertrauliche Daten.
Brauchen Sie eine gute Antwort für Kunden, die darauf bestehen, dass die SOAP WS-* Sicherheitsstandards "Enterprise-Stärke" Web-Services und REST-APIs nicht sind.

Mein erster Gedanke ist die Verwendung eines PKCS # 7-Umschlags als Option, wenn Client-Anwendungen verstehen, wie man umhüllte Antworten verarbeitet.

Ich möchte, dass Clientanwendungen der API mitteilen, dass sie eine gesicherte Antwort erhalten möchten, oder der API mitteilen, dass die Nachricht, die sie POSTing oder PUTing erhalten, gesichert ist.

Meine eigentliche Frage ist, ob dies über einen Medientyp kommuniziert werden soll. Zum Beispiel:

Inhaltstyp: application / vnd.resourcetype1 + json + pkcs7
Inhaltstyp: txt / csv + pkcs7

Ich möchte keine Informationen über den umhüllten Medientyp verlieren.

Es wird kompliziert, da in einigen Fällen die Signatur ausreicht. Andere erfordern ebenfalls eine Verschlüsselung. Der Begriff "pkcs7" ist vage, wie der Umschlag konstruiert wird.

Ich möchte, dass der Client und der Server einander den Typ des Inhalts mitteilen, den sie senden, und den Typ des Inhalts, den sie durch Standard-HTTP-Header verstehen.

security rest web-services pkcs#7

user1758003 19.10.2012, 02:17

quelle

1 Antwort

Tags und Links security rest web-services pkcs#7

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Howto debuggen: Git Pull hängt während Git Pull (immer bei 54%)

score 1 · Accepted Answer

Natürlich liegt es an Ihnen, wie Sie Ihre API definieren, es gibt jedoch keinen richtigen oder falschen Weg S / MIME ist ein sehr gut verstandenes Nachrichtenformat, gut geeignet für das Internet. Wie auch PGP / MIME , wenn Sie eine dezentrale Sicherheitshierarchie bevorzugen. Da diese Formate gut verstanden werden, können Clients vorhandene Bibliotheken zur Verarbeitung dieser Nachrichtentexte übernehmen.

Wenn Sie möchten, dass Sie keine mehrteilige Antwort verwenden möchten, sollten Sie sich die Content-Encoding Header, neben nur Content-Type. Sie könnten dann das Signatur- / Verschlüsselungsformat als benutzerdefinierten Codierungstyp angeben.

Es gibt erhebliche Vorteile bei der Verwendung von HTTP als Anwendungsprotokoll und nicht nur als Transportprotokoll, aber Sie scheinen das bereits zu verstehen. Stellen Sie sicher, dass Sie die Header Accept * einschließlich der q-Werte korrekt gesetzt und syntaktisch analysiert haben. Hüten Sie sich vor Dingen wie dem Standardwert von q = 1, der gleiche (nicht absteigende) Präferenz bedeutet, und q = 0.