Ποιος μπορεί να έχει πρόσβαση στον πηγαίο κώδικα, τη γραμμή και το περιβάλλον παραγωγής;
Ο έλεγχος πρόσβασης στην ανάπτυξη λογισμικού αφορά το ερώτημα ποιος μπορεί να εκτελέσει ποια ενέργεια σε ποιο τμήμα της γραμμής ανάπτυξής σας: ποιος μπορεί να διαβάσει κώδικα, ποιος μπορεί να τροποποιήσει και να συγχωνεύσει κώδικα, ποιος μπορεί να ξεκινήσει μια κατασκευή και ποιος μπορεί να κάνει μια έκδοση στην παραγωγή. Αυτό είναι ένα πιο συγκεκριμένο ερώτημα από τον έλεγχο πρόσβασης για έναν οργανισμό γενικά, επειδή μια ομάδα ανάπτυξης εργάζεται με πολλά συστήματα ταυτόχρονα: ένα αποθετήριο πηγαίου κώδικα, ένα περιβάλλον κατασκευής και δοκιμών, και συνήθως ένα отдельное περιβάλλον παραγωγής όπου εκτελείται πραγματικά το λογισμικό.
Ο λόγος για τον οποίο αυτό το θέμα εμφανίζεται στις λίστες ερωτήσεων ασφάλειας και στα μέτρα υπευθυνότητας της Οδηγίας NIS2 είναι ότι ένα σφάλμα στην πρόσβαση στη γραμμή ανάπτυξής σας έχει άμεση επίδραση σε όλους που χρησιμοποιούν το λογισμικό σας. Όποιος μπορεί να τροποποιήσει κώδικα χωρίς να παρατηρηθεί, ο οποίος στη συνέχεια αναπτύσσεται, δεν επηρεάζει μόνο τον δικό σας οργανισμό αλλά και τους πελάτες σας. Γι' αυτό ένας εποπτικός φορέας όπως και ένας αγοραστής που υπόκειται στους δικούς του όρους υπευθυνότητας ζητούν πώς έχετε αυτό διευθετήσει.
Γιατί αυτό αφορά συγκεκριμένα τον πηγαίο κώδικα και τη γραμμή
Μια ομάδα ανάπτυξης έχει συνήθως περισσότερα άτομα με ευρύτερα δικαιώματα από όσα είναι αυστηρά απαραίτητα, απλώς επειδή είναι πρακτικό: όλοι μπορούν να έχουν πρόσβαση παντού, κανείς δεν χρειάζεται να περιμένει για κάτι. Από τη σκοπιά της υπευθυνότητας, αυτό είναι ακριβώς το σημείο στο οποίο γίνονται επιπλέον ερωτήσεις. Όχι επειδή η εμπιστοσύνη θα ήταν λάθος, αλλά επειδή η αποδεικτικότητα είναι κάτι διαφορετικό από την εμπιστοσύνη: ένας εποπτικός φορέας ή ένας αγοραστής θέλει να γνωρίζει αν μπορείτε να δείξετε ποιος έχει πρόσβαση, όχι μόνο αν το εμπιστεύεστε.
Τα ερωτήματα που προκύπτουν συνήθως αφορούν τρεις στρώσεις. Η πρώτη είναι το ίδιο το αποθετήριο πηγαίου κώδικα: ποιος μπορεί να διαβάσει, ποιος μπορεί να τροποποιήσει, και υπάρχει υποχρεωτικός έλεγχος πριν συγχωνευθεί μια τροποποίηση με την κύρια έκδοση. Η δεύτερη είναι το περιβάλλον κατασκευής και δοκιμών: ποιος μπορεί να ξεκινήσει μια κατασκευή, και έχει εκείνο το περιβάλλον πρόσβαση σε δεδομένα ή συστήματα που δεν προορίζονται για δοκιμαστικούς σκοπούς. Η τρίτη είναι το περιβάλλον παραγωγής: ποιος μπορεί πραγματικά να αναπτύξει μια έκδοση, και είναι αυτό διαφορετικό από την ομάδα ατόμων που γράφουν τον κώδικα.
Διαχωρισμός μεταξύ συγγραφής και ανάπτυξης
Ένας επαναλαμβανόμενος διαχωρισμός στις λίστες ερωτήσεων είναι αν το άτομο που γράφει τον κώδικα είναι επίσης εκείνο που κάνει την έκδοση στην παραγωγή. Όταν αυτό είναι το ίδιο άτομο, χωρίς ενδιάμεσο βήμα από κάποιον άλλο, προκύπτει μια κατάσταση όπου ένα σφάλμα ή μια κακόβουλη τροποποίηση μπορεί να φτάσει ανεξέλεγκτη στην παραγωγή. Πολλοί οργανισμοί το επιλύουν αυτό με έναν υποχρεωτικό δεύτερο έλεγχο πριν συγχωνευθεί ο κώδικας, και με ένα ξεχωριστό ρόλο ή ξεχωριστά δικαιώματα για την πραγματική ανάπτυξη. Το πώς αυτό φαίνεται στην πράξη ποικίλλει πολύ ανάλογα με την ομάδα και το μέγεθος. η ίδια η Οδηγία δεν θέτει συγκεκριμένη μέθοδο, αλλά οι εποπτικοί φορείς και οι αγοραστές κοιτάζουν το υποκείμενο ερώτημα: μπορεί ένα άτομο ανεξέλεγκτα να εισάγει τροποποιήσεις που επηρεάζουν τους πελάτες.
Μυστικά και κλειδιά ξεχωριστά από τον κώδικα
Ένα δεύτερο σημείο στο οποίο οι λίστες ερωτήσεων συχνά ρωτούν επιπλέον είναι το πού αποθηκεύονται τα συνθηματικά, τα κλειδιά API και άλλα μυστικά. Τα μυστικά που βρίσκονται στον ίδιο τον πηγαίο κώδικα είναι ορατά σε όλους όσους έχουν πρόσβαση ανάγνωσης στον κώδικα, που μπορεί να είναι μια πολύ μεγαλύτερη ομάδα από όσους θα έπρεπε πραγματικά να δουλεύουν με εκείνο το κλειδί. Ένα ξεχωριστό θησαυροφυλάκιο για μυστικά, με δικά του δικαιώματα πρόσβασης ανεξάρτητα από το αποθετήριο κώδικα, είναι ένας συνηθισμένος τρόπος να γίνει αυτό ο διαχωρισμός. Το αν και πώς θα το οργανώσετε είναι μια τεχνική επιλογή. το σχετικό σημείο για το δοσιέ είναι κυρίως αν μπορείτε να εξηγήσετε γιατί η επιλεγμένη προσέγγιση είναι κατάλληλη για το μέγεθος και τους κινδύνους αυτού που κατασκευάζετε.
Τι καταγράφετε, όχι μόνο τι ρυθμίζετε
Η τεχνική ρύθμιση των δικαιωμάτων πρόσβασης είναι ένα πράγμα· η απόδειξη αυτής της ρύθμισης είναι ένα δεύτερο, και αυτό το δεύτερο ξεχνιέται συχνά στην πράξη. Ένας κατάλογος του ποιος έχει πρόσβαση σε ποιο σύστημα, πότε χορηγήθηκε αυτή η πρόσβαση και με ποια βάση, είναι ακριβώς το στοιχείο απόδειξης το οποίο ζητούν ένα ερωτηματολόγιο ή ένας εποπτικός φορέας. Χωρίς αυτόν τον κατάλογο θα πρέπει να το διευθετήσετε ξανά για κάθε ερώτηση· με ένα δυναμικό μητρώο δίπλα σε κάθε μέτρο η απάντηση είναι ήδη έτοιμη. παρακολουθήστε την εξήγηση ανά μέτρο παρέχει μια εικόνα του τρόπου με τον οποίο η διαχείριση πρόσβασης σχετίζεται με τα άλλα εννέα μέτρα από τη δέσμευση φροντίδας.
Εάν ο οργανισμός σας εμπίπτει υπό τη δέσμευση φροντίδας ή εάν λαμβάνετε αυτήν την ερώτηση επειδή ένας ανάδοχος εμπίπτει, μπορεί να προσδιοριστεί με μερικές ερωτήσεις. Για όσους αναρωτιούνται πόσο αυστηροί είναι ακριβώς οι απαιτήσεις για τη διαχείριση πρόσβασης όταν ένας πελάτης ζητά να αποδείξει ποια μέτρα έχουν εφαρμοστεί, η εξήγηση σχετικά με την προστασία και την ασφάλεια δεδομένων παρέχει μια ευρύτερη εικόνα του τόπου προέλευσης αυτού του είδους των απαιτήσεων.
Για την ίδια περίστασή σας, για παράδειγμα εάν ένας συγκεκριμένος τρόπος ρύθμισης του αναπτυξιακού αγωγού σας είναι επαρκής για τη δέσμευση φροντίδας που σας βαρύνει ή τον ανάδοχό σας, ένας νομικός ή ο αρμόδιος εποπτικός φορέας είναι το κατάλληλο μέρος· το secria.eu προετοιμάζει την καταγραφή αλλά δεν εκδίδει απόφαση σχετικά με την ατομική συμμόρφωση.
Θέλετε να δείτε πώς η διαχείριση πρόσβασης ταιριάζει στο υπόλοιπο δοσιέ σας ή έχετε ακόμη ερωτήσεις σχετικά με το τι ακριβώς εννοείται με αυτό το μέτρο; διαβάστε τις συχνές ερωτήσεις παρέχει απάντηση σε πολλά από αυτά τα σημεία και η δωρεάν γρήγορη σάρωση δείχνει σε λίγα λεπτά πού βρίσκεται ο οργανισμός σας σχετικά με αυτό το θέμα.