Η τράπεζα αναθέτει τα έργα της σε πολλούς εργολάβους. Τα "εξωτερικά" γράφουν κώδικα και μετά μεταδίδουν τα αποτελέσματα σε μια όχι πολύ βολική μορφή. Συγκεκριμένα, η διαδικασία έμοιαζε ως εξής: παρέδωσαν ένα έργο που πέρασε μαζί τους λειτουργικές δοκιμές και στη συνέχεια δοκιμάστηκε εντός της τραπεζικής περιμέτρου για ενσωμάτωση, φόρτο κ.λπ. Συχνά ανακαλύφθηκε ότι τα τεστ απέτυχαν. Στη συνέχεια, όλα επέστρεψαν στον εξωτερικό προγραμματιστή. Όπως μπορείτε να μαντέψετε, αυτό σήμαινε μεγάλους χρόνους παράδοσης για διορθώσεις σφαλμάτων.
Η τράπεζα αποφάσισε ότι ήταν δυνατό και απαραίτητο να σύρει ολόκληρο τον αγωγό κάτω από την πτέρυγά της, από τις δεσμεύσεις μέχρι την απελευθέρωση. Για να είναι όλα ομοιόμορφα και υπό τον έλεγχο των ομάδων που είναι υπεύθυνες για το προϊόν στην τράπεζα. Δηλαδή σαν να δούλευε απλά ο εξωτερικός εργολάβος κάπου στο διπλανό δωμάτιο του γραφείου. Στην εταιρική στοίβα. Αυτό είναι ένα συνηθισμένο devop.
Από πού προήλθε ο Sec; Η ασφάλεια της τράπεζας έχει θέσει υψηλές απαιτήσεις για το πώς ένας εξωτερικός ανάδοχος μπορεί να εργαστεί στο τμήμα του δικτύου, ποια πρόσβαση έχει κάποιος, πώς και ποιος λειτουργεί με τον κωδικό. Απλώς η IB δεν γνώριζε ακόμη ότι όταν οι εργολάβοι εργάζονται έξω, ακολουθούνται λίγα τραπεζικά πρότυπα. Και μετά σε λίγες μέρες όλοι πρέπει να αρχίσουν να τα παρατηρούν.
Η απλή αποκάλυψη ότι ο ανάδοχος είχε πλήρη πρόσβαση στον κωδικό προϊόντος είχε ήδη ανατρέψει τον κόσμο τους.
Αυτή τη στιγμή ξεκίνησε η ιστορία του DevSecOps, για την οποία θέλω να σας πω.
Ποια πρακτικά συμπεράσματα έβγαλε η τράπεζα από αυτή την κατάσταση;
Υπήρχε μεγάλη διαμάχη για το γεγονός ότι όλα γίνονται με λάθος τρόπο. Οι προγραμματιστές είπαν ότι η ασφάλεια είναι απασχολημένη μόνο προσπαθώντας να παρέμβει στην ανάπτυξη και αυτοί, όπως οι φύλακες, προσπαθούν να απαγορεύσουν χωρίς σκέψη. Με τη σειρά τους, οι ειδικοί σε θέματα ασφάλειας δίστασαν να επιλέξουν μεταξύ των απόψεων: «οι προγραμματιστές δημιουργούν τρωτά σημεία στο κύκλωμά μας» και «οι προγραμματιστές δεν δημιουργούν τρωτά σημεία, αλλά είναι οι ίδιοι». Η διαμάχη θα συνεχιζόταν για μεγάλο χρονικό διάστημα αν όχι οι νέες απαιτήσεις της αγοράς και η εμφάνιση του παραδείγματος DevSecOps. Ήταν δυνατό να εξηγηθεί ότι αυτή η ίδια η αυτοματοποίηση των διαδικασιών, λαμβάνοντας υπόψη τις απαιτήσεις ασφάλειας πληροφοριών "εκτός από το κουτί" θα βοηθήσει όλους να παραμείνουν ευχαριστημένοι. Με την έννοια ότι οι κανόνες καταγράφονται αμέσως και δεν αλλάζουν κατά τη διάρκεια του παιχνιδιού (η ασφάλεια των πληροφοριών δεν θα απαγορεύσει κάτι απροσδόκητα), και οι προγραμματιστές ενημερώνουν την ασφάλεια πληροφοριών για ό,τι συμβαίνει (η ασφάλεια πληροφοριών δεν συναντά κάτι ξαφνικά) . Κάθε ομάδα είναι επίσης υπεύθυνη για την απόλυτη ασφάλεια, και όχι κάποιοι αφηρημένοι μεγαλύτεροι αδελφοί.
- Εφόσον οι εξωτερικοί υπάλληλοι έχουν ήδη πρόσβαση στον κωδικό και σε ορισμένα εσωτερικά συστήματα, είναι πιθανώς δυνατό να αφαιρεθεί από τα έγγραφα η απαίτηση «η ανάπτυξη πρέπει να πραγματοποιηθεί εξ ολοκλήρου στην υποδομή της τράπεζας».
- Από την άλλη πλευρά, πρέπει να ενισχύσουμε τον έλεγχο του τι συμβαίνει.
- Ο συμβιβασμός ήταν η δημιουργία διαλειτουργικών ομάδων, όπου οι εργαζόμενοι συνεργάζονται στενά με εξωτερικούς ανθρώπους. Σε αυτήν την περίπτωση, πρέπει να βεβαιωθείτε ότι η ομάδα εργάζεται σε εργαλεία στους διακομιστές της τράπεζας. Από την αρχή μέχρι το τέλος.
Δηλαδή, μπορούν να επιτραπούν οι εργολάβοι, αλλά πρέπει να τους δοθούν χωριστά τμήματα. Για να μην φέρουν κάποιο είδος μόλυνσης από το εξωτερικό στην υποδομή της τράπεζας και για να μην βλέπουν περισσότερα από όσα χρειάζεται. Λοιπόν, για να καταγράφονται οι ενέργειές τους. DLP για προστασία από διαρροές, όλα αυτά συμπεριλήφθηκαν.
Καταρχήν, όλες οι τράπεζες έρχονται σε αυτό αργά ή γρήγορα. Εδώ ακολουθήσαμε την πεπατημένη και συμφωνήσαμε στις απαιτήσεις για τέτοια περιβάλλοντα όπου λειτουργούν τα «εξωτερικά». Εμφανίστηκε ένα μέγιστο εύρος εργαλείων ελέγχου πρόσβασης, εργαλείων ελέγχου ευπάθειας, ανάλυσης προστασίας από ιούς σε κυκλώματα, συγκροτήματα και δοκιμές. Αυτό ονομάζεται DevSecOps.
Ξαφνικά έγινε σαφές ότι αν πριν από το DevSecOps η τραπεζική ασφάλεια δεν είχε κανέναν έλεγχο για το τι συμβαίνει από την πλευρά του προγραμματιστή, τότε στο νέο παράδειγμα η ασφάλεια ελέγχεται με τον ίδιο τρόπο όπως τα συνηθισμένα συμβάντα στην υποδομή. Μόνο τώρα υπάρχουν ειδοποιήσεις για συνελεύσεις, έλεγχο βιβλιοθηκών και ούτω καθεξής.
Το μόνο που μένει είναι να μεταφερθούν οι ομάδες στο νέο μοντέλο. Λοιπόν, δημιουργήστε την υποδομή. Αλλά αυτά είναι μικροπράγματα, είναι σαν να ζωγραφίζεις μια κουκουβάγια. Ουσιαστικά, βοηθήσαμε με τις υποδομές και εκείνη την εποχή άλλαζαν οι διαδικασίες ανάπτυξης.
Τι έχει αλλάξει
Αποφασίσαμε να το εφαρμόσουμε με μικρά βήματα, γιατί καταλάβαμε ότι πολλές διαδικασίες θα κατέρρεαν και πολλοί «εξωτερικοί» μπορεί να μην αντέξουν τις νέες συνθήκες εργασίας υπό την επίβλεψη όλων.
Πρώτον, δημιουργήσαμε διαλειτουργικές ομάδες και μάθαμε να οργανώνουμε έργα λαμβάνοντας υπόψη τις νέες απαιτήσεις. Με την έννοια οργανωτικά συζητήσαμε ποιες διαδικασίες. Το αποτέλεσμα ήταν ένα διάγραμμα του αγωγού συναρμολόγησης με όλους τους υπεύθυνους.
- IC: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
- CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
- Δοκιμή: Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Performance Center, MF UFT, Ataccama.
- Παρουσίαση (ρεπορτάζ, επικοινωνία): Grafana, Kibana, Jira, Confluence, RocketChat.
- λειτουργίες (συντήρηση, διαχείριση): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.
Επιλεγμένη στοίβα:
- Γνωσιακή Βάση - Ατλαντική συμβολή;
- Task tracker - Atlassian Jira;
- Αποθετήριο τεχνουργημάτων - "Nexus";
- Σύστημα συνεχούς ολοκλήρωσης - "Gitlab CI".
- Σύστημα συνεχούς ανάλυσης - "SonarQube";
- Σύστημα ανάλυσης ασφάλειας εφαρμογής - "Micro Focus Fortify";
- Σύστημα επικοινωνίας - "GitLab Mattermost";
- Σύστημα διαχείρισης διαμόρφωσης - "Ansible";
- Σύστημα παρακολούθησης - "ELK", "TICK Stack" ("InfluxData").
Άρχισαν να δημιουργούν μια ομάδα που θα ήταν έτοιμη να σύρει εργολάβους μέσα. Υπάρχει συνειδητοποίηση ότι υπάρχουν πολλά σημαντικά πράγματα:
- Όλα θα πρέπει να είναι ενοποιημένα, τουλάχιστον κατά τη μετάδοση κώδικα. Γιατί ήταν τόσοι εργολάβοι όσοι και τόσες διαφορετικές διαδικασίες ανάπτυξης με τις δικές τους ιδιαιτερότητες. Ήταν απαραίτητο να χωρέσουν όλοι σε ένα περίπου, αλλά με επιλογές.
- Υπάρχουν πολλοί εργολάβοι και η χειρωνακτική δημιουργία υποδομής δεν είναι κατάλληλη. Οποιαδήποτε νέα εργασία θα πρέπει να ξεκινά πολύ γρήγορα - δηλαδή, το στιγμιότυπο θα πρέπει να αναπτυχθεί σχεδόν αμέσως, έτσι ώστε οι προγραμματιστές να έχουν ένα σύνολο λύσεων για τη διαχείριση του αγωγού τους.
Για να γίνει το πρώτο βήμα, ήταν απαραίτητο να καταλάβουμε τι γινόταν. Και έπρεπε να αποφασίσουμε πώς θα φτάσουμε εκεί. Ξεκινήσαμε βοηθώντας στη σχεδίαση της αρχιτεκτονικής της λύσης στόχου τόσο στην υποδομή όσο και στην αυτοματοποίηση CI/CD. Στη συνέχεια ξεκινήσαμε τη συναρμολόγηση αυτού του μεταφορέα. Χρειαζόμασταν μια υποδομή, ίδια για όλους, όπου θα λειτουργούσαν οι ίδιοι μεταφορείς. Προσφέραμε επιλογές με υπολογισμούς, σκέφτηκε η τράπεζα, μετά αποφάσισε τι θα κατασκευαστεί και με ποια κεφάλαια.
Ακολουθεί η δημιουργία του κυκλώματος - εγκατάσταση λογισμικού, παραμετροποίηση. Ανάπτυξη σεναρίων για ανάπτυξη και διαχείριση υποδομών. Ακολουθεί η μετάβαση στην υποστήριξη μεταφορέων.
Αποφασίσαμε να δοκιμάσουμε τα πάντα στον πιλότο. Είναι ενδιαφέρον ότι κατά τη διάρκεια της πιλοτικής λειτουργίας, μια συγκεκριμένη στοίβα εμφανίστηκε στην τράπεζα για πρώτη φορά. Μεταξύ άλλων, ένας εγχώριος πωλητής μιας από τις λύσεις προσφέρθηκε για την εμβέλεια του πιλότου για γρήγορη εκτόξευση. Η ασφάλεια τον γνώρισε καθώς οδηγούσε και άφησε αξέχαστη εντύπωση. Όταν αποφασίσαμε να αλλάξουμε, ευτυχώς, το στρώμα υποδομής αντικαταστάθηκε με μια λύση Nutanix, η οποία ήταν ήδη στην τράπεζα πριν. Επιπλέον, πριν από αυτό ήταν για VDI, αλλά το χρησιμοποιήσαμε ξανά για υπηρεσίες υποδομής. Σε μικρούς όγκους δεν ταίριαζε στην οικονομία, αλλά σε μεγάλους όγκους έγινε εξαιρετικό περιβάλλον ανάπτυξης και δοκιμών.
Το υπόλοιπο stack είναι λίγο πολύ γνωστό σε όλους. Χρησιμοποιήθηκαν εργαλεία αυτοματισμού στο Ansible και οι ειδικοί ασφαλείας συνεργάστηκαν στενά μαζί τους. Η στοίβα Atlassin χρησιμοποιήθηκε από την τράπεζα πριν από το έργο. Εργαλεία ασφαλείας Fortinet - προτάθηκε από τους ίδιους τους ανθρώπους ασφαλείας. Το πλαίσιο δοκιμής δημιουργήθηκε από την τράπεζα, χωρίς ερωτήσεις. Το σύστημα αποθετηρίου έθεσε ερωτήματα· έπρεπε να το συνηθίσω.
Στους εργολάβους δόθηκε νέα στοίβα. Μας έδωσαν χρόνο να το ξαναγράψουμε για το GitlabCI και να μεταφέρουμε τον Jira στο τραπεζικό τμήμα κ.ο.κ.
βήμα βήμα
Βήμα 1. Αρχικά, χρησιμοποιήσαμε μια λύση από έναν εγχώριο προμηθευτή, το προϊόν συνδέθηκε σε ένα νέο τμήμα δικτύου που δημιουργήθηκε DSO. Η πλατφόρμα επιλέχθηκε για τον χρόνο παράδοσης, την ευελιξία κλιμάκωσης και τη δυνατότητα πλήρους αυτοματισμού. Πραγματοποιήθηκαν δοκιμές:
- Δυνατότητα ευέλικτης και πλήρως αυτοματοποιημένης διαχείρισης της υποδομής της πλατφόρμας virtualization (δίκτυο, υποσύστημα δίσκου, υποσύστημα υπολογιστικών πόρων).
- Αυτοματοποίηση διαχείρισης κύκλου ζωής εικονικής μηχανής (πρότυπο, στιγμιότυπα, αντίγραφα ασφαλείας).
Μετά την εγκατάσταση και τη βασική διαμόρφωση της πλατφόρμας, χρησιμοποιήθηκε ως σημείο τοποθέτησης των υποσυστημάτων του δεύτερου σταδίου (εργαλεία DSO, περιγράμματα ανάπτυξης συστημάτων λιανικής). Δημιουργήθηκαν τα απαραίτητα σύνολα αγωγών - δημιουργία, διαγραφή, τροποποίηση, δημιουργία αντιγράφων ασφαλείας εικονικών μηχανών. Αυτοί οι αγωγοί χρησιμοποιήθηκαν ως το πρώτο στάδιο της διαδικασίας ανάπτυξης.
Το αποτέλεσμα είναι ότι ο παρεχόμενος εξοπλισμός δεν πληροί τις απαιτήσεις της τράπεζας για απόδοση και ανοχή σφαλμάτων. Η DIT της τράπεζας αποφάσισε να δημιουργήσει ένα συγκρότημα βασισμένο στο πακέτο λογισμικού Nutanix.
Στάδιο 2. Πήραμε τη στοίβα που ορίστηκε και γράψαμε αυτοματοποιημένα σενάρια εγκατάστασης και μετα-διαμόρφωσης για όλα τα υποσυστήματα, έτσι ώστε τα πάντα να μεταφέρονται από το πιλότο στο κύκλωμα στόχο όσο το δυνατόν γρηγορότερα. Όλα τα συστήματα αναπτύχθηκαν σε μια διαμόρφωση ανεκτική σε σφάλματα (όπου αυτή η δυνατότητα δεν περιορίζεται από τις πολιτικές αδειοδότησης του προμηθευτή) και συνδέθηκαν με μετρήσεις και υποσυστήματα συλλογής συμβάντων. Η IB ανέλυσε τη συμμόρφωση με τις απαιτήσεις της και έδωσε το πράσινο φως.
Στάδιο 3. Μετάβαση όλων των υποσυστημάτων και των ρυθμίσεών τους στο νέο PAC. Τα σενάρια αυτοματισμού υποδομής γράφτηκαν ξανά και η μετεγκατάσταση των υποσυστημάτων DSO ολοκληρώθηκε σε πλήρως αυτοματοποιημένη λειτουργία. Τα περιγράμματα της ανάπτυξης IP αναδημιουργήθηκαν από τους αγωγούς των ομάδων ανάπτυξης.
Βήμα 4. Αυτοματοποίηση εγκατάστασης λογισμικού εφαρμογών. Αυτά τα καθήκοντα τέθηκαν από τους επικεφαλής των ομάδων των νέων ομάδων.
Βήμα 5. Εκμετάλλευση.
Απομακρυσμένη πρόσβαση
Οι ομάδες ανάπτυξης ζήτησαν μέγιστη ευελιξία στην εργασία με το κύκλωμα και η απαίτηση για απομακρυσμένη πρόσβαση από προσωπικούς φορητούς υπολογιστές τέθηκε στην αρχή του έργου. Η τράπεζα είχε ήδη απομακρυσμένη πρόσβαση, αλλά δεν ήταν κατάλληλη για προγραμματιστές. Το γεγονός είναι ότι το σχήμα χρησιμοποίησε τη σύνδεση του χρήστη σε ένα προστατευμένο VDI. Αυτό ήταν κατάλληλο για όσους χρειάζονταν μόνο αλληλογραφία και πακέτο γραφείου στο χώρο εργασίας τους. Οι προγραμματιστές θα χρειάζονταν βαρείς πελάτες, υψηλής απόδοσης, με πολλούς πόρους. Και φυσικά, έπρεπε να είναι στατικά, αφού η απώλεια της συνεδρίας χρήστη για όσους εργάζονται με VStudio (για παράδειγμα) ή άλλο SDK είναι απαράδεκτη. Η οργάνωση ενός μεγάλου αριθμού παχύ στατικών VDI για όλες τις ομάδες ανάπτυξης αύξησε σημαντικά το κόστος της υπάρχουσας λύσης VDI.
Αποφασίσαμε να εργαστούμε για την απομακρυσμένη πρόσβαση απευθείας στους πόρους του τμήματος ανάπτυξης. Jira, Wiki, Gitlab, Nexus, πάγκοι κατασκευής και δοκιμής, εικονική υποδομή. Οι φρουροί ασφαλείας έχουν ζητήσει να παρέχεται πρόσβαση μόνο με τα ακόλουθα:
- Χρησιμοποιώντας τεχνολογίες που είναι ήδη διαθέσιμες στην τράπεζα.
- Η υποδομή δεν πρέπει να χρησιμοποιεί υπάρχοντες ελεγκτές τομέα που αποθηκεύουν εγγραφές παραγωγικών αντικειμένων λογαριασμού.
- Η πρόσβαση θα πρέπει να περιορίζεται μόνο σε εκείνους τους πόρους που απαιτούνται από μια συγκεκριμένη ομάδα (έτσι ώστε μια ομάδα προϊόντος να μην μπορεί να έχει πρόσβαση στους πόρους μιας άλλης ομάδας).
- Μέγιστος έλεγχος του RBAC στα συστήματα.
Ως αποτέλεσμα, δημιουργήθηκε ένας ξεχωριστός τομέας για αυτό το τμήμα. Αυτός ο τομέας φιλοξενούσε όλους τους πόρους του τμήματος ανάπτυξης, τόσο τα διαπιστευτήρια χρήστη όσο και την υποδομή. Η διαχείριση του κύκλου ζωής των εγγραφών σε αυτόν τον τομέα γίνεται με χρήση του IdM που υπάρχει στην τράπεζα.
Η άμεση απομακρυσμένη πρόσβαση οργανώθηκε με βάση τον υπάρχοντα εξοπλισμό της τράπεζας. Ο έλεγχος πρόσβασης χωρίστηκε σε ομάδες AD, στις οποίες αντιστοιχούσαν κανόνες για τα περιβάλλοντα (μία ομάδα προϊόντων = μία ομάδα κανόνων).
Διαχείριση προτύπων VM
Η ταχύτητα δημιουργίας βρόχου συναρμολόγησης και δοκιμής είναι ένας από τους κύριους KPI που ορίζει ο επικεφαλής της μονάδας ανάπτυξης, επειδή η ταχύτητα προετοιμασίας του περιβάλλοντος επηρεάζει άμεσα τον συνολικό χρόνο εκτέλεσης του αγωγού. Εξετάστηκαν δύο επιλογές για την προετοιμασία βασικών εικόνων VM. Το πρώτο είναι τα ελάχιστα μεγέθη εικόνας, προεπιλογή για όλα τα προϊόντα συστήματος, η μέγιστη συμμόρφωση με τις πολιτικές ρυθμίσεων της τράπεζας. Η δεύτερη είναι μια βασική εικόνα που περιέχει εγκατεστημένο ένα POPPO βαρέως τύπου, ο χρόνος εγκατάστασης του οποίου θα μπορούσε να επηρεάσει σε μεγάλο βαθμό την ταχύτητα εκτέλεσης του αγωγού.
Κατά την ανάπτυξη λήφθηκαν επίσης υπόψη οι απαιτήσεις υποδομής και ασφάλειας - διατήρηση εικόνων ενημερωμένες (patch κ.λπ.), ενσωμάτωση με το SIEM, ρυθμίσεις ασφαλείας σύμφωνα με τα πρότυπα της τράπεζας.
Ως αποτέλεσμα, αποφασίστηκε να χρησιμοποιηθούν ελάχιστες εικόνες προκειμένου να ελαχιστοποιηθεί το κόστος της διατήρησής τους ενημερωμένες. Είναι πολύ πιο εύκολο να ενημερώσετε το βασικό λειτουργικό σύστημα παρά να επιδιορθώσετε κάθε εικόνα για νέες εκδόσεις του POPPO.
Με βάση τα αποτελέσματα, σχηματίστηκε μια λίστα με το ελάχιστο απαιτούμενο σύνολο λειτουργικών συστημάτων, η ενημέρωση των οποίων πραγματοποιείται από την ομάδα λειτουργιών και τα σενάρια από το pipeline είναι εξ ολοκλήρου υπεύθυνα για την ενημέρωση του λογισμικού και, εάν είναι απαραίτητο, αλλάξτε την έκδοση του εγκατεστημένου λογισμικού - απλώς μεταφέρετε την απαιτούμενη ετικέτα στον αγωγό. Ναι, αυτό απαιτεί από την ομάδα προϊόντων devops να έχει πιο σύνθετα σενάρια ανάπτυξης, αλλά μειώνει σημαντικά τον λειτουργικό χρόνο που απαιτείται για την υποστήριξη βασικών εικόνων, οι οποίες διαφορετικά θα μπορούσαν να απαιτήσουν περισσότερες από εκατό βασικές εικόνες VM για τη διατήρηση.
Πρόσβαση στο Internet
Ένα άλλο εμπόδιο με την τραπεζική ασφάλεια ήταν η πρόσβαση σε πόρους του Διαδικτύου από το περιβάλλον ανάπτυξης. Επιπλέον, αυτή η πρόσβαση μπορεί να χωριστεί σε δύο κατηγορίες:
- Πρόσβαση στις υποδομές.
- Πρόσβαση προγραμματιστή.
Η πρόσβαση στην υποδομή οργανώθηκε μέσω διαμεσολάβησης εξωτερικών αποθετηρίων με το Nexus. Δηλαδή δεν παρείχε άμεση πρόσβαση από εικονικές μηχανές. Αυτό κατέστησε δυνατή την επίτευξη συμβιβασμού με την ασφάλεια των πληροφοριών, η οποία ήταν κατηγορηματικά αντίθετη με την παροχή οποιασδήποτε πρόσβασης στον έξω κόσμο από το τμήμα ανάπτυξης.
Οι προγραμματιστές χρειάζονταν πρόσβαση στο Διαδίκτυο για προφανείς λόγους (stackoverflow). Και παρόλο που όλες οι εντολές, όπως αναφέρθηκε παραπάνω, είχαν απομακρυσμένη πρόσβαση στο κύκλωμα, δεν είναι πάντα βολικό όταν δεν μπορείτε να κάνετε ctrl+v από τον χώρο εργασίας του προγραμματιστή στην τράπεζα στο IDE.
Επετεύχθη συμφωνία με το IS ότι αρχικά, στο στάδιο της δοκιμής, η πρόσβαση θα παρέχεται μέσω τραπεζικού αντιπροσώπου βάσει λευκής λίστας. Με την ολοκλήρωση του έργου, η πρόσβαση θα μεταφερθεί στη μαύρη λίστα. Ετοιμάστηκαν τεράστιοι πίνακες πρόσβασης, οι οποίοι έδειχναν τους κύριους πόρους και τα αποθετήρια στα οποία απαιτούνταν πρόσβαση στην αρχή του έργου. Ο συντονισμός αυτών των προσβάσεων πήρε αρκετό χρόνο, γεγονός που επέτρεψε να επιμείνουμε στην ταχύτερη δυνατή μετάβαση σε μαύρες λίστες.
Ευρήματα
Το έργο ολοκληρώθηκε πριν από λίγο λιγότερο από ένα χρόνο. Παραδόξως, όλοι οι εργολάβοι πέρασαν στη νέα στοίβα εγκαίρως και κανείς δεν έφυγε λόγω του νέου αυτοματισμού. Η IB δεν βιάζεται να μοιραστεί θετικά σχόλια, αλλά ούτε παραπονιέται, από την οποία μπορούμε να συμπεράνουμε ότι τους αρέσει. Οι συγκρούσεις έχουν υποχωρήσει επειδή η ασφάλεια των πληροφοριών αισθάνεται και πάλι υπό έλεγχο, αλλά δεν παρεμβαίνει στις διαδικασίες ανάπτυξης. Στις ομάδες δόθηκε μεγαλύτερη ευθύνη και η συνολική στάση απέναντι στην ασφάλεια των πληροφοριών έγινε καλύτερη. Η τράπεζα κατάλαβε ότι η μετάβαση στο DevSecOps ήταν σχεδόν αναπόφευκτη και το έκανε, κατά τη γνώμη μου, με τον πιο ήπιο και σωστό τρόπο.
Alexander Shubin, αρχιτέκτονας συστημάτων.
Πηγή: www.habr.com