Проверяемые границы безопасности

Меры безопасности выделенного узла: от физических границ до реагирования на инциденты

Каждый заказ соответствует отдельному физическому узлу Mac mini, а не виртуальной машине. HexVM отвечает за предоставление узла, базовую сеть и эксплуатационное управление на платформе; клиент — за учетные записи, права доступа, ключи сборки, подключение к репозиториям и данные на узле.

Арендовать выделенный Mac Связаться с командой безопасности

Отчеты о безопасности принимаются только через тикет в консоли или по адресу support@hexvm.com. Не отправляйте реальные закрытые ключи, полные токены доступа или необезличенные учетные данные.

Выделенный узел Mac mini HexVM и интерфейс управления состоянием безопасности

Проверка границ узла Норма

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

Изоляция узлов 1 устройство на заказ

Период работы 365 дней

Целевой показатель сервиса 99,9%

Каналы отчетности 2

Разграничение ответственности

Сначала определите зоны контроля

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

Границы физических ресурсов

Каждому заказу соответствует отдельный Mac mini; CPU, память и локальное хранилище не делятся с экземплярами других клиентов. Доступны две конфигурации: базовая конфигурация M4 (16 ГБ, 256 ГБ) и конфигурация M4 Pro (64 ГБ, 2 ТБ).

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

Права клиента

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

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

Границы эксплуатации платформы

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

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

Основа совместной ответственности

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

Контроль доступа

Разделите долгосрочные риски на пять постоянных действий

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

Немедленно обновите временные учетные данные

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

В первую очередь используйте ключи SSH

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

Ограничивайте права задачами

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

Отзывайте доступ сразу при увольнении

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

Изолируйте разработку, тестирование и релиз

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

Ежемесячный список проверки прав

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

Открыть инструкции в центре помощи

Защита данных

Определите путь данных за пределы узла еще до их загрузки

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

Передача

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

Обработка

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

Хранение

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

Удаление

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

Рекомендуемые меры контроля для распространенных типов данных
Тип данных	Рекомендуемое место хранения	Границы доступа	Действия перед удалением
Исходный код и зависимости	Контролируемый рабочий каталог и каталог кэша сборки	Участники разработки и назначенный runner	Проверьте состояние коммитов и удалите неотслеживаемые чувствительные файлы
Ключи сборки и токены доступа	Ограниченное хранилище учетных данных или внедрение во время выполнения	Только соответствующий конвейер и ответственные лица	Отозвать, ротировать и удалить локальные копии
Сертификаты и профили подготовки	Среда подписи с контролируемыми правами	Задача подписи и ответственный за релиз	Экспортировать необходимые резервные копии и удалить копии с узла
Артефакты сборки	Каталог артефактов или одобренное командой хранилище	Роли тестирования, релиза и аудита	Проверить контрольные суммы и удалить временные версии после переноса
Журналы и диагностические пакеты	Каталог журналов с ограниченным сроком хранения	Администраторы, команда безопасности и владельцы задач	Обезличить и архивировать, удалить исходные копии с учетными данными

Сеть и журналы

Каждая аномалия должна иметь временную шкалу, охват и доказательства

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

Аудит подключений и выявление аномалий

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

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

Синхронизация времени и формат журналов

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

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

Подключение мониторинга клиента

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

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

Стабильность работы

Цель доступности 99,9% и состояние за последние 90 дней

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

Целевой показатель сервиса 99,9%

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

Период наблюдения: 90 дней
Шаг отображения состояния: По дням
Текущие события: Нет

Ежедневное состояние сервиса

Норма Событие сервиса

90 дней назад 60 дней назад 30 дней назад Сегодня

Краткая информация о запросе сервисной компенсации

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

Отправить тикет через консоль

Реагирование на инциденты

Шесть этапов: от обнаружения до разбора

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

01

Обнаружение

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

Изоляция

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

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

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

Исправление

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

Уведомление

Через проверенный канал связи по заказу сообщите масштаб влияния, текущее состояние, выполненные действия и время следующего обновления. Не обменивайтесь чувствительными данными через непроверенные каналы.
Содействие клиента: назначьте ответственного, способного подтвердить техническое и бизнес-влияние.
06

Разбор

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

Канал для отчетов о безопасности

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

Проблемы безопасности принимаются только через тикет в консоли или по адресу support@hexvm.com. Аномалии существующих заказов и узлов в первую очередь направляйте через тикет для проверки принадлежности заказа и дальнейшего отслеживания.

Тикет безопасности в консоли

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

Войти в консоль и отправить тикет

Электронная почта для отчетов о безопасности

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

Отправить на support@hexvm.com

Что должно содержаться в пригодном для обработки отчете

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

Не отправляйте вместе с отчетом

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

Выделенный Apple Silicon

Развертывайте облачный Mac с четкими границами

Сравните конфигурации и сроки аренды двух выделенных физических узлов и выберите вариант для сборок Xcode, CI/CD или постоянной разработки. Все цены указаны в долларах США (USD).

Арендовать выделенный Mac Посмотреть варианты аренды