Нужен ли мне входящий NACL для разрешения доступа к конечной точке DynamoDB VP C? - PullRequest
Новая
       27

Нужен ли мне входящий NACL для разрешения доступа к конечной точке DynamoDB VP C?

0 голосов
/ 20 января 2020

В моем VP C есть лямбда, которой требуется доступ к DynamoDB. У меня есть настройка конечной точки VP C для этого, наконец-то она заработала, но я сомневаюсь в настройке.

  • Lambda работает в моем личном су bnet.
  • Су bnet имеет таблицу маршрутов:
    1. Пункт назначения : 10.153.32.0/21 Цель : местный
    2. Пункт назначения : pl-02cd2c6b (com.amazon aws .us-east-1.dynamodb, 52.94.0.0/22, 52.119. 224,0 / 20) Цель : (мой VP C Конечная точка)
    3. Пункт назначения : 0.0.0.0/0 Target : (мой NAT-шлюз)
  • My VP C Конечная точка связана с вышеуказанной таблицей маршрутов (и несколькими другими), следовательно, маршрут №2 .
  • И я добавил следующее правило входящих сетевых ACL
    • Диапазон портов 1024 - 65535
    • Блоки CIDR 52.94.0.0/22 и 52.119.224.0/20
    • ALLOW

Меня беспокоит правило сетевого ACL. Я добавил его после прочтения этого комментария .

Мне интересно, нужно ли мне это правило или, может быть, что-то еще не так? Я был удивлен, что мне пришлось добавить его, потому что этот комментарий SO был единственным местом, в котором он упоминался.

Чувствовать себя достаточно безопасно, поскольку эти CIDR должны быть безопасными, поскольку они предназначены специально для DynamoDB. Но я предполагаю, что мне придется следить за изменениями в этих диапазонах.

РЕДАКТИРОВАТЬ: Я также пытался обновить исходящие правила моей группы безопасности лямбда, чтобы разрешить всем портам с пунктом назначения pl-02cd2c6b , но это не сработало.

1 Ответ

1 голос
/ 20 января 2020

Это правило может понадобиться только в том случае, если вы решили использовать настраиваемый сетевой ACL. По умолчанию NACL разрешают все, оставляя контроль доступа к сети в руках настроек группы безопасности ... поэтому вы не используете правила по умолчанию, вам нужно вручную разрешить все в обоих направлениях, поскольку, в отличие от безопасности группы, NACL не отслеживают состояния потока IP.

То, что вы делаете, выглядит правильно (при условии, что вам нужен собственный NACL).

IP-адреса из списка префиксов необходимы для разрешения ответа traffi c во входящем направлении, а необычно широкий диапазон эфемерных портов взят из документации VP C:

AWS Лямбда-функции используют порты 1024-65535.

https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#nacl -ephemeral-ports

Есть документально подтвержденное предостережение относительно обработки списка префиксов как stati c:

диапазон опубликованных c IP-адресов для службы может время от времени меняться. Примите во внимание последствия, прежде чем принимать маршрутизацию или другие решения на основе текущего диапазона IP-адресов для службы.

https://docs.aws.amazon.com/vpc/latest/userguide/vpce-gateway.html#vpc -endpoints-routing

Использование по умолчанию "разрешить все" NACL, вероятно, является лучшей альтернативой. Если вы действительно чувствуете необходимость заблокировать доступ к вашей лямбда-функции, вы сможете создать правило исходящей группы безопасности, ссылающееся непосредственно на pl-xxxx. Это будет работать, как только ваш NACL будет возвращен, чтобы разрешить все.

...