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