2022年3月15日、米国サイバーセキュリティ・インフラセキュリティ庁（CISA）は、以下の文書を発表した。 アラート 非政府組織（NGO）に対するロシアのサイバー攻撃について詳述している。
ロシアの脅威者は、ブルートフォースパスワード推測攻撃を使用して、非アクティブなNGOのユーザーアカウントを侵害しました。その後、この脅威者はNGOの新しいデバイスを登録することができました。 多要素認証 (MFA)プロバイダーが、侵害されたアカウントを使用していた。その後、「フェイルオープン」設定を悪用し、脅威者はデバイスをインターネットから切り離すことで、MFAを効果的にオフにすることができた。
最終的に脅威者は、脆弱なパスワード、非アクティブなユーザーアカウント、セキュリティよりも利便性を優先したデフォルト設定、そして以前のWindowsの脆弱性を連鎖させた。これにより、CISAによれば、「文書流出のためのクラウドおよび電子メールアカウントへのアクセス」が可能になった。
このブログ記事は、他のプロバイダーをバッシングするためのものではありません。私はRSAに20年近く勤務しています。その間に、サイバーセキュリティの山あり谷ありを身をもって体験してきました。つまり、悲喜こもごもは誰の役にも立たないということです。
私について 意志 は、CISAの最近の警告を受けてRSAが顧客に行ったアドバイスの一部を詳しく説明する。また、このアドバイスがすべてのMFAソリューションにどのように適用されるかについても説明する。
ネタバレ注意：この記事の残りの部分で言及されているすべての機能や要件は、RSAの一部です。
MFAは認証方法以上のものである
このような攻撃を防ぐために、組織はMFAとは何か、ユーザーは最初にどのようにMFAに登録すべきか、そしてユーザーのライフサイクルにわたってどのように登録を維持するかを再考する必要がある。
MFAは、「MFA」ではないことを常に念頭に置いておこう。 ちょうど を持つことについて ワンタイムパスワード (OTP）トークン、認証アプリ、またはFIDOスティックを使ってログインする。もし、あなたやあなたのユーザーがクラウドアプリケーションにログインするために、たまたまスマートフォンでバイオメトリクス認証を使用したからといって、安全だと思うのであれば、悪い知らせだ。
それは最低限のことに過ぎない。確かに、コンプライアンス監査で「MFAを使用する」チェックボックスをチェックすることは可能だが、セキュリティの観点からは、これは時間とお金の無駄だ。
ほとんどのオーセンティケータは、認証のために暗号化シードまたはキーに依存している。ハードウェア認証器は、ソフトウェア・ベースの認証器よりもシードをより高度に保護するため、通常、より高いレベルのセキュリティを提供する。企業は、自社のセキュリティ・ニーズを理解し、十分なセキュリティを提供する認証機を選択する必要がある。
しかし、ハードウェアであろうとソフトウェアであろうと、認証者の登録が適切な信頼性を確立できなければ、その方法自体はほとんど無意味である。たとえ組織が最高の認証者を使用していたとしても、その管理方法が間違っていれば、攻撃を防いだり遅らせたりするためにはほとんど役に立たない。強力なエンジンを搭載し、ブレーキパッドを黄色に塗ったからといって、いきなりレーシングカーのハンドルを握れるわけではない。ブレーキやサスペンション、タイヤも変えなければならないし、実際のレースに出場するためのドライバーのトレーニングも必要だ。他にも考慮すべきことはたくさんある。
典型的なIDライフサイクルを確認することで、MFAソリューションを最大限に活用し、ユーザーを保護し、デジタル資産を保護するという、MFAソリューションが意図した役割を確実に果たす方法を説明する。
登録は、ID ライフサイクルの第 1 段階である。登録中に、ID（ユーザ）に認証子が割り当て られる。しかし、組織が特定のユーザを登録する前であっても、2、3 の質問を検討する必要がある：
- 誰がMFAに入学できますか？
- ユーザーはどのようにしてMFAに登録できますか？
最初の質問は簡単な答えだと思うかもしれない！
しかし、登録すべきではない、あるいは登録してはならないユーザーやグループがあるかもしれません。育児休暇中の従業員や、特定のユーザに割り当てられたことがない、あるいは割り当てられなく なった孤児アカウントなど、存在するがアクティブでないアカウントについて考えてみる。セキュリティ・チームは、これらのアカウントに発行された新規または変更された認証機 能の登録が気付かれる可能性が低いため、これらのアカウントに MFA の登録を許可すべきではない。例えば、設定変更を知らせる通知メールは、監視されていない受信トレイにそのまま放置される。
2つ目の質問は、2つの観点から取り組む必要があるため、より重要である：
- どうすれば、あなたの組織の登録が望ましい信頼レベルに達するのか？
- ユーザーと管理／ヘルプデスクの双方にとって便利で効率的な方法で、望ましい信頼レベルを満たすにはどうすればいいのか。
ユーザが登録時に持つセキュリティの程度は、そのユーザがその認証機を使用し続ける限り、その 信頼の上限を設定する。
別の言い方をすれば、ハードウェアであろうとソフトウェアであろうと、認証者は、最初の登録が十分に強力であった場合にのみ、MFAログインやステップアップ認証に必要なレベルの信頼を提供することができる。不安定な基礎を築けば、家は常に不安定になる。
セキュリティと利便性の両方を両立させる方法で、誰が登録し、どのように手続きを完了させるかを決める方法はたくさんあります。しかし、あなたの組織がどのような方法を決定するにせよ、次のようなことがないようにしてください。 だけ パスワードを使って登録する。
なぜダメなのか？パスワードは便利だ。ユーザーはすでに自分の認証情報を知っているので、管理者はMFAソリューションをActive Directoryに向けること以外、何も心配する必要はない。そうだろう？
違う。MFA登録を完了させる簡単な方法ではあるが、パスワードだけを使用することは、組織をあらゆる種類の攻撃から開放することになる。最悪のシナリオは、攻撃者がすでに侵害したアカウントをMFAに登録することだ。MFAに登録するアカウントは まさか MFAに登録することは、事実上MFAを完全に回避することと同じである。
この記事の冒頭で触れたNGOへの攻撃が成功したのは、まさにそのためだった。攻撃者はアクセス権を昇格させるために追加のステップを踏んだが、登録そのものに致命的な欠陥があった。
よりスマートで安全な認証者の登録方法がある。SecurID は、MFA 登録に技術的および手続き的な管理を追加することを強く推奨している。実際、SecurID ではパスワードのみの登録はデフォルトではできません。そのような登録を可能にするためには、顧客がわざわざその方法を選択する必要があります。
適切な登録の決定は、利用可能な認証子、要求される信頼レベル、組織の MFA ソリューション の機能、および企業が利用可能なツールと手順によって決まる。
パスワードに頼ることなく、登録プロセスを安全かつ簡素化するのに役立つ技術的コントロールは数多くある。例えば、組織には次のような方法がある：
- 入会前にあらかじめ登録された電話番号へのSMSまたはVoice-OTPを利用する。
- 登録コードを取得するために、ユーザーにヘルプデスクへの連絡を義務付ける。
- 登録コードを電子メールでユーザーに配布する。
- PINレターを印刷・共有し、ユーザーにそのユニークなPINを使った入会を強制する。
- ユーザーにハードウェアトークンを割り当て、送信する (このシナリオでは、組織はトークンを非アクティブにしておき、ユーザーがヘルプデスクに電話してハードウェアトークンを有効にするようにします)
- 社内ネットワークからのみ登録可能
もちろん、利用可能なコントロールはもっとあり、さまざまな組み合わせも可能である。大規模で多様なユーザー集団を抱える組織は、おそらく複数の登録方法を提供することを検討すべきであり、その結果、ユーザーの役割に応じて信頼レベルが異なる可能性がある。
これらの管理はすべて、登録サービス自体にセキュリティ層を追加するものである。そして、これらのレイヤーを確立するには、セットアップと維持に労力がかかるが、その投資は、信頼できる認証者という大きな見返りをもたらす。
しかし、これはユーザーのIDライフサイクルを保護するための第一歩に過ぎない。脅威行為者に重大な機会を与えないようにするシナリオや、組織が準備すべき状況はまだまだたくさんある。 このシリーズの次のパートでは, ここでは、リセット、フェイルセーフ、および組織が自身とチームを保護するために優先すべきIDライフサイクルのその他のポイントについて説明する。
