Спросите бармена: можно ли предоставлять учетные данные администратора 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. Это просто базовый уровень, в котором должны работать пользователи. Если вы вступите в какое-либо взаимодействие с таким мышлением, это должно помочь вам принимать более разумные решения в каждом конкретном случае.