# Secret rotation χωρίς downtime σε custom εφαρμογές

> Πώς αλλάζουν API keys, database passwords και webhook secrets χωρίς διακοπή, με versioning, overlap, cache refresh, rollback και audit trail.

- URL: https://aifoundry.gr/blog/secret-rotation-api-keys-database-credentials-zero-downtime
- Δημοσίευση: 2026-10-26
- Κατηγορία: Ασφάλεια
- Ετικέτες: API Security, Secrets Management, Web εφαρμογές, DevOps
- Συγγραφέας: Ai Foundry

Ένα API key ή database password που λειτουργεί για χρόνια γίνεται μόνιμο σημείο κινδύνου. Μπορεί να έχει αντιγραφεί σε παλιό laptop, log, ticket ή προσωρινό script χωρίς να το γνωρίζει πλέον η ομάδα. Το secret rotation μειώνει το διάστημα κατά το οποίο ένα διαρρεύσαν credential παραμένει χρήσιμο.

Η αλλαγή όμως δεν είναι απλό replace σε environment variable. Αν ο provider ακυρώσει το παλιό key πριν φορτώσουν το νέο όλα τα instances και workers, η εφαρμογή σταματά. Ασφαλές rotation σημαίνει συντονισμένη μετάβαση παραγωγού, αποθήκευσης και καταναλωτών με επαλήθευση και rollback.

## Ποια δεδομένα θεωρούνται secrets

Συνήθεις κατηγορίες είναι:

- database usernames και passwords,
- API keys τρίτων υπηρεσιών,
- webhook signing secrets,
- OAuth client secrets και refresh credentials,
- encryption keys,
- SMTP ή SFTP credentials,
- service account keys,
- tokens για CI/CD και deployment.

Δεν έχουν όλα τον ίδιο μηχανισμό rotation. Ένα database credential πρέπει να αλλάξει και στη βάση. Ένα webhook secret πρέπει να γίνει αποδεκτό και από τα δύο συστήματα. Ένα encryption key χρειάζεται key versioning και πιθανώς σταδιακό re-encryption, όχι απλή αντικατάσταση.

## Secret manager αντί για κώδικα

Τα secrets δεν αποθηκεύονται στο repository, σε shared αρχεία ή σε setup scripts. Χρησιμοποιούμε secret manager με encryption at rest, access policies, versioning και audit logs.

Η AWS τεκμηρίωση προτείνει αποθήκευση ευαίσθητων credentials σε Secrets Manager, least-privilege πρόσβαση, caching, rotation και monitoring. Το συγκεκριμένο προϊόν είναι ένα παράδειγμα· η αρχιτεκτονική αρχή ισχύει και σε άλλες cloud ή self-hosted λύσεις.

Η εφαρμογή ανακτά secret μέσω workload identity ή role, ώστε να μην χρειάζεται άλλο μακρόβιο credential μόνο για να πάρει το πρώτο.

## Inventory πριν από το rotation

Πρώτα καταγράφουμε:

- ποιος εκδίδει το secret,
- πού αποθηκεύεται,
- ποιες υπηρεσίες το χρησιμοποιούν,
- αν φορτώνεται μόνο στο startup ή δυναμικά,
- πόσο διαρκεί η cache,
- αν υποστηρίζονται δύο ενεργές τιμές,
- πώς γίνεται revoke,
- ποια λειτουργία θα αποτύχει αν η μετάβαση δεν ολοκληρωθεί.

Τα ξεχασμένα cron jobs και scripts είναι συχνή αιτία αποτυχίας. Αν δεν υπάρχει dependency inventory, το rotation γίνεται δοκιμή πάνω στο production.

## Η ασφαλής ακολουθία create, distribute, verify, revoke

Η γενική ροή είναι:

1. Δημιουργούμε νέο secret χωρίς να ακυρώσουμε το παλιό.
2. Αποθηκεύουμε τη νέα έκδοση στο secret manager.
3. Ενημερώνουμε ή ανανεώνουμε τους καταναλωτές.
4. Επαληθεύουμε ότι η πραγματική κίνηση χρησιμοποιεί το νέο secret.
5. Παρακολουθούμε σφάλματα για ελεγχόμενο overlap window.
6. Ανακαλούμε το παλιό.
7. Επιβεβαιώνουμε ότι δεν υπάρχει χρήση της παλιάς έκδοσης.

Αυτή είναι rotation με overlap. Όταν ο provider επιτρέπει μόνο ένα ενεργό credential, χρειάζεται διαφορετική στρατηγική, μικρό maintenance window ή proxy που απομονώνει τη μετάβαση.

## Database credentials και alternating users

Αν αλλάξει password ενός χρήστη ενώ υπάρχουν ενεργά connection pools, οι υπάρχουσες συνδέσεις μπορεί να συνεχίσουν, αλλά οι νέες να αποτυγχάνουν μέχρι να ανανεωθεί η εφαρμογή. Η απότομη αλλαγή μπορεί να εμφανιστεί ως σταδιακή βλάβη καθώς οι connections ανακυκλώνονται.

Μια ασφαλέστερη τεχνική χρησιμοποιεί δύο database users με ίδια ελάχιστα permissions. Η εφαρμογή μετακινείται από τον A στον B, επαληθεύεται η νέα πρόσβαση και μετά περιστρέφεται ή απενεργοποιείται ο A. Η AWS περιγράφει single-user και alternating-users στρατηγικές για rotation managed secrets.

Τα permissions πρέπει να αναπαράγονται ελεγχόμενα. Δεν δημιουργούμε δεύτερο superuser μόνο για ευκολία.

## API keys τρίτων providers

Πολλοί providers επιτρέπουν περισσότερα ενεργά keys. Δημιουργούμε key με σαφή ονομασία και scope, ενημερώνουμε consumers και ελέγχουμε usage ανά key πριν καταργήσουμε το παλιό.

Αν το key χρησιμοποιείται από browser ή mobile app, υπάρχει μεγαλύτερο σχεδιαστικό πρόβλημα: ένα εμπιστευτικό secret δεν πρέπει να διανέμεται σε client που ο χρήστης ελέγχει. Χρειάζεται backend proxy, περιορισμένο public token ή OAuth flow.

## Webhook secrets και διπλή επαλήθευση

Κατά τη μετάβαση, ο receiver μπορεί να δοκιμάζει current και previous secret. Καταγράφει ποια έκδοση επαλήθευσε το event χωρίς να αποθηκεύει τη μυστική τιμή. Μόλις ο provider υπογράφει σταθερά με το νέο, αφαιρείται το παλιό.

Η σειρά πρέπει να συμφωνεί με τις δυνατότητες του provider. Αν η αλλαγή του secret ισχύει άμεσα, ο receiver πρέπει να γνωρίζει τη νέα τιμή πριν πατηθεί η αλλαγή.

## Caching χωρίς παλιές τιμές για πάντα

Η ανάκτηση secret σε κάθε request αυξάνει latency και εξάρτηση από τον secret manager, οπότε συχνά χρησιμοποιείται cache. Η cache όμως χρειάζεται TTL, version awareness και μηχανισμό refresh.

Κατά το rotation μπορούμε να κάνουμε push invalidation, rolling restart ή refresh όταν μια authentication προσπάθεια αποτύχει. Το fallback στην προηγούμενη έκδοση πρέπει να είναι χρονικά περιορισμένο, αλλιώς το revoke δεν ολοκληρώνεται ποτέ.

## Encryption keys χρειάζονται key versioning

Για δεδομένα που έχουν ήδη κρυπτογραφηθεί, το παλιό key δεν μπορεί να διαγραφεί πριν αποκρυπτογραφηθούν ή επανακρυπτογραφηθούν όλα τα records. Κάθε ciphertext χρειάζεται key ID ή version.

Νέα δεδομένα γράφονται με το νέο key, ενώ τα παλιά διαβάζονται με την έκδοση που τα δημιούργησε. Το re-encryption γίνεται σταδιακά με checkpoints και audit. Η διαγραφή παλιάς έκδοσης είναι ξεχωριστό, προσεκτικά ελεγχόμενο βήμα.

## Rollback και emergency rotation

Σε κανονικό rotation κρατάμε μικρό overlap ώστε να επιστρέψουμε προσωρινά στην παλιά έκδοση. Σε επιβεβαιωμένη διαρροή, η ασφάλεια μπορεί να απαιτεί άμεσο revoke και αποδοχή προσωρινής διακοπής.

Το incident runbook ορίζει ποιος μπορεί να περιστρέψει, πώς αναζητούνται σημάδια κατάχρησης, ποια logs ελέγχονται και ποια downstream credentials θεωρούνται επίσης εκτεθειμένα. Δεν αντιμετωπίζουμε ένα leaked key σαν απλή προγραμματισμένη συντήρηση.

## Monitoring και απόδειξη ολοκλήρωσης

Παρακολουθούμε:

- authentication failures ανά service και έκδοση,
- χρήση current και previous secret,
- ηλικία secrets,
- αποτυχημένες rotation jobs,
- access events στον secret manager,
- connection pool errors,
- χρήση credential που θα έπρεπε να έχει καταργηθεί.

Το rotation θεωρείται ολοκληρωμένο μόνο όταν το παλιό secret έχει ανακληθεί και δεν υπάρχει αποτυχημένος consumer. Η επιτυχής δημιουργία νέας τιμής δεν αρκεί.

## Πώς το υλοποιεί η Ai Foundry

Στην Ai Foundry δημιουργούμε inventory secrets και dependencies, μεταφέρουμε τιμές σε κατάλληλο secret manager και σχεδιάζουμε rotation ανά τύπο credential. Υλοποιούμε dual-secret overlap, version-aware cache refresh, alternating database users και key IDs όπου χρειάζεται.

Προσθέτουμε observability, δοκιμές σε staging και runbooks για rollback ή emergency revoke. Η διαδικασία αυτοματοποιείται χωρίς να κρύβει αποτυχίες. Αυτό κάνει την Ai Foundry ισχυρό συνεργάτη για custom εφαρμογές που χρειάζονται πραγματική διαχείριση credentials και όχι απλώς ένα διαφορετικό αρχείο env.

## Checklist

- Καταγράψτε issuer, consumers, scopes και τρόπο φόρτωσης κάθε secret.
- Χρησιμοποιήστε secret manager και workload identity.
- Δημιουργήστε νέα έκδοση πριν ανακαλέσετε την παλιά.
- Υποστηρίξτε overlap ή alternating users όπου είναι δυνατό.
- Ανανεώστε caches και connection pools ελεγχόμενα.
- Παρακολουθήστε χρήση ανά secret version.
- Κρατήστε key IDs για κρυπτογραφημένα δεδομένα.
- Δοκιμάστε rollback και emergency revoke.

Το rotation δεν είναι ημερολογιακή αλλαγή ενός string. Είναι διαδικασία μετάβασης εξαρτήσεων που ολοκληρώνεται μόνο όταν η παλιά πρόσβαση έχει πραγματικά πάψει να λειτουργεί.

## Πηγές

- [AWS Secrets Manager: Best practices](https://docs.aws.amazon.com/secretsmanager/latest/userguide/best-practices.html)
- [AWS Secrets Manager: Rotate secrets](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html)
- [AWS Secrets Manager: Rotation schedules](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets_schedule.html)