Безопасность на уровне строк

Угрозы для инфраструктуры

Рассмотрите следующие распространенные угрозы для инфраструктуры:

Атака методом подбора — злоумышленник пытается пройти проверку подлинности, используя несколько паролей для разных учетных записей, пока не будет подобран правильный пароль.
Взлом или распыление пароля — злоумышленники пробуют использовать один тщательно продуманный пароль в отношении всех известных учетных записей пользователей (один пароль ко многим учетным записям)

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

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

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

Риски для паролей

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

Создайте уникальную локальную учетную запись администратора с именем, отличным от Administrator.
Используйте сложные надежные пароли для всех учетных записей. Дополнительные сведения о том, как создать надежный пароль, см. в статье Создание надежного пароля.
По умолчанию во время настройки виртуальной машины SQL Server в Azure выбирается проверка подлинности Windows. Следовательно, имя для входа SA отключается, а пароль назначается в ходе настройки. Мы рекомендуем не использовать и не включать имя для входа SA. Если вам необходимо имя для входа SQL, используйте одну из следующих стратегий.

Создайте учетную запись SQL с уникальным именем, являющуюся участником роли sysadmin. Этого можно сделать на портале, включив аутентификацию SQL во время подготовки.

Совет

Если не включить аутентификацию SQL во время подготовки, необходимо будет вручную изменить режим аутентификации на Проверка подлинности SQL Server и Windows. Дополнительные сведения см. в статье Изменение режима проверки подлинности сервера.

Если необходимо использовать имя для входа SA, включите его после подготовки и задайте для него новый надежный пароль.

Риски, связанные с программой-шантажистом

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

Лучшая стратегия защиты от атаки программой-шантажистом — уделить особое внимание уязвимостям RDP и SSH. Кроме того, учтите следующее:используйте брандмауэры и блокируйте порты;
убедитесь, что к операционной системе и приложениям применяются последние обновления безопасности;
используйте групповые управляемые учетные записи служб (gMSA);
ограничьте доступ к виртуальным машинам;
Требовать JIT-доступ и Бастион Azure

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

Совместимость с разными компонентами

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

DBCC SHOW_STATISTICS предоставляет статистику по нефильтрованным данным и может вызвать утечку информации, которая должна быть защищена политикой безопасности. По этой причине доступ к просмотру объектов статистики для таблицы с политикой безопасности на уровне строк ограничен. Пользователь должен быть владельцем таблицы, членом предопределенной роли сервера sysadmin, предопределенной роли базы данных db_owner или предопределенной роли базы данных db_ddladmin.
Filestream. Безопасность на уровне строк не совместима с компонентом Filestream.
PolyBase: безопасность на уровне строк поддерживается для внешних таблиц в Azure Synapse и SQL Server 2019 CU7 или более поздней версии.
Таблицы, оптимизированные для памяти. Встроенная функция с табличным значением, которая используется в качестве предиката безопасности для таблицы, оптимизированной для памяти, должна быть определена с помощью параметра . Этот параметр позволяет блокировать функции языка, не поддерживаемые в оптимизированных для памяти таблицах, и выдавать соответствующую ошибку во время создания. Дополнительные сведения см. в разделе Безопасность на уровне строк в таблицах, оптимизированных для памяти статьи Вводные сведения о таблицах, оптимизированных для памяти.
Индексированные представления. Как правило, политики безопасности можно создавать на основе представлений, а представления — на основе таблиц, связанных политиками безопасности. Тем не менее индексированные представления нельзя создать на основе таблиц с политикой безопасности, так как операции поиска строк через индекс будут обходить политику.
Отслеживание измененных данных. Система отслеживания измененных данных может вызвать утечку целых строк, которые должны быть отфильтрованы для доступа членов db_owner или пользователей, являющихся членами «шлюзовой» роли, указанной при включении этой системы для таблицы. (Примечание. Для этой функции можно явно задать значение NULL, чтобы все пользователи имели доступ к измененным данным.) В результате параметр db_owner и члены такой шлюзовой роли могут просматривать все изменения данных в таблице даже при наличии политики безопасности для таблицы.
Отслеживание изменений. Отслеживание изменений может вызвать утечку первичного ключа строк, которые должны быть отфильтрованы для доступа пользователей с разрешениями SELECT и VIEW CHANGE TRACKING. Доступ к фактическим значениям данных не предоставляется, становится известно только то, что столбец A был обновлен (вставлен или удален) для строки с первичным ключом B. Это создает проблему, если первичный ключ содержит конфиденциальные элементы, например номер социального страхования. Тем не менее на практике для получения последних данных инструкция CHANGETABLE почти всегда объединена с исходной таблицей.
Полнотекстовый поиск. Запросы, использующие следующие функции полнотекстового и семантического поиска, будут выполняться со сниженной производительностью из-за введения дополнительного соединения для применения безопасности на уровне строк и блокирования утечки первичных ключей строк, которые должны быть отфильтрованы: CONTAINSTABLE, FREETEXTTABLE, semantickeyphrasetable, semanticsimilaritydetailstable, semanticsimilaritytable.
Индексы Columnstore. Безопасность на уровне строк совместима с кластеризованными и некластеризованными индексами columnstore. Тем не менее, поскольку безопасность на уровне строк применяет функцию, оптимизатор может изменить план запроса таким образом, чтобы пакетный режим не использовался.
Секционированные представления. Предикаты блокировки нельзя определить в секционированных представлениях, а секционированные представления нельзя создавать на основе таблиц, использующих предикаты блокировки. Предикаты фильтров совместимы с секционированными представлениями.
Темпоральные таблицы. Темпоральные таблицы совместимы с безопасностью на уровне строк. Тем не менее предикаты безопасности в текущей таблице не реплицируются автоматически в прежнюю таблицу. Чтобы применить политику безопасности для текущей и прежней таблиц, необходимо по отдельности добавить предикат безопасности в каждую таблицу.

Средства оценки безопасности и вычисление

Приведенные ниже инструменты настройки и оценки позволяют решать проблемы с безопасностью контактной зоны, определять возможности защиты данных и проводить оценку безопасности среды SQL Server на уровне экземпляра.

Настройка контактной зоны — рекомендуется включать только те возможности, которые необходимы в вашей среде. Это позволит минимизировать количество функций, которые могут быть атакованы злоумышленником.
Оценка уязвимости для SQL Server (SSMS) — оценка уязвимости SQL — это средство в SSMS v17.4+, помогающее находить, отслеживать и устранять потенциальные уязвимости базы данных. Оценка уязвимостей является ценным инструментом для повышения безопасности вашей базы данных и выполняется для каждой базы данных на уровне базы данных.
Обнаружение и классификация данных SQL (SSMS) — обычно DBA управляют серверами и базами данных, не осознавая конфиденциальность данных, содержащихся в базе данных. Классификация обнаружения & данных позволяет обнаруживать, классифицировать, присваивать метки и сообщать о уровне конфиденциальности данных. Классификация обнаружения & данных поддерживается начиная с SSMS 17.5.

Защита на уровне столбцов

Организациям часто необходимо защищать данные на уровне столбцов, поскольку в базах данных SQL Server часто хранятся данные о клиентах, сотрудниках, коммерческие тайны, данные о продуктах, медицинские, финансовые и другие конфиденциальные данные. К конфиденциальным столбцам часто относятся национальные идентификационные номера/номера социального страхования, номера мобильных телефонов, имя, фамилия, идентификация финансового счета и любые другие данные, которые могут быть расценены как персональные данные (PII).

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

Используйте Always encrypted для шифрования неактивных данных и сетевого трафика. Зашифрованные данные расшифровываются только клиентскими библиотеками на уровне клиента приложения. По возможности используйте . Always Encrypted (с анклавами) может повысить производительность операций сравнения, таких как для сценариев случайного шифрования.

Используйте для маскировки данных на уровне столбцов, если вариант Always Encrypted недоступен. Динамическое маскирование данных (DDM) . Используйте Always Encrypted, а не динамическое маскирование данных, когда это возможно.

Вы можете также предоставить разрешения на уровне столбцов для таблицы, представления или функции с табличным значением. Рассмотрим следующее: для столбца могут быть предоставлены только разрешения SELECT, REFERENCES и UPDATE.
— ПАРАМЕТР DENY на уровне таблицы не имеет приоритета над параметром GRANT на уровне столбца.

Сопоставление удостоверений

Управляющая программа Launchpadd (с двумя «D» — ) сопоставляет удостоверение вызывающего пользователя с отдельным процессом launchpad (с одной буквой «D») с помощью папки «launchpad GUID» и вспомогательного сертификата. Эти папки «launchpad GUID» создаются в . Процесс launchpad использует этот сертификат для обратной проверки подлинности в SQL, а затем создает временные папки для каждого идентификатора GUID сеанса в папке «launchpad GUID». Вспомогательный процесс (R, Python или ExtHost) может получить доступ к папке «launchpad GUID», сертификату в ней и папке «session GUID».

Следующий скрипт SQL выводит содержимое папок панели запуска.

Базовые учетные данные администратора

Кластер можно развернуть либо в режиме AD, либо с использованием только базовых учетных данных администратора. Режим безопасности с использованием только базовых учетных данных администратора не поддерживается в рабочей среде и предназначен для ознакомления с продуктом.

Даже если выбран режим Active Directory, для администратора кластера будут созданы базовые учетные данные. Эта функция обеспечивает альтернативный доступ при невозможности подключения к AD.

При развертывании этим базовым учетным данным будут предоставлены разрешения администратора в кластере. Вошедший пользователь будет системным администратором в главном экземпляре SQL Server и администратором в контроллере кластера.
Компоненты Hadoop не поддерживают смешанный режим проверки подлинности. Это означает, что базовые учетные данные администратора нельзя использовать для проверки подлинности в шлюзе (Knox).

Эти учетные данные для входа необходимо определить при развертывании.

Имя пользователя администратора кластера:

AZDATA_USERNAME=

Пароль администратора кластера:

AZDATA_PASSWORD=

Примечание

Обратите внимание, что в режиме, отличном от AD, для проверки подлинности в шлюзе для доступа к HDFS/Spark необходимо указывать имя пользователя в сочетании с приведенным выше паролем. До выпуска накопительного пакета обновления 5 для SQL Server 2019 имя пользователя имело значение

Начиная с SQL Server 2019 CU5, при развертывании нового кластера с обычной проверкой подлинности все конечные точки, включая шлюз, используют и . Конечные точки в кластерах, обновленных до CU5, продолжают использовать в качестве имени пользователя для подключения к конечной точке шлюза. Это изменение не применяется к развертываниям, в которых используется проверка подлинности с помощью Active Directory. Подробные сведения см. в заметках о выпуске в разделе .

Удостоверения и проверка подлинности

SQL Server поддерживает два режима проверки подлинности: проверка подлинности Windows и режим проверки подлинности SQL Server и Windows (смешанный режим).

Имена для входа отличаются от пользователей базы данных. Сначала сопоставьте имена для входа или группы Windows пользователям базы данных или ролям в отдельной операции. Затем предоставьте разрешения на доступ к объектам базы данных пользователям, ролям сервера, а также (или) ролям базы данных.

В SQL Server существуют следующие типы имен входа.

Локальная учетная запись пользователя Windows или учетная запись доменных служб Active Directory — SQL Server полагается на Windows для проверки подлинности учетных записей пользователей Windows.
Группа Windows — предоставление доступа группе Windows обеспечивает доступ ко всем именам для входа пользователей Windows, которые являются членами группы. При удалении пользователя из группы для него будут удалены права, которые он получил во время членства в группе. Членство в группе является предпочтительной стратегией.
Учетные данные SQL Server — SQL Server сохраняет имя пользователя и хэш пароля в базе данных master.
Пользователи автономной базы данных проверяют подлинность подключений SQL Server на уровне базы данных. Автономная база данных — это база данных, изолированная от других баз данных и от экземпляра SQL Server (а также базы данных master), на котором размещена эта база данных. SQL Server поддерживает использование пользователей автономной базы данных для проверки подлинности Windows и SQL Server.

Следующие рекомендации и лучшие методики помогут вам защитить удостоверения и способы проверки подлинности:

Используйте стратегии для улучшения управления безопасностью.

Обычно пользователей Active Directory помещают в группы AD, причем группы AD должны существовать в ролях SQL Server, а ролям SQL Server необходимо предоставлять минимальные разрешения, требуемые приложением.
Использование защиты по принципу предоставления минимальных прав в Azure с помощью элементов управления доступом на основе ролей (RBAC)
Выбирайте AD DS вместо проверки подлинности SQL Server, когда это возможно, и в особенности отдавайте предпочтение AD DS, а не хранению средств безопасности на уровне приложения или базы данных.
- Так вы сможете легко отключить учетную запись пользователя, который покидает организацию.
- Или легко удалить пользователей из групп при смене их роли или ухода из организации. Гарантирование безопасности групп является рекомендуемым поведением.
Используйте многофакторную проверку подлинности для учетных записей с доступом на уровне компьютера, а также учетных записей, использующих RDP для входа в систему компьютера. Это помогает защититься от кражи или утечки учетных данных, так как однофакторная проверка подлинности на основе пароля является более слабой формой проверки подлинности с учетными данными, подверженными риску компрометации или ошибочной отправки.
Требуйте ввода сильных и сложных паролей, которые нельзя угадать, и которые не используются для других учетных записей или целей. Регулярно обновляйте пароли и применяйте политики AD DS.
Групповые управляемые учетные записи служб (gMSA) обеспечивают автоматическое управление паролями, упрощенное управление именами субъектов-служб и возможность делегировать управление другим администраторам.
- Если использовать gMSA, паролем учетной записи управляет не администратор, а сама операционная система Windows.
- gMSA автоматически обновляет пароли учетных записей, не перезапуская службы.
- gMSA сокращает уровень административной плоскости и улучшает разделение обязанностей.
Минимизируйте объем прав, предоставляемых учетной записи AD для DBA; рассмотрите возможность разделения обязанностей, ограничивающего доступ к виртуальной машине, возможность входа в операционную систему, возможность изменения журналов ошибок и аудита, а также возможность установки приложений и/или возможностей.
Рассмотрите возможность удаления для учетных записей DBA прав роли sysadmin и предоставления прав , вместо того, чтобы делать эти учетные записи участниками роли sysadmin. Роль системного администратора не учитывает операцию DENY, в отличие от .

Аутентификация

Конечные точки внешнего кластера поддерживают проверку подлинности AD. Используйте удостоверение AD для проверки подлинности в кластере больших данных.

Конечные точки кластера

В кластере больших данных имеется пять точек входа.

Главный экземпляр — конечная точка TDS для доступа к главному экземпляру SQL Server в кластере, используемая приложениями и инструментами баз данных, такими как SSMS или Azure Data Studio. При использовании команд HDFS или SQL Server изAzure Data CLI () инструмент будет подключаться к другим конечным точкам в зависимости от типа операции.
Шлюз для доступа к файлам HDFS, Spark (Knox) — конечная точка HTTPS для доступа к таким службам, как webHDFS и Spark.
Конечная точка службы управления кластером (контроллера) — служба управления кластером больших данных, которая предоставляет REST API для управления кластером. Инструменту azdata требуется подключение к этой конечной точке.
Прокси-сервер управления — для доступа к панели мониторинга поиска по журналам и панели мониторинга метрик.
Прокси-сервер приложений — конечная точка для управления приложениями, развернутыми в кластере больших данных.

В настоящее время невозможно открыть дополнительные порты для доступа к кластеру извне.

Описание

Безопасность на уровне строк поддерживает два типа предикатов безопасности.

Предикаты фильтров автоматически фильтруют строки, доступные для операций чтения (SELECT, UPDATE и DELETE).
Предикаты BLOCK явно блокируют операции записи (AFTER INSERT, AFTER UPDATE, BEFORE UPDATE, BEFORE DELETE), которые нарушают предикат.

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

Предикаты фильтров применяются при считывании данных из базовой таблицы. Они влияют на все операции получения: SELECT, DELETE и UPDATE. Пользователи не могут выбирать, удалять и обновлять отфильтрованные строки. Но они могут обновлять строки так, чтобы они были отфильтрованы позже. Предикаты блокировки влияют на все операции записи.

Предикаты AFTER INSERT и AFTER UPDATE могут блокировать обновление строк значениями, нарушающими предикат.
Предикаты BEFORE UPDATE могут блокировать обновление строк, нарушающих предикат на данный момент.
Предикаты BEFORE DELETE могут блокировать операции удаления.

Предикаты фильтров и блокировки, а также политики безопасности имеют следующие особенности:

Вы можете определить функцию предиката, которая соединяется с другой таблицей или вызывает функцию. Если политика безопасности создана с использованием команды (по умолчанию), соединение или функция будут доступными из запроса и будут работать должным образом без каких-либо дополнительных проверок разрешений. Если политика безопасности создана с использованием , для отправки запросов в целевую таблицу вам потребуются разрешения SELECT в этих дополнительных таблицах и функциях. Если функция предиката вызывает скалярную функцию CLR, также потребуется разрешение EXECUTE.
Вы можете выполнить запрос к таблице, имеющей предикат безопасности, который определен, но отключен. Все отфильтрованные или заблокированные строки не затрагиваются.
Когда пользователь dbo, член роли db_owner или владелец таблицы выполняет запрос к таблице, для которой определена или включена политика безопасности, строки фильтруются или блокируются в соответствии с этой политикой.
Попытка изменить схему таблицы, связанной политикой безопасности привязки к схеме, приведет к ошибке. Тем не менее можно изменить столбцы, на которые не ссылается предикат.
Попытки добавить предикат в таблицу, в которой уже есть один определенный предикат для указанной операции, приведет к ошибке (независимо от того, включен ли предикат или отключен).
Попытка изменить функцию, которая используется в качестве предиката в таблице в рамках привязанной к схеме политики безопасности, приведет к ошибке.
Определение нескольких активных политик безопасности, содержащих неперекрывающиеся предикаты, завершается успешно.

Предикаты фильтров имеют следующие особенности.

Определение политики безопасности, которая фильтрует строки таблицы. Приложение не учитывает отфильтрованные строки в операциях SELECT, UPDATE и DELETE, включая ситуации, когда все строки исключены. Приложение может применить операцию INSERT к строкам, даже если они будут отфильтрованы во время любой другой операции.

Предикаты блокировки имеют следующие особенности.

Предикаты блокировки для операций UPDATE разбиваются на отдельные операции BEFORE и AFTER. Например, невозможно запретить пользователям обновлять строку, чтобы иметь значение выше текущего. Если требуется такая логика, необходимо использовать триггеры с промежуточными таблицами DELETED и INSERTED, чтобы создать ссылки на новые и старые значения.
Оптимизатор не будет проверять предикат блокировки AFTER UPDATE, если не изменяется ни один из столбцов, используемых функцией предиката. Пример: Алиса не должна иметь возможность изменить зарплату на значение, превышающее 100 000. Алиса может изменить адрес сотрудника, зарплата которого уже превышает 100 000, если столбцы, ссылки на которые указаны в предикате, не были изменены.
Изменения не вносились для пакетных API, в том числе BULK INSERT. Это означает, что предикаты блокировки AFTER INSERT будут применяться к операциям пакетной вставки так же, как к обычным операциям вставки.

Варианты использования

Ниже приведены примеры конструирования использования RLS.

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

Предикаты фильтров RLS функционально эквивалентны добавлению предложения WHERE . Предикат может по сложности сравниваться с определением деловой практики или предложение может быть простым как .

При использовании более формальных терминов можно сказать, что RLS представляет управление доступом на основе предиката. При этом поддерживаются гибкие централизованные вычисления на основе предиката. Предикат может учитывать метаданные или другие критерии, определяемые администратором по своему усмотрению. Предикат используется как критерий для определения, имеет ли пользователь необходимый доступ к данным, на основе пользовательских атрибутов. Управление доступом на основе метки можно реализовать с помощью управления доступом на основе предиката.

Примечание по безопасности. Атаки на стороне канала

Злонамеренный диспетчер политики безопасности

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

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

Тщательно созданные запросы

Утечку информации можно вызвать с помощью тщательно созданных запросов, использующих ошибки. Например, дает возможность злоумышленнику узнать, что заработная платы Джона До (John Doe) составляет 100 000 долларов. Даже при наличии предиката безопасности для предотвращения ситуаций, когда злонамеренный пользователь может напрямую выполнять запросы о заработной плате других людей, пользователь может определить, когда запрос возвращает исключение деления на ноль.