Ситуация
У нас есть веб-приложение, размещенное на Amazon EC2. Оно предназначено для использования только несколькими пользователями в компании.
Как мы с этим справляемся
- Мы делимся (эластичным) IP-адресом экземпляра с пользователями.
- Мы добавляем IP-адрес каждого пользователя в группу безопасности экземпляра по мере необходимости.
Когда я говорюпо мере необходимости, я имею в виду письма от пользователей, жалующихся на то, что веб-портал показывает страницу с ошибкой. Они забывают, что этот шаг включения IP в группу безопасности обязателен (и я их не виню; они конечные пользователи).
Для этого вопроса предположим, что в компании всего 5 пользователей, которым нужен такой доступ. IP-адреса Пользователя-1 и Пользователя-2 уже добавлены в группу безопасности.
Проблемы
- Пользователь 3 переходит по IP-адресу напрямую, но не может получить к нему доступ, поскольку IP-адрес пользователя не добавлен в группу безопасности.
- Если Пользователь-1 или Пользователь-2 перезагрузят свой Интернет, их IP-адрес, скорее всего, изменится (динамический IP-адрес, предоставленный интернет-провайдером), и новый IP-адрес придется добавить в группу безопасности (а старый придется отозвать, чтобы избежать доступа к нему других лиц).
Другие варианты, которые я рассматриваю
- Предоставьте доступ только к своему офисному VPN и попросите всех пользователей подключаться через него.
- (Очень обременительно для пользователя) Попросите пользователей войти в консоль управления AWS, перейти в службу EC2, перейти в раздел «Группы безопасности» и вручную добавить свои IP-адреса (у пользователей уже есть пользователи AWS IAM и соответствующие разрешения для выполнения этого).
- Создать скрипт, который добавляет текущий IP-адрес пользователя в группу безопасности (с помощью AWS CLI/SDK) — звучит очень опасно и неуместно, поскольку нам придется включить в скрипт чьи-то учетные данные API.
решение1
Вариант 4 — прекратить контролировать доступ через группы безопасности и вместо этого реализовать какой-либо достойный механизм аутентификации.
Например, поставьтеБалансировщик нагрузки приложенийперед веб-приложением и настройте ALB так, чтобы он требовалАутентификация Cognito. Только аутентифицированные пользователи пройдут через ALB в ваше веб-приложение — проблема решена. Cognito может иметь локальных пользователей или может использоваться вместе с вашим Azure AD или если вы используете Office365 в своей организации. Это довольно прозрачный способ, не требующий никаких изменений в приложении.
В качестве альтернативы, если ваше веб-приложение поддерживает эту функцию, вам следует настроить его так, чтобы оно требовало аутентификации SAML для любого каталога пользователей, который используется в вашей организации — Office365, G-Suite и т. д.
Надеюсь, это поможет :)
решение2
Вариант 5 — прекратить управление группами безопасности (по сути, межсетевыми экранами на основе IP) и использовать клиентские сертификаты TLS.
Если вы используете современные системы управления пользователями, такие как Azure AD или LDAP, у вас уже есть правильный инструмент для выпуска и распространения сертификатов. Вы настроите частный CA и настроите HTTP-сервер (Nginx, Apache2 или AWS ALB) для аутентификации по сертификатам. Тот, у кого нет сертификата или есть недействительный сертификат (включая просроченные), не сможет пройти через HTTP-сервер. Для этого требуетсянульвнести изменения в само веб-приложение, и вы даже можете отказаться от любой аутентификации в приложении, поскольку сертификаты могут служить этой цели в дополнение к контролю доступа.
Бонус в том, что это работает.повсюду- будь то AWS, Azure или ваша локальная инфраструктура. Вы даже можете повторно использовать тот же самый стек учетных данных и конфигурацию (за исключением AWS ALB) без проблем.