Инцидент с безопасностью GitBook: что делать пользователям

Разбор инцидента с безопасностью GitBook: как проверить утечку, какие данные могли скомпрометировать и какие меры защиты применить командам.

Что известно об инциденте GitBook

Хронология уведомлений и ответ поддержки

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

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

Если вы используете GitBook для хранения внутренней документации, проверьте логи доступа к своим пространствам. Ниже пример запроса к API GitBook для получения списка последних сессий (замените YOUR_TOKEN на реальный токен):

bash
curl -s -H "Authorization: Bearer YOUR_TOKEN" \
  https://api.gitbook.com/v1/spaces | jq '.[] | {name, updatedAt}'

Команда выводит названия пространств и дату последнего обновления. Если видите пространство, которое не правили вы или ваша команда — это повод для инцидента на вашей стороне.

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

Какие данные могли пострадать

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

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

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

Проверьте, не хранили ли вы в GitBook секреты. Если да — считайте их скомпрометированными и ротируйте немедленно. Пример проверки переменных окружения в GitHub Actions (если интеграция была подключена):

bash
gh secret list -R your-org/your-repo

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

Настоятельно рекомендуется проверить логи аутентификации на своих серверах за период, указанный в уведомлении GitBook. Если используете Wazuh или аналогичный SIEM, поищите события входа с необычных IP:

bash
# Пример запроса к Wazuh API (замените на свои параметры)
curl -u wazuh-api-user:wazuh-api-password \
  "https://wazuh-server:5500/v1/alerts?rule.id=5710&timeframe=7d" | jq '.data.affected_items[].srcip'

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

Для аудита изменений в документации после инцидента полезно сравнивать версии страниц. Например, OmniDiff — ultrafast Git difftool на Rust позволяет быстро найти, какие именно фрагменты были изменены или удалены.

Оценка рисков для пользователей и команд

Что делать с токенами, паролями и сессиями

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

Не делайте так: менять только пароль в веб-интерфейсе и оставлять старые personal access tokens активными. Сессии остаются валидными, а токены в CI/CD продолжают работать.

Настоятельно рекомендуется ротировать все credentials в течение первого часа после инцидента.

С точки зрения безопасности порядок действий такой:

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

Пример проверки репозитория:

bash
trufflehog --json . > gitbook-leaks-$(date +%F).json

Если нашли секрет — считать его скомпрометированным и ротировать целевую систему, а не только удалять из истории. Удаление из git не отменяет утечки, если репозиторий был публичным или склонирован.

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

Интеграции GitBook с GitHub, GitLab, Bitbucket и облачными хранилищами — отдельная поверхность атаки. OAuth-приложения, вебхуки и CI/CD-токены могут остаться активными даже после смены пароля.

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

Что проверить:

список OAuth-приложений в GitHub/GitLab, имеющих доступ к репозиториям организации;
вебхуки, отправляющие данные из GitBook во внешние системы;
токены в GitHub Actions, GitLab CI, Jenkins и других конвейерах;
права участников организации в GitBook — кто имеет роль администратора.

Пример проверки авторизации в GitHub CLI:

bash
gh auth status
gh api user -q '.login'

Если нашли незнакомое приложение — отозвать доступ сразу. Не ждите подтверждения от поддержки GitBook.

Для быстрого просмотра изменений в репозиториях после инцидента полезен OmniDiff — ultrafast Git difftool на Rust. Если инцидент связан с уязвимостями в инфраструктуре, стоит проверить патчи — например, Ubuntu не выпустил патч для критической RCE уязвимости Linux.

Чеклист действий:

Отозвать все personal access tokens GitBook
Завершить все активные сессии в организации
Сменить пароли, особенно повторяемые на других сервисах
Просканировать историю Git на секреты (truffleHog, gitleaks)
Аудит OAuth-приложений и вебхуков в подключённых репозиториях
Удалить незнакомые интеграции и CI/CD-токены
Проверить права администраторов в GitBook

Меры защиты после утечки

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

Ротация секретов и отзыв сессий

Сначала определите, что именно попало в документацию. Чаще всего это API-ключи, строки подключения к базам данных, пароли от админок, приватные ключи SSH. С точки зрения безопасности, любое значение, которое когда-либо открывалось в браузере автора, уже считается утекшим.

Типовая ошибка — ротировать только «текущие» пароли, оставив старые ключи в истории ревизий GitBook. Если документ редактировался, секрет остаётся в предыдущих версиях страницы.

Действия:

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

Пример отзыва GitHub personal access token через CLI:

bash
# Проверьте активные токены в профиле
gh auth status

# Отзовите токен, если он был в документации.
# Замените TOKEN на реальное значение перед выполнением.
gh api -X DELETE /authorizations/TOKEN

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

На практике я видел случай, когда разработчик ротировал пароль от базы данных, но оставил старый пароль в переменных окружения CI/CD. Атакующий, получивший доступ к документации, использовал устаревший ключ для подключения к реплике. Проверяйте все места хранения, а не только те, что видны на экране.

Если утечка затронула серверы, убедитесь, что инфраструктура пропатчена независимо от смены паролей: Ubuntu не выпустил патч для критической RCE уязвимости Linux.

Мониторинг подозрительной активности и алерты

После ротации секретов нужно понять, не использовали ли их до того, как вы заметили инцидент. Мониторинг — это не про «установить и забыть», а про настройку алертов на конкретные события.

Что мониторить:

попытки входа с новых IP-адресов;
создание новых API-ключей и токенов;
изменения в репозиториях, связанных с утечкой;
доступ к административным панелям из нетипичных геолокаций.

Если у вас есть доступ к логам аутентификации, настройте правило в Wazuh или аналогичном SIEM. Пример простого правила для обнаружения множества неудачных входов:

xml
<rule id="100005" level="10">
  <if_sid>5710</if_sid>
  <match>Failed password</match>
  <description>Multiple failed SSH login attempts after GitBook incident</description>
  <group>authentication_failed,</group>
</rule>

Для быстрой проверки вручную можно просмотреть journalctl на сервере:

bash
# Последние 100 записей об аутентификации SSH
journalctl -u ssh -n 100 --no-pager

# Поиск успешных входов за последние сутки
journalctl --since "24 hours ago" | grep "Accepted publickey"

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

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

Если нужно сравнить конфигурации до и после инцидента, используйте инструмент для работы с git-диффами: OmniDiff — ultrafast Git difftool на Rust.

Чеклист дальнейших действий

Составлен перечень всех секретов, попавших в документацию
Отозваны все активные сессии и токены в затронутых сервисах
Сгенерированы новые ключи и пароли, заменены в конфигурации
Старые версии страниц удалены из истории GitBook (если возможно)
Настроен мониторинг попыток входа с новых IP
Настроены алерты на создание новых API-ключей
Проверены логи аутентификации на серверах инфраструктуры
Убедитесь, что мониторинг не зависит от уведомлений GitBook

Как предотвратить подобные инциденты

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

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

Аудит сторонних сервисов и поставщиков

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

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

Проверяйте технические возможности, а не маркетинг:

поддерживается ли enforced MFA для всех пользователей;
можно ли ограничить доступ по IP (allowlist);
есть ли экспорт аудит-логов в ваш SIEM;
работает ли SSO/SAML с вашим IdP.

Пример проверки заголовков безопасности стороннего домена:

bash
# Проверяем наличие заголовков безопасности
curl -I https://docs.example.com

В ответе ищите Strict-Transport-Security, Content-Security-Policy, X-Frame-Options. Если заголовков нет — задайте вопрос поставщику перед тем как загружать в его систему конфиденциальную информацию.

Категорически не рекомендуется хранить production-секреты, строки подключения к базам данных или ключи API в документации, даже в «приватных» разделах. Типовая ошибка — выложить .env или config.yml в вики «для удобства команды».

На практике я видел случай, когда команда хранила пароли от staging-среды в публичном пространстве документации, потому что «там же только текст». Инцидент у поставщика раскрыл всё пространство сразу.

Регулярно пересматривайте список поставщиков. Сервис, который был безопасен год назад, мог сменить владельца, модель монетизации или уровень защиты. Если поставщик не публикует отчёт о безопасности (SOC 2, ISO 27001) и не отвечает на запросы — это сигнал к поиску альтернативы.

Ubuntu не выпустил патч для критической RCE уязвимости Linux — даже крупные вендоры задерживают патчи, поэтому нельзя полагаться только на обязательства поставщика по безопасности.

Принцип наименьших привилегий и политика доступа

Если сторонний сервис скомпрометирован, у атакующих будет ровно столько прав, сколько вы выдали этому сервису. Инцидент с GitBook — повод пересмотреть модель доступа не только к документации, но и ко всем интеграциям.

Принцип наименьших привилегий применяется и к людям, и к сервисным аккаунтам.

Для сотрудников:

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

Для сервисных интеграций:

не используйте личные аккаунты сотрудников для подключения сторонних сервисов. Заводите отдельный сервисный аккаунт с минимальными правами;
токены API — с ограниченным scopes, коротким сроком жизни и обязательной ротацией;
если сервису нужно только читать репозиторий, не выдавайте права на запись, удаление или управление вебхуками.

Пример: deploy key в GitHub только на чтение:

bash
# Генерируем ключ только для чтения репозитория
ssh-keygen -t ed25519 -f deploy_key -C "gitbook-readonly"
# Выводим публичную часть для добавления в Deploy Key
cat deploy_key.pub

Публичный ключ добавляется в репозиторий как Deploy Key с флагом «Read only». Приватный ключ никогда не передаётся стороннему сервису, если он не поддерживает безопасное хранение ключей.

Политика доступа — default deny. Всё, что не разрешено явно, запрещено. Это относится и к входящим, и к исходящим соединениям от вашей инфраструктуры к сторонним API.

Настоятельно рекомендуется автоматизировать ревью доступа: если у сотрудника не было активности в сервисе 30 дней, доступ приостанавливается до подтверждения руководителем. При увольнении или расторжении контракта все токены и ключи отзываются в первый же день, а не к концу недели.

Используйте инструменты сравнения конфигураций, чтобы отслеживать изменения в правах доступа. Например, OmniDiff — ultrafast Git difftool на Rust позволяет быстро видеть, кто и когда изменил политики IAM или конфиги интеграций.

Skills for Real Engineers: Инструменты и практика — подборка практик для инженеров, которые хотят выстроить процессы доступа без лишней бюрократии.

Чеклист: что сделать в первую очередь

Составить инвентарь сторонних сервисов с классами данных и контактами безопасности поставщиков.
Проверить поддержку MFA, SSO, IP-allowlist и экспорта аудит-логов у каждого критического поставщика.
Удалить секреты, ключи API и конфиги из документации и вики.
Провести ревью ролей и прав сервисных аккаунтов по принципу default deny.
Ротировать токены API и ключи доступа, используемые для интеграций.
Настроить экспорт аудит-логов сторонних сервисов в ваш SIEM.
Запланировать квартальный ревью доступа сотрудников и подрядчиков.

Часто задаваемые вопросы

Что делать с паролями и ключами, которые хранились в страницах GitBook

Считайте их скомпрометированными и немедленно ротируйте. С точки зрения безопасности, текст в открытом виде в wiki — это уже утечка, даже если доступ к аккаунту не был взломан. Настоятельно рекомендуется проверить все страницы на наличие паролей, токенов API и приватных ключей, а затем удалить их из истории ревизий. Не делайте так: не ограничивайтесь только сменой пароля от самого GitBook.

Нужно ли отзывать токены GitHub и GitLab, подключённые к GitBook

Да, отзывайте все токены интеграций, которые имели доступ к репозиториям через GitBook. На практике я видел случай, когда злоумышленник получал доступ к приватным репозиториям именно через скомпрометированный OAuth-токен стороннего сервиса. Рекомендуется создать новые токены с минимальными правами и подключить их повторно только после аудита. Категорически не рекомендуется оставлять старые токены активными «на всякий случай».

Как проверить, заходил ли кто-то ещё в моё пространство GitBook

Выполните запрос к API GitBook, чтобы получить список пространств и даты последнего обновления:

bash
curl -s -H "Authorization: Bearer YOUR_TOKEN" \
  https://api.gitbook.com/v1/spaces | jq '.[] | {name, updatedAt}'

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

Стоит ли переходить с GitBook на другое решение после инцидента

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

Что делать с доступом бывших сотрудников к GitBook после инцидента

Проведите внеплановую проверку всех активных сессий и отзовите доступ у уволенных сотрудников, если этого не сделали ранее. Инцидент со стороны поставщика не отменяет необходимости аудита своих прав доступа — наоборот, он показывает, что внешний контур может быть скомпрометирован. Рекомендуется выдать временные пароли всем пользователям и потребовать повторную аутентификацию через 2FA. Не делайте так: не оставляйте старые сессии активными, ожидая официального заявления от GitBook.

Инцидент с безопасностью GitBook: что делать пользователям