Каковы лучшие практики для внутренних стандартов безопасности в компаниях с большими инвестициями SAP?

Question

Я работаю в крупной компании, и меня интересуют лучшие практики для внутренних стандартов безопасности. Мы вкладываем большие средства (более 500 миллионов долларов США) в SAP, а также имеем .Net и немного Java EE во внутренней среде.

Я нашел некоторую документацию от MS и SAP, но она устарела и не очень специфична.

Похоже, что в конечном итоге мы могли бы использовать Active Directory в качестве стандартного хранилища пользователей для всех не-SAP-приложений и SAP CUA / Portal для приложений SAP.

Некоторые проблемы, которые у меня есть по поводу AD:

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

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

  Что касается синхронизации между AD и CUA, я хочу подойти к этому очень осторожно. У нас ограниченный бюджет, и я хочу убедиться, что если мы в конечном итоге создадим что-то для синхронизации магазинов, то это будет продано и обеспечит отличную ценность. Если мы не сможем найти что-то подобное, я бы с удовольствием вернулся с рекомендацией, чтобы магазины оставались независимыми. SSO был бы идеальным решением, но я пытался запустить приложение SSO до SAML, и это было не красиво.

Сокращения:

• SSO: единый вход SAML: безопасность

• Язык разметки утверждений

• CUA: центральное администрирование пользователей (для SAP)

Answer 1

Есть много возможностей на эту тему.

У нас был клиент, который обновил свою AD и свой список пользователей SAP из SAP HR. Идея состояла в том, чтобы модуль OM содержал всех сотрудников. Вы можете ежедневно экспортировать список всех активных сотрудников в LDAP с базовой информацией (имя, фамилия, employeeId, логин ...). Для системы SAP для единицы / функции / задания требуется доступ sap, где есть теги, и пользователя, где они создаются / удаляются ежедневно.

Фактически, все сотрудники имели учетную запись SAP, но только у тех, у кого была пометка, была «диалоговая». Этим аккаунтам разрешено подключаться через SAPGUI, другим пришлось использовать портал, что является менее дорогой лицензией. Набор правил позволил установить роли для управляемых пользователей. Цель состояла в том, чтобы свести к минимуму управление пользователями и ограничить неумолимый рост авторизации, который начинается с перехода от работы к работе в организации. (это было для 105000 сотрудников, с большим количеством кадрового движения).

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

Конечно, возможно и обратное: запрашивать LDAP у SAP для управления учетными записями SAP, не будучи напрямую связанным с LDAP. Транзакция LDAP может дать вам некоторую информацию.

надеюсь, это поможет

Редактировать : синхронизация была выполнена программой ABAP. эта программа запускалась каждый день в четыре часа и создавала / удаляла / модифицировала некоторые учетные записи в LDAP. После этого другая программа добавила некоторую техническую информацию в записи LDAP, информацию, которая была недоступна для системы SAP RH (например, почтовый сервер, используемый для данного сотрудника, в зависимости от его местоположения по всему миру). Записи затем проверяются на согласованность и отправляются на мастер LDAP.

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

Привет

Answer 2

Возможно, вы захотите взглянуть на OpenSSO - у него есть агенты для SAP, и он будет интегрироваться с AD в качестве хранилища пользователей. Это также довольно солидно - Verizon использует его для 40 миллионов клиентов, чтобы войти на свой веб-сайт .

Answer 3

Почему это проблема, если пользователям не нужно входить в систему? Разве это не будет удобнее для пользователей? И не даст ли им дополнительный стимул для выхода из приложения?

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

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