Wie bewahre ich den SSL-Schlüssel für unsere Website vertraulich auf?


12

Ich möchte unseren SSL-Schlüssel für unsere Website vertraulich behandeln. Es ist auf 2 USB-Sticks gespeichert, einen in einem Safe und einen, den ich aufbewahre. Und dann bin ich der einzige, der es auf den Webserver anwendet, so dass es absolut sicher ist.

Außer...

Zumindest in IIS können Sie den Schlüssel exportieren. So kann jeder, der Administrator ist, eine Kopie des Schlüssels erhalten. Gibt es einen Weg, dies zu umgehen? Oder haben per Definition alle Administratoren vollen Zugriff auf alle Schlüssel?

Update: Ich habe Sysadmins, denen ich voll und ganz vertraue. Was dazu geführt hat, ist, dass einer von ihnen gekündigt hat (sie hatten eine Stunde Fahrt zu unserer Firma, eine 5-minütige Fahrt zur neuen). Ich vertraue dieser Person, genau wie wir ihr Active Directory-Konto deaktivieren, wenn jemand das Unternehmen verlässt. Ich dachte jedoch, wir sollten einen Weg finden, um sicherzustellen, dass sie nicht in der Lage sind, unser SSL zu verwenden.

Und was mir am leichtesten gefallen hat, ist, wenn ich der einzige bin, der es hat. Unser Zertifikat läuft im Januar aus, daher war dies die Zeit, die Praxis zu ändern, wenn wir konnten. Aufgrund der Antworten sieht es so aus, als könnten wir nicht.

Dies führt zu einer neuen Frage: Wenn jemand, der Zugriff auf das Zertifikat hat, das Unternehmen verlässt, ist es üblich, ein neues Zertifikat zu erhalten und das vorhandene zu widerrufen. Oder wenn die Person, die gegangen ist, vertrauenswürdig ist, fahren wir dann mit dem Zertifikat fort, das wir haben?


5
Auch wenn der von Ihnen verwendete Server das Exportieren nicht zugelassen hat, muss er sich im Arbeitsspeicher befinden und kann daher extrahiert werden. Die einzige Option, die ich sehe, ist die Verwendung eines Hardware-Kryptomoduls, wie z. B. einer Smartcard, die nur eine mit dem Schlüssel enthält, aber jeder, der physischen Zugriff auf das Gerät hat, könnte es stehlen. Sie können es trotzdem widerrufen, wenn es gestohlen wurde.
user2313067

27
Wenn Sie Ihren Administratoren nicht vertrauen können, haben Sie ein HR-Problem.
Michael Hampton

5
Warum haben Sie den Schlüssel überhaupt auf diese USB-Medien kopiert? Der mit SSL verwendete geheime Schlüssel muss sich nicht an anderen Orten als dem Server befinden, auf dem er verwendet wird. (Es kann natürlich in Sicherungskopien des Servers enthalten sein, aber es ist weniger wichtig, diesen Schlüssel als die anderen Daten auf dem Server zu sichern, da Sie jederzeit einen neuen geheimen Schlüssel generieren und ihn signieren lassen können, wie Sie es mit dem getan haben altes.)
Kasperd

Ich bin kein Experte auf diesem Gebiet, aber gibt es keine Hardware-Verschlüsselungsmodule, die einen Schlüssel enthalten, der in ihnen verbleibt und nur die Signierungsanforderungen eingehen und Signaturen herauskommen? Löten oder Einkleben in den Server könnte die Lösung sein.
10.

Antworten:


26

Eine Person mit administrativem (oder häufig sogar physischem) Zugriff auf einen Server kann den privaten Schlüssel extrahieren. Sei es durch Exportieren, Memory Sniffing oder andere derartige Tricks.

Ihre Administratoren haben Zugriff auf die privaten Schlüssel Ihrer Webserver. Akzeptieren Sie dies als Tatsache und umgehen Sie dies. Wenn Ihre Sysadmins nicht vertrauenswürdig sind, benötigen Sie möglicherweise bessere Sysadmins oder mindestens weniger Sysadmins mit Zugriff auf die Webserver. Wenn es um Managementsicherheits-Paranoia geht, kann es zu einem tieferen Problem hinsichtlich der Fähigkeit kommen, einem Systemadministrator zu vertrauen.

Das soll nicht heißen, dass Sie einfach jedem Zugriff auf den privaten Schlüssel gewähren sollten. Es sollte immer eine Zugangsbedürftigkeit bestehen, bevor der Zugang gewährt wird. Wirst du vor diesem Hintergrund extreme Maßnahmen ergreifen, um sicherzustellen, dass ein Sysadmin mit vollständiger Kontrolle über eine Website den privaten Schlüssel nicht exportieren kann, die Website selbst jedoch auf eine beliebige Anzahl von nahezu unauffindbaren Arten manipulieren kann? Wir können hier wieder vertrauen, und ich denke, das ist der Kern des Problems, das angegangen werden muss.


2
+1 für "Ihre Administratoren haben Zugriff auf die privaten Schlüssel Ihrer Webserver. Akzeptieren Sie dies als Tatsache und umgehen Sie das". Fragen zu "Wie verhindere ich, dass Benutzer mit Administratorrechten X ausführen?" zeige mir ein tieferes Problem an. Entweder zu misstrauisch oder zu lässig bei der Vergabe von Administratorrechten.
Brandon

2
Ich habe aktualisiert, warum ich gefragt habe. Es geht nicht um die Sysadmins, sondern darum, Best Practices zu befolgen.
David Thielen

11

Wenn Sie den Schlüssel importieren, können Sie ihn als nicht exportierbar markieren. Dadurch wird verhindert, dass Sie IIS oder die Zertifikat-MMC zum Exportieren verwenden. Zumindest wird es dadurch etwas schwieriger.

Wenn sie jedoch ein Administratorkonto auf dem Computer haben oder physischen Zugriff darauf haben, können sie den Schlüssel auch auf andere Weise erhalten.


1
Es ist wirklich nicht viel schwieriger. isecpartners.com/tools/application-security/jailbreak.aspx
Greg Askew

0

Hier kann eine "Intermediate CA" Abhilfe schaffen.

Die "Stammzertifizierungsstelle" in diesem Beispiel gehört einer SSL-Firma und Ihnen nicht.

Sie haben keine direkte Kontrolle über die von der Stammzertifizierungsstelle erstellten Schlüssel. Wenn also ein von der Stammzertifizierungsstelle signierter Schlüssel kompromittiert wird, müssen Sie ihn durchgehen, um ihn zu widerrufen.

Aber:

Root CA (SSL company)
 |
 +-Intermediate CA (You)
   |
   +-Server Key for site

Wenn Sie eine andere Zertifizierungsstelle in die Mitte legen und Ihr gekauftes SSL-Zertifikat Ihr eigenes Zertifizierungsstellenzertifikat signieren lässt, anstatt Ihr Serverzertifikat direkt zu signieren, können Sie die Kontrolle über die unten aufgeführten Serverzertifikate behalten und Sperrzertifikate ausstellen oder andere Aktionen ausführen, wenn die darunter liegenden Punkte beeinträchtigt werden .

Sie behalten den privaten Schlüssel der Zwischenzertifizierungsstelle für sich und die Administratoren müssen ihn nicht sehen.

Sie können dies auch tun:

Root CA (SSL company)
 |
 +-Intermediate CA (You)
   |
   +-Server Key 1 for site
   +-Server Key 2 for site 
   +-Server Key 3 for site

Sie können sich auf einen Kompromiss vorbereiten und Zertifikate im Voraus generieren, um bei einem Widerruf eines einzelnen Schlüssels schnell zu wechseln. Administratoren erhalten erst nach dem Kompromiss von 1 Schlüssel für 2 oder 3. Sie können auf Ihrer Website einen Hinweis zu diesem Schema platzieren. Dies würde auch Ihren Administratoren mitteilen, dass Sie im Falle eines Kompromisses bereit sind und dass das Geschäft lustig ist Ende wird Ihre Website nicht zerstören.


1
Würde dies nicht zu SSL-Warnungen für Benutzer einer nicht vertrauenswürdigen Zertifizierungsstelle führen?
Ceejayoz

1
Ich denke, dies würde nur dann gut funktionieren, wenn Sie die Zertifizierungsstelle als vertrauenswürdiges Zertifikat im Browser des Benutzers installieren können, z. B. in einer Intraneteinstellung eines Unternehmens. Ich wusste, dass etwas mit meinem brillanten Schema nicht stimmte. :(
LawrenceC

0

Es gibt viele Artikel, in denen vorgeschlagen wird, die privaten Schlüssel an einem anderen Ort als dem Server zu speichern. Diese privaten Schlüssel sind jedoch für Codesignaturzertifikate bestimmt . Stellen Sie sich vor, Sie haben die Schlüssel auf einem Offline-Computer, auf die nur Sie Zugriff haben, einige Software sind geschrieben, Sie erhalten den privaten Schlüssel vom Offline-Server, signieren den Code und benötigen den privaten Schlüssel erst dann wieder, wenn Sie einen signieren müssen Code erneut.

Die beste Lösung war und ist die Offline-Speicherung Ihres Schlüssels. Wie Sie es tun, liegt ganz bei Ihnen (es gibt einige Methoden). Denken Sie daran, es gut geschützt in einem Bürosafe aufzubewahren oder an einem Ort, an dem es für jemanden nicht leicht ist, es in die Tasche zu stecken.

Lesen Sie mehr unter: https://www.thesslstore.com/blog/heres-what-happens-when-your-private-key-gets-compromised/

Im Gegensatz dazu sind SSL-Zertifikate für Websites vorgesehen, um die HTTPS-Kommunikation zu ermöglichen: Der private Schlüssel wird bei jedem Handshake vom Webserver benötigt. Daher funktioniert das Speichern offline nicht.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.