Der Herbst ist auf dem Hof gekommen, die Techno-Utopie tobt. Die Technologie rast voran. Wir haben einen Computer in der Tasche, dessen Rechenleistung hunderte Millionen Mal höher ist als die Leistung der Computer, die die Flüge zum Mond gesteuert haben. Mit Hilfe von Youtube VR können wir mit Quallen und Walen im Meer schwimmen, und Roboter erforschen seit langem den leblosen Horizont kalter Planeten.
Gleichzeitig teilten sich Ingenieure und IT-Dienstleistungsspezialisten, Entwickler und ihre unzähligen Kollegen in zwei Lager auf: diejenigen, die neue Lösungen entwickeln (Software, Strategien, Informationssysteme), und diejenigen, die sie verstehen.
Einbruch in das Ökosystem der Anwendungsentwicklung und die Methode zur Verwendung von Microservices. Bis vor kurzem war es eine unverständliche, vor neugierigen Blicken geschlossene, grundlegend neue Technik. Doch schon nach wenigen Jahren setzen große und mittlere Unternehmen diesen Ansatz bereits in ihrer eigenen Entwicklungsumgebung sicher ein. Wie ist er? Wir werden nicht die "klassischen" Definitionen verwenden, sondern es Ihnen in unseren eigenen Worten sagen.
Microservice-Architektur. Container
Microservices ist eine Methode, bei der die Funktionalität eines Systems in viele kleine Dienste unterteilt ist und jeder von ihnen eine Aufgabe aus einer komplexen Funktionalität ausführt. Einer fungiert als Webserver, der andere als Datenbank, der dritte ist mit etwas anderem beschäftigt usw. Zwischen all diesen Mikrodiensten wird eine Netzwerkinteraktion hergestellt und die erforderlichen Ressourcen zugewiesen. Ein lustiges und nicht weniger offensichtliches Beispiel für ein solches Konzept ist das System der Bestellung und Ausgabe von Mittagessen in Fast-Food-Restaurants.
Der Kunde (Benutzer) erstellt eine neue Bestellung über das Terminal oder die Rezeption (Webserver), überträgt Daten über die Anzahl der Cheeseburger, Kartoffeln und die Art der Limonade in seinem Mittagessen (füllt die Datenbank), leistet eine Zahlung, wonach die Daten an die Küche übertragen werden, wo Teil Mitarbeiter braten Kartoffeln (Kochservice), der andere Teil verteilt Lebensmittel und gießt Soda ein (Abholservice). Dann wird die abgeholte Bestellung an den ausstellenden Schalter (ausstellender Service) weitergeleitet, wo der Kunde einen Scheck mit der Bestellnummer vorlegt (es gibt sogar eine Bestätigung!), Und er wird zu Mittag gegessen. In diesem Fall ist jede der Prozesseinheiten mit einer Aufgabe beschäftigt und arbeitet jedoch schnell und reibungslos gemäß einem festgelegten Algorithmus. Sie müssen zugeben, dass es dumm wäre zu erwarten, dass Sie an der Rezeption schneller mit Soda beladen werden als in der Küche, oder dass der Mitarbeiter, der die Pastetchen brät, die Zahlung für Ihre Bestellung akzeptieren kann. Wenn das System jedoch ordnungsgemäß debuggt und die Prozesse wie erwartet ablaufen, funktioniert alles sehr schnell und effizient.
In Bezug auf die Microservice-Architektur ist ein wichtiger Punkt zu beachten - die Ausführungsumgebung. Eine weit verbreitete Option sind heute Container (hi, Docker). Ein Merkmal von Containern ist die Idee, die gesamte erforderliche Umgebung in sie zu packen, beginnend mit einem einfachen Betriebssystem-Image, installierten Paketen, geladenen Frameworks und Bibliotheken und endend mit der Anwendung selbst. Wie ist das nützlich? Zumindest die Tatsache, dass der Entwickler die Erklärung „Alles funktioniert auf meinem Computer“ nicht ablehnen kann, wenn Sie mit der Meldung zu ihm kommen, dass die Anwendung nicht funktioniert.
Mit Containern können Sie Anwendungen erstellen, diese zusammen mit der gesamten Umgebung in ein fertiges Image eines leichten Systems packen und sich nicht mehr um die Probleme kümmern, die mit der Arbeit in verschiedenen Umgebungen verbunden sind. Müssen Sie die Anwendung auf einem anderen Server bereitstellen? Wir haben damit ein Arbeitsbild im Container gestartet - und alles funktioniert.
In einem Informationssystem, das aus Containern besteht, müssen Sie sich nicht mehr um Softwareversionen in der Umgebung kümmern, in der die Anwendungen ausgeführt werden. Wenn kontinuierliche Bereitstellungsprozesse implementiert sind, müssen Sie auch Code usw. bereitstellen. Die Idee eines Containers impliziert, dass die Entwicklung selbst erfolgt Die Anwendung wird in derselben Containerumgebung ausgeführt. Da der Microservice geschlossen ist, spielt es keine Rolle, für welches Betriebssystem oder mit welchen installierten Paketen er funktioniert. Die Anwendung funktioniert, weil sie für eine Containerumgebung erstellt wurde, die sich unabhängig vom System, das den Container umgibt, nicht ändert. Sie müssen nicht mehr die gesamte erforderliche Software für eine lange und langwierige Zeit installieren, um Verbindungen, Abhängigkeiten und Pakete herzustellen. Sie müssen Anwendungen nicht manuell migrieren, wenn Sie zwischen Entwicklungs- und Bereitstellungsumgebungen wechseln oder wenn die Kapazität des Rechenzentrums zunimmt. Es ist eine neue Abstraktionsebene entstanden, die ihren Platz zwischen der endgültigen Software mit ihren Benutzern und der Host-Umgebung (virtuell oder Bare-Metal) einnimmt, auf der all dies funktioniert. Dieser Ansatz gewinnt aufgrund seiner Zweckmäßigkeit stetig an Dynamik und wird sich nicht verlangsamen.
Viele große Unternehmen bemühen sich, die besten Techniken zur Verbesserung der Geschäftseffizienz, ihrer Entwicklung, Skalierbarkeit und Transformation anzuwenden, auch im Zusammenhang mit Informationssystemen. Schließlich ist es genau für große, digital orientierte Unternehmen gedacht, die in erster Linie an Lösungen interessiert sind, die auf Flexibilität, Skalierbarkeit und Mobilität abzielen, da es bei einem Branchenwechsel anfällig für Schwierigkeiten wird, die mit der Expansion, Anpassung an einen sich ändernden Markt usw. verbunden sind. nicht unbedingt über IT-Unternehmen. Im Zusammenhang mit CI / CD-Themen und ihrer Sicherheit wenden sich Unternehmen des öffentlichen Sektors, wichtige Finanzmarktakteure wie Banken und sogar Logistikmonopolisten an unsere Organisation. In allen Fällen verbindet sie eines - die Verwendung von Containern in der einen oder anderen Form bei der Entwicklung von Anwendungen, Diensten usw.
Big Business wird oft mit Haien verglichen. In diesem Fall ist es schwieriger, einen geeigneteren Vergleich zu finden. Haben Sie gesehen, wie Haie Fischschwärme jagen? Haben Sie bemerkt, wie viel wendiger kleine Fische sind, selbst wenn sie sich in einer großen Herde befinden? Wer reagiert schärfer, wendiger und schneller - ein Hai oder eine kleine Makrele? Gleiches gilt für Unternehmen auf dem gesamten Markt. Natürlich berücksichtigen wir Microsoft oder Apple in jenen Tagen, in denen sie in die Garage passen, nicht. Dies sind Einzelfälle. Statistisch gesehen ist das Bild jedoch so, dass große Unternehmen Trends diktieren und Richtungen festlegen können. Für kleine Unternehmen ist es jedoch einfacher, sich schnell anzupassen und anzupassen. Und große Unternehmen versuchen auch, Mobilität und Flexibilität auf erschwingliche Weise zu erhöhen.
Aber wie sie sagen, gibt es eine Nuance ... Große Unternehmen sind in der Tat kein Monolith. Sie bestehen aus vielen Abteilungen mit vielen Abteilungen, Teams, Einheiten und einer noch größeren Anzahl von Mitarbeitern. Insbesondere im Kontext von Informationssystemen und Entwicklung können sich die Aktionsbereiche von Teams überschneiden. Und genau an diesem Punkt entstehen diese Konfliktsituationen zwischen IS-Diensten und Entwicklern. Das heißt, es stellt sich heraus, dass weder große noch mittlere Unternehmen gegen solche Schwierigkeiten immun sind.
Früher oder später, wenn Container verwendet werden, wird die Organisation eine Frage haben. Dies kann zu Beginn ihrer Verwendung oder nach einem Zwischenfall geschehen, wodurch dem Unternehmen Verluste entstehen.
Wie können Prozesse sicher gemacht werden?
In der einen oder anderen Form hören wir diese Frage oft und denken gemeinsam mit dem Kunden über die Lösung nach und suchen nach geeigneten Wegen. In der Regel besteht eine Organisation, insbesondere eine große Organisation, die CI / CD implementiert hat, aus intelligenten und erfahrenen Spezialisten, einschließlich Fachleuten für Informationssicherheit. Diese Leute verstehen, warum sie Microservices verwenden müssen, welche Probleme dadurch gelöst werden und welche neuen Schwierigkeiten auftreten werden. Daher ergreifen sie Maßnahmen für die erfolgreiche Implementierung und Nutzung von Technologie: Vorbereitung der Infrastruktur, Durchführung von Audits, Bereitstellung von Systemen, Erstellung von Prozessen und Koordinierung interner Vorschriften.
Es ist jedoch nicht immer möglich, alles vorherzusehen, alles im Auge zu behalten und alles zu überwachen. So können Sie beispielsweise verstehen, ob die Version des SQL-Servers im Container eine kritische Sicherheitsanfälligkeit enthält. Manuell? Sagen wir mal. Und wenn es Dutzende von Containern gibt? Und Hunderte?
Wie kann ein Informationssicherheitsspezialist sicherstellen, dass das Basis-Betriebssystem-Image im Container mit der Anwendung keinen versteckten Exploit enthält? Manuell prüfen? Und was genau zu überprüfen, wo zu suchen? Auf allen Dutzenden und Hunderten von Containern? Und wo bekommt man so viel Zeit und Ressourcen?
Mit der Entwicklung und Verbreitung von CI / CD wurde das Thema Sicherheit im Entwicklungszyklus immer akuter. Schließlich müssen Sie sicherstellen, dass die Qualität der Bilder zumindest auf einem akzeptablen Niveau liegt. Sie müssen die Schwachstellen von Software und Paketen sowie den Status der Arbeitscontainer kennen, ob verdächtige oder offensichtlich illegitime Aktionen in ihnen stattfinden. Und wenn wir speziell über den Entwicklungszyklus sprechen, lohnt es sich, Tools zur Gewährleistung der Sicherheit im Entwicklungsprozess selbst, in der Pipeline und nicht nur in Containern zu haben. Außerdem benötigen Sie die Kontrolle über Geheimnisse, die Prüfung von Registern, die Kontrolle über die Netzwerkinteraktion usw. Und hier kommen wir zum Hauptthema.
Warum wird Sicherheit benötigt und welche Funktionen bietet CI / CD?
Im Wesentlichen handelt es sich um eine Reihe von Methoden zur Gewährleistung der Sicherheit im und um den Entwicklungszyklus. Das heißt, es ist die Verwendung spezieller Software, die Entwicklung von Methoden und Vorschriften und sogar die Vorbereitung von Teams (Teams sind der Schlüssel zu allem!), Um die Sicherheit zu gewährleisten. Und ein wichtiger Punkt: die gerechtfertigte Einführung all dieser Sicherheit in die Entwicklung und nicht das Abschneiden von der Schulter!
Hier werden wir näher darauf eingehen. Der übliche Ansatz zur IT-Sicherheit im Allgemeinen und zur Entwicklung im Besonderen, der in den Sinn kommt, basiert auf den Prinzipien „Verbieten / Einschränken / Verhindern“. Das mit Abstand sicherste Informationssystem funktioniert überhaupt nicht. Aber es muss funktionieren! Und Menschen, die dieses System verwenden, sollten auch in der Lage sein, damit zu arbeiten.
Es liegt ein oben genannter Interessenkonflikt vor. Der Informationssicherheitsspezialist versucht, die Umgebung sicher zu machen und die vollständige Kontrolle darüber zu haben, der Entwickler möchte das Produkt herstellen und möchte, dass es schnell und bequem funktioniert, und der IT-Ingenieur macht die Umgebung funktionsfähig, fehlertolerant und strebt gemeinsam mit dem Entwickler nach Automatisierung.
Beim Schutz in CI / CD geht es nicht um Software oder Vorschriften, sondern um Teamarbeit und die Einbettung des Sicherheitskonzepts in den Entwicklungsstrom. Dieser Ansatz zielt darauf ab, alle Teilnehmer gleichermaßen in den Prozess einzubeziehen, klare Verantwortungsbereiche zu verteilen, zu automatisieren, zu überwachen und transparent zu berichten. Und am wichtigsten ist, dass die Sicherheit innerhalb des Anwendungsentwicklungsprozesses so implementiert wird, dass sie in einem frühen Stadium angezeigt wird und keine zusätzlichen rechnerischen und personellen Ressourcen erforderlich sind.
Schauen wir uns ein Beispiel an. Angenommen, eines der Entwicklungsteams erstellt eine Anwendung. Dies geschieht auf einem Containermedium unter Aufsicht von Spezialisten für Informationssicherheit, während Infrastrukturmanager den Zustand dieser Umgebung erhalten. Am Ende der Entwicklung erscheint eine vorgefertigte Anwendung, die in die Produktion fließt und dort zu arbeiten beginnt. Die Kunden nutzen sie - alle sind glücklich. Nach einiger Zeit wird jedoch eine schwerwiegende Sicherheitsanfälligkeit im Container mit der Anwendung entdeckt. Ein Informationssicherheitsspezialist registriert diese Sicherheitsanfälligkeit und gibt sie zur Beseitigung an die Entwickler weiter. Diese beheben sie wiederum mit einem Patch. Anschließend müssen Sie die Abhängigkeiten neu schreiben und einige Pakete aktualisieren. Dann wird die nächste Version der Anwendung ausgerollt.
Die Zeit, die IS-Spezialisten für die Lokalisierung des Problems aufgewendet haben, die Zeit des Entwicklungsteams für die Behebung des Problems und eine kurze Zeit, in der der IS-Dienst ein zweites Audit durchführt und den Fall abschließt. Aber was wäre, wenn wir ein Tool verwenden und es in der Entwicklungsphase implementieren könnten? Was wäre, wenn unsere Anwendung nicht auf das Produkt übertragen würde und für das angegebene Sicherheitsniveau ungeeignet wäre? Und jeder am Prozess beteiligte Spezialist konnte sehen, welche Bedrohungen in seinem Verantwortungsbereich festgestellt wurden? Was aber, wenn der gesamte Prozess auch automatisiert würde, beginnend mit der Erkennung und endend mit Vorfällen im Bug-Tracker?
Dies ist das Ziel der Organisation einer sicheren Entwicklung und Implementierung. Dass es nicht nur sicher, sondern auch bequem war. Die Einführung neuer Prozesse oder der Einsatz zusätzlicher Tools sollte die Aktivitäten vereinfachen und nicht umgekehrt.
Es gibt Tools und Techniken, mit denen Sie den Status der erforderlichen Systemelemente und Phasen des Entwicklungsprozesses überwachen und allen Beteiligten helfen können, sich über Ereignisse in ihrem Verantwortungsbereich auf dem Laufenden zu halten. Der Schwerpunkt liegt hier nicht auf spezialisierter Software, sondern auf der Interaktion von Menschen mit dem System und untereinander. Ist es für den Entwickler bequemer, die Anwendung direkt im Arbeitscontainer zu reparieren und zu testen? Nun, lass ihn das reparieren. Gleichzeitig möchte der IS-Dienst sicherstellen, dass sich keine illegitimen Aktionen im Container befinden. Kein Problem, sie wird Bescheid wissen. Die Aufgabe wurde abgeschlossen und niemand störte jemanden in den Prozess. Effizienz und Rationalität! Dies ist möglich, wenn Sie die erforderlichen Tools für die Informationssicherheit an den richtigen Stellen in der Entwicklungsumgebung anwenden und die Regeln für die Interaktion zwischen Diensten und Teams überarbeiten. Und dann soll es keine Utopie geben, aber Sie müssen zustimmen, dass das Leben mit beiden etwas einfacher wird.
Warum die Hände der Entwickler binden und den IB-Service damit laden, wenn Sie Prozesse so erstellen können, dass der Entwickler tut, was er kann (selbstlos, erschöpft von der Perfektion seines Codes), und der IB-Spezialist diesen Prozess kontrollierte (nicht störte, sondern nur dieses Vergnügen teilte) von der Seite).
Containersicherheit. Lohnt es sich?
Wir werden von Kunden in völlig unterschiedlichen Phasen und mit unterschiedlicher Erfahrung in CI / CD kontaktiert. Es gab große Organisationen, die in der Produktion einer unentdeckten Hintertür im Container gegenüberstanden, durch die Zugang zu wichtigen Daten erhalten und die Daten gestohlen wurden. Infolgedessen wurde deutlich, dass es in einem überwucherten, umständlichen System zu schwierig ist, potenzielle Bedrohungen zu verfolgen und präventiv zu neutralisieren.
Es gab auch kleine Unternehmen, die kürzlich CI / CD in der Entwicklung verwendeten. Nach der Analyse der Prozesse in den Pipelines kamen ihre Experten zu dem Schluss, dass die verfügbaren Tools für die Informationssicherheit ein unzureichendes Prozessvolumen abdecken und es gefährliche Orte gibt, an denen früher oder später ein Angriff stattfinden kann. Vielleicht nicht jetzt, vielleicht später oder vielleicht gar nicht. In diesem Fall ist der Fehlerpreis jedoch hoch.
Unsere Kunden teilen Bedenken, die in den meisten Fällen darauf zurückzuführen sind, dass Entwickler, Ingenieure und alle am Prozess Beteiligten die Hände schlagen, wenn sie versuchen, das Zeitlimit zu überschreiten. Aber manchmal ist es auf diese Weise einfacher und schneller, und in einigen Fällen ist es im Allgemeinen anders. Und dann muss der IS-Dienst Verstöße mit den Fingern betrachten. Aber wir sind für ein anderes Konzept. Warum gegen Vorschriften verstoßen oder diese ignorieren, die mit solchen Schmerzen geschrieben wurden? Warum sollten sich Dienste gegenseitig stören, um ihre Aufgaben zu erfüllen? In der Zusammenarbeit mit dem Kunden beginnen wir mit der Kommunikation mit seinen Problemen. Sie sind immer da.
"Suchen Sie nicht nach einem Kunden, finden Sie ein Problem und bieten Sie eine Lösung an - der Kunde wird selbst erscheinen."
Nachdem wir dem Kunden in der Regel zugehört haben, verstehen wir, mit welchen Problemen er konfrontiert ist. Dies können Schwierigkeiten bei der Teaminteraktion, erfolglose Entscheidungen bei der Gestaltung der "Pipeline", Mangel an Computer- und Personalressourcen und vieles mehr sein. Bei unserem Ansatz zur Implementierung von Sicherheitsverbesserungen in der Infrastruktur des Kunden orientieren wir uns an dem Wunsch, zur Lösung seiner Probleme beizutragen und dies so zu erreichen, dass die Wahrscheinlichkeit neuer Probleme minimiert wird. So wird eine Grundlage für die Zukunft geschaffen, es spielt keine Rolle, wer das geschaffene System warten wird, viele Probleme sollten zu Beginn vorausgesehen und gelöst werden. In der Anfangsphase erweisen sich Entscheidungen in den meisten Fällen als billiger als bei hoher Arbeitsbelastung in der Tiefproduktion.
Auf dieser Grundlage empfehlen wir, mit einem Audit zu beginnen, das nicht nur den Status der Informationssysteme und ihrer Elemente umfasst, sondern auch ein Verständnis der Prozesskomponente zwischen den Entwicklungsteams, des Ansatzes der Informationssicherheitsdienste usw. Vergessen Sie nicht, dass Menschen sowohl in Bezug auf Bedrohungen als auch für die Ergebnisse der Funktionsweise des Systems der wichtigste Faktor sind. Ein Audit ist eine notwendige Phase, aufgrund derer wichtige Systemfehler oder Fehlkalkulationen bei Interaktionen, die zusammen mit dem Kunden, den wir zu lösen oder zu verarbeiten versuchen, aufgedeckt werden können. Es ist wichtig zu verstehen, dass das Ziel nicht darin besteht, viele Softwarelösungen und Produkte zu stapeln und die von ihnen entdeckten Schwachstellen nicht auszuschließen. Im Gegenteil, es ist wahrscheinlich, dass der Kauf teurer Softwareprodukte überhaupt nicht erforderlich ist. Häufig kann der Prozess der Erhöhung der Sicherheit in einer CI / CD-Umgebung mithilfe vorhandener Sicherheitsfunktionen der Organisation erreicht werden, die sowohl in die Containerisierungsumgebung (z. B. im Orchestrator) als auch von Drittanbietern integriert sind. Das Wichtigste ist weniger ihre Quantität oder Qualität als vielmehr die richtige Anwendung.
Basierend auf den Ergebnissen des Audits wird es möglich, einen Arbeitsplan, einen Fahrplan mit klaren Zwischenzielen und einem verständlichen Endziel zu erstellen. Nun, alles weitere ist eine technische Angelegenheit. Die richtige Planung in jedem Unternehmen ist ein wesentlicher Bestandteil des erfolgreichen Abschlusses.
Es ist wichtig, sich nicht zu sehr mitreißen zu lassen und nicht zu vergessen, warum alles getan wird. Niemand hat die Aufgabe, ein wahnsinnig geschütztes System zu erstellen, in dem kein Container startet, wenn darin Bedrohungen erkannt werden, oder keine Anwendung in der Produktion bereitgestellt wird, wenn Abweichungen vom geschützten Modell vorliegen. Es sei daran erinnert, dass die Einführung oder Einführung von Schutzwerkzeugen nicht nur zur Erhöhung der Sicherheit, sondern auch zur Vereinfachung dienen sollte.
Einer dieser Fälle betraf beispielsweise die Einführung von Containerschutzsoftware und Orchestrierungsumgebungen. Es scheint, als hätten sie alle Schwachstellen implementiert, konfiguriert, gescannt, erkannt - und dann den langen Prozess der Beseitigung. Bei diesem Ansatz treten jedoch Probleme auf, die zu Beginn erörtert wurden. Der Informationssicherheitsdienst verfügt über ein Tool, mit dem Sie viele Aktivitäten in einer Orchestrierungsumgebung blockieren können. Bei unsachgemäßer Verwendung kann dies mehr schaden als nützen. Den Entwicklern sind die Hände gebunden, weil der Informationssicherheitsdienst ihre Fähigkeiten einschränkt. Zum Beispiel ist es nicht mehr möglich, etwas im Container „heiß“ zu reparieren, und wenn im Image eine Paketanfälligkeit erkannt wird, ist der Entwickler in die Regulierungsbürokratie involviert. Infolgedessen verzögert sich die Lösung eines Problems, das tagsüber behoben werden könnte, auf unbestimmte Zeit.
Um solche Situationen zu vermeiden, empfehlen wir, die Prozesse so anzuordnen, dass der Informationssicherheitsdienst nicht wie so oft vom Entwicklungsprozess entfernt ist, sondern daran teilnimmt. Es dauert sicherlich einige Zeit, aber es lohnt sich, den Prozess zu debuggen, und das Leben wird wirklich einfacher. Mit IS-Tools können Sie beispielsweise Bedrohungen überwachen, die sich bereits in der Montagephase innerhalb der CI / CD-Pipeline befinden, und der IS-Dienst kann dies registrieren. Gleichzeitig können Informationen über Bedrohungen in jeder Phase der Versammlung automatisch an das Team oder den Spezialisten übertragen werden, die für eine bestimmte Phase verantwortlich sind, und diese wiederum ergreifen die erforderlichen Maßnahmen, um die Bedrohung zu beseitigen. Und das alles nicht unter der Aufsicht einer Peitsche, sondern unter der Aufsicht des IS-Dienstes.Letztendlich kann der Zeitaufwand für die Behebung von Schwachstellen erheblich reduziert werden, und damit auch die Geschäftskosten, beispielsweise finanzielle oder Reputationskosten.Mit den ersten Daten bemühen wir uns, einen Ansatz zur Organisation und Verbesserung des Sicherheitsniveaus der Containerentwicklung zu entwickeln, der sich nicht nur auf das Design und die Implementierung spezifischer Lösungen konzentriert, sondern auch auf die Humanressourcen. Jeder Teilnehmer am Prozess erfüllt seine Rolle und je bequemer es ist, desto weniger unnötige Eingriffe, desto besser ist sein Endergebnis. Und wenn Sie ein Gleichgewicht zwischen der Bequemlichkeit aller Beteiligten finden, erhalten Sie ein sehr effektives Team. In Zukunft sind natürlich verschiedene Optimierungen, Anwendungen oder Erhöhungen der Automatisierung einiger Prozesse, die Delegation von Aufgaben usw. möglich. Die Hauptidee bleibt jedoch unverändert - eine Überarbeitung der Sicherheit als solche. Aufgabentrennung, Überwachung statt sinnloser Verbote und Beteiligung aller in ihrem Verantwortungsbereich.Und natürlich Bequemlichkeit! Sicherheit kann bequem sein.