Die Antwort auf Ihre Frage lautet "Bedrohungsmodellierung". Die Verwendung kryptografischer Protokolle wie HTTPS ist ein Sicherheitsmechanismus zum Schutz vor bestimmten Bedrohungen. Wenn diese Bedrohungen für Sie relevant sind, müssen sie analysiert werden:

• Gibt es potenzielle Bedrohungsakteure in Ihrem internen Netzwerk? Aufgrund Ihrer Frage scheinen Sie davon auszugehen, dass die internen Netzwerk kann voll vertrauenswürdig sein. Dies ist häufig ein Missverständnis, da Ihr internes Netzwerk auf verschiedene Weise kompromittiert werden kann (z. B. werden gültige Benutzer mit Zugriff auf dieses Netzwerk bösartig, ein System in diesem Netzwerk wird kompromittiert, eine Fehlkonfiguration öffnet das Netzwerksegment usw.).

Dies sind wichtige Themen, die analysiert werden sollten. Wenn ich Systemarchitekturen entwerfe und Zweifel habe, ziehe ich es vor, auf der Seite der Sicherheit zu irren. In diesem Fall verwendet der Best-Practice-Ansatz in der Tat HTTPS für die Kommunikation, unabhängig von den Umständen, solange keine wesentlichen Auswirkungen auf die Anwendung bestehen (z. B. Auswirkungen auf die Leistung).

Die Schwierigkeit, Serverzertifikate zu verwalten, sollte heutzutage kein Problem mehr sein, da dies gängige Praxis ist. Dies sollte Teil der normalen geplanten Betriebsaktivitäten sein.

Nach alledem ist natürlich ein zusätzlicher Aufwand erforderlich, um HTTPS anstelle von HTTP zu verwenden, und Sie haben das Recht, dem Kunden diesen zusätzlichen Aufwand in Rechnung zu stellen. Ich schlage vor, dass Sie berechnen, was dies während der Entwicklung und im Laufe der Zeit während des Betriebs kostet, und den Kunden entscheiden lassen, ob die Kosten den Nutzen wert sind.

Das Mischen und Anpassen von HTTP und HTTPS ist keine gute Idee - Sie werden ständig mit Konfigurationen jonglieren.

Normalerweise sollte das Hinzufügen einer Komponente zu einem System nur erfolgen, wenn es einen bestimmten Grund dafür gibt. Nur weil jemand dachte, es sei eine gute Idee, ist dies kein spezifischer Grund.

Ich sage nicht, dass HTTPS eine schlechte Idee ist - im Gegenteil -, aber Sie müssen viel lernen. Das von Ihnen vorgeschlagene Modell untergräbt die Vertrauensbeziehung, die der Hauptgrund für die Verwendung von TLS ist. Sie scheinen auch nicht darüber nachgedacht zu haben, wie Sie Ihre PKI planen sollen.

Server, die eines Tages in der Zukunft defekt sind, weil auf einem Server das Zertifikat abgelaufen ist und niemand weiß,

Wenn Sie den Dienst bereitstellen, sollten Sie die Überwachung konfigurieren für den Dienst, einschließlich Ablauf des Zertifikats.

Es hört sich so an, als würden Sie nach Gründen suchen, um mit dem Ansatz der Einführung von Zertifikaten zu argumentieren. Wenn Sie hier zwischen den Zeilen lesen, scheinen Ihnen derzeit die Fähigkeiten und die Planung zu fehlen, die Sie zur Implementierung benötigen.

Ja, es ist viel Arbeit, aber das ist das Geschäftsmodell - Sie bewerten den Arbeitsaufwand, die Fähigkeiten, die Sie erwerben müssen, und die, die Sie kaufen können, und die Sie dem Kunden in Rechnung stellen. (Serge hebt die Kosten für die Zertifikate hervor - dies sind jedoch die geringsten Kosten in dieser gesamten Übung.)

Interne Netzwerke sind nicht sicher

Interne Netzwerke sind im Allgemeinen sicherer als öffentlich zugängliche Systeme, sollten jedoch nicht als vollständig sicher angesehen werden. Ein erheblicher Teil der Angriffe kommt von innen - Spearphishing, Social Engineering und Insider-Angriffe sind beliebte Vektoren, die mit einem Halt in Ihrem Netzwerk beginnen.

Es gibt also keinen guten Grund für unverschlüsselten geheimen oder privaten Verkehr Informationen auch über Ihre internen Netzwerke. Sie benötigen nicht unbedingt öffentliche Namen oder CA-Hierarchien. Wenn Sie über genau definierte bilaterale Kommunikationskanäle verfügen, ist es möglicherweise einfacher, eine explizite Vertrauensbeziehung zu haben, in der Ihre Load-Balancer so konfiguriert sind, dass sie einem bestimmten selbstsignierten Zertifikat von Ihnen vertrauen Backend-Server und sonst nichts.

Als Fachmann schulden Sie Ihrem Kunden Ratschläge, sollten die Entscheidung jedoch nicht selbst treffen.

Die Argumente, die Sie Ihrem Kunden vorlegen müssen, sind:

• was ist der Gewinn bei der Verwendung von HTTPS innerhalb des Servernetzwerks? Wenn dieses Netzwerk von einem anderen System isoliert ist und nur Systemadministratoren darauf zugreifen können, können Sie argumentieren, dass der Gewinn vernachlässigt werden kann, da es nur ein System vor jemandem schützt, der bereits über Administratorrechte verfügt. Wenn andere Mitarbeiter ohne Administratorrechte darauf zugreifen können, ist der Gewinn nicht null, ebenso wenig wie Systeme für andere Kunden.
• Wie hoch ist das Risiko, dies zu tun? Die Disgression auf Zertifikaten ist hauptsächlich ... eine Disgression. Tatsache ist jedoch, dass HTTPS ein komplexeres Protokoll als HTTP ist und jede zusätzliche Komplexität das Risiko von Implementierungsfehlern erhöht. Wenn der vorherige Schritt zu dem Schluss kam, dass der Gewinn vernachlässigbar ist, reicht dies aus, um den Kunden davon abzubringen.
• Was wären die zusätzlichen Kosten? Hier müssen direkte und indirekte Kosten berücksichtigt werden. Zu den direkten Kosten können der Preis für zusätzliche Zertifikate gehören, wenn Sie externe Zertifikate verwenden, oder die Zeit für die Erstellung privater Zertifikate, wenn Sie eine private PKI verwenden. Sie würden auch die Zeit für die Konfiguration des Systems enthalten. Und sie sollten die Wartungszeiten als wiederkehrende Kosten enthalten, einschließlich einer programmierten Erneuerung von Zertifikaten - dieser Teil befindet sich in Ihrer Verantwortungsdomäne, aber Sie können Ihrem Kunden die Zeit in Rechnung stellen. Indirekte Kosten sind schwerer zu ermitteln, aber Sie sollten Ihre eigenen Erfahrungen nutzen, um das Fehlerrisiko aufgrund der zusätzlichen Komplexität und ihrer möglichen Folgen zu bewerten. Und IMHO können Sie Ihrem Kunden dies in Rechnung stellen, wenn er darauf besteht, Ihren Ratschlägen nicht zu folgen.

Wenn Sie jedoch alles gesagt haben, ist der Kunde für die Entscheidung verantwortlich.

Verschlüsselung ist billig. Datenlecks oder Datenverlust sind dies nicht.

Verwenden Sie die Verschlüsselung zwischen Servern (und es ist sogar noch besser, die TLS-Authentifizierung zwischen Servern zu verwenden).

Und wenn ich billig sage, ist es sogar billig unter Berücksichtigung der Verwaltung der Schlüssel und der Zertifikate. Es kann sinnvoll sein, beiden Servern selbstsignierte und langlebige Zertifikate auszustellen.

Es gibt einige Ausnahmen von der Regel:

1. Entweder die Client oder Server sind Legacy-Systeme mit bekannten SSL / TLS-Schwachstellen. Es ist immer besser, den anfälligen Code zu aktualisieren, aber wir alle wissen, dass dies nicht immer möglich ist. Manchmal ist es besser (immer noch nicht gut, aber besser), den anfälligen Code vollständig zu deaktivieren, Klartext auszuführen und die Risiken auf die eine oder andere Weise zu mindern.

2. Sie tauschen einen Wahnsinnigen aus Datenmenge und / oder benötigen eine wahnsinnig niedrige Latenz. Die Verschlüsselung kann zu einem Engpass und / oder einem Ressourcenfresser werden. Sie können sich für keine Verschlüsselung entscheiden und auch etwas anderes tun, um das Ding zu sichern.

ol>

"https" sichert nicht nur die Kommunikation über das Netzwerk, sondern überprüft auch das vom Server vorgelegte Zertifikat . Auf diese Weise können Sie feststellen, dass Sie wirklich mit der richtigen Site sprechen. Und dies ist meiner Meinung nach der eigentliche Vorteil von "https".

"letsencrypt.org", das signierte Zertifikate kostenlos ausstellt, hat auf seiner Website viel Material, in dem diese Vorteile erörtert werden . Sie argumentieren ... zu Recht, ich denke ... dass "alles https sein sollte, ob das Material tatsächlich empfindlich ist oder nicht."

( mod_ssl et al ist auch in der Lage, den Zertifikatsbesitz auf der Client -Seite zu erzwingen, obwohl dies selten der Fall ist. Für eine sichere interne Anwendung möchten Sie jedoch möglicherweise so etwas tun Der Server kann dann einschränken, welche Computer überhaupt eine Verbindung herstellen können, und sie durch die Anmeldeinformationen einschränken, über die sie verfügen müssen.)