REST-APIs und Sicherheit auf Nachrichtenebene

Question

Ich muss Sicherheit auf Nachrichtenebene in einer REST-API implementieren und habe einige Bedenken und Fragen. 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, darunter:

• Grundlegende http-Autorisierung (erforderlich für einige Netzausrüstungsdienste, die die mit unseren APIs kommunizieren)
• HMAC mit Pre-Shared Secrete Key in den Varianten SHA1 und SHA256.
• Client-Identitätszertifikate, die auf der TLS-Ebene gesendet werden.
• SAML 2.0

Warum wir Sicherheit auf der Nachrichtenebene brauchen, weil:

• Zu den Kunden gehören u. a. das Gesundheitswesen, das Finanzwesen und die öffentliche Verwaltung, die oft nur SSL ablehnen.
• Es muss eine durchgängige Sicherheit gewährleistet sein. Durch Reverse Proxies, SSL-Beschleuniger usw...
• Einige Daten, die über die Dienste übermittelt werden, enthalten sehr sensible Daten.
• Wir brauchen eine gute Antwort für Kunden, die darauf bestehen, dass die WS-*-Sicherheitsstandards von SOAP "unternehmenstaugliche" Webdienste sind und REST-APIs nicht.

Mein erster Gedanke ist, optional einen PKCS#7-Umschlag zu verwenden, wenn die Client-Anwendungen wissen, wie sie umhüllte Antworten verarbeiten können.

Ich möchte, dass Client-Anwendungen der API mitteilen, dass sie eine gesicherte Antwort wünschen, oder der API mitteilen, dass die Nachricht, die sie POSTen oder PUTen, gesichert ist.

Meine eigentliche Frage ist, ob dies durch einen Medientyp vermittelt werden sollte. Z.B.:

• Inhalt-Typ: application/vnd.resourcetype1+json+pkcs7
• Inhalt-Typ: txt/csv+pkcs7

Ich möchte nicht, dass Informationen über die Art des Mediums, das umhüllt wird, verloren gehen.

Es wird kompliziert, denn in manchen Fällen reicht die Unterschrift aus. In anderen ist zusätzlich eine Verschlüsselung erforderlich. Der Begriff "pkcs7" ist unklar, wie der Umschlag aufgebaut ist.

Ich möchte, dass der Client und der Server sich gegenseitig über Standard-HTTP-Header mitteilen, welche Art von Inhalt sie senden und welche Art von Inhalt sie verstehen.

Answer 1

Natürlich ist es Ihnen überlassen, wie Sie Ihre API definieren, es gibt keinen richtigen oder falschen Weg, aber S/MIME ist ein sehr gut verständliches Nachrichtenformat, das sich gut für das Internet eignet. Wie auch PGP/MIME wenn Sie eine dezentralisierte Vertrauenshierarchie bevorzugen. Da es sich um wohlverstandene Formate handelt, können die Kunden bestehende Bibliotheken zur Verarbeitung dieser Nachrichtenkörper übernehmen.

Wenn Sie auf keinen Fall eine mehrteilige Antwort verwenden wollen, sollten Sie einen Blick auf die Content-Encoding Header, außer nur Content-Type. Sie könnten dann das Signatur-/Verschlüsselungsformat als benutzerdefinierten Kodierungstyp angeben.

Die Verwendung von HTTP als Anwendungsprotokoll und nicht nur als Transportprotokoll hat erhebliche Vorteile, aber das scheinen Sie ja bereits zu wissen. Vergewissern Sie sich, dass Sie die Accept*-Header korrekt setzen und auswerten, einschließlich der q-Werte. Achten Sie auf Dinge wie den Standardwert q=1, der gleiche (nicht absteigende) Präferenz bedeutet, und q=0.