585 lines
70 KiB
Markdown
585 lines
70 KiB
Markdown
МИНОБРНАУКИ РОССИИ
|
||
Федеральное государственное автономное образовательное
|
||
учреждение высшего образования
|
||
«ЮЖНЫЙ ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ»
|
||
|
||
Институт компьютерных технологий и информационной безопасности
|
||
Структурное подразделение
|
||
|
||
Направление подготовки **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 в приложении:**
|
||
|
||
|
||
|
||
### 3.3. Разработка мобильного приложения на Kotlin (Android)
|
||
|
||
В UI реализованы операции:
|
||
|
||
- отображение **списка** vault;
|
||
- **переименование** и **удаление**;
|
||
- **включение шифрования**;
|
||
- **открытие** зашифрованного vault с использованием мастер-ключа;
|
||
- **просмотр параметров** vault (состояние, служебные сведения, статус шифрования);
|
||
- модуль работы с **содержимым** vault;
|
||
- **блокировка/закрытие** vault.
|
||
|
||
Реализованы **диалоговые** сценарии подтверждения и настройки операций. Интерфейс построен так, чтобы пользователь видел текущее состояние (зашифровано/не зашифровано, открыто/закрыто) и выполнял действия **без** перехода на технические служебные экраны — это улучшает эргономику и снижает число лишних шагов.
|
||
|
||
**Иллюстрации — диалоги включения шифрования, открытия/закрытия зашифрованного vault, переименования и удаления:**
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
### 3.4. Модуль работы с небезопасными хранилищами через адаптеры
|
||
|
||
Реализован модуль **адаптерного** взаимодействия с типами хранилищ **без** собственного серверного контура приложения. Подход через адаптеры сохраняет **единый интерфейс** работы с vault и упрощает расширение списка провайдеров. Добавление нового типа внешнего провайдера **не требует** переработки пользовательской логики и **не нарушает** слоистую архитектуру.
|
||
|
||
### 3.5. Взаимодействие с внешними провайдерами через API/SDK
|
||
|
||
Реализована **авторизация через Яндекс** (OAuth) и интеграция пользовательского потока в приложение. Подготовлен слой **удалённых** vault и связанных сущностей для дальнейшего расширения удалённых операций. Реализованный контур обеспечивает сценарий **идентификации** пользователя во внешнем провайдере и формирует основу для расширения удалённой функциональности.
|
||
|
||
**Иллюстрации — экран удалённых vault и сценарий добавления с авторизацией через Яндекс:**
|
||
|
||
|
||
|
||
|
||
|
||
### 3.6. Хранение ключевой информации и метаданных (Room)
|
||
|
||
Реализован слой локальной БД для:
|
||
|
||
- таблиц сопоставления **ключевой информации** и идентификаторов хранилищ;
|
||
- таблиц **метаданных** vault и состояния хранилищ;
|
||
- данных, необходимых для **восстановления состояния** приложения.
|
||
|
||
Структура БД интегрирована в общий цикл работы приложения как **системный** слой управления состоянием. Room обеспечивает устойчивое хранение служебной информации между запусками и **централизованный** доступ через DAO.
|
||
|
||
**Иллюстрация — визуализация схемы Room (служебные сущности приложения):**
|
||
|
||
|
||
|
||
### 3.7. Тестирование приложения
|
||
|
||
Параллельно с ручной проверкой экранов велся учёт задач в трекере: на экране задач отображались этапы работ по проекту, а push-уведомление фиксировало обновление статусов — это упорядочивало регрессию сценариев и снижало риск пропустить проверку после изменений в коде.
|
||
|
||
**Иллюстрации — экран задач и уведомление о статусе задач:**
|
||
|
||
|
||
|
||
|
||
|
||
- **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. Старт приложения и параллельная синхронизация
|
||
|
||
|
||
|
||
### 5.2. Жизненный цикл vault и постановка в очередь синхронизации
|
||
|
||
|
||
|
||
### 5.3. Навигация с главного экрана и независимый SyncWorker
|
||
|
||
|
||
|
||
### 5.4. Диаграмма классов модуля `domain`
|
||
|
||
Сгенерирована из **скомпилированных** `.class` (Kotlin → JVM) плагином **code-atlas** (`./gradlew :domain:generateDiagrams`), исходник PlantUML: `puml/domain-classdiagram.puml`.
|
||
|
||
|
||
|
||
---
|
||
|
||
## Заключение
|
||
|
||
По результатам **первого** этапа сформирована проектная база 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).
|
||
|
||
---
|
||
|
||
*Конец отчёта.*
|