Комментарии 13
Но в .net core ушли от web.config и теперь настройки хранятся в appsetttings.json.
Поэтому лучше использовать в core, то что microsoft предлагает Safe storage или Azure Key Vault
Вот тут можно почитать подробнее.
1. если у вас — то зачем это все??? чтобы не украли? ну это по другому решается.
2. если у кого-то — то это вам не поможет, т.к. этот кто-то наверняка будет иметь физический доступ к машине.
Это не гарантия и не панацея, но чем больше преград на пути потенциального злоумышленника — там меньше шансов, что он таки сумеет нанести существенный ущерб.
для расшифровки надо залогиниться под нужной учёткой
Но ведь эту задачу решает правильная настройка прав доступа.
эту задачу решает правильная настройка прав доступатут ещё и защита от случайного взгляда…
Хотя лично я предпочитаю вместо много хитростей использовать встроенную аутентификацию при доступе к другим серверам или ресурсам, ведь гораздо проще сохранить секрет, если его не нужно нигде хранить.
Мы же не можем нигде не хранить строку подключения к бд. Как иначе сайт узнает откуда брать данные
Жаль, не всегда можно обойтись интегрированной аутентификацией.
Можем. Тут вообще большой простор действий. Можно, например, использовать отдельный микросервис для аутентификации всего и вся. Причем он может как просто передавать параметры для коннекта, так и производить конфигурацию сервера бд. Но зачем?
Некоторые БД вообще ничего против незашифрованного файлика в домашней директории не имеют. А файлик можно обновлять как угодно, благо, инструментов вагон. И это правильно тем, что не создает лишних иллюзий безопасности и не дает городить огороды.
Для того чтобы при автоматической заливке данные передавались в зашифрованном виде. Т.к. тут два выхода, либо вы правите конфиг руками на сервере, либо он идёт в пакете с заливкой.
Шифрование конфигурационных файлов