Модель безопасности и границы ответственности

Сначала разберитесь с изоляцией, доступом и состоянием — затем защищайте каждую сборку.

Каждый заказ соответствует одному выделенному физическому Mac, а не виртуальной машине. Изоляция устройства — лишь отправная точка: учетные данные, удаленные сеансы, материалы подписи, резервные копии и конфигурацию проекта нужно управлять отдельно в рамках инженерного процесса.

Базовая изоляция
1 заказ соответствует 1 выделенному хосту
Вычислительные ресурсы и локальное хранилище выделены заказу
Внешние сетевые каналы относятся к общей инфраструктуре
Учетные записи, ключи и права доступа к проектам контролирует пользователь

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

Модель изоляции

Выделен хост, а не весь сетевой маршрут.

Оценивая степень изоляции, проверяйте отдельно устройство, сеть, учетные записи и внешние системы. Не следует считать, что выделенный физический Mac автоматически делает эксклюзивными все звенья цепочки.

Уровень устройства: выделенный хост

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

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

Сетевой уровень: общая инфраструктура

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

  • Открывайте только те адреса, порты и сервисы, которые действительно нужны рабочему процессу.
  • Для репозиториев, целей загрузки артефактов и источников зависимостей сохраняйте отдельное управление правами.
  • При сбоях отдельно фиксируйте состояние хоста, соединения и ответ целевого сервиса.
Учетные записи и учетные данные

После первого подключения прежде всего сократите поверхность доступа.

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

01

Обновите исходные учетные данные

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

02

Отдавайте приоритет ключам

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

03

Не используйте общие учетные записи

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

04

Регулярно проверяйте права

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

Минимальный набор для проверки прав

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

  • Системная учетная записьОставить только текущего оператора
  • Открытый ключ SSHУдалить недействующие ключи
  • Права доступа к репозиториюОграничить необходимыми проектами
  • Переменные окруженияОграничить область чтения
  • Учетные данные загрузкиАвторизовать отдельно для каждой задачи
Защита удаленного доступа

Ограничьте точки подключения минимумом, необходимым рабочему процессу.

SSH, VNC и общий экран macOS предназначены для разных задач. Выбрав способ подключения, синхронно настройте область доступа, поведение сеанса, версию клиента и периодичность смены учетных данных.

Проверка защиты удаленного доступа
Пункт проверки Необходимое действие Чего следует избегать Сигнал проверки
Область доступа Оставьте только входы, нужные текущему способу подключения и задачам автоматизации. Не возвращать временно расширенный для диагностики доступ. К неиспользуемым входам невозможно подключиться.
Блокировка сеанса Блокируйте экран при выходе из графического сеанса и завершайте его после окончания задачи. Оставлять аутентифицированный сеанс на общем терминале. При повторном входе требуется новая проверка.
Обновление клиента Используйте поддерживаемые клиенты SSH, VNC или общего доступа к экрану. Долго сохранять старый клиент с непроверяемым источником. Версия клиента соответствует командному стандарту.
Проверка аномалий Проверяйте время входа, источник, активные сеансы и недавние изменения конфигурации. Считать доступ исправным только потому, что хост находится в сети. Каждый активный сеанс соответствует реальному оператору.
Смена учетных данных Немедленно меняйте их после ухода участника, подозрения на раскрытие ключа или изменения прав. Копировать одни и те же учетные данные в несколько проектов и на устройства участников. Старые учетные данные недействительны, а новые существуют только там, где необходимы.
Оптимизация слабой сети не должна расширять доступ

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

Посмотреть способы удаленного доступа
Жизненный цикл данных

С первого синхронизированного файла сохраняйте путь для последующего переноса.

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

Подключение

Определите источники и места назначения данных

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

Работа

Пусть резервное копирование следует ритму сборки

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

Перенос

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

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

Освобождение

Завершайте использование только после поэтапной проверки

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

Защита материалов сборки

Подпись, репозитории и права загрузки не должны проходить весь процесс с использованием одного секрета.

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

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

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

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

Принцип маскирования

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

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

Надежность работы

Исправный узел не означает, что исправны каждое соединение и каждая задача сборки.

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

Состояние узла

Доступна ли инфраструктура

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

Само по себе не доказывает

Что системный сеанс конкретного хоста или задача проекта уже работает нормально.

Состояние хоста в сети

Устройство завершило запуск

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

Само по себе не доказывает

Что адрес, порт и учетные данные SSH, VNC или общего доступа к экрану указаны правильно.

Состояние соединения

Сеанс успешно установлен

Фиксируйте способ подключения, клиент, адрес назначения, порт, локальную сеть и занятость сеанса.

Само по себе не доказывает

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

Состояние задачи

Шаги сборки завершены

Оценивайте выполнение по журналам шагов, коду завершения, проверке артефактов и результату загрузки.

Само по себе не доказывает

Что на узле или в сети не произошло инфраструктурного сбоя — это нужно сопоставить с тремя предыдущими сигналами.

Узел Сигнал инфраструктуры
Хост Сигнал доступности устройства
Соединение Сигнал доступности сеанса
Задача Сигнал выполнения проекта
Порядок сообщения об инциденте

Сначала зафиксируйте факты, затем передайте воспроизводимый контекст.

Качественное сообщение помогает поддержке быстро отличить проблему узла, хоста, соединения или проекта. Фраза «не работает» скрывает ключевые данные маршрутизации и увеличивает число уточнений.

Что записать перед отправкой

Минимальный пакет инцидента состоит из семи пунктов.

01 Время возникновения

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

02 Узел

Укажите Сингапур, Японию (Токио), Южную Корею (Сеул), Гонконг или восток США.

03 Идентификатор заказа

Укажите идентификатор заказа или хоста, который можно проверить в консоли.

04 Масштаб воздействия

Укажите, затронута ли отдельная задача, весь хост или несколько участников.

05 Шаги воспроизведения

Перечислите в фактическом порядке ввода данные, действия и место сбоя.

06 Сопоставление состояний

Отдельно укажите состояния узла, хоста, соединения и задачи.

07 Маскированные журналы

Сохраните контекст ошибки, удалив пароли, закрытые ключи, токены и секреты исходного кода.

Проблема существующего заказа

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

Создать обращение в консоли

Консультация по безопасности и конфиденциальности

Отправьте время инцидента, масштаб воздействия и маскированные материалы на адрес поддержки. Не прикладывайте пароли, закрытые ключи, полные платежные данные или немаскированный исходный код.

support@minidebug.com
Границы ответственности

Платформа отвечает за узлы и управление, пользователь — за доступ и данные внутри рабочего процесса.

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

Ответственность MiniDebug

Физические узлы и интерфейс управления

  • Предоставление физического хоста

    Предоставлять выделенный физический Mac согласно заказу и показывать состояние хоста и заказа в интерфейсе управления.

  • Инфраструктура узлов

    Обеспечивать работу пяти узлов — Сингапур, Япония (Токио), Южная Корея (Сеул), Гонконг и восток США — 365 дней в году.

  • Передача данных для подключения

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

  • Диагностика инфраструктурных инцидентов

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

  • Управление жизненным циклом заказа

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

Ответственность пользователя

Учетные записи, код, учетные данные и конфигурация проекта

  • Права учетных записей и участников

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

  • Правомерность кода и материалов

    Подтверждать наличие необходимых прав на исходный код, модели, материалы, сертификаты, профили и другие материалы сборки.

  • Конфигурация среды проекта

    Поддерживать версии Xcode, зависимости, скрипты, пути, правила подписи, переменные окружения и цели загрузки.

  • Резервное копирование и перенос данных

    Резервировать исходный код и артефакты в период аренды, а до освобождения хоста выполнить необходимый перенос и проверить восстановление.

  • Маскирование журналов и взаимодействие при инцидентах

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

Быстрая маршрутизация

Определите следующий шаг по уровню, на котором возникла проблема.

Аномалия состояния узла или хоста

Зафиксируйте идентификатор заказа, узел, время и масштаб воздействия и отправьте обращение через консоль.

Не удается установить соединение

Сначала проверьте доступность, адрес, порт, локальную сеть, учетные данные, клиент и параллельные сеансы.

Сбой команды сборки

Проверьте Xcode, кэш зависимостей, место на диске, настройки подписи, код завершения и журнал шагов.

Риск материалов или прав доступа

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

Следующий шаг

Разверните среду сборки с четкими границами ответственности.

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