MFA の限界を知ろう:Active Directory との相性の悪さについて深堀りする

When Partial Protection is Zero Protection: The MFA Blind Spots No One Talks About

2023/03/10 TheHackerNews — 多要素認証 (MFA) は、かなり以前から、標準的なセキュリティ手法になっている。アカウント乗っ取り攻撃の 99% 以上を防ぐという、MFA の性能は広く認められており、MFAの導入は必須だと、セキュリティ・アーキテクトが考えるのも不思議ではない。しかし、あまり知られていないのは、従来からの MFA ソリューションには、固有の適用範囲の制限であるという視点である。RDP 接続やローカル・デスクトップへのログインには対応しているが、たとえば PsExec や Remote PowerShell などの、リモート・コマンド・ライン・アクセス・ツールを保護する機能は備えていない。


現実の話として、MFA ソリューションが完全に機能していても、横移動/ランサムウェア拡散などの ID 脅威に対して、ワークステーションやサーバが脆弱が状態にあることを意味する。つまり、敵対者は RDP の代わりにコマンド・ライン・パスを使用して、保護機能がインストールされていない環境であるかのように、ログインできるのである。この記事では、この盲点を探り、その根本原因と意味の理解を促す。そして、この盲点をセキュリティ・チームが克服し、環境の保護を維持するための多様な選択肢を紹介していく。

MFA の基本的な目的:不正な認証情報でリソース・アクセスを防ぐ

MFA は、アカウント乗っ取りを防ぐための、最も効率的なセキュリティ対策である。そもそも、MFA を導入している理由は、漏洩した認証情報を悪用する敵対者が、リソースにアクセスすることを防ぐためである。そのため、たとえ攻撃者が、私たちのユーザー名とパスワードを入手できたとしても、私たちに代わって悪意のアクセスに、それらを活用することができない。つまり、クレデンシャル漏洩に対する究極の最終防衛ラインであり、この漏洩が、いかなる悪意の利益にもつながらないことを目的としているのである。

MFA の盲点:Active Directory 環境のコマンドライン・アクセス・ツールはサポートされない

MFA は SaaS や Web アプリへのアクセスを完全にカバーできるが、Active Directory が管理する環境に関しては、かなりの制限がある。なぜなら、この環境で使用される主要な認証プロトコルである NTLM と Kerberos が、MFA が位置する場所のずっと手前に置かれているため、ネイティブなサポートが不可能だからだ。つまり、それらのプロトコルを実装した認証方式に関しては、MFA で保護できないことになる。そこに含まれるものには、CMD や PowerShell ベースのリモートアクセス・ツールがあり、その中でも最も著名なものは PsExec と Remote PowerShell となる。それらは、トラブルシューティングやメンテナンスを行う管理者が、ユーザー・マシンにリモートで接続するために用いるデフォルトのツールである。したがって、実質的に、すべての AD 環境に存在するものとなる。

サイバー・セキュリティへの影響:横移動とランサムウェア攻撃に抵抗できない

それらの主流であるリモート接続経路は、定義上、漏洩した認証情報のシナリオから保護されていない。その結果として、ほとんど全ての横移動およびランサムウェア拡散攻撃で悪用されている。RDP 接続を保護し、悪用を阻止する MFA ソリューションがあることに問題はない。しかし、攻撃者にとって、PsExec や Remote PowerShell を使って、法的環境内のマシンからマシンへと移動することは、RDP を使って移動するのと同じくらい簡単である。つまり、片方のドアと、もう片方のドアを、使い分けるだけの問題なのだ。

厳しい真実:部分的な MFA 保護では問題が解決しない

そのため、重要なサーバやワークステーションに対して、苦労して MFA エージェントをインストールしても、ID 脅威に対する保護は、ほとんど成功していない可能性が高くなる。それは、保護されているか、保護されていないかの、いずれかであり、曖昧さが許される話ではない。いかに頑強なボートであっても、底に穴が開いてしまえば、それで終わりである。同じように、コマンドライン・アクセス・ツールを悪用する攻撃者が、危険な認証情報を取得することで、環境内での横方向への移動が可能になる。つまり、RDP やデスクトッ・プログインを MFA で保護していることは、もはや関係のない話になってしまう。

オンプレミス環境での MFA の限界:クラウド・リソースがリスクにさらされる

クラウドへの移行が進んでいるが、90% 以上の組織が、AD で管理されたワークステーションやサーバと、SaaS アプリやクラウドを組み合わせる、ハイブリッド ID インフラを維持している。そのため、レガシー・アプリやファイル共有などのオンプレミスのコア・リソースだけではなく SaaS アプリも、MFA 保護の欠如により漏洩した認証情報の危機にさらされている。

今日の一般的な慣行は、それら全てのリソース間でパスワードを同期させることであり、同じユーザー名とパスワードが、オンプレミスのファイル・サーバと SaaS アプリへのアクセスで使用される。つまり、漏洩したユーザーの認証情報を悪用するオンプレミス攻撃が成功すると、侵害されたマシンから SaaS リソースへの不正アクセスへと、簡単にピボットできてしまう。

パラダイムシフト:統合されたアイデンティティ保護への移行

この記事で説明してきたギャップは、従来からの MFA の設計/実装の起因するものだ。そのため、認証を行うソフトウェアが MFA をサポートしていない場合 (AD のコマンドラインなど) には、保護することが不可能となっている。

しかし、MFA を個々のリソースに配置することから、ディレクトリに焦点を移すことで、この障壁を完全に克服する新しいアプローチが存在する。

Silverfort は、MFA をネイティブにサポートしているかどうかに関係なく、あらゆるリソースに MFA を拡張するための、最初の統合型 ID 保護プラットフォームを開発している。エージェントレスでプロキシレスな技術を利用し、Silverfort は AD とのダイレクトな統合を果たしている。この統合により、AD がアクセス要求を得るときは必ず検証を行い、その結果を Silverfort に転送する形態をとることになる。続いて Silverfort はアクセス要求を分析し、必要に応じて MFA でユーザーを審査する。そのときのユーザーの応答に基づき Silverfort は、ユーザーに対する信頼を判断し、それぞれのアクセスに対する許可/拒否の評価を AD に受け渡す。

このアプローチにおける革新は、それらのアクセス要求が RDP/コマンドラインで行われたかどうかには関係なく、また、MFA をサポートしているかどうかにも関係なく、セキュリティが保持される点にある。アクセス要求が AD に対して行われる限り、AD は Silverfort と連携できる。したがって、リソースレベルの MFA 保護から、ディレクトリレベルの MFA 保護への移行が可能となり、何年もにわたって敵対者が悪用している盲点が解決されることになる。

この記事の元タイトルには、No One Talks About というフレーズが含まれていますが、文中の「 この環境で使用される主要な認証プロトコルである NTLM と Kerberos が、MFA が位置する場所のずっと手前に置かれている」という部分に該当するのでしょうね。試しに、[NTLM と MFA] と [Kerberos と MFA] でググってみたら、以下の記事が、日本マイクロソフトのサイトで見つかりました。Silverfort の Re-Evaluate Your MFA Protection – eBook も、ぜひ、ご参照ください。

Azure AD Multi-Factor Authentication についてよく寄せられる質問
Azure Files でハイブリッド ID に対して Azure AD Kerberos 認証を有効にする

%d bloggers like this: