Где хранил пароли на предыдущих проектах?

Хранение паролей в продакшен-приложениях

На предыдущих проектах в качестве Go-разработчика я использовал многоуровневый подход к хранению чувствительных данных, где пароли и секреты никогда не хранились в plain-text в коде или репозиториях. Вот основные методы и инструменты, которые применялись:

1. Environment Variables (для локальной разработки)

Для локальных окружений использовались .env файлы, добавленные в .gitignore, с последующей загрузкой через библиотеку godotenv:

import (
    "github.com/joho/godotenv"
    "os"
)

func main() {
    godotenv.Load()
    dbPassword := os.Getenv("DB_PASSWORD")
    // ... использование пароля
}

Важный нюанс: В production .env файлы не использовались из-за рисков утечки файловой системы.

2. Secret Management Systems (продакшен)

Для production-окружений применялись специализированные системы:

• HashiCorp Vault – основной инструмент на большинстве проектов
• AWS Secrets Manager – для инфраструктуры на AWS
• Kubernetes Secrets – в k8s-окружениях с обязательным шифрованием etcd

Пример интеграции с Vault в Go:

import (
    "github.com/hashicorp/vault/api"
)

func getSecretFromVault(path, key string) (string, error) {
    config := api.DefaultConfig()
    config.Address = os.Getenv("VAULT_ADDR")
    
    client, err := api.NewClient(config)
    if err != nil {
        return "", err
    }
    
    client.SetToken(os.Getenv("VAULT_TOKEN"))
    
    secret, err := client.Logical().Read(path)
    if err != nil {
        return "", err
    }
    
    return secret.Data[key].(string), nil
}

3. Database Credentials

Для доступа к БД использовались следующие подходы:

• Динамические секреты Vault – временные credentials с автоматическим ротацией
• IAM-аутентификация в RDS (для AWS) через IAM-роли
• Короткоживущие токены с rotation policy 24-72 часа

4. Принципы безопасности, которые соблюдались

Никогда не хранили в коде:

• Пароли в plain text
• API-ключи
• SSH-ключи
• TLS-сертификаты

Обязательные практики:

• Rotation политики – автоматическая смена секретов каждые 30-90 дней
• Least privilege principle – минимальные необходимые права
• Audit logging – логирование всех обращений к секретам
• Encryption at rest – шифрование секретов в хранилище
• Encryption in transit – TLS для передачи

5. CI/CD Pipeline Security

В пайплайнах использовались:

• Secrets injection на этапе сборки через CI-системы (GitLab CI, GitHub Actions)
• Temporary credentials для deployment
• Access control на уровне репозиториев и окружений

Пример настройки в GitHub Actions:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to production
        run: ./deploy.sh
        env:
          DB_PASSWORD: ${{ secrets.PRODUCTION_DB_PASSWORD }}
          API_KEY: ${{ secrets.PRODUCTION_API_KEY }}

6. Мониторинг и инцидент-менеджмент

• Alerting на подозрительные паттерны доступа
• Automatic revocation при обнаружении компрометации
• Regular security audits сторонними специалистами
• Penetration testing дважды в год

7. Backup и Disaster Recovery

Секреты хранились с репликацией между регионами, с процедурами восстановления, протестированными ежеквартально.

Итог: Мой опыт основан на принципе "секреты – как огонь, полезны под контролем, опасны при утечке". Современный подход требует не просто хранить пароли "где-то безопасно", а создавать целостную систему управления секретами с аудитом, ротацией и минимальным временем жизни credentials. В Go-экосистеме для этого есть отличные библиотеки для работы с Vault, AWS Secrets Manager и другими системами, которые интегрируются в приложение через стандартные интерфейсы, обеспечивая безопасность без компромиссов для разработки.