Разработка и проектирование подсистемы защиты баз данных корпоративной АИС с учетом требований ФСТЭК России и ГОСТ 34

Введение: Актуальность проблемы защиты корпоративных баз данных

В условиях стремительной цифровизации экономики и роста зависимости бизнеса от критически важных данных, корпоративная автоматизированная информационная система (АИС) становится ключевым объектом защиты. Центральным элементом любой АИС, хранящим самый ценный актив — информацию, является система управления базами данных (СУБД). Актуальность проектирования специализированной подсистемы защиты БД обусловлена не только возрастающей изощренностью внешних кибератак (например, SQL-инъекции), но и строгими требованиями российского законодательства, прежде всего Федерального закона № 152-ФЗ «О персональных данных» и обязательных приказов ФСТЭК России. Игнорирование этих требований несет как репутационные, так и прямые финансовые риски, что является недопустимым.

По данным отраслевых отчетов, внутренние угрозы (инсайдерские атаки или небрежность сотрудников), которые часто используют чрезмерные или неиспользуемые привилегии доступа к СУБД, являются одной из наиболее известных причин инцидентов безопасности баз данных. Это подчеркивает, что защита БД — это не только периметровая оборона, но и глубокий контроль над внутренними процессами и привилегиями доступа.

Целью данной работы является разработка, обоснование и проектирование интегрированной подсистемы защиты баз данных корпоративной АИС.

Для достижения поставленной цели необходимо решить следующие задачи:

1. Провести анализ актуальных угроз и разработать комплексную модель нарушителя для СУБД.
2. Определить обязательные нормативно-правовые требования (ФЗ-152, Приказ ФСТЭК № 64) и соотнести их с классом защиты СУБД.
3. Обосновать архитектурные решения и функциональные механизмы защиты (DAM, DBF, RLS) для обеспечения гранулированного контроля доступа и аудита.
4. Спроектировать подсистему защиты в соответствии с методологией ГОСТ 34 серии, детализируя требования к Техническому заданию.
5. Провести количественную оценку риска и выполнить экономическое обоснование внедрения разработанной подсистемы.

Теоретические основы и анализ угроз безопасности СУБД

Основой для проектирования любой системы защиты служит четкое понимание фундаментальных принципов информационной безопасности (ИБ). Информационная безопасность (ИБ) — это процесс обеспечения триады свойств информации: конфиденциальности, целостности и доступности. ИБ не является одноразовым действием, а представляет собой непрерывный цикл управления рисками.

Термин	Определение (В контексте ГОСТ/Академических источников)	Роль в подсистеме защиты БД
Конфиденциальность (Confidentiality)	Свойство информационных ресурсов, связанное с тем, что они не станут доступными и не будут раскрыты для неуполномоченных лиц (ГОСТ Р ИСО/МЭК 17799-2005).	Обеспечивается механизмами управления доступом и криптографическим шифрованием данных.
Целостность (Integrity)	Обеспечение достоверности и полноты информации и методов ее обработки. Неизменность данных в процессе передачи или хранения.	Обеспечивается контролем ссылочной целостности, хэшированием, резервным копированием и восстановлением.
Доступность (Availability)	Свойство, определяющее возможность получения и использования информационных ресурсов по требованию уполномоченных лиц.	Обеспечивается отказоустойчивостью СУБД, резервированием, защитой от атак типа «отказ в обслуживании» (DoS).
Подсистема защиты БД	Совокупность программных, аппаратных, организационных и программно-технических средств, реализующих функции ИБ: идентификацию, аутентификацию, разграничение доступа, аудит и криптографическую защиту.	Непосредственный объект проектирования.
СУБД	Программное средство, реализующее функциональные возможности по созданию, манипулированию, обеспечению безопасности, надежности хранения и целостности данных.	Базовая платформа, для которой разрабатывается подсистема защиты.

Классификация актуальных угроз и уязвимостей

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

1. Уровень сети: Перехват трафика, атаки «отказ в обслуживании» (DoS/DDoS), спуфинг.
2. Уровень операционной системы (ОС): Компрометация ОС, на которой работает СУБД, эксплуатация уязвимостей ОС для получения административных привилегий, несанкционированный доступ (НСД) к файлам БД.
3. Уровень базы данных (СУБД): Наиболее критичный уровень, включающий атаки, направленные непосредственно на логику работы СУБД.

К наиболее критичным и актуальным угрозам на уровне СУБД относятся:

SQL/NoSQL-инъекции

SQL-инъекция остается одной из самых опасных и распространенных угроз. Она основана на внедрении вредоносного кода через внешний интерфейс веб-приложения или другого клиентского ПО, который затем передается в бэк-энд СУБД. Если входные данные не проходят должную очистку, СУБД воспринимает внедренный код как часть легитимного запроса. Это позволяет злоумышленнику: получить несанкционированный доступ к конфиденциальным данным (кража); манипулировать или уничтожать данные; а в некоторых случаях — получить контроль над всей системой при эксплуатации специфических уязвимостей.

Угроза повышения привилегий (Инсайдерские атаки)

Эта угроза преимущественно исходит от внутренних нарушителей (инсайдеров), которые могут быть как злонамеренными, так и небрежными. Инсайдеры часто имеют легитимные привилегии доступа, но используют их для получения доступа к информации, которая не требуется им для выполнения служебных обязанностей. Атака повышения привилегий реализуется через использование чрезмерных привилегий, предоставленных по ошибке или избыточности, а также эксплуатацию конфигурационных ошибок СУБД, позволяющих получить более высокий уровень доступа (например, от обычного пользователя до администратора). Разве внутренние угрозы не являются более сложными для обнаружения, чем внешние, поскольку они маскируются под легитимную активность?

Разработка модели нарушителя и политики безопасности

Разработка модели нарушителя — это формализованное описание потенциального злоумышленника, его целей, квалификации и используемых им средств. Это позволяет нам понять, против кого мы строим защиту.

Модель нарушителя для корпоративной БД

Тип нарушителя	Мотивация и Цель	Уровень квалификации	Используемые средства
Внешний (Хакер/Конкурент)	Финансовая выгода, промышленный шпионаж, вандализм. Цель: Кража, уничтожение, искажение данных.	Высокий (профессиональное знание SQL, уязвимостей, сетевых протоколов).	Сканеры уязвимостей, специализированный софт для SQL-инъекций, DDoS-инструменты.
Внутренний (Рядовой сотрудник)	Личная неприязнь, небрежность, финансовый интерес. Цель: Кража/искажение данных, к которым имеет косвенный доступ.	Средний/Низкий (использование стандартных инструментов СУБД, социальной инженерии).	Чрезмерно широкие привилегии, физический доступ к оборудованию.
Привилегированный внутренний (Администратор СУБД)	Максимальный ущерб, продажа данных. Цель: Кража или уничтожение всего массива данных, обход встроенных средств защиты.	Высокий (знает архитектуру системы и механизмы защиты).	Прямой доступ к системным таблицам, обход штатного аудита.

Политика безопасности СУБД

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

1. Принцип минимальных привилегий (Need-to-Know): Пользователям должны предоставляться только те права и привилегии, которые необходимы им для выполнения служебных обязанностей. Политика должна быть направлена на предотвращение чрезмерных привилегий и немедленную деактивацию устаревших привилегий при изменении должностных обязанностей или увольнении, поскольку именно избыточные права являются лазейкой для инсайдеров.
2. Запрет прямого доступа: Максимальное ограничение прямого доступа пользователей к СУБД, за исключением авторизованных приложений и администраторов.
3. Обязательный аудит: Требование непрерывного и независимого аудита всех действий привилегированных пользователей и попыток НСД (через DAM-системы).
4. Процедура реагирования: Четкие инструкции по реагированию на инциденты безопасности, включая обнаружение SQL-инъекций и несанкционированного повышения привилегий.

Нормативно-правовое и проектное обоснование подсистемы защиты

Проектирование подсистемы защиты в Российской Федерации невозможно без учета обязательных требований государственных регуляторов, в первую очередь ФСТЭК России.

Требования ФЗ-152 и Приказа ФСТЭК № 64 к защите СУБД

Основным правовым актом, требующим защиты информации, является Федеральный закон от 27 июля 2006 г. № 152-ФЗ «О персональных данных». Если корпоративная БД содержит ПДн, требования закона обязательны к выполнению.

Для обеспечения технического соответствия этим и другим требованиям (например, для защиты государственных ИС и объектов КИИ), ФСТЭК России устанавливает обязательные требования к самим средствам защиты и к защищенности информационных систем.

Критически важным документом для проектирования является Приказ ФСТЭК России от 14.04.2023 N 64, который утвердил обязательные Требования по безопасности информации к системам управления базами данных (СУБД).

Приказ № 64 устанавливает 6 классов защиты СУБД (от 1-го до 6-го). Чем ниже номер класса, тем выше требования к защищенности. Выбор класса защиты СУБД напрямую зависит от категории значимости обрабатываемой информации и типа информационной системы:

Класс защиты СУБД (Приказ ФСТЭК № 64)	Тип системы и Категория/Уровень	Требования к защите
СУБД 4 класса защиты	Объекты КИИ 1 категории значимости; ГИС 1 класса защищенности; ИСПДн 1 уровня защищенности ПДн.	Максимальные требования к защите от НСД, мандатному контролю, аутентификации.
СУБД 5 класса защиты	Объекты КИИ 2 категории значимости; ГИС 2 класса защищенности; ИСПДн 2 уровня защищенности ПДн.	Высокие требования, обязательность применения сертифицированных средств защиты.
СУБД 6 класса защиты	Объекты КИИ 3 категории значимости; ГИС 3 класса защищенности; ИСПДн 3 уровня защищенности ПДн.	Базовые требования к защите.

Следствие для проектирования: При проектировании подсистемы защиты необходимо сначала определить класс защищенности АИС (например, если обрабатываются специальные категории ПДн, это может быть 1 уровень защищенности), а затем выбрать СУБД (или доработать ее защиту), которая соответствует требуемому классу (например, 4 или 5 классу защиты СУБД). Обеспечение выполнения этих требований является обязательным при проведении работ по оценке соответствия и аттестации системы.

Применение методологии ГОСТ 34 серии в проектировании

Процесс создания, модернизации и проектирования автоматизированных систем (АС) в России традиционно регламентируется стандартами ГОСТ 34 серии. ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Стадии создания» определяет последовательность шагов, которые необходимо пройти, чтобы ввести систему в эксплуатацию.

ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы» устанавливает структуру и содержание ключевого проектного документа — Технического задания (ТЗ).

Обоснование выбора проектного подхода: Использование ГОСТ 34 гарантирует методологическую корректность, академическую строгость и юридическую обоснованность проекта. Подсистема защиты БД рассматривается как составная часть АС, и ее проектирование должно быть интегрировано в общий цикл создания АС.

Архитектура и функциональные механизмы подсистемы защиты БД

Архитектура подсистемы защиты — это совокупность выбранных и интегрированных механизмов, обеспечивающих защиту информации на уровне СУБД, ОС и сети. Типовые функциональные механизмы включают идентификацию и аутентификацию, управление доступом, аудит (регистрацию событий), криптографические функции и контроль целостности.

Механизмы управления доступом и гранулированная защита

Управление доступом является критически важным элементом, реализующим принцип минимальных привилегий. В современных СУБД используются три основные модели:

1. Дискреционный контроль доступа (DAC): Наиболее распространенная модель. Основана на списках, где владелец объекта (например, таблицы) самостоятельно определяет, кто и какие права (чтение, запись, изменение) имеет к его объекту. Недостаток: Недостаточен для защиты высококонфиденциальной информации, так как права могут быть произвольно переданы.
2. Ролевой контроль доступа (RBAC): Права назначаются не конкретным пользователям, а ролям (например, «Бухгалтер», «Менеджер по продажам»). Пользователь получает права, входя в соответствующую роль. Это упрощает администрирование и является основным механизмом для большинства корпоративных систем.
3. Мандатный контроль доступа (MAC): Или принудительный контроль доступа. Основан на метках безопасности, присваиваемых как субъектам (пользователям), так и объектам (данным). Субъект может получить доступ к объекту только в том случае, если его уровень классификации соответствует или превышает уровень конфиденциальности объекта. MAC является обязательным требованием для СУБД высоких классов защищенности (например, 4 класс по ФСТЭК) и при защите информации категории «гостайна».

Row Level Security (RLS)

Для обеспечения настоящей гранулированности доступа в больших базах данных, особенно при необходимости реализации MAC, используется механизм Row Level Security (RLS). RLS позволяет реализовать разграничение доступа на уровне отдельных строк таблицы, а не только на уровне самой таблицы или колонки.

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

Интеграция систем независимого мониторинга и активной защиты

Внутренние механизмы аудита СУБД могут быть скомпрометированы или отключены привилегированным нарушителем. Поэтому для надежной защиты критически важно внедрение независимых средств мониторинга и активной защиты.

Система	Назначение	Принцип работы	Защищаемая угроза
Database Activity Monitoring (DAM)	Независимый аудит и фиксация активности пользователей.	Мониторинг сетевого трафика СУБД и/или системных вызовов в режиме реального времени. Не полагается на внутренние журналы СУБД.	Инсайдерские атаки, использование чрезмерных привилегий, попытки обхода аудита.
Database Firewall (DBF)	Активное предотвращение и блокировка подозрительных запросов.	Действует как прокси-сервер или сетевой шлюз. Анализирует SQL-запросы в реальном времени, сравнивает их с разрешенной политикой (белый список).	SQL/NoSQL-инъекции, неавторизованные запросы, попытки выполнения вредоносного кода.

Обоснование включения DAM и DBF: Внедрение DBF обеспечивает проактивную защиту, блокируя атаки типа SQL-инъекций до того, как они достигнут СУБД. DAM обеспечивает неотвергаемый и независимый аудит действий администраторов и привилегированных пользователей, что является ключевым требованием для минимизации рисков, связанных с внутренними угрозами и обязательным условием для выполнения требований ФСТЭК.

Криптографические методы и контроль целостности

Криптография обеспечивает защиту конфиденциальности данных при их хранении (шифрование данных на диске — TDE, Transparent Data Encryption) и передаче (SSL/TLS-соединения). Для защиты высокочувствительных данных (паролей, платежной информации) следует применять шифрование на уровне приложения или колонок.

Механизм представлений (View): Представления яв��яются гибким инструментом для обеспечения гранулированной защиты. Они позволяют:

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

Контроль целостности обеспечивается встроенными механизмами СУБД (транзакции, ограничения, триггеры) и организационными мерами (регулярное резервное копирование и процедуры восстановления, регламентированные в Техническом задании).

Этапы проектирования и разработка Технического Задания

Проектирование подсистемы защиты БД должно строго соответствовать методологии, заложенной в ГОСТ 34 серии.

Стадии разработки подсистемы защиты (по ГОСТ 34.601-90)

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

1. Формирование требований к АС: Включает анализ существующих систем, определение целей и задач, проведение анализа угроз и разработку модели нарушителя (выполнено в данной работе). Результат — Отчет о научно-исследовательской работе.
2. Разработка концепции АС: Определение архитектурных решений, выбор базовой СУБД и средств защиты (DAM/DBF).
3. Техническое задание (ТЗ): Основной документ, фиксирующий все требования к системе.
4. Эскизный проект: Разработка предварительных проектных решений, включая принципиальные схемы защиты.
5. Технический проект: Детальная разработка всех подсистем, включая рабочую документацию на подсистему защиты.
6. Рабочая документация: Подготовка инструкций, программ и методик для внедрения и эксплуатации.
7. Ввод в действие: Аттестация системы, приемочные испытания.
8. Сопровождение: Эксплуатация, мониторинг и модернизация.

Состав требований к защите информации в ТЗ (по ГОСТ 34.602-2020)

В соответствии с ГОСТ 34.602-2020, раздел «Требования к системе» в Техническом задании должен содержать подробные требования к подсистеме защиты информации. Эти требования должны быть разделены на три ключевых подраздела:

1. Требования к защите информации от несанкционированного доступа (НСД)

Данный подраздел детализирует механизмы, направленные на предотвращение атак со стороны внутреннего и внешнего нарушителя:

• Идентификация и Аутентификация: Требования к надежности аутентификации (например, использование двухфакторной аутентификации для администраторов СУБД).
• Разграничение доступа: Обязательство реализации модели RBAC, а также применения MAC (например, через RLS) для критически важных данных.
• Реализация DAM/DBF: Четкое требование о внедрении системы независимого мониторинга (DAM) для аудита всех привилегированных операций и системы активной защиты (DBF) для блокировки известных и аномальных SQL-запросов.
• Протоколирование: Требование к объему и срокам хранения журналов аудита (не менее 1 года) и невозможности их удаления или модификации администраторами СУБД.

2. Требования по сохранности информации

Данный подраздел фокусируется на обеспечении целостности и доступности данных после сбоев, ошибок или атак:

• Резервное копирование (РК): Определение периодичности, типа (полное, инкрементное) и места хранения резервных копий. Требование к хранению копий в изолированном, защищенном контуре.
• Восстановление: Разработка регламента и тестирование процедур восстановления БД из копии в заданные сроки (RTO — Recovery Time Objective).
• Контроль целостности: Требования к средствам контроля целостности программного обеспечения СУБД и ОС (например, использование сертифицированных средств контроля целостности).

3. Требования к средствам защиты от внешних воздействий

Этот подраздел касается защиты на физическом и программно-аппаратном уровне:

• Защита от вредоносного ПО: Требования к антивирусной защите серверов СУБД.
• Сетевая защита: Требования к межсетевому экранированию и сегментации сети.
• Защита от физического доступа: Требования к размещению оборудования СУБД в защищенных помещениях.

Оценка эффективности и экономическое обоснование внедрения

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

Методология количественной оценки риска (Годовые ожидаемые потери)

Для академически корректного обоснования используется количественная методология оценки риска, основанная на расчете годовых ожидаемых потерь.

1. Классическая формула риска:

R = P₊ · S

Где:

• R — Риск (величина ожидаемого ущерба).
• P₊ — Вероятность реализации угрозы.
• S — Размер потенциальных потерь (ущерба).

2. Расчет Годовых ожидаемых потерь (R₃од):

Для детализированной оценки используется показатель Годовых ожидаемых потерь (Annualized Loss Expectancy, ALE):

R₃од = У₅диный · Ч₃од

Где:

• R₃од — Годовые ожидаемые потери (ущерб).
• У₅диный — Единовременный ожидаемый ущерб (Single Loss Expectancy, SLE).
• Ч₃од — Годовая частота возникновения угрозы (Annualized Rate of Occurrence, ARO).

Пошаговый алгоритм расчета Единовременного ожидаемого ущерба (У₅диный)

Единовременный ожидаемый ущерб (У₅диный) — это прогнозируемый ущерб от однократной успешной реализации угрозы.

У₅диный = С₀ктива · К₃щерба

Где:

• С₀ктива — Стоимость защищаемого актива.
• К₃щерба — Коэффициент воздействия ущерба (Exposure Factor, EF).

а) Определение Стоимости актива (С₀ктива):

Стоимость актива (корпоративной БД) включает не только стоимость программного обеспечения и оборудования, но и стоимость самой информации (включая затраты на сбор, обработку и хранение данных), а также потенциальные штрафы (например, по ФЗ-152) и затраты на восстановление после инцидента.
Пример: Стоимость восстановления БД после компрометации (рабочее время ИТ-специалистов, юридические издержки, стоимость оповещения клиентов) — С₀ктива = 5 000 000 руб.

б) Определение Коэффициента воздействия ущерба (К₃щерба):

Коэффициент воздействия ущерба (0 < К₃щерба < 1) — это доля потерь от общей стоимости актива, если угроза реализуется. Если утечка данных приводит к полному уничтожению актива, К₃щерба близок к 1. Если только к временной недоступности — ниже.
Пример: Для угрозы SQL-инъекции, приведшей к краже 80% критических данных, экспертная оценка К₃щерба = 0.6 (60%).

в) Расчет У₅диный:

У₅диный = 5 000 000 руб. · 0.6 = 3 000 000 руб.

г) Расчет Годовых ожидаемых потерь (R₃од):

Если, по экспертным данным или статистике, угроза SQL-инъекции в данной отрасли реализуется в среднем 0.2 раза в год (Ч₃од = 0.2):

R₃од = 3 000 000 руб. · 0.2 = 600 000 руб.

Это означает, что без внедрения СЗИ компания ожидает потерь в среднем на 600 000 рублей ежегодно.

Оценка экономической эффективности подсистемы защиты

Экономический эффект (Э) от внедрения подсистемы защиты БД рассчитывается как разница между предотвращенным ущербом и совокупными затратами на систему защиты.

Э = У₉редотв - С₉сзи

Где:

• У₉редотв — Предотвращенный ущерб.
• С₉сзи — Совокупные затраты на создание и эксплуатацию системы защиты информации (стоимость DAM/DBF, внедрение, обучение, зарплата ИБ-специалиста).

1. Расчет предотвращенного ущерба (У₉редотв):

Внедрение СЗИ (например, DBF) снижает годовую частоту возникновения угрозы (Ч₃од) или уменьшает коэффициент воздействия ущерба (К₃щерба).

Допустим, внедрение DBF снижает вероятность реализации угрозы до Ч'₃од = 0.05 (снижение риска на 75%).

Тогда остаточный риск (R'₃од) составит:

R'₃од = 3 000 000 руб. · 0.05 = 150 000 руб.

Предотвращенный ущерб:

У₉редотв = R₃од - R'₃од = 600 000 руб. - 150 000 руб. = 450 000 руб.

2. Расчет экономического эффекта (Э):

Если совокупные годовые затраты на СЗИ (С₉сзи) составляют 300 000 руб.

Э = 450 000 руб. - 300 000 руб. = 150 000 руб.

Положительное значение Э (150 000 руб.) подтверждает, что внедрение подсистемы защиты БД является экономически эффективным, поскольку снижение рисков (ΔR) превышает затраты на ее внедрение. Насколько часто компании пренебрегают этим расчетом, сосредотачиваясь только на технической стороне?

Заключение

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

Ключевые результаты и достижения целей работы:

1. Теоретическое и нормативное обоснование: Даны строгие определения ключевых терминов ИБ и проведено детальное соотнесение класса защиты СУБД с требованиями Приказа ФСТЭК России № 64 от 2023 года (основной документ для проектирования в 2025 году), что обеспечивает юридическую и техническую корректность проекта.
2. Анализ угроз и модель нарушителя: Выявлены критические угрозы (SQL-инъекции, повышение привилегий) и разработана модель нарушителя, ставшая основой для формирования политики минимальных привилегий.
3. Архитектурные решения: Обоснована необходимость использования современных, независимых средств защиты: Database Firewall (DBF) для проактивной блокировки инъекций и Database Activity Monitoring (DAM) для неотвергаемого аудита привилегированных пользователей. Предложено использование Row Level Security (RLS) для реализации гранулированного мандатного контроля доступа.
4. Проектная методология: Проектирование структурировано в соответствии с ГОСТ 34 серии (ГОСТ 34.601-90 и ГОСТ 34.602-2020). Детализировано содержание Технического задания, включая конкретные требования к НСД и сохранности информации.
5. Экономическое обоснование: Проведена количественная оценка риска с использованием методики расчета Годовых ожидаемых потерь (R₃од) и детализацией расчета Единовременного ожидаемого ущерба (У₅диный), подтвердив экономическую эффективность внедрения СЗИ.

Разработанная структура подсистемы защиты БД является обоснованной, актуальной и технически глубокой. Перспективы дальнейшего развития проекта включают детальную разработку рабочей документации, проведение пилотного внедрения и последующую аттестацию АИС на соответствие требованиям ФСТЭК России.

Список использованной литературы

1. Хомоненко А.Д. Базы данных: учебник для вузов / А.Д. Хомоненко [и др.]. Санкт-Петербург: КОРОНА принт, 2004. 736 с.
2. Успенский И.В. Интернет – маркетинг: учебник. Санкт-Петербург: Изд-во СПГУЭиФ, 2003.
3. Экономическая информатика: Введение в экономический анализ информационных систем: учебник. Москва: ИНФРА-М, 2005.
4. Шафер Д.Ф., Фартрел Т., Шафер Л.И. Управление программными проектами: достижение оптимального качества при минимуме затрат. Москва: Вильямс, 2004.
5. Проектирование экономических информационных систем: учебник / под ред. Ю. Ф. Тельнова. Москва, 2005.
6. Автоматизированные информационные технологии в экономике: учебник / под ред. Г.А. Титоренко. Москва: Компьютер, ЮИНИТИ, 2006.
7. Маклаков С. В. Моделирование бизнес-процессов с AllFusion Process Modeler (BPwin 4.1). Москва, 2003.
8. Требования по безопасности информации к системам управления базами данных (выписка): утв. приказом ФСТЭК России от 14.04.2023 N 64. URL: https://www.consultant.ru/ (дата обращения: 24.10.2025).
9. Обеспечение целостности базы данных. URL: https://studfile.net/ (дата обращения: 24.10.2025).
10. Стандартизированные определения: Безопасность информации. URL: https://studfile.net/ (дата обращения: 24.10.2025).
11. Управление доступом к данным. URL: https://wiki.ifmo.ru/ (дата обращения: 24.10.2025).
12. Попов В., Чадаев Н.Г. Построение защищенных БД с использованием мандатного разграничения доступа в PostgreSQL. URL: https://pgconf.ru/ (дата обращения: 24.10.2025).
13. Метод расчета риска информационной безопасности. URL: https://core.ac.uk/ (дата обращения: 24.10.2025).
14. ОС и СУБД: мандатное разграничение доступа. URL: https://postgrespro.ru/ (дата обращения: 24.10.2025).
15. Обзор актуальных угроз безопасности систем баз данных. URL: https://elar.urfu.ru/ (дата обращения: 24.10.2025).
16. Оценка экономической эффективности защиты информации малого предприятия на примере ООО Лилия с помощью метода экспертных оценок. URL: https://donntu.ru/ (дата обращения: 24.10.2025).
17. Формулировка понятия “информационная безопасность” в учебном курсе дисциплины “Основы информационной безопасности”. URL: https://snauka.ru/ (дата обращения: 24.10.2025).
18. Методика оценки величины ущерба от воздействия на автоматизированную информационную систему внутренних угроз. URL: https://cyberleninka.ru/ (дата обращения: 24.10.2025).
19. Требования ГОСТ на автоматизированные системы в ИБ-проектах. Что изменилось и как это применять? URL: https://habr.com/ (дата обращения: 24.10.2025).
20. Типы угроз для базы данных. URL: https://habr.com/ (дата обращения: 24.10.2025).
21. Способы защиты баз данных. URL: https://garda.ai/ (дата обращения: 24.10.2025).
22. Защитные механизмы охраны информации от несанкцион��рованного доступа на примере баз данных. URL: https://cyberleninka.ru/ (дата обращения: 24.10.2025).
23. Классификация угроз в системах управления базами данных. URL: https://cyberleninka.ru/ (дата обращения: 24.10.2025).
24. ГОСТ 34 серии: ГОСТ 34.201-2020, ГОСТ 34.601-90. URL: https://swrit.ru/ (дата обращения: 24.10.2025).
25. Архитектура подсистемы защиты операционной системы. URL: https://bstudy.net/ (дата обращения: 24.10.2025).