ПОЛИТИКА БЕЗОПАСНОСТИ И ЗАЩИТЫ ПЕРСОНАЛЬНЫХ ДАННЫХ

1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Настоящая Политика безопасности и защиты персональных данных (далее — «Политика») разработана в соответствии с:

• Федеральным законом от 27.07.2006 № 152-ФЗ «О персональных данных» (ст. 18.1, 19);
• Постановлением Правительства РФ от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»;
• Постановлением Правительства РФ от 15.09.2008 № 687 «Об утверждении Положения об особенностях обработки персональных данных без использования средств автоматизации»;
• Приказом ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных»;
• Федеральным законом от 14.07.2022 № 266-ФЗ «О внесении изменений в Федеральный закон "О персональных данных"» (требования об уведомлении об инцидентах, вступившие в силу с 01.09.2022).

1.2. Оператором персональных данных является ООО «Время Цифровых Решений» (ИНН 7000028979, ОГРН 1257000006152), 634049, Томская обл., г. Томск, ул. Мичурина, д. 43, info@kopilka.app (далее — «Оператор»).

1.3. Настоящая Политика является внутренним документом Оператора, публикуемым в открытом доступе в целях информирования субъектов персональных данных о принятых мерах защиты, и распространяется на все информационные системы персональных данных (далее — «ИСПДн»), эксплуатируемые Оператором при функционировании сервиса «Копилка».

2. ОПРЕДЕЛЕНИЕ УРОВНЯ ЗАЩИЩЁННОСТИ ИНФОРМАЦИОННОЙ СИСТЕМЫ

2.1. Характеристики ИСПДн

В соответствии с Постановлением Правительства РФ № 1119 Оператор определяет характеристики обрабатываемых персональных данных:

2.2. Обоснование выбора уровня защищённости

Руководствуясь п. 9 Постановления Правительства № 1119, Оператор устанавливает уровень защищённости УЗ-3 (третий уровень) как соответствующий следующей совокупности условий:

• обрабатываются иные персональные данные (не специальные категории и не биометрические);
• субъекты ПДн — лица, не являющиеся сотрудниками Оператора;
• количество субъектов — менее 100 000;
• актуальны угрозы 3-го типа (недекларированных возможностей в системном ПО не выявлено).

Применение более высокого уровня защищённости (УЗ-1 или УЗ-2) не требуется, поскольку отсутствуют основания, предусмотренные пп. 8–11 Постановления № 1119 (специальные категории ПДн, биометрические данные, угрозы 1-го и 2-го типов).

2.3. Актуальные угрозы

Оператором идентифицированы следующие актуальные угрозы безопасности персональных данных:

3. ТЕХНИЧЕСКИЕ МЕРЫ ЗАЩИТЫ

3.1. Защита передачи данных

3.1.1. HTTPS / TLS.
Все соединения между клиентом и сервером осуществляются исключительно по протоколу HTTPS с использованием TLS версий 1.2 и 1.3. Поддержка устаревших протоколов (SSL 3.0, TLS 1.0, TLS 1.1) отключена на уровне конфигурации Nginx.

Применяемые меры:

• принудительное перенаправление HTTP → HTTPS (301 Redirect);
• заголовок HSTS (Strict-Transport-Security) с директивой max-age не менее 31 536 000 секунд (1 год);
• использование актуальных TLS-шифров, соответствующих рекомендациям Mozilla SSL Configuration Generator (профиль Intermediate или Strict).

3.1.2. Защита внешних API-запросов.
Запросы к API банков (Т-Банк, Альфа-Банк) и иным внешним сервисам выполняются через SOCKS5-прокси. Данная мера обеспечивает:

• сокрытие реального IP-адреса сервера Оператора от внешних систем;
• маршрутизацию трафика через контролируемый узел;
• дополнительный уровень изоляции инфраструктуры Оператора.

3.2. Защита данных при хранении

3.2.1. Шифрование банковских токенов.
Сессионные токены Т-Банка и OAuth2-токены Альфа-Банка хранятся в базе данных PostgreSQL исключительно в зашифрованном виде. Для шифрования применяется алгоритм Fernet (AES-128-CBC + HMAC-SHA256) — симметричное шифрование с аутентификацией.

Ключ шифрования (BANK_ENCRYPTION_KEY):

• не хранится в базе данных совместно с зашифрованными данными;
• передаётся в приложение через переменные окружения (environment variables);
• не включается в репозиторий исходного кода, системы логирования и мониторинга;
• подлежит ротации при подозрении на компрометацию.

3.2.2. Хэширование паролей.
Пароли пользователей хранятся исключительно в виде необратимого криптографического хэша. Применяется алгоритм bcrypt (cost factor ≥ 12) или Argon2id (рекомендуемый OWASP для новых систем). Исходный пароль Оператором не хранится, не передаётся и не может быть восстановлен.

3.2.3. Хранение данных в PostgreSQL.
База данных развёрнута на серверах, расположенных на территории Российской Федерации. Доступ к базе данных:

• ограничен сетевым экраном (firewall): принимаются только соединения от приложения, работающего в той же Docker-сети;
• порт PostgreSQL (5432) закрыт для внешних соединений;
• осуществляется от имени отдельной роли с минимально необходимыми привилегиями (принцип least privilege).

3.2.4. Redis (кэш и очереди Celery).
Redis используется для кэширования данных приложения и управления очередями фоновых задач (Celery). В Redis не хранятся персональные данные в открытом виде:

• при необходимости временного кэширования пользовательских данных применяется обезличивание или шифрование;
• доступ к Redis ограничен внутренней Docker-сетью;
• для внешних соединений Redis недоступен.

3.3. Управление аутентификацией и сессиями

3.3.1. JWT-аутентификация.
Система аутентификации построена на основе JSON Web Tokens (JWT) с разделением на два типа токенов:

Короткое время жизни access-токена (15 минут) минимизирует последствия его возможной компрометации: перехваченный токен становится бесполезным в течение короткого времени.

3.3.2. При выходе пользователя из системы refresh-токен немедленно инвалидируется на сервере. Список инвалидированных токенов хранится в Redis.

3.3.3. При обнаружении подозрительной активности (множественные неудачные попытки входа, вход с нового IP-адреса) система инициирует дополнительную верификацию через email.

3.4. Безопасность инфраструктуры

3.4.1. Docker-изоляция.
Все компоненты Сервиса (приложение, БД, Redis, Celery, Nginx) развёрнуты в изолированных Docker-контейнерах. Межсервисное взаимодействие осуществляется через внутренние Docker-сети; внешние порты открыты только для Nginx (80, 443).

3.4.2. Nginx как обратный прокси.
Nginx выполняет функцию единой точки входа (reverse proxy) и обеспечивает:

• терминацию TLS-соединений;
• ограничение размера запросов (защита от атак типа large payload);
• базовую защиту от перебора запросов (rate limiting);
• скрытие информации о внутренней инфраструктуре.

3.4.3. Мониторинг и метрики.
Метрики производительности и доступности Сервиса собираются через Prometheus. Данные мониторинга не содержат персональных данных пользователей — исключительно агрегированные технические показатели (число запросов, время ответа, загрузка ресурсов).

3.4.4. Мониторинг ошибок.
Технические ошибки фронтенда и бэкенда логируются через мониторинг ошибок. Перед передачей в мониторинг ошибок из отчётов об ошибках фильтруются персональные данные (email, идентификаторы пользователей). В мониторинг ошибок передаются исключительно технические сведения: тип ошибки, стек вызовов, версия приложения.

4. ОРГАНИЗАЦИОННЫЕ МЕРЫ ЗАЩИТЫ

4.1. Разграничение прав доступа

4.1.1. Доступ к персональным данным пользователей предоставляется сотрудникам Оператора по принципу минимально необходимых привилегий (least privilege): каждый сотрудник имеет доступ только к тем данным и системам, которые необходимы для выполнения его должностных обязанностей.

4.1.2. Матрица доступа к ИСПДн:

4.1.3. Прямой доступ к производственной базе данных через SQL-клиент строго ограничен и осуществляется только через защищённое соединение (VPN + SSH) с обязательной фиксацией в журнале доступа.

4.2. Политика паролей и аутентификация сотрудников

4.2.1. Для сотрудников, имеющих доступ к инфраструктуре, устанавливаются следующие требования:

• длина пароля — не менее 16 символов;
• использование комбинации букв верхнего/нижнего регистра, цифр и специальных символов;
• обязательная двухфакторная аутентификация (2FA) для доступа к серверам, репозиторию кода и административным панелям;
• смена паролей — не реже одного раза в 6 месяцев и немедленно при подозрении на компрометацию;
• запрет использования одного пароля для нескольких систем.

4.2.2. Учётные данные (пароли, ключи API, сертификаты) хранятся в специализированных системах управления секретами; хранение паролей в открытом виде в репозитории кода, документах или электронной почте запрещено.

4.3. Логирование и аудит доступа

4.3.1. Оператор ведёт следующие журналы:

4.3.2. Журналы защищены от несанкционированного изменения и удаления. Целостность журналов проверяется регулярно.

4.4. Резервное копирование

4.4.1. Резервное копирование данных производится по следующему расписанию:

4.4.2. Все резервные копии хранятся на серверах, расположенных на территории Российской Федерации. Хранение резервных копий за пределами РФ не осуществляется.

4.4.3. Резервные копии шифруются перед сохранением. Работоспособность резервных копий проверяется процедурой тестового восстановления не реже одного раза в квартал.

4.5. Управление уязвимостями и обновлениями

4.5.1. Оператор применяет следующие меры управления уязвимостями:

• регулярное обновление компонентов ПО и зависимостей (не реже одного раза в месяц);
• аудит зависимостей на наличие известных уязвимостей (CVE) с использованием автоматизированных инструментов;
• применение критических обновлений безопасности в течение 48 часов с момента публикации.

4.5.2. Изменения в производственную инфраструктуру вносятся только через контролируемый процесс CI/CD с обязательным прохождением тестирования в изолированной среде.

4.6. Работа с персоналом

4.6.1. Сотрудники, имеющие доступ к персональным данным пользователей, знакомятся с настоящей Политикой и Политикой конфиденциальности под подпись (или в электронной форме) до получения доступа к данным.

4.6.2. Оператор проводит инструктаж по информационной безопасности при приёме на работу и не реже одного раза в год.

4.6.3. При прекращении трудовых отношений доступ сотрудника ко всем системам Оператора аннулируется в день прекращения трудовых отношений.

5. ОТВЕТСТВЕННЫЙ ЗА ОРГАНИЗАЦИЮ ОБРАБОТКИ ПЕРСОНАЛЬНЫХ ДАННЫХ

5.1. Ответственным за организацию обработки персональных данных в ООО «Время Цифровых Решений» назначается Генеральный директор Сосунов Даниил Валентинович].

5.2. Контактные данные ответственного:
Электронная почта: info@kopilka.app
Почтовый адрес: 634049, Томская обл., г. Томск, ул. Мичурина, д. 43

5.3. Ответственный за обработку ПДн осуществляет:

• контроль за соблюдением требований законодательства в сфере ПДн;
• организацию внутренних проверок соответствия;
• взаимодействие с Роскомнадзором по вопросам обработки ПДн;
• рассмотрение обращений субъектов ПДн;
• организацию расследования инцидентов безопасности.

6. ПОРЯДОК ДЕЙСТВИЙ ПРИ УТЕЧКЕ ПЕРСОНАЛЬНЫХ ДАННЫХ

6.1. Классификация инцидентов

6.2. Процедура реагирования

Этап 1 — Обнаружение и немедленное реагирование (0–2 часа)

1. Фиксация факта инцидента и времени обнаружения в журнале инцидентов;
2. Уведомление ответственного за обработку ПДн;
3. Немедленная изоляция скомпрометированных компонентов (отключение от сети, остановка сервисов при необходимости);
4. Принятие мер по предотвращению дальнейшей утечки (смена ключей шифрования, аннулирование токенов, закрытие уязвимости);
5. Начало сбора доказательств и технической диагностики.

Этап 2 — Уведомление Роскомнадзора (в течение 24 часов)

В соответствии с ч. 3.1 ст. 21 ФЗ-152 (в ред. ФЗ-266 от 14.07.2022) Оператор обязан уведомить Роскомнадзор об инциденте в течение 24 часов с момента его обнаружения.

Уведомление направляется через Государственную систему обнаружения, предупреждения и ликвидации последствий компьютерных атак (ГосСОПКА) и/или через личный кабинет на портале РКН и содержит:

• дату и время обнаружения инцидента;
• предполагаемую причину инцидента;
• перечень скомпрометированных данных (категории, предполагаемое количество субъектов);
• принятые и планируемые меры по устранению последствий.

Этап 3 — Уведомление пользователей (в течение 72 часов)

В течение 72 часов с момента обнаружения инцидента Оператор уведомляет затронутых пользователей путём:

• направления email-уведомления на адрес, указанный при регистрации, с описанием: характера инцидента (какие данные могли быть скомпрометированы); потенциальных рисков для пользователя; мер, принятых Оператором; рекомендаций для пользователя (смена пароля, мониторинг активности и пр.);
• публикации информации об инциденте на странице kopilka.app/security (при инцидентах уровня «Критический» и «Высокий»).

Этап 4 — Расследование и устранение (в течение 72 часов после обнаружения)

1. Полное техническое расследование: установление вектора атаки, объёма скомпрометированных данных, временного диапазона;
2. Устранение уязвимости, ставшей причиной инцидента;
3. Ротация всех скомпрометированных ключей, токенов и учётных данных;
4. Принятие дополнительных мер защиты для предотвращения повторения.

Этап 5 — Повторное уведомление РКН (в течение 72 часов)

В соответствии с ФЗ-266 в течение 72 часов после первоначального уведомления Оператор направляет в РКН уточняющее уведомление с результатами внутреннего расследования:

• подтверждённый объём утечки (количество субъектов, категории данных);
• установленная причина инцидента;
• принятые меры по устранению и предотвращению повторения.

Этап 6 — Документирование и анализ

1. Составление итогового отчёта об инциденте (хранится 3 года);
2. Анализ причин и обновление мер защиты;
3. При необходимости — обновление настоящей Политики и смежных документов.

6.3. Контакты для сообщения об уязвимостях (Responsible Disclosure)

Исследователи безопасности и пользователи, обнаружившие уязвимость в Сервисе, могут сообщить о ней по адресу info@kopilka.app с пометкой «Security». Оператор обязуется:

• подтвердить получение уведомления в течение 48 часов;
• оценить и устранить критические уязвимости в течение 7 рабочих дней;
• не предпринимать юридических действий против лиц, сообщивших об уязвимости добросовестно.

7. ХРАНЕНИЕ ДАННЫХ И ИНФРАСТРУКТУРА

7.1. Локализация данных.
В соответствии с требованиями ФЗ-242 все персональные данные пользователей Сервиса, включая транзакции, данные счетов, регистрационные и технические данные, хранятся исключительно на серверах, расположенных на территории Российской Федерации.

7.2. Резервные копии.
Резервные копии баз данных и иных компонентов, содержащих персональные данные, хранятся исключительно на серверах, расположенных на территории Российской Федерации. Создание резервных копий в иностранных облачных сервисах без дополнительного шифрования и правового обеспечения не осуществляется.

7.3. Состав инфраструктуры.
Производственная инфраструктура Сервиса включает следующие компоненты, задействованные в обработке персональных данных:

8. ПРОВЕРКА СООТВЕТСТВИЯ И АУДИТ

8.1. Оператор проводит внутреннюю проверку соответствия требованиям к защите персональных данных не реже одного раза в год, а также внеплановые проверки — при существенных изменениях инфраструктуры или после инцидентов безопасности.

8.2. Результаты проверок фиксируются в внутреннем акте и хранятся не менее 3 лет.

8.3. Настоящая Политика подлежит пересмотру:

• ежегодно — в плановом порядке;
• при существенных изменениях законодательства в сфере ПДн;
• при существенных изменениях технической инфраструктуры Сервиса;
• после инцидентов безопасности уровня «Критический» или «Высокий».

9. ЗАКЛЮЧИТЕЛЬНЫЕ ПОЛОЖЕНИЯ

9.1. Настоящая Политика вступает в силу с момента её публикации по адресу kopilka.app/security-policy и действует до принятия новой редакции.

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

9.3. Вопросы, не урегулированные настоящей Политикой, разрешаются в соответствии с законодательством Российской Федерации.

ООО «Время Цифровых Решений»

г. Томск, 2025

info@kopilka.app | kopilka.app/security-policy