Я хотел бы разместить статический веб-сайт на amazon S3, но мне нужно ограничить доступ к нему определенным пользователям. Это возможно через ip-адрес или учетные данные amazon (только зарегистрированные пользователи могут получить доступ к содержимому ковша.
Возможно ли это?
Спасибо
Да, это действительно возможно. Лучшая отправная точка для вас будет считаться контроль доступа S3.
Но по умолчанию ковши, созданные на S3, не являются общедоступными. Таким образом, поведение по умолчанию должно быть таким, что оно будет доступно только человеку/программе, который/который знает ваш доступ и секретный ключ.
Вы также можете редактировать разрешение ведра, чтобы предоставить доступ к определенной учетной записи AWS или идентификатору электронной почты.
Чтобы ограничить доступ к определенным IP-адресам, вы можете создать дополнительную политику ведра.
Ограничение доступа к определенным IP-адресам
Этот оператор предоставляет разрешения любому пользователю выполнять любое действие S3 на объекты в указанном ковше. Однако запрос должен исходят из диапазона IP-адресов, указанных в условии. Условие в этом утверждении определяет 192.168.143. * Диапазон разрешенные IP-адреса с одним исключением, 192.168.143.188.
Обратите внимание, что значения IPAddress и NotIpAddress, указанные в условие использует запись CIDR, описанную в RFC 2632. Для получения дополнительной информации информацию, перейдите в http://www.rfc-editor.org/rfc/rfc4632.txt.
{
"Version": "2012-10-17",
"Id": "S3PolicyId1",
"Statement": [
{
"Sid": "IPAllow",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::bucket/*",
"Condition" : {
"IpAddress" : {
"aws:SourceIp": "192.168.143.0/24"
},
"NotIpAddress" : {
"aws:SourceIp": "192.168.143.188/32"
}
}
}
]
}
Изменить: ограничения на основе пользователя/группы не работают для статических веб-сайтов, размещенных на S3, так как AWS не регистрирует вашу консоль управления AWS ( путь: amazon.com) учетные данные/файлы cookie для S3 (путь: amazonaws.com), а также не проверяйте их.
Обходной путь: www.s3auth.com - Базовый Auth для S3-ковшей может сделать трюк для вас, но связан с третьей стороной. Другим решением может быть Аутентификация запроса строки запроса, используя экземпляр EC2 или Вариант статических файлов Java SE. В настоящее время мы изучаем безопасность наших ведер с помощью Amazon API Gateway в качестве прокси-сервера Amazon S3.
Sidenote: Есть некоторые дополнительные вещи, которые нужно искать, которые часто не указываются напрямую.
В настоящее время невозможно в политике ведра предоставлять или ограничивать доступ к группе, а только конкретные пользователи. Поскольку вы также обычно не хотите обновлять каждую политику ведра для каждого изменения в своей структуре пользователя, а политики в виде корзины могут (непреднамеренно) вмешиваться в ваши пользовательские политики, вам может не понадобиться использовать политики ведра.
Политики, основанные на пользователе/группе, работают только с s3:GetBucketLocation и s3:ListAllMyBuckets, привязанными к arn:aws:s3:::* или * (к сожалению, фильтрация невозможна здесь, все имена ведра будут видны для пользователей/групп с этой политикой).
Пример политики IAM: (а не политика ведомости S3 и не, работающая для статического хостинга веб-сайта)
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets",
"s3:GetBucketLocation"
],
"Resource": [
"arn:aws:s3:::*"
]
},
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": [
"arn:aws:s3:::YOURBUCKETNAME",
"arn:aws:s3:::YOURBUCKETNAME/*"
]
}
]
}
Более подробное сообщение в блоге: Как ограничить доступ к конкретному роли IAM для Amazon S3
Вы можете ограничить доступ к ведро/статический веб-сайт определенным HTTP-референтам. Таким образом, вы можете создать сайт членства в wordpress, где только зарегистрированные пользователи на этом сайте могут получить доступ к сайту, размещенному на Amazon. Например. mymembershipsite.com/members.