Менеджер секретов AWS и безопасность аутентификации базы данных
Я пытаюсь выяснить преимущества безопасности при перемещении аутентификаторов служб в хранилище секретов.
Очевидно, плохая идея хранить аутентификаторы базы данных в коде или в конфигурациях сервера приложений.
AWS Secrets Manager упрощает шифрование секретов и позволяет AWS автоматически поворачивать учетные данные, что очень хорошо. Понятно, что вращение db-аутентификатора выгодно с точки зрения безопасности. Если кто-то как-то украдет аутентификатор БД, Менеджер секретов может менять его ежедневно или чаще, а если он старый, вам не повезло.
Однако, если ваш сервер приложений будет скомпрометирован, не будут ли у него ключи AWS, необходимые для запроса Secrets Manager? То же самое для вашего исходного кода (то есть, где-то хранятся какие-то учетные данные, которые ведут к базе данных u/p). И, конечно, к этому серверу приложений прикреплена роль IAM, которая позволяет этому запросу, а также предоставлению сетевого трафика доступ к базе данных.
Чем это на самом деле сильно отличается от хранения аутентификатора базы данных на сервере приложений? Просто если программный доступ к Secrets Manager осуществляется через ваш код (через SDK), кому-то придется скомпрометировать ваш исходный код и сервер приложений, чтобы иметь пароль и правильный путь в VPC (например, безопасность входящего трафика) правила группы, таблица маршрутов и т. д.) чтобы добраться до данных?
Я думаю, что я что-то здесь упускаю!
1 ответ
Короткий ответ заключается в том, что Secrets Manager позволяет вам не хранить пароли в исходном коде или в файлах конфигурации, которые должны распространяться на ваши серверы. Однако, как вы указали, если ваши хосты скомпрометированы, все ставки отключены, и ничто не помешает злоумышленнику прочитать ваши секреты из памяти.
Что касается учетных данных AWS, если это экземпляр EC2, вы также хотели бы использовать роли для EC2, чтобы AWS автоматически поворачивал и доставлял ваши учетные данные на хост.