IISアプリケーション-サービスアカウント権限
私の会社は、インフラストラクチャにサードパーティアプリケーションをインストールしようとしています。このアプリケーションは、IIS SQLサーバーへの接続を持つサーバーにインストールされます。これらのサーバーには、次の権限を持つADサービスアカウントが必要です、その一部は私には大ざっぱに見えます。悪意のある俳優がアカウントを危険にさらした場合、次のことができる場合、アカウントにそのような権限を与えることのリスクは何ですか？
- 特定のアプリケーションフォルダーに対する完全な読み取り/書き込み権限-問題ではありません。
- SQL Serverを読み取ってログオンする-問題ではありません。
- サービスを開始できる必要があります-サービスの終了は心配になりますが、サービスの開始に関連するリスクはありますか？
- .exeファイルの開始-再度理由を調査する必要がありますが、サービスアカウントが侵害されている場合、.exeファイルの開始により、悪意のあるユーザーが悪意のある.exeファイルを実行できる可能性があると思いますか？
- .batファイルを実行する-考えはありますか？
サービスが開始されたプロセスのセキュリティトークンを継承するのではなく、自分のユーザーとして実行されるため、サービスが開始されるのは潜在的にでもある唯一のリスクです。サービスアカウントがより特権の高いサービスを起動できる場合、特にそれらのいずれかがパラメーターを取得する場合や、サービスアカウントが改ざんできるデータを消費する場合は、それは確実なリスクです。
それ以外はすべて、攻撃者（アプリケーションを危険にさらすことに成功した）またはアプリケーション自体（悪意がある場合）がすでに効果的に実行できるものです。悪意のあるアクターがマシン上で実行されているコードをすでに制御している場合、エクスプロイトを容易にすることはできますが、実際には同じセキュリティトークンで新しいプロセスを生成する必要はありません（これは、EXEまたはBATファイルを起動すると起こります） 。ただし、サービスを開始するということは、コードをdifferent権限で実行することを意味します。これで、低特権のサービスアカウントから抜け出し、「SYSTEM」全体を引き継ぐのに十分な可能性があります。
サンドボックスに必要のない特権を与えるべきではないことは明らかです。たとえば、Chromeのレンダープロセスは子プロセスを起動できません。ただし、許可がほとんど制限されていなくても、サービスアカウントのアクセス制限がある限りはです。 EXEを起動できるようにするのに十分なタイトです（cmd.exe、これは「.batファイルの実行」が実際に行うことです）、サービスアカウントの権限が広すぎる場合、アプリケーション内でコード実行を取得する攻撃者はneed他のプロセス。
これらはすべて、サーバーが自己監視および自己回復スクリプトを使用して実行する場合、かなり正常に見えます。確かに、.batファイルの使用は少し古い形式ですが、珍しいことではありません。