Compliance und Governance in der DevOps-Acht

•

0 gefällt mir•254 views

In der Cloud leben wir im Spannungsfeld zwischen Enterprise Compliance und Continuous Delivery. Wie schaffen wir es, dass Entwickler:innen schnell Wert liefern können, ohne dabei Compliance und Governance zu vernachlässigen oder die DevOps-Acht zu unterbrechen? Wir zeigen anhand von verschiedenen Beispielen wie wir diese Herausforderungen lösen und wie bei uns Shift Left gelebt wird.

Präsentationen & Vorträge

Governance und Compliance in der
DevOps 8
Stefan Johner, Christof Leuenberger, Mathias Schnydrig

Vorstellung
v.l.n.r. Stefan Johner, Mathias Schnydrig, Christof Leuenberger
Bereits
unterwegs in die
verdienten Ferien

Cloud Grundsätze der Mobiliar für Eigenentwicklung
Higher Level
Services
Standard
Schnittstellen
Zero Trust Everything as
Code

Shift Left
https://devopedia.org/shift-left

Zusammenarbeit mit CISO & IT Security Architektur
Abstim-
mungs-
meetings
Einbezug
in PI
Planning
Security
Architektur
in ART
Troika
Vorgaben
mit ein-
beziehen
Cloud
Review
Shows
ITSA
operativ
im Cloud
Team

Transparenz und Steuerung des Deployment-Prozesses
20.06.2022 9
Graph API
Reporting
Delivery Information
Gitlab

Nachvollziehbarkeit von Änderungen in der Produktion
Delivery Information
Build Acceptance Publish Deploy
Gitlab

Peer Review von Codeänderungen
Peer Review
Trunk-based
Development
Kritischer
Source Code

Tech Stacks
• Applikationsplattform ist eine stabile, performante und
einheitliche Basis, auf der Applikationen
(Anwendungsprogramme) entwickelt und ausgeführt
werden.
• Tech Stacks sind eine Sammlung an Tools, Praktiken und
Libraries um mit einer bestimmten Technologie
Applikationen für eine Applikationsplattform zu entwickeln
• Wir unterscheiden zwischen Infrastruktur und Business
Tech Stacks

Software Composition Analysis (SCA)
https://snyk.io/series/open-source-security/software-composition-analysis-sca/
• Unzählige Open Source Software Pakete fliessen heute in einen Software Build. Jedes dieser
Artefakte könnte theoretisch kompromittiert sein.
• Security Teams können bei heutigem Entwicklungstempo unmöglich Schritt halten
• Sicherheitslücken können (und treten primär) in transitiv eingebetteten Paketen auf
• Bekannte Sicherheitslücken werden bewertet (CVSS) und in zentralen Datenbanken (z.B. NVD)
anhand von Paket Namen und Version eindeutig erfasst (CVE Nummer)
• SCA Software scannt bei jedem Pipeline Durchlauf alle verwendeten Software Pakete sowie
deren Lizenzen und vergleicht sie gegen definierte Policies (erlaubte Lizenzen, tolerierte CVSS
Level)
• SCA wird bei uns unabhängig des Tech Stacks implementiert

Static Application Security Testing (SAST)
• Statische Analyse von Source Code nach Code und Design
Mustern, die auf eine potentielle Sicherheitslücke hinweisen
• Innensicht auf die Applikation zur build-time (anstatt zur runtime)
• SAST wird bei uns von den Tech Stacks eigenständig
implementiert
https://about.gitlab.com/resources/whitepaper-seismic-shift-application-security/
Tech Stack SAST Umsetzung
Frontend (Angular, Node) Eslint Security Plugin, Semgrep
Backend Services (Java, Quarkus) SpotBugs
Machine Learning (Python) Pylint
Cloud Infrastructure (Terraform) tfsec

SLSA
Supply Chain Levels for Software Artifacts (salsa)
SLSA ist ein Security Framework – eine Checkliste von Standards und Kontrollen um die Integrität
von Software Artefakten sicherzustellen.
https://slsa.dev ∙ https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html

Continuous Governance / Policy As Code
• In Anlehnung an die Herangehensweisen Infrastructure
as Code und DevOps werden Policies, Initiatives und
Assignments in Code definiert und in der Pipeline
automatisierbar angewandt
• DevOps Teams können selbstständig Ressourcen
provisionieren und sind dafür verantwortlich, dass ihre
Ressourcen compliant sind.
• Ressourcen die eine Policy verletzen werden beim ersten
Deployment-Versuch zu einem Fehler führen.
Nachträglich non-compliant Ressourcen werden im Azure
Portal ausgewiesen.
https://www.microsoft.com/en-us/insidetrack/enabling-enterprise-governance-in-azure

Weitere ähnliche Inhalte

Was ist angesagt?

Video recording of this presentation: https://youtu.be/upWzamacOVQ Blog post with more details: https://www.kai-waehner.de/blog/2020/04/24/mainframe-offloading-replacement-apache-kafka-connect-ibm-db2-mq-cdc-cobol/ Mainframes are still hard at work, processing over 70 percent of the world’s most essential computing transactions every day. Very high cost, monolithic architectures, and missing experts are the key challenges for mainframe applications. Time to get more innovative, even with the mainframe! Mainframe offloading with Apache Kafka and its ecosystem can be used to keep a more modern data store in real-time sync with the mainframe. At the same time, it is persisting the event data on the bus to enable microservices, and deliver the data to other systems such as data warehouses and search indexes. But the final goal and ultimate vision are to replace the mainframe by new applications using modern and less costly technologies. Stand up to the dinosaur, but keep in mind that legacy migration is a journey! Kai will guide you to the next step of your company’s evolution! You will learn: - how to not only reduce operational expenses but provide a path for architecture modernization, agility and eventually mainframe replacement - what steps some of Confluent’s customers already took, leveraging technologies like Change Data Capture (CDC) or MQ for mainframe offloading - how an event streaming platform enables cost reduction, architecture modernization, and a combination of a mainframe with new technologies

Mainframe Integration, Offloading and Replacement with Apache Kafka

Kai Wähner

I see the following topics coming up more regularly in conversations with customers, prospects, and the broader Kafka community across the globe: Kappa Architecture: Kappa goes mainstream to replace Lambda and Batch pipelines (that does not mean that there is no batch processing anymore). Examples: Kafka-powered Kappa architectures from Uber, Disney, Shopify, and Twitter. Hyper-personalized Omnichannel: Retail and customer communication across online and offline channels becomes the new black, including context-specific upselling, recommendations, and location-based services. Examples: Omnichannel Retail and Customer 360 in Real-Time with Apache Kafka. Multi-Cloud Deployments: Business units and IT infrastructures span across regions, continents, and cloud providers. Linking clusters for bi-directional replication of data in real-time becomes crucial for many business models. Examples: Global Kafka deployments. Edge Analytics: Low latency requirements, cost efficiency, or security requirements enforce the deployment of (some) event streaming use cases at the far edge (i.e., outside a data center), for instance, for predictive maintenance and quality assurance on the shop floor level in smart factories. Examples: Edge analytics with Kafka. Real-time Cybersecurity: Situational awareness and threat intelligence need to process massive data in real-time to defend against cyberattacks successfully. The many successful ransomware attacks across the globe in 2021 were a warning for most CIOs. Examples: Cybersecurity for situational awareness and threat intelligence in real-time.

The Top 5 Apache Kafka Use Cases and Architectures in 2022

Kai Wähner

Presenter: Tim Berglund, Senior Director of Developer Experience, Confluent It has become a truism in the past decade that building systems at scale, using non-relational databases, requires giving up on the transactional guarantees afforded by the relational databases of yore. ACID transactional semantics are fine, but we all know you can’t have them all in a distributed system. Or can we? In this talk, I will argue that by designing our systems around a distributed log like Apache Kafka®, we can in fact achieve ACID semantics at scale. We can ensure that distributed write operations can be applied atomically, consistently, in isolation between services, and of course with durability. What seems to be a counterintuitive conclusion ends up being straightforwardly achievable using existing technologies, as an elusive set of properties becomes relatively easy to achieve with the right architectural paradigm underlying the application.

Dissolving the Problem (Making an ACID-Compliant Database Out of Apache Kafka®)

confluent

고급 클라우드 아키텍처 방법론- 양승도 솔루션즈 아키텍트:: AWS Cloud Track 2 Advanced

Amazon Web Services Korea

AWS Black Belt Online Seminar 2016 AWS CloudFormation

Amazon Web Services Japan

클라우드 네이티브로의 전환이 확산되면서 애플리케이션을 상호 독립적인 최소 구성 요소로 쪼개는 마이크로서비스(microservices) 아키텍쳐가 각광받고 있는데요. MSA는 애플리케이션의 확장이 쉽고 새로운 기능의 출시 기간을 단축시킬 수 있다는 장점이 있지만, 반면에 애플리케이션이 커지고 동일한 서비스의 여러 인스턴스가 동시에 실행되면 MSA간 통신이 복잡해 진다는 단점이 있습니다. 서비스 메쉬(Service Mesh)는 이러한 MSA의 트래픽 문제를 보완하기 위해 탄생한 기술로, 서비스 간의 네트워크 트래픽 관리에 초점을 맞춘 네트워킹 모델입니다. 서로 다른 애플리케이션이 얼마나 원활하게 상호작용하는지를 기록함으로써 커뮤니케이션을 최적화하고 애플리케이션 확장에 따른 다운 타임을 방지할 수 있습니다. 서비스 메쉬의 탄생 배경과 기능, 그리고 현재 오픈소스로 배포되어 있는 서비스 메쉬 솔루션에 대해 소개합니다. Step1. Cloud Native Trail Map Step2. Service Proxy, Discover, & Mesh Step3. Service Mesh 솔루션 Step4. Service Mesh 구현화면 - Istio / linkerd Step5. Multi-cluster (linkerd)

[오픈소스컨설팅] 서비스 메쉬(Service mesh)

Open Source Consulting

Real-time data streaming is a hot topic in the Telecommunications Industry / Telecom Sector. As telecommunications companies strive to offer high speed, integrated networks with reduced connection times, connect countless devices at reduced latency, and transform the digital experience worldwide, more and more companies are turning to Apache Kafka’s data stream processing solutions to deliver a scalable, real-time infrastructure for OSS and BSS scenarios. Enabling a combination of on-premise data centers, edge processing, and multi-cloud architectures is becoming the new normal in the Telco Industry. This combination is enabling accelerated growth from value-added services delivered over mobile networks. Join Kai Waehner, Technology Evangelist at Confluent, for this session which explores various telecommunications use cases, including data integration, infrastructure monitoring, data distribution, data processing and business applications. Different architectures and components from the Kafka ecosystem are also discussed. This talk explores: - Overcome challenges for building a modern hybrid telco infrastructure - Build a real time infrastructure to correlate relevant events - Connect thousands of devices, networks, infrastructures, and people - Work together with different companies, organisations and business models - Leverage open source and fully managed solutions from the Apache Kafka ecosystem, Confluent Platform and Confluent Cloud

Apache Kafka in the Telco Industry (OSS, BSS, OTT, IMS, NFV, Middleware, Main...

Kai Wähner

AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと

Takayuki Ishikawa

마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017

Amazon Web Services Korea

금융 회사를 위한 클라우드 이용 가이드 – 신은수 AWS 솔루션즈 아키텍트, 김호영 AWS 정책협력 담당:: AWS Cloud Week ...

Amazon Web Services Korea

While many organizations have started to automate their software development processes, many still engineer their infrastructure largely by hand. Treating your infrastructure just like any other piece of code creates a “programmable infrastructure” that allows you to take full advantage of the scalability and reliability of the AWS cloud. This session will walk through practical examples of how AWS customers have merged infrastructure configuration with application code to create application-specific infrastructure and a truly unified development lifecycle. You will learn how AWS customers have leveraged tools like CloudFormation, orchestration engines, and source control systems to enable their applications to take full advantage of the scalability and reliability of the AWS cloud, create self-reliant applications, and easily recover when things go seriously wrong with their infrastructure.

infrastructure as code

Amazon Web Services

JenkinsとCodeBuildとCloud Buildと私

Shoji Shirotori

Microservice architectures are not free lunch! Microservices need to be decoupled, flexible, operationally transparent, data aware and elastic. Most material from last years only discusses point-to-point architectures with inflexible and non-scalable technologies like REST / HTTP. This video takes a look at cutting edge technologies like Apache Kafka, Kubernetes, Envoy, Linkerd and Istio to implement a cloud-native service mesh to solve these challenges and bring microservices to the next level of scale, speed and efficiency. Key takeaways: - Apache Kafka decouples services, including event streams and request-response - Kubernetes provides a cloud-native infrastructure for the Kafka ecosystem - Service Mesh helps with security and observability at ecosystem / organization scale - Envoy and Istio sit in the layer above Kafka and are orthogonal to the goals Kafka addresses Blog post: http://www.kai-waehner.de/blog/2019/09/24/cloud-native-apache-kafka-kubernetes-envoy-istio-linkerd-service-mesh Video recording of this slide deck: https://youtu.be/Us_C4RFOUrA

Service Mesh with Apache Kafka, Kubernetes, Envoy, Istio and Linkerd

Kai Wähner

Skillsmatter CloudNative eXchange 2020 The microservice architecture is a key part of cloud native. An essential principle of the microservice architecture is loose coupling. If you ignore this principle and develop tightly coupled services the result will mostly likely be yet another "microservices failure story”. Your application will be brittle and have all of disadvantages of both the monolithic and microservice architectures. In this talk you will learn about the different kinds of coupling and how to design loosely coupled microservices. I describe how to minimize design time and increase the productivity of your DevOps teams. You will learn how how to reduce runtime coupling and improve availability. I describe how to improve availability by minimizing the coupling caused by your infrastructure.

Designing loosely coupled services

Chris Richardson

Identity and access control for custom enterprise applications - SDD412 - AWS...

Amazon Web Services

(Gwen Shapira + Matthias J. Sax, Confluent) Kafka Summit SF 2018 Kafka Streams, Apache Kafka’s stream processing library, allows developers to build sophisticated stateful stream processing applications which you can deploy in an environment of your choice. Kafka Streams is not only scalable, but fully elastic allowing for dynamic scale-in and scale-out as the library handles state migration transparently in the background. By running Kafka Streams applications on Kubernetes, you will be able to use Kubernetes powerful control plane to standardize and simplify the application management—from deployment to dynamic scaling. In this technical deep dive, we’ll explain the internals of dynamic scaling and state migration in Kafka Streams. We’ll then show, with a live demo, how a Kafka Streams application can run in a Docker container on Kubernetes and the dynamic scaling of an application running in Kubernetes.

Deploying Kafka Streams Applications with Docker and Kubernetes

confluent

Apache Kafka and Event Streaming are two of the most relevant buzzwords in tech these days. Ever wonder what the predicted TOP 5 Event Streaming Architectures and Use Cases for 2021 are? Check out the following presentation. Learn about edge deployments, hybrid and multi-cloud architectures, service mesh-based microservices, streaming machine learning, and cybersecurity. On-demand video recording: https://videos.confluent.io/watch/XAjxV3j8hzwCcEKoZVErUJ

Top 5 Event Streaming Use Cases for 2021 with Apache Kafka

Kai Wähner

Apache Kafka is an open-source event streaming platform used to complement or replace existing middleware, integrate applications, and build microservice architectures. Used at almost every large company today, it's understood, battled-tested, highly scalable, and reliable. Blockchain is a different story. Being related to cryptocurrencies like Bitcoin, it's often in the news. But what is the value of software architecture? And how is it related to an integration architecture and event streaming platform? This session explores blockchain use cases and different alternatives such as Hyperledger, Ethereum, and Kafka-native blockchain implementation. We discuss the value blockchain brings for different architectures, and how it can be integrated with the Kafka ecosystem to build a highly scalable and reliable event streaming infrastructure. This talk discusses the concepts, use cases, and architectures behind Event Streaming, Apache Kafka, Distributed Ledger (DLT), and Blockchain. A comparison of different technologies such as Confluent, AIBlockchain, Hyperledger, Ethereum, Ripple, IOTA, and Libra explores when to use Kafka, a Kafka-native blockchain, a dedicated blockchain, or Kafka in conjunction with another blockchain.

Apache Kafka and Blockchain - Comparison and a Kafka-native Implementation

Kai Wähner

Kubecost and NGINX have recently partnered together to provide a more comprehensive solution for managing cost and performance when deploying Kubernetes. The Kubecost platform helps organizations optimize and monitor their Kubernetes costs, while NGINX is a leading open source software web server, reverse proxy and ingress controller. Together, they offer a powerful combination of cost optimization and application delivery capabilities, enabling you to gain greater visibility into your Kubernetes environments and achieve better performance and efficiency. On-Demand Link https://www.nginx.com/resources/webinars/managing-kubernetes-cost-performance-with-nginx-kubecost/

Managing Kubernetes Cost and Performance with NGINX & Kubecost

NGINX, Inc.

Apache Kafka for Real-time Supply Chainin the Food and Retail Industry

Kai Wähner

Was ist angesagt? (20)

Mainframe Integration, Offloading and Replacement with Apache Kafka

The Top 5 Apache Kafka Use Cases and Architectures in 2022

Dissolving the Problem (Making an ACID-Compliant Database Out of Apache Kafka®)

고급 클라우드 아키텍처 방법론- 양승도 솔루션즈 아키텍트:: AWS Cloud Track 2 Advanced

AWS Black Belt Online Seminar 2016 AWS CloudFormation

[오픈소스컨설팅] 서비스 메쉬(Service mesh)

Apache Kafka in the Telco Industry (OSS, BSS, OTT, IMS, NFV, Middleware, Main...

AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと

마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017

금융 회사를 위한 클라우드 이용 가이드 – 신은수 AWS 솔루션즈 아키텍트, 김호영 AWS 정책협력 담당:: AWS Cloud Week ...

infrastructure as code

JenkinsとCodeBuildとCloud Buildと私

Service Mesh with Apache Kafka, Kubernetes, Envoy, Istio and Linkerd

Designing loosely coupled services

Identity and access control for custom enterprise applications - SDD412 - AWS...

Deploying Kafka Streams Applications with Docker and Kubernetes

Top 5 Event Streaming Use Cases for 2021 with Apache Kafka

Apache Kafka and Blockchain - Comparison and a Kafka-native Implementation

Managing Kubernetes Cost and Performance with NGINX & Kubecost

Apache Kafka for Real-time Supply Chainin the Food and Retail Industry

Ähnlich wie Compliance und Governance in der DevOps-Acht

JCON 2018, Düsseldorf: Vortrag von Mario-Leander Reimer (@LeanderReimer, Cheftechnologe bei QAware) Abstract: Jahrzehnte lang haben wir mehr oder weniger erfolgreich monolithische Enterprise Applikationen gebaut. Leider können diese Systeme und deren Betriebsmodelle den hohen Anforderungen moderner Geschäftsmodelle nur noch schwer genügen. Kurze Release-Zyklen, Antifragilität und Hyperscale scheinen unerreichbar zu sein. Was also tun? Muss man diese Systeme alle neu bauen? Das ist sicherlich kein besonders ökonomischer und sinnvoller Weg. Dieser Vortrag zeigt mögliche Wege der Cloud-nativen Evolution von Bestandssystemen und berichtet aus der Praxis.

Steinzeit war gestern! Wege der Cloud-nativen Evolution.

QAware GmbH

DACHNUG50 Volt MX & AppScan_20230615.pdf

DNUG e.V.

Migration von Aftersales Systemen auf eine Cloud Plattform

QAware GmbH

Architektur und Automation als Enabler für DevOps

matfsw

On the Portability of Applications in Platform as a Service

Stefan Kolb

Test- und Produktionsumgebungen gehören zum täglich Brot von Entwicklungs-, Test- und Adminteams. In der Praxis sieht man dabei sehr oft das Phänomen, dass die diversen Umgebungen immer wieder von den Beteiligten händisch angelegt und gepflegt werden. In modernen DevOps-Prozessen ist dieses Vorgehen nicht mehr zeitgemäß, fehleranfällig und zu teuer. Im Vortrag soll vorgestellt werden, wie Umgebungen mit modernen Deployment- und Verwaltungskonzepten in Azure betrieben und automatisch deployt werden können. Die Grundlage für die Build-, Deployment- und Testautomatiseriung bildet hierbei Team Foundation Server bzw. Team Foundation Team Services.

Basta 2016 - Test- und Releaseumgebungen in der Cloud

Marc Müller

Log4j war erst der Anfang.pdf

Stephan Kaps

Um agile Entwicklung sinnvoll in einem Projekt zu ermöglichen, spielt die Architektur des Systems eine entscheidende Rolle. In einem agilen Projekt sind Architektureigenschaften wie Installierbarkeit und Prüfbarkeit entscheidend, da die Software in kurzen Abständen regelmäßig geliefert und im besten Fall dem Endnutzer zur Verfügung gestellt wird. Diese kurzen Releasezyklen gelingen nur durch ein hohes Maß an Automatisierung. Agile Projekte benötigen bereits passende Lösungsansätze in der Architektur, die es erlauben eine Continous Delivery Pipeline möglichst einfach zu realisieren; das Architekturmuster „Microservices“ versucht u.A. diesen Anforderungen gerecht zu werden. Weitere Vorteile des Architekturmusters ergeben sich bei der Skalierung von Projekten. Durch den Einsatz von „Microservices“ können Projekte einfach aufgeteilt und parallel von mehreren Cross-Functional Teams mit agilen Methoden umgesetzt werden. Die Idee eines Microservice ist nicht neu: das System wird in kleine, losgelöste Anwendungen (sog. Microservices) aufgeteilt. Diese Bausteine stellen Ihre Funktionalität als Service zur Verfügung. Der Vortrag gibt einen Praxiseinblick, auf welche Weise man vom Einsatz des Architekturmusters „Microservice“ in einem agilen Projektumfeld profitieren kann. Es wird aufgezeigt, wo sich in der Praxis Schwierigkeiten ergeben und wie man diesen vorbeugen kann. Der gesamte Vortrag gibt einen grundlegenden Einblick in die agile Entwicklung auf Basis einer Microservice-Architektur.

Microservices – die Architektur für Agile-Entwicklung?

Christian Baranowski

ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...

Aberla

IT-Tage 2018, Frankfurt: Vortrag von Mario-Leander Reimer (@LeanderReimer, Cheftechnologe bei QAware) === Dokument bitte herunterladen, falls unscharf! Please download slides if blurred! === Abstract: Jahrzehnte lang haben wir mehr oder weniger erfolgreich monolithische Enterprise Applikationen gebaut. Leider können diese Systeme und deren Betriebsmodelle den hohen Anforderungen moderner Geschäftsmodelle nur noch schwer genügen. Kurze Release-Zyklen, Antifragilität und Hyperscale scheinen unerreichbar zu sein. Was also tun? Muss man diese Systeme alle neu bauen? Das ist sicherlich kein besonders ökonomischer und sinnvoller Weg. Dieser Vortrag zeigt mögliche Wege der Cloud-nativen Evolution von Bestandssystemen und berichtet aus der Praxis.

Steinzeit war gestern! Wege der cloud-nativen Evolution

QAware GmbH

Continuous Lifecycle 2018, Mannheim: Vortrag von Mario-Leander Reimer (@LeanderReimer, Cheftechnologe bei QAware) === Dokument bitte herunterladen, falls unscharf! Please download slides if blurred! === Abstract: Jahrzehnte lang haben wir mehr oder weniger erfolgreich monolithische Enterprise Applikationen gebaut. Leider können diese Systeme und deren Betriebsmodelle den hohen Anforderungen moderner Geschäftsmodelle nur noch schwer genügen. Kurze Release-Zyklen, Antifragilität und Hyperscale scheinen unerreichbar zu sein. Was also tun? Muss man diese Systeme alle neu bauen? Das ist sicherlich kein besonders ökonomischer und sinnvoller Weg. Dieser Vortrag zeigt mögliche Wege der Cloud-nativen Evolution von Bestandssystemen und berichtet aus der Praxis.

Steinzeit war gestern! Wege der cloud-nativen Evolution

QAware GmbH

Sicherheit ist leider immer noch eine allzu häufig vernachlässigte nicht-funktionale Eigenschaft heutiger IT-Systeme. Auftraggeber haben oft nur die implizite Erwartung an ein sicheres System. Wir als Entwickler konzipieren und bauen aber genau das, was explizit gefordert wurde. Mit manchmal unangenehmen Konsequenzen. Das Nachrüsten von Sicherheit in ein bestehendes System ist arbeitsintensiv, zeitaufwändig und teuer. Einfacher ist es, die Sicherheit bereits vom ersten Tag an mit zu berücksichtigen. Hört sich schwierig an? Das muss nicht sein. Dieser Vortrag präsentiert einfache Regeln, Tools, Technologien und Entwurfsmuster für sichere Systemarchitekturen, die ein sicherheitsorientierter Entwickler oder Architekt definitiv kennen sollte. @heise_devSec @qaware #heisedevsec

Das kleine Einmaleins der sicheren Architektur @heise_devSec

Mario-Leander Reimer

OOP 2020, Februar 2020, München: Vortrag von Mario-Leander Reimer (@LeanderReimer, Technischer Geschäftsbereichsleiter bei QAware) == Dokument bitte herunterladen, falls unscharf! Please download slides if blurred! == Abstract: Holistische Sicherheit für Microservice-Architekturen ist komplex: Eine Vielzahl an Infrastruktur-Bausteinen, Technologien und Betriebseinheiten mit ihren API-Endpunkten und Kommunikationskanälen muss berücksichtigt werden. Hier braucht es ein flexibles und vor allem mehrschichtiges Vorgehen. Dieser Vortrag gibt einen Überblick zu Ansätzen, relevanten Schutzmechanismen und Technologien zur Absicherung von Microservice-Architekturen auf Ebene der Infrastruktur, der Plattform und der Anwendung.

Holistische Sicherheit für Microservice Architekturen

QAware GmbH

Continuous Testing Days, Mai 2021, online: Vortrag von Mario-Leander Reimer (@LeanderReimer, Principal Software Architect bei QAware) == Please download slides if blurred! == Abstract: Viele Teams straucheln immer noch dabei regelmäßig gut getestete Produktinkremente zu liefern. Normalerweise mit der gleichen alten Ausrede: speziell die (nicht)-funktionale Tests seien zu aufwändig und zu teuer umzusetzen. Doch genau das Gegenteil ist der Fall!

Kontinuierliches (Nicht)-Funktionales Testen von Microservices auf K8s

QAware GmbH

The Architecture Gathering 2018, München: Vortrag von Mario-Leander Reimer (@LeanderReimer, Cheftechnologe bei QAware) Abstract: Jahrzehnte lang haben wir mehr oder weniger erfolgreich monolithische Enterprise-Applikationen gebaut. Leider können diese Systeme und deren Betriebsmodelle den hohen Anforderungen moderner Geschäftsmodelle nur noch schwer genügen. Kurze Release-Zyklen, Antifragilität und Hyperscale scheinen unerreichbar zu sein. Was also tun? Muss man diese Systeme alle neu bauen? Das ist sicherlich kein besonders ökonomischer und sinnvoller Weg. Dieser Vortrag zeigt mögliche Wege der Cloud-nativen Evolution von Bestandssystemen und berichtet aus der Praxis.

Steinzeit war gestern! Wege der Cloud-nativen Evolution.

QAware GmbH

//heise devSec() 2017, Heidelberg: Vortrag von Mario-Leander Reimer (@LeanderReimer, Cheftechnologe bei QAware) und Simon Bäumler (Softwarearchitekt bei QAware). Abstract: Sicherheit ist leider immer noch eine allzu häufig vernachlässigte nicht-funktionale Eigenschaft heutiger IT-Systeme. Auftraggeber haben oft nur die implizite Erwartung an ein sicheres System. Wir als Entwickler konzipieren und bauen aber genau das, was explizit gefordert wurde. Mit manchmal unangenehmen Konsequenzen. Das Nachrüsten von Sicherheit in ein bestehendes System ist arbeitsintensiv, zeitaufwändig und teuer. Einfacher ist es, die Sicherheit bereits vom ersten Tag an mit zu berücksichtigen. Hört sich schwierig an? Das muss nicht sein. Dieser Vortrag präsentiert einfache Regeln, Tools, Technologien und Entwurfsmuster für sichere Systemarchitekturen, die ein sicherheitsorientierter Entwickler oder Architekt definitiv kennen sollte.

Das kleine Einmaleins der sicheren Architektur

QAware GmbH

ECN Summit 2019, München: Workshop von Josef Adersberger (@adersberger, CTO QAware), Helmut Weiss (Beck et al.) und Mario Lohner (Syncier Cloud) Abstract: Um eine Anwendungslandschaft in die Zukunft zu führen wird immer deutlicher, dass kein Weg mehr an Cloud Native Plattformen wie Kubernetes vorbei führt. Eine flexiblere Entwicklung, hochfrequente Releases sowie geringere Betriebskosten und eine bessere Skalierbarkeit zählen mit zu den Hauptvorteilen dieser Technologie. Dies erreicht man jedoch nicht durch eine simple Migration der bestehenden Anwendungen in einen Container und einem Betrieb auf Kubernetes. Im Workshop gliedert sich dabei in drei Teile: - Migration von IT-Services in die Cloud - Migration von Anwendungen in die Cloud - Aufbau einer Kubernetes-Plattform mit Blick auf Day 2

Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...

QAware GmbH

Internet of Things Architecture

Christian Waha

Make Developers Fly – Helping developers to build better applications Cloud Native Night, Mainz, November 2023, Alex Krause Platform Engineering is the next stage of DevOps and accelerates software developers even more to build applications faster and bring products rapidly to the customers. In this meetup, we show you the key principles of platform engineering, as we experienced them in our projects, and additionally show you a better way to manage your internal software platforms. PRINCIPLES FOR PLATFORM ENGINEERING, Alex Krause How do we help our developers to fly instead of crashing miserablely? The answer is Platform Engineering, a discipline for building internal developer platforms (IDPs) to simplify software delivery for product teams. In this talk, you'll learn how Platform Engineering evolved from the DevOps movement and what principles and best practices make for a good implementation. Finally, we'll take a look at reference architectures that can support your platform.

Make Developers Fly: Principles for Platform Engineering

QAware GmbH

Software-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools

Andreas Schreiber

Ähnlich wie Compliance und Governance in der DevOps-Acht (20)

Steinzeit war gestern! Wege der Cloud-nativen Evolution.

DACHNUG50 Volt MX & AppScan_20230615.pdf

Migration von Aftersales Systemen auf eine Cloud Plattform

Architektur und Automation als Enabler für DevOps

On the Portability of Applications in Platform as a Service

Basta 2016 - Test- und Releaseumgebungen in der Cloud

Log4j war erst der Anfang.pdf

Microservices – die Architektur für Agile-Entwicklung?

ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...

Steinzeit war gestern! Wege der cloud-nativen Evolution

Das kleine Einmaleins der sicheren Architektur @heise_devSec

Holistische Sicherheit für Microservice Architekturen

Kontinuierliches (Nicht)-Funktionales Testen von Microservices auf K8s

Steinzeit war gestern! Wege der Cloud-nativen Evolution.

Das kleine Einmaleins der sicheren Architektur

Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...

Internet of Things Architecture

Make Developers Fly: Principles for Platform Engineering

Software-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools

Mehr von BATbern

Das BATbern52 fand wie folgt statt Datum: 8. März 2024, 16:00h - 19:00h Thema: "Data Mesh - Modernes Datenmanagement" Ort: Forum, Zentrum Paul Klee, Bern (Anfahrt) Beiträge: "Data Mesh: 2019, 2023 und 2024++", Simon Harrer, INNOQ "Skalierte Datenwertschöpfung mit Data Mesh", Bruno Russiniello, die Mobiliar, Lukas Feuz, die Mobiliar "Schöne neue Data Products und deren nicht nur technischen Knacknüsse", André Rogger, SBB "Swisscom's Journey into Data Mesh", Mirela Navodaru, Swisscom

BATbern52 Moderation Berner Architekten Treffen zu Data Mesh

BATbern

Swisscom is taking one bold step after another to become a data-driven company. The approach is always business-first: how to find data&AI-driven solutions to enable the business to make the best decisions to offer a great experience to our customers. Our journey with Data Mesh is no different. Together with the business, we looked at the current challenges of quickly transforming data into information and insights while having a crucial regard for data management and governance. I invite you to this session to go through our transformation from data to data products, how to foster co-creation between data producers and data consumers, and what it takes to create the right balance between central governance and decentralizing the accountability for its implementation.

BATbern52 Swisscom's Journey into Data Mesh

BATbern

Mit den Data Products und dem Data Mesh weht ein neuer Wind durch die Data Analytics-Stuben. Konzepte, die im Bereich des Software Engineerings bereits etabliert sind, werden für neue Analytics-Vorhaben entsprechend adaptiert. Dies Nähe zur Software Entwicklung ist nicht erstaunlich, stammen doch die Prinzipien des Data Mesh aus dem Umfeld von Martin Fowler. Die Grundgedanken sind bestechend einfach: das Data Product als eine klar abgegrenzte Einheit mit klaren Regeln und Daten, die einen Mehrwert für den Datennutzer bieten. Diese Data Products können in einer Mesh-Architektur miteinander verknüpft und zu einem funktionierenden Ganzen zusammengefügt werden. Damit soll der «Ad-Hoc»-Charakter, der vielen Analytics-Lösungen innewohnt, überwunden werden. Bei der Adaption von Data Products in eine bestehende Analytics-Landschaft müssen technische und organisatorische Hürden genommen und viel Überzeugungsarbeit in der Analytics-Gemeinde geleistet werden. Wir nehmen Euch mit auf diese Reise, die noch nicht zu Ende ist.

BATbern52 SBB zu Data Products und Knacknüsse

BATbern

Die Gruppe Mobiliar hat sich das Ziel gesetzt, 'unter jedem Dach daheim' zu sein und dabei ein optimales Kundenerlebnis zu bieten. Um dieses Ziel zu erreichen, setzt sie unter anderem auf eine skalierte Datenwertschöpfung als strategische Unternehmensfähigkeit. Bruno Russiniello und Lukas Feuz geben in dieser Präsentation Einblicke in die genaue Bedeutung dieses Ansatzes. Erfahren Sie, wie die Mobiliar durch die Nutzung von Datenprodukten die Digitalisierung aktiv vorantreibt.

BATbern52 Mobiliar zu Skalierte Datenprodukte mit Data Mesh

BATbern

Data Mesh ist ein soziotechnischer Ansatz für die Erstellung einer dezentralen Datenarchitektur. Zhamak Dehghani hat den Begriff Data Mesh und die Theorie dahinter mit ihren Blog-Beiträgen in 2019 bereits geprägt und dann mit ihrem Buch noch etwas ausführlicher beschrieben. Diese Theorie möchte ich kurz vorstellen, um für den Abend ein Begriffsfundament zu giessen. Seit 2019 ist jedoch viel passiert. Viele haben das Konzept gelesen und einige haben ihre Data Mesh Reise bereits begonnen. Ich möchte auf 2023 zurückblicken und den aktuellen Stand der Praxis beschreiben. Enden möchte ich mit einem Ausblick über die Top 5 Entwicklungen in Data Mesh, die dich total überraschen werden.

BATbern52 InnoQ on Data Mesh 2019 2023 2024++

BATbern

This presentation delves into the journey of transitioning an on-premises monolithic real estate application to a fully serverless, event-driven microservices stack on AWS. Explore the compelling business drivers that necessitated this shift, from traffic demands and team scalability to architectural flexibility. We'll unpack the challenges, from navigating many service choices to the cost implications. At the same time, we'll celebrate the undeniable advantages: improved security through AWS's shared responsibility model, the economic flexibility of a pay-as-you-go approach, and remarkable reliability and scalability.

Embracing Serverless: reengineering a real-estate digital marketplace

BATbern

Stirbt Serverless den Kubernetes-Tod bevor es richtig geboren wurde? Es gibt zumindest eine Domäne, in der Serverless definitiv lebendig und munter ist - das Internet der Dinge (IoT). In den letzten sieben Jahren wurden IoT-Systeme vermehrt unter Verwendung von Platform as a Service (PaaS) und Serverless-Diensten der Public Cloud Provider entwickelt. Dabei kommt die Event-Driven Architecture zum Einsatz, ein Muster, das sich sowohl für Serverless als auch für die asynchrone Natur von IoT-Systemen bestens eignet. Aber wie sehen solche Architekturen konkret aus? Warum sind gerade IoT-Anwendungen prädestiniert für Serverless? Und welche wertvollen Erkenntnisse können wir aus diesem Bereich für andere Anwendungsdomänen gewinnen? In dieser Session werden wir diese Fragen anhand von Beispielen aus der Azure-Welt genauer unter die Lupe nehmen.

Serverless und Event-Driven Architecture

BATbern

Die Schweiz, das Land der vielen Sprachen. Das Translation Portal der Raiffeisen Schweiz bietet verschiedenste Möglichkeite Übersetzungsprozesse zu standardisieren und automatisieren. Bei der Entwicklung des Portals wurden ausschliesslich cloud native Dienste und Methoden eingesetzt. Wir zeigen auf, wie Serverless Code durch vollautomatisierte Pipelines integriert, getestet und ausgerollt wird. Dabei erfahren Sie unter anderem was Serverless aus Sicht DevOps für die Raiffeisen Schweiz und im Allgemeinen bedeutet.

Serverless Dev(Ops) in der Praxis

BATbern

Serverless at Lifestage

BATbern

Keynote Gregor Hohpe - Serverless Architectures

BATbern

BATbern51 Serverless?!

BATbern

Peter Kummer leitet seit 2020 die Division Infrastruktur und ist Mitglied der Konzernleitung der SBB. Die Division Infrastruktur gewährleistet eine optimale Auslastung und Steuerung des Personen- und Güterverkehrs und ist für den Unterhalt, die Entwicklung und den Ausbau des Telekom- Strom- und Schienennetzes der SBB zuständig. Peter Kummer stiess 2007 als Chief IT Architect zu den Schweizerischen Bundesbahnen SBB. 2009 wurde er zum CIO und Mitglied der Konzernleitung der SBB ernannt. Vor dem Eintritt bei der SBB war Peter Kummer “Head of Enterprise Architecture & IT Strategy” bei der Versicherungsgesellschaft Die Mobiliar.

Ein Rückblick anlässlich des 50. BAT aus Sicht eines treuen Partners

BATbern

What powers the AI/ML services of Switzerland's leading telecommunication company? In this talk, we will provide an overview of the different AI/ML projects at Swisscom, from Conversational AI and Recommender Systems to Anomaly Detection. Moreover, we will show how we automate, scale, and operationalise these ML pipelines in production, highlighting the MLOps techniques and open source tools that are used. Finally, we will present Swisscom's roadmap towards the cloud with AWS and discuss how we envision a common MLOps solution for the organisation.

MLOps journey at Swisscom: AI Use Cases, Architecture and Future Vision

BATbern

Imagine a world where you transform a business problem into data specification, collect a data set, learn a ML model and put it into stable, scheduled production within 7 days – rather than spending weeks on data preparation and implementing a production pipeline. At Raiffeisen Data Science this became reality with our Scoring Factory, a ML OPs framework where all customer data is condensed and prepared in a 'feature data layer' - ready to be used for ML algorithms, and a “Scoring Template” with which ML models are created in hours and which delivers production ready code. This overcomes our biggest obstacles in implementing new ML use cases: Data preparation and deployment used to demand so much time, that we were very limited in taking on new ML use cases. In particular, we can now try new ideas fast and without the risk of too much initial time investment. The Scoring Factory is the so-far final piece in a 3 year long effort to build a versatile, automated, robust data platform which allows to unleash the full potential of customer analytics and which started with local models executed on desktop PCs. The foundation is the Customer Analytics Platform. A Hadoop-Cluster where data from various sources gets collected, cleaned, interconnected and aggregated, resulting in thousands of attributes describing the customer in any angle which the business needs to solve their questions. In this talk, we give details about the Architecture of the Customer Analytics Platform and the key ingredients of the Scoring Factory.

From Ideation to Production in 7 days: The Scoring Factory at Raiffeisen

BATbern

Data is a critical component of today management governance in all companies and industries, and so it is in sports as well. Data can be generated by a lot of different sources like human annotations, sensors, optical tracking and should be produced to help decision makers to take better decisions. The aim of this presentation is first to share Dartfish experience on today Data generation using AI and Machine Learning, but as well to explore the future usage of AI/ML in Data mining to produced better decision indicators.

The Future of Coaching in Sport with AI/ML

BATbern

MLOps-Prozesse und -Infrastruktur stellen die Grundlage dar für effizientes Entwickeln und nachhaltigen Betrieb von Machine Learning Modellen. Unser NLP Modell zur Klassifizierung von Versicherungsschäden veranschaulicht, wie die Mobiliar MLOps verwendet, um Mitarbeiter sowie Kunden zu befähigen und zu entlasten. Neben der Entwicklungsarbeit im interdisziplinären Team zeigen wir, wie das Modell in Geschäftsprozessen (B2E und B2C) eingebunden wird. Wir beleuchten anhand konkreter Beispiele, weshalb die MLOps-Prozesse und -Infrastruktur der Mobiliar zentral sind für die Entwicklung und den Betrieb von Machine Learning Modellen. Dabei sollen angetroffene Stolpersteine nicht ausgespart werden, zum Beispiel im Monitoring des Modells im Geschäftsprozess.

Klassifizierung von Versicherungsschäden – AI und MLOps bei der Mobiliar

BATbern

Bei Zero Trust wird keinem Akteur, der Zugang zu Ressorucen oder Diensten im Netzwerk will, von vornherein vertraut. Gemäss dem Motto «never trust, always verify» erfordert jede Abfrage im System eine neue Verifizierung. Es wird aufgezeigt, wie dies in einer Umgebung mit vielen verschiedenen Akteuren durchgängig umgesetzt werden kann. Dabei nehmen OAuth-Token und die Funktionalität Token-Exchange eine zentrale Rolle ein.

BATbern48_ZeroTrust-Konzept und Realität.pdf

BATbern

BATbern48_How Zero Trust can help your organisation keep safe.pdf

BATbern

BATbern48_Zero Trust Architektur des ISC-EJPD.pdf

BATbern

Why did the shift-left end up in the cloud for Bank Julius Baer?

BATbern

Mehr von BATbern (20)

BATbern52 Moderation Berner Architekten Treffen zu Data Mesh

BATbern52 Swisscom's Journey into Data Mesh

BATbern52 SBB zu Data Products und Knacknüsse

BATbern52 Mobiliar zu Skalierte Datenprodukte mit Data Mesh

BATbern52 InnoQ on Data Mesh 2019 2023 2024++

Embracing Serverless: reengineering a real-estate digital marketplace

Serverless und Event-Driven Architecture

Serverless Dev(Ops) in der Praxis

Serverless at Lifestage

Keynote Gregor Hohpe - Serverless Architectures

BATbern51 Serverless?!

Ein Rückblick anlässlich des 50. BAT aus Sicht eines treuen Partners

MLOps journey at Swisscom: AI Use Cases, Architecture and Future Vision

From Ideation to Production in 7 days: The Scoring Factory at Raiffeisen

The Future of Coaching in Sport with AI/ML

Klassifizierung von Versicherungsschäden – AI und MLOps bei der Mobiliar

BATbern48_ZeroTrust-Konzept und Realität.pdf

BATbern48_How Zero Trust can help your organisation keep safe.pdf

BATbern48_Zero Trust Architektur des ISC-EJPD.pdf

Why did the shift-left end up in the cloud for Bank Julius Baer?

Compliance und Governance in der DevOps-Acht

1. Governance und Compliance in der DevOps 8 Stefan Johner, Christof Leuenberger, Mathias Schnydrig

2. Vorstellung v.l.n.r. Stefan Johner, Mathias Schnydrig, Christof Leuenberger Bereits unterwegs in die verdienten Ferien

3. Cloud Grundsätze der Mobiliar für Eigenentwicklung Higher Level Services Standard Schnittstellen Zero Trust Everything as Code

4. Shift Left https://devopedia.org/shift-left

5. Shift Left – DevOps

6. Compliance in der Cloud sicherstellen

8. Zusammenarbeit mit CISO & IT Security Architektur Abstim- mungs- meetings Einbezug in PI Planning Security Architektur in ART Troika Vorgaben mit ein- beziehen Cloud Review Shows ITSA operativ im Cloud Team

9. Transparenz und Steuerung des Deployment-Prozesses 20.06.2022 9 Graph API Reporting Delivery Information Gitlab

10.

11.

12. Nachvollziehbarkeit von Änderungen in der Produktion Delivery Information Build Acceptance Publish Deploy Gitlab

13.

14. Peer Review von Codeänderungen Peer Review Trunk-based Development Kritischer Source Code

15. Mobi.yaml

16. Governance in der Cloud mit DevSecOps

17. Tech Stacks • Applikationsplattform ist eine stabile, performante und einheitliche Basis, auf der Applikationen (Anwendungsprogramme) entwickelt und ausgeführt werden. • Tech Stacks sind eine Sammlung an Tools, Praktiken und Libraries um mit einer bestimmten Technologie Applikationen für eine Applikationsplattform zu entwickeln • Wir unterscheiden zwischen Infrastruktur und Business Tech Stacks

18. Tech Stacks

19. Tech Stacks

20. Software Composition Analysis (SCA) https://snyk.io/series/open-source-security/software-composition-analysis-sca/ • Unzählige Open Source Software Pakete fliessen heute in einen Software Build. Jedes dieser Artefakte könnte theoretisch kompromittiert sein. • Security Teams können bei heutigem Entwicklungstempo unmöglich Schritt halten • Sicherheitslücken können (und treten primär) in transitiv eingebetteten Paketen auf • Bekannte Sicherheitslücken werden bewertet (CVSS) und in zentralen Datenbanken (z.B. NVD) anhand von Paket Namen und Version eindeutig erfasst (CVE Nummer) • SCA Software scannt bei jedem Pipeline Durchlauf alle verwendeten Software Pakete sowie deren Lizenzen und vergleicht sie gegen definierte Policies (erlaubte Lizenzen, tolerierte CVSS Level) • SCA wird bei uns unabhängig des Tech Stacks implementiert

21. Software Composition Analysis (SCA)

22. Software Composition Analysis (SCA)

23. Static Application Security Testing (SAST) • Statische Analyse von Source Code nach Code und Design Mustern, die auf eine potentielle Sicherheitslücke hinweisen • Innensicht auf die Applikation zur build-time (anstatt zur runtime) • SAST wird bei uns von den Tech Stacks eigenständig implementiert https://about.gitlab.com/resources/whitepaper-seismic-shift-application-security/ Tech Stack SAST Umsetzung Frontend (Angular, Node) Eslint Security Plugin, Semgrep Backend Services (Java, Quarkus) SpotBugs Machine Learning (Python) Pylint Cloud Infrastructure (Terraform) tfsec

24. SLSA Supply Chain Levels for Software Artifacts (salsa) SLSA ist ein Security Framework – eine Checkliste von Standards und Kontrollen um die Integrität von Software Artefakten sicherzustellen. https://slsa.dev ∙ https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html

25. SLSA https://slsa.dev/spec/v0.1/levels

26. Continuous Governance / Policy As Code • In Anlehnung an die Herangehensweisen Infrastructure as Code und DevOps werden Policies, Initiatives und Assignments in Code definiert und in der Pipeline automatisierbar angewandt • DevOps Teams können selbstständig Ressourcen provisionieren und sind dafür verantwortlich, dass ihre Ressourcen compliant sind. • Ressourcen die eine Policy verletzen werden beim ersten Deployment-Versuch zu einem Fehler führen. Nachträglich non-compliant Ressourcen werden im Azure Portal ausgewiesen. https://www.microsoft.com/en-us/insidetrack/enabling-enterprise-governance-in-azure

27. Continuous Governance / Policy As Code

28. Continuous Governance / Policy As Code

29. Fragen?

Compliance und Governance in der DevOps-Acht

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Compliance und Governance in der DevOps-Acht

Ähnlich wie Compliance und Governance in der DevOps-Acht (20)

Mehr von BATbern

Mehr von BATbern (20)

Compliance und Governance in der DevOps-Acht