Κέρδη:
- Δυνατότητα διαχωρισμού ταυτότητας και εξουσιοδότησης και εφαρμογή ελάχιστης εξουσιοδότησης με RBAC/ABAC
- Δυνατότητα αποφυγής μικτού κινδύνου διακομιστή μεσολάβησης εκτελώντας το μοντέλο στο περιβάλλον χρήστη
- Δυνατότητα αποθήκευσης και περιστροφής κλειδιών API με το μυστικό σύστημα διαχείρισης
Ένα σημαντικό μέρος των επιθέσεων σε ένα σύστημα τεχνητής νοημοσύνης δεν ξεκινά με την «εξαπάτηση» του μοντέλου, αλλά με ένα κλεμμένο κλειδί API ή έναν υπερβολικά εξουσιοδοτημένο λογαριασμό. Αυτό το επίπεδο ασφάλειας προέρχεται από την κλασική ασφάλεια πληροφοριών, αλλά προσθέτει νέους κινδύνους στο πλαίσιο της τεχνητής νοημοσύνης: ένα μοντέλο καλεί μια διαδρομή για λογαριασμό κάποιου άλλου, ένας λογαριασμός υπηρεσίας έχει πρόσβαση σε όλα τα δεδομένα, ένα κλειδί διαρρέει στο GitHub. Σε αυτήν την ενότητα, θα μάθουμε πώς να περιορίζουμε την πρόσβαση στο σύστημα AI με έλεγχο ταυτότητας, εξουσιοδότηση (RBAC/ABAC), ελάχιστη εξουσιοδότηση και μυστική διαχείριση.
Διαφορά μεταξύ ελέγχου ταυτότητας και εξουσιοδότησης
Οι δύο όροι συχνά συγχέονται:
- Έλεγχος ταυτότητας: "Ποιος είσαι;" — απόδειξη ότι ο χρήστης/η υπηρεσία είναι πραγματικά αυτός που ισχυρίζονται ότι είναι (κωδικός πρόσβασης, διακριτικό, πιστοποιητικό, MFA).
- Εξουσιοδότηση: "Τι μπορείτε να κάνετε;" — προσδιορίστε σε ποιον πόρο/ενέργεια μπορεί να έχει πρόσβαση το πιστοποιημένο μέρος.
Η κρίσιμη λεπτότητα στα συστήματα τεχνητής νοημοσύνης είναι η εξής: όταν το μοντέλο εκτελεί εργασία για λογαριασμό ενός χρήστη, λειτουργεί με την εξουσία αυτού του χρήστη ή με έναν ευρύ λογαριασμό υπηρεσίας; Το τελευταίο είναι επικίνδυνο — επειδή το μοντέλο που εξαπατήθηκε από την έγχυση αποκτά πλήρη πρόσβαση στον λογαριασμό υπηρεσίας.
Προσοχή: Πρόβλημα "μπερδεμένος αναπληρωτής": ένας χρήστης χαμηλής εξουσιοδότησης έχει έμμεσα πρόσβαση σε δεδομένα στα οποία δεν μπορεί να έχει πρόσβαση αναθέτοντας σε εξωτερικούς συνεργάτες ένα μοντέλο υψηλής εξουσιοδότησης. Το μοντέλο πρέπει πάντα να λειτουργεί εντός του πλαισίου της εξουσίας του χρήστη, όχι της δικής του ευρείας εξουσίας.
RBAC και ABAC
- RBAC (Role-Based Access Control): Η πρόσβαση εξαρτάται από τον ρόλο του χρήστη. Ο ρόλος "ειδικός υποστήριξης" μπορεί να διαβάζει σημειώσεις πελατών, αλλά δεν μπορεί να τις διαγράψει. Απλό και κοινό.
- ABAC (Attribute-Based Access Control): Η πρόσβαση εξαρτάται από χαρακτηριστικά: το τμήμα του χρήστη, την ετικέτα απορρήτου των δεδομένων, την ώρα της ημέρας, το δίκτυο από το οποίο προέρχεται το αίτημα. Πιο τελειοποιημένο αλλά πιο σύνθετο.
Οι περισσότεροι οργανισμοί ξεκινούν με το RBAC και εμβαθύνουν στο ABAC για ευαίσθητα δεδομένα. Εμπειρικός κανόνας για την τεχνητή νοημοσύνη: το μοντέλο πρέπει να φιλτράρει κάθε πράκτορα που καλεί και κάθε δεδομένα στα οποία έχει πρόσβαση με βάση τον ρόλο/τα χαρακτηριστικά του χρήστη που υποβάλλει το αίτημα.
Βήμα προς βήμα: Άσκηση ελάχιστης εξουσίας
- Κάντε απογραφή. Ποια εργαλεία καλεί το μοντέλο, σε ποια δεδομένα έχει πρόσβαση; Καταγράψτε τα όλα.
- Να αιτιολογήσετε κάθε πρόσβαση. "Χρειάζεται πραγματικά αυτός ο βοηθός εξουσιοδότηση διαγραφής;" Διαφορετικά, αφαιρέστε το.
- Προεπιλογή μόνο για ανάγνωση. Το μοντέλο θα πρέπει να μπορεί να διαβάζει από προεπιλογή. Απαιτείται εγγραφή/διαγραφή ξεχωριστού διακριτικού στενού εύρους.
- Μετακίνηση περιβάλλοντος χρήστη. Καλέστε το όχημα με την εξουσιοδότηση του χρήστη, όχι με τον λογαριασμό σέρβις.
- Διαπιστευτήριο βραχύβιας διάρκειας. Χρησιμοποιήστε κουπόνια μικρής διάρκειας και αυτόματης ανανέωσης αντί για κλειδιά μεγάλης διάρκειας.
Μυστική Διαχείριση
Ένα μυστικό είναι τα διαπιστευτήρια που πρέπει να παραμείνουν μυστικά, όπως ένα κλειδί API, κωδικός πρόσβασης, διακριτικό ή πιστοποιητικό. Το πιο συνηθισμένο ατύχημα σε έργα τεχνητής νοημοσύνης είναι όταν το κλειδί API του παρόχου μοντέλου είναι ενσωματωμένο στον κώδικα και διαρρέει στον έλεγχο έκδοσης (Git).
Σωστή εφαρμογή:
- Μην ενσωματώνετε ποτέ κλειδιά σε κώδικα. Χρησιμοποιήστε μια μεταβλητή περιβάλλοντος ή ένα μυστικό σύστημα διαχείρισης (μια υπηρεσία που αποθηκεύει τα κλειδιά κρυπτογραφημένα και ελέγχει την πρόσβαση).
- Περιστροφή: Ανανεώστε τα πλήκτρα σε τακτά χρονικά διαστήματα (π.χ. κάθε 90 ημέρες). Εάν υπάρχει υποψία διαρροής, ακυρώστε αμέσως.
- Μείωση εύρους: Κάθε διακόπτης έχει μόνο την απαιτούμενη υπηρεσία και την απαιτούμενη εξουσιοδότηση.
- Έλεγχος: Καταγραφή ποιος χρησιμοποίησε το κλειδί, πότε και πού.
Τέσσερα αντιγράψιμα πρότυπα
Προτροπή ελέγχου ελέγχου πρόσβασης:
Για κάθε εργαλείο στη λίστα εργαλείων παρακάτω, αξιολογήστε: - ΑΠΑΙΤΕΙΤΑΙ αυτό το εργαλείο για την εκτέλεση της εργασίας αυτού του βοηθού; (ναι/όχι) - Είναι μόνο για ανάγνωση ή εγγραφή/διαγραφή; - Καλείται αυτό το εργαλείο με την εξουσιοδότηση ή τον λογαριασμό υπηρεσίας του χρήστη; Επισημάνετε τα περιττά ή υπερβολικά εξουσιοδοτημένα ως "REMOVE/REDACT".<tools>{{ tool_list }}</tools>
Μυστική προτροπή σάρωσης διαρροής:
Βρείτε οτιδήποτε θα μπορούσε να είναι ένα μυστικό με σκληρό κώδικα στο ακόλουθο απόσπασμα κώδικα: κλειδί API, κωδικός πρόσβασης, διακριτικό, συμβολοσειρά σύνδεσης, ιδιωτικό κλειδί. Δώστε σειρά και πληκτρολογήστε για το καθένα. COPY τιμή σε απάντηση;μάσκα (πρώτοι 4 χαρακτήρες + ***).<code>{{ πηγή }}</code>
Κανόνας απόφασης ελάχιστης αρχής:
Όταν φτάσει ένα νέο εργαλείο/αίτημα πρόσβασης, ρωτήστε:1. Μπορεί η εργασία να εκτελεστεί χωρίς αυτήν την πρόσβαση; -> Εάν ναι: ΑΠΟΡΡΙΨΗ2. Αρκεί μόνο για ανάγνωση; -> Εάν ναι: ΧΟΡΗΓΗΣΤΕ άδεια εγγραφής3. Μπορεί το πεδίο εφαρμογής να περιοριστεί σε μία μόνο πηγή; -> Εάν ναι: daratΗ προεπιλεγμένη απάντηση είναι "όχι". Η πρόσβαση αποκτάται από τη λογική.
Υπενθύμιση ημερολογίου εναλλαγής:
Για κάθε μυστικό, καταγράψτε: κάτοχος, ημερομηνία δημιουργίας, λήξη, εύρος. Αναφέρετε οποιοδήποτε κλειδί έχει υπερβεί τις 90 ημέρες ή δεν έχει χρησιμοποιηθεί για 30 ημέρες ως "ΥΠΟΨΗΦΙΟΣ ΕΝΙΣΧΥΣΗΣ/ΑΚΥΡΩΣΗΣ".
Αδύναμη προτροπή / Ισχυρή προτροπή
κακή προσέγγιση
Ισχυρή προσέγγιση
Το μοντέλο έχει πρόσβαση σε όλα τα δεδομένα με έναν μόνο λογαριασμό υπηρεσίας
Το μοντέλο έχει πρόσβαση με την εξουσία του χρήστη που υποβάλλει το αίτημα
Το κλειδί API είναι ενσωματωμένο στον κώδικα, δεν αλλάζει ποτέ
Εναλλαγή σε βασικό μυστικό διαχειριστή, 90 ημέρες
Ευρεία εξουσία "κάνω οτιδήποτε" στον βοηθό
Προεπιλογή μόνο για ανάγνωση, γράψτε στενά
Οι προσβάσεις δεν ελέγχονται ποτέ
Τακτική αναθεώρηση και ανάκληση πρόσβασης
Τρεις Μίνι Θήκες
Περίπτωση 1 — Διέρρευσαν μικτά δεδομένα διακομιστή μεσολάβησης. Ένας εσωτερικός βοηθός εργαζόταν με έναν λογαριασμό υπηρεσίας που είχε πρόσβαση σε όλα τα αρχεία εργαζομένων. Ένας ασκούμενος χρήστης είχε πρόσβαση σε δεδομένα που κανονικά δεν θα έβλεπε λέγοντας "συνοψίστε τον πίνακα μισθών στελεχών". επειδή το μοντέλο το αμφισβήτησε στο πλαίσιο της δικής του ευρείας εξουσίας, όχι του χρήστη. Μόλις το περιβάλλον χρήστη προσαρμόστηκε για να μετακινηθεί, ο ασκούμενος μπορούσε να τραβήξει ηχογραφήσεις που μόνο αυτός ή αυτή μπορούσε να δει.
Περίπτωση 2 — Κλειδί που διέρρευσε, λογαριασμός 190.000 TL σε 2 εβδομάδες. Ένας προγραμματιστής ενσωμάτωσε το μοντέλο κλειδί API σε ένα βοηθητικό σενάριο και το ώθησε σε ένα δημόσιο αποθετήριο. Ένα bot βρήκε το κλειδί σε 40 λεπτά και το χρησιμοποίησε για δύο εβδομάδες. Ο λογαριασμός έφτασε τις 190.000 TL. Όταν το κλειδί μετακινήθηκε στον διαχειριστή μυστικών, συνδέθηκε με περιστροφή και προστέθηκε σάρωση αποθήκης, το περιστατικό δεν επαναλήφθηκε.
Περίπτωση 3 — Προεπιλεγμένη αποτροπή διακοπής μόνο για ανάγνωση. Ένας βοηθός DevOps έλαβε μια εντολή "επαναφορά βάσης δεδομένων παραγωγής" μέσω έγχυσης προτροπής. Ωστόσο, στον βοηθό δόθηκε μόνο ένα διακριτικό μόνο για ανάγνωση. Η εγγραφή/διαγραφή ήταν σε ξεχωριστή εγκεκριμένη ροή. Η εντολή απορρίφθηκε με σφάλμα εξουσιοδότησης και το συμβάν καταγράφηκε ως συναγερμός. Δεν υπήρξε απώλεια δεδομένων.
Συμβουλή: Κάντε "όχι" την προεπιλεγμένη σας απάντηση σε ένα νέο αίτημα πρόσβασης. Η πρόσβαση είναι κάτι που αποκτάται μέσω αιτιολόγησης. Το να δίνουμε σε όλους ευρεία και στη συνέχεια να μειώσουμε δεν γίνεται σχεδόν ποτέ και ο κίνδυνος συσσωρεύεται.
Συνήθη λάθη
- Εκτέλεση του μοντέλου με μεγάλο λογαριασμό υπηρεσίας και απώλεια του περιβάλλοντος χρήστη (μικτός διακομιστής μεσολάβησης).
- Ενσωμάτωση του κλειδιού API στον κώδικα και διαρροή του στον έλεγχο έκδοσης.
- Δεν περιστρέφονται καθόλου τα πλήκτρα ("λειτουργεί, μην αγγίζετε").
- Δίνοντας στον βοηθό δικαιώματα εγγραφής/διαγραφής από προεπιλογή.
- Παραχώρηση πρόσβασης μία φορά και ποτέ επανεξέτασή της.
- Συγχέοντας τον έλεγχο ταυτότητας με την εξουσιοδότηση και υποθέτοντας ότι "είναι συνδεδεμένος, μπορεί να έχει πρόσβαση σε όλα".
Συνοπτικά
- Ο έλεγχος ταυτότητας είναι ένα ζήτημα «ποιος είσαι», η εξουσιοδότηση είναι ένα ζήτημα «τι μπορείς να κάνεις». Στο AI, και τα δύο πρέπει να λειτουργούν στο πλαίσιο του χρήστη.
- Το μοντέλο θα πρέπει να λειτουργεί με την εξουσία του χρήστη που υποβάλλει το αίτημα, όχι με τη δική του ευρεία εξουσία (αποφεύγοντας τον κίνδυνο μικτής αντιπροσωπείας).
- Ξεκινήστε με RBAC, εμβαθύνετε με ABAC σε ευαίσθητα δεδομένα. Ορίστε την ελάχιστη εξουσία ως προεπιλογή.
- Μην θάβετε τα μυστικά σε κώδικα. αποθηκεύστε το στο μυστικό διαχειριστή, περιορίστε το και βάλτε το σε τακτική περιστροφή.
- Η προεπιλογή μόνο για ανάγνωση και η στενή εγγραφή περιορίζουν σημαντικά τον αντίκτυπο της έγχυσης.
Εργασία εφαρμογής
Καταγράψτε όλα τα εργαλεία και τα δεδομένα στα οποία έχει πρόσβαση ο Βοηθός AI σας. Απαντήστε σε τρεις ερωτήσεις για καθεμία: (1) Είναι πραγματικά απαραίτητο; (2) Αρκεί μόνο για ανάγνωση; (3) Εκτελείται σε περιβάλλον χρήστη; Στη συνέχεια, αναζητήστε όλα τα κωδικοποιημένα μυστικά (μέσω της προτροπής σάρωσης παραπάνω) και γράψτε ένα σχέδιο περιστροφής για κάθε κλειδί που βρίσκετε. Καταργήστε τουλάχιστον μία περιττή εξουσιοδότηση.
λίστα ελέγχου
- [ ] Το μοντέλο εκτελείται στο πλαίσιο αρχής του χρήστη που υποβάλλει το αίτημα.
- [ ] Η πρόσβαση σε εργαλεία και δεδομένα έχει περιοριστεί στην αρχή του ελάχιστου προνομίου.
- [ ] Η εγγραφή/διαγραφή είναι ξεχωριστή από μόνο για ανάγνωση, έλεγχος ταυτότητας και περιορισμένη.
- [ ] Δεν υπάρχουν μυστικά θαμμένα στον κώδικα. Φυλάσσεται στον μυστικό διαχειριστή.
- [ ] Υπάρχει πρόγραμμα εναλλαγής και διαδικασία ακύρωσης για τα κλειδιά.
- [ ] Οι προσβάσεις ελέγχονται τακτικά.