ВведениеАктуальность исследований обоснована растущим спросом на услуги поставщиков облачных сервисов, что сопровождается риском утечки и/или несанкционированного доступа к конфиденциальной информации. Согласно исследованию компании ИКС-ХОЛДИНГ, объем российского рынка облачных хранилищ в 2024 г. вырос до 165,6 млрд руб., что соответствует росту на 36,3 % относительно показателей 2023 г. [1]. Согласно данным компании Red Canary [2], в 2024 г. количество атак на поставщиков услуг облачных сервисов по всему миру возросло в 16 раз. Одним из важнейших инструментов в процессе расследования инцидентов информационной безопасности (ИБ) в облачных сервисах являются журналы действий пользователей. В процессе атаки злоумышленники могут удалять журналы либо вносить в них недостоверные сведения, усложняя процесс расследования инцидентов ИБ. Таким образом, актуальной задачей является разработка метода проверки целостности журналов действий пользователей с целью обеспечения достоверности результатов, получаемых в ходе анализа журналов. Проверка целостности журналов действий пользователей может выполняться не только в процессе расследования инцидентов ИБ, но и в ходе аудита ИБ. Поскольку аудит может выполняться сторонней организацией, важной задачей является обеспечение возможности проверки целостности журналов без раскрытия содержимого журналов и данных, над которыми выполнялись операции.  Объектом исследования являются журналы действий пользователей, хранящиеся в облачных сервисах, предметом исследования являются методы и средства проверки их целостности. В статье предложен метод, основанный на технологии блокчейн, позволяющий обеспечивать возможность проверки целостности журналов действий пользователей без раскрытия их содержимого. Описан способ организации хранения файлов журналов в облачных сервисах для поддержки возможности интеграции предложенного метода. Предложенный метод позволяет обеспечить гарантию достоверности результатов, получаемых при анализе журналов действий пользователей и, таким образом, востребован в области расследования инцидентов ИБ. Структура файла журналаПусть G1 и G2 – циклическая мультипликативная группа большого простого порядка p. Пусть u, g – порождающие элементы группы G1. Пусть H : {0, 1}*→ G1  – криптографическая хеш-функция. Обозначим множество, состоящее из Umax пользователей, как U = {U1, U2, …, U(umax)}. Каждому пользователю Uk (где 1 ≤  k  ≤  umax ) соответствует уникальный идентификатор пользователя uk. Каждый пользователь Uk генерирует закрытый ключ suk∈ Zp  и открытый ключ puk= gsuk . Поставщик облачных сервисов генерирует закрытый ключ sc ∈ Zp  и открытый ключ pc = gsc . Каждый файл журнала F состоит из bmax  последовательных блоков, т. е.  . Каждый блок состоит из emax  записей ei, j , где i – номер блока, j – порядковый номер записи, т. е.Bi = ei, 1, ei, 2, …, ei, emax.  Каждая запись журнала ei,j(1 ≤  j ≤ emax)  состоит из следующих элементов: идентификатор блока   – порядковый номер блока в файле журнала, идентификатор записи ξi, j  – порядковый номер записив блоке, идентификатор пользователя ηi,j , соответствующий некоторому uk, метка времени ti,j, полезная нагрузка pi,j , содержащая сведения о выполненной операции.Обозначим результат конкатенации полей βi , ξi,j , uk, T , Pi,j  записи ei,j как μi,j :  Служебные записи журнала (первая и последняя в блоке) имеют структуру, аналогичную другим записям, однако не содержат сведений о действиях пользователя и в качестве полезной нагрузки содержат строки BEGIN и END соответственно. В качестве транзакций в рамках настоящего исследования используются метки записей журнала. Метки записей, хранимые в одном блоке файла журнала B, должны быть записаны в виде транзакций в один блок C в блокчейне. При этом блок C не должен содержать другие транзакции. В рамках данного исследования не рассматриваются детали реализации хранения данных блокчейна на отдельных узлах сети, а также особенности конкретных технологий, используемых для реализации блокчейн-системы.  Поставщик услуг предоставляет потребителю (организации) [3] доступ к вычислительным ресурсам. Потребитель предоставляет доступ к вычислительным ресурсам пользователям. Каждому пользователю соответствует пара «открытый/закрытый ключ». Пользователи взаимодействуют с облачными сервисами, выполняя операции в рамках предоставленных им прав. Пользователи выполняют действия над распределенно расположенными данными и программами, что приводит к созданию записей журнала действий. Записи журнала сохраняются в хранилище (далее – «диск»), управляемом поставщиком облачных сервисов. Информация для проверки целостности данных журналов публикуется в блокчейн и на сетевой ресурс, принадлежащий потребителю и управляемый потребителем (далее – «внутренний сетевой ресурс»). У поставщика облачных сервисов отсутствует возможность удалять или модифицировать существующие данные на внутреннем сетевом ресурсе, но присутствует возможность записывать новые данные. При выполнении проверки целостности данных журналов аудитор получает доступ к внутреннему сетевому ресурсу, блокчейну, списку пользователей и их открытым ключам, но не получает доступ к содержимому записей журналов. Инициализация нового блока в файле журналаПроцесс инициализации нового блока в файле журнала представлен на рис. 1.Рис. 1. Процесс инициализации нового блока в файле журнала Fig. 1. The process of initializing of a new block in the log file Выполнение операции пользователем Uk над данными в облачном сервисе приводит к созданию информации о выполненной операции, которая будет записана в файл журнала действий пользователей в качестве полезной нагрузки pi, j , где j – порядковый номер записи в текущем блоке. Таким образом, μi,j= (i || j || tj || uk || pi, j) , где tj – время создания μi,j.  Поставщик облачных сервисов находит подпись λμi, j  и отправляет пользователю Uk сообщение mj:                           (1)Пользователь Uk проверяет подпись и в случае успешной проверки находит значение метки:                        (2)Метка σi,j  записывается в блокчейн и отправляется поставщику облачных сервисов. После получения метки поставщик облачных сервисов создает и записывает на диск ei,j .  Запись конца блокаПроцесс записи конца блока представлен на рис. 3. При достижении количества записей e max – 1   поставщик облачных сервисов должен записать служебную запись e i, e max   и перейти к созданию следующего блока. Метку служебной записи формирует пользователь, чьи действия привели к созданию записи e i, e max –1  . Поставщик облачных сервисов формирует μ i, e max = (i | e max | u k ||  t l || END)  . Аналогично записи e i,1   служебная запись e i, e max   не содержит сведений о выполненной операции. Аналогично выражениям (1), (2) выполняется нахождение значений m e max   и σ i, e max  . Метка σ i, e max   записывается в блокчейн. После получения значения метки поставщик облачных сервисов записывает e i, e max   на диск. Служебная запись e i, e max   публикуется на внутренний сетевой ресурс.   Рис. 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  Для выполнения проверки целостности журналов аудитор случайным образом выбирает набор блоков Bcheck ∈ F . Для каждого блока Bc∈ Bcheck  аудитор запрашивает ранее опубликованные служебные записи ec,1  и ec,emax  и отправляет поставщику облачных сервисов список блоков  Bcheck . Поставщик облачных сервисов находит для каждого блока Bc ∈ Bcheck :                         (3)                            (4)В выражениях (3), (4) f – некоторая функция сжатия. Поставщик облачных сервисов находит подпись  λ J  для значения φ и отправляет аудитору сообщение m = φ || λ(φ) .Получив сообщение m, аудитор проверяет подпись и в случае успешной проверки восстанавливает из φ значения меток записей. Для каждого блока Bc ∈ Bcheck  аудитор выполняет следующие действия:1. Аудитор получает служебные записи  и ec,emax . Аудитор находит значения μc,1  и μc,emax  посредством конкатенации полей ec,1   и ec,emax  соответственно.2. Для записи ec,1   аудитор получает идентификатор пользователя uf = ηс,1  и запрашивает значение закрытого ключа suf  пользователя uf .3. Аудитор проверяет выполнение условияH(μс,1)║0 =? σс,1suf .                       (5)4. Для записи ec,emax  аудитор получает идентификатор пользователя um = ηс,emax  и запрашивает значение закрытого ключа sum  пользователя um .5. Аудитор проверяет выполнение условияH(μс,emax)║σс,emax-1 =? σс,emaxsum .                (6)Если существует   такой, что не выполняется хотя бы одно из условий (5), (6), проверка целостности завершается с ошибкой. В случае успешной проверки согласно условиям (5), (6) для каждого   аудитор запрашивает из блокчейна значение корня дерева Меркла Rc [4–6]. Далее для каждого Bc аудитор выполняет следующие действия:1. Используя значения σс,1, …, σс,emax-1 , аудитор находит значение корня дерева Меркла: 2. Аудитор проверяет выполнение условия для каждого  : .                                 (7)Если существует   такой, что не выполняется условие (7), проверка завершается с ошибкой.  ЗаключениеПредложен метод проверки целостности журналов действий пользователей облачных сервисов на основе технологии блокчейн, позволяющий выполнять проверку целостности без раскрытия данных журналов. Описан способ организации хранения файлов журналов в облачных сервисах для поддержки возможности интеграции предложенного метода. Предложенный метод позволяет обеспечить гарантию достоверности результатов, получаемых при анализе журналов действий пользователей, и, таким образом, востребован в области расследования инцидентов информационной безопасности.