T-SQL
Помимо симметричного шифрования, когда упаковка и распаковка текста
производятся одним и тем же ключом (общим для двух участников обмена
сообщениями), поддерживается и ассиметричное криптование. Идея ассиметричных
алгоритмов подразумевает наличие двух ключей – открытого и закрытого
(секретного). Один из них используется для шифрования информации, а другой — для
дешифрования. Если кодирование осуществляется с помощью открытого ключа, то
расшифровать такие данные можно только с помощью парного ему закрытого.
Предлагаю разобраться с этим на примере Microsoft SQL Server, который часто
используется в корпоративных порталах и сложных приложениях.
Для шифрования применяются функции T-SQL, представляющие собой специальное
дополнение языка SQL. Оно поддерживает управляющие операторы, локальные
переменные и различные дополнительные функции.
Одна из таких функций – EncryptByCert(), используемая для ассиметричного
шифрования данных с помощью сертификатов. Открытым ключом тут выступает
сертификат. Только откуда этот сертификат взять? Ответ прост – сгенерировать с
помощью другой специальной функции. Покажу на примере, как можно сгенерировать
сертификат с именем для andrej базы “Bank” с помощью хранимой процедуры:
У нас создался сертификат! Теперь его можно без проблем использовать для
размещения в таблице зашифрованных записей, выполняя привычные SQL-запросы:
В этом примере неформатированный текст из переменной @cleartext шифруется
сертификатом с именем “andrej”. Зашифрованные данные помещаются в таблицу
“ТАБЛИЦА”. Уточню, что данные могут быть расшифрованы только с помощью
соответствующего закрытого ключа (как уже было сказано, “приватного”).
Имя функции для обратного преобразования угадать несложно: DecryptByCert(). А
вот синтаксис более хитер, и с ним все чуть сложнее. Дело в том, что на
приватный ключ, как правило, закладывается дополнительный пароль (passphrase).
Его необходимо ввести, и по этой причине он обязательно будет присутствовать в
коде запроса или процедуры. Это не очень хорошо, потому что в этом случае его
можно быстро увести. Но с этим мы разберемся позже, когда поговорим о
безопасности хранимых процедур. А пока – код для извлечения данных из
шифрованной базы данных:
В этом примере производится выборка строк из таблицы .,
помеченных как “Employers Access”. Пример дешифрует зашифрованный текст с
помощью закрытого ключа сертификата “Andrej” и дополнительного пароля
pGFD4bb925DGvbd2439587y. Расшифрованные данные преобразуются из типа varbinary в
тип nvarchar.
Надо сказать, что ассиметричные преобразования гораздо более накладны, чем
шифрование и дешифрование с использованием симметричного ключа. Поэтому
использование ассиметричного шифрования не рекомендуется при работе с большими
объемами данных, например, таблицами пользовательских данных
Это важно
учитывать при особо больших базах, а также базах, структура которых не приведена
к одной из нормальных форм
С чего начать?
Стоит отметить, что ни в коем случае нельзя пытаться сразу улучшить качество всех данных в организации или описать в бизнес-глоссарии все термины, используемые в компании. Относительно управления данными, можно сформулировать принцип Парето следующим образом: «20% всех данных критически влияют на 80% бизнес-процессов компании».
Правильным подходом в данном случае будет следующая последовательность шагов:
Необходимо выявить самые критичные с точки зрения бизнеса процессы, определить данные, существенно влияющие на эффективность этих процессов, зафиксировать начальную оценку эффективности процессов. Далее последовательно шаг за шагом повышать уровень качества, доступности данных и описания их метаданных. По завершении работ оценить, насколько удалось достичь заявленных бизнес–целей и переходить на активности по следующему бизнес-процессу, масштабируя таким образом деятельность по системной работе с данными.
Так делать не стоит
В SQL Server можно создавать четыре типа объектов (хранимые процедуры,
представления, пользовательские функции и триггеры) с параметром WITH
ENCRYPTION. Этот параметр позволяет зашифровать определение объекта таким
образом, что тот можно будет использовать, но получить его определение
стандартными способами станет невозможно. Это средство рекомендуется и
Microsoft. К сожалению, на практике никакой защиты применение стандартных
средств шифрования не обеспечивает! Алгоритм, используемый при шифровании
определений объектов, выглядит так:
- SQL Server берет GUID той базы данных, в которой создается объект, и
значение столбца colid таблицы syscomments для создаваемого объекта (чаще
всего, его значение – 1 или 2) и производит их конкатенацию; - Из полученного значения генерируется ключ при помощи алгоритма SHA;
- Этот хеш используется в качестве входящего значения при применении еще
одного алгоритма хеширования – RSA. С его помощью генерируется набор символов,
равный по длине шифруемому определению объекта; - С этим набором символов и с реальным определением объекта производится
операция XOR. В результате получаются данные, которые помещаются в столбец
ctext таблицы syscomments.
У этой схемы есть два слабых места:
- Нам ничего не мешает заиметь исходные значения (GUID и colid) для
выполнения тех же самых операций и получить ключ на расшифровку. Это можно
сделать, например, использовав утилиту dSQLSRVD. Правда, для получения GUID
базы данных (и для запуска этой утилиты) нам нужны права системного
администратора; - Если у нас есть права на создание объектов в базе данных, можно
сгенерировать точно такой же ключ для объекта, определение которого нам уже
известно (путем сравнения шифрованного определения с незашифрованным). Ну и –
использовать его для расшифровки значения другого объекта.
Как можно расшифровать зашифрованные объекты на SQL Server? Есть два
варианта:
Продолжение работы над проектом
Для того чтобы продолжить работу, необходимо придумать основную информацию, которую будет содержать в себе база данных в Excel. Пример ее приведен ниже.
Допустим, мы хотим создать базу данных собранных средств с родителей в фонд школы. Размер суммы не ограничен и индивидуален для каждого человека. Пусть в классе учится 25 детей, значит, и родителей будет соответствующее количество. Чтобы не нагромождать базу данных большим числом записей, стоит сделать раскрывающиеся списки, которые спрячут лишнюю информацию, а когда она снова потребуется, они услужливо предоставят ее опять.
3.5.Шифрование
Шифрование – кодирование данных с использованием специального алгоритма, в результате чего данные становятся недоступными для чтения любой программой, не имеющей ключа дешифрования.
Для организации защищённой передачи данных по незащищённым сетям должны использоваться схемы шифрования, включающие следующие компоненты:
1. ключ шифрования, предназначенный для шифрования исходных данных (обычного текста);
2. алгоритм шифрования, который описывает, как с помощью ключа шифрования преобразовать обычный текст в шифротекст;
3. ключ дешифрования, предназначенный для дешифрования шифротекста;
4. алгоритм дешифрования, который описывает, как с помощью ключа шифрования преобразовать шифротескт в исходный обычный текст.
Существуют симметричные и несимметричные системы шифрования. Симметричными называются системы, использующие один и тот же ключ, как для шифрования, так и для дешифрования, при этом предполагается наличие защищённых линий связи, предназначенных для обмена ключами. Несимметричные тип систем предусматривает использование для шифровки и дешифровки сообщений различных ключей.
С помощью параметра SET SECURITY TO могут быть установлены четыре режима шифрования данных в БД, которые определяют степень защиты информации. Это следующие режимы:
• NONE – нет шифрования в БД, режим шифрования отключён.
• LOW – низкий уровень защиты (каждый символ по сложному алгоритму заменяется другим). В этом режиме обеспечивается самая высокая производительность, но уровень защиты данных самый низкий.
• MEDIUM – обеспечивается более высокая защита (64 битный ключ) и наблюдается незначительное влияние на производительность СУБД.
• HIGH – самый высокий уровень защиты и обеспечивается не очень сильное влияние на производительность СУБД (128 битный ключ.)
В процессе эксплуатации БД предусмотрена возможность миграции от одного уровня шифрования к другому, вплоть до полного отключения этого режима (NONE). Эти операции выполняются в административном режиме. Если включена защита, то выполняется шифрование журналов и транзакций по методу MEDIUM.
Удостоверения и проверка подлинности
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, в отличие от .
3.7 Метки безопасности и принудительный контроль доступа
Средства произвольного управления доступом не решают одной важной задачи – задачи слежения за передачей информации. Они не могут помешать авторизированному пользователю законным образом получить секретную информацию и затем сделать её доступной для других, неавторизированных пользователей
При произвольном управлении доступом, привилегии существуют отдельно от данных (в случае реляционных СУБД – отдельно от таблиц). В результате данные оказываются ”обезличенными”, и ничто не мешает передать их кому угодно даже средствами самой СУБД.
Рассмотрение реализации меточной безопасности в СУБД INGRES интересно с познавательной точки зрения, а сам подход, основанный на разделении данных по уровням секретности и категориям доступа, может оказаться полезным при проектировании системы привилегий многочисленных пользователей по отношению к большим массивам данных.
В СУБД INGRES/Enhanced Security к каждой реляционной таблице неявно добавляется столбец, содержащий метки безопасности строк таблицы. Метка безопасности состоит из трёх компонентов:
1. Уровень секретности. Смысл этого компонента зависит от приложения. В частности, возможен традиционный спектр уровней от ”совершенно секретного” до ”несекретного”.
2. Категории. Понятие категории позволяет разделить данные на ”отсеки” и тем самым повысить надёжность системы безопасности. В коммерческих приложениях категориями могут служить ”финансы”, ”кадры”, ”материальные ценности”.
3. Области. Является дополнительным средством деления информации на отсеки. На практике компонент ”область” может действительно иметь географический смысл, обозначая, например, страну, к которой относятся данные.
Каждый пользователь СУБД INGRES/Enhanced Security характеризуется степенью благонадёжности, которая также определяется меткой безопасности, присвоенной данному пользователю. Пользователь может получить доступ к данным, если степень его благонадёжности удовлетворяет требованиям соответствующей метки безопасности. Более точно:
• Уровень секретности пользователя должен быть не ниже уровня секретности данных;
• Набор категорий, заданных в метке безопасности данных, должен целиком содержаться в метке безопасности пользователя;
• Набор областей, заданных в метке безопасности пользователя, должен целиком содержаться в метке безопасности данных.
Когда пользователь производит выборку данных из таблицы, он получает только те строки, метками безопасности которых удовлетворяет степень его благонадёжности. Для совместимости с обычными версиями СУБД, столбец с метками безопасности не включается в результирующую информацию.
Следует отметить, что механизм меток безопасности не отменяет, а дополняет произвольное управление доступом. Пользователи по прежнему могут оперировать с таблицами только в рамках своих привилегий, но даже при наличии привилегии SELECT им доступна, вообще говоря, только часть данных.
При добавлении или изменении строк они, как правило, наследуют метки безопасности пользователя, инициировавшего операцию. Таким образом, даже если авторизованный пользователь перепишет секретную информацию в общедоступную таблицу, менее благонадёжные пользователи не смогут её прочитать.
Специальная привилегия, DOWNGRADE, позволяет изменять метки безопасности, ассоциированные с данными. Подобная возможность необходима, например, для коррекции меток, по тем или иным причинам оказавшихся неправильными.
Как компании защитить базы данных от злоумышленников
Вот набор простых правил, которые позволят сохранить уязвимую информацию.
Ограничиваем доступ в систему
Важно ужесточить доступ сотрудников к базе данных. Они должны подключаться к ней только по «пригласительным» — вейтлистам (их IP-адрес должен быть в списке адресов, которым доступ разрешен)
Для всех остальных соединение должно прерываться моментально при попытке подключения.
Ведем строгую парольную политику
Доступ должен предоставляться только по паролю, при этом обязательно изменять стандартные пароли, которые автоматически ставят после установки базы (root, toor, и т. д.).
Руководителям стоит внедрить «парольные политики» — требовать от всех сотрудников, которые имеют доступ к базе данных, устанавливать надежные пароли, причем менять их время от времени.
В это сложно поверить, но в условиях роста опасности утечек в мире существует огромное количество баз данных, вообще не защищенных паролем.
Ограничиваем возможности доступа
Все пользователи внутри базы данных должны иметь ограниченные возможности, касающиеся только их должностных задач — если сотруднику необходимо получить только информацию о совершенных покупках клиента, он не должен видеть остальные данные, например, его имя и фамилию.
Проблема нередко кроется в том, что в ИТ-сфере очень часто можно встретить переработки и задачи с максимально сжатыми сроками, что оборачивается разными проблемами.
Допустим, в компании появился новый проект, в котором необходимо получать данные о времени совершенной продажи для будущего анализа. Администратор базы данных вместо грамотной настройки ролей попросту создает нового пользователя и выдает ему права и на чтение, и на запись, причем не только для нужного параметра, а вообще для всех данных.
Если произойдет атака на компанию, и она придется именно на этот проект, злоумышленники сразу же смогут получить полную копию всей базы, перезаписать все данные в ней и остановить процесс работы компании.
В таких случаях злоумышленники вымогают деньги у компании за полученную информацию.
Резервные копии храним на отдельных серверах
Нельзя хранить бэкапы базы данных и конфигурационные файлы в корневой папке. Их необходимо держать на отдельных серверах с ограниченным доступом.
В противном случае злоумышленники могут завладеть логином и паролем от аккаунта администратора. Получив права администратора, они способны причинить компании любой вред.
Отслеживаем действия участников системы
Важно сохранять информацию о любых действиях пользователя в системе: кто, что и когда сделал тот или иной сотрудник. Так можно заметить, что пользователь начал среди ночи или в выходной читать базу — что может быть признаком, что аккаунт взломан и по ночам хакеры копируют данные.
Так можно заметить, что пользователь начал среди ночи или в выходной читать базу — что может быть признаком, что аккаунт взломан и по ночам хакеры копируют данные.
Проверяем все, что устанавливаем
Стоит тщательно проверять, какие плагины устанавливаются на сайт: они могут быть инфицированы.
Существует отдельный вектор атак, когда злоумышленники пытаются перехватить управление над популярными плагинами. Они изменяют исходный код и выпускают плагин под видом новой версии. После ее установки вредоносный код встраивается в сайт.
Далее внутрь сайта может быть встроен майнер или установлен вебшелл.
Такие «инородные» программы позволят злоумышленникам в будущем полностью перехватить контроль над всем сервером, а не только над сайтом.
Вовремя обновляем ПО
Не менее важно своевременно обновлять программное обеспечение. Своевременное обновление ПО гарантирует, что компания использует наиболее актуальную версию без багов и уязвимостей
Своевременное обновление ПО гарантирует, что компания использует наиболее актуальную версию без багов и уязвимостей.
Регулярно проверяем системы
Время от времени стоит проводить аудит безопасности всего сайта. Методы и техники атакующих постоянно совершенствуются, злоумышленники используют новые инструменты и векторы атак, которые не детектируются стандартными средствами защиты.
Обращаемся к современным решениям
Для более качественного аудита необходимо обращаться к профессиональным компаниям, которые досконально исследуют сеть и оценивают степень ее защиты.
Сегодня на рынке существует ряд решений, с которыми можно вовремя выявить угрозу и минимизировать риски.
Есть продукты, которые обеспечивают полный мониторинг всех доступных извне цифровых активов организации, выявляют риски, ранжируют их, что экономит рабочие силы компании.
3.8 Копирование и восстановление
Процедуры копирования и восстановления должны быть тщательно продуманы и проработаны. Процедуры, регламентирующие процессы создания резервных копий, определяются типом и размерами эксплуатируемой базы данных, а также тем набором соответствующих инструментов, который предоставляется используемой СУБД. В зависимости от частоты внесения в систему изменений, в течение одних суток может выполняться несколько копирований. В процедурах копирования также может указываться, какие ещё части системы, помимо самих данных, должны подлежать копированию. Место хранения последних копий должно быть хорошо защищено.
Что касается процедур восстановления, то какие именно процедуры восстановления будут выполняться, должно определяться типом отказа
Не мало важно и то, что процедурами восстановления должны учитываться особенности методов восстановления, принятых в используемой СУБД. Следует регулярно тестировать процессы восстановления, чтобы иметь полную гарантию, что они работают правильно
Моделирование бизнес-процессов
Моделирование необходимо, чтобы представить бизнес-процесс в таком виде, который максимально точно и полно опишет его с учетом поставленной задачи.
На практике применяют различные подходы к моделированию, что позволяет выделить три основных вида:
- Структурное моделирование – применяется для исследования текущих и разработки новых систем. Здесь есть три подвида:
- функциональное – бизнес-процесс показан как последовательность действий, использующих конкретные ресурсы, от входа к выходу;
- имитационное (второе название – моделирование поведения) – схема строится с учетом временных интервалов, показывает, что происходит под воздействием внутренних и внешних условий;
- информационное – демонстрирует связи между объектами и их свойства.
- Объектно-ориентированное моделирование – процессы представлены в виде набора объектов с событиями и условиями, детализация отсутствует. Говоря об объекте, подразумевают любой предмет, преобразуемый по ходу выполнения процесса.
- Интегрированное моделирование – включает модели разных видов и позволяет создать схему, которая представит комплексно объект моделирования.
Нотации моделирования бизнес-процессов
Существуют стандартизированные условные обозначения или нотации бизнес-процессов, которые используются во всем мире.
BPMN – помогает демонстрировать бизнес-процесс представителям разных аудиторий.
BPMN
- SADT – используется для создания функциональной модели.
- DFD – стандарт для макропроцессов в бизнесе.
- WFD – стандарт для бизнес-процессов нижнего уровня с возможностью демонстрации последовательности работ с учетом времени.
- ARIS – применяется для создания, анализа, внедрения и улучшения бизнес-процессов.
- EPC – показывает вход и выход процесса в ходе моделирования сложных комплексов.
- STD – показывает, как ведет себя система при внешнем управляющем воздействии.
- UML – описывает требования к ИС.
- ERM – описывает концепцию бизнес-процесса.
- FCD – описывает действия, исполнителей, оборудование и данные с помощью символов.
- RAD – описывает и анализирует функциональные элементы, наглядно демонстрирует их взаимодействие.
- ANSI – набор блок-схем для демонстрации хода процесса.
- IDEF – набор инструментов для разделения и объединения блоков (IDEF0), изображения процесса (IDEF3) и др.
- Unified Modeling Language – средства визуализации, конструирования, документирования систем и процессов.
- Цветные сети Петри – демонстрируют переходы, изображают события и действия.
- Дорожки Брюса Силвера – дополнение к другим нотациям, применяется, чтобы показать, как переходит ответственность от одного участника к другому.
ДорожкиКарты потоков создания ценности – набор условных обозначений, которые показывают затраты времени и ресурсов.
Сравнение нотаций
Выше перечислено много различных нотаций, но на практике чаще всего применяется две наиболее популярные – BPMN и ARIS eEPS. Сравним их.
BPMN | ARIS eEPS |
|
|
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
1. Толковый словарь по вычислительной технике. – М.: Издательский отдел ”Русская редакция” ТОО ”Channel trading Ltd”, 2005.
2. Материалы сайта ”Сервер информационных технологий”. WEB: www.citforum.ru.
3. Хомоненко А. Базы данных: Учеб. Для вузов. – 2-е изд. – СПб., 2000.
4. Фёдорова А., Елманова Н. Базы данных для всех. –М.: Компьютер пресс , 2001.
5. Глушаков С.В., Ломотько. Базы данных (2001 год издания). – М.: АСТ, 2001.
6 Карпова Т. Базы данных: модели, разработка, реализация, 2001.
7. Когаловский М.Р. Энциклопедия технологий баз данных. –М.: Финансы и статистика, 2002.
8. Конноли Т., Бегг Л., Страчан А. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. – 2-е изд. – Вильямс, 2000.
9. Ханенко В.Н. Информационные системы. – СПб.: Питер, 2001
10. Корнеев В.В., Гареев А.Ф. и др. Базы данных. Интеллектуальная обработка информации. М.: Изд. С.В. Молгачева, 2001.
11. Ребекка М. Райордан Основы реляционных баз данных, 2001.
