Спросите бармена: можно ли предоставлять учетные данные администратора WordPress персоналу службы поддержки плагинов?

Нет. Нада. Неа. Неа. Это отрицательно. Ни при каких условиях. Моя мама не воспитывала дураков. Черт возьми. Не в этой жизни. И другие тысячи способов сказать любому, кто запрашивает учетные данные сайта, чтобы он не работал, даже персоналу службы поддержки плагинов «доверенной» компании-разработчика WordPress.

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

Сегодняшний выпуск серии « Спроси бармена » любезно предоставлен читателем по имени Нико. Поскольку весь текст состоит из более чем 1000 слов, просто сделаем ссылку на стенограмму через файл .txt для тех, кто хочет прочитать ее полностью. В этом посте  остановимся на жизненно важных моментах. Или, по крайней мере, те части, к которым хочется обратиться.

Один из участников группы Нико в Facebook начал обсуждение.

«Можно ли отправлять данные FTP разработчику плагина для устранения проблемы, с которой мы сталкиваемся с WooCommerce? Мы уже предоставили учетные данные администратора WordPress ».

Это нормальная практика в мире WordPress, верно? Разработчики плагинов помогают в решении проблем, и если они не могут воспроизвести проблему, им нужен доступ, чтобы они могли проверить, проблема ли это плагина или сервера, и исправить что-то?

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

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

Иногда пользователи предоставляли учетные данные запроса. Часто они размещали их в виде обычного текста на форумах, по электронной почте или в Slack (к тому же вы никогда не должны этого делать). Если код на сайте нуждался в изменении, наши пользователи выполняли задачу самостоятельно или устанавливали безошибочную версию темы / плагина, которые им передали.

Если они не знали, как выполнить задачу через администратора, FTP или иным образом, он находил время, чтобы научить их. Да, это потребовало больше энергии с обеих сторон, но надо полагать, что мы были в этом лучшие. Не раз эти моменты побуждали некоторых пользователей становиться разработчиками или, по крайней мере, для них это была крошечная ступенька.Мы остаемся друзьями со многими из них сегодня и гордимся тем, что они начали с маленького одиночного магазина WordPress.

Некоторые случаи были более тяжелыми, чем другие. Много раз  копировали их настройки (плагины, темы и т. д.) На своей машине. В большинстве случаев это приводило бы к решению –  использовать его __doing_it_wrong()задолго до того, как WordPress представил эту идею. В конечном итоге можно передать бесчисленные исправления ошибок другим разработчикам. Так у нас появилось много друзей-разработчиков.

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

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

Бывают ли моменты, когда персоналу службы поддержки плагина действительно нужен доступ? Наверное.

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

Вторая часть вопроса Нико касается Общего регламента ЕС по защите данных (GDPR) и пользовательских данных. Это жизненно важная часть работы в те времена, когда вы решаете передать ключи от своего веб-сайта.

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

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

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

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

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

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

• create_users
• delete_users
• edit_users
• list_users
• promote_users
• remove_users

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

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

Что насчет пароля FTP?  Доверяем очень немногим людям с таким уровнем доступа.

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

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

Этот пост не предназначен для того, чтобы выставить разработчиков плагинов или компании ненадежными. Большинство из них хорошие люди, просто пытающиеся зарабатывать на жизнь честно. Однако не доверять кому-либо – это безопасность веб-сайта 101. Это просто базовый уровень, в котором должны работать пользователи. Если вы начнете какое-либо взаимодействие с этим мышлением, это должно помочь вам принимать более разумные решения в каждом конкретном случае.