/証明書とユーザー名とパスワードによる二要素認証？
シナリオ例：
- ActiveSync
認証方法：
- 証明書ベースの認証[〜＃〜] and [〜＃〜] Active Directoryドメインのユーザー名とパスワード
デバイスで暗号化：
- 公開鍵と秘密鍵
- ADユーザー名とパスワード
質問：
証明書がリバースプロキシの認証に使用され、ユーザー名とパスワードがOutlook Web Accessに使用される場合、これは2要素認証と見なされますか？証明書の公開キーがActive Directoryユーザーアカウントの一部である場合、それはまったく役に立ちますか？引数は何ですか賛成または反対この実装？
ノート：
- この設計はより安全ではありませんか（ADドメインのユーザー名とパスワードがデバイスに不必要に保存されているため）。
- 書類はありませんが、ADドメインのユーザー名とパスワードをデバイスに保存すると、証明書の公開鍵と秘密鍵のペアだけでなく、脅威の可能性が高まることは一般的に認められています。
- ActiveSyncに対して発行された証明書を強制的にExchangeアクセスにのみ使用できるようにするオプションがExchangeにありませんか？ （たとえば、証明書はアプリケーションへのHTTPS認証に使用できませんでしたか？）
質問を解読するのは少し難しいですが、ユーザーにユーザー名とパスワードを提示してもらい、ユーザーに保存されている秘密鍵（クライアント証明書）でユーザーを認証させることでユーザーを認証することを検討していると仮定します。ユーザーのデバイス。
短い答え：はい、これは一般的に有益です。ユーザーがクライアント証明書とユーザー名/パスワードのペアの両方で認証する場合、はい、この2要素認証を検討します。
2要素認証が「カウントされる」かどうかよりもさらに重要なのは、セキュリティを追加するかどうか、およびセキュリティのニーズを満たすかどうかです。一般的に言えば、そうです、ユーザー名とパスワードを使用するだけの場合と比較して、このアプローチは有用であり、セキュリティを強化します。ビジネスニーズに十分であるかどうかを評価するのに十分な情報を提供していませんが、このアプローチの長所と短所についていくつかの考えを共有できます。
セキュリティ分析。一般的に言えば、ユーザーにクライアント証明書とユーザー名/パスワードのペアの両方を使用した認証を要求することは、どちらか一方だけの場合よりも安全です。クライアントの秘密鍵はデバイスにのみ保存され、ユーザーのパスワードはデバイスに保存されていないと想定します。ここにいくつかの利点があります：
利点：ソーシャルエンジニアリングに対するセキュリティ。パスワードの弱点の1つは、ユーザーが自分のパスワードを知っているため、たとえば、フィッシング、なりすましの電子メール、なりすましなどにより、ユーザーがパスワードをだまされる可能性があることです。 ITヘルプデスク、またはその他のソーシャルエンジニアリングから取得します。クライアント証明書はこのリスクに対処します。クライアント証明書の利点は、秘密鍵がユーザーが知らない秘密であるため、ユーザーがだまされてそれを公開できないことです。攻撃者は依然としてソーシャルエンジニアリングを使用してユーザーのパスワードを盗むことができますが、ユーザーの秘密鍵を盗むのは簡単ではないため、ユーザーのアカウントにアクセスすることはできません。
利点：パスワード推測攻撃に対するセキュリティ。パスワードのもう1つの弱点は、ユーザーが不適切なパスワードを選択することが多いことです（辞書攻撃によって推測される可能性があります）。また、ユーザーは複数のサイトでパスワードを再利用することがよくあります。つまり、1つのサイトの侵害が他のサイトのセキュリティに悪影響を及ぼす可能性があります。クライアント証明書はこの問題を排除します。秘密鍵はコンピューターによってランダムに選択されるため、エントロピーが低いという問題はありません。したがって、攻撃者がユーザーのパスワードを推測できたとしても、攻撃者はユーザーのアカウントにアクセスできません。
利点：紛失したデバイスに対するセキュリティ。クライアント証明書の1つの欠点は、秘密鍵がユーザーのデバイスに保存されることです。したがって、ユーザーのデバイスが紛失または盗難にあった場合、秘密鍵が危険にさらされ、デバイスの新しい所有者がユーザーのアカウントにアクセスできる可能性があります。クライアント証明書に加えてパスワードを使用すると、この脅威に対処できます。ユーザーのデバイスが紛失または盗難にあった場合、デバイスの受信者はおそらくユーザーのアカウントにアクセスできません。これは、受信者がユーザーのパスワードを知らないためです（ユーザーがまったくひどいパスワードを選択しなかった場合）。 。
ただし、このアプローチにはいくつかの制限と注意点があり、注意する必要があります。
制限：クライアント側のマルウェアを防御しません。この2要素認証の形式は、ユーザーのデバイス上のマルウェアやスパイウェアを防御しません。このようなマルウェアは、ユーザーのパスワードを記録したり、ユーザーの秘密鍵のコピーを取得したりして、ユーザーのアカウントへのアクセスに必要なすべての資格情報を取得する可能性があります。したがって、クライアント側のマルウェアが心配な場合は、他の方法を使用してその脅威を軽減する必要があります。
落とし穴：パスワードを保存しないでください。このアプローチには落とし穴があります。ユーザーのパスワードをユーザーのデバイスに保存すると、パスワードはデバイス上でもう1つの秘密になります。その場合、セキュリティはクライアント証明書を使用することと同じです。特に、その時点でユーザーのデバイスが紛失または盗難にあった場合、ユーザーのアカウントにアクセスするために必要なすべての情報がユーザーの電話に存在するため、ユーザーのアカウントが侵害されたと見なす必要があります。したがって、カスタムクライアントアプリを作成する場合は、ユーザーのデバイスにユーザーのパスワードを保存しないようにすることが重要です。同様に、これがWeb経由でアクセスできるようにする場合は、ユーザーのパスワードがブラウザーのパスワードマネージャーに保存されていないことを確認する必要があります。
警告私の分析についての注意点。ユーザー名/パスワードとクライアント証明書の組み合わせでユーザーを認証するという一般的な概念に取り組んでいます。 Outlook、Active Directory、Exchange、ActiveSync、リバースプロキシ、またはWindows環境に固有の他の側面に関する実装の詳細については、詳しくないので話せません。私は一般的なアプローチしか分析できません。関連する実装の詳細がない場合、私の結論はあなたの状況に当てはまらない可能性があります。
証明書はコンピューターに保存され、おそらくユーザーのパスワードで暗号化されます。したがって、OWAアカウントにアクセスするには、
- ユーザー名（おそらく、ログオン時に事前入力されているか、簡単に見つけることができます）
- パスワード
- 証明書が保存されているコンピューター。
問題（+1から@ D.W。に既に言及した人）は、コンピューターのキーストアが改ざんされないことをほとんど証明できないことです。セキュリティは本当にあなたが知っているもの、ユーザー名とパスワードです。
同じ設定のクライアントでこの問題を解決しました。2つの要素ではなく、より優れたセキュリティを提供するため、1.xの要素と見なすことができると述べました。すでにPKIを導入している場合、適切なプロセスを使用してスマートカードに証明書を配置すると、スキームが2つの要素になります。
静的な認証情報/キーを2要素認証としては考慮していません。以前に回答したように、保存されている秘密鍵とともにデバイスが盗まれる可能性があります。
最良の2要素認証では、SecurIDトークンやソフトトークンなど、パスワードとして使用できるデータを計算するデバイス（またはソフトウェア）を使用し、スマートフォン（Android/iPhone）でもクライアントを設定できます。
そして、あなたの設定では、VPNがより良い解決策になると思います。ユーザーにそのようなセキュリティデバイスを備えたVPNをセットアップする場合、より厳密なセキュリティは必要ありません。
- 認証は二要素になります
- 通信は保護されます（通常はL2TP/IPSEC）
通常、コンピューターはそのようなキー（キーリングに合うか、または電話にある）で盗まれません。
認証には次の要素が考えられます。
- あなたが知っている何か。
- あなたが所有するもの。
- あなたが何か。
あなたが知っているものは、パスワードやピンかもしれません。所有するものには、スマートカードのようなトークンや、秘密キーと証明書を含むPKCS12ファイルのようなソフトPSEがあります。あなたが何かは、指紋や静脈パターンなどの生体認証属性です。
同じ認証に2つまたは3つの要素が使用されている場合、認証は2つまたは3つの要素の認証です。
2つの1要素認証があるため、この例は2要素認証ではありません。