Russian Federation
Russian Federation
Saint Petersburg, St. Petersburg, Russian Federation
Russian Federation
Russian Federation
User activity logs are one of the key sources of information when investigating information security incidents in distributed and cloud computing systems. During a cyberattack, attackers can modify or delete user activity log entries in order to complicate the investigation of the incident. Information security audits are often carried out by third-party organizations that do not have legitimate access to user data, which may make it impossible to verify the integrity of user activity logs without disclosing log data, while disclosing log data may carry legal risks for a cloud service provider or a service consumer organization. The object of the study is user activity logs hosted in the cloud services infrastructure. The subject of the research is methods and tools that ensure the integrity of user activity logs without disclosing the contents of the logs. A method based on blockchain technology is presented that makes it possible to verify the integrity of user activity logs without access to information stored in the logs. A method of organizing the storage of log files for the implementation of the developed method is proposed. The main components of the proposed method and the procedures for interaction between them are described, including the procedure for initializing a new block, the procedure for recording the payload, and the procedure for recording the end of the block. The procedures performed by a third-party auditor when performing integrity checks of user activity logs are described. It is possible to selectively verify integrity based on published hash sums and hash tree data structures, without the need to access data stored in logs. The developed method can be integrated into existing distributed and cloud computing systems and can be used both in the investigation of information security incidents and during routine inspections.
cloud services, distributed computing, blockchain, integrity verification, investigation of information security incidents
Введение
Актуальность исследований обоснована растущим спросом на услуги поставщиков облачных сервисов, что сопровождается риском утечки и/или несанкционированного доступа к конфиденциальной информации. Согласно исследованию компании ИКС-ХОЛДИНГ, объем российского рынка облачных хранилищ в 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. Available at: https://resource.redcanary.com/rs/003-YRU-314/images/2024ThreatDetectionReport_RedCanary.pdf (accessed: 06.02.2025).
2. Rossiiskii rynok oblachnykh infrastrukturnykh servisov 2024 [The Russian market of cloud infrastructure services 2024]. AO «IKS-KhOLDING». Available at: https://survey.iksconsulting.ru/page59801703.html (accessed: 06.02.2025).
3. GOST R ISO 9127-94. Sistemy obrabotki informatsii. Dokumentatsiia pol'zovatelia i informatsiia na upakovke dlia potrebitel'skikh programmnykh paketov [ISS R ISO 9127-94. Information processing systems. User documentation and packaging information for consumer software packages]. Moscow, Gosstandart Rossii Publ., 1995. 8 p.
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. Pp. 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, vol. 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, vol. 8, no. 2, pp. 655-663. DOI:https://doi.org/10.1109/JSYST.2013.2271537.
