Безопасное соединение JDBC
Необходимо получить задания, чтобы получить доступ к результату действия.
ProjectsListViewModel result = GetViewModel<ProjectsListViewModel>(await controller.List(2));
Метод испытания также должен быть асинхронным
public async Task Should_Return_ProjectsListViewModel() {
//Arrange
//...
//Act
IActionResult actual = await controller.List(2);
//Assert
ViewResult viewResult = actual as ViewResult;
viewResult.Should().NotBeNull(); //FluentAssertions
ProjectsListViewModel result = viewResult.ViewData.Model as ProjectsListViewModel;
result.Should().NotBeNull();
}
5 ответов
Я-.NET dev, но я столкнулся с той же самой ситуацией.
В прошлом году я работал в компании, которая должна была быть PCI, совместимым, чтобы хранить данные кредитной карты, таким образом, безопасность была грандиозным предприятием. Данные URL/входа в систему должны существовать где-нибудь. Наиболее распространенный метод я видел обеспечение его, с шифрованием. Я не знаю о Java, в частности, но.NET имеет несколько пространств имен шифрования в базовой Платформе. Мы использовали их для шифрования логинов базы данных.
У Вас все еще есть потенциальная уязвимость системы обеспечения безопасности, которые являются ключами шифрования, используемыми для шифрования/дешифрования данных. Мы использовали PCI "компенсация средств управления" метод здесь. Доступ к ключам ограничивается ролью "управления ключами". Мы также отследили доступ самого ключа так, чтобы была запись всего инициируемого пользователями и инициируемого системой доступа. Ни у какого пользователя не было доступа к этим журналам, таким образом, не могло быть никакого покрытия дорожек отдельным пользователем. Эти перекрывающиеся методы защиты по существу создают ситуацию, где не что иное как coordiated заговор между несколькими администраторами требуются поместить данные в опасность.
Если Вы не готовы сохранить его, необходимо запросить его. Вы могли зашифровать пароль, но затем у Вас должен быть ключ для дешифрования его, и Вы застреваете в той же проблеме.
Одно из общих решений этой проблемы для серверных приложений должно сохранить имя пользователя и пароль в файле, которому установили полномочия пользователя таким способом, которым только выполняющийся пользователь приложения/сервиса может считать его содержание.
Например, Вы запускаете свое приложение как пользовательский сервис нечто, и это наследовало все права доступа пользователя услуги нечто. Файл, содержащий имя пользователя и пароль, только читаем тем пользователем. Вы читаете значение из файла и подключения к базе данных как нормальное.
Возможные проблемы с этим подходом:
- Суперпользователь этой машины может получать пароль к базе данных.
- Взломщик, который проник через Вашу безопасность приложений, может получить доступ к учетным данным базы данных.
Вышеупомянутые проблемы обычно смягчаются путем настройки прав доступа для приложения к базе данных и сети. Почти любое другое решение Вы подходите, получит Вас в проблему курицы-и-яйца, потому что Вы в основном пытаетесь скрыть что-то от себя.
Лучший способ состоял бы в том, чтобы хранить информацию как настроенный источник данных в контексте JNDI Вашего сервера приложений. Можно затем использовать средства сервера приложений для конфигурирования источников данных во время развертывания. Все приложение должно сделать, ищут соответствующее имя JNDI во времени выполнения и использовании это. Это - общий шаблон для веб-приложений Java.
Используйте веб-сервисы для разделения приложения от сервера, делающего доступ к базе данных. Подпишите свое веб-приложение и затем только позвольте правильно приложению со знаком называть сервер веб-сервисов.