Аудитор клиента требует открыть «AWS security audit role» в нашем облаке — сколько прав выдавать?

Самая частая ошибка — путать ReadOnlyAccess и SecurityAudit. Если накатить ReadOnlyAccess, аудитор сможет скачивать файлы из ваших S3-бакетов и глубоко копаться в метаданных БД. Безопаснику же нужна только SecurityAudit и, от силы, пара дашбордов для мониторинга.

Для безопасной роли аудита обязательно сделайте три вещи: 1) пропишите сложный, не поддающийся подбору ExternalId в trust policy; 2) поставьте MaxSessionDuration на один час; 3) залочьте доступ на уровне политик по диапазону IP-адресов аудитора.

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

исправление: ошибся в цифре, было чуть меньше.

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

В прошлом году проходили два похожих аудита. Включали роль строго на 72-часовое окно с длительностью сессии в 3 часа. Аудитор суммарно сделал всего 42 вызова API и закончил работу. Тайм-аут вышел — роль снесли, вообще без проблем.

в первый раз всегда мандраж, это нормально. но паниковать не стоит: скажите аудитору «по нашей политике безопасности мы не выдаем консольных пользователей, только audit role с external id» — это сразу покажет ваш уровень и профессионализм.

как роль заведете мониторьте ее имя в cloudtrail время от времени, чекайте че он там делает. если начнет лазить по левым сервисам, сразу на карандаш.

Не теряйте времени: идете в консоль IAM создаете роль типа «Another AWS account», вбиваете ID их аккаунта, ставите галочку Require external ID цепляете исключительно SecurityAudit и сохраняете.

Поделюсь своим опытом. Главное не цифра, а то, на основе чего она получена.

Интересно, есть ли те, кто делает иначе.

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

На этом всё, извините, если затянул.

Здесь есть еще и аспект измерений. Автоматический отчет о сканировании и пентест — это не одно и то же.

Интересно, есть ли те, кто делает иначе.

Вы правы.

Если пойдете этим путем, сразу решите вот этот вопрос. То, что делают все, не значит, что это правильно.

Изменение платежных данных никогда не подтверждается через тот же канал. Интересно, есть ли те, кто делает иначе.

Вы правы, я сам проходил через это. Забытые тестовые среды становятся входом в систему чаще, чем продакшн.

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

Автоматический отчет о сканировании и пентест — это не одно и то же. Проверено опытом.

Не знал об этом.

Я сталкивался с тем же.

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

Конечно, если ваша ситуация отличается, всё меняется.