Безопасное хранение учетных данных REST API для доступа в среде Python

По этой теме есть ряд статей, быстрый поиск в Интернете по запросу «Хранение ключей API» даст вам несколько интересных и информативных материалов для чтения, поэтому я просто расскажу здесь о своем опыте.

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

Каждый ключ хранится в переменных среды

Достаточно просто, просто нужно было использовать os.environ для каждой клавиши. Это очень быстро превратилось в головную боль управления, особенно при развертывании в нескольких средах или настройке среды для нового участника проекта.

Все ключи хранятся в локальном файле

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

[
  {
    "name": "Service Name",
    "date": "1970-01-01",  // to track rotations
    "key": "1234abcd",
    "secret_key": "abcd1234"
  }
]

Это превратилось в класс, который обращался за меня к этому файлу и возвращал желаемый ключ, поэтому мне не приходилось повторять json.load() или импортировать os в каждом скрипте, обращающемся к API. Это стало немного сложнее, когда мне понадобилось хранить токены OAuth.

В конце концов я переместил этот файл в частный, зашифрованный (git-secret) репозиторий git только для локального доступа, поэтому команда члены также могут использовать ключи в своей среде.

Используйте службу секретного управления

Стремление к удаленной работе заставило меня создать систему для удаленного доступа и управления ключами API. Моя команда обсуждала ряд решений, но в конце концов мы остановились на AWS Secrets Manager. Вышеупомянутый настраиваемый класс был направлен на AWS, а не на локальный файл, и мы получили значительное повышение безопасности и гибкости по сравнению с локальным решением.

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