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

Отчёт по 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: определены предметная область, архитектурная модель, структура данных, технологический стек и требования к безопасности.
Подготовленные материалы позволяют переходить к реализации следующего этапа — построению функционального ядра приложения и расширению сценариев работы с хранилищами, включая синхронизацию зашифрованных данных с удалёнными провайдерами.