Введение
Разграничение прав доступа является необходимой функциональностью любой корпоративной СУБД. Практические все современные СУБД предоставляют набор базовых средств по управлению правами доступа. Как правило, поддерживаются такие концепции, как пользователи и группы, а также так называемая декларативная безопасность – возможность предоставить этим пользователям и группам права доступа к определенным объектам базы данных. Немаловажным вопросом является гранулярность этой безопасности, т.е. насколько детально можно назначить права.
Основными объектами безопасности в СУБД являются таблицы, представления (view), и хранимые процедуры. В зависимости от типа объекта можно управлять правами на конкретные действия с ним. Например, в случае таблиц можно независимо управлять правами на чтение, добавление, удаление и изменение записей. В тех СУБД, где поддерживаются какие-либо другие объекты (например, пользовательские функции), доступом к ним можно управлять аналогичным образом. В некоторых системах можно управлять доступом на уровне отдельного столбца представления или таблицы.
Это достаточно гибкая и развитая система, позволяющая администратору СУБД настраивать права доступа пользователей в соответствии с их служебными обязанностями.
Однако в некоторых случаях встроенной в СУБД функциональности недостаточно для реализации требований корпоративной политики доступа к данным. Дело в том, что очень немногие СУБД позволяют ограничить доступ пользователей к отдельным строкам таблиц, хотя подобное требование достаточно часто встречается в прикладных задачах. Например, менеджеры по продажам не имеют права «видеть» накладные, выписанные в другом офисе той же компании, а директору по продажам все эти данные доступны. Рядовой бухгалтер не должен изменять документы задним числом, но главному бухгалтеру это позволительно. В англоязычной традиции данная функциональность называется Row-Level Security. Устоявшейся русскоязычной терминологии нет, поэтому мы будем пользоваться английским термином, иногда сокращая его до RLS.
Там, где встроенных средств поддержки такой функциональности нет, разработчику придется придумать свой способ гарантировать выполнение требований заказчика. Как и в любой другой задаче, существует большой выбор таких способов. В этой статье предлагается несколько из них.
Предоставление прав
Для уменьшения уязвимости базы данных Oracle настоятельно рекомендует избегать предоставления прав пользователям Oracle типа , таких как права на удаление (т.е. любой) таблицы. Этой проблемы можно вообще избежать, отказавшись от выдачи объектных прав непосредственно пользователям. Кроме того, следует избегать предоставлять полномочия . Полномочия означают, что пользователь, которому они выданы, может, в свою очередь, предоставлять полномочия другим пользователям. В результате администратор баз данных может очень быстро потерять контроль над тем, кому и какие полномочия выдавались.
Непосредственно пользователям следует предоставлять роли, а не полномочия. Это значительно облегчает администрирование базы данных Oracle с большим количеством пользователей, в которой трудно проверить, какие полномочия были выданы непосредственно тому или иному пользователю. — это роль, используемая по умолчанию для каждого пользователя, созданного в базе данных. Удостоверьтесь, что этой роли не назначены никакие лишние роли или полномочия, поскольку каждый пользователь, в том числе такие создаваемые по молчанию пользователи, как и , будет автоматически наследовать эти роли и полномочия.
Следующий запрос показывает, что роль имеет более 12 000 полномочий объектного уровня:
Из более чем 12 000 объектных полномочий, предоставленных роли , свыше 100 являются полномочиями на выполнение пакетов , таких как , , , , и . Отзовите все важные полномочия выполнения у роли . Выдавайте важные полномочия пользователям посредством продуманного использования ролей.
Полномочия наделяют пользователя очень большими возможностями, включая удаление объектов базы данных и изменение таблиц словаря данных. Не стоит и говорить, что полномочия следует предоставлять очень расчетливо.
Безопасность файлов БД и резервных копий
Для обеспечения безопасности данных БД необходимо обеспечить безопасное хранение и передачу файлов БД, резервных копий и данных файлового хранилища (если оно используется).
Файлы БД:
необходимо ограничить доступ к файлам БД с помощью доменных политик. К данным должен иметь доступ только администратор домена, администратор баз данных, а также индивидуальная учетная запись СУБД
всегда использовать антивирусыне средства защиты (с агентами, либо безагентные), в случае использования антивируса с агентом, чтобы не снижалась производительность СУБД, добавьте в исключения антивируса директории, где располагаются исполняетесь файлы СУБД, папки резервных копий и все файлы данных БД
в случае, если резервные копии планируется передавать через сеть, либо могут храниться на недостаточно безопасных носителях, выполняйте архивирование резервных копий с шифрованием
Внимание, используйте только необходимые и достаточные алгоритмы сжатия и шифрования, т.к. при необходимости восстановления или проверки резервных копий может потребоваться в короткий срок расшифровать данные
Каковы особенности защиты БД?
Современные хранилища данных состоят из двух компонентов: хранимых данных (собственно, БД) и программ для управления (СУБД).
Обеспечить безопасность нельзя, не организовав безопасное управление данными. А значит, все уязвимости и вопросы защиты СУБД можно поделить на 2 категории: независящие и зависящие от данных.
Те уязвимости, которые от данных не зависят, характерны и для других видов программного обеспечения. Причина проблем тут разная — это и несвоевременное обновление, и недостаточная квалификация админа, и наличие неиспользуемых функций.
Однако практика показывает, что большая часть аспектов безопасности СУБД как раз-таки зависит от данных. К примеру, многие СУБД поддерживают запросы через некоторый язык, содержащий наборы функций, доступных пользователю. А архитектура используемых языков связана с моделью данных, которая применяется для хранения информации. В результате можно сказать, что модель отчасти определяет особенности языка, а особенности языка определяют наличие в нём определённых уязвимостей. При этом такие общие уязвимости, допустим, как инъекции, выполняются по-разному (Java-инъекция, SQL-инъекция) с учётом синтаксиса языка.
Рецепты для хворающих SQL-запросов
За прошедшее время вы уже воспользовались им более 6000 раз, но одна из удобных функций могла остаться незамеченной — это структурные подсказки, которые выглядят примерно так:
Прислушивайтесь к ним, и ваши запросы «станут гладкими и шелковистыми».
А если серьезно, то многие ситуации, которые делают запрос медленным и «прожорливым» по ресурсам, типичны и могут быть распознаны по структуре и данным плана.
В этом случае каждому отдельному разработчику не придется искать вариант оптимизации самостоятельно, опираясь исключительно на свой опыт — мы можем ему подсказать, что тут происходит, в чем может быть причина, и как можно подойти к решению. Что мы и сделали.
Давайте чуть подробнее рассмотрим эти кейсы — как они определяются и к каким рекомендациям приводят.
AdBlock похитил этот баннер, но баннеры не зубы — отрастут
Экспертный кейс. Расследование фатального замедления времени расчета себестоимости в 1С:ERP 2
При выполнении нагрузочного тестирования информационной системы на базе 1С:ERP для одного из клиентов с целью оценки возможности миграции системы на PostgreSQL и Astra Linux мы столкнулись с неприемлемым увеличением времени выполнения расчета себестоимости.
Строго говоря, сценарий тестирования закрытия месяца не был выполнен вообще – он не укладывался в таймаут выполнения теста, 24 часа. По прошествии 18 часов всё ещё шло выполнение операции «Распределение затрат и расчет себестоимости». Более 16 часов выполнялся подэтап “Расчет партий и себестоимости. Этап. Расчет себестоимости: РассчитатьСтоимость”. Всё это время выполнялся запрос, который в текущей инфраструктуре клиента (СУБД MS SQL Server) выполняется чуть более 3 минут на аналогичных данных.
67
Практика обновления версий PostgreSQL. Андрей Сальников
Предлагаю ознакомиться с расшифровкой доклада 2018 года Андрея Сальникова «Практика обновления версий PostgreSQL»
В большинстве своем, системные администраторы и ДБА бояться как огня делать мажорные обновления версий баз данных (RDBMS), особенно если эта база данных в эксплуатации и имеет достаточно высокую нагрузку. Главной причиной тому некоторый даунтайм базы данных, который всегда подразумевается при планировании таких работ.
На практике, такого рода upgrade занимает довольно длительное время и зачастую администраторам с малым опытом подобных операций приходится откатываться на старую версию баз данных из-за достаточно банальных ошибок, которые можно было бы избежать еще на этапе подготовки.
В Data Egret мы накопили огромный опыт проведения мажорных апгрейдов PostgreSQL в проектах, где нет права на ошибку. Я поделюсь своим опытом и расскажу о следующих шагах процесса: как правильно подготовиться к upgrade-у PostgreSQL? что необходимо сделать на этапе подготовки? как запланировать последовательность действий на сам upgrade? как провести процедуру upgrade-а успешно, без возврата на предыдущую версию бд? как минимизировать или вообще избежать простоя всей системы во время upgrade-а? какие действия необходимо выполнить после успешного upgrade-а PostgreSQL? Я также расскажу про две наиболее популярные процедуры апгрейда PostgreSQL — pg_upgrade и pg_dump/pg_restore, плюсы и минусы каждого из методов и расскажу про все типичные проблемы на всех этапах этой процедуры, и как их избежать.
Доклад будет интересен как новичкам так и тем ДБА которые уже давно работают с PostgreSQL, но хотят побольше узнать о том как правильно планировать и проводить upgrade максимально безболезненно.
Kilor 31 марта 2020 в 09:45
Прячем хранимые процедуры!
Если ты не заметил, многое упирается в то, что вся конфиденциальность и
целостность завязана на использование хранимых процедур или функций. Получается,
что, получив к ним доступ и грамотно проанализировав их код, любой опытный хакер
сможет преобразовать шифрованную белиберду в исходный текст. Конечно, добраться
до кода процедур далеко не всегда реально, потому здесь всплывает вопрос об
утечке программной начинки производства, а именно – логике ПО. Но именно по этой
причине необходимо прибегать к шифрованию процедур и функций в базе. Одно из
самых популярных и удачных средств для таких действий – это программа SQL Shield
(www.sql-shield.com).
После несложной установки приложения не забудь указывать дополнительный флаг
/*sqlshield*/ с выражением «WITH ENCRYPTION» всякий раз, когда будешь создавать
защищенную процедуру. Вот пример функции, которая исполняет простейший запрос к
базе:
Исполняем процедуру и получаем:
Проверим, в каком виде хранится процедура, с помощью специального средства
для ковыряния в файлах базы. Подойдет SQL Server Syscomments Decryptor (www.geocities.com/d0mn4r/dSQLSRVD.html),
который при отображении текста процедуры показывает одни лишь знаки вопроса.
Все работает!
Защита на уровне столбцов
Организациям часто необходимо защищать данные на уровне столбцов, поскольку в базах данных SQL Server часто хранятся данные о клиентах, сотрудниках, коммерческие тайны, данные о продуктах, медицинские, финансовые и другие конфиденциальные данные. К конфиденциальным столбцам часто относятся национальные идентификационные номера/номера социального страхования, номера мобильных телефонов, имя, фамилия, идентификация финансового счета и любые другие данные, которые могут быть расценены как персональные данные (PII).
Методы и возможности, упомянутые в этом разделе, повышают уровень защиты на уровне столбцов при минимальных накладных расходах и без необходимости внесения значительных изменений в код приложения.
Используйте Always encrypted для шифрования неактивных данных и сетевого трафика. Зашифрованные данные расшифровываются только клиентскими библиотеками на уровне клиента приложения. По возможности используйте . Always Encrypted (с анклавами) может повысить производительность операций сравнения, таких как для сценариев случайного шифрования.
Используйте для маскировки данных на уровне столбцов, если вариант Always Encrypted недоступен. Динамическое маскирование данных (DDM) . Используйте Always Encrypted, а не динамическое маскирование данных, когда это возможно.
Вы можете также предоставить разрешения на уровне столбцов для таблицы, представления или функции с табличным значением. Учитывайте следующее: — для столбца можно предоставить только разрешения SELECT, REFERENCES и UPDATE.
— параметр DENY на уровне таблицы не имеет приоритета над grant на уровне столбца.
Проблемы безопасности БД
Киберпреступность развивается одновременно с базами данных и средствами защиты. Но, несмотря на это, за последние годы список главных уязвимостей СУБД мало изменился
Выполнив анализ архитектуры БД, известных уязвимостей, имеющихся средств обеспечения безопасности СУБД и прецедентов нарушения безопасности, можно отметить следующие причины появления проблем:
— разработчики баз данных, администраторы и программисты уделяют недостаточное внимание вопросам безопасности баз;
— разные СУБД применяют различные языковые конструкции доступа к данным, однако они организованы на основе той же модели;
— всерьёз занимаются проблемами безопасности лишь крупные производители СУБД;
— возникают новые модели хранения данных и их виды, сразу попадая в зону риска
Кроме того, ряд уязвимостей потенциально опасны из-за банального невнимания, а иногда даже и незнания администраторами систем БД вопросов безопасности
К примеру, широко эксплуатируются в отношении веб-приложений простые SQL-инъекции, в которых достаточное внимание входным данным запросов не уделено
Для предприятий финансовым компромиссом является использование разных средств обеспечения информационной защиты, ведь внедрение продуктов повышенной защищённости и подбор высококвалифицированного персонала — это очень большие затраты. Однако стоит понимать, что компоненты безопасности могут оказывать на производительность СУБД негативное влияние.
Проблема усугубляется и широким распространением нереляционных СУБД — они оперируют другой моделью данных, но построены по тем же принципам, если сравнивать с реляционными. Нельзя не вспомнить и про многообразие современных NoSQL-решений — это становится причиной разнообразия используемых моделей данных, и, в свою очередь, размывает границу понятия БД в целом.
Следствие вышеперечисленных проблем — это отсутствие единых методик защиты баз. Если говорить о NoSQL-системах, то тут отсутствуют не только общепринятые механизмы сохранения целостности (например, шифрование и аудит данных), но и развитые средства для аутентификации пользователей.
Средства активного аудита сетей.
Активный аудит дополняет идентификацию/аутентификацию и разграничение
доступа, и направлен на выявление подозрительной (злоумышленной и/или
аномальной) активности с целью оперативного принятия ответных мер.
Назначение активного аудита — обнаруживать и реагировать. Обнаружению
подлежит подозрительная активность компонентов сети — от пользователей
(внутренних и внешних) до программных систем и аппаратных устройств.
Подозрительную активность можно подразделить на злоумышленную и аномальную
(нетипичную).
Примерами средств активного аудита являются:
- системные и сетевые сканеры безопасности, такие как XSpider, MaxPatrol;
- сканеры сетевых сервисов — Nmap;
- сканеры открытых сетевых TCP/UDP-портов;
- сканеры, используемые для определения конфигурации межсетевого экрана и построения топологии сети.
Безопасность платформы и сети
Платформа для SQL Server включает в себя физическое оборудование и сетевые компьютеры, с помощью которых клиенты соединяются с серверами базы данных, а также двоичные файлы, применяемые для обработки запросов базы данных.
Физическая безопасность
Рекомендуется строго ограничивать доступ к физическим серверам и компонентам оборудования. Например, оборудование сервера базы данных и сетевые устройства должны находиться в закрытых охраняемых помещениях. Доступ к резервным носителям также следует ограничить. Для этого их рекомендуется хранить в отдельных охраняемых помещениях.
Реализация физической сетевой безопасности начинается с запрета доступа неавторизованных пользователей к сети. Следующая таблица содержит дополнительные сведения об источниках сведений по сетевой безопасности.
| Сведения о | См. |
|---|---|
| SQL Server Compact и сетевой доступ к другим выпускам SQL Server | Раздел «Настройка и обеспечение безопасности среды сервера» в электронной документации по SQL Server Compact |
Безопасность операционной системы
В состав пакетов обновления и отдельных обновлений для операционной системы входят важные дополнения, позволяющие усилить безопасность. Все обновления для операционной системы необходимо устанавливать только после их тестирования с приложениями базы данных.
Кроме того, эффективную безопасность можно реализовать с помощью брандмауэров. Брандмауэр, распределяющий или ограничивающий сетевой трафик, можно настроить в соответствии с корпоративной политикой информационной безопасности. Использование брандмауэра повышает безопасность на уровне операционной системы, обеспечивая узкую область, на которой можно сосредоточить меры безопасности. Следующая таблица содержит дополнительные сведения по использованию брандмауэра с SQL Server.
| Сведения о | См. |
|---|---|
| Настройка брандмауэра для работы со службами SQL Server | Настройка брандмауэра Windows для доступа к компоненту Database Engine |
| Настройка брандмауэра для работы со службами Службы Integration Services | Службы Integration Services (службы SSIS) |
| Настройка брандмауэра для работы со службами Службы Analysis Services | Настройка брандмауэра Windows на разрешение доступа к службам Analysis Services |
| Открытие конкретных портов брандмауэра, чтобы предоставить доступ к SQL Server | Настройка брандмауэра Windows для разрешения доступа к SQL Server |
| Настройка поддержки расширенной защиты для проверки подлинности с помощью привязки каналов и привязки служб | Соединение с компонентом Database Engine с использованием расширенной защиты |
Уменьшение контактной зоны является мерой безопасности, предполагающей остановку или отключение неиспользуемых компонентов. Уменьшение контактной зоны повышает уровень безопасности за счет уменьшения числа возможных способов атаковать систему. Важную роль в ограничении контактной зоны SQL Server играет запуск необходимых служб по принципу «минимума прав доступа», согласно которому службам и пользователям предоставляются только необходимые для работы права. Следующая таблица содержит дополнительные сведения по службам и доступу к системе.
| Сведения о | См. |
|---|---|
| Службы, необходимые для SQL Server | Настройка учетных записей службы Windows и разрешений |
Если в системе SQL Server используются службы IIS, необходимы дополнительные действия для обеспечения безопасности контактной зоны платформы. Следующая таблица содержит сведения о SQL Server и службах IIS.
| Сведения о | См. |
|---|---|
| Безопасность служб IIS в SQL Server Compact | «Безопасность служб IIS» в электронной документации по SQL Server Compact |
| Службы Reporting Services Проверка подлинности | Проверка подлинности в службах Reporting Services |
| SQL Server Compact и доступ к службам IIS | «Блок-схема безопасности служб IIS» в электронной документации по SQL Server Compact |
Безопасность файлов операционной системы SQL Server
SQL Server использует файлы операционной системы для работы и хранения данных. Оптимальным решением для обеспечения безопасности файлов будет ограничение доступа к ним. Следующая таблица содержит сведения об этих файлах.
| Сведения о | См. |
|---|---|
| SQL Server программные файлы | Расположение файлов для экземпляра по умолчанию и именованных экземпляров SQL Server |
SQL Server позволяют повысить безопасность. Для определения новейшего доступного пакета обновления для SQL Serverперейдите на веб-сайт SQL Server .
С помощью приведенного ниже скрипта можно определить установленный в системе пакет обновления.
Безопасность доступа к БД
Когда говорим о безопасном доступе к БД , необходимо иметь ввиду два способа доступа:
- пользовательский и административный доступ к среде управления СУБД
- к среде запуска процесса СУБД и его окружению и файлам БД
При установке MSSQL пользователю предлагается выбрать учетные записи под которыми будут работать сервисы MSSQL:
- Local System — неограниченный доступ к системным ресурсам конкретного сервера
- Local service — права доступа обычного пользователя системы, но с ограничением работы с сетевыми ресурсами
- Network Service — аналогично Local Service, предоставляет права обычного пользователя к ресурсам локальной системы, но также предоставляет возможность работы с сетевыми ресурсами
Какую учетную запись стоит выбрать?
Правильно — ни одну из них, необходимо создать доменную учетную запись, индивидуальную для данного сервера и для конкретной службы MSSQL, для которой настроим ограниченные права доступа.
Ключевое слово — индивидуальную.Что же будет, если мы создадим доменную учетную запись для всех сервисов СУБД в вашей локальной сети? Верно, вирус-шифровальщик будет рад зашифровать все ваши БД разом.
Аналогично поступаем для всех сервисов СУБД и агентов, выдаём ограниченные индивидуальные доменные учетные записи. Исключением из правил является использование отказоустойчивого кластера MSSQL, в данном случае потребуется использовать идентичные учетные записи для сервисов СУБД в рамках кластера.
Отказоустойчивость SQL Server 2012:
Database Mirroring в SQL Server 2012
Кластеры высокой доступности (High Availability Cluster). Крупные компании, которым требуется непрерывность функционирования, постоянная доступность БД и распределение нагрузки, используют SQL Server 2012 в режиме кластера. SQL Server 2012 поддерживает 16-ти узловую кластеризацию, причём кроме кластеризации ядра СУБД, поддерживается также кластеризация Analysis Services, Notification Services и Replication Services. Кластер SQL Server 2012 позволяет обеспечить режим функционирования 24/7 для критических бизнес-приложений.
Двух узловой кластер на базе SQL Server 2012
Угрозы для инфраструктуры
Рассмотрите следующие распространенные угрозы для инфраструктуры:
Атака методом подбора — злоумышленник пытается пройти проверку подлинности, используя несколько паролей для разных учетных записей, пока не будет подобран правильный пароль.
Взлом или распыление пароля — злоумышленники пробуют использовать один тщательно продуманный пароль в отношении всех известных учетных записей пользователей (один пароль ко многим учетным записям)
Если первоначальная попытка распыления пароля оказывается неудачной, они повторяют попытку, используя другой тщательно продуманный пароль, и, как правило, выжидают определенное время между попытками, чтобы избежать обнаружения.
Атаки программой-шантажистом — это тип целенаправленной атаки, при которой вредоносное ПО используется для шифрования данных и файлов, предотвращая доступ к важному содержимому. После удачной атаки злоумышленники вымогают деньги у жертв, обычно в виде криптовалют, в обмен на ключ дешифрования
Большинство заражений программами-шантажистами начинаются с сообщений электронной почты с вложениями, которые пытаются установить программы-шантажисты, или веб-сайтов, на которые размещены наборы эксплойтов, которые пытаются использовать уязвимости в веб-браузерах и другое программное обеспечение для установки программ-шантажистов.
Риски для паролей
Выполните следующие шаги, чтобы снизить риск определения пароля, и сделать так, чтобы злоумышленники не смогли легко угадать имена учетных записей или пароли.
-
Создайте уникальную локальную учетную запись администратора с именем, отличным от Administrator.
-
Используйте сложные надежные пароли для всех учетных записей. Дополнительные сведения о том, как создать надежный пароль, см. в статье Создание надежного пароля.
-
По умолчанию во время настройки виртуальной машины SQL Server в Azure выбирается проверка подлинности Windows. Следовательно, имя для входа SA отключается, а пароль назначается в ходе настройки. Мы рекомендуем не использовать и не включать имя для входа SA. Если вам необходимо имя для входа SQL, используйте одну из следующих стратегий.
Создайте учетную запись SQL с уникальным именем, являющуюся участником роли sysadmin. Этого можно сделать на портале, включив аутентификацию SQL во время подготовки.
Совет
Если не включить аутентификацию SQL во время подготовки, необходимо будет вручную изменить режим аутентификации на Проверка подлинности SQL Server и Windows. Дополнительные сведения см. в статье Изменение режима проверки подлинности сервера.
Если необходимо использовать имя для входа SA, включите его после подготовки и задайте для него новый надежный пароль.
Риски, связанные с программой-шантажистом
Примите во внимание следующие сведения, чтобы минимизировать риски, связанные с программой-шантажистом
Лучшая стратегия защиты от атаки программой-шантажистом — уделить особое внимание уязвимостям RDP и SSH. Кроме того, учтите следующее:используйте брандмауэры и блокируйте порты;
убедитесь, что к операционной системе и приложениям применяются последние обновления безопасности;
используйте групповые управляемые учетные записи служб (gMSA);
ограничьте доступ к виртуальным машинам;
Требовать JIT-доступ и Бастион Azure
усовершенствуйте безопасность контактной зоны, отказавшись от установки инструментов, включая sysinternals и SSMS, на локальном компьютере;
не устанавливайте компоненты, роли Windows и не включайте службы без надобности;
кроме того, необходимо регулярно планировать полное резервное копирование, защищенное от общей учетной записи администратора, чтобы исключить возможность удаления копий баз данных.
Основные требования к безопасности БД
Уязвимости мы разделили (независящие и зависящие от данных). Теперь выделим независящие и зависящие от данных меры по обеспечения безопасности хранилищ.
Требования по безопасности к системе БД, не зависящей от данных:
1. Работа в доверенной среде. Доверенная среда — инфраструктура предприятия с её защитными механизмами, обусловленными политикой безопасности.
2. Обеспечение физической безопасности файлов данных. Здесь требования не отличаются от тех, которые применимы к любым другим файлам приложений и пользователей.
Требования к целостности информации для систем, зависящим от данных:
1. Безопасность пользовательского программного обеспечения. Речь идёт о задачах построения безопасных механизмов доступа и интерфейсов.
2. Безопасная организация работы с данными. Организация данных и управление ими — ключевой вопрос для системы хранения информации. Сюда входит и задача по организации данных с контролем целостности, и другие задачи, порой специфичные для СУБД.
Усовершенствования в области шифрования
В системе шифрования были сделаны два серьезных изменения. Во-первых, ключи теперь могут храниться на внешних аппаратных модулях сторонних разработчиков. Во-вторых, данные, хранящиеся в SQL Server, можно шифровать с использованием метода, понятного для приложений, подключающихся к базе данных. Это означает, что администратор может зашифровать все содержимое базы данных, не меняя при этом код приложения.
Первое нововведение стало возможным благодаря функции расширенного управления ключами (EKM) — она имеется в SQL Server 2008 Enterprise, Developer и Evaluation. EKM зарегистрировать в SQL Server системы управления корпоративными ключами и аппаратные модули безопасности (HSM), разработанные сторонними компаниями. После регистрации устройства пользователь может хранить ключи на этом модуле.
Кроме того, производитель модуля может добавить дополнительные возможности шифрования (например, задать правила устаревания и замены ключей). В некоторых конфигурациях это позволяет закрыть доступ к данным тем администраторам, которые не являются членами группы администраторов системы. Криптографические инструкции T-SQL выполняют шифрование и расшифровку данных с применением ключей, хранящихся на внешнем EKM-устройстве.
Еще одна новая функция, прозрачное шифрование, позволяет шифровать файлы баз данных, не меняя код приложений. Шифрование и расшифровка входных и выходных данных и журналов происходит в режиме реального времени. При этом используется ключ шифрования баз данных (DEK), хранящийся в загрузочной записи базы данных: так его можно использовать при восстановлении. Ключ DEK защищен сертификатом, которых находится в основной базе данных сервера. Схема на рис. 1 демонстрирует архитектуру, обеспечивающую прозрачное шифрование данных.
Рис 1 Архитектура прозрачного шифрования данных
Все описанное помогает защитить статические данные. Существуют различные способы повышения безопасности баз данных: шифрование, настройка брандмауэра на серверах баз данных. Но дело в том, что физический носитель, на котором хранятся базы данных (в том числе и ленты с резервными копиями) подвергаются опасностям еще и другого характера. Злоумышленник может украсть сам носитель, а это, возможно, позволит ему получить доступ к информации, имеющейся на нем.
Используя прозрачное шифрование, можно зашифровать конфиденциальные данные и защитить ключи при помощи сертификата. Тем самым будет обеспечено соблюдение многих законодательных требований и отраслевых рекомендаций по обеспечению безопасности данных.
Функции прозрачного шифрования данных позволяют применять алгоритмы AES и 3DES. Шифрование файла базы данных выполняется на уровне страницы, причем страница шифруется перед записью на диск, а потом расшифровывается во время считывания в память. Для шифрования резервных файлов тоже используется ключ шифрования базы данных.
Для расшифровки базы данных необходимо иметь доступ к сертификату или асимметричному ключу, использованному при шифровании. В противном случает базу данных восстановить не удастся. Ключи следует хранить, пока резервная копия не перестанет использоваться.
Физическая безопасность
Трудно назвать безопасным СУБД сервером, сервер к которому имеется физический доступ неограниченного количества лиц. Даже если используются хитроумные средства ограничения доступа к операционной системе, всегда можно получить физический доступ к диску, после чего расшифровать данные (если они были зашифрованы, что бывает крайне редко) и получить данные организации.
Крайний случай физической незащищенности — рабочая система на ноутбуке руководителя, а ноутбуки, как известно, часто являются целью кражи.
Доступ к серверу или носителю, где располагается БД системы документооборота должен быть ограничен и регламентирован:
- необходимо размещать сервер с СУБД в серверной комнате с контролем доступа и видео-наблюдением
- использовать облачный сервис документооборота