Черновик ПЗ

Report/Другие отчёты Wallenc/Отчёт 1 этап.md

@@ -0,0 +1,122 @@
+# Отчёт по 1-му предварительному этапу производственной практики  
+**Проект:** Wallenc — универсальный кошелёк для безопасного хранения данных на небезопасных хранилищах без собственного сервера.
+
+## Введение
+
+На первом этапе практики была выполнена аналитическая и проектная подготовка к разработке мобильного приложения Wallenc. Цель этапа — сформировать техническую основу проекта: определить предметную область, выбрать архитектурный подход, описать требования к системе и зафиксировать технологические решения для последующей реализации.
+
+Ключевая идея проекта заключается в том, что безопасность пользовательских данных обеспечивается на стороне клиента: данные шифруются до отправки во внешнее хранилище, а расшифрование выполняется только в приложении при наличии корректного ключа. Это позволяет использовать небезопасные или недоверенные хранилища без потери конфиденциальности и без развертывания собственного серверного backend.
+
+## Анализ предметной области
+
+В рамках анализа предметной области рассмотрены подходы к хранению чувствительных данных в мобильных приложениях и в облачных хранилищах. Выделены основные требования к таким системам:
+
+- конфиденциальность данных при хранении и передаче;
+- отсутствие необходимости доверять инфраструктуре хранилища;
+- устойчивость к компрометации удалённого провайдера;
+- разделение логики хранения и логики криптографической защиты;
+- удобный пользовательский сценарий: создание хранилища, шифрование, открытие, работа с содержимым.
+
+Сформирован вывод, что для проекта Wallenc приоритетны клиентские криптографические механизмы, унифицированный доступ к разным типам хранилищ и архитектура с чётким разделением слоёв.
+
+## Обзор аналогичных решений
+
+### Аналоги
+
+- **Google Files Secure Folder**  
+  Что делает: локально прячет и защищает файлы в папке по PIN/Pattern внутри Android.  
+  Минусы: по сути только локальный “сейф” (без нормальной кроссплатформенной синхронизации), ограниченные сценарии переноса между устройствами, не про универсальную модель vault для разных хранилищ.
+
+- **Proton Pass / Proton Drive**  
+  Что делает: end-to-end экосистема для паролей, заметок и файлов с облачной синхронизацией.  
+  Минусы: привязка к экосистеме Proton, часть полезных сценариев/объёма и функций зависит от тарифа, меньше гибкости как “универсальный клиент” под разные внешние хранилища.
+
+- **Bitwarden**  
+  Что делает: менеджер паролей/секретов с шифрованием, синхронизацией, офлайн-доступом и self-host вариантом.  
+  Минусы: ориентирован в первую очередь на учетные данные и секреты, а не на общий файловый vault; офлайн-сценарии ограничены (часть операций требует синхронизации/сервера).
+
+- **Cryptomator**  
+  Что делает: клиентское шифрование файловых vault перед хранением в облаке (zero-knowledge подход).  
+  Минусы: фокус именно на шифровании файлов, а не на расширенной модели “кошелька” с собственной мета-логикой и UI-сценариями; есть ограничения интеграций в зависимости от платформы/сборки и провайдера.
+
+Проведён обзор классов решений (secure-folder приложения, менеджеры секретов, облачные клиенты с zero-knowledge подходом). По результатам обзора отмечены типовые сильные и слабые стороны:
+
+**Преимущества аналогов:**
+
+- понятный пользовательский сценарий хранения;
+- готовые механизмы шифрования файлов;
+- интеграция с несколькими хранилищами.
+
+
+**Ограничения аналогов:**
+
+- зависимость от собственного backend или закрытой инфраструктуры;
+- недостаточная прозрачность модели ключей;
+- ограниченная переносимость между провайдерами.
+
+
+Это подтвердило актуальность выбранной концепции Wallenc: безопасность без собственного сервера, с переносимой архитектурой хранилищ.
+
+## Формирование технического задания
+
+На основании анализа подготовлена структура ТЗ в логике ГОСТ 7.32–2017: определены цели, этапы работ, основные и дополнительные задачи, ожидаемые результаты и направления тестирования.  
+ТЗ синхронизировано с фактическим направлением проекта: приоритет на ядро системы хранения/шифрования и поэтапное расширение функциональности.
+
+## Изучение архитектурных подходов
+
+Для проекта принят архитектурный подход **MVVM + Clean Architecture**:
+
+- **Domain**: интерфейсы и use-case логика (операции над vault и шифрованием);
+- **Data**: реализации хранилищ, слой доступа к данным, локальная БД, криптографические адаптеры;
+- **Presentation**: UI-слой, навигация, состояния экранов, ViewModel.
+
+Такое разделение снижает связность, упрощает тестирование и позволяет независимо развивать локальные и удалённые провайдеры.
+
+## Проектирование структуры системы
+
+Спроектирована клиентская система, в которой:
+
+- локальный vault является базовой реализацией хранения;
+- зашифрованное представление открывается через отдельный менеджер;
+- операции чтения/записи выполняются через абстракции доступа к файлам;
+- служебные данные (метаданные, связи ключей и хранилищ) отделены от пользовательского содержимого.
+
+Подход ориентирован на дальнейшее подключение удалённых провайдеров (например, облачных API) без изменения доменной модели.
+
+## Проектирование структуры базы данных
+
+Определена структура локальной БД для служебной информации приложения:
+
+- хранение соответствий между исходным хранилищем и его зашифрованным представлением;
+- хранение метаданных хранилищ;
+- поддержка восстановления состояния при запуске приложения.
+
+БД используется как внутренний механизм управления состоянием vault и не хранит пользовательские данные в открытом виде.
+
+## Выбор технологий
+
+Для реализации первого этапа и последующей разработки определён следующий стек:
+
+- **Kotlin**, **Android SDK**;
+- **Jetpack Compose** (UI);
+- **Coroutines/Flow** (асинхронность и реактивные потоки);
+- **Hilt** (dependency injection);
+- **Room** (локальная БД);
+- криптографические механизмы на стороне клиента (AES-шифрование данных и служебных атрибутов);
+- модульная структура проекта (`app`, `presentation`, `domain`, `data`).
+
+Выбранный стек соответствует целям проекта и обеспечивает масштабируемость.
+
+## Дополнительные исследования этапа
+
+На первом этапе также проработаны дополнительные направления:
+
+- варианты OAuth-аутентификации при работе с удалёнными провайдерами без собственного сервера;
+- подходы к безопасной работе с ключами шифрования и проверке корректности ключа;
+- защита структуры данных (скрытие служебных файлов/директорий, минимизация утечек через имена и пути);
+- предварительный план тестирования (unit, интеграционные и UI-сценарии).
+
+## Итоги первого этапа
+
+По результатам первого этапа сформирована целостная проектная база для разработки Wallenc: определены предметная область, архитектурная модель, структура данных, технологический стек и требования к безопасности.  
+Подготовленные материалы позволяют переходить к реализации следующего этапа — построению функционального ядра приложения и расширению сценариев работы с хранилищами, включая синхронизацию зашифрованных данных с удалёнными провайдерами.