|
Реализация Row Level Security и Process Security в 1С для SQL |
|
||
Профессионалам в MS SQL посвящается Организация безопасности 1С для SQL Особенности реализации Process Security и Row Level Security в 1С Взлом и защита Row Level Security и Process Security Почему 1С с Row Level Security работает быстрее? Внимание! Данная статья не описывает рабочую спецификацию продукта "Защита 1С для SQL", а только общие принципы построения защит класса RLS и PS. Работа продукта "Защита 1С для SQL" может существенно отличаться от данного описания дающего только обзор технологии. Профессионалам в MS SQL посвящается Данная статья рассчитана на опытных специалистов в Microsoft SQL Server. В статье обсуждается реализация следующих видов секретности Row Level Security и Process Security для реальных БД в MS SQL. Будет рассмотрена пожалуй самая популярная система в России 1C: Предприятие (далее 1С). Организация безопасности 1С для SQL Поскольку не все знакомы с принципами организации безопасности 1С для SQL, сделаем краткий обзор. Авторизация в данной системе происходит следующим образом. 1) Пользователь запускает 1С. Выбирает пользователя и вводит пароль. 2) 1С через алгоритм MD5 получает HASH-код пароля и сравнивает его с эталоном в файле users.usr 3) Далее 1С расшифровывает из файла 1CV7.DBA через XOR-алгоритм пользователя SQL и его пароль. Отметим, пользователи не знают данной информации. 4) 1С устанавливает коннекцию с MS SQL через данного пользователя. 5) 1С начинает смотрит нет ли других процессов с 1С. Если есть, запускается краткая верификация БД, если нет - полная. Тонкий момент, 1С проверяет наличие процесса как по sysprocesses, так и через проверку файловой блокировки каталогов пользователя. Если есть приложение с именем "1СV7", но нет файловой блокировки, программа аварийно завершается. 6) Краткая верификация состоит только в проверке общих параметров БД. Для выполнения данной операции пользователь должен быть DBO. Если это не так, то программа аварийно завершается. 7) Полная верификация состоит в сравнении структур таблиц (включая все поля и индексы) и хранимых процедур с их описанием в файле 1CV7.DDS. Если есть отличие, 1С аварийно завершается. Отметим, для указанных проверок также требуется иметь права DBO. 8) После успешного прохождения верификации 1С начинает работать с базой MS SQL. При этом работа идет от лица DBO и секретность контролируется на клиенте самой 1С. Смысл данного подхода состоит в том, что пользователь видит не всю таблицу, а только часть строк таблицы. Такая задача разграничения доступа возникает очень часто. Пример типичных задач: 1) Пользователи должны видеть только часть "Товаров". Обычно это только своя линейка для сейл-менеджеров. 2) Пользователи должны видеть только часть "Контрагентов". Разделение базы клиентов и поставщиков между разными менеджерами типично. 3) Пользователи должны видеть в журналах только документы своего подразделения. Реализация Row Level Security (RLS) обычно строится на базе использования представлений. Вот оригинал очень известной статьи по данной проблематике. http://vyaskn.tripod.com/row_level_security_in_sql_server_databases.htm В принципе существует 2 подхода реализации RLS. Первый это создание нескольких view для разных групп пользователей. Второй это создание единой view, в которой пользователь контролируется либо через SUSER или @@spid. Первый метод удобен при небольшом числе пользователей и в том случае, если он применяется изначально при разработке программы. Второй метод хорошо работает при большом числе пользователей и может быть реализован для уже рабочей системы путем подмены таблиц на view. Приложение во втором случае может даже не заметить, что RLS включен. Просто теперь клиент видит только часть строк таблицы. RLS очень безопасен, т.к. контроль доступа делается на сервере, а не на клиенте. Естественно, view должны отвечать условиям updateable view. Их довольного много, в частности отметим, что нельзя использовать связанные таблицы во view любым образом для таблиц с identity. В противном случае view будет казаться, что нужно обязательно при insert подавать значение в колонку indentity. Process Security (PS) позволяет сделать авторизацию коннекций не только на базе логина и пароля, а также на основании прочей информации о конекции из sysprocesses. Обычно Process Security применяют для запрещения работы со стандартными средствами анализа БД такими как MS Query, SQL Analyzer и др. Кроме того, Process Security обычно проверяет клиентскую машину по хосту и коду сетевой карты. Таким образом, можно привязать вход определенного пользователя к определенной машине. Process Security может быть объединен с Row Level Security путем использования проверок @@spid. Она может делаться одновременно с проверкой SUSER или без этого. Особенности реализации Process Security и Row Level Security в 1С Поскольку мы говорим о реализации RLS и PS не в абстрактном случае, а для конкретной системы в лице 1С, мы сталкиваемся с целым рядом особенностей и ограничений. 1) Мы не можем ни каким образом модифицировать 1cv7s.exe. Все его поведение это данность, мы должны использовать только совместимые методы. 2) Для реализации RLS и PS нам потребуется сконструировать некого магического пользователя (назовем его s2), который умеет читать статистику БД как DBO, но не имеет доступа к таблицам БД. Методика создания такого пользователя лежит за рамками данной статьи, примем как данность, что он существует. 3) Нам не обойти тот факт, что все пользователи 1С будут входить в MS SQL под одним логином. Нам придется разделять их права на уровне процессов. Реализация Row Level Security и Process Security в 1С Опишем по шагам работу автоматической инсталляции RLS и PS на 1С. 1) Программа создает магического пользователя s2 и указывает его в 1CV7.DBA 2) Система переименовывает все таблицы в ..._HIDE. Например, SC33 в SC33_HIDE. 3) Создаем view для всех таблиц, через специальное автоматическое средство. Этот процесс не прост, т.к. в зависимости от административных настроек создаются различные варианты view. 4) Если
на таблицу наложен только PS, то
view будет выглядеть примерно так: create view DH410 as select * from DH410_HIDE where
dbo.ivn_CheckSec() 5) Если на таблицу наложен RLS, то view будет примерно следующего вида. create view _1SJOURN as select * from _1SJOURN_HIDE where SP1005 in dbo.ivn_CheckSC1('SC13') Внутри функции ivn_CheckSC1 проверяется какие значения справочника SC13 могут быть в поле SP1005. Отметим, если на SC13 наложен RLS, то он автоматически распространяется на подчиненные документы. 6) Настройка полномочий. s2 запрещается (deny) доступ ко всем HIDE-таблицам и ненужным ему хранимым процедурам. 7) Добавление пользователей 1С через NT-логины. Это неавтоматическое действие. Администратор добавляет NT-логины соответствующие пользователям 1С в БД и включает их только в группу public. Данная группа вообще не имеет прав ни на один объект базы, а только на вызов хранимой процедуры менеджера процессов ProcessManager. 8) Для пользователей с серьезными правами, администратор может назначить привязку их к определенным машинам через имя хоста и/или код сетевой карты. Описание процесса авторизации при использовании RLS и PS Опишем как происходит авторизация. 1) Штатная авторизация 1С. 2) Вход в БД под магическим пользователем s2. Прав у него на видимость строк в таблицах пока еще нет. Заметим, пароль s2 пользователи незнают, хотя могут его получить дешифрацией 1CV7.DBA. 3) Вызов в глобальном модуле конфигурации 1С через ADO в новой коннекции по Trusted Security некой хранимой процедуры ProcessManager следующим образом: exec ProcessManager 'Пользователь1С', 'AppPassword' Разберемся, что подается на вход. Первый параметр это пользователь 1С, который вошел в систему, второй параметр это пароль приложения. Пароль приложения это еще одна степень защиты, которая не носит обязательный характер. 4) ProcessManager вызывает менеджера процессов. Менеджер анализирует sysprocess и проверяет, что верно следующее: - Пользователь 1С соответствует пользователю NT - AppPassword верный, возможна проверка, что он верный для данного пользователя 1С. - Если наложено ограничение на хост, оно проверяется - Если наложено ограничение на сетевую карту, оно проверяется Если все верно, менеджер процессов запоминает код процесса и его login_time как разрешенные и функции Check уже смогут показывать данные во view с RLS. Замечания по аудиту. Если менеджер процессов вдруг видит, что есть два одинаковых пользователя 1С в разных процессах, тогда генерируется событие аудита DetectHacker с фиксацией пользователя/машины с отсылкой сообщения администратору, затем менеджер убивает все процессы неизвестного происхождения. Данная функция активного аудита процессов выполняется при входе/выходе пользователей и раз в несколько секунд. О выявлении хакерских атак написано ниже. 5) Приложение может использовать select, update, delete, insert и другие функции для работы с view, как с таблицей. Примечательно, что пользователь не только не видит записи вне разрешенного диапазона, но и не может их удалить/обновить. Например, если пользователь не видит объект с кодом 5, то следующее выражение не приведет к модификации таблицы: delete SCXX where ID=5. В тоже время, для своих записей пользователь может делать delete как обычно. Отметим, Check-функции во view проверяют не только код процесса по @@spid, но и проверяют login_time для контроля возможной хакерской атаки с подменой процесса (см. ниже). 6) Пользователь закрывает 1С. При выходе из глобального модуля 1С вызывается процедура LogOff. Данная процедура снимает код процесса с учета и view перестает показывать данные. Взлом и защита Row Level Security и Process Security Проанализируем возможные методы взлома и противодействие им. Взлом 1. Захват процесса 1С на клиенте. а) Взломщику удалось внести специальный код в конфигурацию 1С или во внешний отчет 1С. Данный код средствами макроязыка пытается украсть например базу клиентов. б) Взломщик захватил хенд ODBC-коннекции 1C на клиенте и пытается SQL-запросами вытащить туже базу клиентов. Защита 1. Row Level Security безразлична к взлому клиента Небольшое замечание, от разновидности взлома (а) можно защитится настройкой конфигурации и прав NTFS. От (б) во многом можно защитится также, т.к. наиболее простой путь для (б) это загрузка внешних компонент в 1С типа rainbow. Однако надо отметить, что данный метод взлома очень часто проходит в 1С успешно, т.к. очень часто пользователи используют целую массу различных конфигураций и внешних отчетов, которые постоянно модифицируются. В результате администратор часто вынужден пойти на ослабление защиты. Увы, троянские конфигурации типичный метод взлома, особенно для баз 1С под Microsoft Terminal Server. Однако даже если NTFS-защиты нет, взлом будет неудачен, Row Level Security работает на сервере, любое клиентское приложение от 1С до MS Query не видит БД в правах пользователя, т.е. не всю, а только разрешенную часть. Взлом 2. Захват чужого процесса Высококвалифицированный хакер может сделать атаку следующего вида. Сначала проводится атака DoS по рабочей станции пользователя с серьезными правами, например директора. Затем сразу выполняется соединение с БД, если повезло, то хакер попадает в тот-же код коннекции. Затем запускается очень компактный код по краже данных. Всю базу не украсть, периодический аудит застукает, в вот часть можно попробовать. Вот еще цитата по анализу такого взлома от Sergey Vasiltsoff: "Я даю направление - интенсивное переоткрытие хенлов (совершенно законное, под гестом), с одновременным входом легальным способом с соседнего компьютера. После входа и разрешения его процесса выдергиваем из него пачкорд и открываем соединения до получения его @@spid. Это решаемо, если хаб - рядом." Защита 2. login_time - уникальная характеристика процесса Отметим для начала, что для атак такого класса требуется очень высокая квалификация и изрядное везение, т.к. если периодический аудит обнаружит проникновение, взломщик будет пойман на месте с поличным. Однако атака будет неудачна. Тонкость в том, что менеджер процессов и Check-функции во view проверяют не только @@spid, а еще login_time из sysprocesses. Повторная коннекция будет иметь другой login_time, поэтому Check-функция откажется показывать данные во view. Интересно, эксперимент
показывает, что login_time - абсолютно
уникальная характеристика
процесса. Дело в том, что MS SQL не
регистрирует процессы
одновременно, а ставит их в
очередь, затем они быстро
регистрируются друг за другом. В
результате время коннекций
будет отличаться хоть вот так: Взлом 3. Взлом Application Password Взломщик дешифрует конфигурацию 1С и получает Application Password. Сможет ли он проникнуть в БД? Другой вариант. Взломщик прослушал сеть и вычислил Application Password. Защита 3. Сертификационная защита Для начала отметим следующие моменты. Незнание Application Password не позволяет взломщику использовать любые программы для анализа с БД с клиента. Будем откровенны, любая клиентская защита обречена. Поэтому защиты класса Application Role с любым уровнем криптования легко вскрываются методом трассировки. Для этого надо знать пароль хоть одного пользователя, а во многих случаях и этого не нужно. Таким образом, делать ставку на надежность Application Password и его аналогов, типа пароля в 1CV7.DBA или Application Role, не стоит, надежность от взлома гарантируется только Row Level Security, который работает на сервере. Однако Application Password серьезное препятствие и можно усложнить работу хакеру используя сертификационный метод. Если администратор хочет спрятать AppPassword от глаз хакера, который может декомпилировать/трассировать MDB-файл, можно применить систему файлов-сертификатов по аналогии с защитой на ID-файлах Lotus Domino. Если упрощенно, сертификаты - это файлы содержащие бинарную информацию аналогичную AppPassword. Смысл в том, что можно хранить разные AppPassword для разных пользователей, а на сами сертификаты наложить права NTFS. Другой аспект сертификата, это то что его не запишешь на бумажке как пароль. . Отметим, хакер может получить Application Password только для пользователя с NT-правами, которого работает. Причем если задуматься, потребуется для такого взлома потребуется изрядное время, т.е. у нас есть возможность его застукать аудитом. Несколько слов о прослушивании Application Password. От этого можно надежно защитится использую средства криптования трафика, такие как SSL. Напомним, что такое решение потребует лицензирования ФАПСИ. Однако можно ограничится и трюком, который используется в "Защите 1С для SQL". Если используются средства трассировки типа SQL Profiler, то можно исключить прослушку просто вставив в любую часть кода вызова (хоть в комментарий) строку "sp_setapprole". MS SQL думает, что идет активизация Application Role, поэтому запрещает SQL Profiler показывать, что было внутри команды. Конечно, такой метод не подразумевает истинное шифрование трафика. Почему 1С с Row Level Security работает быстрее? Любая защита обычно понижает быстродействие системы, однако RLS-защита приводит к ускорению 1С на целом ряде операций на 30-40%. Почему это происходит? Дело в том, что 1С оптимизирована для DBF-баз. Поэтому операции поиска и многие операции формирования отчетов представляют собой не запрос к серверу в формате "select ... from ... where условие выборки", а просто выборку всех элементов справочника или журнала. Далее идет перебор элементов на клиенте. Надо ли говорить, что это приводит к неоправданному трафику и снижению быстродействия? Если на 1С установлена защита RLS, то на клиент будет доставлен не весь справочник/журнал, а только его часть, которую может видеть пользователь. Обычно пользователь может видеть 25-30% от всех элементов. Таким образом, c RLS на клиент доставляется существенно меньше записей и перебор их происходит быстрее. Однако, сколько же времени тратится на сами RLS-проверки? Анализ через SQL Analyzer показывает, что около 1-2% времени запроса. Сравните примерно с 2х кратным понижением производительности при реализации аналога RLS на клиенте средствами 1С-программирования. Я уже не говорю об трудоемкости реализации на 1С схем разделения доступа аналогичных RLS. см. также описание продукта "Защита 1С для SQL"
|
Row Level Security - защита таблиц на уровне записей Process Security - защита на уровне процессов сервера Почему 1С с RLS-защитой работает быстрее? Захват
хендела соединения 1С. Взлом
Process Security - захват чужого процесса. Прослушивание
App Password |
||
Рейтинги сайта:
