it-swarm.com.de

Sind Zertifikate für Intranet-SSL nützlich?

Ich wurde mit der Entwicklung einer Intranet-Schnittstelle für Befehlszeilensoftware beauftragt und untersuche nun die Sicherheitsoptionen. Unsere Befehlszeilenanwendung ist fertig, aber ich habe noch nicht begonnen, das Webinterface zu schreiben. Ich weiß nicht genau, welche Sicherheitsanforderungen für potenzielle Kunden gelten, obwohl ich der Meinung bin, dass ssh für die Befehlszeilenschnittstelle im Allgemeinen akzeptabel ist. In diesem Sinne bitte ich um Hilfe bei der Entwicklung eines Auswahlmenüs mit den damit verbundenen Vor- und Nachteilen. Eines Tages werden wir möglicherweise erwägen, unser Webinterface für das Internet freizugeben. Daher bin ich bereit, mehr Sicherheit in Betracht zu ziehen als derzeit erforderlich, wenn dies einfach und/oder kostenlos ist.

Ich habe viel gelesen und meine vorläufige Schlussfolgerung ist, dass SSL-Sicherheit ohne Zertifikat der beste Ansatz ist, nicht weil weniger Sicherheit inakzeptabel ist, sondern weil SSL der Standard ist und weil es nicht schwierig zu sein scheint installieren. Ich, ein Nicht-Experte für Sicherheitsfragen, würde nicht erklären müssen, warum für Nicht-Experten für Sicherheitsfragen weniger Sicherheit akzeptabel ist. Falls erforderlich, kann ich meine Anwendung aktualisieren, um in Zukunft ein Zertifikat zu verwenden.

Hier ist eine Liste der SSL-bezogenen Sicherheitsoptionen, sortiert nach meiner Wahrnehmung der Sicherheitsstufe mit meinen Kommentaren. Welches Schutzniveau brauche ich?

  1. Kein SSL. Dies kann akzeptabel sein, wenn unsere Kunden nicht befürchten, dass ihre Mitarbeiter die Daten der jeweils anderen sehen oder ändern. Ihre Mitarbeiter möchten die Ergebnisse möglicherweise trotzdem miteinander teilen, und ich könnte aus Sicherheitsgründen eine IP-basierte Zugangskontrolle und/oder Passwörter verwenden.

  2. SSL ohne Zertifikat ausführen. Dadurch wird die Kommunikation verschlüsselt, wodurch die Daten zumindest vor dem Lesen durch nicht autorisierte Mitarbeiter geschützt werden. Bei Verwendung eines Kennworts entspricht dies der Sicherheitsstufe von ssh in der Befehlszeile, richtig? Ich muss mir keine Sorgen um Man-in-the-Middle-Angriffe in einem Intranet machen, oder? Ein Nachteil für diesen Ansatz wäre, wenn es viele Browser-Warnmeldungen gäbe.

  3. Verwenden Sie SSL mit einem selbstsignierten Zertifikat. Was bringt mir das, das mir kein Zertifikat gibt? Wenn der DNS unangemessen geändert werden kann, ist der Kunde derjenige, der sich am wenigsten um meine Anwendung kümmert. Anders ausgedrückt, wenn sich der DNS ändern kann, dann denke ich, dass ssh auch anfällig wäre.

  4. Führen Sie SSL mit einer lokalen Zertifizierungsstelle durch. Mit OpenSSL kann ich meine eigene Zertifizierungsstelle erstellen. Was bringt mir das, dass ein selbstsigniertes Zertifikat nicht funktioniert? Ich gehe davon aus, dass in einem LAN die Überprüfung des Servers weniger wichtig ist.

  5. Führen Sie SSL mit einer externen Zertifizierungsstelle durch. Gibt es jemals einen Grund, diesen Weg für ein Intranet einzuschlagen? Ich habe einige "Intranet-Zertifikate" zum Online-Verkauf gefunden - aber es ist nicht klar, was sie anbieten, ich kann es nicht selbst tun.

Als Referenz kann diese Seite hilfreich sein, um Zertifikate zu vergleichen:

http://httpd.Apache.org/docs/trunk/ssl/ssl_faq.html#aboutcerts

[aktualisieren]

hier ist ein Artikel, in dem die Risiken und Regeln für das Erhalten eines internen Zertifikats von einer öffentlichen Zertifizierungsstelle erläutert werden.

37
amos

Ja, Zertifikate sind für Intranet-SSL immer noch nützlich.

Es gibt einen wichtigen Unterschied zwischen SSH und SSL ohne Zertifikat: Wenn Sie zum ersten Mal eine Verbindung mit einem Server über SSH herstellen, speichert Ihre SSH den Fingerabdruck des Servers. Wenn Sie dann versuchen, eine Verbindung zu dem herzustellen, von dem der SSH-Client glaubt, dass es sich um denselben Computer handelt, der jedoch einen anderen Fingerabdruck zurückerhält, werden Sie darauf hingewiesen, dass möglicherweise jemand Ihre Kommunikation abfängt.

SSL-without-a-certificate speichert dagegen nicht den Fingerabdruck des Servers. Ihre Kommunikation wird weiterhin verschlüsselt, aber wenn jemand den DNS-Server wie von Ihnen erwähnt hijackt oder, wie Rushyo bemerkt ARP-Vergiftungen oder ähnliches vornimmt, kann er eine mitten im Angriff. Wie bereits erwähnt, würde SSH (vorausgesetzt, Sie haben sich in der Vergangenheit mit dem richtigen Server verbunden) feststellen, dass sich der Fingerabdruck geändert hat, und Sie warnen.

Ein selbstsigniertes Zertifikat wäre hinsichtlich der Sicherheit mit SSH vergleichbar. Ein Mann in der Mitte könnte sein eigenes selbstsigniertes Zertifikat generieren. Solange Ihre Anwendungen jedoch so konfiguriert sind, dass sie nur das selbstsigniertes Zertifikat akzeptieren, sollten Sie eine Warnung erhalten, die der von SSH ähnelt Sie.

Eine lokale Zertifizierungsstelle bietet Ihnen eine ähnliche Sicherheit wie selbstsignierte Zertifikate, ist jedoch möglicherweise skalierbarer. Wenn Sie mehrere Server haben, kann jeder sein eigenes Zertifikat haben, aber ein Client benötigt nur den obersten, um allen zu vertrauen. Wenn ein Server gefährdet ist, können Sie sein Zertifikat widerrufen, anstatt das Zertifikat jedes Servers ändern zu müssen.

Ich glaube nicht, dass eine externe Zertifizierungsstelle Vorteile hat, abgesehen von möglicherweise weniger Konfiguration, wenn Ihre Computer bereits über eine vertrauenswürdige Zertifizierungsstelle verfügen.

Schließlich weiß ich nicht genug über die Zwei-Faktor-Authentifizierung, um sie zu bewerten, aber für die meisten Anwendungen sollte SSL ausreichen.

Haftungsausschluss: Ich bin kein Sicherheitsexperte.

21
icktoofay
  1. Führen Sie SSL mit einer externen Zertifizierungsstelle durch. Gibt es jemals einen Grund, diesen Weg für ein Intranet einzuschlagen? Ich habe einige "Intranet-Zertifikate" zum Online-Verkauf gefunden - aber es ist nicht klar, was sie anbieten, ich kann es nicht selbst tun.

Der Vorteil ist, dass Sie nicht lernen müssen, wie Sie Ihre eigene Zertifizierungsstelle einrichten, wenn Sie eine angemessene Anzahl von Zertifikaten und/oder Computern verwalten müssen. Ein solches Zertifikat wird bereits von allen Browsern als vertrauenswürdig eingestuft, ohne dass Sie Ihre eigenen Zertifikate im vertrauenswürdigen Speicher installieren müssen.

Dies ist jedoch weniger sicher, da jemand ein Zertifikat für ein anderes Intranet erwerben und in Ihrem Netzwerk verwenden kann. Aus diesem Grund bieten SSL-Anbieter diesen Service nicht mehr an. Weitere Informationen finden Sie unter: https://www.godaddy.com/help/phasing-out-intranet-names-and-ip-addresses-in-ssls-6935

Wenn Sie nur ein sehr kleines Intranet haben, empfehle ich die Verwendung eines selbstsignierten Zertifikats und füge dann jedes selbstsignierte Zertifikat dem vertrauenswürdigen Speicher jedes Computers hinzu.

Es wird jedoch schnell unpraktisch, auf jedem Computer in Ihrem Intranet ein neues Zertifikat zu installieren, wenn Sie einen neuen Computer hinzufügen möchten. Zu diesem Zeitpunkt möchten Sie Ihre eigene Zertifizierungsstelle einrichten, sodass Sie nur ein einziges CA-Zertifikat im vertrauenswürdigen Speicher jedes Computers installieren müssen.

4
geofflee