Инцидент в сервисе непрерывной интеграции Travis CI

Как сообщает opennet.ru разработчики сервиса непрерывной интеграции Travis CI раскрыли сведения об инциденте с повреждением инфраструктуры проекта 13 марта, в результате которого случайно была инициирована операция удаления всех таблиц из СУБД. В течение 30 минут после удаления сервис оставался доступен с поврежденными данными, после чего был отключен на пять с половиной часов для проведения восстановления.

После восстановления всплыл неожиданный эффект - пользователи которые подключились к сервису за те 30 минут, что база оставалась повреждена, оказались подключенными под совсем другими аккаунтами. Подобный эффект объясняется тем, что для пользователей, которые вошли при пустой БД, были созданы новые записи и первичные ключи (данные в Travis CI синхронизируются с GitHub).

После восстановления новые токены аутентификации не были очищены и стали указывать на совсем другие записи (в PosgreSQL идентификатор последовательности (sequences) не был сброшен и созданные при пустой базе записи стали указывать на новые записи, созданные после восстановления). После того как проблема была замечена, разработчики Travis CI примерно через сутки после очистки БД удалили проблемные токены. По логу всего один пользователь успел подключиться к чужим данным. Тем не менее, всем пользователям, для которых было обнаружено пересечение, было направлено уведомление с предложением сгенерировать новые токены доступа.

Что касается причины удаления всех данных, то она кроется в давно забытом сеансе tmux на одной из рабочих машин проекта - когда-то давно один из разработчиков выполнял в данном сеансе инспектирование основной базы и оставил выставленной переменную окружения DATABASE_URL, указывающую на первичную БД. Много дней спустя разработчик в том же сеансе запустил локальный тест, в котором вызывался скрипт Database Cleaner, производящий очистку всех таблиц пред генерацией тестовой нагрузки. Так как переменная окружения DATABASE_URL указывала на основную СУБД, то и очистка была запущена в контексте первичной БД.

Для того чтобы подобное не повторилось в будущем в БД было отозвано право очистки таблиц. Во внутренние скрипты добавлен обработчик (spec_helpers), проверяющий наличие переменной окружения DATABASE_URL, а в утилитах обеспечен вывод соответствующего предупреждения. В gem-пакет Database Cleaner добавлена проверка на наличие переменной DATABASE_URL.