После анализа собранной информации оказалось, что у команды подрядчика, который осуществлял настройку системы SAP ERP, были неограниченные полномочия (SAP_ALL, DEBUG), при этом анализ действий пользователей с подобными полномочиями не проводился на регулярной основе. После внутреннего расследования и выяснения деталей компания прекратила контрактные отношения с подрядчиком, а также существенно обновила команду сотрудников ИТ и менеджмента, отвечающих за реализацию продукции и управление мастер-данными, нормативно-справочной информацией.

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

• запретить или максимально ограничить доступ к таким полномочиям, как SAP_ALL, DEBUG.

• реализовать процедуру формализованного предоставления/блокировки доступа пользователей, сотрудников подрядных организаций к подобным полномочиям.

• внедрить регулярный мониторинг активности пользователей с подобными полномочиями;

• реализовать механизм, позволяющий осуществлять контроль, с тем чтобы любые произведенные в системе и согласованные заказчиком изменения затем оставались неизменными либо в дальнейшем изменялись только по согласованию с заказчиком или непосредственно владельцем системы;

• журналировать, то есть производить периодическую фиксацию критических действий в отдельном хранилище, недоступном для пользователей с доступом SAP_ALL, DEBUG;

• ограничить доступ подрядчику определенным промежутком времени либо продолжительностью контракта.

Пример 4

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

И небольшая вишенка на торте для тех, кто дочитал примеры до конца: рекомендую посмотреть фильм Office Space (просто погуглите). В фильме приведен пример реализации риска ИТ. Раскрывать детали не буду, наслаждайтесь отличным фильмом!

Что-то изменить может только тот, у кого все под контролем.

Рикако Такигава

Что вы узнаете из этой главы

В этой главе хочу поделиться с вами своими знаниями и опытом по внедрению контроля над ИТ, а главное, рассказать о том, как можно убедить владельцев ИТ-систем, автоматизированных сервисов и процессов в необходимости управления рисками, присущими ИТ (включая риски ИБ), и какие выгоды это может принести как им, так и компании.

2.1. ПРЕДПОЛОЖИМ, ЧТО…

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

• повышение и удержание лояльности клиентов;

• соответствие требованиям различных регуляторных органов;

• надежность и достоверность финансовой отчетности;

• эффективность и своевременность принятия управленческих решений.

Компания динамично развивается, новое ПО, «фичи», отчеты и т. д. появляются, как бургеры в известном ресторане.