Использование ACL сети AWS и SG для контроля доступа? - PullRequest
Новая
       50

Использование ACL сети AWS и SG для контроля доступа?

2 голосов
/ 22 мая 2019

У меня есть экземпляр Ubuntu EC2, работающий на AWS. Я всегда использовал сетевой ACL для управления доступом к порту 22 вместо использования групп безопасности.

Вопрос 1. Для варианта использования одного экземпляра EC2, есть ли плюсы и минусы между использованием NACL против SG для контроля доступа? (Помимо состояния с сохранением состояния и отсутствия различий в документации по безопасности AWS VPC.)

Вопрос 2: Как большая среда справляется с этим? Есть ли лучшая практика? (Я знаю, что в одной крупной компании NACL полностью открыт и контролирует все с помощью SG.)

Первым делом, чтобы попытаться найти ответ, я прочитал документы AWS по безопасности VPC: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Security.html

Я вижу пару методов для контроля доступа в моем случае использования:

Вариант 1. Ограничьте вход NACL для портов 80, 443 и эфемерных портов до 0.0.0.0/0. Добавьте порт 22 доступа на IP-адрес. Запретить весь другой трафик. (Это то, что я всегда делал.) Если бы я хотел экземпляр частной подсети, я бы ограничил частную подсеть через SG внутренним CIDR публичной подсети.

Вариант 2. Откройте NACL для всего мира и используйте SG для контроля доступа к экземпляру EC2.

Вариант 3: быть избыточным и использовать оба.

Когда я перехожу в новое место (кафе) и хочу использовать SSH для своего экземпляра, я захожу в консоль AWS и добавляю новое правило NACL, чтобы разрешить доступ к порту IP-адреса 22. Добавление правила и к NACL, и к SG кажется одинаковым количеством щелчков мышью и вводом.

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

Ресурс NACL: 

  ingress {
    protocol   = 6
    rule_no    = 300
    action     = "allow"
    cidr_block = "0.0.0.0/0"
    from_port  = 80
    to_port    = 80
  }

Ресурс SG: 

ingress {
    from_port = 80
    to_port = 80
    protocol = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

Единственное большое преимущество, которое я вижу для NACL, - если есть несколько Public SG, проще занести в черный список IP-адреса в NACL, если они обрабатываются вручную через консоль.

Ответы [ 2 ]

1 голос
/ 23 мая 2019

Контроль доступа и обеспечение безопасности VPC - большая тема, и есть много рекомендаций, которые AWS предлагает использовать для различных сценариев (например, Bastion Hosts )

Для простого случаяПолучая доступ к одной EC2 в общедоступной подсети с компьютера вашей кофейни, вам нужно изменить группу безопасности, чтобы разрешить SSH из кофейни ip.

Используя консоль, общие шагиявляются:

  1. В панели мониторинга VPC -> Безопасность -> Группа безопасности -> синяя кнопка: Создать группу безопасности.Назовите его Coffee SG, опишите его и выберите соответствующий VPC, с которым вы хотите связать его, и нажмите «Создать».
  2. После создания SG перейдите на вкладку «Входящее правило» внизу и нажмите кнопку «Изменить правила»
  3. Для Типа выберите SSH
  4. Для источника выберите «мой ip», если вы находитесь за компьютером кафе.Браузер автоматически заполнит форму с IP-адресом компьютера.Чтобы разрешить любой ip, вы можете использовать 0.0.0.0/0 ( не рекомендуется ), чтобы разрешить диапазон, используйте CIDR.
  5. Нажмите Сохранить правила.
  6. При запускев вашем экземпляре ec2 выберите Coffee SG для своей группы безопасности.

Если ваш EC2 уже запущен, перейдите в группу безопасности и начните с шага 2 выше.Для получения дополнительной информации см. Руководства AWS:

В этом руководстве представлены шаги, которые необходимо выполнить для экземпляров Linux. В этом руководстве представлены действия, которые необходимо выполнить для экземпляров Windows.

1 голос
/ 23 мая 2019

NACL работает на уровне подсети, SG работает на уровне экземпляра, как сказано в документах, на которые вы ссылаетесь, поэтому для подсети с одним экземпляром в ней, тогда NACL с явным отказом - единственное различие в функциональности.Я предлагаю AWS cli для вашего примера кофейни, выбирайте между NACL и sg, в зависимости от того, какая команда вам удобнее.

В большой среде может быть несколько экземпляров в подсети, поэтому SG позволяет разрешать уровень экземпляров.Я также считаю, что SG, являющийся динамическим облачным вариантом, делает его предпочтительным, поскольку в правилах может использоваться членство в SG, а не IP-адреса.Это делает инфраструктуру переносимой между областями, vpcs и az, так как адресация может быть динамической или перекрывающейся, но ваш стек все равно будет работать.

...