Контроллер Сборки TFS разработан так, чтобы он мог быть выполнен на рабочей станции в небольших средах (См. эту статью MS). Очевидно, это идет с обычными протестами о выполнении чего-либо на рабочей станции (более низкая производительность, должен быть онлайн все время, не сохранен, склонен конфликтовать с вещами), но это - зарегистрированная конфигурация, что MS ожидает, что малочисленные команды будут использовать.
Контроллер сборки должен быть разделен от самого сервера TFS по причинам безопасности и устойчивости - Это - хост, который создает и выполняет изменяющуюся кодовую базу и как таковой, та роль должна избегать Вашего репозитория кода.
Относительно отсутствия домена - Да, TFS установит в режиме рабочей группы.
In normal operation (ie, with an encrypted private key), the private key is known to the running webserver, but isn't present on-disc. In order to get a copy of the private key, an attacker would have to subvert the running webserver.
If you leave the private key constantly decrypted on-disc, then (assuming you have the permissions set tightly) an attacker needs only to subvert the file system.
But as you've observed, there is a cost to leaving the key encrypted on-disc: unattended restarts aren't possible. Only you can say whether the additional security afforded by leaving the key encrypted on-disc justifies the additional cost.
For myself, I suspect that anyone who can subvert file system protections can probably read your web server's memory anyway (think /proc/kcore
), and thus the difficulty of extracting the decrypted key from the memory map of the running server is the only additional protection afforded by encrypting the key. I tend to assume attackers are intelligent, so that makes the additional security fairly small.