Zendesk сделал старые данные поддержки проверкой доверия клиентов и ответственности

Краткое содержание

• Обновлённый FAQ Zendesk сообщает, что в 2019 году компания была уведомлена об инциденте безопасности, затронувшем учётные записи Support и Chat, активированные до ноября 2016 года, и что до этой даты без авторизации был получен доступ к информации об учётных записях клиентов.
• Центральный вопрос подотчётности: кто фактически контролировал хранение данных в базах поддержки, доступ к учётным данным и токенам, сроки уведомления клиентов, сегментацию тенантов, восстановление аудита и доказательства того, что содержимое тикетов было ограничено?
• Ранние публикации описывали пострадавший набор примерно как 10 000 учётных записей Support и Chat; поздний FAQ Zendesk называет около 15 000 учётных записей и сообщает, что для примерно 7 000 клиентских учётных записей был получен доступ к определённой аутентификационной информации.
• Клиентам, использующим Zendesk для поддержки, чатов, справочных центров, интеграций и операций с клиентами, приходилось определять, могут ли старые метаданные поддержки по-прежнему подвергать риску агентов, конечных пользователей, интеграции, сертификаты или доверие нижестоящих клиентов.
• Материалы подтверждают вывод о подотчётности с высокой степенью уверенности в отношении хранения, аутентификации, уведомлений и границ доказательств. Они не позволяют выдумывать частные факты о каждом тенанте, каждом тикете, каждом учётном данном приложения, каждом ключе TLS или каждом решении нижестоящих клиентов.

Доказательственная база и как она используется

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

Рамка подотчётности уже, чем обвинение, и шире, чем старая база данных

Zendesk превратил старые данные поддержки в проверку доверия клиентов, потому что инцидент был не просто историческим уведомлением о взломе. Публичные материалы показывают инцидент безопасности, затронувший учётные записи, активированные до ноября 2016 года: он был обнаружен и о нём сообщили в 2019 году, а в позднейших обновлениях FAQ Zendesk указал персональные данные, хешированные и с солью пароли, отдельные материалы аутентификации, настройки конфигурации приложений и небольшое число элементов TLS-сертификатов. Тот же FAQ сообщает, что Zendesk не нашёл доказательств доступа к данным тикетов в связи с этим инцидентом.

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

Для такого вопроса обвинение — слишком грубый инструмент. Подотчётность спрашивает, у кого были полномочия, доказательства, инструменты и обязанность снижать риск на каждом этапе. Zendesk контролировал базы учётных записей поддержки и чатов, решения о хранении устаревших данных, записи конфигурации приложений, обработку загруженных сертификатов, план ротации паролей, уведомление клиентов и публичный FAQ. Клиенты контролировали собственных агентов, конечных пользователей, установленные приложения, учётные данные интеграций, замену TLS-сертификатов, анализ для регуляторов и локальные правила хранения тикетов.

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

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

Что устанавливают публичные материалы

Обновлённый FAQ Zendesk устанавливает несколько твёрдых пунктов. Компания сообщила, что третья сторона уведомила её об инциденте безопасности, который мог затронуть продукты Support и Chat, а также клиентские учётные записи, активированные до ноября 2016 года. Zendesk заявила, что её команды безопасности и внешние эксперты по криминалистике провели расследование. До ноября 2016 года был получен доступ к информации, принадлежащей небольшому проценту клиентов. Текущий FAQ называет около 15 000 учётных записей Support и Chat, включая истёкшие пробные учётные записи и более неактивные учётные записи, чья информация была получена без авторизации.

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

FAQ добавляет и второй слой. Zendesk сообщила, что для примерно 7 000 клиентских учётных записей, включая истёкшие пробные и неактивные, был получен доступ к определённой аутентификационной информации. В перечень вошли предоставленные клиентами ключи шифрования TLS и настройки конфигурации приложений из маркетплейса или частных приложений, возможно, включая ключи интеграций, которые эти приложения использовали для аутентификации в сторонних сервисах.

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

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

Вторичные публикации фиксируют первую публичную форму инцидента. CyberScoop, SecurityWeek и BleepingComputer сообщили в октябре 2019 года, что Zendesk раскрыла старую утечку, затронувшую примерно 10 000 учётных записей. Расхождение в цифрах — не повод выбрать один источник и отбросить другой. Это повод читать инцидент как поэтапный. Публичное понимание сдвинулось от первоначальной оценки в 10 000 учётных записей к более позднему FAQ с дополнительными деталями об учётных записях и материалах аутентификации.

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

Манифест для этой статьи использует публичные данные о том, что в 2019 году Zendesk сообщила об обнаружении несанкционированного доступа примерно к 10 000 учётных записей Support и Chat в связи с инцидентом 2016 года. Это была ранняя публичная рамка. Текущий FAQ Zendesk говорит примерно о 15 000 учётных записей, а также выделяет около 7 000 клиентских учётных записей, в отношении которых в зону действия попала определённая аутентификационная информация. Важны оба факта. Ранняя цифра показывает, с чем клиентам и журналистам приходилось работать изначально. Обновлённая цифра показывает, что публичные материалы позже стали подробнее и сложнее.

Поэтапно раскрываемые данные об утечках не обязательно подозрительны. Расследования часто меняют цифры по мере проверки журналов, сверки спящих учётных записей, удаления дубликатов и разделения категорий данных. Вопрос подотчётности в том, могут ли клиенты понять разницу. Число учётных записей Support и Chat — не то же самое, что число клиентов с аутентификационными материалами. Пробная учётная запись — не то же самое, что активный корпоративный тенант. Хеш пароля — не то же самое, что OAuth-токен. Ключ TLS — не то же самое, что содержимое тикета.

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

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

Объектом доверия были отношения поддержки

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

Именно поэтому инцидент весил больше, чем старая таблица пользователей. Имена и контактные данные агентов могут помочь нацелиться на сотрудников поддержки. Имена и контактные данные конечных пользователей могут помочь нацелиться на клиентов клиентов Zendesk. Хешированные и с солью пароли создают обязанности по сбросу и опасения по поводу повторного использования. Настройки конфигурации приложений и ключи интеграций могут связывать систему поддержки с другими системами. Материалы TLS-сертификатов могут затрагивать справочные центры под брендом клиента. Каждый элемент касается другой части отношений поддержки.

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

Устаревшее хранение сделало старые учётные записи операционно актуальными

Возраст инцидента — и есть суть. Учётные записи, активированные до ноября 2016 года, оставались актуальны в 2019 году, потому что старые записи могут сохранять операционный смысл. FAQ Zendesk прямо упоминает истёкшие пробные учётные записи и учётные записи, которые больше не были активны. Эти категории важны, потому что клиент может предположить, что неактивные или пробные записи имеют небольшую ценность. На платформе поддержки старые записи всё ещё могут содержать имена пользователей, адреса электронной почты, номера телефонов, хешированные пароли, настройки приложений или материалы сертификатов.

Спящий режим снижает одни риски, но не стирает данные.

Ответственность за хранение — это не только вопрос конфиденциальности. Это вопрос безопасности и рабочей нагрузки клиента. Если старые учётные записи остаются в базе данных, провайдер должен знать, зачем они хранятся, как защищены, когда удаляются или деидентифицируются и что делать клиентам в случае доступа. Словарь статьи 5 GDPR — минимизация данных и ограничение хранения — полезен здесь, потому что он описывает хранение как контрольную обязанность, а не просто как привычку. NIST Cybersecurity Framework добавляет более широкую дисциплину идентификации, защиты, обнаружения, реагирования и восстановления.

Публичные материалы не показывают каждое правило хранения Zendesk в 2016 году или каждое последующее изменение. Zendesk сообщила, что после 2016 года вложилась в улучшения, включая дополнительную защиту чувствительных персональных данных и приведение хранения журналов и данных в соответствие с GDPR. Это заявление полезно, но клиентам всё равно требовались доказательства, привязанные к инциденту: какие старые записи остались, какие были активны, какие неактивны, какие содержали аутентификационные материалы и какие ротация или замена требовались.

Хеши паролей потребовали плана действий для клиентов

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

Если пользователи повторно использовали пароли за пределами Zendesk, скопированный верификатор может создать последующий риск, даже если сам Zendesk не видит связанного доступа.

План ротации паролей Zendesk закрывал именно этот класс рисков. В FAQ сказано, что ротация применялась к определённым агентам и конечным пользователям, созданным до 1 ноября 2016 года, в случаях, когда Zendesk не могла установить, что пользователь сменил пароль после этой даты, и когда пользователь не использовал единый вход. Ротация также затронула продукты, разделяющие аутентификацию с Support, включая Guide, Talk и Explore. Это деталь подотчётности, потому что она говорит клиентам, кому и почему пришлось действовать.

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

Материалы аутентификации сделали дело шире, чем сброс паролей

Самое значимое обновление в FAQ Zendesk — слой аутентификационных материалов. FAQ сообщает, что для примерно 7 000 клиентских учётных записей был получен доступ к определённой аутентификационной информации. В перечень включены предоставленные клиентами ключи шифрования TLS и настройки конфигурации приложений из маркетплейса или частных приложений, возможно, включая ключи интеграций, использовавшиеся этими приложениями для аутентификации в сторонних сервисах. Эти формулировки выводят дело за рамки обычной ротации паролей.

Учётные данные приложений и TLS-материалы создают другую обязанность клиента. Сброс пароля часто выполняется каждым пользователем при следующем входе. Учётные данные приложения могут связывать Zendesk с CRM, биллингом, хранилищем данных, обменом сообщениями, рабочими процессами или системами идентификации. Закрытый ключ TLS может влиять на справочный центр под брендом клиента или сопоставление доменов. Люди, отвечающие за эти обязанности, — не обязательно те же агенты, которые пользуются Zendesk ежедневно. Это могут быть инженеры по безопасности, владельцы приложений, веб-администраторы или команды управления поставщиками.

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

Приложения и интеграции превратили поддержку в связанную систему

Документация Zendesk для разработчиков показывает, почему важна конфигурация приложений. Apps API может управлять приложениями Zendesk и взаимодействовать с ними, и в документации отмечается, что действия этих конечных точек фиксируются в журнале аудита соответствующей учётной записи Support. Документация по запросам приложений объясняет, что приложения могут выполнять вызовы REST API и другие HTTP-запросы, а также обрабатывать OAuth-токены доступа для сторонних сервисов. Документация по безопасности API называет API-токены и OAuth-токены способами авторизации запросов.

Документация по OAuth-токенам даёт администраторам способ просматривать свойства токенов.

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

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

Материалы TLS-сертификатов создали отдельное бремя доказывания

Материалы TLS-сертификатов — не обычные данные учётной записи. Если клиент загрузил сертификат и закрытый ключ для поддержки справочного центра под своим брендом, доступ к этим материалам мог затронуть способность клиента доказывать контроль над доменом или защищать зашифрованный трафик. FAQ Zendesk сообщает, что выявлена небольшая группа клиентов, чьи TLS-сертификаты были затронуты доступом, причём почти все они уже истекли на момент публикации FAQ. Компания рекомендовала клиентам с всё ещё действующими загруженными сертификатами от 1 ноября 2016 года загрузить новый сертификат и отозвать старый.

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

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

Содержимое тикетов было границей, которая нужна клиентам больше всего

В FAQ Zendesk сказано, что компания не нашла доказательств доступа к данным тикетов в связи с инцидентом. Там также сказано, что если Zendesk устанавливала, что сервисные данные клиента, включая персональные данные, были скомпрометированы, компания отдельно сообщала об этом клиенту. Для клиентов Zendesk эта граница была центральной. Содержимое тикетов может включать жалобы, историю учётной записи, проблемы с продуктами, вложения, детали устранения неполадок, сообщения о мошенничестве, сведения о здоровье, студенческие записи, вопросы по персоналу, проблемы с оплатой или идентификационную информацию — в зависимости от клиента.

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

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

Роли контролёра и обработчика изменили нагрузку по уведомлениям

FAQ Zendesk прямо описывает клиентов как контролёров данных в отношении сервисных данных, а Zendesk — как обработчика данных при оказании сервиса. Это различие важно, потому что объясняет, почему клиенты не могли просто ждать, пока Zendesk примет все регуляторные решения. Согласно статье 33 GDPR, у контролёра могут возникнуть обязанности по уведомлению надзорного органа, если утечка персональных данных достигает юридического порога. FAQ Zendesk сообщал клиентам, что компания предоставит имеющуюся у неё информацию, чтобы помочь им принять это решение.

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

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

Сегментация тенантов была невидимым слоем гарантий

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

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

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

Восстановление аудита было частью восстановления, а не фоновой работой

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

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

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

Текущие документы о доверии — полезный контекст, а не ретроактивное доказательство

Центр доверия Zendesk описывает текущие практики безопасности, соответствия, шифрования, центров обработки данных и гарантий. Соглашение об обработке данных описывает нынешнюю юридическую рамку для сервисных данных и мер защиты. Документация разработчика описывает нынешнюю аутентификацию API, управление приложениями, видимость OAuth-токенов и паттерны запросов приложений. Эти документы полезны, потому что показывают словарь контроля, который клиенты используют при оценке Zendesk сегодня.

Их не следует читать как ретроактивное доказательство каждого элемента контроля 2016 года. Текущий Центр доверия не доказывает, какие записи существовали в устаревших базах данных. Текущая страница об API-токенах не доказывает, какие токены или настройки были в 2016 году. Текущая страница помощи по сертификатам не доказывает каждую деталь обработки загруженных клиентом ключей в период инцидента. Правильное использование уже и дисциплинированнее: текущие документы определяют типы контролей и обязанностей клиентов, которые делают инцидент 2016/2019 годов значимым.

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

Чего публичные материалы не доказывают

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

Они не показывают каждый последующий контроль безопасности или каждое взаимодействие с регуляторами.

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

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

Более сильные публичные материалы разделяли бы каждую затронутую поверхность

Более сильные публичные материалы свели бы основные поверхности в единую карту действий. Они отделяли бы информацию об учётных записях Support и Chat от аутентификационных материалов. Они отделяли бы активных клиентов от истёкших пробных и неактивных учётных записей. Они отделяли бы хешированные пароли от учётных данных приложений и ключей TLS. Они отделяли бы ротацию паролей пользователей от ротации учётных данных приложений и замены сертификатов. Они отделяли бы данные тикетов от метаданных учётных записей и объясняли бы основание этой границы на уровне класса.

Карта описывала бы и роли клиентов. Агентам и конечным пользователям нужны указания по паролям. Администраторам Zendesk нужны указания по затронутым учётным записям и продуктам. Владельцам приложений нужны указания по учётным данным интеграций. Веб-администраторам нужны указания по сертификатам. Командам по конфиденциальности нужны доказательства по ролям контролёра и обработчика. Командам безопасности нужны указания по аудиту, токенам и проверке доступа. Руководителям нужно краткое заявление об остаточном риске и влиянии на клиентов. Эти аудитории не взаимозаменяемы.

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

Покупателям следует спрашивать о старых данных поддержки до продления

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

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

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

Советы директоров должны рассматривать системы поддержки как инфраструктуру доверия клиентов

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

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

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

Формулировки контрактов должны следовать за поверхностями платформы поддержки

Общие пункты об утечках слишком тонки для платформы поддержки. Формулировки контрактов должны следовать за значимыми поверхностями. Если провайдер хранит данные учётных записей, контракт должен касаться защиты верификаторов паролей, статуса единого входа, активных и неактивных учётных записей и ротации паролей. Если провайдер размещает тикеты поддержки, контракт должен касаться данных тикетов, вложений, пользовательских полей, хранения, удаления и индивидуальных уведомлений клиентов. Если провайдер поддерживает приложения и API, контракт должен касаться учётных данных интеграций, проверки токенов, инвентаризации приложений и журналов аудита.

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

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

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

Операционные индикаторы сделали бы будущие заявления проверяемыми

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

По TLS-материалу — истекли сертификаты или действуют, попали ли закрытые ключи в зону действия и как клиентам заменять и отзывать их.

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

По действиям клиента провайдер может отделить шаги отдельных пользователей от шагов администраторов. Пользователям может потребоваться сбросить пароли. Администраторам — составить список приложений, ротировать секреты, проверить токены, заменить сертификаты и задокументировать анализ конфиденциальности. Командам по конфиденциальности — решить, применима ли статья 33 или другие обязанности по уведомлению. Командам безопасности — проверить журналы на связанный подозрительный доступ. Руководителям поддержки — предупредить агентов и подготовить ответы конечным пользователям.

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

Вопрос повторяемости шире, чем Zendesk

Вопрос не в том, повторит ли Zendesk то же самое событие. Вопрос в том, усвоили ли платформы поддержки, CRM-инструменты, чат-системы и рабочие концентраторы урок старых данных. Система поддержки может стать долгоживущим хранилищем идентификационных данных, операционного контекста, контактных записей клиентов, материалов аутентификации и секретов интеграций. Утечка, обнаруженная спустя годы, может снова сделать старые данные актуальными, потому что клиентам всё равно приходится решать, что ротировать, заменять, о чём уведомлять и что мониторить.

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

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

Главный вывод об ответственности

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

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

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

Решение читателя

Читатель должен вынести практический вопрос. Если бы платформа поддержки сегодня раскрыла, что старые учётные записи, хеши паролей, настройки приложений, учётные данные интеграций и TLS-материалы были доступны годы назад, смогла бы она показать затронутый диапазон дат, классы активных и неактивных учётных записей, доказательства по токенам и приложениям, путь замены сертификатов, границы данных тикетов, индивидуальные уведомления и поддержку регуляторных решений, не заставляя каждого клиента гадать по разрозненным записям? Если ответ отрицательный, запись Zendesk остаётся актуальным уроком подотчётности.

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