Προφανώς το κάρμα μου είναι το εξής: να εφαρμόζω τυπικές εργασίες με κάθε είδους μη τετριμμένους τρόπους. Εάν κάποιος έχει διαφορετική άποψη για το πρόβλημα, παρακαλούμε να το συζητήσει ώστε να επιλυθεί το ζήτημα.
Ένα ωραίο πρωί προέκυψε μια ενδιαφέρουσα εργασία για τη διανομή δικαιωμάτων σε ομάδες χρηστών για διαφορετικά κοινόχρηστα στοιχεία που περιέχουν υποφακέλους έργων με φακέλους εγγράφων. Όλα ήταν καλά και γράφτηκε ένα σενάριο για να εκχωρηθούν δικαιώματα στους φακέλους. Και μετά αποδείχθηκε ότι οι ομάδες πρέπει να περιέχουν χρήστες από διαφορετικούς τομείς, από διαφορετικά δάση (). Ας υποθέσουμε ότι η ίδια η κοινή χρήση βρίσκεται σε μέσα Synology, καταχωρημένα στον τομέα FB του δάσους PSI. Εργασία: να επιτραπεί στους χρήστες τομέων σε άλλο δάσος να έχουν πρόσβαση στα περιεχόμενα αυτού του κοινόχρηστου στοιχείου, και μάλιστα πολύ επιλεκτικά.
Μετά από κάποιο χρονικό διάστημα, οι τεχνικές προδιαγραφές πήραν την εξής μορφή:
- 2 δάση: δάσος PSI, δάσος TG.
- Κάθε δάσος έχει 3 τομείς: PSI (ZG, PSI, FB). TG (TG, HU, KC).
- Υπάρχει μια σχέση εμπιστοσύνης μεταξύ των δασών· το Synology βλέπει όλες τις ομάδες ασφαλείας σε όλα τα δάση.
- Τα κοινόχρηστα στοιχεία και οι φάκελοι/υποφάκελοι πρέπει να έχουν λογαριασμούς διαχειριστή τομέα FB με δικαιώματα FullControl
- Τα ονόματα των φακέλων θα πρέπει να συστηματοποιηθούν. Η διοίκηση συντόνισε τα αναγνωριστικά έργων· αποφάσισα να συνδέσω το όνομα των ομάδων ασφαλείας με τα αναγνωριστικά έργων.
- Οι φάκελοι έργων σε κοινόχρηστα στοιχεία συστήματος πρέπει να περιέχουν μια δομή που έχει προετοιμαστεί εκ των προτέρων σε αρχείο .xlsx, με κατάλληλα δικαιώματα πρόσβασης (R/RW/NA, όπου NA – χωρίς πρόσβαση)
- Θα πρέπει να είναι δυνατός ο περιορισμός των δικαιωμάτων των χρηστών/μελών ομάδας ενός έργου μόνο σε ορισμένους καταλόγους αυτού του έργου. Ο χρήστης ενδέχεται να μην έχει πρόσβαση σε άλλους καταλόγους/έργα, ανάλογα με τη συμμετοχή στην ομάδα.
- Κατά τη δημιουργία ενός φακέλου έργου, οι ομάδες θα πρέπει να δημιουργούνται όσο το δυνατόν αυτόματα στους κατάλληλους τομείς με ονόματα που αντιστοιχούν στα αναγνωριστικά έργου.
Σημειώσεις για τις τεχνικές προδιαγραφές
- Η δημιουργία σχέσεων εμπιστοσύνης δεν περιλαμβάνεται στο πεδίο εφαρμογής των τεχνικών προδιαγραφών
- Το αναγνωριστικό έργου περιέχει αριθμούς και λατινικούς χαρακτήρες
- Οι ρόλοι χρήστη του έργου για όλους τους τομείς έχουν τυπικά ονόματα
- Ένα αρχείο .xlsx με φακέλους και δικαιώματα πρόσβασης (πίνακας πρόσβασης) προετοιμάζεται πριν από την έναρξη ολόκληρου του έργου
- Κατά την υλοποίηση έργων, είναι δυνατή η δημιουργία ομάδων χρηστών στους αντίστοιχους τομείς
- Ο αυτοματισμός επιτυγχάνεται με τη χρήση τυπικών εργαλείων διαχείρισης MS Windows
Εφαρμογή τεχνικών προδιαγραφών
Μετά την επισημοποίηση αυτών των απαιτήσεων, έγινε μια τακτική παύση για τη δοκιμή μεθόδων για τη δημιουργία καταλόγων και την εκχώρηση δικαιωμάτων σε αυτούς. Είχε σκοπό να χρησιμοποιήσει μόνο το PowerShell, ώστε να μην περιπλέξει το έργο. Όπως έγραψα νωρίτερα, ο αλγόριθμος σεναρίου φαινόταν αρκετά απλός:
- καταχωρούμε ομάδες με όνομα που προέρχεται από το αναγνωριστικό του έργου (για παράδειγμα KC40587) και τους αντίστοιχους ρόλους που καθορίζονται στον πίνακα πρόσβασης: KC40587-EN- για μηχανικός. KC40587-PM – για διαχειριστή προϊόντων κ.λπ.
- παίρνουμε τα SID των ομάδων που δημιουργήθηκαν
- καταχωρήστε το φάκελο του έργου και το αντίστοιχο σύνολο καταλόγων (η λίστα των υποφακέλων εξαρτάται από το κοινόχρηστο στοιχείο στο οποίο δημιουργείται και ορίζεται στη μήτρα πρόσβασης)
- εκχώρηση δικαιωμάτων σε ομάδες για νέους υποκαταλόγους του έργου σύμφωνα με τον πίνακα πρόσβασης.
Δυσκολίες που αντιμετωπίστηκαν στο στάδιο 1:
- παρανόηση της μεθόδου καθορισμού της μήτρας πρόσβασης στο σενάριο (ένας πολυδιάστατος πίνακας εφαρμόζεται τώρα, αλλά η διαδρομή για την πλήρωσή του αναζητείται με βάση τα περιεχόμενα του αρχείου/μήτρας πρόσβασης .xlsx)
- αδυναμία ορισμού δικαιωμάτων πρόσβασης σε κοινόχρηστα στοιχεία SMB σε μονάδες συνολογίας με χρήση PoSH (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on- nas -share?forum=winserverpowershell), εξαιτίας του οποίου χάθηκε πολύς χρόνος και όλα έπρεπε να προσαρμοστούν σε σενάρια χρησιμοποιώντας το βοηθητικό πρόγραμμα επεξεργασίας δικαιωμάτων πρόσβασης icacls, το οποίο απαιτούσε τη δημιουργία μιας ενδιάμεσης αποθήκης αρχείων κειμένου και cmd.
Στην τρέχουσα λειτουργία, η εκτέλεση των αρχείων cmd ελέγχεται χειροκίνητα, ανάλογα με την ανάγκη εγγραφής ενός φακέλου για το έργο.
Αποδείχθηκε επίσης ότι το σενάριο θα πρέπει επίσης να εκτελεστεί για την εγγραφή ομάδων σε άλλα δάση (χρησιμοποιήθηκε ο όρος Cross-domains) και η αναλογία μπορεί να είναι όχι μόνο 1 προς ένα, αλλά και 1 προς πολλά.
Αυτό σημαίνει ότι ομάδες από άλλους διατομείς, συμπεριλαμβανομένου ενός γειτονικού δάσους, μπορούν πλέον να διεκδικήσουν πρόσβαση στους πόρους οποιουδήποτε τομέα. Για να επιτευχθεί ομοιομορφία, αποφασίστηκε να δημιουργηθεί μια συμμετρική δομή στο OU όλων των εξυπηρετούμενων περιοχών όλων των δασών (μαύρα κάθετα οβάλ). Όπως λένε, στο στρατό όλα πρέπει να είναι άσχημα, αλλά ομοιόμορφα:
Έτσι, κατά την εγγραφή του έργου 80XXX στον τομέα TG, το σενάριο εκτελεί:
1. δημιουργία των αντίστοιχων OU (κόκκινα οριζόντια οβάλ) σε αυτόν τον τομέα και cross-domains, δηλαδή εκείνων των τομέων των οποίων οι υπάλληλοι πρέπει να έχουν πρόσβαση σε αυτόν τον πόρο.
2. συμπληρώνοντας το OU με ομάδες με ονόματα όπως -, όπου:
- Τομέας SRC_ – διατομέας του οποίου οι υπάλληλοι θα έχουν πρόσβαση σε πόρους τομέα DST
- DST_domain – ο τομέας στους πόρους του οποίου, στην πραγματικότητα, θα πρέπει να παρέχεται πρόσβαση, δηλαδή, για χάρη του οποίου ξεκίνησαν όλα
- — αριθμός έργου
- ROLES – ονόματα των ρόλων που παρατίθενται στον πίνακα πρόσβασης.
3. ανάγνωση της σειράς SID όλων των ομάδων όλων των εμπλεκόμενων τομέων και αποθήκευση της για μεταγενέστερη μεταφορά δεδομένων σε ένα αρχείο που ορίζει τα δικαιώματα σε έναν συγκεκριμένο υποφάκελο έργου
4. δημιουργία αρχείων προέλευσης (παράμετρος /επαναφορά) με ένα σύνολο δικαιωμάτων για χρήση από το βοηθητικό πρόγραμμα icacKC σε λειτουργία εκτελέσιμου αρχείου "icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt"
5. δημιουργία ενός αρχείου CMD που συνδυάζει όλα τα εκκινημένα icacl για όλους τους φακέλους του έργου
Όπως γράφτηκε νωρίτερα, η εκκίνηση του εκτελέσιμου αρχείου γίνεται με μη αυτόματο τρόπο και η αξιολόγηση των αποτελεσμάτων της εκτέλεσης γίνεται επίσης χειροκίνητα.
Δυσκολίες που έπρεπε να αντιμετωπίσουμε στο τέλος:
- εάν ο φάκελος του έργου είναι ήδη γεμάτος με μεγάλο αριθμό αρχείων, τότε η εκτέλεση της εντολής icacls στους υπάρχοντες τόμους μπορεί να πάρει αρκετό χρόνο και σε ορισμένες περιπτώσεις να οδηγήσει σε αποτυχία (για παράδειγμα, όταν υπάρχουν μεγάλες διαδρομές αρχείων).
- Εκτός από την παράμετρο /restore, έπρεπε να προσθέσουμε γραμμές με την παράμετρο /reset σε περίπτωση που οι φάκελοι δεν δημιουργήθηκαν, αλλά μεταφέρονταν από προηγουμένως υπάρχοντες φακέλους, με τα δικαιώματα κληρονομιάς από τη ρίζα απενεργοποιημένα.
- Μέρος του σεναρίου για τη δημιουργία ομάδων έπρεπε να εκτελεστεί σε ένα αυθαίρετο dc κάθε δάσους, το πρόβλημα αφορά διαχειριστικούς λογαριασμούς για κάθε δέντρο.
Γενικό συμπέρασμα: είναι πολύ περίεργο που δεν υπάρχουν ακόμη βοηθητικά προγράμματα με παρόμοια λειτουργικότητα στην αγορά. Φαίνεται δυνατή η υλοποίηση παρόμοιας λειτουργικότητας με βάση την πύλη Sharepoint.
Είναι επίσης ακατανόητο ότι δεν είναι δυνατή η χρήση βοηθητικών προγραμμάτων PoSH για τη ρύθμιση δικαιωμάτων φακέλων σε συσκευές sinology.
Εάν επιθυμείτε, είμαι έτοιμος να μοιραστώ το σενάριο δημιουργώντας κάποιο έργο στο github αν κάποιος ενδιαφέρεται.
Πηγή: www.habr.com