Τώρα εργάζομαι σε μια εταιρεία πωλητή λογισμικού, ιδίως σε λύσεις ελέγχου πρόσβασης. Και η εμπειρία μου "από μια προηγούμενη ζωή" συνδέεται με την πλευρά του πελάτη - ένα μεγάλο χρηματοπιστωτικό ίδρυμα. Εκείνη την εποχή, η ομάδα ελέγχου πρόσβασης στο τμήμα ασφάλειας πληροφοριών δεν μπορούσε να καυχηθεί για μεγάλες ικανότητες στο IdM. Μάθαμε πολλά στη διαδικασία, έπρεπε να γεμίσουμε ένα σωρό προσκρούσεις για να δημιουργήσουμε έναν λειτουργικό μηχανισμό για τη διαχείριση των δικαιωμάτων των χρηστών στα πληροφοριακά συστήματα της εταιρείας.
Συνδυάζοντας την εμπειρία μου από τον πελάτη με τις γνώσεις και τις ικανότητες του προμηθευτή, θέλω να μοιραστώ μαζί σας ουσιαστικά μια βήμα προς βήμα οδηγίες: πώς να δημιουργήσετε ένα μοντέλο ελέγχου πρόσβασης βάσει ρόλου σε μια μεγάλη εταιρεία και τι θα δώσει στο τέλος. Η οδηγία μου αποτελείται από δύο μέρη: το πρώτο - ετοιμαζόμαστε να φτιάξουμε ένα μοντέλο, το δεύτερο - το κατασκευάζουμε στην πραγματικότητα. Πριν αποχωριστείτε το πρώτο, προπαρασκευαστικό.
Σημείωση Η οικοδόμηση ενός προτύπου δεν είναι, δυστυχώς, αποτέλεσμα, αλλά διαδικασία. Ή μάλλον, ακόμη και μέρος της διαδικασίας δημιουργίας ενός οικοσυστήματος ελέγχου πρόσβασης στην εταιρεία. Συντονιστείτε λοιπόν στο παιχνίδι για πολύ καιρό.
Αρχικά, ας ορίσουμε - τι είναι ο έλεγχος πρόσβασης βάσει ρόλων; Ας υποθέσουμε ότι έχετε μια μεγάλη τράπεζα με δεκάδες ή και εκατοντάδες χιλιάδες υπαλλήλους (υποκείμενα), καθένας από τους οποίους έχει δεκάδες δικαιώματα πρόσβασης σε εκατοντάδες ενδοτραπεζικά πληροφοριακά συστήματα (αντικείμενα). Και τώρα πολλαπλασιάστε τον αριθμό των αντικειμένων με τον αριθμό των θεμάτων - αυτό είναι πόσες τουλάχιστον συνδέσεις πρέπει να δημιουργήσετε πρώτα και μετά να ελέγξετε. Είναι πραγματικά δυνατό να το κάνετε χειροκίνητα; Φυσικά όχι - εμφανίστηκαν ρόλοι για να λύσουν αυτό το πρόβλημα.
Ένας ρόλος είναι ένα σύνολο δικαιωμάτων που χρειάζεται ένας χρήστης ή ομάδα χρηστών για να εκτελέσει ορισμένες εργασίες εργασίας. Κάθε υπάλληλος μπορεί να έχει έναν ή περισσότερους ρόλους και κάθε ρόλος μπορεί να περιέχει ένα έως πολλά δικαιώματα που επιτρέπονται σε έναν χρήστη εντός αυτού του ρόλου. Οι ρόλοι μπορούν να συνδεθούν με ορισμένες θέσεις, τμήματα ή λειτουργικά καθήκοντα υπαλλήλων.
Οι ρόλοι δημιουργούνται συνήθως από μεμονωμένες εξουσιοδοτήσεις εργαζομένων σε κάθε σύστημα πληροφοριών. Στη συνέχεια, οι παγκόσμιοι επιχειρηματικοί ρόλοι διαμορφώνονται από τους ρόλους κάθε συστήματος. Για παράδειγμα, ο επιχειρηματικός ρόλος «διαχειριστής δανείων» θα περιλαμβάνει αρκετούς ξεχωριστούς ρόλους σε πληροφοριακά συστήματα που χρησιμοποιούνται στο γραφείο πελατών της τράπεζας. Για παράδειγμα, σε όπως το κύριο αυτοματοποιημένο τραπεζικό σύστημα, ταμειακή μηχανή, ηλεκτρονικό σύστημα διαχείρισης εγγράφων, διαχειριστής υπηρεσιών και άλλα. Οι επιχειρηματικοί ρόλοι, κατά κανόνα, συνδέονται με την οργανωτική δομή - με άλλα λόγια, με ένα σύνολο εταιρικών τμημάτων και θέσεων σε αυτά. Έτσι σχηματίζεται ο παγκόσμιος πίνακας ρόλων (δίνω ένα παράδειγμα στον παρακάτω πίνακα).
Αξίζει να σημειωθεί ότι είναι απλά αδύνατο να οικοδομηθεί ένα 100% πρότυπο, παρέχοντας όλα τα απαραίτητα δικαιώματα για τους εργαζόμενους κάθε θέσης σε μια εμπορική δομή. Ναι, αυτό δεν είναι απαραίτητο. Άλλωστε, το πρότυπο δεν μπορεί να είναι στατικό, γιατί εξαρτάται από το συνεχώς μεταβαλλόμενο περιβάλλον. Και από μια αλλαγή στις επιχειρηματικές δραστηριότητες της εταιρείας, η οποία, κατά συνέπεια, επηρεάζει την αλλαγή στην οργανωτική δομή και λειτουργικότητα. Και από την έλλειψη πλήρους παροχής πόρων, και από τη μη συμμόρφωση με τις περιγραφές των θέσεων εργασίας, και από την επιθυμία για κέρδος σε βάρος της ασφάλειας, και από πολλούς άλλους παράγοντες. Ως εκ τούτου, είναι απαραίτητο να οικοδομηθεί ένα πρότυπο που να μπορεί να καλύψει έως και το 80% των αναγκών των χρηστών για τα απαραίτητα βασικά δικαιώματα όταν διορίζονται σε μια θέση. Και το υπόλοιπο 20% θα μπορούν, αν χρειαστεί, να ανακρίνουν αργότερα σε ξεχωριστές αιτήσεις.
Φυσικά, μπορείτε να ρωτήσετε: "Τι, δεν υπάρχουν 100% πρότυπα;" Λοιπόν, γιατί, αυτό συμβαίνει, για παράδειγμα, σε μη κερδοσκοπικές δομές που δεν υπόκεινται σε συχνές αλλαγές - σε κάποιο ερευνητικό ινστιτούτο. Ή σε οργανώσεις στρατιωτικο-βιομηχανικού συγκροτήματος με υψηλό επίπεδο ασφάλειας, όπου η ασφάλεια προέχει. Συμβαίνει, και σε μια εμπορική δομή, αλλά στο πλαίσιο μιας ενιαίας ενότητας, το έργο της οποίας είναι μια αρκετά στατική και προβλέψιμη διαδικασία.
Το κύριο πλεονέκτημα της διαχείρισης ρόλων είναι η απλοποίηση της έκδοσης δικαιωμάτων, επειδή ο αριθμός των ρόλων είναι σημαντικά μικρότερος από τον αριθμό των χρηστών του πληροφοριακού συστήματος. Και αυτό ισχύει για κάθε κλάδο.
Ας πάρουμε μια εταιρεία λιανικής: απασχολεί χιλιάδες πωλητές, αλλά έχουν το ίδιο σύνολο δικαιωμάτων στο σύστημα N, και μόνο ένας ρόλος θα τους δημιουργηθεί. Ένας νέος πωλητής ήρθε στην εταιρεία - του ανατέθηκε αυτόματα ο απαραίτητος ρόλος στο σύστημα, το οποίο έχει ήδη όλες τις απαραίτητες εξουσίες. Επίσης, με ένα κλικ, μπορείτε να αλλάξετε τα δικαιώματα για χιλιάδες πωλητές ταυτόχρονα, για παράδειγμα, να προσθέσετε μια νέα επιλογή για τη δημιουργία αναφοράς. Δεν χρειάζεται να κάνετε χίλιες λειτουργίες, συνδέοντας ένα νέο δικαίωμα σε κάθε λογαριασμό - απλώς προσθέστε αυτήν την επιλογή στον ρόλο και θα εμφανιστεί για όλους τους πωλητές ταυτόχρονα.
Ένα άλλο πλεονέκτημα της διαχείρισης βάσει ρόλων είναι η αποφυγή μη συμβατών δικαιωμάτων. Δηλαδή, ένας εργαζόμενος που έχει συγκεκριμένο ρόλο στο σύστημα δεν μπορεί να έχει ταυτόχρονα άλλον ρόλο, τα δικαιώματα του οποίου δεν πρέπει να συνδυάζονται με τα δικαιώματα του πρώτου. Ένα ζωντανό παράδειγμα είναι η απαγόρευση συνδυασμού των λειτουργιών εισροής και ελέγχου μιας οικονομικής συναλλαγής.
Όποιος ενδιαφέρεται για το πώς προέκυψε ο έλεγχος πρόσβασης βάσει ρόλων, μπορεί
βουτήξτε στην ιστορία
Αν στραφούμε στην ιστορία, τότε για πρώτη φορά η κοινότητα της πληροφορικής σκέφτηκε τις μεθόδους ελέγχου πρόσβασης στη δεκαετία του '70 του ΧΧ αιώνα. Αν και οι εφαρμογές ήταν τότε αρκετά απλές, αλλά, όπως και τώρα, όλοι ήθελαν πραγματικά να διαχειριστούν εύκολα την πρόσβαση σε αυτές. Παραχωρήστε, αλλάξτε και ελέγξτε τα δικαιώματα των χρηστών - απλώς για να καταστεί ευκολότερη η κατανόηση της πρόσβασης που έχει ο καθένας από αυτούς. Αλλά εκείνη την εποχή δεν υπήρχαν κοινά πρότυπα, τα πρώτα συστήματα ελέγχου πρόσβασης αναπτύχθηκαν και κάθε εταιρεία βασιζόταν στις δικές της ιδέες και κανόνες.
Πολλά διαφορετικά μοντέλα ελέγχου πρόσβασης είναι πλέον γνωστά, αλλά δεν εμφανίστηκαν αμέσως. Ας σταθούμε σε αυτούς που συνέβαλαν απτά στην ανάπτυξη αυτής της κατεύθυνσης.
Το πρώτο και ίσως το πιο απλό μοντέλο είναι Διακριτικός (Επιλεκτικός) Έλεγχος Πρόσβασης (DAC - Διακριτικός έλεγχος πρόσβασης). Αυτό το μοντέλο συνεπάγεται την κοινή χρήση δικαιωμάτων από όλους τους συμμετέχοντες στη διαδικασία πρόσβασης. Κάθε χρήστης έχει πρόσβαση σε συγκεκριμένα αντικείμενα ή λειτουργίες. Στην πραγματικότητα, εδώ το σύνολο των υποκειμένων των δικαιωμάτων αντιστοιχεί στο σύνολο των αντικειμένων. Αυτό το μοντέλο διαπιστώθηκε ότι είναι πολύ ευέλικτο και πολύ δύσκολο να διατηρηθεί: οι λίστες πρόσβασης γίνονται τεράστιες και δύσκολο να ελεγχθούν με την πάροδο του χρόνου.
Το δεύτερο μοντέλο είναι Υποχρεωτικός έλεγχος πρόσβασης (MAC). Σύμφωνα με αυτό το μοντέλο, κάθε χρήστης αποκτά πρόσβαση στο αντικείμενο σύμφωνα με την εκδοθείσα πρόσβαση σε ένα συγκεκριμένο επίπεδο εμπιστευτικότητας δεδομένων. Αντίστοιχα, τα αντικείμενα θα πρέπει να κατηγοριοποιούνται ανάλογα με το επίπεδο εμπιστευτικότητας. Σε αντίθεση με το πρώτο ευέλικτο μοντέλο, αυτό, αντίθετα, αποδείχθηκε πολύ αυστηρό και περιοριστικό. Η χρήση του δεν δικαιολογείται όταν η εταιρεία διαθέτει πολλούς διαφορετικούς πόρους πληροφοριών: για να οριοθετήσετε την πρόσβαση σε διαφορετικούς πόρους, θα πρέπει να εισαγάγετε πολλές κατηγορίες που δεν θα επικαλύπτονται.
Λόγω των προφανών ατελειών αυτών των δύο μεθόδων, η κοινότητα της πληροφορικής συνέχισε να αναπτύσσει μοντέλα που είναι πιο ευέλικτα και ταυτόχρονα περισσότερο ή λιγότερο καθολικά για να υποστηρίζουν διαφορετικούς τύπους πολιτικών ελέγχου πρόσβασης του οργανισμού. Και τότε ήταν που εμφανίστηκε το τρίτο μοντέλο ελέγχου πρόσβασης βάσει ρόλων! Αυτή η προσέγγιση αποδείχθηκε η πιο πολλά υποσχόμενη, καθώς απαιτεί όχι μόνο εξουσιοδότηση της ταυτότητας του χρήστη, αλλά και τις λειτουργίες εργασίας του στα συστήματα.
Η πρώτη καλά περιγραφόμενη δομή προτύπων προτάθηκε από τους Αμερικανούς επιστήμονες David Ferrailo και Richard Kuhn του Εθνικού Ινστιτούτου Προτύπων και Τεχνολογίας των ΗΠΑ το 1992. Τότε πρωτοεμφανίστηκε ο όρος RBAC (Έλεγχος πρόσβασης βάσει ρόλων). Αυτές οι μελέτες και περιγραφές των κύριων στοιχείων, καθώς και οι σχέσεις τους, αποτέλεσαν τη βάση του προτύπου INCITS 359-2012, το οποίο ισχύει μέχρι σήμερα, εγκεκριμένο από τη Διεθνή Επιτροπή Προτύπων Τεχνολογίας Πληροφορικής (INCITS).
Το πρότυπο ορίζει έναν ρόλο ως "μια λειτουργία εργασίας στο πλαίσιο ενός οργανισμού με κάποια σχετική σημασιολογία σχετικά με την εξουσία και την ευθύνη που ανατίθεται στον χρήστη που έχει ανατεθεί στο ρόλο". Το έγγραφο καθορίζει τα βασικά στοιχεία του RBAC - χρήστες, περιόδους σύνδεσης, ρόλους, δικαιώματα, λειτουργίες και αντικείμενα, καθώς και τις σχέσεις και τις σχέσεις μεταξύ τους.
Το πρότυπο παρέχει την ελάχιστη απαραίτητη δομή για τη δημιουργία ενός προτύπου - συνδυάζοντας δικαιώματα σε ρόλους και στη συνέχεια παροχή πρόσβασης στους χρήστες μέσω αυτών των ρόλων. Περιγράφονται οι μηχανισμοί σύνθεσης ρόλων από αντικείμενα και λειτουργίες, περιγράφεται η ιεραρχία των ρόλων και η κληρονομικότητα των εξουσιών. Πράγματι, σε κάθε εταιρεία υπάρχουν ρόλοι που συνδυάζουν στοιχειώδεις εξουσίες που είναι απαραίτητες για όλους τους υπαλλήλους της εταιρείας. Αυτό μπορεί να είναι η πρόσβαση στο e-mail, στο EDMS, στην εταιρική πύλη κ.λπ. Αυτά τα δικαιώματα μπορούν να συμπεριληφθούν σε έναν γενικό ρόλο που ονομάζεται "υπάλληλος" και δεν θα είναι απαραίτητο σε καθέναν από τους ρόλους υψηλότερου επιπέδου να αναφέρονται όλα τα βασικά δικαιώματα ξανά και ξανά. Αρκεί απλώς να υποδείξετε το σημάδι κληρονομικότητας του ρόλου «εργαζομένου».
Αργότερα, το πρότυπο συμπληρώθηκε με νέα χαρακτηριστικά πρόσβασης που σχετίζονται με το συνεχώς μεταβαλλόμενο περιβάλλον. Προστέθηκε η δυνατότητα εισαγωγής στατικών και δυναμικών περιορισμών. Οι στατικές υποδηλώνουν την αδυναμία συνδυασμού ρόλων (η ίδια εισαγωγή και έλεγχος των λειτουργιών που αναφέρονται παραπάνω). Τα δυναμικά όρια μπορούν να οριστούν αλλάζοντας παραμέτρους όπως ο χρόνος (εργάσιμες/μη εργάσιμες ώρες ή ημέρες), η τοποθεσία (γραφείο/σπίτι) και τα παρόμοια.
Ξεχωριστά, θα πρέπει να ειπωθεί για Έλεγχος πρόσβασης βάσει χαρακτηριστικών (ABAC). Η προσέγγιση βασίζεται στην παραχώρηση πρόσβασης χρησιμοποιώντας κανόνες κοινής χρήσης χαρακτηριστικών. Αυτό το μοντέλο μπορεί να χρησιμοποιηθεί ξεχωριστά, αλλά αρκετά συχνά συμπληρώνει ενεργά το κλασικό πρότυπο: μπορείτε να προσθέσετε χαρακτηριστικά χρηστών, πόρων και συσκευών, καθώς και ώρα ή τοποθεσία σε έναν συγκεκριμένο ρόλο. Αυτό σας επιτρέπει να χρησιμοποιείτε λιγότερους ρόλους, να εισάγετε πρόσθετους περιορισμούς και να κάνετε την πρόσβαση ελάχιστα επαρκή και, ως εκ τούτου, να αυξήσετε την ασφάλεια.
Για παράδειγμα, ένας λογιστής μπορεί να έχει πρόσβαση σε λογαριασμούς εάν εργάζεται σε μια συγκεκριμένη περιοχή. Στη συνέχεια, η θέση του ειδικού θα συγκριθεί με μια συγκεκριμένη τιμή αναφοράς. Ή μπορείτε να δώσετε πρόσβαση σε λογαριασμούς μόνο εάν ο χρήστης συνδεθεί από μια συσκευή που έχει καταχωριστεί στο μητρώο επιτρεπόμενων. Μια καλή προσθήκη στο πρότυπο, αλλά σπάνια χρησιμοποιείται από μόνη της λόγω της ανάγκης δημιουργίας πολλών κανόνων και πινάκων αδειών ή περιορισμών.
Θα δώσω ένα παράδειγμα χρήσης του ABAC από την «προηγούμενη ζωή» μου. Η τράπεζά μας είχε πολλά υποκαταστήματα. Οι υπάλληλοι των γραφείων πελατών σε αυτά τα υποκαταστήματα εκτελούσαν ακριβώς τις ίδιες λειτουργίες, αλλά έπρεπε να εργάζονται στο κύριο σύστημα μόνο με λογαριασμούς στην περιοχή τους. Αρχικά, αρχίσαμε να δημιουργούμε ξεχωριστούς ρόλους για κάθε περιοχή - και υπήρχαν πάρα πολλοί τέτοιοι ρόλοι με επαναλαμβανόμενη λειτουργικότητα, αλλά με πρόσβαση σε διαφορετικούς λογαριασμούς! Στη συνέχεια, χρησιμοποιώντας ένα χαρακτηριστικό τοποθεσίας για έναν χρήστη και συνδέοντάς το με ένα συγκεκριμένο εύρος λογαριασμών προς έλεγχο, μειώσαμε σημαντικά τον αριθμό των ρόλων στο σύστημα. Ως αποτέλεσμα, οι ρόλοι παρέμειναν μόνο για ένα υποκατάστημα, οι οποίοι επαναλήφθηκαν για τις αντίστοιχες θέσεις σε όλα τα άλλα εδαφικά τμήματα της τράπεζας.
Και τώρα ας μιλήσουμε για τα απαραίτητα προπαρασκευαστικά βήματα, χωρίς τα οποία είναι απλά αδύνατο να οικοδομηθεί ένα πρότυπο εργασίας.
Βήμα 1. Δημιουργήστε ένα λειτουργικό μοντέλο
Αξίζει να ξεκινήσετε με τη δημιουργία ενός λειτουργικού μοντέλου - ενός εγγράφου ανώτατου επιπέδου που περιγράφει λεπτομερώς τη λειτουργικότητα κάθε μονάδας και κάθε θέσης. Κατά κανόνα, οι πληροφορίες εισάγονται από διάφορα έγγραφα: περιγραφές θέσεων εργασίας και κανονισμούς για μεμονωμένα τμήματα - τμήματα, τμήματα, τμήματα. Το λειτουργικό μοντέλο πρέπει να συμφωνηθεί με όλα τα ενδιαφερόμενα τμήματα (επιχειρήσεις, εσωτερικός έλεγχος, ασφάλεια) και να εγκριθεί από τη διοίκηση της εταιρείας. Σε τι χρησιμεύει αυτό το έγγραφο; Για να μπορεί το πρότυπο να αναφέρεται σε αυτό. Για παράδειγμα, πρόκειται να οικοδομήσετε ένα πρότυπο με βάση τα υπάρχοντα δικαιώματα των εργαζομένων - ξεφορτωμένο από το σύστημα και «ανάγεται σε έναν κοινό παρονομαστή». Στη συνέχεια, όταν συμφωνείτε για τους ληφθέντες ρόλους με τον ιδιοκτήτη της επιχείρησης του συστήματος, μπορεί κανείς να αναφερθεί σε ένα συγκεκριμένο στοιχείο του λειτουργικού μοντέλου, βάσει του οποίου αυτό ή εκείνο το δικαίωμα περιλαμβάνεται στον ρόλο.
Βήμα 2. Ελέγχουμε συστήματα πληροφορικής και καταρτίζουμε ένα σχέδιο ιεράρχησης προτεραιοτήτων
Στο δεύτερο στάδιο, θα πρέπει να διενεργηθεί έλεγχος των συστημάτων πληροφορικής προκειμένου να κατανοηθεί πώς οργανώνεται η πρόσβαση σε αυτά. Για παράδειγμα, η οικονομική μου εταιρεία διαχειριζόταν αρκετές εκατοντάδες πληροφοριακά συστήματα. Σε όλα τα συστήματα υπήρχαν ορισμένα βασικά στοιχεία διαχείρισης ρόλων, στα περισσότερα - ορισμένοι ρόλοι, αλλά κυρίως σε χαρτί ή στον κατάλογο του συστήματος - είναι πολύ ξεπερασμένα και η πρόσβαση σε αυτά διανεμήθηκε κατόπιν των πραγματικών αιτημάτων των χρηστών. Φυσικά, είναι απλά αδύνατο να χτίσετε ένα πρότυπο σε πολλές εκατοντάδες συστήματα ταυτόχρονα, πρέπει να ξεκινήσετε από κάπου. Πραγματοποιήσαμε μια εις βάθος ανάλυση της διαδικασίας ελέγχου πρόσβασης για να προσδιορίσουμε το επίπεδο ωριμότητάς της. Κατά τη διαδικασία της ανάλυσης, αναπτύχθηκαν κριτήρια για την ιεράρχηση των πληροφοριακών συστημάτων - κρισιμότητα, ετοιμότητα, σχέδια παροπλισμού κ.λπ. Με τη βοήθειά τους, δημιουργήσαμε μια σειρά για την ανάπτυξη / ενημέρωση προτύπων για αυτά τα συστήματα. Και στη συνέχεια - συμπεριέλαβε πρότυπα στο σχέδιο για την ενσωμάτωση με τη λύση Identity Management για την αυτοματοποίηση του ελέγχου πρόσβασης.
Λοιπόν, πώς να προσδιορίσετε την κρισιμότητα του συστήματος; Απαντήστε στον εαυτό σας στις ακόλουθες ερωτήσεις:
- Συνδέεται το σύστημα με τις λειτουργικές διαδικασίες από τις οποίες εξαρτάται η βασική δραστηριότητα της εταιρείας;
- Θα επηρεάσει η διαταραχή του συστήματος την ακεραιότητα των περιουσιακών στοιχείων της εταιρείας;
- Ποιος είναι ο μέγιστος επιτρεπόμενος χρόνος διακοπής λειτουργίας του συστήματος, μετά την επίτευξη του οποίου είναι αδύνατο να αποκατασταθεί η δραστηριότητα μετά από διακοπή;
- Μπορεί μια παραβίαση της ακεραιότητας των πληροφοριών στο σύστημα να οδηγήσει σε μη αναστρέψιμες συνέπειες, τόσο οικονομικές όσο και για τη φήμη;
- Κρισιμότητα στην απάτη. Η παρουσία λειτουργικότητας, με ανεπαρκή έλεγχο της οποίας, είναι δυνατή η διενέργεια εσωτερικών / εξωτερικών δόλιων ενεργειών.
- Ποιες είναι οι νομικές απαιτήσεις, καθώς και οι εσωτερικοί κανόνες και διαδικασίες για αυτά τα συστήματα; Θα υπάρξουν κυρώσεις από τις ρυθμιστικές αρχές για μη συμμόρφωση;
Στην οικονομική μας εταιρεία, διενεργήσαμε έναν τέτοιο έλεγχο. Η Διοίκηση έχει αναπτύξει μια διαδικασία ελέγχου για την αναθεώρηση του δικαιώματος πρόσβασης για να ασχοληθεί με τους υπάρχοντες χρήστες και τα δικαιώματα πρώτα σε εκείνα τα συστήματα πληροφοριών που βρίσκονται στην πρώτη λίστα προτεραιότητας. Ο κάτοχος αυτής της διαδικασίας έχει ανατεθεί στο τμήμα ασφαλείας. Αλλά για να έχουμε μια πλήρη εικόνα των δικαιωμάτων πρόσβασης στην εταιρεία, ήταν απαραίτητο να εμπλακούν στη διαδικασία τα τμήματα πληροφορικής και επιχειρήσεων. Και εδώ ξεκίνησαν διαφωνίες, παρεξηγήσεις και μερικές φορές ακόμη και δολιοφθορές: κανείς δεν θέλει να ξεφύγει από τα τρέχοντα καθήκοντά του και να εμπλακεί σε ορισμένες, εκ πρώτης όψεως, ακατανόητες δραστηριότητες.
Σημείωση Οι μεγάλες εταιρείες με ανεπτυγμένες διαδικασίες πληροφορικής είναι πιθανώς εξοικειωμένες με τη διαδικασία ελέγχου πληροφορικής - γενικοί έλεγχοι πληροφορικής (ITGC), που σας επιτρέπει να εντοπίσετε ελλείψεις στις διαδικασίες πληροφορικής και να δημιουργήσετε έλεγχο με τέτοιο τρόπο ώστε να βελτιώνετε τις διαδικασίες σύμφωνα με τις βέλτιστες πρακτικές (ITIL, COBIT, IT Governance, κ.λπ.).
Ένας από τους τομείς του ελέγχου είναι ο προσδιορισμός των παραμέτρων της λογικής και φυσικής πρόσβασης στα πληροφοριακά συστήματα. Λάβαμε τα δεδομένα που λήφθηκαν ως βάση για περαιτέρω χρήση στη δημιουργία ενός προτύπου. Ως αποτέλεσμα ενός τέτοιου ελέγχου, έχουμε ένα μητρώο συστημάτων πληροφορικής, στο οποίο προσδιορίστηκαν οι τεχνικές τους παράμετροι και δόθηκαν περιγραφές. Επιπλέον, για κάθε σύστημα, προσδιορίστηκε ένας ιδιοκτήτης από την επιχειρηματική κατεύθυνση προς τα συμφέροντα της οποίας λειτουργούσε: ήταν αυτός που ήταν υπεύθυνος για τις επιχειρηματικές διαδικασίες που εξυπηρετούσε αυτό το σύστημα. Επίσης ορίστηκε υπεύθυνος υπηρεσιών πληροφορικής, υπεύθυνος για την τεχνική υλοποίηση των επιχειρηματικών αναγκών σε συγκεκριμένο ΚΠ. Καταγράφηκαν τα πιο κρίσιμα συστήματα για την εταιρεία και οι τεχνικές τους παράμετροι, ημερομηνίες θέσης σε λειτουργία και παροπλισμού κ.λπ.. Αυτές οι παράμετροι βοήθησαν πολύ στη διαδικασία προετοιμασίας για την κατασκευή ενός προτύπου.
Βήμα 3 Δημιουργήστε μια μεθοδολογία
Το κλειδί για την επιτυχία κάθε επιχείρησης είναι η σωστή μέθοδος. Επομένως, τόσο για να χτίσουμε ένα πρότυπο όσο και για να διενεργήσουμε έλεγχο, πρέπει να δημιουργήσουμε μια μεθοδολογία στην οποία θα περιγράφουμε την αλληλεπίδραση μεταξύ των τμημάτων, θα καθορίζουμε την ευθύνη στους εταιρικούς κανονισμούς κ.λπ.
Πρώτα πρέπει να εξετάσετε όλα τα διαθέσιμα έγγραφα που καθορίζουν τη διαδικασία χορήγησης πρόσβασης και δικαιωμάτων. Με καλό τρόπο, οι διαδικασίες θα πρέπει να τεκμηριώνονται σε πολλά επίπεδα:
- γενικές εταιρικές απαιτήσεις·
- απαιτήσεις για τους τομείς της ασφάλειας των πληροφοριών (εξαρτώνται από τις δραστηριότητες του οργανισμού)·
- απαιτήσεις για τεχνολογικές διαδικασίες (οδηγίες, πίνακες πρόσβασης, κατευθυντήριες γραμμές, απαιτήσεις διαμόρφωσης).
Στην οικονομική μας εταιρεία, βρήκαμε πολλά απαρχαιωμένα έγγραφα - έπρεπε να τα φέρουμε σε συμφωνία με τις νέες διαδικασίες που εισήχθησαν.
Με εντολή της διοίκησης δημιουργήθηκε ομάδα εργασίας, στην οποία συμμετείχαν εκπρόσωποι από τους τομείς της ασφάλειας, της πληροφορικής, των επιχειρήσεων και του εσωτερικού ελέγχου. Η παραγγελία περιέγραφε τους στόχους δημιουργίας της ομάδας, την κατεύθυνση της δραστηριότητας, την περίοδο ύπαρξης και τις ευθύνες κάθε πλευράς. Επιπλέον, έχουμε αναπτύξει μια μεθοδολογία ελέγχου και μια διαδικασία για τη δημιουργία ενός προτύπου προς μίμηση: συμφωνήθηκαν από όλους τους υπεύθυνους εκπροσώπους των περιοχών και εγκρίθηκαν από τη διοίκηση της εταιρείας.
Έγγραφα που περιγράφουν τη διαδικασία εκτέλεσης των εργασιών, τις προθεσμίες, τις αρμοδιότητες κ.λπ. - μια εγγύηση ότι στο δρόμο προς τον αγαπημένο στόχο, ο οποίος στην αρχή δεν είναι προφανής σε όλους, κανείς δεν θα έχει ερωτήσεις "γιατί το κάνουμε αυτό, γιατί το χρειαζόμαστε κ.λπ.". και δεν θα υπάρχει καμία ευκαιρία να "πηδήξετε" ή να επιβραδύνετε τη διαδικασία.
Βήμα 4. Διόρθωση των παραμέτρων του υπάρχοντος μοντέλου ελέγχου πρόσβασης
Συντάσσουμε το λεγόμενο «διαβατήριο συστήματος» όσον αφορά τον έλεγχο πρόσβασης. Στην πραγματικότητα, πρόκειται για ένα ερωτηματολόγιο σε ένα συγκεκριμένο πληροφοριακό σύστημα, στο οποίο καταγράφονται όλοι οι αλγόριθμοι διαχείρισης της πρόσβασης σε αυτό. Οι εταιρείες που έχουν ήδη εφαρμόσει λύσεις κλάσης IdM είναι πιθανώς εξοικειωμένες με ένα τέτοιο ερωτηματολόγιο, καθώς με αυτό ξεκινά η μελέτη των συστημάτων.
Ορισμένες από τις παραμέτρους σχετικά με το σύστημα και τους κατόχους έχουν εισρεύσει στο ερωτηματολόγιο από το μητρώο IT (βλ. βήμα 2, έλεγχος), αλλά έχουν προστεθεί νέες:
- πώς γίνεται η διαχείριση των λογαριασμών (απευθείας στη βάση δεδομένων ή μέσω διεπαφών προγραμμάτων).
- πώς οι χρήστες συνδέονται στο σύστημα (χρησιμοποιώντας ξεχωριστό λογαριασμό ή χρησιμοποιώντας λογαριασμό AD, LDAP κ.λπ.)
- ποια επίπεδα πρόσβασης στο σύστημα χρησιμοποιούνται (επίπεδο εφαρμογής, επίπεδο συστήματος, χρήση πόρων αρχείων δικτύου από το σύστημα).
- περιγραφή και παραμέτρους των διακομιστών στους οποίους εκτελείται το σύστημα·
- ποιες λειτουργίες διαχείρισης λογαριασμού υποστηρίζονται (αποκλεισμός, μετονομασία κ.λπ.)
- ποιοι αλγόριθμοι ή κανόνες χρησιμοποιούνται για να σχηματίσουν το αναγνωριστικό χρήστη του συστήματος.
- ποιο χαρακτηριστικό μπορεί να χρησιμοποιηθεί για τη δημιουργία σύνδεσης με ένα αρχείο σχετικά με έναν υπάλληλο στο σύστημα προσωπικού (πλήρες όνομα, αριθμός προσωπικού, κ.λπ.)·
- όλα τα πιθανά χαρακτηριστικά λογαριασμού και κανόνες για τη συμπλήρωσή τους·
- ποια δικαιώματα πρόσβασης υπάρχουν στο σύστημα (ρόλοι, ομάδες, ατομικά δικαιώματα κ.λπ., υπάρχουν ένθετα ή ιεραρχικά δικαιώματα);
- μηχανισμοί διαχωρισμού δικαιωμάτων πρόσβασης (κατά θέσεις, τμήματα, λειτουργικότητα κ.λπ.)·
- εάν το σύστημα έχει κανόνες για τον διαχωρισμό δικαιωμάτων (SOD - Segregation of Duties) και πώς λειτουργούν.
- πώς επεξεργάζονται στο σύστημα τα γεγονότα απουσίας, μεταφοράς, απόλυσης, ενημέρωσης δεδομένων υπαλλήλων κ.λπ.
Η λίστα θα μπορούσε να συνεχιστεί, αναφέροντας λεπτομερώς τις διάφορες παραμέτρους και άλλες οντότητες που εμπλέκονται στη διαδικασία ελέγχου πρόσβασης.
Βήμα 5: Δημιουργήστε μια περιγραφή εξουσιοδότησης με επιχειρηματικό προσανατολισμό
Ένα άλλο έγγραφο που θα χρειαστούμε όταν χτίζουμε ένα πρότυπο είναι ένας οδηγός για όλες τις πιθανές εξουσίες (δικαιώματα) που μπορούν να παραχωρηθούν στους χρήστες σε ένα πληροφοριακό σύστημα με λεπτομερή περιγραφή της επιχειρηματικής λειτουργίας που βρίσκεται πίσω από αυτό. Συχνά οι εξουσίες στο σύστημα είναι κρυπτογραφημένες με συγκεκριμένα ονόματα, που αποτελούνται από γράμματα και αριθμούς, και οι υπάλληλοι της επιχείρησης δεν μπορούν να καταλάβουν τι κρύβεται πίσω από αυτούς τους χαρακτήρες. Στη συνέχεια, πηγαίνουν στην υπηρεσία πληροφορικής και εκεί ... δεν μπορούν επίσης να απαντήσουν στην ερώτηση, για παράδειγμα, σχετικά με τα σπάνια χρησιμοποιούμενα δικαιώματα. Τότε πρέπει να κάνετε περισσότερες δοκιμές.
Είναι καλό αν υπάρχει ήδη περιγραφή επιχείρησης ή ακόμα και αν υπάρχει συσχέτιση αυτών των δικαιωμάτων σε ομάδες και ρόλους. Για ορισμένες εφαρμογές, η καλύτερη πρακτική είναι να δημιουργηθεί ένας τέτοιος οδηγός στο στάδιο ανάπτυξης. Αυτό όμως δεν συμβαίνει συχνά, γι' αυτό και πάλι πηγαίνουμε στο τμήμα πληροφορικής για να συλλέξουμε πληροφορίες σχετικά με όλα τα πιθανά δικαιώματα και να τα περιγράψουμε. Ο οδηγός μας θα περιέχει τελικά τα εξής:
- το όνομα της αρχής, συμπεριλαμβανομένου του αντικειμένου στο οποίο ισχύει το δικαίωμα πρόσβασης·
- η ενέργεια που επιτρέπεται να γίνει με το αντικείμενο (προβολή, αλλαγή κ.λπ., δυνατότητα περιορισμού, για παράδειγμα, σε εδαφική βάση ή σε μια ομάδα πελατών).
- κωδικός αρχής (κωδικός και όνομα της λειτουργίας/αίτησης του συστήματος που μπορεί να εκτελεστεί χρησιμοποιώντας την αρχή).
- περιγραφή της αρχής (λεπτομερής περιγραφή των ενεργειών στο IS κατά την εφαρμογή της αρχής και των συνεπειών τους στη διαδικασία·
- κατάσταση άδειας: "Ενεργή" (εάν η άδεια έχει εκχωρηθεί σε τουλάχιστον έναν χρήστη) ή "Μη ενεργή" (αν δεν χρησιμοποιείται η άδεια).
Βήμα 6 Ξεφορτώνουμε δεδομένα σχετικά με τους χρήστες και τα δικαιώματα από τα συστήματα και τα συγκρίνουμε με την πηγή προσωπικού
Στο τελικό στάδιο της προετοιμασίας, πρέπει να ανεβάσετε δεδομένα από συστήματα πληροφοριών σχετικά με όλους τους χρήστες και τα δικαιώματα που έχουν αυτήν τη στιγμή. Δύο σενάρια είναι πιθανά εδώ. Πρώτον, το τμήμα ασφαλείας έχει άμεση πρόσβαση στο σύστημα και έχει τα μέσα να κατεβάσει τις σχετικές αναφορές, κάτι που είναι σπάνιο, αλλά πολύ βολικό. Δεύτερον: στέλνουμε ένα αίτημα στην IT για να λάβουμε αναφορές στην απαιτούμενη μορφή. Η πρακτική δείχνει ότι δεν είναι δυνατό να διαπραγματευτείτε με την πληροφορική και να λάβετε τα απαραίτητα δεδομένα την πρώτη φορά. Είναι απαραίτητο να γίνουν πολλές προσεγγίσεις μέχρι να ληφθούν οι πληροφορίες στην επιθυμητή μορφή και μορφή.
Ποια δεδομένα πρέπει να μεταφορτωθούν:
- Ονομα λογαριασμού
- Όνομα του υπαλλήλου στον οποίο έχει ανατεθεί
- Κατάσταση (ενεργή ή αποκλεισμένη)
- Ημερομηνία δημιουργίας λογαριασμού
- Ημερομηνία τελευταίας χρήσης
- Λίστα διαθέσιμων δικαιωμάτων/ομάδων/ρόλων
Λοιπόν, έχουμε λάβει εκφορτώσεις από το σύστημα με όλους τους χρήστες και με όλα τα δικαιώματα που τους παραχωρούνται. Και άφησαν αμέσως στην άκρη όλους τους αποκλεισμένους λογαριασμούς, καθώς οι εργασίες για τη δημιουργία ενός προτύπου θα πραγματοποιηθούν μόνο για ενεργούς χρήστες.
Στη συνέχεια, εάν η εταιρεία σας δεν διαθέτει αυτοματοποιημένα μέσα για το κλείσιμο της πρόσβασης σε απολυμένους υπαλλήλους (αυτό δεν είναι ασυνήθιστο) ή υπάρχει αυτοματισμός συνονθύλευμα που δεν λειτουργεί πάντα σωστά, πρέπει να αναγνωρίσετε όλες τις «νεκρές ψυχές». Μιλάμε για τους λογαριασμούς των ήδη απολυμένων εργαζομένων, των οποίων τα δικαιώματα για κάποιο λόγο δεν είναι μπλοκαρισμένα - πρέπει να αποκλειστούν. Για να γίνει αυτό, συγκρίνουμε τα μεταφορτωμένα δεδομένα με την πηγή προσωπικού. Η εκφόρτωση του προσωπικού πρέπει επίσης να ληφθεί εκ των προτέρων από τη μονάδα που οδηγεί τη βάση προσωπικού.
Ξεχωριστά, είναι απαραίτητο να παραμεριστούν λογαριασμοί των οποίων οι ιδιοκτήτες δεν βρέθηκαν στη βάση προσωπικού, δεν έχουν ανατεθεί σε κανέναν - δηλαδή χωρίς ιδιοκτήτη. Για αυτήν τη λίστα, χρειαζόμαστε την ημερομηνία της τελευταίας χρήσης: αν είναι αρκετά πρόσφατη, τότε πρέπει ακόμα να αναζητήσουμε τους ιδιοκτήτες. Αυτό μπορεί να περιλαμβάνει λογαριασμούς εξωτερικών εργολάβων ή λογαριασμούς υπηρεσιών που δεν έχουν εκχωρηθεί σε κανέναν, αλλά σχετίζονται με οποιεσδήποτε διαδικασίες. Για να διευκρινίσετε την ιδιοκτησία του λογαριασμού, μπορείτε να στείλετε επιστολές σε όλα τα τμήματα με αίτημα απάντησης. Όταν βρεθούν οι ιδιοκτήτες, εισάγουμε δεδομένα σχετικά με αυτούς στο σύστημα: με αυτόν τον τρόπο, προσδιορίζονται όλοι οι ενεργοί λογαριασμοί και οι υπόλοιποι μπλοκάρονται.
Μόλις οι μεταφορτώσεις μας διαγραφούν από περιττά αρχεία και παραμείνουν μόνο ενεργοί λογαριασμοί, μπορούμε να αρχίσουμε να χτίζουμε ένα πρότυπο για ένα συγκεκριμένο σύστημα πληροφοριών. Αλλά θα μιλήσω για αυτό στο επόμενο άρθρο.
Συγγραφέας: Lyudmila Sevastyanova, Υπεύθυνη Προώθησης Solar inRights
Πηγή: www.habr.com