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