Смотря что вкладываете в понятие безопасности, по каким направлениям строите защиту. Несколько примеров:
Если сайт интересен (для конкурентов, например) для целенаправленного взлома и при этом движок дырявый насквозь - ничто не поможет.
Незакрытые уязвимости в системе - тоже не поможет.
Ддос-атаки - не поможет.
На случай, когда растяпа-админ случайно отключил PHP от вебсервера, вынос файла настроек (да и всего движка целиком) в недоступную для вебсервера директорию будет полезным.

andrejk,

Дак написал же выше.

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

andrejkДвижок свой, пишу сам.У самописного движка есть одна хорошая положительная особенность - он самописный. А значит, для взлома потребуется приложить некоторые усилия (в отличии от популярных, типа джумлы).

andrejk- административная часть на отдельном поддомене;Знаю гораздо более радикальный случай. Хтмл-страницы сайта (магазин) генерит самописный набор скриптов, который живёт на офисном кампутере. После генерации файлы автоматически загружаются на хостинговый сервер. На хостинговом же сервере ломать абсолютно нечего в контексте сайта. Используется бюджетный тарифный план без возможности подключения скриптов и баз данных. Ддос? Ну на статике ещё постараться надо заддосить. Так и работает уже лет 15, владелец доволен и не собирается что-то менять. :-)

andrejkЗащититься хочу просто от баловства, от доступа к управлению сайтом, кражи бд и просто от любителей потренироваться.Вы цели нечистоплотных товарисчей перечислили. Но не ситуации, которые хотите предотвратить. Тот же доступ к управлению сайтом можно стырить непосредственно с Вашего компьютера. А при использовании протокола http и передачи логина/пароля в явном виде виде, можно их вытащить из IP-пакетов на любом участке от Вашего компа до сервера. Как видите, о сервере тут вообще речи не идёт.
А вот чтоб стырить БД, сайт ломать не обязательно. Иногда достаточно грамотно поездить по ушам техподдержке хостинга и попросить выложить вчерашний бэкап в корень сайта.


andrejkЭто что ж теперь, два репозитория в один сливать?О чём это, вообще?

Громыхательпри переносе сайта на другой IP - можно забыть поменять запись в ДНС
Достаточно сделать CNAME запись, на основной домен сайта указующую. И забыть об этой "проблеме". Конечно, если не переезжать при этом ещё и на другой ДНС.

А вот при переносе сайта на другой хостинг можно вообще забыть проверить админку. И забывают. Или забивают. А потом вопить начинают, что то фотки не загружаются, то слеши в тексте задвояются, то рассылка не работает. Так что, при правильном подходе, "проблема забывчивости" смены/установки записи в ДНС обозначится и будет устранена достаточно рано, при первой же проверке админки.

andrejk,

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

Выносить админку на отдельный домен имеет смысл при перспективе достаточно значительного расширения проекта, когда один сервер банально "не тянет". Тогда придётся растаскивать проект на множество серверов и вот тут-то, как раз, потребуется админка на отдельном домене. Однако, в такой ситуации админка и движок должны уметь поддерживать "многосерверность" проекта.

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

Если же админка живёт вместе с сайтом, то ни пользы, ни вреда от выноса админки на отдельный домен лично я не усматриваю. Некоторые дополнительные телодвижения потребуются, конечно, но они ж довольно просты и носят разовый характер.

ГромыхательvkleДостаточно сделать CNAME запись, на основной домен сайта указующую. И забыть об этой "проблеме". Конечно, если не переезжать при этом ещё и на другой ДНС.
Переезжать придётся по-всякому, если это не сайт-однодневка.

vkleТак что, при правильном подходе, "проблема забывчивости" смены/установки записи в ДНС обозначится и будет устранена достаточно рано, при первой же проверке админки.
При условии что админ днс и сайта - один и тот же человек. А если разные, да ещё один из них в отпуске?Если не однодневка, то сайт ещё и почтой обрастает. Вот Вам ещё одна головная боль :-) И переезжать можно по-всякому. Можно с громом и молниями и большой кучей наломанных дров. А можно переезд сделать безболезненным и совершенно незаметным. Разница между этими двумя вариантами в наличии планирования работ, и не более. Вы совершенно верно заметили про отпуск. Значит, планировать уже начали.

Если же столкнулись с этой проблемой именно как с проблемой, критически повлиявшей на работоспособность чего-либо, это значит, всего лишь, что никакого планирования не было. Когда имеется хоть какой-то план действий, там будет если не большой раздел, то, хотя бы, строчка про настройку и проверку ДНС. И рядом фамилия некого, ответственного за эту процедуру, администратора Сидорова, до которого этот план довели. Заблаговременно и под роспись. Если под роспись довести не получается, значит, тут явно что-то не так. Ну, вот, администратор Сидоров просто уволился. И что, теперь всё пропало? Наверно, пойдёте искать другого человека, который может выполнить необходимые настройки. Может быть, даже, поинтересуетесь, имеются ли у него необходимые права доступа и логины/пароли для выполнения запланированных действий. Может быть, даже, попросите проверить, не протух ли имеющийся пароль. При желании можете вспомнить ещё пунктики, успешное выполнение каждого из которых приводит к успешному достижению цели, а невыполнение - с проблемам.

А ведь придётся заручиться ещё и поддержкой программиста, который готов будет сделать необходимые исправления скриптов, если на новом хостинге что-то будет работать не так. И поддержкой тестировщика, который обнаружит это "не так". И с верстальщиком, который новые шаблоны уже вот-вот готов залить, придётся согласовать эти работы. И с контент-менеджером. А возможно, с кем-то ещё. Про копирование файлов и БД не забудте. Про их актуальность. Конечно, если всем этим занимается один "универсальный солдат", жить проще.

Можно привести некую аналогию с танком, который собираетесь отправить в бой. Думаю, вполне очевидно, что без администратора ДНС механика-водителя танк не поедет. Только вот успех всей боевой операции зависит далеко не только от одного мехвода. Без остальных членов экипажа, без боекомплекта, без приемлемого запаса топлива вряд ли есть смысл посылать машину в бой вообще. Думаю, по вполне понятным причинам.

ГромыхательvkleЕсть в этом смысл?
Если вы задаёте такой вопросНе я задаю вопрос, это ТС спрашивает.

andrejkесть смысл в возможности располагать админку где угодно или лучше в папке сайта оставить?В принципе - без разницы. Смотрите по удобству поддержки, обслуживания. Довольно часто админку вообще делают неотъемлемой частью движка, даже не обозначая её как-то в файловой системе (нет специальных директорий "для админки").
Другое направление - движок вообще выносится за пределы директории сайта. В этом есть некоторый плюс - автоматически полностью исключается прямое обращение к файлам движка (хотя, это можно сделать и другими способами), а все запросы идут через единую "точку входа". В том же и минус - система становится чуток более сложной.

andrejkвсё выливается в то, чтоб движок использовать на разных сайтах и лучше сразу заложить нужное направление развития, чем потом переделывать.Разумно. Однако, есть смысл определить границы развития и применяемости этого самого движка. Вы их определили уже? Как уже говорил выше Громыхатель, если не знаете, для чего это Вам надо - значит, оно Вам не надо. Будет мега-проект, под который задействованы десятки серверов - будет и бюджет. Тогда и перепишите и админку и движок под конкретные требования проекта.

andrejkAreostarandrejk,

А эта папка с настройками хотя бы закрыта от стороннего доступа через .access хотя бы?

Настройки вынесены на уровень выше и закрыты ещё .аксесом.За пределами директории сайта .htaccess бесполезен.