Кто такие три богатыря (3 основных блока) ИТ?
Программное обеспечение Программное обеспечение

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

Главная>Программное обеспечение>Три богатыря корпоративных ИТ
Программное обеспечение Тренд

Три богатыря корпоративных ИТ

Дата публикации:
29.09.2020
Посетителей:
228
Просмотров:
252
Время просмотра:
2.3

Авторы

Автор
Александр Краснов Руководитель лаборатории DevSecOps «Инфосистемы Джет»

Кто такие три богатыря ИТ?

 

Как должны быть построены корпоративные ИТ?

 

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

 

 

ИТ в крупных компаниях — это комплексная система, взаимоувязывающая 3 основных блока: разработку, эксплуатацию и информационную безопасность. Образно их можно назвать тремя «богатырями». Каждый из них реализует свои цели и задачи, у каждого свои KPI, иногда даже противоречащие двум другим блокам, и, конечно, свои проблемы.

 

Разработка — самый стремительный из «богатырей». Разработчики несут все новое. Их требования просты: дайте API, доступ к ресурсам, сделайте так, чтобы не пришлось разбираться, как работает инфраструктура, и не мешайте.

 

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

 

Безопасность — самый сильный богатырь. Есть присказка: чтобы безопасник спал спокойно, ему необходимо ограничить остальным доступ ко всем ресурсам. Конечно, это не так, ведь запрет — это низшая форма контроля. Специалисты по безопасности хотят иметь инструменты для эффективной оценки рисков, а также для мониторинга и контроля за тем, что происходит во вверенных им системах.

 

ИБ-шники предпочли бы заранее знать о потенциальных проблемах в коде или инфраструктуре, чтобы сыграть на опережение. Но в реальности разработчики и инфраструктурщики ставят их в известность о новом приложении по факту его запуска в продуктив.

Александр Садыков

руководитель блока Development по направлению DevSecOps компании «Инфосистемы Джет»:

Комментарий

 

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

Дмитрий Ключников

руководитель блока Security по направлению DevSecOps компании «Инфосистемы Джет»:

Комментарий

 

Цель любой службы безопасности ― нивелировать риски и не дать злоумышленникам воспользоваться уязвимостями. Однако порой службе безопасности неизвестны даже детали разработки, не говоря уже о постоянных обновлениях тех же приложений. Если безопасность не может что-то контролировать, остается только один путь ― все запрещать.

Эксплуатация — самый веселый богатырь. Ему достается больше всего: на него валятся срочные, зачастую неструктурированные запросы от разработчиков и безопасников. Приходится сталкиваться с постоянной нехваткой ресурсов, рутиной и отсутствием времени на развитие. Да еще и решения разработчиков не соответствуют корпоративным стандартам, и совершенно непонятно, как реализовывать то, чего хотят безопасники.

 

Что мешает разработке, безопасности и эксплуатации работать вместе? Приведу пример. Группа разработчиков предлагает бизнесу создать новый продукт. За пару недель готовится прототип, проводится показ, достигается wow-эффект. Довольный клиент дает разработчикам добро на вывод решения в production. Как вы думаете, что произойдет после того, как они придут с этим запросом к безопасности и эксплуатации? Они получат целый список требований по доработке продукта.

Дмитрий Ключников

руководитель блока Security по направлению DevSecOps компании «Инфосистемы Джет»:

Комментарий

 

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

Александр Садыков

руководитель блока Development по направлению DevSecOps компании «Инфосистемы Джет»:

Комментарий

 

Успешность бизнеса — в инновациях и умении оперативно выводить новые идеи на рынок. Поэтому разработчики, находящиеся ближе всего к бизнесу, должны иметь возможность раскрыть свой творческий и технический потенциал и сосредоточиться именно на реализации бизнес-потребностей и сокращении Time-to-Market.

 

По этой причине, достигая определенного уровня зрелости в компании, все 3 направления работают согласованно для достижения общей цели. Эксплуатация предоставляет для разработки полигон — удобные инфраструктурные сервисы. А безопасность встраивает в конвейер непрерывной интеграции свои инструменты для повышения уровня ИБ и обеспечения защиты инфраструктуры после выхода ПО в продуктивную среду.

Это происходит потому, что каждый из трех богатырей смотрит на ИТ со своей колокольни, не видя картину целиком. На рис. 1 показано, как выглядит мир глазами разработчика. Есть только то, что нужно для создания и запуска продукта.

Рисунок 1. Корпоративные ИТ глазами разработчика, или Контейнеры — это круто!

А вот как должна выглядеть картина целиком (рис. 2).

Рисунок 2. Корпоративные ИТ в реальности

Рассмотрим ее подробнее. Первый крупный блок — инструменты разработки и тестирования (рис. 3).

Рисунок 3. Инструменты разработки и тестирования

Разработчики должны понимать, что современная инфраструктура и безопасность тоже живут в коде. Как следствие, им можно и нужно применять все те же практики, что и для прикладного ПО: переиспользование, контроль версий, тестирование и практики inner-source. Понимание этого позволит всем участникам говорить на одном языке.

 

Один из ключевых блоков — платформа управления (рис. 4).

Рисунок 4. Платформа управления

Здесь для каждого из наших богатырей важна обратная связь в виде мониторинга. Она позволяет понять, что происходит на самом деле, на чем нужно сфокусировать усилия, что доработать, нужна ли оптимизация.

Следующий блок — вычислительные ресурсы (рис. 5).

Рисунок 5. Вычислительные ресурсы

Они неоднородны и включают подблоки: традиционную, облачную и специализированную ИТ-инфраструктуры. При этом весь блок поставляет ресурсы в унифицированном виде. Это дает возможность использовать как тяжелые машины, построенные на Enterprise-решениях, так и специализированное ПО, например для 3D-графики, размещенное в облаке.

 

Последний блок — безопасность (рис. 6). 

Рисунок 6. Инструменты информационной безопасности

Чтобы разработка была эффективной, необходимо как можно раньше интегрировать ИБ в процесс создания продукта. Важно, чтобы безопасники принимали активное участие как в самой разработке, так и в проектировании вычислительной инфраструктуры для развертывания решения.

Дмитрий Ключников

руководитель блока Security по направлению DevSecOps компании «Инфосистемы Джет»:

Комментарий

 

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

 

Если говорить о подходе ShiftLeft (привлечение на как можно более ранних стадиях), он не является ноу-хау, это уже отработанный метод, доказавший свою эффективность. Его стоит применить и к безопасности, так как часто она незаслуженно сдвигается в самый конец цикла, что способствует «удорожанию» исправления кода при наличии уязвимостей.

 

На сегодняшний день безопасность в большинстве случаев стоит в стороне и выполняет согласующую функцию, что нельзя назвать полноценным участием в разработке. Отсюда и множество проблем с безопасностью выпускаемого кода. Чтобы изменить ситуацию, необходимо вовлекать безопасность в весь цикл разработки, и в первую очередь — к DevSecOps (для чего точно потребуется менеджмент с «политической» волей).

Александр Садыков

руководитель блока Development по направлению DevSecOps компании «Инфосистемы Джет»:

Комментарий

 

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

Я хочу закончить статью высказыванием Альберта Эйнштейна: «We cannot solve our problems with the same thinking we used when we created them». Иначе говоря, для того чтобы три наших богатыря двигались в одном направлении, нужен принципиально иной подход. Начинать изменения я предлагаю с себя.

Уведомления об обновлении тем – в вашей почте

Организованная киберпреступность, кадровый голод и другие ИБ-вопросы. Опыт Росбанка

Каковы основные ИБ-тренды в банковской индустрии? В чем состоит основная сложность использования DevSecOps-подхода? Что разумно отдавать на ИБ-аутсорсинг?

Играли в детстве в сыщиков? SecDevOps во многом то же самое

Отношения между безопасностью и бизнесом директор по безопасности «Яндекс.Такси» Артем Гутник описывает как погоню черепахи за зайцем. Причем с помощью цифровизации и технологий черепаха может не только догнать, но и обогнать зайца. Особенно ярко эта философия проявляется в SecDevOps — операционной модели, в которой безопасность обеспечивается на каждом этапе разработки приложений. Мы поговорили с Артемом о том, почему целесообразно использовать именно термин SecDevOps, каким компаниям стоит применять этот подход и как обеспечить себя компетентными специалистами.

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня