Стратегии защиты файлов конфигурации сторонних веб-приложений PHP

Меня интересуют комментарии и стратегии защиты файлов конфигурации PHP, особенно тех, которые имеют учетные данные Db.

Стандартный совет, устанавливающий расширение файла на * .php, хорош, но не защищает от атак с просмотром каталогов. Я рассматриваю конкретный сценарий:

У нас есть сервер, на котором размещены различные сторонние приложения.
Мы не можем тщательно проверить все приложения
Если злоумышленник скомпрометирует приложение, он потенциально может использовать это приложение для чтения файлов из других каталогов. Конфигурационные файлы DB - очевидная цель.

У меня есть решение, которое, кажется, заслуживает внимания, но оно меня не совсем устраивает. Я хотел бы услышать комментарии к нему, а также

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

ЦЕЛИ

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

Это не касается конфликтов имен файлов конфигурации, хотя в некоторых приложениях, вероятно, стоит изменить имя включаемого файла конфигурации.

К сожалению, для многих наших веб-приложений требуются жестко заданные пути.

Какие подходы придумали другие?

Применяется стандартный совет:

Поместите файл конфигурации над корневым веб-каталогом
Используйте .htacess или аналогичный, чтобы запретить доступ к этим папкам
Используйте права доступа к файлам для защиты папок

Еще лучший совет:

Убедитесь, что ваш сервер БД может быть доступен только вашему веб-серверу как через ACL сети / брандмауэра, так и через его собственную аутентификацию на основе хоста.
Не используйте пароли, используйте сертификаты / Kerberos / PKI (краткий гугл есть это предложение для реализации этого в MySQL)
Если вы не доверяете приложению, запустите его на собственном веб-сервере, у которого нет доступа к файлам других приложений.
Используйте Tripwire для обнаружения вторжений

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