Entity Framework и STIG

Question

Я работаю над проектом для DoD с использованием Microsoft MVC и всех других связанных технологий.

Для обеспечения безопасности я должен следовать Руководству по технической поддержке безопасности (STIG).

В версии 3, выпуск 9, раздел 3.10.1, это означает, что «Разрешить доступ к базе данных через представления нет непосредственно в базовые таблицы в базе данных».

Он также указывает, что «(APP3540.4: CAT II) Дизайнер гарантирует, что приложение не будет напрямую обращаться к таблицам в базе данных».

Мой вопрос: могу ли я использовать Entity Framework с LINQ?

Вот ссылка ссылка: http://iase.disa.mil/stigs/app-security/app-security/Pages/app-security.aspx

Спасибо!

Answer 1

Ну, это один из способов предотвратить инъекцию SQL, я полагаю, но человек, оставляйте это правительству США, чтобы применять правила asinine к тем, что должно быть простым.

Ограничение в основном требует, чтобы сайт был только для чтения. Предположительно, это относится только к объектам, открытым для публики, поэтому вы все равно можете разрешать прямой доступ к базе данных во внутреннем приложении (в противном случае я понятия не имею, как вы на самом деле когда-либо сохраняете что-либо). Несмотря на это, 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, которые позволяют писать, но так как подложка представляет собой вид, го ese будет увеличивать исключения при запуске. Если вы можете сделать что-то вроде запуска хранимой процедуры для внесения изменений, что косвенно разрешает доступ на запись, но технически само приложение не касается базы данных, тогда вы также можете использовать Entity Framework. См. Code First Insert/Update/Delete Stored Procedures для получения дополнительной информации (к сожалению, только EF6 и выше, хотя).

Answer 2

Прямой link в STIG. Это одна ревизия старой, но я смотрю на последнюю, и они точно такие же. Я думаю, что текст не менялся много лет, что печально, так как это не очень понятно. В названии правила указано использование параметризованных операторов (которые я вижу как любая операция CRUD), но также не предоставлять прямой доступ к таблице.

Entity Framework отправляет параметризованные запросы в базу данных, которая является формой прямого доступа. Думаю, это небезопасно? Точно нет. Но можно утверждать, что STIG говорит, что не делать этого. Проблема заключается в том, что STIG также использует использование хранимой процедуры вместо прямого доступа, но вы можете так же легко получить SQL-инъекции, если они написаны неправильно.

Мое толкование?В конце концов, вся суть заключается в том, чтобы обращаться к SQL-инъекции, пока вы используете параметризованные запросы (например, EF, Dapper, ADO.NET и т. Д.) Или записываете надлежащие хранимые процедуры для смягчения этого, вы должны быть в порядке.

Answer 3

STIG на самом деле не требует ReadOnly, только эти представления используются вместо прямого обращения к таблицам.

Поэтому вместо подключения к tblEmployees вы должны подключиться к vwEmployees (который является представлением tblEmployees).

Это значит, что вы можете иметь больший контроль над разрешениями, элементами управления доступом и ограничениями.

Пример: роль пользователя 1 может видеть столбцы A и B, но не C и D. Если вы подключаетесь непосредственно к таблице, пользовательская роль 1 будет иметь разрешения для столбцов A-D. Таким образом, может быть создан вид, который включает только столбцы A и B.

Пример2: Другие правила DoD включают в себя такие вещи, как захват, который в последний раз изменил данные. Много раз это достигается с помощью триггеров, которые сохраняют имя пользователя/datetime в столбцы в таблице для каждой строки. Очевидно, что это не то, к чему должен иметь доступ пользователь или программа. При непосредственном доступе к таблицам вы не можете удалить это разрешение. Таким образом, вы создаете представление обо всех столбцах, кроме двух.

Что касается вопроса, соединения с базой данных не волнуют, разговариваете ли вы с видом или таблицей, они будут вести себя так же, как и в отношении программы.

Спасибо. Шон.