Require 2FA for administrative actions even user has administrator role| ロールあるでもProd環境で2FAセットアップした管理者のみが管理アクションを実行できるようにします

[eternal-flame-AD]

Summary

タイトル通りです。

Purpose

僕個人としても推進したい所ではありますが、懸念がいくつかあります。

セキュリティ方面はAdmin権限があるユーザーは信頼レベルは極めて高い
上記の通りな方もいれば、残念ながらあまり関心のない方もいらっしゃるので、とても難しい話だと思います…。
アクセストークンの発行は少しでも防御力の高い状態で使ってほしい機能だと認識しています。なので…2FA設定済みの場合のみ実行可能なようにするなどいかがでしょう？（参考までに…Gmailがサードパーティアプリ向けに発行するパスワードは2FA設定済みであることが条件のようです）
(@samunohito)

アタッカーがSigninできるまたは他の手段でユーザートークンが手に入れた場合は、アクセストークンがなくでも作成できる。２FAは前提条件が高めるでもこのフィーチャーが自身のセキュリティ問題ではないと思います。
[...]
深刻なデータリークまたはトークン構成ミスでadmin許可があるトークンがある場合は、create-accountだけ許可があるの可能性が低いと思います。他のwrite:admin:delete-account write:invite-codes "write:admin:meta" "write:admin:reset-password" (2FAも無効する) などサーバーを新しい始まりに持ち込みできる許可がありますと思います。

仰る通り、以下は別問題として分けて考えた方が良いですね。
adminユーザ向けのトークン発行は2FAを必須としないとセキュリティ面で懸念が残る
/admin/accounts/createをアクセストークンから行えるようにしたい
他のメンバーの意見も聞いてみたい所ではありますが…
ひとまず、自分の意見としては1を解消してから2（このissue）に取り組んだ方が良いと考えています。
(@samunohito )

userpassもリークされた (パスワード再利用など)　の方面で、2FAをセットアップする前に、許可検証の目的で、WebUI Signinでもユーザーを管> 理者と見なさないといいと思います。

これらからの抜粋 ：

#14959

Do you want to implement this feature yourself?

• Yes, I will implement this by myself and send a pull request (not my priority right now, so if a maintainer think this is time sensitive please do not wait for me, I will probably get around to this at the end of the year)

[samunohito]

#14959 の背景を整理します。

1. UIから発行したアクセストークンを使用して新たなユーザを作ることが提案されました
2. しかし、アカウントの防御にあまり関心のないadmin権限保有者も存在する現実もあり、2FAを必須化する旨の提案を僕がしました
3. 2を考えると、/admin/accounts/createだけの問題だけではないということで、このissueが作成されました

---

念のために確認させてほしいです。

• 2FA未設定の場合において、admin権限保有者のコントロールパネル操作を封じる意図ではない
• 2FA未設定の場合において、admin権限を要求するエンドポイント（meta.kindにwrite:adminまたはread:adminが設定されているもの）へのリクエスト権限を持つアクセストークンを発行できないようにする（または、リクエストを拒否する）

上記であると理解しています。これに相違はありますか？

[eternal-flame-AD]

(Deleted one comment because I accidentally pressed submit)

2FA未設定の場合において、admin権限保有者のコントロールパネル操作を封じる意図ではない

I think this can be done on two levels: one is to only restrict token creation a more strict one is just do a popup asking them to setup 2FA when they use the control panel. The major security benefit of the second is if the password is leaked the admin account is still protected as this effectively makes sure every admin has 2FA setup.

We can have a require2FaForAdmin config key or a 2FA setup role condition to make the strict version opt-in

これは2つのレベルで行うことができると思います。1つは、トークンの作成を制限することです。より厳格なものは、コントロールパネルを使用するときに2FAをセットアップするように依頼するポップアップを行うことです。 2番目の主要なセキュリティ利益は、パスワードが漏れている場合、管理アカウントがまだ保護されていることです。

より厳格なルールは（管理APIはユーザートーケンがあっても2FA必要）config.yml に require2FaForAdmin: true 或いは 2FA Setup ロールルールで実装がいいと思います。

2FA未設定の場合において、admin権限を要求するエンドポイント（meta.kindにwrite:adminまたはread:adminが設定されているもの）へのリクエスト権限を持つアクセストークンを発行できないようにする（または、リクエストを拒否する）

Yes, and there can be a popup asking for 2FA to be setup when they access the control panel.

おっしゃる通りです コントロールパネルを使用するときに2FAをセットアップするポップアップを行うことです。

[eternal-flame-AD]

I doubt the first level will break any existing setup unless they are programmatically creating access tokens (which they should not) and I think can safely be implemented without breaking anything.

The second level may break if some users are already using the user token to get around some limitations, but I think it is still very important for completely fixing the original issue cited (inadequate security control by administrators). Thus I think an opt-in approach is a good idea.

最初のレベルが自動化アクセストークン作成していない限り（それはそうすべきではない）、既存のセットアップを破るとは思わず、安全に実装できると思います。

一部のユーザーがすでにユーザートークンを使用していくつかの制限を回避している場合、2番目のレベルが破損する可能性がありますが、引用された元の問題（管理者による不十分なセキュリティ制御）を完全に修正するためにはまだ非常に重要だと思います。したがって、opt-inは良い考えだと思います。

[sakuhanight]

オフトピックかもしれませんが、トークンの安全性を考えれば、より短い有効期限のリフレッシュ可能なトークンがあると良いと思いました。(OIDCのように)

[eternal-flame-AD]

In the long run I think multiple things regarding authentication can be improved, my biggest perceived risk is the user token which grant the full scope is reused and can be retrieved by both JS and a leaked cookie. Not many users understand logging out does not really invalidate the session. (Which I can offer suggestion but am not comfortable submitting an upstream patch simply because there are too many different opinions on how it can be implemented)

長期的には、@sakuhanight 貴重な提案を含め、関連する複数の問題を解決できると思います。認証に関連して私が認識した最大のリスクは、すべでのスコープを許可するユーザー トークンが再利用され、JS と漏洩した Cookie の両方によって取得できることです。ログアウトしてもセッションが無効になるわけではないことを理解しているユーザーは多くありませんかもしれない （提案を提供することはできますが、それがどのように実装されるかについて異なる意見が多すぎるという理由だけで、上流のパッチを提出することに自信がありません）

一つずつ取り上げて、問題を明確に定義し、個別に修正するのが良いアプローチだと思います。