Учебное пособие по безопасности SAP: первые 10 шагов реализации безопасности SAP

Доброе утро!

Безопасное внедрение программного обеспечения SAP - это не только работа специалистов SAP; Весь ИТ-отдел должен играть определенную роль. Изучите десятку шагов для безопасной реализации SAP.

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

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

1. Согласование параметров конфигурации SAP с политиками организации

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

Посмотрите на следующее, которое должно быть настроено на соблюдение предопределенных правил организации:

login/password_expiration_time (по умолчанию 0, рекомендуется 30)

Пользователи вынуждены менять свой пароль SAP через это количество дней.

login/min_password_lng (по умолчанию 3, рекомендуется 8+)

Устанавливает минимальную длину пароля.

login/fail_to_session_end (по умолчанию 3, рекомендуется 3)

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

login/fail_to_user_lock (по умолчанию 12, рекомендуется 5)

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

2. Доступ к общим учетным записям пользователей

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

Наиболее важным идентификатором установки является идентификатор SAP*. Его статус, наряду с другими идентификаторами общего типа, можно проверить с помощью отчета SAP RSUSR003.

Пароли этих общих идентификаторов должны быть сброшены, а профили с высокой степенью привилегий (SAP_ALL и SAP_NEW) должны быть удалены. Важно отметить, что учетная запись SAP* может воссоздать себя со стандартным и общеизвестным паролем при удалении. Соответственно, важно, чтобы учетная запись SAP* была защищена, но не удалена, а для параметра системного параметра login/no_automatic_user_sapstar установлено значение = 1.

3. Распределение профилей широкого доступа

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

Наиболее важным высокоприоритетным профилем доступа, который должен быть известен в системе SAP, является профиль SAP_ALL. Это дает доступ ко всем транзакциям и объектам авторизации и, следовательно, к любой функции или действию в системе SAP. Крайне важно, чтобы этот профиль не распределялся на регулярной основе. Аналогично, профиль SAP_NEW предоставляет доступ ко всем транзакциям и ко всем новым объектам авторизации.

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

4. Поддержка и доступ к проектной команде

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

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

Разработчики

Администраторы BASIS

Управление безопасностью (ролью)

Администрирование безопасности (пользователя)

Функциональность / Конфигурация

Также должен быть установлен процесс, который подтверждает правильность определения ролей для нужд организации.

5. Надлежащее разделение обязанностей при ролевом проектировании и процессах администрирования доступа

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

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

Чтобы обеспечить разделение обязанностей, включенных в процессы организации роли и процессов администрирования доступа, для управления этими рисками должен быть установлен инструмент, такой как SAP GRC Risk Analysis & Remediation (RAR). Ручные процессы могут использоваться в качестве альтернативы в небольших организациях, но ограничения этих процессов (например, мониторинг на уровне ролей, в отличие от уровня транзакции) должны быть распознаны и управляемы.

6. Чрезвычайные и высокоприоритетные процедуры доступа

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

Процедуры и процессы аварийного доступа и использование таких инструментов, как SAP GRC Super User Privilege Management (SPM), могут контролировать и контролировать распределение и использование доступа с высокими привилегиями.

7. Обзор доступа пользователей и домашнего хозяйства

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

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

8. Процедуры управления изменениями

Строгое соблюдение процедур управления изменениями и транспортного пути через разработки, QA/тестовые и производственные среды имеет решающее значение для целостности данных, хранящихся в производственной среде системы SAP. SAP имеет встроенный транспортный механизм под названием «Change and Transport System» (CTS), и важно, чтобы доступ к ключевым транзакциям, используемым для управления CTS, ограничивался только теми сотрудниками администрации, которым требуется выполнять свои роли.

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

9. Доступ к чувствительным функциям

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

Аудитор может предоставить список тех функций, которые следует более тщательно ограничить, например:

Доступ для поддержки и создания пользователей и ролей

Доступ к командам операционной системы

Доступ к транспортным транзакциям и объектам

Доступ к изменениям или создание программ

Доступ к открытию и закрытию системы для настройки

Доступ к программам отладки (позволяет пользователям обойти проверки авторизации)

10. Владение бизнесом процессами безопасности

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

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

Вывод

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

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

Об авторе:

Ричард Хант (Richard Hunt) является управляющим директором компании «Под ключ», специализированной компании по ИТ-безопасности, специализирующейся на объединении бизнес-консалтинга с технической реализацией для предоставления решений по информационной безопасности для систем SAP. Компания была основана в 2004 году компанией Hunt и теперь имеет офисы в Великобритании, Австралии, Германии и США, обслуживая клиентов в Европе, США и Азии.

Ричард уже более десяти лет работает в сфере ИТ-безопасности. Его карьера началась в качестве консультанта по безопасности в PricewaterhouseCoopers (PwC), где он специализировался на реализации безопасности SAP и обзорах безопасности ИТ. На протяжении своей карьеры он участвовал в более чем 20 проектах в области ИТ-безопасности, работающих в различных бизнес-процессах и отраслях промышленности в Великобритании, Азии и Австралии.