Προγραμματισμένη εργασία ή ανθρώπινη σύνδεση: ποια ταυτότητα πρέπει να βλέπει το API;
Μια εργασία cron και ένα άτομο σε προτροπή σύνδεσης είναι διαφορετικοί υποκείμενοι. Συγκρίνετε διαδρομή δικτύου, ταυτότητα εφαρμογής και ανάθεση πριν αυτοματοποιήσετε.
Μια προγραμματισμένη εργασία και ένα άτομο σε προτροπή σύνδεσης καλούν το ίδιο API με διαφορετικά διαπιστευτήρια, διαφορετική διάρκεια ζωής και διαφορετικούς ιδιοκτήτες. Η εργασία χρειάζεται διαδρομή δικτύου, ταυτότητα εφαρμογής και σύνολο δικαιωμάτων· το άτομο χρειάζεται σύνδεση, δεύτερο παράγοντα και συνεδρία. Η ανάμειξη των δύο παράγει αυτοματοποίηση που σπάει κάθε φορά που αλλάζει ο κωδικός του ατόμου, ή πολιτική πολλαπλών παραγόντων αποδυναμωμένη όσο ακριβώς χρειάζεται για να μείνει ζωντανή μια εργασία cron.
Τρεις πύλες που μοιάζουν με μία
Ένας κανόνας διεύθυνσης προέλευσης ρωτά από πού ήρθε το αίτημα. Η ταυτοποίηση ρωτά ποιος καλεί και ποια στοιχεία παρουσιάστηκαν. Η εξουσιοδότηση ρωτά αν αυτός ο υποκείμενος μπορεί να εκτελέσει αυτή τη λειτουργία. Ένα VPN αλλάζει μόνο την πρώτη από τις τρεις και την αλλάζει για κάθε διεργασία στον κεντρικό υπολογιστή και όχι μόνο για την εργασία, γι' αυτό κρατήστε τις τρεις παρατηρήσεις χωριστά στην καταγραφή του συμβάντος.
Γι' αυτό η αλλαγή του κόμβου εξόδου μπορεί να διορθώσει μια απόρριψη λόγω διεύθυνσης προέλευσης και να αφήσει ένα μη έγκυρο διακριτικό ανέγγιχτο. Γι' αυτό επίσης ένα έγκυρο διακριτικό API δεν κάνει ένα ιδιωτικό τελικό σημείο προσβάσιμο από εργασία που δεν έχει διαδρομή προς αυτό.
Η διαδραστική διαδρομή είναι κακό πρότυπο αυτοματοποίησης
Το να γράψετε σε σενάριο τη σύνδεση ενός ατόμου είναι δελεαστικό επειδή λειτουργεί μία φορά. Το σενάριο αποθηκεύει έναν κωδικό, ίσως έναν σπόρο κωδικού μίας χρήσης, και μετά εξαρτάται από μια πρόκληση σχεδιασμένη να απαιτεί άνθρωπο. Η τρέχουσα βέλτιστη πρακτική ασφαλείας για το OAuth, RFC 9700, απαγορεύει την εκχώρηση resource-owner-password-credentials και εξηγεί γιατί ταιριάζει άσχημα με ταυτοποίηση δύο παραγόντων και πολλαπλών βημάτων.
Η υποστηριζόμενη εναλλακτική είναι συνήθως ροή εμπιστευτικού πελάτη, όπου ο διακομιστής εξουσιοδότησης ταυτοποιεί την εφαρμογή και εκδίδει διακριτικό. Η εκχώρηση client-credentials στο RFC 6749 ενότητα 4.4 είναι ένα παράδειγμα. Η ύπαρξή της δεν σημαίνει ότι κάθε API τη δέχεται, ούτε ότι μια εργασία ανατεθειμένη από χρήστη μπορεί να αντικατασταθεί από αυτήν, γιατί αυτά είναι ερωτήματα για τον ιδιοκτήτη της υπηρεσίας. Ρωτήστε ποιο μοντέλο χωρίς επίβλεψη υποστηρίζει η υπηρεσία πριν γράψετε κώδικα.
Πού ανήκει ακόμη το VPN
Ένα VPN μπορεί να παρέχει τη διαδρομή δικτύου που απαιτεί ένα ιδιωτικό API, και αυτός είναι νόμιμος ρόλος. Δεν ταυτοποιεί την εργασία στην εφαρμογή και δεν καθορίζει το εύρος του τι επιτρέπεται να κάνει η εργασία. Μια κοινόχρηστη διεύθυνση εξόδου προσδιορίζει επίσης τον κεντρικό υπολογιστή και όχι την εργασία, οπότε μια καταχώριση στη λίστα επιτρεπόμενων για αυτή τη διεύθυνση δέχεται κάθε διεργασία που εκτελείται σε αυτήν.
Αν η εργασία εκτελείται σε κοινόχρηστο runner, αυτή η διάκριση έχει περισσότερη και όχι λιγότερη σημασία. Μια άλλη ροή εργασίας στον ίδιο κεντρικό υπολογιστή κληρονομεί τη διαδρομή και τη διεύθυνση, και το API δεν μπορεί να ξεχωρίσει τις δύο. Είναι η ίδια αδυναμία με έναν κοινόχρηστο κωδικό, μετατοπισμένη ένα επίπεδο πιο κάτω. Βάλτε τον περιορισμό εκεί όπου η εφαρμογή μπορεί να τον επιβάλει, και απομονώστε τον runner αν δεν μπορείτε να περιορίσετε τη λίστα επιτρεπόμενων.
Συγκρίνετε τα δύο σχέδια με ειλικρίνεια
Η ανθρώπινη σύνδεση σας δίνει ένα πραγματικό άτομο, έναν πραγματικό δεύτερο παράγοντα και μια συνεδρία που μπορεί να ελεγχθεί, και δεν μπορεί να εκτελεστεί χωρίς επίβλεψη. Η ταυτότητα εφαρμογής σας δίνει εκτέλεση χωρίς επίβλεψη, εύρος που μπορεί να ελεγχθεί και διαπιστευτήριο που μπορείτε να περιστρέψετε, και δεν μπορεί να ενεργήσει για χρήστη που δεν έχει αναθέσει τίποτα. Κανένα δεν είναι ασθενέστερη εκδοχή του άλλου· απαντούν σε διαφορετικά ερωτήματα. Επιλέξτε ρωτώντας αν η εργασία πρέπει να εκτελείται χωρίς κανέναν παρόντα και αν η λειτουργία πρέπει να αποδίδεται σε συγκεκριμένο χρήστη.
Αν και οι δύο απαντήσεις είναι ναι, το σχέδιο χρειάζεται μοντέλο ανάθεσης και όχι δανεικό κωδικό. Γράψτε αυτή την απόφαση εκεί όπου θα τη βρει ο επόμενος συντηρητής.
Τι να επαληθεύσετε πριν την παράδοση
Εκτελέστε μία επιτρεπόμενη λειτουργία και μία απαιτούμενη άρνηση από τον πραγματικό worker, και κρατήστε και τα δύο αποτελέσματα. Έπειτα δοκιμάστε ένα ληγμένο διαπιστευτήριο και τη συμπεριφορά όταν η διαδρομή δικτύου δεν είναι διαθέσιμη, γιατί αυτές είναι οι δύο αστοχίες που ξυπνούν κάποιον τη νύχτα.
curl -sS -o /dev/null -w '%{http_code}\n' \
-H "Authorization: Bearer TOKEN" https://api.example.com/v1/records
Καταγράψτε τον υποκείμενο, το εύρος, τον ιδιοκτήτη περιστροφής και το περιβάλλον εκτέλεσης δίπλα σε αυτό το αποτέλεσμα. Αυτή η καταγραφή είναι που κάνει την επόμενη περιστροφή ρουτίνα και όχι συμβάν. Είναι επίσης το κομμάτι που ζητά ένας ελεγκτής.