Как подготовиться к нагрузочному тестированию SAP без деперсонализации и доступа к базе данных
SAP — экосистема для выстраивания общего информационного пространства в больших компаниях.
Однако тестировать его нелегко: создание стенда и обезличивание такого объема данных требует огромных затрат. На собственном опыте рассказываем, как можно организовать нагрузочное тестирование SAP крупного бизнеса без деперсонализации и доступа к конфиденциальной информации.
Постановка задачи
Перед нашей командой стояла задача протестировать SAP большой нефтегазовой компании. С точки зрения доступа к данным дилемма была такой:
Поэтому нам требовалось предложить законченное решение, которое даст доступ к стенду для проведения нагрузочного тестирования и при этом будет соответствовать внутреннему регламенту заказчика.
Шаг первый: договариваемся со службой безопасности
Для нагрузочного тестирования SAP потребовалось три основных типа сотрудников: сотрудник службы информационной безопасности (может иметь доступ к паролям учетных записей), тестировщик (не имеет доступа к паролям, его действия на стенде должны отслеживаться), а также администратор машин, на которых работают сотрудники организации (не должен иметь доступ к паролям).
Сотрудник
службы ИБ
Не может администрировать машины с Loadrunner
Не может проводить НТ
Тестировщик
Не имеет доступ к паролям
Не имеет доступ к администрированию машин с Loadrunner
Доступ к данным на стенде должен как-то отслеживаться
Администратор
Имеет доступ к администрированию всех серверов в организации
Не имеет доступ к паролям
Не может проводить НТ
Администратор хранилища
Имеет доступ к паролям
Не может проводить НТ
Когда мы начали решать проблему, добавился еще один, четвертый сотрудник — администратор хранилища секретной информации. Чтобы провести нагрузочное тестирование, нужно было воплотить техническое решение, которое отвечало бы этим полномочиям.
Для запуска симуляции работы пользователей потребовалось две машины: генератор и контроллер. Для НТ требуется MicroFocus LoadRunner — это стандартный и чуть ли не единственный инструмент для нагрузочного тестирования SAP.
Но процесс оказалось невозможно запустить без разработки такого решения, которое позволило бы не передавать пароли при нагрузочном тестировании SAP из LoadRunner.
Алгоритм действий был таким:
Шаг второй: придумываем техническое решение
Прототип называется PassGiving и является фоновой программой. Он работает на генераторе нагрузки рядом с процессами mmdrv.exe — это процессы LoadRunner, в которых запускаются скрипты.
В скриптах находится стандартный код для обращения в PassGiving. Когда скрипту нужно авторизовать сессию, он вызывает этот код, а код обращается к процессу PassGiving.
Как авторизуются сессии HTTP на портале SAP
Запросы авторизации — обычные запросы на главную страницу. Первый запрос — получение страницы, он возвращает куки. Второй — отправка пользователя и пароля, он также возвращает куки. Последующие запросы авторизуются с помощью этих куков.
Очевидно, эти два запроса нужно просто проксировать, и можно будет авторизовать сессии пользователей, не передавая пароли в скрипт. То есть:
- Вспомогательный код в скрипте вызывает процесс PassGiving.exe;
- PassGiving.exe совершает оба запроса и возвращает куки;
- Куки сохраняются в хранилище LoadRunner так, чтобы следующие запросы могли их использовать.
Есть предполагаемый вектор атаки: тестировщик может сформировать запрос, который будет посылать пароль на свою страницу, с которой этот пароль станет доступным. Для этого случая в прототипе реализована проверка адреса запроса на попадание в белый список.
Как авторизовать сессии SAP GUI
На этапе инициализации пользователя LoadRunner создается клиент SAP GUI:
Этот SAP-клиент и возвращается обратно в скрипт. Скрипты LoadRunner работают с этим объектом через COM-интерфейс («скриптинг» в SAP GUI).
Как получить доступ к клиенту SAP GUI
Перехват сетевого трафика — плохое решение, потому что сервер может использовать шифрование (настраивается в сервере SAP). Перехватывать на системном уровне вызовы COM трудоемко.
Нам повезло: оказалось, что после того, как клиент SAP GUI возвращен в скрипт, он регистрируется в Running Object Table (объект Windows, хранящий запущенные программы ActiveX) . Очевидно, что в таком случае клиент SAP GUI можно получить из этой таблицы после того, как он будет зарегистрирован.
Доступ к клиенту SAP GUI осложняется тем фактом, что клиентов SAP GUI должно быть много (настройка Run as process в LoadRunner), иначе работа виртуальных пользователей замедляется, или виртуальные пользователи спонтанно падают. Для этого нужно будет переименовывать клиенты SAP GUI, чтобы их имена были уникальными.
Как авторизовывать сессию SAP GUI
Вспомогательный код находится в скрипте и вызывает PassGiving. PassGiving получает ссылку на запущенный клиент SAP из RunningObjectTable и совершает вызовы этого объекта, после этого сессия авторизована.
Что, если пользователь запросит пароль на страницу, с которой он сможет его получить? В таком случае, нужно проверять, что пароль вводится в поле типа GuiPassword — из него получить значение нельзя, запрет закреплен в самом клиенте SAP GUI.
Шаг третий: законченное решение
Прототип называется PassGiving и является фоновой программой. Он работает на генераторе нагрузки рядом с процессами mmdrv.exe — это процессы LoadRunner, в которых запускаются скрипты.
Прототип, о котором мы рассказывали, — всего лишь одна составляющая решения. Компонентов несколько:
Выше — схема использования решения от начала до конца. Подписи на ребрах графа — действия, пронумерованные в логическом порядке. Результат выполнения этой схемы — авторизация сессий SAP GUI и HTTP без передачи паролей в скрипт.
Сложность конечного решения обусловлена двумя факторами:
Итог работ
Задача потребовала как организационных навыков, так и навыков низкоуровневой разработки и, естественно, составления документации. В результате заказчик получил решение, которое прошло аудит безопасности и аудит производительности. Оно обеспечило допуск штатных сотрудников к стенду для проведения нагрузочного тестирования без доступа к паролям, не нарушая требований к конфиденциальности. Заказчику не пришлось тратить значительные средства на дополнительный стенд и наполнение базы обезличенными данными — оба варианта были бы непозволительно дорогими в условиях проекта. Использование нашей технологии позволило успешно проводить тестирование на препродакшне, не боясь создавать тысячи учетных записей для нужд тестирования.
Над материалом работали:
