Bucket Access Policy: когда авторизацию возвращают в хранилище, а прокси выключают
<img src="https://habrastorage.org/getpro/habr/upload_files/238/2b3/972/2382b3972445e03680963e2ebe081af9.jpg" /><p>У нас в публичном облаке <a href="https://cloud.vk.ru/">VK Cloud</a> у каждого бакета Object Storage есть Bucket Access Policy. Это набор правил в формате JSON, который лежит на самом бакете и говорит, кому какие операции с какими объектами разрешены. Хранилище проверяет эти правила само на каждый запрос. Включается политика в личном кабинете и через S3 API, и я регулярно вижу проекты, где её не настраивали ни разу.</p><p>В статье разбираю состав бакет-политики, её отличия от AWS-руководства и что задавать областью действия ключа, а что политикой. Дальше три механизма проверки на endpoint и порядок между ними, перенос политики из AWS-руководства как есть с разбором, почему он не работает, и четыре итерации доводки (Resource, Principal, aws:SourceIp, явный Deny). Затем матрица из 16 запросов с ожидаемыми кодами и скрипт прогона, метрика доли отказов по Cloud Audit, регуляторика, чек-лист переноса между AWS S3, Ceph, MinIO и VK Object Storage.</p><p>Пригодится тем, кто держит прокси перед хранилищем и хочет перенести правила доступа в само хранилище, и специалистам по ИБ, которым нужно доказать разграничение доступа выгрузкой, а не скриншотом консоли. Для другого S3-совместимого хранилища применима основная часть: механика проверки и матрица тестов от платформы не зависят.</p> <a href="https://habr.com/ru/articles/1076548/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1076548#habracut">Читать далее</a>
