Teilen
Inhaltsverzeichnis
- Policy & Compliance-as-Code
- Reaktive Richtlinienprüfungen
- Frühe Richtlinienkontrolle – Shift Policy Checks left!
- Bringen Sie Compliance und Sicherheit zu DevOps
Unternehmen vergessen manchmal die Einhaltung von Richtlinien, wenn sie ihre digitale Transformation planen und beginnen. Es ist jedoch ein sehr wichtiger Bereich, und wenn Sie ihn im Auge behalten, können Sie ernsthafte Probleme vermeiden. Betrachten wir eine Situation wie diese: Sie befinden sich bereits auf Ihrer DevOps-Transformationsreise. Ihr Unternehmen verlagert den größten Teil seiner IT-Infrastruktur in die Cloud und konzentriert sich auf Cloud-native Lösungen. Ihre Entwicklungsteams arbeiten eng mit der Betriebsabteilung zusammen und einige Projekte sollen in wenigen Tagen ihr „Go-Live“ erleben. Das Einzige was fehlt ist die Konformitäts- und Sicherheitsfreigabe von dem Change Advisory Board (CAB) zu erhalten.
Dann stellen Sie fest, dass die Anwendung die Sicherheitsanforderungen nicht erfüllt. Sie haben wichtige Infrastrukturteile für das Internet geöffnet und haben vergessen, ein Dashboard für die Anwendungsüberwachung vorzubereiten, um Fehler zu erkennen. Sie müssen die Veröffentlichung verzögern, um die erforderlichen Compliance-Regeln zu implementieren und auf die nächste CAB-Versammlung zu warten.
Aus Ihrer Sicht folgten Sie den DevOps-Prinzipien und verwendeten die Infrastruktur als Code-Paradigma für eine kontinuierliche Bereitstellungspipeline. Wie ist das möglich? Wenn Ihre Infrastruktur "vercodet" wird, bedeutet dies nicht, dass sie ständig auf Konformität überprüft wird. Sie können jedoch speziell aus diesem Grund einen Prozess namens „Policy-as-Code“ implementieren. Dieser Artikel zeigt Ihnen, was es damit auf sich hat und wie Sie es in Ihren Projekten implementieren können.
Policy & Compliance-as-Code
Normalerweise erstellen die Richtlinienautoren ein PDF-Dokument und verteilen es im Unternehmen oder Projekt. Kollegen können diese Richtlinien somit lesen und einhalten. Vor einer Freigabe oder Änderung wird das Compliance- und Sicherheitsteam aufgefordert zu überprüfen, ob das System kompatibel ist. Dieses Verfahren ist nicht wirklich effizient. Das Prüfen und Anwenden von Änderungen, um die Richtlinien in der Anwendung so spät im Entwicklungsprozess zu erfüllen, ist schwierig und fehleranfällig. Es entspricht auch nicht dem DevOps-Prinzip so viel wie möglich zu automatisieren. Die vorgeschlagene Lösung für dieses Problem besteht darin, den Richtlinienvalidierungsprozess zu automatisieren.
Policy-as-Code ist ein Konzept, bei dem Sie anstelle eines PDF-Dokuments Ihre Richtlinien in maschinenlesbare Definitionsdateien übersetzen und damit überprüfen und durchsetzen, ob der Status des Systems diesen Richtlinien entspricht. Auf diese Weise können wir Validierungen nach einem festen Zeitplan ohne menschliche Interaktion einbetten. Dadurch kann sichergestellt werden, dass die von Ihnen bereitgestellte Cloud-Infrastruktur den deklarierten Richtlinien entspricht.
Die Richtlinien können mehrere Kategorien abdecken:
- Compliance Richtlinien – Die DSGVO ist ein gutes Beispiel, welche fast alle Branchen abdeckt. Abgesehen davon können verschiedene Branchen auch ihre eigenen Vorschriften haben. Für den Gesundheitssektor sind es HIPAA und BfArM, in der Finanzwelt die Financial Conduct Authority (FCA), BaFin und FINMA. Aus IT-Sicht wirken sich diese Vorschriften auf die Art und Weise aus, wie Daten gespeichert und übertragen werden, sowie auf die Transparenz bei der Erstellung eines Produkts.
- Security Policy – IT-Sicherheitsrichtlinien zum Schutz des Computersystems. Dies kann eine Nur-HTTPS-Richtlinie oder eine Regel sein, die nur Verbindungen aus einem bestimmten IP-Bereich zulässt.
- Richtlinien zur Kostenoptimierung – wird verwendet, um die Kosten Ihrer IT-Infrastruktur zu senken. Sie können beispielsweise die nicht verwendeten Entwicklungsumgebungen außerhalb der Geschäftszeiten herunterfahren oder die Dienste identifizieren, die nicht ausgelastet sind und heruntergestuft werden können.
- Gute Praktiken – andere Richtlinien, um die Dauerhaftigkeit oder eine hohe Verfügbarkeit zu gewährleisten. Beispielsweise, falls größere Infrastrukturänderungen eine manuelle Genehmigung in der Pipeline erfordern.
Figure 1. Ein Beispiel für einen Open Policy Agent-Richtliniencode, der Ressourcen ohne Tags im Terraform-Plan erkennt. Eine solche Richtlinie könnte verwendet werden, um sicherzustellen, dass Cloud-Ressourcen ordnungsgemäß gekennzeichnet sind.
Reaktive Richtlinienprüfungen
Wenn Sie mit der Implementierung von Richtlinien als Code beginnen, verfügen Sie wahrscheinlich bereits über eine Cloud-Infrastruktur. In diesem Fall ist es am besten, Tools zu verwenden, mit denen Sie die vorhandene Infrastruktur kontinuierlich anhand der Richtlinien überprüfen können. Cloud-Anbieter bieten solche Tools häufig an. AWS hat es als AWS Config und AWS Inspector. In Azure können Sie Azure Policy verwenden. Es gibt auch Open-Source-Hybrid-Cloud-Tools wie Cloud Custodian.
Versuchen wir, eine Beispielrichtlinie in Cloud Custodian zu implementieren. Unser Ziel ist es, den Löschschutz für alle RWS-Produktionsinstanzen (AWS Relational Database Service) zu aktivieren, um versehentlichen Datenverlust zu vermeiden. Wenn wir eine RDS-Instanz ohne sie erkennen, können wir die nicht kompatiblen Instanzen beheben und den Beendigungsschutz darauf aktivieren.
1. policies:
2. - name: enable-rds-deletion-protection-on-prod
3. resource: rds
4. filters:
5. - DeletionProtection: false
6. - “tag:Environment”: “production”
7. actions:
8. - type: modify-db
9. update:
10. - property: 'DeletionProtection'
11. value: true
12. immediate: true
Wenn Sie diese Richtlinie mit Cloud Custodian ausführen, werden RDS-Instanzen erkannt, bei denen das Tag "Environment/Umgebung" auf "Production/Produktion" gesetzt und der Löschschutz deaktiviert ist. Dieses Tag wird dann automatisch für alle aktiviert. Sie können eine solche Richtlinie täglich ausführen, um sicherzustellen, dass Ihre Datenbanken nicht versehentlich entfernt werden.
Frühe Richtlinienkontrolle – Shift Policy Checks left!
Schnelles und funktionierendes Feedback von Ihren Produktionssystemen und Betriebsteams zu den Entwicklungsteams ist ein wichtiger Aspekt der DevOps-Kultur. Ebenso ist es eine gute Idee, die Rückkopplung von Ihren Sicherheits- und Compliance-Teams zur Entwicklung zu verbessern. Sie können dies erreichen, indem Sie Richtlinienprüfungen in Ihre Integrations- und Bereitstellungspipeline integrieren. Dadurch werden die Entwickler jedes Mal über jede Richtlinienüberprüfung informiert, wenn sie Code in die Repositorys übertragen, sodass das Team Korrekturen der Richtlinien später im Projekt vermeiden kann. Diese Praxis umfasst auch die Zusammenarbeit zwischen den Compliance- und Entwicklungsteams und bringt sie zusammen.
In diesem Fall verwenden wir Open Policy Agent. Open Policy Agent ist eine Richtlinie als Code-Engine, die eine Richtliniensprache namens Rego und eine Binärdatei zum Auswerten der Richtlinien anhand einiger Eingabedaten bereitstellt. Dies kann ein Terraform-Plan, eine Kubernetes-Ressource oder eine beliebige JSON-Datei sein. Das Projekt wird in der Cloud-nativen Community immer beliebter und ist derzeit ein Inkubationsprojekt in der Cloud Native Computing Foundation.
Schauen wir uns ein Beispiel für eine Open Policy Agent-Richtlinie an, die einen Terraform-Plan als Eingabe verwendet und sicherstellt, dass alle bereitgestellten Ressourcen über die beiden erforderlichen Tags verfügen.
1. package policies.terraform
2.
3. import data.libraries.terraform
4. import data.libraries.common
5.
6. required_tags = {
7. "Project",
8. "Environment",
9. }
10.
11. missing_tags_errors[msg] {
12. tags = terraform.taggable_resources[res].values.tags
13. resource_tags := { tag | tags[tag] }
14.
15. required_tag := required_tags[_]
16. not common.contains(resource_tags, required_tag)
17.
18. msg := sprintf("Error in resource %v. Missing required tag %v", [res.address, required_tag])
19. }
20.
21. approve {
22. count(missing_tags_errors) == 0
23. }
Diese Richtlinie überprüft, ob alle von Terraform verwalteten Ressourcen als "Projekt" und "Umgebung" gekennzeichnet sind. Man kann leicht verstehen, was diese Richtlinie bewirkt, indem man einfach den Code liest. Mit einer solchen Definition können Sie sie jetzt in Ihre Pipeline für die kontinuierliche Bereitstellung einbetten, sodass die Anwendungsteams jedes Mal, wenn sie Code festschreiben, Feedback erhalten und Korrekturen zum frühesten Zeitpunkt der Entwicklung anwenden können.
1. # Evaluate OPA policies
2. $ opa eval --format pretty -d '.' --input terraform.tfplan.json "data.policies.missing_tags_errors"
3. [
4. "Error in resource aws_cloudtrail.organization. Missing required tag Project",
5. "Error in resource aws_cloudtrail.organization. Missing required tag Environment",
6. "Error in resource aws_s3_bucket.cloudtrail. Missing required tag Project",
7. "Error in resource aws_s3_bucket.cloudtrail. Missing required tag Environment"
8. ]
Bringen Sie Compliance und Sicherheit zu DevOps
Die Sicherheits- und Compliance-Teams werden bei der DevOps-Transformation häufig übersehen. Alle sprechen von kontinuierlicher Bereitstellung, Infrastruktur als Code und anderen DevOps-Prinzipien. Compliance-Richtlinien können jedoch zu einem Problem werden, das die Veröffentlichung Ihres Projekts anhält.
Richtlinien und Compliance als Code können Ihnen dabei helfen, den Compliance- und Sicherheitsprozess in Ihre kontinuierliche Integration und Bereitstellung einzubetten. Dies stellt sicher, dass Ihre Infrastruktur und Produkte alle Richtlinienanforderungen erfüllen. Wenn Sie die Compliance- und Sicherheitsteams an einen Tisch bringen und den Richtlinienvalidierungsprozess „kodifizieren“, können Sie die Bereitstellungspipeline verkürzen und so den Geschäftswert schneller bereitstellen, während Ihre Cloud-Bereitstellungen sicher und geschützt bleiben. Mit dieser Lösung ist kein CAB-Meeting zu schwierig zu handhaben oder sogar erforderlich! Durch Ausführen reaktiver Konformitätsprüfungen können Sie falsch konfigurierte Ressourcen oder ungesicherte IT-Systeme erkennen. Nach unserer Erfahrung besteht der beste Ansatz darin, eine Kombination aus reaktiven Konformitätsprüfungen und proaktiven Pipelines mit eingebetteten Richtlinienprüfungen durchzuführen.
