Как я могу регистрировать, кто и где имеет доступ к моему хранилищу S3?

Как я могу регистрировать, кто и где имеет доступ к моему хранилищу S3?

Недавно я получил электронное письмо, в котором говорилось, что некоторые соединения IE имеют доступ к моему хранилищу:

eu-central-1|media.myapp | REST.GET.OBJECT|TLSv1|9|[Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NE
eu-central-1|media.myapp | REST.GET.OBJECT|TLSv1|54|[Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; InfoPath.1; .NET CLR 3.5.30729; .NET CLR 3.0.30618; .NET4.0C;

Но я хочу знать, что это за устройства и какой IP-адрес они используют, чтобы диагностировать причину проблемы (устаревшая инфраструктура без документов). Есть ли способ вести журнал доступа к учетным записям IAM и устройствам, под которыми IP и MAC получают элементы из моего бакета?

решение1

Я не уверен, правильно ли я понял ваш вопрос, но если вы спрашиваете, как разрешить доступ к вашему ведру S3 только определенным пользователям или IP-адресам (и я предполагаю, что вы говорите об этом из публичного Интернета), вот блок политики ведра, который я использовал, чтобы разрешить, например, доступ к ведру только публичным IP-адресам, которым я хочу:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "IPAllow",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<bucket name>/*",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": [
                        "<first IP/32",
                        "<second IP>/32",
                        "<third IP>/32",
                        "<fourth IP>/32"
                    ]
                }
            }
        }
    ]
}

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

решение2

В руководстве пользователя Amazon S3 объясняется, как вести журнал запросов.

Журнал доступа к серверу предоставляет подробные записи для запросов, которые сделаны к контейнеру. Журналы доступа к серверу полезны для многих приложений. Например, информация журнала доступа может быть полезна для аудита безопасности и доступа.

https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerLogs.html

Вы не сможете узнать MAC-адреса, поскольку они никогда не передаются через Интернет, но IP-адрес устройства (или публичный адрес NAT, если устройство находится за маршрутизатором NAT) будет захвачен. Для идентификации конкретных устройств в локальной сети за маршрутизатором NAT требуется доступ к устройствам и/или к маршрутизатору.

В журналах также будут фиксироваться учетные данные IAM, используемые для доступа к объекту (если таковые имеются).

Со стороны AWS больше ничего нельзя узнать об устройствах, кроме того, что содержится в этих журналах.

Вероятно, письмо, о котором вы говорите, связано с тем, что эти устройства используют TLSv1, поддержку которого AWS вскоре прекратит.

Чтобы соответствовать развивающимся технологиям и нормативным стандартам для Transport Layer Security (TLS), мы обновим конфигурацию TLS для всех конечных точек API сервисов AWS до версии TLS 1.2 как минимум. Это обновление означает, что вы больше не сможете использовать версии TLS 1.0 и 1.1 со всеми API AWS во всех регионах AWS к 28 июня 2023 года.

https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/

Вы можете заблокировать старые версии TLS сейчас, до того как изменения API вступят в силу, с помощью соответствующегополитика отказа. Это потенциально поможет вам идентифицировать устройства из отчетов о неполадках. Периодически добавляя и удаляя политику на данный момент, вы можете идентифицировать устройства, не вызывая постоянного сбоя, как это произойдет, когда изменения API будут вытеснены AWS. Отклоненные запросы по-прежнему будут регистрироваться S3, но будут встречены ответом HTTP 403 и ошибкой AccessDenied.

Связанный контент