[{"data":1,"prerenderedAt":177},["ShallowReactive",2],{"publication:ru:P185":3},{"meta":4,"copy":17,"relatedArticles":135,"terms":169,"term":170,"resourceParent":171,"glossaryParent":174},{"id":5,"path":6,"kind":7,"keyword":8,"title":9,"seoTitle":10,"description":11,"incoming":12,"updated":15,"preparedOn":16},"P185","\u002Fblog\u002Fhosting-security-responsibility","article","кто отвечает за безопасность хостинга и VPS","Кто отвечает за безопасность хостинга и VPS","Безопасность хостинга и VPS: кто за что отвечает","Как распределить обновления, приложение, доступы, резервные копии и помощь при инциденте. Матрица владельцев, подтверждений и границ договора.",[13,14],"\u002Fservices\u002Fservers-hosting","\u002Fservices\u002Flinux-vps","2026-06-16","2026-10-31",{"intro":18,"sections":19,"checklistTitle":93,"checklist":94,"faq":101,"sources":111,"links":113,"cta":130},"Ответственность за безопасность хостинга и VPS определяется фактической услугой, договором и распределением задач. Общий хостинг, VPS и слово managed не подтверждают автоматически обслуживание приложения, копий или инцидентов. Для каждой важной функции назначьте владельца, подтверждение выполнения и путь обращения при проблеме.",[20,26,36,72,78,87],{"title":21,"paragraphs":22},"Разберите услугу на задачи",[23,24,25],"Серверная площадка, гостевая ОС, приложение, домен, почта, доступы и резервные копии являются разными областями. Состав услуги может включать часть из них. Начинайте с перечня задач, а не предположения, что все принадлежит одной стороне.","Название тарифа не заменяет описание работы. Уточните, кто следит за поддержкой версии, применяет исправления и проверяет функцию после изменения. Если ответ ограничен словами сервер работает, это еще не приемка сайта и его интеграций.","Распределение должно быть понятным при нормальной работе и при проблеме. Тот, кто технически имеет доступ, не всегда обязан выполнять конкретную задачу по договору. Уточняйте полномочия и согласованный объем заранее.",{"title":27,"paragraphs":28,"sources":32},"Пример модели провайдера и ее границы",[29,30,31],"AWS описывает разделение безопасности облачной инфраструктуры и задач клиента с учетом сервиса. Для ряда услуг клиент отвечает за гостевую ОС, приложения и настройки. Этот пример полезен как способ задать вопросы, но не является договором любого хостинга.","Для своего предложения проверьте, что именно управляется поставщиком. Если часть задач делегирована подрядчику, уточните, как он получает сигнал, выполняет изменение и передает результат владельцу бизнеса. Делегирование не должно создавать область, за которую никто не отвечает.","Не делайте вывод о безопасности только по физической инфраструктуре или выделенным ресурсам. Даже надежный провайдер не подтверждает автоматически правильность ролей, формы приложения или происхождения установленного плагина.",[33],{"label":34,"url":35},"AWS: разделение ответственности с учетом сервиса","https:\u002F\u002Faws.amazon.com\u002Fcompliance\u002Fshared-responsibility-model\u002F",{"title":37,"paragraphs":38,"table":41},"Матрица задачи, владельца и подтверждения",[39,40],"Матрица CyberFixCrew помогает сравнить реальный состав обслуживания. Заполняйте ее вместе с ответственными сторонами. Неизвестная строка является вопросом до согласования, а не основанием предположить бесплатное выполнение в будущем.","Для каждой задачи укажите контакт, необходимые права и способ подтверждения. Это облегчает передачу обслуживания и предотвращает ситуации, когда клиент, хостинг и разработчик направляют запрос друг другу без принятия решения.",{"caption":42,"headers":43,"rows":47},"Как распределить ответственность за размещение",[44,45,46],"Задача","Что согласовать","Как подтвердить",[48,52,56,60,64,68],[49,50,51],"Платформа и ОС","Кто поддерживает и обновляет","Область и результат обслуживания",[53,54,55],"Приложение","Кто исправляет и выпускает","Приемка важного сценария",[57,58,59],"Доступы","Кто выдает, меняет и отзывает","Владельцы и история решения",[61,62,63],"Копии","Состав, хранение и восстановление","Доступный тест нужной функции",[65,66,67],"Инцидент","Кто принимает сигнал и что делает","Реальный контакт и границы помощи",[69,70,71],"Передача","Данные, домен, права и выход","Понятный порядок смены стороны",{"title":73,"paragraphs":74},"Обновления, копии и приемка",[75,76,77],"Разделите обновление ОС, приложения и интеграций. У каждого могут быть разные исполнители и условия. Важно применить изменение и понять, кто подтверждает работу важной функции и учитывает возникшую несовместимость.","Для резервного копирования уточните состав, доступ, хранение и порядок восстановления. Фраза копии есть не определяет, можно ли вернуть базу и актуальные зависимые данные. Согласуйте, кто инициирует тест и принимает результат.","Если изменение может нарушить управление или доступность, определите путь возврата до выполнения. Договоренность должна учитывать реальную среду и права. Нельзя рассчитывать на консоль или копию, доступность которых никто не проверял.",{"title":79,"paragraphs":80,"example":84},"Поддержка при инциденте и эскалация",[81,82,83],"Уточните, кто принимает сигнал, какие сведения нужны и где заканчивается помощь провайдера. Восстановление виртуальной машины, очистка приложения и анализ данных могут быть разными работами. Не считайте доступность канала обращения обещанием любого результата.","Сохраните основной и альтернативный контакт, владельца решения и необходимые полномочия. Если один участник недоступен, должен существовать согласованный следующий шаг. Не придумывайте круглосуточное покрытие или гарантированное время ответа там, где этого нет.","Условный клиент получает восстановленную систему, но приложение еще не прошло приемку. Правильный статус разделяет готовность платформы и рабочую функцию. Нужный владелец продолжает свою часть с сохранением текущих наблюдений.",{"title":85,"text":86},"Условная запись распределения","Провайдер подтвердил доступность платформы; разработчик отвечает за приемку формы и интеграции; владелец бизнеса принимает рабочий результат. Пример показывает роли и не является договором или выполненным восстановлением клиента.",{"title":88,"paragraphs":89},"Подготовьте передачу и пересмотр",[90,91,92],"Уточните, кто контролирует домен, учетные записи, данные и возможность экспорта. При смене стороны должны оставаться понятными доступы, копии и техническая информация. Не передавайте секреты в открытой заявке: сначала согласуйте безопасный механизм.","Пересматривайте матрицу при новом тарифе, приложении, подрядчике и важных изменениях. Услуга может менять объем, а старые ожидания - сохраняться по инерции. Запишите актуальное решение и владельца каждой незакрытой строки.","CyberFixCrew - израильская компания по защите сайтов и цифровой инфраструктуры для русскоязычных бизнесов по всему миру. Применяем израильские знания в области кибербезопасности к Linux, сайтам и рабочим зависимостям. Согласуем техническую область обслуживания и связь результата с ответственностью сторон.","Перед согласованием обслуживания хостинга",[95,96,97,98,99,100],"Задачи платформы, ОС и приложения разделены.","Для обновлений и приемки назначены владельцы.","Копии описаны по составу и восстановлению.","Помощь при инциденте имеет реальные границы и контакты.","Контроль домена, данных и доступов понятен.","Матрица пересматривается при смене услуги или стороны.",[102,105,108],{"question":103,"answer":104},"VPS автоматически безопаснее общего хостинга?","Один тип размещения не подтверждает состояние доступа, приложения, обновлений и копий. VPS может менять обязанности клиента, а конкретный объем зависит от услуги. Сравните задачи, владельцев и подтверждения вместо вывода только по названию.",{"question":106,"answer":107},"Managed означает, что приложение полностью обслуживают?","Не обязательно: уточните, какие слои, изменения, проверки и инциденты входят в реальный объем. Название услуги не заменяет распределение задач. Для важной функции нужно знать исполнителя, приемку и способ обращения при проблеме.",{"question":109,"answer":110},"Если провайдер делает копии, кто проверяет восстановление?","Это необходимо согласовать. Наличие копии не определяет ее состав, права доступа, запуск проверки и приемку приложения. Запишите владельца теста и нужный рабочий результат, а также ограничения по актуальным данным и внешним зависимостям.",[112],{"label":34,"url":35},[114,117,120,123,126,128],{"path":115,"label":116},"\u002Fblog\u002Flinux-server-hardening","Базовая конфигурация Linux",{"path":118,"label":119},"\u002Fblog\u002Fbackup-restore-test","Приемка восстановления",{"path":121,"label":122},"\u002Fblog\u002Fincident-response-small-business","Контакты и полномочия при инциденте",{"path":124,"label":125},"\u002Fglossary\u002Fhardening","Понятие харденинга",{"path":13,"label":127},"Серверы и хостинг",{"path":14,"label":129},"Linux и VPS",{"title":131,"description":132,"button":133,"type":134},"Согласуем технические задачи и владельцев","Опишите услугу, приложение и важные функции без секретов. Уточним область, подтверждения и открытые вопросы.","Обсудить ответственность за инфраструктуру","check",[136,145,153,161],{"id":137,"path":138,"title":139,"description":140,"category":141,"artwork":142,"order":143,"publishedOn":144},"P056","\u002Fblog\u002Fcloudflare-waf-false-positives","Ложные срабатывания Cloudflare WAF: как вернуть нужную функцию","Как сопоставить ошибку, Ray ID, событие защиты и правило. Ограниченное исключение, проверка рабочей функции и план возврата настройки.","infrastructure","security",26,"2026-05-31",{"id":146,"path":147,"title":148,"description":149,"category":141,"artwork":150,"order":151,"publishedOn":152},"P187","\u002Fblog\u002Fdocker-security-checklist","Чек-лист безопасности Docker для малого бизнеса","Проверка доступа к daemon, пользователя контейнера, rootless, портов, монтирований, секретов и постоянных данных с понятной областью приемки.","integrations",35,"2026-07-02",{"id":154,"path":155,"title":156,"description":157,"category":141,"artwork":158,"order":159,"publishedOn":160},"P176","\u002Fblog\u002Fdiagnose-ddos-vs-overload","DDoS или перегрузка сайта: как сравнить признаки и причины","Сравните трафик, ресурсы сервера, ошибки и недавние изменения. Область Cloudflare, рабочие зависимости и выбор мер без нагрузочных экспериментов.","performance",21,"2026-05-15",{"id":162,"path":163,"title":164,"description":165,"category":141,"artwork":166,"order":167,"publishedOn":168},"P101","\u002Fblog\u002Flinux-ssh-hardening","Защита SSH на Linux-сервере без потери управления","Как согласовать владельцев ключей и полномочия, проверить эффективную конфигурацию, новый вход и резервный путь до завершения изменения SSH.","servers",42,"2026-07-18",[],null,{"path":172,"label":173},"\u002Fresources","Материалы и шаблоны безопасности сайта",{"path":175,"label":176},"\u002Fglossary","Словарь кибербезопасности для бизнеса",1794134064544]