3

Azure Key Vault に保持したい秘密がいくつかあります。次の手順に従って、クライアントとシークレットを使用する代わりに、クライアント ID と証明書を使用して Key Vault で認証できることを知っています。

  1. 証明書を取得または作成する
  2. 証明書を Azure AD アプリケーションに関連付ける
  3. 証明書を使用するコードをアプリケーションに追加します

ほとんどの例では、makecert または New-SelfSignedCertificate を使用して証明書を作成しています。この場合、本番アプリケーションの場合、自己署名証明書に問題はありますか? これは、アプリケーションが Azure Key Vault で認証するためだけのものであり、クライアントがブラウザーに表示するものではありません。

この場合、自己署名証明書がまだ嫌われている場合、信頼できる機関から証明書を購入することは、SSL/TLS 証明書を購入することと同じプロセスですか? 同じ種類の証明書ですか?

4

1 に答える 1

6

自己署名証明書を使用することに本質的に問題はありません (いくつかの注意点があります)。純粋な暗号の観点からは、購入した証明書と自己署名証明書の間に違いはありません。唯一の違いは、購入した証明書が、ほとんどのブラウザー/オペレーティング システムなどで公開鍵を配布する 1 つ以上の認証局 (CA) によって署名されていることです。つまり、ユーザーは、購入した証明書が正当なものであるという信頼性を大幅に高めることができますが、自己署名証明書を受け入れるには大きな信頼を寄せる必要があります。

ただし、あなたの場合、クライアント アプリケーションを制御できるように見え、実際のユーザーはこの証明書を見ることはありません。したがって、中間者攻撃 (つまり、誰かが独自の自己署名証明書を生成し、あなたになりすます) を防ぐための予防措置を講じている限り、心配なく自己署名証明書を使用できます。これを行う最も効果的な方法の 1 つは、証明書のピン留めを使用することです。基本的に、証明書の公開鍵をクライアント アプリケーションに同梱すると、クライアント アプリケーションはその公開鍵を提供する証明書のみを受け入れます。これにより、悪意のあるアクター (証明書を盗んでいない) が中間者攻撃を実行することがはるかに困難になります。

TL;DR: 中間者攻撃を防ぐための措置を講じ、証明書を安全に保つ限り、自己署名および自己生成証明書を使用して非ユーザー向けを保護することに何の問題もありません接続。

于 2016-06-13T16:12:27.127 に答える