Чему вы научитесь
Ознакомьтесь с десятью наиболее распространёнными уязвимостями в системе доступа к ERP-системам и финансовым приложениям, поймите, как каждая из них позволяет мошенникам обойти ваши внутренние меры контроля, и получите практические решения для каждой из них.
Многие организации вкладывают значительные средства в брандмауэры, защиту конечных точек и обнаружение угроз. Это правильный подход. Но пока периметр защищен, дверь для риска мошенничества в ваших собственных бизнес-приложениях остается широко открытой.
Системы планирования ресурсов предприятия (ERP) и финансовые приложения занимают центральное место в операционной деятельности: они хранят ваши самые конфиденциальные данные, контролируют финансовые транзакции и определяют, кто может создавать, утверждать или изменять критически важные записи. И все же безопасности в этих критически важных бизнес-системах постоянно уделяют недостаточно внимания, её неправильно понимают или некорректно настраивают.
Это не теоретические риски. Ассоциация сертифицированных специалистов по расследованию мошенничества (ACFE) оценивает, что организации ежегодно теряют 5 % дохода из-за мошенничества, а более половины случаев профессионального мошенничества связаны с отсутствием или обходом средств внутреннего контроля. Ущерб не всегда является злонамеренным; иногда это нажатие неправильной кнопки кем-то, у кого был более широкий доступ, чем следовало бы. В любом случае потери ощутимы.
Устранение этого риска требует надежного Application Access Governance (AAG): фреймворка и IT General Controls (ITGCs), которые гарантируют, что нужные люди имеют надлежащий доступ к этим бизнес-приложениям в нужное время, а их доступ постоянно проверяется и контролируется.
Ниже приведены десять распространенных «подводных камней» безопасности бизнес-приложений и способы их избежать.
Ошибка 1. Вы предоставляете пользователям чрезмерный доступ
Одна из самых распространенных ошибок — предоставление пользователям бизнес-приложений большего доступа, чем им необходимо. Обычно все начинается с упрощенного подхода: кому-то из бизнес-подразделения нужно быстро решить проблему, ИТ-отдел предоставляет широкий доступ, а роль администратора так и не удаляется. Умножьте это на всю организацию, и вы получите раздутые права доступа, повышенный риск и систему, которую практически невозможно проверить.
Решение — принцип минимальных привилегий. Предоставляйте пользователям только минимальный доступ, необходимый для выполнения их повседневных задач, и ничего больше. Да, для правильного внедрения требуется больше времени и сотрудничество с владельцами бизнес-приложений, но при этом обеспечивается заметная рентабельность инвестиций (ROI). Ограничение доступа снижает риск мошенничества, риск нарушения принципа разделения обязанностей (SoD) и позволяет сократить расходы на лицензирование во многих ERP-средах.
Ошибка 2. У вас «туннельное зрение» в вопросах безопасности
Легко сосредоточиться на том, имеет ли пользователь доступ к нужным экранам, и забыть проверить, что на самом деле дает этот доступ или сколько он стоит. Во многих ERP-системах назначение полномочий в области безопасности напрямую связано с требованиями к лицензированию. Чрезмерное назначение роли пользователю может означать переплату за лицензию этого пользователя. Организации несли шести- и даже семизначные расходы на лицензирование, поскольку безопасность была настроена без учета влияния последующего лицензирования.
Рекомендация — оценивать каждое решение или изменение в системе безопасности с двух точек зрения: риска нарушения принципа разделения полномочий (SoD) и влияния на лицензирование. Если ваша система ERP предоставляет доступ к телеметрическим данным, используйте их, чтобы сравнить фактические действия пользователей с тем, что им поручено, и определить, где можно ограничить доступ и сократить количество лицензий.
Для Microsoft D365 Finance & Supply Chain (F&SC) и D365 Business Central (BC) отчет Delinea Fastpath Telemetry Data демонстрирует именно это. Мы также знаем, что ни один сотрудник никогда не просил лишить его доступа к своей учетной записи. Правильно настроенный доступ по принципу минимальных привилегий также может сократить расходы на лицензирование.
Ошибка 3. Вы не соблюдаете процесс управления жизненным циклом приложений (Application Lifecycle Management)
К безопасности следует относиться так же, как к коду. Она должна проходить через среды разработки, тестирования и производства с надлежащей проверкой и утверждением на каждом этапе. Вместо этого безопасность настраивается непосредственно в производственной среде или применяется непоследовательно в разных средах, потому что кому-то нужно было быстро вмешаться, при этом тестирование изменений в системе безопасности проводится в ограниченном объеме или вовсе отсутствует.
В результате возникают несовместимые среды, роли, которые существуют в одном месте, но отсутствуют в другом, а также расхождения в настройках, которые со временем усугубляются. Если вы не разрешаете разработчику вносить изменения в код непосредственно в производственную среду, не позволяйте изменениям, касающимся безопасности, обходить те же самые меры контроля.
Ошибка 4. Вы не проводите периодические проверки доступа пользователей
Безопасность не является статичной, как и ваши пользователи. Люди меняют отделы, сотрудники уходят из компании, а к работе привлекаются временные подрядчики. Без плановых проверок доступа пользователей временный доступ становится постоянным, пользователи накапливают роли, которые им больше не нужны, а архитектура безопасности, созданная при запуске, постепенно разрушается.
Решение — разработать регулярный график проверок прав пользователей (UAR), независимо от того, будут ли это ежеквартальные, полугодовые или ежегодные проверки. Эти проверки должны дать ответы на три вопроса:
- Кто имеет доступ?
- Какой у них доступ?
- Уместен ли такой доступ по-прежнему?
Эти проверки не должны проводиться исключительно ИТ-специалистами. Владельцы и менеджеры бизнес-приложений должны присутствовать, поскольку именно они могут определить, нужен ли ещё разрешение на доступ. Они также должны были одобрить первоначальные запросы на доступ к этим приложениям.
Ошибка 5. Ваша безопасность изолирована в сфере ИТ
ИТ-отдел знает, как настроить систему безопасности. Зачастую ИТ-отделы не знают, что именно должен уметь делать тот или иной пользователь в сфере бухгалтерского учета, операций или закупок в своей повседневной работе. Когда проектирование безопасности рассматривается как чисто техническое задание, владельцы бизнес-приложений остаются в стороне, и в результате возникают роли, которые технически обоснованы, но функционально неверны.
Управление доступом к приложениям (Application Access Governance) по своей сути является межфункциональным процессом. Настройка безопасности и проектирование доступа требуют обратной связи между ИТ-отделом и бизнесом. Бизнес определяет, какой доступ необходим, а ИТ-отдел его внедряет и обеспечивает. Когда эта связь нарушается, результатом становятся пользователи с избыточными правами, доступ, не отражающий реальные должностные функции, и система безопасности, которой никто полностью не владеет. Любой из этих факторов может привести к слабым местам в контроле и повышенному риску инсайдерского мошенничества.
Ошибка 6. Вы относитесь к безопасности как к второстепенному вопросу
Часто вопросы безопасности откладывают на конец внедрения или обновления ERP, поскольку команды не хотят замедлять функциональное тестирование. Такая задержка приводит к дорогостоящим корректирующим мерам впоследствии: переработке ролей, переработке архитектуры безопасности и даже перенастройке бизнес-процессов.
Начинайте работу над безопасностью как можно раньше и включайте её в каждый спринт-цикл. Это должно быть обязательной частью плана внедрения проекта, а не просто «приятным дополнением». Преимуществами являются более согласованная модель безопасности, меньше неожиданностей в последнюю минуту и команда, обладающая опытом в этом процессе ещё до того, как давление, связанное с запуском, достигнет пика. Строгие меры безопасности ваших бизнес-приложений снижают риск мошенничества, что является положительным результатом.
Ошибка 7. Вы неправильно тестируете безопасность
Если ваша QA-команда запускает тестовые скрипты, войдя в систему под учетными данными системного администратора, вы не тестируете безопасность. Вы тестируете функциональность «с завязанными глазами». Если безопасность не проверена должным образом, проблемы с доступом проявляются только в производственной среде.
При тестировании приложения используйте реальные роли безопасности, которые будут у пользователей. Тестируйте безопасность поэтапно:
- Разработайте роль безопасности
- Назначьте её тестовому пользователю отдельно, без других ролей
- Проверьте функциональность, а затем проверьте SoD и влияние лицензирования
- Назначьте дополнительные роли и повторно проверьте
Кроме того, картина рисков SoD часто меняется, когда роли объединяются, и вам необходимо учесть это, прежде чем изменения поступят в производственную среду. Анализ влияния предлагаемых изменений доступа на SoD перед их развертыванием в производственной среде является ещё одним эффективным средством контроля для снижения риска мошенничества.
Ошибка 8. Вы не проверяете обновления ISV на предмет влияния на безопасность
Ваша команда — не единственная, кто вносит изменения в модель безопасности вашей системы. ERP-поставщики и сторонние ISV выпускают обновления, которые добавляют новые функции, изменяют существующие разрешения и вводят новые объекты безопасности. Я видел компоненты ISV, для функционирования которых требуется повышенный или даже административный доступ. Никто не ставил это под сомнение, поскольку предполагалось, что поставщик ответственно подходит к вопросам безопасности.
На самом деле этому ISV, как правило, не требовался расширенный или административный доступ для внесения изменений в код, но было проще запустить систему с чрезмерно широкими правами. Это также создает новый уровень риска для среды ваших бизнес-приложений.
Не делайте предположений. Любое обновление, независимо от того, от вашего поставщика ERP оно или от сторонней интеграции, следует оценивать на предмет влияния на безопасность. Это включает риск SoD и изменения в лицензировании. Принцип «Доверяй, но проверяй» применим здесь так же, как и везде.
Ошибка 9. Ваши встроенные функции безопасности используются недостаточно
Большинство корпоративных бизнес-приложений предлагают возможности безопасности, выходящие далеко за рамки базовых ролей и разрешений. Существуют средства управления безопасностью на уровне данных, разрешения на сущностях и структуры на уровне таблиц, которые позволяют администраторам более детально контролировать, кто что может видеть и делать. Эти функции часто используются недостаточно — либо потому, что организации не знают об их существовании, либо потому, что их партнер по внедрению не сообщил о них во время настройки.
Прежде чем прибегать к индивидуальному обходному решению или соглашаться на ненужное раскрытие доступа, ознакомьтесь с тем, что уже предлагает ваша ERP-система. Зачастую в ней уже есть встроенные инструменты, которые могут решить проблему без дополнительных затрат и сложностей.
Однако это не означает, что вам следует доверять нативным ролям, поставляемым вместе с бизнес-приложениями. Эти роли не были разработаны с учетом распределения обязанностей. Большинство компаний берут нативные роли и клонируют их, модифицируя в соответствии со своими потребностями в области контроля, включая SoD.
Ошибка 10. Вы попадаете в «пончик безопасности»
Представьте себе пончик. Представьте внешнее кольцо как периметр кибербезопасности: брандмауэры, endpoint detection, identity threat protection. Организации вкладывают значительные средства в эти зоны, и это оправданно, чтобы снизить эти внешние угрозы. Но что насчёт дыры посередине? Это ваши бизнес-приложения и внутренние риски мошенничества. Слишком часто эта дыра в «слепой зоне» безопасности остаётся на усмотрение бизнес-подразделений, оторванная от более широкой стратегии безопасности, за которую отвечает CISO.
CISO и CIO, которые руководят корпоративной безопасностью, также должны нести ответственность за безопасность бизнес-приложений.
Внутренняя угроза так же реальна, как и внешняя.
Ни один брандмауэр не остановит сотрудника, который случайно инициирует заказ на покупку в количестве, в десять раз превышающем запланированное, или того, кто намеренно использует чрезмерно широкий доступ в сложный период. Настоящая безопасность предприятия означает устранение «дыры в бублике», а не просто укрепление периметра.
Общая черта? Отсутствие последовательности
Вероятно, ни одна из этих ошибок не станет большим сюрпризом, но я наблюдаю их в различных отраслях, различных бизнес-приложениях и организациях любого размера. Общей чертой является отсутствие последовательного подхода к управлению доступом к приложениям и внутренним контролям, необходимым для снижения рисков мошенничества.
Хорошая новость заключается в том, что ни одно из этих улучшений не требует сложных инструментов или неограниченного бюджета. Они требуют дисциплины в процессах, межфункционального взаимодействия и отношения к безопасности как к первоочередной задаче, а не как к последнему пункту контрольного списка. Решения Delinea Fastpath предоставляют простые в использовании средства управления доступом к приложениям, которые обеспечивают прозрачность и автоматизацию для оптимизации внутренних контролей с целью снижения операционных рисков. Они также выявляют рисковые инсайты, помогающие принимать обоснованные решения в отношении доступа.
