Управление базами данных через консольные клиенты вроде mysql или psql - дело привычное и в чём-то даже медитативное, но не всегда удобное. Когда нужно быстро посмотреть структуру таблицы, пробежаться по результатам сложного запроса или наглядно показать данные коллеге, графический интерфейс выручает в разы. Среди подобных инструментов давно правит phpMyAdmin, но у него есть младший брат, которого многие незаслуженно обделяют вниманием - и зря. Adminer (раньше его называли phpMinAdmin) умудряется делать всё то же самое, что и его раздутый старший товарищ, но при этом весит как пушинка.
Adminer - это полноценный веб-инструмент для администрирования баз данных, который поддерживает целый зоопарк систем хранения. Тут и классические реляционные движки (MySQL/MariaDB, PostgreSQL, SQLite, MS SQL, Oracle), и через подключаемые плагины даже NoSQL-решения вроде MongoDB. Получается универсальный пульт управления для разнородной инфраструктуры, где живут несколько типов баз сразу.
Главная фишка Adminer заключается в его аскетизме. Весь инструмент - это один-единственный PHP-файл размером в пару сотен килобайт. Никаких десятков подкаталогов с тысячами скриптов, никакой сложной системы шаблонов и многоступенчатой инициализации. Распространяется проект под лицензией Apache (или GPL v2 на выбор), что снимает любые юридические вопросы при использовании в коммерческих проектах. Ниже разобран процесс установки на свежий Ubuntu 22.04 с пошаговой настройкой защиты от любопытных глаз.
Подготовительные требования и базовое окружение для развёртывания веб-инструмента работы с базами
Чтобы пройти этот путь без сюрпризов, понадобится сервер на Ubuntu 22.04 - желательно свежий, без хвостов от предыдущих экспериментов. Доступ должен быть с правами обычного пользователя, у которого есть возможность повышать привилегии через sudo. Постоянная работа из-под root считается дурным тоном с давних времён, и эта привычка никуда не делась.
Также на машине должен быть установлен сервер базы данных, к которому Adminer будет подключаться. Поддерживаются разные СУБД из реляционного семейства - MySQL/MariaDB, PostgreSQL, SQLite3, OracleDB. Сама по себе инсталляция Adminer не требует определённой базы заранее, поскольку при её установке apt автоматически подтягивает PHP-драйверы для всех популярных систем. Но смысл инструмента в том, чтобы куда-то ходить за данными, поэтому какая-то СУБД должна быть в наличии или появиться позже.
Apache2 в этом руководстве выступает веб-сервером по умолчанию. Если предпочтителен Nginx, общая логика настройки сохраняется, но конкретные конфигурационные блоки придётся переписать под синтаксис другого сервера.
Установка пакета Adminer из стандартного репозитория Ubuntu и активация конфигурации Apache
Хорошая новость - на современных Ubuntu, начиная с 22.04, Adminer уже лежит в стандартном репозитории Universe. Никаких сторонних PPA подключать не нужно, и обновления приходят вместе с системными - удобно с точки зрения безопасности, поскольку патчи устанавливаются по тому же конвейеру, что и для всего остального ПО.
Освежаем индекс пакетов перед установкой:
sudo apt update
Эта команда обращается к серверам репозитория и подтягивает актуальный список доступных версий. Без неё apt может пытаться поставить устаревший пакет или вообще не найти нужный. Привычка обновлять индекс перед установкой экономит часы будущих разбирательств.
Можно сначала посмотреть, что именно за пакет лежит в репозитории:
sudo apt info adminer
Команда показывает версию (на момент написания материала это была v4.8), категорию репозитория (universe/web) и список зависимостей. В зависимостях фигурируют PHP-драйверы для разных СУБД - php-mysql, php-pgsql, php-sqlite3 и так далее. apt подтянет их автоматически при установке, так что отдельно беспокоиться о драйверах не нужно.
Сама установка:
sudo apt install adminer
При запросе подтверждения нажимаем Y и Enter. Менеджер пакетов выкачает Adminer и все зависимости, развернёт файлы в нужных местах файловой системы и подготовит конфигурацию для Apache.
После установки нужно активировать конфигурационный файл, который пакет положил в каталог conf-available, но не подключил автоматически:
sudo ln -s /etc/apache2/conf-available/adminer.conf /etc/apache2/conf-enabled/
Эта команда создаёт символическую ссылку из conf-enabled на конфиг в conf-available. Такая двухуровневая схема - стандартная практика Apache в Debian-подобных дистрибутивах. В conf-available лежат все возможные конфигурации, а в conf-enabled только те, которые реально работают. Удалить ссылку - и конфигурация выключена, не теряя сам файл.
Проверяем, что синтаксис конфигурации в порядке:
sudo apachectl configtest
Утилита разбирает все конфиги Apache и выдаёт Syntax OK при удачной проверке. Если что-то не так, в выводе появится конкретная строка с ошибкой - очень удобно для быстрой диагностики.
Перезапускаем веб-сервер для применения изменений:
sudo systemctl restart apache2
Теперь Adminer доступен по адресу вида http://192.168.5.75/adminer (адрес заменяется на реальный IP сервера). При открытии браузера откроется страница входа с полями для выбора типа СУБД, адреса сервера, имени пользователя, пароля и базы данных.
Вот тут проявляется одно из главных преимуществ Adminer перед конкурентами. phpMyAdmin работает только с MySQL/MariaDB, pgAdmin только с PostgreSQL. А Adminer на одной и той же странице входа позволяет выбрать любую из поддерживаемых СУБД и подключиться к ней. Получается универсальный пульт, к которому не нужно отдельно изучать интерфейс под каждую базу.
Защита установки через смену стандартного URL пути и подключение базовой авторизации Apache
После установки Adminer работает на всем известном пути /adminer. Это удобно для запоминания, но опасно с точки зрения безопасности. Любой автоматический сканер уязвимостей в первую очередь проверяет именно стандартные пути - /admin, /phpmyadmin, /adminer, /wp-admin и так далее. Если оставить настройки по умолчанию, в логах сервера через пару дней появится поток подозрительных запросов от ботов, которые перебирают пароли.
Защита выстраивается в два слоя. Первый - смена стандартного URL на нестандартный. Второй - дополнительная авторизация на уровне веб-сервера до того, как пользователь увидит даже страницу входа в Adminer. Каждый слой по отдельности уже отсекает большинство автоматических атак, а вместе они дают серьёзную защиту даже от целенаправленных попыток.
Изменение стандартного пути доступа к Adminer через правку конфигурации Apache
Открываем файл конфигурации:
sudo nano /etc/apache2/conf-available/adminer.conf
В верхней части файла находится директива Alias, которая определяет, по какому URL будет доступен Adminer. По умолчанию там что-то вроде Alias /adminer /etc/adminer. Меняем путь на свой собственный, желательно неочевидный для сторонних:
Alias /mydbadmin /etc/adminer
В этом примере выбран путь /mydbadmin, но в реальности стоит использовать что-то менее предсказуемое. Хорошие варианты - комбинации букв и цифр без явного смысла, например /db-x7k29 или /panel-93qz. Чем меньше путь похож на стандартное название, тем выше шанс, что автоматические сканеры его не найдут.
Сохраняем файл и закрываем редактор. Проверяем синтаксис:
sudo apachectl configtest
Если в ответе Syntax OK - значит правка корректна. Перезапускаем веб-сервер:
sudo systemctl restart apache2
Теперь Adminer доступен только по новому пути. Старый /adminer больше не работает, и попытки обратиться к нему вернут 404. Это первый рубеж обороны - ботам, которые сканируют стандартные пути, теперь нечего ловить.
Подключение базовой авторизации Apache через модуль basic_auth для двойного уровня защиты
Смена пути - хорошо, но недостаточно. Если злоумышленник как-то узнает новый адрес (через украденный конфиг, неосторожно сохранённую закладку, ошибку администратора), путь перестанет защищать. Поэтому добавляется второй слой - HTTP Basic Authentication на уровне Apache. Это значит, что прежде чем веб-сервер вообще начнёт отдавать страницу Adminer, он спросит пользователя у браузера и пароль.
Создаём файл с пользователями для базовой авторизации:
sudo htpasswd -B -c /etc/adminer/.htpasswd dbadmin
Разберём флаги по порядку. Параметр -B заставляет htpasswd использовать алгоритм bcrypt для хеширования пароля - это самый стойкий из доступных алгоритмов, существенно медленнее устаревшего MD5. Опция -c (от create) создаёт новый файл с пользователями. Если файл уже существует и нужно просто добавить ещё одного пользователя, опцию -c использовать нельзя, иначе старые записи будут затёрты. Имя dbadmin - просто пример, можно выбрать любое.
Команда запросит пароль и подтверждение. Стоит выбрать длинный сложный пароль, причём не совпадающий с паролем самой базы данных. Получится двойной барьер - сначала Apache проверит один пароль, потом Adminer проверит другой при входе в БД.
Если в дальнейшем нужно добавить ещё пользователей в тот же файл, команда выглядит без флага -c:
sudo htpasswd -B /etc/adminer/.htpasswd newuser
Теперь подключаем созданный файл к конфигурации Apache. Открываем тот же конфиг:
sudo nano /etc/apache2/conf-available/adminer.conf
Добавляем блок Location с настройками авторизации:
<Location /mydbadmin>
AuthType Basic
AuthName "Restricted Resource"
AuthBasicProvider file
AuthUserFile /etc/adminer/.htpasswd
Require valid-user
</Location>
Разберём построчно. Директива AuthType Basic выбирает простейший тип HTTP-авторизации - тот самый, при котором браузер показывает всплывающее окно с двумя полями. Параметр AuthName задаёт текст, который видит пользователь в этом окне (Restricted Resource - просто пример, можно написать что угодно). AuthBasicProvider file говорит Apache, что пользователи хранятся в обычном файле, а не в LDAP или базе данных. AuthUserFile указывает путь к файлу с пользователями. Наконец, Require valid-user разрешает доступ любому пользователю из файла, который введёт правильный пароль.
Сохраняем файл и проверяем синтаксис:
sudo apachectl configtest
Перезапускаем Apache:
sudo systemctl restart apache2
Теперь при попытке открыть Adminer браузер сначала покажет диалог HTTP-авторизации. Только после ввода логина dbadmin и правильного пароля пользователь попадёт на страницу входа в саму базу данных. Получается тот самый двойной барьер - неправильный пароль на первом шаге даже не даёт увидеть форму входа Adminer, а уж о попытках перебора паролей самой базы и речи нет.
Настройка пользователя MariaDB на отдельном сервере для удалённого подключения через Adminer
В реальной инфраструктуре Adminer часто стоит на одном сервере, а собственно базы данных - на других. Это разумно с точки зрения безопасности (компрометация веб-инструмента не даёт прямого доступа к данным) и удобно с точки зрения распределения нагрузки. Разберём настройку именно такого сценария на примере MariaDB.
По умолчанию MariaDB слушает только локальный интерфейс 127.0.0.1, что отрезает любые удалённые подключения. Меняем это в конфиге:
sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf
Находим параметр listen и меняем его на приватный IP сервера базы данных:
listen = 192.168.5.20
В этом примере MariaDB живёт на адресе 192.168.5.20. Важно - используется именно приватный IP внутри корпоративной сети. Открывать MariaDB на публичном интерфейсе категорически нельзя, это прямой путь к катастрофе. Если связь между сервером Adminer и сервером БД должна идти через интернет, схема меняется кардинально - туннель через SSH, VPN или хотя бы TLS-шифрование самого подключения к базе.
Сохраняем файл и перезапускаем MariaDB:
sudo systemctl restart mariadb
Подключаемся к консоли базы данных:
sudo mysql -u root -p
Создаём пользователя, привязанного к конкретному IP-адресу - тому, с которого будет ходить Adminer. В этом примере сервер с Adminer имеет адрес 192.168.5.75:
CREATE USER 'dbadmin'@'192.168.5.75' IDENTIFIED BY 'dbpassword';
GRANT ALL PRIVILEGES ON *.* TO 'dbadmin'@'192.168.5.75' WITH GRANT OPTION;
FLUSH PRIVILEGES;
Запись 'dbadmin'@'192.168.5.75' означает, что пользователь dbadmin сможет подключаться только с адреса 192.168.5.75. Если кто-то узнает пароль и попробует зайти с другого IP - получит отказ. Это ещё один слой защиты, который часто недооценивают. Стандартная ошибка новичков - создавать пользователей с маской '%', которая разрешает подключение с любого адреса. Удобно, но крайне опасно.
Параметр IDENTIFIED BY 'dbpassword' задаёт пароль (в реальной работе нужен длинный сложный пароль, не совпадающий ни с одним другим в инфраструктуре). GRANT ALL PRIVILEGES ON . выдаёт полные права на все базы - в боевом окружении лучше выдавать только нужные права на конкретные базы, но для роли администратора такой подход допустим. WITH GRANT OPTION позволяет пользователю в свою очередь раздавать права другим - это нужно, если dbadmin будет создавать новых пользователей через интерфейс Adminer.
Проверяем, что права выданы корректно:
SHOW GRANTS FOR Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript. ;
quit
В выводе должны быть видны все выданные привилегии. После проверки выходим из консоли командой quit.
Дополнительный слой защиты - правила брандмауэра UFW. Если на сервере MariaDB включён UFW, имеет смысл явно разрешить подключения к порту 3306 только с адреса сервера Adminer:
sudo ufw allow from 192.168.5.75 to 192.168.5.20 port 3306 proto tcp comment 'allow mysql access for Adminer'
sudo ufw reload
Команда выглядит длинно, но логика прозрачная. Параметр from 192.168.5.75 ограничивает источник, to 192.168.5.20 указывает целевой адрес, port 3306 proto tcp - порт и протокол, comment добавляет описание для удобства аудита. После reload правила применяются.
Проверяем результат:
sudo ufw status
В списке должна появиться новая запись с разрешением для адреса Adminer и портом MariaDB. Все остальные попытки подключения к 3306 будут отбрасываться брандмауэром на лету, не доходя даже до самой базы данных.
Подключение к удалённому серверу MariaDB через веб-интерфейс Adminer и работа с базами
Открываем браузер и переходим на адрес Adminer (с учётом нового пути и базовой авторизации). После прохождения первого экрана авторизации Apache попадаем на страницу входа Adminer.
Выбираем тип базы (MySQL/MariaDB), указываем адрес сервера 192.168.5.20 в поле Server, имя пользователя dbadmin, тот пароль, который задавался при создании пользователя через CREATE USER. Поле Database можно оставить пустым - тогда после входа будет виден список всех доступных баз. Жмём Login.
После успешного подключения открывается панель Adminer со списком баз данных. В правом верхнем углу видна версия сервера и текущий пользователь - удобная подсказка для тех, кто параллельно работает с несколькими установками. Дальше начинается обычная работа с базами - создание таблиц, выполнение SQL-запросов, экспорт и импорт данных, управление пользователями.
Интерфейс Adminer построен максимально просто. Никаких многоуровневых меню и скрытых настроек - всё необходимое доступно с главной страницы каждой сущности. SQL-команда выполняется через кнопку SQL command, экспорт через Export, поиск по таблицам через стандартный фильтр. Те, кто привык к phpMyAdmin, освоятся за десять минут, причём с приятным удивлением от того, насколько быстрее всё работает.
Распространённые подводные камни и практические наблюдения из реальной эксплуатации Adminer
В копилку наблюдений из практики стоит добавить несколько моментов, на которых обжигаются те, кто впервые поднимает Adminer в боевом окружении.
Первая частая проблема - забытое подключение HTTPS. HTTP Basic Authentication передаёт логин и пароль почти в открытом виде (всего лишь base64-кодирование, которое расшифровывается за секунду). Если Adminer работает по обычному HTTP без шифрования, любой сниффер на пути от клиента до сервера увидит и пароль базовой авторизации, и пароль базы данных. Лекарство простое - обязательно подключать TLS через Let's Encrypt и переводить весь трафик на HTTPS. Без этого все слои защиты, которые мы выстраивали, превращаются в иллюзию.
Вторая популярная грабля связана с правами выданного пользователя. Привычка делать grant all privileges на всё подряд приводит к тому, что любая компрометация Adminer открывает злоумышленнику дорогу к удалению целых баз. Разумная практика - создавать отдельных пользователей под отдельные задачи. Пользователь для разработчика получает права только на его рабочую базу. Аналитик получает только select на боевую базу без возможности менять данные. Отдельный административный пользователь существует на крайний случай и используется редко.
Третий момент касается журналирования. Apache по умолчанию пишет в access.log все обращения, включая попытки авторизации. Стоит периодически пробегать глазами по этим логам или настраивать автоматическое оповещение при многократных неудачных попытках входа. Скрипт fail2ban с правилом для базовой авторизации Apache отлично справляется с автоматической блокировкой адресов, которые перебирают пароли.
Четвёртая тонкость - ограничение доступа на сетевом уровне. Если Adminer нужен только для команды разработчиков, имеет смысл добавить в конфигурацию Apache директивы Require ip с конкретными адресами офиса или VPN-сети. Это отрезает доступ для всего остального интернета на самом раннем этапе, ещё до проверки авторизации. Получается третий слой защиты после смены пути и базовой аутентификации.
Где такая инсталляция пригодится в реальной жизни? Сценариев масса. Маленькие команды разработчиков, которым нужен лёгкий веб-интерфейс к нескольким базам без накладных расходов на phpMyAdmin или DBeaver. Хостинговые компании, предоставляющие клиентам базовый доступ к их базам через веб. Аналитики, работающие с разными СУБД одновременно и не желающие держать на машине отдельные клиенты под каждую систему. Удалённые филиалы, где нужно дать пользователям возможность работать с базами через стандартный браузер без дополнительного софта.
Освоение Adminer даёт инженеру не просто навык установки одного инструмента, а понимание целого пласта практик веб-администрирования. Те же концепции - смена стандартных путей, базовая авторизация Apache, ограничение доступа по IP, настройка пользователей баз данных под конкретные источники подключений - применимы к любым другим веб-приложениям. Тот, кто разобрался с защитой Adminer, без труда настроит безопасный доступ к Webmin, Cockpit, Grafana или любой другой админ-панели. И за лёгкостью этого крошечного PHP-файла скрывается зрелая инженерная философия - делать одну вещь, делать её хорошо, не раздуваясь до неузнаваемости. Именно поэтому Adminer уже больше десяти лет остаётся верным помощником тех, кто ценит простоту и надёжность выше броских функций и пёстрых интерфейсов.
Канал сайта в Telegram
Канал сайта на YouTube