Применение принципа наименьших привилегий для повышения безопасности WordPress

Опубликовано: 2021-07-27

Принцип наименьших привилегий для WordPress упускает из виду громкие заголовки, когда происходят взломы, потеря данных и DoS-атаки. Тем не менее, это один из самых эффективных, хотя и упускаемых из виду, способов обеспечения безопасности веб-сайтов WordPress.

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

Оглавление

  • Что такое принцип наименьших привилегий?
  • Когда и где применяется принцип наименьших привилегий?
  • Каковы риски, если PoLP не применяется?
  • Почему многие владельцы веб-сайтов пренебрегают принципом наименьших привилегий в WordPress?
  • Как применить PoLP для WordPress
    • Права пользователя базы данных WordPress
    • Роли и привилегии пользователей WordPress
      • Создание пользовательских ролей
    • Разрешения на файлы и каталоги
    • Настройка плагинов WordPress
    • Доступ по FTP для сторонних подрядчиков
  • Мини-кейсы
    • Приложения для веб-сайтов электронной коммерции
    • Университеты и учебные заведения
    • Новостные сайты и блоги
    • Банковские сайты
    • Трекеры здоровья и фитнеса
  • Использование принципа наименьших привилегий для WordPress и не только

Что такое принцип наименьших привилегий?

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

Принцип наименьших привилегий (PoLP) также известен как «принцип наименьших полномочий», «принцип минимальных привилегий» или «наименее привилегированная учетная запись пользователя» (LUA).

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

Когда и где применяется принцип наименьших привилегий?

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

Каковы риски, если PoLP не применяется?

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

Подумайте о следующих возможных пользователях:

  • Новый пользователь начинает с небольшим пониманием последствий ошибок на веб-сайте WordPress для бизнеса.
  • Те, у кого мало опыта администрирования WordPress
  • Без знания последствий загрузки новых версий или плагинов WordPress по желанию или их обновления без предварительного создания резервной копии.
  • Лица с ограниченной осведомленностью о безопасности, создающие новых пользователей или изменяющие разрешения существующих пользователей.
  • Те, кто не знает, как бороться с сообщениями об ошибках или других проблемах
  • Внешние авторы сообщений в блогах, такие как партнеры, фрилансеры и клиенты, возможно, с небольшим знанием WordPress, которые могут даже «полезно» загружать или обновлять плагины на вашем веб-сайте — без запроса.

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

Такие как:

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

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

СОВЕТ: Используйте плагин журнала активности для WordPress, чтобы вести журнал всех изменений, которые пользователи делают на вашем сайте WordPress. Это помогает с ответственностью пользователей и упрощает устранение неполадок.

Почему многие владельцы веб-сайтов пренебрегают принципом наименьших привилегий в WordPress?

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

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

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

То же самое относится к файлам и каталогам. Например, некоторые плагины WordPress хранят файлы кеша или другие данные в файловой системе (то есть в каталогах WordPress). Проще просто настроить разрешения 777 в каталоге /wp-content/plugins/, потому что все плагины будут работать, и нет необходимости тратить дополнительное время на устранение неполадок и настройку разрешений каждый раз, когда вы устанавливаете новый плагин. Но проведение некоторых исследований в начале для определения конкретных областей приложения или каталогов веб-сайта — чтобы пользователи не имели слишком большого доступа — снижает уже упомянутые риски. Кроме того, у него есть дополнительное преимущество: каждый может получить доступ к тому, что ему нужно для работы, без дополнительного участия администратора.

Вопросы, которые задают Маску владельцы и администраторы веб-сайтов

Стоит ли удобство риска для безопасности? Вы знаете, каким был бы наш ответ на этот вопрос. Просто нет смысла устанавливать и поддерживать передовые и надежные плагины безопасности веб-приложений, протоколы паролей и другие меры, такие как 2FA, если ваша самая большая угроза безопасности заключается в том, что вы уже оставили черный ход открытым с любительским и слабым контролем доступа!

Как применить принцип наименьших привилегий для WordPress

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

Права пользователя базы данных WordPress

Давайте начнем с самого основного места — разрешений или привилегий пользовательской базы данных WordPress.

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

  • Выбирать
  • Вставлять
  • Обновлять
  • Удалить

Эти разрешения не позволяют пользователю базы данных WordPress изменять структуру базы данных.

Рекомендации

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

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

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

Роли и привилегии пользователей WordPress

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

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

  • Суперадмин — сетевой администратор сайта.
  • Администратор — администратор сети сайта для одного сайта.
  • Редактор — управляйте и публикуйте сообщения, в том числе сообщения других пользователей.
  • Автор — управляйте и публикуйте собственные сообщения
  • Участник — пишите и управляйте собственными сообщениями, но не публикуйте их.
  • Подписчик – только управление профилем

Примером того, как это работает на практике, является то, что, хотя Участник и Автор могут совместно использовать некоторые возможности (например, редактировать сообщения и удалять сообщения), Участник не может делать все, что может Автор, например загружать файлы или создавать полезные блоки.

Создание пользовательских ролей

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

Вот несколько распространенных вариантов использования:

  • В более крупных организациях вам может потребоваться назначить кого-то из вашей маркетинговой команды для модерации, утверждения и ответа на комментарии. Возможность «модерировать комментарии» находится в роли редактора, но эта роль также назначает целый ряд других мощных возможностей. Итак, если это все, что им нужно сделать, то достаточно настроить пользовательскую роль с этим единственным разрешением.
  • Если ваш сайт WordPress содержит плагин для электронной коммерции, такой как WooCommerce, вы ограничены двумя первоначальными ролями: менеджер магазина (позволяющий пользователю управлять всем магазином) и покупатель (позволяющий пользователю просматривать свою учетную запись и заказы). Администратор имеет дополнительные права, такие как «управление настройками» и «просмотр отчетов». Но что, если вашим пользователям — например, неруководящему персоналу — требуется что-то среднее, например, возможность добавлять и управлять количествами запасов или артикулами или просто обрабатывать заказы?
  • На нашем веб-сайте мы используем плагин для статей нашей базы знаний. Это дает нашей команде поддержки доступ к созданию и изменению статей базы знаний, но не доступ к основным страницам веб-сайта и сообщениям в блогах.

Рекомендации

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

Дополнительные сведения см. в разделе Как использовать роли пользователей WordPress для повышения безопасности WordPress.

Разрешения на файлы и каталоги

Легко настроить права доступа к файлам и каталогам, и в Интернете доступно достаточно документации, объясняющей, как усилить разрешения вашей установки WordPress. WordPress работает на любой ОС с PHP, обычно на Linux. Что касается групп, в Linux есть три группы разрешений:

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

Каждому из них назначается разрешение на чтение (просмотр содержимого), запись (запись или изменение содержимого) или выполнение (запуск содержимого, например скрипта). Эти разрешения хранятся в виде набора чисел и дают доступ к коду PHP, изображениям и другим медиафайлам, файлам HTML и javascript, а также к плагинам.

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

Рекомендации

При установке WordPress вы также должны использовать PoLP, настроив минимально возможные права доступа к файлам и каталогам для работы WordPress.

Помните, что, усиливая права доступа к файлам и каталогам, вы также можете ограничить работу некоторых плагинов WordPress. Как объяснялось ранее, вы можете устанавливать плагины, которым необходимо хранить данные в своем установочном каталоге. Если это так, не настраивайте просто разрешения 777 для каталога плагинов (полное чтение, запись и выполнение для всех, у кого есть права на его управление). Это легкий выход. Но вам также не следует ограничивать его до такой степени, что это не позволит соответствующим пользователям обновлять WordPress, его темы и плагины из веб-интерфейса.

Для получения дополнительной информации см. Права доступа к файлам WordPress: руководство по настройке разрешений безопасного веб-сайта и веб-сервера.

Настройка плагинов WordPress

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

Рекомендации

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

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

Доступ по FTP для сторонних подрядчиков

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

Рекомендации

В случае дизайнера все, к чему им нужен доступ, — это каталог темы, поэтому ограничьте доступ к этому каталогу. То же самое относится и к группам поддержки плагинов. Если им нужен доступ для проверки файлов журналов, предоставьте им FTP-доступ к каталогу подключаемого модуля или к месту, где подключаемый модуль хранит файлы журналов. Избегайте зависимости от внешних сторон, которые должны выполнять комплексную проверку безопасности для вас.

Мини-кейсы

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

Приложения для веб-сайтов электронной коммерции

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

Некоторые решения по управлению доступом для разработчиков приложений для веб-сайтов электронной коммерции очевидны:

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

Некоторые из них менее очевидны:

  • Нужен ли потребителям постоянный доступ ко всем их данным?
  • Нужен ли специалистам по соответствию PCI-DSS доступ ко всем данным потребителей?

Университеты и учебные заведения

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

Некоторые решения по управлению доступом к порталам университетов и колледжей очевидны:

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

Некоторые из них менее очевидны:

  • Каким сторонним поставщикам, например поставщикам электронных карт, может потребоваться периодический доступ к некоторым таблицам данных учащихся?

Новостные сайты и блоги

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

Некоторые решения по управлению доступом для новостных и блоговых веб-приложений очевидны:

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

Некоторые из них менее очевидны:

  • Нужен ли всем третьим сторонам доступ к каждой таблице в базе данных WordPress? Здесь на помощь приходят настраиваемые элементы управления.

Банковские сайты

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

Некоторые из решений по управлению доступом для создания веб-приложений очевидны:

  • Ни один пользователь банковских услуг не должен иметь доступ к учетной записи другого пользователя, кроме как с явного (вероятно, контролируемого пользователем) согласия.
  • Учетные записи сотрудников должны иметь доступ ко многим учетным записям пользователей службы, но только к тем задачам, которые им необходимо выполнять в рамках своей работы.

Некоторые из них менее очевидны:

  • Какой доступ должны иметь отделы технической поддержки? Должны ли они иметь возможность просматривать и исправлять все в случае ошибок?

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

Трекеры здоровья и фитнеса

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

Некоторые из решений по контролю доступа для брендов трекеров здоровья и фитнеса очевидны:

  • Каким командам внутри организации нужен доступ к каким данным? Имеет смысл, что если одна команда отвечает за дизайн и разработку части приложения для отслеживания сна, им не обязательно нужен доступ к таблицам статистики тренировок.
  • Большинство пользователей захотят, чтобы PoLP (независимо от того, знают они об этом или нет) был очень строгим, чтобы информация об их здоровье не передавалась никому другому пользователю. Итак, какие привилегии доступа должны быть предоставлены обычной роли пользователя и какие данные, следовательно, будут доступны для общего доступа в общедоступном профиле (только имя, изображение профиля и среднее количество шагов за день?).

Некоторые из них менее очевидны:

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

Использование принципа наименьших привилегий для WordPress и не только

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

Чтобы приступить к внедрению PoLP, начните с рассмотрения того, что вы хотите сделать со следующими пунктами:

  • Веб-сервер
  • База данных
  • Настройки

Не уклоняйтесь от применения принципа наименьших привилегий просто потому, что сразу ничего не получается. Да, большую часть времени вам придется потратить несколько часов на настройку пользовательских ролей и плагинов для устранения неполадок. Воспринимайте это как долгосрочную инвестицию в безопасность ваших веб-сайтов WordPress.