我们的应用程序是在。net WinForms和SQL server中开发的，它有自己的用户认证&;配置文件授权机制映射到SQL登录名/用户/角色，部署在DMZ网络中，只有授权的人才可以访问。
潜在客户的IT部门抱怨在SQL服务器上维护数百个登录/用户/角色，他们只希望一个SQL登录/用户附加到单个SQL服务器角色，其余的安全事项必须在客户端应用程序中管理。
-
a)而不是每个数据库用户登录，我可以减少通过映射到NT组并将其链接到应用程序用户配置文件?有没有更好的办法?
-
b)如何减少数据库用户的数量而不失去审计的可能性?有150个活跃用户，每个用户都应该被跟踪。
这完全取决于你需要多安全。
在谈到客户端应用程序时,你已经被他们的本质问题,客户端工具————容易被滥用;例如，如果我有一个客户端应用程序的副本，那么对我来说，反编译/逆向工程它正在做的任何事情，并更改逻辑——完全绕过客户端应用程序中的任何和所有安全是相对微不足道的。您可能仍然可以在数据库服务器上进行审计，但老实说:在大多数情况下，除非您在行为中捕获恶意数据库访问，否则很难知道发生了什么—客户机软件可能不执行任何审计步骤，或者执行任何令人困惑的审计步骤。现在:如果你采取这种情况和使用单个登录，与客户端直接连接:问题变得更糟:这些登录细节将需要嵌入到应用程序中，以便应用程序可以代表共享凭据登录(这意味着:任何攻击者都可以获得它们)，如果你在行动中捕获一些东西:你会看到它发生在那些共享凭据-除非你可以查看IP数据等。
如果这对你来说不是一个攻击向量，那么当然，只要做你需要做的——但是你提到审计的事实意味着这是可能不可取的。
相反，我建议考虑让客户端间接地与数据库对话。如果客户端应用程序仅通过web服务(您选择的任何类型的web服务)进行通信，那么客户端所能做的事情将受到更大的限制。您可以在web服务层使用现有的安全模型，然后一旦您对用户等进行了身份验证，就可以切换到可信子系统模型，以便使用单个凭据(可能是运行web服务的AD帐户)与数据库通信。web服务器是一个更难被攻击和滥用的目标。现在，你可以将所有的逻辑、安全检查、审计等保存在web服务层，而不是客户端(当然，你可以在客户端复制这些检查，在不打扰web服务的情况下，提供不允许操作的即时UI反馈)。这为您提供了和的两全其美，可能允许更好的远程使用。然而，这几乎肯定意味着重写应用程序的整个数据层。