Безопасность как свойство архитектуры
Молния проектируется для фармкомпаний масштаба 500–1500 пользователей, где доступом управляют политики, а не договорённости. Поэтому контроль доступа, целостность данных и аудит встроены на уровне базы данных — и проверяются автотестами при каждой сборке.
Контроль доступа
Кто какие записи видит — определяется не интерфейсом, а самой базой данных. Это принципиальное решение: проверку, встроенную в СУБД, нельзя обойти ни через API, ни через ошибку в коде приложения.
Row-level security применяется самой СУБД в принудительном режиме. Прямой запрос к API вернёт только те записи, на которые у пользователя есть право.
Роли, группы, владельцы записей, точечные гранты доступа. Руководитель видит записи своей ветки иерархии, представитель — свои. Циклы в иерархии ролей исключены на уровне данных.
Администратор может увидеть систему глазами конкретного сотрудника — например, чтобы разобрать инцидент. В журналах при этом фиксируются оба: от чьего имени выполнено действие и кто его реально совершил.
Вложения хранятся в S3-совместимом хранилище и наследуют права родительской записи; размер ограничен, при сбое загрузки не остаётся «осиротевших» файлов.
Аутентификация и сессии
Стандартные, проверенные индустрией механизмы — без самодельной криптографии.
Пароли хэшируются алгоритмом Argon2id — современным стандартом, устойчивым к перебору на GPU.
Короткоживущие токены доступа и ротация refresh-токенов: перехваченный токен быстро теряет ценность, украденная сессия не живёт дольше ротации.
Универсальные ссылки вида molniyalabs.ru/{id} открывают запись только после проверки прав — подобрать чужой идентификатор бесполезно.
Целостность данных и аудит
Для фармы журнал согласований — это комплаенс-артефакт. Мы сделали его неуничтожимым технически, а не организационно.
История решений по согласованиям защищена триггерами СУБД: изменить или удалить запись журнала нельзя даже с правами администратора базы. Процессы не удаляются, а деактивируются — история остаётся.
Решение по шагу согласования атомарно: два руководителя, нажавшие «утвердить» одновременно, не создадут двойного решения или перескока шага.
Каждое действие привязано к реальному человеку — включая действия, выполненные администратором от имени сотрудника.
Правила валидации срабатывают при любом способе записи: веб, мобильное приложение, API. Обойти проверку «записав напрямую» нельзя.
Изоляция и резидентность
Архитектура рассчитана на компании, где вопрос «где физически лежат данные» задаёт не ИТ, а юристы и комплаенс.
У каждой компании — собственная изолированная база данных. Не общие таблицы с фильтром по арендатору: утечка «соседям» исключена архитектурно.
Облачная инсталляция и персональные данные — в российских дата-центрах, под требования 152-ФЗ.
Продукт разворачивается в контуре заказчика, в том числе полностью без доступа в интернет: лицензия — подписанным файлом офлайн, обновления — переносимыми пакетами, телеметрия отключается.
Лицензии подписаны асимметричной криптографией. Приложение содержит только публичный ключ — подделать лицензию, не владея закрытым ключом, нельзя.
Как устроена разработка
Безопасность держится не на обещаниях, а на проверках, которые выполняются при каждой сборке.
Каждая сборка проходит единый обязательный набор проверок: строгая типизация, статический анализ, автотесты. Красный гейт блокирует выпуск.
Сценарии «кто какие записи видит и не видит» зафиксированы автотестами. Изменение, случайно расширяющее доступ, не проходит сборку.
Изменения в чувствительных местах (доступ, целостность данных) проходят выделенное ревью с точки зрения безопасности.
Перед коммерческим релизом запланирован полный внешний аудит безопасности. Результаты предоставим заказчикам по запросу.
Готовы к вопросам вашей службы безопасности
Пришлём развёрнутые ответы на опросник ИБ, расскажем об архитектуре доступа и модели изоляции данных — и честно скажем, что уже закрыто, а что в работе.