2022年3月15日、米国サイバーセキュリティ・インフラセキュリティ庁（CISA）は、以下の文書を発表した。 アラート 詳細 ロシアによる非政府組織（NGO）へのサイバー攻撃。この脅威者は、脆弱なパスワード、非アクティブなユーザーアカウント、セキュリティよりも利便性を優先したデフォルト設定、ウィンドウズの以前の脆弱性などを連鎖的に利用した。これにより、「クラウドや電子メールアカウントにアクセスして文書を流出させる」ことが可能になった。アティオン"
で パート1 本連載の第2回では、RSAグローバル・クラウド・アイデンティティ・アーキテクトのインゴ・シューベルトが、この攻撃を受けてRSAが顧客と共有したベスト・プラクティスのいくつかをレビューし、多要素認証（MFA）の目的、MFAへのユーザー登録、パスワードの使用を最小限に抑える方法について説明しました。このシリーズの第2部では、インゴが認証のリセット、フェイルセーフ、およびセキュリティ・インシデントにつながる可能性のあるその他のシナリオについてレビューします。
登録が完了したとしましょう。さらに、ベスト・プラクティスに従って、信頼上限が高くなるような登録を作成し、ユーザーがその認証方法を使用する限り、高い信頼度で認証できるようにしたとします。
私たちの仕事は終わったのか？そうではない。オーセンティケータを紛失したり、置き忘れたりしたユーザーについてはどうだろう？新しいスマートフォンを手に入れ、アプリを再インストールしなければならないユーザーについてはどうだろう？
このようなシナリオは必ず起こるものであり、あなたの組織は、安全でユーザーフレンドリーな方法で対処できるよう準備する必要がある。
聞き覚えがあるだろうか？そのはずです。あなたの組織はおそらく 置き換える 認証者は、最初の登録と同じような方法で認証を行う。組織は、どの段階においても、攻撃を受ける可能性がないことを確認しなければならない。
認証デバイスを交換する際には、登録時に確立した信頼を壊さないようにしてください。新しいデバイスの登録、登録済みデバイスの交換、および認証のリセットは、ID ライフサイクル の中でハッカーが最も好む瞬間である。これらは通常よりも変更の度合いが高く、その結果、攻撃者が不正アクセスする可能性が最も高い場面の一部となる。
そうさせるなモダンな 多要素認証 (MFAソリューションは、このような瞬間を保護し、アイデンティティ・アクセス管理（IAM）へのAPI統合を提供し、ヘルプデスク業務を1か所に統合します。
仮に、登録の段階ですべてを正しく行い、認証の置き換えや緊急アクセスを確保したとしても、自問してほしい。あらゆる場所でMFAを使用しなかったり、攻撃者が単純にMFAのスイッチを切って迂回したりできるのであれば、何の意味があるのだろうか？
最初のシナリオを解決するのは簡単だ。（少なくとも適切なユーザーには）どこでもMFAを使うことだ。
これを成功させるために、MFAソリューションは、ユーザーを認証するためのさまざまな方法とインタフェースを提供する必要がある。 いつでもどんなときでも を好む。また、いくつかのレガシー・アプリケーションをチェックし、適切なインタフェースを提供できるか、FIDOベースのパスワードレスや、古き良きRADIUSにこだわっている場合など、新しい認証方法を利用できるかどうかを確認する必要があるかもしれない。
すべてのアプリをMFAで保護したと仮定しよう。また、攻撃者がMFAをオフにできないようにする必要もある。最近の CISAアラート, このNGOは、ユーザーがインターネットに接続できない場合、MFAなしでログインできるMFAソリューションを使用していた。脅威者はこれを悪用し、インターネットへの接続をオフにするだけで、MFAを実質的に無効にすることができた。
したがって、組織の MFA ソリューションは、MFA バックエンド（クラウドまたはオンプレミス）に到達できない場合でも MFA が確実に実施されるように、フェイルセーフまたはオフライン・フェイルオーバー・フェイルモードを備えていなければならない。
ビジネスを継続させるためには、全員を閉め出すのではなく、パスワードだけでログインできるようにした方がいい。
その選択は理解できるかもしれないが、セキュリティ態勢に重大な脆弱性を組み込むことになる。より良い、より安全なアプローチは、MFAバックエンドが利用できなくても強力な認証が機能するようにすることである。MFAバックエンドがクラウドベースであるかオンプレミスであるかは問題ではない。
オフラインMFA認証の保護は、私たちが頻繁に遭遇する問題です。通常、私たちは企業に対し、ユーザーがオンラインかオフラインかによって異なる認証方法を提供するようアドバイスしている。例えば、ノートブックがオンラインの場合、Microsoft Windowsへのログインは、プッシュ通知または生体認証を使用して保護されます。ノートブックがオフラインの場合 ワンタイムパスワード (OTP）が実施される。
OTPはユーザーフレンドリーではないので、このシナリオでは、より高いセキュリティのために利便性を犠牲にしました。そうすることで、フェイルオープンがなく、攻撃者がMFAをオフにできないようにする。
フェイルセーフの動作は、個々のユーザーのWindows PCにとって重要なだけではありません。
使用しているMFAクラウド・サービスがオフラインになったら？それは起こりうるし、起こるだろう。MFAプロバイダーが停止しているかもしれないし、インターネット接続がダウンしているかもしれない。どのような状況であっても、フェイルセーフ／フェイルオーバーの動作を計画することで、ユーザーがインターネットに接続できない場合でもビジネスの継続性とセキュリティを維持することができます。
A オンプレミス/クラウドのハイブリッド高可用性MFAセットアップ がその日を救う。通常、アプリケーションはオンプレミスの MFA コンポーネントに接続し、MFA コンポーネントはリクエストを MFA クラウド・サービスに転送する。MFAクラウドが利用できなくなった場合でも、オンプレミスのMFAサービス・フェイルオーバー・コンポーネントに接続しているすべてのアプリケーションは、ユーザーを強力に認証することができる。
Windows PCのシナリオと同様に、このユースケースでは、インターネットが停止するとユーザーのスマートフォンへのプッシュ通知が利用できなくなるため、オフライン認証はOTPのみで行われる。MFAクラウドが停止した場合にOTPを強制するか、フェイルオープンをデフォルトにするかの選択肢があるなら、私は10回中10回はOTPを選ぶ。
当初からMFAを適切に設定し、登録についてよく考え、フェイル・オープンMFAを排除することが、こうしたすべてのシナリオに備える最善の方法のいくつかである。
もう 1 つの重要な要素は、セキュリティ・チームがアイデンティティのライフサイクル全体を通して可視化できるようなガバナン ス手法を開発することである。
SecurIDガバナンスとライフサイクル は、ユーザ・アカウントとエンタイトルメントが最新であることを保証する。MFA 登録を含め、認可の決定は ID データに基づいて行われるため、このデータが信頼できる ことが重要である。
まだ触れていないものに、Identity Confidence Scoring がある：SecurIDは、ユーザーの現在のコンテキストと過去の行動に基づいて、現在のMFAトランザクションの信頼度を評価することができます。Identity Confidence Scoringは、私たちが20年近く前から行っているものです。これはSecurIDのリスクエンジンに組み込まれており リスクベース分析.
SecurIDはこれらのベストプラクティスをすべてサポートします。初期登録の安全性確保から認証のリセット、ハイブリッド認証の導入、IDガバナンスの管理まで、スマートでシンプルかつ安全なソリューションの設計における数十年の経験を基に構築されています。
オンラインかオフラインか、オンプレミスかクラウドかにかかわらず、あなたとあなたのチームの安全を守る方法があります。 その方法をお見せしよう.
