МИНОБРНАУКИ РОССИИ Федеральное государственное автономное образовательное учреждение высшего образования «ЮЖНЫЙ ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ» Институт компьютерных технологий и информационной безопасности Структурное подразделение Направление подготовки **09.03.04** — «Программная инженерия» (бакалавриат), профиль **«Методы и средства разработки программного обеспечения»** **ОТЧЁТ** **о прохождении практики** обучающегося **4** курса, группа **КТбо4-9** **Тема:** Разработка мобильного приложения Wallenc — универсального «кошелька» для безопасного хранения данных на небезопасных хранилищах без собственного сервера (Android, Kotlin). Фамилия — **Пытков** Имя — **Роман** Отчество — **Евгеньевич** **Место практики:** ООО НМФ «Нейротех» Вид практики: производственная Тип практики: технологическая (проектно-технологическая) Способ проведения практики: стационарная **Сроки прохождения практики:** **с 09.02.2026 г. по 06.05.2026 г.** *(по приказу ЮФУ № 2191-к от 17.02.2026 г.)* --- **Задание обучающегося на практику согласовано:** | Руководитель практики от Университета | Руководитель практики от профильной организации | | --- | --- | | _______________________ Беликов Александр Николаевич | _______________________ Алексеев Дмитрий Михайлович | *(По приказу: руководитель от ЮФУ — старший преподаватель кафедры системного анализа и телекоммуникаций Беликов А. Н.; от организации — технический директор Алексеев Д. М., ООО НМФ «Нейротех».)* --- ## 1. Задание обучающегося на практику | № | Содержание задания (выполнялось в рамках проекта Wallenc) | | --- | --- | | 1 | **Анализ предметной области.** Требования к хранению чувствительных данных, клиентскому шифрованию и сценариям работы с vault. | | 2 | **Обзор аналогов.** Сравнение решений (secure-folder, менеджеры секретов, zero-knowledge); выводы для концепции Wallenc. | | 3 | **Техническое задание.** Структура ТЗ по ГОСТ 7.32–2017; приоритет ядра хранения и шифрования. | | 4 | **Архитектура.** MVVM + Clean Architecture; структура системы и абстракции хранилищ; задел под удалённые провайдеры. | | 5 | **Проектирование БД.** Служебные сущности Room (метаданные, соответствия, восстановление состояния); без открытого пользовательского контента. | | 6 | **Технологический стек.** Kotlin, Android, Compose, Coroutines/Flow, Hilt, Room, AES на клиенте; модули app / presentation / domain / data. | | 7 | **Доп. исследования (этап 1).** OAuth без своего сервера; ключи и проверка ключа; защита путей/имён; план тестов. | | 8 | **Ядро приложения (этап 2).** Vault, метаданные, шифрование/открытие/закрытие, абстракция хранилищ, защита от гонок при длительных операциях. | | 9 | **Интерфейс (Compose).** Списки vault, диалоги операций, состояние шифрования/открытия, содержимое vault. | | 10 | **Адаптеры хранилищ.** Единый интерфейс vault без серверного backend приложения. | | 11 | **Внешний провайдер.** OAuth Яндекс; слой удалённых vault. | | 12 | **Room.** Таблицы метаданных, ключей, учётных записей; DAO и жизненный цикл приложения. | | 13 | **Доп. (этап 2).** Проект синхронизации без передачи ключей на сервер; ручное UI-тестирование сценариев. | | 14 | **Тестирование.** Unit-тесты криптографии; ручные прогоны экранов. | | 15 | **Отчётность.** Отчёты по этапам и итоговый отчёт с иллюстрациями. | --- ## 2. Инструктаж по охране труда, технике безопасности, пожарной безопасности, правилам внутреннего распорядка *(До начала практики проводится собрание и вводный инструктаж в соответствии с приказом ЮФУ от 14.10.2016 № 1513 «Об обеспечении безопасности жизни и здоровья обучающихся, работников при проведении учебных и производственных практик» — см. приказ № 2191-к.)* | | Инструктаж проведён | Ознакомлен | | --- | --- | --- | | по требованиям охраны труда | ________________________________ «\_\_» \_\_\_\_\_\_\_\_\_ 2026 г. | ________________________________ «\_\_» \_\_\_\_\_\_\_\_\_ 2026 г. | | по технике безопасности | | | | по пожарной безопасности | | | | по правилам внутреннего трудового распорядка | | | --- ## 3. Дневник практики | Дата | Выполненные мероприятия в соответствии с заданием на практику | | --- | --- | | **09.02.2026** | Начало производственной практики по приказу ЮФУ. Участие во вводном инструктаже по требованиям охраны труда, техники безопасности, пожарной безопасности и правилам внутреннего распорядка (в соответствии с приказом ЮФУ от 14.10.2016 № 1513). Ознакомление с целями практики и проектом Wallenc. | | **10.02.2026 — 16.02.2026** | **Анализ предметной области (этап 1):** изучение подходов к хранению чувствительных данных в мобильных приложениях и облачных хранилищах. Формулировка требований: конфиденциальность при хранении и передаче; отсутствие необходимости доверять инфраструктуре хранилища; устойчивость к компрометации удалённого провайдера; разделение логики хранения и криптографической защиты; пользовательские сценарии (создание хранилища, шифрование, открытие, работа с содержимым). Вывод о приоритете клиентских криптографических механизмов, унифицированного доступа к разным типам хранилищ и архитектуры с чётким разделением слоёв. | | **17.02.2026 — 28.02.2026** | **Обзор аналогов (этап 1):** детальный разбор **Google Files Secure Folder** (локальный «сейф» по PIN/Pattern; ограничения по кроссплатформенной синхронизации и универсальной модели vault); **Proton Pass / Proton Drive** (E2E-экосистема; привязка к экосистеме Proton, тарифные ограничения, меньшая гибкость как универсального клиента); **Bitwarden** (менеджер секретов; ориентация на учётные данные, ограничения офлайн-сценариев); **Cryptomator** (клиентское шифрование vault в облаке; фокус на файлах, ограничения интеграций). Обобщение по классам решений; фиксация типовых преимуществ (понятный сценарий, готовое шифрование файлов, интеграция с хранилищами) и ограничений (зависимость от backend, прозрачность модели ключей, переносимость). Подтверждение актуальности концепции Wallenc: безопасность без собственного сервера и переносимая архитектура хранилищ. | | **01.03.2026 — 14.03.2026** | **ТЗ и архитектура (этап 1):** подготовка структуры технического задания по логике **ГОСТ 7.32–2017** (цели, этапы, основные и дополнительные задачи, ожидаемые результаты, направления тестирования), синхронизация ТЗ с приоритетом ядра хранения/шифрования. Изучение и закрепление выбора **MVVM + Clean Architecture** с разбиением на Domain (интерфейсы и use case — операции над vault и шифрованием), Data (реализации хранилищ, доступ к данным, локальная БД, криптоадаптеры), Presentation (UI, навигация, состояния экранов, ViewModel). Обоснование снижения связности и возможности независимого развития локальных и удалённых провайдеров. | | **15.03.2026 — 28.03.2026** | **Проектирование системы и БД, стек (этап 1):** проектирование клиентской системы — локальный vault как базовая реализация; отдельный менеджер для открытия зашифрованного представления; операции чтения/записи через абстракции доступа к файлам; отделение служебных данных (метаданные, связи ключей и хранилищ) от пользовательского содержимого; закладка на подключение удалённых провайдеров без изменения доменной модели. Проектирование локальной БД: соответствия исходное/зашифрованное хранилище, метаданные, восстановление состояния при запуске; принцип — БД не хранит пользовательские данные в открытом виде. Выбор стека: Kotlin, Android SDK, Jetpack Compose, Coroutines/Flow, Hilt, Room, AES на клиенте, модули `app`, `presentation`, `domain`, `data`. **Доп. исследования:** OAuth без собственного сервера; работа с ключами и проверка ключа; скрытие служебных путей и имён; план unit/интеграционных/UI-тестов. | | **29.03.2026 — 19.04.2026** | **Реализация (2-й этап, период 29.03.2026–19.04.2026):** разработка ядра — CRUD локальных vault, метаданные, шифрование и параметры, открытие/закрытие с проверкой ключа, абстракция хранилищ, фильтрация системных каталогов и скрытие служебных объектов в UI, защита от повторного запуска шифрования. UI на Compose: списки, диалоги переименования/удаления/шифрования/открытия, параметры vault, содержимое, блокировка; отображение состояния шифрования и открытия. Адаптеры типов хранилищ. **Яндекс OAuth**, слой удалённых vault. **Room:** `DbStorageKeyMap`, `DbStorageMetaInfo`, `DbYandexAccount`, DAO, версия схемы 4. **Тесты:** unit-тесты криптографии (`Encryptor.generateEncryptionInfo`, `checkKey` для верного и неверного ключа); ручные прогоны экранов и сценариев. **Дополнительно:** основа для синхронизации без передачи ключей на сервер; ручное UI-тестирование связных цепочек действий. | | **21.04.2026 — 05.05.2026** | Подготовка иллюстраций к отчёту: скриншоты приложения, схема Room, экран задач и уведомление о статусах размещены в **приложении 1** непосредственно в соответствующих подразделах (пп. 3.2–3.7); подготовка диаграмм user flow и доменной модели (заготовки в п. 5 приложения). Систематизация результатов практики, оформление отчётной документации. | | **06.05.2026** | Завершение практики, защита результатов *(дата окончания по приказу)*. | --- ## 4. Анализ проведённой работы в период прохождения практики обучающимся | № п/п | Выполненные мероприятия | Анализ проведённой работы | | --- | --- | --- | | 1 | Анализ предметной области | Выполнен систематический обзор требований к системам хранения чувствительных данных: учтены конфиденциальность, модель «недоверенное хранилище», разделение криптографии и хранения, пользовательские сценарии. Сформирован вывод о необходимости клиентского шифрования до выгрузки данных и единой абстракции над разными провайдерами — это определило дальнейшую архитектуру Wallenc. | | 2 | Обзор аналогов | По каждому из рассмотренных решений зафиксированы назначение и ограничения (локальный сейф, привязка к экосистеме, ориентация на секреты вместо файлового vault, ограничения интеграций). Сравнение по классам продуктов позволило отделить идею Wallenc от «ещё одного облачного клиента» и обосновать фокус на переносимости и отсутствии собственного backend. | | 3 | Техническое задание | Структура ТЗ по ГОСТ 7.32–2017 обеспечила связность целей, этапов и критериев тестирования. Приоритет ядра хранения и шифрования зафиксирован в ТЗ и затем последовательно реализован на втором этапе без смещения фокуса на второстепенные функции. | | 4 | Архитектура MVVM + Clean Architecture | Разделение на domain/data/presentation снизило связность компонентов: сценарии шифрования и работы с vault выражены через use case, доступ к файлам и Room изолирован в data, интерфейс и состояние — в presentation. Это упростило поэтапное внедрение удалённого контура (Яндекс) без переписывания доменной логики. | | 5 | Проектирование структуры системы и БД | Спроектированные абстракции (локальный vault, менеджер зашифрованного представления, файловые абстракции) соответствуют реализованному коду второго этапа. Роль Room как хранилища **только** служебной информации соблюдена: пользовательский контент в открытом виде в БД не сохраняется, что согласуется с моделью угроз. | | 6 | Выбор технологий и доп. исследования | Стек Kotlin/Compose/Room/Hilt/Coroutines оказался достаточным для реализации всех запланированных на этапе функций. Отдельно проработанные темы OAuth без своего сервера, проверка ключа и минимизация утечек через пути подготовили реализацию Яндекс-авторизации и криптографического контура без противоречий с общей моделью безопасности. | | 7 | Реализация ядра приложения | Реализован полный набор операций жизненного цикла vault и шифрования; контроль параллельных задач снизил риск некорректного состояния при повторных нажатиях. Сокрытие служебных объектов и фильтрация системных директорий улучшили безопасность и удобство отображения содержимого. | | 8 | Пользовательский интерфейс | Интерфейс отражает состояние хранилища (шифрование, открытие) на основных экранах; диалоги подтверждения снижают риск деструктивных ошибок. Реализованы как локальный, так и удалённый контуры в одном приложении. | | 9 | Адаптеры и интеграция с Яндекс | Адаптерный подход подтвердил расширяемость: добавление провайдера не требует переписывания пользовательских сценариев. OAuth-интеграция доведена до рабочего пользовательского потока; подготовлены сущности для развития удалённых операций с сохранением принципа отсутствия передачи ключей на внешние сервисы приложения. | | 10 | Room и метаданные | Внедрение сущностей для ключей, метаданных и учётных записей Яндекс с раздельными DAO обеспечило устойчивое состояние между сеансами и ясную границу ответственности слоя данных. | | 11 | Тестирование | Unit-тесты на `Encryptor` подтверждают корректную генерацию параметров шифрования и валидацию ключа; ручное тестирование покрыло типовые цепочки и взаимодействие модулей в сборке приложения. | | 12 | Документирование | Промежуточные отчёты по этапам зафиксировали содержание работ; итоговый отчёт объединяет аналитику, проектирование, реализацию и результаты проверок с иллюстрациями. | --- ## 5. Отзыв руководителя практики от профильной организации В процессе прохождения практики обучающийся **Пытков Роман Евгеньевич** выполнил анализ предметной области защищённого хранения данных и обзор аналогичных решений, на основе которых сформулировал требования к мобильному приложению **Wallenc** (клиентское шифрование, работа с недоверенными хранилищами без собственного сервера приложения). Подготовил структуру технического задания и спроектировал архитектуру **MVVM + Clean Architecture**, модель служебных данных и использование **Room** для метаданных и учётных записей внешних провайдеров. На втором этапе практики реализовал функциональное ядро: управление **vault**, включение и использование шифрования, пользовательский интерфейс на **Kotlin** и **Jetpack Compose**, адаптерный слой хранилищ и интеграцию **OAuth Яндекс** для удалённого контура. Провёл **unit**-тестирование криптографического модуля и ручную проверку пользовательских сценариев. Все поставленные задачи в рамках практики выполнены **в срок**, с **самостоятельной** постановкой работ и добросовестным отношением к вопросам безопасности и качества кода. За время практики зарекомендовал себя **дисциплинированным, ответственным, исполнительным** студентом. Программа производственной (технологической) практики выполнена **своевременно**, **в полном объёме** и с **высоким** качеством результатов. **Рекомендуемая оценка — «отлично».** Руководитель практики от профильной организации ______________________ / **Алексеев Дмитрий Михайлович** / подпись расшифровка подписи --- ## 6. Отзыв руководителя практики от университета Студент **4** курса группы **КТбо4-9** **Пытков Роман Евгеньевич**, направления подготовки **09.03.04** «Программная инженерия» (профиль «Методы и средства разработки программного обеспечения»), в **8** семестре прошёл стационарную **производственную** практику в компании **ООО НМФ «Нейротех»**. В период практики **Пытков Р. Е.** работал в качестве **разработчика программного обеспечения** (мобильное приложение **Wallenc** на платформе **Android**). Им были решены следующие задачи: 1. Анализ предметной области: требования к хранению чувствительных данных, клиентскому шифрованию и сценариям работы с vault. 2. Обзор аналогов (secure-folder, менеджеры секретов, zero-knowledge) и выводы для концепции проекта. 3. Подготовка структуры технического задания по **ГОСТ 7.32–2017** с приоритетом ядра хранения и шифрования. 4. Проектирование архитектуры **MVVM + Clean Architecture**, структуры системы и абстракций хранилищ; задел под удалённые провайдеры. 5. Проектирование локальной **БД (Room)**: служебные сущности без хранения пользовательского контента в открытом виде. 6. Выбор и обоснование технологического стека (**Kotlin**, **Compose**, **Coroutines/Flow**, **Hilt**, **Room**, криптография на клиенте). 7. Дополнительные исследования: **OAuth** без собственного сервера, работа с ключами, минимизация утечек по путям и именам, план тестирования. 8. Реализация **ядра приложения**: vault, метаданные, шифрование и открытие/закрытие, защита от гонок при длительных операциях. 9. Разработка пользовательского **интерфейса** (**Jetpack Compose**): списки vault, диалоги операций, отображение состояния шифрования и доступа к содержимому. 10. Реализация **адаптеров** типов хранилищ с единым интерфейсом без серверного backend приложения. 11. Интеграция с внешним провайдером: **OAuth Яндекс**, слой удалённых vault. 12. Внедрение **Room**: таблицы метаданных, ключей, учётных записей; **DAO** и использование в жизненном цикле приложения. 13. Проектирование контура **синхронизации** зашифрованных данных без передачи ключей на сервер; ручное **UI**-тестирование сценариев. 14. **Тестирование**: unit-тесты криптографии; ручные прогоны экранов и пользовательских цепочек. 15. **Отчётность**: отчёты по предварительным этапам и итоговый отчёт с иллюстрациями и диаграммами пользовательских потоков. За время прохождения практики **Пытков Р. Е.** показал **высокий** уровень теоретической подготовки, **высокую** степень умения и навыков применять знания, полученные в университете, для решения практических задач. **Пытковым Р. Е.** проявлены следующие личностные и профессиональные качества: самостоятельность, ответственность, системность в подходе к проектированию, внимание к требованиям информационной безопасности, умение работать с технической документацией и оформлять результаты работы. Считаю, что проявленные профессиональные качества **полностью** удовлетворяют потребностям профильной организации, программа практики выполнена **в полном объёме**, сроки выполнения заданий соблюдены **полностью**. **Рекомендуемая оценка — «отлично».** Руководитель практики от Университета ______________________ / **Беликов Александр Николаевич** / подпись расшифровка подписи --- # ПРИЛОЖЕНИЕ 1 **ОТЧЁТ** **о прохождении производственной практики, технологической практики на тему** «Разработка мобильного приложения Wallenc — универсального «кошелька» для безопасного хранения данных на небезопасных хранилищах без собственного сервера (Android, Kotlin)» Студента гр. **КТбо4-9** **Пыткова Романа Евгеньевича** --- ## Содержание 1. [Введение](#введение) 2. [Результаты первого предварительного этапа (аналитика и проектирование)](#2-результаты-первого-предварительного-этапа-аналитика-и-проектирование) 3. [Результаты второго предварительного этапа (реализация и тестирование)](#3-результаты-второго-предварительного-этапа-реализация-и-тестирование) 4. [Фрагменты реализованного кода и пояснения](#4-фрагменты-реализованного-кода-и-пояснения) 5. [Дополнительные иллюстрации (диаграммы)](#5-дополнительные-иллюстрации-диаграммы) 6. [Заключение](#заключение) 7. [Список условных обозначений и сокращений](#список-условных-обозначений-и-сокращений) 8. [Использованные источники](#использованные-источники) --- ## Введение **Wallenc** — мобильное приложение-кошелёк для безопасного хранения пользовательских данных на недоверенных или потенциально небезопасных хранилищах **без развёртывания собственного сервера** приложения. Ключевая идея: безопасность обеспечивается **на стороне клиента** — данные **шифруются до отправки** во внешнее хранилище, расшифрование выполняется **только в приложении** при наличии корректного ключа. Это позволяет использовать небезопасные или недоверенные хранилища без потери конфиденциальности и без серверного backend приложения. **Цель практики** — пройти полный цикл технологической (проектно-технологической) работы: от анализа предметной области и оформления требований до работающего Android-приложения на Kotlin с проверкой ключевых сценариев и тестированием. **Задачи:** исследовать предметную область и аналоги; подготовить ТЗ и спроектировать архитектуру и данные; реализовать ядро, UI и интеграцию с внешним провайдером; провести тестирование; оформить отчётность. **Объект исследования** — методы клиентской защиты данных в мобильных приложениях. **Предмет исследования** — проектные и программные решения приложения Wallenc. --- ## 2. Результаты первого предварительного этапа (аналитика и проектирование) На первом этапе практики выполнена **аналитическая и проектная** подготовка к разработке Wallenc: определена предметная область, выбран архитектурный подход, описаны требования к системе и зафиксированы технологические решения для последующей реализации. ### 2.1. Анализ предметной области Рассмотрены подходы к хранению чувствительных данных в мобильных приложениях и облачных хранилищах. Выделены требования: - конфиденциальность данных при хранении и передаче; - отсутствие необходимости доверять инфраструктуре хранилища; - устойчивость к компрометации удалённого провайдера; - разделение логики хранения и логики криптографической защиты; - удобный пользовательский сценарий: создание хранилища, шифрование, открытие, работа с содержимым. **Вывод:** для Wallenc приоритетны клиентские криптографические механизмы, унифицированный доступ к разным типам хранилищ и архитектура с чётким разделением слоёв. ### 2.2. Обзор аналогичных решений **Google Files Secure Folder** — локально прячет и защищает файлы в папке по PIN/Pattern внутри Android. **Ограничения:** по сути только локальный «сейф» без полноценной кроссплатформенной синхронизации; ограниченные сценарии переноса между устройствами; не универсальная модель vault для разных хранилищ. **Proton Pass / Proton Drive** — E2E-экосистема для паролей, заметок и файлов с облачной синхронизацией. **Ограничения:** привязка к экосистеме Proton; часть сценариев и объёма зависит от тарифа; меньше гибкости как универсального клиента под разные внешние хранилища. **Bitwarden** — менеджер паролей/секретов с шифрованием, синхронизацией, офлайн-доступом и вариантом self-host. **Ограничения:** ориентация на учётные данные и секреты, а не на общий файловый vault; офлайн-сценарии ограничены (часть операций требует синхронизации/сервера). **Cryptomator** — клиентское шифрование файловых vault перед хранением в облаке (zero-knowledge). **Ограничения:** фокус на шифровании файлов, а не на расширенной модели «кошелька» с собственной мета-логикой и UI-сценариями; ограничения интеграций в зависимости от платформы/сборки и провайдера. Проведён обзор **классов решений:** secure-folder приложения, менеджеры секретов, облачные клиенты с zero-knowledge. **Типовые преимущества аналогов:** понятный пользовательский сценарий хранения; готовые механизмы шифрования файлов; интеграция с несколькими хранилищами. **Типовые ограничения:** зависимость от собственного backend или закрытой инфраструктуры; недостаточная прозрачность модели ключей; ограниченная переносимость между провайдерами. Это **подтвердило актуальность** концепции Wallenc: безопасность без собственного сервера и **переносимая** архитектура хранилищ. ### 2.3. Формирование технического задания На основании анализа подготовлена **структура ТЗ** в логике **ГОСТ 7.32–2017**: цели, этапы работ, основные и дополнительные задачи, ожидаемые результаты, направления тестирования. ТЗ **синхронизировано** с направлением проекта: приоритет на ядро системы хранения и шифрования и **поэтапное** расширение функциональности. ### 2.4. Изучение архитектурных подходов Принят подход **MVVM + Clean Architecture**: - **Domain** — интерфейсы и use case (операции над vault и шифрованием); - **Data** — реализации хранилищ, слой доступа к данным, локальная БД, криптографические адаптеры; - **Presentation** — UI-слой, навигация, состояния экранов, ViewModel. Такое разделение **снижает связность**, **упрощает тестирование** и позволяет **независимо** развивать локальные и удалённые провайдеры. ### 2.5. Проектирование структуры системы Спроектирована клиентская система, в которой: - локальный vault — базовая реализация хранения; - зашифрованное представление открывается через **отдельный менеджер**; - операции чтения/записи выполняются через **абстракции доступа к файлам**; - служебные данные (метаданные, связи ключей и хранилищ) **отделены** от пользовательского содержимого. Подход ориентирован на дальнейшее подключение удалённых провайдеров (в т.ч. облачных API) **без изменения доменной модели**. ### 2.6. Проектирование структуры базы данных Определена структура локальной БД для **служебной** информации: - соответствия между исходным хранилищем и зашифрованным представлением; - метаданные хранилищ; - поддержка восстановления состояния при запуске приложения. БД используется как внутренний механизм управления состоянием vault и **не хранит** пользовательские данные в открытом виде. ### 2.7. Выбор технологий Определён стек: - **Kotlin**, **Android SDK**; - **Jetpack Compose** (UI); - **Coroutines/Flow** (асинхронность и реактивные потоки); - **Hilt** (внедрение зависимостей); - **Room** (локальная БД); - криптография на клиенте (**AES** для данных и служебных атрибутов); - модульная структура: `app`, `presentation`, `domain`, `data`. Стек согласован с целями проекта и обеспечивает **масштабируемость**. ### 2.8. Дополнительные исследования первого этапа - варианты **OAuth** при работе с удалёнными провайдерами без собственного сервера; - безопасная работа с **ключами** шифрования и **проверка корректности** ключа; - защита структуры данных: скрытие служебных файлов и каталогов, минимизация утечек через имена и пути; - предварительный план тестирования: **unit**, интеграционные и **UI**-сценарии. ### 2.9. Итоги первого этапа Сформирована целостная **проектная база**: предметная область, архитектурная модель, структура данных, технологический стек, требования к безопасности. Материалы позволили перейти к **реализации функционального ядра** и расширению сценариев, включая синхронизацию зашифрованных данных с удалёнными провайдерами. --- ## 3. Результаты второго предварительного этапа (реализация и тестирование) **Период выполнения этапа:** 29.03.2026–19.04.2026. На втором этапе выполнена **реализация функционального ядра** Wallenc и ключевых пользовательских сценариев для локальных и удалённых хранилищ. Основной фокус — **перевод проектных решений первого этапа в рабочий код**: управление vault, шифрование, метаданные и ключевая информация, интерфейсы для повседневной работы пользователя. Обеспечена **практическая готовность** базовой версии: операции создания, просмотра, переименования, удаления и защиты vault; инфраструктура для расширения удалённых сценариев. Модули работают **совместно** в одном приложении: пользователь создаёт хранилища, включает защиту, открывает и закрывает зашифрованные представления, видит состояние vault в интерфейсе, выполняет операции сопровождения. Сценарии реализованы в рамках **единой архитектуры**, выбранной на первом этапе. ### 3.1. Краткая характеристика выполненного этапа За период **29.03.2026–19.04.2026** реализовано: - рабочее ядро управления **локальными и удалёнными** vault; - пользовательские экраны и **диалоговые** сценарии основных операций; - авторизация в **Яндекс** как часть удалённого контура; - хранение метаданных и служебной информации в **Room**; - **unit**-тестирование криптографии и **ручное** тестирование экранов. Этап завершён с заметным приростом прикладной готовности: архитектура первого этапа переведена в **работающее приложение** с подтверждённой функциональностью базового уровня. ### 3.2. Разработка модуля ядра приложения Wallenc Реализованы возможности: - создание и управление **локальными** vault; - хранение **метаданных** vault на устройстве; - включение **шифрования** выбранного vault с формированием параметров шифрования; - **открытие и закрытие** зашифрованного представления с проверкой корректности ключа; - доступ к содержимому через **слой абстракции** хранилищ; - **сокрытие** служебных объектов и **фильтрация** системных директорий при отображении данных пользователю. Ядро реализовано в логике **domain / data / presentation**. Для предотвращения конфликтов при параллельных операциях используется **контроль запущенных задач** (в частности, защита от повторного запуска шифрования одного и того же vault до завершения предыдущей операции), что повышает устойчивость при активном взаимодействии пользователя с приложением. **Иллюстрация — список локальных vault в приложении:** ![СКРИНШОТ №1 — локальные vault в приложении](<../Отчёт 2 этап/images/СКРИНШОТ №1 — локальные vault в приложении.jpg>) ### 3.3. Разработка мобильного приложения на Kotlin (Android) В UI реализованы операции: - отображение **списка** vault; - **переименование** и **удаление**; - **включение шифрования**; - **открытие** зашифрованного vault с использованием мастер-ключа; - **просмотр параметров** vault (состояние, служебные сведения, статус шифрования); - модуль работы с **содержимым** vault; - **блокировка/закрытие** vault. Реализованы **диалоговые** сценарии подтверждения и настройки операций. Интерфейс построен так, чтобы пользователь видел текущее состояние (зашифровано/не зашифровано, открыто/закрыто) и выполнял действия **без** перехода на технические служебные экраны — это улучшает эргономику и снижает число лишних шагов. **Иллюстрации — диалоги включения шифрования, открытия/закрытия зашифрованного vault, переименования и удаления:** ![СКРИНШОТ №2 — диалог включения шифрования vault](<../Отчёт 2 этап/images/СКРИНШОТ №2 — диалог включения шифрования vault.jpg>) ![СКРИНШОТ №3 — диалог открытия/закрытия зашифрованного vault](<../Отчёт 2 этап/images/СКРИНШОТ №3 — диалог открытия⁄закрытия зашифрованного vault.jpg>) ![СКРИНШОТ №4 — диалог переименования/удаления vault](<../Отчёт 2 этап/images/СКРИНШОТ №4 — диалог переименования⁄удаления vault.jpg>) ### 3.4. Модуль работы с небезопасными хранилищами через адаптеры Реализован модуль **адаптерного** взаимодействия с типами хранилищ **без** собственного серверного контура приложения. Подход через адаптеры сохраняет **единый интерфейс** работы с vault и упрощает расширение списка провайдеров. Добавление нового типа внешнего провайдера **не требует** переработки пользовательской логики и **не нарушает** слоистую архитектуру. ### 3.5. Взаимодействие с внешними провайдерами через API/SDK Реализована **авторизация через Яндекс** (OAuth) и интеграция пользовательского потока в приложение. Подготовлен слой **удалённых** vault и связанных сущностей для дальнейшего расширения удалённых операций. Реализованный контур обеспечивает сценарий **идентификации** пользователя во внешнем провайдере и формирует основу для расширения удалённой функциональности. **Иллюстрации — экран удалённых vault и сценарий добавления с авторизацией через Яндекс:** ![СКРИНШОТ №5 — экран удалённых vault](<../Отчёт 2 этап/images/СКРИНШОТ №5 — экран удалённых vault.jpg>) ![СКРИНШОТ №6 — диалог добавления удалённого vault и авторизация через Яндекс](<../Отчёт 2 этап/images/СКРИНШОТ №6 — диалог добавления удалённого vault ⁄ авторизация через Яндекс.jpg>) ### 3.6. Хранение ключевой информации и метаданных (Room) Реализован слой локальной БД для: - таблиц сопоставления **ключевой информации** и идентификаторов хранилищ; - таблиц **метаданных** vault и состояния хранилищ; - данных, необходимых для **восстановления состояния** приложения. Структура БД интегрирована в общий цикл работы приложения как **системный** слой управления состоянием. Room обеспечивает устойчивое хранение служебной информации между запусками и **централизованный** доступ через DAO. **Иллюстрация — визуализация схемы Room (служебные сущности приложения):** ![ИЗОБРАЖЕНИЕ №7 — визуализация Room базы данных](<../Отчёт 2 этап/images/ИЗОБРАЖЕНИЕ №7 — визуализация Room базы данных.png>) ### 3.7. Тестирование приложения Параллельно с ручной проверкой экранов велся учёт задач в трекере: на экране задач отображались этапы работ по проекту, а push-уведомление фиксировало обновление статусов — это упорядочивало регрессию сценариев и снижало риск пропустить проверку после изменений в коде. **Иллюстрации — экран задач и уведомление о статусе задач:** ![СКРИНШОТ №7 — экран задач](<../Отчёт 2 этап/images/СКРИНШОТ №7 — Экран задач.jpg>) ![СКРИНШОТ №8 — уведомление со статусом задач](<../Отчёт 2 этап/images/СКРИНШОТ №8 — Уведомление со статусом задач.jpg>) - **Unit-тесты** криптографических компонентов: проверка корректности шифрования/дешифрования и валидации ключа. - **Ручное** тестирование экранов и основных пользовательских сценариев работы с vault. Проверки подтвердили **работоспособность** базового функционального ядра второго этапа. ### 3.8. Дополнительные работы по п. 2.2 ТЗ **Синхронизация зашифрованных данных с удалёнными хранилищами без передачи ключей на сервер:** подготовлена безопасная база — поток авторизации через Яндекс; сущности и механизм учёта удалённых vault; сохранён принцип клиентской защиты (ключевая логика шифрования на стороне приложения). Это даёт архитектурную основу для дальнейшего развития синхронизации **без** передачи ключей на сторону внешних сервисов. **Тестирование пользовательского интерфейса:** проверены отображение списков локальных и удалённых vault, корректность вызова и отработки диалогов, стабильность операций создания, переименования, удаления, шифрования, открытия и закрытия vault. Проверка велась на **последовательностях реальных пользовательских действий**, что позволило оценить связную работу функций в типовом использовании. ### 3.9. Итоги второго этапа Сформировано и протестировано **работоспособное ядро** Wallenc: управление vault, шифрование, Room, UI для локальных и удалённых сценариев. Получен **функционирующий** Android-проект на Kotlin, готовый к дальнейшему расширению удалённой работы с хранилищами и синхронизационных механизмов. Этап можно считать **успешно завершённым**: ключевые задачи реализованы, протестированы и представлены в форме, пригодной для демонстрации и развития проекта. --- ## 4. Фрагменты реализованного кода и пояснения ### 4.1. Room-база приложения и состав сущностей ```kotlin @Database( entities = [DbStorageKeyMap::class, DbStorageMetaInfo::class, DbYandexAccount::class], version = 4, exportSchema = false, ) abstract class AppDb : IAppDb, RoomDatabase() { abstract override val storageKeyMapDao: StorageKeyMapDao abstract override val storageMetaInfoDao: StorageMetaInfoDao abstract override val yandexAccountDao: YandexAccountDao } ``` **Пояснение:** на этапе реализована целевая модель хранения метаданных и удалённой учётной информации в Room с разделением доступа через DAO. ### 4.2. Логика шифрования и открытия зашифрованного vault в ViewModel ```kotlin fun enableEncryption(storage: IStorageInfo, password: String, encryptPath: Boolean) { val key = EncryptKey(password) viewModelScope.launch { when (manageStoragesEncryptionUseCase.canEncrypt(storage)) { ManageStoragesEncryptionUseCase.CanEncryptResult.Allowed -> { manageStoragesEncryptionUseCase.enableEncryption(storage, key, encryptPath) manageStoragesEncryptionUseCase.openStorage(storage, key, true) _messages.emit("Encryption enabled") } ManageStoragesEncryptionUseCase.CanEncryptResult.AlreadyEncrypted -> _messages.emit("Storage is already encrypted") else -> _messages.emit("Unsupported operation") } } } ``` **Пояснение:** включение шифрования — управляемый сценарий с валидацией состояния, запуском шифрования и последующим открытием зашифрованного представления. ### 4.3. UI-операции над удалёнными vault (фрагмент) ```kotlin FloatingActionButton( onClick = { if (!uiState.isBusy) viewModel.setAddChoiceVisible(true) }, ) { Icon(Icons.Filled.Add, contentDescription = stringResource(R.string.remote_vaults_add_cd)) } ... FilledTonalButton( onClick = { viewModel.setAddChoiceVisible(false) viewModel.yandexSignIn.launch { outcome -> when (outcome) { is RemoteYandexAuthResult.Success -> viewModel.onYandexAuthSuccess(outcome.accessToken) is RemoteYandexAuthResult.Failure -> { /* сообщение об ошибке */ } RemoteYandexAuthResult.Cancelled -> { } } } } ) ``` **Пояснение:** отражён пользовательский путь запуска авторизации для удалённого провайдера из интерфейса приложения. ### 4.4. Unit-тесты криптографического контура ```kotlin @Test fun `test correct key for StorageEncryptionInfo`() { val encInfo = Encryptor.generateEncryptionInfo(key1) val res = Encryptor.checkKey(key = key1, encInfo = encInfo) assertEquals(true, res) } @Test fun `test incorrect key for StorageEncryptionInfo`() { val encInfo = Encryptor.generateEncryptionInfo(key1) val res = Encryptor.checkKey(key = key2, encInfo = encInfo) assertEquals(false, res) } ``` **Пояснение:** тесты подтверждают корректную проверку ключа и работоспособность криптографической логики. --- ## 5. Дополнительные иллюстрации (диаграммы) Скриншоты работы приложения, схема Room, экран задач и уведомление о статусах приведены **в соответствующих подразделах** раздела 3 приложения (пп. 3.2–3.7). Ниже — **три диаграммы пользовательских потоков** для Wallenc в стиле отчёта по практике (аналог блок-схем из примера коллеги). На всех схемах отдельно показана **проектная** (ещё не реализованная в коде) механика **синхронизации**: в Room хранятся записи с **UUID** хранилищ (`storage`), подлежащих синхронизации; по **таймеру** (или периодическому Worker’у Android) запускается сервис синхронизации; у каждого **Storage** ведётся **история коммитов** (аналог git); сервис **находит отличия** между локальной и удалённой историей и **приводит зашифрованное содержимое** к одному состоянию **без передачи ключей** на сторону провайдера. Исходники **PlantUML**: каталог `Отчёт практика/puml/` (`wallenc-01-start-and-sync.puml`, `wallenc-02-vault-lifecycle.puml`, `wallenc-03-navigation-hub.puml`). Растеризация: PNG сгенерированы командой `/usr/lib/jvm/java-21-openjdk/bin/java -jar plantuml.jar -tpng …` (системный вызов `plantuml` в среде может требовать Java 11+). ### 5.1. Старт приложения и параллельная синхронизация ![Диаграмма 1 — старт Wallenc и фоновая синхронизация по таймеру]() ### 5.2. Жизненный цикл vault и постановка в очередь синхронизации ![Диаграмма 2 — жизненный цикл vault и коммиты/очередь UUID]() ### 5.3. Навигация с главного экрана и независимый SyncWorker ![Диаграмма 3 — главный экран и фоновый SyncWorker]() ### 5.4. Диаграмма классов модуля `domain` Сгенерирована из **скомпилированных** `.class` (Kotlin → JVM) плагином **code-atlas** (`./gradlew :domain:generateDiagrams`), исходник PlantUML: `puml/domain-classdiagram.puml`. ![Диаграмма классов domain]() --- ## Заключение По результатам **первого** этапа сформирована проектная база Wallenc: предметная область, обзор аналогов, ТЗ по ГОСТ 7.32–2017, архитектура MVVM + Clean Architecture, структура системы и локальной БД, технологический стек и дополнительные исследования по OAuth, ключам и тестированию. По результатам **второго** этапа получено **работоспособное** ядро приложения на Kotlin/Android с Jetpack Compose, Hilt и Room, реализованы ключевые пользовательские сценарии, интеграция с Яндекс OAuth и контур тестирования (unit и ручной). Итог практики соответствует целям направления и приказу о прохождении практики **с 09.02.2026 по 06.05.2026** и создаёт основу для дальнейшего развития синхронизации зашифрованных данных и поддержки дополнительных провайдеров хранения. --- ## Список условных обозначений и сокращений | Обозначение | Расшифровка | | --- | --- | | API | Application Programming Interface | | DAO | Data Access Object | | E2E | End-to-end | | MVVM | Model — View — ViewModel | | OAuth | протокол авторизации | | UI | пользовательский интерфейс | | CRUD | создание, чтение, изменение, удаление | --- ## Использованные источники Ниже приведены нормативные документы, официальная техническая документация и иные материалы, на которые опирались при подготовке отчёта и реализации проекта Wallenc. Для страниц в сети Интернет указана **дата обращения: 23.04.2026**. 1. ГОСТ 7.32—2017. Система стандартов по информации, библиотечному и издательскому делу. Отчёт о научно-исследовательской работе. Структура и правила оформления. — М.: Стандартинформ, 2017. — Публичная электронная копия официального издания для ознакомления [Электронный ресурс] // Томский государственный университет. — URL: https://tsu.ru/upload/medialibrary/235/gost_7.32_2017.pdf (дата обращения: 23.04.2026). 2. Приказ ректора ЮФУ № 2191-к от 17.02.2026 г. о прохождении практики *(внутренний нормативный документ университета; текст — в распоряжении кафедры и обучающегося)*. 3. Kotlin Documentation [Электронный ресурс] // JetBrains и Kotlin Foundation. — URL: https://kotlinlang.org/docs/home.html (дата обращения: 23.04.2026). 4. Guide to app architecture [Электронный ресурс] // Android Developers. — URL: https://developer.android.com/topic/architecture (дата обращения: 23.04.2026). 5. ViewModel overview [Электронный ресурс] // Android Developers. — URL: https://developer.android.com/topic/libraries/architecture/viewmodel (дата обращения: 23.04.2026). 6. Get started with Jetpack Compose [Электронный ресурс] // Android Developers. — URL: https://developer.android.com/develop/ui/compose/documentation (дата обращения: 23.04.2026). 7. Save data in a local database using Room [Электронный ресурс] // Android Developers. — URL: https://developer.android.com/training/data-storage/room (дата обращения: 23.04.2026). 8. Hilt [Электронный ресурс] // Android Developers. — URL: https://developer.android.com/training/dependency-injection/hilt-android (дата обращения: 23.04.2026). 9. Kotlin coroutines [Электронный ресурс] // Kotlin Documentation. — URL: https://kotlinlang.org/docs/coroutines-overview.html (дата обращения: 23.04.2026). 10. Hardt D. The OAuth 2.0 Authorization Framework. RFC 6749 [Электронный ресурс] // IETF. — октябрь 2012. — URL: https://datatracker.ietf.org/doc/html/rfc6749 (дата обращения: 23.04.2026). 11. OAuth для сервисов Яндекса [Электронный ресурс] // Яндекс ID для разработчиков. — URL: https://yandex.ru/dev/id/doc/ru/ (дата обращения: 23.04.2026). 12. NIST FIPS 197. Advanced Encryption Standard (AES) [Электронный ресурс]. — URL: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf (дата обращения: 23.04.2026). 13. NIST Special Publication 800-38A. Recommendation for Block Cipher Modes of Operation: Methods and Techniques [Электронный ресурс] // NIST CSRC. — URL: https://csrc.nist.gov/pubs/sp/800/38/a/final (дата обращения: 23.04.2026). 14. PlantUML Language Reference Guide — Class diagram [Электронный ресурс]. — URL: https://plantuml.com/class-diagram (дата обращения: 23.04.2026). 15. Plugin: io.github.euledge.code-atlas [Электронный ресурс] // Gradle Plugin Portal. — URL: https://plugins.gradle.org/plugin/io.github.euledge.code-atlas (дата обращения: 23.04.2026). 16. euledge/code-atlas [Электронный ресурс] // GitHub. — URL: https://github.com/euledge/code-atlas (дата обращения: 23.04.2026). 17. Use a PIN to lock your Safe folder in Files by Google [Электронный ресурс] // Google Help. — URL: https://support.google.com/files/answer/9935263 (дата обращения: 23.04.2026). 18. Cryptomator Documentation [Электронный ресурс]. — URL: https://docs.cryptomator.org/en/latest/ (дата обращения: 23.04.2026). 19. Bitwarden Help Center [Электронный ресурс]. — URL: https://bitwarden.com/help/ (дата обращения: 23.04.2026). 20. Martin R. C. The Clean Architecture [Электронный ресурс] // blog.cleancoder.com. — 13.08.2012. — URL: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html (дата обращения: 23.04.2026). --- *Конец отчёта.*