alekciy
Новичок
Я понимаю, что для начинающих вопрос в принципе не возникает, а продвинутые используют один_сервер_(дедик/виртуальный)-один_проект и им вопрос не актуален, но тем не менее решил озадачить таким вопросом.
Представим контекст из двух сайтов и двух независимых разработчиках (фрилансеры, люди сторонние, т.е. потенциально ненадежные) каждый из которых работает только со своим сайтом и не должен иметь возможности вмешаться в работу другого. Доступа к конфигурированию самого сервера ни кто из них не имеет. У каждого свой ftp аккаунт находящийся в chroot внутри директории сайта, но сам php за-chroot-тен выше директорий сайтов, т.е. php доступа к серверу не имеет, но потенциально из php скрипта можно залезть в директорию чужого сайта. По сути - схема шаред хостинга.
Связка nginx и php-fpm с прописанным для каждого пула системным юзером + правильная настройка прав на файлы позволяет разграничить файлы двух сайтов с тем, что бы системный юзер одного сайта не мог править или даже видеть файлы (к примеру, файл конфигурации) другого. Ни какой suhosin патч для обеспечения безопасности не требуется, все срабатывает на уровне ОСи и прав доступа к файлам. Т.е. php скрипт одного сайта не может прочесть скрипты другого сайта.
Используя redis можно получить неплохой кэш кроме того в нем можно хранить сессии. Но в контексте предшествующего абзаца и отсутствия в самом redis возможности задания привязки аккаунта к определенной базе получается, что имеем дыру. Даже если сайты будут находится каждый в своей redis базе, ни что не мешает сделать SELECT, выбрать базу другого сайта и копаться в ней.
Возникает вопрос, как их максимально безопасно разграничить. На вскидку возникает только два варианта.
Вариант 1. Каждому сайту запускать свою копию redis-а. Соответственно в init.d скриптах заводить по отдельному скрипту с запуском отдельной копии redis. Плюсы и минусы:
+ полное разделение каждого сайта (все права доступа вполне настраиваемы до уровня привязки к конкретному системному юзеру);
- "усложнение" администрирования, в кавычках потому как условно ибо можно создать скрипт генерации нужного init скрипта;
- большее потреблении ОЗУ, понятно, что для двух сайтов не критично, но если их со временем станет несколько сотен? (хотя если я не ошибаюсь, ОС linux сама в ОЗУ занесет только одну копию кода redis сервера и реальное потребление ОЗУ будет меньше, чем количество_сайтов*количество_ОЗУ_под_redis);
Вариант 2. Для всех сайтов работает одна копия redis. Но через rename-command в файле конфигурации команда SELECT переименовывается. Реквизитов доступа к redis разработчики сайтов не знают и используют класс-прослойку код которого зашифрован через Zend Encoder и в этом классе захардкожено новое имя для SELECT. Класс сам выбирает требуемую базу. Соответственно разработчики самостоятельно не смогут выбрать чужую redis базу. Плюсы и минусы:
+ с точки зрения администрирования практически ни каких изменений;
- потенциально возможность смены базы остается ибо ограничена только незнанием разработчиков нового имени команды SELECT;
- логика класса-прослойки по сути сосредоточена в двух местах, в самом классе и в файле конфигурации redis, если нужно будет еще раз сменить имя команды, то правку нужно будет не забыть внести в два места;
- при добавлении новых сайтов нужно будет править и код класса-прослойки.
Вариант 1 видится более предпочтительным, но смущает увеличение потребления ОЗУ под такую схему. Вариант 2 более "привычен", т.к. один сервис - один процесс, но потенциально видится не совсем безопасным. Опять же, если linux будет гарантированно держать в ОЗУ одну копию кода сервера в случае запуска нескольких инстансов, то следует использовать без раздумий вариант 1, имхо.
Есть ли другие варианты? Ну пустил ли я чего для приведенных вариантов? Вообще, есть ли какие либо комментарии?
Представим контекст из двух сайтов и двух независимых разработчиках (фрилансеры, люди сторонние, т.е. потенциально ненадежные) каждый из которых работает только со своим сайтом и не должен иметь возможности вмешаться в работу другого. Доступа к конфигурированию самого сервера ни кто из них не имеет. У каждого свой ftp аккаунт находящийся в chroot внутри директории сайта, но сам php за-chroot-тен выше директорий сайтов, т.е. php доступа к серверу не имеет, но потенциально из php скрипта можно залезть в директорию чужого сайта. По сути - схема шаред хостинга.
Связка nginx и php-fpm с прописанным для каждого пула системным юзером + правильная настройка прав на файлы позволяет разграничить файлы двух сайтов с тем, что бы системный юзер одного сайта не мог править или даже видеть файлы (к примеру, файл конфигурации) другого. Ни какой suhosin патч для обеспечения безопасности не требуется, все срабатывает на уровне ОСи и прав доступа к файлам. Т.е. php скрипт одного сайта не может прочесть скрипты другого сайта.
Используя redis можно получить неплохой кэш кроме того в нем можно хранить сессии. Но в контексте предшествующего абзаца и отсутствия в самом redis возможности задания привязки аккаунта к определенной базе получается, что имеем дыру. Даже если сайты будут находится каждый в своей redis базе, ни что не мешает сделать SELECT, выбрать базу другого сайта и копаться в ней.
Возникает вопрос, как их максимально безопасно разграничить. На вскидку возникает только два варианта.
Вариант 1. Каждому сайту запускать свою копию redis-а. Соответственно в init.d скриптах заводить по отдельному скрипту с запуском отдельной копии redis. Плюсы и минусы:
+ полное разделение каждого сайта (все права доступа вполне настраиваемы до уровня привязки к конкретному системному юзеру);
- "усложнение" администрирования, в кавычках потому как условно ибо можно создать скрипт генерации нужного init скрипта;
- большее потреблении ОЗУ, понятно, что для двух сайтов не критично, но если их со временем станет несколько сотен? (хотя если я не ошибаюсь, ОС linux сама в ОЗУ занесет только одну копию кода redis сервера и реальное потребление ОЗУ будет меньше, чем количество_сайтов*количество_ОЗУ_под_redis);
Вариант 2. Для всех сайтов работает одна копия redis. Но через rename-command в файле конфигурации команда SELECT переименовывается. Реквизитов доступа к redis разработчики сайтов не знают и используют класс-прослойку код которого зашифрован через Zend Encoder и в этом классе захардкожено новое имя для SELECT. Класс сам выбирает требуемую базу. Соответственно разработчики самостоятельно не смогут выбрать чужую redis базу. Плюсы и минусы:
+ с точки зрения администрирования практически ни каких изменений;
- потенциально возможность смены базы остается ибо ограничена только незнанием разработчиков нового имени команды SELECT;
- логика класса-прослойки по сути сосредоточена в двух местах, в самом классе и в файле конфигурации redis, если нужно будет еще раз сменить имя команды, то правку нужно будет не забыть внести в два места;
- при добавлении новых сайтов нужно будет править и код класса-прослойки.
Вариант 1 видится более предпочтительным, но смущает увеличение потребления ОЗУ под такую схему. Вариант 2 более "привычен", т.к. один сервис - один процесс, но потенциально видится не совсем безопасным. Опять же, если linux будет гарантированно держать в ОЗУ одну копию кода сервера в случае запуска нескольких инстансов, то следует использовать без раздумий вариант 1, имхо.
Есть ли другие варианты? Ну пустил ли я чего для приведенных вариантов? Вообще, есть ли какие либо комментарии?
)