Microsoft Entra ID の証明書認証
ユーザー名とパスワードだけでクラウドサービスにアクセスする
このことがいかに危険であるかはだいぶ認識されるようになってきました。
ではパスワードの代わりに何を使うか？パスワードと共に何を使うか？
Microsoft Entra IDにはいろいろな選択肢があります。
パスキー、Microsoft Authenticator、PRT.. どれも本質的には公開鍵暗号方式を利用した認証なんだけど「公開鍵暗号方式と言えば証明書」という理屈で
だったら証明書そのもので認証すればよいんじゃないのか？
こんな話が出てくるんじゃないかと思います。
VPNとかWPA Enterpriseなどでもたびたび登場するので、今まで培ってきた技術を活用したい、そう考える人もいるかもしれませんし、なによりも Microsoft Entra ID に証明書認証って機能があるわけだから「これ使おうよ」となるわけです。しかも米国大統領令 14028「国家のサイバーセキュリティ改善に関する大統領令」（Executive Order 14028）に基づく実装だと言われれば、なにかのお墨付きをもらった気分です。
だけどここでは敢えて証明書認証のネガティブなサイドについて語ってみたいと思います。
証明書がインストールされたデバイスを使ったなりすましが起きる
証明書認証は確かに証明書がインストールされているデバイスからしかアクセスできません。その意味では安全なのですが、マルウェア経由で証明書がインストールされたデバイスが遠隔操作できちゃうようなケースではなりすましアクセスが実現できてしまうのです。
そんな話をしていたら、みずほ銀行の法人向けサービスでも証明書認証からOTP方式に切り替えるよう促すアナウンスがありました。
証明書自体が盗まれてアクセスされてしまう
デバイスにインストールされた証明書が何かしらの方法で盗まれることがあったら、そのまま悪用できてしまうことも課題のひとつです。
一般的に秘密鍵が入った証明書はエクスポートできないようにインストール (インポート) されていますが、証明書の展開方法がまずくて秘密鍵がエクスポートできるように実装されていたら、この攻撃が成立してしまうのです。
ちょっと話は外れるかもしれないですが、Microsoft Entra IDのSSOに使われるSAMLプロトコルの世界でもトークンの署名に使われる証明書が盗まれたら、攻撃者がトークンを発行し放題になってしまうので、ADFSサーバーのような証明書を自前で管理する仕組みではなく、Microsoft Entra ID を使ってクラウド側で証明書を管理しましょうという提言がMSさんのサイトの中でも書かれていました。
証明書を利用した認証・認可の方法については Microsoft Entra ID の[アプリの登録]においてクライアントシークレットの代わりに証明書を登録する方法がありますが、クライアントシークレットと比べれば安全な実装方法かもしれません。しかし、こちらも証明書を使う時点でこれまで指摘した懸念点があり、証明書は有効期間を短くして定期的に入れ替えましょうという緩和策をオフィシャルサイトでも案内しているのです。
証明書認証の設定方法
ここまで読んでくださった方が「証明書認証の設定方法を知りたくて、このサイトに来たのに釣りかよ」と思った人もいるでしょう。これについては既にオフィシャルサイトをはじめ、色々なところに記載があるので参考にしていただければと思います。
証明書認証自体、古くからあるテクノロジーなので脊髄反射で選択してしまいがちですし、他社のIdPと比較するときに証明書認証ができるかどうか？便利に使えるかどうか？で判断してしまいがちですが、そこだけじゃない判断基準もありますよという話をさせていただきました。
