То, о чем вы говорите, это объектные ACL. В духе работы, которую нужно выполнить , я хочу отметить, что вы можете настроить корзину, чтобы запретить списки ACL для публичных объектов. Это, вероятно, одна из лучших корпоративных практик для профилактика. Среди лучших корпоративных практик для аудита и проверки постоянно описывается здесь.
Обновление : если вы заинтересованы в мониторинге и аудите ACL на уровне сегмента , , взгляните на это управляемое решение AWS Config.
Однако, если вы ищете скрипт / инструмент bash, использующий aws-cli
(который является тегом для этого вопроса), это поможет:
bucket="my-bucket-name"
search_term="AllUsers"
for key in $(aws s3 ls --recursive s3://$bucket/ | awk '{$1=$2=$3=""; print $0}' | sed 's/^[ \t]*//'); do
acl=$(aws s3api get-object-acl --bucket $bucket --key $key) &&
result_found=$(echo $acl | grep -q $search_term) &&
if $result_found; then
echo $key;
echo $acl;
fi;
done
Вот что он делает:
- Рекурсивно перечислять все объекты в вашем ведре
- Итерация по этим ключам объекта
- Спросите S3, что ACL для этого объекта
- Если этот ACL содержит строку «AllUsers» (глобальная группа разрешений s3), он выведет этот ACL на стандартный вывод.
Я обобщил эту проблему, чтобы «повторить все ключи и их ACL в пределах корзины, если ACL содержит данную $search_term
», поэтому, если другие сталкиваются с похожей, но слегка другой проблемой, это решение все равно будет полезно, постольку, поскольку они заменяют $search_term
на то, что соответствует их проблеме.
В идеале (если вы не хотите публичных объектов), если вы запустите это ... ничего не должно отображаться.
Имейте в виду, это решение не будет хорошо масштабироваться для массивных ведер с тоннами и тоннами объектов.