基于服务器的应用程序安装程序创建新组是否可以接受？
我们正在构建一个设计为在基于 Windows 的服务器上运行的应用程序。我们目前正在研究的考虑因素之一是如何控制对应用程序 GUI 的访问，它允许配置和控制“后端”服务。
为了正确保护应用程序，有几个对象需要应用 ACL - 文件、目录、注册表项、命名管道、服务等。我们需要为管理员提供某种方法来配置这些 ACL 以限制访问仅限授权用户。
我们考虑过的一种方法是创建一个可以同时修改所有这些对象上的 ACL 的工具，但这将是一项相当大的工作，而且可能很脆弱。
我们正在考虑的另一种可能的方法是创建一个自定义组（例如“我的应用程序用户”），以便我们可以为该组授予每个对象的适当权限。这意味着管理员将能够使用熟悉的 Windows 组成员身份工具添加/删除授权用户。
那么：在安装时创建组是可以接受的事情，还是可能会让管理员感到不安？老实说，我更熟悉 UNIX 世界，基于服务器的应用程序或多或少都希望创建组，但我不确定 Windows 生态系统中的礼仪。
另外：是否有我错过的更好的解决方案？
提前致谢！
We're building an application designed to run on Windows-based servers. One of the considerations we're looking into at the moment is how to control access to the application's GUI, which allows configuration and controls the "back end" services.
In order to secure the application properly, there are several objects which will need ACLs to be applied - files, directories, Registry keys, named pipes, services etc. We need to provide administrators with some way to configure those ACLs in order to limit access to authorized users only.
One approach we have considered is to create a tool which can modify the ACLs on all those objects simultaneously, but that would be a fair chunk of work and could be fragile.
The other possible approach we're looking at is to create a custom group (e.g. "My App Users") so we can give that group the appropriate rights to each object. This means that administrators will be able to add/remove authorized users by using familiar Windows group membership tools.
So: is creating groups at install time an acceptable thing to do, or is it likely to upset administrators? I'm more familiar with the UNIX world, to be honest, where server-based apps are more or less expected to create groups, but I'm uncertain of the etiquette in the Windows ecosystem.
Also: is there a better solution to this that I've missed?
Thanks in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这个问题有两个方面：一是技术问题，二是政治问题。从技术上讲，本地组很好，您可以将 AD 或域用户添加到本地组中，每个人都很高兴。关于应用程序是否应该扰乱服务器的安全“立场”，唯一合理的答案是弹出某种请求，告诉用户您要做什么并请求许可（确保您还将决定记录在某种日志或条目）。这也解决了每个人的法律问题，例如，如果他们单击“不，让我的应用程序不安全”并遭到黑客攻击）。
采用 UNIX 方法，您可以告诉用户您需要什么，建议本地组（并让用户有机会选择另一个本地或域/AD 组）。看一下（例如）UNIX 上的 Oracle 安装是如何做到的。
由于这是一个服务器应用程序，您可能必须支持静默/无人值守安装，因此请确保可以在安装脚本中指定该行为，并且非常非常确定该脚本的行为已记录在案，以便没有人在没有安装该程序的情况下安装该程序实现安装程序实施的安全策略的更改。
The question is twofold - one technical, and one political. Technically a local group is fine, you can add AD or domain users into a local group and everyone's happy. In terms of whether an app should be messing with a server's security 'stance', the only reasonable answer is to pop up some kind of request telling the user what you are going to do and asking permission (make sure you also document the decision in some kind of log or entry). This also addresses everybody's legal a$$ eg if they click "no, leave my app unsecured" and get hacked).
Taking a UNIX approach, you could tell the user what you need, suggest a local group (and give the user the chance to pick another local or domain/AD group). Take a look at how (eg) Oracle installs on UNIX do it.
Since this is a server app and you might have to support silent/unattended install, make sure that the behavior can be specified in the install script and very, very sure that the behavior of the script is documented so that no one installs the program without realizing the change in security policy that the installer implements.
我认为为此目的创建一个本地小组是完全可以的。
此外，经过深思熟虑，我也没有找到更好的解决方案。
I think it's perfectly fine to create a local group for this purpose.
Furthermore I have not been able to come up with a better solution after giving it some thought.
根据实施的规模，分组可能是最佳选择。
但请记住，应该设置目录和注册表的相关 ACL。我确实同意将它们设置为组一次，然后让组成员身份维护访问控制。
关于 klausbyskov 的回答，我认为本地组可能没问题，但请考虑使用 LDAP。从安全角度来看，您可以分离身份验证过程并让目录来处理它；使用 Kerberos。
Depending on the size of the implementation, groups could be the way to go.
But please keep in mind that the relevant ACLs on directories and the registry ought to be set. I do agree that setting them once to the group and then let access control be maintained by group memberships.
In regards to klausbyskov's answer, I think a local group could be fine, but consider using LDAP instead. From a security perspective you would detach the authentification process and let the Directory handle it; using kerberos.