Проблемы безопасности и риски, связанные с отладкой производственной среды

Question

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

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

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

Для будущего следственного я нашел это сообщения, связанные:

• What's the risk of deploying debug symbols (pdb file) in a production environment?
• Good processes for debugging production environment? Copying data to Dev?
• Which are the dangers of remote debugging?

Answer 1

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

Это также вызывает беспокойство при регистрации, мы должны быть осторожны с тем, какую информацию мы регистрируем, чтобы у нас было достаточно данных, чтобы исследовать причину ошибки, но не храните в журналах уязвимые данные (финансовые записи, медицинские записи). Существует и другая общая проблема: обычно уровень безопасности не соответствует безопасности производственной базы данных и файлов журналов.

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

2) Еще одна проблема заключается в риске, связанном с внедрением новых дефектов программного обеспечения при исправлении и расследовании сообщений об ошибках. Процесс исправления ошибок имеет тенденцию быть более ad-hoc, а затем нормальным процессом разработки. У этого есть некоторые причины, потому что существующие в производственных ошибках могут стоить деньги компании, поэтому есть давление, чтобы исправить их быстро.

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