ユーザーが自分の許可された機能を知ることを許可すると、セキュリティが低下しますか？
計算された承認の複雑なセットを持つシステムで、特定のユーザーが自分の承認をすべて表示できるようにアクセスを許可すると、セキュリティが低下しますか？
APIのコンシューマーが独自の統合を開発することに依存する「Policy as Code」システムでは、特定のユーザーがより簡単にアクセスをリクエストして利用できるため、すべてのユーザー認証を簡単に表示できるようにするのは賢明な考えのようです。必要に応じて承認の状態をInfoSecに要求するのではなく、「ドキュメントとしてコード化」します。
ユーザー自身が計算した承認の包括的なリストへのアクセスをブロックすることは、ユーザーがシステムを探索して自分がアクセスできるものとできないものを見つけることができるため、「あいまいさによるセキュリティ」の問題のように思えます。
これは、Vaultポリシーの表示に関するこのVaultメーリングリストの投稿についての同僚とのディスカッションで明らかになりました。
しかし、それは他の多くのことに当てはまります。とにかく、私は以前に間違っていたのでこの質問をしているのですが、「それは単なるあいまいなものだ」と宣言するのは時期尚早だと思います。
ユーザーが自分のすべての承認を簡単に表示できるようにすると、脆弱性が増加するかどうかを確認するにはどうすればよいですか？
リー・ライアンの回答ですでに述べたように、ケルコフの原則がここで適用されます。システム上のリソースのユーザーに知識を与えることは、そのシステムの脆弱性を増加させてはなりません。そうだと思うなら、最初に考慮すべきいくつかの大きな問題があります。
システムで最初に行うこと：そのシステムがどのように機能するかについての知識を与えることによって、そもそも危険が増大するかどうかを評価します。
危険性が高まる場合は、ユーザーが自分の承認を表示できるかどうかよりも大きな問題があり、そのシステムに関するその他の知識をすべてロックする必要があります。
さらに、ユーザーの承認を隠すことは、システムの脆弱性を減らすための条件ですか？もしそうなら、あなたは失敗のために自分自身を設定しています。
これは、適切に利用可能なシステムでは、ユーザーは問題のシステムを使用して、自分ができることとできないことを記録するだけで、時間の経過とともに自分の機能をかなり簡単に発見できるからです。 hey、ユーザーはuseそれ。
実際、ユーザーが何を利用できるかについてのユーザーの知識は、多くの場合、そもそも利用の条件です。
そして、利用できないシステムはすでに故障しています。
ケルクホフの原則に戻り、「あいまいさによるセキュリティ」タイプの状況にあるかどうかを確認するための質問を次に示します。
システムの関連コードまたは仕様はオープンソースですか？
同様のシステムを使用して他の人もこの情報を制限してください
そうでない場合、それは彼らにとって危険の増加につながりましたか？
この情報をすべてのユーザーに許可すると、システムが脆弱になると考えられるシナリオはどれですか。そして、情報を制限することで実際に脆弱性が軽減されますか（代替案と比較して）？
以下は、私の選択したBlue Teamセキュリティツールの2つであるKeePassXCとHashiCorp Vaultを使用した実際の例です。
はい KeePassXC 、 HashiCorp Vault
KeePassXC：いいえ。認証は、パスワードとキーを持っているKeePassXC DBに限定されるためです。 HashiCorp Vault： No
KeePassXC：いいえ。パスワードにちなんでDBに名前を付けない場合、あなたは無難です。 HashiCorp Vault： いいえ、認証方法で使用されるもの（KVストア名など）にシークレットデータを保持するための名前を付けない限り 繰り返しますが、ここではユーザーに何らかの責任があります。境界を尊重し、ユーザー名またはパスワードにちなんでDBおよびKVに名前を付けない場合、これは新しい脆弱性をもたらしません。
これは、ユーザー自身のアクセスに関するユーザーの知識によって脆弱性が増加するシナリオです。
A.ユーザーが既に特権アクセスを持っている場合、彼はそれをすべきではありませんし、そうでなければそれを知らないでしょう。
この場合、ユーザーの知識を制限するのが賢明でしょう。しかし、より良い代替策は、自分のアクセスに関する知識を制限するだけでなく、そもそもアクセスレベルを下げることです。なぜなら、とにかく利用可能なリソースを誤って発見する可能性があるからです。 KeePassXC DBまたはHashiCorp VaultのKVキー名に特権を与えた場合、どちらの方法でも、承認システムに公開されていない場所に情報を移動することができます。 VaultのKVストアの例では、キー名を一般的なものに変更し、特権情報をコピーしてそれらのキーの値を保護します。
おおまかな質問をされたので、おおまかな答えを提供します。
「セキュリティの低下」（せいぜい未定義）の観点から問題を考えるのではなく、「脆弱性」と「危険」の観点から考えてください。
- 情報の開示により、どのような脆弱性（システムおよびコントロールの弱点）が公開されますか？
- 情報の開示により、どのような危険（事故につながるおそれのある危険な状況）が生じますか？
これに答えるために、脅威モデルを作成するのではなく、脆弱性モデルを作成します。システムの脆弱性はどこにあり、システムの使用または誤用によって危険が発生する可能性がありますか？
情報の開示がシステムの脆弱なポイントに影響を与えず、情報を使用してハザードを作成できない場合、または影響と可能性が許容できるほど低い場合は、リスクベースの答えがあります。
ケルコフの原則がここに適用されます。適用されるべきではありません。
理論的には、ユーザーの権限のリストは、ユーザーが許可されている権限と一致する必要があります。実際には、見落としがあると、ユーザーに実際に必要な以上の特権を付与する可能性があり、認証情報を開示すると、ユーザーがそれを理解しやすくなります。
ここでの唯一の欠点は、ユーザーが実際に必要以上のアクセスを許可されている場合です。次に、許可情報は、ユーザーに必要以上の特権があることをユーザーに知らせます。結局のところ、これは認証情報の開示が原因の問題ではなく、トークンの特権が広すぎるため、そもそもできませんでした。
最も正確な答えはアプリケーションに依存すると思います。承認は微妙な問題であり、適切なアクセス制御には基盤となるシステムの分析が必要です。
そうは言っても、私の個人的な見解では、それが最高のUXであったり、最も明確なUIを提供したりすることはないかもしれませんが、ユーザーに承認を公開しても、おそらくセキュリティが損なわれることはありません。ユーザーの役割が何かを実行できる場合、その役割を持つ誰かがおそらく最終的にそれを理解するでしょう。
*警告はここで重要です-繰り返しになりますが、実際の答えはアプリケーションによって異なります。これは単なる推測であり、非常によく間違っている可能性があります（アプリケーションの性質に応じて、もう一度）。 YMMV、GLHFなどなど。