Я работаю над веб-сайтом, на котором новые страницы - ASP.NET, а устаревшие - Classic ASP. Будучи новичком в разработке для Windows env, я изучаю новейшие технологии, то есть .NET, и я становлюсь оленем в свете фар, когда возникают проблемы с COM-объектами.
Безопасность на сайте - это мерзость, но я легко зашифровал строки подключения в файле web.config для http://www.4guysfromrolla.com/articles/021506-1.aspx на основе режима машины DPAPI. Я понимаю, что этот подход не самый безопасный, но он лучше, чем ничего, что было для страниц ASP.NET. Теперь я задаюсь вопросом, как сделать подобное шифрование для строк соединения, используемых страницами Classic ASP.
Осложняющим фактором является то, что веб-сайт размещен там, где у меня нет прав администратора или даже доступа к командной строке, только FTP. Более того, я хочу избежать управления ключом.
Мое исследование нашло:
DPAPI с COM-взаимодействием. Похоже, что это уже должно быть доступно, но единственное, что я мог найти, обсуждая это, это CyptoUtility (см. http://msdn.microsoft.com/en-us/magazine/cc163884.aspx), которая не установлена на хост-сервере.
Существует множество других сторонних COM-объектов, например, Crypto от Dalun Software http://www.dalun.com,, но они также не находятся на размещенном сервере, и они надеются, что я потребую от вас какое-то управление ключами.
На размещенном сервере есть CAPICOM, но M $ устарел, и многие сообщают, что его не так просто использовать. Мне не ясно, могу ли я избежать управления ключами с помощью CAPICOM, аналогичного использованию DPAPI для ASP.NET. Если кто-то знает, пожалуйста, сообщите мне.
Я мог бы написать веб-сервис в ASP.NET, и классические страницы ASP могли бы использовать его для получения расшифрованных строк подключения, а затем сохранить их в переменной приложения. Мне не нужно было бы использовать SSL, так как я мог использовать localhost, и через Интернет ничего не отправлялось. В простейшей форме я мог бы реализовать то, что кто-то назвал версией бедняка, основываясь на простом XML-потоке, однако я действительно стремился избежать какой-либо разработки, так как мне трудно поверить, что для Classic ASP нет такого простого решения, как для ASP.NET.
Может быть, мне не хватает некоторых вариантов ... Рекомендации запрашиваются ...