В тематическом плане «Б.О» было запланировано всего несколько материалов, касающихся Agile, DevOps, DevSecOps и других лучших практик написания безопасного ПО, его разворачивания и доставки до клиента. Казалось, что новизны для финансистов здесь нет — повторение пройденного материала. Однако глобальный переход бизнеса на удаленный режим работы в условиях пандемии показал и доказал обратное: все мы только в начале пути.

Сервисы часто оказываются недоступны из-за возросшего трафика, само ПО, написанное в духе ускорения time-2-market едва ли не на коленке, оказывается «дырявым». А главное, сервисы, написанные для работы в тех, «довирусных» временах, нужно срочно затачивать под новые «удаленные реалии». Одной из таких реалий стал дружный переход на облачные технологии и микросервисы взамен клиент-серверной архитектуры и монолитных приложений.

Никаких иных бизнес-подходов для осуществления этого, кроме методик Agile и родственных ему, не просмотрено. И как быть с основной проблемой гибкой разработки — с информационной безопасностью? О DevSecOps говорили довольно давно, и отдельные разработчики им даже успешно пользовались. а теперь пришло время и всем остальным приступить к встраиванию процесса безопасной разработки в процесс DevOps и ничего не сломать. При этом в России есть своя специфика, и ее надо учитывать.

Перед тем как в марте 2020 года большинство разработчиков полностью ушло в онлайн, состоялось несколько значимых мероприятий по этой тематике: конференция DevOps Conf 2019, а также закрытый бизнес-ужин компании Axoft, посвященный DevSecOps, и XII Уральский форум «Информационная безопасность финансовой сферы», прошедшие в феврале 2020 года. Это настоящий кладезь знаний, давайте ими воспользуемся!

Для погружения в анатомию DevSecOps на данном этапе наверняка будет достаточно разобрать сделанную на мероприятии Axoft презентацию Никиты Борзых, архитектора инфраструктурных решений компании «Экспресс 42», одного из организаторов DevOps Conf.

Методики безопасной разработки ПО появились не вдруг и неслучайно. В свое время в Microsoft поняли, что качество их кода не укладывается ни в какие рамки и ради сохранения своей репутации лидера рынка предложили подход SDLC (Security Development Lifecycle), который впоследствии стал каноническим.

Методики безопасной разработки ПО появились не вдруг и неслучайно

Сочетание Application Security (раздел ИБ, отвечающий за безопасность приложений в целом) и SDLC развернуло вектор разработчиков с обнаружения уязвимостей на предотвращение их появления. Традиционный порядок вопросов — «как?» и «зачем?» — стал подвергаться сомнению. Канонический SDLC, получивший свою детализацию в различных методологиях — OpenSAMM (Open Software Assurance Maturity Model), BSIMM (Building Security in Maturity Model), OWASP(Open Web Application Security Project) и др., расставил все по местам.

Так зачем нам вообще нужен DevSecOps? По словам Никиты Борзых, можно выделить четыре момента:

• реалии ускорения time-2-market требуют почти моментального развертывания кода в промышленной среде (Production) едва ли не параллельно с его тестированием, настройкой переключателей функциональности (Feature ags), постепенного развертывания новых версий приложений в целях раннего выявления ошибок (Canary deployment) и т.д.;
• служба ИБ становится сдерживающим фактором в скорости поставки сервисов на рынок, что провоцирует разработчиков на обход требований ИБ;
• команды разработки сами эксплуатируют свои сервисы в Production в полном соответствии с ущербным принципом: больше людей — больше доступов;
• стоимость атаки на эксплуатирующую сервис компанию или банк становится гораздо меньше, чем раньше, а нужно бы сделать наоборот!

Так что же делать? С чего начать? Ответ на этот вопрос был сформулирован так:

• необходимо выбрать фреймворк, который описывает используемые во всем мире практики и подходы к обеспечению безопасности разработки и эксплуатации ПО;
• определиться с детализацией SDLC, например BSIMM. Основа методологии — разделение процесса Application Security на четыре домена: Governance, Intelligence, SSDL Touchpoints и Deployment. В каждом домене 12 практик, которые представлены в виде 112 активностей, у каждой из них есть три уровня зрелости: начальный, средний и продвинутый;
• постановка задачи по внедрению и продвижению любого процесса управления в организации должна соответствовать уровню организационного и технологического развития, в частности уровню процессов обеспечения безопасности. Оборудование не всегда может спасти. Если персонал в целом не обладает необходимой производственной и корпоративной культурой, то очень быстро придется списать в убыток инвестиции в средства защиты. Поэтому необходимо с помощь экспертов выбрать и наполнить модель зрелости, например OpenSAMM.

Детали всех этих шагов были описаны Никитой Борзых достаточно подробно в презентации. Но одно дело — изучать best practices в теории, а другое — использовать их на практике. Константин Савченко, руководитель департамента технического консалтинга, аудита и инженерной поддержки компании Axoft, в этой связи отметил: «Пройдут еще три — пять лет, пока зрелость процессов разработки в средней компании достигнет стандартов, описанных в методологиях. Многие команды разработчиков ввиду отсутствия опыта и отдельных ролей, налаженных процессов в организации будут изобретать велосипед, пока в конце концов не придут к описанным схемам эффективного взаимодействия при разработке приложений».

Что касается человеческого фактора в DevSecOps, то о нем ярко рассказал Дмитрий Гадарь, руководитель департамента информационной безопасности Tinkoff.ru, на Уральском форуме. Если суммировать различные мнения по этому поводу, то получается следующая история.

Пройдут еще три — пять лет, пока зрелость процессов разработки в средней компании достигнет стандартов, описанных в методологиях

Обычно в средней компании на 100–200 разработчиков приходится один представитель службы информационной безопасности, который параллельно выполняет несколько функций в условиях жесткого регуляторного давления и физически не успевает не то что все проверять, но даже вникать. В одиночку он не может проверить весь код. Лучшие мировые практики предлагают в качестве решения проблемы концепт Security Champions — человек, являющийся точкой входа в команду разработки и евангелистом безопасности в одном лице. Security Champions знают свой продукт: что с чем взаимодействует и на что смотреть в первую очередь — они эффективнее. Но этот человек не один, в команде существует целая иерархия ролей, что стимулирует ее участников к саморазвитию.

В заключение необходимо отметить, что мероприятие Axoft привлекло внимание и к технологической трансформации стека технологий, поддерживающих жизненный цикл приложений, в частности, с использованием микросервисов. Так, были разобраны принципы безопасной разработки корпоративных приложений на базе Red Hat OpenShift и Prisma Cloud Compute Edition (ex. Twistlock). Prisma — решение от компании Palo Alto Networks, позволяющее защищать физические серверы, виртуальные машины, контейнеры, кластеры Kubernetes, CaaS, PaaS и бессерверные приложения. Актуальность этой темы наглядно продемонстрировал Росбанк, который первым в России повысил уровень защиты инфраструктуры приложений с помощью Prisma.