Недавно мы начали рассказывать вам о своём опыте выстраивания процесса безопасной разработки для крупного ритейлера. Если вы вдруг пропустили этот момент, то можете прочитать первую часть о безопасной разработке порталов и мобильных приложений здесь. А сегодня мы раскроем подробности реализации этого проекта в группе приложений семейства SAP.
SAP-приложения были у нашего заказчика самой обширной группой систем с точки зрения объема кода. При этом на старте проекта мы знали о SAP очень мало.
C точки зрения привычного мира разработчиков SAP – это совершенно оторванная от реальности среда, которая «варится» сама в себе. Если в обычном мире ИТ можно выбирать языки программирования для выполнения конкретных задач, архитектуру платформы, строить свой процесс разработки, выбирая из инструментов на каждом этапе, то в SAP никакой свободы нет. Всё жестко регламентировано, поскольку весь процесс разработки реализуется исключительно собственными инструментами немецкого вендора. И все действия разработчиков и инженеров строятся вокруг монолитного стека, созданного SAP.
Основная трудность, с которой мы столкнулись с самого начала, состояла в том, что у нас не было чёткого представления, как выгружать код из столь большой системы. Наш анализатор кода приложений умеет проверять код на языке ABAP, но полноценной интеграции с этим софтом у нас на тот момент не было. Однако мы довольно быстро смогли решить задачу, в том числе с помощью инструмента Mass Downloader.
Для этого потребовалось разобраться в устройстве системы. Мы как инженеры внедрения работали только с SAP Logon (некий front end для работы с платформой). Однако и ее возможностей хватило для решения нашей задачи: можно было открыть SAP Logon и попасть на единый портал, где доступна практически вся необходимая информация – код, текущие задачи, задачи по расписанию и прочее. А для разработчиков эта система является еще и интегрированной средой разработки.
У заказчика особенностью реализации SAP была его тесная интеграция с Jira: в код приложений не могли вноситься изменения, если в Jira не была заведена соответствующая задача. При этом SAP-проекты имели свои, отличные от других двух групп (напомним, это группа кассового ПО и группа порталов и мобильных приложений) особенности заведения задач в Jira. Например, задача на исправление уязвимостей не заводилась, а сначала обсуждалась командой разработки и заранее планировалась, чтобы потом ее можно было официально завести в Jira и принять на исправление. Потому что заведенную в Jira задачу обязательно надо было взять в разработку в указанные сроки, без всяких исключений и отсрочек.
В направлении имелось более 20-ти SAP-систем, каждая из них отвечала за отдельное направление в ритейле: логистические маршруты, управление складами, бухучет, производство и т.п. Все эти системы состояли из нескольких ландшафтов, от трех (dev, test и prod) до пяти (указанные три + регрессионное и функциональное тестирование).
Соответственно, нужно было согласовать с заказчиком, в каком из ландшафтов мы будем анализировать исходный код. С одной стороны, надо было проверять код, актуальный для production, а не для разработки, так как в процессе он сильно менялся. А с другой стороны, необходимо было как можно раньше находить потенциальные уязвимости. В итоге мы решили сканировать код на этапах до регрессионного тестирования и не анализировать production-код, чтобы его не выгружать и не вносить изменения в production-ландшафты.
Экстрактором исходного кода является программа на языке ABAP. Её нужно было скачать и установить в два, а иногда и в три ландшафта каждой из 12-ти систем, которые мы брали на анализ. После установки экстрактора надо было настроить выгрузку исходного кода по расписанию с помощью специально встроенных инструментов. Отдельно загружались функциональные модули, отдельно классы, отдельно – сам исходный код программ для каждого ландшафта, и только после этого код отправлялся в Solar appScreener на анализ.
Как в целом выглядел процесс отправки кода на сканирование? У заказчика имелись Unix-сервера (IBM IX системы для работы SAP-приложений), на них экстрактором выгружался исходный код. Код архивировался и отправлялся по SSH-протоколу на сервер Solar appScreener, на котором каждые 10 минут запускалась по расписанию задача проверки наличия вновь пришедшего кода. Если код пришел, то проверялось, запущен ли анализ в соответствующем проекте для конкретного ландшафта в определенной системе. Если нет, то код ставился в очередь на анализ и анализировался. Затем менеджер по безопасности кода заходил в Solar appScreener, просматривал в соответствующем проекте результаты анализа новой части кода, верифицировал уязвимости и заводил задачи на исправления, которые попадали в Jira.
С точки зрения требований заказчика с SAP-системами не возникло каких-то специфических сложностей. Просто нужно было анализировать исходный код по расписанию раз в день. Однако реализовать это было технически сложно, поскольку для этого ПО как закрытой системы сканирование на уязвимости было абсолютно инородным процессом.
Не знаю, интегрируются ли другие инструменты в процесс разработки SAP, но для нас такая интеграция была нова в принципе, и каждый шаг нам приходилось исследовать, придумывать, прорабатывать. Нужно отдать должное заказчику, инженеры SAP нам очень помогали.
Например, под этот проект нам пришлось модифицировать программу выгрузки исходного кода, поскольку при выгрузке из SAP возникали ошибки, с которыми нам помогали разбираться инженеры заказчика. Для всех систем команда саповцев завела себе пользователя, который отправлял нам по SCP все публичные ключи для всех систем, чтобы мы могли их включить как авторизованные на своем сервере.
Или, например, в некоторых ландшафтах SAP каждые две недели производился полный сброс всех изменений и настроек и откат до версии, реализованной в production, чтобы можно было проводить регрессионное тестирование. Из-за этого в Solar appScreener сбрасывались все задачи по расписанию, и нужно было заново их заводить. Эту проблему вместе с инженерами SAP мы решили следующим образом. Сканирование на уязвимости внедряется в среды разработки и тестирования, а сами задачи и настройки, необходимые для создания задачи по расписанию (конфиги), – в production-системы, но без выгрузки. Тогда при полном сбросе задачу можно быстро восстановить: конфиги сохраняются, и нужно только включить задачу по расписанию.
С помощью инженеров из команды заказчика мы успешно внедрили анализ кода в такую закрытую систему, как SAP. В процессе мы значительно расширили свои знания о самой системе и смогли практически с нуля сделать полноценную интеграцию, успешно применяющуюся в 12-ти независимых SAP-проектах заказчика.
Это и правда круто, когда, реализуя проект, ты многому учишься сам и обогащаешь новыми возможностями свою технологию! Так вышло не только с группой SAP-приложений, но и с приложениями кассового ПО ритейлера. Но об этом проекте мы расскажем уже в следующем посте :-)
Будем рады ответить на вопросы и узнать о вашем опыте реализации практик безопасной разработки в комментариях!
Автор: Иван Старосельский, руководитель отдела эксплуатации и автоматизации информационных систем
Знакомство с SAP
SAP-приложения были у нашего заказчика самой обширной группой систем с точки зрения объема кода. При этом на старте проекта мы знали о SAP очень мало.
C точки зрения привычного мира разработчиков SAP – это совершенно оторванная от реальности среда, которая «варится» сама в себе. Если в обычном мире ИТ можно выбирать языки программирования для выполнения конкретных задач, архитектуру платформы, строить свой процесс разработки, выбирая из инструментов на каждом этапе, то в SAP никакой свободы нет. Всё жестко регламентировано, поскольку весь процесс разработки реализуется исключительно собственными инструментами немецкого вендора. И все действия разработчиков и инженеров строятся вокруг монолитного стека, созданного SAP.
Основная трудность, с которой мы столкнулись с самого начала, состояла в том, что у нас не было чёткого представления, как выгружать код из столь большой системы. Наш анализатор кода приложений умеет проверять код на языке ABAP, но полноценной интеграции с этим софтом у нас на тот момент не было. Однако мы довольно быстро смогли решить задачу, в том числе с помощью инструмента Mass Downloader.
Для этого потребовалось разобраться в устройстве системы. Мы как инженеры внедрения работали только с SAP Logon (некий front end для работы с платформой). Однако и ее возможностей хватило для решения нашей задачи: можно было открыть SAP Logon и попасть на единый портал, где доступна практически вся необходимая информация – код, текущие задачи, задачи по расписанию и прочее. А для разработчиков эта система является еще и интегрированной средой разработки.
У заказчика особенностью реализации SAP была его тесная интеграция с Jira: в код приложений не могли вноситься изменения, если в Jira не была заведена соответствующая задача. При этом SAP-проекты имели свои, отличные от других двух групп (напомним, это группа кассового ПО и группа порталов и мобильных приложений) особенности заведения задач в Jira. Например, задача на исправление уязвимостей не заводилась, а сначала обсуждалась командой разработки и заранее планировалась, чтобы потом ее можно было официально завести в Jira и принять на исправление. Потому что заведенную в Jira задачу обязательно надо было взять в разработку в указанные сроки, без всяких исключений и отсрочек.
Выбор ландшафта для сканирования
В направлении имелось более 20-ти SAP-систем, каждая из них отвечала за отдельное направление в ритейле: логистические маршруты, управление складами, бухучет, производство и т.п. Все эти системы состояли из нескольких ландшафтов, от трех (dev, test и prod) до пяти (указанные три + регрессионное и функциональное тестирование).
Соответственно, нужно было согласовать с заказчиком, в каком из ландшафтов мы будем анализировать исходный код. С одной стороны, надо было проверять код, актуальный для production, а не для разработки, так как в процессе он сильно менялся. А с другой стороны, необходимо было как можно раньше находить потенциальные уязвимости. В итоге мы решили сканировать код на этапах до регрессионного тестирования и не анализировать production-код, чтобы его не выгружать и не вносить изменения в production-ландшафты.
Процесс сканирования
Экстрактором исходного кода является программа на языке ABAP. Её нужно было скачать и установить в два, а иногда и в три ландшафта каждой из 12-ти систем, которые мы брали на анализ. После установки экстрактора надо было настроить выгрузку исходного кода по расписанию с помощью специально встроенных инструментов. Отдельно загружались функциональные модули, отдельно классы, отдельно – сам исходный код программ для каждого ландшафта, и только после этого код отправлялся в Solar appScreener на анализ.
Как в целом выглядел процесс отправки кода на сканирование? У заказчика имелись Unix-сервера (IBM IX системы для работы SAP-приложений), на них экстрактором выгружался исходный код. Код архивировался и отправлялся по SSH-протоколу на сервер Solar appScreener, на котором каждые 10 минут запускалась по расписанию задача проверки наличия вновь пришедшего кода. Если код пришел, то проверялось, запущен ли анализ в соответствующем проекте для конкретного ландшафта в определенной системе. Если нет, то код ставился в очередь на анализ и анализировался. Затем менеджер по безопасности кода заходил в Solar appScreener, просматривал в соответствующем проекте результаты анализа новой части кода, верифицировал уязвимости и заводил задачи на исправления, которые попадали в Jira.
Сложности SAP-проектов
С точки зрения требований заказчика с SAP-системами не возникло каких-то специфических сложностей. Просто нужно было анализировать исходный код по расписанию раз в день. Однако реализовать это было технически сложно, поскольку для этого ПО как закрытой системы сканирование на уязвимости было абсолютно инородным процессом.
Не знаю, интегрируются ли другие инструменты в процесс разработки SAP, но для нас такая интеграция была нова в принципе, и каждый шаг нам приходилось исследовать, придумывать, прорабатывать. Нужно отдать должное заказчику, инженеры SAP нам очень помогали.
Например, под этот проект нам пришлось модифицировать программу выгрузки исходного кода, поскольку при выгрузке из SAP возникали ошибки, с которыми нам помогали разбираться инженеры заказчика. Для всех систем команда саповцев завела себе пользователя, который отправлял нам по SCP все публичные ключи для всех систем, чтобы мы могли их включить как авторизованные на своем сервере.
Или, например, в некоторых ландшафтах SAP каждые две недели производился полный сброс всех изменений и настроек и откат до версии, реализованной в production, чтобы можно было проводить регрессионное тестирование. Из-за этого в Solar appScreener сбрасывались все задачи по расписанию, и нужно было заново их заводить. Эту проблему вместе с инженерами SAP мы решили следующим образом. Сканирование на уязвимости внедряется в среды разработки и тестирования, а сами задачи и настройки, необходимые для создания задачи по расписанию (конфиги), – в production-системы, но без выгрузки. Тогда при полном сбросе задачу можно быстро восстановить: конфиги сохраняются, и нужно только включить задачу по расписанию.
Резюме
С помощью инженеров из команды заказчика мы успешно внедрили анализ кода в такую закрытую систему, как SAP. В процессе мы значительно расширили свои знания о самой системе и смогли практически с нуля сделать полноценную интеграцию, успешно применяющуюся в 12-ти независимых SAP-проектах заказчика.
Это и правда круто, когда, реализуя проект, ты многому учишься сам и обогащаешь новыми возможностями свою технологию! Так вышло не только с группой SAP-приложений, но и с приложениями кассового ПО ритейлера. Но об этом проекте мы расскажем уже в следующем посте :-)
Будем рады ответить на вопросы и узнать о вашем опыте реализации практик безопасной разработки в комментариях!
Автор: Иван Старосельский, руководитель отдела эксплуатации и автоматизации информационных систем
