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

Перейти в облако SAP и спокойно отдохнуть? Совсем нет. Те, кто переходит в частное облако с помощью RISE with SAP, передают часть ответственности – но далеко не всю. На практике часто существует опасный разрыв между обеспечением безопасности инфраструктуры со стороны поставщика и обязанностями клиентов по настройке, управлению правами доступа и защите данных. Эксперт компании SAP, Джессика Вольф, в коротком интервью разъясняет, где именно проходит граница в модели разделенной ответственности, какие подводные камни регулярно упускают из виду специалисты по информационным технологиям, и почему "облако" не означает "пакет беззаботных услуг".

В интервью: Джессика Вольф.

Джессика Вольф является старшим консультантом компании cbs Corporate Business Solutions и работает в сфере решений SAP уже более восьми лет. После начала работы с базовыми системами SAP она специализировалась на вопросах безопасности SAP. Более двух с половиной лет она является заместителем председателя рабочей группы по вопросам безопасности и управления уязвимостями при организации DSAG.

Многие компании неосознанно ассоциируют термин "облако" с фразой "поставщик берет на себя все заботы". Где именно проходит граница между ответственностью SAP и клиентом в модели разделенной ответственности, и какие наиболее распространенные недоразумения возникают?

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

Поскольку "совместная ответственность" (Shared Responsibility) уже подразумевает свое название: ответственность распределяется, а не полностью передается. Компания SAP берет на себя – в зависимости от конкретного договора и заказанных услуг – основные задачи, связанные с инфраструктурой, платформой и техническим обслуживанием. Поэтому крайне важно с самого начала четко определить, кто за что отвечает, и какие вопросы остаются ответственностью клиента.

При этом компания не должна полагать, что система SAP автоматически является "безопасной" только потому, что она работает в частном облаке. Важно задать следующие вопросы: Что означает безопасность для конкретной компании? На каких эталонных моделях, внутренних стандартах или минимальных требованиях мы основываемся? И соответствуют ли фактическая конфигурация, права доступа, интерфейсы и процессы эксплуатации этим требованиям? Эти вопросы должны активно обсуждаться и проверяться.

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

Онлайн-курсы SAP для специалистов.

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

Наиболее распространенное недопонимание возникает уже на этапе заключения контракта: что именно подразумевается под выполняемыми работами – и какие дополнительные условия необходимо согласовать с точки зрения безопасности? Часто контракты RISE заключаются на уровне высшего руководства, без достаточного привлечения соответствующих подразделений, специалистов SAP и команд по информационной безопасности. В результате могут возникать незаметные пробелы: предполагаемые услуги не включены в договор; ответственность за определенные аспекты возлагается на SAP, но фактически остается у клиента; необходимые сервисы обеспечения безопасности обнаруживаются слишком поздно или, как минимум, требуют значительных дополнительных усилий для реализации.

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

Кроме того, существует общая проблема зрелости: в многих компаниях безопасность SAP значительно менее развита по сравнению с классической IT-безопасностью. Такие темы, как системы управления информацией о безопасности и событиями (SIEM), центры оперативного реагирования на инциденты (SOC) и процедуры реагирования на инциденты, часто являются стандартными в общей IT-безопасности, но пока не получили последовательного развития в средах SAP. Атаки на системы SAP – это отнюдь не чисто теоретический сценарий. Они существуют, и компании должны соответствующим образом защищать свои системы SAP.

Ключевой вопрос заключается не только в том, что именно берет на себя компания SAP, но и в следующем: какие риски и задачи остаются за нами, какие требования к безопасности мы сами предъявляем, и как мы обеспечим соблюдение этих требований?

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

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

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

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

Еще один важный аспект – это мониторинг приложения SAP. В зависимости от объема предоставляемых услуг, мониторинг сети и инфраструктуры может осуществляться компанией SAP. Однако то, что происходит внутри самого приложения, в основном является ответственностью клиента, если только не были заключены дополнительные соглашения об оказании соответствующих услуг. Например, клиент должен определить:

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

Эти оповещения приложений также должны быть сопоставлены с другими сообщениями, поступающими из корпоративной системы обнаружения и предотвращения вторжений (SOC). Дополнительная платная услуга может выполнять определенные задачи, но она не заменяет ответственность клиента за определение и приоритизацию конкретных сценариев использования, а также за разработку процедур реагирования на инциденты.

Часто недооценивают и сложность взаимодействия между различными системами. Как часто клиенты действительно знают все свои интерфейсы, полностью их задокументировали, описали и оценили с точки зрения критичности? При этом необходимо четко понимать, какие данные передаются, какие системы участвуют в обмене данными, кто несет ответственность и какие интерфейсы являются наиболее уязвимыми или критически важными для бизнеса.

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

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

Что бы вы посоветовали специалистам в области информационных технологий, которые планируют переход на платформу RISE with SAP или уже осуществили его, чтобы они могли правильно выполнять свои обязанности по обеспечению безопасности с самого начала?

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

После этого следует сосредоточиться на устранении наиболее критичных недостатков. Я бы особенно рекомендовал следующие шаги:

• Необходимо четко определить зоны ответственности: границы договорных обязательств между компанией SAP, клиентом и, при необходимости, другими поставщиками услуг должны быть конкретно и понятно задокументированы.
• Оценка уровня безопасности системы SAP включает в себя анализ различных аспектов, таких как права доступа, конфигурация, усиление защиты, интерфейсы, мониторинг, реагирование на инциденты, управление рисками и активами.
• Определение критически важных активов и процессов: Клиент должен знать, какие данные, бизнес-процессы, системы и интерфейсы являются наиболее важными для его компании.
• Необходимо проверять права доступа и конфигурацию: роли пользователей, привилегированный доступ, разделение функциональных обязанностей и параметры безопасности системы следует регулярно проверять и переаттестовывать. Для начала можно использовать статический мониторинг, сравнивающий текущую систему с базовыми параметрами безопасности.
• Определение сценариев использования функций безопасности SAP: Компании должны определить, какие события необходимо отслеживать в системе SAP, какие из них являются критическими и как на них следует реагировать.
• Интеграция мониторинга SAP в корпоративную систему центра управления безопасностью (SOC): оповещения о проблемах в приложениях должны быть сопоставлены с остальными сообщениями о безопасности, поступающими в компанию. Для этого необходичны четкое распределение ответственности, процедуры эскалации и надежный процесс реагирования на инциденты.
• Инвентаризация и оценка интерфейсов: Каждый важный интерфейс должен быть известен, описан, закреплен за ответственным лицом и оценен с точки зрения его критичности и потенциальных рисков.
• Непрерывное совершенствование: Обеспечение безопасности – это не одноразовый проект, завершающийся после запуска системы. Важно регулярно пересматривать и улучшать конфигурации, права доступа, оценивать риски, анализировать сценарии использования и оптимизировать процессы реагирования на инциденты.

Самый важный вопрос, который должны задавать себе специалисты в области информационных технологий: Как вы планируете защитить свои системы SAP, если вы не знаете, какие данные, процессы, интерфейсы и конфигурации являются критически важными для вашей компании?

Независимо от того, где работают эти системы, безопасность больше не должна быть опциональным проектом. Вопросы безопасности должны учитываться с самого начала – в архитектуре, в эксплуатации, в процессах и в распределении ответственности. Она начинается не после запуска системы, а сейчас. Любое конкретное действие лучше, чем бездействие.

Госпожа Вольф, большое спасибо за интервью!

Первоисточник — Heise

Автор оригинала — Moritz Förster