Классификация СУБД и требования к безопасности: комплексный анализ современных подходов и перспектив

В условиях стремительной цифровизации, когда данные становятся новым «золотом», а информационные системы — кровеносной системой любого бизнеса и государственного управления, роль систем управления базами данных (СУБД) невозможно переоценить. Они хранят, обрабатывают и делают доступной критически важную информацию, от персональных данных граждан до финансовых транзакций и стратегических разработок. Однако с ростом ценности данных пропорционально увеличивается и количество киберугроз, что делает вопрос безопасности СУБД одним из наиболее актуальных и острых вызовов современности. По данным на 2023 год, несанкционированный доступ является одной из основных причин утечек данных, приводя к компрометации миллионов записей по всему миру, включая около 59% персональных данных и до 30% учетных данных. Эти тревожные цифры убедительно демонстрируют значимость эффективного управления базами данных и обеспечения их безопасности.

Целью настоящей работы является деконструирование и всесторонний анализ темы «Классификация СУБД. Требования к безопасности современных СУБД». Мы ставим перед собой задачи по систематизации знаний об основных принципах классификации СУБД на основе различных моделей данных и архитектурных особенностей, а также по глубокому исследованию актуальных требований и методов обеспечения их информационной безопасности. Структура данного академического исследования последовательно раскроет сущность СУБД, проследит их историческую эволюцию, представит многообразие современных систем, а затем углубится в мир киберугроз, стандартов безопасности и передовых методов защиты, включая перспективные направления развития в контексте облачных вычислений, больших данных и искусственного интеллекта.

Основы систем управления базами данных

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

Определение и функции СУБД

В самом широком смысле, Система управления базами данных (СУБД) — это сложный комплекс программно-языковых средств, разработанный для создания, поддержания и обеспечения доступа к базам данных. Ее можно представить как своеобразного «переводчика» или посредника, который стоит между пользователем или приложением и огромными массивами сырых данных, делая их структурированными, управляемыми и полезными.

Ключевые функции СУБД охватывают широкий спектр задач, жизненно важных для любой информационной системы:

• Управление данными во внешней и оперативной памяти: СУБД эффективно организует хранение данных на дисках и управляет их загрузкой в оперативную память для быстрой обработки.
• Журнализация изменений: Все операции, изменяющие данные, тщательно протоколируются, что критически важно для отслеживания событий и восстановления системы после сбоев.
• Резервное копирование и восстановление: СУБД предоставляет механизмы для создания копий данных и их последующего восстановления в случае потери или повреждения, обеспечивая непрерывность бизнеса.
• Поддержка языков определения и манипулирования данными: Это включает языки, такие как SQL, которые позволяют пользователям и приложениям создавать структуру базы данных (DDL — Data Definition Language) и взаимодействовать с данными (DML — Data Manipulation Language).

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

Историческая эволюция СУБД

Путь СУБД от простых файловых систем до современных высокопроизводительных решений — это история постоянного поиска более эффективных способов организации и управления информацией.

Развитие СУБД началось не сразу с реляционной модели, а гораздо раньше. До 1960-х годов основным способом хранения данных были файловые системы, которые быстро исчерпали свои возможности по мере роста объемов информации и усложнения связей.

В середине 1960-х годов появились первые базы данных на больших ЭВМ, открыв новую эру. Ярким примером стала IBM Information Management System (IMS), разработанная в 1966 году для программы Apollo и выпущенная для коммерческого использования в 1968 году. Эти системы заложили основы централизованного управления данными, но имели ограничения, присущие тогдашним технологиям.

Переломный момент наступил в 1970 году, когда Эдгар Кодд опубликовал свою основополагающую работу «A Relational Model of Data for Large Shared Data Banks» в журнале Communications of the ACM. Эта статья заложила теоретические основы реляционной модели, которая вскоре стала доминирующей.

1970-е и 1980-е годы ознаменовались активным развитием реляционных СУБД, а также концепций распределенных баз данных. В то же время, с распространением персональных компьютеров, появились настольные СУБД, такие как dBASE и Paradox, которые сделали базы данных доступными для более широкого круга пользователей и малого бизнеса.

К концу 1980-х и в 1990-е годы, по мере усложнения программных систем, возникли объектно-ориентированные СУБД, призванные более тесно интегрироваться с объектно-ориентированным программированием. Затем появились объектно-реляционные СУБД, которые стремились объединить преимущества обеих парадигм.

Наконец, с начала 2000-х годов, под влиянием взрывного роста объемов данных (Big Data), требовательности к масштабируемости и гибкости, а также появлением облачных технологий, получили развитие NoSQL-СУБД. Этот этап развития знаменует отход от строгих ограничений реляционной модели в пользу разнообразия специализированных решений.

Этапы эволюции СУБД можно наглядно представить в таблице:

Период	Основные особенности	Примеры систем/технологий	Влияние на безопасность
До 1960-х	Файловые системы	—	Отсутствие централизованных механизмов защиты, уязвимость к несанкционированному доступу.
1960-1970-е	Иерархические и сетевые СУБД на больших ЭВМ	IBM IMS, IDMS, Adabas	Появление централизованного контроля доступа, но ограниченные возможности защиты.
С 1970-х	Реляционные СУБД	Oracle, MySQL, SQL Server	Развитие SQL-ориентированных механизмов управления доступом, появление SQL-инъекций.
Конец 1980-х	Объектно-ориентированные и объектно-реляционные СУБД	POET, Versant, PostgreSQL	Новые вызовы безопасности, связанные со сложной структурой объектов и их связей.
С начала 2000-х	NoSQL-СУБД (ключ-значение, документоориентированные, графовые, колоночные)	MongoDB, Cassandra, Neo4j	Распределенные риски, новые угрозы, связанные с гибкими схемами и горизонтальной масштабируемостью.

Каждый из этих этапов не только привносил новые возможности в управление данными, но и ставил новые вызовы перед системами безопасности, требуя постоянной адаптации и совершенствования методов защиты. Именно поэтому так важно учитывать исторический контекст при выборе и внедрении систем безопасности.

Основные модели данных в СУБД

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

1. Иерархическая модель данных.
   Иерархическая модель, популярная в 1960-70-х годах, организует информацию в строгую древовидную структуру. Это означает, что каждый объект-потомок может иметь только одного родителя, но родитель, в свою очередь, может иметь множество потомков. Такая структура естественна для моделирования иерархических отношений, например, организационной структуры компании, административных или воинских подразделений.
   • Принцип организации: Данные представлены в виде дерева, где узлы — это сегменты данных, а связи — отношения «родитель-потомок».
   • Пример: IBM IMS (Information Management System) — одна из старейших и наиболее известных иерархических СУБД, выпущенная в 1968 году. Она до сих пор используется в некоторых крупных корпорациях.
   • Преимущества: Простота и эффективность при работе с иерархически организованными данными, быстрая навигация по предопределенным связям.
   • Недостатки: Главное ограничение — сложность представления связей типа «многие-ко-многим» и отсутствие гибкости при изменении структуры. Изменение одного узла может повлиять на всю ветвь.
2. Сетевая модель данных.
   Сетевая модель, появившаяся как расширение иерархической, предлагает большую гибкость, позволяя потомку иметь множество предков. Это позволяет представлять более сложные связи, чем простая древовидная структура, и организовывать базу данных, структура которой выглядит как граф общего вида.
   • Принцип организации: Данные представлены в виде записей (подобных узлам) и наборов (подобных связям), где одна запись может участвовать в нескольких наборах в качестве «потомка».
   • Примеры: Integrated Database Management System (IDMS), выпущенная в 1971 году, и Adabas (Adaptable DAta BAse System), разработанная Software AG и также выпущенная в 1971 году.
   • Достоинства: Эффективное использование памяти и хорошие показатели оперативности для сложных запросов, высокая производительность при работе с предопределенными связями.
   • Недостатки: Сложность проектирования и поддержки, отсутствие физической независимости данных (изменение физической структуры может потребовать изменения логической), что затрудняет ее использование для неспециалистов.
3. Реляционная модель данных.
   Реляционная модель данных, концепция которой была сформулирована Эдгаром Коддом в 1969-1970 годах, стала революционной и доминирующей в мире СУБД. Она представляет данные в виде двумерных таблиц, известных как отношения, состоящих из строк (кортежей) и столбцов (атрибутов). Эти таблицы связаны между собой через общие поля.
   • Принцип организации: Данные хранятся в таблицах, где каждая строка уникальна, а столбцы имеют определенный тип данных. Связи между таблицами устанавливаются с помощью внешних ключей.
   • Управление: Управление реляционными базами данных осуществляется с помощью стандартизированного языка SQL (Structured Query Language), который объединяет функции описания и манипулирования данными.
   • Примеры: Oracle Database, MySQL, Microsoft SQL Server, PostgreSQL, Firebird.
   • Достоинства:
     • Отсутствие дублирования данных: Нормализация помогает минимизировать избыточность.
     • Исключение ошибок и аномалий: Строгая структура и реляционные ограничения обеспечивают целостность данных.
     • Упрощенная и удобная схема данных: Табличное представление интуитивно понятно и удобно для пользователя.
     • Высокая гибкость запросов: SQL позволяет извлекать данные практически любым способом.
   • Недостатки: В некоторых случаях может возникнуть избыточность по полям из-за необходимости создания связей между таблицами, что, впрочем, компенсируется общими преимуществами модели. Для очень больших объемов неструктурированных данных или сложных графовых связей реляционная модель может быть менее эффективной по производительности по сравнению со специализированными NoSQL-решениями.

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

Архитектура и классификация современных СУБД

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

Реляционные и объектно-реляционные СУБД

Несмотря на появление множества альтернатив, реляционные СУБД продолжают доминировать на рынке. По данным на 2024–2025 годы, они традиционно удерживают долю свыше 60-70% рынка корпоративных систем. Эта устойчивость объясняется их зрелостью, надежностью, стандартизацией (SQL) и обширной экосистемой инструментов и квалифицированных специалистов. Они остаются основой для большинства транзакционных систем (OLTP), где важна высокая согласованность данных.

К популярным реляционным СУБД относятся:

• Oracle Database: Лидер рынка корпоративных СУБД, известный своей мощью, масштабируемостью и широкими возможностями для обеспечения безопасности.
• MySQL: Популярная открытая СУБД, широко используемая в веб-приложениях.
• Microsoft SQL Server: Корпоративная СУБД от Microsoft, глубоко интегрированная с экосистемой Windows и Azure.
• PostgreSQL: Мощная, расширяемая СУБД с открытым исходным кодом, часто называемая «самой продвинутой открытой реляционной базой данных».
• Firebird: Легковесная, высокопроизводительная реляционная СУБД с открытым исходным кодом.
• Линтер: Российская СУБД, разрабатываемая компанией АО «НПП «РЕЛЭКС» с 1990 года, активно применяемая в критически важных системах.

Однако, по мере усложнения данных и появления объектно-ориентированных языков программирования, возникла потребность в более естественном представлении сложных структур. Это привело к появлению объектно-ориентированной модели данных.

В этой модели данные представляются в виде объектов, аналогичных тем, что используются в ООП, с их атрибутами, методами и классами. Здесь активно применяются принципы наследования, инкапсуляции и полиморфизма для установления связей.

• Достоинства: Возможность отображения сложных взаимосвязей объектов, идентификация отдельных записей базы данных, тесная интеграция с объектно-ориентированными языками программирования (Python, Java, C#, C++).
• Недостатки: Отсутствие общепринятого определения и универсальных средств манипулирования данными (подобных реляционной алгебре), сложности интеграции с существующими системами и отсутствие стандартизации. Это привело к тому, что объектно-ориентированные СУБД (такие как POET, Versant, O2, Iris) так и не получили широкого распространения в массовом сегменте.

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

Нереляционные (NoSQL) СУБД

Революция больших данных и потребность в горизонтальной масштабируемости, гибкости схем и высокой доступности привели к появлению NoSQL-систем (Not only SQL). Это не единый тип СУБД, а целый класс разнообразных систем, каждая из которых оптимизирована для конкретных сценариев использования и отходит от строгих принципов реляционной модели. Они часто жертвуют частью ACID-свойств (Атомарность, Согласованность, Изолированность, Долговечность) в пользу высокой производительности и масштабируемости, следуя принципам BASE (Basically Available, Soft state, Eventually consistent).

Базы данных «ключ-значение»

Это самый простой тип NoSQL-СУБД, хранящий данные как пары «ключ-значение».

• Принципы работы: Ключ является уникальным идентификатором, а значение может быть любым объектом — от простой строки до сложного JSON-документа или бинарного блоба (Binary Large Object).
• Примеры: Redis (для высокоскоростного кеширования), Amazon DynamoDB, Riak, Memcached.
• Преимущества: Высокая производительность для операций чтения/записи по ключу, простота модели хранения, гибкость в типах значений, а также отличные показатели доступности (Availability) и устойчивости к разделению (Partition tolerance) в контексте CAP-теоремы. CAP-теорема утверждает, что распределенная система может одновременно обеспечить только две из трех гарантий: согласованность (Consistency), доступность (Availability) и устойчивость к разделению (Partition tolerance).
• Недостатки: Неэффективность при работе со сложными моделями данных и группами записей, отсутствие встроенного декларативного языка запросов, подобного SQL, вместо которого часто используются простые API. Это усложняет выполнение сложных аналитических запросов.

Графовые СУБД

Графовые базы данных реализуют сетевую модель в виде графа, используя узлы для объектов/сущностей и рёбра для связей между ними. Они часто рассматриваются как обобщение RDF-модели (Resource Description Framework) или сетевой модели данных.

• Принципы работы: Узлы представляют сущности (например, пользователя, товар), а рёбра — отношения между ними (например, «дружит с», «купил»). Каждому узлу и ребру могут быть присвоены свойства.
• Примеры: Neo4j (одна из самых известных, выпущена в 2007 году), Amazon Neptune, OrientDB (мультимодельная), DataStax Enterprise Graph.
• Области применения: Моделирование социальных сетей, рекомендательные системы, биоинформатика, обнаружение мошенничества, семантическая паутина.
• Преимущества: Гибкая и адаптивная структура, наглядное представление взаимосвязей, высокая скорость запросов для задач с естественной графовой структурой (например, поиск кратчайшего пути, обход связей), так как связи хранятся явно, а не вычисляются через операции соединения (JOIN).

Документоориентированные и колоночные СУБД

• Документоориентированные СУБД: Хранят данные в виде полуструктурированных документов (JSON, XML, BSON), что обеспечивает высокую гибкость схемы. Каждый документ может иметь свою структуру, и нет необходимости заранее определять жесткую схему, как в реляционных БД.
  • Примеры: MongoDB (лидер в этой категории, выпущена в 2009 году), CouchDB, Amazon DocumentDB.
  • Особенности: Подходят для приложений, где схема данных часто меняется или данные не имеют фиксированной структуры. Хорошо масштабируются горизонтально.
• Колоночные СУБД: Представляют данные в виде колонок, каждая из которых аналогична отдельной таблице. В отличие от строковых СУБД, где все данные одной строки хранятся вместе, в колоночных СУБД данные одного столбца хранятся вместе.
  • Примеры: SAP IQ (ранее Sybase IQ, представлена в 1994 году), Google Bigtable, Vertica.
  • Особенности: Значительно ускоряют аналитические запросы (OLAP), которые затрагивают только часть столбцов, так как считывается только необходимая информация. Это также способствует лучшему сжатию данных. Оптимальны для хранилищ данных и аналитических платформ.

Классификация СУБД по способу хранения и обработки

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

1. Локальные (централизованные) СУБД:
   В таких системах все элементы СУБД и базы данных находятся на одном сервере. Обработка запросов может происходить как на самом сервере, так и на устройствах пользователей (в случае клиент-серверной архитектуры).
   • Пример: Microsoft Access — популярная локальная СУБД для небольших приложений и персонального использования. Однако она имеет ограничения по масштабируемости и количеству одновременных пользователей (хотя формально до 255, практические пределы значительно ниже).
   • Влияние на безопасность: Более простая архитектура может упростить защиту периметра, но делает систему единой точкой отказа. Вся ответственность за безопасность лежит на одном узле.
2. Распределенные СУБД:
   Элементы системы и/или данные распределены по нескольким серверам, которые могут находиться как в одном дата-центре, так и географически удаленно, включая облачные среды. Многие современные СУБД, как реляционные (например, Oracle RAC), так и NoSQL (MongoDB, Cassandra), поддерживают распределенное применение.
   • Влияние на безопасность: Обеспечивают высокую доступность и масштабируемость. Однако это создает новые вызовы безопасности:
     • Усложнение периметра: Множество узлов, потенциально в разных сетях и регионах.
     • Безопасность передачи данных: Необходимость защиты данных в движении между узлами.
     • Распределенное управление доступом: Синхронизация политик безопасности между всеми компонентами.
     • Целостность данных: Поддержание согласованности данных при распределенных операциях.

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

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

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

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

Несанкционированный доступ

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

• Причины:
  • Слабые пароли: Использование простых, легко угадываемых или стандартных паролей.
  • Уязвимости в системе безопасности: Эксплуатация ошибок в программном обеспечении СУБД или операционной системе.
  • Ошибки конфигурации: Неправильная настройка прав доступа, открытые порты, отсутствие сегментации сети.
  • Социальная инженерия: Обман сотрудников для получения учетных данных.
• Последствия:
  • Кража конфиденциальных данных: Похищение личной, финансовой, коммерческой, государственной информации. По данным различных исследований, НСД является основной причиной утечек данных, приводя к компрометации миллионов записей по всему миру (около 59% персональных данных и до 30% учетных данных в 2023 году).
  • Вымогательство: Шифрование данных с требованием выкупа.
  • Уничтожение или изменение данных: Целенаправленное повреждение или фальсификация информации.
  • Использование СУБД для других атак: Запуск целевых атак, DDoS-атак или распространение вредоносного ПО через скомпрометированную СУБД.

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

SQL-инъекции

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

• Механизм: Злоумышленник использует уязвимости в коде приложения, которое не должным образом фильтрует или экранирует вводимые пользователем данные. Например, введя ' OR '1'='1 в поле логина, можно обойти аутентификацию.
• Последствия:
  • Несанкционированный доступ: Обход аутентификации и получение доступа к системе.
  • Получение конфиденциальной информации: Извлечение любых данных из базы данных.
  • Изменение или удаление данных: Фальсификация или уничтожение информации.
  • Получение прав администратора: Полный контроль над СУБД.
• Типы SQL-инъекций:
  • In-band (обычные): Ответы сервера содержат данные атаки. Включают Error-based (ошибки СУБД выдают информацию) и Union-based (использование оператора UNION для объединения результатов запросов).
  • Blind (слепые): Сервер не возвращает данные, но злоумышленник может определить результат запроса по поведению приложения (например, по времени ответа или по булевым ответам).
  • Out-of-band: Данные отправляются на внешний контролируемый злоумышленником сервер.
  • Второго порядка: Внедренный код сохраняется в БД и срабатывает при последующем вызове.

SQL-инъекции долгое время остаются одной из наиболее распространенных и критически опасных веб-уязвимостей, входя в топ-10 угроз по версии OWASP. Как следствие, разработчикам и администраторам необходимо уделять особое внимание параметризованным запросам и строгой валидации вводимых данных.

Атаки типа «Отказ в обслуживании» (DoS/DDoS)

DoS-атаки (Denial of Service) и их распределенный вариант DDoS (Distributed Denial of Service) направлены на то, чтобы сделать сервис недоступным для легитимных пользователей. В контексте СУБД это означает перегрузку сервера базы данных, что приводит к снижению производительности или полному отказу в обслуживании.

• Методы реализации:
  • SQL-флуд: Постоянное выполнение большого количества ресурсоемких SQL-запросов, истощающих ресурсы СУБД.
  • Переполнение буфера: Эксплуатация уязвимостей, приводящих к сбою работы СУБД.
  • Использование некорректных или ресурсоемких запросов: Запросы, которые требуют чрезмерных вычислительных мощностей или обращений к диску.
  • Атаки на сетевой уровень: Перегрузка сетевых каналов, препятствующая доступу к серверу СУБД.
• Влияние: Снижение производительности, невозможность выполнения легитимных операций, репутационные и финансовые потери.

Инсайдерские угрозы и человеческий фактор

Инсайдерские угрозы — это одна из наиболее коварных и труднообнаруживаемых опасностей для баз данных. Она исходит от сотрудников или бывших сотрудников, имеющих легитимный доступ к системам. По некоторым оценкам, до 30-40% всех нарушений безопасности данных могут быть связаны с инсайдерскими угрозами.

• Причины:
  • Злоупотребление полномочиями: Сотрудники с привилегированным доступом используют его в корыстных целях (кража, продажа данных).
  • Случайные ошибки: Непреднамеренные действия, такие как некорректная настройка прав доступа, игнорирование обновлений безопасности, несоблюдение процедур резервного копирования.
  • Недостаточная осведомленность: Отсутствие понимания важности соблюдения политик безопасности.
• Человеческие ошибки: Помимо инсайдерских угроз, к уязвимостям относятся общие человеческие ошибки:
  • Использование слабых, легко угадываемых или повторно используемых паролей.
  • Совместное использование учетных записей.
  • Несвоевременное применение обновлений и патчей безопасности.
  • Неудачные конфигурации баз данных, оставленные «по умолчанию» параметры.

Вредоносное программное обеспечение и целенаправленные атаки

Широкий спектр вредоносного программного обеспечения и сложные целенаправленные атаки также представляют серьезную угрозу для СУБД.

• Вредоносное ПО:
  • Вирусы, черви, трояны: Могут проникать в системы, красть учетные данные, портить или уничтожать данные.
  • Программы-вымогатели (ransomware): Шифруют данные в базах данных и требуют выкуп за их дешифровку, парализуя работу всей организации.
  • Шпионское ПО: Собирает конфиденциальную информацию без ведома пользователя.
• Другие угрозы:
  • Фишинг: Массовые или целенаправленные рассылки для кражи учетных данных.
  • Перехват паролей: Использование снифферов или других методов для получения паролей в незашифрованном виде.
  • Ботнеты: Сети зараженных компьютеров, используемые для DDoS-атак или рассылки спама.
  • Эксплойты: Программы, использующие известные уязвимости для получения контроля над системой.
  • Атаки Man-in-the-middle (MitM): Перехват и модификация данных, передаваемых между клиентом и СУБД.
  • Advanced Persistent Threat (APT): Продолжительные и хорошо подготовленные целевые кибератаки, сочетающие различные способы воздействия на корпоративную инфраструктуру, часто направленные на длительное незаметное присутствие в системе для кражи данных.

Понимание этих угроз — первый и самый важный шаг к построению эффективной и многоуровневой системы защиты баз данных. Без этого знания невозможно адекватно оценить риски и выбрать подходящие контрмеры.

Стандарты и требования к безопасности СУБД

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

Национальные требования: ФСТЭК России

В Российской Федерации ключевую роль в регулировании безопасности информации играет Федеральная служба по техническому и экспортному контролю (ФСТЭК России).

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

Международные стандарты: PCI DSS

Стандарт безопасности данных индустрии платежных карт (PCI DSS) — это международный стандарт, разработанный для повышения безопасности данных учетных записей платежных карт и содействия широкому внедрению согласованных мер безопасности данных во всем мире. Он обязателен для всех организаций, которые хранят, обрабатывают или передают данные платежных карт.

PCI DSS состоит из 12 детализированных требований, сгруппированных в шесть основных целей контроля:

1. Построение и поддержание безопасных сетей и систем:
   1. Установка и поддержка брандмауэра.
   2. Запрет использования по умолчанию паролей и других параметров безопасности.
2. Защита данных держателей карт:
   1. Защита хранимых данных держателей карт (шифрование, хеширование, токенизация).
   2. Шифрование передачи данных держателей карт по открытым, публичным сетям (использование TLS 1.2+).
3. Поддержание программы управления уязвимостями:
   1. Защита всех систем от вредоносного ПО и регулярное обновление антивирусного ПО.
   2. Разработка и поддержка защищенных систем и приложений.
4. Внедрение строгих мер контроля доступа:
   1. Ограничение доступа к данным держателей карт по принципу «служебной необходимости».
   2. Идентификация и аутентификация доступа к компонентам системы.
   3. Ограничение физического доступа к данным держателей карт.
5. Регулярный мониторинг и тестирование сетей:
   1. Отслеживание и мониторинг всего доступа к сетевым ресурсам и данным держателей карт.
   2. Регулярное тестирование систем и процессов безопасности.
6. Поддержание политики информационной безопасности:
   1. Поддержание политики информационной безопасности для всего персонала.

Особое внимание уделяется защите хранимых данных о держателях карт с использованием сильного шифрования (например, AES с ключами не менее 128 бит), одностороннего хеширования, усечения или токенизации, а также строгому управлению ключами шифрования. Передача данных по открытым сетям должна быть защищена с помощью сильной криптографии, например, TLS версии 1.2 или выше, а использование устаревших протоколов, таких как TLS 1.0 и 1.1, запрещено с 30 июня 2018 года. PCI DSS категорически запрещает хранение критических аутентификационных данных, таких как полные данные дорожки, CAV2/CVC2/CVV2/CID и ПИН/ПИН-блок.

Международные стандарты: ISO/IEC 27000

Серия международных стандартов ISO/IEC 27000 представляет собой набор лучших практик и рекомендаций в области информационной безопасности, разработанных совместно Международной организацией по стандартизации (ISO) и Международной электротехнической комиссией (IEC). Эта серия предназначена для создания, развития и поддержания системы менеджмента информационной безопасности (СМИБ) в организациях.

• ISO/IEC 27001: Центральный стандарт серии, который устанавливает требования к созданию, внедрению, функционированию, мониторингу, анализу, поддержке и улучшению СМИБ. Основа стандарта — система управления рисками, связанными с информацией, позволяющая определить, где находятся риски, и методично их обрабатывать.
  • Приложение A к ISO/IEC 27001 содержит 114 контролей безопасности, сгруппированных в 14 категорий (доменов), охватывающих:
    • Политику информационной безопасности.
    • Организацию информационной безопасности.
    • Управление активами.
    • Безопасность персонала.
    • Физическую и окружающую безопасность.
    • Управление операциями.
    • Управление доступом.
    • Приобретение, разработку и сопровождение информационных систем.
    • Управление инцидентами информационной безопасности.
    • Управление непрерывностью бизнеса.
    • Соответствие требованиям.
• Определение информационной безопасности: В контексте ISO/IEC 27001 информационная безопасность определяется как сохранение конфиденциальности, целостности и доступности информации. Дополнительно она может включать такие аспекты, как подлинность, невозможность отказа от авторства и достоверность.

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

Методы и средства обеспечения безопасности данных в СУБД

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

К основным средствам защиты СУБД относятся:

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

Управление доступом, аутентификация и авторизация

Управление доступом является краеугольным камнем безопасности любой многопользовательской СУБД. Оно обеспечивает, чтобы только авторизованные пользователи могли получать доступ к определенным данным и выполнять определенные операции.

• Механизмы разграничения доступа:
  • Пароли и логины: Базовый уровень защиты, требующий использования сильных, уникальных паролей и их регулярной смены.
  • Сопоставление замков управления доступом и ключей: Более сложные системы, где к объектам доступа (данным) привязаны «замки», а к субъектам (пользователям) — «ключи».
  • Явная спецификация полномочий: Четкое определение, кто и к чему имеет доступ.
• Ролевая модель разграничения доступа (RBAC — Role-Based Access Control): Это предпочтительный подход, позволяющий применять несколько политик безопасности и контролировать доступ в соответствии с принципом наименьших привилегий. Суть принципа в том, что каждому пользователю или приложению предоставляются только те права доступа, которые абсолютно необходимы для выполнения их функций, и не более. Это значительно снижает риск злоупотребления полномочиями и ограничивает потенциальный ущерб в случае компрометации учетной записи. Управление правами пользователя на уровне базы данных и приложения помогает избежать несанкционированного доступа.

Аутентификация и авторизация — два взаимосвязанных, но различных понятия:

• Аутентификация подтверждает подлинность пользователя (или процесса), отвечая на вопрос «Кто вы?». Это проверка учетных данных, например, логина и пароля, биометрических данных или сертификатов. Системы идентификации и аутентификации пользователей позволяют проводить проверку каждого пользователя на подлинность, ограничивать попытки проникновения извне и манипуляции учетными записями.
• Авторизация определяет, какие действия пользователь (который уже аутентифицирован) может выполнять и к каким ресурсам имеет доступ, отвечая на вопрос «Что вам разрешено делать?».

Криптографические методы защиты данных

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

• Методы шифрования:
  • Симметричное шифрование: Использует один и тот же ключ для шифрования и дешифрования. Отличается высокой скоростью. Примеры: AES (Advanced Encryption Standard), DES (Data Encryption Standard), Blowfish.
  • Асимметричное шифрование: Использует пару ключей — открытый (для шифрования) и закрытый (для дешифрования). Повышает безопасность за счет разделения ключей, но медленнее симметричного. Примеры: RSA (Rivest-Shamir-Adleman), ECC (Elliptic Curve Cryptography), Diffie-Hellman.
  • Гибридные схемы: Сочетают преимущества обоих методов, используя асимметричное шифрование для обмена сессионным симметричным ключом, а затем симметричное для шифрования больших объемов данных.
• Уровни реализации шифрования:
  • На уровне базы данных: Встроенные функции СУБД позволяют шифровать таблицы, столбцы или всю базу данных. Данные доступны после аутентификации и получения ключа. Пример: Прозрачное шифрование данных (TDE).
  • На уровне приложения: Шифрование выполняется самим приложением до того, как данные будут переданы в СУБД. Дает полный контроль над данными и ключами, но требует значительных усилий по разработке и поддержке.
  • На уровне хранилища/файловой системы: Данные шифруются на уровне операционной системы или диска, на котором хранится база данных. Проще в реализации, но защищает только файлы на диске, не затрагивая данные в памяти или при передаче.

Прозрачное шифрование данных (TDE) — это особая форма шифрования на уровне базы данных, поддерживаемая многими коммерческими СУБД (Microsoft SQL Server, Oracle Database, IBM Db2). Оно автоматически шифрует все данные в файлах базы данных, включая журналы транзакций и резервные копии, не требуя изменений в приложениях или пользовательском коде. TDE обеспечивает защиту данных в покое с минимальным влиянием на приложения.

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

Аудит и мониторинг активности СУБД

Аудит безопасности СУБД — это систематическая проверка работоспособности и безопасности IT-системы, которая может быть внутренней или внешней. Он позволяет выявлять уязвимости, отслеживать подозрительную активность и обеспечивать соответствие регуляторным требованиям.

• Штатный аудит СУБД: Большинство коммерческих СУБД имеют встроенные механизмы аудита, которые включают ведение журнала подключения к СУБД и выполнения запросов. Часто это реализуется с использованием триггеров и специфичных функций.
  • Недостатки штатного аудита:
    • Дополнительная нагрузка на серверы БД: Постоянная запись большого объема данных аудита может снижать общую производительность системы.
    • Вовлечение администраторов БД в настройку: Это затрудняет независимый контроль привилегированных пользователей, так как они могут изменить или отключить аудит.
    • Отсутствие удобного интерфейса: Анализ журналов может быть сложным.
    • Невозможность контроля действий пользователей в приложениях с трехзвенной архитектурой: Когда приложение взаимодействует с БД под одной учетной записью, сложно отследить действия конкретного конечного пользователя.
• Автоматизированные системы защиты баз данных: Для более эффективного аудита и мониторинга используются специализированные решения:
  • Database Activity Monitoring (DAM): Обеспечивает независимый мониторинг действий пользователей в СУБД. Системы DAM перехватывают и анализируют трафик между клиентами и СУБД, а также локальную активность на сервере базы данных, не внося изменений в код приложений или СУБД. Они могут работать в режиме прокси-сервера, сетевого сниффера или агента на сервере БД. DAM позволяет классифицировать SQL-запросы, вести полный аудит запросов и ответов, не нагружая бизнес-процессы.
  • Database Firewall (DBF): Действует как шлюз или прокси-сервер между клиентами и СУБД. DBF осуществляет защиту внутренних и внешних серверов баз данных, независимый мониторинг пользователей, поведенческий анализ и блокировку подозрительных запросов в режиме реального времени. Он может блокировать запросы, соответствующие заранее определенным правилам или аномалиям, выявленным поведенческим анализом.

Пример встроенного аудита: Подсистема аудита SQL Server отслеживает и журналирует события на уровне сервера и базы данных, записывая их в журналы событий или файлы аудита, что позволяет контролировать доступ и изменения.

Резервное копирование и восстановление

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

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

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

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

Разработка и внедрение политик безопасности

Разработка эффективных политик безопасности СУБД — это сложный процесс, требующий учета множества факторов:

• Требования законодательства: Политики должны строго соответствовать всем применимым законам и нормативным актам в области информационной безопасности (например, Приказ ФСТЭК России №64, GDPR, HIPAA, PCI DSS).
• Внутренние корпоративные документы: Политики должны интегрироваться с общей стратегией информационной безопасности организации, ее внутренними регламентами и стандартами.
• Эргономичность системы безопасности: Важно, чтобы меры безопасности не создавали чрезмерных препятствий для легитимных пользователей и бизнес-процессов. Излишне сложные или неудобные политики будут игнорироваться или обходиться.
• Организационная поддержка: Политика информационной безопасности должна поддерживаться на организационном уровне, начиная с высшего руководства. Необходимо четкое распределение ролей и ответственности, обучение персонала и регулярное информирование о рисках.

Важным аспектом является проведение регулярного аудита исполнения политик безопасности. Это позволяет своевременно обнаруживать уязвимости, выявлять нарушения и адаптировать политики к изменяющимся угрозам и условиям.

Концепция «нулевого доверия» (Zero Trust)

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

• Принципы: Концепция Zero Trust исходит из предпосылки, что ни одно устройство, пользователь или сеть не должны считаться доверенными по умолчанию, даже если они находятся внутри периметра организации. Вместо традиционной модели «доверяй внутри, не доверяй снаружи» Zero Trust призывает к постоянной верификации.
• Для СУБД это означает:
  • Строгая аутентификация и авторизация: Все запросы к базам данных должны быть верифицированы, авторизованы и постоянно контролироваться, независимо от источника запроса.
  • Минимальные привилегии: Пользователям и приложениям предоставляются только строго необходимые права доступа.
  • Сегментация сети: Базы данных изолируются в отдельных сетевых сегментах.
  • Непрерывный мониторинг: Постоянный анализ активности для выявления аномалий.

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

Примеры реализации систем безопасности в популярных СУБД

Рассмотрим, как конкретные СУБД реализуют меры безопасности:

• Google Cloud SQL (управляемый сервис MySQL, PostgreSQL, SQL Server в Google Cloud):
  Google, как облачный провайдер, берет на себя значительную часть ответственности за безопасность. В Cloud SQL автоматически внедряется множество методов безопасности:
  • Шифрование данных: Данные автоматически шифруются как в покое (с использованием AES-256 или более сильных алгоритмов), так и в движении (TLS 1.2+ для всех соединений).
  • Контроль доступа: Интеграция с Identity and Access Management (IAM) Google Cloud для детального управления доступом.
  • Функции мониторинга: Интеграция с облачными сервисами мониторинга и логирования.
  • Автоматическое резервное копирование и патчи: Google автоматически управляет резервным копированием и применением патчей безопасности.
• Microsoft SQL Server:
  Эта СУБД предлагает широкий спектр встроенных функций безопасности, позволяющих администраторам реализовать комплексные политики:
  • Аутентификация и авторизация: Поддержка различных методов аутентификации (SQL Server Authentication, Windows Authentication), ролевая модель, детальное управление разрешениями.
  • Прозрачное шифрование данных (TDE): Шифрует всю базу данных, файлы данных и журналов в покое без изменения приложений.
  • Always Encrypted: Позволяет шифровать конфиденциальные столбцы данных таким образом, что данные остаются зашифрованными даже в памяти SQL Server, доступными только для приложений с соответствующими ключами.
  • Row-Level Security (RLS): Позволяет контролировать доступ к отдельным строкам таблицы на основе контекста выполнения (например, по идентификатору пользователя), обеспечивая принцип наименьших привилегий.
  • Динамическое маскирование данных (Dynamic Data Masking): Скрывает конфиденциальные данные от несанкционированных пользователей, не изменяя сами данные в базе.
  • Расширенные возможности аудита: Подсистема аудита позволяет детально отслеживать и журналировать события на уровне сервера и базы данных.

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

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

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

Безопасность СУБД в облачных вычислениях

Переход к облачным моделям (IaaS, PaaS, SaaS) значительно меняет подходы к безопасности баз данных. Безопасность облачных данных — это комплекс процессов, технологий и решений, предназначенных для защиты информации, хранящейся в облачной инфраструктуре.

• Модель общей ответственности (Shared Responsibility Model): В облаке ответственность за безопасность распределяется между облачным провайдером и клиентом. Провайдер отвечает за «безопасность облака» (базовая инфраструктура, физическая безопасность, сеть, гипервизоры), а клиент — за «безопасность в облаке» (свои данные, приложения, конфигурации, управление доступом, операционные системы). Это ключевой аспект, который необходимо понимать при работе с облачными СУБД.
• Ключевые аспекты безопасности облачных баз данных:
  • Предотвращение несанкционированного доступа: Строгий контроль доступа с использованием Identity and Access Management (IAM) провайдера.
  • Шифрование данных: Как при хранении (в покое), так и при передаче (в движении).
  • Соблюдение нормативных правил: Обеспечение соответствия регуляторным требованиям (PCI DSS, GDPR, ФСТЭК).
  • Оценка безопасности облака: Регулярные аудиты и тестирования.
• Основные способы защиты данных в облаке:
  • Многофакторная аутентификация (MFA): Добавляет дополнительный уровень безопасности, требуя два или более фактора для подтверждения личности.
  • Ролевое управление доступом (RBAC): Позволяет назначать пользователям и приложениям роли с минимально необходимыми привилегиями.
  • Постоянное устранение уязвимостей: Регулярные обновления ПО и управление патчами.
  • Журналирование и мониторинг активности: Для выявления подозрительного поведения.
  • Сегментация сети: Изоляция различных компонентов СУБД и приложений.
  • Web Application Firewall (WAF) и защита от DDoS-атак: Для защиты от внешних угроз.
• Внедрение DevSecOps: Позволяет интегрировать меры защиты на всех этапах жизненного цикла разработки, тестирования и эксплуатации приложений и СУБД в облачной инфраструктуре.
• Принципы минимальных привилегий и сегментации сети: Эти принципы критически важны в облаке для ограничения распространения угроз.

Облачные базы данных (DBaaS — Database as a Service), такие как Amazon RDS, Google Cloud SQL, Microsoft Azure SQL Database, предоставляют масштабируемость и упрощают управление, но требуют повышенного внимания к вопросам конфиденциальности, поскольку данные хранятся у стороннего провайдера.

Защита больших данных

Технологии больших данных (Big Data) с их огромными объемами, разнообразием и скоростью обработки информации создают уникальные вызовы для безопасности, но также предоставляют новые возможности для защиты СУБД.

• Возможности для защиты:
  • Непрерывный мониторинг в режиме реального времени: Сбор, хранение и анализ огромных объемов логов и событий безопасности из СУБД. Это позволяет выявлять аномалии и паттерны подозрительной активности.
  • Управление правилами разграничения доступа: Более гранулярный контроль доступа, основанный на анализе контекста и поведения.
  • Идентификация источников данных: Отслеживание происхождения и перемещения данных.
  • Динамическое профилирование: Использование машинного обучения и больших данных для создания «нормального» профиля поведения пользователей, приложений и самой базы данных. Любые отклонения от этого профиля расцениваются как потенциальная угроза.
• Вызовы и риски:
  • Нарушение конфиденциальности и анонимности: Сложность обеспечения конфиденциальности больших наборов данных, особенно при их агрегации и анализе.
  • Трудности в управлении доступом: Из-за разнородности источников и большого количества пользователей.
  • Уязвимости в распределенных системах: Множество компонентов и узлов увеличивают поверхность атаки.
  • Отсутствие единой концепции защиты: Пока нет общепринятой единой методологии защиты Big Data, что требует индивидуального подхода.

Искусственный интеллект (ИИ) и машинное обучение в безопасности СУБД

Искусственный интеллект (ИИ) и машинное обучение (МО) играют двойную роль в сфере безопасности СУБД: они являются как мощным инструментом в руках злоумышленников, так и перспективным средством защиты.

• ИИ как инструмент злоумышленников:
  • Автоматизация сбора данных: ИИ может автоматизировать поиск уязвимостей, сканирование сетей и сбор информации о потенциальных жертвах.
  • Адаптивный фишинг и социальная инженерия: Создание более убедительных и персонализированных фишинговых сообщений.
  • Генерация сложных атак: ИИ может генерировать более изощренные и скрытые SQL-инъекции, а также разрабатывать адаптивные методы обхода традиционных систем обнаружения вторжений, что делает атаки более целенаправленными и труднообнаружимыми.
  • Распространение вредоносного ПО: ИИ может использоваться для создания самообучающихся вредоносных программ.
• ИИ как средство защиты:
  • Автоматическое обнаружение аномалий: Системы безопасности на базе ИИ и МО могут анализировать паттерны доступа к СУБД, выявлять аномалии в поведении пользователей (например, необычное время доступа, необычные запросы, доступ к редко используемым таблицам), предсказывать потенциальные угрозы.
  • Поведенческий анализ: Создание профилей «нормального» поведения и выявление отклонений от них.
  • Автоматическое реагирование: Специально разработанные системы на базе ИИ могут автоматически блокировать подозрительные действия, уведомлять специалистов о потенциальных угрозах и даже предоставлять рекомендации по их устранению.
  • Прогнозирование угроз: Анализ больших объемов данных об угрозах для выявления новых тенденций и прогнозирования будущих атак.

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

Заключение

Исследование «Классификация СУБД и требования к безопасности: комплексный анализ современных подходов и перспектив» позволило нам глубоко погрузиться в мир систем управления базами данных, деконструировав их сущность, эволюцию и многообразие. Мы проследили путь СУБД от ранних иерархических систем до доминирующих реляционных и гибких NoSQL-решений, подчеркнув, как каждая модель данных и архитектура формирует уникальный набор требований к безопасности.

Основные выводы исследования заключаются в следующем:

1. Многообразие СУБД: Современный ландшафт СУБД представлен не только классическими реляционными системами, но и широким спектром NoSQL-решений, каждое из которых имеет свои преимущества и специфику применения, а также, что критически важно, свои уникальные вызовы безопасности.
2. Эволюция угроз: Угрозы безопасности СУБД постоянно развиваются, от классических SQL-инъекций и несанкционированного доступа до сложных инсайдерских атак, вредоносного ПО и целенаправленных Advanced Persistent Threat (APT). Это требует непрерывного совершенствования методов защиты, поскольку вчерашние решения могут оказаться бессильны перед завтрашними вызовами.
3. Значимость стандартов: Национальные (ФСТЭК России) и международные (PCI DSS, ISO/IEC 27000) стандарты играют ключевую роль в формировании требований к безопасности, обеспечивая нормативную базу и лучшие практики для построения защищенных систем.
4. Комплексный подход: Эффективная защита СУБД невозможна без комплексного подхода, включающего управление доступом, криптографические методы, системы аудита и мониторинга (DAM, DBF), а также надежное резервное копирование и восстановление. При этом решающее значение имеют организационные политики безопасности и принцип «нулевого доверия».
5. Перспективные направления: Облачные вычисления, большие данные и искусственный интеллект не только создают новые вызовы (распределенная ответственность, риски конфиденциальности), но и предлагают новые мощные инструменты для защиты (динамическое профилирование, ИИ-мониторинг аномалий).

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

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

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

1. Архангельский, А. Я. 100 компонентов общего назначения библиотеки Delphi 5. Москва : Бином, 1999. 266 с.
2. Архангельский, А. Я. Delphi 6. Справочное пособие. Москва : Бином, 2001. 1024 с.
3. Архангельский, А. Я. Программирование в Delphi 6. Москва : Бином, 2001. 564 с.
4. Архангельский, А. Я. Язык SQL в Delphi 5. Москва : Бином, 2000. 205 с.
5. Базы данных: модели, разработка, реализация / Карпова Т. Санкт-Петербург : Питер, 2001. 304 с.
6. Буч, Г. Объектно-ориентированное проектирование с примерами применения. Москва, 1992. 654 с.
7. Волков, В. Ф. Экономика предприятия. Москва : Вита-Пресс, 1998. 380 с.
8. Галатенко, В. Информационная безопасность // Открытые системы. 1996. № 1-4.
9. Глушаков, С. В., Ломотько, Д. В. Базы данных. Харьков : Фолио, 2002. 504 с.
10. Гофман, В. Э., Хомоненко, А. Д. Delphi 6. Санкт-Петербург, 2001. 1145 с.
11. Конноли, Т., Бегг, К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. Москва : Вильямс, 2000. 1111 с.
12. Культин, Н. Б. Delphi 7: Программирование на OBJECT PASCAL. Москва : Бином, 2003. 535 с.
13. Маклаков, С. В. BPwin и ERwin. CASE-средства разработки информационных систем. Москва : Диалог-Мифи, 2001. 304 с.
14. Фатрелл, Р., Шафер, Д., Шафер, Л. Управление программными проектами: достижение оптимального качества при минимуме затрат. Москва : Вильямс, 2003. 1128 с.
15. СУБД: что это, виды, структура, функции — где и как используются системы управления базами данных, примеры. Яндекс Практикум. URL: https://practicum.yandex.ru/blog/chto-takoe-subd/ (дата обращения: 20.10.2025).
16. Что такое СУБД? Наиболее популярные СУБД. RU-CENTER помощь. URL: https://www.nic.ru/help/chto-takoe-subd-naibolee-populyarnye-subd_15370.html (дата обращения: 20.10.2025).
17. Сетевая модель данных — логическая модель данных, являющаяся расширением иерархического подхода. Руниверсалис. URL: https://runiversalis.com/doc/setevaja-model-dannyh (дата обращения: 20.10.2025).
18. Графовая база данных — разновидность баз данных с реализацией сетевой модели в виде графа и его обобщений. Руниверсалис. URL: https://runiversalis.com/doc/grafovaja-baza-dannyh (дата обращения: 20.10.2025).
19. Информационная безопасность баз данных. SearchInform. URL: https://searchinform.ru/blog/informatsionnaya-bezopasnost-baz-dannykh/ (дата обращения: 20.10.2025).
20. СУБД: что это и зачем нужно простыми словами. GoIT. URL: https://goit.global/ru/blog/chto-takoe-subd/ (дата обращения: 20.10.2025).
21. 3.1. Иерархическая модель данных. Intuit.ru. URL: http://www.intuit.ru/studies/courses/60/60/lecture/2099?page=1 (дата обращения: 20.10.2025).
22. СУБД — что это: Системы Управления Базами Данных. Skillfactory media. URL: https://skillfactory.ru/blog/chto-takoe-subd (дата обращения: 20.10.2025).
23. Что такое СУБД – подробно о системах управления базами данных, их типах и назначении. Рег.ру. URL: https://www.reg.ru/blog/chto-takoe-subd/ (дата обращения: 20.10.2025).
24. Модели данных в СУБД. AppMaster. URL: https://appmaster.io/blog/data-models-in-dbms (дата обращения: 20.10.2025).
25. 1. Классификация моделей данных. Главная страница. URL: http://www.intuit.ru/studies/courses/60/60/lecture/2099?page=2 (дата обращения: 20.10.2025).
26. Реляционные СУБД: история появления, эволюция и перспективы. Habr. URL: https://habr.com/ru/companies/quadcode/articles/587974/ (дата обращения: 20.10.2025).
27. История развития систем управления базами данных. Генерим! URL: http://generim.ru/articles/programmirovanie/istoriya-razvitiya-subd.html (дата обращения: 20.10.2025).
28. Иерархическая СУБД. TAdviser. URL: https://www.tadviser.ru/index.php/%D0%A1%D1%82%D0%B0%D1%82%D1%8C%D1%8F:%D0%98%D0%B5%D1%80%D0%B0%D1%80%D1%85%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F_%D0%A1%D0%A3%D0%91%D0%94 (дата обращения: 20.10.2025).
29. Графовые базы данных. Сайт Лыткина Игоря Владиславовича. URL: https://ilytkin.ru/graph-db/ (дата обращения: 20.10.2025).
30. Этапы развития СУБД. Помощь студентам. URL: https://pomoschstudentam.ru/etapy-razvitiya-subd/ (дата обращения: 20.10.2025).
31. Базы данных. DBS. URL: https://dbs.com.ru/dbmodel/netmodel.html (дата обращения: 20.10.2025).
32. Объектно-ориентированная модель базы данных. E-college.ru. URL: http://www.e-college.ru/xbooks/xbook020/chap06/ch06_3.html (дата обращения: 20.10.2025).
33. 6.3. Объектно-ориентированные СУБД. Intuit.ru. URL: http://www.intuit.ru/studies/courses/2193/22/lecture/620?page=7 (дата обращения: 20.10.2025).
34. Классификация систем управления базами данных. Skyeng. URL: https://skyeng.ru/articles/klassifikatsiya-sistem-upravleniya-bazami-dannyh/ (дата обращения: 20.10.2025).
35. СУБД NoSQL — хранилище «ключ-значение». OTUS. URL: https://otus.ru/journal/subd-nosql-hranilishche-klyuch-znachenie/ (дата обращения: 20.10.2025).
36. СЕТЕВАЯ МОДЕЛЬ БАЗ ДАННЫХ. Студенческий научный форум. URL: https://scienceforum.ru/2016/article/2016024194 (дата обращения: 20.10.2025).
37. 4.3. Реляционная модель данных. CITForum.ru. URL: http://citforum.ru/database/osnovy_bd/4.shtml (дата обращения: 20.10.2025).
38. Базы данных. DB.CS.MSU.SU. URL: http://db.cs.msu.su/old_pages/db_lections/lect2.htm (дата обращения: 20.10.2025).
39. История развития баз данных. Studfile.net. URL: https://studfile.net/preview/440536/page:3/ (дата обращения: 20.10.2025).
40. Иерархические БД: описание и ключевые характеристики. Otus. URL: https://otus.ru/journal/ierarhicheskie-bd/ (дата обращения: 20.10.2025).
41. Что такое графовая база данных? IBM. URL: https://www.ibm.com/ru-ru/topics/graph-databases (дата обращения: 20.10.20225).
42. Безопасность в базах данных. Habr. URL: https://habr.com/ru/companies/otus/articles/732598/ (дата обращения: 20.10.2025).
43. 3.6. Объектно-ориентированная модель. Docviewer.yandex.ru. URL: https://docviewer.yandex.ru/view/0/%D0%91%D0%BB%D0%BE%D0%BA%20%E2%84%96%202%20%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8%20%D0%B8%20%D1%82%D0%B8%D0%BF%D1%8B%20%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85.doc?page=9&*=n65f42%2F6j0jWwJ0K00fO%2Bf2hD0x7Ij1ycHB1cnRvcj0iaHR0cHM6%2F%2Fdocviewer.yandex.ru%2F&lang=ru (дата обращения: 20.10.2025).
44. Защита баз данных. ЕВРААС. URL: https://evraas.ru/zashchita-baz-dannyh/ (дата обращения: 20.10.2025).
45. Key-value базы данных. SQL Academy. URL: https://sql-academy.org/ru/lessons/key-value-databases (дата обращения: 20.10.2025).
46. Субд Ключ-Значение (Key-Value). NoSQL-databases.org. URL: http://nosql-databases.org/key-value/ (дата обращения: 20.10.2025).
47. База данных «ключ-значение». OTUS. URL: https://otus.ru/journal/baza-dannyh-klyuch-znachenie/ (дата обращения: 20.10.2025).
48. Графовая база данных — Что это такое, советы и примеры. Pro DGTL. URL: https://prodgtl.ru/graph-database/ (дата обращения: 20.10.2025).
49. Ключ к данным: разгадываем секреты NoSQL с БД «Ключ-Значение» БД «Ключ-значение» — это, пожалуй, самый.. 2025. ВКонтакте. URL: https://vk.com/@bigdata_ot_a_do_ya-klyuch-k-dannym-razgadyvaem-sekrety-nosql-s-bd-klyuch-znachenie (дата обращения: 20.10.2025).
50. Защита ПО на уровне СУБД. Информационная безопасность систем управления базами данных. SearchInform. URL: https://searchinform.ru/blog/zashhita-po-na-urovne-subd/ (дата обращения: 20.10.2025).
51. Защита данных в СУБД: современные методы шифрования. itWeek. URL: https://itweek.ru/security/article/detail.php?ID=258440 (дата обращения: 20.10.2025).
52. Типы угроз для базы данных. Habr. URL: https://habr.com/ru/companies/selectel/articles/556942/ (дата обращения: 20.10.2025).
53. Аудит безопасности в СУБД. SearchInform. URL: https://searchinform.ru/blog/audit-bezopasnosti-v-subd/ (дата обращения: 20.10.2025).
54. SQL-инъекция: что это такое, как ее обнаружить и предотвратить. Солар. URL: https://solar-security.ru/analytics/articles/sql-inektsiya-chto-eto-takoe-kak-ee-obnaruzhit-i-predotvratit/ (дата обращения: 20.10.2025).
55. ФСТЭК утвердила Требования по безопасности информации к NGFW и СУБД. Fstec.ru. URL: https://fstec.ru/normotvorcheskaya/akty/939-fstek-utverdila-trebovaniya-po-bezopasnosti-informatsii-k-ngfw-i-subd (дата обращения: 20.10.2025).
56. “Проткни меня, если сможешь” — как атакуют вебсайты и базы данных SQL инъекциями. «Гладиаторы ИБ». URL: https://cyber-gladiators.ru/articles/sql-injekcii-kak-atakujut-vebsajty-i-bazy-dannyh/ (дата обращения: 20.10.2025).
57. Cheat sheet: предотвращение SQL-инъекций. CoreWin. URL: https://corewin.ru/blogs/cheat-sheet-predotvrashhenie-sql-inekcij (дата обращения: 20.10.2025).
58. SQL-инъекция и как ее предотвратить. Лаборатория Касперского. URL: https://www.kaspersky.ru/resource-center/definitions/sql-injection (дата обращения: 20.10.2025).
59. СУБД: что такое системы управления базами данных, виды, где используются, для чего нужны. DIS Group. URL: https://disgroup.ru/blog/chto-takoe-subd-vidy-funktsii-naznachenie/ (дата обращения: 20.10.2025).
60. ОБЗОР И АНАЛИЗ МЕТОДОВ ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ В РАЗЛИЧНЫХ СУБД. Текст научной статьи по специальности «Компьютерные и информационные науки. КиберЛенинка. URL: https://cyberleninka.ru/article/n/obzor-i-analiz-metodov-obespecheniya-bezopasnosti-v-razlichnyh-subd (дата обращения: 20.10.2025).
61. 23.7.6. Разграничение доступа к данным. Intuit.ru. URL: http://www.intuit.ru/studies/courses/2193/22/lecture/620?page=8 (дата обращения: 20.10.2025).
62. SQL Injection: основы, угрозы и современные подходы к защите. Infosecurity.ru. URL: https://www.infosecurity.ru/lib/sql_injection_basics/ (дата обращения: 20.10.2025).
63. Способы защиты баз данных. Группа компаний Гарда Технологии. URL: https://gardatech.ru/company/press-center/articles/sposoby-zashchity-baz-dannykh/ (дата обращения: 20.10.2025).
64. Защита баз данных СУБД. Azone IT. URL: https://azone-it.ru/blog/zashchita-baz-dannyh/ (дата обращения: 20.10.2025).
65. «Требования по безопасности информации к системам управления базами данных (выписка)» (утв. приказом ФСТЭК России от 14.04.2023 N 64). КонсультантПлюс. URL: https://www.consultant.ru/document/cons_doc_LAW_444908/ (дата обращения: 20.10.2025).
66. Приказ ФСТЭК России №64 от 14.04.2023 «Об утверждении Требований по безопасности информации к СУБД». Хаб Злонова. URL: https://zlonov.ru/docs/2023/04/prikaz-fstek-rossii-no64-ot-14-04-2023-ob-utverzhdenii-trebovanij-po-bezopasnosti-informacii-k-subd/ (дата обращения: 20.10.2025).
67. Прозрачное шифрование данных (TDE) — SQL Server. Microsoft Learn. URL: https://learn.microsoft.com/ru-ru/sql/relational-databases/security/transparent-data-encryption-tde?view=sql-server-ver16 (дата обращения: 20.10.2025).
68. Аудит сервера баз данных. SearchInform. URL: https://searchinform.ru/blog/audit-servera-baz-dannyh/ (дата обращения: 20.10.2025).
69. [таблица] Сертифицированные системы управления базами данных 2024. Zlonov.ru. URL: https://zlonov.ru/docs/2024/09/tablica-sertificirovannye-sistemy-upravleniya-bazami-dannyh-2024/ (дата обращения: 20.10.2025).
70. ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ. КонсультантПлюс. URL: https://www.consultant.ru/document/cons_doc_LAW_28353/ (дата обращения: 20.10.2025).
71. Технология больших данных для защиты СУБД. ITSec.Ru — Журнал «Information Security». URL: https://www.itsec.ru/articles2/bigdata/tehnologiya-bolshih-dannyh-dlya-zashity-subd (дата обращения: 20.10.2025).
72. Лекция 7. Вредоносные атаки на реляционные СУБД. MSUniversity. URL: https://www.msu.ru/projects/db/lectures/lecture7.html (дата обращения: 20.10.2025).
73. Защита базы данных – перечень уязвимостей, методы и примеры эффективной защиты. Солар. URL: https://solar-security.ru/analytics/articles/zashchita-bazy-dannykh-perechen-uyazvimostey-metody-i-primery-effektivnoy-zashchity/ (дата обращения: 20.10.2025).
74. Методы защиты данных встроенными средствами СУБД. Сайт Сергея Панасенко. URL: https://sergpanasenko.ru/metody-zashhity-dannyh-vstroennymi-sredstvami-subd/ (дата обращения: 20.10.2025).
75. Подсистема аудита SQL Server (Database Engine). Microsoft Learn. URL: https://learn.microsoft.com/ru-ru/sql/relational-databases/security/sql-server-audit-database-engine?view=sql-server-ver16 (дата обращения: 20.10.2025).
76. Аудит баз данных Oracle, MS SQL Server и PostgreSQL: цена. DB Serv. URL: https://dbserv.ru/audit-bd/ (дата обращения: 20.10.2025).
77. Несанкционированный доступ (НСД): что это, риски и способы защиты. Spectrumdata. URL: https://spectrumdata.ru/wiki/nesankcionirovannyj-dostup/ (дата обращения: 20.10.2025).
78. Несанкционированный доступ. Кибрарий – библиотека знаний по кибербезопасности. Всё самое важное и полезное о том, как защитить себя в цифровом мире. Сбербанк. URL: https://www.sberbank.ru/glossary/nesankcionirovannyj-dostup (дата обращения: 20.10.2025).
79. Управление доступом к базе данных. SearchInform. URL: https://searchinform.ru/blog/upravlenie-dostupom-k-baze-dannykh/ (дата обращения: 20.10.2025).
80. Несанкционированный доступ: что это такое, способы реализации, риски. Солар. URL: https://solar-security.ru/analytics/articles/nesanktsionirovannyy-dostup/ (дата обращения: 20.10.2025).
81. Виды угроз информационной безопасности. Академия Selectel. URL: https://selectel.ru/blog/information-security-threats/ (дата обращения: 20.10.2025).
82. Основные аспекты обеспечения безопасности СУБД. Текст научной статьи по специальности «Компьютерные и информационные науки. КиберЛенинка. URL: https://cyberleninka.ru/article/n/osnovnye-aspekty-obespecheniya-bezopasnosti-subd (дата обращения: 20.10.2025).
83. Data Security Standards (PCI-DSS). PCI Security Standards Council. URL: https://www.pcisecuritystandards.org/pci_dss/ (дата обращения: 20.10.2025).
84. Payment Card Data Security Standards (PCI DSS). PCI Security Standards Council. URL: https://www.pcisecuritystandards.org/pci_dss_resources/ (дата обращения: 20.10.2025).
85. Безопасность данных в облаке: современные методы защиты. DB Serv. URL: https://dbserv.ru/security-cloud-data/ (дата обращения: 20.10.2025).
86. The 12 PCI DSS Requirements Explained. Exabeam. URL: https://www.exabeam.com/information-security/pci-dss-requirements/ (дата обращения: 20.10.2025).
87. Что такое безопасность облачных данных? Microsoft Security. URL: https://www.microsoft.com/ru-ru/security/business/security-baselines/cloud-data-security (дата обращения: 20.10.2025).
88. Безопасность облачных хранилищ: какие бывают риски и как защитить данные. Rusonyx.ru. URL: https://rusonyx.ru/knowledge-base/bezopasnost-oblachnyh-hranilisch-kakie-byvayut-riski-i-kak-zashchitit-dannye (дата обращения: 20.10.2025).
89. What are the 12 Requirements of PCI DSS Compliance? Upguard.com. URL: https://www.upguard.com/blog/pci-dss-compliance-requirements (дата обращения: 20.10.2025).
90. Облачная безопасность: Виды хранилищ, угрозы и методы защиты. Rusonyx.ru. URL: https://rusonyx.ru/knowledge-base/oblachnaya-bezopasnost-vidy-hranilisch-ugrozy-i-metody-zashchity/ (дата обращения: 20.10.2025).
91. Стандарт Безопасности Данных — Индустрии Платежных Карт (PCI). PCI Security Standards Council. URL: https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2_RUS.pdf (дата обращения: 20.10.2025).
92. ISO 27000: как международные стандарты помогают защитить бизнес от информационных угроз. SGS. 2025. URL: https://www.sgs.ru/ru-ru/news/2025/08/iso-27000-how-international-standards-help-protect-businesses-from-information-threats (дата обращения: 20.10.2025).
93. PCI DSS (Payment Card Industry Data Security Standard). Safe-Tech.ru. URL: https://safe-tech.ru/library/pci-dss-payment-card-industry-data-security-standard/ (дата обращения: 20.10.2025).
94. PCI DSS: краткая история, определение, требования, уровни. RTM Group. URL: https://rtmtech.ru/info/articles/pci-dss-kratkaya-istoriya-opredelenie-trebovaniya-urovni/ (дата обращения: 20.10.2025).
95. Что такое ISO 27000 и зачем компаниям нужна информационная безопасность? SGS. 2025. URL: https://www.sgs.ru/ru-ru/news/2025/08/what-is-iso-27000-and-why-do-companies-need-information-security (дата обращения: 20.10.2025).
96. Стандарты серии ISO/IEC 27000 по менеджменту информационной безопасности. БелГИСС. URL: https://belgiss.by/news/standarty-serii-iso-iec-27000-po-menedzhmentu-informatsionnoy-bezopasnosti/ (дата обращения: 20.10.2025).
97. Общие сведения о стандартах серии ISO 27000. InfoSecPortal.ru. URL: http://infosecportal.ru/taxonomy/term/34 (дата обращения: 20.10.2025).
98. Стандарт безопасности PCI DSS: ключевые требования. БПЦ Процессинг. URL: https://bpc-processing.ru/blog/standart-bezopasnosti-pci-dss/ (дата обращения: 20.10.2025).
99. Стандарт pci dss, сертификат, требования и область применения — статьи от компании Miran. ЦОД Миран. URL: https://miran.ru/articles/pci-dss-standart-sertifikat-trebovaniya-i-oblast-primeneniya/ (дата обращения: 20.10.2025).
100. ISO 27001 Информационная безопасность. Сертификация с DQS. URL: https://www.dqs.de/ru/sertifikatsiya/iso-27001/ (дата обращения: 20.10.2025).
101. ISO/IEC 27001 (Системы менеджмента защиты информации). TKB.ru. URL: https://www.tkb.ru/iso-27001.htm (дата обращения: 20.10.2025).
102. Что такое облачная база данных? Типы и преимущества. Объяснение. Astera Software. URL: https://www.asterasoftware.com/ru/blog/cloud-database (дата обращения: 20.10.2025).
103. Система менеджмента информационной безоасности ISO 27001. Cert-group.com. URL: https://www.cert-group.com/services/sertifikaciya-sistem-menedzhmenta-informacionnoj-bezopasnosti-iso-27001/ (дата обращения: 20.10.2025).
104. Международный стандарт ISO 27001: особенности для предприятий и сертификация. Standartkachestva.ru. URL: https://standartkachestva.ru/sertifikatsiya-iso-27001/ (дата обращения: 20.10.2025).
105. Безопасность облачных вычислений. Habr. URL: https://habr.com/ru/company/ucsbonline/articles/775952/ (дата обращения: 20.10.2025).
106. Что такое безопасность облачных вычислений? Keeper Security. URL: https://keepersecurity.com/ru_RU/blog/what-is-cloud-computing-security/ (дата обращения: 20.10.2025).
107. DBaaS: базы данных в облаке. Habr. URL: https://habr.com/ru/company/technoserv/articles/337580/ (дата обращения: 20.10.2025).
108. Система шифрования БД для СУБД Firebird. Сайфер. URL: https://cypher.ru/products/cryptosystem/ (дата обращения: 20.10.2025).