我们正在构建一个旨在在基于 Windows 的服务器上运行的应用程序。我们目前正在研究的考虑因素之一是如何控制对应用程序 GUI 的访问，它允许配置和控制“后端”服务。
为了正确保护应用程序，有几个对象需要应用 ACL——文件、目录、注册表项、命名管道、服务等。我们需要为管理员提供一些方法来配置这些 ACL，以便仅限授权用户访问。
我们考虑过的一种方法是创建一个可以同时修改所有这些对象的 ACL 的工具，但这将是一项相当大的工作，而且可能很脆弱。
我们正在寻找的另一种可能的方法是创建一个自定义组(例如“我的应用程序用户”)，这样我们就可以为该组授予对每个对象的适当权限。这意味着管理员将能够使用熟悉的 Windows 组成员工具添加/删除授权用户。
那么:在安装时创建组是可以接受的事情，还是可能会让管理员不高兴？老实说，我更熟悉 UNIX 世界，其中基于服务器的应用或多或少会创建组，但我不确定 Windows 生态系统中的礼节。
此外:是否有我错过的更好的解决方案？
提前致谢!
最佳答案
问题有两个方面 - 一个是技术问题，一个是政治问题。从技术上讲，本地组很好，您可以将 AD 或域用户添加到本地组中，每个人都很高兴。关于应用程序是否应该扰乱服务器的安全“立场”，唯一合理的答案是弹出某种请求，告诉用户您将要做什么并征求许可(确保您还记录了决定某种日志或条目)。这也解决了每个人的合法 a$$ 例如，如果他们单击“不，让我的应用程序不安全”并被黑客攻击)。
采用 UNIX 方法，您可以告诉用户您需要什么，建议本地组(并让用户有机会选择另一个本地或域/AD 组)。看看(例如)Oracle 在 UNIX 上安装是如何做到的。
由于这是一个服务器应用程序，您可能必须支持静默/无人值守安装，因此请确保可以在安装脚本中指定该行为，并且非常非常确定该脚本的行为已记录在案，这样就不会有人安装程序没有意识到安装程序实现的安全策略发生了变化。
关于windows - 基于服务器的应用程序安装程序创建新组是否可以接受？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1874849/