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

Γιατί αυτό το θέμα έχει σήμερα σημασία

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

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

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

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

Πού αυξάνεται συχνότερα το κόστος ή ο κίνδυνος

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

Το συνηθέστερο σφάλμα στον σχεδιασμό είναι ότι τα δικαιώματα ορίζονται με βάση τις οργανωτικές θέσεις και όχι με βάση τις επιχειρησιακές συνέπειες. Σε μια βιομηχανική εφαρμογή δεν αρκεί να ξεχωρίζουμε τον χειριστή, τη συντήρηση και τον διαχειριστή. Πρέπει να διαχωρίζονται η ανάγνωση, η επιβεβαίωση συναγερμού, η αλλαγή τεχνολογικής παραμέτρου, η παράκαμψη μανδάλωσης, η επαναφορά ρυθμίσεων, η ενημέρωση λογισμικού και η απομακρυσμένη πρόσβαση, και στη συνέχεια αυτές οι ενέργειες να αντιστοιχίζονται σε ζώνες, τρόπους λειτουργίας και προϋποθέσεις εκτέλεσης. Όταν αυτός ο διαχωρισμός λείπει, εμφανίζονται εξαιρέσεις «για τη φάση θέσης σε λειτουργία», κοινόχρηστοι λογαριασμοί service και εκτεταμένα τεχνικά δικαιώματα, τα οποία αργότερα παραμένουν στο σύστημα κατά την παραγωγή. Για τον υπεύθυνο έργου αυτό δεν είναι μια τεχνική λεπτομέρεια, αλλά μια προβλέψιμη πηγή καθυστερήσεων στις παραλαβές, επειδή κάθε ασάφεια επανέρχεται με το ίδιο ερώτημα: ποιος, από πού και υπό ποιες συνθήκες μπορεί να εκτελέσει μια ενέργεια που επηρεάζει το μηχάνημα ή τη διαδικασία. Το πρακτικό κριτήριο αξιολόγησης είναι απλό: αν η ίδια ταυτότητα ή η ίδια συνεδρία μπορεί, χωρίς αλλαγή πλαισίου, να περάσει από την προβολή στην τροποποίηση λειτουργιών με ουσιώδεις συνέπειες, τότε η τμηματοποίηση είναι υπερβολικά επίπεδη.

Χαρακτηριστικό παράδειγμα είναι μια εφαρμογή που επιτρέπει απομακρυσμένη διάγνωση μιας γραμμής και ταυτόχρονα παρέχει οθόνη αλλαγής συνταγών ή οριακών παραμέτρων. Στο στάδιο της σύλληψης αυτό φαίνεται λογικό, επειδή απλοποιεί το service και μειώνει τον χρόνο απόκρισης. Το πρόβλημα εμφανίζεται αργότερα: ένας λογαριασμός που προορίζεται για ανάλυση βλαβών αρχίζει να έχει πραγματική επίδραση στη συμπεριφορά του εξοπλισμού, ενώ ένα κανάλι επικοινωνίας που προορίζεται για ανάγνωση μετατρέπεται σε οδό παρέμβασης. Αν προστεθεί και η δυνατότητα επαναφοράς αντιγράφου διαμόρφωσης, επανεκκίνησης υπηρεσίας ή απομακρυσμένης φόρτωσης πακέτου, ένα μεμονωμένο σφάλμα στην εκχώρηση δικαιωμάτων μπορεί να παρακάμψει τον συμφωνημένο διαχωρισμό ευθυνών. Σε μια τέτοια διάταξη, το κόστος δεν προκύπτει μόνο από την πρόσθετη εργασία προγραμματισμού. Περιλαμβάνει επίσης επαναληπτικές δοκιμές, ενημέρωση της τεκμηρίωσης, συνεννοήσεις με τους προμηθευτές εξαρτημάτων και την ανάγκη να αποδειχθεί ότι δεν δημιουργήθηκε νέα οδός επιρροής στη λειτουργία του μηχανήματος. Γι’ αυτό αξίζει να μετριέται όχι ο αριθμός των ρόλων, αλλά ο αριθμός των κρίσιμων ενεργειών που είναι διαθέσιμες μέσω απομακρυσμένων καναλιών, ο αριθμός των κοινόχρηστων λογαριασμών και ο αριθμός των εξαιρέσεων από το προεπιλεγμένο μοντέλο άρνησης.

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

Πώς να προσεγγίσετε το θέμα στην πράξη

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

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

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

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

Τι να προσέξετε κατά την υλοποίηση

Το συνηθέστερο λάθος κατά την εφαρμογή της αρχής των ελάχιστων δικαιωμάτων και της τμηματοποίησης πρόσβασης σε βιομηχανικές εφαρμογές είναι ότι αντιμετωπίζονται ως ένα διοικητικό επίπεδο που προστίθεται στο τέλος του έργου. Στην πράξη, πρόκειται για αρχιτεκτονική απόφαση που επηρεάζει το μοντέλο λειτουργίας του συστήματος, τον τρόπο διαχείρισης βλαβών, την ευθύνη για τις αλλαγές και το κόστος συντήρησης. Αν τα δικαιώματα ορίζονται μόνο αφού έχει ήδη υλοποιηθεί η λογική ελέγχου, οι διασυνδέσεις και τα service interfaces, η ομάδα συνήθως καταλήγει με εξαιρέσεις, παρακάμψεις και «προσωρινούς» ρόλους που τελικά παραμένουν μόνιμα. Αυτό αυξάνει την επιφάνεια πρόσβασης, περιπλέκει τις παραλαβές και δυσκολεύει την απόδειξη ότι μια συγκεκριμένη λειτουργία δόθηκε συνειδητά και όχι κατά λάθος. Για τον υπεύθυνο έργου, αυτό έχει μια απλή συνέπεια: όσο αργότερα λαμβάνεται η απόφαση για τα όρια πρόσβασης, τόσο υψηλότερο είναι το κόστος αλλαγών και τόσο μεγαλύτερος ο κίνδυνος να θολώσει η ευθύνη για τις λειτουργικές συνέπειες μεταξύ κατασκευαστή, integrator και τελικού χρήστη.

Έτσι, το θέμα αυτό περνά πολύ γρήγορα στον χώρο του σχεδιασμού βιομηχανικών εφαρμογών και όχι μόνο της διαχείρισης λογαριασμών. Η τμηματοποίηση πρόσβασης πρέπει να λαμβάνει υπόψη τα πραγματικά όρια της διεργασίας: τους τρόπους λειτουργίας, τις εξαρτήσεις μεταξύ συσκευών, την τοπικότητα της ενέργειας και τη συμπεριφορά σε περίπτωση απώλειας επικοινωνίας, επανεκκίνησης του ελεγκτή ή μετάβασης σε χειροκίνητη λειτουργία. Αν η εφαρμογή απαιτεί συνεχή διαθεσιμότητα της υπηρεσίας αυθεντικοποίησης ώστε ο χειριστής να μπορέσει να εκτελέσει μια ενέργεια απαραίτητη για την ασφαλή ακινητοποίηση ή την αποκατάσταση της διεργασίας, τότε το μοντέλο ασφάλειας έχει σχεδιαστεί εσφαλμένα. Το ίδιο ισχύει όταν μια βλάβη δικτύου προκαλεί ανεξέλεγκτη επέκταση δικαιωμάτων «για το διάστημα του service», επειδή διαφορετικά το σύστημα καθίσταται άχρηστο. Το πρακτικό κριτήριο αξιολόγησης εδώ είναι σαφές: για κάθε προνομιακή ενέργεια πρέπει να μπορεί να δοθεί απάντηση στο τι θα συμβεί σε περίπτωση απουσίας δικτύου, μετά από επανεκκίνηση της συσκευής και μετά από απώλεια σύνδεσης με το ανώτερο σύστημα. Αν η απάντηση είναι «ο διαχειριστής θα δώσει το δικαίωμα χειροκίνητα» ή «ο χρήστης γνωρίζει τη διαδικασία παράκαμψης», τότε δεν πρόκειται ακόμη για λύση έτοιμη προς υλοποίηση.

Στην πράξη αυτό φαίνεται καθαρά στις λειτουργίες service και συντήρησης, οι οποίες εκ πρώτης όψεως δεν αλλάζουν τη διεργασία, αλλά αλλάζουν τη δυνατότητα ελέγχου της. Παραδείγματα είναι η απομακρυσμένη αλλαγή παραμέτρων, η διαγραφή συναγερμών, η εναλλαγή πηγής δεδομένων, η προσωρινή απενεργοποίηση της επικύρωσης εισόδων ή η ενεργοποίηση δοκιμαστικής λειτουργίας της διεπαφής. Κάθε μία από αυτές τις ενέργειες μπορεί να είναι δικαιολογημένη, αλλά δεν θα πρέπει κατ’ ανάγκη να είναι διαθέσιμη από το ίδιο τμήμα δικτύου, στον ίδιο τρόπο λειτουργίας και για τον ίδιο ρόλο. Αν μία ταυτότητα χρήστη επιτρέπει ταυτόχρονα διάγνωση, τροποποίηση παραμέτρων και έγκριση επαναφοράς της λειτουργίας, τότε η ομάδα έχει δημιουργήσει ένα κοινό σημείο οργανωτικής και τεχνικής αστοχίας. Είναι προτιμότερο να αξιολογείται αυτό όχι με βάση τον αριθμό των ρόλων, αλλά με βάση μετρήσιμες συνέπειες: πόσες κρίσιμες ενέργειες απαιτούν πολυλειτουργική πρόσβαση, πόσες εξαιρέσεις από την πολιτική πρέπει να διατηρούνται μετά την έναρξη λειτουργίας και αν τα αρχεία καταγραφής συμβάντων επιτρέπουν να διαπιστωθεί με σαφήνεια ποιος, από πού και σε ποιο πλαίσιο πραγματοποίησε την αλλαγή. Αυτοί είναι δείκτες που δείχνουν στην πράξη αν η τμηματοποίηση περιορίζει τον κίνδυνο ή απλώς περιπλέκει τη λειτουργία.

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