Выбор места принудительного применения безопасности

  • Статья

Компромиссы присущи принудительному обеспечению безопасности. База данных может быть естественным местом для размещения логики безопасности, учитывая, что в конечном счете данные являются наиболее важными для защиты. Однако это имеет значительные последствия для производительности. Обеспечение безопасности в базе данных может быть очень дорогим, масштабируется плохо и является негибким.

Обеспечение безопасности на среднем уровне

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

Оптимальная ситуация заключается в том, чтобы обеспечить безопасность таблиц базы данных, чтобы приложение COM+ могло получить доступ к ним под собственным удостоверением. База данных должна просто пройти проверку подлинности приложения COM+ и доверять ей для правильной проверки подлинности и авторизации клиентов, которые будут получать доступ к данным. Ниже приведены преимущества этого подхода.

  • Он обеспечивает пул подключений среди всех клиентов, так как подключения являются полностью универсальными.
  • Обычно она оптимизирует доступ к данным, часто проблематичную точку чоха при масштабировании приложений.
  • Это может свести к минимуму затраты логики для обеспечения безопасности, особенно если можно использовать декларативную безопасность на основе ролей.
  • Она может обеспечить большую гибкость в политике безопасности. Вы можете легко настроить и перенастроить его, как описано в разделе "Безопасность на основе ролей" Администратор istration.

Но, как описано в статье "Проектирование ролей эффективно", в то время как роли могут быть легко и эффективно применены к некоторым связям с данными пользователей, они не являются универсальным решением для решений по доступу к безопасности.

Обеспечение безопасности в базе данных

Несмотря на предпочтительность обеспечения безопасности на среднем уровне, существует ряд причин для обеспечения безопасности в базе данных, таких как:

  • У вас нет выбора, возможно, по устаревшим причинам или, возможно, потому что решение просто не в ваших руках.
  • Доступ к базе данных осуществляется различными приложениями, и ее безопасность не может быть настроена на основе одного приложения.
  • Базу данных можно сделать предсказуемо защищенной. Если вы храните критически важные данные предприятия в базе данных, вы можете нарисовать узкий вагон вокруг него и помочь контролировать, кто получает, чтобы увидеть его.
  • Проверка подлинности исходных клиентов в базе данных позволяет подробно ведения журнала, который сделал то, что в базе данных.
  • Некоторые данные изначально привязаны к конкретным пользователям, и логика принятия решений об очень точном доступе может быть наиболее эффективно проведена в самой базе данных рядом с данными.

Когда у вас есть роскошь проектирования безопасности базы данных и приложения COM+ в тандеме, большинство этих проблем относятся к характеристикам самих данных и его отношениям с пользователями, к которым он обращается. С помощью данных, к которым можно получить доступ с помощью прогнозируемых категорий пользователей, эффективно управлять доступом на среднем уровне с помощью ролей. С данными, которые сложно привязаны к очень небольшим классам пользователей, эти отношения часто должны быть выражены с самими данными, и поэтому необходимо обеспечить некоторую безопасность в базе данных.

Последствия обеспечения безопасности в базе данных

Если вы выполняете проверку подлинности или авторизуете пользователей в базе данных, удостоверение пользователя должно распространяться в базу данных для поддержки этого. Если база данных доверяет приложению среднего уровня для этого, можно передать сведения о безопасности пользователей в параметрах. В противном случае вызов к базе данных должен выполняться под удостоверением пользователя, что означает, что серверное приложение должно олицетворить клиента. Это может повлиять на производительность, например следующее:

  • Олицетворение клиента может быть гораздо медленнее, чем вызов непосредственно под удостоверением приложения. Дополнительные сведения см. в разделе олицетворение клиента и делегирование.
  • Подключение к базе данных, сделанное под определенным удостоверением пользователя, невозможно объединить в пул.
  • При добавлении логики в саму базу данных возникает риск создания узкого места масштабирования.

Основные сценарии защиты данных в многоуровневых приложениях

Безопасность приложений с несколькими уровнями