Azure ポイント対サイト (P2S) 接続が自己署名証明書な理由の推測

先の記事で、Azure の仮想ネットワークにポイント対サイト (P2S) 接続するときに必要になる、ルート証明書とクライアント証明書の作り方を書いた。
そこで Azure の P2S 接続につかう証明書は「自己署名証明書が推奨」されており、商用認証局で購入した者ではセキュリティ的に問題が生じると記した。

筆者個人の推測ではあるが、ここにその理由を述べる。

Virtual Network

認証 (Authentication) と認可 (Authorization)

「認証 (Authentication)」とは相手の正当性を確認することだ。
クライアント認証ならサーバーがクライアントの正当性を確認することで、サーバー認証ならクライアントがサーバーの正当性を確認することだ。

正当性とは、相手が間違いなくその相手自身であることの保証だ。
認証で最も手軽かつ多く用いられるパスワード認証を例に挙げると、アカウント名 (ID) が正しいことをパスワードで確認する認証方式で有り、アカウントの所有者と認証する相手だけがパスワードを知っていることを前提に、パスワードを知っていることを正当性の保証にしている。

認証によってアカウントの正当性を確認したら、アカウントに対してどの機能の利用を許可するかといった権限の割り当てを伴うことがほとんどだろう。
この権限の割り当てを「認可 (Authorization)」という。

Azure の ポイント対サイト (P2S) 接続の場合は、接続してきた端末の確認が認証で、その接続を許可するか拒否するか動作が認可になる。
さらなる認可として、P2S 接続が許可された後の Azure 仮想ネットワーク内のどのホストへのアクセスを許可するといった権限の割り当ても考えられるが、今のところ Azure にそういった機能はない。

証明書を使った認証

認証 (Authentication) で最も手軽かつ多く用いられるのはパスワード認証で、これはアカウント名 (ID) で相手の正当性を確認する。
証明書を使った認証では、アカウント名の代わりに証明書の内容で正当性を確認する。

証明書には対象になる主体者の情報と、証明書の発行者の情報などが記載され、さらに発行者の秘密鍵によって暗号化された署名 (証明書のハッシュ) が添付されている。
パスワード認証でのアカウント名に相当するのは、主体者の情報だ。
そして、証明書の発行者の署名がパスワードに相当する。
もっとも実際には、認証の際に、主体者の情報を利用することはほとんど無く、発行者の署名だけで正当性が確認される。

主体者の情報は、認可、つまり権限の割り当てで使われるのが一般的だが、認可の判定では主体者の情報に限らず、証明書に記されている情報を任意に使うことができる。

なお、署名の正しさを検証するためには、証明書に記された発行者の公開鍵が必要だ。
発行者の公開鍵は発行者の証明書に含まれており、この発行者の証明書は俗にルート証明書と呼ばれる。
このため、署名を検証する (認証を行う) 側は、発行者のルート証明書が参照できなくてはならない。
Azure の ポイント対サイト (P2S) 接続の場合は、Azure にアップロードするルート証明書が、この発行者のルート証明書だ。

Azure のポイント対サイト (P2S) 接続でのクライアント認証

Azure の P2S 接続でクライアント認証をどのように行っているかと言った資料は一切公表されていない。
そこで、Azure で可能な設定項目と実際の動作から推測する。

Azure の P2S 接続に関する設定項目は、ルート証明書のアップロードだけだ。
後は VPN クライアントのインストーラーをダウンロードして、クライアント端末にインストールするくらいだが、VPN クライアントのインストーラーは、Azure への P2S 接続用にクライアント証明書を使う SSTP VPN を構成するだけでしかない。
なお、本記事で述べようとしている件とは直接の関係はないが、 VPN クライアントのインストーラーで SSTP で必須のサーバー認証のためのルート証明書がインストールされる。
これはクライアント端末の接続先サーバーの確認と、通信路の暗号化 (SSL セッションの確立) に必要なだけで、クライアント認証には関与していない。
重ねて蛇足だが、ここでインストールされるルート証明書も自己署名証明書だったりする。

これらのことから Azure の P2S 接続では、クライアントが SSTP VPN で Azure のゲートウェイに接続する際にクライアント証明書を送信するが、Azure 側ではクライアント証明書に記されている主体者の情報を使った認可をしていないと推測できる。

さらに、クライアント証明書を指定せずに接続しようとしたり、Azure にアップロードしたルート証明書 (のコピー/原本) で発行・署名したクライアント証明書以外のクライアント証明書を使って接続しようとすると接続が拒否されることから、Azure の P2S 接続のクライアント認証 (と認可) が以下のただひとつ条件で行われていると推測した。

  • 接続元の端末から提示された証明書が、Azure にアップロードしたルート証明書 (のコピー/原本) で発行・署名されている。

つまり、Azure にアップロードしたルート証明書の署名で認証して、同様に接続を認可しているということだ。
この認証・認可でクライアント証明書に記されている主体者の情報が使われている様子はない。
そもそも Azure に、証明書に記されている主体者の情報を認証・認可で利用させる設定項目が、そもそも存在していない。

Azure のポイント対サイト (P2S) 接続で商用認証局のクライアント証明書を使うとどうなる

それでは、商用認証局から発行されたクライアント証明書を使って Azure に P2S 接続するとどうなるだろうか。

Azure の P2S 接続で商用認証局から発行されたクライアント証明書を使うということは、商用認証局のルート証明書を Azure の P2S 接続のルート証明書としてアップロードするということだ。
商用認証局のルート証明書は公開されており、自由にダウンロードして使えるので、このこと自体には何の問題も無い。
例えば、シマンテック・ウェブサイトセキュリティ (旧 VeriSign) のルート証明書の場合は「ルート証明書」の Web ページでダウンロードできる。

商用認証局のルート証明書を Azure にアップロードし、その商用認証局で発行されたクライアント証明書を使って P2S 接続してみたところ、これ自体は何の問題も無くできる。
筆者が実際に試して確認した。

このときに問題になるのは、Azure の P2S 接続におけるクライアント認証が、クライアント証明書に記載された主体者の情報を利用していない点にある。
このため、Azure にアップロードしたルート証明書の商用認証局で発行されたものであれば、どのクライアント証明書でも区別無く P2S 接続ができてしまう。
当然のことだが、商用認証局がクライアント証明書を発行する先は自組織に限らない。
Azure  の P2S 接続のルート証明書に商用認証局のものをアップロードすることは、知らない人に接続を許可したのと同じと言えるだろう。

ルート証明書を自己署名証明書にすることで、知らない人が P2S で接続できなくできる。
これが、Azure のポイント対サイト (P2S) 接続が自己署名証明書を推奨している理由だろう。


以下は与太言だ。

自己署名証明書を使ってクライアント証明書を発行する際に、一時にまとめて発行するなら makecert.exe を使う程度で済む。
不定期、散発的にクライアント証明書を発行するような場合は、Active Directory 証明書サービスを構築し、維持するといった手間が掛かる。
しかし、Azure の P2S 接続が自己署名証明書によるクライアント証明書を要求する以上は、こういった手間をかけることもやむを得ないだろう。

なお、クライアント証明書に記されている主体者の情報で、認可 (接続の可否) できれば、商用認証局を使っても問題ないで、そのような機能が追加されることを望まれる。

コメントを残す