Ротируйте сертификаты iOS CI поэтапно: сначала составьте карту сертификатов, закрытых ключей, профилей и задач выпуска, затем синхронизируйте новые активы через Fastlane Match и проверьте сборку на реальном Mac CI — только после этого выводите старые. Этот порядок подходит командам, которым важно сохранить воспроизводимость сборок и иметь доказуемый план отката.
Материал предназначен для IT-руководителя, который определяет владельцев активов, согласование и условия возврата.
Платформенный инженер найдёт порядок настройки Fastlane Match в режиме чтения для CI.
Релизный инженер — критерии проверки архива, подписи и пути распространения.
Этап 1. Сначала карта активов, затем план ротации
Не начинайте с выпуска нового сертификата или отзыва старого. Сначала выясните, какие именно задачи зависят от текущего набора: разработка, App Store, внутренняя или тестовая дистрибуция. Эти типы подписи не взаимозаменяемы, поэтому общее указание «обновить сертификат» недостаточно для безопасного изменения.
Соберите реестр для каждого приложения и рабочего процесса. Включите в него:
- идентификатор приложения и тип распространения;
- сертификат и его назначение, например Apple Distribution;
- закрытый ключ, который должен соответствовать сертификату;
- iOS provisioning profile и связанные с ним приложения и возможности;
- Mac-узел, CI-задачу и ответственного за выпуск;
- место хранения сертификата, профиля и секрета для доступа к зашифрованному хранилищу.
Сверьте записи в учётной записи разработчика с сертификатами и ключами, установленными в Keychain на Mac-узлах, а также с настройками CI. Сертификатный файл сам по себе не доказывает, что узел может подписывать приложение: проверьте наличие соответствующего закрытого ключа и фактический результат подписания. Для разделения ответственности за создание и управление сертификатами проверьте актуальные полномочия участников по описанию ролей программы разработчиков.
| Актив или настройка | Что зафиксировать | Чем подтвердить |
|---|---|---|
| Сертификат | Тип, владелец, назначение и статус | Учётная запись разработчика и сведения о подписи сборки |
| Закрытый ключ | Где доступен и кто может его использовать | Keychain целевого Mac и тестовая операция подписи |
| Профиль | Приложение, тип распространения и связанный сертификат | Учётная запись и профиль, встроенный в артефакт |
| CI-доступ | Секреты и участники, которым они доступны | Настройки защищённого окружения и история изменений |
| Задача выпуска | Сборка, архивирование, тестирование или публикация | Журнал CI и артефакт последнего успешного запуска |
Проверьте, кто вправе создавать и менять активы, а кто только запускает сборки. Apple описывает типы сертификатов и их управление в справке по сертификатам. Не сводите аудит к дате окончания действия: состояние конкретного актива нужно проверить в учётной записи и сопоставить с применяемым рабочим процессом. Заранее запишите владельца решения, согласующего изменение и человека, который сможет остановить расширение ротации.
Этап 2. Зафиксируйте исходную сборку, а не только настройки
Перед изменением активов получите воспроизводимую исходную точку. Зафиксируйте версию Xcode, выбранную командой подписи, целевой профиль и результаты ключевых задач CI. Сохраните журналы и доступные артефакты предыдущего успешного запуска. Они помогут отличить проблему новых активов от уже существовавшей ошибки конфигурации.
Проверку подписи проводите на том Mac, который действительно выполняет задачу. Если у команды есть основной и резервный узел, учтите оба: конфигурация на одном Mac не подтверждает готовность другого. Уточните доступ CI к Keychain, файлам профилей и секретам. Не расширяйте права учётной записи только ради удобства ротации; назначьте владельца, который отвечает за создание или изменение активов, отдельно от CI-задачи, использующей их.
Для командной синхронизации подписывающих идентификаторов Xcode предусмотрены отдельные механизмы; их поведение описано в документации по совместному использованию сертификатов подписи команды. Сопоставьте их с тем, как именно в вашей команде хранятся и устанавливаются активы. Не запускайте одновременно несколько систем управления сертификатами без ясного разделения ответственности: иначе будет сложнее определить, какой процесс изменил состояние профиля или ключа.
В журнал исходного состояния внесите не только итог «задача прошла», но и то, чем именно она подписала приложение. Позже сравните эти сведения с новыми: идентичность сертификата, используемый профиль и подпись готового артефакта. Разбор профиля и диагностических сообщений можно сверять с заметкой Apple о профилях подготовки и журнале подписания.
Этап 3. Выберите, кто создаёт новые активы и как обновляется профиль
До создания сертификата определите путь управления: существующий процесс Fastlane Match, средства Xcode или учётная запись разработчика. Выберите одного ответственного и зафиксируйте, кто утверждает изменение. Если сертификат меняется, проверьте профиль, который должен соответствовать новой подписи. При необходимости отредактируйте или заново загрузите профиль через предусмотренный Apple процесс — порядок описан в инструкции по изменению, загрузке и удалению профилей.
Для Apple Distribution проверьте не только отображаемое имя сертификата, но и соответствие закрытого ключа и нужному профилю. Если приложение подписывается в нескольких режимах, не переносите автоматически решение для App Store на внутреннюю или тестовую дистрибуцию. У каждого потока должны быть свои критерии приёмки.
Сразу решите, где будут храниться зашифрованные материалы, кто имеет доступ к хранилищу и каким способом CI получает секрет для расшифровки. Пароль не должен попадать в репозиторий, команду запуска или обычный журнал CI. Например, документация GitHub Actions о секретах описывает управление секретами платформы; если ваша CI-система другая, сверяйте правила с её документацией, а не переносите настройки по аналогии.
Не делайте отзыв старого сертификата обычным первым действием. Apple предупреждает, что профили, содержащие отозванный сертификат, становятся недействительными; последствия и порядок действий изложены в инструкции Apple по отзыву сертификата. Поэтому сначала установите новый актив, проверьте зависимые профили и рабочие процессы и только затем принимайте отдельное решение об отзыве.
Этап 4. Fastlane Match в CI: синхронизация с правом чтения
Fastlane Match удобно применять для доставки общих подписывающих активов команде, но его наличие не заменяет корпоративное согласование. До изменения production-конфигурации проверьте в официальной документации Fastlane Match точные параметры используемой версии и способ хранения репозитория.
Ключевое разделение такое: подготовка и изменение активов выполняются в контролируемом процессе ответственным участником, а обычная CI-задача получает уже существующий набор только для чтения. Для этого документация Match предусматривает параметр readonly: true. Например, при настройке задачи явно задайте тип используемой подписи и режим чтения, а не полагайтесь на неявные значения. Если ваша конфигурация использует переменную MATCH_PASSWORD, предоставляйте её CI как защищённый секрет, а не храните в репозитории.
Перед распространением проверьте синхронизацию на изолированном Mac-узле и на целевом приложении. Убедитесь, что CI не создаёт сертификат и не меняет общие материалы при обычном запуске. Для производственного запуска ограничьте доступ к секретам задачами и участниками, которым он действительно нужен. Защита секрета не устраняет риск скомпрометированного runner: изучите рекомендации CI-платформы о рисках скомпрометированных исполнителей и отделите задачи, работающие с подписывающими материалами, от недоверенных запусков.
Если ваша платформа поддерживает защищённые окружения и ручное подтверждение развёртывания, рассмотрите их для релизного этапа. Такие правила помогают ограничить запуск, но не доказывают изоляцию Mac и не заменяют аудит полномочий; для GitHub Actions это различие раскрыто в документации об окружениях и правилах защиты развёртываний.
Этап 5. Подтвердите ротацию реальной сборкой и артефактом
Проверка завершена не тогда, когда Match сообщил об успешной синхронизации, а когда целевой Mac CI выполнил нужную работу и сформировал артефакт с ожидаемой подписью. Запустите репрезентативные задачи для каждого затрагиваемого потока: сборку, архивирование и соответствующую тестовую или релизную дистрибуцию. Сверьте результат с исходной базовой линией.
| Проверка | Критерий прохождения | Если проверка не пройдена |
|---|---|---|
| Синхронизация Match | CI получил нужные активы в режиме чтения | Остановить расширение и проверить тип подписи, доступ и профиль |
| Сборка приложения | Задача выполнилась на целевом Mac | Сравнить настройки и журнал с исходным запуском |
| Архивирование | Архив создан для требуемого рабочего процесса | Не считать зелёную сборку достаточной; проверить стадию архива |
| Подпись артефакта | Сертификат и встроенный профиль соответствуют плану | Сохранить артефакт и диагностику, исправить профиль или ключ |
| Резервный узел | Повторная задача использует ожидаемый набор активов | Не отключать прежний путь, пока узел не прошёл приёмку |
Проверьте фактические сведения о подписи и встроенном профиле в созданном артефакте, а не только статус задачи. Сопоставьте их с реестром из первого этапа. Если основная сборка проходит, а архивирование или распространение — нет, ротацию нельзя считать принятой. Сначала выясните, затронут ли конкретный профиль, сертификат или доступ CI, затем повторите проверку на том же узле.
Используйте следующий список решений, чтобы выбрать дальнейшее действие:
- Если все нужные потоки подписывают артефакт новыми активами на целевых и резервных Mac, то фиксируйте приёмку и переходите к решению о выводе старых материалов.
- Если прошла только базовая сборка, но не архивирование или распространение, то остановите расширение ротации и сохраните прежний рабочий путь.
- Если Match синхронизирует активы, но подпись не подтверждена, то проверяйте Keychain, соответствие ключа и сертификата, а также профиль; успешную синхронизацию не считайте доказательством готовности.
- Если неизвестно, какие приложения или узлы используют старый сертификат, то не отзывайте его и вернитесь к инвентаризации зависимостей.
Для каждой неудачной проверки сохраняйте журнал, идентификатор задачи и артефакт, если он был сформирован. Это даст команде основу для отката к известной рабочей конфигурации, а не к предположению о том, какой актив ещё действителен.
Этап 6. Старые активы — после приёмки и проверки зависимостей
Когда новые активы прошли все требуемые проверки, зафиксируйте владельцев, дату изменения, результаты испытаний, условия отката и перечень узлов, которые были проверены. Отдельно убедитесь, что production-процессы, резервные Mac и нужные приложения больше не зависят от старого набора. Только после этого назначенный владелец принимает решение: сохранить старый актив на ограниченный срок, заменить связанный профиль или отозвать сертификат по принятой процедуре.
Не удаляйте единственную восстанавливаемую копию подписывающих материалов до проверки восстановления и утверждения ответственного. Одновременно не оставляйте секреты без владельца и пересмотра доступа: определите, кому разрешено читать хранилище, кто может менять активы и как прекращается доступ при изменении роли. Для каждой ротации сохраняйте результат решения, а не только технический журнал.
Такой порядок не делает Fastlane Match системой корпоративного согласования и не подтверждает физическую изоляцию Mac-узла. Это отдельные вопросы: их решают разграничение доступа, контроль CI-секретов и проверка самого окружения. Ротация отвечает на более узкую задачу — обновить используемые подписи и профили, доказать работоспособность выпуска и только затем убрать прежние активы.
После приёмки сопоставьте текущий Mac CI с требованиями подписания: кто имеет доступ к Keychain и секретам, можно ли воспроизвести окружение, доступны ли резервный узел и возврат к рабочей конфигурации. Собственный Mac даёт контроль над физической машиной, но требует закупки, обслуживания и самостоятельного обеспечения резервирования; общая удалённая среда тоже не подходит, если политика требует физически выделенного оборудования или локальных интерфейсов. Если ограничение — временный дефицит узлов для пилота или отдельной проверки подписи, сравните условия удалённого Mac и его стоимости с требованиями вашей политики, не передавая провайдеру ответственность за сертификаты и секреты. Когда команде нужен дополнительный Mac для ограниченной задачи, изучите варианты аренды удалённого Mac и до подключения отдельно проверьте доступ, хранение ключей и порядок удаления данных.