Аудитор запрашивает политику SecurityAudit для среды AWS: насколько это безопасно?

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

Когда будете настраивать роль, железно требуйте External ID. Заодно добавьте в trust relationship ограничение по исходным IP, чтобы зайти под этой ролью можно было только из их офиса или через корпоративный VPN. Через две недели просто удалите роль в один клик.

Аудиторы будут сканировать инфраструктуру автоматическими тулами или инженеры руками пойдут в консоль? Если подключают сторонние сканеры, вы заранее запросили письменно номер их аккаунта и External ID для политики доверия роли?

Мы для комплаенс-аудита настраивали похожую роль. Сам аудит длился 12 дней. Как только всё закончилось, мы сразу удалили IAM-роль и проверили сессию аудитора по логам: суммарно они сделали около 14 200 вызовов API только на чтение. Никаких попыток скачать данные не было.

только не вздумай создавать iam-пользователя и отдавать access key. эти ключи потом вечно где-то забывают и сделайте чисто роль, пропишите external id, закончат работу — удалите роль и дело с концом.

Аудиторским компаниям лишь бы всё на блюдечке получить, но вы вовсе не обязаны давать роль прямо в проде. Большинство контор сами выгружают отчеты по конфигурациям и секурити-выгрузки через консольные утилиты и отдают файлами. Зачем вообще открывать весь живой аккаунт на просмотр?

В соглашении о конфиденциальности (NDA), подписываемом до начала аудита, должно быть четко зафиксировано: как именно обрабатываются данные конфигурации, через сколько дней уничтожаются логи из кэша аудиторского софта и что никакие данные не передаются третьим лицам.

Подытоживая: SecurityAudit дает доступ к конфигурации, а не к самим данным, так что это стандартный запрос. Тем не менее выдавайте права через роль, повесьте External ID, ограничение по IP и таймлимит, а в день окончания аудита грохните роль и проверьте системные логи.

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

Надеюсь, это будет полезно.

Именно так, и при этом об этом мало кто знает. Большинство инцидентов начинается не с уязвимости, а с украденного пароля.

У нас так же.

Есть момент, который я не понял. Чем сложнее отменить решение тем медленнее его принимайте.

Оставлю как заметку, пригодится.

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

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

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

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

Мои сомнения развеялись, спасибо. Не стесняйтесь спрашивать, молчание всегда обходится дороже.

верно. если ругать за ложные тревоги никто больше не будет присылать уведомления.

я бы пошел этим путем.

Я проходил через это, расскажу. Люди защищают не процесс, а привычку. Сопротивление идет оттуда.

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

я бы пошел этим путем.