Как лучше всего хранить данные для доступа к api?

Question

[Roman]

Добрый день. Есть вот такой код

define( 'B_LOGIN', get_theme_mod( 'b_p_login', '3333@3333' ) );
	define( 'B_PASS', get_theme_mod( 'b_p_pass', '22222 ) );
	define( 'B_TOKEN', get_theme_mod( 'b_p_token', '11111' ) );

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

Что советую ChatGPT (Установи переменные среды на своем сервере:)

Для установки переменных среды на сервере, тебе понадобится доступ к терминалу или консоли сервера. Вот как это можно сделать для UNIX-подобных систем (например, Linux):

Открой терминал или консоль:

Подключись к серверу через SSH (Secure Shell) с помощью программы типа PuTTY (для Windows) или терминала (для macOS и Linux).
Используй команду export:

Чтобы установить переменную среды, используй команду export. Например:
export B_P_LOGIN=your_login
Проверь установленные переменные:

Чтобы проверить установленные переменные среды, используй команду env или echo $B_P_LOGIN для проверки конкретной переменной.
Сделай перманентные изменения (опционально):

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

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

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

Насколько стабильны переменные среды, не потеряет ли их хостер при миграции. Интересует best practices

Answer 1

[rPman]

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

Самое простое, размести свой config файл где-нибудь вне каталога с исходными файлами (например в /etc/ ) а в проекте размещай и поддерживай config.example со всеми доступными настройками с комментариями (грустно, что этот момент часто забывают и не документируют, и приходится выковыривать нужные настройки из исходников)

Еще можно использовать другие способы, которые можно привязать к конкретному серверу и его установке, если по простому, то действительно - разместить в переменных окружения (.bashrc пользователя, под которым будет запускаться сервис), это удобно, потому как машина разработчика работает с одними базами данных, а production версия - с другими.
p.s. лично мне не очень нравится хранение чего либо в переменных окружения, особенно если данных много, так как они будут все копироваться в память каждому приложению, запускаемому от этого пользователя, так же были разные уязвимости, позволяющие вытаскивать именно переменные окружения сетевым запросом.

Так же существуют готовые централизованные инструменты по хранению и управлению такими данными (например централизованно отозвать доступ у машины, или сменить пароль и т.п.) типа azure key vault.

Answer 2

[pantsarny]

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

Comments

[pantsarny]

Понятно что хардкодить креды в коде - зло. Как минимум .env который не попадёт в гит по правилам игнора

Answer 3

[yarovikov]

Eсли используешь sage, то в env.
Если нет, то в бд (я обычно делал страницу настроек в админке под такие данные)