BerryVM предоставляет физический узел Mac mini, которым в течение срока аренды пользуется один клиент, а не виртуальную машину. Модель безопасности основана на изоляции устройства, контроле доступа, журналировании действий и чётких границах данных, включая обязанности клиента по настройке.
BerryVM не распределяет процессор, память или локальное хранилище одного устройства между несколькими клиентами. После передачи по заказу выделенное устройство используется только этим клиентом до окончания срока аренды; затем доступ закрывается и запускается процедура завершения.
Чип, память и встроенное хранилище относятся ко всему выделенному Mac mini. Это выделенный физический сервер, а не общая виртуальная машина; ресурсы не описываются через коэффициент перепродажи.
Идентификатор устройства, узел и данные доступа передаются вместе с заказом. Клиент должен предоставлять доступ только авторизованным участникам и немедленно менять учётные данные при изменении обязанностей, уходе сотрудника или подозрении на утечку.
Сотрудники поддержки не получают постоянный доступ к среде клиента по умолчанию. Если нужна помощь в диагностике, через тикет в консоли следует чётко указать проблему, разрешённые действия и срок доступа; предпочтительно использовать обезличенные журналы.
Данные доступа содержат только информацию, необходимую для первого защищённого сеанса. Получив их, сначала проверьте устройство и узел, затем обновите учётные данные, ограничьте источники доступа и зафиксируйте список авторизованных участников.
Сопоставьте идентификатор заказа, конфигурацию устройства, выбранный узел и полученные данные доступа. При несоответствии прекратите подключение и создайте тикет через консоль.
Не используйте исходный пароль для повседневной совместной работы. Установите надёжные новые учётные данные по правилам команды, отдавая предпочтение аутентификации по ключу, и безопасно сохраните данные для восстановления.
Откройте только необходимые для задачи удалённые сервисы и исходные адреса, отключите неиспользуемые возможности общего доступа, а для автоматизированных Runner используйте отдельные отзываемые разрешения.
Запишите, у кого есть доступ, когда менялись учётные данные, какие конвейеры используют устройство и кто отвечает за отзыв доступа при изменении состава команды.
Диагностика по умолчанию начинается с состояния устройства, сетевого маршрута и обезличенных журналов. Помощь оказывается только при явном разрешении клиента и реальной необходимости удалённой диагностики, в пределах, согласованных в тикете.
Если есть подозрение на утечку учётных данных, сначала остановите затронутые автоматизированные задачи, отзовите связанный доступ и выполните ротацию. Сохраните идентификатор заказа, узел, время события, исходный адрес и обезличенные журналы, затем создайте тикет через консоль.
Создать тикет безопасностиДанные проектов клиента в основном находятся на выделенном физическом устройстве. Данные аккаунта, заказа, статуса оплаты, обращений в поддержку и необходимые эксплуатационные записи обрабатываются для соответствующих целей. Полные основания хранения и права пользователей указаны в политике конфиденциальности.
Обрабатываются контактные данные аккаунта, конфигурация, срок аренды, узел и статус оплаты — для подтверждения заказа, назначения устройства и передачи данных доступа. На этапе активации клиенту не нужно передавать исходный код проекта или рабочие данные.
В течение срока аренды клиент отвечает за репозитории, кэш сборки, файлы моделей, ключи и права доступа к артефактам на выделенном устройстве. BerryVM обрабатывает только необходимые для работы, безопасности и поддержки записи.
После подтверждения продления срок использования устройства продолжается согласно заказу. Команда по-прежнему должна регулярно менять учётные данные, удалять права бывших участников и проверять ключи автоматизированных задач.
После окончания срока аренды доступ клиента закрывается, а данные устройства обрабатываются по процедуре сервиса. До окончания аренды клиент должен экспортировать нужные артефакты, отозвать токены внешних систем и убедиться, что не полагается на единственную копию данных на устройстве.
Политика конфиденциальности отдельно описывает обработку данных аккаунта, записей заказов, обращений в поддержку, необходимых журналов и данных устройства.
Риски удалённых сеансов обычно связаны с постоянными учётными данными, слишком широким кругом источников, простаивающими сервисами и общим доступом без возможности отследить действия. Этот список подходит как базовый план настройки после передачи устройства.
Включайте только необходимые для задачи удалённые сервисы и порты. Общие, обнаруживаемые и тестовые сервисы, не нужные среде разработки, должны оставаться отключёнными, чтобы временная диагностика не создавала постоянный вход.
Точка проверки: сервисы, порты, адреса прослушиванияАвтоматизированные задачи и участники проекта должны использовать отдельные отзываемые средства аутентификации. Не используйте одну постоянную пару паролей для нескольких людей и не записывайте закрытые ключи непосредственно в репозиторий, скрипты сборки или текст тикета.
Точка проверки: владелец ключа, хранение, отзывОграничивайте источники доступа по командным выходным адресам, контролируемым jump-host или сетевому маршруту задачи. При работе участников из разных регионов сначала согласуйте политику источников; не открывайте все адреса как постоянное решение.
Точка проверки: диапазон источников, исключения, срок действияРегулярно проверяйте участников, автоматизированные Runner, удалённые сервисы и внешние токены. При выходе участника из проекта, отключении конвейера или изменении назначения устройства немедленно отзывайте ненужные права.
Точка проверки: участники, задачи, токены, записи аномалий| Объект проверки | Рекомендуемое действие | Когда выполнять | Какие записи сохранять |
|---|---|---|---|
| Доступ сотрудников | Проверьте права участников и отзовите просроченный доступ | Изменение обязанностей или уход участника из проекта | Авторизовавший сотрудник, время отзыва, затронутое устройство |
| Учётные данные автоматизации | Смените ключи и проверьте восстановление конвейера | Плановая ротация или подозрение на утечку | Идентификатор ключа, время ротации, результат проверки |
| Удалённые сервисы | Отключите простаивающие сервисы и сузьте диапазон источников | Завершение задачи или изменение сетевой политики | Порт, правило источника, ответственный за изменение |
| Разрешение поддержки | Закройте временный доступ и обновите связанные учётные данные | Завершение диагностики по тикету | Идентификатор тикета, область разрешения, результат закрытия |
Обработка инцидента безопасности строится вокруг фактов и временной шкалы. При обращении не нужно отправлять пароль доступа; для быстрой оценки обычно полезнее идентификатор заказа, узел, время события, масштаб воздействия, шаги воспроизведения и обезличенные журналы.
Укажите идентификатор заказа, узел, время первого обнаружения, затронутые задачи и уже выполненные действия. Перед добавлением журналов обезличьте ключи, токены, данные клиентов и сведения об участниках.
Уточните, продолжается ли инцидент, затрагивает ли он одно устройство или внешнюю зависимость, а также нужно ли немедленно отозвать учётные данные, остановить конвейер или ограничить сетевые источники.
На основании фактов закройте затронутый вход, отзовите связанные разрешения или приостановите задачу. Действия по изоляции должны быть отслеживаемыми; не удаляйте важные журналы до сохранения доказательств.
После ротации учётных данных, исправления правил источников, обновления зависимостей или отката конфигурации выполните минимальную проверочную задачу и убедитесь, что подключение, сборка и путь к артефактам работают нормально.
Составьте временную шкалу, определите первопричину, масштаб воздействия и последующие действия; зафиксируйте необходимые новые средства мониторинга, отзыв прав, механизмы ротации и командные чек-листы.
Если требовались действия на стороне сервиса, сообщите через отслеживаемый канал поддержки подтверждённые результаты, ход работ и действия со стороны клиента. Не заменяйте выводы непроверенными предположениями.
BerryVM использует 99,9% как целевой показатель доступности сервиса; все узлы работают 365 дней в году без плановых остановок. Область статистики, исключения, сроки подачи и применимые варианты компенсации определяются условиями сервиса.
Чтобы проверить сбой во время работы, укажите идентификатор заказа, узел, время события, продолжительность и масштаб воздействия. Записи сервиса и журналы клиента должны использовать один часовой пояс или явно указывать часовой пояс.
Сообщения об уязвимостях, вопросы безопасности и рабочие аномалии можно отправить через тикет в консоли или на support@berryvm.com. Укажите идентификатор заказа, узел, временную шкалу, масштаб воздействия и обезличенные журналы; не отправляйте учётные данные, закрытые ключи или необезличенные данные проекта.