Как построить надежную систему защиты информации: комплексный подход

Защита информации для многих компаний до сих пор сводится к покупке антивируса или установке шифрования. Но этого мало. Современные угрозы куда сложнее: внешние атаки сочетаются с инсайдерскими рисками, утечки происходят из-за человеческого фактора и ошибок администрирования. Ситуацию усугубляют разрозненные решения — внедряют одну «коробку», а про организационные процессы забывают. В итоге система не выдерживает нагрузку, регуляторные требования не выполняются, а последствия обходятся бизнесу дороже, чем изначально правильный подход.

Артем Фомичев, коммерческий директор компании «ГИГАНТ Компьютерные системы», поделился актуальными рисками и собрал практические рекомендации — как выстроить современную многослойную систему защиты: от анализа угроз и потребностей до выбора технологий и их грамотного внедрения.

Первый этап при построении ИТ-системы: анализ угроз, потребностей и контекста

На первом этапе формируются требования, которые определяют, какие технологии и процессы далее стоит выстраивать. Например, если в компании десятки филиалов и сотрудники подключаются к корпоративной сети через открытые Wi-Fi в коворкингах, то в приоритете окажется защищенный VPN, двухфакторная аутентификация и контроль конечных точек. Если организация работает с персональными данными миллионов клиентов, ключевым станет шифрование баз данных, разграничение доступа по ролям и журналирование всех действий администраторов. В производственных компаниях ситуация иная: там критично контролировать физический доступ в серверные, резервировать каналы связи между цехами и защищать SCADA-системы от внешнего вмешательства. Без этого анализа легко ошибиться: закупают DLP-систему, а утечки происходят через плохо настроенный облачный сервис; внедряют SIEM, но не учитывают, что инфраструктура распределена и логов недостаточно для полноценного мониторинга. В результате деньги потрачены, а ключевые риски остались не закрыты. Поэтому отправная точка построения защиты — анализ исходных условий, а не выбор технологий.

На первом этапе важно определить, что именно защищать, кто может выступить потенциальным злоумышленником и в каких условиях работает компания, потому что именно эти три фактора задают рамки всей системы безопасности. Если не понимать ценность активов, можно тратить ресурсы на второстепенные данные, оставив критичные без защиты. Если не учитывать вероятных злоумышленников, меры окажутся неадекватными реальным угрозам. А игнорирование внутренних условий эксплуатации приведёт к тому, что даже правильные технологии не будут работать эффективно — они либо не впишутся в инфраструктуру, либо станут «бутылочным горлышком» для бизнеса.

1. Объекты защиты

Персональные данные: ФИО, паспортные реквизиты, телефоны, e-mail, номера банковских карт и CVV-коды. Они хранятся в CRM-системах, базах 1С, корпоративной почте и часто передаются через веб-формы. Утечка таких данных не только приводит к штрафам по ФЗ-152, но и к прямым искам от клиентов.

Коммерческая тайна: сведения о себестоимости продукции, тендерная документация, условия поставок и контракты. Обычно они хранятся в документообороте (Directum, DocsVision), на сетевых дисках или в SharePoint. Потеря доступа к этим данным позволяет конкуренту демпинговать на тендерах или напрямую выходить на ваших заказчиков.

Внутренние документы: протоколы совещаний, кадровые приказы, переписка в корпоративной почте и мессенджерах (Exchange, Teams, Slack). Их утечка раскрывает стратегию компании и внутренние конфликты.

Секреты производства: конструкторские чертежи в CAD-системах, рецептуры и технологические карты, исходный код ПО в Git-репозиториях. Это ядро конкурентоспособности. Утечка исходников через GitHub или потеря доступа к SCADA-системам может парализовать бизнес.

2. Источники угроз

Внешние атаки. Основной риск здесь — потеря контроля над критичными системами и данными через эксплуатацию уязвимостей. Фишинговые письма могут привести к компрометации учетных записей, drive-by-атаки — к заражению рабочих станций, SQL Injection и XSS — к краже или искажению данных из веб-приложений. DDoS выводит из строя публичные сервисы и делает бизнес недоступным для клиентов. При описании внешних угроз важно учитывать, какие именно сервисы компании доступны из интернета и какие сценарии эксплуатации для них реальны.

Инсайдеры. Опасность заключается в том, что действия сотрудника или подрядчика выглядят как нормальная активность, но приводят к массовым утечкам. Это может быть выгрузка базы клиентов бухгалтером, копирование исходного кода программистом или передача тендерной документации партнёру. Здесь ключевой акцент — уровень доступа и знания внутренних процессов, которые у внешнего злоумышленника отсутствуют.

Случайные утечки. Наибольшую угрозу представляют ошибки и халатность: документы с персональными данными попадают «не туда», администраторы оставляют по умолчанию открытые облачные бакеты, а ноутбуки с важной информацией теряются в командировках. В результате данные оказываются в свободном доступе или в руках третьих лиц без всякого злого умысла. При описании таких рисков важно учитывать, где хранятся данные, кто с ними работает и насколько персонал обучен обращению с ними.

Физический доступ. Угроза здесь — кража оборудования или прямое взаимодействие с носителями. Украденный ноутбук, доступ в серверную или даже фотографирование документов на телефон — всё это реальный риск. Слабое звено — неконтролируемые помещения, мобильные устройства сотрудников, временный персонал.

Перехват каналов связи. Здесь угроза в том, что передаваемая информация может быть прочитана или изменена по пути. Классические сценарии — атаки «человек посередине» в публичных Wi-Fi, подмена сертификатов при подключении к корпоративным сервисам или прослушивание VoIP-трафика. Наибольший риск несут незашифрованные каналы, устаревшие протоколы и неконтролируемые точки доступа.

3. Особенности инфраструктуры и среды работы

Инфраструктура. На первом этапе важно зафиксировать, в какой модели работает компания — централизованной или распределенной. От этого напрямую зависит устойчивость. В централизованной схеме единый сбой в дата-центре или падение магистрального канала связи может обрушить работу всех пользователей. В распределенной инфраструктуре с филиалами и партнерами критичным становится качество каналов связи: потеря доступности хотя бы одного узла может парализовать цепочку процессов. Если это заранее не учесть, система защиты окажется «красивой на бумаге», но бесполезной в реальной эксплуатации.

Удаленные сотрудники. Этот фактор нельзя игнорировать: работа из дома и доступ через публичные Wi-Fi создают риски заражения корпоративной сети, кражи учетных записей и утечек конфиденциальных данных. Опасность усиливается в сценариях BYOD, когда личные ноутбуки и смартфоны сотрудника используются для рабочих задач. Если такие условия не описать в начале, средства защиты окажутся неготовыми к контролю устройств за периметром офиса, а именно там чаще всего и происходят инциденты.

Распределенные сети. Чем больше узлов и подключений, тем сложнее поддерживать единую политику безопасности. Риск заключается в потере управляемости: разные сегменты могут жить по своим правилам, а это открывает путь злоумышленникам. Дополнительная проблема — задержки и перебои в передаче данных, которые критичны для сервисов реального времени и промышленной автоматизации. Если такие особенности не описать заранее, выбранные средства защиты не выдержат нагрузки и станут узким местом всей инфраструктуры.

Когда ясно, какие данные для компании критичны, кто представляет наибольшую угрозу и в каких условиях работает инфраструктура, возникает следующий вопрос: какими средствами всё это защищать. Здесь важно понимать, что безопасность не сводится к выбору одной технологии или покупке готового продукта. Любая система строится на двух опорах — организационных и технических мерах. Первые задают правила игры внутри компании, вторые закрепляют их в виде конкретных инструментов и технологий. Только их комбинация превращает разрозненные шаги в работающую систему защиты. Рассмотрим каждый детально.

Организационные меры

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

• Первое, что требуется, — разработка и поддержка внутренних нормативных документов. Это включает политику информационной безопасности, где фиксируется перечень защищаемых данных, допустимые способы их обработки, порядок доступа и хранения. К документам также относятся регламенты по использованию электронной почты и мессенджеров, правила работы с внешними носителями, инструкции по удаленному подключению. Для сотрудников с доступом к конфиденциальным сведениям обязательны соглашения о неразглашении (NDA). Без актуальных документов невозможно требовать дисциплины — любой инцидент превращается в «серую зону».
• Следующий слой — инструктажи и обучение. Практика показывает, что большинство инцидентов связано не с взломами, а с ошибками персонала. Чтобы снизить этот риск, вводятся обязательные курсы: от базовых («как создавать надежные пароли», «как распознавать фишинговые письма») до специализированных («работа с СКЗИ», «правила администрирования серверов в защищенном сегменте»). В компаниях с высокой текучкой кадров обучение закрепляется в HR-процессах: новый сотрудник не получает доступ к системе, пока не прошёл вводный инструктаж.
• Третий элемент — разграничение обязанностей и доступа. Классическая ошибка — когда один администратор владеет всеми критичными ресурсами: доменом, файловыми серверами, бэкапами. Это создаёт риск как злоупотреблений, так и простой ошибки, которая парализует компанию. Для устранения таких ситуаций вводят модель разделения полномочий: например, доступ к бухгалтерской системе имеют только сотрудники бухгалтерии, права на изменение политик безопасности в AD закреплены за отдельной группой администраторов, резервные копии контролирует другой отдел. Всё это фиксируется в матрице распределения ролей и обязанностей (RACI).
• Наконец, обязательный элемент — планирование восстановления. Это набор процедур на случай сбоев и аварий. В документах прописываются сценарии: что делать при отказе дата-центра, компрометации учетных записей или шифровальщике на файловом сервере. Для каждого сценария определяются ответственные лица, время реакции и план восстановления. Например, в регламенте может быть указано: при падении основного канала связи филиал автоматически переключается на резервный, а в течение часа ИТ-служба обязана восстановить синхронизацию баз данных. Такие документы подкрепляются технической практикой — хранением резервных копий в другом ЦОДе и регулярными учениями по disaster recovery.

Технические меры

Технические меры — это инструменты и средства, реализуемые через ПО, оборудование или физическую защиту.

• Идентификация и аутентификация. Это базовый механизм, который определяет, кто именно обращается к системе. На практике используется комбинация способов: пароли (с минимальной длиной, сроком действия и запретом повторов), двухфакторная аутентификация через SMS, OTP-приложения (Google Authenticator, Authy) или аппаратные токены (Rutoken, YubiKey). В продвинутых сценариях внедряется многофакторная схема с биометрией (Face ID, отпечатки пальцев), а также привязкой устройства к учётной записи. Ошибка в этой области приводит к тому, что украденный пароль открывает злоумышленнику доступ ко всем корпоративным системам.
• Управление доступом. Речь идёт о том, кто и какие действия может совершать с данными. Основой является модель RBAC (role-based access control), где каждому сотруднику назначаются права по его роли. В критичных системах применяется ABAC (attribute-based access control), где учитываются дополнительные параметры: местоположение, время суток, тип устройства. Отдельное внимание уделяется работе с документами — блокируется массовое копирование, печать и пересылка файлов вне организации. Системы уровня DLP и ECM фиксируют каждую попытку выгрузки или удаления. Важно, чтобы права доступа регулярно пересматривались: иначе у бывших сотрудников могут сохраняться «висячие» аккаунты с доступом к данным.
• Криптографическая защита. Ключевой инструмент для работы с конфиденциальной информацией. Используется шифрование на уровне файловых систем (BitLocker, VeraCrypt), баз данных (Transparent Data Encryption в MS SQL, Oracle) и каналов связи (TLS 1.3, IPsec). Для подтверждения подлинности документов и сообщений внедряется электронная цифровая подпись. В промышленности и госструктурах применяются сертифицированные СКЗИ, соответствующие требованиям ФСТЭК и ФСБ. Ошибки в этой сфере часто связаны с использованием устаревших протоколов (SSL 3.0, TLS 1.0) или хранением ключей «рядом» с зашифрованными данными.
• Резервирование и бэкап. Основная задача — гарантировать восстановление информации при сбое оборудования, атаках шифровальщиков или авариях. Для этого формируются расписания резервного копирования: ежедневное инкрементальное и еженедельное полное. Копии хранятся на независимых носителях или в другом ЦОДе. В продвинутых схемах применяются immutable-хранилища, где данные нельзя перезаписать или удалить до истечения заданного срока. Особое внимание уделяется регулярной проверке восстановления — практика показывает, что «мертвые» бэкапы обнаруживаются только при реальной аварии.
• Защита физической инфраструктуры. Техническая безопасность невозможна без инженерных мер. Для серверных помещений внедряются СКУД с разграничением доступа, видеонаблюдение, охранная сигнализация. Серверные стойки оснащаются датчиками температуры и влажности, источниками бесперебойного питания, а в крупных ЦОДах — дизель-генераторами. Противопожарная защита реализуется газовым тушением, чтобы оборудование не пострадало от воды. Для каналов связи критично резервирование маршрутов и защита кабельных коллекторов от физического повреждения.

Как выбрать надежные средства защиты

Теперь, когда определены объекты защиты, профили нарушителей и условия эксплуатации, логично перейти к выбору конкретных инструментов. Делать это «на глаз» нельзя: нужен формализованный отбор по единым правилам. На входе — перечень требований и ограничений (регуляторные допуски, сценарии нагрузки, RTO/RPO, интеграция с AD/SIEM/DLP, наличие API/SDK, требования к импортозамещению, бюджет CAPEX/OPEX). На выходе — прозрачное решение, почему выбрано именно это средство, при каких допущениях и с какими рисками.

Рабочий подход — методика с критериями и весами. Можно взять за основу, например, следующие критерии выбора:

Но сами по себе перечисленные критерии — лишь список параметров. Чтобы превратить его в инструмент выбора, нужен алгоритм: пошаговая процедура, которая позволяет объективно оценить каждый продукт, сравнить их между собой и выбрать решение, которое действительно соответствует потребностям компании.

Алгоритм оценки и отбора

1. На первом этапе важно собрать перечень потребностей, приоритизировать их, определить, что критично, а что опционально

На этом шаге формируется техническое задание на выбор средства защиты. Например, для банка ключевыми потребностями будут поддержка PCI DSS, возможность обрабатывать большие объёмы транзакций и минимальное количество ложных срабатываний. Для производственного предприятия — совместимость с промышленными протоколами (Modbus, OPC UA) и отказоустойчивость в условиях цеховой сети. Важно разделить требования на обязательные («must have») и дополнительные («nice to have»): если продукт не выполняет базовые задачи, он автоматически исключается.

2. Затем — формализовать критерии и сгруппировать их по смысловым блокам

Критерии собираются в группы, чтобы сравнение не свелось к хаотичному списку. Например: архитектура (масштабируемость, форм-фактор, резервирование), функциональность (DLP-модуль, поддержка шифрования, встроенный корреляционный анализ), интеграция (наличие API, работа с AD, коннекторы для SIEM), эксплуатация (удобство администрирования, документация, время внедрения), нормативы и соответствие (ФСТЭК, импортозамещение). Такая группировка помогает избежать перекосов — когда вся оценка делается на основе одного аспекта, например цены.

3. Дать вес каждому критерию

Не все параметры одинаково важны. Для одной компании ключевой фактор — наличие сертификата ФСТЭК, без него решение нельзя использовать в принципе. Для другой — стоимость владения, так как проект ограничен бюджетом. Вес задается в баллах или процентах (например, «соответствие регуляторике» — 30%, «стоимость» — 20%, «масштабируемость» — 15%). Это позволяет объективно учесть приоритеты бизнеса, а не только мнение ИТ-службы или службы безопасности.

4. Для каждого кандидата оценить его по критериям

Каждое решение получает баллы по шкале — например, от 0 до 9. Если система поддерживает только ограниченный набор протоколов, она получает низкий балл в категории «интеграция». Если продукт имеет простую консоль и быструю установку — высокий балл по «юзабилити». После этого оценки умножаются на веса, чтобы в итоговом счёте отражалась значимость параметров. Например, удобный интерфейс может дать +3 балла, но если его вес всего 5%, он не перекроет провал по сертификации (30%).

5. Сравнить варианты

На выходе формируется сравнительная матрица, где видно, какое решение соответствует требованиям лучше всего. Итоговые баллы показывают сильные и слабые стороны каждого кандидата: у одного — лучшая интеграция, у другого — выше устойчивость, у третьего — оптимальная цена. Это позволяет аргументированно выбрать продукт, а не ориентироваться на маркетинг или личные симпатии. Для наглядности часто строят диаграммы (радарные, сравнительные графики), которые показывают расстановку сил по ключевым блокам.

Внедрение и поддержка системы защиты

• Выбор средств защиты — это только начало. Реальную ценность решение приобретает на этапах внедрения, эксплуатации и развития. Именно здесь определяется, станет ли система рабочим инструментом или останется «мертвым грузом».
• Пилотный запуск. Перед масштабированием на всю организацию продукт разворачивают в ограниченном сегменте инфраструктуры. Например, DLP сначала включают только для почтового трафика, SIEM — для части серверов, а систему резервного копирования — для одного филиала. Это позволяет проверить производительность, выявить узкие места, оценить количество ложных срабатываний и нагрузку на администраторов. По итогам пилота формируются доработки конфигурации и план обучения персонала.
• Настройка под бизнес-процессы. Ни одно решение «из коробки» не соответствует всем требованиям. В почтовом шлюзе приходится прописывать правила по доменам партнёров, в DLP — исключения для конкретных отделов, в SIEM — корреляционные правила под специфику логов. Для промышленных компаний добавляется необходимость работы с SCADA-протоколами, для банков — обязательная интеграция с ABS. Если настройки не адаптировать, система либо перегрузит сотрудников бессмысленными алертами, либо пропустит реальные инциденты.
• Мониторинг и поддержка. После внедрения система должна оставаться актуальной. Решения обновляются, появляются новые уязвимости и угрозы, меняются регуляторные требования. Важно регулярно устанавливать патчи, проводить аудиты, тесты на проникновение, проверять резервные копии. Невнимание к этому этапу ведёт к накоплению технического долга: например, устаревший SIEM перестаёт справляться с потоком логов, а система шифрования работает на уязвимом протоколе.
• Обучение и контроль. Любая технология теряет смысл, если сотрудники не понимают, как с ней работать, и не соблюдают правила. Для этого создаются регулярные курсы и практические тренинги: от базовых (распознавание фишинга) до специализированных (реагирование на инциденты). Контроль строится на регулярных проверках: аудит логов доступа, тестовые инциденты, контроль за соблюдением политик. Нарушения должны иметь реальные последствия — иначе регламенты превращаются в формальность.

Пример применения алгоритма

Предположим, компания из финансового сектора ставит перед собой задачу: обеспечить защиту персональных данных клиентов (ФИО, номера карт, транзакции), сохранить конфиденциальность договоров с партнёрами, поддержать непрерывность онлайн-банкинга и соответствовать требованиям ФЗ-152 и PCI DSS.

1. Анализ угроз. Угрозы фиксируются по нескольким каналам:
2. внешний периметр (фишинговые атаки на клиентов, SQL-инъекции в интернет-банке, DDoS на публичный портал);
3. инсайдеры (сотрудники колл-центра с доступом к CRM, администраторы баз данных, подрядчики с временным доступом);
4. физические риски (утрата ноутбуков, доступ посторонних в офис или серверную);
5. сбои инфраструктуры (отказ СХД, перегрузка каналов связи, отключение электричества).
6. Формирование критериев. В список попадают:
7. функциональность (наличие модуля DLP, поддержка корреляции событий в SIEM, интеграция с Active Directory и почтовыми серверами);
8. масштабируемость (поддержка до 10 000 пользователей без деградации производительности, возможность кластеризации);
9. интеграция (наличие REST API, готовых коннекторов для Splunk/MaxPatrol, поддержка криптосредств по ГОСТ);
10. соответствие нормативам (наличие сертификатов ФСТЭК/ФСБ, PCI DSS Compliance);
11. стоимость владения (CAPEX на внедрение, OPEX на поддержку и лицензии).
12. Присвоение весов. Для банка наибольший вес получает соответствие нормативным требованиям (30%), затем защита персональных данных и транзакций (25%), интеграция с существующей инфраструктурой (20%), масштабируемость (15%) и стоимость (10%).
13. Сравнение кандидатов. Каждое решение оценивается по шкале 0–9 по каждому критерию. Например, одна DLP имеет лучший модуль анализа переписки, но не сертифицирована ФСТЭК (низкий балл по нормативам). Другая сертифицирована, но хуже интегрируется с корпоративной почтой. После умножения оценок на веса выводится итоговая матрица, где видно, какой продукт максимально соответствует задачам. В шорт-лист попадают:
14. DLP-система для контроля почтового и веб-трафика (InfoWatch, SearchInform, Falcongaze);
15. SIEM-решение для корреляции событий (Positive Technologies MaxPatrol SIEM, Splunk, QRadar);
16. средство двухфакторной аутентификации (Аппаратные токены + Push-уведомления через мобильное приложение);
17. система резервного копирования (Veeam, отечественные аналоги с сертификацией ФСТЭК).
18. Пилотный проект. Выбранные системы внедряются в ограниченном сегменте: SIEM обрабатывает логи с пяти серверов, DLP подключается к почтовому шлюзу, а двухфакторная аутентификация вводится для группы тестовых сотрудников. По итогам пилота выявляется: DLP даёт слишком много ложных срабатываний на внутренние рассылки, SIEM требует дополнительной оптимизации корреляционных правил, а аутентификация удобна для пользователей, но часть сотрудников теряет токены.
19. Корректировка и масштабирование. После доработок и оптимизации правила внедряются на всю организацию: SIEM подключается ко всем сегментам, DLP начинает анализировать сетевой трафик и мессенджеры, двухфакторная аутентификация становится обязательной для всех администраторов и сотрудников с доступом к CRM.
20. Эксплуатация. Проводятся регулярные обновления, пересмотр политик безопасности, внутренние аудиты и тесты на проникновение. Сотрудники ежегодно проходят обучение: от распознавания фишинга до работы с системой реагирования на инциденты.

Что делает систему защиты реально работающей

Надёжная защита информации работает только тогда, когда она выстроена как единая система. На практике это означает: заранее определить перечень критичных данных (например, базы клиентов, финансовые транзакции, конструкторскую документацию), оценить реальные угрозы — от фишинга и инсайдеров до сбоев оборудования и физического доступа, закрепить правила в виде регламентов и матрицы доступа, выбрать средства защиты с учётом архитектуры инфраструктуры (централизованной или распределённой), требований к масштабируемости и обязательной сертификации (ФСТЭК, ФСБ, PCI DSS). После этого решения проходят сравнительную оценку по весам и критериям, разворачиваются через пилот, адаптируются под бизнес-процессы и интегрируются с существующими системами (AD, почтовые серверы, SIEM). Дальше — постоянная эксплуатация: обновления, аудит, тесты на проникновение, обучение сотрудников. Только при такой последовательности шагов защита действительно снижает риски и поддерживает бесперебойную работу бизнеса.

Источник: https://www.novostiitkanala.ru/news/detail.php?ID=191090

Комментариев пока нет.