Безопасность стран на примере экономической и информационной безопасности SAP

Источник материала:

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

Экономическая безопасность

Стереотипы использования, положенные в основу системы, отнюдь не современны, например, не нажать-на-кнопку, а нажать-на-кнопку и на-кнопку-"Выполнить". Например, для запуска мероприятий в транзакции PB40 (дойдите до нужного пункта по "Руководству пользователя" на pcmag.ru/solutions/detail_print.php?ID=34219) вы нажимаете на кнопку напротив мероприятия (она утопляется, нажатие на другую освобождает первую кнопку, т.е. они ведут себя как radiobox-ы; причем о том, что это кнопки, нужно еще догадаться, их ряд замаскирован под левую утолщенную границу таблицы, строки которой содержат названия мероприятий), а затем на иконку "Часы" (F8).

Далее, экраны перегружены элементами управления: переход к следующему экрану - кнопки "Сохранить", "Следующий экран"; возврат к предыдущему экрану - кнопки "Назад", "Предыдущая запись"; выход из транзакции - кнопки "Выход", "Отмена". Вместо многострочных текстовых полей ввода ("textarea" в терминах HTML) система содержит несколько однострочных ("input-text" в терминах HTML), приходится делить строку на несколько частей и вбивать части в отдельные поля. Длинные выпадающие списки ("select/option" в терминах HTML) демонстрируются не с места ранее выбранной позиции, а с самого начала. Часть работы компьютера просто делают руками, например, после ввода нового кандидата (сотрудника и т.д.) он не появляется автоматически на экране в списке кандидатов, для обновления этого списка нужно выполнить поиск всех кандидатов вручную. А главное - сам интерфейс сделан так, что последовательность событий не прогнозируема; опытный пользователь, который в другом ПО разбирается сам, тут бессилен. Оценили древность? Таким образом, дороги не только изменения настроек или ваших ABAP-программ, но и смена собственного персонала. И расходы состоят не только из оплаты обучения. Время на привыкание к такому ПО увеличивается - даже если допустить отсутствие негативной реакции и сопротивления. А негативная реакция есть.

Модель ведения бизнеса, настраиваемая чекбоксами и радиобоксами SAP, непродуманна. Взять хоть "Руководство пользователя", на которое мы ссылались ранее. Часть инфотипов (инфотипами называется часть таблиц модуля HR, он же HCM, предназначенного для управления человеческими ресурсами; поскольку выгодно всех запугивать и козырять непонятными словами, слово infotype распространилось далеко по индустрии, но в реальности за пределами SAP не используется) предназначена для хранения данных о кандидате в сотрудники (в кандидаты принимают в транзакции PB40), часть - для хранения данных о сотруднике (в сотрудники принимают в транзакции PA40). Первые инфотипы являются подмножеством вторых. Может статься, вам нужно собирать больше данных о кандидате, например, регистрировать его инвалидность и ее параметры. Однако инфотип, в который они записываются - инфотип 4 - предназначен только для сотрудников. Если вы пропишите его для мероприятия транзакции PB40, то система продемонстрирует его в мероприятии, но введенные данные не сохранит. Записи инфотипов для кандидатов хранятся в таблицах базы данных с именами вида PBxxxx, где xxxx - номер инфотипа, номера меньшие тысячи содержат лидирующие нули; записи инфотипов для сотрудников - в таблицах с именами вида PAxxxx; каждый инфотип демонстрируется и сохраняется отдельным ABAP-модулем MPxxxx00 (т.е. не одна процедура на все инфотипы, как можно было бы подумать). Независимо от того, в какой таблице вы хотите регистрировать инвалидность и ее параметры - в PA0004, во вновь созданной PB0004 (создав ее, вы вторгаетесь в область системных имен и рискуете нарушить работу системы при установке ближайшего service pack), или во вновь созданной таблице вне системных имен - вам придется модифицировать MP000400.

Затем придется решать проблему переноса данных при приеме сотрудника из числа кандидатов. Полные перечни инфотипов для кандидатов и инфотипов для сотрудников вы можете видеть в транзакциях PB30 и PA30. Если вам необходимо поэкспериментировать с приемом кандидата или сотрудника: удаляют кандидата или сотрудника со всеми записями инфотипов в транзакциях PB30 и PA30, соответственно, выбирая в меню клиента, а не в меню экрана, позиции "Вспомогательные функции / Удалить номер кандидата" в первой транзакции и "Утилиты / Удалить табельный номер" во второй (некоторые элементы управления программы появляются не в ее окне, а в меню клиента посреди его собственных элементов управления: не знаешь - не догадаешься).

Таким образом экономически выгоднее перекроить бизнес-процессы компании до соответствия возможностям SAP, предоставляемым настройками, чем добавлять функциональность своими разработками на ABAP. Так и делают, и это гордо называется "приведение организации к стандарту SAP". Такой выбор не случаен, ведь новая функциональность незнакома саперам-настройщикам, конфликтует с service pack-ами (для модуля HR вместо его новых версий поставляются расширения EhP и CLC); подпрограммы, сделанные покупателем, в результате конфликтов придется переписывать или не устанавливать service pack-и (последнее не редкость); документация на подпрограммы будет скудна, в связи с чем сопровождать их будет крайне тяжело. В случае SAP все это становится критичным в связи с высокой ценой саперов. Это же замечание ограничивает в возможностях реинженеринга вообще, значительно повышая цену перепроектирования организации.

Даже если вы "привели организацию к стандарту SAP", то, вопреки рекламным уверениям, что продукт требует главным образом настройки, в реальности все внедрения требуют добавления полей в инфотипы, создания непредусмотренных отчетов и просто дописывания логики работы - это вы знаете и по другим АСУ. То есть даже если вы поступитесь, без ваших собственных подпрограмм все равно не получится. Случаи покупки одним потребителем у другого всех настроек со всеми разработками и установки их у себя "под копирку" получили специальное название rollout. Но практически всегда модели бизнеса достаточно отличаются.

Кроме того, в современном обществе настройка превратилась фактически в обманку: каждый производитель преднамеренно создает в своем ПО область ручной путанной работы - а как иначе превратить клиента в дойную корову? Иначе клиент скопирует ПО, уйдет и не заплатит. От программирования такая настройка отличается уже мало. Вопрос "дойки" тесно смыкается с вопросом "удержания" - недаром появился термин Vendor lock-in. Чтобы развеять ваш романтизм, расскажу о существовании более масштабного цинизма, например, в хартии w3.org прямо записано, что новая технология не может быть стандартизирована, если существует технология с той же областью применимости. Когда автор обратил внимание, что появление языка JavaScript надолго остановило развитие языка HTML, в ходе дискуссии выяснилось, что ничтожны все аргументы (гибкость для неизвестных будущих применений: психологическая рационализация), кроме запрета на уменьшение ручной работы (уменьшать означает "портить рынок"). Даже в организации, стандатизирующей Интернет! От кого и что вы еще ожидаете? От SAP AG?

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

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

Но так на этом пути вообще невозможны ни продукт без массы программирования-настройки, ни снижение цены в целом по отрасли - ведь в ряду конкурентов видим типичную диссипативную структуру, типичный триггерный эффект: кто больше обрёл, тот больше имеет ресурсов для ведения рекламно-психологической войны, а значит, с позиции силы его снова ждет "успех". Доли рынка конкурентов стоят в геометрической прогрессии, а все они барражируют, закрывая новые подходы. Поэтому делегирование вниз IT-шникам или бизнес-аналитикам права выбора программы приводит не более чем к нахождению мелких отличий, много меньших масштаба самой отрицательной величины. Необходимо подняться над схваткой. Нас могут обвинить в голословности - мол, скажите, как это сделать, но такой выход из плоскости мы уже изложили в статьях "Ошибки и их исправление в эргономике API и GUI" ("КВ" №25) и "Систематика и обобщение методологий моделирования и языков" ("КВ" №38). Вкратце речь идет о том, что сила и устойчивость режима определяется сравнительной производительностью труда, и нужно дать простому смертному программировать так же легко, как писать шариковой ручкой. Тогда он создаст всё сам. Это тем более очевидно, что из науковедения давно известно, что новая точка роста, скачок возникает при создании инструмента нового типа, а не изделия.

Информационная безопасность

Предварительные сведения. В одной схеме базы данных могут быть расположены данные сразу нескольких компаний, для различения их записей в таблицах и инфотипах существует поле MANDT (инфотипами называется часть таблиц модуля HR). Соответственно, таблицы и инфотипы с этим полем называются клиенто-зависимыми, а без него - клиенто-независимыми. Совокупность записей всех клиенто-зависимых таблиц и инфотипов с одинаковым значением этого поля и всех записей клиенто-независимых называется мандантом. Разграничение прав доступа на основе значения этого поля прописывается в логине. Логины пользователя в разных мандантах разные. Разумеется, они не имеют никакого отношения к логину сервера приложений в СУБД. Далее, полномочия в SAP бывают обычными и структурными, последние существуют только в модуле HR и отсутствуют в других модулях. Первые описывают режим доступа к любым элементарным объектам - процедурам, транзакциям (вторые, дополнительные названия процедур разновидности report; не имеют никакого отношения к транзакциям баз данных), инфотипам, таблицам, ракурсам (аналог view из СУБД); вторые описывают режим доступа к поддеревьям организационного плана компании, который состоит из "объектов" и "связей", хранящихся, соответственно, в 1000 и 1001 инфотипах. Связи не имеют никакого отношения к foreign key баз данных.

Связь соединяет два внутренних объекта, т.е. два объекта из модуля HR, или внутренний с внешним, т.е. с объектом из другого модуля, и имеет следующие атрибуты: идентификаторы двух объектов, между которыми связь протянута; направление, везде фигурирует просто как булевское поле "A/B" со значениями "a" - снизу-вверх и "b" - сверху-вниз; имя связи, называемое соединением; два произвольных числа, называемых взвешиванием и приоритетом; даты начала и конца существования связи и временную привязку. Связи между совершенно разнородными парами объектов могут иметь одинаковое имя (соединение). Временная привязка - это ограничение целостности для периода существования, она бывает следующих видов: связь с данным именем и направлением между данными объектами может существовать только один раз за все время существования объектов; может существовать несколько раз, но периоды существования не пересекаются и не образовывают разрывов; только не пересекаются, но возможны разрывы; никаких ограничений. Не существует временной привязки, обязывающей только не образовывать разрывов и допускающей пересечения. Хотя SAP представляет собой собрание анахронизмов, чтобы быть честными до конца, отметим, что этот constraint - одна из трех чужих идей, использованных автором в работе sql50.euro.ru/sql5.19.2.pdf по модернизации SQL (изложена на с.201-205; другие две - на c.161 и 198-200). Однако продолжим.

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

Между плоскими и структурными полномочиями выполняется операция AND, они группируются в профили, профили - в роли, роли - в групповые роли. Вычитания полномочий нет. Роли и групповые роли без модуля HR выдаются напрямую логинам, а после его установки - поддеревьям организационного плана, начинающимся с должностей, штатных должностей, рабочих мест, персон (табельный номер привязывается всё равно к логину в 105-м инфотипе) и организационных единиц компании. Поддерево, которому выдаются полномочия, не имеет количество уровней и путь анализа в качестве ограничений. Не существует механизма не делегировать полномочия какой-либо из его ветвей. Роли SAP не имеют никакого отношения к ролям СУБД.

Ну а теперь про безопасность. Она в SAP низкая: ни логин, ни пароль не ограничивают ABAP-программы, а только поставляют им дополнительные данные: report-ы имеют доступ сразу ко всем инфотипам и таблицам, ко всем их записям, в т.ч. к записям всех мандантов, и сразу по всем операциям - вставка, удаление, изменение, чтение. Существует транзакция SCI для выявления потенциально опасных действий программы до ее запуска, но после запуска проконтролировать и остановить программу не может ничто. Потенциально в системе есть место для двух центров контроля - в ABAP-интерпретаторе и в SQL-интерпретаторе. Однако в первый возможности контроля до сих пор не добавлены, а во втором они отключены - СУБД низведена просто до раздатчика и приемщика записей.

А что вы хотите!? Когда появился ABAP (сравните с датами появления Clipper и Fox)? Чтобы соответствовать современным представлениям, в язык добавили операторы обращения к базе данных, однако убожество пользовательского интерфейса и существование NetWeaver указывают, что SAP никто не переписывал (новые компоненты SAP - они называются AddOn-ы - создаются отдельно в связи с трудностью добавления их в R/3, а с R/3 состыковываются через прокладку под названием NetWeaver). Вы, наверное, представляете, что такое Fox, обращающийся за данными в современную реляционную СУБД (опять же, чтобы соответствовать современным представлениям, в SAP добавлен Java, однако весь продукт наработан на ABAP, и уйти от него невозможно).

Замусоривание базы данных - вещь обычная. Продолжим демонстрацию на все том же "Руководстве пользователя": запустите транзакцию PB40, выберите в ней любое мероприятие, нажмите "Выполнить" (F8); пройдите несколько экранов, введя в них данные - переход от экрана к экрану осуществляется по кнопке "Сохранить" (Ctrl-S); выйдите из транзакции - кнопка "Выход" (Shift-F3) - на каком-нибудь промежуточном этапе, т.е. не доходя до последнего экрана. Вы оставили после себя в базе данных столько записей инфотипов, сколько экранов прошли; rollback не было. А ведь обычны попытки внести несколько раз одного и того же кандидата в сотрудники. Затем он будет использоваться под разными идентификаторами. Падет производительность персонала, рыскающего по длинному списку; персонал демотивирован этим и т.д. Да и удаление дубликатов - процедура, повышающая риск нарушения работы любой системы.

Уже стало общим местом, что экономика пост-индустриального общества питается информацией. Ее крайняя ценность возникла при одновременном стечении двух обстоятельств: продают не товары, а имиджи; не накапливают капитал, а инвестируют. Лучшее, что можно сделать, "попав" на SAP, - отказаться от него и забыть про те деньги, которые уже выбросили на ветер. За саповские деньги вы реализуете любое решение. И в те же сроки - все организации плохо управляются, но никто в этом не признается.

Дмитрий ТЮРИН,
dima.turin@gmail.com