Поздним вечером 22 июля 2021 г. десятки популярных сайтов по всему миру отключились. Сбой возник в результате обновления DNS-сервиса Edge DNS, которое проводила Akamai. Месяцем ранее сравнимое по масштабам отключение по причине «неизвестной ошибки» допустил CDN-провайдер Fastly. Старший директор Forcepoint
Как показали недавние события, чтобы отключить огромный сектор Интернета, достаточно одного человека, непреднамеренно изменившего настройки, а это значит, что пришло время решать проблему технического долга. Сбои в работе Fastly и Akamai, в результате которых игровые онлайн-платформы, правительственные и новостные сайты не работали более часа, привлекли внимание к проблемам, связанным с управлением инфраструктурой и ПО Интернета.
Концепция технического долга существует уже давно, и сбои в работе Fastly и Akamai — наглядный пример гораздо более серьезной проблемы. Термин «технический долг» — это разница между «ценой», которая включает время, человеческие ресурсы или инвестиции в технологии, и которую нужно заплатить за качественную работу технического проекта в будущем, и реальной «ценой», которую организация готова заплатить за его выполнение в текущий момент времени.
Поскольку мы живем не в идеальном мире, каждый проект по самым разным причинам будет периодически накапливать небольшой объем технического долга. В конце концов, он достигнет определенного уровня, когда его необходимо будет устранить. Если этого не сделать, то в продукте появятся изъяны, его нельзя будет модернизировать или он полностью перестанет функционировать так, как было задумано. Со временем накопленный технический долг может привести к крупномасштабному инциденту, как злонамеренному, так и случайному.
Существуют три основные области, где накапливается технический долг. ИТ- и ИБ-руководители должны отслеживать и учитывать их в текущей оценке рисков.
1. Перенаправленные инвестиции
С течением временем все компании меняют свои приоритеты. Они могут перенаправить бюджеты и ресурсы на новые проекты и технологии, в то время как старые продукты остаются частью общего предложения, или же их могут оставить на произвол судьбы с меньшей поддержкой, чем раньше. Если для продукта не установлены четкие планы по завершению срока службы или поддержки, существует реальный риск появления серьезных уязвимостей по причине того, что код продукта устарел и его нельзя обновить для работы с последними версиями ОС или другим совместимым ПО.
Кодовая база продукта замораживается, как только прекращаются инвестиции в него, и это может вызвать проблемы с текущим обслуживанием и управлением, а также увеличить подверженность уязвимостям и неправильной конфигурации.
Инвестиционные решения влияют не только на унаследованные продукты, которые постепенно устаревают, это происходит и с продуктами, которые еще даже не были полностью выпущены. Идеальный сценарий разработки может потребовать значительных времени и инвестиций, но жизнеспособный продукт может быть создан в более короткие сроки. Приоритеты бизнеса могут взять верх, и возникает давление, требующее довести продукт до жизнеспособного состояния, даже если конечный результат не идеален.
Найти подходящий баланс между совершенством, соответствующей функциональностью и минимальной жизнеспособностью довольно сложно, и заказчики или даже команды разработчиков внутри компании могут столкнуться с тем, что после завершения проекта у них уже не будет возможности доработать его из-за изменения приоритетов бизнеса. В этом контексте техническим долгом можно управлять путем постановки четких целей и тесного сотрудничества с командами разработчиков для постоянного управления ожиданиями.
2. Физические технологии
Вторая область, в которой может накапливаться технический долг, связана с физическими технологиями. Нередки случаи, когда в дата-центры инвестируют, открывают их, а затем оставляют без дальнейшего управления на срок до четырех лет. Работа с сочетанием устаревших и новых услуг в цепочке поставок ИТ может поставить компанию в уязвимое положение.
Такие отрасли, как финансовые услуги и здравоохранение, полагаются на множество источников данных, микросервисов и других систем, работающих бок о бок. К отключению критически важных сервисов могут привести именно проблемы с интеграцией.
Критически важная инфраструктура часто строится на основе операционных технологий, которые являются проприетарными по своей природе, что усложняет связь с современными цифровыми сервисами. Если также учесть длительный характер цепочек поставок ПО, на которые опираются предприятия, правительства и критически важные объекты инфраструктуры, то нетрудно понять, что в будущем большое количество устаревших и неподдерживаемых технологий может нанести серьезный ущерб.
3. Люди
Еще один большой и, возможно, самый важный источник технического долга — это люди. ПО — это итеративный продукт, и большая его часть разрабатывается десятилетиями, командами работников со значительным опытом и институциональными знаниями. Эти команды также отвечают за поддержку и управление унаследованными технологиями и платформами. Но поскольку бизнес-приоритеты со временем меняются, системы, построенные на устаревшем коде, могут быть упущены из виду. Со временем внимание команд разработчиков ПО — либо по собственному желанию, либо вынужденно — переключается на другие задачи, что при неправильном управлении может вызвать неудовольствие сотрудников. Когда доступом к старому коду и знаниями о нем обладают лишь несколько человек, это создает потенциальный риск инсайдерской угрозы, что особенно важно, если ПО используется для управления критически важной ИТ-инфраструктурой.
В связи с этим ИТ-руководители должны учитывать планирование преемственности в любых стратегических обсуждениях. Все работники в конечном итоге уходят или выходят на пенсию, и если знаниями не обмениваются, возникает риск, что новые сотрудники не смогут поддерживать старые системы. Реализация базовых требований, таких как установка обновлений и исправлений или управление конфигурациями, всегда актуальна даже для старых систем.
Компаниям необходимо установить четкие процедуры завершения срока службы продукта, это касается и новых продуктов. Помимо этого нужно разработать планы на случай непредвиденных обстоятельств, например, предусмотреть ответные меры на организационные изменения, чтобы устранить потенциальное воздействие на имеющееся программное и аппаратное обеспечение.
Когда речь идет о будущих инвестициях, нельзя полностью оставлять унаследованные технологии без внимания, равно как и запускать новое ПО только с учетом масштабируемости — необходимо составить план изменений с картой будущих обновлений и жизненными циклами.
Ничто не вечно, и ПО не является исключением. Как уже говорилось, с течением времени технический долг накапливается, и если его не устранить, могут образоваться огромные «слепые пятна», которые делают организации уязвимыми и ведут к сбоям.
