Здравствуйте, Doom100500, Вы писали:

D>Сервис крутится от имени SYSTEM

значит ваш сервис может создать другого админа, а текущему ограничить права ниже админских, и запретить чтение файла с паролем для шифрования.
Вроде все просто.
Есть возражения против такого решения?

Здравствуйте, Doom100500, Вы писали:

D>Есть система, установленная на Windows. Работает на производстве и выполняет производственные задачи. Время от времени заливает отчёты на наш FTP.
D>Возникло требование отчёты шифровать и передавать по SFTP, для этого нужно как-то хранить в системе приватный ключ.
А если не программисткое, а администраторское решение.
Зашифровать канал связи. Поднимается VPN, и вся работа с нужным FTP пускается по этому VPN.
Как итог, переделывать софт не надо, для него всё тот же ftp, но по другому маршруту, обеспечивающему шифрование.

Здравствуйте, paradok, Вы писали:

P>Здравствуйте, Doom100500, Вы писали:

D>>Сервис крутится от имени SYSTEM

P>значит ваш сервис может создать другого админа, а текущему ограничить права ниже админских, и запретить чтение файла с паролем для шифрования.
P>Вроде все просто.
P>Есть возражения против такого решения?

Вполне годно.

Здравствуйте, akasoft, Вы писали:

A>Здравствуйте, Doom100500, Вы писали:

D>>Есть система, установленная на Windows. Работает на производстве и выполняет производственные задачи. Время от времени заливает отчёты на наш FTP.
D>>Возникло требование отчёты шифровать и передавать по SFTP, для этого нужно как-то хранить в системе приватный ключ.
A>А если не программисткое, а администраторское решение.
A>Зашифровать канал связи. Поднимается VPN, и вся работа с нужным FTP пускается по этому VPN.
A>Как итог, переделывать софт не надо, для него всё тот же ftp, но по другому маршруту, обеспечивающему шифрование.

Тоже вариант

Здравствуйте, Doom100500, Вы писали:

D>Привет.

D>Есть система, установленная на Windows. Работает на производстве и выполняет производственные задачи. Время от времени заливает отчёты на наш FTP.
D>Возникло требование отчёты шифровать и передавать по SFTP, для этого нужно как-то хранить в системе приватный ключ.

Обычно это делается не так.
В приложение зашивается *публичный* ключ для шифрования отчетов, затем приложение отправляет зашифрованный отчет по HTTP на сервер, установленный на вашей стороне, а сервер уже перекладывает на sftp. Аутентификация на стороне HTTP сервера необязательна, но желательна, т.к. позволяет для разных версий/экземпляров вашего приложения использовать разные креды — полезно для сбора статистики, отсечения проблемных клиентов и т.п.

Здравствуйте, scf, Вы писали:

scf>Здравствуйте, Doom100500, Вы писали:

scf>Обычно это делается не так.
scf>В приложение зашивается *публичный* ключ для шифрования отчетов, затем приложение отправляет зашифрованный отчет по HTTP на сервер, установленный на вашей стороне, а сервер уже перекладывает на sftp. Аутентификация на стороне HTTP сервера необязательна, но желательна, т.к. позволяет для разных версий/экземпляров вашего приложения использовать разные креды — полезно для сбора статистики, отсечения проблемных клиентов и т.п.

Зачем тогда SFTP если трафик на него будет идти внутри сети организации?
Но идея заслуживает внимания. Поднимаем http server, делаем ему домен и https сертификат, с системы делаем ему запрос на upload с метадатой (ftp user), и потом на стороне сервера перекладываем его на ftp по внутренней сети .
Канал завод -> внутренняя сеть зашифрован (https), значит требования материнской компании удовлетворены. Для всего остального ftp остаётся ftp. Хранить на заводе никаких ключей не нужно.

Можно попробовать протолкнуть идею. Может разрешат.

Здравствуйте, Doom100500, Вы писали:

D>Как же хранить этот ключ в таких условиях?
D>Или просто сделать на от***сь и не париться?

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

D>Есть система, установленная на Windows. Работает на производстве и выполняет производственные задачи. Время от времени заливает отчёты на наш FTP.
D>Возникло требование отчёты шифровать и передавать по SFTP, для этого нужно как-то хранить в системе приватный ключ.
D>Сервис, который этим занимается дотнетовский, следовательно может быть легко декомпилирован. Пробовал обфуксацию, но на моём рабочем лаптопе его убивает антивирь при запуске, значит антивирь может сработать у клиента

Приватный ключ к SFTP это не супер секрет.
Права на SFTP должны быть такие что юзер мог только закачать отчёт зашифрованый публичным(!) ключом.
Ни скачать ни удалить прав не дожно быть. Ну и если хотите контроль IP.
Вот и всё.