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