Текущая инфраструктура содержит два сервера, расположенных в Amazon EC2: сервер приложений и сервер MySQL.
Забота: безопасность связи между сервером приложений и базой данных без снижения производительности.
Текущая настройка: сервер MySQL имеет эластичный IP-адрес, который приложение использует для подключения к серверу. Причина в том, что внутренний IP меняется при перезагрузке, а эластичный остается постоянным. Соединение в MySQL защищено брандмауэром от сервера приложений, а в самом MySQL пользователю назначен IP-адрес сервера приложений.
В идеале мы хотим, чтобы два сервера обменивались данными с использованием внутренних IP-адресов. Мы бы предпочли не реализовывать связь через SSL по соображениям производительности.
Вопросы:
Прав ли я в том, что атака «человек посередине» возможна, потому что связь происходит по сети, которая использует эластичные IP-адреса?
Насколько сильно снизится производительность при реализации связи SSL между двумя серверами?
Есть ли альтернатива, помимо настраиваемых сценариев, для работы с изменениями внутреннего IP-адреса?
Без SSL может ли атака типа «злоумышленник посередине» происходить по внутренней сети от соседа EC2?
Использование VPC решит множество ваших проблем, поскольку частные IP-адреса там будут статическими. Amazon настоятельно рекомендует людям переходить на VPC по подобным причинам. Если у вас есть один, ваши две системы должны иметь возможность взаимодействовать по внутренней сети AWS.
Чтобы ответить на ваш вопрос об экспозиции по маршруту aws-public <---> aws-public, он теоретически раскрыт. Однако все это, скорее всего, происходит через внутреннюю коммутационную матрицу Amazon, поэтому уязвимость для злоумышленников, вероятно, такая же, как и для маршрутизации только внутреннего трафика.
Так как рекомендуется в ответе sysadmin1138, именно в таких ситуациях VPC были добавлены в Amazon Web Services: чтобы вы могли иметь частную интрасеть между инстансами EC2. На мой взгляд, это Первая часть решения: поместите сервер базы данных в VPC с сервером приложений и разрешите доступ к серверу базы данных только из внутренней (не выходящей в Интернет) сети и отклоните доступ к TCP 3306 из внешней (выходящей в Интернет) сети.
Второй шаг - «да, вы должны использовать SSL, и нет, затраты на производительность не очень значительны». Вы конечно можете тест подключения к вашей базе данных через SSL вместо обычного текста, но накладные расходы в лучшем случае будут относительно небольшими. Фактическая стоимость вашей производительности будет зависеть от использования.
Ваше приложение:
Лично, если у меня есть возможность использовать SSL, я использую SSL. Использование 2048-битных ключей RSA по сравнению с 4096-битными ключами RSA может ускорить начальное время установления связи, а также обрезать список шифров до ускорить время до первого байта; вам нужно будет проверить, какие у вас есть варианты для MySQL.
На заметку о безопасности: использовать шифры с PFS и не используйте SSLv3; используйте только TLSv1.2, если можете (например, если вы используете MySQL / SSL версии более поздней, чем 2008). Я не уверен, насколько MySQL позволяет вам это настраивать.
TL; DR: Предоставляйте серверу приложений доступ только к порту MySQL через внутреннюю сеть VPC, определенно используйте SSL, но проверьте его, если вас беспокоит скорость и вы не используете соединения повторно.