Более правильная структура Vault,Storage
This commit is contained in:
@@ -16,5 +16,5 @@
|
||||
|
||||
parbreak()
|
||||
|
||||
[Реализованы управление локальными и удалёнными vault, клиентское AES-шифрование, OAuth Яндекс, служебное хранение метаданных в Room; спроектирован контур синхронизации без передачи ключей провайдеру. Исходный код размещён в приватном репозитории GitLab ЮФУ. Полный листинг исходных файлов — приложение А; программная документация — приложение Б.]
|
||||
[Реализованы иерархия VaultsManager → vault → storage → файлы (один LocalVault на устройстве, удалённые vault по OAuth), клиентское AES-шифрование, служебные метаданные в Room и проектный контур синхронизации без передачи ключей провайдеру. Исходный код размещён в приватном репозитории GitLab ЮФУ. Полный листинг исходных файлов — приложение А; программная документация — приложение Б.]
|
||||
}
|
||||
|
||||
@@ -18,9 +18,9 @@
|
||||
|
||||
=== Назначение и цели создания системы
|
||||
|
||||
*Назначение* системы Wallenc — предоставление пользователю мобильного клиента для управления локальными и удалёнными vault с обязательным клиентским шифрованием содержимого до выгрузки во внешнее хранилище.
|
||||
*Назначение* системы Wallenc — предоставление пользователю мобильного клиента для работы с иерархией *vault → storage → файлы*: один локальный vault на устройстве, удалённые vault по учётным записям провайдера; внутри каждого vault пользователь управляет отдельными storage с обязательным клиентским шифрованием до выгрузки во внешнее хранилище.
|
||||
|
||||
*Цели создания*: обеспечить единую модель хранилищ; минимизировать доверие к провайдеру; поддержать расширение списка провайдеров через адаптеры; сохранить метаданные и состояние приложения в локальной БД без хранения пользовательского контента в открытом виде.
|
||||
*Цели создания*: обеспечить единую модель vault и storage; минимизировать доверие к провайдеру; поддержать расширение списка провайдеров через адаптеры; сохранить служебные метаданные в локальной БД без хранения пользовательского контента в открытом виде.
|
||||
|
||||
=== Функциональные требования
|
||||
|
||||
@@ -30,23 +30,23 @@
|
||||
[Свод функциональных требований],
|
||||
2,
|
||||
table.header([Код], [Требование]),
|
||||
[ФР-1], [Создание, просмотр, переименование и удаление локальных vault],
|
||||
[ФР-2], [Включение шифрования vault, проверка ключа, открытие и закрытие зашифрованного представления],
|
||||
[ФР-3], [Просмотр и операции с файлами через абстракцию хранилищ; текстовые секреты и 2FA в vault],
|
||||
[ФР-4], [OAuth-авторизация во внешнем провайдере (Яндекс), учёт удалённых vault],
|
||||
[ФР-1], [Создание, просмотр, переименование и удаление storage в локальном vault (LocalVault — один на устройстве)],
|
||||
[ФР-2], [Включение шифрования storage, проверка ключа, открытие и закрытие зашифрованного представления],
|
||||
[ФР-3], [Просмотр и операции с файлами внутри storage; текстовые секреты и 2FA],
|
||||
[ФР-4], [OAuth-авторизация (Яндекс), регистрация удалённых vault и листинг их storage],
|
||||
[ФР-5], [Синхронизация: группы хранилищ, журнал коммитов, фоновый Worker без передачи ключей],
|
||||
[ФР-6], [Очередь фоновых задач: шифрование, синхронизация, отображение прогресса],
|
||||
) <tbl-req>
|
||||
|
||||
==== Управление локальными vault
|
||||
==== Управление storage в локальном vault
|
||||
|
||||
Пользователь создаёт vault, просматривает список, переименовывает и удаляет хранилища. Служебные каталоги и системные пути не отображаются в пользовательском представлении.
|
||||
Пользователь создаёт storage, просматривает список, переименовывает и удаляет их в единственном `LocalVault`. Служебные каталоги и системные пути не отображаются в пользовательском представлении.
|
||||
|
||||
==== Шифрование и открытие зашифрованного vault
|
||||
==== Шифрование и открытие storage
|
||||
|
||||
При включении шифрования формируются параметры `StorageEncryptionInfo`; открытие выполняется только после успешной проверки ключа. Повторное шифрование одного vault до завершения предыдущей операции блокируется.
|
||||
При включении шифрования формируются параметры `StorageEncryptionInfo`; открытие выполняется только после успешной проверки ключа. Повторное шифрование одного storage до завершения предыдущей операции блокируется.
|
||||
|
||||
==== Работа с содержимым vault
|
||||
==== Работа с содержимым storage
|
||||
|
||||
Операции чтения и записи выполняются через единый интерфейс файлового доступа независимо от типа хранилища.
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@
|
||||
|
||||
=== Карта процессов
|
||||
|
||||
Основные процессы: создание vault → опциональное шифрование → открытие → работа с содержимым → закрытие; для удалённых vault — авторизация OAuth → привязка хранилища → проектная синхронизация.
|
||||
Основные процессы: создание storage в vault → опциональное шифрование → открытие → работа с файлами → закрытие; для удалённых vault — OAuth → привязка учётной записи → листинг storage провайдера → проектная синхронизация.
|
||||
|
||||
=== Диаграмма BPMN
|
||||
|
||||
@@ -42,6 +42,16 @@ DFD уровня 0 (рис. @fig-16) отражает потоки между UI
|
||||
|
||||
#pz-fig("fig_04_domain_class.png", [Диаграмма классов модуля domain], "fig-04")
|
||||
|
||||
=== Доменная иерархия хранения данных
|
||||
|
||||
Модель данных приложения строится на трёх уровнях (см. `IVaultsManager`, `IVault`, `IStorage` на рис. @fig-04):
|
||||
|
||||
+ *VaultsManager* — единая точка доступа: реактивный список всех vault (`vaults`), агрегированный список storage (`allStorages`) и `IUnlockManager` для открытых storage;
|
||||
+ *IVault* — контейнер, объединяющий набор storage. *LocalVault* в приложении один (корень на устройстве); удалённые vault (например, `YandexVault`) добавляются по одному на привязанную учётную запись OAuth;
|
||||
+ *IStorage* — хранилище, которое пользователь создаёт, переименовывает и удаляет в интерфейсе; внутри — файлы и каталоги, доступные через `IStorageAccessor` (с опциональным клиентским шифрованием).
|
||||
|
||||
Пользовательские сценарии «создать локальный vault» в UI соответствуют созданию нового *storage* внутри единственного `LocalVault`, а не появлению второго локального vault.
|
||||
|
||||
Служебные сущности Room показаны на рисунке @fig-11.
|
||||
|
||||
#pz-fig("fig_11_room_schema.png", [Схема служебных сущностей Room], "fig-11")
|
||||
@@ -58,14 +68,14 @@ DFD уровня 0 (рис. @fig-16) отражает потоки между UI
|
||||
|
||||
== Проектирование локальной базы данных
|
||||
|
||||
Служебная БД Room хранит соответствия между исходным хранилищем и зашифрованным представлением (`DbStorageKeyMap`), метаданные vault (`DbStorageMetaInfo`), учётные записи Яндекс (`DbYandexAccount`) и группы синхронизации (`DbStorageSyncGroup`). Пользовательский контент в открытом виде в БД не сохраняется — только параметры, необходимые для восстановления состояния приложения при следующем запуске. Доступ инкапсулирован в DAO и репозиториях модуля `:infrastructure-android`.
|
||||
Служебная БД Room хранит ключи шифрования для пар «исходный storage → зашифрованное представление» (`DbStorageKeyMap`), сериализованные метаданные storage (`DbStorageMetaInfo`), учётные записи Яндекс (`DbYandexAccount`) и группы синхронизации (`DbStorageSyncGroup`). Пользовательский контент в открытом виде в БД не сохраняется — только параметры, необходимые для восстановления состояния приложения при следующем запуске. Доступ инкапсулирован в DAO и репозиториях модуля `:infrastructure-android`.
|
||||
|
||||
#pz-table(
|
||||
[Сущности Room и назначение],
|
||||
3,
|
||||
table.header([Сущность], [Назначение], [Связь с тестами]),
|
||||
[`DbStorageKeyMap`], [Связь vault ↔ параметры шифрования], [Интеграция],
|
||||
[`DbStorageMetaInfo`], [Имя, путь, флаги состояния vault], [Интеграция],
|
||||
[`DbStorageKeyMap`], [Ключ для `sourceUuid` storage (связь с зашифрованной копией)], [Интеграция],
|
||||
[`DbStorageMetaInfo`], [Сериализованные метаданные `IStorage` (имя, путь, шифрование)], [Интеграция],
|
||||
[`DbYandexAccount`], [OAuth access token, идентификатор аккаунта], [`YandexAccountRepositoryTest`],
|
||||
[`DbStorageSyncGroup`], [Группа UUID для синхронизации], [`StorageSyncEngineTest`],
|
||||
) <tbl-room-entities>
|
||||
|
||||
@@ -30,7 +30,7 @@
|
||||
[User Story Wallenc],
|
||||
3,
|
||||
table.header([ID], [Формулировка], [Критерий приёмки]),
|
||||
[US-1], [Создаю локальный vault для файлов на устройстве], [Vault в списке (рис. 5)],
|
||||
[US-1], [Создаю storage для файлов в локальном vault на устройстве], [Storage в списке (рис. 5)],
|
||||
[US-2], [Включаю шифрование vault паролем], [Статус encrypted, тест T-8],
|
||||
[US-3], [Открываю зашифрованный vault ключом], [Доступ к контенту, тест T-9],
|
||||
[US-4], [Подключаю Яндекс и удалённый vault], [OAuth OK, тест T-10],
|
||||
@@ -56,7 +56,7 @@ CJM сценария «защитить и открыть vault» предста
|
||||
|
||||
Интерфейс реализован на Jetpack Compose @compose-docs. Экраны локальных и удалённых vault, диалоги шифрования и OAuth показаны на рис. @fig-05–@fig-10 (подробно — приложение В и руководство пользователя в приложении Б).
|
||||
|
||||
#pz-fig("fig_05_local_vaults.jpg", [Список локальных vault], "fig-05")
|
||||
#pz-fig("fig_05_local_vaults.jpg", [Список storage в локальном vault (экран «локальные vault»)], "fig-05")
|
||||
#pz-fig("fig_06_encrypt_dialog.jpg", [Диалог включения шифрования], "fig-06")
|
||||
#pz-fig("fig_07_open_close_dialog.jpg", [Диалог открытия и закрытия vault], "fig-07")
|
||||
#pz-fig("fig_08_rename_delete_dialog.jpg", [Диалог переименования и удаления], "fig-08")
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
=== Модуль :vault-contracts
|
||||
|
||||
Определяет интерфейсы регистрации типов хранилищ (`VaultRegistrar`, `VaultRegistration`) и фасад `Vaults` для получения реализации по идентификатору. Позволяет подключать новый провайдер без изменения `:app`.
|
||||
Определяет дескрипторы vault (`VaultDescriptor`, `DescribedVault`) и контракты регистрации удалённых vault (`VaultRegistrar`, `VaultRegistration`). Реализация агрегатора — `VaultsManager` в `:domain-vault`.
|
||||
|
||||
=== Модуль :domain-vault
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
|
||||
=== Модуль управления vault и шифрованием
|
||||
|
||||
Use case `ManageStoragesEncryptionUseCase` инкапсулирует проверку `canEncrypt`, включение шифрования и открытие хранилища. ViewModel предотвращает повторный запуск шифрования для занятого vault.
|
||||
Use case `ManageStoragesEncryptionUseCase` инкапсулирует проверку `canEncrypt`, включение шифрования и открытие хранилища. ViewModel предотвращает повторный запуск шифрования для занятого storage.
|
||||
|
||||
Фрагмент логики включения шифрования:
|
||||
|
||||
@@ -38,7 +38,7 @@ fun enableEncryption(storage: IStorageInfo, password: String, encryptPath: Boole
|
||||
|
||||
=== Модуль адаптеров хранилищ
|
||||
|
||||
Адаптеры реализуют единый контракт доступа к локальным и удалённым хранилищам; регистрация vault выполняется через модуль `:vault-contracts`.
|
||||
`VaultsManager` агрегирует один `LocalVault` и удалённые vault; адаптеры реализуют доступ к файлам внутри каждого `IStorage`. Регистрация удалённых vault — через модуль `:vault-contracts`.
|
||||
|
||||
=== Проект модуля синхронизации
|
||||
|
||||
|
||||
@@ -41,7 +41,7 @@
|
||||
[T-4], [Синхронизация группы хранилищ], [Unit], [Да], [Копирование, удаление, trash, блокировки],
|
||||
[T-5], [2FA TOTP генерация], [Unit], [Да], [Совпадение с эталоном Java OTP],
|
||||
[T-6], [Маппинг ошибок сети/диска], [Unit], [Да], [Типизированные `WallencException`],
|
||||
[T-7], [CRUD локального vault], [Ручной], [Нет], [Список обновлён (рис. @fig-05)],
|
||||
[T-7], [CRUD storage в LocalVault], [Ручной], [Нет], [Список обновлён (рис. @fig-05)],
|
||||
[T-8], [Включение шифрования vault], [Ручной], [Нет], [Статус «зашифровано» (рис. @fig-06)],
|
||||
[T-9], [Открытие/закрытие vault], [Ручной], [Нет], [Доступ только с ключом (рис. @fig-07)],
|
||||
[T-10], [OAuth Яндекс], [Ручной / IT], [Частично], [Токен в Room (рис. @fig-10)],
|
||||
@@ -125,7 +125,7 @@
|
||||
[Протокол ручного тестирования],
|
||||
5,
|
||||
table.header([ID], [Шаг], [Статус], [Фактический результат], [Иллюстрация]),
|
||||
[T-7], [Создать локальный vault], [OK], [Vault в списке], [@fig-05],
|
||||
[T-7], [Создать storage в LocalVault], [OK], [Storage в списке], [@fig-05],
|
||||
[T-8], [Включить шифрование], [OK], [Статус encrypted], [@fig-06],
|
||||
[T-9], [Открыть/закрыть vault], [OK], [Контент только при открытом vault], [@fig-07],
|
||||
[T-10], [OAuth Яндекс], [OK], [Запись в `DbYandexAccount`], [@fig-10],
|
||||
@@ -145,7 +145,7 @@
|
||||
[Трассировка требований → тесты],
|
||||
3,
|
||||
table.header([ФР], [Тесты], [Комментарий]),
|
||||
[ФР-1], [T-7, StorageDomainUseCasesTest], [Локальный vault и CRUD секретов],
|
||||
[ФР-1], [T-7, StorageDomainUseCasesTest], [Storage в LocalVault и CRUD секретов],
|
||||
[ФР-2], [EncryptorTest, T-8, T-9], [Покрытие AES],
|
||||
[ФР-3], [TextSecretsScreenContentTest], [UI + domain],
|
||||
[ФР-4], [YandexDiskRepositoryTest, T-10], [HTTP-мок и ручной OAuth],
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
По главе 1 сформированы требования и выполнен сравнительный анализ аналогов; обоснован выбор стека Kotlin/Compose/Room/Hilt. По главе 2 спроектированы бизнес-процессы, DFD, UML-диаграммы и модель данных Room. Глава 3 описывает пользовательские сценарии и интерфейсные решения. Глава 4 представляет реализованные модули; полный исходный код приведён в приложении А. Глава 5 документирует план и результаты тестирования. Глава 6 содержит краткую экономическую оценку.
|
||||
|
||||
*Цель работы достигнута*: разработан и протестирован прототип Android-приложения с клиентским шифрованием, управлением vault, OAuth Яндекс и проектным контуром синхронизации.
|
||||
*Цель работы достигнута*: разработан и протестирован прототип Android-приложения с иерархией vault → storage → файлы, клиентским шифрованием, OAuth Яндекс и проектным контуром синхронизации.
|
||||
|
||||
*Перспективы развития*: завершение синхронизации по модели коммитов; поддержка дополнительных провайдеров; расширение автоматизированных UI-тестов.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
*Актуальность* темы обусловлена распространением мобильных приложений для хранения файлов и секретов, а также ограниченностью готовых решений: многие продукты привязаны к собственному backend, закрытой экосистеме или узкой предметной области @google-secure-folder @bitwarden-help @cryptomator-docs.
|
||||
|
||||
*Цель работы* — повысить конфиденциальность пользовательских данных при работе с недоверенными хранилищами за счёт разработки мобильного приложения для защищённого хранения пользовательских данных (Wallenc) без собственного сервера приложения и с единой моделью vault и клиентским шифрованием.
|
||||
*Цель работы* — повысить конфиденциальность пользовательских данных при работе с недоверенными хранилищами за счёт разработки мобильного приложения для защищённого хранения пользовательских данных (Wallenc) без собственного сервера приложения, с иерархией vault → storage → файлы и клиентским шифрованием.
|
||||
|
||||
Для достижения цели были поставлены следующие *задачи*:
|
||||
+ выполнить анализ предметной области и сравнительный обзор аналогов, сформировать требования к программному продукту;
|
||||
@@ -19,7 +19,7 @@
|
||||
|
||||
*Практическая база.* Работа выполнена в рамках производственной практики в ООО НМФ «Нейротех» (09.02.2026–06.05.2026) по направлению 09.03.04 «Программная инженерия» на кафедре математического обеспечения и применения ЭВМ (МОП ЭВМ). Научный руководитель — Беликов А. Н. (кафедра системного анализа и телекоммуникаций, САИТ); руководитель от организации — Алексеев Д. М.
|
||||
|
||||
*Научная новизна* заключается в сочетании универсальной модели vault, клиентского шифрования и адаптерного доступа к разным типам хранилищ без собственного сервера приложения, с проектным контуром синхронизации зашифрованных данных без передачи ключей провайдеру.
|
||||
*Научная новизна* заключается в сочетании единого `VaultsManager`, модели vault/storage, клиентского шифрования и адаптерного доступа к провайдерам без собственного сервера приложения, с проектным контуром синхронизации зашифрованных данных без передачи ключей провайдеру.
|
||||
|
||||
*Практическая значимость* — использование результатов при дальнейшей разработке продукта и в учебных проектах по мобильной разработке и информационной безопасности.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user