Стратегии безопасного хранения и использования среды тестирования учетных данных пользователей

Question

Проблема

Я создаю набор тестов e2e на существующем веб-приложении. Для этого требуется автоматическая регистрация на странице входа (пароль &). До сих пор, по мере того как я все еще разрабатываю тесты, я добавляю учетные данные тестовой учетной записи в cleartext в своих тестовых сценариях. Я удаляю учетные данные вручную перед каждой фиксацией, но он не будет использоваться для надлежащего автоматического тестирования на сервере где-нибудь, и если все разработчики должны иметь возможность запускать тесты с комфортом своих компьютеров. Кроме того, тесты должны иметь возможность запускать несколько разных наборов учетных данных пользователей, а безопасность учетных данных имеет решающее значение. Поскольку нам нужно проверить права доступа, кажется, что мы не можем избежать наличия хотя бы одной тестовой учетной записи с доступом к конфиденциальным данным.

Вопрос

Так что мой вопрос: Какие стратегии вы знаете, или использования, для безопасного хранения и использования тестовых учетных данных в средах тестирования на разработчиков машин, отдельных серверов, или как?

Предыдущие исследования

Я провел несколько дней озираясь в Интернете (в основном StackOverflow, и много попыток с помощью моего Google-фу), а также с просьбой коллег, но, не найдя каких-либо известных и используемых стратегий обработки и сохранение учетных данных в тестах. Я считаю, что многие опытные программисты должны решить эту проблему по-разному.

StackOverflow любезно предложил эти несколько подобные вопросы, которые предлагают некоторые интересные стратегии:

• Safely storing credentials when I need to retrieve the password for use, где принятый ответ рекомендует шифрование файла конфигурации. Похоже, это очень интересная идея, но мне непонятно, насколько хорошо это распределяет между серверами и отдельными компьютерами-разработчиками, и как можно справиться с логистикой этого.
• Storing credentials for automated use, где ответчик отвечает на них, заявляя, что они просто кладут учетные данные в виде открытого текста в файл на своем защищенном паролем сервере. Это может работать на одном сервере, но я считаю, что это проблематично, если для тестирования будет использовано несколько локальных машин для разработчиков или отдельные тестовые серверы.

специфика Case

Я думаю, что вопрос представляет общий интерес, независимо от деталей реализации, но так как они могут быть интересны они предусмотрены здесь в любом случае.

Я использую protractor для тестирования приложений AngularJS и рассматриваю Grunt для дальнейшей автоматизации тестирования. Мы планируем подключить тесты на нашем сервере Git и запускаем тесты при каждой фиксации на главную ветку, чтобы мы знали, что она никогда не ломается. Или, не нарушая во время наших тестов, по крайней мере :)

Answer 1

Я не уверен, что вы имеете в виду, когда вы говорите «Стратегии безопасно хранения и использования учетных данных пользователей среды тестирования. Вы заявляете, что ваши тесты должны выполняться с разными наборами учетных данных. Если ваш тест может получить учетные данные в виде открытого текста, то есть любое другое приложение/пользователь, работающий под одной учетной записью.

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

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

Лучший вариант - не использовать конфиденциальные данные при тестировании. Я работаю в компании, занимающейся медицинским программным обеспечением, и у нас есть тестовый домен, в котором мы создали наше программное обеспечение с известными учетными записями и используем поддельные данные для его проверки.

Или если вы хотите, чтобы другие разработчики могли запускать тесты под своими учетными данными, вы можете рассмотреть возможность переключения на Kerberos и избежания паролей.

Answer 2

Я согласен с приведенным выше ответом, вы можете создать ключ, сохранить его где-нибудь и использовать. Иначе вы можете получить шифрование, я нашел ссылку, которая может быть вам полезна. http://docstore.mik.ua/orelly/java-ent/security/ch13_05.htm