Подключение вверх (к облачным службам): мнение одного архитектора

Статья
07/16/2023

В этой статье Эд Фишер (Ed Fisher), архитектор безопасности & соответствия требованиям корпорации Майкрософт, описывает, как оптимизировать сеть для подключения к облаку, избегая наиболее распространенных ошибок.

Об авторе

Снимок экрана: фотография Эда Фишера.

В настоящее время я главный технический специалист в нашей команде по розничной торговле и потребительским товарам, уделяя особое внимание обеспечению безопасности & соответствия требованиям. Я работал с клиентами, переезжающими в Office 365 в течение последних десяти лет. Я работал с небольшими магазинами с несколькими расположениями для государственных учреждений и предприятий с миллионами пользователей, распределенных по всему миру, и многие другие клиенты между ними, большинство из которых имеют десятки тысяч пользователей, несколько расположений в разных частях мира, потребность в более высокой степени безопасности и множество требований к соответствию. Я помог сотням предприятий и миллионам пользователей безопасно и безопасно перейти в облако.

Имея опыт в течение последних 25 лет, который включает в себя безопасность, инфраструктуру и сетевую инженерию, и переведя двух моих предыдущих работодателей в Office 365, прежде чем присоединиться к Корпорации Майкрософт, я был на вашей стороне стола много раз, и помню, что это такое. Хотя два клиента никогда не совпадают, большинство из них имеют одинаковые потребности, и при использовании стандартизированной службы, такой как любая платформа SaaS или PaaS, лучшие подходы, как правило, одинаковы.

Это не сеть — это то, как вы (неправильно) используете его!

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

Когда такого рода вещи обостряются для меня, я обычно готов принять вызов и провести их через то, как и почему и заставить их там, где они должны быть. Но если я полностью откровенный, я должен поделиться, что иногда я хочу просто позволить им делать то, что они будут, и вернуться, чтобы сказать, что я сказал вам так, когда они, наконец, признают, что это не работает. Я, возможно, захотеть сделать это иногда, но я нет. То, что я делаю, это попытаться объяснить все, что я собираюсь включить в этот пост. Независимо от вашей роли, если ваша организация хочет использовать облачные службы Майкрософт, вероятно, есть определенная мудрость в том, что может помочь вам.

Руководящие принципы

Давайте начнем с некоторых наземных правил вокруг того, что мы здесь делаем. Мы обсуждаем, как безопасно подключиться к облачным службам, чтобы обеспечить минимальную сложность и максимальную производительность при сохранении реальной безопасности. Ни одно из следующих действий не противоречит этому, даже если вы или ваш клиент не сможете использовать ваш любимый прокси-сервер для всего.

Просто потому, что вы можете, не означает, что вы должны: Или перефразировать д-р Ян Малкольм из фильма "... Да, да, но ваша команда безопасности была настолько озабочена вопросом, могут ли они или нет, что они не перестают думать, если они должны".
Безопасность не означает сложность. Вы не более безопасны только потому, что тратите больше денег, маршрутизируете через больше устройств или нажимаете больше кнопок.
Office 365 доступ осуществляется через Интернет: Но это не то же самое, что Office 365 является Интернетом. Это служба SaaS, управляемая корпорацией Майкрософт и администрируемая вами. В отличие от веб-сайтов, которые вы посещаете в Интернете, вы на самом деле заглядываете за занавес, и можете применять элементы управления, необходимые для соблюдения ваших политик и стандартов соответствия, если вы понимаете, что, хотя вы можете достичь своих целей, вам, возможно, просто придется делать их другим способом.
Chokepoints плохие, локализованные прорывы хороши: Все всегда хотят вернуть весь свой интернет-трафик для всех своих пользователей в какую-то центральную точку, как правило, чтобы они могли отслеживать его и применять политику, но часто потому, что это либо дешевле, чем подготовка доступа к Интернету во всех своих местах, либо это просто, как они это делают. Но эти дроссельные точки именно то, что ... точки, в которых трафик задыхается. Нет ничего плохого в том, чтобы запретить пользователям переходить в Instagram или потоковой передачи кошачьих видео, но не относитесь к трафику критически важных бизнес-приложений таким же образом.
Если DNS не устраивает, то нет ничего счастливого: лучше всего спроектированная сеть может быть подколена плохой DNS, будь то путем рекурсии запросов к серверам в других регионах мира или использования DNS-серверов вашего поставщика услуг Интернета или других общедоступных DNS-серверов, которые кэшируют сведения о разрешении DNS.
Просто потому, что вы привыкли делать это, не означает, что это то, как вы должны делать это сейчас: технология постоянно меняется, и Office 365 не является исключением. Применение мер безопасности, которые были разработаны и развернуты для локальных служб или для управления веб-серфингом, не обеспечит тот же уровень безопасности и может оказать значительное негативное влияние на производительность.
Office 365 был создан для доступа через Интернет: это в двух словах. Независимо от того, что вы хотите сделать между вашими пользователями и вашим краем, трафик по-прежнему идет через Интернет, как только он покидает вашу сеть и до того, как он попадает на нашу. Даже если вы используете Azure ExpressRoute для маршрутизации трафика с учетом задержки непосредственно в нашу сеть, подключение к Интернету обязательно. Примите его. Не передумай.

Где часто делается неправильный выбор

Хотя есть много мест, где плохие решения принимаются во имя безопасности, это те, которые я встречаю чаще всего с клиентами. Многие беседы клиентов включают все сразу.

Недостаточно ресурсов на границе

Очень немногие клиенты развертывают среды greenfield, и у них есть многолетний опыт работы своих пользователей и того, как их исходящий интернет-трафик. Независимо от того, имеют ли клиенты прокси-серверы или разрешают прямой доступ и просто исходящий трафик NAT, они делают это в течение многих лет и не учитывают, сколько еще они собираются начать прокачивать через свои границы, когда они традиционно перемещают внутренние приложения в облако.

Пропускная способность всегда является проблемой, но устройства NAT могут не иметь достаточно лошадиных сил для обработки повышенной нагрузки и могут начать преждевременно закрывать подключения для освобождения ресурсов. Большая часть клиентского программного обеспечения, подключающегося к Office 365, ожидает постоянных подключений, и пользователь, полностью используюющий Office 365, может иметь 32 или более одновременных подключений. Если устройство NAT преждевременно удаляет их, эти приложения могут перестать отвечать, так как они пытаются использовать подключения, которые больше не существуют. Когда они сдаются и пытаются установить новые подключения, они кладут еще большую нагрузку на ваше сетевое снаряжение.

Локализованный прорыв

Все остальное в этом списке сводится к одному - выйти из вашей сети и на наш как можно быстрее. Обратная маршрутизация трафика пользователей в центральную точку исходящего трафика, особенно если эта точка исходящего трафика находится в другом регионе, чем пользователи, создает ненужную задержку и влияет как на взаимодействие с клиентом, так и на скорость загрузки. Корпорация Майкрософт имеет точки присутствия по всему миру с интерфейсами для всех наших служб и пиринга, созданными практически с каждым крупным поставщиком услуг Интернета, поэтому маршрутизация трафика ваших пользователей локально гарантирует, что он быстро попадает в нашу сеть с минимальной задержкой.

Трафик разрешения DNS должен следовать пути исходящего трафика через Интернет

Конечно, чтобы клиент нашел любую конечную точку, он должен использовать DNS. DNS-серверы Майкрософт оценивают источник DNS-запросов, чтобы убедиться, что мы возвращаем ответ, который, с точки зрения Интернета, ближе всего к источнику запроса. Убедитесь, что служба DNS настроена таким образом, чтобы запросы на разрешение имен выходили по тому же пути, что и трафик пользователей, чтобы не передать их локальный исходящий трафик, но в конечную точку в другом регионе. Это означает, что локальные DNS-серверы должны "переходить в корневой каталог", а не перенаправляться на DNS-серверы в удаленных центрах обработки данных. И watch для общедоступных и частных служб DNS, которые могут кэшировать результаты из одной части мира и обслуживать их для запросов из других частей мира.

Прокси-сервер или не прокси-сервер, вот вопрос

В первую очередь следует рассмотреть вопрос о том, следует ли использовать прокси-сервер для подключений пользователей к Office 365. Это легко; не прокси-сервер. доступ к Office 365 осуществляется через Интернет, но не через Интернет. Это расширение основных служб, и его следует рассматривать как таковой. Все, что может потребоваться от прокси-сервера, например защита от потери данных, защита от вредоносных программ или проверка содержимого, уже доступно в службе и может использоваться в большом масштабе и без необходимости взлома подключений, зашифрованных TLS. Но если вы действительно хотите прокси-трафик, который вы не можете контролировать другим способом, обратите внимание на наше руководство по адресу https://aka.ms/pnc и категории трафика по адресу https://aka.ms/ipaddrs. У нас есть три категории трафика для Office 365. Оптимизация и разрешение действительно должны идти напрямую и обходить прокси-сервер. По умолчанию можно использовать прокси-сервер. Подробные сведения приведены в этих документах... читать их.

Большинство клиентов, которые настаивают на использовании прокси-сервера, когда они на самом деле смотрят на то, что они делают, понимают, что когда клиент делает запрос HTTP CONNECT к прокси-серверу, прокси-сервер теперь является просто дорогим дополнительным маршрутизатором. Используемые протоколы, такие как MAPI и RTC, даже не являются протоколами, которые понимают веб-прокси, поэтому даже при взломе TLS вы не получаете никакой дополнительной безопасности. Вы* получаете дополнительную задержку. Дополнительные сведения https://aka.ms/pnc см. в разделе Оптимизация, Разрешение и По умолчанию для трафика Microsoft 365.

Наконец, рассмотрите общее влияние на прокси-сервер и его соответствующий ответ, чтобы справиться с этим воздействием. По мере того как через прокси-сервер выполняется все больше подключений, он может уменьшить коэффициент масштабирования TCP, чтобы ему не нужно было буферизировать так много трафика. Я видел клиентов, где их прокси-серверы были настолько перегружены, что они использовали коэффициент масштабирования 0. Так как коэффициент масштабирования является экспоненциальным значением, и мы хотели бы использовать значение 8, каждое сокращение значения коэффициента масштабирования оказывает огромное негативное влияние на пропускную способность.

Проверка TLS означает БЕЗОПАСНОСТЬ! Но не совсем! Многие клиенты с прокси-серверами хотят использовать их для проверки всего трафика, и это означает, что TLS "прерывает и проверяет". Когда вы делаете это для веб-сайта, доступ к которому выполняется через HTTPS (невзирая на вопросы конфиденциальности), прокси-серверу может потребоваться сделать это для 10 или даже 20 параллельных потоков в течение нескольких сотен миллисекунда. Если есть большое скачивание или, возможно, видео, одно или несколько из этих подключений может длиться гораздо дольше, но в целом большинство из этих подключений устанавливаются, передаются и закрываются очень быстро. Выполнение перерыва и проверки означает, что прокси-сервер должен удвоить работу. Для каждого подключения клиента к прокси-серверу прокси-сервер также должен установить отдельное подключение к конечной точке. Итак, 1 становится 2, 2 становится 4, 32 становится 64... видеть, куда я иду? Вы, вероятно, размер прокси-решения просто отлично подходит для типичного веб-серфинга, но когда вы пытаетесь сделать то же самое для клиентских подключений к Office 365, количество одновременных, долгоживущие подключения может быть на порядок больше, чем вы размер для.

Потоковая передача не важна, за исключением того, что она

Единственными службами в Office 365, которые используют UDP, являются Skype (скоро будет прекращена) и Microsoft Teams. Teams использует UDP для потоковой передачи трафика, включая аудио, видео и общий доступ к презентациям. Потоковый трафик осуществляется в реальном времени, например, когда вы проводите онлайн-собрание с голосом, видео и презентацией или выполняете демонстрации. Они используют UDP, так как если пакеты удаляются или приходят из строя, это практически незаметно для пользователя, и поток может просто продолжаться.

Если вы не разрешаете исходящий трафик UDP от клиентов к службе, они могут вернуться к использованию TCP. Но если TCP-пакет удаляется, все останавливается до тех пор, пока не истечет время ожидания повторной передачи (RTO) и отсутствующий пакет можно будет повторно отправить. Если пакет поступает не по порядку, все останавливается до тех пор, пока не поступят другие пакеты, и его можно будет повторно выполнить по порядку. Оба привести к ощутимым сбоям в аудио (помните Макс Headroom?) и видео (вы что-то щелкнуть... oh, там это) и привести к плохой производительности и плохому взаимодействию с пользователем. И помните, что я поставил выше о прокси-сервере? При принудительном использовании прокси-сервера клиент Teams принудительно использует TCP. Теперь вы дважды оказываете негативное влияние на производительность.

Разделение туннелирования может показаться страшным

Но это не так. Все подключения к Office 365 выполняются по протоколу TLS. Мы уже давно предлагаем TLS 1.2 и скоро отключим старые версии, так как устаревшие клиенты по-прежнему используют их, и это риск.

Принудительное подключение TLS (или 32 из них) к vpn-подключению, прежде чем они переходят к службе, не добавляет безопасности. Это увеличивает задержку и снижает общую пропускную способность. В некоторых решениях VPN он даже заставляет UDP туннелировать через TCP, что опять же окажет очень негативное влияние на потоковый трафик. И, если вы не делаете проверку TLS, нет никакой обратной стороны, все недостатки. Очень распространенной темой среди клиентов, теперь, когда большая часть их сотрудников является удаленной, является то, что они видят значительное влияние на пропускную способность и производительность от того, что все их пользователи подключаются с помощью VPN вместо настройки разделенного туннелирования для доступа к оптимизации категории Office 365 конечных точек.

Это простое исправление, чтобы сделать разделение туннелирования, и это то, что вы должны сделать. Дополнительные сведения см. в статье Оптимизация подключения Office 365 для удаленных пользователей с помощью раздельного туннелирования VPN.

Грехи прошлого

Во многих случаях причиной неправильного выбора является сочетание (1) не зная, как работает служба, (2) попытка придерживаться политик компании, которые были написаны до внедрения облака, и (3) команды безопасности, которые не могут быть уверены в том, что существует несколько способов достижения своих целей. Надеюсь, выше, и ссылки ниже, помогут с первым. Исполнительное спонсорство может потребоваться, чтобы пройти мимо второго. Решение задач политик безопасности, а не их методов, помогает в третьем. От условного доступа к модерации содержимого, защиты от потери данных и защиты информации, проверки конечных точек до угроз нулевого дня — любая конечная цель, которую может иметь разумная политика безопасности, может быть достигнута с помощью доступных в Office 365, без зависимости от локального сетевого оборудования, принудительных VPN-туннелей, прерывания и проверки TLS.

В других случаях оборудование, которое было приобретено до того, как организация начала переходить в облако, просто не может быть масштабировано для обработки новых шаблонов трафика и нагрузок. Если вам действительно нужно направить весь трафик через одну точку исходящего трафика и (или) прокси-сервер, будьте готовы соответствующим образом обновить сетевое оборудование и пропускную способность. Тщательно отслеживайте использование в обоих вариантах, так как взаимодействие не будет уменьшаться медленно по мере подключения большего количество пользователей. Все в порядке, пока не достигнут переломный момент, потом все страдают.

Исключения из правил

Если в вашей организации требуются ограничения клиента, вам потребуется использовать прокси-сервер с прерыванием TLS и проверить, чтобы принудительно использовать трафик через прокси-сервер, но вам не придется принудительно использовать весь трафик через него. Это не все или ничего предложение, поэтому обратите внимание на то, что нужно изменить прокси-сервером.

Если вы собираетесь разрешить раздельное туннелирование, но также использовать прокси-сервер для общего веб-трафика, убедитесь, что pac-файл определяет, что должно идти напрямую, а также определяет, как вы определяете интересный трафик для того, что проходит через VPN-туннель. Мы предлагаем примеры PAC-файлов, https://aka.ms/ipaddrs которые упрощают управление ими.

Заключение

Десятки тысяч организаций, включая почти все из списка Fortune 500, ежедневно используют Office 365 для выполнения своих критически важных функций. Они делают это безопасно, и они делают это через Интернет.

Независимо от того, какие цели безопасности у вас есть в игре, есть способы их выполнения, которые не требуют VPN-подключений, прокси-серверов, прерывания и проверки TLS, или централизованного исходящего трафика через Интернет, чтобы трафик ваших пользователей из вашей сети и дальше в нашу как можно быстрее, что обеспечивает наилучшую производительность, независимо от того, является ли ваша сеть штаб-квартирой компании. удаленный офис или пользователь, работающий дома. Наше руководство основано на том, как создаются службы Office 365 и обеспечивают безопасное и производительное взаимодействие с пользователем.