Обфускация поможет препятствовать модификации функционала в той её части где она не нужна. Т.е. у того, кто дорабатывал, будет весь проект. Но сплагиатить весь проект будет довольно проблематично
Во-первых, если Вы уйдёте туда, где сейчас больше платят, то рискуете быть на работе с окладом, который не будет сильно меняться годами и без возможности развиваться. В то время как там, откуда Вы ушли, сотрудникам будут платить уже больше. И не думайте, что Вы возьмёте и вернётесь на прежнее место. Мне, например, не нужны нестабильные сотрудники, которые готовы свалить при первой же удобной возможности. И так будет рассуждать каждый здравомыслящий руководитель.
Не равняйте всё по себе. Я стараюсь вовремя заметить тех, кто думает также как и Вы и вовремя с ними прощаться, сведя проблемы от ухода к минимуму
Anonym, если для каждого клиента свой ключ — да, это имеет смысл. Но тогда следите, чтоб в трафике не было зашифрованных сообщений, расшифрованное тело которых можно предсказать. Тогда ключ подберётся легко.
Пример: в каком-то случае сообщаете пользователю, что команда выполнена успешно. И это сообщение фиксировано. Но закрыто ключом. Тогда мы просто ждём это сообщение (вычислить его среди всех зашифрованных несложно) и раскрываем ключ.
Ключ клиентов и сервера одинаковый? Тогда любой клиент (или тот, у кого есть файлы клиента вместе с ключом шифрования) сможет расшифровать данные других клиентов. Если это не критично, то не совсем ясно зачем вообще использовать шифрование, коли это могут расшифровать другие?
Это не гибкое решение. Давно уже port knoking существует. Я на своих серверах так и делаю. Вдруг в командировке буду? IP мой не известен. А так постучался по нужным портам в нужной последовательности — и для этого IP открылся SSH (через iptables).
VPN-сервер на web-сервере открывать не хочется. Его можно настроить на ssh-сервере
Тогда на ssh-сервере дополнительно нужно будет прописывать правило, которое позволяет от адреса VPN доступ только к web-серверу, верно?
