Θήκες διαπιστευτηρίων παρόχου για πύλες AI πολλαπλών μοντέλων: Ξεχωριστός χρόνος εκτέλεσης, διαχειριστής, χρέωσης και πρόσβαση BYOK

Τα κλειδιά API μεταγενέστερης ροής και τα διαπιστευτήρια παρόχου ανόδου λύνουν διαφορετικά προβλήματα. Ένα κλειδί προγραμματιστή που εκδίδεται από την πύλη σας προσδιορίζει την εφαρμογή, την ομάδα, τον μισθωτή, τον προϋπολογισμό και το πλαίσιο πολιτικής. Ένα κλειδί παρόχου ανοδικής ροής επιτρέπει στην πύλη να ξοδεύει χρήματα και να έχει πρόσβαση σε μοντέλα σε έναν λογαριασμό παρόχου. Η αντιμετώπιση αυτών ως του ίδιου είδους μυστικού είναι ο τρόπος με τον οποίο οι ομάδες καταλήγουν με ένα απεριόριστο κλειδί σε ένα κοινόχρηστο έργο, διαπιστευτήρια διαχειριστή σε υπηρεσίες χρόνου εκτέλεσης και κανένα αξιόπιστο τρόπο απάντησης ποιος μισθωτής προκάλεσε τη χρέωση από την πλευρά του παρόχου.

Το πρακτικό μοτίβο είναι ένα θησαυροφυλάκιο διαπιστευτηρίων παρόχου: ένα ειδικό επίπεδο ελέγχου για εισαγωγή, ταξινόμηση, αποθήκευση, επιλογή, περιστροφή και έλεγχο διαπιστευτηρίων ανάντη. Θα πρέπει να βρίσκεται πίσω από το δρομολογητή, το βιβλίο τιμολόγησης, τη μηχανή πολιτικής και τη ροή εργασιών λειτουργιών—όχι μέσα στον κώδικα εφαρμογής, τα αρχεία διαμόρφωσης μοντέλου, τις εγγραφές μισθωτή ή τα συμβάντα αναλυτικών στοιχείων.

Το πρόβλημα του αναγνώστη: τα upstream διαπιστευτήρια γίνονται αόρατη υποδομή

Οι περισσότερες αναπτύξεις πολλαπλών μοντέλων ξεκινούν με έναν απλό στόχο: δρομολογήστε ένα αίτημα συμβατό με OpenAI στον καλύτερο διαθέσιμο πάροχο. Στη συνέχεια εμφανίζονται περισσότεροι λογαριασμοί: ένα έργο παρόχου για παραγωγή, ένα άλλο για αξιολόγηση, ένας χώρος εργασίας Anthropic για μια επιχειρηματική μονάδα, ένα έργο Google Cloud για το Gemini και πολλά κλειδιά που παρέχονται από τους πελάτες για συμβάσεις BYOK.

Ο κίνδυνος δεν είναι απλώς μυστική διαρροή. Είναι απώλεια του πλαισίου εξουσιοδότησης. Ένα έγκυρο κλειδί παρόχου μπορεί τεχνικά να μπορεί να καλέσει ένα τελικό σημείο, αλλά η πύλη πρέπει ακόμα να γνωρίζει εάν αυτό το κλειδί επιτρέπεται για αυτόν τον μισθωτή, αυτήν την οικογένεια μοντέλων, αυτήν την πολιτική διατήρησης δεδομένων, αυτόν τον προϋπολογισμό, αυτήν την περιοχή και αυτήν τη διαδρομή αυτοματισμού.

Γεγονός: οι πλατφόρμες παρόχων εκθέτουν διαφορετικά όρια λογαριασμών και τύπους διαπιστευτηρίων. Το OpenAI τεκμηριώνει έργα και λογαριασμούς υπηρεσιών, καθώς και τα βασικά δικαιώματα API λογαριασμού υπηρεσίας για πρόσβαση ανάγνωσης και εγγραφής για τους πόρους API του έργου. Το OpenAI εκθέτει επίσης τα βασικά αντικείμενα του API Admin ξεχωριστά από τη συνηθισμένη χρήση API έργου/χρόνου εκτέλεσης. Το Anthropic τεκμηριώνει τους χώρους εργασίας ως οργανωτικό όριο και δηλώνει ότι τα τελικά σημεία του Admin API απαιτούν κλειδιά API διαχειριστή διαφορετικά από τα τυπικά κλειδιά API. Η Anthropic σημειώνει επίσης ότι τα κλειδιά API συνδέονται με τον χώρο εργασίας όπου δημιουργούνται και δεν μπορούν να μετακινηθούν μεταξύ των χώρων εργασίας. Η τεκμηρίωση κλειδιού Gemini API της Google λέει ότι κάθε κλειδί API Gemini σχετίζεται με ένα έργο Google Cloud και συνιστά περιορισμούς API για τη μείωση της ζημιάς σε περίπτωση παραβίασης ενός κλειδιού.

Σύσταση: μην δημιουργήσετε ένα γενικό πεδίο "provider_key" και ονομάστε το ολοκληρωμένο. Δημιουργήστε ένα απόθεμα διαπιστευτηρίων που διατηρεί τα όρια του παρόχου, ενώ εκθέτει ένα κανονικοποιημένο μοντέλο πολιτικής στην πύλη.

Καθορίστε μια ταξινόμηση διαπιστευτηρίων πριν αποδεχτείτε τα κλειδιά

Ένα θησαυροφυλάκιο θα πρέπει να απορρίπτει διφορούμενα διαπιστευτήρια. Κατά την εισαγωγή, ο χειριστής ή η ροή εργασιών αυτοματισμού πρέπει να ταξινομήσει τα διαπιστευτήρια. Χρησιμοποιήστε τουλάχιστον αυτές τις κατηγορίες:

• Διαπιστευτήρια συμπερασμάτων χρόνου εκτέλεσης: χρησιμοποιούνται από την πύλη για την κλήση τελικών σημείων συμπερασμάτων μοντέλου, όπως συνομιλία, αποκρίσεις, ενσωματώσεις, εποπτεία, μεταγραφή ή δημιουργία εικόνων, ανάλογα με την υποστήριξη του παρόχου.
• Διαπιστευτήρια αυτοματισμού διαχειριστή: χρησιμοποιούνται για τη διαχείριση οργανισμών, χώρων εργασίας, έργων, χρηστών, κλειδιών ή διαχειριστικών πόρων από την πλευρά του παρόχου. Αυτά δεν πρέπει ποτέ να βρίσκονται στη διαδρομή αιτήματος χρόνου εκτέλεσης.
• Διαπιστευτήρια χρέωσης και αναφοράς: χρησιμοποιούνται για την ανάκτηση χρήσης, τιμολογίων, κόστους ή αναφορών οργανισμού όπου οι πάροχοι υποστηρίζουν αυτά τα API. Κρατήστε τα ξεχωριστά από τα κλειδιά συμπερασμάτων, ώστε οι εργασίες αναφοράς να μην μπορούν να δημιουργήσουν χρήση μοντέλου.
• Διαπιστευτήρια μόνο για αξιολόγηση: χρησιμοποιούνται από ροές εργασιών συγκριτικής αξιολόγησης, διασφάλισης ποιότητας, μετεγκατάστασης ή σταδιοποίησης. Θα πρέπει να έχουν χαμηλές ποσοστώσεις, σαφείς περιβαλλοντικές ετικέτες και χωρίς εναλλακτική καταλληλότητα παραγωγής.
• Διαπιστευτήρια BYOK πελάτη: κλειδιά που παρέχονται από τον πελάτη δεσμευμένα σε συγκεκριμένο μισθωτή, λογαριασμό παρόχου, σύμβαση και πολιτική δεδομένων. Δεν θα πρέπει να συγκεντρώνονται σε κοινόχρηστη δρομολόγηση εκτός εάν ο πελάτης επιλέξει ρητά.

Αυτή η ταξινόμηση δεν είναι απλώς τεκμηρίωση. Θα πρέπει να καθοδηγεί τον έλεγχο πρόσβασης, την καταλληλότητα δρομολόγησης, τις ειδοποιήσεις και τις ροές εργασίας εναλλαγής. Εάν ένα διαπιστευτήριο εισάγεται χωρίς κατηγορία, κάτοχο, όριο λογαριασμού παρόχου και επιτρέπεται χρήση, θα πρέπει να παραμείνει απενεργοποιημένο.

Αποθηκεύστε μυστικά σε θησαυροφυλάκιο, όχι σε αρχεία προϊόντων

Το θησαυροφυλάκιο θα πρέπει να είναι το μόνο στοιχείο που μπορεί να αποκρυπτογραφήσει τα διαπιστευτήρια ανάντη. Άλλα συστήματα ενδέχεται να αποθηκεύουν αναφορές, κατακερματισμούς, πεδία κατάστασης και μεταδεδομένα πολιτικής, αλλά όχι την ίδια την τιμή διαπιστευτηρίων.

Μην αποθηκεύετε μυστικά ανάντη σε αυτά τα μέρη

• Σειρές προφίλ μισθωτή.
• Μοντέλο αρχείων διαμόρφωσης δρομολόγησης.
• Αρχεία καταγραφής μηνυμάτων ή διαστήματα ανίχνευσης.
• Ωφέλιμα φορτία συμβάντων Analytics.
• Μεταβλητές CI που αντιμετωπίζουν οι προγραμματιστές.
• Υποστηρίξτε εισιτήρια, εργαλεία συνομιλίας ή στιγμιότυπα οθόνης.

Ένα χρησιμοποιήσιμο σχέδιο θόλου έχει δύο επίπεδα. Το μυστικό αεροπλάνο αποθηκεύει κρυπτογραφημένο υλικό διαπιστευτηρίων και ελέγχει αυστηρά τις λειτουργίες αποκρυπτογράφησης. Το επίπεδο μεταδεδομένων αποθηκεύει μη απόρρητα χαρακτηριστικά που χρησιμοποιούνται από τη δρομολόγηση και τη διακυβέρνηση. Ο δρομολογητής θα πρέπει συνήθως να χρειάζεται μόνο ένα αναγνωριστικό διαπιστευτηρίων και μια βραχύβια ανάκτηση μυστικού στη μνήμη κατά τον χρόνο αποστολής, όχι ευρεία πρόσβαση στη βάση δεδομένων σε κάθε κλειδί παρόχου.

Προστατέψτε το θησαυροφυλάκιο ως υποδομή υψηλής αξίας: κρυπτογράφηση φακέλων ή διαχειριζόμενο KMS, αυστηρές ταυτότητες υπηρεσίας, διαδικασίες σπασίματος, δοκιμές δημιουργίας αντιγράφων ασφαλείας και επαναφοράς, έλεγχος πρόσβασης και ειδοποίηση για ασυνήθιστο όγκο αποκρυπτογράφησης. Ένα κεντρικό θησαυροφυλάκιο απλοποιεί τη διακυβέρνηση, αλλά συγκεντρώνει επίσης τον κίνδυνο. Αυτός είναι ο συμβιβασμός.

Επισυνάψτε μεταδεδομένα πολιτικής σε κάθε διαπιστευτήριο

Το μοντέλο μεταδεδομένων θα πρέπει να είναι αρκετά σαφές ώστε η πύλη να μπορεί να αποφασίσει εάν ένα διαπιστευτήριο είναι κατάλληλο προτού αγγίξει ένα τελικό σημείο παρόχου.

Μια πρακτική εγγραφή διαπιστευτηρίων περιλαμβάνει:

• credential_id: εσωτερικό αμετάβλητο αναγνωριστικό.
• πάροχος: OpenAI, Anthropic, Gemini, Azure OpenAI ή άλλος προσαρμογέας.
• όριο_λογαριασμού_παρόχου: οργανισμός, έργο, χώρος εργασίας, έργο cloud, συνδρομή ή ισοδύναμο.
• credential_class: χρόνος εκτέλεσης, διαχειριστής, χρέωσης, αξιολόγησης ή BYOK.
• περιβάλλον: παραγωγή, σκηνοθεσία, ανάπτυξη, αξιολόγηση, sandbox.
• tenant_binding: κοινόχρηστο διαπιστευτήριο πλατφόρμας, μεμονωμένος μισθωτής, ομάδα ενοικιαστών ή μισθωτής BYOK πελάτη.
• allowed_model_families: για παράδειγμα, δημιουργία κειμένου, ενσωματώσεις, όραμα, εικόνα, ήχος ή προφίλ συγκεκριμένων μοντέλων.
• allowed_endpoints: κανονικοποιημένες δυνατότητες πύλης που αντιστοιχίζονται στα τελικά σημεία παρόχου.
• data_policy: επιτρέπεται η τάξη διατήρησης, η τάξη καταγραφής, η απαίτηση κατοικίας και οι περιορισμοί χαρακτηριστικών.
• scope_budget: κέντρο κόστους, πελάτης μεταπωλητή, εσωτερικό τμήμα ή σύμβαση.
• κάτοχος: κατονομαζόμενη ομάδα ή υπόλογο άτομο.
• created_at, expires_at, rotation_due_at, last_used_at.
• κατάσταση_υγείας: άγνωστο, υγιές, υποβαθμισμένο, μη εξουσιοδοτημένο, όριο_εξαντλημένο, απενεργοποιημένο.
• emergency_disable: άμεσο μπλοκ δρομολόγησης ανεξάρτητα από την κανονική κατάσταση πολιτικής.

Διατηρήστε αυτό το μοντέλο ουδέτερο ως προς τον πάροχο, αλλά μην διαγράψετε τις πραγματικότητες του παρόχου. Ένα Anthropic κλειδί συνδεδεμένο σε χώρο εργασίας και ένα κλειδί Gemini που συνδέεται με ένα έργο Google Cloud δεν είναι εναλλάξιμα μόνο και μόνο επειδή και τα δύο μπορούν να δημιουργήσουν κείμενο. Η πύλη χρειάζεται αυτή την προέλευση για ελέγχους, αντιστροφή χρέωσης και ασφαλή ανακατεύθυνση.

Ξεχωριστή πρόσβαση χρόνου εκτέλεσης, διαχειριστή και χρέωσης

Ο πιο σημαντικός κανόνας είναι απλός: ένα κλειδί που χρησιμοποιείται για συμπέρασμα χρόνου εκτέλεσης δεν πρέπει να διαχειρίζεται οργανισμούς παρόχων, χώρους εργασίας, χρήστες, έργα ή διαχειριστικούς πόρους.

Η κυκλοφορία χρόνου εκτέλεσης είναι μεγάλος όγκος και εκτίθεται στη μεγαλύτερη επιχειρησιακή επιφάνεια. Περνά από δρομολογητές αιτημάτων, λογική επανάληψης δοκιμής, χειριστές ροής, προσαρμογείς μοντέλων και ροές εργασίας περιστατικών. Τα διαπιστευτήρια διαχειριστή είναι χαμηλής συχνότητας και υψηλού αντίκτυπου. Θα πρέπει να ζουν πίσω από μια ξεχωριστή διαδρομή έγκρισης με σύντομα TTL, που ονομάζονται ανθρώπινη έγκριση όπου χρειάζεται, ισχυρή καταγραφή και χωρίς καταλληλότητα δρομολόγησης χρόνου εκτέλεσης.

Τα διαπιστευτήρια χρέωσης αξίζουν επίσης διαχωρισμό. Μια εργασία αναφοράς που συμβιβάζει τιμολόγια δεν θα πρέπει να μπορεί να δημιουργήσει συμπληρώσεις και ένα κλειδί συμπερασμάτων χρόνου εκτέλεσης δεν θα πρέπει να είναι ο μόνος τρόπος για την ανάκτηση αναφορών χρήσης. Όταν ένας πάροχος δεν προσφέρει λεπτομερή διαχωρισμό, αντισταθμίστε το στην πύλη: απομονώστε το διαπιστευτήριο, περιορίστε ποια ταυτότητα εσωτερικής υπηρεσίας μπορεί να το ανακτήσει και καταγράψτε κάθε χρήση.

Σύσταση: ορίστε την κατηγορία διαπιστευτηρίων ένα σκληρό όριο εξουσιοδότησης, όχι μια ετικέτα. Ένας διεκπεραιωτής χρόνου εκτέλεσης δεν θα πρέπει να μπορεί να ζητήσει αποκρυπτογράφηση για ένα διαπιστευτήριο διαχειριστή, ακόμη και αν ένα λάθος διαμόρφωσης αναφέρεται στο αναγνωριστικό του.

Δημιουργήστε μια μηχανή πολιτικής επιλογής διαπιστευτηρίων

Η επιλογή διαπιστευτηρίων θα πρέπει να γίνει αφού η πύλη ελέγξει την ταυτότητα του μεταγενέστερου καλούντος και προτού επιχειρηθεί οποιαδήποτε κλήση παρόχου. Η μηχανή πολιτικής πρέπει να ενώνει πολλές εισόδους:

• Αναγνωριστικό μισθωτή και εύρος κλειδιού μεταγενέστερου API.
• Ζητήθηκε προφίλ μοντέλου ή αναγνωριστικό μοντέλου για συγκεκριμένο πάροχο.
• Δυνατότητα τελικού σημείου: συνομιλία, ενσωματώσεις, εικόνα, ήχος, δέσμη, αρχεία, εργαλεία ή αυτοματισμός διαχειριστή.
• Απαιτήσεις διατήρησης δεδομένων και κατοικίας.
• Προϋπολογισμός, κράτηση πίστωσης και κέντρο κόστους.
• Κατάσταση ορίου ρυθμού και πίεση ποσόστωσης.
• Δέσμευση μεταδεδομένων διαπιστευτηρίων, υγεία, περιβάλλον και μισθωτή.

Ο κινητήρας θα πρέπει να εμφανίσει ένα από τα τρία αποτελέσματα: να επιτρέπεται με ένα επιλεγμένο διαπιστευτήριο, να απορρίπτεται λόγω πολιτικής ή να απαιτείται έγκριση. Οι αρνήσεις θα πρέπει να είναι αρκετά ακριβείς ώστε οι ομάδες επιχειρήσεων να επιλύσουν το πρόβλημα χωρίς να αποκαλύπτουν μυστικό υλικό στους προγραμματιστές.

Παράδειγμα απόφασης:

{
  "tenant_id": "tenant_42",
  "requested_profile": "fast-text-prod",
  "endpoint": "chat.completions",
  "data_policy": "no_prompt_logging",
  "credential_requirements": {
    "class": "runtime",
    "περιβάλλον": "παραγωγή",
    "tenant_binding": "tenant_42",
    "allowed_model_family": "κείμενο",
    "health_status": "υγιής"
  },
  "απόφαση": "επιτρέπω",
  "credential_id": "cred_8f2...",
  "audit_reason": "τα διαπιστευτήρια BYOK ενοικιαστή ταιριάζει με το προφίλ κειμένου χρόνου εκτέλεσης και την πολιτική δεδομένων"
}

Μην εφαρμόσετε εναλλακτική ως "δοκιμάστε το επόμενο κλειδί". Η εναλλακτική πολιτική πρέπει να επαναληφθεί. Ένα διαπιστευτήριο κοινόχρηστης πλατφόρμας μπορεί να είναι έγκυρο για πρόσβαση παρόχου, αλλά μη έγκυρο για πελάτη μόνο BYOK. Ένα διαπιστευτήριο σε άλλο έργο μπορεί να έχει όριο, αλλά μπορεί να παραβιάζει τις απαιτήσεις απόδοσης κόστους ή διατήρησης.

Χειριστείτε το BYOK ως πρόσβαση που ανήκει στον ενοικιαστή, όχι ως πλεονάζουσα χωρητικότητα

Το BYOK αλλάζει το μοντέλο εμπιστοσύνης. Ο πελάτης παρείχε τα διαπιστευτήρια, ώστε η επισκεψιμότητά του να μπορεί να χρεωθεί, να διέπεται από ή να απομονώνεται στον λογαριασμό παρόχου του. Αυτό το διαπιστευτήριο θα πρέπει να δεσμεύεται από την προέλευση του λογαριασμού μισθωτή πελάτη και παρόχου.

Προτεινόμενα στοιχεία ελέγχου BYOK:

• Μία εγγραφή θησαυροφυλακίου ανά πελάτη, πάροχο, όρια λογαριασμού και περιβάλλον.
• Δεν υπάρχει δρομολόγηση μεταξύ ενοικιαστών μέσω διαπιστευτηρίων BYOK.
• Δεν χρησιμοποιείται ως κοινόχρηστη εναλλακτική χωρητικότητα εκτός εάν ο πελάτης επιλέξει ρητά.
• Κατάσταση υγείας ορατή από τον πελάτη που δεν αποκαλύπτει το μη επεξεργασμένο κλειδί.
• Ξεχωριστή ροή εργασιών εναλλαγής που επιτρέπει στον πελάτη να προσθέσει μια αντικατάσταση πριν απενεργοποιηθεί το παλιό κλειδί.
• Διαγράψτε την απόδοση στα αναλυτικά στοιχεία χρήσης και στα τιμολόγια: μισθωτής πύλης, όριο λογαριασμού παρόχου, αναγνωριστικό διαπιστευτηρίων, προφίλ μοντέλου και αναγνωριστικό ίχνους αιτήματος.

Για τις εταιρείες, τους μεταπωλητές και τον αυτοματισμό Partner API, το BYOK μπορεί να είναι πιο περίπλοκο, επειδή μια υπηρεσία μπορεί να παρέχει ενοικιαστές και διαπιστευτήρια μέσω προγραμματισμού. Ο ίδιος κανόνας εξακολουθεί να ισχύει: ο αυτοματισμός μπορεί να εισάγει και να δεσμεύει διαπιστευτήρια, αλλά δεν θα πρέπει να θολώνει την ιδιοκτησία του ενοικιαστή.

Προσθέστε υγειονομικούς ελέγχους πριν από την πτήση χωρίς προτροπές διαρροής

Ένα διαπιστευτήριο μπορεί να αποτύχει για πολλούς λόγους: ανάκληση κλειδιού, λάθος χώρο εργασίας, έλλειψη πρόσβασης μοντέλου, απενεργοποιημένη χρέωση, εξάντληση ορίου, περιορισμός τελικού σημείου, αναντιστοιχία περιφερειακής πολιτικής ή διακοπή παροχής. Η ανακάλυψη ότι μόνο μετά την άφιξη ενός αιτήματος παραγωγής δημιουργεί θορυβώδη περιστατικά.

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

Οι υγειονομικοί έλεγχοι θα πρέπει να εκτελούνται:

• Κατά την εισαγωγή διαπιστευτηρίων.
• Πριν ενεργοποιήσετε ένα διαπιστευτήριο για δρομολόγηση παραγωγής.
• Μετά από αλλαγές περιορισμών από την πλευρά του παρόχου.
• Κατά την εναλλαγή περιστροφής.
• Περιοδικά για διαπιστευτήρια με καταλληλότητα παραγωγής.

Αντικατάσταση: οι αυτοματοποιημένοι έλεγχοι εντοπίζουν νωρίς ληγμένα κλειδιά ή κλειδιά με χαμηλό εύρος, αλλά οι εσφαλμένα σχεδιασμένοι έλεγχοι μπορούν να δημιουργήσουν περιττές κλήσεις παρόχου, θόρυβο χρέωσης ή ψευδείς συναγερμούς κατά τη διάρκεια διακοπών του παρόχου. Αποθηκεύστε το αποτέλεσμα υγείας με χρονική σήμανση, κατηγορία σφάλματος παρόχου, δοκιμασμένο τελικό σημείο και δοκιμασμένη οικογένεια μοντέλων. Μην αποθηκεύετε μυστικές τιμές ή ευαίσθητα μηνύματα.

Περιστροφή με δύο υποδοχές, όχι μία επικίνδυνη αντικατάσταση

Η εναλλαγή διαπιστευτηρίων δεν πρέπει να είναι μια λειτουργία διαγραφής και προσευχής. Χρησιμοποιήστε ένα μοντέλο περιστροφής δύο θυρίδων:

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

Οι προθεσμίες εναλλαγής θα πρέπει να είναι ορατές στις προβολές λειτουργιών και στις ειδοποιήσεις. Η εναλλαγή έκτακτης ανάγκης χρειάζεται μια συντομότερη διαδρομή: απενεργοποιήστε τα διαπιστευτήρια, αποκλείστε τη δρομολόγηση, ενεργοποιήστε την εγκεκριμένη αντικατάσταση και διατηρήστε όλα τα αρχεία ελέγχου για έλεγχο συμβάντων.

Περιορίστε τα κλειδιά παρόχου όπου το υποστηρίζει ο πάροχος

Η πολιτική πύλης είναι απαραίτητη, αλλά οι περιορισμοί από την πλευρά του παρόχου μειώνουν την ακτίνα έκρηξης σε περίπτωση παραβίασης ή κακής χρήσης ενός κλειδιού. Για το Gemini και άλλα κλειδιά API πλατφόρμας cloud, χρησιμοποιήστε περιορισμούς API/υπηρεσίας και κατάλληλους περιορισμούς εφαρμογών όπου είναι διαθέσιμοι. Για έργα παρόχου, χώρους εργασίας και λογαριασμούς υπηρεσιών, αποφύγετε τα μεγάλα οργανωτικά προνόμια όταν αρκεί ένα κλειδί χρόνου εκτέλεσης με εμβέλεια έργου.

Σύσταση: διατηρήστε μια λίστα ελέγχου περιορισμών από την πλευρά του παρόχου για κάθε κατηγορία διαπιστευτηρίων. Η λίστα ελέγχου πρέπει να αποτελεί μέρος της έγκρισης εισαγωγής και της έγκρισης εναλλαγής, όχι μια ξεχωριστή εργασία ασφαλείας που μπορεί να παραλειφθεί υπό πίεση.

Αναλλαγή: οι περιορισμοί από την πλευρά του παρόχου προσθέτουν λειτουργικά έξοδα. Τα νέα τελικά σημεία, οι οικογένειες μοντέλων, οι περιοχές ή οι δυνατότητες αυτοματισμού ενδέχεται να απαιτούν αλλαγές πολιτικής και περιορισμών. Αυτό είναι προτιμότερο από το να ανακαλύψετε μετά από διαρροή ότι ένα κλειδί θα μπορούσε να έχει πρόσβαση σε κάθε φόρτο εργασίας σε ένα κοινόχρηστο έργο.

Διατηρήστε ένα αρχείο καταγραφής ελέγχου διαπιστευτηρίων μόνο για προσάρτημα

Μια διαδρομή ελέγχου θα πρέπει να απαντά ποιος εισήγαγε ένα διαπιστευτήριο, τι του επιτρέπεται να κάνει, ποιες αποφάσεις δρομολόγησης το επέλεξαν, πότε απέτυχε και πότε εναλλάχθηκε ή ανακλήθηκε.

Καταγραφή αυτών των συμβάντων:

• Δημιουργήθηκε ή εισήχθη διαπιστευτήριο.
• Τα μεταδεδομένα άλλαξαν, συμπεριλαμβανομένων των επιτρεπόμενων τελικών σημείων, της δέσμευσης μισθωτή ή της πολιτικής δεδομένων.
• Έγινε έλεγχος υγείας και καταγράφηκε το αποτέλεσμα.
• Το διαπιστευτήριο επιλέχθηκε από την πολιτική δρομολόγησης για ένα αίτημα.
• Αποκρυπτογράφηση διαπιστευτηρίων ζητήθηκε από μια εσωτερική ταυτότητα υπηρεσίας.
• Η κλήση παρόχου απέτυχε λόγω σφάλματος ελέγχου ταυτότητας, εξουσιοδότησης, ορίου ή περιορισμού.
• Ξεκίνησε η εναλλαγή, η κυκλοφορία μετατοπίστηκε, το παλιό διαπιστευτήριο ανακλήθηκε.
• Ενεργοποιήθηκε ή διαγράφηκε η απενεργοποίηση έκτακτης ανάγκης.
• Πρόσβαση σε διαπιστευτήριο διαχειριστή ή διαπιστευτηρίου.

Μην τοποθετείτε ακατέργαστες τιμές διαπιστευτηρίων σε συμβάντα ελέγχου. Χρησιμοποιήστε αναγνωριστικά διαπιστευτηρίων, όρια λογαριασμών παρόχου, ζητήστε αναγνωριστικά ιχνών, ταυτότητες ηθοποιών και λόγους απόφασης πολιτικής. Για επισκεψιμότητα μεγάλου όγκου χρόνου εκτέλεσης, μπορείτε να δοκιμάσετε λεπτομερή τηλεμετρία αποκρυπτογράφησης, αλλά η επιλογή δρομολόγησης και η απόδοση κόστους θα πρέπει να παραμείνουν αρκετά ολοκληρωμένες για την απόκριση χρέωσης και περιστατικού.

Λίστα ελέγχου εφαρμογής

• Δημιουργήστε μια ταξινόμηση διαπιστευτηρίων και απορρίψτε τις μη ταξινομημένες εισαγωγές.
• Μετακινήστε όλα τα μυστικά του παρόχου σε ένα αποκλειστικό κρυπτογραφημένο θησαυροφυλάκιο.
• Αποθηκεύστε τα μεταδεδομένα δρομολόγησης ξεχωριστά από μυστικό υλικό.
• Κάντε τα διαπιστευτήρια χρόνου εκτέλεσης, διαχειριστή, χρέωσης, αξιολόγησης και BYOK ξεχωριστές κατηγορίες εξουσιοδότησης.
• Δέστε τα διαπιστευτήρια BYOK με την προέλευση του λογαριασμού μισθωτή και παρόχου.
• Απαιτήστε έγκριση μηχανισμού πολιτικής προτού επιλέξετε οποιοδήποτε διαπιστευτήριο ανόδου.
• Εκτέλεση έγκαιρων και ασφαλών υγειονομικών ελέγχων πριν από την καταλληλότητα της παραγωγής.
• Χρησιμοποιήστε την εναλλαγή δύο θέσεων με σταδιακή μετατόπιση κίνησης και ανάκληση από την πλευρά του παρόχου.
• Εφαρμόστε περιορισμούς από την πλευρά του παρόχου όπου είναι διαθέσιμοι.
• Διατηρήστε αρχεία καταγραφής ελέγχου μόνο για προσαρτήσεις για εισαγωγή, χρήση, αποτυχίες, εναλλαγή και ανάκληση.
• Διατηρήστε τα διαπιστευτήρια διαχειριστή πίσω από τα στοιχεία ελέγχου: σύντομο TTL, ονομαστική έγκριση, ισχυρή καταγραφή, χωρίς χρήση χρόνου εκτέλεσης.

Εκκίνητο συμπέρασμα

Ξεκινήστε με την απογραφή κάθε διαπιστευτηρίου ανάντη παρόχου που χρησιμοποιείται αυτήν τη στιγμή από την πύλη, τα σενάρια, τις εργασίες CI, τις πλεξούδες αξιολόγησης και την αυτοματοποίηση συνεργατών. Για κάθε ένα, εκχωρήστε μια τάξη, κάτοχο, όριο λογαριασμού παρόχου, δέσμευση μισθωτή, επιτρεπόμενα τελικά σημεία, επιτρεπόμενες οικογένειες μοντέλων, προθεσμία εναλλαγής και κατάσταση απενεργοποίησης έκτακτης ανάγκης. Οτιδήποτε δεν μπορείτε να ταξινομήσετε θα πρέπει να απενεργοποιηθεί ή να τεθεί σε καραντίνα μέχρι να έχει ξεκάθαρο σκοπό.

Στη συνέχεια, εφαρμόστε έναν αρχιτεκτονικό κανόνα: οι μεταγενέστεροι προγραμματιστές λαμβάνουν κλειδιά με εμβέλεια πύλης. μόνο η πύλη ελέγχει την πρόσβαση του ανάντη παρόχου. Αυτός ο διαχωρισμός σάς επιτρέπει να διατηρείτε τα λιγότερα προνόμια, την απόδοση μισθωτή, την ακρίβεια χρέωσης, τη δρομολόγηση της πολιτικής δεδομένων και την ασφαλή αυτοματοποίηση, ακόμη και όταν πολλαπλασιάζονται οι πάροχοι, τα έργα, οι χώροι εργασίας και οι πελάτες BYOK.

Σχετική ανάγνωση

• διαχείριση κλειδιών API που αντιμετωπίζει ομάδα και απόκριση διαρροών
• πολιτικές δρομολόγησης με επίγνωση δεδομένων
• λογιστικό βιβλίο χρέωσης και στοιχεία ελέγχου απόδοσης κόστους