Как разделить доступ редактора сайта и администратора VPS

Что известно из исходного материала

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

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

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

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

Две разные зоны ответственности

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

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

Проверить подходящий вариант можно на странице Beget.

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

Разделение ролей помогает избежать нескольких типичных ошибок:

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

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

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

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

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

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

Перед настройкой откройте Beget и сверьте актуальные условия.

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

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

Контроль, журналирование и пересмотр прав

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

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

Для каждой существенной операции желательно иметь понятный след:

1. кто запросил действие;
2. кто его выполнил;
3. что именно было изменено;
4. когда это произошло;
5. был ли результат проверен;
6. как отменить изменение при необходимости.

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

Когда требования понятны, перейдите в Beget и проверьте выбранный вариант.

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

Что следует уточнить перед публикацией регламента

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

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

Минимальный регламент должен отвечать на следующие вопросы:

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

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

Что почитать дальше

• Администрирование сайта после запуска: что проверять и кто отвечает
• Какие ресурсы нужны боту и почему их пока нельзя оценить
• Сайт готов: где разместить и нужны ли VPS и CDN Beget
• CDN, VPS и хостинг: как сравнивать варианты размещения сайта
• VPS для одностраничного сайта: когда оправдан, а когда нет

Обложка вдохновлена картиной Ганса Гольбейна Младшего «Послы» (1533). Посмотреть оригинал в коллекции Национальной галереи в Лондоне.