#javascript #node.js #security #environment-variables #api-key
#язык JavaScript #node.js #Безопасность #переменные среды #api-ключ
Вопрос:
Я работаю над Node.js приложение, которое требует, чтобы пользователь вводил свои ключи API из стороннего сервиса (сервис не позволяет входить в систему через oauth). Прямо сейчас я храню их в файле .env, поэтому его нужно ввести при настройке. Я бы хотел, чтобы пользователь мог один раз установить ключи в пользовательском интерфейсе (с паролем), а затем постоянно хранить их, чтобы при выходе из приложения и повторном перезапуске ключи все еще были там. Как бы я поступил с этим? Нужно ли шифровать ключи и хранить их в базе данных? Существуют ли какие-либо другие методы?
Ответ №1:
В общем, это слишком большой риск как для ваших пользователей, так и для вас как поставщика услуг. Если это ценные ключи api, которые вы хотите сохранить, ваша служба становится хорошей целью. Как вы также отметили, для этого и был изобретен oauth.
Если вы все же решите это сделать, вы можете обменять немного ux на дополнительную безопасность. Вам определенно следует зашифровать ключи api, но где хранить ключи шифрования, чтобы это действительно имело смысл, всегда остается вопросом.
Подумайте о том, как злоумышленник может завладеть этими ключами api (угрозами), и это поможет обеспечить адекватную защиту (смягчение этих угроз).
Например, злоумышленник может получить доступ к базе данных напрямую или в автономном режиме, например, из резервной копии или через скомпрометированный сервер базы данных. Для этого подходит стандартное шифрование в режиме покоя, предоставляемое вашей СУБД, особенно если вы используете что-то вроде AWS и KMS для хранения ключей шифрования. Таким образом, вам нужно шифрование в состоянии покоя, но этого недостаточно.
Злоумышленник также может скомпрометировать ваше приложение, поэтому прозрачное шифрование не поможет. Вы можете, например, зашифровать свои конфиденциальные поля (т. Е. ключи api) на уровне приложения, с уникальными ключами, связанными с каждым пользователем, которые надежно хранятся в соответствующем сервисе (например, в HSM или в чем-то вроде Менеджера секретов в AWS). Это все еще может позволить злоумышленнику получить доступ, но становится все сложнее, и вы получаете гораздо больший контроль и возможность проверки доступа к ключам.
И чтобы сделать еще один шаг вперед, вы должны извлекать ключи из паролей своих пользователей с помощью соответствующей функции извлечения ключей (например, pbkdf2 или аналогичной) и никогда не хранить их в базе данных, только в памяти. Это означает, что секреты зарегистрированных пользователей все еще могут быть скомпрометированы злоумышленником, если у них есть доступ к памяти сервера и/или сетевым коммуникациям на стороне сервера (после завершения tls), но секреты автономных пользователей по-прежнему будут в безопасности, потому что даже у вас нет ключа для их расшифровки. Это, конечно, работает только в том случае, если вам нужен доступ к их ключам api только до тех пор, пока они присутствуют.