Как защитить облачный Mac и удалить секреты после аренды

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

Сначала определите границы доверия для этой аренды

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

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

Что проверить в первые пятнадцать минут после подключения

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

whoami
sw_vers
sudo systemsetup -getremotelogin
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
softwareupdate --list

Создайте отдельный SSH-ключ для аренды

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

umask 077
mkdir -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/armmacs-rental -C "temporary-build-node"
chmod 700 ~/.ssh
chmod 600 ~/.ssh/armmacs-rental

В локальном ~/.ssh/config можно задать для узла отдельный псевдоним, а параметром IdentitiesOnly yes запретить SSH-клиенту перебирать другие ключи. Адрес узла, имя пользователя и путь к ключу берите из данных текущего заказа. Не сохраняйте реальный адрес в репозитории кода.

Host rented-mac
    HostName <node-address>
    User <node-user>
    IdentityFile ~/.ssh/armmacs-rental
    IdentitiesOnly yes
    ServerAliveInterval 30

Предоставляйте секреты только тогда, когда они нужны

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

umask 077
mkdir -p ~/secure-input
chmod 700 ~/secure-input
security add-generic-password -a build -s ci-token -w

Сразу после использования удалите переменные из текущего сеанса Shell. Если учётные данные нужны только для одного релиза, не сохраняйте их между сеансами.

unset CI_TOKEN
security delete-generic-password -a build -s ci-token

Не допускайте утечки секретов через журналы и кеши

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

Проводите облегчённый аудит во время работы

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

who
ps -axo user,pid,ppid,command
lsof -nP -iTCP -sTCP:LISTEN
df -h
find ~/work -type f -perm -004

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

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

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

mkdir -p ~/export
ditto -c -k --keepParent ~/work/project ~/export/project.zip
shasum -a 256 ~/export/project.zip
git -C ~/work/project status --short

Как минимум необходимо удалить каталоги проектов и экспорта, кеши сборки, временные каталоги, записи связки ключей, разрешения SSH, записи публичных ключей и историю Shell выделенной учётной записи. Кроме того, отзовите токен репозитория на стороне сервиса, который его выпустил, и удалите со своей рабочей станции приватный ключ, созданный для этой аренды. Многократная перезапись отдельных файлов на SSD не заменяет процедуру утилизации узла со стороны платформы. Количество циклов перезаписи нельзя считать доказательством завершённой очистки.

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

Часто задаваемые вопросы