プロトコルが常に「ターゲットアカウント」になりすましを通知する認証システムはありますか？
なりすましには多くの形式があります。
- * nixのsudo
- アプリケーションのなりすまし（
send as交換で） - パスワードを開示しないようにユーザーとしてログインする特権ユーザー（ヘルプデスク）
- WindowsのRunAs管理者
私は、それ自体が次の一連の手順を定義する認証システムを探しています。
- 有効ななりすましの試みをすべてログに記録する
- アカウント所有者にそれらの試みが表示されるようにします
- アカウントの所有者は、受動的に受け入れるか、疑わしいとマークします。
ある意味で、これはスパムUCEの報告方法やDMARC報告と同様に、RFCとして体系化することができます。
私の目標は、このロジックを独自の認証システムに移植し、ログ形式を同じに保ち、可能であれば、各試行の処理を追跡および更新することです。
私はここでホイールを作り直そうとはしていません、そしていくつかの前の仕事が存在するべきだと思います。
ここでの問題は、あらゆる形態のなりすましがさまざまな理由で実行されることです。
- Sudoは通常、特権の低いユーザーが通常はより高いレベルの特権を必要とするタスクを実行できるようにするために使用されます。
- Exchangeの偽装を使用すると、任意の特権レベルのすべてのユーザーが別のユーザーとしてメッセージを送信できるようになりますが、アカウントの他の機能は許可されません。
- ヘルプデスクのなりすましにより、特定の目的で特権の高いユーザー（ITスタッフ）が特権の低いユーザー（他のすべてのユーザー）の役割を引き受けることができる傾向があります（この場合、「特権」はシステムアクセスにのみ関係し、会社の階層には関係しません）。ただし、たとえば、従業員による不正行為の疑いがある場合のアクティビティ監視を可能にするためにも使用できます。
- RunAsは、このコンテキストでは基本的にSudoと同じです。
その結果、それらはすべて、ロギングと通知の要件が異なります。
- Sudo：実際のユーザーアカウントと実行されたアクティビティをログに記録する必要があります
- Exchange：おそらく元のユーザーをログに記録する必要がありますが、アクティビティは通常の使用の一部としてログに記録され、通常は正当なユーザーによって許可が付与されるため、「このアクションはメインアカウントの所有者によって実行されました」というステータスが暗黙的に示される場合があります。なりすましユーザーが実際に実行した場合。秘書がマネージャーに代わって手紙を送ることを考えてみてください。マネージャーは、自分で「送信」を押さなかったとしても、通常は「送信者」と見なされます。
- ヘルプデスク：なりすましをログに記録する必要がありますが、実行された特定のアクティビティをログに記録することは困難/不可能な場合があります。たとえば、複雑なシステム内でダイアログを見つける方法をユーザーに示しているだけで、ログを記録する唯一の方法は、マウスのクリックがどこにあるかを記録し、その瞬間にスクリーンショットを撮ることです。従業員が調査中である場合、彼らに通知することは調査を危うくするかもしれません。
この問題のため、RFCでの標準化に役立つトピックではありません。非常に多くの除外と例外があり、ほとんど価値がなく、相互運用可能なシステムを構築することは事実上不可能です。
あなたが概説したステップは、あなたが持っているいくつかの例ではうまくいきません：
- 須藤-誰に通知しますか？ルートアカウント？誰がどのようにアクセスしますか？須藤を通して、多くの現代のシステムで！
- 交換-1つの一般的な使用法は、電子メールの受信者が休暇中に電子メールに応答できるようにすることです。試行ごとに承認を得る必要がある場合、そのユースケースは失敗します。ある人が別の人に代わって電子メールを準備するなど、他のユースケースでは問題ありません。
- ヘルプデスク-一般的な使用例の1つは、アカウントへのログインに関する問題を分類することです。ユーザーがログインできない場合、問題が発生するまで、偽装を有効なものとして受け入れることはできません。