Россия
Россия
Санкт-Петербург, г. Санкт-Петербург и Ленинградская область, Россия
Россия
Россия
Журналы действий пользователей являются одним из ключевых источников информации при расследовании инцидентов информационной безопасности в распределенных и облачных вычислительных системах. В ходе кибератак злоумышленники могут выполнять модификацию или удаление записей журналов действий пользователей с целью усложнения расследования инцидента. Аудит информационной безопасности часто осуществляется сторонними организациями, не имеющими легитимного доступа к пользовательским данным, из-за чего проверка целостности журналов действий пользователей без раскрытия данных журналов может быть невозможна, в то время как раскрытие данных журналов может нести юридические риски для поставщика облачных сервисов или организации-потребителя услуг. Объектом исследования являются журналы действий пользователей, размещенные в инфраструктуре облачных сервисов. Предмет исследования – методы и средства, обеспечивающие проверку целостности журналов действий пользователей без раскрытия содержимого журналов. Представлен метод на основе технологии блокчейн, позволяющий выполнять проверку целостности журналов действий пользователей без доступа к информации, хранящейся в журналах. Предложен метод организации хранения файлов журналов для внедрения разработанного метода. Описаны основные компоненты предлагаемого метода и процедуры взаимодействия между ними, включая процедуру инициализации нового блока, процедуру записи полезной нагрузки, процедуру записи конца блока. Описаны процедуры, выполняемые сторонним аудитором при выполнении проверок целостности журналов действий пользователей. Предусмотрена возможность выборочной проверки целостности на основе опубликованных хеш-сумм и структур данных типа «хеш-дерево», без необходимости доступа к данным, хранящимся в журналах. Разработанный метод может быть интегрирован в существующие распределенные и облачные вычислительные системы и может применяться как при расследовании инцидентов информационной безопасности, так и в ходе плановых проверок.
облачный сервис, распределенные вычисления, блокчейн, проверка целостности, расследование инцидентов информационной безопасности
Введение
Актуальность исследований обоснована растущим спросом на услуги поставщиков облачных сервисов, что сопровождается риском утечки и/или несанкционированного доступа к конфиденциальной информации. Согласно исследованию компании ИКС-ХОЛДИНГ, объем российского рынка облачных хранилищ в 2024 г. вырос до 165,6 млрд руб., что соответствует росту на 36,3 % относительно показателей 2023 г. [1]. Согласно данным компании Red Canary [2], в 2024 г. количество атак на поставщиков услуг облачных сервисов по всему миру возросло в 16 раз.
Одним из важнейших инструментов в процессе расследования инцидентов информационной безопасности (ИБ) в облачных сервисах являются журналы действий пользователей. В процессе атаки злоумышленники могут удалять журналы либо вносить в них недостоверные сведения, усложняя процесс расследования инцидентов ИБ. Таким образом, актуальной задачей является разработка метода проверки целостности журналов действий пользователей с целью обеспечения достоверности результатов, получаемых в ходе анализа журналов. Проверка целостности журналов действий пользователей может выполняться не только в процессе расследования инцидентов ИБ, но и в ходе аудита ИБ. Поскольку аудит может выполняться сторонней организацией, важной задачей является обеспечение возможности проверки целостности журналов без раскрытия содержимого журналов и данных, над которыми выполнялись операции. Объектом исследования являются журналы действий пользователей, хранящиеся в облачных сервисах, предметом исследования являются методы и средства проверки их целостности. В статье предложен метод, основанный на технологии блокчейн, позволяющий обеспечивать возможность проверки целостности журналов действий пользователей без раскрытия их содержимого. Описан способ организации хранения файлов журналов в облачных сервисах для поддержки возможности интеграции предложенного метода. Предложенный метод позволяет обеспечить гарантию достоверности результатов, получаемых при анализе журналов действий пользователей и, таким образом, востребован в области расследования инцидентов ИБ.
Структура файла журнала
Пусть G1 и G2 – циклическая мультипликативная группа большого простого порядка p. Пусть u, g – порождающие элементы группы G1. Пусть 
. Каждый блок состоит из
Каждая запись журнала
в блоке, идентификатор пользователя 
, соответствующий некоторому uk, метка времени ti,j, полезная нагрузка 
, содержащая сведения о выполненной операции.
Обозначим результат конкатенации полей 
, 
, 
как 
:
Служебные записи журнала (первая и последняя в блоке) имеют структуру, аналогичную другим записям, однако не содержат сведений о действиях пользователя и в качестве полезной нагрузки содержат строки BEGIN и END соответственно. В качестве транзакций в рамках настоящего исследования используются метки записей журнала. Метки записей, хранимые в одном блоке файла журнала B, должны быть записаны в виде транзакций в один блок C в блокчейне. При этом блок C не должен содержать другие транзакции. В рамках данного исследования не рассматриваются детали реализации хранения данных блокчейна на отдельных узлах сети, а также особенности конкретных технологий, используемых для реализации блокчейн-системы. Поставщик услуг предоставляет потребителю (организации) [3] доступ к вычислительным ресурсам. Потребитель предоставляет доступ к вычислительным ресурсам пользователям. Каждому пользователю соответствует пара «открытый/закрытый ключ». Пользователи взаимодействуют с облачными сервисами, выполняя операции в рамках предоставленных им прав. Пользователи выполняют действия над распределенно расположенными данными и программами, что приводит к созданию записей журнала действий. Записи журнала сохраняются в хранилище (далее – «диск»), управляемом поставщиком облачных сервисов. Информация для проверки целостности данных журналов публикуется в блокчейн и на сетевой ресурс, принадлежащий потребителю и управляемый потребителем (далее – «внутренний сетевой ресурс»). У поставщика облачных сервисов отсутствует возможность удалять или модифицировать существующие данные на внутреннем сетевом ресурсе, но присутствует возможность записывать новые данные. При выполнении проверки целостности данных журналов аудитор получает доступ к внутреннему сетевому ресурсу, блокчейну, списку пользователей и их открытым ключам, но не получает доступ к содержимому записей журналов.
Инициализация нового блока в файле журнала
Процесс инициализации нового блока в файле журнала представлен на рис. 1.
Рис. 1. Процесс инициализации нового блока в файле журнала
Fig. 1. The process of initializing of a new block in the log file
Выполнение операции пользователем Uk над данными в облачном сервисе приводит к созданию информации о выполненной операции, которая будет записана в файл журнала действий пользователей в качестве полезной нагрузки
(1)
Пользователь Uk проверяет подпись 
и в случае успешной проверки находит значение метки:
(2)
Метка 
записывается в блокчейн и отправляется поставщику облачных сервисов. После получения метки поставщик облачных сервисов создает и записывает на диск 
.
Запись конца блока
Процесс записи конца блока представлен на рис. 3. При достижении количества записей
Рис. 3. Процесс записи конца блока
Fig. 3. The process of end of the block recording
Проверка целостности журналов
Процесс проверки целостности журналов представлен на рис. 4–6.
Рис. 4. Процесс проверки целостности журналов – этап запроса значений меток записей
Fig. 4. Logs integrity checking process – the stage of requesting the values of entries tags
Рис. 5. Процесс проверки целостности журналов – этап проверки меток служебных записей
Fig. 5. Logs integrity checking process – the stage of service entries verification
Рис. 6. Процесс проверки целостности журналов – этап реконструкции и проверки корня дерева Меркла
Fig. 6. Logs integrity checking process – the stage of reconstruction and verification of the Merkle tree root
Для выполнения проверки целостности журналов аудитор случайным образом выбирает набор блоков
(3)
(4)
В выражениях (3), (4) f – некоторая функция сжатия. Поставщик облачных сервисов находит подпись
Получив сообщение m, аудитор проверяет подпись и в случае успешной проверки восстанавливает из φ значения меток записей. Для каждого блока
1. Аудитор получает служебные записи и
2. Для записи .
3. Аудитор проверяет выполнение условия
4. Для записи
5. Аудитор проверяет выполнение условия
Если существует 
такой, что не выполняется хотя бы одно из условий (5), (6), проверка целостности завершается с ошибкой.
В случае успешной проверки согласно условиям (5), (6) для каждого аудитор запрашивает из блокчейна значение корня дерева Меркла Rc [4–6]. Далее для каждого Bc аудитор выполняет следующие действия:
1. Используя значения
2. Аудитор проверяет выполнение условия для каждого :
. (7)
Если существует такой, что не выполняется условие (7), проверка завершается с ошибкой.
Заключение
Предложен метод проверки целостности журналов действий пользователей облачных сервисов на основе технологии блокчейн, позволяющий выполнять проверку целостности без раскрытия данных журналов. Описан способ организации хранения файлов журналов в облачных сервисах для поддержки возможности интеграции предложенного метода. Предложенный метод позволяет обеспечить гарантию достоверности результатов, получаемых при анализе журналов действий пользователей, и, таким образом, востребован в области расследования инцидентов информационной безопасности.
1. 2024 Threat Detection Report // Red Canary. URL: https://resource.redcanary.com/rs/003-YRU-314/images/2024ThreatDetectionReport_RedCanary.pdf (дата обращения: 06.02.2025).
2. Российский рынок облачных инфраструктурных сервисов 2024 // АО «ИКС-ХОЛДИНГ». URL: https://survey.iksconsulting.ru/page59801703.html (дата обращения: 06.02.2025).
3. ГОСТ Р ИСО 9127-94. Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов. М.: Госстандарт России, 1995. 8 с.
4. Szydlo M. Merkle Tree Traversal in Log Space and Time // International Conference on the Theory and Applications of Cryptographic Techniques. Berlin, Heidelberg: Springer Berlin Heidelberg, 2004. P. 541–554. DOI:https://doi.org/10.1007/978-3-540-24676-3_32.
5. Becker G. Merkle signature schemes, merkle trees and their cryptanalysis // Ruhr-University Bochum, Tech. Rep. 2008. V. 12. P. 19.
6. Li H., Lu R., Zhou L., Yang B., Shen X. An efficient merkle-tree-based authentication scheme for smart grid // IEEE Systems Journal. 2013. V. 8. N. 2. P. 655–663. DOI:https://doi.org/10.1109/JSYST.2013.2271537.
