Безопасность систем ERP

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску

Безопасность систем ERP затрагивает применение широкого ряда мер по защите систем ERP от неправомерного доступа к системе, а также обеспечения доступности и целостности данных системы. ERP-система — это компьютерная программа, предназначенная для объединения всей информации необходимой для эффективного управления компанией, включая такие аспекты деятельности как производство, управление цепочками поставок, бухгалтерский учёт, склады, перевозки, кадры, работа с клиентами. Наиболее популярными ERP-системами являются SAP, Oracle E-Business Suite, Microsoft Dynamics. Кроме этого, в России популярно 1С:Предприятие.

Обзор[править | править код]

Ядро каждой крупной компании — это ERP система; в ней проходят все критичные для бизнеса процессы, начиная от закупки, оплаты и доставки и заканчивая управлением человеческими ресурсами, продуктами и финансовым планированием. Вся информация, хранящаяся в ERP-системах, имеет важнейшее значение, и любой неправомерный доступ к ней может понести за собой громадные потери вплоть до остановки бизнеса.[1] Важно проводить комплексную оценку защищенности системы ERP, проверяя серверы ERP на наличие программных уязвимостей, ошибок конфигурации, конфликтов полномочий, соответствие актуальным стандартам и рекомендациям, включая рекомендации производителя.[1]

Причины уязвимости систем ERP[править | править код]

Сложность[править | править код]

Сложность систем ERP ведёт к возникновению уязвимостей безопасности. ERP системы обрабатывают большое число различных транзакций и реализуют сложные механизмы, которые предоставляют разные уровни доступа разным пользователям. Например, в SAP R/3 существуют сотни объектов авторизации, которые позволяют разным пользователям выполнять разные действия в системе. В организации среднего размера может существовать около ста видов транзакций, каждая транзакция обычно требует, по крайней мере, два объекта авторизации. Если в компании 200 пользователей, то существует приблизительно 800000 (100*2*20*200) способов настроить параметры безопасности ERP-системы. С ростом сложности увеличивается вероятность ошибок и конфликтов полномочий.[2]

Специфичность[править | править код]

В популярных ОС и приложениях ежемесячно находятся уязвимости, так как они находятся под постоянным прицелом хакеров. В результате популярные приложения становятся безопаснее. Внутренние бизнес-приложения закрыты для посторонних глаз, и это приводит к иллюзии «безопасно, так как засекречено». Из-за этого в специфичных бизнес-приложениях находят тривиальные и крайне опасные уязвимости в системе безопасности, которые редко встречаются в популярных продуктах.[3]

Недостаток квалифицированных специалистов[править | править код]

Большинство программ подготовки специалистов по системам ERP разработаны для обучения использованию возможностей системы и уделяют мало внимания безопасности и аудиту ERP.[2] В большинстве компаний понимание угроз систем ERP со стороны службы безопасности в лучшем случае поверхностно.[4] Многие компании не уделяют должного внимания безопасности ERP-системы. Консультанты по внедрению, как правило, озабочены лишь тем, чтобы развернуть систему в срок и уложиться в заданный бюджет. Вопросы безопасности считаются при этом второстепенными. Из-за этого защищённость системы оказывается слабой, а выявление и исправление проблем безопасности — сложным и дорогим мероприятием.[2]

Недостаток инструментов для аудита безопасности[править | править код]

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

Большое количество тонких настроек[править | править код]

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

Проблемы безопасности систем ERP[править | править код]

Проблемы безопасности в системе ERP могут возникать на разных уровнях.[5]

Сетевой уровень[править | править код]

Возможность перехвата и модификации трафика

  • отсутствие шифрования данных

В 2011 году специалисты из компании Sensepost проанализировали протокол DIAG, использующийся в системе SAP ERP для передачи данных между клиентом и сервером SAP. В результате была опубликованы две утилиты, позволяющие полностью перехватывать, дешифровывать и модифицировать на лету клиент-серверные запросы, содержащие критичную информацию, тем самым открывая пути для различных атак типа Человек посередине. Вторая утилита работает как Proxy и создана в большей степени для поиска новых уязвимостей, позволяя модифицировать запросы на клиент и сервер и искать новые уязвимости.[6][7]

  • передача пароля в открытом виде (SAP J2ee Telnet / Oracle listener старые версии)

В системе SAP ERP есть возможность администрирования по протоколу Telnet, который не шифрует пароли.[8]

Уязвимости протоколов шифрования или аутентификации

  • аутентификация хэшем
  • XOR шифрование паролей (SAP DIAG)
  • навязывание использование старых протоколов аутентификации
  • некорректные алгоритмы аутентификации

Уязвимости сетевых протоколов таких как протокол RFC в SAP ERP и Oracle Net в Oracle e-Business Suite. В SAP ERP для связи между двумя системами по TCP/IP используется протокол RFC (Remote Function Call). RFC-вызов — это функция, которая может вызвать и запустить на выполнение функциональный модуль, расположенный в другой системе. В языке ABAP, который используется для написания бизнес-приложений в SAP, существуют функции для совершения RFC-вызовов. В SAP RFC Library версий 6.x и 7.x было найдено несколько серьёзных уязвимостей[9]:

  • RFC функция «RFC_SET_REG_SERVER_PROPERTY» позволяет определять эксклюзивное использование RFC сервера. Эксплуатирование уязвимости приведет к отказу в доступе легитимным пользователям. Таким образом можно провести атаку отказ в обслуживании.
  • Ошибка в RFC функции «SYSTEM_CREATE_INSTANCE». Эксплуатирование уязвимости позволяет выполнить произвольный код.
  • Ошибка в RFC функции «RFC_START_GUI». Эксплуатирование уязвимости также позволяет выполнить произвольный код.
  • Ошибка в RFC функции «RFC_START_PROGRAM». Эксплуатирование уязвимости позволяет выполнить произвольный код или получить сведения о конфигурации RFC сервера.
  • Ошибка в RFC функции «TRUSTED_SYSTEM_SECURITY». Эксплуатирование уязвимости позволяет получить сведения о существующих пользователях и группах на RFC сервере.

Уровень ОС[править | править код]

Программные уязвимости ОС

  • Любая удаленная уязвимость в ОС может быть использована для получения доступа к приложениям

Слабые пароли ОС

  • возможность удаленного подбора паролей
  • пустые пароли на средства удаленного управления, таких как RAdmin и VNC

Небезопасные настройки ОС

  • NFS и SMB. Данные SAP могут быть доступны анонимному пользователю через NFS или SMB
  • Права доступа к файлам. Критичные файлы данных SAP и СУБД Oracle часто имеют небезопасные права доступа, такие как 755 или 777
  • Небезопасные настройки rhosts. В доверенных хостах могут быть прописаны серверы, на которые может легко попасть злоумышленник

Уязвимости СУБД[10][править | править код]

Всякая система ERP содержит множество баз данных. Поэтому одной из проблем безопасности ERP являются программные уязвимости СУБД.

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

format string — вид уязвимости, позволяющая выполнить вредоносный код. Проблема возникает из-за использования нефильтрованного пользовательского ввода в качестве строки формата в какой-нибудь C-функции, выполняющей форматирование, например, printf(). Злоумышленник может использовать спецификаторы формата %s или %n, чтобы записать произвольные данные в произвольную область памяти.

  • Пароли
    • множество паролей по умолчанию
    • возможность подбора паролей и пользователей (отсутствие блокирования по умолчанию)
  • Огромное количество возможностей повысить привилегии внутри СУБД
    • Высокие привилегии по умолчанию
    • PL/SQL инъекции

SQL-инъекции — один из распространённых способов взлома сайтов и программ, работающих с базами данных, основанный на внедрении в запрос произвольного SQL-кода. Внедрение SQL, в зависимости от типа используемой СУБД и условий внедрения, может дать возможность атакующему выполнить произвольный запрос к базе данных (например, прочитать содержимое любых таблиц, удалить, изменить или добавить данные), получить возможность чтения и/или записи локальных файлов и выполнения произвольных команд на атакуемом сервере. Атака типа внедрения SQL может быть возможна из-за некорректной обработки входных данных, используемых в SQL-запросах.

  • Cursor snarfing

Курсор применительно к SQL — это число, которое указывает на область памяти, где сервер базы данных хранит данные о запросе, переменных запроса и правах. В нормальной ситуации курсор создаётся и существует дор тех пор, пока не будет явно уничтожен. Если во время выполнения какой-либо SQL процедуры произошла ошибка, курсор может быть не уничтожен. Злоумышленник может воспользоваться этим куросорм, чтобы сделать запрос с правами этой неудачно завершившейся процедуры.[11]

Уязвимости приложений[править | править код]

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

  • Все возможные уязвимости веб-приложений (XSS, XSRF, SQL Injection, Response Splitting, Code Execution)
  • Переполнения буфера и format string в веб-серверах и application-серверах (к примеру, SAP IGS, SAP Netweaver, Oracle BEA Weblogic)
  • Небезопасные привилегии на доступ (SAP Netweaver, SAP CRM, Oracle E-Business Suite)

Управление доступом на основе ролей[править | править код]

В большинстве современных систем ERP для того, чтобы позволить пользователям выполнять только строго определённые транзакции и получать доступ лишь к определённым бизнес-объектам, применяется модель RBAC (Role-Based Access Control, управление доступом на основе ролей).[12] В модели RBAC решения о предоставлении доступа пользователю принимаются на основе функций, которые пользователь выполняет в организации. Эти функции называются ролями. Например, роли в банке это кассир, бухгалтер, кредитный инспектор и др. Роль можно понимать как множество транзакций, которые пользователь или группа пользователей могут совершать в организации. Транзакция — это некоторая процедура по преобразованию данных в системе, плюс данные, над которыми эту процедуру можно выполнять. Всякой роли соответствует множество пользователей, которые принадлежат этой роли. У пользователя может быть несколько ролей. Роли могут быть иерархическими, например, роль «кассир» также является ролью «сотрудник». Одним из достоинств модели RBAC является удобство администрирования. После того, как в системе заведены роли, транзакции, соответствующие каждой роли, меняются редко. Администратору нужно лишь добавлять или удалять пользователей из ролей. Когда сотрудник приходит в организацию, администратор даёт ему членство в одной или нескольких ролях. Когда сотрудник покидает организацию, администратор удаляет его из всех ролей, в которых тот состоял.[13]

Разделение полномочий[править | править код]

Разделение полномочий (Separation/Segregation of Duties, SoD) — концепция, состоящая в том, что пользователь не может совершить транзакцию без содействия других пользователей. Например, пользователь в одиночку не может добавить нового поставщика, выписать счёт или заплатить поставщику. Таким образом снижается риск ошибки или мошенничества.[14] Использование SoD является важным, хотя и недостаточным[3], условием безопасности системы ERP. Политику SoD можно реализовать, используя механизмы RBAC. Для этого вводится понятие взаимоисключающих ролей. Например, чтобы заплатить поставщику, один пользователь должен инициировать оплату, а другой подтвердить её. В этом случае инициация оплаты и подтверждение — взаимоисключающие роли. Разделение полномочий может быть статическим или динамическим. При статическом разделении полномочий (Static SOD) пользователь не может принадлежать двум взаимоисключающим ролям. При динамическом разделении полномочий (Dynamic SOD) пользователь может принадлежать двум взаимоисключающим ролям, но не может исполнять их в рамках одной транзакции. Достоинство SSOD — простота, DSOD — большая гибкость.[15] Обычно разделение полномочий описывается матрицей SoD. По осям X и Y матрицы отложены роли в системе. Если две роли являются взаимоисключающими, то на пересечении соответствующих столбца и строки выставляется флаг.

Сканеры безопасности систем ERP[править | править код]

Сканер безопасности систем ERP — это компьютерная программа, предназначенная для поиска уязвимостей в системах ERP. Сканер анализирует конфигурацию ERP-системы на наличие небезопасных параметров аутентификации, контроля доступа, шифрования, проверяет, установлены ли последние версии компонентов, ищет компоненты системы про которые известно, что они небезопасны. Кроме этого, сканер проверяет параметры системы на соответствие рекомендациям производителя и процедурам аудита ISACA. Результатом работы сканера безопасности является отчёт, в котором представлены обнаруженные уязвимости и степень критичности каждой из них.[1] Известные сканеры:

Примечания[править | править код]

  1. ↑ 1 2 3 http://www.dsec.ru/products/erpscan Архивная копия от 10 октября 2012 на Wayback Machine Digital security
  2. ↑ 1 2 3 4 Архивированная копия. Дата обращения: 21 ноября 2012. Архивировано 4 марта 2016 года. Security issues in ERP
  3. ↑ 1 2 http://www.dsec.ru/press_releases/pdf/business.pdf (недоступная ссылка)
  4. ↑ 1 2 Безопасность SAP в цифрах / Блог компании Digital Security / Хабрахабр. Дата обращения: 19 ноября 2012. Архивировано 19 октября 2012 года.
  5. ↑ http://dsec.ru/press_releases/infosec2009/infosec2009_polyakov_erp.pdf (недоступная ссылка) Безопасность ERP
  6. ↑ Digital Security предупреждает о новых угрозах протокола DIAG в SAP — ERPScan сканер безопасности SAP. Дата обращения: 11 ноября 2012. Архивировано из оригинала 16 апреля 2013 года.
  7. ↑ SensePost — SapCap Архивировано 29 октября 2012 года.
  8. ↑ Administering the SAP J2EE Engine Using Telnet (SAP Library — SAP NetWeaver Technical Operations Manual)
  9. ↑ Xakep Online > Множественные уязвимости в SAP RFC Library (недоступная ссылка)
  10. ↑ Александр Поляков(2009). Безопасность Oracle глазами аудитора. Нападение и защита. ДМК Пресс. ISBN 978-5-94074-517-4
  11. ↑ Архивированная копия. Дата обращения: 21 ноября 2012. Архивировано 19 июня 2012 года. Cursor snarfing
  12. ↑ Архивированная копия. Дата обращения: 22 ноября 2012. Архивировано 11 июня 2014 года.
  13. ↑ http://csrc.nist.gov/rbac/ferraiolo-kuhn-92.pdf Архивная копия от 18 октября 2011 на Wayback Machine Role-Based Access Controls
  14. ↑ ComplianceTutorial.com — How to build segregation of duties Архивировано 11 января 2013 года.
  15. ↑ Simple search. Дата обращения: 22 ноября 2012. Архивировано из оригинала 26 февраля 2015 года.
Источник — https://ru.wikipedia.org/w/index.php?title=Безопасность_систем_ERP&oldid=136399814