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