Δεν συνδέονται όλοι οι εταιρικοί λογαριασμοί σε ένα σύστημα επειδή ένας εργαζόμενος πληκτρολόγησε username και password.
Εφαρμογές, Windows services, backup jobs, scripts, integrations, databases, monitoring tools και automations μπορεί να χρειάζονται τη δική τους ταυτότητα για να αποκτούν πρόσβαση σε άλλα συστήματα. Αυτές οι μη ανθρώπινες identities συχνά υλοποιούνται ως service accounts, workload identities, API credentials ή άλλοι μηχανισμοί authentication.
Το πρόβλημα εμφανίζεται όταν ένας τέτοιος λογαριασμός δημιουργείται για μια προσωρινή ανάγκη και παραμένει ενεργός για χρόνια, με ισχυρά permissions, ένα static password που κανείς δεν θυμάται ποιος διαχειρίζεται και χωρίς monitoring.
Τι είναι ένα Service Account;
Ένα service account είναι μια identity που χρησιμοποιείται κυρίως από εφαρμογή, υπηρεσία, script, automation ή άλλο workload αντί από έναν άνθρωπο για την καθημερινή διαδραστική εργασία του.
Για παράδειγμα, μια επιχείρηση μπορεί να χρειάζεται μια μη ανθρώπινη identity ώστε:
- μια εφαρμογή να συνδέεται σε database,
- ένα backup job να αποκτά πρόσβαση στα δεδομένα που πρέπει να προστατεύσει,
- ένα monitoring system να συλλέγει πληροφορίες από servers,
- ένα script να εκτελεί μια προγραμματισμένη εργασία,
- δύο επιχειρηματικά συστήματα να ανταλλάσσουν δεδομένα,
- ένα CI/CD process να εκτελεί συγκεκριμένες αυτοματοποιημένες ενέργειες.
Η ακριβής ονομασία και ο τρόπος authentication διαφέρουν ανά πλατφόρμα. Η βασική αρχή όμως παραμένει ίδια: μια μη ανθρώπινη διεργασία αποκτά μια αναγνωρίσιμη identity και συγκεκριμένα permissions.
Service Account και User Account: Ποια είναι η διαφορά;
Ένας ανθρώπινος λογαριασμός συνδέεται συνήθως με συγκεκριμένο εργαζόμενο και ακολουθεί το employment lifecycle του. Όταν ο εργαζόμενος αλλάξει ρόλο ή αποχωρήσει, υπάρχει μια φυσική αφορμή για αλλαγή ή κατάργηση της πρόσβασής του.
Ένα service account μπορεί αντίθετα να συνεχίσει να λειτουργεί στο παρασκήνιο χωρίς καθημερινή ανθρώπινη αλληλεπίδραση.
Αυτό δημιουργεί διαφορετικές απαιτήσεις διαχείρισης. Η επιχείρηση πρέπει να γνωρίζει ποια εφαρμογή χρησιμοποιεί την identity, ποιος άνθρωπος ή ποια ομάδα είναι υπεύθυνη για αυτή, ποια permissions χρειάζεται και τι θα σταματήσει να λειτουργεί αν η identity απενεργοποιηθεί.
Γιατί τα Service Accounts δημιουργούν ιδιαίτερο κίνδυνο;
Το πρόβλημα δεν είναι ότι τα service accounts είναι εγγενώς μη ασφαλή. Είναι απαραίτητα σε πολλά περιβάλλοντα.
Ο κίνδυνος αυξάνεται όταν αποκτούν χαρακτηριστικά όπως:
- άγνωστο ή ανύπαρκτο owner,
- περισσότερα permissions από όσα απαιτούνται,
- credentials που παραμένουν ίδια για πολύ μεγάλο διάστημα,
- κοινά credentials μεταξύ διαφορετικών workloads,
- passwords ή keys αποθηκευμένα σε scripts και configuration files,
- απουσία logging και monitoring,
- λογαριασμοί που παραμένουν ενεργοί αφού η εφαρμογή που τους χρειαζόταν έχει καταργηθεί.
Επειδή πολλές τέτοιες identities λειτουργούν αυτόματα, μια λανθασμένη ρύθμιση μπορεί επίσης να παραμένει απαρατήρητη περισσότερο από έναν αντίστοιχο ανθρώπινο λογαριασμό.
Το πρώτο βήμα είναι το Inventory
Δεν μπορείτε να διαχειριστείτε identities που δεν γνωρίζετε ότι υπάρχουν.
Δημιουργήστε inventory των service accounts και άλλων σημαντικών non-human identities. Για κάθε καταχώρηση είναι χρήσιμο να γνωρίζετε τουλάχιστον:
- το όνομα ή identifier της identity,
- ποιο σύστημα ή workload τη χρησιμοποιεί,
- ποιος είναι ο υπεύθυνος owner ή η υπεύθυνη ομάδα,
- ποιος είναι ο επιχειρηματικός σκοπός της,
- ποια συστήματα προσπελαύνει,
- ποια permissions διαθέτει,
- ποιο authentication mechanism χρησιμοποιεί,
- πού διαχειρίζονται τα σχετικά credentials ή secrets,
- πότε χρησιμοποιήθηκε ή επανεξετάστηκε τελευταία φορά, όπου υπάρχουν τα κατάλληλα δεδομένα.
Το inventory δεν πρέπει να περιέχει plaintext passwords, private keys ή άλλα secret values. Πρέπει να καταγράφει την identity και τον τρόπο διαχείρισής της, όχι να μετατρέπεται σε νέο σημείο διαρροής credentials.
Η ίδια λογική inventory είναι χρήσιμη και για τις υπόλοιπες τεχνολογικές εξαρτήσεις μιας ΜΜΕ. Δείτε επίσης τον οδηγό της DataShield για το IT Asset Inventory.
Κάθε Service Account χρειάζεται Owner
Το γεγονός ότι η identity δεν ανήκει σε άνθρωπο δεν σημαίνει ότι δεν πρέπει να υπάρχει άνθρωπος ή ομάδα υπεύθυνη για αυτή.
Ο owner πρέπει να μπορεί να απαντήσει:
- γιατί υπάρχει ο λογαριασμός,
- ποια εφαρμογή τον χρησιμοποιεί,
- ποια permissions είναι απαραίτητα,
- πώς αλλάζει το credential χωρίς να διακοπεί η υπηρεσία,
- πότε μπορεί να καταργηθεί.
Ένα service account χωρίς γνωστό owner είναι δύσκολο να αξιολογηθεί. Κανείς δεν γνωρίζει με βεβαιότητα αν είναι ακόμη απαραίτητο και η απενεργοποίησή του μπορεί να θεωρείται υπερβολικά επικίνδυνη επειδή δεν είναι γνωστές οι εξαρτήσεις του.
Εφαρμόστε Least Privilege
Σύμφωνα με την αρχή του least privilege, κάθε identity πρέπει να διαθέτει μόνο τους πόρους και τις εξουσιοδοτήσεις που χρειάζεται για τη λειτουργία της.
Αν ένα service χρειάζεται μόνο read access σε συγκεκριμένα δεδομένα, δεν υπάρχει λόγος το account του να έχει γενικά administrative permissions.
Ελέγξτε ειδικά service accounts που:
- είναι administrators ή διαθέτουν ισοδύναμα υψηλά privileges,
- έχουν πρόσβαση σε πολλά άσχετα συστήματα,
- μπορούν να δημιουργούν άλλους λογαριασμούς ή credentials,
- έχουν permissions που είχαν δοθεί για παλαιότερη λειτουργία η οποία δεν χρησιμοποιείται πλέον.
Τα permissions πρέπει να επανεξετάζονται όταν αλλάζει η εφαρμογή ή ο επιχειρηματικός σκοπός της identity.
Μην χρησιμοποιείτε ένα κοινό Account για πολλές υπηρεσίες
Η επαναχρησιμοποίηση της ίδιας identity ή του ίδιου credential σε διαφορετικά workloads δημιουργεί περιττή σύνδεση μεταξύ τους.
Αν ένα credential διαρρεύσει, μπορεί να επηρεαστούν περισσότερες υπηρεσίες. Παράλληλα γίνεται δυσκολότερο να προσδιοριστεί ποιο workload πραγματοποίησε μια συγκεκριμένη ενέργεια.
Όπου είναι τεχνικά εφικτό, χρησιμοποιήστε ξεχωριστές identities και credentials για διαφορετικές υπηρεσίες και σκοπούς.
Τι είναι τα Static Credentials;
Ένα service account μπορεί να χρησιμοποιεί password, API key, token, certificate, cryptographic key ή άλλο authentication mechanism ανάλογα με το σύστημα.
Ένα static credential είναι ιδιαίτερα προβληματικό όταν παραμένει έγκυρο για μεγάλο χρονικό διάστημα και πρέπει να αποθηκεύεται κάπου ώστε το workload να μπορεί να το χρησιμοποιήσει ξανά.
Αν ένα μακρόβιο credential αντιγραφεί από configuration file, repository, script, backup ή άλλο σημείο, μπορεί να συνεχίσει να παρέχει πρόσβαση μέχρι να λήξει ή να ανακληθεί.
Μην αποθηκεύετε Secrets μέσα στον κώδικα
Passwords, API keys και άλλα secrets δεν πρέπει να ενσωματώνονται απευθείας στον source code ή να αποθηκεύονται απροστάτευτα σε repositories.
Το ίδιο ισχύει για scripts και configuration files όταν αυτά μπορούν να διαβαστούν από περισσότερους χρήστες ή συστήματα από όσους πραγματικά χρειάζονται το secret.
Όπου απαιτούνται αποθηκευμένα secrets, χρησιμοποιήστε κατάλληλο secrets-management mechanism που επιτρέπει ελεγχόμενη πρόσβαση, auditing και διαχείριση του lifecycle τους.
Rotation, Revocation και Expiration
Τα machine credentials χρειάζονται οργανωμένο lifecycle.
Η OWASP περιγράφει για τα secrets στάδια όπως creation, rotation, revocation και expiration. Η ακριβής διάρκεια ζωής ενός credential εξαρτάται από τον σκοπό, την τεχνολογία και τον κίνδυνο.
Για την επιχείρηση αυτό σημαίνει ότι πρέπει να μπορεί να απαντήσει:
- πώς δημιουργείται ένα νέο credential,
- πώς αντικαθίσταται με ασφάλεια,
- ποια workloads πρέπει να ενημερωθούν κατά το rotation,
- πώς ανακαλείται άμεσα αν υπάρξει υποψία compromise,
- αν μπορεί να λήγει αυτόματα όταν η πλατφόρμα το υποστηρίζει.
Το rotation δεν πρέπει να σχεδιάζεται ως χειροκίνητη ενέργεια που κανείς δεν τολμά να πραγματοποιήσει επειδή μπορεί να σταματήσει μια κρίσιμη εφαρμογή.
Προτιμήστε Short-Lived Credentials όπου είναι κατάλληλα
Ορισμένες σύγχρονες πλατφόρμες μπορούν να επιτρέπουν σε workloads να αποκτούν προσωρινά credentials ή tokens αντί να αποθηκεύουν ένα μακρόβιο static secret.
Όταν μια τέτοια δυνατότητα είναι διαθέσιμη και κατάλληλη για το περιβάλλον, μπορεί να μειώσει το χρονικό διάστημα κατά το οποίο ένα κλεμμένο credential παραμένει χρήσιμο.
Αυτό δεν σημαίνει ότι κάθε εφαρμογή μπορεί να λειτουργήσει χωρίς stored secret ούτε ότι όλες οι τεχνολογίες υλοποιούν workload identity με τον ίδιο τρόπο. Η επιλογή εξαρτάται από την πλατφόρμα και την αρχιτεκτονική.
Service Accounts και MFA
Το MFA είναι ιδιαίτερα σημαντικό για ανθρώπινους λογαριασμούς, αλλά ένα automated workload δεν μπορεί πάντα να ολοκληρώσει ένα interactive MFA prompt όπως ένας εργαζόμενος.
Για αυτό η προστασία των non-human identities δεν πρέπει να περιορίζεται στη σκέψη «θα ενεργοποιήσουμε MFA».
Χρειάζεται κατάλληλο machine-authentication design: περιορισμένα permissions, προστασία των credentials, σύντομη διάρκεια ζωής όπου υποστηρίζεται, περιορισμός του πού μπορεί να χρησιμοποιηθεί η identity και παρακολούθηση της δραστηριότητάς της.
Περιορίστε πού μπορεί να χρησιμοποιηθεί η Identity
Όπου η πλατφόρμα παρέχει σχετικούς ελέγχους, μην εξετάζετε μόνο τι μπορεί να κάνει ένα service account αλλά και από πού και από ποιο workload μπορεί να χρησιμοποιηθεί.
Ένα credential που προορίζεται αποκλειστικά για συγκεκριμένη εφαρμογή δεν πρέπει, όπου αυτό μπορεί να επιβληθεί τεχνικά, να λειτουργεί ανεξέλεγκτα από οποιοδήποτε σύστημα.
Η ακριβής υλοποίηση μπορεί να βασίζεται σε διαφορετικούς μηχανισμούς ανάλογα με την πλατφόρμα.
Monitoring των Service Accounts
Η δραστηριότητα μιας μη ανθρώπινης identity είναι συχνά περισσότερο προβλέψιμη από τη δραστηριότητα ενός ανθρώπου.
Ένα backup account, για παράδειγμα, μπορεί να αναμένεται να εκτελεί συγκεκριμένες εργασίες σε συγκεκριμένα συστήματα. Μια ξαφνική χρήση του από άσχετο σύστημα ή για διαφορετικό τύπο ενέργειας μπορεί να χρειάζεται διερεύνηση.
Όπου υπάρχουν τα κατάλληλα logs, παρακολουθήστε:
- authentication events,
- αποτυχημένες προσπάθειες πρόσβασης,
- χρήση privileged permissions,
- αλλαγές στα permissions της identity,
- δημιουργία ή αλλαγή credentials,
- χρήση από μη αναμενόμενα systems ή workloads,
- δραστηριότητα μετά από revocation ή προγραμματισμένη κατάργηση.
Το logging πρέπει να καταγράφει τη χρήση του secret χωρίς να καταγράφει το ίδιο το plaintext secret.
Τι είναι ένα Orphaned Service Account;
Ένα service account γίνεται ουσιαστικά orphaned όταν παραμένει ενεργό χωρίς σαφή επιχειρηματική ανάγκη ή υπεύθυνο owner.
Αυτό μπορεί να συμβεί όταν:
- καταργείται μια παλιά εφαρμογή,
- μεταφέρεται ένα workload σε νέο σύστημα,
- αλλάζει IT provider,
- αποχωρεί ο εργαζόμενος που είχε δημιουργήσει το integration,
- ένα προσωρινό project ολοκληρώνεται αλλά οι identities του παραμένουν ενεργές.
Η περιοδική ανασκόπηση inventory, ownership, last-use information και dependencies βοηθά στον εντοπισμό τέτοιων accounts.
Μην απενεργοποιείτε άγνωστα Service Accounts στα τυφλά
Ένα άγνωστο service account δεν πρέπει να παραμένει επ' αόριστον ενεργό μόνο επειδή κανείς δεν γνωρίζει τι κάνει. Η άμεση διαγραφή του χωρίς διερεύνηση όμως μπορεί να προκαλέσει διακοπή κρίσιμης υπηρεσίας.
Πριν από την κατάργηση:
- εντοπίστε πρόσφατη χρήση και διαθέσιμα logs,
- ελέγξτε σε ποια συστήματα εμφανίζεται το credential ή η identity,
- εντοπίστε πιθανές εφαρμογές και scheduled jobs που εξαρτώνται από αυτή,
- επιβεβαιώστε τον owner ή τον επιχειρηματικό σκοπό όπου είναι δυνατό,
- σχεδιάστε ελεγχόμενη απενεργοποίηση και rollback όπου απαιτείται.
Μετά την επιβεβαιωμένη κατάργηση του workload, τα credentials πρέπει να ανακληθούν και η μη απαραίτητη identity να απομακρυνθεί σύμφωνα με τις διαδικασίες του οργανισμού.
Service Accounts και Privileged Access
Ορισμένα service accounts χρειάζονται αυξημένα permissions για να εκτελέσουν τη λειτουργία τους. Αυτό τα καθιστά ιδιαίτερα σημαντικά για την ασφάλεια.
Μην θεωρείτε όμως ότι μια εφαρμογή χρειάζεται administrative access μόνο επειδή «έτσι λειτουργούσε πάντα».
Ελέγξτε ποια ακριβώς operations εκτελεί και αν μπορούν να δοθούν στενότερα permissions.
Η αρχή είναι η ίδια με κάθε privileged identity: όσο μεγαλύτερη είναι η πρόσβαση, τόσο μεγαλύτερο μπορεί να είναι το impact μιας παραβίασης.
Service Accounts, API Keys και Secrets δεν είναι ακριβώς το ίδιο
Οι όροι συχνά εμφανίζονται μαζί, αλλά περιγράφουν διαφορετικές έννοιες.
Το service account είναι identity. Ένα API key, password, certificate ή token μπορεί να είναι credential που χρησιμοποιείται για authentication. Ένα secret είναι ευρύτερη κατηγορία ευαίσθητου υλικού που πρέπει να προστατεύεται από μη εξουσιοδοτημένη αποκάλυψη.
Η διάκριση βοηθά στην οργάνωση της ασφάλειας: πρέπει να γνωρίζετε τόσο ποια identity έχει πρόσβαση όσο και ποιο credential χρησιμοποιεί και πώς διαχειρίζεται.
Πρακτικό πλάνο για μια ΜΜΕ
- Ανακαλύψτε τις non-human identities. Καταγράψτε service accounts, σημαντικά integrations και machine credentials.
- Ορίστε owner. Κάθε identity πρέπει να έχει υπεύθυνο άνθρωπο ή ομάδα.
- Καταγράψτε τον σκοπό. Ποιο workload χρησιμοποιεί την identity και γιατί;
- Ελέγξτε permissions. Αφαιρέστε πρόσβαση που δεν απαιτείται.
- Διαχωρίστε workloads. Αποφύγετε κοινές identities και credentials όταν μπορούν να χρησιμοποιηθούν ξεχωριστά.
- Εντοπίστε static secrets. Ελέγξτε scripts, configuration και άλλες τοποθεσίες όπου μπορεί να υπάρχουν μακρόβια credentials.
- Μεταφέρετε τα secrets σε κατάλληλη διαχείριση. Χρησιμοποιήστε ελεγχόμενη αποθήκευση και πρόσβαση όπου απαιτείται.
- Σχεδιάστε rotation και revocation. Βεβαιωθείτε ότι η αλλαγή credential μπορεί να γίνει χωρίς αυτοσχεδιασμό.
- Ενεργοποιήστε κατάλληλο logging. Παρακολουθήστε authentication και σημαντικές αλλαγές χωρίς να εκθέτετε τα secret values.
- Καταργήστε ό,τι δεν χρειάζεται. Μετά από έλεγχο dependencies, απενεργοποιήστε obsolete identities και ανακαλέστε τα credentials τους.
Checklist για Service Accounts
- Υπάρχει inventory των σημαντικών service accounts και non-human identities;
- Έχει κάθε identity γνωστό owner και καταγεγραμμένο σκοπό;
- Γνωρίζουμε ποια εφαρμογή ή workload τη χρησιμοποιεί;
- Έχουν ελεγχθεί τα permissions σύμφωνα με least privilege;
- Αποφεύγεται η χρήση κοινών credentials από διαφορετικά workloads;
- Υπάρχουν secrets μέσα σε source code, scripts ή μη προστατευμένα configuration files;
- Μπορούν τα credentials να ανακληθούν γρήγορα σε περίπτωση compromise;
- Υπάρχει ασφαλής διαδικασία rotation;
- Μπορούν να χρησιμοποιηθούν short-lived credentials αντί για μακρόβια static secrets όπου υποστηρίζεται;
- Καταγράφονται authentication και σημαντικά administrative events;
- Ελέγχονται περιοδικά identities που δεν χρησιμοποιούνται πλέον;
- Υπάρχει διαδικασία deprovisioning όταν καταργείται μια εφαρμογή ή integration;
Συχνά λάθη
«Δεν είναι User Account, άρα δεν είναι σημαντικό»
Μια machine identity μπορεί να έχει πρόσβαση σε κρίσιμα δεδομένα και συστήματα. Η απουσία ανθρώπινου χρήστη δεν μειώνει από μόνη της την αξία της για έναν attacker.
«Δεν αλλάζουμε το Password γιατί μπορεί να σταματήσει η εφαρμογή»
Αυτό συνήθως δείχνει ότι δεν έχει σχεδιαστεί σωστά το credential lifecycle. Η επιχείρηση πρέπει να γνωρίζει πώς αλλάζει ή ανακαλεί ένα credential και ποιες dependencies επηρεάζονται.
«Ένα Account για όλα είναι πιο εύκολο»
Η ευκολία δημιουργεί μεγαλύτερο blast radius και δυσκολότερο attribution. Οι ξεχωριστές identities επιτρέπουν πιο συγκεκριμένα permissions και καλύτερη παρακολούθηση.
«Το Secret είναι σε Configuration File, άρα είναι ασφαλές»
Η ασφάλεια εξαρτάται από το ποιος μπορεί να διαβάσει το αρχείο, πού αντιγράφεται, αν βρίσκεται σε backups ή repositories και πώς προστατεύεται συνολικά το credential.
Πώς μπορεί να βοηθήσει η DataShield
Τα service accounts συχνά βρίσκονται ανάμεσα σε identity management, server administration, cloud services, applications και cybersecurity. Για αυτό μπορεί εύκολα να μην ανήκουν ξεκάθαρα σε καμία καθημερινή διαδικασία.
Η DataShield μπορεί να βοηθήσει μια επιχείρηση να χαρτογραφήσει τις κρίσιμες non-human identities και τα credentials τους, να αξιολογήσει permissions και ownership και να οργανώσει πρακτικό lifecycle για storage, rotation, monitoring και deprovisioning με βάση την πραγματική υποδομή.
Συμπέρασμα
Τα service accounts είναι απαραίτητο μέρος πολλών σύγχρονων IT environments, αλλά δεν πρέπει να αποτελούν αόρατους λογαριασμούς που λειτουργούν επ' αόριστον.
Η σωστή προσέγγιση είναι να αντιμετωπίζονται ως κανονικές identities με inventory, σαφές ownership, least privilege, ξεχωριστά credentials, ασφαλές secrets management, rotation, monitoring και οργανωμένο deprovisioning.
Όσο περισσότερο μια επιχείρηση αυτοματοποιεί διαδικασίες και συνδέει εφαρμογές μεταξύ τους, τόσο σημαντικότερο γίνεται να γνωρίζει όχι μόνο ποιοι άνθρωποι έχουν πρόσβαση, αλλά και ποια μηχανήματα, εφαρμογές και services μπορούν να ενεργούν μέσα στα συστήματά της.
