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 zugänglich - dh der Port ist offen.

Ich habe auch einen Back-End-API-Server, an den mein Webserver API-Anforderungen sendet. Dies ist öffentlich und erfordert eine Authentifizierung. Der Port ist offen.

Diese 2 Server laufen über HTTPS.

Hinter dem API-Server gibt es viele andere Server. Der API-Server kehrt Proxys zu diesen Servern um. Ports für diese anderen Server sind für eingehenden Datenverkehr nicht geöffnet. Sie können nur über den API-Server angesprochen werden.

Meine Frage ... Müssen die "vielen anderen Server" über HTTPS laufen oder können sie stattdessen sicher über HTTP laufen, da kein externer Zugriff möglich ist?

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

Dies ist eine Ansichtssache und hat auch mit regulatorischen Problemen zu tun (falls Sie damit konfrontiert sind).

Auch wenn es derzeit nicht erforderlich ist, bin ich ein großer Befürworter der Aktivierung von HTTPS zwischen Firewalls / Load Balancern / Front-End-Servern auf Anwendungsebene und Back-End-Servern. Es ist eine Angriffsfläche weniger. Ich habe Verträge mit Orten abgeschlossen, die konvertiert werden mussten, als vertrauliche Informationen weitergegeben wurden - es ist besser, dort zu beginnen.

Im Allgemeinen würde ich vorschlagen, die Back-End-Server mit einer internen Zertifizierungsstelle (falls verfügbar) oder selbst zu signieren (falls keine interne Zertifizierungsstelle vorhanden). Wir würden das Ablaufdatum schön und weit in die Zukunft verschieben, 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-Anforderungen abfangen / ändern.

Es handelt sich nicht um theoretische Angriffe, sondern um ein reales Beispiel:

• Router (wahrscheinlich gehackt) innerhalb des Netzwerks einiger Websites, auf denen Werbung eingeblendet wird: https://www.blackhat.com/docs/us-16/materials/us-16-Nakibly-TCP-Injection-Attacks-in-the-Wild- A-Large-Scale-Study-wp.pdf

• Indisches Netzwerk schnüffelt zwischen Cloudfare und Backend: https://medium.com/@karthikb351/airtel-is-niffing-and-censoring-cloudflares-traffic-in-india-and-they-don-teven-know -it-90935f7f6d98 # .hymc3785e

• Das mittlerweile berühmte "SSL hier hinzugefügt und entfernt :-)" von der NSA

Müssen die "vielen anderen Server" über HTTPS laufen oder können sie stattdessen sicher über HTTP laufen, da von außen nicht auf sie zugegriffen werden kann?

Dies hängt wirklich davon ab, was Sie erreichen möchten. Verstehen Sie, dass der Zweck der Verwendung von HTTPS darin besteht, Daten auf dem Weg zwischen zwei Punkten zu schützen. Wenn Sie Bedenken haben, dass die Daten in Ihrem Netzwerk abgehört werden, sollten Sie sich zuerst darum kümmern. Wenn Sie die Daten während der Übertragung in Ihrem Netzwerk schützen müssen, müssen Sie entweder Bedenken hinsichtlich der Sicherheit der Daten haben, die Ihre Systeme in Ihrem Netzwerk durchlaufen, oder Sie müssen die Daten während der Übertragung aus Compliance-Gründen verschlüsseln.

Dies ist wirklich eher eine Meinungsfrage, aber die Antwort ist, es kommt darauf an. Was versuchst du zu machen? Welche Art von Daten verschlüsseln Sie? Gegen welche Bedrohungen versuchen Sie sich zu verteidigen? Haben Sie eine gesetzliche Anforderung (z. B. PCI-DSS, HIPAA usw.), die besagt, dass Sie die Daten während der Übertragung verschlüsseln müssen? Wenn die Daten vertraulich sind und Sie befürchten, dass sie bei der Übertragung in Ihrem Netzwerk missbraucht werden, empfehle ich, sich mit dem Management zusammenzutun, um das Problem zu beheben. Also, was versuchst du am Ende zu schützen und warum versuchst du es zu schützen?

Damals 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 ausführen. "Wenn Sie Ihrem internen Netzwerk nicht vertrauen können, wem können Sie dann vertrauen?" Ich wies darauf hin, dass wir Schüler-Laptops in unserem internen Netzwerk hatten und dass es keine Firewall zwischen den Schüler-Laptops und meinen Servern gab. Er, der für die Wissenschaft neu war, schien bei diesen Informationen sein Universum in Trümmern zu halten.

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

Das heißt, ja, es hängt davon ab, welche Informationen übertragen werden, ob es um die Einhaltung gesetzlicher Bestimmungen geht usw. Sie können sich entscheiden, dass es Ihnen egal ist, ob jemand beispielsweise Wetterdaten schnüffelt. Das heißt, es ist möglich, dass, selbst wenn die gesendeten Daten jetzt nicht vertraulich sind , jemand später Funktionen zu Ihrer Anwendung hinzufügt, die vertraulich sind. Daher würde ich eine größere Paranoia (einschließlich HTTPS) empfehlen.

Heutzutage mit speziellen CPU-Befehlen zur Beschleunigung der Verschlüsselung und neuen Transportprotokollen, die über eine unverschlüsselte Verbindung (HTTP / 2, gRPC usw.) überhaupt nicht oder nur eingeschränkt funktionieren, ist die bessere Frage vielleicht: Gibt es welche? Grund, warum Sie eine Netzwerkverbindung auf HTTP downgraden müssen? Wenn es keinen bestimmten Grund gibt, lautet die Antwort: Bleiben Sie bei HTTPS.

Der einzige Grund, warum ich die Verschlüsselung deaktivieren kann, ist die Leistung. In Ihrem Fall sind interne Server jedoch über HTTP verbunden, was bedeutet, dass sie bereits die Leistungskosten für den Betrieb eines Webservers tragen, das HTTP-Protokoll unterstützen und Daten in HTTP / JSON / whatever codieren. Durch Deaktivieren der Verschlüsselung werden möglicherweise 100 KB RAM frei und Sie erhalten ein paar Mikrosekunden pro KB übertragener Daten, was keine sichtbaren Auswirkungen auf die Gesamtleistung hat. Andererseits müssen Sie der Sicherheit erheblich 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 Leistung verlangsamt, anstatt sie durch Deaktivieren der Verschlüsselung zu beschleunigen, was zu einer schlechteren Leistung für die Endbenutzer führt.

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