Compliant & Secure Cloud für Entscheider und Sicherheitsverantwortliche - Michael Frank (Syncier Cloud) & Adrian Lambeck (ALPS)

Transcript

1. Workshop “Compliant & Secure Cloud für Entscheider und Sicherheitsverantwortliche” ECNS-2019 München, Nockerberg 07.10.2019
2. Michael Frank QAware PSO Syncier Cloud/Software Architekt Adrian Lambeck CEO ALPS GmbH ISO27001 Experte & Trainer michael.frank@qaware.de lambeck@alps-gmbh.de
3. Thema Zeit Eröffnung - Fragen & neuralgische Punkte abholen 30 min 14:00 Impulsvortrag zu den neuralgischen Punkten 15 min 14:30 Neuralgische Themen: Compliance/ISO270xx 15 min 14:45 Shared Responsibility Model 15 min 15:00 Threats unique to the cloud - are there any? 15 min 15:15 How to raise confidence - trusting the cloud 15 min 15:30 - Pause - 30 min 15:45 - 16:15 Gemeinsame Themenarbeit 90 min 16:15 Top Takeaways 15 min 17:45
4. Workshop Ziele
5. Ziele: • gegenseitiges Verständnis zwischen “compliance” und “security” • cloud entmystifizieren, (sicherheits-) Vorurteile abbauen • shared responsibility verstehen • sec&Comp chancen mit Cloudtechnologie erkennen
6. Developers Managers Auditors Regulators Security Officers Architects Customers
7. Fragerunde Ich bitte um Handzeichen :-)
8. Q: “Wer fühlt sich eher auf der Compliance-/Entscheiderseite?” Publikum: ca 2/3
9. Q: “Wer fühlt sich eher auf der Technikerseite?” Publikum: ca 1/3
10. Q: “Cloud is mir (noch) suspekt?” Publikum: Cloud ist im allgemeinen verstanden, keiner findet sie noch suspekt.
11. Q: “Bei unserer Security könnte man noch was verbessern?” Publikum: Die meisten stimmen dem zu
12. Q: “Ich könnte eine konkrete Sache nennen, die wir sofort besser machen könnten?” Publikum: Die meisten stimmen dem zu Tonspur: Es liegt also offensichtlich nicht an der Awareness und nicht daran, dass wir nicht wissen, was zu tun wäre.
13. Q: „Mein Unternehmen spielt Patches innerhalb 24h ein!“ Publikum: Die meisten patchen nicht innerhalb von 24h, aber doch 4-5 Handzeichen. Bei der Frage: “ .. und auch meine Dienstleister” noch 2 Handzeichen.
14. Q: „Wir haben deshalb auch ein bisschen ein schlechtes Gewissen!“
15. Einschub: Cloud - Demystified
16. Cloud is not...
17. Cloud is not...
18. Cloud is..
19. Cloud is.. just someone elses datacenter
23. Europäische(r)/Deutsche(r) • Standort • § Gesetze • Regulatorik
24. Cloud (im B2B Fall): • Jemand anders stellt die Hardware und einige übliche Services • Sie können sich auf ihre (Software) Produkte konzentrieren. Wo/Wie/Wieviel/Welche Hardware ist nicht Teil ihres Produktes und nicht das womit Sie sich abgrenzen. • Weder ist die Cloud ein/das Problem noch löst sie alle Probleme • Sie können aus fertigen Lösungsbausteinen wählen, aber müssen diese zu ihrem Produkt hinzu und zusammenfügen
25. Fragerunde 2 Ich bitte um Handzeichen :-)
26. Q: „Wo steht ihr in der Cloud Journey?“ enterprise readiness production-ready scalable platform first {OpenShift, PCF, Kubernetes} cluster up and running effort “stuck in PoC” High technical inflation Publikum: Die meisten stehen am Übergang zu Production ready.
27. Q: „Warum seid ihr hier - welche Fragen und Erwartungen habt ihr?“
28. Q: “Wo seht ihr die neuralgischen Punkte und Fragestellungen bei der Cloud(-Migration)? Welche Anforderungen gibt es?”
29. Compliance & Standards
30. Relevante Standards ISO 27001 – Anforderungen an ein ISMS ISO 27017 – Guideline für Cloud Security VDA-ISA – Anforderungen der Automobilindustrie basierend auf ISO 27001 / 27017
31. Tonspur: Wenn sie keine Behörde sind, machen Sie ISO27001 und nicht C5 oder Grundschutz. C5 und Grundschutz kennt keiner außerhalb Deutschlands Grundschutz ist zu konkret und lässt sich schwer auf ihr Business münzen.
32. QAware 32 BaFin VAIT BaFin MaRisk verweist auf BaFin BAIT Banken Versicherungen Risikomanagement BaFin IT-Grundschu tz ISO / IEC 2700x Reihe verweist auf verweist auf beinhaltet BSI Standards 200-1, 200-2, 200-3 Risiken & Handlungsempfehlungen des BSI (~5000 Seiten) Prozesse und Verfahren für ein angemessenes Sicherheitsniveau verweist auf Internationale IT-Sicherheitsnormen, insbesondere ISO 27001 Gängige Industriestandards NIST SP 800-190 PCI-DSS CIS Controls & Benchmarks reflektiert teilweise Handlungsanweisungen zur Absicherung von Systemen im Internet Globaler Standard für die Abwicklung von Kreditkartentransaktionen US-Standards reflektiert teilweise Sicherheitsleitfaden für Anwendungscontainer DSGVO verweist auf Verarbeitung personenbezogener Daten (europ.: GDPR) GoBD Buchführung und Aufbewahrung elektronischer steuerrelevanter Daten Gesetzliche Vorschriften §8a BSIG BSI-Gesetz zum Schutz kritischer Infrastrukturen (KRITIS) §203 StGB Verletzung von Privatgeheimnissen verweist auf * Illustration - kein Anspruch auf Vollständigkeit
33. Shared Responsibility
34. Shared Responsibility
35. Beispiel IAM
36. Customer domain SOP provided by - customer, - customer’s partners - other Syncier ventures -Syncier Cloud or Syncier Cloud third level support (Subjected to SLA)
37. Requirements & Regulations Building Blocks Syncier internal Security and Compliance ISO 27001 / 270xx GDPR CIS NIST BSI ... *) C5 -> Cloud Computing Compliance Controls Catalogue We provide audit-proof operation We offer a compliant DevSecOps toolstack We provide secure CI/CD We manage your certificates We offer automated compliance controls We provide IAM tooling We provide a centralized policy management We provide layered security Services, Blueprints & Security as a Service Customers Security and Compliance Integrated Security Framework We guide you how to use our managed clusters We provide managed clusters for secure operation We provide secure defaults PCI DSS Customer requirements Certified Vendors e.g. AWS Internal controls - C5* aligned ISMS - Documentation Auditable organization and operations We provide self service for policies
38. Technical building blocks
39. Continuous Delivery Policies: ❏ All images are signed ❏ No image contains a known vulnerability ❏ All images are assigned to a certain layer ❏ All deployments are audited ❏ All deployments are done by 4-eyes principle (PR exists on a protected deployment branch) ❏ All images are derived from whitelisted base image ❏ ... Cluster Runtime Policies: ❏ No newer patch level exists for running image ❏ All communication paths are secured with mTLS 1.2 (encryption & workload identity) and a valid OIDC token (user identity) ❏ Inbound traffic to a service is checked against an ACL ❏ ... k8s Admission Controller k8s Network Policy Clair / OWASP results Copper.sh rules k8s Pod Security Policy Istio Traffic Mgmt Policy Istio Auth Policy Jenkins pipeline anatomy SonarQube rules Continuously Enforced Policies (guards, spys, responders) Ecosystem of Policy Enforcement Points Compliance Sources ISO 27001 GDPR BAFIN HIPAA CIS NIST BSI ... ... Avoiding security & compliance debt by continuously enforcing policies
40. Continuous Security Continuous Compliance Secure by Design ❏ Automated security scanning ❏ Continuously monitor running applications ❏ Bill of Material - know what is running and their security risks ❏ Life forensics and incident response ❏ Technical enforcement, rollout and monitoring of policies ❏ ISMS and C5 certification + certified IaaS providers ❏ SIEM - Monitoring and acting on audit events ❏ Architecture providing and enforcing 0-Trust Networking, workload identification, strong isolation, and secure building blocks ❏ Central and natural policy enforcement points ❏ Secure and compliant Software Development Lifecycle
41. Container-as-a-Service (CaaS) Platform-as-a-Service (PaaS) Syncier Cloud Technology Blueprint: Building blocks Developer Collaboration Continuous Integration Developer Chat Continuous Quality Developer Self Service Service Provisioning Package Management Platform Provisioning Infrastructure Provisioning Secret & Cert Management Continuous Compliance Secure Software Supply Chain Backup & Recovery SIEM | Audit Log Incident Response Orchestration SOP Automation Alerting Metrics Traces Logs APM Billing, Accounting & Reporting Continuous Delivery Provisioning Continuous Security SRE Toolchain Diagnosability (Cluster & Apps) Infrastructure-as-a-Service (IaaS) Hardware Virtualization Bare Metal API Management Microservice Platform Customer IAM Service Mesh | Egress | DC-Connect Nanoservice Platform Dataservice Platform Legacy Platform Microservice Chassis Nanoservice Chassis Dataservice Chassis Legacy Chassis Kubernetes-as-a-Service Cluster Virtualization Secure Container Runtime Secure Native Storage Secure Cloud Native Network Infrastructure Image Registry Ingress | Web Layer Continuous Delivery
42. Container-as-a-Service (CaaS) Platform-as-a-Service (PaaS) The PaaS is assembled of a sane default choice of open source components github, gitlab, Bitbucket Open Service Broker & kube-apps HELM KaaS-specific tooling Terraform, Ansible Vault, cert-manager, SPIFFE Phylake (CFi project), OPA PagerDuty, OpsGenie k8s CRDs Grafana, Prometheus, Elastert Prometheus + Grafana Jaeger EFK Instana, Dynatrace, Kiali WunderBAR (CFi project) Continuous Delivery Provisioning Continuous Security SRE Toolchain Diagnosability (Cluster & Apps) AWS, Azure, Google Cloud OpenStack vmWare Bare Metal Kong, tyk Microservice Platform Keycloak Istio, Consul Connect Nanoservice Platform Dataservice Platform Legacy Platform Spring Boot, Microprofile Knative, Fn, OpenFaaS, … Spark, Flink, kubeflow, … LEAP (CFi project) Rancher, Gardener, Kubermatic AKS, EKS, GKE Cluster Virtualization Docker, CRI-O Falco infrastructure-native, Portworx, Quobyte, Rook infrastructure-native, Cilium, Calico, weave Infrastructure nginx, traefik, metallb, Gimbal, Istio/Envoy Jenkins/JX, gitlab, Concourse, Knative Slack, Mattermost SonarQube, jQAssistant CLI, ChatBot,UI, YAML Artifactory, Nexus, Harbor QAradiator, QAtorch ,Jenkins,/JX, gitlab, Spinnaker, Concourse, Knative Clair, copper.sh, Grafeas, Anchore ark, infrastructure-native EFK, SIEMonster, Metron, OSSIM
43. Policy Management
44. Policy management goals Centralized policy management Bridging business and technical policies Uniform real-time policies Security & compliance by default creates confidence and auditability helps executives, security officers architects, developers and auditors to work together. prevent costly mistakes saves time and effort
45. What kinds of policies do we see? Cluster policies Network policies Secure CI/CD policies Data governance policies Custom applications policies Namespaces, isolation, RBAC, container security, runtime compliance 0-Trust networking, data flow governance Compliance and security gates, archival requirements , prevent deployment of vulnerable applications §203, GDPR labeled data - isolation, stay in region Externalization of policy based decisions
46. Isolation
47. Isolation Customer Tenant Service Cluster User Cluster 1 * 1 1 1 * A department / team at the customer using one installation of the CFi stack Roughly: Dev- and Build Infrastructure “Common Components” Roughly: Customer applications Master Cluster 1 1
48. team 2 dev team 1 prod Master cluster team 1 dev Service cluster Tenant IaaS Account Core principle: many clusters with distinct hosts for good isolation and no direct communication between nodes of different clusters. • Customer provides/owns AWS/Azure IaaS account • Syncier Cloud manages the Customers IaaS account • Syncier Cloud installs and manages the Tenant setup • A Tenant setup consists of at least 3 different distinct Kubernetes clusters: ◦ Syncier Cloud operates a Master and a Service cluster ◦ Customer can have 1-n “customer-clusters” • Each cluster has its own: ◦ set of distinct IaaS hosts ▪ in an availability zone of customers choice ◦ distinct network ◦ storage ◦ rights and roles management ... Isolation - cluster overview
49. Isolation - responsibility Tennant IaaS Account ... Customer Syncier Cloud Managed team 1 dev Storage ns1 mgmt team 2 dev Storage ns1 mgmt team 1 prod Storage ns1 mgmt Service cluster Storage artifact- ory mgmt Syncier Cloud runs THE cloud and clusters Customer runs workloads IN the cloud Customer has full rights on his clusters Customer can have as many clusters and namespaces as they like Customer is responsible to have a roles&rights concept for their employees. IAM Account Storage Keycloak AD Master cluster Storage orchest rator ...
50. Ergebnissdokumentation
52. Key Takeaways • Cloud ist nur ein weiteres Datacenter - aber mit mehr Möglichkeiten Risiken auf Dienstleister zu übertragen ◦ Security und compliance Fragen sind selten cloud spezifisch • Security denkt in technischen konkreten Lösungen - Compliance in, teils abstrakten, Risiken. Gegenseitiges Verständnis und Vertrauen zwischen Security und Compliance ist wichtig um eine Gute Lösung zu finden • Wir wissen eigentlich was für Security zu machen ist… .. meist ist es aber eine Frage der Compliance ◦ dabei geht es ganz oft um die Daten (Was, Wofür, Wo, Wer, Wie, Wie lange) ▪ und die anforderungen der Gesetzgeber/Regulierer ▪ “darf ich Daten in/außerhalb dieses Landes verarbeiten?” ◦ und um die Risiken ▪ welche haben wir und wie adressieren wir sie ▪ wie weisen wir und unsere Dienstleister nach, was wir gegen die Risiken unternehmen • Shared Responsibility von Betrieb “der Cloud” (IaaS, PaaS Dienstleister) und Betrieb “in der Cloud” ◦ alle Daten(-sicherheits)fragen müssen vom Auftraggeber beantwortet werden ◦ zur Erfüllung der Anforderungen können wir Services der Cloud/Plattform nutzen. ◦ Cloud bietet chancen Papier Prozesse (deployment/Freigabe) zu automatisieren. • Security und Compliance Fragen und Maßnahmen müssen im Kontext des Business Case / der Anwendung betrachtet werden. ◦ Mit einem Sicherheitskonzept die Stakeholder abholen (Datenschützern, Information Security Officer,..) - Denn Sie kennen weder euren use case noch alle modernen Technologien und Schutzmaßnahmen. -> Ein Konzept schafft Diskussionsgrundlage und Vertrauen