正在寻找数据访问层保护建议

我目前正在参与一个非常大的供应链管理软件系统，内部就职于我的职位。系统的用户界面目前仅通过ASP.NET实现，但我们也在开发Windows Forms和Windows Mobile Compact界面。我们在界面，业务和数据访问层的分离方面拥有相当不错的设置，所以我们已经在多个平台上成功共享。但是，当我们将基于客户端的接口分发给客户时，我们有一些安全问题。正在寻找数据访问层保护建议

我们的一些数据访问库随可执行文件一起发布。只需在记事本中打开已编译的程序集，就可以查看其中的任何查询。

例如，假设我们有一个名为“用户”谁实现方法“的GetName”作为类：

从用户选择name其中id = @id

的问题是任何足够强烈的人都可以在记事本中打开已编译的程序集，现在可以看到列名和表名。当然，他们可能无法访问这些内容，但如果我不需要，我还是宁愿不公开这个模式。

以上只是一个简单的例子。我是否正确地思考了思考过程，还是有办法保护我们的疑问？（我宁愿不诉诸使用存储过程的一切。）

我想过迫使数据访问层是远程和通过Web服务从业务层进行通信，以便所有与数据库相关的信息都在我们的内部服务器，我们可以更容易保护。

来源

2010-02-27 Justin Skiles

使用存储过程比这更有益处。对于一个如果你改变你的模式，因此不得不改变你的SQL查询，你将不必对你的C＃源代码做任何事情。 Stored Procs还有其他几个好处。 – awright18 2010-02-27 21:43:11

它确实要求您的数据库和存储过程语言不会更改。但是我发现很难从一个数据库供应商切换到另一个数据库供应商。 – duffymo 2010-02-27 21:49:35

从客户端移动DAL并将其放在业务层后面有很多好处，通常称为n层开发。如果您需要对模式进行更改，则很容易做到，这意味着更新您的服务器，但如果意味着更新每个客户端，则很困难。 – sipwiz 2010-02-27 21:56:03

如果你想从src中删除sql，那么你正在寻找另一个像web服务的图层。虽然这隐藏了您的SQL，但服务本身现在必须公开。所以，当那些偷看的人看不到数据库模式时，他们仍然可以看到数据布局。

Web服务允许的是更简单的方式来进行模式更改，因为现在您只需确保数据输出始终相同即可。它还允许您移动，重命名和/或执行模式dbs的其他维护。最后，它最好允许你将数据库连接集中在本地而不是通过网络，并在服务器上运行更多的处理。

来源

2010-02-27 21:53:52 JDMX

这是我正在考虑的方法，需要某种凭证才能访问Web服务。 – 2010-02-27 22:07:25

证书是给定的，特别是对于任何更新数据库的服务。只是因为你的数据库模式现在隐藏并不意味着你可以在记事本中查看有价值的信息。 – JDMX 2010-02-27 22:38:55

正在寻找数据访问层保护建议

回答

相关问题