Переменная среды Windows и файл конфигурации - PullRequest
2 голосов
/ 25 февраля 2012

Есть веб-приложение, над которым я работаю.Это PHP на основе веб-сервера Apache.

На производственных серверах приложение извлекает некоторую «конфиденциальную» информацию, такую ​​как пароль для базы данных и имя пользователя базы данных, из переменных среды Windows.Это делается вместо того, чтобы помещать информацию в конфигурационный файл в приложении.

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

Вот мое мнение:

Недостатки

  1. Любой, кто получает доступ к машине Windows, может просто зайти в переменные среды Windows и в любом случае увидеть их.

  2. Изменить информацию невозможнобез выключения сервера.Были случаи, когда мы меняли переменные среды и вынуждены были полностью отключить apache, чтобы он полностью перезагрузил новые значения.

Преимущества

  1. При переходе от dev к qa к компьютерам prod файлы конфигурации приложения не должны изменяться, поскольку на каждом сервере уже установлены необходимые данные в переменных среды.(Мне не нужно «помнить», чтобы использовать правильный файл конфигурации, потому что переменные среды уже установлены для каждого сервера).

  2. Безопасность может быть усилена, так что только администраторы могут видетьпеременные среды.Не уверен, что Windows может сделать это, но я уверен, что есть некоторые изменения реестра, которые могут это позволить.

Какова ваша точка зрения?

Ответы [ 3 ]

1 голос
/ 25 февраля 2012

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

Вы можете сделать это, используя файл для хранения контента, например, файл config.php, который имеет соответствующий контроль доступа.Ограничьте область действия этого файла настройкой только этого ограниченного числа параметров, которые должны быть защищены. Например,

<?php
$DBuser   = "abd";
$DBpasswd = 'fred:ere12#';

Это может быть скомпрометировано только тем, кто на сервере имеет доступ для чтения к файлу.(Даже если он находится в каталоге, доступном через Интернет, доступ к нему по URI не приведет к раскрытию этой информации. Вы понимаете, почему?)

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

На самом деле в моих приложениях я использую немного другой подход, который я привожу в качестве примера.Я использую определения (приложения OO OO и не используют глобальные переменные) в небольшом загрузочном файле index.php и храню все остальные данные конфигурации в моем D / B

<?php
define( 'SQL_CONTEXT', 'DB:user:pwd:tableprefix' );
define( 'ROOT_DIR', dirname(__FILE__) );
define( 'START_TIME', microtime() );
// a couple of other app-specific defines go here

if( ( @include( "./_cache/dispatcher.class.php" ) ) != 1 ) {
    require("./_include/functions.php");
}

Dispatcher::dispatch();

Это сборка для dev, мойпротестируйте ВМ и выполните установочный скрипт, который имеет некоторые правки для вставки этой конфиденциальной информации в APPROOT / index.php, так что мне не нужно хранить эту конфиденциальную информацию в моем git хранилище.

0 голосов
/ 11 октября 2013

Предполагается, что архитектура Windows NT (8, 7, Vista, XP ...)

Если у пользователя A есть переменная среды пользователя USER "PASSWORD", то пользователь B (не являющийся администратором) не сможет прочитать пользователя AUSER-переменная среды "PASSWORD", поэтому она безопасна, если пользователь B. не является администратором.

Вы должны запускать разные программы под разными пользователями.

Вы также должны защищать физический доступ к своим компьютерам.

0 голосов
/ 25 февраля 2012

Я бы выбрал, что больше оперативно удобно для вас (звучит так, что переменные среды делают вашу жизнь проще - иди вперед) ...

... а затем зашифровать текстовую строку.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...