Я люблю смотреть разные спортивные игры. Можно сказать, я просто рожден для этого занятия. А вот играть в них — не мое призвание. И однажды мне стало интересно, чем мир спорта схож с миром программного обеспечения, а точнее — с моделью DevOps. В какой-то момент меня осенило, что если и есть что-то, совсем не похожее на спорт, то это модель DevSecOps. Попробуем разобраться на примерах.
С самого начала сохранение безопасности процессов DevOps было общей обязанностью, и в результате возникло такое понятие, как DevSecOps. DevSecOps — это полностью интегрированная система, а не просто безопасность «вокруг» приложений и данных. Если безопасность перенесена в конец конвейера разработки, то организации, внедряющие DevOps, могут оказаться в ситуации, когда придется вернуться к долгим циклам разработки, которых они пытались избежать. DevSecOps означает, что нужно думать о безопасности приложений и безопасной инфраструктуре с самого начала работы. Также подразумевается необходимость автоматизации некоторых доступов для того, чтобы поддерживать рабочий процесс, а не тормозить его. Однако DevSecOps — это больше, чем подобранные инструменты. Это система, построенная на культурных изменениях DevOps для внедрения в работу security-команд, и чем раньше такое произойдет, тем лучше.
1. Нельзя во всем винить вратаря
Я начну с сугубо личного, но, надеюсь, хорошо понятного примера: когда в детстве мы играли в футбол, меня, как наименее ценного игрока, обычно ставили на ворота. И всякий раз, когда мяч со всей дури влетал в ворота (или неторопливо закатывался в них мимо меня), все, конечно же, винили вратаря. Должен сказать, что такой подход не только ужасно влияет на командный дух, но и является полной противоположностью тому, как необходимо работать в команде.
С другой стороны, лично меня напрягают фразы типа: «Безопасность в DevSecOps — это ответственность каждого». Далеко не каждый является экспертом по безопасности, хотя все участники команды обязаны понимать, что такое правильно организованные процессы, и нести определенную ответственность за их выполнение. И если что-то идет не так, не следует возлагать всю вину только на одного человека. И не забывайте о том, что в DevSecOps у вас есть все возможности, создав соответствующие тесты, оперативно устранить проблему и избежать ее дальнейшего появления.
2. Вы не знаете, кто ваш противник
В спорте всегда известен соперник. Вы знаете, кто он, где он, и можете оценить его действия в различных игровых ситуациях. Вы не всегда можете его остановить, зато точно понимаете, какие цели он преследует. В обычных ИТ-проектах это далеко не так, а в модели DevSecOps всё вообще не так, поскольку есть вы — те, кто занимается разработкой, тестированием и эксплуатацией различных уровней стека приложений, и есть противники, сильно различающиеся в плане ресурсов и профессионализма. И ключевая фраза здесь — «есть вы». И если «вы» — действительно команда, то совокупные знания ваших специалистов можно применять для реализации более амбициозных решений, которые практически невозможно выполнить в рамках стандартной модели «проектирование —разработка — тестирование — развертывание».
3. В отличие от спорта, здесь нет правил
Да, такой вот жесткач. В спорте противник играет по тем же правилам, что и вы, иначе он получит предупреждение от арбитра, рефери или другого спортивного судьи. Было бы здорово, если бы тех, кто атакует ИТ-инфраструктуры и приложения, всегда ловили и наказывали, но, к сожалению, нет никаких предпосылок для ожидания такого счастья в ближайшем будущем. Поскольку у вас вряд ли будет возможность отслеживать в реальном времени действия противника и активно контратаковать, вам надо продумать, какие исправления можно задействовать, как их применять и насколько быстро их можно запустить. Важно отметить, что эту задачу не надо сваливать только на тех членов вашей команды, которые отвечают за безопасность. Хотя эксперты по безопасности могут неплохо спрогнозировать возможные атаки, именно основной инженерный и операционный персонал лучше всего сможет оценить, как скажутся последствия атак на работе системы, поэтому эти люди и должны разрабатывать соответствующие меры по смягчению последствий при возникновении проблем.
4. В игре участвуют все и всё время
Во всех командных видах спорта во время игры на поле находятся далеко не все участники команды. А вот в DevSecOps можно задействовать абсолютно всех. Тренер не обязан наблюдать за игрой со стороны и может привлекать вспомогательный персонал (а точнее говоря — экспертов по производительности и разного рода технических специалистов) в моменты, когда возникает такая потребность. По мере роста количества итераций каждый участник команды довольно быстро сможет внести свой вклад, поскольку изменения будут возникать как на уровне приложения, так и в среде развертывания на уровне безопасности. Кроме того, командам DevSecOps не стоит изолироваться от других сотрудников и подразделений организации: если вам нужно привлечь кого-то из них на денек-другой, не стесняйтесь это делать. Не бойтесь действовать быстро и признаваться в том, что вам нужна помощь.
5. В проигрыше нет ничего страшного
В спорте принято думать о том, как одержать победу, невзирая на условия и силу соперника. Но и поражение является необходимым инструментом. Лучшие спортсмены и команды знают, как его использовать, чтобы в следующий раз выступить, выполнив «работу над ошибками». В DevSecOps надо поощрять команду и не бояться проигрывать, поскольку только опыт поражений позволит сделать приложения и проекты лучше. Уже никто не верит, что можно создать абсолютно неуязвимые приложения и системы. Главный вопрос не в том, смогут ли вас взломать, а в том, когда это произойдет и где. Поэтому стройте свои процессы, отслеживая подозрительную активность, и будьте готовы минимизировать последствия атак. Первым делом стоит убедиться в том, что ваши процессы позволяют учиться на ошибках и помогают повысить эффективность, надежность и устойчивость вашего проекта и команды на следующей итерации.
Подводя итоги
Я не утверждаю, что между DevSecOps и спортом нет ничего общего. Сходство есть, и достаточно большое. Вот наиболее очевидные общие черты: серьезные изменения требуют серьезного распределения ответственности как сверху вниз, так и снизу вверх; в команде важны эффективные коммуникации друг с другом и слаженная реакция на угрозы в реальном времени. Я не настаиваю на том, что различия — это главное. Но иногда лучше сравнивать отличия, а не сходные черты. Это, как говорится, открывает глаза.
Автор — Майк Берселл, главный архитектор по безопасности Red Hat