• Новости
• Блоги
• Аналитика
• Новости компаний
• В СНГ и в мире
• Анонсы

DevSecOps как PaaS

Безопасность ПО надо обеспечивать, начиная с этапа разработки, и вести такую разработку эффективнее в облаке. Облачные провайдеры стали предлагать DevSecOps как управляемую услугу.

Безопасные программы

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

В 2022 г. ситуация радикально изменилась. Атаковать начали всех, и не только ради денег, а просто для нанесения максимального ущерба. Атаковать веб-приложения компаний, их подрядчиков, всё российское, до чего можно дотянуться через интернет. Выросла и юридическая ответственность компаний, причем за утечки некоторых персональных данных — вплоть до уголовной. Кибербезопасность стала проблемой для всех.

Установка наложенных средств защиты помогает не всегда. Затыкать «дыры» после взлома нужно, но поздно, гораздо эффективнее обеспечивать безопасность уже на этапе разработки. Разработка тоже изменилась — вендоры уходят от использования медленного классического каскадного метода и превращают разработку в непрерывный автоматизированный процесс, в рамках которого компании внедряют методологии DevOps, объединяющие разработчиков (Development) и специалистов ИТ-поддержки (Operations) для ускорения вывода программного продукта на рынок и повышения его качества. Логическим развитием DevOps стало внедрение в процесс проверки безопасности разрабатываемого кода (Security). Так появилась модель DevSecOps, интегрирующая безопасность во все этапы жизненного цикла разработки программного обеспечения. Команды из разработчиков и специалистов поддержки отвечают теперь не только за контроль качества и интеграцию кода, но и за его безопасность. Они обсуждают влияние кода на ИБ во время планирования, выявляют проблемы безопасности в средах разработки, не ожидая ее окончания.

Источник: SwordFish

Практики DevSecOps

Изменились и методы проверки. Теперь это не только статический анализ (SAST), выполняемый на исходном коде приложения без его запуска, но и динамический (DAST), тестирующий рабочую программу. Стал использоваться компонентный анализ ПО (SCA), идентифицирующий сторонние и открытые компоненты, интегрированные в приложения, оценивающий риски их использования и соблюдения лицензионных требований. Проводится анализ используемых приложением библиотек с открытым исходным кодом (OSA) и программных интерфейсов (API ST).

Преимущества DevSecOps

«Каждые 100 руб., потраченные компанией на выявление уязвимостей на этапе разработки, экономят 500 руб. на исправление ошибок в ходе эксплуатации. Лучше потратить деньги на анализы, чем на лечение», — отметил Александр Мухин, менеджер по работе с ключевыми клиентами компании SwordFish, на DevHops-митапе, организованном компанией Nubes и ассоциацией профессионалов в сфере облачных технологий RCCPA. В идеале при использовании DevSecOps разработчики получают целостный CI/CD-конвейер (непрерывная интеграция и непрерывная доставка) со встроенными проверками на безопасность, безопасники уменьшают число уязвимостей в коде продукта, могут сэкономить на тестах и выплатах багбаунти. Кроме того, бизнес обретает возможность выполнить требования стандартов по безопасной разработке и улучшить взаимоотношения разработчиков, безопасников и эксплуатантов, которые обычно редко имеют общие интересы, но, работая в одной команде, начинают понимать проблемы друг друга.

Выступает Александр Мухин

По мнению эксперта, инструменты, автоматизирующие DevSecOps, обязательны для банков и финансовых организаций, вендоров средств защиты информации и крупных продуктовых компаний со штатом более 200 программистов. Их уже применяют «Почта России», Сбер, ВТБ, «Ростелеком» и Газпромбанк. Использование DevSecOps актуально и для компаний — разработчиков ПО, имеющих более 50 программистов.

DevSecOps и облака

Подход DevSecOps можно применять не только на площадке клиента, но и в облаке, причем последний вариант становится все более популярным. В облаке можно быстро попробовать новые продукты, протестировать решения под разными версиями ОС, обеспечить работу географически распределенных команд. «Сейчас примерно половина DevOps/DevSecOps-продуктов и услуг предоставляются по облачной модели, и доля будет расти. Это связано как с ростом использования облачных инфраструктур, так и с популяризацией таких практик облачными гиперскейлерами, которые активно пропагандируют оптимизацию DevOps/DevSecOps-процессов при помощи своих готовых инструментов», — дал комментарий нашему изданию член оргкомитета RCCPA Антон Салов.

Подобные предложения есть и на российском рынке. Инструменты DevSecOps из облака предоставляют облачные провайдеры Selectel, Yandex Cloud, VK Cloud, MWS, Сloud.ru, уже внедрившие такие практики и процессы в свою разработку. При этом облачный провайдер часто берет на себя не только администрирование сервисов, но и консультационную поддержку, что позволяет заказчикам не иметь в штате дорогостоящих DevOps-инженеров.

DevSecOps стали предлагать и по модели PaaS, причем как управляемый сервис. «Новому облачному провайдеру нужно заявить о себе на рынке, продемонстрировать новые услуги, выделяющие его среди конкурентов. Мы предлагаем DevSecOps из облака, причем как управляемую провайдером услугу, не требующую от заказчика специализированной экспертизы», — рассказал генеральный директор компании Nubes Василий Степаненко.

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

Трактовать результаты отчасти помогают системы ИИ, активно внедряемые вендорами. Но когда речь идет о безопасности, все не так просто. «Основная масса атак стандартна, выполняется с помощью опубликованных инструментов и через типовые уязвимости, которые эксплуатируются низкоквалифицированными злоумышленниками. Для их выявления часто достаточно работы ИИ. Но хакер высокого уровня мыслит нестандартно, и для противодействия ему не обойтись без столь же нестандартно мыслящего человека, который сможет объективно оценить угрозы, выявленные инструментами ИБ, в том числе в рамках процессов DevSecOps», — пояснил член оргкомитета RCCPA Михаил Соловьев. Так что без помощи квалифицированного специалиста по DevSecOps не обойтись, а если их нет в компании, лучше привлекать стороннюю экспертизу, в частности, облачного провайдера.

DevSecOps и регулирование

На уязвимость работающих в финансовой сфере программ, прежде всего систем дистанционного банковского обслуживания, обратил внимание Банк России и стал требовать проведения оценки уровня доверия (ОУД) используемого ПО. В 2018 г. Положение Банка России от 25.06.2012 № 382-П (основное положение по ИБ для банков) было дополнено п. 2.5.5.1, согласно которому для осуществления денежных переводов необходимо использовать автоматизированные системы и приложения, которые имеют сертификат ФСТЭК на соответствие требованиям по безопасности информации (включая анализ уязвимостей и контроль отсутствия недекларированных возможностей) или в отношении которых проведен анализ уязвимостей по требованиям к оценочному уровню доверия не ниже чем ОУД 4 в соответствии с ГОСТ Р ИСО/МЭК 15408-3-2013. В дальнейшем требования по оценочному уровню доверия появилось и в других нормативных документах: положениях Банка России № 672-П (через ссылку на ГОСТ Р 57580.1-2017, где в требованиях ЖЦ.8 и ЖЦ.20 косвенно формулируется ежегодный ОУД 4), № 683-П, № 684-П и № 719-П.

Требования к работам по ОУД касаются программного обеспечения, которое либо распространяется клиентам организации, либо доступно через интернет неограниченному кругу лиц. А такого ПО немало, и его разработчикам нужно регулярно демонстрировать выполнение требований Банка России. И здесь тоже может помочь предоставляемый из облака сервис DevSecOps.

«Бумажная» сторона безопасности разработки помимо предприятий финансовой сферы затрагивает и тех, кто желает соответствовать стандарту требований к безопасности данных в сфере платежных карт PCI DSS (v4.0.1). Круг таких организаций достаточно широк: платформы электронной коммерции; принимающие платежи по кредитным картам розничные предприятия; компании, предоставляющие клиентам возможность самостоятельно оплачивать услуги через терминалы или онлайн-платежи (например, АЗС, парковки); компании, хранящие, обрабатывающие или передающие данные держателей карт. Чтобы пройти независимый аудит и получить сертификацию на соответствие требованиям PCI DSS, им надо, в том числе, доказать безопасность разработки используемых программ. Такое свидетельство сможет дать облачный провайдер, обеспечивающий DevSecOps, и тогда не придется покупать дорогостоящее ПО и различные сканеры для проверок — достаточно использовать имеющиеся в облаке.

В целом DevSecOps из облака представляется логичным развитием услуг PaaS и имеет неплохой потенциал. Насколько сервис будет востребован — покажет рынок.