こんにちは、富士榮です。
少し間が開きましたがNIST SP 800-63B-3の追補版の続きです。
今回は同期と共有は違うぞ!という話のうちの共有の部分です。1回目にも書きましたがAppleの共有パスワードグループの話などもありますので、非常に重要な部分だと思います。
サイバーセキュリティ・ガイドラインは、歴史的に、ユーザ間で認証器を共有しないよう警告してきた。このガイダンスにもかかわらず、一部のユーザ・グループやアプリケーションでは、個人がデジタル・アカウントへのアクセスを共有できるようにするために、認証器とパスワードの共有が行われている。
表 3 に示すように、一部の同期可能な認証器の実装は、このようなユーザの行動を受け入れ、 異なるユーザ間で認証キーを共有する方法を確立している。さらに、一部の実装は、一般的なサービスにおいて、パスワード共有に代わる便利で より安全な方法として、同期可能な認証器の共有を積極的に推奨している。
言われてますよ、Appleさん。。
企業ユースケースの場合、鍵の共有に関する懸念は、鍵が承認されたデバイスや同期 ファブリックから移動されることを制限するデバイス管理技術を使用することで、効果的に緩和することができる。しかし、公衆向けのユースケースでは、同様の緩和策は現在のところ利用できないため、 リライングパーティは、同期可能な認証プロバイダが採用する共有モデルに依存することになる。公衆向けアプリケーションの所有者は、共有認証器に関連するリスクを認識する必要がある。公衆と対話する場合、機関は、ユーザがどの特定の認証器を使用しているのかについて限られ た可視性しか持たないため、すべての同期可能な認証器が共有の対象となる可能性があることを想定する必要がある。多くの共有モデルには、リスクを最小化する実質的な制御(例えば、共有を許可するためにデバイス間の近接を要求する)があるが、他の実装はそれほど制限的ではない。
やっぱり共有を制御する方法とセットになっていることが必要なんじゃないかと思いますね。この辺りの判断をリライングパーティに全部任せちゃうのは実質不可能だと思いますし。
この新しいクラスの認証者がもたらす共有のリスクは、特別なものではない。実際には、すべての AAL2 認証タイプに適用され、中には同期可能な認証タイプより弱いものもある。AAL2 のどの認証子も、それを共有しようとするユーザによって共有される可能性がある。ユーザは、パスワード、OTP、帯域外認証子、さらにはプッシュ認証イベントを積極的に共有したり、被指名人(正式か否かを問わない)がエンドユーザに代わって認証を行うことを許可したりすることができる。
各省庁は、直面する特定のリスク、脅威、およびユーザビリティの考慮事項に基づいて、アプリ ケーションにどの認証手段を受け入れるかを決定する。同期可能な認証方式は、AAL2 までの実装を求めるアプリケーションの新しいオプションとして提供されるかもしれず、他の認証方式と同様に、この技術のトレードオフは、セキュリティ、プライバシー、公平性、およびユーザビリティに対する期待される結果に基づいて、うまくバランスをとるべきである。
そろそろこのレポートもおしまいです。
というか早くSP800-63-4の次のドラフトが出て欲しいですね。
0 件のコメント:
コメントを投稿