Zertifikatsauthentifizierung in Key Vault

Question

Ich habe einige Geheimnisse, die ich in Azure Key Vault aufbewahren möchte. Ich weiß, dass ich ein Client-ID und Zertifikat verwenden kann mit Key Vault zu authentifizieren, anstatt einen Client verwenden und und geheime folgende diese Schritte:

1. erhalten oder ein Zertifikat erstellen
2. Mitarbeitern das Zertifikat mit einer Azure AD Anwendung
3. -Code in Ihre Anwendung hinzufügen das Zertifikat

die meisten Beispiele verwenden entweder makecert oder New-SelfSignedCertificate zu erstellen, das Zertifikat zu verwenden. Ist ein selbstsigniertes Zertifikat in diesem Fall für eine Produktionsanwendung problematisch? Dies ist nur für eine Anwendung erforderlich, die mit Azure Key Vault authentifiziert werden soll. Dies ist nichts, was ein Client jemals in seinem Browser sehen wird.

Wenn ein selbstsigniertes Zertifikat in diesem Fall immer noch verpönt ist, kauft ein Zertifikat von einer vertrauenswürdigen Stelle den gleichen Prozess wie den Kauf eines SSL/TLS-Zertifikats? Ist es sogar die gleiche Art von Zertifikat?

Answer 1

Es gibt (mit einigen Vorbehalten) nichts an sich falsch mit der Verwendung eines selbstsignierten Zertifikats. Es gibt keinen Unterschied zu einer reinen Krypto-Perspektive zwischen einem gekauften und einem selbstsignierten Zertifikat. Der einzige Unterschied besteht darin, dass ein erworbenes Zertifikat von einer oder mehreren Zertifizierungsstellen (CAs) signiert wurde, die ihre öffentlichen Schlüssel mit den meisten Browsern/Betriebssystemen/etc. Dies bedeutet, dass ein Benutzer ein höheres Vertrauen haben kann, dass ein erworbenes Zertifikat legitim ist, während sie einen Vertrauensvorschuss nehmen müssen, um ein selbstsigniertes Zertifikat zu akzeptieren.

In Ihrem Fall scheinen Sie jedoch in der Lage zu sein, die Clientanwendung zu steuern, und tatsächliche Benutzer sollten dieses Zertifikat nie sehen. Daher können Sie ein selbstsigniertes Zertifikat ohne Bedenken verwenden, solange Sie Vorkehrungen treffen, um Man-in-the-Middle-Angriffe zu verhindern (d. H. Jemand, der sein eigenes selbstsigniertes Zertifikat erstellt und so tut, als wären Sie). Eine der effektivsten Methoden hierfür ist das Zertifikats-Pinning. Im Wesentlichen versenden Sie den öffentlichen Schlüssel für Ihr Zertifikat mit Ihrer Clientanwendung, und Ihre Clientanwendung akzeptiert nur Zertifikate, die diesen öffentlichen Schlüssel bereitstellen. Dies macht es für einen böswilligen Akteur (der Ihr Zertifikat nicht gestohlen hat) viel schwieriger, einen Man-in-the-Middle-Angriff zu erzeugen.

TL; DR: Solange Sie Maßnahmen ergreifen, um Man-in-the-Middle-Angriffe zu verhindern, und Sie Ihr Zertifikat sicher halten, ist nichts Falsches daran, ein selbstsigniertes und selbst erzeugtes Zertifikat zu verwenden -Benutzeranschlüsse.