Информационная безопасность для бизнеса

Что входит в информационную безопасность бизнеса

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

На практике эти термины означают вполне понятные вещи.

Конфиденциальность отвечает за то, чтобы клиентские базы, финансовая информация, внутренние документы и другие данные не получили люди, которым они не предназначены.

Целостность означает, что информацию или настройки систем нельзя незаметно изменить. Например, злоумышленник не должен иметь возможности подменить реквизиты платежа, изменить данные клиента или получить административные права.

Доступность нужна для того, чтобы сотрудники и клиенты могли пользоваться системами тогда, когда они необходимы. Защищенная инфраструктура должна выдерживать не только атаки, но и ошибки конфигурации, сбои оборудования и другие нештатные ситуации.

Поэтому услуги информационной безопасности обычно затрагивают сразу несколько уровней: серверы, рабочие устройства сотрудников, сеть, облачную инфраструктуру, сайты и веб-приложения, базы данных, учетные записи, резервное копирование и внутренние процессы.

Просто установить защитное ПО недостаточно. Если администратор использует один пароль в нескольких системах, бывший сотрудник продолжает иметь доступ к корпоративному облаку, резервная копия хранится рядом с основной инфраструктурой, а критичные события нигде не регистрируются, серьезный риск остается даже при наличии дорогих средств защиты.

Какие риски помогает снизить информационная безопасность

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

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

Другой сценарий связан с доступами. Сотруднику или подрядчику однажды выдали административные права для решения конкретной задачи, а после завершения работ права никто не отозвал. Через несколько месяцев эта учетная запись может стать слабым местом всей системы.

Отдельный риск — данные. Клиентская база может быть надежно защищена на основном сервере, но регулярно выгружаться сотрудниками в Excel и храниться на ноутбуках, в почте или сторонних облачных сервисах. Формально база защищена, фактически появляется несколько неконтролируемых копий.

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

Что мы проверяем

Объем проверки зависит от инфраструктуры компании. Небольшому бизнесу с облачными сервисами и несколькими десятками сотрудников не требуется тот же набор мер, что компании с собственными серверами, несколькими офисами и внутренними информационными системами.

На первом этапе мы определяем границы проверки и собираем информацию об инфраструктуре.

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

Аудит информационной безопасности: с чего начинается работа

Первый этап — инвентаризация. Невозможно защищать инфраструктуру, о существовании которой никто не знает.

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

После этого формируется картина инфраструктуры и начинается анализ рисков.

Здесь важно не превращать аудит в автоматический сканер, который выдает несколько сотен предупреждений без приоритета. Технически у компании может быть множество замечаний, но влияние каждого из них различается.

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

Результатом становится не просто перечень уязвимостей, а приоритизированный план работ.

Как проходит работа над информационной безопасностью

После первичного анализа мы разделяем задачи на несколько уровней.

В первую очередь устраняются критичные проблемы, через которые можно получить доступ к данным или важным системам. Это могут быть открытые административные интерфейсы, небезопасные учетные записи, избыточные права, уязвимые сервисы или ошибки сетевой конфигурации.

Следом закрываются риски, которые сами по себе не обязательно приведут к инциденту, но могут значительно усилить последствия атаки. Например, отсутствие сегментации сети или централизованного контроля доступа.

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

Такой порядок важен. Если просто установить систему мониторинга, но оставить критичную уязвимость в публичном сервисе, сама по себе регистрация событий проблему не решит.

Контроль доступа: человек должен видеть только то, что ему действительно нужно

Один из ключевых элементов информационной безопасности — управление доступом.

В компаниях права пользователей имеют свойство накапливаться. Сотрудник переходит в другой отдел, получает новые роли, подключается к новому проекту, временно получает административный доступ — но старые разрешения часто остаются.

Через несколько лет один аккаунт может иметь доступ к CRM, облачному хранилищу, внутренней панели, аналитике и другим системам, хотя для текущей работы большая часть этих прав уже не требуется.

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

Для критичных систем дополнительно применяются многофакторная аутентификация, отдельные административные учетные записи, ограничения по источнику подключения и другие меры.

Это уменьшает последствия компрометации аккаунта. Даже если пароль одного сотрудника станет известен злоумышленнику, он не должен автоматически открывать путь ко всей инфраструктуре.

Защита серверов, сети и корпоративной инфраструктуры

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

Защита начинается с сокращения поверхности атаки.

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

Дальше проверяются обновления, права пользователей, конфигурация сервисов, журналы безопасности, резервное копирование и механизмы восстановления.

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

В результате одна скомпрометированная машина не должна автоматически давать злоумышленнику возможность перемещаться по всей сети.

Безопасность сайтов, веб-приложений и API

Для компаний, которые работают через собственный сайт, личный кабинет, мобильное приложение или SaaS-платформу, информационная безопасность напрямую связана с безопасностью разработки.

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

По необходимости проводится анализ уязвимостей и тестирование защищенности.

Главная задача здесь — понять, может ли пользователь получить доступ к функциям или информации, которые ему не предназначены, выполнить нежелательные действия или использовать приложение как точку входа во внутреннюю инфраструктуру.

Отдельное внимание необходимо API. Через него современные сервисы передают значительную часть данных между сайтом, мобильным приложением, CRM и другими системами. Ошибка авторизации на уровне API иногда опаснее уязвимости самого интерфейса, поскольку позволяет работать с данными напрямую.

Защита персональных данных

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

В России базовые требования определяются Федеральным законом № 152-ФЗ «О персональных данных», а технические и организационные меры для информационных систем персональных данных конкретизируются в том числе документами ФСТЭК России. Приказ ФСТЭК № 21 устанавливает состав и содержание организационных и технических мер для соответствующих уровней защищенности.

Но для бизнеса защита персональных данных не должна ограничиваться наличием политики на сайте.

Необходимо понимать, где эти данные фактически находятся. Они могут храниться одновременно в CRM, базе сайта, корпоративной почте, резервных копиях, аналитических системах и документах сотрудников.

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

Резервное копирование — часть безопасности, а не просто функция системного администратора

Даже хорошо защищенную систему нельзя считать устойчивой без работающей схемы резервного копирования.

Причина проста: задача информационной безопасности состоит не только в том, чтобы не допустить инцидент, но и в том, чтобы бизнес смог продолжить работу, если проблема все-таки произошла.

Особенно опасна ситуация, когда резервные копии доступны из той же инфраструктуры и с теми же правами, что основные данные. При атаке шифровальщика или компрометации административной учетной записи злоумышленник может уничтожить не только рабочие файлы, но и резервные копии.

Поэтому важен не сам факт создания backup, а архитектура хранения, периодичность копирования и возможность реального восстановления.

Хорошая проверка резервного копирования заканчивается не сообщением «копия создана успешно», а тестовым восстановлением данных.

Мониторинг позволяет увидеть атаку до того, как последствия станут очевидными

Абсолютной защиты, при которой инцидент технически невозможен, не существует. Поэтому еще одна задача информационной безопасности — своевременно заметить подозрительное поведение.

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

Для этого события из критичных систем собираются и анализируются.

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

Поэтому сначала определяются сценарии, действительно важные для конкретной инфраструктуры, а уже затем под них настраиваются правила контроля.

Что происходит, если инцидент уже произошел

Первая реакция после обнаружения атаки часто состоит в желании как можно быстрее выключить сервер, удалить вредоносные файлы и поменять пароли.

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

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

После локализации проблемы недостаточно просто восстановить работу. Если оставить причину атаки, инфраструктура может быть скомпрометирована повторно.

Поэтому нормальный цикл выглядит так: локализация инцидента, анализ причины, восстановление работы, устранение уязвимости и дополнительное усиление защиты.

Информационная безопасность и требования законодательства

Для некоторых организаций требования к защите информации определяются не только внутренними рисками, но и законодательством и отраслевым регулированием.

Помимо требований к персональным данным, отдельные нормы действуют, например, для субъектов критической информационной инфраструктуры. Федеральный закон № 187-ФЗ регулирует безопасность критической информационной инфраструктуры Российской Федерации, а требования к защите значимых объектов конкретизируются нормативными документами ФСТЭК России.

Поэтому состав проекта всегда зависит от типа организации, используемых информационных систем, категории данных и применимых требований.

Важно разделять две задачи: формальное соответствие требованиям и реальную защищенность инфраструктуры. Документы необходимы там, где их требует регулирование, но сами по себе они не закрывают технические уязвимости.

Сколько информационной безопасности действительно нужно компании

Уровень защиты должен соответствовать риску.

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

Для такой компании основными точками защиты могут быть корпоративная почта, CRM, облачное хранилище, сайт, учетные записи сотрудников и резервные копии.

У технологической компании набор будет другим: облачная инфраструктура, Git-репозитории, CI/CD, API, production-серверы, секреты приложений и административные доступы.

У интернет-магазина критичными становятся сайт, база заказов, интеграции с внешними сервисами, персональные данные покупателей и доступы сотрудников.

Именно поэтому мы не начинаем проект с готового набора продуктов. Сначала определяется инфраструктура и риск, а затем под них подбираются меры защиты.

Что получает бизнес после внедрения

Результатом проекта должна быть не папка с отчетом и не формулировка «безопасность улучшена».

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

При этом информационная безопасность не должна парализовать работу сотрудников.

Если для выполнения обычной операции человеку приходится проходить десять согласований, сотрудники начинают обходить правила: передавать файлы через личную почту, хранить пароли в браузере или создавать собственные неконтролируемые процессы.

Поэтому хорошая защита ищет баланс между безопасностью и удобством работы.

Разовая проверка или постоянное сопровождение?

Это зависит от инфраструктуры.

Если компания небольшая и ее системы меняются редко, можно начать с аудита, устранить основные проблемы и периодически проводить повторную проверку.

Для активно развивающегося продукта ситуация другая. Появляются новые сервисы, сотрудники, интеграции, серверы и доступы. В такой среде состояние безопасности меняется постоянно.

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

Поэтому для изменяющейся инфраструктуры эффективнее регулярный контроль: проверка новых систем, пересмотр доступов, анализ уязвимостей и мониторинг критичных изменений.

Как понять, что компании пора проверить информационную безопасность

Проверка особенно актуальна после быстрого роста бизнеса, перехода в облако, запуска нового сервиса, появления удаленных сотрудников, серьезного изменения инфраструктуры или подключения большого количества внешних интеграций.

Еще один сигнал — отсутствие ответа на простые вопросы.

Кто сейчас имеет административный доступ к CRM? Какие сервисы компании доступны из интернета? Где находятся резервные копии? Можно ли восстановить из них рабочую систему? Какие данные сможет получить злоумышленник, если взломает почту обычного сотрудника? Кто заметит подозрительный вход ночью?

Если на эти вопросы приходится отвечать «надо спросить у разработчика» или «скорее всего все закрыто», фактическое состояние безопасности компании неизвестно.

Именно с этого имеет смысл начинать аудит.

Как мы работаем

Сначала мы знакомимся с инфраструктурой и бизнес-процессами компании. Определяем критичные системы, данные и точки доступа, после чего формируем границы проверки.

Затем проводится технический анализ. Мы ищем уязвимости и ошибки конфигурации, проверяем внешние сервисы, учетные записи, права доступа, сетевую архитектуру и другие компоненты, которые входят в согласованный контур.

После анализа найденные проблемы распределяются по приоритету. Критичные риски, способные привести к компрометации важных систем или данных, исправляются в первую очередь.

Дальше мы внедряем необходимые меры: меняем конфигурацию, усиливаем контроль доступа, настраиваем защиту инфраструктуры, резервное копирование и мониторинг.

После выполнения работ проводится повторная проверка.

Так бизнес получает не абстрактную рекомендацию «усилить безопасность», а конкретный результат: что было найдено, что изменено и какие риски удалось закрыть.

С чего начать

Если вы не знаете, насколько защищена текущая инфраструктура, покупать дополнительные средства информационной безопасности вслепую не имеет смысла.

Начните с оценки существующей ситуации.

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

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