Аудит безопасности ERP в ОАЭ: что он проверяет на самом деле

Коротко. Аудит безопасности ERP проверяет пять вещей: доступ, разделение полномочий, контроль изменений над пользовательским кодом и транспортами, интерфейсы к другим системам и то, куда уходят данные. В ОАЭ он также должен отвечать Стандартам обеспечения информационной безопасности ОАЭ по набору контролей и закону PDPL — по персональным данным, покидающим страну. Находка, повторяющаяся везде, одна и та же: у небольшого числа пользователей есть такие сочетания прав, которые позволяют одному человеку в одиночку завершить платёжный цикл, и никто об этом не знал, потому что права были выданы через вложенные роли, а не напрямую.

ERP — это то место, где лежат деньги, и поэтому этот аудит отличается от любого другого технического аудита в организации. Сканирование уязвимостей спрашивает, может ли злоумышленник войти. Аудит безопасности ERP спрашивает, может ли инсайдер, который уже внутри и с законными учётными данными, перевести средства, изменить мастер-запись или удалить след того, что он это сделал. Модель угроз здесь — санкционированный доступ, использованный в несанкционированном сочетании.

Содержание

Доступ: у кого что есть и почему это до сих пор так
Разделение полномочий: конфликты, которые приносят выгоду
Контроль изменений: пользовательский код и транспорты
Интерфейсы: учётные записи, у которых нет владельца
Данные: размещение и что требует PDPL
Что даёт аудит и сколько он стоит

                    ┌────────────────────────────────┐
                    │  ERP security audit scope      │
                    └───────────────┬────────────────┘
                                    │
        ┌───────────────┬───────────┼───────────┬───────────────┐
        ▼               ▼           ▼           ▼               ▼
  ┌───────────┐  ┌────────────┐ ┌────────┐ ┌──────────┐ ┌─────────────┐
  │ Access    │  │ Segregation│ │ Change │ │Interfaces│ │ Data and    │
  │ who has   │  │ of duties  │ │ custom │ │ what     │ │ residency   │
  │ what, why │  │ conflicts  │ │ code,  │ │ talks to │ │ what leaves │
  │ still     │  │ that pay   │ │ trans- │ │ it, with │ │ the country │
  │           │  │ out        │ │ ports  │ │ what     │ │ and why     │
  └───────────┘  └────────────┘ └────────┘ └──────────┘ └─────────────┘
        │               │           │           │               │
        └───────────────┴───────────┼───────────┴───────────────┘
                                    ▼
                       Evidence per finding, dated,
                    traceable to a control identifier

Пять областей, которые охватывает аудит безопасности ERP

1. Доступ: у кого что есть и почему это до сих пор так

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

Четыре типовые ситуации объясняют большую часть находок первого аудита. Постоянный привилегированный доступ, когда административные права выдали к запуску в 2019 году и не забрали. Вложенное наследование ролей, когда безобидная на вид роль даёт чувствительное право на три уровня ниже, — именно поэтому аудит обязан проверять фактические права, а не назначенные роли. Осиротевшие учётные записи ушедших сотрудников, которые выживают потому, что процесс увольнения заканчивается в поставщике идентификации, а у ERP собственное хранилище пользователей. И общие учётные записи, которыми пользуются командами, — они обрывают журнал действий ровно в тот момент, когда он нужен, потому что каждое действие приписывается учётной записи, а не человеку.

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

2. Разделение полномочий: конфликты, которые приносят выгоду

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

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

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

sql

-- The conflict that actually matters: one person who can both create a
-- vendor and release a payment to it. Roles differ per ERP; the shape
-- of the query does not.

WITH grants AS (
    SELECT u.user_id, u.display_name, r.role_id, p.permission
    FROM   user_role  u
    JOIN   role_perm  r ON r.role_id = u.role_id
    JOIN   permission p ON p.permission_id = r.permission_id
    WHERE  u.valid_to IS NULL          -- current grants only
)
SELECT   g1.user_id, g1.display_name,
         g1.permission AS creates_vendor,
         g2.permission AS releases_payment
FROM     grants g1
JOIN     grants g2 ON g2.user_id = g1.user_id
WHERE    g1.permission IN ('VENDOR_CREATE', 'VENDOR_BANK_EDIT')
  AND    g2.permission IN ('PAYMENT_RELEASE', 'PAYMENT_RUN_EXECUTE')
ORDER BY g1.display_name;

Конфликт, который прямо превращается в убыток

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

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

3. Контроль изменений: пользовательский код и транспорты

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

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

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

4. Интерфейсы: учётные записи, у которых нет владельца

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

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

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

5. Данные: размещение и что требует PDPL

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

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

Для организаций в DIFC или ADGM применимое право иное, а для организаций критических секторов сверху действуют Стандарты UAE IA (NESA), и ERP попадает под технические семейства контролей по управлению доступом, журналированию и криптографии. Один аудит может ответить за все режимы сразу при условии, что набор контролей сопоставлен один раз, а не проверен трижды.

6. Что даёт аудит и сколько он стоит

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

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

Чего он давать не должен — так это отчёта о том, что ERP небезопасна. У любой ERP с десятилетней историей такие находки есть; совет директоров на самом деле спрашивает, какие из них можно закрыть в этом квартале, а какие требуют изменения процесса длиной в год. Мы делаем эту работу в рамках аудитов информационной безопасности в Дубае, а там, где находка оказывается структурной, а не технической, она переходит в управление ИТ-безопасностью в ОАЭ.

Что почитать дальше

Регламент обеспечения информационной безопасности ОАЭ, версия 1.1, TDRA, технические семейства T1–T9
Федеральный декрет-закон ОАЭ № 45 от 2021 года о защите персональных данных
ISACA, Segregation of Duties Control Matrix — таксономия конфликтов
ISO/IEC 27001:2022, Приложение A.5.15, A.8.2 и A.8.32

Что на самом деле проверяет аудит безопасности ERP в ОАЭ