Я прочитал несколько постов о том, что происходит за кулисами обработки веб-запроса, что также является популярным вопросом на собеседовании для SRE/DevOps. Есть много хороших страниц с объяснениями об общем потоке этого: разрешение DNS -> соединение TCP -> соединение SSL -> запрос HTTPS -> балансировщик нагрузки -> брандмауэр -> веб-сервер, а оттуда запрос возвращается обратно.
Но я не смог найти ответ на некоторые сомнения за кулисами на стороне сервера, особенно для облака. Например, что происходит, когда запрос достигает глобального балансировщика нагрузки? Он завершает SSL там или переходит на внутренний балансировщик нагрузки (если настроен) и завершается там? Оттуда запрос к конкретной виртуальной машине небезопасен, где есть другие поставщики, также размещающие свои виртуальные машины и внутренний балансировщик нагрузки. Защищен ли запрос с помощью каких-либо ACL/брандмауэра или какого-либо внутреннего механизма VPC?
Я понимаю, что мы можем повторно зашифровать или переслать зашифрованный трафик на веб-сервер для лучшей безопасности, но высокой стоимости ресурсов. Но что происходит, когда мы этого не делаем? Я чувствую, что все равно будет использоваться какой-то другой механизм безопасности, чтобы избежать легкого доступа.
Заранее спасибо.
решение1
Жду комментария:
Подобные вопросы на собеседовании — это не школьные экзамены по естествознанию, где возможен только один правильный ответ, и не стоит ожидать, что вы сможете"проходить"просто повторяя ответы, найденные на случайных интернет-платформах. И обычно вы не «проваливаете» из-за того, что пропускаете что-то, что вам неинтересно или с чем вы не знакомы (если только это не конкретные требования к работе).
Мой коллега делает свои собственные клавиатуры и был бы в восторге, если бы вы начали свою цепочку событий с электрических сигналов, которые генерируются при нажатии клавиши на вашей клавиатуре. Мне все равно.
Если бы вы проходили собеседование со мной, ваш ответ был бы достаточно хорош, чтобы не быть немедленно дисквалифицированным (но я тоже недостаточно разбираюсь, например, в спецификации DNSSEC, чтобы немедленно бросить вам вызов на самом первом этапе цепочки событий, которую вы описываете), но меня бы зацепило ваше замечание:«зашифрованный трафик для лучшей безопасности, но с высокими затратами ресурсов»как это часто говорят иУ меня лично есть сомненияотносительно правдивости этого утверждения.
Что касается проектирования безопасности и компромиссов безопасности, меры, которые вы хотите разработать, являются ответом на фактические и предполагаемые угрозы, определенные в анализе рисков и их соотношении затрат и выгод.
Эти риски не являются универсальной истиной (хотя некоторые из них очень распространены), они различаются от компании к компании, и часто риски меняются в зависимости от уже реализованных мер.
В реальной жизни вы увидите, как общие шаблоны проектирования реализуются по-разному в зависимости от разных обстоятельств. Как реализовать балансировку нагрузки и где завершить TLS, тоже является одной из этих вещей. В качестве прощальной мысли:«Вам все еще нужен HTTPS, если вы используете IPSEC?»