Контроли токенов Cloudflare показывают настоящую проблему IAM
Последнее обновление Cloudflare по developer security не выглядит эффектно. Без кинематографичной истории взлома. Без магического AI-щита. Просто более точные контроли для API tokens, OAuth connections и resource-scoped permissions.
И это хорошо. Именно там и находится большая часть реальной работы по security.
Обновление фокусируется на проблеме, которую большинство команд всё ещё считает нормой: non-human identities продолжают накапливать права долго после того, как кто-либо помнит, зачем они вообще были созданы. API tokens, service accounts, CI/CD secrets, боты, OAuth apps, proxy integrations, monitoring agents и automation scripts часто превращаются в невидимую инфраструктуру. Они не проходят onboarding. Они не увольняются из компании. Они не жалуются, когда их credentials никто не ротирует три года.
Они просто лежат там с доступом.
Cloudflare анонсировала три практических улучшения: scannable API tokens, лучшую видимость OAuth connections и general availability для resource-scoped permissions. Но реальный смысл шире, чем Cloudflare. Credential sprawl и слишком широкие permissions всё ещё остаются дефолтом в современной инфраструктуре. Least privilege обычно появляется не потому, что кто-то написал это в policy document. Он появляется тогда, когда платформа не даёт легко сделать неправильную вещь.
Вот на эту часть стоит обратить внимание. 💀
Non-Human Identities — это не фоновая сантехника#
Большинство программ access control строились вокруг людей: сотрудников, contractors, admins, support staff, партнёров. Можно включить MFA, отключать accounts после увольнения, требовать смену пароля, проводить access reviews и привязывать identity к HR workflows.
Машины плохо вписываются в эту модель.
Non-human identity может быть:
- API token, который использует deployment script,
- service account для monitoring tool,
- OAuth grant, одобренный для third-party app,
- CI/CD secret, используемый для публикации builds,
- bot account, который управляет tickets или DNS records,
- proxy или edge integration, меняющая routing behavior,
- security automation token с read/write permissions across environments.
Такие identities часто оказываются вне обычных циклов проверки. Их создают во время incidents, migrations, launches, proof-of-concept projects, vendor integrations и ночных сессий в стиле «просто заставь это работать». Потом проект меняется, владелец уходит, документация устаревает, а credential остаётся.
Это не edge case. Это дефолтный режим отказа.
Когда компрометирован human account, defenders обычно спрашивают: кто это, какая у него role, к каким systems у него есть access и можем ли мы его suspended? С non-human identities ответы часто хуже:
- Никто не знает, кому принадлежит token.
- Имя token расплывчатое или бесполезное.
- Scope шире, чем исходная задача.
- Secret встроен в pipeline, который никто не хочет трогать.
- Revoking может сломать production.
- Никто не знает, нужна ли OAuth connection до сих пор.
Именно так «маленький» leaked credential превращается в full-account incident.
Что изменила Cloudflare — и почему это важно#
Обновление Cloudflare подсвечивает три control, которые важны, потому что уменьшают operational friction вокруг более безопасного identity management.
Scannable API tokens#
Scannable API tokens помогают defenders и operators надёжнее находить exposed или misplaced credentials. Это важно, потому что secrets утекают постоянно: в repositories, chat logs, build artifacts, local config files, screenshots, support tickets и на developer machines.
Security value не только в том, что leaked token можно обнаружить. Более глубокая ценность в том, что tokens становится проще inventory и track. Если credentials нельзя обнаружить, они превращаются в shadow infrastructure. Shadow infrastructure не проходит review. Её компрометируют.
Token, который нельзя легко найти, — это token, который переживёт свою цель.
Лучшая видимость OAuth#
OAuth grants — один из самых недооценённых путей access во многих environments. User один раз approves app, app получает access, и дальше все мысленно идут дальше. Через месяцы эта third-party integration всё ещё может иметь permissions к business-critical systems.
К OAuth connections нужно относиться с тем же подозрением, что и к API keys. Это delegated access. Он может быть over-scoped. Он может жить дольше, чем планировалось. Он может стать supply-chain risk, если connected application будет compromised.
Лучшая видимость означает, что команды быстрее могут ответить на базовые вопросы:
- У каких apps есть access?
- Кто их approved?
- Какие scopes были granted?
- Используются ли они до сих пор?
- Можно ли их удалить, не сломав workflows?
Эти вопросы звучат базово, потому что они базовые. Проблема в том, что многие platforms всё ещё делают ответы на них раздражающе сложными.
Resource-scoped permissions#
Это самая острая часть обновления.
Resource-scoped permissions позволяют сузить access до конкретного resource вместо выдачи широких account-level permissions. В терминах Cloudflare, th