Files
abdristus/docs/PRD.md

15 KiB
Raw Permalink Blame History

Product Requirements Document (PRD): Кроссплатформенный Менеджер Паролей

1. Обзор продукта

Локальный, строго типизированный кроссплатформенный менеджер паролей с поддержкой многопользовательского режима, надежным шифрованием данных "в покое" (data-at-rest) и подготовленной архитектурой для будущей облачной синхронизации и интеграции с браузерными расширениями.

Технологический стек:

  • Backend / Ядро: Rust (Tauri) — отвечает за криптографию, работу с ФС, БД и системными API (биометрия).
  • Frontend: Angular (TypeScript) — отвечает за UI, строгую ООП-архитектуру, управление состояниями и валидацию.
  • База данных: SQLite (через Rust).

2. Архитектура безопасности и хранения данных

Безопасность строится на принципе нулевого доверия к окружению (Zero Trust Local Storage). Даже при полной компрометации устройства (кража диска или копирование файла БД), злоумышленник не должен получить доступ к данным без знания Мастер-пароля.

2.1. Криптографическая схема

  • Деривация ключа (Key Derivation): Мастер-пароль пользователя никогда не хранится в явном виде. При вводе он пропускается через функцию Argon2id (устойчивую к атакам на GPU/ASIC) вместе со случайной солью. Результатом является Ключ Шифрования Данных (Data Encryption Key - DEK).
  • Шифрование полезной нагрузки: Для шифрования самих паролей и заметок используется алгоритм XChaCha20-Poly1305 (AEAD — Authenticated Encryption with Associated Data). Он быстрее и безопаснее стандартного AES на программном уровне и проверяет целостность данных.
  • Что шифруется: Логины, пароли, заметки и привязанные почты шифруются. Метаданные (UUID записи, дата создания) можно оставить открытыми для упрощения синхронизации в будущем.

2.2. База данных (SQLite) и многопользовательский режим

  • Каждый пользователь имеет свой отдельный файл базы данных (например, vault_<user_uuid>.sqlite). Это изолирует данные пользователей друг от друга и радикально упрощает будущую синхронизацию (не нужно фильтровать чужие записи).
  • Схема таблицы accounts (задел под синхронизацию):
    • id (TEXT, UUIDv4) — Первичный ключ.
    • service_name (TEXT) — Название сервиса.
    • encrypted_data (BLOB) — Зашифрованный JSON с логином, паролем, ссылкой и тегами.
    • nonce (BLOB) — Уникальный вектор инициализации для расшифровки XChaCha20.
    • updated_at (INTEGER) — Unix timestamp последнего изменения. Критично для будущей синхронизации (разрешение конфликтов LWW - Last Write Wins).
    • is_deleted (BOOLEAN) — Soft-delete (мягкое удаление). При удалении запись не стирается, а помечается удаленной, чтобы при будущей синхронизации другие устройства узнали об удалении.

2.3. Биометрия (Touch ID / Windows Hello)

  • Логика работы: При успешном вводе Мастер-пароля, полученный ключ DEK шифруется средствами операционной системы (через системный Keyring/Связку ключей/Windows Credential Manager) и сохраняется там.
  • При следующем входе приложение запрашивает биометрическую аутентификацию через системный API (в Rust для этого используются крейты keyring или платформозависимые вызовы). При успехе ОС отдает приложению DEK, и база расшифровывается без ввода пароля.

3. Frontend Архитектура (Angular + OOP)

Код должен быть максимально модульным, тестируемым и следовать принципам SOLID.

3.1. Основные слои (Dependency Injection)

  1. Domain Models (Модели данных): Классы Account, UserVault, Tag. Модели не содержат бизнес-логики, только структуру и методы-геттеры/сеттеры.
  2. Services (Бизнес-логика):
    • TauriIpcService: Абстракция над window.__TAURI__.invoke. Реализует паттерн Adapter, изолируя Angular от специфики Tauri.
    • CryptoStrategyService: Реализует паттерн Strategy для выбора метода авторизации (Мастер-пароль или Биометрия).
    • VaultService: Управляет состоянием расшифрованных паролей в оперативной памяти (в виде RxJS BehaviorSubject). При блокировке приложения этот сервис немедленно очищает данные из памяти.
  3. Components (UI): Разделены на "Умные" (Smart/Container) — общаются с сервисами, и "Глупые" (Dumb/Presentational) — только отображают данные (кнопки, формы ввода, карточки паролей).

3.2. Паттерны проектирования в UI

  • Observer (через RxJS): Компоненты подписываются на изменения в VaultService. Если в фоновом режиме (или через окно быстрого добавления) добавился пароль, список в главном окне обновляется реактивно.
  • Visitor: Для будущей реализации экспорта (в CSV, JSON). Класс Account принимает "посетителя" CsvExportVisitor, который знает, как правильно отформатировать поля аккаунта для выгрузки, не нарушая инкапсуляцию самого аккаунта.

4. Подготовка к будущим фичам (Future-Proofing)

4.1. Задел для облачной синхронизации

Так как на старте используется локальный SQLite с полями updated_at и is_deleted (Soft-delete), в будущем реализация синхронизации сведется к написанию фонового процесса (в Rust), который будет:

  1. Запрашивать у сервера все записи с updated_at больше, чем время последней синхронизации.
  2. Отправлять на сервер локальные записи, которые изменились с момента последней синхронизации.
  3. Сервер (когда он появится) будет просто передавать зашифрованные BLOB-ы (E2E шифрование), ничего не зная о содержимом.

4.2. Задел для браузерного расширения

Чтобы расширение могло общаться с десктопным приложением (забирать пароли и сохранять новые), приложение на Tauri должно выступать в роли сервера.

  • Архитектурное решение: В ядре Rust поднимается легковесный локальный WebSocket-сервер или используется механизм Native Messaging (стандарт для Chrome/Firefox).
  • Все запросы от браузера проверяются на подлинность (расширение и десктопное приложение обмениваются криптографическими токенами при первичном сопряжении). На текущем этапе (MVP) этот сервер не реализуется, но API-функции для получения конкретного пароля по URL сайта на стороне Rust проектируются заранее, чтобы их можно было легко обернуть в сетевой интерфейс позже.

5. Требования к UI / UX

  • Горячие клавиши (Global Shortcuts): Окно "быстрого добавления/поиска" (Spotlight-like) вызывается системным шорткатом (например, Cmd/Ctrl + Shift + Space). Работает глобально, даже если главное окно закрыто. Реализуется через tauri-plugin-global-shortcut.
  • Генератор паролей: Интегрирован прямо в форму создания аккаунта. При фокусе на поле "Пароль" предлагается сгенерированная строка. Сложность (длина, спецсимволы) настраивается в параметрах.
  • Автоматическая блокировка: По таймеру бездействия (настраивается пользователем, например, 5 минут) или при блокировке операционной системы приложение уничтожает расшифрованные данные из памяти Angular и требует повторного сканирования биометрии или ввода пароля.

6. Структура проекта (Репозиторий и src-файлы)

Проект строится по принципу монорепозитория, разделенного на два изолированных контекста: системный бэкенд (Tauri/Rust) и фронтенд-интерфейс (Angular).

6.1. Backend: Ядро на Rust (/src-tauri/src/)

Структура следует принципам чистого кода, жестко отделяя инфраструктуру Tauri от чистой бизнес-логики и работы с базой данных.

  • main.rs — Точка входа. Регистрация плагинов, глобальных шорткатов, инициализация БД и запуск Tauri-приложения.
  • commands/ — Обработчики вызовов от фронтенда (Tauri IPC Commands). Здесь функции получают аргументы от UI и делегируют работу ядру.
    • auth.rs (апи для авторизации и сканирования биометрии)
    • vault.rs (сохранение и получение записей)
  • core/ — Изолированная бизнес-логика, которая ничего не знает про Tauri (максимально тестируемый код).
    • crypto.rs (реализация шифрования XChaCha20-Poly1305 и деривации ключей Argon2id)
    • password_gen.rs (генератор надежных паролей)
  • database/ — Слой абстракции над SQLite.
    • schema.sql (миграции базы данных)
    • models.rs (структуры данных Rust для маппинга таблиц БД)
    • repository.rs (SQL-запросы и транзакции)
  • events/ — Система Push-событий (Event-Driven Architecture).
    • emitter.rs (отправка событий system-locked, vault-updated во фронтенд).

6.2. Frontend: Angular App (/src/)

Используется современный подход с Angular Standalone-компонентами (без лишнего бойлерплейта в виде NgModules). Структура директорий базируется на Domain-Driven Design (DDD) для строгого соблюдения принципов ООП.

  • main.ts — Точка входа фреймворка Angular.
  • app/ — Корневая директория логики UI.
    • core/ — Базовая инфраструктура и Сервисы-синглтоны (существуют в единственном экземпляре).
      • services/tauri-event-bus.service.ts (RxJS-адаптер, слушающий события от Rust)
      • services/crypto-strategy.service.ts (паттерн Strategy для авторизации)
      • services/vault.service.ts (хранение расшифрованного стейта в оперативной памяти)
    • models/ — Глобальные TypeScript-интерфейсы и ООП-классы Моделей.
      • account.model.ts (включая методы для валидации и приема паттерна Visitor)
      • user.model.ts
    • shared/ — «Глупые» (Dumb/Presentational) компоненты и UI-кит. Они не содержат бизнес-логики, только принимают данные и отдают события кликов.
      • components/account-card/ (карточка аккаунта)
      • components/password-input/ (компонент поля ввода с индикатором надежности)
    • features/ — «Умные» (Smart) компоненты, разделенные по бизнес-доменам приложения.
      • auth/ (экраны ввода мастер-пароля и биометрии)
      • main-window/ (весь интерфейс главного окна со списком паролей и настройками)
      • spotlight/ (изолированное окно быстрого добавления/поиска, вызываемое горячими клавишами)
  • styles/ — Глобальные стили, Tailwind конфигурации и CSS-переменные темы.
  • assets/ — Статические файлы (локальные шрифты, иконки).