Salesforce сделала хранение OAuth-токенов Heroku проверкой подотчётности платформ разработчиков

Резюме

• Инцидент Heroku 2022 года с интеграцией GitHub важен, потому что OAuth-токены — не обычные пароли; это делегированные полномочия, которые могут связывать исходные репозитории, конвейеры развёртывания, сборочные системы, клиентские приложения и конечных пользователей программного обеспечения.
• GitHub публично предупредил, что злоумышленник использовал украденные OAuth-токены пользователей, выданные Heroku и Travis CI, при этом сообщения Heroku об инциденте требовали от клиентов следовать меняющимся инструкциям по мере развития расследования, отзыва токенов и сброса учётных данных.
• Вопрос подотчётности не только в том, ротировала ли Heroku в итоге ключи или восстановила интеграции. Он в том, кто контролировал хранение токенов, уведомление клиентов, поведение приложения GitHub, доказательства доступа к исходному коду, границы доверия в CI/CD и доказательства после инцидента.
• В этой статье источники Heroku, GitHub, Travis CI, Salesforce, IETF, NIST, CISA и MITRE рассматриваются как отдельные линии доказательств; ни один открытый источник не считается полной внутренней записью расследования.
• Долговременный урок в том, что удобство платформ разработчиков должно сопровождаться реестром хранения токенов: какой токен интеграции существует, зачем он существует, какой у него объём прав, где он хранится, кто может его отозвать и какие доказательства получают клиенты, когда токен вызывает подозрения.

Почему этот случай относится к досье рисков и подотчётности

Salesforce сделала контроль за OAuth-токенами Heroku испытанием подотчётности для платформ разработчиков, потому что Heroku — это управляемая платформа разработки, ценность которой основана на доверии на границе между кодом, развёртыванием, идентификацией и операциями. Клиенты используют Heroku для подключения приложений к репозиториям исходного кода, развёртывания кода, автоматизации сборочных процессов, управления командами, запуска дополнений, подключения сервисов данных и эксплуатации производственных нагрузок. Поэтому интеграция Heroku и GitHub — не просто косметическое удобство.

Она может стать мостом из системы исходного кода клиента в платформу развёртывания и обратно — к операционным рискам клиента.

Публичный триггер 2022 года был виден, потому что GitHub опубликовал предупреждение о безопасности наисточник: github.blog, описывающее украденные OAuth-токены пользователей, выданные Heroku и Travis CI. Страница статуса инцидента Heroku наисточник: status.heroku.comи публичный разбор инцидента Heroku за апрель 2022 года наисточник: blog.heroku.comизлагают позицию платформы. Бюллетень безопасности Travis CI наисточник: travis-ci.comдаёт ещё одну линию пострадавшей интеграции. Эти источники устанавливают публичные контуры: OAuth-токены, связанные с рабочими процессами разработчиков, уведомление клиентов, обновления расследования и последовательность защитных мер.

Этот случай важен, потому что OAuth меняет форму подотчётности. Украденный пароль часто можно объяснить через одну учётную запись. Украденный OAuth-токен может представлять собой делегированные полномочия, которые пережили момент, когда пользователь в последний раз думал о согласии. Он может нести доступ к репозиторию, доступ к автоматизированным рабочим процессам, область действия API, доступ к метаданным, последствия для членства в организации или полномочия на развёртывание.

Материалы IETF по OAuth 2.0 наисточник: datatracker.ietf.orgи запись о лучших современных практиках безопасности OAuth наисточник: datatracker.ietf.orgне являются отчётами об инциденте Heroku, но они помогают определить, почему важны выпуск токенов, область действия, хранение, ротация, отзыв, защита от повторного использования и доверие к клиентам.

В досье подотчётности не следует сводить Heroku, Salesforce, GitHub, Travis CI и клиентов к одному действующему лицу. Salesforce владела Heroku как бизнесом и брендом. Heroku контролировала дизайн интеграции платформы, коммуникации с клиентами, обработку учётных данных в своей платформе и доказательства, которые она могла опубликовать. GitHub контролировал собственное расследование, отзыв токенов, доказательства на стороне хостинга исходного кода, контроль над приложениями OAuth и публичное предупреждение для клиентов. Travis CI контролировал свой пострадавший канал интеграции и сообщения для клиентов.

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

Такая карта ролей важна, потому что платформы разработчиков создают разделённую ответственность, не всегда предоставляя общие доказательства. Клиентам Heroku могли сказать ротировать учётные данные или проверить репозитории, но они не могли независимо восстановить все пути хранения токенов на стороне Heroku или действия злоумышленника на стороне GitHub. Пользователи GitHub могли отозвать приложение OAuth, но могли не знать, какой конвейер развёртывания Heroku, приложение или команда требовали замены доступа.

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

Поэтому главный вопрос подотчётности — распределение доказательств: что знал каждый участник, что каждый мог доказать и что должны были делать клиенты, пока сохранялась неопределённость?

Публичный архив также показывает, почему инциденты с инструментами разработчиков относятся к подотчётности в цепочке поставок ПО, а не только к подотчётности безопасности учётных записей. Доступ к исходному коду стоит выше безопасности приложений, секретов, задач CI/CD, артефактов сборки, учётных данных развёртывания и выпусков продуктов. Техника MITRE ATT&CK «application-access-token» наисточник: attack.mitre.orgи техника «alternate-authentication-material» наисточник: attack.mitre.orgдают полезный словарь, потому что они отличают неправомерное использование токенов от обычного подбора паролей.

Материалы CISA по безопасному проектированию наисточник: cisa.govи структура NIST по безопасной разработке ПО наисточник: csrc.nist.govпомогают объяснить, почему хранение исходного кода и доверие к сборочной системе должны рассматриваться как производственные контроли.

Эта статья не претендует на доступ к приватным журналам Heroku, данным аудита приватных репозиториев GitHub, внутренним записям Travis CI, уведомлениям по каждому клиенту, коммуникациям правоохранительных органов или материалам совета директоров Salesforce. Она использует открытые материалы, чтобы спросить, сделали ли доказательства практический контроль видимым.

Сильный отчёт о подотчётности должен показывать не только то, что токены были отозваны, но и когда была обнаружена подозрительная активность, какие области действия были затронуты, каким клиентам требовались действия, какой доступ к репозиториям был подтверждён или исключён, какие секреты могли быть раскрыты, когда были ротированы учётные данные и что изменилось, чтобы тот же путь хранения токенов не мог молча повториться.

Согласие OAuth становится хранением после первого клика

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

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

Текущая документация GitHub по OAuth наисточник: docs.github.comи руководство по поддержке OAuth-приложений наисточник: docs.github.comполезны, поскольку показывают словарь контроля вокруг OAuth-приложений, секретов клиентов, URL обратных вызовов, владения и управления приложениями. Руководство GitHub по журналам аудита предприятия наисточник: docs.github.comпоказывает, почему организациям нужны доказательства активности после подозрительного события интеграции. Документация Heroku по интеграции GitHub наисточник: devcenter.heroku.comпоказывает видимую клиенту поверхность функций. Ни один из этих документов не доказывает, что именно произошло в 2022 году. Они устанавливают операционную поверхность, которую клиенты должны были защищать.

Хранение означает, что платформа должна отвечать на иной набор вопросов, чем обычная доступность. Где хранились OAuth-токены? Были ли задействованы токены обновления или токены доступа? Были ли они зашифрованы, сегментированы или изолированы по арендаторам? Какая служба или база данных могла их читать? Какой мониторинг показал бы необычное использование? Кто мог их отозвать? Какие действия клиента требовались после отзыва? Могла ли Heroku развёртывать из GitHub без повторного согласия клиента? Были ли под угрозой секреты времени сборки, переменные конфигурации, содержимое репозиториев или ключи развёртывания?

Какие из этих ответов были известны при первом уведомлении, а какие ещё расследовались?

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

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

Экономическое измерение реально. Команды разработчиков оптимизируют быструю интеграцию, потому что ручное развёртывание и управление учётными данными дороги. OAuth-приложения снижают трение. Но когда путь хранения на стороне провайдера даёт сбой, цена удобства возвращается в виде аварийного труда: проверка репозиториев, ротация секретов, пересборка интеграций, поиск по журналам, объяснение раскрытия клиентам и ответы аудиторам. Поэтому экономика инструментов разработчика входит в тематику статьи. Платформа, которая выигрывает от лёгкой интеграции, должна инвестировать в хранение, отзыв и доказательства.

Доступ к исходному коду — не то же самое, что компрометация продакшена, но он не безвреден

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

В то же время один лишь доступ к исходному коду не доказывает доступ к среде выполнения, кражу данных или манипуляцию развёртыванием.

Предупреждение GitHub и сообщения Heroku об инциденте важны, потому что они вносят риск доступа к исходному коду в открытые материалы. Клиенту с подключёнными репозиториями нужно было знать, мог ли злоумышленник читать приватные репозитории, были ли секреты закоммичены в репозитории, существовали ли учётные данные развёртывания вне GitHub, раскрывали ли GitHub Actions, конвейеры Heroku, review apps или задачи CI дополнительные материалы, и показывали ли журналы аудита уровня репозитория необычный доступ. Если клиент использовал Travis CI, те же вопросы могли распространяться на переменные окружения CI и журналы сборки.

NIST SP 800-218 наисточник: csrc.nist.govполезен, потому что рассматривает безопасную разработку ПО как жизненный цикл, а не только написание кода. NIST SP 800-204D наисточник: csrc.nist.govпомогает сформулировать вопросы безопасности облачных приложений и идентификации сервисов. NIST SP 800-53 Rev. 5 наисточник: csrc.nist.govдаёт словарь контроля для управления доступом, аудита, конфигурации, реагирования на инциденты и целостности систем. Эти материалы — не выводы, специфичные для Heroku. Это ориентиры для решения, следует ли рассматривать инцидент платформы разработчиков как событие в цепочке поставок ПО.

Ключевая граница — доказательства. Если платформа может определить, что OAuth-токен использовался только для определённого репозитория или набора клиентов, она должна объяснить основу этого определения. Если она не может определить доступ по каждому клиенту из-за ограничений логирования, она должна это сказать. Если GitHub может уведомить затронутых пользователей на основе использования токена или доступа к репозиторию, открытые материалы должны указать, что означает уведомление и что оно не означает. Если клиентам нужно проверять собственные журналы, провайдер должен указать, какие источники журналов важны.

Публичный риск также различается по зрелости клиентов. Крупное предприятие может иметь журналы аудита GitHub Enterprise, централизованное сканирование секретов, анализ состава ПО, сегрегацию CI/CD и персонал для реагирования на инциденты. Меньший клиент Heroku может иметь простое подключение к GitHub, одного-двух сопровождающих и ограниченное хранение журналов. Поэтому одно и то же событие с токеном создаёт разное бремя. Зрелый отчёт о подотчётности не предполагает, что каждый клиент может самостоятельно восполнить пробелы в доказательствах провайдера.

Он даёт малым командам практические шаги, а крупным командам — достаточно технических деталей для автоматизации проверки.

Конечная аудитория шире, чем владельцы учётных записей Heroku. Если доступ к исходному коду выявляет уязвимости или секреты, конечные пользователи ПО клиента могут пострадать позже, даже если первоначальный инцидент платформы не вызвал немедленного простоя. Это не означает, что каждый конечный пользователь пострадал. Это означает, что анализ подотчётности должен проследить путь риска: кража токена, возможный доступ к репозиторию, возможное раскрытие исходного кода или секретов, возможное неправомерное использование CI/CD, возможный доступ к продакшену и возможный вред конечным пользователям.

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

Своевременность уведомлений — часть поверхности контроля

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

Страница инцидента Heroku наисточник: status.heroku.comполезна, потому что обновления статуса показывают последовательность, а не единое итоговое заявление. Предупреждение GitHub даёт ещё одну линию временной шкалы. Бюллетень Travis CI — третью. Внимательный читатель не должен сводить эти временные шкалы в одну идеальную хронологию, если источники этого не подтверждают. Полезный вопрос — как уведомление каждого участника меняло действия клиента. Нужно ли было клиентам отзывать авторизацию приложения? Нужно ли было ротировать API-ключи Heroku? Нужно ли было ротировать пароли пользователей Heroku? Нужно ли было проверять репозитории GitHub? Нужно ли было проверять переменные окружения CI? Нужно ли было пересоздавать хуки развёртывания?

Ответ мог меняться по мере появления фактов. Это приемлемо, когда изменения объясняются. Уведомление может говорить: «мы расследуем возможный доступ и предоставим дополнительные инструкции». Оно может говорить: «мы отозвали токены, и клиенты должны пройти повторную авторизацию». Оно может говорить: «мы требуем сброса пароля, потому что не можем исключить доступ к хешированным учётным данным». Оно может говорить: «мы не нашли доказательств для категории, но клиенты должны проверить собственные журналы на эти индикаторы». Подотчётность ослабляет не неопределённость. Подотчётность ослабляет неопределённость, представленная как завершённость.

Уведомление клиентов также несёт обязанность сегментации. Не каждый клиент Heroku использовал интеграцию с GitHub. Не каждый пользователь GitHub авторизовал Heroku. Не каждый пользователь Travis CI имел ту же область действия. Не каждый репозиторий содержал чувствительные материалы. Полезное уведомление различает затронутые, потенциально затронутые, незатронутые и неизвестные группы. Если точная сегментация невозможна, провайдер должен объяснить почему. Клиенты не должны выводить из широких заголовков, относится ли к ним сообщение.

Качество коммуникации можно измерить. Публиковал ли провайдер постоянные страницы инцидентов? Включали ли сообщения даты и временные метки? Указывали ли затронутые сервисы? Давали ли конкретные действия для клиентов? Обновляли ли прежние инструкции, когда они менялись? Поддерживали ли согласованность между прямыми уведомлениями клиентов и публичными записями? Публиковали ли разбор после инцидента, называвший улучшения контроля без раскрытия эксплуатируемых приватных деталей? Это вопросы подотчётности в той же мере, что и вопросы коммуникации.

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

Принудительная ротация — средство, только если клиенты знают, что изменилось

Принудительная ротация учётных данных может быть необходимой и всё же неполной как восстановление доверия. Клиент может ротировать API-ключ, сбросить пароль или повторно авторизовать OAuth-приложение, но клиенту также нужно понять, что изменилось в модели хранения платформы. Если остаются тот же путь хранения, тот же дизайн областей действия, тот же пробел в мониторинге или тот же пробел в доказательствах для клиента, ротация может восстановить доступ, не восстанавливая доверие. В открытых материалах об инциденте Heroku 2022 года ротация и повторная авторизация были в центре действий клиентов.

Вопрос подотчётности — сопровождались ли эти действия устойчивыми доказательствами контроля.

Страницы Heroku Dev Center, такие какисточник: devcenter.heroku.com,источник: devcenter.heroku.com,источник: devcenter.heroku.comиисточник: devcenter.heroku.com, показывают более широкую среду управления доступом вокруг использования платформы Heroku. Страница Heroku о двухфакторной аутентификации наисточник: devcenter.heroku.comдаёт контекст усиления защиты учётной записи на стороне клиента. Опять же, текущая документация не является доказательством внутреннего состояния 2022 года. Она помогает читателям понять типы учётных данных и действий пользователя, которые могут существовать вокруг учётной записи Heroku.

У ротации три разных уровня. Первый — отзыв скомпрометированных OAuth-токенов, чтобы злоумышленник не мог продолжать использовать делегированную авторизацию. Второй — замена или повторная авторизация на стороне клиента, чтобы легитимные рабочие процессы могли возобновиться с новыми токенами. Третий — проверка смежных учётных данных, включая API-ключи, пароли, ключи развёртывания, переменные CI, секреты репозиториев, персональные токены доступа и облачные учётные данные. Уведомление платформы должно чётко указывать, какой уровень требуется и почему.

Самый сложный уровень — раскрытие секретов в исходном коде. Если злоумышленник мог читать репозитории, ротации только OAuth-токена может быть недостаточно. Клиентам может понадобиться искать секреты, закоммиченные в репозиториях, и ротировать любое раскрытое значение. Документация GitHub по сканированию секретов наисточник: docs.github.comдаёт современный словарь для такой проверки на стороне клиента. Руководство CISA по цепочке поставок ПО наисточник: cisa.govи материалы по безопасному проектированию помогают объяснить, почему секреты в коде могут превратить событие в репозитории в более широкий операционный риск.

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

Платформе также нужны внутренние доказательства завершения. Какие учётные записи клиентов выполнили требуемые шаги? Какие учётные записи остаются в исключительном состоянии? Какие клиенты были недостижимы? Какие интеграции были заброшены? Какие токены не удалось сопоставить с текущим владельцем? Какие контроли были добавлены, чтобы предотвратить молчаливое длительное хранение токенов? Публичный посмертный разбор может не раскрывать имена клиентов, но может раскрыть форму очистки. В этом разница между «мы ротировали» и «рискованного состояния больше не существует».

GitHub, Heroku, Travis CI, Salesforce и клиенты владели разными доказательствами

Карта подотчётности инцидента многосторонняя. GitHub владел доказательствами на стороне хостинга исходного кода, видимостью OAuth-приложений и опубликованным предупреждением безопасности. Heroku владела интеграцией платформы, коммуникацией с клиентами, хранением токенов и программой принудительной ротации учётных данных. Travis CI владел своей пострадавшей линией интеграции CI/CD и инструкциями для клиентов. Salesforce владела управлением Heroku, распределением ресурсов, эскалацией рисков и обязанностью сделать ремонт платформы заслуживающим доверия.

Клиенты владели гигиеной репозиториев, ротацией секретов, организационными одобрениями OAuth и проверкой развёртывания. Ни одна из этих ролей не отменяет другие.

Это важно, потому что вред клиентам может возникнуть из-за разрывов между ролями. Если GitHub знает, что токен использовался, но клиент не знает, какое приложение Heroku ему соответствовало, реакция клиента медленнее. Если Heroku знает, какие учётные записи использовали интеграцию с GitHub, но не может сказать, был ли доступ к содержимому репозиториев, клиентам приходится проверять шире. Если Travis CI и Heroku делят предупреждение GitHub, но дают разные инструкции клиентам, организациям, использующим обе, приходится согласовывать конфликтующие или пересекающиеся действия.

Если Salesforce рассматривает Heroku как дочерний бренд, а клиенты — как производственную платформу, управление должно преодолевать границу бренда.

Документы о разделённой ответственности в облаке и SaaS часто говорят, что обязанности провайдера и клиента различаются. Инцидент Heroku показывает, что разделённая ответственность также требует общих доказательств. Клиент не может ответственно принять заверение провайдера, если провайдер не раскрывает, какую часть цепочки покрывает заверение. Провайдер не может ответственно переложить все действия на клиентов, если у клиентов нет журналов или функций продукта, необходимых для действий. Хостинг исходного кода не может предполагать, что нижестоящие инструменты идеально переведут его предупреждение.

Каждый участник должен сделать свои доказательства полезными следующему участнику цепочки.

Источники IETF, NIST, MITRE, CISA, GitHub, Heroku и Travis CI вместе образуют ограниченный открытый набор материалов. Они не раскрывают каждый приватный факт, но позволяют построить ясную модель подотчётности. OAuth-токены должны иметь узкую область действия, защищаемое хранение, быстрый отзыв, непрерывный мониторинг и привязку к текущим бизнес-целям. Платформы разработчиков должны сообщать об инцидентах достаточно конкретно, чтобы клиенты могли действовать. Клиенты должны периодически проверять интеграции, а не считать авторизацию постоянной.

Хостинги исходного кода должны предоставлять достаточно данных аудита, чтобы клиенты могли отличить возможное раскрытие от подтверждённого доступа.

Карта ролей также предостерегает от упрощённых обвинений. Если злоумышленник крадёт токен, за неправомерное использование отвечает злоумышленник. Но подотчётность спрашивает, кто мог снизить возможность, радиус поражения и неопределённость. Дизайн хранения токенов может снизить возможность. Минимизация области действия может снизить радиус поражения. Быстрый отзыв может сократить продолжительность. Хорошие журналы могут снизить неопределённость. Ясные инструкции клиентам могут сократить бесполезный труд. Доказательства контроля после инцидента могут снизить повторяемость. Это проектные решения, а не только посмертные заявления.

Доказательства, проверяемые клиентом, — недостающая половина разделённой ответственности

Инцидент Heroku также показывает предел языка разделённой ответственности, когда доказательства асимметричны. Платформа может сказать клиентам, что они отвечают за гигиену репозиториев, ротацию секретов и проверку OAuth-приложений, но клиент всё равно зависит от доказательств провайдера, чтобы решить, где искать. Если провайдер не может сказать, имел ли токен область чтения репозитория, использовался ли он после определённой даты, был ли привязан к конкретному приложению или существуют ли журналы для конкретного клиента, то ответственность клиента превращается в угадывание.

Справедливая модель разделённой ответственности даёт клиентам и обязанности, и пригодные к использованию доказательства.

Доказательства, проверяемые клиентом, начинаются с инвентаризации. Каждый клиент должен видеть, какие приложения Heroku были подключены к каким организациям, репозиториям, пользователям и процессам развёртывания GitHub. Инвентаризация должна показывать текущий статус, последнюю авторизацию, область действия, владельца, требование повторной авторизации и то, отключил ли провайдер подключение. Без такой карты команда безопасности должна реконструировать интеграцию из старых тикетов, вебхуков репозиториев, истории развёртываний и личных учётных записей разработчиков.

Это именно тот аварийный труд, который платформа должна сокращать после события с токеном на стороне провайдера.

Второй слой доказательств — активность. Клиентам нужно знать, какие журналы могут показать доступ к репозиториям, использование авторизации OAuth, использование API-ключей, активность учётной записи Heroku, события развёртывания, события сборки и изменения конфигурации. Если соответствующие доказательства существуют только на GitHub, провайдер должен направить клиентов к записям аудита GitHub. Если соответствующие доказательства существуют только на Heroku, провайдер должен предоставить представление для конкретного клиента или путь поддержки.

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

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

Он также должен избегать намёка на то, что один лишь отзыв токена закрывает риск содержимого репозитория.

Четвёртый слой — гарантия выпуска ПО. Если клиент использует Heroku для автоматического развёртывания из GitHub, клиенту нужно знать, мог ли несанкционированный доступ к репозиторию повлиять на развёрнутый код, артефакты сборки, review apps, конвейеры или историю выпусков. Это не означает, что такое влияние имело место. Это означает, что клиент должен получить достаточно информации, чтобы доказать или опровергнуть это. История выпусков, происхождение сборки, временные метки развёртывания, подписи коммитов, защита веток и журналы CI становятся частью досье подотчётности.

Пятый слой — устойчивая очистка. Клиент должен иметь возможность определить, когда закончилось подозрительное состояние. Были ли отозваны старые OAuth-токены? Были ли интеграции повторно авторизованы с новыми токенами? Были ли завершены ротации паролей или API-ключей? Были ли отключены заброшенные приложения? Были ли удалены осиротевшие персональные авторизации? Предотвратила ли платформа сохранение активности старого класса токенов в каких-либо фоновых задачах или устаревших путях? Заверения провайдера наиболее сильны, когда клиенты могут сверить собственное состояние арендатора с доказательствами завершения провайдера.

Эта модель доказательств для клиента не требует от провайдера публиковать чувствительные приватные журналы в открытом интернете. Она может быть реализована через панели учётных записей, прямые уведомления, экспорт для поддержки, брифинги для предприятий об инцидентах или контрактные пакеты доказательств. Форма может различаться по уровню клиента и чувствительности. Принцип не должен меняться: когда провайдер просит клиентов действовать, он должен также предоставлять доказательства, необходимые клиентам для соразмерных действий.

Закупки и управление должны рассматривать интеграции как постоянный доступ

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

Язык контрактов также должен избегать расплывчатых передач ответственности. Провайдер может требовать от клиентов защиты их репозиториев и учётных данных, но должен указать, как будут обрабатываться инциденты интеграций на стороне провайдера. Уведомит ли провайдер каждого клиента, использующего затронутую интеграцию? Предоставит ли затронутые временные окна? Укажет ли, подтверждён ли доступ к исходному коду, возможен ли он или не наблюдался? Потребует ли повторной авторизации? Раскроет ли события аудита? Предоставит ли сводку после инцидента? Поддержит ли регулируемых клиентов, которым нужны собственные уведомления?

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

Управление внутри Salesforce и Heroku также важно. Общественность не должна предполагать, что дочерний бренд несёт меньше подотчётности из-за ориентации на разработчиков. Приложения Heroku могут быть производственными приложениями, внутренними инструментами, публичными API, прототипами, ставшими критически важными, или серверными системами, обрабатывающими чувствительные рабочие процессы. Структура собственности важна, потому что управление определяет инвестиции в логирование, хранение токенов, реагирование на инциденты, поддержку клиентов и инжиниринг безопасности.

Материнской компании не нужно раскрывать каждое обсуждение совета директоров, чтобы показать, что инцидент платформы разработчиков получил серьёзное внимание к контролю.

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

Если платформа не может объяснить, кто владеет риском хранения токенов в обычной работе, ей будет трудно объяснить, кто владеет им во время кризиса.

Для клиентов практический ответ в управлении — классифицировать интеграции по последствиям. Интеграция для личной продуктивности отличается от интеграции развёртывания, которая может читать производственный исходный код. Приложение с доступом только для чтения к репозиторию отличается от приложения, которое может создавать развёртывания или управлять вебхуками. Пробное приложение Heroku отличается от ориентированного на клиентов производственного приложения. Организации должны назначать более строгую проверку, логирование и повторную сертификацию интеграциям, которые могут влиять на производственный код или секреты.

Инцидент Heroku напоминает, что «подключённое приложение» — это объект управления, а не только функция удобства.

В результате формируется более зрелый стандарт подотчётности. Платформы разработчиков должны публиковать достаточно доказательств об инцидентах, чтобы клиенты могли завершить собственные решения о рисках. Клиенты должны вести достаточную инвентаризацию интеграций, чтобы доказательства провайдера можно было быстро использовать. Хостинги исходного кода должны поддерживать OAuth и контроли аудита пригодными для использования. Вендоры CI/CD должны отделять секреты сборки от широкого доверия к репозиториям. Материнские компании должны относиться к доверию разработчиков как к производственному доверию.

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

Как должен выглядеть устойчивый ремонт после инцидента с хранением OAuth-токенов

Стандарт устойчивого ремонта для инцидента с OAuth на платформе разработчиков включает как минимум восемь частей. Первое: провайдер должен опубликовать чёткую временную шкалу: обнаружение, уведомление GitHub, расследование Heroku, уведомление клиентов, отзыв токенов, ротация учётных данных, доступность повторной авторизации и посмертный разбор. Второе: он должен определить затронутую поверхность интеграции, не подразумевая, что каждый клиент или репозиторий пострадали одинаково. Третье: он должен объяснить разницу между украденными OAuth-токенами, паролями клиентов, API-ключами, ключами развёртывания, секретами репозиториев и переменными CI.

Четвёртое: провайдер должен опубликовать действия клиентов в виде чек-листа, различающего обязательные, рекомендованные и условные шаги. Пятое: он должен указать, какие доказательства видит клиент, а какие — только провайдер или хостинг исходного кода. Шестое: он должен определить, какие контроли изменились: хранение токенов, шифрование, управление секретами, проверка областей действия, мониторинг, обнаружение аномалий, доступ клиентов к аудиту или вывод интеграции из эксплуатации. Седьмое: он должен дать сигнал о завершении, например завершение принудительного сброса, завершение отзыва токенов или принудительную повторную авторизацию.

Восьмое: он должен чётко указать остаточные неизвестные.

Открытые материалы Heroku содержат содержательные доказательства, но урок подотчётности шире одного инцидента. Платформы разработчиков должны проектировать подотчётность для дней подозрительных токенов до того, как они наступят. Это означает инвентаризацию OAuth-приложений, сопоставление владельцев, минимизацию областей действия, отслеживание возраста токенов, автоматизированные процессы отзыва, шаблоны уведомлений клиентов, страницы действий для конкретных клиентов, экспорт журналов аудита и периодическую повторную сертификацию интеграций. Это также означает тестирование клиентского опыта принудительной повторной авторизации до кризиса.

Если клиенты не могут понять путь ремонта в спокойный день, они не поймут его во время инцидента.

Клиентам также нужны устойчивые привычки. Они должны вести инвентаризацию OAuth-приложений, удалять неиспользуемые интеграции, ограничивать одобрение в масштабе организации, требовать проверки приложений с широкими правами, использовать сканирование секретов, избегать коммитов учётных данных, ротировать долгоживущие секреты, сохранять журналы аудита и наносить на карту процессы развёртывания. Документация GitHub и Heroku даёт многие строительные блоки, но работа по управлению принадлежит каждой организации.

Инцидент вендора становится более управляемым, когда клиенты уже знают, какие приложения подключены к каким репозиториям и производственным системам.

Финальный тест подотчётности не в том, может ли платформа сказать, что инцидент закрыт. А в том, можно ли проследить закрытие до доказательств. Были ли аннулированы подозрительные токены? Были ли уведомлены затронутые клиенты? Были ли завершены требуемые сбросы? Были ли даны ответы на вопросы о доступе к исходному коду на уровне, который позволяли доказательства? Были ли проверены секреты и учётные данные развёртывания? Были ли изменены продуктовые контроли? Были ли сохранены остаточные неизвестные? «Да» на эти вопросы сильнее общего заявления об уверенности, потому что оно говорит клиентам, что изменилось.

Поэтому инцидент Heroku 2022 года с OAuth относится к серии Даниэля Кейда о рисках и подотчётности, потому что он делает доверие разработчиков видимым. Инцидент превращает знакомую кнопку интеграции в вопрос о хранении. Он показывает, что платформы исходного кода, платформы развёртывания, вендоры CI/CD и клиенты связаны делегированными полномочиями, которые переживают клик пользователя. Когда эти полномочия украдены, подотчётность следует за токеном: кто его выпустил, кто хранил, кто мог его видеть, кто отозвал, кто предупредил пользователей, кто доказал ремонт и кто заплатил за издержки, пока доказательства ещё были неполными.