fragen stichworte

Müssen alle Server das HTTPS-Protokoll oder nur öffentlich zugängliche Server verwenden?

Ich habe einen Front-End-Webserver, der über HTTPS läuft - dies ist öffentlich ausgerichtet - d. h. der Port ist offen.

Ich habe auch einen Backend-API-Server, an den mein Webserver API-Anforderungen stellt. Dies ist öffentlich und erfordert eine Authentifizierung. Der Port ist geöffnet.

Diese 2 Server laufen über HTTPS.

Hinter dem API-Server befinden sich viele andere Server. Der API-Server führt zu diesen Servern Reverse-Proxies. Ports für diese anderen Server stehen dem eingehenden Datenverkehr nicht offen. Sie können nur über den API-Server angesprochen werden.

Meine Frage ... Müssen die "vielen anderen Server" über HTTPS ausgeführt werden, oder, da sie nicht von außen zugänglich sind, können sie stattdessen sicher über HTTP laufen?

Ich dachte, dies wäre eine häufige Frage, aber ich konnte keine Antwort darauf finden. Vielen Dank. Wenn dies ein Betrug ist, weisen Sie mich bitte auf die richtige Antwort.

antworten

Dies ist eine Frage der Meinung und hat auch mit regulatorischen Problemen zu tun (wenn Sie irgendwelche Probleme haben).

Auch wenn es derzeit nicht notwendig ist, befürworte ich, dass HTTPS zwischen Firewalls/Load Balancern/Front-End-Servern auf Anwendungsebene und den Back-End-Servern aktiviert bleibt. Es ist eine Angriffsfläche weniger. Ich habe Verträge mit Orten geschlossen, die umgestellt werden mussten, sobald sensiblere Informationen weitergegeben wurden - es ist besser, dort anzufangen.

Was ich im Allgemeinen vorschlagen würde, ist eine interne CA (falls verfügbar) oder ein Self-Sign (wenn keine interne CA) die Back-End-Server. Wir haben das Ablaufdatum schön und weit in die Zukunft gesetzt, um unnötige Änderungen zu vermeiden.

TL; DR Sie sollten den Datenverkehr verschlüsseln, es sei denn, er befindet sich auf demselben Host.

Sie können Ihrem Netzwerk nicht vertrauen. Malware in Ihrem eigenen Netzwerk kann HTTP-Anfragen abfangen/ändern.

Es sind keine theoretischen Angriffe, sondern ein Beispiel aus dem wirklichen Leben:

Do the "lots of other servers" need to run over HTTPS or, given that they cannot be accessed externally, can they run over HTTP safely instead?

Das hängt wirklich davon ab, was Sie erreichen wollen. Der Zweck der Verwendung von HTTPS besteht darin, die Daten beim Übergang zwischen zwei Punkten zu schützen. Wenn Sie befürchten, dass die Daten in Ihrem Netzwerk erkannt werden, sollten Sie sich zuerst darum kümmern. Wenn Sie die Daten während des Transports in Ihrem Netzwerk schützen müssen, haben Sie entweder Bedenken hinsichtlich der Sicherheit der Daten, die Ihre Systeme in Ihrem Netzwerk durchlaufen, oder es gibt einige Compliance-Gründe für die Verschlüsselung der übertragenen Daten.

Das ist wirklich mehr eine Frage der Meinung, aber die Antwort ist, hängt davon ab. Was versuchst du zu machen? Welche Art von Daten verschlüsseln Sie? Vor welchen Bedrohungen möchten Sie sich schützen? Haben Sie eine gesetzliche Anforderung (z. B. PCI-DSS, HIPAA usw.), nach der Sie die Daten während der Übertragung verschlüsseln müssen? Wenn die Daten sensibel sind und Sie befürchten, dass sie missbraucht werden könnten, wenn sie in Ihrem Netzwerk übertragen werden, würde ich vorschlagen, mit dem Management zusammenzuarbeiten, um das Problem zu beheben. Also, was versuchst du am Ende zu schützen und warum versuchst du es zu schützen?

Früher gingen die Leute davon aus, dass interne Netzwerke als Häuser sicher sind. Ich geriet einmal in einen Streit mit einem Vorgesetzten, der entsetzt war, dass meine internen Server ihre eingebauten Firewalls hatten. "Wenn Sie Ihrem internen Netzwerk nicht vertrauen können, wem können Sie vertrauen?" Ich wies darauf hin, dass wir Schüler Laptops in unserem internen Netzwerk hatten, und dass es keine Firewall zwischen den Laptops der Schüler und meinen Servern gab. Er, neu in der Wissenschaft, schien bei dieser Information sein Universum in Fetzen zu haben.

Interne Netzwerke gelten nicht mehr als sicher, selbst wenn Sie in Ihrem Netzwerk keine Schüler-Laptops haben. Siehe Toms Antwort für einige Beispiele.

Das heißt, ja, es kommt darauf an, welche Informationen übertragen werden, auf irgendwelche rechtlichen Compliance-Fragen, etc. Sie könnten entscheiden, dass es Ihnen egal ist, wenn jemand, sagen wir, Wetterdaten schnüffelt. Das heißt, es ist möglich, dass jemand, selbst wenn die gesendeten Daten nicht sensibel jetzt sind, beschließen könnte, Funktionen später zu Ihrer Anwendung hinzuzufügen, die sind empfindlich, also würde ich mehr empfehlen Paranoia (einschließlich HTTPS).

Heute, mit spezialisierten CPU-Anweisungen zur Beschleunigung der Verschlüsselung, und neuen Transportprotokollen, die überhaupt nicht funktionieren oder mit einer verschlechterten Leistung über einen unverschlüsselten Link (HTTP/2, gRPC, etc ...) funktionieren, ist vielleicht die bessere Frage: Gibt es einen Grund, warum Sie eine Netzwerkverbindung zu HTTP herabstufen müssen? Wenn es keinen bestimmten Grund gibt, bleibt die Antwort bei HTTPS.

Der einzige Grund, die Verschlüsselung zu deaktivieren, ist die Leistung. In Ihrem Fall sind interne Server jedoch über HTTP miteinander verbunden, was bedeutet, dass sie bereits die Kosten für die Ausführung eines Webservers tragen, das HTTP-Protokoll unterstützen und Daten in HTTP/JSON/was auch immer codieren. Wenn Sie die Verschlüsselung deaktivieren, werden möglicherweise 100 KB RAM freigegeben und Sie erhalten ein paar Mikrosekunden pro übertragener KB-Daten, was keinen sichtbaren Einfluss auf die Gesamtleistung hat. Auf der anderen Seite müssen Sie der Sicherheit deutlich mehr Aufmerksamkeit schenken, da Sie jetzt HTTP in Ihrem Intranet ausführen. In der Tat ist es möglich, dass eine strengere Firewall-Konfiguration die Dinge verlangsamen wird, mehr als die Deaktivierung der Verschlüsselung hat sie beschleunigt, was zu einer schlechteren Leistung führt, die von Endbenutzern wahrgenommen wird.

Es wird so sein, als würde man einen Spoiler auf einen Traktor setzen: Man gewinnt theoretisch so gut wie nichts und praktisch viele Unannehmlichkeiten.