Безопасность закладывают в систему до того, как написан код и куплены серверы: решают, какие данные защищать, кто и как получает к ним доступ, что шифровать, какие события записывать в журналы и где хранить данные и копии. Эти решения фиксируют в схеме сети, матрице доступов и регламентах. Добавить их в работающую систему можно, но дольше и дороже: придётся переносить данные и менять привычки людей.
Коротко
Безопасность на этапе проектирования (security by design) — подход, при котором требования к защите входят в техническое задание наравне с функциями. Архитектор отвечает не только на вопрос «как это будет работать», но и на вопрос «что будет, если украдут пароль или откажет сервер».
Защита, добавленная задним числом, превращается в набор заплаток. Каждая закрывает один сценарий и нередко оставляет новые обходные пути: порт, открытый «на время», общую учётную запись администратора, копию базы на ноутбуке разработчика.
Что проще сделать на этапе проекта:
Проект начинается с инвентаризации и классификации данных: нельзя защитить то, о существовании чего вы не знаете. Составьте список систем, баз, файловых хранилищ и каналов, через которые данные уходят наружу: почта, мессенджеры, подрядчики, облачные сервисы.
Затем каждому типу данных присваивают класс. От класса зависят требования к доступу, шифрованию и месту хранения.
| Класс данных | Примеры | Что требуется |
|---|---|---|
| Публичные | Прайс, описание услуг, вакансии | Защита от подмены: доступ к редактированию только у ответственных |
| Внутренние | Регламенты, планы, рабочая переписка | Доступ только сотрудникам, вход с двухфакторной аутентификацией |
| Конфиденциальные | Клиентская база, договоры, финансы, данные сотрудников | Доступ по ролям, шифрование, журнал действий, проверенные копии |
| Биометрические и генетические | Отпечатки и шаблоны лиц в системе контроля доступа | Всё перечисленное, хранение в Узбекистане и регистрация базы в государственном реестре |
Следующий шаг — модель угроз: кто может навредить (внешний злоумышленник, сотрудник, подрядчик), через какой вход и что при этом потеряет бизнес. Как оценить вероятность и ущерб и расставить приоритеты, мы разобрали в статье о рисках информационной безопасности, а типичные причины утечек — в материале об утечке персональных данных.
Совет Начните с таблицы на одну страницу: система, какие данные в ней лежат, кто владелец, у кого есть доступ, где хранятся копии. Уже она показывает главные риски и первые шаги.
Каждый сотрудник и каждый сервис получают ровно тот доступ, который нужен для работы. Это принцип минимальных привилегий: менеджеру продаж не нужна бухгалтерская база, а публичному сайту — кадровые документы.
Компаниям с удалёнными сотрудниками и облачными сервисами подходит модель нулевого доверия. Стандарт NIST SP 800-207 описывает её так: устройство или учётная запись не получают доверия только потому, что находятся во внутренней сети. Каждый запрос к ресурсу проверяется: кто пользователь, с какого устройства он работает и есть ли у него право именно на это действие.
Для небольшой компании рабочим вариантом остаётся VPN с двухфакторной аутентификацией. Когда сотрудников, подрядчиков и сервисов много, доступ к отдельным приложениям через шлюз нулевого доверия (ZTNA) проще контролировать, чем пускать человека сразу во всю сеть.
Сегментация ограничивает ущерб: атака, начавшаяся в одной зоне, не расходится по всей компании. Плоская сеть — сеть, в которой бухгалтерия, склад, гостевой Wi-Fi и серверы находятся в одном сегменте, и один заражённый ноутбук видит в ней всё.
Типовая схема для офиса на 30–50 человек выглядит так.
| Сегмент | Что внутри | Кто имеет доступ | Правила между сегментами |
|---|---|---|---|
| Серверы | Базы данных, CRM, учётная система, файловое хранилище | Администраторы; сотрудники — только к своим приложениям | Открыты лишь порты нужных приложений, остальное закрыто |
| Рабочие места | Компьютеры и ноутбуки сотрудников | Сотрудники | К серверам — через разрешённые приложения, между отделами — по необходимости |
| DMZ | Сайт, почтовый шлюз, VPN-шлюз | Внешние пользователи — к публичным сервисам | Во внутреннюю сеть — только заданные запросы, например от сайта к API |
| Гостевой Wi-Fi | Телефоны гостей, личные устройства | Все | Только интернет, внутренняя сеть закрыта |
| Устройства | Принтеры, камеры, контроллеры доступа | Администраторы | Связь только с сервером управления |
Границы между сегментами держит межсетевой экран с явными правилами: всё, что не разрешено, запрещено. В облаке ту же роль выполняют виртуальные сети и группы безопасности.
Периметр — все точки, где инфраструктура соприкасается с внешним миром: интернет-каналы, удалённый доступ, публичные сервисы и почта. В проекте для каждой такой точки записывают, зачем она открыта и кто за неё отвечает.
SPF, DKIM и DMARC — записи в DNS, по которым почтовые серверы получателей отличают ваши письма от подделок. С 1 февраля 2024 года Gmail требует SPF или DKIM от всех отправителей, а от тех, кто отправляет больше 5 000 писем в день, — SPF, DKIM и DMARC вместе. Без этих записей письма компании чаще попадают в спам, а мошенникам проще рассылать письма от вашего имени.
Данные шифруют в трёх состояниях: при передаче, при хранении и в резервных копиях. Тогда перехваченный трафик, украденный диск или выгруженный архив бесполезны без ключа.
Резервное копирование закладывают в проект двумя параметрами: RPO — сколько данных бизнес готов потерять, например записи за последний час, и RTO — за какое время систему нужно вернуть в работу. От них зависят частота копий, место хранения и резервирование серверов. Правило 3-2-1, защиту копий от шифровальщиков и порядок действий после сбоя мы описали в статье о восстановлении IT-систем после сбоев.
Важно Копия, из которой ни разу не восстанавливались, ещё не защита. Заложите в проект тестовое восстановление по расписанию и замер времени, за которое оно проходит.
В журналы (логи) записывают события, по которым можно заметить атаку и восстановить картину инцидента. Рекомендации OWASP для приложений называют такой минимум:
Пароли, токены доступа, ключи, данные платёжных карт и лишние персональные данные в журналы не пишут: иначе журнал сам становится источником утечки. Записи отправляют на отдельный сервер, где администраторы рабочих систем не могут их удалить, а время на всех серверах синхронизируют — иначе события из разных систем не сложить в одну цепочку.
Минимальный срок хранения журналов в CIS Controls v8.1 — 90 дней (мера 8.10). Отраслевые правила и договоры с партнёрами могут требовать больше, поэтому срок фиксируют в проекте для каждой системы. Там же решают, кто просматривает журналы и реагирует на тревоги: своя команда или внешний сервис мониторинга.
Место хранения выбирают по закону, скорости работы и тому, кто будет отвечать за инфраструктуру. С 27 марта 2026 года статья 27-1 Закона «О персональных данных» № ЗРУ-547 в редакции закона ЗРУ-1125 от 26.03.2026 требует хранить в Узбекистане три категории: биометрические данные, генетические данные и данные пользователей операторов связи. Базы с этими данными регистрируют в Государственном реестре баз персональных данных (статья 20).
Остальные персональные данные можно хранить и обрабатывать за рубежом, если выполнено одно из условий части третьей статьи 27-1: страна признана обеспечивающей адекватную защиту, оператор соблюдает стандартные договорные условия или обязательные корпоративные правила либо международные стандарты из утверждённого перечня.
Для проекта это значит: биометрию из системы контроля доступа размещают только в стране, а площадку для CRM или сайта выбирают по скорости, цене и удобству поддержки. Сравнение своего сервера, облака в Узбекистане и зарубежного облака, перечень стран и замеры задержек — в статье о выборе облака и сервера в Узбекистане.
Проект безопасности заканчивается документами, по которым систему можно построить, проверить и передать другой команде. Работы идут в таком порядке:
На выходе у вас схема сети, матрица доступов, регламенты резервного копирования и реагирования на инциденты и список мер с приоритетами. Эти документы нужны и при внедрении, и когда уровень защиты нужно показать партнёру или банку.
Мы в Syntra Systems начинаем с аудита информационной безопасности — от 1 200 $: составляем карту того, что нужно защищать, проверяем серверы, сети, почту, сайты и рабочие места, смотрим доступы и работу с персональными данными и собираем отчёт с приоритетами. Если система уже работает, аудит показывает, с чего начинать переделку.
Затем выстраиваем защиту данных и доступов — от 4 000 $: роли и двухфакторная аутентификация, шифрование, защита почты от подделки, резервное копирование с проверкой восстановления, межсетевой экран и VPN, регламенты на случай инцидента и обучение сотрудников. Состав работ — на странице кибербезопасности для бизнеса.
Обсудим вашу задачу
Расскажите, что нужно сделать, — оценим сроки и стоимость и предложим решение.
Можно. Начинают с аудита: что уже есть, где лежат критичные данные и какие слабые места опаснее всего. Затем меры внедряют поэтапно, обычно с доступов и резервных копий, не останавливая работу компании.
Нет. Они не защищают от украденного пароля, лишних прав у сотрудника или заражённого устройства внутри плоской сети. Защита работает, когда доступы, сегментация, шифрование, журналы и копии выстроены вместе.
Со списка систем и данных, двухфакторной аутентификации в почте и облачных сервисах, отдельной резервной копии с проверкой восстановления и отзыва доступов у бывших сотрудников. Эти шаги не требуют крупных вложений.
Желательно. Если журналы лежат на том же сервере, злоумышленник с правами администратора сотрёт следы. Небольшой компании хватает отдельной виртуальной машины или облачного хранилища журналов с ограниченным доступом.
Дата-центр защищает от физического доступа, но не от выгрузки базы по украденному паролю, ошибки в правах на хранилище или потери копии. Шифрование делает такие данные бесполезными без ключа.
По статье 31 Закона «О персональных данных» собственник или оператор назначает подразделение или должностное лицо, ответственное за обработку и защиту персональных данных. Технические меры можно поручить подрядчику, но ответственность остаётся за компанией.
Цена зависит от числа систем, сотрудников и площадок. В Syntra Systems аудит информационной безопасности стоит от 1 200 $, выстраивание защиты данных и доступов — от 4 000 $, мониторинг событий безопасности — от 800 $ в месяц.
