Безопасность на уровне строк в сценарии клиент-база данных

Question

Я ищу хороший шаблон для реализации мер безопасности на уровне строк (например, через прокси, веб-службу "человек посередине" или хранимые процедуры), подходящих для использования в среде клиент-база данных. Я контролирую как клиента, так и базу данных. Некоторые требования:

• Запрещение пользователям видеть строки в результатах запроса, которые они не имеют разрешения на просмотр
• Разрешение пользователям вставлять и обновлять свои строки в таблице, что дает им разрешение на их просмотр
• (мягкое требование), позволяющее пользователям предоставлять другим доступ для чтения или записи своих строк
• Открытое или недорогое решение, работающее в Linux. Насколько я понимаю, ни одна бесплатная база данных не обеспечивает безопасность на уровне строк как таковую. Oracle поддерживает это, но это слишком $$$$. Postgres может реализовывать это в 9.4, но изначально он был нацелен на 9.3 и проскочил, и есть обсуждение ML, что он может снова проскочить. Я предварительно подумываю об использовании postgres только потому, что они кажутся наиболее далекими в этой функции.

Некоторые (не очень хорошие) идеи, которые у меня были:

• Используйте защитные барьеры postgresql и запретите пользователю доступ к базовой таблице. К сожалению, нет хорошего способа вставить строку в представление защитного барьера, поэтому некоторые привилегированные прокси / веб- службы должны будут обрабатывать операторы вставки. Это кажется трудно понять правильно.
• Используйте регулярные представления и запретите пользователю доступ к базовой таблице. Это позволяет insert, но мне нужно было бы довольно плотно заблокировать разрешения (например, не создавать функции), и, похоже, есть много ошибок (например, деление на ноль), которые пропускают информацию.
• Определите некоторое подмножество SQL и создайте прокси, который является вашей единственной точкой связи с базой данных. Прокси анализирует ваш SQL-запрос и переписывает его, чтобы обеспечить соблюдение требований безопасности. В общем, кажется, что это трудно сделать, но, возможно, я смогу обойтись без очень маленького подмножества SQL, пока postgres не реализует безопасность на уровне строк.
• Просто есть разные таблицы для разных пользователей (или даже разных БД). Однако я не уверен, насколько хорошо это масштабируется для большого количества пользователей. Кроме того, это не соответствует мягким требованиям.
• Найдите коммерческую, но разумную базу данных, которая действительно поддерживает это
• Используйте Veil, но, похоже, он не поддерживается, и у него есть большинство ограничений других решений.

Я много гуглил по этой теме, но мне еще предстоит увидеть посмертное объяснение того, как кто-то решил эту проблему в реальном сценарии. Существует некоторая документация по MS SQL, но в MySQL, похоже, не рекомендуется, и записи для postgres практически отсутствуют.

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

Answer 1

Тема безопасности на уровне строк довольно противоречива. Мое личное мнение заключается в том, что вы лаете не на то дерево, пытаясь реализовать это на уровне ACL базы данных. Я знаю, что Oracle поддерживает это, но с самого начала это была действительно плохая идея, которая вызвала гораздо больше разочарований, чем пользы. Я знаю, что вы испытываете искушение повторно использовать существующие функции контроля доступа, чтобы сэкономить на строках кода, но я сам не посмел бы пойти по этому пути только потому, что вы можете оказаться в тупике из-за ожиданий от реальности того, как ACL реализовано против того, как вы хотели бы, чтобы это работало.

Answer 2

Я сделал это в Oracle и SQL Server на уровне базы данных, а также через веб-сервер с предустановленными элементами управления авторизацией (запрос не в свободной форме), а также с помощью анализатора SQL, который позволяет выполнять запрос в свободной форме. Мой дубль:

1. Подход 1. Использование механизмов уровня базы данных, где пользователь А является пользователем базы данных.
   который создает / владеет / полностью контролирует все таблицы, представления и другие
   объекты, и пользователь B, C, D... являются учетными записями конечных пользователей, которые используют
   объекты, к которым A предоставляет доступ.
  а. Pros
    я. Может быть проще в обслуживании; вам может понадобиться меньше тестовых случаев, чтобы подтвердить, что это 
       работает правильно
    II. Позволяет распространять приложение, которое использует прямые соединения ODBC (например, файл Microsoft Access) для нескольких пользователей, каждый из которых может иметь
        безопасность на уровне строк
    III. Позволяет обновления в режиме реального времени для контроля доступа (либо для отдельных разрешений, 
         или ко всем наборам разрешений), через изменения внутренней базы данных
    внутривенно Вам не нужно беспокоиться о безопасности приложения, потому что вы полагаетесь на
        база данных для всей безопасности (включая безопасность вашей учетной записи администратора)
  б. Минусы:
    я. Требуется отдельная учетная запись пользователя базы данных для каждого конечного пользователя. Это вообще
       не желательно, например, для десятков тысяч пользователей
    II. Используя ODBC, пользователи напрямую подключаются к серверу базы данных, что может
        быть слабым в безопасности при некоторых обстоятельствах (что зависит от большего числа факторов, чем
        в поле для этого вопроса)
    III. Производительность имеет значительный успех. Еще один барьер для масштабируемости
    внутривенно По этим и другим причинам этот подход, как правило, не считается лучшим
        практика для производственного использования
  с. Реализация:
    я. Для Oracle, как вы заметили, есть встроенная поддержка
    II. Для SQL Server это может быть реализовано с использованием представлений и вместо триггеров,
        где представление или сохраненный процесс выполняет SELECT и запускает запись
        контролируемым образом. Это может сделать работу,
        но это громоздко, и требует значительного количества кода, большая часть которого должна
        изменяться всякий раз, когда меняется ваш подход к авторизации (например,
        поля в каких таблицах ACL будут разрешать какие действия на основе каких значений в
        таблицы, которые вы хотите обеспечить). Кроме того, каждый набор кода должен быть добавлен к каждому
        стол, который вы хотите обеспечить. Oracle, с другой стороны, делает что-то похожее на
        парсинг оператора SQL и вставка предложения where всякий раз, когда вы
        Обеспечение вовлечено. Это гораздо более гибкий подход, но будет очень
        трудно реализовать на сервере SQL, если вы не можете написать анализатор SQL на T-SQL
    III. Я полагаю, что для postgreql и mysql вы можете реализовать тот же подход, что и описанный
         выше для SQL Server, если вы хотите именно этого. Полагаю, в postgresql
         Вы можете написать синтаксический анализатор SQL в C, который выполняет преобразование, чтобы добавить
         необходимо, где пункты, сделать его доступным в качестве функции базы данных, передать ваш бесплатный
         сформировать SQL для этой функции в вашем триггере или хранимой процедуре, и использовать полученный результат
         модифицированный SQL как запрос, который запускается (или просто заставить функцию C выполнить запрос
         и передать это обратно в представление). Но это может быть много работы для некоторых добавленных
         гибкость для запросов, которые вы не могли ожидать.

2. Подход 2: Используйте приложение в середине. Так что либо ваше приложение использует пользователя A для входа
   и делать свои вещи (не рекомендуется, но технически, работает нормально), или вы можете настроить
   более ограниченный пользователь B только для вашего приложения, которое может делать все, что угодно конечному пользователю
   может сделать (например, просмотреть / изменить данные), но ничего более (например, удалить таблицу). Вы полагаетесь на
   приложение для контроля доступа.
  а. Плюсы: так работает большинство веб-приложений и подобных клиент-серверных приложений, и вы найдете
     много ресурсов, доступных для этого
  б. Минусы:
   я. Вы не можете использовать этот подход, если хотите предоставить конечным пользователям соединение ODBC
      (или приложение, которое использует ODBC)
   II. Как вы указываете, обычно это осуществляется таким образом, что не позволяет
       SQL в свободной форме. Есть два способа решить эту последнюю проблему:
    A. Создайте свой собственный парсер SQL (это ваше "прокси" решение), который ваше приложение
       будет использовать для разбора любого запроса SQL свободной формы (в конечном итоге это будет похоже на
       Реализация Oracle, за исключением того, что ваша SQL обезьяна происходит в вашем приложении,
       тогда как оракулы встречаются в базе данных). Для всех элементов запроса, что ваш
       анализатор идентифицируется как таблица, вы будете выполнять поиск в таблице ACL, чтобы определить
       что предикат "ГДЕ" (если таковой имеется) связан с этой таблицей, который будет добавлен к
       запрос SQL перед отправкой на сервер. Если вы знакомы с созданием
       ваши парсеры языка программирования, этот подход не должен быть слишком сложным, но если нет,
       вы можете не захотеть пытаться - вы можете обнаружить, что пытаетесь решить даже простые варианты использования
       в конечном итоге будет так же сложно, как решение любого варианта использования, так что вы либо создаете правильный
       Парсер, который является полностью гибким, или вы увязли в исправлении ошибок навсегда. В
       Кроме того, этот подход сильно ударит по вашей производительности, так же как и подход 1.
    Б. Создайте пользовательский интерфейс, предоставляющий желаемый тип функций запросов.
       действительно быть свободной формой. Вы должны убедиться, что интерфейс может поддерживать каждый
       мыслимый запрос, который вы хотите принять. Хотя это не идеально, исходя из того, что вы спросили,
       Вы можете найти это более экономически эффективным подходом, учитывая объем работы, чтобы получить
       ваш синтаксический анализатор SQL правильный, если вы не сделали этого раньше, 

В целом, я рекомендую придерживаться подхода 1, если у вас очень мелкомасштабный проект, и это сэкономит вам время на использование ODBC (например, я сделал это для пилотного / тестового проекта, где мы создавали приложение в Microsoft Access в 2 недели), и в противном случае, если гибкость не является приоритетом номер 1, а производительность не важна, использовать подход 2 с использованием структурированного интерфейса, который позволяет приложению контролировать доступ, а также предоставлять вам больший контроль над производительностью.

Answer 3

Я работаю над таким прокси здесь https://github.com/jbaliuka/sql-analytic Первоначально он был разработан для отчетности / аналитических целей, но я планирую реализовать приложение шлюза, чтобы я мог перемещаться по БД и выполнять SQL с DML через JavaScript из browser.It может быть полезным в качестве плагина Olingo для публикации базы данных как OData Service.