Связаться с редакцией
Кто такие три богатыря ИТ?
Как должны быть построены корпоративные ИТ?
Почему между разработкой, эксплуатацией и информационной безопасностью до сих пор нет взаимопонимания?
ИТ в крупных компаниях — это комплексная система, взаимоувязывающая 3 основных блока: разработку, эксплуатацию и информационную безопасность. Образно их можно назвать тремя «богатырями». Каждый из них реализует свои цели и задачи, у каждого свои KPI, иногда даже противоречащие двум другим блокам, и, конечно, свои проблемы.
Разработка — самый стремительный из «богатырей». Разработчики несут все новое. Их требования просты: дайте API, доступ к ресурсам, сделайте так, чтобы не пришлось разбираться, как работает инфраструктура, и не мешайте.
Какой бы инновационной ни была компания, если она достаточно зрелая, служба безопасности будет играть в ней не последнюю роль. Поэтому разработчикам приходится соблюдать определенные правила (иногда дурацкие, с их точки зрения). Например, писать служебки с просьбой открыть доступ к нужным портам, а затем с грустью обнаруживать, что порты открыли не те и не там. Как ни крути, а без взаимодействия не обойтись.
Безопасность — самый сильный богатырь. Есть присказка: чтобы безопасник спал спокойно, ему необходимо ограничить остальным доступ ко всем ресурсам. Конечно, это не так, ведь запрет — это низшая форма контроля. Специалисты по безопасности хотят иметь инструменты для эффективной оценки рисков, а также для мониторинга и контроля за тем, что происходит во вверенных им системах.
ИБ-шники предпочли бы заранее знать о потенциальных проблемах в коде или инфраструктуре, чтобы сыграть на опережение. Но в реальности разработчики и инфраструктурщики ставят их в известность о новом приложении по факту его запуска в продуктив.
руководитель блока Security по направлению DevSecOps компании «Инфосистемы Джет»:
Комментарий
Цель любой службы безопасности ― нивелировать риски и не дать злоумышленникам воспользоваться уязвимостями. Однако порой службе безопасности неизвестны даже детали разработки, не говоря уже о постоянных обновлениях тех же приложений. Если безопасность не может что-то контролировать, остается только один путь ― все запрещать.
Эксплуатация — самый веселый богатырь. Ему достается больше всего: на него валятся срочные, зачастую неструктурированные запросы от разработчиков и безопасников. Приходится сталкиваться с постоянной нехваткой ресурсов, рутиной и отсутствием времени на развитие. Да еще и решения разработчиков не соответствуют корпоративным стандартам, и совершенно непонятно, как реализовывать то, чего хотят безопасники.
Что мешает разработке, безопасности и эксплуатации работать вместе? Приведу пример. Группа разработчиков предлагает бизнесу создать новый продукт. За пару недель готовится прототип, проводится показ, достигается wow-эффект. Довольный клиент дает разработчикам добро на вывод решения в production. Как вы думаете, что произойдет после того, как они придут с этим запросом к безопасности и эксплуатации? Они получат целый список требований по доработке продукта.
руководитель блока Security по направлению DevSecOps компании «Инфосистемы Джет»:
Комментарий
Один из основных посылов культуры DevSecOps заключается в том, что все преимущества методологии зависят от совместной работы: общих целей, интересов, обмена опытом и т.п. DevSecOps как методология разработки ― тот самый инструмент, который призван положить конец вражде и обеспечить совместное движение к целям, которые преследует бизнес. Разработка будет повышать скорость выпуска продукта, а безопасность — улучшать его качество.
руководитель блока Development по направлению DevSecOps компании «Инфосистемы Джет»:
Комментарий
Успешность бизнеса — в инновациях и умении оперативно выводить новые идеи на рынок. Поэтому разработчики, находящиеся ближе всего к бизнесу, должны иметь возможность раскрыть свой творческий и технический потенциал и сосредоточиться именно на реализации бизнес-потребностей и сокращении Time-to-Market.
По этой причине, достигая определенного уровня зрелости в компании, все 3 направления работают согласованно для достижения общей цели. Эксплуатация предоставляет для разработки полигон — удобные инфраструктурные сервисы. А безопасность встраивает в конвейер непрерывной интеграции свои инструменты для повышения уровня ИБ и обеспечения защиты инфраструктуры после выхода ПО в продуктивную среду.
Это происходит потому, что каждый из трех богатырей смотрит на ИТ со своей колокольни, не видя картину целиком. На рис. 1 показано, как выглядит мир глазами разработчика. Есть только то, что нужно для создания и запуска продукта.
А вот как должна выглядеть картина целиком (рис. 2).
Рассмотрим ее подробнее. Первый крупный блок — инструменты разработки и тестирования (рис. 3).
Разработчики должны понимать, что современная инфраструктура и безопасность тоже живут в коде. Как следствие, им можно и нужно применять все те же практики, что и для прикладного ПО: переиспользование, контроль версий, тестирование и практики inner-source. Понимание этого позволит всем участникам говорить на одном языке.
Один из ключевых блоков — платформа управления (рис. 4).
Здесь для каждого из наших богатырей важна обратная связь в виде мониторинга. Она позволяет понять, что происходит на самом деле, на чем нужно сфокусировать усилия, что доработать, нужна ли оптимизация.
Следующий блок — вычислительные ресурсы (рис. 5).
Они неоднородны и включают подблоки: традиционную, облачную и специализированную ИТ-инфраструктуры. При этом весь блок поставляет ресурсы в унифицированном виде. Это дает возможность использовать как тяжелые машины, построенные на Enterprise-решениях, так и специализированное ПО, например для 3D-графики, размещенное в облаке.
Последний блок — безопасность (рис. 6).
Чтобы разработка была эффективной, необходимо как можно раньше интегрировать ИБ в процесс создания продукта. Важно, чтобы безопасники принимали активное участие как в самой разработке, так и в проектировании вычислительной инфраструктуры для развертывания решения.
руководитель блока Security по направлению DevSecOps компании «Инфосистемы Джет»:
Комментарий
Александр привел хороший пример «джентльменского» набора, хотя, конечно, инструментов и методик сильно больше, причем многие из них являются «комбайнами», включающими в себя несколько решений.
Если говорить о подходе ShiftLeft (привлечение на как можно более ранних стадиях), он не является ноу-хау, это уже отработанный метод, доказавший свою эффективность. Его стоит применить и к безопасности, так как часто она незаслуженно сдвигается в самый конец цикла, что способствует «удорожанию» исправления кода при наличии уязвимостей.
На сегодняшний день безопасность в большинстве случаев стоит в стороне и выполняет согласующую функцию, что нельзя назвать полноценным участием в разработке. Отсюда и множество проблем с безопасностью выпускаемого кода. Чтобы изменить ситуацию, необходимо вовлекать безопасность в весь цикл разработки, и в первую очередь — к DevSecOps (для чего точно потребуется менеджмент с «политической» волей).
руководитель блока Development по направлению DevSecOps компании «Инфосистемы Джет»:
Комментарий
Не нужно бояться ломать привычные подходы, выходить за рамки своих задач, повышать техническую экспертизу и смотреть на то, как работают коллеги из смежных отделов. Это позволит выстроить правильную культуру по взаимодействию разработчиков, инженеров по эксплуатации и безопасности. Никакие регламенты и процессы не будут работать идеально, пока люди не начнут говорить на одном языке, не станут хорошо понимать проблемы друг друга и видеть общую цель.
Я хочу закончить статью высказыванием Альберта Эйнштейна: «We cannot solve our problems with the same thinking we used when we created them». Иначе говоря, для того чтобы три наших богатыря двигались в одном направлении, нужен принципиально иной подход. Начинать изменения я предлагаю с себя.
Александр Садыков
руководитель блока Development по направлению DevSecOps компании «Инфосистемы Джет»:
Комментарий
В крупных компаниях меняется парадигма взаимодействия между разработчиками и безопасниками. Разработка начинает понимать, что чем раньше найдут уязвимости в софте, тем проще будет их устранить. Тем более что не существует разницы относительно того, какой дефект устранять: исправить некорректно работающую функцию или устранить уязвимость. Все равно требуется доработка исходного кода ПО.