Границы физического узла и доступа

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

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

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

Арендовать облачный Mac Руководство по безопасному подключению
Принадлежность узла
1 действующий заказ = 1 выделенная физическая машина
Способ доступа
После выдачи временных данных клиент обновляет их при первом подключении
Границы поддержки
Мы не запрашиваем полный закрытый ключ или токены репозитория
ЗАПИСЬ О БЕЗОПАСНОСТИ СЕАНСА

Запись выдачи удалённого сеанса

Границы подтверждены
01
Привязка заказа к узлу Подтверждаем модель, узел и владельца заказа; физические вычислительные ресурсы не используются совместно с другими заказами.
Выполнено
02
Проверка перед выдачей Проверяем запуск системы, сетевое соединение, объём хранилища и состояние учётной записи доступа.
Выполнено
03
Выдача временных данных Данные предоставляются через контролируемый канал; после первого подключения их необходимо сразу обновить.
Выдано
04
Ограничение админ-доступа Доступ предоставляется только в необходимом объёме для согласованного устранения неисправности; причина и результат фиксируются.
Ограничено
Принципы сеанса Минимальные права · Аудит · Отзыв
Модель доверия

Границы ответственности платформы и клиента определены

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

01

Изоляция физического узла

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

  • Идентификатор узла связан с записью заказа
  • Проверка модели и объёма хранилища до выдачи
  • После завершения заказа прежние пути доступа отключаются
02

Разделение панели управления и рабочих нагрузок

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

  • Запрашиваются только сведения, необходимые для диагностики
  • Административные действия выполняются в необходимом объёме
  • После завершения диагностики временные права отзываются
03

Ответственность клиента

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

  • Ограничивайте область действия и срок токенов репозитория
  • Сразу удаляйте доступ после увольнения или смены роли
  • Шифруйте конфиденциальные файлы и храните отдельную резервную копию
Проверка выдачи

До выдачи данных доступа выполняются пять проверок устройства

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

  1. 01

    Состояние устройства

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

    Выдано после проверки
  2. 02

    Запуск системы

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

    Запуск подтверждён
  3. 03

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

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

    Соединение подтверждено
  4. 04

    Объём хранилища

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

    Объём подтверждён
  5. 05

    Учётная запись доступа

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

    Ожидает обновления клиентом
Безопасность учётных данных

Временные данные нужны только для первого входа; дальнейший доступ контролирует клиент

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

Жизненный цикл учётных данных От выдачи до отзыва
Выдача

Вход во временную учётную запись

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

Обновление

Замена после первого подключения

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

Разделение

Раздельная авторизация людей и автоматизации

Для интерактивного удалённого рабочего стола, администрирования по SSH и CI/CD Runner используйте разные пути доступа. Автоматизированным токенам предоставляйте только необходимые репозитории и операции.

Отзыв

Очистка сразу после изменения состава

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

SSH-ключи

Загружайте только открытый ключ, не передавайте полный закрытый ключ

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

  • Называйте открытые ключи по пользователю или задаче
  • Ограничивайте локальные права чтения файла закрытого ключа
  • Удаляйте соответствующий открытый ключ после прекращения использования
Пример проверки прав 
identity: build-runner
scope: repository-read
interactive-login: false
expires: project-policy
owner: mobile-ci-team

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

Административный доступ

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

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

01

Подтверждение проблемы и разрешения

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

02

Ограничение необходимого объёма

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

03

Фиксация действий

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

04

Завершение и отзыв прав

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

Распространённые сценарии поддержки и допустимый объём данных
Сценарий Что клиент предоставляет в первую очередь Возможные действия поддержки Что не следует передавать
Сбой удалённого подключения Время возникновения, сеть клиента, сообщение об ошибке, идентификатор узла Проверка состояния служб, сетевого пути и учётной записи Полный закрытый ключ, необезличенный токен репозитория
Прерывание процесса сборки Команда, код завершения, обезличенный журнал, признаки использования ресурсов Проверка системных процессов, места на диске и базовых служб Полный исходный код проекта, рабочие ключи
Аномальный объём хранилища Сводка использования каталогов, конфигурация заказа, ожидаемый объём Проверка файловой системы, состояния монтирования и дополнений заказа Содержимое рабочих файлов, незашифрованная копия данных
Сеть и удалённые сеансы

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

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

Сеанс удалённого рабочего стола

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

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

SSH и автоматизированные подключения

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

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

Статус оплаты попадает в заказ, полные данные карты не поступают на страницы VMOak

Платёжный процесс хранит только сведения, необходимые для завершения заказа, проверки статуса и решения вопросов по счёту. Для двух способов оплаты действуют разные проверки, но расчёты ведутся в долларах США (USD); доступный шлюз определяется при оформлении.

Оплата картой

Visa / Mastercard / Amex

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

  • Расчёты в долларах США (USD)
  • В заказе фиксируются статус оплаты и необходимая ссылка на транзакцию
  • Вопросы по счёту решаются через обращение в панели управления или по адресу поддержки
Оплата в блокчейне

USDT-TRC20

Заказы USDT-TRC20 сверяются по записи транзакции в блокчейне. В обращении по счёту можно указать номер заказа, идентификатор транзакции и время оплаты; не прикладывайте закрытый ключ кошелька или другие данные управления.

  • Цена указана в долларах США (USD)
  • Сверка выполняется по заказу и идентификатору блокчейн-транзакции
  • Закрытый ключ и данные восстановления всегда хранятся у клиента
VMOak требуется Номер заказа, статус оплаты, необходимая ссылка на транзакцию VMOak не требуется Полные данные карты, закрытый ключ кошелька, посторонние учётные данные
Реагирование на инциденты безопасности

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

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

  1. 01

    Подтверждение

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

    Составить временную шкалу
  2. 02

    Изоляция

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

    Ограничить воздействие
  3. 03

    Расследование

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

    Проверить доказательства
  4. 04

    Восстановление

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

    Восстановить доступность
  5. 05

    Уведомление и разбор

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

    Сформировать запись обработки
Сообщить об инциденте

Предоставьте минимальный набор доказательств для восстановления временной шкалы

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

Войдите в панель управления и отправьте обращение Отправить сообщение об инциденте
Контрольный список безопасности клиента

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

Этот список подходит для удалённой разработки, CI/CD, самостоятельных Runner, экспериментов с ИИ и творческих рабочих процессов. Чем больше команда, тем важнее назначить для каждого пункта ответственного и периодичность проверки.

01

Обновить первоначальные данные

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

Ответственный: администратор узла
02

Ограничить токены репозитория

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

Ответственный: администратор репозитория
03

Разделить ключи сотрудников и Runner

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

Ответственный: администратор CI/CD
04

Регулярно очищать доступ

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

Ответственный: владелец прав команды
05

Шифровать конфиденциальные файлы

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

Ответственный: владелец данных
06

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

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

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

Выберите облачный Mac, выделенный одному заказу

Сначала подтвердите конфигурацию M4 или M4 Pro, шесть доступных узлов и расчётный период, затем оформите заказ в панели управления. Фактическая доступность узла определяется актуальным статусом в панели.

Арендовать облачный Mac Посмотреть конфигурации и цены