Dokumentierte Information, die als Nachweis der Konformität aufbewahrt wird, muss vor unbeabsichtigten Änderungen geschützt werden.
ISO 9001, Kapitel 7.5

Der Schutz dokumentierter Information wird in Kapitel 7.5 der Qualitätsmanagementnorm ISO 9001 (2015) gefordert. Zuverlässiger Schutz ist kein Selbstläufer. Voraussetzung für einen optimalen Schutz ist eine korrekte Konfiguration und Nutzung der IT-Services, in denen dokumentierte Information gespeichert ist. Das klingt einfacher als es tatsächlich ist. Die Personen, die für die QM-Dokumentation verantwortlich sind, brauchen fundiertes Wissen über die Berechtigungskonzepte in den IT-Services. Und für die Umsetzung der Berechtigungskonzepte ist die Unterstützung der Fachleute aus der IT erforderlich. Hilfreich bei diesem Vorhaben ist eine Reduzierung auf die wirklich notwendigen Funktionen in den IT-Services. Trotzdem gilt es, die verfügbaren IT-Services optimal einzusetzen, nichts zu “verbiegen”. Termine gehören in einen Kalender, workflow-basierte Vorgänge werden in JIRA erfasst, bearbeitet und geschlossen. Code und code-nahe Spezifikationen befinden sich ausschließlich in Gitlab.

Die Konsequenz ist, dass eine moderne QM-Dokumentation in der Regel in mehr als einem IT-Service existiert. Bei uns sind es die IT-Services Confluence, JIRA, Gitlab, Gsuite Calendar und Gsuite Drive. Ein zentrales LDAP-Verzeichnis bildet die Grundlage für den Zugriffsschutz in den anderen IT-Services des QM-Systems. Nur im LDAP-Verzeichnis werden Nutzer erfasst. Nur dort befinden sich personenbezogene Daten wie E-Mail-Adresse oder Telefonnummer. Auch die Struktur der Organisation wird im LDAP-Verzeichnis abgebildet. Jeder Beschäftigte ist beispielsweise einem Standort zugeordnet.

Konsistenter Schutz der dokumentierten Information wird durch die Integration des LDAP-Verzeichnisses in die anderen IT-Services erreicht. Die Befugnisse der Beschäftigten des Unternehmens für den Zugriff auf die dokumentierte Information in den IT-Services wird durch Berechtigungen geregelt, die zu Rollen gebündelt werden. Diese Rollen unterscheiden sich in den IT-Services.

Das Berechtigungskonzept von Confluence erlaubt die Vergabe eine Reihe von bereichsbezogenen Berechtigungen an Gruppen oder Nutzer in einem Bereich. Ein wichtiges Merkmal der Rechteverwaltung ist die additive Vergabe von Berechtigungen. Einem Nutzer von Confluence können Berechtigungen erteilt, aber nicht explizit entzogen werden. Obwohl Confluence kein Rollenkonzept hat, verwenden wir Rollen als Regeln für bestimmte Zusammenstellungen von Berechtigungen in einem Bereich. Für die Zuordnung der Personen zur Rolle verwenden wir ausschließlich LDAP-Gruppen.

Ein Systemadministrator hat alle Rechte, die man in Confluence vergeben kann. Seine Aufgaben beschränkten sich aber auf Tätigkeiten, die für den Betrieb des IT-Services notwendig sind.

Der Gärtner ist der Administrator in einem Confluence-Bereiches. Er hat alle Rechte, die man in Confluence für die Bearbeitung von Seiten vergeben kann. Er ist Experte im Zusammenhang mit Dokumentation. Seine Aufgaben sind die Formulierung und Durchsetzung von Dokumentationsrichtlinien (wie die Programmierrichtlinien für Entwickler). Er sorgt für die Einhaltung der abgestimmten Regeln für die Inhalte in den Seiten.

In den Bereichen der QM-Dokumentation sind dies ausschließlich die Geschäftsführung und die QM-Beauftragten. In allen anderen Bereichen haben die Projektverantwortlichen diese Rolle.

Der Autor ist ein Bearbeiter in einem Confluence-Bereich. Er darf Seiten, Beiträge und Anhänge anlegen und löschen (nicht nur eigene) und kann Kommentare in den Seiten erstellen und löschen (nicht nur eigene).

In den Bereichen der QM-Dokumentation sind dies ausschließlich die Geschäftsführung und die QM-Beauftragten. In allen anderen Bereichen haben die Projektmitarbeiter diese Rolle.

Diese Rolle hat in der Regel jeder Beschäftigte des Unternehmens. Der Nutzer darf Seiten lesen und kann Kommentare in den Seiten erstellen und löschen (nicht nur eigene).

Ausnahmen gibt es, wenn ein Kunde einen Beschränkung der Sichtbarkeit der Daten fordert, die wir in seinem Auftrag verarbeiten.

Das Berechtigungskonzept von JIRA erlaubt die Vergabe einer Reihe von bereichsbezogenen Berechtigungen an Gruppen oder Nutzer. Anders als bei Confluence unterstützt JIRA aber auch ein Rollenkonzept. Die Zusammenstellung von Berechtigungen zu einer Rolle befindet sich ein einem Schema. Wir nutzen vorgefertigte, an unsere Prozesse angepasste Schemas. Sie lassen uns ausreichend Spielraum für individuelle Anpassungen in einem Projekt. Für die Zuordnung der Personen zur Rolle verwenden wir ausschließlich LDAP-Gruppen.

Ein Systemadministrator hat alle Rechte, die man in JIRA vergeben kann. Seine Aufgaben beschränkten sich aber auf Tätigkeiten, die für den Betrieb des IT-Services notwendig sind.

Die Rolle Administrator hat alle Berechtigungen, die man für die Verwaltung eines JIRA-Projektes vergeben kann. Der Nutzer darf Vorgänge bearbeiten (auch löschen) und kommentieren.

Im Projekt der QM-Dokumentation sind dies ausschließlich die Geschäftsführung und die QM-Beauftragten. In allen anderen Projekten haben die Projektverantwortlichen diese Rolle.

Die Rolle Developer hat alle Berechtigungen, die man für die Verwendung des JIRA-Projektes benötigt. Der Nutzer darf Vorgänge bearbeiten (nicht löschen) und kommentieren,

Im Projekt der QM-Dokumentation in JIRA sind dies ausschließlich die Geschäftsführung und die QM-Beauftragten. In allen anderen Projekten haben die Projektmitglieder diese Rolle.

Diese Rolle hat in der Regel jeder Beschäftigte des Unternehmens. Der Nutzer darf Seiten lesen und kann Kommentare in den Seiten erstellen und löschen (nicht nur eigene).

Ausnahmen gibt es, wenn ein Kunde einen Beschränkung der Sichtbarkeit der Daten fordert, die wir in seinem Auftrag verarbeiten.

Gitlab ist das wichtigste IT-Service für unsere Entwicklungsprojekte. Dort liegen alle Arbeitsergebnisse versioniert vor. Das Berechtigungskonzept von Gitlab basiert auf einer Grundstruktur bestehend aus Gruppen, Untergruppen und Projekten (=Git-Repository). Untergruppen sind optional und werden nur in sehr großen Entwicklungsprojekten verwendet. Die Rollen werden von Gitlab vorgegeben.

Ein Systemadministrator hat alle Rechte, die man in Gitlab vergeben kann. Seine Aufgaben beschränkten sich aber auf Tätigkeiten, die für den Betrieb des IT-Services notwendig sind.

Die Rolle Owner hat umfassende Rechte für alle Ressourcen (code, page, issue) in Gitlab. Ausgeschlossen ist das Löschen oder Verändern geschützter Ressourcen (protected branches).

Die Rolle Master hat alle Berechtigungen, die man für die Verwaltung der Ressourcen (code, page, issue) in Gitlab benötigt. Ausgeschlossen ist das endgültige Löschen oder Verschieben von Ressourcen und die Veränderung der Sichtbarkeit von Projekten.

In Entwicklungsprojekten haben die Projektverantwortlichen diese Rolle.

Die Rolle Developer hat alle Berechtigungen, die man für die Verwendung der Ressourcen (code, page, issue) in Gitlab benötigt.

In Entwicklungsprojekten haben die Projektmitarbeiter diese Rolle.

Diese Rolle hat in der Regel jeder Beschäftigte des Unternehmens. Der Nutzer darf Ressourcen (code, page, issue) in Gitlab lesen und kommentieren.

Ausnahmen gibt es, wenn ein Kunde einen Beschränkung der Sichtbarkeit der Daten fordert, die wir in seinem Auftrag verarbeiten.

Alle Gsuite-Anwendungen werden mithilfe von Google Cloud Directory Sync mit dem LDAP-Verzeichnis synchronisiert. Dadurch können die LDAP-Gruppen auch für die Freigabe von Kalendern oder Dateien verwendet werden.

Ein Gsuite Calendar kann freigegeben werden. Der Besitzer des Kalenders entscheidet, wie berechtigte Personen Termine in diesem Kalender nutzen können, ob sie Termine ändern, Termindetails oder nur die Verfügbarkeit ohne weitere Details sehen. Es gibt eine Reihe von Kalendern, die gemeinsam genutzt werden. Über eine LDAP-Gruppe ist beispielsweise geregelt, dass alle Beschäftigten alle Termine im Schulungsplan sehen können. Die Bearbeitung des Schulungsplans ist aber beschränkt auf die Assistenz der Geschäftsführung und die QM-Beauftragten.

In Gsuite Drive bleibt jede Datei vertraulich, bis sie vom Besitzer für andere Personen zum Herunterladen, Ansehen, Kommentieren oder Bearbeiten freigegeben wird. Außerdem gibt es die Möglichkeit, ein Ablaufdatum für die Freigabe festzulegen. Neben der Freigabe von einzelnen Dateien ist auch die Freigabe ganzer Ordner möglich. Über eine LDAP-Gruppe ist beispielsweise ein Ordner mit Vorlagen für alle Beschäftigten freigegeben. Die Vorlagen können jedoch nur durch die Assistenz der Geschäftsführung und die QM-Beauftragten geändert werden.

Die Quintessenz beim Schutz dokumentierter Information lässt sich auf zwei wesentliche Punkte reduzieren. Zum Einen ist es wichtig, dokumentierte Information nur dort aufzubewahren, wo sie erwartet wird und wo, also in welchem IT-Service, für ihren Schutz Sorge getragen wird. Zum Anderen ist es wichtig, die Befugnisse für den Zugriff auf dokumentierte Information auf Basis eines zentral gepflegten und dokumentierten LDAP-Verzeichnisses zu regeln. Damit ist das LDAP-Verzeichnis selbst eine sehr wichtige dokumentierte Information.