сложных систем
Работы / Аудит и запуск существующего проекта
База пантонов для типографии: аудит и защищённый запуск
Сотрудник типографии сам написал систему учёта пантонов и рецептов краски. Мы проверили безопасность и код, закрыли найденное, перевезли на сервер заказчика с проверенными бэкапами и вывели в работу.
- Роль
- Аудит безопасности и кода, исправления, переезд на сервер заказчика
- Срок
- Две недели
- Статус
- Работает на сервере заказчика
- Результат
- Каждое изменение данных сервер проверяет по роли; бэкап восстановлен на отдельном стенде целиком
Типография флексопечати. Сотрудник компании сам написал веб-приложение: база пантонов с рецептами смешивания краски в граммах, схема стеллажей, учёт расхода по штрихкодам на банках, подбор пантона по CMYK, база знаний технолога. Им уже пользовались — на стороннем хостинге. Но прежде чем опираться на систему всерьёз, нужно было понять, что у неё внутри, и подготовить серверную часть.
Мы подключились к существующему проекту. Код не переписывали: задача — довести то, что есть, до состояния, на которое можно положиться.
Что нашёл аудит безопасности
Права проверялись только в интерфейсе: лишние кнопки не показывались, а сервер не проверял ничего. Любой сотрудник с учётной записью, обратившись к серверу напрямую — для этого хватает браузера, — мог читать, менять и удалять любые данные и назначить себе роль владельца. Регистрация была открыта: доступ получал каждый, кто знал адрес.
Что сделали
- Защита на сервере. Каждое изменение данных проверяется по учётной записи и роли, а не по тому, что прислал браузер: печатник, менеджер и сотрудник без роли больше ничего не меняют — ни через интерфейс, ни в обход. Учётные записи заводит администратор, частота запросов ограничена, добавлены защитные заголовки.
- Сторож на будущее. Автоматическая проверка обходит все команды сервера при каждом изменении программы и останавливает сборку, если у новой команды не указано, кому она разрешена.
- Аудит кода. Три ревизии — бэклог ошибок, мёртвый код, корректность; найденное закрыто по приоритетам. Каждое изменение прогоняет 413 автоматических проверок.
- Окружения. Три контура в Docker — локальный, тестовый, рабочий; миграции базы — отдельным шагом; обновление одной командой.
- Тестовый стенд. Отдельный стенд с полным стеком на нашей инфраструктуре: изменения проверяются там до того, как попадут к пользователям.
- Рабочий сервер. Переезд со стороннего хостинга на сервер заказчика: сертификаты выпускаются сами, резервные копии снимаются ежедневно в два места и перед каждым обновлением, состояние сервисов под мониторингом.
- Восстановление проверено. Копию из удалённого хранилища развернули на отдельном стенде: база поднялась целиком — 597 пантонов, учёт по месяцам, рецепты. Копия, из которой ни разу не восстанавливались, — ещё не резервная копия.
Заодно
Роли стали понятными: в приложении появился раздел «Помощь» с правами каждой роли, заработала роль колориста, история рецепта ведётся целиком с автором правки, добавлена смена пароля, поправлена вёрстка на планшетах.
Результат
Система работает на сервере заказчика. За две недели она прошла путь от «данные доступны любому сотруднику с учётной записью» до «каждое действие проверяется сервером по роли» — с резервным копированием, подтверждённым восстановлением.
Как это выглядит.






Есть разработка, которую нужно довести до запуска?
Обсудим, что для этого потребуется.
Обсудить задачу ↘