Τα σημερινά application programming interface(API) δεν είναι πλέον ούτε απλά ούτε front-facing, δημιουργώντας νέους κινδύνους τόσο για την ασφάλεια όσο και για τα DevOps.
Όλα τα API είναι διαφορετικά στο εσωτερικό τους, ακόμα κι αν χρησιμοποιούν παρόμοια πλαίσια και αρχιτεκτονικές, όπως το REST. Κάτω από οποιαδήποτε αρχιτεκτονική “στέγη”, τα πρωτόκολλα δεδομένων είναι πάντα διαφορετικά – ακόμα και όταν η δομή είναι η ίδια.
Έχετε ακούσει πιθανώς συγκεκριμένες μορφές πρωτοκόλλου, όπως REST, JSON, XML και gRPC. Αυτές είναι στην πραγματικότητα μορφοποίηση δεδομένων και γλώσσες μεταφοράς που λειτουργούν σύμφωνα με το API. Μέσα σε αυτές τις μορφές υπάρχει μεγάλη ποικιλία.
Από την άποψη της ασφάλειας, το ίδιο το πρωτόκολλο δεν κάνει τίποτα. Για να είναι αποτελεσματική, η ασφάλεια πρέπει να μεταφράζει τη γλώσσα και την πρόθεση του κάθε προσώπου που διέρχεται, όχι μόνο να αφήνει τους «επιβάτες» να περιηγούνται ελεύθερα.
Ακολουθούν πέντε προκλήσεις σε ότι αφορά την προστασία των API:
Δεν υπάρχουν δύο εφαρμογές που να είναι παρόμοιες
Προκειμένου να προστατεύσουμε ένα API, πρέπει επίσης να γνωρίζουμε πώς σχεδιάστηκε αρχικά. Δεν γίνεται διαβάζοντας μόνο τον κώδικα ή τις μορφοποιήσεις κωδικοποίησης. Είναι ανάγνωση και ταξινόμηση μέσω των στρώσεων και των μεταβολών του κώδικα που επηρεάζονται από την τεχνολογική πολυπλοκότητα και τον ανθρώπινο παράγοντα.
Είναι αδύνατο να φανταστεί κανείς πώς ακριβώς ένας προγραμματιστής σχεδίασε μια συγκεκριμένη εφαρμογή. Γνωρίζουμε ότι ένα από τα κοινά API frameworks, όπως XML ή gRPC, θα χρησιμοποιηθεί σε πολλές περιπτώσεις. Ακόμα, οι τύποι δεδομένων, οι σημειώσεις και η ίδια η λογική της εφαρμογής θα είναι διαφορετικές.
Η ανάλυση των δεδομένων δυσχεραίνεται από τις παραλλαγές τους. Για να διευκρινιστεί ο τρόπος με τον οποίο σχεδιάστηκε ειδικά μια εφαρμογή, οι αναλυτές μπορούν να απαιτήσουν πολλά δεδομένα για αποκωδικοποίηση. Για να αποκωδικοποιήσετε τις πιο εξελιγμένες περιπτώσεις, ενδέχεται να χρειαστεί η αποκωδικοποίηση δεδομένων δύο ή τρεις φορές. Μπορείτε να βρείτε το JSON μέσα σε ένα επίπεδο, αλλά μια άλλη επανάληψη του ίδιου κώδικα κάπου αλλού. Αυτές οι αλυσίδες και τα επίπεδα του κώδικα μπορεί να είναι τεράστια.
Η κακή επικοινωνία είναι ο αγωγός απόρριψης
Για να δημιουργηθούν κανόνες για την προστασία API, οι ομάδες ασφαλείας πρέπει να καταλάβουν τι ακριβώς πρέπει να κάνει ένα συγκεκριμένο endpoint API και πώς πρέπει να γίνει αυτό. Αυτές οι πληροφορίες υποτίθεται ότι προέρχονται από την ομάδα προγραμματιστών / DevOps, αλλά συχνά χάνονται στη διαλειτουργική επικοινωνία.
Για να κατανοήσουμε πώς υποτίθεται ότι λειτουργεί ένα API και να μπορέσουμε να το ασφαλίσουμε χρειαζόμαστε το documentation. Ωστόσο, η παρακίνηση των προγραμματιστών να γράφουν documentations για τα API και να επεξεργάζονται τα έγγραφα μπορεί να είναι απίστευτα δύσκολη. Αυτό καθιστά το documentation αναξιόπιστo.
Όταν το documentation είναι αναξιόπιστo, η ευθυγράμμιση της ασφάλειας με τους επιχειρηματικούς στόχους για το API είναι δύσκολη. Χωρίς τον επιχειρηματικό σκοπό του API, η ασφάλεια μπορεί να εμποδίσει ή να επιτρέψει τα λάθος πράγματα. Φανταστείτε ότι το API πρέπει να ανακοινώνει τις λεπτομέρειες της αποστολής. Η ομάδα ασφάλειας μπορεί να υποθέσει ότι τα δεδομένα στο API θα είναι το όνομα και η διεύθυνση του παραλήπτη. Εάν ένα API περιλαμβάνει μια ετικέτα αποστολής UPS ή κώδικα φορέα, η λύση ασφάλειας ενδέχεται να την εμποδίσει ως πιθανή επίθεση, επειδή μια ταχυδρομική διεύθυνση δεν μπορεί τυπικά να μοιάζει με αυτή.
Τα Internal APIs χρειάζονται επίσης προστασία
Εκτός από τη χρήση API για τη σύνδεση δύο διαφορετικών συστημάτων, τα API λειτουργούν εσωτερικά, ανταποκρινόμενα στο ρυθμό και την κλίμακα της εξέλιξης του API και της νέας τεχνολογίας.
Ας πούμε ότι επιλέγετε να αναπτύξετε την εφαρμογή σας στο Kubernetes. Ένα σύνολο από Internal API θα χρησιμοποιηθεί για τη διαχείριση των επιμέρους μικροεπιχειρήσεων από το Kubernetes και για την αποστολή των δεδομένων μεταξύ των επιμέρους containers. Αυτό δημιουργεί νέες ανησυχίες ασφαλείας και μπορεί να απαιτήσει μια γενική επισκόπηση της ασφαλείας σας.
Η ασφάλειά σας πρέπει τώρα να προστατεύει τόσο αυτό το internal API όσο και τα front-facing ΑPI. Μέσα στα management API, μπορείτε να προσθέσετε χρήστες και κλειδιά ή να παραχωρήσετε πρόσβαση σε οποιονδήποτε server εκεί – καθιστώντας τα internal ΑPI ευάλωτα. Αυτό σημαίνει ότι χειρίζεται την ασφάλειά τους και πώς συμπεριφέρονται σε σχέση με άλλα ΑPI άρα πρέπει να δοθεί ίση ή μεγαλύτερη προσοχή στις εξωτερικές συνδέσεις.
Τα Service APIs δημιουργούν πρόσθετες προκλήσεις
Η σύγχρονη εποχή μας βρίσκει να μετακινούμαστε από φυσικούς server σε υπηρεσίες cloud. Πολλές από αυτές τις υπηρεσίες που βασίζονται σε cloud (SaaS) επιτρέπουν στους καταναλωτές να συνδεθούν μέσω των προγραμμάτων περιήγησης, όπως τον έλεγχο του email σας σε μια επιφάνεια εργασίας. Πολλά περισσότερα SaaS είναι διαθέσιμα μόνο μέσω APIs. Αυτά είναι service API. Και έχουν προσθέσει προκλήσεις ασφάλειας που βασίζονται στον υψηλό όγκο δεδομένων τους και τις συνολικές παραλλαγές των μοντέλων ασφάλειας και ταυτοποίησης.
Με τα service API, τα δύο σημεία της σύνδεσης ανήκουν σε δύο διαφορετικές επιχειρήσεις. Επειδή δεν μπορούν να εμπιστευτούν το ένα το άλλο, πρέπει να αναπτυχθούν διαφορετικά μοντέλα ασφάλειας και ταυτοποίησης για την προστασία κάθε συμβαλλόμενου μέρους.
Τα API δεν είναι Web App
Τα API συμπεριφέρονται εντελώς διαφορετικά από τα ανθρώπινα αιτήματα σε σχέση με τα web apps, απαιτώντας νέους τρόπους σκέψης μέσω των τοπίων ασφαλείας.
Φανταστείτε ότι θέλουμε να προστατέψουμε ένα login ΑPI κατά των στατικών επιθέσεων βάσει των credentials και θέλουμε να αποκλείσουμε όλα τα bots. Ωστόσο, όλοι τα clients του ΑPI σχεδιάζονται ως αυτοματοποιημένα εργαλεία. Αυτό τεχνικά τα κάνει να λειτουργούν ως bots. Για παράδειγμα, ένας e-shop μπορεί να θέλει να έχει συνδέσεις για τους λιανοπωλητές, τους διανομείς ή άλλους τελικούς χρήστες. Τώρα, για να προστατέψουμε το ΑPI, η λύση ασφαλείας πρέπει να είναι σε θέση να αναγνωρίζει τα κανονικά, νόμιμα bots (πελάτες που χρησιμοποιούν αυτοματοποίηση) από παράνομα bots. Στην επιφάνεια, όλα φαίνονται και συμπεριφέρονται με τις παραδοσιακές προοπτικές ασφάλειας.
Η κινητή πρόσβαση, η οποία αντιμετωπίζει μεγάλη επισκεψιμότητα από τεχνικά bots, προστίθεται στο αυξανόμενο πρόβλημα της διάκρισης των “καλών” έναντι “κακών” bots. Για την εκκίνηση, αυτά τα bots προέρχονται μόνο από μερικές εξωτερικές διευθύνσεις IP που βασίζονται στον παροχέα. Η προστασία από τα bots για τα API μπορεί να φαίνεται σαν μια απλή διαδικασία, αλλά στην πραγματικότητα είναι μια τεράστια επιχείρηση.
Οι προκλήσεις στην ασφάλεια πηγάζουν από το πόσο γρήγορα τα ΑPI εξελίχθηκαν από απλά, front-facing API. Δεν είναι πλέον ούτε απλά, ούτε front-facing. Τα API αυτή τη στιγμή είναι γεμάτα με ανθρώπινα δακτυλικά αποτυπώματα, τα οποία αυξάνονται καθημερινά. Καθώς η ασφάλεια των API καθίσταται όλο και πιο πολύπλοκη, θα είναι σημαντικό για τους προγραμματιστές να εξετάσουν αυτές τις προκλήσεις ασφαλείας καθώς προχωρούν στην δημιουργία τους.
 δεν είναι πλέον ούτε απλά ούτε front-facing, δημιουργώντας νέους κινδύνους){kind=link}