Как DevSecOps расширяет возможности гражданских разработчиков

Всего к 2025 г. создание глобальных данных достигнет 181 зеттабайта. Для предприятий эти данные являются активом, позволяющим им использовать различные технологические платформы для создания высоко персонализированного клиентского опыта, который вызывает лояльность и привлекает новых клиентов. Однако эти возможности зависят от облачных инфраструктур, использующих общие режимы безопасности. Вот где кроется риск, и он увеличивается по мере того, как технология растет, чтобы включить новую армию гражданских разработчиков, использующих платформы с низким кодом и без кода.

Понимание и преодоление мышления наследования 

Gartner По оценкам, к 2025 году 70% корпоративных приложений будут создаваться на платформах с минимальным кодом и без кода, таких как Salesforce и ServiceNow. Реагирование с мышлением, основанным на наследовании, — это верный способ настроить более двух третей корпоративных приложений на провал.   

«Мышление наследования» — подходящее описание проблем, преследующих инфраструктуру. Это напоминает богатых, избалованных детей, которые полностью зависят от проделанной работы и людей, которые были до них. Это не лучший способ создать наследие, и в равной степени плохой способ построить систему.

Когда у вас устаревшее мышление, вы предполагаете, что инфраструктура настроена. Платформа безопасна, и встроенная система безопасности. Доверие предполагается просто потому, что технология появилась до администратора.

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

Допустим, разработчики Salesforce создают программу автоматического назначения для новых лидов. Они используют его в Salesforce для внутренних заданий, и это нормально. Они могут положиться на безопасность платформы. Они решают расширить его, чтобы улучшить автоматизацию. Они подключают эту программу к внешней CRM, такой как ServiceNow, SAP или Oracle. Мышление наследования берет верх: Salesforce безопасна. ServiceNow, SAP или третья сторона в безопасности.

Таким образом, Salesforce + третья сторона = безопасность.

Но в этом плюсе много неизвестного. Как безопасно и в соответствии с требованиями подключить внутреннюю программу, созданную в Salesforce, к внешней программе, созданной на сторонней платформе? В этом единственном персонаже есть много места для ошибки.  

И это только одно соединение. Многие программы, созданные в Salesforce, затрагивают сотни других. Это сотни неизвестных, с которыми обращаются как со знаком плюс, описанным выше, людьми, у которых практически нет опыта разработки.  

Единственное решение — вернуть эту разработку на землю, вернувшись к принципам DevSecOps.

Создание инфраструктуры DevSecOps 

DevSecOps Фреймворки писались, переписывались и снова писались с момента создания концепции. Нет необходимости изобретать велосипед при их установке, особенно когда SAFECode и Альянс облачной безопасности воздвиг шесть столпов:

1. Коллективная ответственность: Безопасность — это обязанность каждого человека на предприятии, но люди не могут соответствовать стандартам, которых они не знают. Следует назначать руководителей для реализации политики кибербезопасности и обеспечения ее распространения по всему предприятию.  
2. Сотрудничество и интеграция: Знания необходимо распространять и передавать. Половина причин, по которым предприятия переходят к устаревшему мышлению, заключается в том, что все, кто знал старую систему, ушли. Непрерывный обмен знаниями помогает решить эту проблему.
3. Прагматичная реализация: Прагматичная реализация связана с опытом разработчиков. Трудные, обыденные и громоздкие процессы не выполняются долго. Безопасность должна быть встроена в практику разработки, то есть каждая строка кода требует проверки. Высокопроизводительное предприятие пошло бы дальше, используя инструмент для автоматизации каждой строки тестового кода.
4. Соответствие и развитие: Требования соответствия должны направлять процесс разработки таким образом, чтобы разработчики не могли отклоняться от них. Например, разработчик финансового учреждения будет работать на платформе, разработанной в соответствии с законом Грэмма-Лича-Блайли. Разработчику не нужно знать отдельные тонкости действия, чтобы соответствовать требованиям, потому что они встроены в платформу.  
5. Автоматизация: Предсказуемые, повторяемые и объемные задачи следует по возможности автоматизировать, чтобы снять нагрузку с разработчиков и снизить риск человеческой ошибки.
6. Монитор: Современные облачные инфраструктуры меняются и растут. Крайне важно следить за этим — в идеале, с помощью какой-либо формы оркестровки, которая позволяет сразу увидеть все различные взаимосвязи.

В низкий или нулевой код окружающей среде, эти столпы не так просты, как можно было бы ожидать. Люди, использующие эти инструменты, часто являются бизнес-экспертами, мало знакомыми с основами DevSecOps.

Объединение людей, процессов и технологий

Использование low-code и no-code платформ действительно может помочь закрыть этот пробел в навыках. Сотрудники хотят освоить новые навыки. Предприятия могут поддержать это, создав структуру DevSecOps, ориентированную на людей, процессы и технологии. 

• Процессы: В среде с нулевым доверием разработчикам low-code и no-code не нужно беспокоиться об установлении соединений, которые угрожают целостности системы, потому что они не в состоянии это сделать. У них нет базовых полномочий за пределами их изолированной системы.  
• Люди: Культура ответственности отличается от культуры обвинения. Подотчетность означает, что люди чувствуют себя комфортно, сообщая о проблеме или ошибке, потому что основное внимание уделяется проблеме, а не человеку.
• Наши технологии: Технологии — это самое большое препятствие для надлежащей реализации принципов DevSecOps, потому что они не зависят от разработчиков. Они должны использовать то, что дает им организация. Если эта технология не работает, разработчики придумают обходные пути, которые не являются ни безопасными, ни безопасными. По сути, технология становится одним большим теневым генератором ИТ.

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