Как настроить сетевой белый список CI для Xcode 27? Корпоративный список 2026

По требованиям Apple к корпоративным сетям, для работы программных сервисов Apple нужно разрешать конкретные хосты и порты, а не просто проверять доступность веб-страницы в официальном перечне сетевых требований Apple. Поэтому сетевой белый список CI для Xcode 27 нельзя строить по правилу «разрешить весь Apple». Ваше рабочее решение — разделить исходный код, зависимости, компоненты Xcode, подпись, публикацию и служебные уведомления, а каждое разрешение подтвердить реальным запуском конвейера.

Кому предназначен материал

Сетевым и безопасностным руководителям, которым нужно обосновать минимальный исходящий доступ Mac CI и порядок его пересмотра.

Руководителям платформенной разработки, которые вводят Xcode 27, Apple Silicon и CI Runner в корпоративную инфраструктуру.

Ответственным за закупки и инфраструктуру — чтобы проверить, способен ли удалённый Mac-узел предоставить контролируемый сетевой доступ, приватные зависимости и воспроизводимую проверку восстановления связи.

Последняя проверка выполнена 21 сентября 2026 года; данные сверены с официальными материалами Apple и документацией CI Runner. При переходе Xcode 27 из бета-статуса в стабильный релиз, изменении сервисных адресов Apple или корпоративной политики прокси список нужно пересмотреть.

SECTION 01 Карта потока сборки

Шесть сетевых стадий

Одна ошибка «сборка не удалась» скрывает несколько разных сетевых операций. В типичном конвейере Xcode 27 их нужно разделять следующим образом:

Получение исходного кода. Runner обращается к корпоративному Git-серверу, внешнему репозиторию или зеркалу. Этот трафик не обязан идти к доменам Apple.
Разрешение зависимостей. Swift Package, CocoaPods, Git LFS и внутренние бинарные артефакты могут использовать разные хранилища, учётные данные и правила прокси.
Получение компонентов Xcode. Симуляторы, дополнительные платформы и другие компоненты устанавливаются отдельным механизмом; Apple описывает его в документации по загрузке компонентов Xcode.
Аутентификация и подпись. Сюда относятся Apple Developer, сертификаты, профили подготовки, проверка команды и доступ к хранилищу ключей.
Публикация результата. Архив может отправляться в App Store Connect, TestFlight или сервис нотарификации macOS. Для каждого направления нужны собственные учётные данные и подтверждение результата.
Возврат результата. CI-система передаёт статусы, логи, артефакты и уведомления. Это отдельная зависимость, особенно если Runner находится в изолированном сегменте.

Хост, который открывает сайт в браузере, не обязательно способен выполнить все шесть операций. В CI могут отличаться DNS, переменные прокси, сертификаты доверия, сервисная учётная запись, доступ к Keychain и маршрут до приватного репозитория.

Признаки неправильной границы

Сетевой белый список CI для Xcode 27 следует считать не перечнем доменов, а набором правил с доказательством. Для каждого правила зафиксируйте:

инициирующий узел и сервисную учётную запись;
имя назначения, порт и направление соединения;
стадию конвейера и бизнес-цель;
тип доступа: DNS, TCP, TLS, API или загрузка артефакта;
ожидаемый код ответа либо событие в логе;
владельца правила и дату повторной проверки.

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

SECTION 02 Mac CI и внешние зависимости

Источники кода

Начните с разделения репозиториев по зонам доверия:

корпоративный исходный код;
публичные репозитории;
приватные зависимости;
LFS-объекты;
внутренний реестр пакетов;
кэш сборки.

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

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

Ошибки разрешения зависимостей

Если разработчик получает зависимости, а сервисная сборка — нет, проверьте проблему в таком порядке:

Запустите разрешение зависимостей от имени сервисной учётной записи CI.
Сравните переменные HTTP_PROXY, HTTPS_PROXY, NO_PROXY и настройки системного прокси.
Проверьте доверенную цепочку сертификатов именно на Mac-узле, а не на рабочей станции администратора.
Убедитесь, что файл блокировки не изменяется во время сборки.
Отключите или очистите кэш и повторите операцию, чтобы проверить холодный маршрут.
Сохраните адрес назначения, DNS-ответ, результат TLS-проверки и запись менеджера зависимостей.

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

Swift Package Manager, CocoaPods и Git LFS нельзя считать одной сетевой категорией. У них могут быть разные домены, методы аутентификации и размеры объектов. Если в инфраструктуре есть корпоративный прокси, его настройка должна быть частью воспроизводимого образа Runner, а не ручной операцией администратора.

Кэш и изоляция

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

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

SECTION 03 Apple-сервисы и компоненты Xcode

Что проверять на стороне Apple

Условия работы Xcode 27, поддерживаемые версии системы и известные ограничения берите только из официальных примечаний к выпуску Xcode 27. Из этого документа нельзя выводить, что конкретный корпоративный прокси или удалённый Mac уже имеет сетевой доступ: версию инструмента и сетевую достижимость нужно проверять раздельно.

Сформируйте отдельные правила для следующих функций:

загрузка и обновление компонентов Xcode;
установка симуляторов и дополнительных платформ;
работа с учётной записью разработчика;
получение или проверка профилей подготовки;
отправка сборки в App Store Connect;
публикация тестовой сборки;
нотарификация и получение статуса;
загрузка лога и получение результата операции.

Требования Apple к хостам и портам нужно сопоставлять с внутренним DNS и фактическими журналами firewall. Список *.apple.com может быть временным диагностическим исключением, но не окончательной корпоративной политикой: широкое правило усложняет аудит и не показывает, какая операция действительно нужна.

Для общих сетевых портов сверяйтесь с официальным списком TCP- и UDP-портов программных продуктов Apple. Не переносите порт в постоянное правило только потому, что он указан в общей документации: сначала определите, какая стадия CI его использует и нужен ли он именно конкретному типу узла.

Подпись и публикация

Обычная проверка pull request, архивирование, подписание, отправка и нотарификация должны находиться в разных доверенных контекстах. Особенно важно не размещать секреты производственной подписи на узле, который одновременно:

скачивает произвольные зависимости из внешних источников;
выполняет код из непроверенных веток;
используется для интерактивной отладки;
имеет широкий исходящий доступ без журналирования.

Для загрузки в App Store Connect используйте отдельную роль и ключ с минимально необходимыми правами; порядок создания таких ключей описан в официальной документации App Store Connect API. Секрет не должен попадать в логи, переменные сборочного артефакта или общий кэш.

Нотарификация требует большего, чем успешная отправка файла. Для автоматизированного сценария проверьте:

принятие запроса;
получение идентификатора операции;
запрос текущего статуса;
получение лога;
прикрепление билета к результату;
проверку результата на целевом Mac.

Эти действия соответствуют автоматизированному интерфейсу Apple Notary API. Если проверяется только факт загрузки, вы не доказали, что производственный процесс завершился успешно.

SECTION 04 Прокси, TLS и аудит

Почему Mac CI не проходит через корпоративный выход

Наиболее частые скрытые блокировки возникают не в самом firewall, а на границе между сетевыми слоями:

DNS переписывает имя на внутренний адрес;
явный прокси требует отдельную аутентификацию;
прозрачный прокси меняет маршрут без настройки на Mac;
TLS-инспекция подменяет сертификат;
внутренний CA установлен у администратора, но отсутствует в системном или пользовательском хранилище Runner;
NO_PROXY исключает приватный репозиторий или, наоборот, отправляет его наружу;
редирект ведёт к адресу, которого нет в исходном разрешённом списке.

Поэтому ping и открытие URL в браузере не являются достаточными тестами. Для каждого назначения пройдите шесть уровней:

DNS: имя разрешается в ожидаемый адрес.
TCP: соединение с требуемым портом устанавливается из нужного сегмента.
TLS: сертификат, имя и цепочка доверия проходят проверку.
Аутентификация: сервисная учётная запись или API-ключ принимаются.
Бизнес-запрос: выполняется конкретная операция, например получение пакета или отправка архива.
Полный конвейер: результат появляется в CI, журнале и системе публикации.

Результат каждого уровня сохраняйте рядом с правилом. Для внешних сервисов указывайте время проверки и версию образа Runner; для внутренних — владельца DNS, прокси и репозитория.

Разделение доверенных узлов

Минимальная схема для предприятия выглядит так:

обычный узел сборки — исходный код, разрешённые зависимости и сервисы, необходимые для тестов;
узел зависимостей — дополнительно доступ к внутреннему зеркалу и внешним источникам пакетов;
производственный подписывающий узел — только необходимые Apple-сервисы, публикация и защищённое хранилище ключей;
аварийный узел — заранее проверенный маршрут, но без постоянного доступа к производственным секретам.

Сетевое разделение не заменяет контроль заданий. Группа Runner, метки, правила веток и права на секреты должны согласовываться с firewall-политикой. Если задача может быть назначена на любой Mac без учёта его зоны, даже точный белый список не обеспечит ожидаемую изоляцию.

SECTION 05 Пошаговая проверка перед запуском

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

Шаг 1. Зафиксируйте инвентаризацию

Запишите версию Xcode 27, версию macOS, архитектуру узла, группу Runner, сервисную учётную запись и тип сети. Условия системы сверяйте с примечаниями Apple к Xcode 27, а не с неподтверждёнными списками в сообществах.

Шаг 2. Составьте карту назначений

Разделите адреса на исходный код, зависимости, компоненты Xcode, Apple Developer, App Store Connect, нотарификацию, уведомления и внутренние сервисы. Для каждого оставьте поле «источник подтверждения»: официальная документация, запись предприятия или результат тестового запуска.

Шаг 3. Проверьте сетевые слои

С узла CI выполните DNS-проверку, TCP-соединение и TLS-проверку через тот же маршрут, который использует Runner. Затем выполните авторизованный API-запрос или загрузку тестового объекта. Команды и параметры должны быть сохранены в журнале, но секреты и токены — замаскированы.

Шаг 4. Повторите запуск от имени CI

Не используйте интерактивную сессию администратора как доказательство. Запустите минимальное задание сервисной учётной записью: получить исходный код, разрешить зависимости, собрать тестовую цель и сохранить логи. Отдельно проверьте холодный кэш.

Шаг 5. Проверьте подписывающий маршрут

На изолированном узле выполните тестовое архивирование, подпись, отправку и получение результата. Если используется нотарификация, обязательно запросите статус и лог после отправки. Успешный TCP-сеанс без бизнес-ответа не считается пройденной проверкой.

Шаг 6. Проверьте отказ и восстановление

Временно заблокируйте каждую критическую группу назначения в тестовом сегменте и убедитесь, что журнал показывает ожидаемую причину. После восстановления правило должно вернуть конвейер в рабочее состояние без ручной настройки на Mac.

SECTION 06 Приёмочный чек-лист

Перед утверждением сетевой политики отметьте каждый пункт только после получения доказательства:

[ ] Для каждого исходящего правила указаны назначение, порт, инициирующий узел и бизнес-цель.
[ ] Источники исходного кода отделены от Apple-сервисов и внутренних хранилищ.
[ ] Разрешение Swift Package, CocoaPods, Git LFS и бинарных артефактов проверено с сервисной учётной записью CI.
[ ] Холодное получение зависимостей прошло после очистки кэша.
[ ] Компонент Xcode или симулятор установлен через отдельный проверяемый маршрут.
[ ] Apple Developer и профили подготовки проверены без интерактивного входа администратора.
[ ] App Store Connect использует ограниченный API-ключ, а секреты отсутствуют в логах.
[ ] Для нотарификации проверены отправка, статус, лог и прикрепление билета.
[ ] TLS-инспекция либо запрещена для конкретного маршрута, либо подтверждена совместимостью и внутренним CA.
[ ] Обычный Runner и производственный подписывающий узел имеют разные группы правил.
[ ] Метки Runner не позволяют отправить чувствительное задание в неподходящий сетевой сегмент.
[ ] Для отказа, восстановления и повторной проверки назначены владельцы.
[ ] Аварийный Mac-узел прошёл тот же набор тестов, что и основной.
[ ] Дата следующего пересмотра записана в системе управления изменениями.

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

SECTION 07 Проверка удалённого Mac-узла

Удалённый Mac имеет смысл рассматривать только после того, как утверждены требования к сети. Запросите у поставщика не рекламное обещание, а подтверждение следующих возможностей:

контролируемый исходящий прокси или заданный firewall-маршрут;
отдельная сетовая зона для сборки и подписи;
доступ к приватным зависимостям без обхода корпоративной политики;
сохранение журналов DNS, прокси и сетевых отказов;
возможность повторно выполнить тест после разрыва соединения;
проверка установки компонентов Xcode и прохождения публикационного маршрута;
понятная процедура изоляции и восстановления узла.

Для первичной оценки инфраструктуры можно использовать описание удалённых Mac-решений VPSNIX, но решение о допуске принимайте только после собственного приёмочного запуска. Если вам нужно сравнить коммерческие условия, страница тарифов VPSNIX не заменяет проверку сетевой политики, приватных зависимостей и производственного подписания.

Покупка физического Mac обычно даёт прямой контроль над сетевой картой, локальным Keychain и размещением в вашем сегменте, но переносит на вас закупку, замену оборудования, резервирование и круглосуточное наблюдение. Общий облачный маршрут может быстрее стартовать, однако часто усложняет приватный DNS, TLS-инспекцию, доступ к внутренним пакетам и аудит групп Runner. Аренда Mac через VPSNIX может быть рациональнее для пилота, временной команды или дополнительного CI-узла, если до оплаты вы письменно проверили режим выхода, изоляцию подписывающей среды и восстановление после потери связи. Для постоянной тяжёлой нагрузки или требований к физическому интерфейсу собственное оборудование может остаться более подходящим вариантом.

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