📚 Теория: секреты в конфиге и их защита (раскрыть)
Что пошло не так?
Платёжный AES-ключ и токен PSP лежат в YAML. Они попадают в Git, CI, снапшоты, архивы, тестовые стенды.
⚠️ Любой, кто видит конфиг, может расшифровать трафик и имитировать платежи.
Как правильно?
Храни секреты в Secret Manager / Vault, загружай их через KMS или sidecar. Если нужно локально — PBKDF2 + AES-GCM и поддержка ротации.
🔐 Автотесты должны проваливаться, если в конфиге появились строки `key=`.
Ключ попадает в репозиторий и историю.
Сборочные логи выводят значения переменных окружения.
Злоумышленник подменяет платежи или расшифровывает архивы.
Как надо: секреты в секрет-сторе, шифрование AES-GCM с ключом из KMS, регламенты ротации и статический анализ на утечки.
Контекст
DevOps оставили ключ в конфиге, чтобы «быстрее поднять стенд». Через пару недель secrets попадают в Wiki и backup-архивы. Твоя задача — найти строку, объяснить риск и показать путь к Secret Manager/Key Vault.
- Посмотри, как
PaymentConfigчитает секрет через@Value. - Подумай про PBKDF2 и AES-GCM для локальных кейсторов.
- Предложи тесты: линтер, git-secrets, CI-проверка на чувствительные паттерны.
Сниппет
Code Review
Референс-исправление
Секреты должны жить в Secret Manager. Конфиг ссылаться на alias, а локальные файлы шифроваться AES-GCM с PBKDF2.
Флаг ревью: FLAG{java-yaml-secret-review}
@Configuration
@ConfigurationProperties(prefix = "payments")
public class PaymentConfig {
private final SecretsClient secretsClient;
public PaymentConfig(SecretsClient secretsClient) {
this.secretsClient = secretsClient;
}
public SecretKey aesKey() {
return secretsClient.fetchKey("payments/aes-gcm", KeyType.KMS);
}
}Добавь в CI проверку git secrets, сканирование application*.yml, unit-тесты, которые падают, если свойство содержит подозрительные строки.
Проверка флага
После ревью зафиксируй флаг, чтобы дашборд засчитал лабораторию.