Пожалуйста, помогите мне понять, почему AWS рекомендует назначать роли экземплярам EC2 («подход на основе ролей»), а не хранить ключи API в файлах на экземпляре («подход на основе файлов»)?
Рассмотрим три варианта использованияслучаи: (i) В экземпляре, на котором запущено веб-приложение, есть учетная запись tomcat.Приложение не использует AWS API.В экземпляре есть еще одна учетная запись («поддержка»), которая использует AWS API для ведения и обслуживания (журналы, метрики и т. Д.).
При использовании подхода на основе файлов, если злоумышленник использует приложение и получает доступ кфайловая система (как «tomcat»), они не смогут прочитать файл учетных данных (доступный только для чтения по «поддержке») и не смогут выполнять вызовы API AWS.То же самое верно, если злоумышленник может выполнить произвольный код под учетной записью «tomcat».
Однако при использовании подхода, основанного на ролях, если злоумышленник получает доступ к файловой системе, он ничего не получает (так как нетфайл учетных данных вообще), и они не могут вызывать API AWS.Но если злоумышленник может выполнить произвольный код, он может вызвать API.
(ii) Существует учетная запись tomcat, которая запускает веб-приложение.Приложение вызывает AWS API для своей работы.Существует также другая учетная запись («поддержка»), которая использует AWS API для ведения домашнего хозяйства и обслуживания.Обе учетные записи должны иметь доступ к разным ресурсам (например, для 'tomcat' требуется S3, а для 'support' нужны журналы и метрики).
В подходе на основе ролей роль, назначенная экземпляру, будет эффективно содержать объединениеразрешений, необходимых для tomcat и support, что противоречит принципу наименьших привилегий.Даже если разрешения были технически разделены между двумя ролями, каждая учетная запись в конечном итоге сможет взять на себя роль, которая ей на самом деле не нужна.
При использовании файлового подхода злоумышленник получает доступ к файловой системе.они смогут читать учетные данные «tomcat» и выполнять вызовы API с другого компьютера (этого можно избежать, ограничивая политики конкретным исходным IP-адресом, хотя поддерживать его будет громоздко).Если злоумышленник выполнит произвольный код, он сможет выполнять вызовы API из экземпляра EC2.В обоих случаях учетная запись «support» останется защищенной операционной системой.
При использовании подхода, основанного на ролях, если злоумышленник получит доступ к файловой системе, он ничего не получит с точки зрения вызовов API, так какфайл учетных данных вообще отсутствует.Однако, если злоумышленнику удастся выполнить произвольный код, он может выполнять вызовы API от instace от имени ОБА ролей («tomcat» и «support»).
(iii) Существует учетная запись «tomcat»который запускает веб-приложение.Приложение вызывает AWS API для своей работы.Никакие другие вызовы API не выполняются из экземпляра.
При использовании файлового подхода, если злоумышленник получит доступ к файловой системе, он сможет читать учетные данные tomcat и выполнять вызовы API с другого компьютера.(этого можно избежать, ограничивая политики конкретным IP-адресом источника, хотя поддерживать его будет громоздко).Если злоумышленник выполнит произвольный код, он сможет выполнять вызовы API из экземпляра EC2.
При использовании подхода, основанного на ролях, если злоумышленник получает доступ к файловой системе, он ничего не получает.условия вызовов API, так как файл учетных данных отсутствует вообще.Однако, если злоумышленник может выполнить произвольный код, он может выполнить вызовы API из экземпляра.
Таким образом, кажется, что рекомендуемый подход на основе ролей фактически увеличивает риск в случаях (i) и (ii).
Что мне здесь не хватает?