Вопрос или проблема
У меня есть проект, который требует подхода, который я никогда не использовал ранее.
У меня есть приложение, к которому можно получить доступ только через имя пользователя/пароль/многофакторную аутентификацию. В приложении есть раздел для управления веб-сайтом (CMS), т.е. настройки, страницы, посты и т.д. Думайте о WordPress, но это не WordPress.
Файлы публичного веб-сайта в данный момент находятся в подпапке частного приложения и имеют свой собственный htaccess, env файлы и т.д. Когда пользователи в защищенном CMS вносят изменения в контент, это обновляет файлы публичного веб-сайта в области частного приложения.
Я настроил Docker для обслуживания как частного приложения, так и публичных веб-сайтов в разных контейнерах и портах.
Мой вопрос: существует ли риск того, что пользователи смогут получить доступ к файлам в частном приложении, если публичный сайт находится внутри подпапки частного приложения?
Я работал с виртуальными хостами с разными доменами и разными папками, однако никогда не использовал “виртуальные хосты” внутри подпапок. Ограничен ли доступ только к папке родительского виртуального хоста? Я знаю, что в PHP можно ввести DIR, чтобы получить директорию, или $_SERVER[‘DOCUMENT_ROOT’], чтобы получить корень документа, который затем вернет верхнюю родительскую папку.
Я также думаю о автоматизированном развертывании в отдельную “родительскую” папку, чтобы публичные веб-сайты были доступны вне защищенного приложения, однако у меня уже есть первый работающий подход, и если он безопасен, я оставлю его как есть. Я понимаю, что безопасность будет зависеть от других факторов (правильная конфигурация, межсетевой экран, заголовки и т.д.), что я учту, этот вопрос касается только структуры папок.
Структура папок следующая:
app.domain.com
- public
- index.php
- .htaccess
- public.domain.com
- public
- index.php
- contact.php
- .htaccess
- .env
- src
- vendor
- .env
- ...
Ответ или решение
Чтобы ответить на ваш вопрос о рисках доступа к файловой системе частного приложения через публичный сайт, находящийся в его подкаталоге, давайте детально рассмотрим архитектуру вашего приложения и вопросы безопасности, связанные с использованием Docker и веб-серверов.
Структура вашего приложения
Ваше приложение состоит из следующих компонентов:
- Частное приложение (например, CMS), защищенное авторизацией (логин/пароль/многофакторная аутентификация).
- Публичный сайт, размещенный внутри подкаталога частного приложения.
- Использование Docker для интеграции компонентов в отдельные контейнеры.
Риски доступа к частному контенту
Основной вопрос заключается в том, существует ли риск получения доступа к файлам частного приложения через публичный сайт, если он расположен в его подкаталоге. Несмотря на то, что ваше приложение в значительной степени защищено, важно учитывать следующие аспекты:
-
Настройки веб-сервера: Убедитесь, что ваш веб-сервер (например, Apache или Nginx) правильно настроен для разграничения доступа между частным и публичным контентом. Главный файл конфигурации должен четко указывать, что доступ к частным файлам и директориям ограничен. Избыточные правила в конфигурации .htaccess могут привести к утечкам информации.
-
Структура файловых прав: Правильно настраивайте права доступа к файлам и директориям. Убедитесь, что публичный сайт не имеет разрешения на чтение или выполнение файлов другой части приложения, особенно в директориях, таких как
src
илиvendor
. -
Автоматизация развертывания: Как вы упомянули, развертывание публичного содержимого на уровень выше, вне защищенной зоны, может сильно увеличить уровень безопасности. Это разделение структур каталогов снижает риск случайного доступа к конфиденциальной информации.
-
Избежание выводимых ошибок: PHP предоставляет функции, такие как
DIR
и$_SERVER['DOCUMENT_ROOT']
, которые могут раскрывать структуру каталогов. Убедитесь, что ваши скрипты не выводят информацию о файловой системе в случае ошибок. -
Механизмы безопасности: В дополнение к базовой архитектуре безопасности, настройте дополнительные меры, такие как межсетевые экраны и заголовки безопасности (например, CORS, Content Security Policy), которые ограничивают доступ к определённым ресурсам.
Рекомендуемые подходы
-
Создание отдельного контейнера для публичного сайта: Это позволяет обеспечить дополнительный уровень изоляции и контроля. Каждый контейнер будет использоваться для своей конкретной части приложения, с ограничениями по сети и файловой системе.
-
Тестирование на уязвимости: Проверьте приложение с помощью инструментов для анализа уязвимостей. Это поможет выявить потенциальные проблемы безопасности, связанные с конфигурацией.
-
Изучите возможности Docker: Например, вы можете использовать Docker Compose для настройки изолированного окружения с разными сервисами, которые могут работать в своих собственных контейнерах.
Заключение
Хоть ваш публичный сайт находится внутри подкаталога частного приложения, риск утечки данных зависит от множества факторов — от настроек веб-сервера до управления правами доступа и дополнительной защиты на уровне инфраструктуры. Для повышения безопасности храните содержимое, доступное для широкой публики, отдельно от личных файлов и старайтесь минимизировать доступность конфиденциальной информации. Всегда проводите регулярные аудиты и тестирования безопасности для оценки защиты ваших данных.