背景：我们的团队正在构建一个内部Intranet web应用程序。我们正在使用标准的三层方法。展示层(mvc web app(、业务层和数据访问层。
Sql数据库用于持久性。
Web app/is处理用户身份验证(windows身份验证(。日志记录是在业务和数据访问层中完成的。
问题服务帐户与特定于用户的Sql帐户： 使用服务/应用程序帐户：开发团队建议设置服务帐户(仅针对应用程序设置(。此服务帐户需要写入&对数据库的读取访问。
与
将用户凭据传递到SQLIT运营部门表示，使用服务帐户(专门为应用程序创建(访问数据库不被视为最佳做法。设置从web服务器到SQL服务器配置的Kerberos委派，以便您可以传递最终用户的Windows凭据&创建一个数据库角色，为最终用户授予适当的数据访问级别
在sql中设置帐户的最佳做法是什么？在sql中，所有对数据库的请求都将通过前端客户端(即通过总线层和数据层(
这里的最佳实践是让负责数据库的人员/团队做出决定。听起来开发团队想向DB转发(或模拟(一些凭据，我知道一些小团队喜欢这样做，但是的，这可能会让事情变得有点太开放。该应用程序可以对数据库做任何它喜欢的事情，如果你喜欢这种事情，这并不是一个很大的分离。
就我个人而言，如果我理解你上面所说的，我会做更多IT团队正在考虑的事情(我使用Postgres(。换句话说，我的应用程序使用给定的帐户(假设它是AppName帐户(通过SSH进行部署。这意味着我需要为安全部署(使用PEM或known_keys或其他什么(排列SSH密钥。
在AppName的根目录中，我有一个名为.pgpass的文件，它具有非常特定的安全性(0600(。这意味着我的AppName帐户将使用本地安全性而不是用户名/密码登录。
我这样做是因为否则我需要将这些信息存储在某个文件中——例如，这些信息会被推送到github。
最终，想想5年后你的项目和团队会是什么样子。乐观一点——也许这将是一个巨大的成功！维护会是什么样子？你的团队会犯什么样的错误？灵活性现在很好，但请确保，如果数据库出现安全问题，谁会遇到麻烦，谁就可以做出决定。
最佳做法是拥有单独的帐户。这允许您使用数据库工具来识别访问数据库的人员。
如果正在修改数据，这一点尤为重要。您可以记录谁在修改什么数据——在任何用户具有此功能的系统中，这通常是一项核心要求。
您可能会发现，出于某种原因，您不想使用数据库的内置身份验证机制。在这种情况下，您可能会在数据库的顶部构建一个层，复制大部分内置功能。在某些情况下，这可能是必要的。一般来说，这将是一种危险的方法(数据库安全机制可能比定制代码要经受更多的测试(。
最后，如果您构建的内部应用程序只有少数对数据库具有只读访问权限的用户，那么只有一个登录帐户可能会更简单。通常，您仍然想知道谁在做什么，但为了简单起见，您可能会放弃该功能。然而，了解谁在做什么对于维护和增强应用程序通常是非常有用的知识。