基于服务器的应用程序安装程序是否可以创建新组?

时间:2009-12-09 15:56:32

标签: windows security installer usergroups

我们正在构建一个旨在在基于Windows的服务器上运行的应用程序。我们目前正在考虑的一个考虑因素是如何控制对应用程序GUI的访问,这允许配置和控制“后端”服务。

为了正确保护应用程序,有几个对象需要应用ACL - 文件,目录,注册表项,命名管道,服务等。我们需要为管理员提供一些方法来按顺序配置这些ACL仅限授权用户访问。

我们考虑过的一种方法是创建一个可以同时修改所有这些对象的ACL的工具,但这将是一项相当大的工作,并且可能很脆弱。

我们正在研究的另一种可能的方法是创建一个自定义组(例如“我的应用程序用户”),这样我们就可以为该组赋予每个对象适当的权限。这意味着管理员可以使用熟悉的Windows组成员资格工具添加/删除授权用户。

所以:在安装时创建组是可接受的事情,还是可能会让管理员感到不安?我更熟悉UNIX世界,说实话,基于服务器的应用程序或多或少地期望创建组,但我不确定Windows生态系统中的礼仪。

另外:我错过了更好的解决方案吗?

提前致谢!

3 个答案:

答案 0 :(得分:2)

这个问题是双重的 - 一个技术问题,一个政治问题。从技术上讲,本地组很好,您可以将AD或域用户添加到本地组中,每个人都很高兴。关于应用程序是否应该破坏服务器的安全“立场”,唯一合理的答案是弹出某种请求告诉用户你要做什么并请求许可(确保你也记录了决定)某种日志或条目)。这也解决了每个人的合法a $$,例如,如果他们点击“不,让我的应用程序无担保”并被黑客入侵)。

采用UNIX方法,您可以告诉用户您需要什么,建议本地组(并让用户有机会选择另一个本地或域/ AD组)。看看(例如)Oracle在UNIX上安装的方式。

由于这是一个服务器应用程序,您可能必须支持静默/无人参与安装,因此请确保可以在安装脚本中指定行为,并且非常非常确定脚本的行为是否已记录,以便无人安装程序没有意识到安装程序实现的安全策略的更改。

答案 1 :(得分:0)

我认为为此目的创建一个本地小组是完全可以的。

此外,在考虑之后,我还没有能够提出更好的解决方案。

答案 2 :(得分:0)

根据实施的规模,群组可能是最佳选择。 但请记住,应该设置目录和注册表上的相关ACL。我同意将它们设置为一次,然后让组成员资格维护访问控制。 关于klausbyskov的回答,我认为本地组可能没问题,但考虑使用LDAP。从安全角度来看,您将分离身份验证过程并让目录处理它;使用kerberos。