Управление риском ИТ. Основы. Максим Торнов
Чтение книги онлайн.

Читать онлайн книгу Управление риском ИТ. Основы - Максим Торнов страница 6

Название: Управление риском ИТ. Основы

Автор: Максим Торнов

Издательство: Издательские решения

Жанр:

Серия:

isbn: 9785006449299

isbn:

СКАЧАТЬ лет уволенные либо переведенные администраторы имели полный доступ к POS-терминалам и серверам во всех восьмистах магазинах в разных штатах.

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

      Подобный риск можно было бы снизить при наличии эффективного контроля над риском ИТ, например:

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

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

      Пример 3

      Европа. Крупнейший производитель пива.

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

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

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

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

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

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

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

      • СКАЧАТЬ