Szyfrowanie pliku web.config przy użyciu konfiguracji chronionej bezcelowe?

Question

Muszę czegoś brakować ...

W tej chwili szukam najlepszego sposobu szyfrowania ciągu połączenia z bazą danych i informacji o stanie sesji Sql w pliku web.config. Szybko znajduję przejście przez msdn wyjaśniające używanie chronionej konfiguracji do szyfrowania części web.config: MSDN walkthrough on using Protected Configuration

Tak więc myślę, że jest świetny, istnieje mechanizm, który to umożliwia i wygląda bardzo prosto. Dochodzę do końca instrukcji i dostarczają kod źródłowy strony aspx, która może być użyta do odszyfrowania wszystkich łańcuchów połączeń !!!!

Jaki jest sens ??? Nie mam żadnej usługi ftp działającej na tym serwerze WWW, jedynym sposobem, aby ktokolwiek zobaczył plik web.config, był dostęp do systemu plików, w którym publikowana jest strona. Jeśli tak, to wszystko, co muszą zrobić, to użyć dostarczonego kodu do odszyfrowania.

Czego mi brakuje? Czy istnieje lepszy sposób na ich zaszyfrowanie? Czy po uruchomieniu niestandardowego rozwiązania będzie działać dla części stanu sesji sql? (nie wierz, że laska zostanie usunięta z web.config)

Answer 1

Musisz mieć przynajmniej możliwość zapisu do systemu plików, aby móc go odszyfrować, zakładając, że korzystasz z dostawcy DPAPI. Sposobów, aby odszyfrować obejmują:

• Kopiuj strony aspx zawierającą kod deszyfrowania do serwera i przejdź do niego
• Zaloguj się na serwerze i uruchomić aplikację, aby je odszyfrować.

Ale chroni przed odszyfrowaniem przez nieautoryzowanego użytkownika, który ma dostęp do odczytu systemu plików lub kopii zapasowej systemu plików.

Zazwyczaj można skonfigurować serwery produkcyjne, aby tylko autoryzowani administratorzy mogli logować się do serwera lub zapisywać na jego systemie plików.

Programiści mogą mieć zdalny dostęp do odczytu w celach wsparcia i nie mogą zdalnie odszyfrować pliku konfiguracyjnego.

Szyfrowanie/odszyfrowywanie jest proste w przypadku standardowych bibliotek: najtrudniejszą częścią jest zapewnienie, że tylko upoważnione osoby mają dostęp do kluczy.

Jeśli korzystasz z interfejsu DPAPI, zasadniczo delegujesz zarządzanie kluczami na zabezpieczenia systemu Windows. Jeśli korzystasz z innego dostawcy, takiego jak RSA, musisz gdzieś przechowywać klucz i chronić go przed nieautoryzowanym dostępem, np. przy użyciu listy ACL.