Использование в деятельности организации базы данных, управляемой СУБД, как отдельного объекта информационной системы создает необходимость регламентировать требования к информационной безопасности с учетом особенностей СУБД. Они могут быть сформулированы как в общем положении, рассматривающем вопросы ИБ в компании комплексно, так и в отдельном документе. Разработка политики безопасности сервера и БД поможет оптимизировать бизнес-процессы и снизит степень ИБ-рисков.
В каждой компании – cвоя специфика создания регламентирующих документов. Иногда эту задачу отдают на откуп компаниям, оказывающим услуги на аутсорсинге, иногда ей занимаются собственные службы. В обоих случаях первым шагом в создании инструкции станет аудит серверов и БД. Он позволит выявить зоны риска и создать релевантную модель угроз. Кроме того, аудит подскажет, какое программное обеспечение нуждается в обновлении.
Далее формируется техническое задание, в котором оговаривается, какую структуру документ должен иметь на выходе, какие задачи решать и на какие подразделения компании распространяться. После чего начинается разработка политики безопасности сервера и БД.
Базой для разработки положения становятся:
Какие именно рекомендации и стандарты будут использованы, зависит от архитектуры системы и характеристик базы данных – в какой программной среде она реализована, является ли она стандартной или доработана с учетом потребностей конкретной компании, каковы особенности СУБД. Следует учитывать, что единой концепции обеспечения безопасности БД не существует, в конкретной ситуации все зависит от архитектуры уже работающей системы.
Согласно требованиям Оранжевой книги, инструкция по безопасности БД является одним из ключевых факторов создания требуемого уровня ИБ. Она формируется не только исходя из текущих потребностей системы, но и на перспективу.
В ней должны быть следующие разделы:
На практике разделы расширяются и дополняются, к документу разрабатываются многочисленные приложения. Например, список сотрудников с указанием уровня их привилегий в БД. Процесс разработки политики безопасности БД никогда не заканчивается. Раз в полгода или год ее нужно пересматривать и дополнять исходя из изменений внешней среды, модели угроз, обновления ПО.
Большинство нормативных требований, которые должны быть учтены в инструкции, включены в законы «О персональных данных» и «Об информации». Если в БД обрабатываются персональные данные, то нормативные требования можно найти в разъяснениях и рекомендациях ФСТЭК. Они же будут актуальны, если компания имеет доступ к государственной тайне.
В разделе необходимо дать определение всем терминам, которые в дальнейшем будут использоваться в тексте документа. Иногда здесь оговаривается порядок внесения изменений и дополнений в документ, иногда он выносится в заключительную часть. Здесь же необходимо описать статус документа в общей системе локальных нормативных актов, обслуживающих информационную безопасность компании.
Раздел, посвященный классификации информации ограниченного доступа, является ключевым. Если модель дифференцированного доступа реализуется по принципу присвоения меток пользователям и файлам в БД, то именно здесь сведения должны быть структурированы по уровню конфиденциальности.
Рекомендуется выделять четыре группы конфиденциальности:
Иногда применяется модель градации, как для государственной тайны. Тогда выделяются группы «Секретно», «Особо секретно», «Высшей важности». При проведении аудита БД перед началом разработки политики безопасности сервера и СУБД информационные массивы структурируют, присваивают им категории конфиденциальности. Перечни каталогов и файлов с данными могут быть оформлены в качестве приложения к регламенту.
После того как информация структурирована начинается создание модели ограниченного доступа на организационном, программном и техническом уровнях. Рекомендации по дифференциации доступа можно найти в руководящих документах ФСТЭК РФ.
В инструкции обязательно прописывают:
Для каждой группы пользователей и системных администраторов указывают объем предоставленных прав доступа и управления процессами, реализованными в среде БД. Для меток описывают правила их создания и присвоения, требования к целостности объекта, требования к информации, содержащейся в метках.
Дополнительно описывают:
Если у компании есть филиалы, отдельно описывают процесс предоставления доступа на уровне филиала и головной организации. Допустима визуализация схем доступа для каждой категории пользователей.
Сегодня удаленный доступ к базам данных становится одновременно и ключевым фактором работы, и проблемой для служб безопасности. Многие компании имеют разветвленную структуру с большим количеством удаленных рабочих мест. Некоторые организации хранят свои БД на облачных серверах.
При разработке политики безопасности сервера и БД на первом этапе необходимо решить, будет ли использоваться удаленный доступ к БД в деятельности компании или он полностью исключен. Если исключен, об этом делается пометка в политике безопасности. Обычно такие решения принимаются для СУБД, обслуживающих промышленные объекты. Если он ограничен, прописывается механизм, кто и как может получить разрешение на пользование удаленным доступом и с каких устройств.
Если доступ однозначно разрешен, в политике необходимо описать:
Каждый пользователь БД должен знать, что внешние атаки крайне опасны для информации. В начале этого раздела необходимо описать риски, которым подвержена информация в результате таких внешних атак. Она может быть разглашена, и часть ответственности за разглашение может быть возложена на пользователя, через компьютер которого в систему попал вирус. Она может быть искажена или модифицирована, и это сделает принимаемые на ее основе решения неточными. Может быть отказано в доступе к БД, и это приведет к длительной остановке бизнес-процессов.
Далее в разделе перечисляются угрозы, которым подвержены хранилища данных:
После перечисления угроз даются стандартные рекомендации, как снизить вероятность реализации большинства из них:
Этот раздел может повторять тезисы общей политики информационной безопасности организации. Если оба документа размещены на сайте компании, можно соединить их гиперссылками.
В этом разделе также можно перечислить программные продукты, используемые для обеспечения информационной безопасности БД.
К ним относятся:
В этом разделе содержатся технические требования к серверам, на которых размещается база данных. Рекомендуется устанавливать СУБД на один сервер, а ее приложения – на второй, с более низкими системными требованиями. Требования всегда обусловливаются размером базы данных и количеством обращений к ней в единицу времени. Это влияет на емкость пропускного канала и производительность сервера.
Дополнительно описываются технические требования к физической защите серверной, необходимость наличия кодовых замков, систем видеонаблюдения, ведение журнала учета действий посетителей. Здесь же указываются меры безопасности, позволяющие избежать повреждения базы данных в результате техногенных и природных угроз – аварий, отключения электроснабжения, подтопления. Если БД размещаются на облачных серверах, к ним применяются аналогичные технические и ИБ-требования. При разработке инструкции по безопасности сервера и БД технические требования и требования к безопасности должны быть согласованы со всеми причастными подразделениями.
Требования к обеспечению безопасности данных не будут полными, если не решить задачи, связанные с контролем действий пользователей.
Необходимо регламентировать:
Схожий перечень правил информационной безопасности может быть установлен для сотрудников IТ-подразделений, наделенных правами администрирования. Но он может быть вынесен в приложение, доступное для просмотра только ими.
Сотрудник компании должен знать, что нарушение правил – основание для применения дисциплинарных и иных санкций. Именно поэтому к политике должен обязательно прилагаться лист ознакомления, где сотрудники поставят личную подпись в знак того, что они прочитали инструкцию.
В документах о системе вознаграждений за качественную работу должно быть отмечено, что нарушение требований политики безопасности БД может привести к депремированию. Наличие в трудовых договорах условия о сохранении коммерческой тайны позволит привлечь нарушителя не только к дисциплинарной, но и к гражданско-правовой, уголовной ответственности. Все условия привлечения к ответственности, в том числе методы поиска и фиксации доказательств совершенного нарушения, должны найти свое место в этом разделе.
В конце документа может быть раздел, описывающий правила его корректировки. Политика утверждается на уровне генерального директора организации, и ее действие распространяется на всех сотрудников, имеющих отношение к работе с базами данных. Документ в печатном виде должен находиться в административном отделе. Электронную версию размещают на сайте или внутреннем портале организации, чтобы каждый сотрудник мог обратиться к ней в любое время. Процесс пересмотра документа должен быть регламентирован, ответственные сотрудники должны знать, когда, какие разделы и в каком порядке меняются, как инициировать этот процесс.
04.08.2020
Подпишитесь на нашу рассылку и получите
свод правил информационной безопасности
для сотрудников в шуточных