Вопрос
Как можно ограничить доступ к корзине S3 для одного экземпляра AWS, если у экземпляров нет общедоступного IP-адреса и вы используете конечную точку S3 в своем VPC?
Фон и детали
У нас есть VPC с виртуальным частным шлюзом, который через VPN обеспечивает обратную связь с нашим локальным центром обработки данных. VPC не имеет интернет-шлюза. У серверов нет публичных IP-адресов. Конечная точка S3 и таблица маршрутов настроены правильно. Допустим, есть одна подсеть с тремя экземплярами. Нам еще предстоит создать два сегмента S3, которые будут зашифрованы.
Мы хотели бы ограничить доступ из сегмента A S3 экземпляра A и экземпляра B к сегменту S3 B. Экземпляр C не должен иметь доступа ни к одному из сегментов.
Нам также необходимо иметь возможность загружать информацию в корзины из общедоступного Интернета. Этот доступ должен быть доступен только через определенные IP-адреса, что легко сделать с помощью политик корзины. Однако это может иметь значение для решения.
Эта страница в документации AWS говорит
Вы не можете использовать политику IAM или политику сегмента, чтобы разрешить доступ из диапазона CIDR IPv4 VPC (диапазон частных IPv4-адресов). Блоки VPC CIDR могут перекрываться или совпадать, что может привести к неожиданным результатам. Следовательно, вы не можете использовать условие aws: SourceIp в своих политиках IAM для запросов к Amazon S3 через конечную точку VPC. Это относится к политикам IAM для пользователей и ролей, а также к любым политикам сегментов. Если оператор включает условие aws: SourceIp, значение не соответствует ни одному из предоставленных IP-адресов или диапазонов. Вместо этого вы можете сделать следующее:
- Используйте свои таблицы маршрутов, чтобы контролировать, какие экземпляры могут получать доступ к ресурсам в Amazon S3 через конечную точку.
- Для политик корзины вы можете ограничить доступ к определенной конечной точке или к определенному VPC. Дополнительную информацию см. В разделе Использование политик корзины Amazon S3.
Мы не можем использовать таблицы маршрутов, так как у нас есть два экземпляра, которым нужен доступ к разным корзинам.
Я также читал эта страница, что не помогло в нашей ситуации.
Вариант: ключи KMS
Я подозреваю, что если мы дадим каждой корзине собственный ключ KMS и ограничим доступ к ключам для соответствующего экземпляра, только этот экземпляр сможет получить доступ к расшифрованным данным. Я думаю, это сработает, но в этом есть некоторая сложность, и я не уверен на 100%, поскольку я мало что сделал с KMS.
Преимущество этого подхода в том, что он по умолчанию отклоняет гранты по конфигурации. Из-за большого количества пользователей учетной записи мы не можем полагаться на конфигурацию для отказа по умолчанию, как было очень полезно предложено Алексом ниже.
Идеи, мысли или предложения
Есть ли у кого-нибудь другие предложения или идеи, которыми мы могли бы заняться? Или какие-либо мысли / подробности по идее KMS?
Я предлагаю использовать роли экземпляра. Это роли, которые могут быть приняты приложениями, работающими в определенных экземплярах, путем запроса службы метаданных - инструменты AWS поддерживают это изначально - позволяя приложениям, работающим на этом экземпляре, использовать эти учетные данные. Подробнее о них Вот.
Тогда у вас будет уникальная роль, например, A, и другая, например, B, а затем ознакомьтесь с этим сообщением об использовании политик корзины для ограничения доступа к корзине на основе определенной роли. Вот.
Вероятно, это должно сделать то, что вам нужно. Хотя KMS - тоже подход, но, наверное, более сложный. Вы также можете переместить экземпляры в разные VPC и использовать политику конечных точек для ограничения доступа на основе исходного VPC, но это будет очень беспорядочно и приведет к другим осложнениям.