Ο MCP server σας είναι ασφαλής. Το καθολικό πίσω του, όχι.

Σε πρόσφατο άρθρο εδώ στο Unite.AI, ο Gil Feig παρουσίασε έξι βέλτιστες πρακτικές για τη δημιουργία ενός ασφαλούς MCP server. Είναι σωστές και όποιος διαθέτει έναν MCP server θα πρέπει να τις ακολουθεί. Η συμβουλή του να έχει κάθε ενσωμάτωση «τον δικό της λεπτομερώς καθορισμένο ρόλο, με αυστηρά περιορισμένα δικαιώματα στις απαραίτητες μόνο ενέργειες» είναι απολύτως ορθή. Προϋποθέτει, όμως, ότι το σύστημα στην άλλη πλευρά διαθέτει ρόλους με αντίστοιχα λεπτομερή δικαιώματα. Αυτό υποδηλώνει μια ευρύτερη παραδοχή, που σπάνια διατυπώνεται ρητά: ότι τα συστήματα πίσω από τον server μπορούν να ασφαλιστούν με τα ίδια πρότυπα.

Στα επιχειρηματικά προγράμματα, συχνά αυτό δεν είναι εφικτό. Είμαι επικεφαλής της ομάδας μηχανικών που αναπτύσσει ένα επίπεδο διασύνδεσης με 32 λογιστικά συστήματα και συστήματα ERP, πάνω στο οποίο μπορεί προαιρετικά να προστεθεί ένας MCP server. Βλέπουμε συχνά πράκτορες που από τη δική μας πλευρά έχουν πιστοποιηθεί σωστά, διαθέτουν σαφώς οριοθετημένα δικαιώματα και καταγράφονται επαρκώς, αλλά γράφουν σε συστήματα που δεν έχουν κανέναν τρόπο να γνωρίζουν ότι συμμετείχε πράκτορας.

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

Πού παραδίδει τη σκυτάλη η προδιαγραφή MCP

Η προδιαγραφή εξουσιοδότησης MCP ορίζει με σαφήνεια τα όριά της. Ο MCP server λειτουργεί ως διακομιστής πόρων OAuth για τους πελάτες του. Όταν καλεί ένα ανάντη API, ενεργεί ως ξεχωριστός πελάτης OAuth, με ξεχωριστό διακριτικό που εκδίδεται από το ανάντη σύστημα. Η προώθηση του διακριτικού του πελάτη απαγορεύεται ρητά.

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

Το ίδιο ισχύει και για τις οδηγίες του OWASP για την υπερβολική αυτονομία. Συνιστούν να περιορίζονται τα δικαιώματα που διαθέτουν οι επεκτάσεις ενός πράκτορα σε άλλα συστήματα στα απολύτως απαραίτητα και οι ενέργειες να εκτελούνται στο πλαίσιο του χρήστη για λογαριασμό του οποίου ενεργεί ο πράκτορας. Και οι δύο συμβουλές είναι σωστές. Και οι δύο προϋποθέτουν ότι το άλλο σύστημα μπορεί να ορίσει ελάχιστα δικαιώματα και το πλαίσιο του χρήστη.

Τι προσφέρουν στην πράξη τα ανάντη συστήματα

Αυτή είναι η εικόνα των 32 λογιστικών συστημάτων και συστημάτων ERP με τα οποία συνδεόμαστε, από τη σκοπιά ενός φορέα διασύνδεσης.

Το ένα τρίτο δεν διαθέτει καθόλου OAuth

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

Μεγάλη διάρκεια ισχύος, ελάχιστες δυνατότητες ανάκλησης

Το OAuth βοηθά λιγότερο απ’ όσο θα περίμενε κανείς. Ένας πάροχος εκδίδει διακριτικά ανανέωσης με διάρκεια ζωής περίπου 20 ετών. Πρόκειται για ένα διαπιστευτήριο σχεδιασμένο να διαρκέσει περισσότερο από τον πράκτορα που το χρησιμοποιεί, το πλαίσιο πάνω στο οποίο αναπτύχθηκε ο πράκτορας και, πιθανότατα, ακόμη και το άτομο που πάτησε «Να επιτρέπεται». Σε ένα άλλο σύστημα, δεν λήγουν ούτε τα διακριτικά πρόσβασης.

Και όταν ένα διαπιστευτήριο έχει ήδη εκδοθεί, το ερώτημα είναι ποιος μπορεί να το απενεργοποιήσει. Το πρότυπο γι’ αυτό, η ανάκληση διακριτικών OAuth (RFC 7009), ισχύει από το 2013. Παρ’ όλα αυτά, σε περίπου τέσσερα στα δέκα συστήματα δεν υπάρχει τεχνικός τρόπος για τον φορέα διασύνδεσης να ανακαλέσει τα διαπιστευτήρια. Σε αυτή την κατηγορία ανήκουν όλα τα συστήματα που χρησιμοποιούν κλειδιά API. Η μόνη δυνατότητα που απομένει είναι να ζητηθεί από τον πελάτη να διαγράψει χειροκίνητα την πρόσβαση.

Περιορισμένα πεδία δικαιωμάτων, καμία ταυτότητα πράκτορα

Τα περισσότερα στατικά κλειδιά κληρονομούν απλώς όλα τα δικαιώματα του χρήστη που τα δημιούργησε· μόνο λίγα συστήματα επιτρέπουν τον περιορισμό ενός κλειδιού σε συγκεκριμένα τελικά σημεία. Πολλά συστήματα OAuth διαθέτουν πεδία δικαιωμάτων, αλλά συνήθως είναι γενικά, όπως «λογιστική, ανάγνωση και εγγραφή». Και στα 32 συστήματα δεν βρήκαμε κανέναν τρόπο καταγραφής μέσω API, στην ίδια συναλλαγή, τόσο του πράκτορα όσο και του ατόμου για λογαριασμό του οποίου ενεργεί. Οι εξωτερικοί πράκτορες εμφανίζονται είτε ως ο χρήστης που τους συνέδεσε είτε ως γενικός χρήστης συστήματος. Είναι ενδεικτικό ότι, όταν ένας προμηθευτής ενσωματώνει πράκτορες στο δικό του προϊόν, όπως έχει κάνει η Microsoft στο Business Central, τους δίνει αποκλειστικούς λογαριασμούς χρηστών. Αυτό είναι το ίδιο μοντέλο που προτείνω παρακάτω, με τη διαφορά ότι προορίζεται μόνο για τους πράκτορες του ίδιου του προμηθευτή.

Τι μπορεί να επιβάλει το επίπεδο διασύνδεσης

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

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

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

Πού σταματά ο έλεγχος

Αυτό που δεν μπορείτε να κάνετε είναι να επεκτείνετε αυτό το επίπεδο πέρα από τα όρια του συστήματος. Εκεί καταρρέουν τρία πράγματα.

Απόδοση ενεργειών

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

Οι περισσότερες οργανώσεις δεν έχουν προχωρήσει περισσότερο σε αυτό. Σε μια έρευνα της Cloud Security Alliance, μόλις το 28% των ερωτηθέντων δήλωσε ότι μπορούσε να εντοπίζει αξιόπιστα τις ενέργειες των πρακτόρων και να τις αποδίδει σε άνθρωπο ή σύστημα σε όλα τα περιβάλλοντα, ενώ το 44% χρησιμοποιεί ή σχεδιάζει να χρησιμοποιήσει στατικά κλειδιά API για τους πράκτορές του.

Αρχή των ελάχιστων προνομίων

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

Ανάκληση

Μπορείτε να απενεργοποιήσετε αμέσως τον δικό σας πράκτορα. Αυτό δεν βοηθά αν έχουν παραβιαστεί τα ίδια τα διαπιστευτήρια πρόσβασης στο σύστημα-στόχο. Και για τα τέσσερα στα δέκα συστήματα που δεν διαθέτουν endpoint ανάκλησης, ο διακόπτης απενεργοποίησης είναι ένα email προς τον πελάτη.

Η πρακτική λύση: ξεχωριστός χρήστης για τον πράκτορα

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

Λειτουργεί σε κάθε σύστημα που επιτρέπει τη δημιουργία χρηστών και προσφέρει τρία πράγματα που το επίπεδο διασύνδεσης δεν μπορεί να εξασφαλίσει:

• Απόδοση ενεργειών στο σύστημα καταγραφής. Οι καταχωρίσεις εμφανίζονται με την ένδειξη «Πράκτορας πληρωτέων λογαριασμών» και όχι στο όνομα του οικονομικού διευθυντή που πάτησε «Σύνδεση» πριν από έξι μήνες.
• Δυνατότητα ανάκλησης, ακόμη και χωρίς API. Ο πελάτης μπορεί να απενεργοποιήσει τον χρήστη από το περιβάλλον εργασίας, κάτι που λειτουργεί και σε συστήματα χωρίς endpoint ανάκλησης.
• Μερική εφαρμογή της αρχής των ελάχιστων προνομίων. Όταν το σύστημα διαθέτει έστω και κάποιο μοντέλο ρόλων, ο χρήστης του πράκτορα μπορεί συχνά να περιοριστεί στις ενότητες που χρειάζεται πραγματικά.

Το κόστος είναι πραγματικό. Κάποιος πρέπει να δημιουργεί τον χρήστη χειροκίνητα κατά την αρχική εγκατάσταση, προσθέτοντας τριβή ακριβώς τη χειρότερη στιγμή. Περίπου τα μισά συστήματα χρεώνουν για κάθε πρόσθετο χρήστη, από λίγα ευρώ τον μήνα στα εργαλεία για μικρές επιχειρήσεις έως και πάνω από εκατό ευρώ σε ένα ολοκληρωμένο ERP. Αρκετά άλλα περιορίζουν τον αριθμό χρηστών ανάλογα με το πρόγραμμα, οπότε ένας επιπλέον χρήστης μπορεί να συνεπάγεται ακριβότερο πρόγραμμα για ολόκληρη την εταιρεία. Και ένας χρήστης υπηρεσίας που δεν ανήκει σε κανέναν γίνεται ο ίδιος πηγή κινδύνου, μέρος της ανεξέλεγκτης εξάπλωσης μη ανθρώπινων ταυτοτήτων που έχει καλύψει παλαιότερα το Unite.AI. Χρειάζεται έναν υπεύθυνο και μια ημερομηνία επανεξέτασης, όπως κάθε άλλος λογαριασμός.

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

Η δομική λύση: ανάθεση ταυτότητας

Η σωστή απάντηση υπάρχει ήδη στα χαρτιά. Η ανταλλαγή διακριτικών OAuth 2.0 (RFC 8693) διακρίνει την πλαστοπροσωπία από την ανάθεση. Με την ανάθεση, ο πράκτορας διατηρεί τη δική του ταυτότητα και το διακριτικό καταγράφει ότι ενεργεί για λογαριασμό ενός προσώπου, μέσω της δήλωσης «act».

Αν εφαρμοζόταν στη λογιστική, αυτό θα σήμαινε ότι:

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

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

Τι να κάνετε πριν ένας πράκτορας αλληλεπιδράσει με ένα καθολικό

Αν συνδέετε πράκτορες με λογιστικά συστήματα ή συστήματα ERP, ακολουθήστε αυτόν τον σύντομο κατάλογο ελέγχου:

1. Χαρτογραφήστε το μοντέλο διαπιστευτηρίων κάθε συστήματος-στόχου. Χρησιμοποιεί OAuth ή στατικό κλειδί; Για πόσο διάστημα ισχύει το διαπιστευτήριο; Διαθέτει πεδία δικαιωμάτων και μπορείτε να το ανακαλέσετε;
2. Δημιουργήστε ούτως ή άλλως το δικό σας επίπεδο ελέγχου πρόσβασης. Η ταυτότητα ανά πράκτορα, τα πεδία δικαιωμάτων, η ιδιοδυναμία και οι εγκρίσεις πρέπει να διασφαλίζονται από τη δική σας πλευρά, ό,τι κι αν προσφέρει το σύστημα-στόχος.
3. Χρησιμοποιήστε ξεχωριστό χρήστη για τον πράκτορα όπου το επιτρέπει το σύστημα. Αποδεχτείτε τον χρόνο που απαιτείται για την αρχική εγκατάσταση και το κόστος της άδειας χρήσης ως τίμημα για τη δυνατότητα απόδοσης των ενεργειών.
4. Διατηρείτε το δικό σας ίχνος ελέγχου με τρόπο που να επιτρέπει τον εντοπισμό τυχόν παραποίησης. Για πολλά συστήματα, θα είναι το μόνο αρχείο που αποδεικνύει ότι συμμετείχε πράκτορας.
5. Καταγράψτε τον υπολειπόμενο κίνδυνο. Αν ένα σύστημα δεν διαθέτει δικαιώματα περιορισμένης πρόσβασης και δυνατότητα ανάκλησης, αναφέρετέ το στον πελάτη σας και στο δικό σας μητρώο κινδύνων.

Το όριο είναι το κρίσιμο σημείο

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

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