2

我正在使用 Microsoft 的 MVC 和所有其他相关技术为 DoD 开发一个项目。出于安全目的，我必须遵循安全技术实施指南（STIG）。

在第 3 版第 9 版第 3.10.1 节中，它表示

允许通过视图访问数据库，而不是直接访问数据库中的基础表。

和

（APP3540.4：CAT II）设计师将确保应用程序不会直接访问数据库中的表。

我可以将实体框架与 LINQ 一起使用吗？

4

3 回答 3

1

STIG 实际上并不需要 ReadOnly，只是使用视图而不是直接与表对话。

因此，不是连接到 tblEmployees，而是连接到 vwEmployees（这是 tblEmployees 的视图）。

这样您就可以更好地控制权限、访问控制和限制。

示例：用户角色 1 可以看到列 A 和 B，但看不到 C 和 D。如果您直接连接到表，用户角色 1 将拥有列 AD 的权限。因此可以创建一个仅包含 A 列和 B 列的视图。

示例 2：其他 DoD 规则包括捕获上次更改数据的人员等内容。很多时候，这是由触发器完成的，触发器将用户名/日期时间保存到表中每一行的列中。显然，这不是用户或程序应该有权访问的东西。通过直接访问表，您无法删除此权限。因此，您创建了除这两个之外的所有列的视图。

至于问题，数据库连接不会关心您是在与视图还是表交谈，就程序而言，它们的行为相同。

谢谢。肖恩。

于 2016-02-15T01:17:27.060 回答
1

这是 STIG的直接链接。这是一个旧版本，但我正在查看最新版本，它们完全相同。我认为文本多年来一直没有改变，这是不幸的，因为它不是很清楚。规则标题说使用参数化语句（我将其视为任何 CRUD 操作），但也不提供对表的直接访问。

Entity Framework 向数据库发送参数化查询，这是一种直接访问的形式。我认为它不安全吗？绝对不。但有人可能会争辩说，STIG 说不要这样做。问题是 STIG 还说使用存储过程代替直接访问，但是如果编写不正确，您也很容易遇到 SQL 注入漏洞。

我的解释？最后，重点是解决 SQL 注入问题，只要您使用参数化查询（即 EF、Dapper、ADO.NET 等）或编写适当的存储过程来缓解这种情况，您应该没问题。

于 2016-01-28T23:32:59.663 回答
-1

好吧，我想这是防止 SQL 注入的一种方法，但是伙计，让美国政府将愚蠢的规则应用于应该是简单的事情。

该限制基本上要求网站是只读的。据推测，这仅适用于面向公众的属性，因此您仍然可以允许直接访问内部应用程序上的数据库（否​​则，我不知道您实际上将如何持久保存任何内容）。无论如何，Entity Framework 可以轻松处理这个问题。就使用视图而言，你真的不需要做太多特别的事情。如果您将 Code First 与现有数据库一起使用并命名您的视图以使其遵循 EF 约定（实体名称的复数版本），那么您实际上不必做任何特别的事情。

要使 EF 与现有数据库一起使用，您只需将DbContext子类的构造函数修改为 1) 显式引用连接字符串和 2) 禁用初始化程序：

public class ApplicationContext : DbContext
{
    public ApplicationContext()
        : base("ConnectionStringName")
    {
        Database.SetInitializer<ApplicationContext>(null);
    }

    // DbSets here
}

如果您的视图名称不符合 EF 约定，那么您可以明确说明您的实体应引用的内容：

[Table("awesomefooview")]
public class Foo
{
    ...
}

从技术上讲，您仍将拥有允许写入的实体框架 API 方法，但由于支持是视图，因此如果运行这些方法将引发异常。如果您可以执行诸如运行存储过程进行更改之类的操作，这间接地允许写访问，但从技术上讲，应用程序本身并没有触及数据库，那么您也可以让 Entity Framework 使用这些。有关更多信息，请参阅代码优先插入/更新/删除存储过程（不幸的是，只有 EF6 及更高版本）。

于 2014-12-02T19:31:40.660 回答