SOX IT General Controls у российской дочки: общий логин в ERP и другие открытия

Клиент - российская «дочка» крупной западной производственной корпорации, акции которой торгуются на американской бирже. Корпорация публичная, значит материнская компания подпадает под Sarbanes-Oxley Act 2002, а это автоматически тянет за собой требования к ИТ-контролям во всех дочерних структурах. Внешний аудитор по SOX - одна из большой четвёрки - прислал предварительный список вопросов, и российский финансовый директор позвонил нам с вопросом: «Что это вообще такое и что нам с этим делать?»

Мы уже работали с этим клиентом в контексте аудита информационной безопасности и примерно представляли инфраструктуру. Но SOX ITGC - это отдельный разговор.

Что проверяет SOX со стороны ИТ

SOX Section 404 требует, чтобы руководство подтвердило эффективность внутреннего контроля над финансовой отчётностью. Для ИТ это выражается в четырёх блоках, которые аудиторы называют IT General Controls:

• Logical Access Controls - кто имеет доступ к финансовым системам и почему именно он.
• Change Management - как вносятся изменения в системы, влияющие на финансовую отчётность, и есть ли разделение между теми, кто разрабатывает изменения, и теми, кто их утверждает.
• Computer Operations - мониторинг, резервное копирование, восстановление.
• Program Development - контроль над разработкой и внедрением новых систем.

Для дочки с небольшим ИТ-отделом всё это звучит устрашающе. На практике ключевой риск - финансовая ERP-система, в данном случае SAP R/3, и несколько смежных приложений, которые питают данными финансовую отчётность.

Первое интервью и первый сюрприз

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

На вопросе про учётные записи администраторов разговор неожиданно стал интересным.

Оказалось, что у SAP Basis-администраторов нет персональных логинов для входа в систему с привилегиями BASIS. Вместо этого существует одна общая учётная запись типа «BASIS_ADMIN» с паролем, который знают все, кто когда-либо занимался администрированием системы. Текущих администраторов двое, но по этой учётке в разные периоды работало пятеро - некоторые уже уволились. Пароль с тех пор не менялся, «потому что все к нему привыкли».

Мы спросили, как они понимают, кто именно что сделал в системе, если все ходят под одним логином. Администраторы посмотрели на нас с искренним недоумением.

По этой же логике был устроен доступ к серверам: один общий локальный «Администратор» на каждом сервере, пароль один на всех, записан в текстовом файле на сетевом диске.

Что нашли дальше

После этого открытия остальные находки уже не удивляли, но фиксировать их нужно было тщательно.

Разделение обязанностей в SAP отсутствовало. Один и тот же специалист финансового отдела мог создавать платёжные поручения и их же утверждать - в системе это не было разграничено ролями. SOX называет это Segregation of Duties, и это один из базовых контролей.

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

Change management существовал только на словах. Изменения в конфигурацию SAP вносились напрямую в продуктивную систему через тот же BASIS_ADMIN. Transport Request-ы из системы разработки использовались нерегулярно - «когда большое изменение, тогда через TR, а мелочь сразу руками». Аудиторов такой ответ не устроит.

Доступ уволенных сотрудников. Три человека из числа бывших ИТ-сотрудников числились в Active Directory как отключённые, но в SAP их учётки были активны. Плюс общий BASIS_ADMIN, который они знали.

Что стали делать

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

Первое и срочное - смена всех общих паролей и создание персональных учётных записей для администраторов с фиксацией в журнале, кто когда что делал. Это болезненно («привыкли»), но без этого разговор с аудитором не начнётся.

Второе - ревизия ролей в SAP. Матрица конфликтов SoD в SAP R/3 - отдельная трудоёмкая работа: нужно понять, какие комбинации транзакций создают недопустимые права, и перестроить роли. Делаем вместе с функциональными консультантами SAP.

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

Четвёртое - документирование Change Management-процедуры и приучение команды её соблюдать. Регламент Transport Management написали, теперь задача сделать так, чтобы он выполнялся не на словах.

Где сейчас

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

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

Половина администраторов с общим логином в ERP - это не катастрофа и не криминал. Это просто точка отсчёта для нормального процесса, которого раньше не было.