Hinweis perev. : Das Original dieses Artikels wurde im offiziellen Kubernetes-Blog veröffentlicht und von Andrew Martin geschrieben, einem der Gründer des jungen britischen Unternehmens Control Plane, das sich auf die Sicherheit von Cloud-nativen Anwendungen spezialisiert hat, die auf K8s ausgeführt werden.
Die Sicherheit bei Kubernetes hat seit dem Eintreffen des Projekts einen langen Weg zurückgelegt, aber es treten immer noch Fallstricke auf. Wir bieten eine Liste nützlicher Empfehlungen zum Schutz von Clustern und zur Erhöhung ihrer Stabilität im Falle von Hacking: Wir beginnen mit der Kontrollebene, fahren mit Workloads und Netzwerksicherheit fort und enden mit einer Bewertung der zukünftigen Sicherheit.
Teil 1: Kontrollebene
Die Kontrollebene ist das Gehirn von Kubernetes. Er hat eine allgemeine Vorstellung von jedem Container und Pod, der im Cluster ausgeführt wird, kann neue Pods planen (die Container mit Root-Zugriff auf ihre übergeordneten Knoten enthalten können) und alle im Cluster gespeicherten Geheimnisse lesen. Dies ist eine sehr wichtige Komponente, die einen ständigen Schutz vor versehentlichem Datenverlust und böswilligen Aktionen benötigt: sowohl beim Zugriff, wenn nichts passiert, als auch wenn Daten über das Netzwerk übertragen werden.
1. Allgegenwärtiges TLS
Für jede Komponente, die TLS unterstützt, muss sie aktiviert sein, um Traffic-Sniffing, die Überprüfung der Serveridentität und (im Fall von gegenseitigem TLS) die Überprüfung der Clientidentität zu verhindern."Bitte beachten Sie, dass einige Komponenten und Installationsmethoden möglicherweise lokale Ports für HTTP aktivieren. Administratoren müssen sich daher mit den Einstellungen der einzelnen Komponenten vertraut machen, um mögliche Pfade für unsicheren Datenverkehr zu ermitteln."
Aus der Kubernetes-Dokumentation
Das folgende Netzwerkdiagramm von
Lucas Käldström zeigt, wo TLS ideal benötigt wird: zwischen jeder Komponente im Assistenten und zwischen Kubelet und dem API-Server. Die klassischen
Kelsey Hightower Kubernetes The Hard Way und die
Sicherheitsdokumentation auf etcd bieten detaillierte Anweisungen zum Erreichen dieser Ziele.
In der Vergangenheit war die automatische Skalierung von Kubernetes-Knoten nicht einfach, da für jeden Knoten ein TLS-Schlüssel erforderlich war, um eine Verbindung zum Master herzustellen, und es geheim ist, Geheimnisse in einfachen Images zu bewahren.
Mit Kubelet TLS-Bootstrapping kann der neue Kubelet eine Zertifikatsignierungsanforderung erstellen, damit beim Booten Zertifikate generiert werden:
2. Mindestberechtigungen in RBAC, Deaktivieren von ABAC, Protokollüberwachung
Die rollenbasierte Zugriffssteuerung (RBAC) bietet eine detaillierte Richtlinienverwaltung, mit der Benutzer auf Ressourcen wie Namespaces zugreifen können.
Die Attributbasierte Zugriffssteuerung (ABAC) in Kubernetes wurde seit K8s 1.6 durch RBAC ersetzt und sollte auf der Serverseite der API nicht aktiviert werden. Verwenden Sie stattdessen RBAC:
--authorization-mode=RBAC (oder dieses Flag für GKE:
--no-enable-legacy-authorization ).
Es gibt viele
gute Beispiele für RBAC-Richtlinien für verschiedene Dienste in einem Cluster sowie
Dokumentation . Aber hören Sie hier nicht auf: Kompetente Einstellungen für RBAC-Richtlinien können mit
audit2rbac aus den
Überwachungsprotokollen abgerufen werden.
Falsche oder übermäßig zulässige RBAC-Richtlinien stellen ein Sicherheitsrisiko dar, wenn der Herd kompromittiert wird. Die Einhaltung von RBAC-Regeln mit minimalen Berechtigungen, deren ständige Überprüfung und Verbesserung sollte Teil der „technischen Hygiene der Schulden“ sein, die Teams im Entwicklungslebenszyklus anwenden.
Die Überwachungsprotokollierung (Beta in Kubernetes 1.10) bietet eine benutzerdefinierte Protokollierungs-API für Workloads (wie z. B. Anforderung und Antwort) und auf Metadatenebene. Die Protokollierungsstufe kann gemäß den Sicherheitsrichtlinien des Unternehmens konfiguriert werden.
GKE wendet angemessene Standardwerte für diejenigen an, die gerade erst damit beginnen.
Bei Leseanforderungen wie
Abrufen ,
Auflisten und
Überwachen wird nur das angeforderte Objekt in Überwachungsprotokollen ohne Antwortobjekt gespeichert. Bei Abfragen mit vertraulichen Daten wie
Secret oder
ConfigMap werden nur Metadaten exportiert. Bei allen anderen Anforderungen werden beide Objekte in den Überwachungsprotokollen aufgezeichnet: sowohl die Anforderung als auch die Antwort.
Vergessen Sie nicht: Das Speichern dieser Protokolle im Cluster ist ein Sicherheitsrisiko im Falle eines Kompromisses. Diese Protokolle sollten wie alle anderen sicherheitsrelevanten Protokolle außerhalb des Clusters platziert werden, um negative Folgen im Falle einer Sicherheitsanfälligkeit zu vermeiden.
3. Verwenden Sie die Authentifizierung eines Drittanbieters für API Server
Die Zentralisierung der Authentifizierung und Autorisierung für die gesamte Organisation (d. H. Single Sign On) hilft bei der Aufnahme und dem Verlassen neuer Mitarbeiter und gewährleistet konsistente Zugriffsrechte.Die Integration von Kubernetes mit Authentifizierungsanbietern von Drittanbietern (wie Google oder GitHub) bietet Identitätsgarantien von einer Remote-Plattform (mit Schutz wie Zwei-Faktor-Authentifizierung) und macht es für Administratoren überflüssig, den API-Server in Kubernetes neu zu konfigurieren, um Benutzer hinzuzufügen / zu entfernen.
Dex ist ein OpenID Connect Identity (OIDC) - und OAuth 2.0-Anbieter mit Plug-Ins. Pusher ging noch einen
Schritt weiter und stellte
anpassbare Tools zur Verfügung . Zusätzlich gibt es
einige andere Helfer, die sich auf andere Anwendungen konzentrieren.
4. Trennen Sie Ihren Cluster usw. und platzieren Sie ihn hinter der Firewall
etcd speichert Informationen über den Status und die Geheimnisse von Kubernetes und ist eine wichtige Komponente von K8s. Es muss separat vom Rest des Clusters geschützt werden.Der Schreibzugriff auf etcd auf dem API-Server entspricht der Ausgabe von Stammrechten für den gesamten Cluster, und selbst der Lesezugriff kann problemlos zum Eskalieren von Berechtigungen verwendet werden.
Der Kubernetes-Scheduler in etcd sucht nach Pod-Definitionen, die keinen Knoten haben. Dann schickt er alle gefundenen Hülsen zur Planung an den verfügbaren Kubelet. Die Validierung dieser Pods erfolgt durch den API-Server, bevor sie in etcd geschrieben werden, sodass Angreifer, die direkt in etcd schreiben, viele Sicherheitsmechanismen umgehen können,
PodSecurityPolicies . B.
PodSecurityPolicies .
etcd sollte mit
beiden TLS-Zertifikaten (
Client und
Peer ) konfiguriert und auf dedizierten Knoten bereitgestellt werden. Um das Risiko des Diebstahls und der Verwendung privater Schlüssel von Arbeitsknoten zu verringern, können Sie auch die Firewall des API Server-Clusters einschränken.
5. Drehung der Verschlüsselungsschlüssel
Die regelmäßige Rotation von Sicherheitsschlüsseln und Zertifikaten ist die beste Sicherheitspraxis, mit der Sie den "Radius der Zerstörung" begrenzen können, wenn der Schlüssel kompromittiert wird.Kubernetes
dreht automatisch einige Zertifikate (insbesondere Kubelet-Client- und -Serverzertifikate), indem nach Ablauf der aktuellen Zertifikate neue CSRs erstellt werden.
Die vom API-Server zum Verschlüsseln von etcd-Werten verwendeten
symmetrischen Schlüssel werden jedoch nicht automatisch gedreht - dies muss
manuell erfolgen . Dieser Vorgang erfordert Masterzugriff, sodass verwaltete Dienste (wie GKE und AKS) das Problem vor dem Benutzer verbergen.
Teil 2: Workloads
Mit minimaler Sicherheit auf der Ebene der Steuerebene kann der Cluster bereits sicher funktionieren. Wie bei einem Schiff mit potenziell gefährlicher Ladung müssen die Container eines solchen Schiffes die Ladung jedoch im Falle eines unvorhergesehenen Unfalls oder Lecks schützen. Gleiches gilt für Workloads in Kubernetes (
Pods ,
Bereitstellungen ,
Jobs ,
Sets usw.). Sie können zum Zeitpunkt der Bereitstellung als vertrauenswürdig eingestuft werden. Wenn sie jedoch von außen zugänglich sind, besteht immer das Risiko, dass sie später von [Angreifern] verwendet werden. Dieses Risiko kann durch Ausführen von Workloads mit minimalen Berechtigungen und deren sicherer Konfiguration verringert werden.
6. Verwenden Sie Linux-Sicherheitsfunktionen und PodSecurityPolicies
Der Linux-Kernel verfügt über viele teilweise überlappende Sicherheitserweiterungen (Funktionen, SELinux, AppArmor, seccomp-bpf), die so konfiguriert werden können, dass Anwendungen nur minimale Berechtigungen erhalten.Dienstprogramme wie
bane helfen Ihnen beim Generieren von Profilen für AppArmor und
docker-slim beim Generieren von seccomp-Profilen. Seien Sie jedoch vorsichtig: Um alle Nebenwirkungen der Anwendung dieser Richtlinien zu ermitteln, benötigen Sie eine umfassende Testsuite, die den gesamten Anwendungscode überprüft.
PodSecurityPolicies regeln die Verwendung dieser Sicherheitserweiterungen sowie anderer Kubernetes-Sicherheitsanweisungen. Sie sind für die Mindestanforderungen verantwortlich, die erfüllt sein müssen, um zum API-Server zu gelangen, einschließlich Sicherheitsprofilen, Berechtigungsflag, freigegebenem Hostnetzwerk, Prozessen oder Namespaces für IPC.
Diese Anweisungen sind wichtig, da sie verhindern, dass containerisierte Prozesse ihren isolierten Grenzen entkommen.
Das PodSecurityPolicy-Beispiel von Tim Allclair ist sehr vielseitig - Sie können es als Grundlage nehmen und für Ihren Fall anpassen.
7. Führen Sie eine statische Analyse von YAML durch
Wenn PodSecurityPolicies den Zugriff auf den API-Server einschränken, kann die statische Analyse auch im Entwicklungsprozess verwendet werden, um die regulatorischen Anforderungen und den Risikoappetit des Unternehmens zu modellieren.Vertrauliche Informationen sollten nicht in YAML-Ressourcen wie Herden (
Pods ,
Bereitstellungen ,
Sets usw.) gespeichert werden, und vertrauliche
ConfigMaps und
Geheimnisse müssen mit Dienstprogrammen wie
Vault (mit einem Operator von CoreOS),
Git-Crypt ,
Sealed Secrets oder
KMS Cloud verschlüsselt werden
Anbieter .
Die statische Analyse der YAML-Konfiguration kann als Grundlage für die Sicherheit beim Start verwendet werden.
kubesec erstellt Risikobewertungen für Ressourcen:
{ "score": -30, "scoring": { "critical": [{ "selector": "containers[] .securityContext .privileged == true", "reason": "Privileged containers can allow almost completely unrestricted host access" }], "advise": [{ "selector": "containers[] .securityContext .runAsNonRoot == true", "reason": "Force the running image to run as a non-root user to ensure least privilege" }, { "selector": "containers[] .securityContext .capabilities .drop", "reason": "Reducing kernel capabilities available to a container limits its attack surface", "href": "https://kubernetes.io/docs/tasks/configure-pod-container/security-context/" }] } }
Und
kubetest ist ein Framework zum Testen von Kubernetes-Konfigurationen:
#
Diese Dienstprogramme implementieren den
Shift-Left- Ansatz (dh sie verschieben die Validierung und Verifizierung in die frühen Phasen des Entwicklungszyklus). Sicherheitstests in der Entwicklungsphase geben Benutzern ein schnelles Feedback zu Code und Konfiguration, das später durch manuelle oder automatisierte Überprüfung abgelehnt werden kann, und können auch die Einführung zusätzlicher Sicherheitspraktiken erleichtern.
8. Führen Sie Container aus, die nicht root sind
Container, die als Root ausgeführt werden, haben häufig viel mehr Rechte, als ihre Workloads erfordern, und wenn sie kompromittiert werden, helfen sie Angreifern, großartige Funktionen zu erreichen.Container verlassen sich immer noch auf das traditionelle UNIX-Sicherheitsmodell (DAC,
diskretionäre Zugriffskontrolle ) - alles ist eine Datei, und Benutzern und Gruppen werden Rechte gewährt.
Benutzernamensräume funktionieren in Kubernetes nicht. Dies bedeutet, dass die Benutzer-ID-Tabelle im Container der Host-Benutzertabelle zugeordnet ist. Wenn der Prozess mit Root-Berechtigungen im Container gestartet wird, wird er mit Root-Berechtigungen auf dem Host ausgeführt. Obwohl all dies Mechanismen hinzugefügt werden, um das Verlassen des Containers zu verhindern, wird nicht empfohlen, als Root im Container zu arbeiten.
Viele Container-Images verwenden den Root-Benutzer, um PID 1 auszuführen: Wenn dieser Prozess beeinträchtigt wird, erhält der Angreifer Root im Container und bei Konfigurationsfehlern wird die Bedienung des Problems erheblich vereinfacht.
Bitnami
hat großartige Arbeit geleistet, um seine Container-Images in
reguläre (Nicht-Root-) Benutzer zu übersetzen (was auch die Standard-OpenShift-Anforderung ist), was auch Ihre Migration zu Nicht-Root-Images vereinfachen kann.
Dieses PodSecurityPolicy-Fragment verhindert, dass Root-Prozesse im Container ausgeführt werden und zu Root eskalieren:
# Required to prevent escalations to root. allowPrivilegeEscalation: false runAsUser: # Require the container to run without root privileges. rule: 'MustRunAsNonRoot'
Container, die kein Root-Verzeichnis verwenden, können keine privilegierten Ports belegen, d. H. Bis zu 1024 (die entsprechende Funktion im Linux-Kernel -
CAP_NET_BIND_SERVICE ist dafür verantwortlich) hilft jedoch, diese Einschränkung durch die Verwendung von
Diensten zu umgehen. Hier ist ein Beispiel für die MyApp-Anwendung, die Port 8443 im Container belegt, aber vom
Dienst auf Port 443 verfügbar gemacht wird, um Anforderungen für
targetPort :
kind: Service apiVersion: v1 metadata: name: my-service spec: selector: app: MyApp ports: - protocol: TCP port: 443 targetPort: 8443
Die Notwendigkeit, Workloads ohne Verwendung von root auszuführen, bleibt bestehen, bis der Benutzernamensraum oder die
Betriebszeit zum Starten von Containern ohne root in der Container-Laufzeit enthalten sind.
9. Verwenden Sie Netzwerkrichtlinien
Standardmäßig erlaubt das Kubernetes-Netzwerk den gesamten Datenverkehr zwischen Pods. Diese Einstellung kann durch die Netzwerkrichtlinie NetworkPolicy eingeschränkt werden .
Herkömmliche Dienste sind auf Firewalls beschränkt, die statische IP-Adressen und Portbereiche für jeden Dienst verwenden. Da sich diese IP-Adressen sehr selten ändern, wurden sie in der Vergangenheit als Authentifizierungsform verwendet. Container haben selten statische IPs - ihre Natur impliziert die Möglichkeit eines schnellen Ablegens und erneuten Erstellens, da für sie die Diensterkennung anstelle statischer IP-Adressen verwendet wird. Diese Funktionen erschweren die Konfiguration und Überprüfung von Firewalls erheblich.
Da Kubernetes alle Daten zum Status des Systems in etcd speichert, ist es möglich, eine dynamische Firewall zu konfigurieren - sofern das CNI-Netzwerk-Plugin die erforderliche Unterstützung bietet. Calico, Cilium, Kube-Router, Romana und Weave Net - alle diese Plugins unterstützen Netzwerkrichtlinien.
Es ist wichtig zu beachten, dass Richtlinien nach dem Fail-Closed-Prinzip arbeiten,
podSelector hier standardmäßig kein
podSelector ist, der allen möglichen Werten (Platzhalter) entspricht:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny spec: podSelector:
Das Folgende ist ein Beispiel für
NetworkPolicy , das den Austritt von allem außer UDP 53 (DNS) verhindert, wodurch auch eingehende Verbindungen zur Anwendung verhindert werden.
NetworkPolicies sind Stateful- Richtlinien, sodass die Anwendung weiterhin Antworten auf ausgehende Verbindungen erhält.
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: myapp-deny-external-egress spec: podSelector: matchLabels: app: myapp policyTypes: - Egress egress: - ports: - port: 53 protocol: UDP - to: - namespaceSelector: {}
Kubernetes-Netzwerkrichtlinien können nicht auf DNS-Namen angewendet werden. Der Grund dafür ist, dass DNS das Round-Robin-Verfahren für mehrere IP-Adressen und dynamische Antworten in Abhängigkeit von der Zugriffs-IP unterstützt.
podSelector gelten Netzwerkrichtlinien nur für feste IP-Adressen oder
podSelector (für dynamische IP-Adressen von Kubernetes).
Es wird empfohlen, zunächst den gesamten Datenverkehr für den Namespace zu sperren und Schritt für Schritt die Routen hinzuzufügen, die die Anwendung benötigt, um die Abnahmetests zu bestehen. Der Prozess kann schwierig sein, daher hat ControlPlane
netassert entwickelt, ein Dienstprogramm zum Testen der Netzwerksicherheit in DevSecOps-Skripten mit hochparalleler nmap:
k8s: # used for Kubernetes pods deployment: # only deployments currently supported test-frontend: # pod name, defaults to `default` namespace test-microservice: 80 # `test-microservice` is the DNS name of the target service test-database: -80 # `test-frontend` should not be able to access test-database's port 80 169.254.169.254: -80, -443 # AWS metadata API metadata.google.internal: -80, -443 # GCP metadata API new-namespace:test-microservice: # `new-namespace` is the namespace name test-database.new-namespace: 80 # longer DNS names can be used for other namespaces test-frontend.default: 80 169.254.169.254: -80, -443 # AWS metadata API metadata.google.internal: -80, -443 # GCP metadata API
Eine API mit Metadaten eines Cloud-Anbieters ist eine ständige Quelle potenzieller Eskalation (wie
durch die jüngste
Fehlerbehebung von Shopify belegt ). Spezielle Tests, die bestätigen, dass die API im Containernetzwerk blockiert ist, schützen vor Konfigurationsfehlern.
10. Scannen Sie Bilder und führen Sie IDS aus
Webserver sind ein Sprungbrett für Angriffe auf die Netzwerke, an die sie angeschlossen sind. Durch Scannen der in den Images installierten Dateien können Sie überprüfen, ob keine bekannten Sicherheitslücken vorhanden sind, mit denen ein Angreifer Remotezugriff auf den Container erhalten könnte. Intrusion Detection Systems (IDS) zeichnen diese Ereignisse auf, wenn sie auftreten.Kubernetes ermöglicht die Übermittlung an den Cluster durch eine Reihe von Kontrollprüfungen (im
Zulassungscontroller ), die nicht nur für Pods, sondern auch für andere Ressourcen wie
Bereitstellungen gelten . In ihnen kann jedes Sub für die Zulassung validiert oder sein Inhalt geändert werden, zusätzlich werden jetzt auch Webhooks auf der Backend-Seite unterstützt.
Diese Webhooks können von Tools zum Scannen von Containerbildern verwendet werden, um Bilder zu überprüfen, bevor sie im Cluster bereitgestellt werden. Bilder, deren Validierung fehlschlägt, erhalten keine Controller-Genehmigung.
Durch das Scannen von Container-Images auf bekannte Sicherheitslücken wird die Zeit verkürzt, die ein Angreifer von einem offenen CVE profitieren kann. Um die Einführung von Images mit kritischen Schwachstellen in der Bereitstellungspipeline zu verhindern, können Sie kostenlose Dienstprogramme wie
Clair von CoreOS und
Micro Scanner von Aqua verwenden.
Mit Tools wie
Grafeas können Sie Bildmetadaten für laufende Konformitäts- und Schwachstellenprüfungen mithilfe einer eindeutigen Containersignatur (oder eines speziellen
Hashs für die
Adressierung von Inhalten ) speichern. Das Scannen eines Container-Images mit diesem Hash ist gleichbedeutend mit dem Scannen von Bildern, die in der Produktion bereitgestellt werden, und kann kontinuierlich ausgeführt werden, ohne dass Zugriff auf Produktionsumgebungen erforderlich ist.
Unbekannte 0-Tage-Sicherheitslücken sind immer vorhanden, daher sollte Kubernetes ein Intrusion Detection-System wie
Twistlock ,
Aqua oder
Sysdig Secure bereitstellen . IDS erkennt ungewöhnliches Verhalten im Container und stoppt oder tötet ihn.
Sysdigs Falco ist eine Open Source-Regel-Engine und der Ausgangspunkt für dieses Ökosystem.
Teil 3: Die Zukunft
Die nächste Sicherheitsstufe in der „Evolution von Cloud Native“ scheint das Service-Mesh zu sein, obwohl seine Einführung nicht sofort erfolgen wird: Diese Migration erfordert die Verlagerung der Komplexität von Anwendungen auf die Mesh-Infrastruktur, und Unternehmen müssen diese Best Practice umsetzen.
11. Starten Sie das Service-Mesh
Service Mesh ist ein Netzwerk von dauerhaften verschlüsselten Verbindungen zwischen "Side-Connected" (ähnlich wie "Sidecar") , Hochleistungs-Proxys wie Envoy und Linkerd. Es bietet Verkehrsmanagement, Überwachung und Richtlinien - alles ohne Änderung der Microservices.Die Übertragung von Sicherheits- und Netzwerkcode von Microservices auf ein gemeinsam genutztes und kampferprobtes Bibliotheksset war mit
Linkerd bereits möglich, und
Istio von Google, IBM und Lyft brachte eine Alternative zu diesem Bereich. Mit
SPIFFE für die kryptografische Identität jedes Pods und vielen anderen Funktionen kann Istio die Bereitstellung der Netzwerksicherheit der nächsten Generation vereinfachen.
In Netzwerken mit „Zero Trust“ ist möglicherweise keine herkömmliche Firewall oder Kubernetes-Netzwerkrichtlinien erforderlich, da jede Interaktion mithilfe von mTLS (gegenseitiges TLS) erfolgt, was nicht nur die Sicherheit der Interaktion garantiert, sondern auch die Identität beider Dienste bestätigt .
Diese Verlagerung von herkömmlichen Netzwerkansätzen zu den weltweiten Sicherheitsprinzipien von Cloud Native wird für Benutzer mit einer traditionellen Sicherheitsorientierung nicht einfach sein. Als Einführung in diese neue Welt empfehlen wir
das Zero Trust Networking-Buch von
Evan Gilman von SPIFFE.
Istio 0.8 LTS ist derzeit verfügbar und das Projekt nähert sich schnell seiner Version 1.0. Die Versionierung des Projekts in Bezug auf die Stabilität erfolgt ähnlich wie beim Kubernetes-Modell: Ein stabiler Kernel mit separaten APIs, für die der Alpha- oder Betastatus mithilfe von Namespaces angegeben wird. Erwarten Sie, dass Istio in den kommenden Monaten expandieren wird.
Fazit
Cloud Native-Anwendungen verfügen über detailliertere Sicherheitsfunktionen, die zum Schutz von Workloads und Infrastruktur beitragen. Die Leistungsfähigkeit und Flexibilität solcher Tools ist sowohl ein Segen als auch ein Fluch: Ohne ausreichende Automatisierung [für ihre Verwendung] ist es noch einfacher geworden, unsichere Anwendungen über den Container oder ihr Isolationsmodell hinaus freizulegen.
Schutzprogramme sind zugänglicher als je zuvor. Um jedoch das Angriffspotential und das Potenzial für falsche Konfigurationen zu verringern, müssen Sie sie mit Vorsicht verwenden.
Wenn die Sicherheit die Geschwindigkeit des Unternehmens bei der Bereitstellung von Änderungen verlangsamt, wird dies niemals Priorität haben. Durch die Verwendung der Grundsätze der kontinuierlichen Bereitstellung in Bezug auf die Software-Lieferkette kann das Unternehmen die Einhaltung gesetzlicher Vorschriften, die kontinuierliche Prüfung und das verbesserte Management erreichen, ohne die Geschäftsleistung zu beeinträchtigen.
Eine schnelle, schrittweise Sicherheitsverbesserung ist der einfachste Weg mit einer umfassenden Testsuite. Continuous Security — pipeline', , , .
PS vom Übersetzer
Lesen Sie auch in unserem Blog: