Черновик ПЗ
This commit is contained in:
131
Report/includes/ch01.typ
Normal file
131
Report/includes/ch01.typ
Normal file
@@ -0,0 +1,131 @@
|
||||
#import "common.typ": pz-fig, pz-table
|
||||
|
||||
= Анализ требований и предметной области
|
||||
|
||||
== Анализ предметной области
|
||||
|
||||
В рамках анализа предметной области рассмотрены подходы к хранению чувствительных данных в мобильных приложениях и облачных хранилищах. Выделены требования: конфиденциальность при хранении и передаче; отсутствие необходимости доверять инфраструктуре хранилища; устойчивость к компрометации удалённого провайдера; разделение логики хранения и криптографической защиты; удобные сценарии создания хранилища, шифрования, открытия и работы с содержимым.
|
||||
|
||||
Сформирован вывод о приоритете клиентских криптографических механизмов, унифицированного доступа к разным типам хранилищ и архитектуры с чётким разделением слоёв.
|
||||
|
||||
Рассмотрены угрозы STRIDE в применении к клиентскому хранилищу: подмена файлов на диске провайдера (tampering) нейтрализуется шифрованием; утечка метаданных минимизируется за счёт шифрования имён путей (опция `encryptPath`); отказ в обслуживании облака не блокирует локальный доступ при наличии копии vault. Модель доверия: пользователь доверяет только собственному устройству и корректности реализации криптомодуля; облако и сеть считаются активными противниками для ciphertext.
|
||||
|
||||
Контекст взаимодействия участников показан на рисунке @fig-14.
|
||||
|
||||
#pz-fig("fig_14_context_system.png", [Контекстная диаграмма: пользователь, приложение Wallenc и внешний провайдер], "fig-14")
|
||||
|
||||
== Разработка требований к программному продукту
|
||||
|
||||
=== Назначение и цели создания системы
|
||||
|
||||
*Назначение* системы Wallenc — предоставление пользователю мобильного клиента для управления локальными и удалёнными vault с обязательным клиентским шифрованием содержимого до выгрузки во внешнее хранилище.
|
||||
|
||||
*Цели создания*: обеспечить единую модель хранилищ; минимизировать доверие к провайдеру; поддержать расширение списка провайдеров через адаптеры; сохранить метаданные и состояние приложения в локальной БД без хранения пользовательского контента в открытом виде.
|
||||
|
||||
=== Функциональные требования
|
||||
|
||||
Функциональные требования сведены в таблице @tbl-req.
|
||||
|
||||
#pz-table(
|
||||
[Свод функциональных требований],
|
||||
2,
|
||||
table.header([Код], [Требование]),
|
||||
[ФР-1], [Создание, просмотр, переименование и удаление локальных vault],
|
||||
[ФР-2], [Включение шифрования vault, проверка ключа, открытие и закрытие зашифрованного представления],
|
||||
[ФР-3], [Просмотр и операции с файлами через абстракцию хранилищ; текстовые секреты и 2FA в vault],
|
||||
[ФР-4], [OAuth-авторизация во внешнем провайдере (Яндекс), учёт удалённых vault],
|
||||
[ФР-5], [Синхронизация: группы хранилищ, журнал коммитов, фоновый Worker без передачи ключей],
|
||||
[ФР-6], [Очередь фоновых задач: шифрование, синхронизация, отображение прогресса],
|
||||
) <tbl-req>
|
||||
|
||||
==== Управление локальными vault
|
||||
|
||||
Пользователь создаёт vault, просматривает список, переименовывает и удаляет хранилища. Служебные каталоги и системные пути не отображаются в пользовательском представлении.
|
||||
|
||||
==== Шифрование и открытие зашифрованного vault
|
||||
|
||||
При включении шифрования формируются параметры `StorageEncryptionInfo`; открытие выполняется только после успешной проверки ключа. Повторное шифрование одного vault до завершения предыдущей операции блокируется.
|
||||
|
||||
==== Работа с содержимым vault
|
||||
|
||||
Операции чтения и записи выполняются через единый интерфейс файлового доступа независимо от типа хранилища.
|
||||
|
||||
==== Удалённые хранилища и авторизация во внешних провайдерах
|
||||
|
||||
Реализован поток OAuth 2.0 для Яндекса @oauth-rfc6749 @yandex-oauth (рис. @fig-20).
|
||||
|
||||
#pz-fig("fig_20_oauth_sequence.png", [Диаграмма последовательности OAuth Яндекс], "fig-20")
|
||||
|
||||
==== Синхронизация зашифрованных данных
|
||||
|
||||
Спроектирован механизм фоновой синхронизации: в Room хранятся записи с UUID хранилищ; по таймеру запускается сервис, сравнивающий истории коммитов локального и удалённого представления без передачи ключей на сервер провайдера (рис. @fig-01–@fig-03).
|
||||
|
||||
=== Нефункциональные требования
|
||||
|
||||
К системе предъявляются требования по производительности (асинхронные операции на Coroutines), безопасности (AES на клиенте, минимизация утечек через имена путей), расширяемости (модульная структура Gradle) и устойчивости к гонкам при длительных операциях шифрования.
|
||||
|
||||
=== Требования к программно-аппаратной платформе
|
||||
|
||||
Минимальная платформа — Android с поддержкой Jetpack Compose; для OAuth и удалённых операций требуется сетевое подключение. Объём оперативной памяти должен быть достаточен для фоновых задач шифрования и Room.
|
||||
|
||||
== Аналоги
|
||||
|
||||
=== Аналог Google Files Secure Folder
|
||||
|
||||
Google Files Secure Folder локально прячет и защищает файлы в отдельной папке по PIN или графическому ключу внутри Android @google-secure-folder. Пользователь получает понятный «сейф» без настройки облака, однако сценарий ограничен устройством: отсутствует полноценная кроссплатформенная синхронизация зашифрованного vault между провайдерами, а модель хранилища не универсальна для подключения внешних API.
|
||||
|
||||
=== Аналог Proton Pass / Proton Drive
|
||||
|
||||
Экосистема Proton обеспечивает end-to-end шифрование для паролей, заметок и файлов с облачной синхронизацией. Для Wallenc релевантен опыт прозрачной для пользователя защиты и синхронизации, однако продукт жёстко привязан к инфраструктуре Proton, часть функций и объёмов зависит от тарифа, а роль «универсального клиента» к произвольному внешнему хранилищу ограничена.
|
||||
|
||||
=== Аналог Bitwarden
|
||||
|
||||
Менеджер секретов с шифрованием и синхронизацией. Ограничения: ориентация на учётные данные, а не файловый vault @bitwarden-help.
|
||||
|
||||
=== Аналог Cryptomator
|
||||
|
||||
Клиентское шифрование файловых vault в облаке (zero-knowledge). Ограничения: фокус на файлах, ограничения интеграций по платформам @cryptomator-docs.
|
||||
|
||||
=== Сводная оценка
|
||||
|
||||
#pz-table(
|
||||
[Сравнительная оценка аналогов],
|
||||
6,
|
||||
table.header([Критерий], [Secure Folder], [Proton], [Bitwarden], [Cryptomator], [Wallenc]),
|
||||
[Собственный backend приложения], [—], [+], [+/−], [—], [—],
|
||||
[E2E / клиентское шифрование], [+/−], [+], [+], [+], [+],
|
||||
[Файловый vault], [+], [+], [−], [+], [+],
|
||||
[OAuth внешнего провайдера], [−], [+/−], [+/−], [+/−], [+],
|
||||
[Переносимость провайдеров], [−], [−], [+/−], [+], [+],
|
||||
[Unit-тесты без сервера], [н/д], [н/д], [+/−], [+/−], [+ (68)],
|
||||
) <tbl-analog>
|
||||
|
||||
Обзор подтверждает актуальность концепции Wallenc: безопасность без собственного сервера и переносимая архитектура хранилищ.
|
||||
|
||||
== Стек технологий
|
||||
|
||||
Для реализации выбраны Kotlin, Android SDK, Jetpack Compose, Coroutines/Flow, Hilt, Room, AES на клиенте; модульная структура: `:app`, `:domain`, `:usecases`, `:ui`, `:domain-vault`, `:infrastructure-android`, `:vault-contracts`, `:task-runtime` @kotlin-docs @compose-docs @room-docs @hilt-docs @android-arch.
|
||||
|
||||
*Kotlin* обеспечивает выразительную доменную модель и безопасность типов. *Jetpack Compose* декларативно описывает UI и состояние экранов vault. *Coroutines/Flow* используются для асинхронного шифрования, обращения к DAO и отображения прогресса без блокировки главного потока. *Hilt* связывает реализации интерфейсов domain с Android-инфраструктурой. *Room* персистентно хранит метаданные. Криптографические операции выполняются в доменном слое с опорой на стандартные API Java/Android и рекомендации NIST по AES @nist-aes.
|
||||
|
||||
Выбор стека согласован с целями практики: все компоненты поддерживаются Google и сообществом, документированы на русском и английском языках, применимы в промышленной разработке мобильных приложений.
|
||||
|
||||
== Обзор методов и подходов к защите данных в мобильных приложениях
|
||||
|
||||
=== Клиентское шифрование и модель zero-knowledge
|
||||
|
||||
Данные шифруются до отправки во внешнее хранилище; провайдер не получает ключ расшифрования. Используется AES @nist-aes; проверка ключа выполняется через `Encryptor.checkKey` без расшифровки всего содержимого.
|
||||
|
||||
=== Авторизация и взаимодействие с внешними провайдерами без собственного сервера
|
||||
|
||||
Применяется OAuth 2.0: токены доступа хранятся локально в Room (`DbYandexAccount`); ключи шифрования не передаются на сторону провайдера @oauth-rfc6749.
|
||||
|
||||
== Обзор рынка и обоснование выбора решения Wallenc
|
||||
|
||||
Рынок мобильных хранилищ демонстрирует поляризацию: закрытые экосистемы с удобным UX (Proton, Google) и открытые криптоклиенты с ручной настройкой (Cryptomator). Wallenc занимает промежуточную нишу — *мобильный zero-knowledge vault* с OAuth к популярному провайдеру (Яндекс) и расширяемой регистрацией типов хранилищ. Для корпоративного заказчика (Нейротех) важны: отсутствие затрат на сервер приложения, возможность аудита кода, формализованное тестирование (68 unit-тестов, см. гл. 5).
|
||||
|
||||
Перспективы коммерциализации связаны не с продажей облака, а с лицензированием клиента или внутренним внедрением. Барьер входа — ответственность пользователя за ключ; в ПЗ это отражено в руководстве пользователя (прил. Б) и предупреждениях в UI.
|
||||
|
||||
== Формирование технического задания
|
||||
|
||||
Структура ТЗ оформлена по ГОСТ 7.32–2017: цели, этапы, функциональные и нефункциональные требования, порядок приёмки. Приоритет отдан ядру хранения и шифрования; расширения (2FA, текстовые секреты, синхронизация) зафиксированы как дополнительные функции второго этапа практики. Полный текст ТЗ — в приложении Б.
|
||||
Reference in New Issue
Block a user