Kerberos委任のリスク
IIS 7.5で、Windows認証、Kerberos、SPN、および制約付き委任を学習して理解しようと何時間も費やしてきました。私が得られないことの1つは、なぜそれが「危険」なのかということです。 「管理者、CEOなどの委任を有効のままにする（つまり、機密性の高いアカウントの委任を無効にしない）。誰かがこれを簡単に説明してくれませんか？イントラネット環境に関して回答を組み立ててください。
私の推論は、他のサーバーと通信するときに、委任によって、たとえばフロントエンドWebサーバーがWindows Authenticatedの担当者に代わって動作することを許可するだけなので、心配する必要はないということです。その人がアクセスできる場合、彼らはアクセスできます。なぜこれが問題になるのか理解できません。
私の無知を許してください。私は主に開発者ですが、最近は会社が非常にスリムになっていて、サーバー管理者の帽子をかぶることを余儀なくされています...残念ながら、それでもうまく適合しません（笑）。
2つの例：
制約付き委任により、ユーザーの資格情報や認証トークンがなくても偽装が可能になります。例については、これを参照してください answer 。
より一般的な肉とジャガイモの制約のない委任シナリオでは、Windows統合認証であろうとフォーム認証であろうと、ユーザーの認証トークンへの委任アクセス権はとてもパワフルな。これは文字通り、トークンを使用してそのユーザーになりすまし、任意のネットワークリソースにアクセスできることを意味します。開発者など、そのプロセスに関与する人は誰でも、不正な方法でそれを使用して、不正アクセスを取得する可能性があります。
どちらの例でも、[アカウントは機密であり、委任できない]チェックボックスがオンになっている場合、これらはセキュリティの問題ではありません。これらの機能が存在するが、厳密に制御されているシステム/機能を設計することも可能です。
Enterprise Adminsグループのメンバーなど、管理者アカウントの場合は、このボックスをオンにする必要があります。これらのアカウントでは、偽装が必要なアプリケーションを使用する必要がほとんどないためです。また、CIO、COO、財務/財務責任者などの機密情報にアクセスできる上級管理職にとっても良い考えです。
つまり、Microsoftは、非常に正当な理由でそのチェックボックスとそれに伴う警告を提供しました。特定のシナリオに望ましくないリスクへの暴露や何らかの補償制御がないことが実証されない限り、それを却下したり軽視したりしないでください。これには通常、アプリケーションまたはシステムの実際の実装または開発に関与していない有資格者による審査が含まれます。
私は何千もの顧客を、ほとんどの制約のない代表団と一緒にセットアップしました。アプリケーションを信頼しない場合（たとえば、IISに展開されている場合）、または他のユーザーが自由に使用できるように委任されたサービスアカウントの資格情報を提供している場合は、委任を制限することをお勧めします。ただし、誰かがアプリケーションを書き換えることができるとは思わない場合は、サービスアカウントの資格情報を安全に保ち、アプリが設計されたサービスにのみ委任されることを信頼します。通常、心配する必要はありません。一部の「セキュリティを意識した」顧客は、このような問題に非常に重点を置いていますが、実際のセキュリティの脅威にリソースを費やすほうがよいでしょう...