Подготовка к аудиту информационной безопасности CRM - это наведение порядка в доступах, конфигурациях и документах, чтобы внешняя или внутренняя проверка прошла быстро и без авралов. Важно заранее собрать артефакты, описать процессы, проверить резервное копирование и убедиться, что настройки CRM соответствуют вашим политикам безопасности.
Что важно учесть перед началом аудита
- Определите объём: какие CRM-системы, интеграции и филиалы попадают в аудит информационной безопасности CRM.
- Назначьте ответственных по направлениям: ИТ, ИБ, бизнес-владельцы, подрядчики по услугам по аудиту безопасности CRM-систем.
- Убедитесь, что у аудиторов заранее согласованы уровни доступа и формат проверки защиты данных в CRM под ключ.
- Соберите действующие политики, регламенты и схемы сетевой/ролевой архитектуры до старта аудита соответствия CRM требованиям информационной безопасности.
- Проведите внутренний экспресс-аудит и закройте очевидные дыры до прихода аутсорсингового аудита IB для CRM компаний.
- Подготовьте список известных инцидентов и принятых мер: это снизит количество уточняющих вопросов аудитора.
| Пункт | Ответственность | Статус | Доказательство |
|---|---|---|---|
| Определён объём аудита по CRM и интеграциям | Владелец продукта / CISO | Запланировать | Документ "Границы аудита CRM", утверждённый руководством |
| Назначены ответственные за взаимодействие с аудиторами | Руководитель ИТ / ИБ | В процессе | Приказ / распоряжение с перечнем ответственных лиц |
| Собран пакет действующих регламентов ИБ для CRM | Служба ИБ | Готово | Каталог в DMS / wiki с актуальными версиями документов |
| Согласован формат аудита и типы тестов | Служба ИБ, юрист | Запланировать | Договор / программа аудита с описанием работ |
Оценка текущего состояния CRM: с чего стартовать
На первом этапе нужно понять, насколько ваша CRM уже соответствует базовым требованиям безопасности и где объективно есть провалы. Этот этап подходит компаниям, у которых есть хотя бы минимально формализованные процессы ИТ-поддержки и администрирования.
Не стоит начинать формальный аудит, если CRM находится в состоянии активного внедрения или миграции, архитектура ежедневно меняется, а ключевые интеграции ещё не стабилизированы. В такой ситуации рациональнее зафиксировать целевую архитектуру, завершить основные изменения и только потом запускать полноценную проверку.
Практические шаги первичной оценки
- Составьте карту ландшафта CRM: модули, окружения (prod/test/dev), интеграции с внешними системами, потоки персональных и коммерческих данных.
- Оцените критичность: какие данные в CRM наибольше важны (персональные, финансовые, коммерческая тайна), какие процессы остановятся при сбое.
- Сверьте фактическое использование CRM с внутренними требованиями ИБ: что предписано политиками и регламентами, а как на самом деле работают пользователи.
- Зафиксируйте известные проблемы: инциденты, жалобы пользователей, технический долг, "временные" решения, которые живут годами.
| Пункт | Ответственность | Статус | Доказательство |
|---|---|---|---|
| Карта ландшафта CRM и интеграций составлена | Системный архитектор / ИТ-отдел | В процессе | Диаграмма / схема в формате PDF или в wiki |
| Определены критичные данные и процессы в CRM | Бизнес-владелец CRM | Запланировать | Матрица критичности процессов и типов данных |
| Проведено сравнение фактических практик с политиками ИБ | Служба ИБ | Запланировать | Отчёт "Разрыв между требованиями ИБ и практикой использования CRM" |
| Список известных проблем и инцидентов сформирован | Служба поддержки / ИБ | Готово | Реестр инцидентов за последний год |
Документы и артефакты для проверки безопасности
Аудиторы смотрят не только на настройки, но и на то, как они закреплены документально и как управляются изменения. Чем лучше подготовлены артефакты, тем быстрее проходит аудит и меньше "домыслов" со стороны проверяющих.
Сфокусируйтесь на трёх блоках: требования (политики и стандарты), доказательства исполнения (журналы, скриншоты, отчёты) и управление изменениями (заявки, протоколы, планы релизов).
Критичные артефакты, которые стоит подготовить заранее
- Политика информационной безопасности и её приложение, описывающее правила защиты CRM и интеграций.
- Регламенты администрирования CRM: управление пользователями, резервное копирование, обновления, мониторинг.
- Модели угроз и/или отчёты риск-оценки, если они уже проводились для CRM.
- Журналы инцидентов, журналы изменений и план работ по устранению выявленных проблем.
- Договоры с подрядчиками и SLA, если поддержка CRM выведена на аутсорсинг.
| Пункт | Ответственность | Статус | Доказательство |
|---|---|---|---|
| Актуальная политика ИБ с разделом по CRM опубликована | Служба ИБ | В процессе | Файл политики в корпоративном хранилище, ссылка рассылается сотрудникам |
| Есть регламент администрирования и сопровождения CRM | Руководитель ИТ | Запланировать | Документ "Регламент эксплуатации CRM" с версиями и датой утверждения |
| Сформирован комплект журналов инцидентов и изменений | Служба поддержки / ИБ | Готово | Выгрузка из системы заявок / SIEM за требуемый период |
| Договоры с подрядчиками содержат требования ИБ | Юридический отдел | В процессе | Скан-копии договоров с разделами об ИБ и SLA |
Техническая защита CRM: конфигурации, логи и патчи
Техническая часть подготовки критична: именно она чаще всего становится источником замечаний аудиторов. Цель - привести конфигурации, патчи и журналы в состояние, которое можно формально защитить и подтвердить артефактами.
Краткий чек-лист подготовки к технической проверке
- Удостоверьтесь, что резервные копии CRM проходят успешно и есть тест восстановления.
- Проверьте актуальность обновлений CRM, ОС и СУБД.
- Убедитесь, что журналы безопасности включены и хранятся достаточное время.
- Проверьте базовые сетевые фильтры и ограничения доступа к CRM из внешних сетей.
- Подготовьте временные технические доступы для аудиторов (или стенд) с контролируемыми правами.
Пошаговая техническая подготовка к аудиту
-
Актуализировать патчи и версии ПО - приведите версию CRM, СУБД, серверной ОС и ключевых middleware к актуально поддерживаемым. Избегайте больших обновлений непосредственно перед аудитом: лучше запланировать их так, чтобы у вас было время на стабилизацию.
- Составьте реестр версий всех компонентов ландшафта CRM.
- Согласуйте окно обновления и план отката.
-
Проверить и настроить журналирование - включите логирование действий пользователей, администраторов, системных событий и интеграций, обеспечьте защиту логов от удаления и изменения.
- Определите минимальный срок хранения логов в зависимости от политики ИБ.
- Проверьте, что часы на серверах и в CRM синхронизированы.
-
Усилить сетевую защиту вокруг CRM - ограничьте доступ по сети только необходимыми адресами и портами, проверьте настройки VPN, балансировщиков, WAF и межсетевых экранов.
- Уточните, откуда допускается доступ к боевой CRM (офис, VPN, интернет).
- Проверьте наличие сегментации и отсутствие прямого доступа к БД из внепериметра.
-
Провести базовую проверку уязвимостей - до прихода аудитора выполните внутренний скан на распространённые уязвимости и слабые настройки.
- Используйте согласованный с ИБ сканер уязвимостей или возможности вашей SIEM.
- Зафиксируйте найденные проблемы и первичный план их устранения.
-
Подготовить тестовый контур (если требуется) - если программа аудита информационной безопасности CRM предполагает активное тестирование, безопаснее делать его на стенде, адекватно отражающем боевую конфигурацию.
- Анонимизируйте данные или используйте синтетические.
- Задокументируйте отличия тестового контура от боевого.
| Пункт | Ответственность | Статус | Доказательство |
|---|---|---|---|
| Реестр версий CRM, СУБД и ОС сформирован | Администратор CRM / DevOps | Готово | Таблица с версиями и датами последних обновлений |
| Настроено централизованное журналирование | Служба ИБ / ИТ | В процессе | Скриншоты/отчёты из SIEM или системы логирования |
| Ограничен сетевой доступ к CRM | Сетевой администратор | Запланировать | Экспорт правил из межсетевого экрана, схема сегментации сети |
| Выполнен внутренний скан уязвимостей | Служба ИБ | Готово | Отчёт сканера с перечнем уязвимостей и статусом обработки |
| Тестовый контур CRM подготовлен и документирован | Администратор CRM | В процессе | Описание стенда и отличий от боевой среды |
Контроль доступа и управление привилегиями
Неправильные роли и "вечные" высокие права - один из главных источников замечаний при аудите соответствия CRM требованиям информационной безопасности. Подготовиться к проверке здесь можно за относительно короткое время, если системно пройтись по правам доступа.
Чек-лист самопроверки по доступам
- Есть утверждённая матрица ролей и прав для CRM, понятная бизнесу и ИБ.
- Доступ к CRM привязан к учётной записи сотрудника, а не к общим логинам.
- Права администраторов ограничены и используются только при необходимости.
- Выполнена ревизия актуальных пользователей: уволенные и неактивные заблокированы.
- Есть процедура и сроки регулярного пересмотра прав (например, ежеквартально).
- Доступ внешних подрядчиков к CRM ограничен по времени и объёму прав.
- Подключена и настроена двухфакторная аутентификация там, где это допустимо.
- Администрирование по принципу минимально необходимых прав задокументировано.
| Пункт | Ответственность | Статус | Доказательство |
|---|---|---|---|
| Матрица ролей и прав по CRM утверждена | Бизнес-владелец CRM, служба ИБ | В процессе | Документ "Модель ролей CRM" с подписями ответственных |
| Проведена ревизия пользователей и удалены лишние учётные записи | Администратор CRM | Запланировать | Отчёт о пользователях с отметками "актуален/удалён/заблокирован" |
| Настроена двухфакторная аутентификация для критичных ролей | Служба ИТ | В процессе | Скриншоты настроек, инструкция для пользователей |
| Регламент регулярного пересмотра прав внедрён | Служба ИБ | Готово | Регламент, журнал пересмотров, протоколы согласования |
| Доступ подрядчиков ограничен и контролируется | Владелец договора / ИТ | В процессе | Список учётных записей подрядчиков с датами окончания доступа |
Операционные процессы: инциденты, бэкапы и журналирование
Даже идеально настроенная CRM не будет считаться защищённой, если процессы реагирования, резервного копирования и журналирования не работают или не подтверждаются доказательствами. Аудиторы смотрят на процессы в динамике, а не только на "красивую картинку" в момент проверки.
Распространённые ошибки в операционной части
- Резервные копии делаются, но никто не проводит регулярные тестовые восстановления.
- Журналы инцидентов ведутся в Excel локально, без централизованного контроля и резервирования.
- Рассылка уведомлений о сбоях и подозрительных событиях настроена, но за ними фактически никто не следит.
- Нет чёткой границы между инцидентом безопасности и обычным техническим сбоем.
- Пост-инцидентный разбор проводится неформально, выводы не оформляются и не внедряются.
- Бэкапы CRM хранятся в той же инфраструктуре и домене, что и боевая система, без сегментации.
- Регламент реагирования на инциденты существует, но сотрудники о нём не знают или им не пользуются.
- Ротация логов настроена так, что значимые события теряются раньше окончания периода аудита.
| Пункт | Ответственность | Статус | Доказательство |
|---|---|---|---|
| Регулярные тесты восстановления из бэкапов CRM проводятся | Администратор БД / ИТ | Запланировать | Журнал тестовых восстановлений, отчёты по времени и успешности |
| Реестр инцидентов безопасности по CRM ведётся централизованно | Служба ИБ | В процессе | Система тикетов/SIEM с пометкой типа события "инцидент ИБ" |
| Чётко задокументированы критерии отнесения события к инциденту ИБ | Служба ИБ | Готово | Раздел в регламенте реагирования на инциденты |
| Процедура пост-инцидентного разбора формализована | ИБ, ИТ, бизнес-владельцы | В процессе | Шаблоны отчётов по инцидентам, примеры заполненных документов |
| Логи хранятся требуемый период и резервируются | Служба ИТ | Готово | Скриншоты настроек ротации, отчёты о резервном копировании логов |
Устранение несоответствий и подготовка к повторной проверке
После первичного аудита информационной безопасности CRM вы получите перечень несоответствий и рекомендаций. Важно грамотно спланировать их устранение и выбрать подход к повторной проверке, учитывая бюджет, сроки и внутренние ресурсы.
Подходы к устранению замечаний и последующему контролю
- Внутренний план корректирующих действий - вы распределяете замечания между ИТ, ИБ и бизнес-подразделениями, ставите сроки и контролируете исполнение своими силами. Подходит при умерённом количестве замечаний и наличии компетентной команды.
- Точечное привлечение экспертов - по сложным вопросам (архитектура, сегментация, SIEM, модель угроз) привлекаются внешние консультанты, но общий план и контроль остаются внутри компании.
- Комплексная проверка защиты данных в CRM под ключ - подрядчик не только проводит услуги по аудиту безопасности CRM-систем, но и помогает выстроить процессы ИБ вокруг CRM "под ключ" с упаковкой документов, регламентов и обучением персонала.
- Регулярный аутсорсинговый аудит IB для CRM компаний - при высоких требованиях к соответствию и дефиците внутренних ресурсов часть функций контроля и периодических проверок передаётся на аутсорсинг с чётко прописанными SLA и отчётностью.
| Пункт | Ответственность | Статус | Доказательство |
|---|---|---|---|
| План корректирующих действий по результатам аудита утверждён | Руководство, служба ИБ | В процессе | Документ "План мероприятий по устранению несоответствий по CRM" |
| Назначены ответственные и сроки по каждому замечанию | Проектный офис / ИБ | Запланировать | Реестр замечаний с полями "владелец", "срок", "статус" |
| Определён формат повторной проверки (внутренний или внешний) | Руководство, ИБ | Запланировать | Протокол совещания, письмо о выборе формата повторного аудита |
| Ключевые изменения по ИБ CRM включены в дорожную карту ИТ | Руководитель ИТ | В процессе | План развития ИТ/CRM с отмеченными задачами по ИБ |
Типовые сомнения и короткие разъяснения
Нужно ли готовиться к аудиту, если CRM у облачного провайдера?
Да, ответственность за данные и процессы остаётся у вас. Провайдер отвечает за инфраструктуру, но настройки ролей, интеграций, процессов доступа и реагирования на инциденты внутри вашей организации - зона вашей подготовки.
Достаточно ли отчёта провайдера о пройденных сертификациях?
Нет, этого обычно недостаточно. Сертификаты провайдера подтверждают базовый уровень ИБ, но не отражают специфики вашей конфигурации CRM, интеграций и реальных бизнес-процессов, которые проверяются в рамках аудита.
Можно ли обойтись без тестового контура и проверять боевую CRM?
Технически возможно, но рискованно. Лучше использовать тестовый контур, особенно если планируются активные проверки, чтобы не повлиять на доступность и целостность боевых данных и не нарушить договорённости с клиентами.
Насколько детально надо документировать процессы ИБ вокруг CRM?
Достаточно уровня, который позволяет воспроизвести процесс другим специалистом и однозначно понять, кто за что отвечает. Чрезмерно формализованные, но неисполняемые документы вызывают больше вопросов, чем честно описанные живые процессы.
Сколько времени закладывать на подготовку к первому аудиту CRM?
Зависит от сложности ландшафта и зрелости процессов. Практически всегда стоит предусмотреть буфер до официального старта аудита, чтобы успеть закрыть очевидные дыры и собрать артефакты, не работая в режиме постоянного аврала.
Нужно ли обучать пользователей перед аудитом?
Желательно. Краткие напоминания по правилам работы с CRM, паролям, инцидентам и социальным атакам снижают количество нарушений и демонстрируют аудиторам, что обучение - не формальность, а регулярный процесс.
Имеет ли смысл заказывать предварительный "черновой" аудит?
Да, особенно если аудит по ИБ CRM для вас первый. Предварительная проверка позволяет увидеть слабые места и подготовиться к официальному аудиту с меньшим стрессом и более предсказуемым результатом.
