Блог

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

Примечание: система управления пользователями основана только на имени пользователя и пароле. Только один уровень аутентификации.

1. Команда пользовательского интерфейса отвечает за отправку пароля в закодированном формате в серверную систему.

2. Команда серверной части отвечает за хранение пароля пользователя в БД в зашифрованном виде.

3. Если пользователь пытается войти в систему, серверная система может проверить, совпадают пароль пользовательского интерфейса и пароль БД или нет, ИЛИ

   Если decode (пароль пользовательского интерфейса) == decode (пароль, полученный из базы данных), то они позволят пользователю войти в приложение.

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

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

Если я ошибаюсь, что я думаю (иначе разработчики взломали данные пользователя банковского приложения), пожалуйста, дайте мне знать, насколько безопасна система управления пользователями, и НИ ОДИН разработчик не может расшифровать пароль пользователя из БД, даже если они знают метод шифрования и имеют доступ к БД.

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

Единственное, что могло бы предотвратить это, — это больше следить за кодом, когда он запускается в производство. Например, операционная группа проверяет, что по крайней мере два разработчика подписали выпуск, который они должны развернуть, что подразумевает, что второй разработчик проверил код. Обратите внимание, что мы исходим из предположения, что сговор между несколькими вредоносными разработчиками слишком рискован для разработчика.

В настоящее время DevOps наряду с непрерывной интеграцией является горячей новинкой. Допустим, у нас есть конвейер интеграции, и только у подмножества всех разработчиков есть системные разрешения для его настройки. Мы также потребовали бы, чтобы репозиторий кода имел историю, не подлежащую перезаписи (разрешить перебазирование git — плохая идея), чтобы предотвратить запуск вредоносного кода одним разработчиком и скрыть тот факт, что они это сделали. Если вы сами размещаете свой репозиторий кода, то на сервере, на котором он размещен, должна работать другая группа разработчиков. Если проверяемости кода недостаточно, вы даже можете настроить конвейер непрерывной интеграции таким образом, чтобы два разработчика должны были подписывать релиз.

Элементы управления, о которых я упоминал, — это только верхушка айсберга. Есть и другие вещи, которые следует учитывать:

• По сути, вам нужно доверять своим администраторам, но вы можете проверить, выполнив проверку данных при найме нового персонала и регулярно после этого (люди меняются).
• Поскольку речь идет о банковском деле, у вас, вероятно, есть некоторые требования соответствия для вашей юрисдикции. Эти требования могут предписывать некоторые полезные элементы управления безопасностью.
• У вас может быть независимая команда, которая существует только для проверки журналов аудита, что все (или случайная выборка) являются добропорядочными гражданами и ведут себя в соответствии с согласованными процессами.
• Не позволяйте вашим разработчикам или другим операторам (сотрудникам банка) выдавать себя за конечных пользователей в серверной части без надлежащего ведения журнала аудита о том, кто инициировал олицетворение.
• Защитите свои журналы аудита таким же образом, сделав их неизменяемыми разработчиками или другим привилегированным персоналом.
• Требуется двухфакторная аутентификация для ваших конечных пользователей, чтобы разработчик, который каким-то образом заглянул в производственную базу данных и увидел пароль пользователя, должен был внести изменения в систему, чтобы использовать этот пароль.
• Храните только хэшированные пароли (scrypt или аналогичные) и постоянно сравнивайте хэши при входе в систему.
• Если пароль прост и вам не требуется 2FA, разработчик может взломать его в автономном режиме с помощью hashcat или аналогичного. Поэтому требуются некоторые разумные правила сложности для пароля конечного пользователя.