Vorschläge zur Sicherung der Qualität in agilen .NET Softwareprojekten.
Version 1.2.8
Feedback an mail@jannis-kuehn-consulting.de
Siehe auch: Agile Project Review Guide
Anmerkungen, Vorschläge und Hinweise sind ausdrücklich erwünscht!
Inhaltsverzeichnis
| 1. | Organisation |
| 2. | Entwicklung |
| 2.1. | Versionskontrolle |
| 2.2. | Fehlerbehandlung |
| 2.3. | Tests |
| 2.4. | Abhängigkeiten |
| 3. | Daten |
| 3.1. | Datenbanken |
| 4. | Dokumentation |
| 4.1. | Logging |
| 5. | Bereitstellung |
| 5.1. | Build |
| 5.2. | Deployment |
| 6. | Betrieb |
| 6.1. | Monitoring |
| 7. | Literatur |
C001 Anforderungen gelten erst als "Done", wenn sie an den Anwender ausgeliefert und nachweislich in Benutzung sind.
Beispiel: Erst wenn Telemetriedaten zur Nutzung des Features eingetroffen sind und dokumentiert wurden, gilt die Anforderung als "Done".
Tags: Disziplin Organisatorisch Qualität
C002 Dem Anwender wird eine Möglichkeit geboten, Feedback unkompliziert und schnell über die Benutzeroberfläche mitzuteilen.
Beispiel: Anonyme Eingabe von Anwenderfeedback jederzeit möglich (z.B. Freitextfeld mit verschiedenen Smileys zum auswählen), Feedbackkontext (z.B. Applikationsmodul) für den Anwender transparent.
C129 Dem Anwender wird eine Möglichkeit geboten, Datenschutz- und Sicherheitsvorfälle unkompliziert und schnell über die Benutzeroberfläche zu melden.
Beispiel: Anonyme Meldung zu Datenschutz- und Sicherheitsvorfällen jederzeit möglich (z.B. Freitextfeld).
Tags: Kundenorientierung Nachhaltigkeit Organisatorisch Security
C003 Neue Funktionen können für definierte Anwendergruppen separat freigeschaltet werden, um Testphasen in Produktion zu ermöglichen.
Beispiel: Feature-Switches auf Ebene von Anwendergruppen.
Tags: Organisatorisch Stabilität
C004 Die Releaseplanung ist nach außen transparent.
Beispiel: Kunden können sich jederzeit über bereitgestellte und geplante Versionen informieren.
Tags: Kundenorientierung Nachhaltigkeit Nachvollziehbarkeit Organisatorisch
C005 Ein Feedbackprozess ermöglicht dem Kunden Einflussnahme auf die Releaseplanung.
Beispiel: Einbindung des Kunden in den Planungsprozess durch Agile Methoden oder andere Feedbackprozesse.
C006 Bugs werden erfasst und immer mit höchster Priorität behoben.
Anmerkung: Jeder Bug in Produktion sollte als gleich wichtig und kritisch erachtet werden.
Tags: Disziplin Kundenorientierung Organisatorisch Security Stabilität
C007 Bei Ausfall von Abhängigkeiten informiert die Applikation den Nutzer automatisch an passender Stelle und gibt Hinweise zu weiteren Schritten.
Beispiel: Der Nutzer erhält bei dem Ausfall der Datenbank einen für ihn verständlichen Hinweis mit zuständigen Ansprechpartnern.
C008 Test- und Produktionsdaten sind voneinander getrennt.
Beispiel: Auf Testdaten angewendete Operationen haben keine Wirkung auf Produktionssysteme.
C009 Testdaten sind anonymisiert und enthalten keine zuordenbare Nutzerinformationen.
Anmerkung: Datenschutz und diskreter Umgang mit Anwenderdaten.
Tags: Organisatorisch Qualität Security
C010 Test- und Produktionssysteme sind voneinander getrennt.
Anmerkung: Fehler und Systemabstürze in der Testumgebung haben so keine Auswirkung auf das operative Geschäft.
C032 Umfangreiche Refaktorisierungsmaßnahmen werden mit dem kompletten Team besprochen.
Beispiel: Durch die Verteilung der Information werden die Maßnahmen bei zukünftigen Implementierungen beachtet.
C035 Zur Sicherstellung von Qualitätsrichtlinien in Bezug auf den Quellcode werden automatische Analysetools eingesetzt.
Beispiel: FX Cop Analyzers
Tags: Automatisierung Nachhaltigkeit Organisatorisch Qualität
C122 Es gibt ein Konzept für den Austausch von Hash-, bzw. Verschlüsselungsverfahren.
Beispiel: Austausch des Hashverfahrens für Nutzerpasswörter gegen ein stärkeres oder besser geeignetes Verwahren.
Tags: Kundenorientierung Nachhaltigkeit Organisatorisch Qualität Security
C119 Technische Schnittstellen sind durch gängige Authentifizierungsmechanismen abgesichert.
Beispiel: OAuth für Web-APIs.
C036 Passwörter und Verbindungszeichenfolgen sind ausschließlich verschlüsselt abgelegt.
Beispiel: Verschlüsselte Variablen in der Library auf Azure-Pipelines.
Tags: Organisatorisch Security
C044 Persönliche, vertrauliche und geheime Daten werden ausschließlich verschlüsselt übertragen.
Beispiel: Verschlüsselung oder Tunneling bei relevanten Datenübermittlungen, z.B. HTTPS bei REST-Anfragen.
C012 Das Branchingkonzept ist jedem Teammitglied bekannt und wird angewendet.
Beispiel: Git-Flow
Tags: Organisatorisch
C013 Für die Übernahme von Codeänderungen in den Hauptzweig des Code-Repositorys wird das Vier-Augen-Prinzip oder ein ähnliches Verfahren angewendet.
Beispiel: Pull-Request Verfahren mit verpflichtendem Review durch den Author und mindestens eine weitere Person.
C043 Sämtliche Commit-Messages sind in derselben Sprache formuliert.
Beispiel: englisch.
C114 Verbindungszeichenfolgen und Geheimnisse sind nicht in das Code-Repository eingecheckt.
Beispiel: DB Connection-Strings, User-Credentials, OAuth Client-Secrets.
Tags: Disziplin Organisatorisch Security
C124 Jeder darf Code hinzufügen, ändern, entfernen und dokumentieren.
Anmerkung: Der Code gehört dem Team, es gibt kein "Code-Ownership".
Tags: Disziplin Organisatorisch
C024 Die Lizenzen von eingebundenen Bibliotheken und Referenzen sind geprüft und dokumentiert.
Anmerkung: Wenn genutzte Komponenten noch weitere Komponenten integrieren sind auch diese zu prüfen.
C045 Sämtliche Daten sind nach geltenden Datenschutzrichtlinien klassifiziert.
Beispiel: Klassifizierung nach öffentlichen, internen, vertraulichen und geheimen Daten.
C046 Persönliche Daten sind verschlüsselt abgelegt.
Beispiel: Kontaktinformationen, Zahlungsmittel, Geburtsdaten...
C047 Sämtliche Daten sind nach Kriterien der Verfügbarkeit organisiert.
Beispiel: Hochverfügbare Datenbestände sind von anderen Datenbeständen getrennt.
C058 Timestamps enthalten eine Angabe zur Zeitzone.
Anmerkung: Der verwendete Datentyp sollte die Angabe einer Zeitzone sicherstellen.
C060 Für die Abfrage von Datensätzen, durch externe Komponenten oder Benutzer der Applikation, wird als Identifikationsmerkmal keine fortlaufende, nummerische ID verwendet.
Beispiel Eine UUID als Identifikationsmerkmal kann nur schwer erraten werden.
Tags: Organisatorisch Security
C062 Es gibt Mechanismen zur Bereinigung alter Datenbestände.
Beispiel: Ein Reporting stellt alle Vorgänge zusammen, die "aktiv sind, vor zwei Jahren erstellt und seit einem Jahr nicht mehr aktualisiert wurden".
C052 Das Staging-Konzept wird auch auf die Datenbankumgebung angewendet.
Beispiel: Entwicklung, Integration (CI), Public
Tags: Organisatorisch
C055 Zum Lesen und Schreiben von Daten existieren separate Datenbankbenutzer.
Beispiel: Die Applikation "Sample" benutzt die DB-User "app_sample_read" und "app_sample_write". Aus dem Namen des DB-Users lässt sich die zugehörige Applikation ableiten.
C056 Jede Komponente nutzt eigene Datenbankbenutzer mit entsprechend eingeschränkten Rechten.
Beispiel: Jedes fachlich getrennte Modul erhält einen "read" und einen "write" DB-User. Aus dem Namen des DB-Users lässt sich das zugehörige Applikationsmodul ableiten.
C057 CRUD Operationen werden von der Datenbank ausschließlich über Funktionen, Prozeduren und Views bereitgestellt. Die Applikation hat keinen direkten Zugriff auf einzelne Tabellen und besitzt keine "Kenntnis" über die interne Tabellenstruktur.
Anmerkung: Insbesondere die richtige Anwendung von typisierten Parametern verhindert die meisten Angriffe per SQL-Injection.
C063 Datenbanken sind so konfiguriert, dass sie in den Produktiven Umgebungen nicht auf Anfragen zu Instanzinformationen antworten.
Beispiel: MS SQL "Hidden SQL Server Instance" oder "Turn off SQL Server Browser".
C064 Die Anmeldung von globalen Root-Usern an einem Datenbanksystem ist nur von bestimmten Systemen aus erlaubt.
Beispiel: Einschränkung auf 127.0.0.1 (localhost).
C083 Postfächer, Telefonnummern und Kontakte von zuarbeitenden Stellen sind dokumentiert, aktuell und zentral abgelegt.
Beispiel: Kontaktinformationen zu Firewall-, Netzwerk-, Plattformteams und zu wichtigen Stakeholdern des Projekts.
C125 Alle beteiligten Akteure eines Projektes sind mit entsprechender Rollenangabe dokumentiert.
Beispiel: Projektleiter, Entwickler, Kunden, Fachbereiche, Tester, etc...
C084 Alle ein- und ausgehenden Netzwerkverbindungen der Applikation sind dokumentiert.
Beispiel: Netzwerkadresse des Zielsystems, Netzwerkkonfiguration (Proxy, etc.), Fachliche Beziehungen, Abhängigkeiten, Kritikalität bei Ausfall der Verbidung.
Tags: Nachhaltigkeit Nachvollziehbarkeit Organisatorisch Security Stabilität
C072 Es gibt eine fachliche Protokollierung von Vorgängen.
Beispiele: Anmeldung, Vertragsabschluss, Bearbeitungsverlauf
C080 Persönliche Nutzerinformationen (PII) sind in dem technischen Anwendungsprotokoll nicht enthalten.
Anmerkung: Auschluss von Adressen, Kontodaten und weiteren Identifikationsmerkmalen.
C098 API Dokumentationen werden über den Release-Prozess automatisch bereitgestellt und aktualisiert.
Beispiel: Die API Dokumentation ist Teil der Anwendung.
C099 Die Dokumentation von Änderungen an den Firewall-Regeln ist Bestandteil des Release-Prozesses.
Beispiel: Firewall-Regeln werden in einem Release-Task gebrannt, dokumentiert und bei folgenden Releases nachhaltig auf Notwendigkeit geprüft.
Tags: Disziplin Nachhaltigkeit Nachvollziehbarkeit Organisatorisch
C087 Jede beliebige Code-Version kann jederzeit "per Knopfdruck" durch den Buildserver gebaut werden.
Beispiel: Build-Definition in Azure-Pipelines.
C088 Ein CI-Build existiert und verhindert die Übernahme von nicht-kompilierbarem Code in die Hauptzweige des Repositories.
Beispiel: CI-Build Policy für Pull-Requests gegen Hauptzweige (z.B. Master).
C092 Für Änderungen an den Build-Agents gibt es ein Rollback-Konzept.
Beispiel: Bereitstellung von versionierten Build-Agent-Pools.
Tags: Organisatorisch Stabilität
C089 Ein CI-Deployment existiert und verhindert die Übernahme von nicht-deploybarem Code in die Hauptzweige des Repositories.
Beispiel: CI-Release nach allen CI-Builds der Pull-Requests gegen Hauptzweige (z.B. Master).
C094 Für Änderungen an den Release-Agents gibt es ein Rollback-Konzept.
Beispiel: Bereitstellung von versionierten Release-Agent-Pools.
Tags: Organisatorisch Stabilität
C091 Die Verfügbarkeit und Ausfallsicherheit der Hostsysteme ist sichergestellt.
Beispiel: Replikation und automatisiertes Monitoring.
Tags: Organisatorisch Stabilität
C101 Die Patchfähigkeit für verschiedene Release-Versionen der Applikation ist gegeben.
Beispiel: Release-Branches oder Tags (Git).
C102 Die tatsächlich genutzten Versionen der Applikation können für beliebige Zeiträume ermittelt werden.
Beispiel: Protokollierung der Versionsnummer bei Nutzung und Sicherstellung einer angemessenen Aufbewahrungsfrist der Information.
Tags: Kundenorientierung Nachhaltigkeit Nachvollziehbarkeit Organisatorisch
C108 Das Monitoring der Applikation ist nicht oder nur in begrenztem Umfang öffentlich erreichbar.
Beispiel: Interne Monitoring-Schnittstellen sind öffentlich nicht erreichbar. Öffentliche Monitoring-Schnittstellen stellen keine detaillierten Fehlerinformationen bereit.
C109 Ein Benachrichtigungsprozess informiert über den Ausfall des Applikations-Monitorings.
Beispiel: Treffen in einem definierten Zeitraum keine neuen Logs ein, greift ein fest definierter Informationsprozess.
C110 Ein Benachrichtigungsprozess informiert über den Ausfall von geplanten Datenimporten, -exporten oder Nachtläufen.
Beispiel: Monitoring der Jobs und separate Kontrolle der Anzahl importierter Daten.
Tags: Automatisierung Nachhaltigkeit Organisatorisch Stabilität
Kontakt: mail@jannis-kuehn-consulting.de
Dokument: https://old.k-drummer.de/SoftwareProjectReviewGuide
Impressum: https://old.k-drummer.de/
Guide Version: 1.2.8 (09.06.2020)
Major: Große strukturelle Änderungen
Minor: Nummern neu vergeben (z.B. C053 auf C065)
Patch: Neue Kapitel, Neue Einträge, Textanpassung, Reihenfolge
Last Page Update: 06.01.2021
Guides
Agile Projects: https://old.k-drummer.de/AgileProjectReviewGuide
Software Projects: https://old.k-drummer.de/SoftwareProjectReviewGuide
Datenschutzerklärung:
Der Webserver protokolliert Seitenzugriffe und die IP-Adressen der Aufrufer. Diese Protokolle werden ausschließlich zur Fehlersuche ausgewertet. Da es auf dieser Seite keine Benutzerkonten oder Tracking-Cookies gibt, sind diese Daten keiner Person zuordenbar und werden damit als nicht Personenbezogen betrachtet. Abgesehen davon werden keine Daten erhoben, gespeichert oder ausgewertet.
© 2020 Jannis Kühn Rights Reserved