数据安全是否应该在数据库侧进行？

StackOverflow https://stackoverflow.com/questions/55845

  •  09-06-2019
  •  | 
  •  

题

我们正在为新的内部应用程序建立新的框架和开展业务的方式。我们当前的设计规定所有安全逻辑都应由我们的数据库处理，并且所有信息（我的意思是所有）都将通过存储过程进出数据库。

理论上，数据访问层从存储过程请求信息并将身份验证传递给数据库。数据库确定用户的角色/权限并决定是否执行任务（无论是检索数据还是进行更新）。

我想这意味着更少的数据库事务。对数据库的一次调用。如果安全性位于我们的数据访问层，则需要 1 次数据库调用来确定用户是否具有适当的权限，然后需要 1 次单独的数据库调用来执行该操作。

就我而言，我发现 SQL Management studio 完全不具备作为 IDE 的能力。我主要担心的是，我们最终将不得不在存储过程中维护一些令人讨厌的业务逻辑，以获得一些非常小的性能提升。

现在，我们使用 LINQ 作为 ORM。它看起来又轻又快，但最重要的是，它真的很容易快速开发。

维护成本值得性能提升吗？我们是否自欺欺人地认为性能会有明显的提升？或者我们只是在为自己制造一场噩梦？

我们的环境：

  • 内部非关键任务业务应用程序
  • C#/ASP.NET 3.5
  • 视窗2003
  • 微软 SQL Server 2005
  • 35 个中等规模的 Web 应用程序，约有 500 个用户
有帮助吗？

解决方案

不要那样做. 。我们最近有一个 很坏 “数据库大师”决定去另一家公司时的经历。程序中所有逻辑的维护真是太糟糕了！

是的，您将会获得一些性能提升，但这并不值得。事实上，在内部应用中，性能甚至不是一个大问题。投入更多的钱购买好的服务器。它会得到回报。

其他提示

不幸的是，没有“一个正确的答案”。您必须做出的选择取决于多种因素，例如：

  • 团队对给定解决方案的熟悉程度（即，如果大多数人喜欢编写 SQL，则可以在数据库中，但是如果大多数人更喜欢 C#，则应该在代码中）
  • 各党派的“政治权力”
  • ETC

在任何方向上都没有决定性的优势（正如你所说的性能提升微乎其微），需要记住的一件事是 DRY（不要重复自己）原则：不要两次重新实现该功能（在代码中和在数据库中），因为保持它们同步将是一场噩梦。选择一种解决方案并坚持下去。

你可以做到，但是开发和维护是一个巨大的痛苦。这是从一个几乎所有业务逻辑都编码在存储过程中的项目中的某人那里得到的。

为了安全起见，ASP.NET 内置了用户和角色管理，因此您可能会保存对数据库的访问，但那又怎样呢？作为交换，处理和调试系统和验证错误变得更加烦人，因为它们必须从数据库中冒出来。

单元测试要困难得多，因为可用于单元测试存储过程的框架还远远不够开发。

正确的 oop 和领域驱动设计几乎是不可能的。

而且性能提升即使有的话也是很小的。我们讨论过这个 这里.

我建议，如果您想保持作为开发人员的理智，请竭尽全力将数据库仅作为持久层

恕我直言：

应用服务层 -> 应用逻辑和验证
应用数据层->数据逻辑和安全
数据库->数据一致性

你迟早会被存储过程方法所困扰，我已经通过惨痛的教训学到了这一点。
Procs 非常适合需要大量性能的一次性操作，但 CRUD 部分是数据层工作

存储过程通常是安全性的胜利。简化应用程序和数据库之间的关系可以减少可能出错的地方；将业务逻辑与数据库连接的代码中的错误往往会导致安全问题。因此，您的 DBA 将事情锁定到存储过程并没有错。

将应用程序锁定到存储过程的另一个好处是应用程序堆栈的数据库连接可以将其权限锁定到特定的存储过程调用，而不是其他任何东西。

让 DBA 参与应用程序的安全逻辑的一个好处是，不同的应用程序功能和角色可以在数据库中划分为视图，这样即使需要动态 SQL 和通用 select 语句，SQL 漏洞造成的损害也不会受到影响。可以被约束。

当然，这样做的另一面是失去了灵活性。显然，ORM 的开发速度比与 DBA 就存储过程参数不断协商要快。而且，随着这些存储过程的压力越来越大，过程本身越来越有可能诉诸动态 SQL，这与应用程序组成的 SQL 一样容易受到攻击。

这里有一个快乐的中间立场，你应该尝试找到它。我最近参与过一些项目，这些项目避免了非常可怕的 SQL 注入问题，因为 DBA 仔细配置了数据库、其连接及其存储过程，以实现“最小权限”，以便任何一个数据库用户只能访问他们所访问的内容。需要知道。

显然，当您在应用程序逻辑中编写 SQL 代码时，请确保您始终使用参数化准备好的语句，您正在清理您的输入，您要注意国际化输入（有很多很多方法可以说单个-quote over HTTP），并且您要注意当输入对于列宽而言太大时数据库的行为方式。

这完全取决于您的情况，最好不要走 SP 路线并以 DDD 方式完成所有操作（在代码中创建域模型并使用它）。

但是，如果您的数据库不仅由您的应用程序使用，而且还被许多应用程序使用，那么您可能应该考虑 Web 服务。无论如何，数据库只能通过执行业务规则的一层进行访问，否则您将得到“脏”数据，并且事后清理数据比事先编写一些业务规则要痛苦得多。一个好的数据库应该设置检查约束和索引，因此无论你喜欢与否，它都会有一些业务规则。

如果您必须处理数百万条记录，您将很高兴有一个优秀的数据库人员来为您解决问题。

我的观点是应用程序本身应该处理身份验证和授权。在数据库方面，您应该只根据需要处理数据加密。

我过去构建过基于存储过程的应用程序。在您的情况下，可能有一种方法可以在数据库层保留身份验证并在 C# 中使用业务逻辑。使用视图来限制数据（您只能看到您有权访问的行）。这些视图可以像表一样轻松地在 LINQ 中使用。您可以使用存储过程设置更新。

这允许使用 linq、C# 中的业务逻辑以及数据库中控制数据访问的公共身份验证层。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top