Инвестор показывает портфель чужому сервису: свой учёт активов на сервере

MAATRIX

Чтобы понимать, как растёт портфель, инвестор рано или поздно заводит трекер — таблицу или специализированный сервис, куда вносит все позиции: брокерские счета, криптокошельки, недвижимость, вклады. Удобно, пока не задумаешься, что именно вы туда вносите: точный список активов, суммы, даты покупок, иногда — привязку к брокерскому счёту через API-ключ на чтение. Вся эта картина лежит на серверах компании, о политике безопасности которой вы знаете ровно то, что написано в её маркетинговых материалах. Ниже — как собрать тот же учёт у себя, без раскрытия состава портфеля третьей стороне и без ограничений бесплатного тарифа.

Что вы отдаёте стороннему трекеру портфеля

Разберём, что именно уходит наружу, когда вы заводите портфель в облачном сервисе учёта активов.

Во-первых, это структура портфеля целиком: какие классы активов вы держите, в каких пропорциях, насколько диверсифицированы или наоборот сконцентрированы в одном секторе. Такая картина сама по себе — ценные данные: по ней видно ваш риск-профиль, горизонт инвестирования, а иногда и приблизительный размер капитала.

Во-вторых, часть сервисов просят подключить брокерский счёт или биржевой кошелёк через API-ключ, пусть и с правами только на чтение. Ключ на чтение не даёт списать средства, но даёт увидеть полную историю операций — когда и что вы покупали, по какой цене выходили, как реагировали на просадки. Это профиль вашего поведения как инвестора, а не просто список цифр.

В-третьих — это вопрос доверия к конкретной компании и её субподрядчикам. У сервиса может быть безупречная публичная репутация, но вы не увидите ни его внутренние логи доступа, ни то, кто из сотрудников теоретически может открыть вашу карточку, ни то, как обрабатывается инцидент, если база утечёт. История цифровых сервисов знает достаточно случаев утечек данных пользователей — от бирж до финтех-приложений, — чтобы не считать эту компанию застрахованной по умолчанию просто потому, что она про инвестиции.

Отдельно стоит вопрос юрисдикции и доступности: если сервис зарегистрирован за пределами России, а у вас российский IP или карта, риск потерять доступ к собственному учёту в любой момент — не гипотетический. Ваши данные при этом остаются у них, а не у вас.

Где начинаются ограничения бесплатных версий

Даже если вы закрываете глаза на вопрос приватности, бесплатные тарифы трекеров портфеля почти всегда режут функциональность по трём осям.

Первая — число позиций. Типичный бесплатный план ограничивает портфель условными 10-20 активами: как только у вас акции, ETF, облигации, пара криптовалют и немного недвижимости для диверсификации, лимит упирается в потолок за один вечер настройки.

Вторая — глубина истории. Часто бесплатный тариф хранит транзакции без ограничения по числу, но урезает аналитику: нет расчёта доходности с учётом взносов и выводов (XIRR/TWR), нет разбивки по секторам и валютам, нет экспорта в удобном формате.

Третья — число источников данных. Ручной ввод обычно бесплатен, а вот автоматическая синхронизация с брокером или биржей через API нередко переезжает в платную подписку, причём цена растёт с числом подключаемых счетов.

Платная подписка снимает эти ограничения, но не снимает вопрос из предыдущего раздела — вы просто платите за то, чтобы отдавать те же данные без урезаний. Собственный сервер решает оба вопроса разом: лимитов нет, потому что база данных ваша, а раскрытия нет, потому что сервер тоже ваш.

Что даёт свой сервер вместо чужого сервиса

Идея простая: разворачиваете приложение для учёта личных финансов или таблично-табличную базу данных на арендованном сервере, подключаетесь к нему только вы — по защищённому каналу, без публичного доступа. Данные хранятся на диске, который контролируете вы, бэкапы делаете вы, и никто третий не видит состав портфеля целиком.

Что это даёт на практике:

• Полная приватность структуры портфеля. Ни один сторонний сервис не получает список ваших активов и сумм — только вы и, если решите дать доступ, доверенные люди (например, семейный финансовый консультант).
• Отсутствие лимитов. Число позиций, счетов, валют и глубина истории ограничены только диском сервера, а не тарифным планом.
• Полный контроль над бэкапами. Вы сами решаете, где хранится резервная копия базы — и не зависите от того, восстановит ли поддержка сервиса вашу историю, если она случайно всё удалит.
• Независимость от доступности сервиса. Сервер работает, пока вы платите за аренду и поддерживаете систему — а не пока существует компания-разработчик трекера и её решение обслуживать пользователей из России.
• Гибкость под свою модель учёта. Можно завести произвольные категории активов — от акций до доли в семейном бизнесе или физического золота, — которые ни один готовый трекер не предусмотрел.

Обратная сторона — ответственность за настройку и поддержку теперь на вас: обновления, бэкапы, доступ. Это не одна кнопка «зарегистрироваться», а система, которую нужно один раз собрать и потом изредка обслуживать. Дальше — как это сделать без лишних сложностей.

Инструменты для учёта: готовые приложения и связка из простых частей

Есть два разумных пути, и выбор зависит от того, сколько готовой логики вам нужно из коробки.

Путь первый — готовое приложение для личных финансов. Такие системы изначально не заточены под портфель ценных бумаг, но хорошо считают активы, пассивы, чистую стоимость (net worth) во времени и умеют работать с несколькими валютами и счетами. Портфель описывается как набор активов с ручным или полуавтоматическим обновлением стоимости. Из плюсов — готовые отчёты, история изменений капитала, разбивка по категориям без необходимости писать SQL-запросы самому. Из минусов — специфику именно биржевого портфеля (доходность по методу XIRR, разбивку по секторам и странам) такие системы обычно не считают, это надстройка руками поверх базовых данных. Подробно о развёртывании подобной системы через Docker Compose есть отдельный разбор — Firefly III в Docker Compose.

Путь второй — связка база данных + таблица-конструктор. PostgreSQL как хранилище плюс визуальный слой в виде no-code-таблицы поверх неё (аналог связки «Excel плюс база») даёт полную свободу в схеме: вы сами описываете, какие поля нужны для каждого класса активов, добавляете формулы для расчёта текущей стоимости, строите сводные представления по валютам или брокерам. Это больше работы на старте, зато система растёт вместе с вашим портфелем без переезда на другой инструмент. Пример разворачивания такого конструктора — Grist в Docker Compose.

Путь третий, для тех, кто уже ведёт учёт сделок. Если вы активно торгуете и параллельно с портфелем хотите видеть статистику по сделкам — среднюю доходность, win rate, поведение на просадках, — обычно это отдельная система, журнал сделок, а не трекер портфеля. Если это ваш случай, есть смежный разбор именно под такую задачу — журнал сделок трейдера на своём сервере. Портфель и журнал сделок можно развернуть рядом на одном сервере — они не конкурируют за ресурсы при личном использовании.

Для большинства частных инвесторов, которые хотят видеть общую картину капитала без ручного пересчёта в Excel каждую неделю, разумный старт — первый или второй путь. Дальше разберём, как это поднять технически.

Разворачиваем систему на сервере: пошагово

Возьмём для примера путь с готовым приложением для учёта личных финансов на Docker Compose — он быстрее всего даёт рабочую систему.

Шаг 1. Минимальные требования к серверу. Для личного использования (один пользователь, портфель на несколько десятков-сотен позиций) достаточно 1-2 vCPU, 2 ГБ RAM и SSD от 20 ГБ — приложение и база данных под личный учёт не создают серьёзной нагрузки. Если параллельно планируете держать журнал сделок или дашборд аналитики, закладывайте запас в RAM.

Шаг 2. Устанавливаем Docker и Docker Compose на чистый сервер (Ubuntu 24.04 или Debian 12 — самые предсказуемые варианты для такой задачи):

curl -fsSL https://get.docker.com | sh
sudo systemctl enable --now docker
docker compose version

Шаг 3. Готовим docker-compose.yml. Минимальный пример для приложения личного учёта финансов с PostgreSQL в качестве базы:

services:
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: portfolio
      POSTGRES_USER: portfolio
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    volumes:
      - ./data/db:/var/lib/postgresql/data
    secrets:
      - db_password

  app:
    image: your-registry/portfolio-app:latest
    restart: unless-stopped
    depends_on:
      - db
    environment:
      DB_HOST: db
      DB_DATABASE: portfolio
      DB_USERNAME: portfolio
      DB_PASSWORD_FILE: /run/secrets/db_password
      APP_URL: https://127.0.0.1:8443
    ports:
      - "127.0.0.1:8443:8080"
    secrets:
      - db_password

secrets:
  db_password:
    file: ./secrets/db_password.txt

Ключевая деталь — порт приложения 127.0.0.1:8443:8080 вместо 0.0.0.0:8443:8080. Это значит, что интерфейс слушает только локально на сервере и не торчит наружу в интернет. Конкретный образ и имена переменных зависят от выбранного приложения — сверяйтесь с его официальной документацией, названия параметров у разных проектов отличаются.

Шаг 4. Доступ только через приватный канал. Раз порт закрыт от внешнего мира, попасть в интерфейс можно только через VPN до сервера или SSH-туннель:

ssh -N -L 8443:127.0.0.1:8443 user@your-server-ip

После этого интерфейс открывается в браузере по https://127.0.0.1:8443 — но физически трафик идёт через зашифрованный SSH-канал, а не напрямую в интернет. Более удобный вариант для регулярного доступа с телефона и ноутбука — поднять WireGuard между вашими устройствами и сервером и открывать порт приложения только для VPN-подсети.

Шаг 5. SSH только по ключу и с двухфакторной защитой. Раз это единственная дверь к финансовым данным, стоит закрыть вход по паролю и добавить второй фактор на саму SSH-сессию.

Безопасность и бэкапы: то, что легко забыть

Собственный сервер снимает вопрос доверия к третьей стороне, но добавляет вам обязанность не потерять данные самому — это тот риск, о котором облачный сервис заботился за вас.

Шифрование диска. Если сервер физически или логически доступен третьим лицам (например, вы арендуете VPS, а не выделенный сервер), диск стоит шифровать — тогда даже при компрометации инфраструктуры хостера содержимое базы не читается напрямую. Что именно защищает шифрование диска, а что нет, разобрано в статье шифрование дисков: что защищает — это полезно прочитать до того, как вы решите, что «диск зашифрован, значит всё в порядке».

Регулярный бэкап базы. База с историей портфеля — единственный источник правды о том, что вы покупали и когда. Потерять её без бэкапа означает потерять историю целиком. Простой вариант — ежедневный дамп PostgreSQL с отправкой в зашифрованном виде на отдельное хранилище:

#!/bin/bash
docker exec db pg_dump -U portfolio portfolio | gzip > /backups/portfolio_$(date +%F).sql.gz
find /backups -name "portfolio_*.sql.gz" -mtime +30 -delete

Для более надёжной схемы с шифрованием бэкапа и хранением вне сервера стоит взглянуть на выделенные инструменты резервного копирования, а не полагаться на самописный cron-скрипт как на постоянное решение.

Обновления приложения и базы. Личный финансовый трекер — не публичный сервис с тысячами пользователей, поэтому спешить с обновлениями в день релиза не нужно, но и оставлять систему без обновлений годами тоже не стоит: часть релизов закрывает реальные уязвимости. Разумный ритм — проверять обновления раз в один-два месяца и накатывать их на тестовой копии перед продакшеном, если данных накопилось много.

Что не нужно делать. Не открывайте порт приложения в интернет «для удобства», даже с паролем на входе — пароль от веб-интерфейса и закрытый порт снаружи это разные уровни защиты, и второй прикрывает от гораздо большего числа сценариев атаки, чем первый. Не храните файл с бэкапом базы в общедоступном облачном хранилище без шифрования — вы попросту вернётесь к исходной проблеме, только менее контролируемым способом.

Частые вопросы