Введение
Сегодня часто говорят о «разрыве между безопасностью и разработкой» или о «разрыве в безопасности DevOps». В этом есть смысл. Действительно, есть необходимость отделить безопасность от процессов разработки и DevOps.
Однако на удивление меньше внимания уделяется разрыву между разработкой надежности и безопасностью. При всем том, что мы говорим о DevSecOps, мы почти не обращаем внимания на важность более централизованной интеграции безопасности в работу по управлению инцидентами, выполняемую SRE.
Объясним, почему это является проблемой и что могут сделать SRE, чтобы решить ее.
Приоритеты SRE в сравнении с приоритетами безопасности
Когда вы являетесь техническим специалистом, устраняющим проблемы с надежностью, безопасность, вероятно, не является вашим главным приоритетом. Восстановление процесса обслуживания пользователей как можно быстрее — вот ваш главный приоритет. На втором плане у вас, наверняка, стоит обеспечение того, чтобы данный инцидент не повторился.
Если вы и будете думать о безопасности, то, скорее всего, только после того, как инцидент будет окончательно устранен. Возможно, вопросы безопасности всплывут во время анализа инцидента, если вы не забудете его провести.
Эта тенденция ставит SRE в противоречие с интересами инженеров по безопасности, чье основное внимание сосредоточено на безопасности, а не на надежности. Если вы инженер по безопасности, то хотите быть уверены, что любое исправление, которое SRE применяют во время урегулирования инцидентов, является наиболее безопасным решением. Будет ли это самое быстрое и надежное исправление — это не ваша проблема (это проблема SRE).
Разрыв между надежностью и безопасностью
Тот факт, что у инженеров по надежности и безопасности разные цели, создает проблему, поскольку во многих организациях эти две группы обычно не очень тесно взаимодействуют друг с другом. SRE могут хорошо взаимодействовать с разработчиками и ИТ-инженерами, но не с командой безопасности.
В результате может возникнуть реальная проблема с обеспечением того, чтобы в процессе управления инцидентами были учтены приоритеты как для SRE, так и для команд безопасности. Когда эти две группы не взаимодействуют друг с другом, в итоге получается, что SRE внедряют меры по исправлению ситуации, которые могут усугубить проблемы безопасности, а инженеры по безопасности вносят изменения, которые могут снизить надежность.
Например, представьте себе SRE, которому необходимо исправить приложение, вышедшее из строя. Чтобы восстановить работу, технический специалист откатывается на более ранний релиз, который, как известно, является более стабильным. Но поскольку технический специалист не общался с командой безопасности, он не подозревает, что предыдущий релиз содержит уязвимость в системе безопасности. В результате откат приводит к повторному появлению проблемы безопасности в среде эксплуатации.
Позже команда безопасности, которая не знала о сбое приложения, потому что не общалась с SRE, начинает ругать ИТ-отдел за то, что в производстве используется небезопасный релиз. Поэтому более новый, нестабильный релиз, который был отменен, развертывается заново. Это устраняет проблему безопасности, но вновь создает проблему надежности.
Если вы стремитесь создать безопасную и надежную систему поставки программного обеспечения, это не то, что нужно.
Соответствие нормативным требованиям, безопасность и управление инцидентами
Помимо проблем, связанных с надежностью и эффективностью, разобщенность между SRE и инженерами по безопасности может также иметь последствия для соответствия нормативным требованиям.
Среди основных требований SOC 2, общего стандарта соответствия для компаний, предоставляющих SaaS-приложения и облачные услуги, — это наличие процедур для выявления и реагирования на проблемы безопасности во время реагирования на инциденты.
То есть, если не интегрировать вопросы безопасности в процесс реагирования на инциденты, будет сложнее продемонстрировать аудиторам и клиентам, что ваша команда SRE готова справиться с инцидентами таким образом, чтобы безопасность и надежность были приоритетны в равной степени.
Если вы не уверены в том, как сохранить соответствие требованиям, компании по его автоматизации, такие как Secureframe, могут помочь вам создать правила, включающие план реагирования на инциденты безопасности, а также обеспечить создание надлежащих линий связи для получения информации и отчетов об инцидентах или системных сбоях.
DevSecOps для SRE?
Как устранить этот разрыв между безопасностью и надежностью? Обращение к критериям SOC 2 - это отправная точка. Но более широкий ответ заключается в том, чтобы расширить рамки DevSecOps, включив в него разработку надежности и управление инцидентами.
Традиционно DevSecOps фокусируется на идее, что инженеры по безопасности, разработчики и ИТ-инженеры должны работать в тесном сотрудничестве. SRE не были частью DevSecOps, по крайней мере, напрямую. В лучшем случае, они были подключены косвенно, взаимодействуя с разработчиками и ИТ.
Однако если вы сделаете управление инцидентами частью процесса поставки программного обеспечения, а также внедрите DevSecOps, вам будет гораздо проще обеспечить, чтобы SRE и инженеры по безопасности работали сообща для достижения поставленных целей, а не в ущерб друг другу.
Внедрение DevSecOps для SRE включает в себя несколько основных процедур:
Заключение: Инженерия безопасной надежности
За последнее десятилетие ИТ-организации разрушили многие внутренние барьеры, но не те, которые отделяют SRE от инженеров по безопасности. Сейчас самое время устранить этот разрыв, предоставив SRE инструменты для общения и сотрудничества, необходимые для эффективной работы с командами безопасности.
habr.com
Сегодня часто говорят о «разрыве между безопасностью и разработкой» или о «разрыве в безопасности DevOps». В этом есть смысл. Действительно, есть необходимость отделить безопасность от процессов разработки и DevOps.
Однако на удивление меньше внимания уделяется разрыву между разработкой надежности и безопасностью. При всем том, что мы говорим о DevSecOps, мы почти не обращаем внимания на важность более централизованной интеграции безопасности в работу по управлению инцидентами, выполняемую SRE.
Объясним, почему это является проблемой и что могут сделать SRE, чтобы решить ее.
Приоритеты SRE в сравнении с приоритетами безопасности
Когда вы являетесь техническим специалистом, устраняющим проблемы с надежностью, безопасность, вероятно, не является вашим главным приоритетом. Восстановление процесса обслуживания пользователей как можно быстрее — вот ваш главный приоритет. На втором плане у вас, наверняка, стоит обеспечение того, чтобы данный инцидент не повторился.
Если вы и будете думать о безопасности, то, скорее всего, только после того, как инцидент будет окончательно устранен. Возможно, вопросы безопасности всплывут во время анализа инцидента, если вы не забудете его провести.
Эта тенденция ставит SRE в противоречие с интересами инженеров по безопасности, чье основное внимание сосредоточено на безопасности, а не на надежности. Если вы инженер по безопасности, то хотите быть уверены, что любое исправление, которое SRE применяют во время урегулирования инцидентов, является наиболее безопасным решением. Будет ли это самое быстрое и надежное исправление — это не ваша проблема (это проблема SRE).
Разрыв между надежностью и безопасностью
Тот факт, что у инженеров по надежности и безопасности разные цели, создает проблему, поскольку во многих организациях эти две группы обычно не очень тесно взаимодействуют друг с другом. SRE могут хорошо взаимодействовать с разработчиками и ИТ-инженерами, но не с командой безопасности.
В результате может возникнуть реальная проблема с обеспечением того, чтобы в процессе управления инцидентами были учтены приоритеты как для SRE, так и для команд безопасности. Когда эти две группы не взаимодействуют друг с другом, в итоге получается, что SRE внедряют меры по исправлению ситуации, которые могут усугубить проблемы безопасности, а инженеры по безопасности вносят изменения, которые могут снизить надежность.
Например, представьте себе SRE, которому необходимо исправить приложение, вышедшее из строя. Чтобы восстановить работу, технический специалист откатывается на более ранний релиз, который, как известно, является более стабильным. Но поскольку технический специалист не общался с командой безопасности, он не подозревает, что предыдущий релиз содержит уязвимость в системе безопасности. В результате откат приводит к повторному появлению проблемы безопасности в среде эксплуатации.
Позже команда безопасности, которая не знала о сбое приложения, потому что не общалась с SRE, начинает ругать ИТ-отдел за то, что в производстве используется небезопасный релиз. Поэтому более новый, нестабильный релиз, который был отменен, развертывается заново. Это устраняет проблему безопасности, но вновь создает проблему надежности.
Если вы стремитесь создать безопасную и надежную систему поставки программного обеспечения, это не то, что нужно.
Соответствие нормативным требованиям, безопасность и управление инцидентами
Помимо проблем, связанных с надежностью и эффективностью, разобщенность между SRE и инженерами по безопасности может также иметь последствия для соответствия нормативным требованиям.
Среди основных требований SOC 2, общего стандарта соответствия для компаний, предоставляющих SaaS-приложения и облачные услуги, — это наличие процедур для выявления и реагирования на проблемы безопасности во время реагирования на инциденты.
То есть, если не интегрировать вопросы безопасности в процесс реагирования на инциденты, будет сложнее продемонстрировать аудиторам и клиентам, что ваша команда SRE готова справиться с инцидентами таким образом, чтобы безопасность и надежность были приоритетны в равной степени.
Если вы не уверены в том, как сохранить соответствие требованиям, компании по его автоматизации, такие как Secureframe, могут помочь вам создать правила, включающие план реагирования на инциденты безопасности, а также обеспечить создание надлежащих линий связи для получения информации и отчетов об инцидентах или системных сбоях.
DevSecOps для SRE?
Как устранить этот разрыв между безопасностью и надежностью? Обращение к критериям SOC 2 - это отправная точка. Но более широкий ответ заключается в том, чтобы расширить рамки DevSecOps, включив в него разработку надежности и управление инцидентами.
Традиционно DevSecOps фокусируется на идее, что инженеры по безопасности, разработчики и ИТ-инженеры должны работать в тесном сотрудничестве. SRE не были частью DevSecOps, по крайней мере, напрямую. В лучшем случае, они были подключены косвенно, взаимодействуя с разработчиками и ИТ.
Однако если вы сделаете управление инцидентами частью процесса поставки программного обеспечения, а также внедрите DevSecOps, вам будет гораздо проще обеспечить, чтобы SRE и инженеры по безопасности работали сообща для достижения поставленных целей, а не в ущерб друг другу.
Внедрение DevSecOps для SRE включает в себя несколько основных процедур:
- Коммуникация: SRE и команды безопасности нуждаются в средствах коммуникации, которые позволят им сотрудничать друг с другом и получать постоянную информацию о состоянии своих проектов. Служба безопасности должна автоматически получать уведомления, когда SRE делает что-то, например, откатывает релиз, а SRE должна знать, когда служба безопасности отмечает релиз как небезопасный.
- Общий инструментарий: Возможность использования общего инструментария также может помочь SRE и командам безопасности в совместной работе. SRE склонны определять все как код. Команды, которые принимают концепцию безопасности в виде кода, могут использовать аналогичный подход, что повышает их способность работать с теми же инструментами и процессами, что и SRE.
- Плейбуки: Плейбуки, которые SRE используют для упрощения управления инцидентами, должны иметь встроенную защиту. Инженеры по безопасности должны участвовать в разработке создаваемых вручную плейбуков, а также в создании определяющих их правил, которые автоматически генерируются программным обеспечением для управления инцидентами.
Заключение: Инженерия безопасной надежности
За последнее десятилетие ИТ-организации разрушили многие внутренние барьеры, но не те, которые отделяют SRE от инженеров по безопасности. Сейчас самое время устранить этот разрыв, предоставив SRE инструменты для общения и сотрудничества, необходимые для эффективной работы с командами безопасности.
При создании DevSecOps не забывайте о SRE
Введение Сегодня часто говорят о « разрыве между безопасностью и разработкой » или о « разрыве в безопасности DevOps ». В этом есть смысл. Действительно, есть необходимость отделить безопасность от...
habr.com