Πριν από χρόνια, όταν οι on-premise διακομιστές Unix με μεγάλα συστήματα αρχείων ήταν ένα πράγμα, οι εταιρείες έχτιζαν εκτενείς κανόνες διαχείρισης φακέλων και στρατηγικές για τη διαχείριση δικαιωμάτων πρόσβασης σε διαφορετικούς φακέλους για διαφορετικούς ανθρώπους.
Συνήθως, η πλατφόρμα ενός οργανισμού εξυπηρετεί διαφορετικές ομάδες χρηστών με εντελώς διαφορετικά ενδιαφέροντα, περιορισμούς επιπέδου εμπιστευτικότητας ή ορισμούς περιεχομένου. Στην περίπτωση των παγκόσμιων οργανισμών, αυτό θα μπορούσε να σημαίνει ακόμη και διαχωρισμό περιεχομένου με βάση την τοποθεσία, άρα βασικά, μεταξύ των χρηστών που ανήκουν σε διαφορετικές χώρες.
Περαιτέρω τυπικά παραδείγματα μπορεί να περιλαμβάνουν:
- διαχωρισμός δεδομένων μεταξύ περιβαλλόντων ανάπτυξης, δοκιμής και παραγωγής
- περιεχόμενο πωλήσεων που δεν είναι προσβάσιμο σε ένα ευρύ κοινό
- νομοθετικό περιεχόμενο για συγκεκριμένη χώρα που δεν είναι ορατό ή πρόσβαση από άλλη περιοχή
- περιεχόμενο σχετικό με το έργο όπου τα «δεδομένα ηγεσίας» πρέπει να παρέχονται μόνο σε περιορισμένη ομάδα ατόμων κ.λπ.
Υπάρχει ένας δυνητικά ατελείωτος κατάλογος τέτοιων παραδειγμάτων. Το θέμα είναι ότι υπάρχει πάντα κάποια ανάγκη να ενορχηστρωθούν δικαιώματα πρόσβασης σε αρχεία και δεδομένα μεταξύ όλων των χρηστών στους οποίους η πλατφόρμα παρέχει πρόσβαση.
Στην περίπτωση των επί τόπου λύσεων, αυτό ήταν μια εργασία ρουτίνας. Ο διαχειριστής του συστήματος αρχείων απλώς έθεσε ορισμένους κανόνες, χρησιμοποίησε ένα εργαλείο επιλογής και, στη συνέχεια, τα άτομα αντιστοιχίστηκαν σε ομάδες χρηστών και οι ομάδες χρηστών αντιστοιχίστηκαν σε μια λίστα φακέλων ή σημείων προσάρτησης στα οποία θα μπορούν να έχουν πρόσβαση. Στην πορεία, το επίπεδο πρόσβασης ορίστηκε ως πρόσβαση μόνο για ανάγνωση ή ανάγνωση και εγγραφή.
Τώρα, εξετάζοντας τις πλατφόρμες cloud AWS, είναι προφανές ότι οι άνθρωποι θα έχουν παρόμοιες απαιτήσεις για περιορισμούς πρόσβασης περιεχομένου. Η λύση σε αυτό το πρόβλημα πρέπει να είναι, ωστόσο, τώρα διαφορετική. Τα αρχεία δεν αντιστέκονται πλέον σε διακομιστές Unix αλλά στο cloud (και δυνητικά προσβάσιμα όχι μόνο σε ολόκληρο τον οργανισμό αλλά ακόμη και σε ολόκληρο τον κόσμο) και το περιεχόμενο δεν αποθηκεύεται σε φακέλους αλλά σε κουβάδες S3.
Παρακάτω περιγράφεται μια εναλλακτική λύση για την προσέγγιση αυτού του προβλήματος. Είναι χτισμένο στην πραγματική εμπειρία που είχα ενώ σχεδίαζα τέτοιες λύσεις για ένα συγκεκριμένο έργο.
Πίνακας περιεχομένων
Απλή αλλά πολύ χειροκίνητη προσέγγιση
Ένας τρόπος επίλυσης αυτού του προβλήματος χωρίς αυτοματισμό είναι σχετικά απλός και απλός:
- Δημιουργήστε ένα νέο κουβά για κάθε ξεχωριστή ομάδα ανθρώπων.
- Εκχωρήστε δικαιώματα πρόσβασης στον κάδο έτσι ώστε μόνο αυτή η συγκεκριμένη ομάδα να έχει πρόσβαση στον κάδο S3.
Αυτό είναι σίγουρα δυνατό εάν η απαίτηση είναι να γίνει με μια πολύ απλή και γρήγορη ανάλυση. Υπάρχουν, ωστόσο, ορισμένα όρια που πρέπει να γνωρίζετε.
Από προεπιλογή, μόνο έως και 100 κάδοι S3 μπορούν να δημιουργηθούν σε έναν λογαριασμό AWS. Αυτό το όριο μπορεί να επεκταθεί στα 1000 υποβάλλοντας μια αύξηση ορίου υπηρεσίας στο εισιτήριο AWS. Εάν αυτά τα όρια δεν είναι κάτι για το οποίο θα ανησυχούσε η συγκεκριμένη περίπτωση εφαρμογής σας, τότε μπορείτε να επιτρέψετε σε κάθε έναν από τους διαφορετικούς χρήστες του τομέα σας να λειτουργήσει σε έναν ξεχωριστό κάδο S3 και να το καλέσετε την ημέρα.
Τα προβλήματα μπορεί να προκύψουν εάν υπάρχουν ορισμένες ομάδες ατόμων με διαλειτουργικές ευθύνες ή απλώς κάποιοι που χρειάζονται πρόσβαση στο περιεχόμενο περισσότερων τομέων ταυτόχρονα. Για παράδειγμα:
- Οι αναλυτές δεδομένων αξιολογούν το περιεχόμενο δεδομένων για πολλές διαφορετικές περιοχές, περιοχές κ.λπ.
- Η ομάδα δοκιμών μοιράστηκε υπηρεσίες που εξυπηρετούν διαφορετικές ομάδες ανάπτυξης.
- Αναφορά χρηστών που απαιτούν τη δημιουργία ανάλυσης πίνακα ελέγχου πάνω από διαφορετικές χώρες στην ίδια περιοχή.
Όπως μπορείτε να φανταστείτε, αυτή η λίστα μπορεί και πάλι να μεγαλώσει όσο μπορείτε να φανταστείτε και οι ανάγκες των οργανισμών μπορούν να δημιουργήσουν κάθε είδους περιπτώσεις χρήσης.
Όσο πιο περίπλοκη γίνεται αυτή η λίστα, τόσο πιο πολύπλοκη ενορχήστρωση δικαιωμάτων πρόσβασης θα χρειαστεί για να παραχωρηθούν σε όλες αυτές τις διαφορετικές ομάδες διαφορετικά δικαιώματα πρόσβασης σε διαφορετικούς κάδους S3 στον οργανισμό. Θα απαιτηθούν πρόσθετα εργαλεία και ίσως ακόμη και ένας αποκλειστικός πόρος (διαχειριστής) θα χρειαστεί να διατηρεί τις λίστες δικαιωμάτων πρόσβασης και να τις ενημερώνει όποτε ζητείται οποιαδήποτε αλλαγή (κάτι που θα είναι πολύ συχνά, ειδικά αν ο οργανισμός είναι μεγάλος).
Λοιπόν, πώς να πετύχετε το ίδιο πράγμα με πιο οργανωμένο και αυτοματοποιημένο τρόπο;
Εάν η προσέγγιση κάδου ανά τομέα δεν λειτουργεί, οποιαδήποτε άλλη λύση θα καταλήξει σε κοινόχρηστους κάδους για περισσότερες ομάδες χρηστών. Σε τέτοιες περιπτώσεις, είναι απαραίτητο να χτιστεί ολόκληρη η λογική της εκχώρησης δικαιωμάτων πρόσβασης σε κάποια περιοχή που είναι εύκολο να αλλάξει ή να ενημερώσει δυναμικά.
Ένας από τους τρόπους για να το πετύχετε αυτό είναι χρησιμοποιώντας ετικέτες στους κάδους S3. Οι ετικέτες συνιστώνται να χρησιμοποιούνται σε κάθε περίπτωση (αν μη τι άλλο από το να επιτραπεί η ευκολότερη κατηγοριοποίηση χρέωσης). Ωστόσο, η ετικέτα μπορεί να αλλάξει οποιαδήποτε στιγμή στο μέλλον για οποιονδήποτε κάδο.
Εάν ολόκληρη η λογική βασίζεται στις ετικέτες του κάδου και το υπόλοιπο πίσω εξαρτάται από τη διαμόρφωση των τιμών της ετικέτας, η δυναμική ιδιότητα είναι εξασφαλισμένη καθώς μπορεί κανείς να επαναπροσδιορίσει τον σκοπό του κάδου απλώς ενημερώνοντας τις τιμές των ετικετών.
Τι είδους ετικέτες να χρησιμοποιήσετε για να λειτουργήσει αυτό;
Αυτό εξαρτάται από τη συγκεκριμένη περίπτωση χρήσης σας. Για παράδειγμα:
- Μπορεί να χρειαστεί να διαχωριστούν οι κάδοι ανά τύπο περιβάλλοντος. Έτσι, σε αυτήν την περίπτωση, ένα από τα ονόματα της ετικέτας θα είναι κάτι σαν “ENV” και με πιθανές τιμές “DEV”, “TEST”, “PROD” κ.λπ.
- Ίσως θέλετε να χωρίσετε την ομάδα με βάση τη χώρα. Σε αυτήν την περίπτωση, μια άλλη ετικέτα θα είναι “COUNTRY” και θα έχει αξία κάποιου ονόματος χώρας.
- Εναλλακτικά, μπορεί να θέλετε να διαχωρίσετε τους χρήστες με βάση το λειτουργικό τμήμα στο οποίο ανήκουν, όπως επιχειρησιακούς αναλυτές, χρήστες αποθήκης δεδομένων, επιστήμονες δεδομένων κ.λπ. Επομένως, δημιουργείτε μια ετικέτα με το όνομα “USER_TYPE” και την αντίστοιχη τιμή.
- Μια άλλη επιλογή θα μπορούσε να είναι ότι θέλετε να ορίσετε ρητά μια σταθερή δομή φακέλων για συγκεκριμένες ομάδες χρηστών που καλούνται να χρησιμοποιήσουν (για να μην δημιουργήσουν τη δική τους ακαταστασία φακέλων και να χαθούν εκεί με την πάροδο του χρόνου). Μπορείτε να το κάνετε ξανά με ετικέτες, όπου μπορείτε να καθορίσετε πολλούς καταλόγους εργασίας όπως: “data/import”, “data/processed”, “data/error” κ.λπ.
Στην ιδανική περίπτωση, θέλετε να ορίσετε τις ετικέτες έτσι ώστε να μπορούν να συνδυαστούν λογικά και να σχηματίσουν μια ολόκληρη δομή φακέλου στον κάδο.
Για παράδειγμα, μπορείτε να συνδυάσετε τις ακόλουθες ετικέτες από τα παραπάνω παραδείγματα για να δημιουργήσετε μια δομή αποκλειστικού φακέλου για διαφορετικούς τύπους χρηστών από διάφορες χώρες με προκαθορισμένους φακέλους εισαγωγής που αναμένεται να χρησιμοποιήσουν:
- /
/ /<ΧΩΡΑ>/
Απλώς αλλάζοντας την τιμή
Αυτό θα επιτρέψει τη χρήση του ίδιου κάδου για πολλούς διαφορετικούς χρήστες. Οι κάδοι δεν υποστηρίζουν ρητά φακέλους, αλλά υποστηρίζουν “ετικέτες”. Αυτές οι ετικέτες λειτουργούν σαν υποφάκελοι στο τέλος επειδή οι χρήστες πρέπει να περάσουν από μια σειρά ετικετών για να φτάσουν στα δεδομένα τους (ακριβώς όπως θα έκαναν με τους υποφακέλους).
Έχοντας ορίσει τις ετικέτες σε κάποια χρησιμοποιήσιμη μορφή, το επόμενο βήμα είναι να δημιουργήσετε πολιτικές κάδου S3 που θα χρησιμοποιούν τις ετικέτες.
Εάν οι πολιτικές χρησιμοποιούν τα ονόματα των ετικετών, δημιουργείτε κάτι που ονομάζεται “δυναμικές πολιτικές”. Αυτό ουσιαστικά σημαίνει ότι η πολιτική σας θα συμπεριφέρεται διαφορετικά για κουβάδες με διαφορετικές τιμές ετικετών στις οποίες αναφέρεται η πολιτική σε μορφή ή σύμβολα κράτησης θέσης.
Αυτό το βήμα προφανώς περιλαμβάνει κάποια προσαρμοσμένη κωδικοποίηση των δυναμικών πολιτικών, αλλά μπορείτε να απλοποιήσετε αυτό το βήμα χρησιμοποιώντας το εργαλείο επεξεργασίας πολιτικών Amazon AWS, το οποίο θα σας καθοδηγήσει στη διαδικασία.
Στην ίδια την πολιτική, θα θέλετε να κωδικοποιήσετε συγκεκριμένα δικαιώματα πρόσβασης που θα εφαρμοστούν στον κάδο και το επίπεδο πρόσβασης αυτών των δικαιωμάτων (ανάγνωση, εγγραφή). Η λογική θα διαβάσει τις ετικέτες στους κάδους και θα δημιουργήσει τη δομή του φακέλου στον κάδο (δημιουργώντας ετικέτες με βάση τις ετικέτες). Με βάση τις συγκεκριμένες τιμές των ετικετών θα δημιουργηθούν οι υποφάκελοι και τα απαιτούμενα δικαιώματα πρόσβασης θα εκχωρηθούν κατά μήκος της γραμμής.
Το ωραίο με μια τέτοια δυναμική πολιτική είναι ότι μπορείτε να δημιουργήσετε μόνο μία δυναμική πολιτική και στη συνέχεια να εκχωρήσετε την ίδια δυναμική πολιτική σε πολλούς κάδους. Αυτή η πολιτική θα συμπεριφέρεται διαφορετικά για κουβάδες με διαφορετικές τιμές ετικετών, αλλά θα είναι πάντα μαζί με τις προσδοκίες σας για έναν κάδο με τέτοιες τιμές ετικετών.
Είναι ένας πραγματικά αποτελεσματικός τρόπος διαχείρισης των εκχωρήσεων δικαιωμάτων πρόσβασης με οργανωμένο, συγκεντρωτικό τρόπο για μεγάλο αριθμό κουβάδων, όπου υπάρχει η προσδοκία ότι κάθε κάδος θα ακολουθεί ορισμένες δομές προτύπων που έχουν συμφωνηθεί εκ των προτέρων και θα χρησιμοποιηθούν από τους χρήστες σας εντός ολόκληρη την οργάνωση.
Αυτοματοποιήστε την ενσωμάτωση νέων οντοτήτων
Μετά τον καθορισμό δυναμικών πολιτικών και την αντιστοίχιση τους στους υπάρχοντες κάδους, οι χρήστες μπορούν να αρχίσουν να χρησιμοποιούν τους ίδιους κάδους χωρίς τον κίνδυνο να μην έχουν πρόσβαση χρήστες από διαφορετικές ομάδες σε περιεχόμενο (αποθηκευμένο στον ίδιο κάδο) που βρίσκεται κάτω από μια δομή φακέλου όπου δεν έχουν πρόσβαση.
Επίσης, για ορισμένες ομάδες χρηστών με ευρύτερη πρόσβαση, θα είναι εύκολο να προσεγγίσουν τα δεδομένα επειδή θα αποθηκεύονται όλα στον ίδιο κάδο.
Το τελευταίο βήμα είναι να κάνετε την ενσωμάτωση νέων χρηστών, νέων κουβάδων και ακόμη και νέων ετικετών όσο το δυνατόν πιο απλή. Αυτό οδηγεί σε μια άλλη προσαρμοσμένη κωδικοποίηση, η οποία, ωστόσο, δεν χρειάζεται να είναι υπερβολικά περίπλοκη, υποθέτοντας ότι η διαδικασία ενσωμάτωσης έχει μερικούς πολύ σαφείς κανόνες που μπορούν να ενσωματωθούν με απλή, απλή λογική αλγορίθμου (τουλάχιστον μπορείτε να αποδείξετε με αυτόν τον τρόπο ότι η διαδικασία έχει κάποια λογική και δεν γίνεται με τον υπερβολικά χαοτικό τρόπο).
Αυτό μπορεί να είναι τόσο απλό όσο η δημιουργία ενός εκτελέσιμου σεναρίου με την εντολή AWS CLI με τις παραμέτρους που απαιτούνται για την επιτυχή ενσωμάτωση μιας νέας οντότητας στην πλατφόρμα. Μπορεί ακόμη και να είναι μια σειρά σεναρίων CLI, εκτελέσιμα με κάποια συγκεκριμένη σειρά, όπως, για παράδειγμα:
- create_new_bucket(
, , , , ..) - create_new_tag(
, , ) - update_existing_tag(
, , ) - create_user_group(
, , ) - και τα λοιπά.
Καταλαβαίνεις το νόημα. 😃
Μια επαγγελματική συμβουλή 👨💻
Υπάρχει ένα Pro Tip αν θέλετε, το οποίο μπορεί να εφαρμοστεί εύκολα πάνω από τα παραπάνω.
Οι δυναμικές πολιτικές μπορούν να αξιοποιηθούν όχι μόνο για την εκχώρηση δικαιωμάτων πρόσβασης για τοποθεσίες φακέλων αλλά και για την αυτόματη εκχώρηση δικαιωμάτων υπηρεσίας για τους κάδους και τις ομάδες χρηστών!
Το μόνο που θα χρειαστεί είναι να επεκταθεί η λίστα των ετικετών στους κάδους και στη συνέχεια να προστεθούν δικαιώματα πρόσβασης δυναμικής πολιτικής για τη χρήση συγκεκριμένων υπηρεσιών για συγκεκριμένες ομάδες χρηστών.
Για παράδειγμα, μπορεί να υπάρχει κάποια ομάδα χρηστών που χρειάζεται επίσης πρόσβαση στον συγκεκριμένο διακομιστή συμπλέγματος βάσης δεδομένων. Αυτό μπορεί αναμφίβολα να επιτευχθεί με δυναμικές πολιτικές που αξιοποιούν τις εργασίες κάδου, περισσότερο εάν οι προσβάσεις στις υπηρεσίες καθοδηγούνται από μια προσέγγιση που βασίζεται σε ρόλους. Απλώς προσθέστε στον κώδικα δυναμικής πολιτικής ένα τμήμα που θα επεξεργάζεται ετικέτες σχετικά με τις προδιαγραφές του συμπλέγματος βάσης δεδομένων και θα εκχωρεί απευθείας τα δικαιώματα πρόσβασης πολιτικής στο συγκεκριμένο σύμπλεγμα DB και ομάδα χρηστών.
Με αυτόν τον τρόπο, η ενσωμάτωση μιας νέας ομάδας χρηστών θα είναι εκτελέσιμη μόνο από αυτήν την ενιαία δυναμική πολιτική. Επιπλέον, δεδομένου ότι είναι δυναμική, η ίδια πολιτική μπορεί να επαναχρησιμοποιηθεί για την ενσωμάτωση πολλών διαφορετικών ομάδων χρηστών (αναμένεται να ακολουθεί το ίδιο πρότυπο αλλά όχι απαραίτητα τις ίδιες υπηρεσίες).
Μπορείτε επίσης να ρίξετε μια ματιά σε αυτές τις εντολές AWS S3 για να διαχειριστείτε κάδους και δεδομένα.