#Признаки неисправности и область применимости
Роль IAM была изменена, но приложение продолжает получать Forbidden, PermissionDenied или 403. Причина может быть в неправильной области назначения роли, старом IAM-токене, отсутствии переключения на нужный сервисный аккаунт или в дополнительной политике доступа.
#Почему это происходит
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Роль назначена не субъекту приложенияПриложение работает от другого аккаунта/ключа. | У администратора доступ есть, у сервиса нет | Проверьте личность вызывающего клиента. |
| Неправильная область ролиПрава доступа относятся к целевому ресурсу. | Новый доступ указан на аккаунте, а не бакете/каталоге | Уточните уровень назначения IAM. |
| Старые временные реквизитыРазные экземпляры приложения могут пользоваться старыми токенами и версиями конфигурации. | В одном экземпляре всё работает, в другом 403 | Проверьте обновление токена и развёртывания. |
#Пошаговая диагностика и устранение
- Снимите точный отказВ журнале приложения найдите запрос, время, HTTP-код, действие и облачный ресурс. Запишите request ID, если он предоставлен. Не копируйте JWT, IAM-токены, API-ключи и пароли целиком; они не нужны для определения требуемой роли.
- Проверьте работающего субъектаПосмотрите, какой сервисный аккаунт указан в карточке облачной функции, контейнера или ВМ, либо каким ключом приложение подписывает запрос. Не проверяйте доступ от своего личного профиля Yandex Cloud: это другой субъект.
- Уточните нужное разрешениеОпределите конкретное действие: получение объекта, создание ВМ, запись метрики. Найдите минимальную роль для него в справочнике IAM. Не назначайте общую роль admin только из-за одного Forbidden.
- Сверьте область назначенияВ консоли откройте права доступа каталога, облака или отдельного ресурса. Проверьте, что роль назначена нужному сервисному аккаунту именно на ресурс, с которым он работает. Роль, выданная *на самом сервисном аккаунте как на ресурсе*, не даёт ему автоматический доступ к другим сервисам.
- Проверьте ограничения организацииДокументация IAM предупреждает, что политика авторизации организации может запрещать действие даже при наличии разрешающей роли. Если есть такой запрет, эскалируйте его ответственному за безопасность, не пытайтесь обойти другой учётной записью.
- Обновите рабочие учётные данныеЕсли приложение использует короткоживущий IAM-токен, убедитесь, что код запрашивает актуальный токен по штатному механизму. Для токена, закреплённого в файле, выполните его безопасную ротацию и контролируемое обновление экземпляров. Не переписывайте секреты вручную в коде.
- Испытайте разрешение на малой операцииПовторите исходный запрос чтения или другую безвредную операцию от имени приложения. Если нужен доступ на запись, используйте тестовый объект и предусмотрите его очистку. Сравните результат с ошибкой до изменения, не повышая разрешения сверх необходимого.
- Зафиксируйте изменения и проверьте другие узлыПосле успешного запроса проверьте все экземпляры/версии приложения, поскольку один сервер может продолжать использовать устаревшую конфигурацию. Если ошибка остаётся, верните лишние роли и приложите обезличенные журналы для администратора IAM.
#Как проверить, что проблема исправлена
Запросы приложения проходят с нужной ролью от его настоящего сервисного аккаунта; другие ресурсы остаются недоступными, если доступ к ним не предусмотрен. Все экземпляры приложения дают одинаковый результат.
#Если проблема осталась
Если проверка дала 403 при подтверждённых правах, исследуйте политику ресурса, тип ключа и запреты организации. Для проблем S3 дополнительно учитывайте политику бакета и шифрование KMS.