Поделиться через

Руководство по доверенным подключениям к Интернету

В этой статье объясняется, как использовать функции безопасности в облачных службах Azure для обеспечения соответствия требованиям инициативы "Доверенные подключения к Интернету" (TIC). Он применяется как к средам облачных служб Azure, так и к Azure для правительственных организаций, и охватывает последствия TIC для моделей облачных служб инфраструктуры как услуга (IaaS) и платформы как услуга (PaaS) в Azure.

Обзор доверенных подключений к Интернету

Цель инициативы TIC заключается в повышении сетевой безопасности в федеральном правительстве США. Эта цель изначально была реализована путем консолидации внешних подключений и маршрутизации всего сетевого трафика через утвержденные устройства в точках доступа TIC. В последующие годы облачные вычисления прочно закрепились, прокладывая путь для современных систем безопасности и ухода от основного фокуса на безопасности периметра. Соответственно, инициатива TIC развивалась, чтобы обеспечить федеральные учреждения с повышенной гибкостью для использования современных возможностей безопасности.

Руководство по TIC 2.0

Первоначально инициатива TIC была описана в Меморандуме M-08-05 Офиса по управлению и бюджету (OMB), опубликованном в ноябре 2007 года, и в этой статье она упоминается как руководство по TIC 2.0. Программа TIC была создана для улучшения функций безопасности периметра федеральной сети и реагирования на инциденты. TIC изначально был разработан для выполнения сетевого анализа всего входящего и исходящего трафика gov. Цель заключалась в выявлении конкретных шаблонов в потоках сетевых данных и выявлении аномалий поведения, таких как активность ботнета. Учреждения были уполномочены консолидировать свои внешние сетевые подключения и направлять весь трафик через устройства обнаружения и предотвращения вторжений, известные как ЭЙНШТЕЙН. Устройства размещаются в ограниченном количестве сетевых конечных точек, которые называются доверенными интернет-подключениями.

Цель TIC заключается в том, чтобы учреждения знали:

  • Кто находится в моей сети (авторизованной или несанкционированной)?
  • Когда осуществляется доступ к сети и почему?
  • Какие ресурсы доступны?

В соответствии с TIC 2.0 все внешние подключения агентства должны направляться через утвержденный OMB TIC. Федеральные учреждения должны участвовать в программе TIC в качестве поставщика доступа TIC (TICAP) или контрактировать услуги с одним из основных поставщиков услуг Интернета уровня 1. Эти поставщики называются поставщиками управляемой доверенной службы протокола Интернета (MTIPS). TIC 2.0 включает обязательные критические возможности, выполняемые агентством и поставщиком MTIPS. В TIC 2.0 устройства обнаружения вторжений EINSTEIN версии 2 и ускоренные устройства предотвращения вторжений EINSTEIN версии 3 (3A) развертываются в каждом центре TICAP и MTIPS. Агентство устанавливает меморандум о понимании с Министерством национальной безопасности (DHS) для развертывания возможностей ЭЙНШТЕЙН в федеральных системах.

В рамках ответственности за защиту сети .gov Министерство внутренней безопасности требует предоставления необработанных потоков сетевых данных агентств для сопоставления инцидентов по всем федеральным системам и выполнения анализа с помощью специализированных инструментов. Маршрутизаторы DHS позволяют собирать сетевой трафик IP при его входе или выходе из интерфейса. Администраторы сети могут анализировать данные сетевого потока, чтобы определить источник и назначение трафика, класс службы и другие параметры. Чистые данные потока считаются "неконтентными" данными, похожими на заголовок, исходный IP-адрес, IP-адрес назначения и т. д. Данные, отличные от содержимого, позволяют DHS узнать о содержимом: кто делает то, что и сколько времени.

Инициатива TIC 2.0 также включает политики безопасности, рекомендации и платформы, которые предполагают локальную инфраструктуру. Государственные учреждения переходят в облако, чтобы добиться экономии затрат, эффективности работы и инноваций. Однако требования к реализации TIC 2.0 могут замедлить сетевой трафик. Скорость и гибкость, с помощью которой пользователи государственных организаций могут получить доступ к своим облачным данным, ограничен в результате.

Руководство по TIC 3.0

В сентябре 2019 года OMB выпустила меморандум M-19-26, который отменил предыдущие меморандумы, связанные с TIC, и представил руководство по TIC 3.0. Предыдущие меморандумы OMB требуют передачи трафика агентства через физическую точку доступа TIC, которая, как оказалось, является препятствием для внедрения облачной инфраструктуры. Например, TIC 2.0 ориентирован исключительно на безопасность периметра путем канала всех входящих и исходящих данных агентства через точку доступа TIC. В отличие от этого, TIC 3.0 признает необходимость учета нескольких и разнообразных архитектур безопасности, а не единого подхода к безопасности периметра. Эта гибкость позволяет агентствам выбирать, как реализовать возможности безопасности таким образом, чтобы лучше всего соответствовать их общей сетевой архитектуре, подходу к управлению рисками и многое другое.

Чтобы обеспечить эту гибкость, Агентство по кибербезопасности и безопасности инфраструктуры (CISA) работает с федеральными агентствами для проведения пилотов в различных средах агентства, что приводит к разработке вариантов использования TIC 3.0. Для реализации TIC 3.0 CISA призывает агентства использовать основные документы по обеспечению безопасности и конфиденциальности TIC 3.0 с Национальным институтом стандартов и технологий (NIST) Cybersecurity Framework (CSF) и NIST SP 800-53Системы безопасности и конфиденциальности для федеральных информационных систем и организаций. Эти документы могут помочь агентствам разработать безопасную сетевую архитектуру и определить соответствующие требования от поставщиков облачных служб.

TIC 3.0 дополняет другие федеральные инициативы, ориентированные на внедрение облака, таких как Федеральная программа управления рисками и авторизацией (FedRAMP), которая основана на стандарте NIST SP 800-53, дополненных средствами управления FedRAMP и улучшениями контроля. Агентства могут использовать существующие авторизации для работы в Azure и Azure Government FedRAMP High, временные разрешения (P-ATO), выданные Совместным советом авторизации FedRAMP. Они также могут использовать поддержку Azure и Azure Government для NIST CSF. Чтобы помочь агентствам с реализацией TIC 3.0 при выборе облачных возможностей безопасности, CISA сопоставил возможности TIC с NIST CSF и NIST SP 800-53. Например, цели безопасности TIC 3.0 можно сопоставить с пятью функциями NIST CSF, включая определение, защиту, обнаружение, реагирование и восстановление. Возможности безопасности TIC сопоставляются с NIST CSF в каталоге возможностей безопасности TIC 3.0, доступном из основных документов руководства TIC 3.0.

TIC 3.0 — это неописующее руководство по кибербезопасности, разработанное для обеспечения гибкости для реализации возможностей безопасности, соответствующих определенным уровням допустимости рисков. В то время как руководство требует, чтобы учреждения соответствовали всем применимым требованиям телеметрии, таким как Национальная система защиты кибербезопасности (NCPS) и непрерывная диагностика и устранение рисков (CDM), TIC 3.0 в настоящее время требует, чтобы учреждения самоотверяли о своем соблюдении рекомендаций по TIC.

С помощью TIC 3.0 агентства могут поддерживать устаревшую реализацию TIC 2.0, которая использует точки доступа TIC при внедрении возможностей TIC 3.0. CISA предоставил руководство по реализации традиционной модели TIC в TIC 3.0, известной как традиционный вариант использования TIC.

Остальная часть этой статьи содержит рекомендации, относящиеся к возможностям Azure, необходимым для устаревших реализаций TIC 2.0; однако некоторые из этих рекомендаций также полезны для требований TIC 3.0.

Параметры сети Azure

Существует четыре основных варианта подключения к службам Azure:

  • Прямое подключение к Интернету — подключение к службам Azure непосредственно через открытое подключение к Интернету. Среда и подключение являются общедоступными. Шифрование на уровне приложения и транспорта зависит от обеспечения защиты данных. Пропускная способность ограничена подключением сайта к Интернету. Используйте несколько активных поставщиков для обеспечения устойчивости.
  • Виртуальная частная сеть (VPN) — подключение к виртуальной сети Azure в частном порядке с помощью VPN-шлюза. Среда является общедоступной, так как она проходит через стандартное подключение к Интернету сайта, но подключение шифруется в туннеле, чтобы обеспечить защиту данных. Пропускная способность ограничена в зависимости от VPN-устройств и выбранной конфигурации. Подключения типа "точка — сеть" Azure обычно ограничены 100 Мбит/с. Подключения типа "сеть — сеть" варьируются от 100 Мбит/с до 10 Гбит/с.
  • Azure ExpressRoute — ExpressRoute — это прямое подключение к службам Майкрософт. ExpressRoute использует поставщика на узле пиринга для подключения к граничным маршрутизаторам Microsoft Enterprise. ExpressRoute использует различные типы пиринга для служб IaaS и PaaS/SaaS, частного пиринга и пиринга Майкрософт. Пропускная способность составляет от 50 Мбит/с до 10 Гбит/с.
  • Azure ExpressRoute Direct — ExpressRoute Direct позволяет напрямую подключаться к периферийным маршрутизаторам Microsoft Enterprise на точке пиринга. ExpressRoute Direct удаляет провайдера подключения третьей стороны из необходимых шагов маршрута. Пропускная способность составляет от 10 Гбит/с до 100 Гбит/с.

Чтобы включить подключение от агентства к Azure или Microsoft 365 без маршрутизации трафика через агентство TIC, агентство должно использовать следующее:

  • Зашифрованный туннель или
  • Выделенное подключение к поставщику облачных служб (CSP).

Службы CSP могут гарантировать, что подключение к облачным ресурсам агентства не предлагается через общедоступный Интернет для прямого доступа персонала агентства.

Только для Azure второй вариант (VPN) и третий вариант (ExpressRoute) могут соответствовать этим требованиям, если они используются со службами, которые ограничивают доступ к Интернету.

Microsoft 365 соответствует рекомендациям по TIC, используя ExpressRoute с включенным пирингом Майкрософт или подключение к Интернету, которое шифрует весь трафик с помощью TLS 1.2. Пользователи конечных точек в агентской сети могут подключаться к сети и инфраструктуре TIC своего агентства через Интернет. Все удаленные интернет-доступы к Microsoft 365 заблокированы и перенаправляются через агентство.

Параметры сети Azure для соответствия требованиям TIC

Предложения IaaS Azure

Соответствие политике TIC с помощью Azure IaaS является относительно простым, так как клиенты Azure управляют собственной маршрутизацией виртуальной сети.

Основное требование обеспечить соответствие эталонной архитектуре TIC 2.0 заключается в том, чтобы ваша виртуальная сеть была частным расширением сети агентства. Чтобы расширение было частным, политика требует, чтобы никакой трафик не покидал вашу сеть, за исключением подключения к сетевому соединению TIC на территории. Этот процесс называется принудительным туннелированием. Для соответствия требованиям TIC 2.0 процесс направляет весь трафик из любой системы в среде CSP через локальный шлюз в сети организации через Интернет через TIC.

Соответствие Azure IaaS TIC разделяется на два основных этапа.

  • Шаг 1. Настройка
  • Шаг 2. Аудит

Соответствие Azure IaaS с TIC: конфигурация

Чтобы настроить архитектуру, совместимую с TIC, в Azure сначала необходимо запретить прямой доступ к Интернету к виртуальной сети, а затем принудительно использовать интернет-трафик через локальную сеть.

Запрет прямого доступа к Интернету

Сеть IaaS Azure проводится через виртуальные сети, состоящие из подсетей, с которыми связаны сетевые карты виртуальных машин.

Самый простой сценарий поддержки соответствия TIC заключается в том, чтобы убедиться, что виртуальная машина или коллекция виртуальных машин не может подключаться к внешним ресурсам. Вы можете обеспечить отключение от внешних сетей с помощью групп безопасности сети. Используйте группы безопасности сети для управления трафиком для одного или нескольких сетевых адаптеров или подсетей в вашей виртуальной сети. Группа безопасности сети содержит правила управления доступом, которые разрешают или запрещают трафик на основе направления трафика, протокола, исходного адреса и порта, а также адреса назначения и порта. Правила группы безопасности сети можно изменять в любое время, и изменения будут применены ко всем связанным экземплярам. Дополнительные сведения о создании группы безопасности сети см. в разделе "Фильтрация сетевого трафика" с помощью группы безопасности сети.

Принудительное подключение к Интернету через локальную сеть

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

  • Трафик, предназначенный для виртуальной сети, остается в виртуальной сети.
  • Назначенные Органом по присвоению номеров в Интернете (IANA) частные адресные пространства, такие как 10.0.0.0/8, удаляются, если они не включены в адресное пространство виртуальной сети.
  • Последняя маршрутизация 0.0.0.0/0/0 в конечную точку Интернета виртуальной сети.

Принудительное туннелирование TIC

Весь трафик, который покидает виртуальную сеть, должен направляться через локальное подключение, чтобы убедиться, что весь трафик проходит через агентство TIC. Вы создаете пользовательские маршруты, создавая определяемые пользователем маршруты или обмениваясь маршрутами протокола BGP между локальным сетевым шлюзом и VPN-шлюзом Azure.

Добавление определяемых пользователем маршрутов

При использовании шлюза виртуальной сети на основе маршрутов можно использовать принудительное туннелирование в Azure. Добавьте определяемый пользователем маршрут, который задает маршрутизацию трафика с 0.0.0.0/0 в следующий узел вашего шлюза виртуальной сети. Azure отдает приоритет маршрутам, определяемым пользователем, над системными маршрутами. Весь трафик, отличный от виртуальной сети, отправляется в шлюз виртуальной сети, который затем может направлять трафик в локальную среду. После определения определяемого пользователем маршрута свяжите маршрут с существующими подсетями или новыми подсетями во всех виртуальных сетях в среде Azure.

Определяемые пользователем маршруты и TIC

Использование протокола пограничного шлюза

Если вы используете ExpressRoute или шлюз виртуальной сети с поддержкой BGP, BGP является предпочтительным механизмом для рекламных маршрутов. Для объявленного маршрута BGP 0.0.0.0/0/0 шлюзы виртуальной сети с поддержкой BGP гарантируют, что маршрут по умолчанию применяется ко всем подсетям в виртуальных сетях.

Соответствие Azure IaaS TIC: аудит

Azure предлагает несколько способов аудита соответствия TIC.

Просмотр действующих маршрутов

Подтвердите распространение маршрутов по умолчанию, наблюдая за эффективными маршрутами для конкретной виртуальной машины, определенной сетевой карты или пользовательской таблицы маршрутов на портале Azure или в Azure PowerShell. Действующие маршруты отображают соответствующие определяемые пользователем маршруты, маршруты BGP и системные маршруты, применяемые к соответствующей сущности, как показано на следующем рисунке:

Действующие маршруты

Примечание.

Не удается просмотреть действующие маршруты для сетевого адаптера, если сетевой адаптер не связан с работающей виртуальной машиной.

Использование наблюдателя за сетями Azure

Наблюдатель за сетями предлагает несколько средств для аудита соответствия TIC. Дополнительные сведения см. в разделе "Наблюдатель за сетями Azure".

Захват журналов потоков группы безопасности сети

Используйте наблюдатель за сетями для записи журналов потоков сети, указывающих метаданные, которые окружают IP-трафик. Журналы потоков сети содержат исходные и целевые адреса целевых объектов и другие данные. Эти данные можно использовать с журналами из шлюза виртуальной сети, локальных пограничных устройств или инфраструктуры TIC, чтобы отслеживать, что весь трафик направляется вовнутрь.

Предложения Azure PaaS

Службы Azure PaaS, такие как служба хранилища Azure, доступны через URL-адрес, доступный в Интернете. Любой пользователь с утвержденными учетными данными может получить доступ к ресурсу, например учетной записи хранения, из любого расположения без обхода TIC. По этой причине многие клиенты государственных организаций неправильно заключают, что службы Azure PaaS не соответствуют политикам TIC 2.0. Однако многие службы Azure PaaS могут соответствовать политике TIC 2.0. Служба соответствует требованиям, если архитектура совпадает с средой IaaS, совместимой с TIC (как описано ранее), и служба подключена к виртуальной сети Azure.

При интеграции служб Azure PaaS с виртуальной сетью служба доступна из этой виртуальной сети в частном порядке. Вы можете применить пользовательскую маршрутизацию для 0.0.0.0/0 через определяемые пользователем маршруты или BGP. Настраиваемая маршрутизация гарантирует, что все маршруты трафика, привязанные к Интернету, проходят через TIC. Интеграция служб Azure в виртуальные сети с помощью следующих шаблонов:

  • Развертывание выделенного экземпляра службы — все большее число служб PaaS можно развертывать как выделенные экземпляры с конечными точками, подключенными к виртуальной сети, иногда называемыми внедрением виртуальной сети. Среду службы приложений можно развернуть в изолированном режиме , чтобы конечная точка сети была ограничена виртуальной сетью. Затем среда службы приложений может размещать множество служб PaaS Azure, таких как веб-приложения, управление API и функции. Дополнительные сведения см. в статье "Развертывание выделенных служб Azure в виртуальных сетях".
  • Используйте конечные точки службы виртуальной сети . Увеличение числа служб PaaS позволяет переместить конечную точку в частный IP-адрес виртуальной сети вместо общедоступного адреса. Дополнительные сведения см. в статье Конечные точки служб в виртуальной сети.
  • Используйте Приватный канал Azure. Предоставьте общую службу с частной конечной точкой в виртуальной сети. Трафик между виртуальной сетью и службой перемещается по магистральной сети Майкрософт и не проходит через общедоступный Интернет. Дополнительные сведения см. в разделе Приватный канал Azure.

Сведения об интеграции с виртуальной сетью

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

Параметры подключения PaaS для TIC

  1. Частное подключение выполняется в Azure с помощью ExpressRoute. Частный пиринг ExpressRoute с принудительным туннелированием используется для направления всего трафика виртуальной сети клиента через ExpressRoute и обратно в локальную сеть. Майкрософт пиринг не требуется.
  2. VPN-шлюз Azure при использовании с ExpressRoute и пирингом Microsoft может наложить сквозное шифрование IPsec между виртуальной сетью клиента и устройством на границе локальной сети.
  3. Сетевое подключение к виртуальной сети клиента контролируется с помощью групп безопасности сети, позволяющих клиентам разрешать или запрещать трафик на основе IP-адресов, портов и протоколов.
  4. Трафик к частной виртуальной сети клиента отслеживается с помощью наблюдателя за сетями Azure и анализируется с помощью Log Analytics и Microsoft Defender для облака.
  5. Виртуальная сеть клиента распространяется на службу PaaS, создавая конечную точку службы для службы клиента.
  6. Конечная точка службы PaaS защищена по умолчанию, чтобы запретить все и разрешить доступ только из указанных подсетей в виртуальной сети клиента. Защита ресурсов службы в виртуальной сети обеспечивает улучшенную безопасность путем полного удаления общедоступного доступа к интернету к ресурсам и разрешения трафика только из виртуальной сети.
  7. Другие службы Azure, которым требуется доступ к ресурсам в виртуальной сети клиента, должны быть:
    • Развернуто непосредственно в виртуальной сети или
    • Разрешено выборочно на основе рекомендаций соответствующей службы Azure.

Вариант A. Развертывание выделенного экземпляра службы (внедрение виртуальной сети)

Внедрение виртуальной сети позволяет клиентам выборочно развертывать выделенные экземпляры данной службы Azure, например HDInsight, в собственную виртуальную сеть. Экземпляры служб развертываются в выделенной подсети в виртуальной сети клиента. Внедрение виртуальной сети позволяет получить доступ к ресурсам службы через адреса, отличные от Интернета. Локальные экземпляры используют ExpressRoute или VPN типа "сеть — сеть" для прямого доступа к экземплярам служб через адресное пространство виртуальной сети, а не для открытия брандмауэра в общедоступном адресном пространстве Интернета. При присоединении выделенного экземпляра к конечной точке можно использовать те же стратегии, что и для соответствия требованиям IaaS TIC. Маршрутизация по умолчанию гарантирует перенаправление трафика, привязанного к Интернету, на шлюз виртуальной сети, привязанный к локальной среде. Вы можете дополнительно контролировать входящий и исходящий доступ через группы безопасности сети для данной подсети.

Обзор внедрения виртуальной сети

Вариант B. Использование конечных точек службы виртуальной сети (туннель службы)

Все большее число служб Azure с несколькими клиентами предлагает конечные точки службы. Конечные точки службы — это альтернативный метод интеграции с виртуальными сетями Azure. Конечные точки служб виртуальной сети расширяют адресное пространство IP виртуальной сети и идентификатор виртуальной сети до службы через прямое подключение. Трафик из виртуальной сети в службу Azure всегда остается в магистральной сети Azure.

После включения конечной точки службы для службы используйте политики, предоставляемые службой, чтобы ограничить подключения к этой виртуальной сети. Проверки доступа применяются на платформе службой Azure. Доступ к заблокированным ресурсам предоставляется только в том случае, если запрос поступает из разрешенной виртуальной сети или подсети или из двух IP-адресов, которые используются для идентификации локального трафика при использовании ExpressRoute. Используйте этот метод, чтобы эффективно предотвратить входящий и исходящий трафик непосредственно из службы PaaS.

Общие сведения о конечных точках службы

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

Частная конечная точка Azure — это сетевой интерфейс, который подключает вас приватно и безопасно к службе под управлением Приватного канала Azure. Частная конечная точка использует частный IP-адрес из вашей виртуальной сети, тем самым эффективно перенося службу в вашу виртуальную сеть.

Средства для информирования о ситуации в сети

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

Политика Azure

Политика Azure — это служба Azure, которая предоставляет вашей организации более высокую возможность аудита и применения инициатив соответствия требованиям. Теперь вы можете спланировать и проверить правила политики Azure, чтобы обеспечить соответствие требованиям TIC.

Политика Azure ориентирована на уровень подписки. Служба предоставляет централизованный интерфейс, в котором можно выполнять задачи соответствия требованиям, в том числе:

  • Управление инициативами
  • Настройка определений политик
  • Соответствие требованиям аудита
  • Обеспечить соблюдение требований
  • Управление исключениями

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

Аналитика трафика наблюдателя за сетями

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

Аналитика трафика наблюдателя за сетями

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

Геокарта

Используйте топологию виртуальных сетей для быстрого опроса существующих виртуальных сетей:

Карта топологии сети

Тесты следующего прыжка наблюдателя за сетями

Сети в регионах, отслеживаемых наблюдателем за сетями, могут проводить тесты следующего прыжка. На портале Azure можно ввести исходный и конечный узлы для примера сетевого потока в Network Watcher, чтобы определить следующий узел маршрута. Выполните этот тест на виртуальных машинах и образцах интернет-адресов, чтобы убедиться, что следующий узел — это ожидаемый виртуальный шлюз сети.

Тесты следующего прыжка

Выводы

Вы можете легко настроить сетевой доступ для соответствия рекомендациям TIC 2.0 и использовать поддержку Azure для NIST CSF и NIST SP 800-53 для решения требований TIC 3.0.

Дальнейшие действия