News
Das Neuste aus der Welt von Adfinis SyGroup
Gil Oliveira (CCO Adfinis) und Thomas Graf (CTO & Co-Founder Isovalent)
Ab September 2022 erweitert Adfinis ihr Cloud Native Portfolio mit Isovalent, um eine Vielzahl von Herausforderungen zu lösen, welche beim Betrieb von geschäftskritischen Kubernetes Plattformen auftreten.
Durch Isovalent erweitert Adfinis ihr Partnerportfolio im Bereich der eBPF-basierten Cloud Native Networking-Lösungen. Mit Isovalent Cilium Enterprise erhalten Kunden eine der besten CNI-Lösung, welche Sicherheit, Auditierbarkeit, Skalierbarkeit und eine hervorragende Performance bietet.
Unternehmen adaptieren Cloud Native Methoden und Technologien, um Dev-Teams bei der agilen Entwicklung und Integration von Anwendungen zu unterstützen und so die Time-to-Market zu verkürzen. Der Wechsel in den Cloud Native Bereich bedeutet oft auch die Einführung und den Betrieb von Kubernetes, was neue Herausforderungen in Bereichen wie Netzwerk-, Sicherheits- und Compliance-Anforderungen mit sich bringt, insbesondere im Umfeld von geschäftskritischen Services in einer Zero Trust Umgebung.
Isovalent Cilium Enterprise adressiert die komplexen Abläufe im Zusammenhang mit IT-Security, Forensik, Compliance, rollenbasierter Zugriffskontrolle sowie der Integration von Legacy-Infrastrukturen. So werden Plattformteams unterstützt, die mit Anwendungs- und Sicherheitsteams innerhalb einer Unternehmensorganisation zusammenarbeiten.
“Mit Adfinis erweitern wir unsere Partnerlandschaft in DACH, BENELUX und APAC und freuen uns darauf, gemeinsam qualitativ hochwertige technische Projekte und 24/7-Services zu liefern, um die Geschäftskontinuität in geschäftskritischen Umgebungen zu gewährleisten.”
– Philipp Meier, Global Head of Partner Ecosystem, Isovalent
Adfinis verfolgt seit vielen Jahren die Mission, ganzheitliche Cloud Native Lösungen für ihre Kunden anzubieten und begrüsst Cilium Enterprise als wichtige Ergänzung des Cloud Native und Security Journey Portfolios.
“Wir halten immer die Augen offen nach Lösungen, die in unser Portfolio passen. Cilium Enterprise entspricht perfekt unseren Anforderungen, um die fehlenden Netzwerk- und Sicherheitsfunktionen sowie die Auditierbarkeit für unsere Kubernetes-Kunden bereitzustellen. Die Lösung in Verbindung mit den richtigen Personen und der richtigen Denkweise passt hervorragend in unser Portfolio.”
– Gil Oliveira, CCO Adfinis
Wie alle unsere Partner wird auch Isovalent und ihre Lösung Cilium Enterprise in die Adfinis Journeys integriert, die nicht nur das Subscription-Geschäft, sondern auch professionelle Dienstleistungen und Expertise rund um Planung, Aufbau und Betrieb der Lösung umfassen.
Michael Moser übernimmt ab dem 1. Juli 2022 die neue Position als CGO. Gil Oliveira wird seine Nachfolger als CCO antreten.
Die Firma Adfinis, eine führende Schweizer IT-Dienstleisterin für Open Source Lösungen, hat per 1. Juli 2022
Michael Moser zum Chief Strategy & Growth Officer (CGO) und Gil Oliveira zum neuen Chief Commercial Officer (CCO) ernannt. Die Adfinis treibt ihr internationales Wachstum erfolgreich voran, welches zu einer neuen Strukturierung der Führungspositionen leitete. Als Unternehmen ist Adfinis fest entschlossen, nachhaltige Lösungen ohne Vendor Lock-in und mit digitaler Souveränität anzubieten.
Neues C-Level mit internationalem Fokus
Michael Moser, Gründer von Adfinis und Verwaltungsratspräsident, wird in seiner Rolle als CGO das internationale Wachstum vorantreiben. Er wird eng mit bestehenden und neuen Niederlassungen zusammenarbeiten und eine nachhaltige Unternehmensentwicklung, unter Berücksichtigung der lokalen Marktbedürfnisse, sicherstellen.
Adfinis schätzt ihre starken Partnerschaften mit Anbietern von Open Source Software, wie HashiCorp, Red Hat, SUSE und GitLab. Michael Moser wird diese Partnerschaften mit einem internationalen Fokus ausbauen und gezielt entwickeln. Darüber hinaus werden sein Know-how sowie sein Branchenverständnis dazu beitragen, das Portfolio von Adfinis durch die Implementierung neuer Produkte zu erweitern und das Wachstum mit skalierbaren Lösungen zu beschleunigen. Er wird auch weiterhin das Sales-Team bei der Betreuung von strategischen Kunden mit seiner umfangreichen Erfahrung unterstützen. Adfinis freut sich sehr, dass Michael Moser diese neuen Aufgaben übernimmt und die hervorragenden sowie langjährigen Partnerschaften weiter stärkt.
Gil Oliveira übernimmt die Rolle als CCO
Als langjähriges Mitglied des Sales-Teams und mit seiner umfassenden Erfahrung mit Kunden sowie dem Partner-Ökosystem von Adfinis wird Gil Oliveira die Rolle des CCO übernehmen.
Seit 2006 hielt Gil Oliveira verschiedene Positionen bei Adfinis inne – vom System Engineer über Support-Manager bis hin zur Pre-Sales-Rolle. Zuletzt war er als Leiter des Sales-Operations-Teams tätig. Die Übernahme der neuen Verantwortung ist ein konsequenter Schritt und unterstreicht seine hervorragende Erfolgsbilanz im Adfinis Sales-Team. In seiner Rolle als CCO wird er sich für die Führung des Schweizer Sales-Teams, die Überwachung der Verkaufsziele sowie die Umsetzung von Vertriebsstrategien verantwortlich zeichnen.
Als ownCloud Channel Partner und Service Provider bietet Adfinis gemeinsam mit ownCloud vollumfängliche Dienstleistungen für Kunden, welche eine sichere Lösung zur Verwaltung und Bearbeitung ihrer Daten suchen. Dank jahrelanger Erfahrung im Open Source Bereich ist Adfinis der ideale Ansprechpartner auf jeder Stufe der Collaboration Journey, von Beratung und Planung (Plan), über technische Integration (Build), zu Betrieb und Support (Run).
ownCloud ist eine Open-Source-Software zur Synchronisierung und gemeinsamen Nutzung von Dateien und Inhalten, die Teamarbeit überall und auf jedem Gerät unkompliziert möglich macht. ownCloud kann auf einem Server vor Ort oder in jedem vertrauenswürdigen Rechenzentrum eines Drittanbieters, sowie der Cloud betrieben werden. Zudem kann ownCloud via ownCloud.online als Software-as-a-Service-Lösung bezogen werden.
Mit ownCloud haben Kunden jederzeit die volle Kontrolle über Speicherort und Zugriffsrechte ihrer Daten. Damit bietet ownCloud maximale Sicherheit für sensible Daten, Compliance Einhaltung und Nachvollziehbarkeit. Dazu sorgen die Open Source Spezialisten von Adfinis für die unkomplizierte Migration von bestehenden Daten in die eigene Cloud, integrieren ownCloud nahtlos in bestehende IT-Infrastrukturen und ermöglichen die bedürfnisgerechte sowie sorgenfreie Nutzung von ownCloud. Dabei kann Adfinis auf Erfahrungen aus ownCloud Kundenprojekten und über 20 Jahre Erfahrung im Bereich Open Source zurückgreifen.
ownCloud bietet unter anderem die folgenden Features:
- Verbesserung der Zusammenarbeit: Steigerung der Produktivität durch einfache, flexible und sichere gemeinschaftliche Nutzung von Dateien und Ordnern, sowie Einsparung von Speicherkapazität und Bandbreite.
- Standortunabhängige Produktivität: Finden, bearbeiten und teilen von Dokumenten auf Mobilgeräten, ob im Büro, zu Hause oder unterwegs. Nahtlos und in Echtzeit gerät- und plattformunabhängig zusammenarbeiten.
- Teilen von Dateien mit externen Kontakten: Benutzern eine einfache, sichere und vertrauenswürdige Möglichkeit bieten, sensible Informationen mit Externen auszutauschen.
- Sicherheit geht vor: Berechtigten Nutzern Dateien und Ordner zur Verfügung stellen und diese vor unberechtigtem Zugriff schützen.
- Datenschutzkonformität gewährleisten: Modernste Zusammenarbeit per Fernzugriff, die selbst die strengsten Vorschriften erfüllt.
- File Lifecycle: Archivieren und Löschen von Dateien, deren Fälligkeitsdatum überschritten ist, um den Datenschutz zu gewährleisten.
Adfinis hat die Entwicklung von ownCloud immer mit grossem Interesse verfolgt. Dabei ist die kürzlich angekündigte neue ownCloud Infinite Scale in den Fokus gerückt. ownCloud Infinite Scale ist komplett neu in Go programmiert und mit moderner Microservice-Architektur ausgestattet, wodurch die neue ownCloud schnell und skalierbar wird. Bei internen Tests zeigte sich Adfinis begeistert von der Geschwindigkeit und geringen Latenz der neuen ownCloud Infinite Scale.
Mit dem renommierten CERN konnte bereits ein erster namhafter Kunde von ownCloud Infinite Scale überzeugt werden.
Über ownCloud
ownCloud entwickelt und integriert Open-Source-Software für die digitale Zusammenarbeit, mit der Teams von überall und von jedem Gerät aus problemlos gemeinsam auf Dateien zugreifen und sie bearbeiten können. Bereits mehr als 100 Millionen Menschen weltweit nutzen ownCloud als Alternative zu öffentlichen Clouds – und entscheiden sich damit für mehr digitale Souveränität, Sicherheit und Datenschutz. Weitere Informationen befinden sich unter https://owncloud.com/ und auf Twitter unter @ownCloud.
Der Open Source Dienstleister Adfinis und Snyk, führender Anbieter von Security-Lösungen für Entwickler:innen, schliessen eine Partnerschaft. Als Vertriebs- und Integrationspartner von Snyk bringt Adfinis die bei Entwickler:innen und Sicherheitsteams gleichermassen beliebte Plattform für Anwendungssicherheit zu Kundinnen und Kunden in der Schweiz, Holland und Australien.
Snyk ist die Plattform, die Entwickler:innen wählen, um cloud native applications sicher zu erstellen. Sie ermöglicht es mit IDE- und SCM-Integrationen noch während des Programmierens nach Schwachstellen zu suchen. Diese können so schnell und frühzeitig automatisch behoben und die daraus gewonnen Erkenntnisse direkt umgesetzt werden. Dadurch kann die Einführung neuer Schwachstellen in die Codebasis, durch neue Abhängigkeiten und Codeänderungen, verhindert werden. Mit Berichten und Warnungen wird sichergestellt, dass der Überblick über die Sicherheitslage der Anwendung in allen Entwicklungsteams gegeben ist. Die Verwaltung ist durch unternehmensweit definierte und angepasste Sicherheits- und Lizenzrichtlinien, sowie kontextbezogene Priorisierung möglich.
Dadurch ermöglicht Snyk Entwickler:innen die umfassende Integration von mehr Sicherheit. Relevante Anwendungs- und Sicherheitsinformationen werden in eine SaaS-Plattform integriert, wobei die Produkte sowohl die Anforderungen von älteren und neueren Systemen, einschliesslich Open Source, Container und Infrastructure as code erfüllen. Damit bietet Snyk Sicherheit über den cloud native application stack hinweg und ermöglicht die Sicherung aller Komponenten einer modernen nativen Cloud-Anwendung.
Snyk wird bereits von Millionen von Entwicklern und mehr als 1’200 Kunden eingesetzt, darunter Asurion, Google, Intuit, MongoDB, New Relic, Revolut und Salesforce. Die Kunden und Nutzer von Snyk haben in den letzten 12 Monaten mehr als 300 Millionen Tests durchgeführt, sowie mehr als 30 Millionen Sicherheitslücken innerhalb der letzten 90 Tage behoben. In der Schweiz zählt Snyk Helvetia zu seinen Kunden. Die Schweizer Entwickler:innen von Helvetia schätzen an Snyk vor allem die Qualitätssicherung während der Entwicklung. Kürzlich konnte Snyk eine Finanzierungsrunde in Höhe von 530 Millionen Dollar, bei einer Bewertung von 8.5 Milliarden Dollar, abschliessen. Durch das Investment werden die Produktinnovation und -entwicklungen von Snyk weiter vorangetrieben. Einige davon werden diese Woche auf der kostenlosen jährlichen Entwicklerkonferenz von Snyk, der SnykCon 2021, vorgestellt. Auf der SnykCon werden neue Erweiterungen für die Anwendungssicherheits-Plattform, neue Workflow-Integrationen, sowie verbesserte und neue Funktionen präsentiert.
“Als Open Source Dienstleister waren wir auf der Suche nach einer Lösung, die sich insbesondere im Umfeld von offenen Technologien bewährt und den Security und Compliance Anforderungen unserer Kunden Rechnung trägt. Snyk passt hervorragend in diese Lücke und ergänzt unser Portfolio um ein wichtiges Puzzle-Teil im Bereich DevSecOps.” Nicolas Christener, CEO & CTO Adfinis AG
Über Snyk
Snyk, der Marktführer für Anwendungssicherheit, unterstützt Entwickler weltweit dabei, sichere Anwendungen zu entwickeln, und stattet Sicherheitsteams für die Anforderungen der digitalen Transformation aus. Bei Snyk stehen die Entwickler im Mittelpunkt, und Unternehmen können somit alle kritischen Anwendungskomponenten, vom Code bis zur Cloud, sicher gestalten. Dies ermöglicht eine effizientere Arbeit für Entwickler und bringt mehr Umsatzwachstum und grössere Kundenzufriedenheit, bei gleichzeitigen Kosteneinsparungen und einer verbesserten Sicherheit. Die Plattform für Anwendungssicherheit von Snyk lässt sich nahtlos in den Arbeitsablauf von Entwicklern integrieren und wurde speziell für die Zusammenarbeit von Sicherheits- und Entwicklerteams entwickelt. Snyk wird aktuell von 1.200 Kunden weltweit genutzt, darunter Branchenführer wie Asurion, Google, Intuit, MongoDB, New Relic, Revolut und Salesforce. Snyk wird in den Forbes Cloud 100 2021 und den CNBC Disruptor 50 2021 aufgeführt und wurde im Gartner Magic Quadrant 2021 für AST als Visionär eingestuft.
The general availability of the Key Management Secrets Engine in Vault 1.7+ent or higher facilitates the creation, management and deployment of symmetric and asymmetric cryptographic keys from HashiCorp Vault to remote keystores. Currently, this enterprise engine supports the Azure Key Vault as a target Key Management System (KMS), but ships beta support for AWS KMS already. The engine is part of the Vault Enterprise Advanced Data Protection (ADP) offering and useful for enterprises required to control the lifecycle of cryptographic keys (creation, distribution, rotation, revocation, etc.).
Use Vault >= 1.7.2+ent. It includes a fix for a panic error that occurred on audit logging while reading keys from the engine.
The engine increases the portability of cryptographic keys, because the secret key can be distributed to remote key stores while protecting the original key source in Vault. Prevalent security modules or keystores keep secret key material locked tight. For instance, the Azure Key Vault does not support export operations on the private key, i.e., allows exporting the public part of the key material only, not the actual secret. In this sense, the Vault Key Management Secrets Engine represents a holistic solution to generate, maintain and transport secret cryptographic material.
This post captures a few thoughts on how the Key Management Secrets Engine can meet the requirement for secure cryptographic keys of your business. For technical details on how to use the Key Management Secrets Engine refer to HashiCorp learn, the official documentation for the secrets engine and the corresponding API documentation page.
Contact us to explore how Vault can be implemented in your workflows and environment to protect your applications key and cover your secret management needs.
Why to Use Your Own Key
Use the terminology with a grain of salt. The content on which this blog post is based evolved during the last year and was adapted frequently to changes in the upstream documentation.
The Key Management Secrets Engine opens the door for a plenary of interesting application scenarios. Among others, it allows the distribution of cryptographic keys to Azure Key Vault. The keys in Azure Key Vault can then be consumed by a myriad of downstream applications:
- Encryption at rest for Azure VM Disks: Azure Disk Encryption (ADE) or Server-Side Encryption (SSE) for Azure Disks
- Encryption at Rest for Azure Storage (Blob, Files)
- Bring Your Own Key (BYOK) for Azure Azure Information Protection (AIP)
Clearly, the Vault Key Management Secrets Engine is beneficial for applications that use the keys stored in the remote key management systems. For example, keys in Azure Key Vault can be used to protect data in Snowflake (data warehouse). With the “tri-secret secure” Snowflake enterprise feature, Snowflake encryption keys can be combined with a BYOK key to create a composite master key for data protection. Thus, data can no longer be decrypted if either one of the keys is revoked, the key in Azure Key Vault originating at HashiCorp Vault or the key maintained by Snowflake.
The Key Management Secrets Engine also enables some use cases which might not be obvious on first sight and lead back to Vault as downstream consumer. For instance, the engine can be used to manage and keep in charge of cloud keys which are used to unseal other Vault clusters (i.e., backup of the actual cloud auto-unsealing keys and not just the recovery keys).
Procedures for the distribution of customer-managed keys to cloud environments (cloud key management or key brokering) can be categorized in Hold Your Own Key (HYOK) or Bring Your Own Key (BYOK) solutions.
Fig. 1: HYOK, BYOK or mixed use cases with the HashiCorp Vault Key Management Secrets Engine
The two abbreviations or terms are easily confused and flexed to a certain degree. In a mixed HYOK/BYOK scenario, the remote service requests the key material from HashiCorp Vault. The request is initiated at the consumer side (pull mode). The request can be directed immediately to Vault (e.g, authenticated with the Vault JWT backend) or intercepted by an intermediary API, such as the Distributey key wrapper. No Key Management Secrets Engine is needed in this situation, because the Vault Transit engine is sufficient to implement a scenario where the remote service fetches the key material from Vault. This mixed model with an intermediary API sources the keys from the Vault Transit engine. It proved useful in situations where the remote service cannot retrieve key material from a remote key store supported by the Vault Key Management Secrets Engine.
Depending on the understanding and definition of HYOK, the remote service may not be allowed to read the plain-text user data (data opacity). In this purest form of the HYOK model, the user is in possession of the private key and the raw payload (user data) at all times and actually “owns and holds the key”. As a result, data protected by a local key cannot be automatically encrypted and processed by cloud applications without the users consent. This restrictive form of protection is suitable for very sensitive data that requires no processing in the cloud. The private key is not transferred to the remote service at all, rather, data is encrypted before transmission. However, there exists no agreement on this mental model for HYOK and the term HYOK is therefore not always treated equally across cloud providers. For example, secret key material is cached in the cache-only key service by Salesforce, which was labeled a HYOK solution until recently, whereas Azure insists that the private key remains on premises when using HYOK. Hence, the location of the cache and the cache TTL can make the exact identification of HYOK and BYOK solutions a fuzzy affair. Azure permits the operation of both key paradigms, HYOK and BYOK. It is recommended to use the BYOK paradigm for AIP as well, since the AIP classic client is deprecated and the HYOK approach mainly targeted this classic client.
In contrast to HYOK, the key material is pushed from Vault to the remote service when using BYOK. In other words, there is usually no inbound request from the service provider. In practice, the BYOK approach is easier to implement, because engineering efforts for additional infrastructure (key wrapper) can be neglected. Also, publishing the API of a key wrapper (interface or actual HashiCorp Vault) increases the potential attack surface.
From a legal perspective, the HYOK method is oftentimes favored because of the aforementioned mental image of a pure HYOK implementation. HYOK enjoys a more advantageous wording, and if implemented very restrictively, can be considered superior from a security point of view.
Obviously, the short list of use cases above and the schematic example scenarios in Fig. 1 can never be conclusive. Get in touch with us to explore how Vault can fulfill the key brokering requirements of your specific business case.
Key Wrapping in Transport and at Rest
Independent of the exact model for key distribution (Key Management Secrets Engine or Transit engine combined with on-prem wrapping API), the cryptographic keys are usually exchanged with the industry standard JSON Web Encryption format (JWE, see RFC7516). JWE leverages a combination of symmetric (shared) and asymmetric key encryption to encrypt the key material during transport. The Vault Key Management Secrets Engine abstracts this wrapping process. In other words, wrapping procedures (JWE) are taken care of by HashiCorp Vault when the Key Management Secrets Engine is applied in a BYOK transfer, which clearly is an advantage compared to mixed or pure HYOK style of transfers.
Double encryption, composite or wrapped keys are common techniques to protect the user data in the remote service with a local key from on-premises (the BYOK key). In this way, the trust radius spans multiple parties, since both the key of the data owner and the cloud provider are required to decrypt and process the payload. An example scenario for key transport includes three types of keys:
- Data Encryption Key (DEK): Local target key from HashiCorp Vault which will be used to encrypt the user data. This key can be generated with the Transit or Key Management Secrets Engine, depending on the “own key model” depicted in Fig. 1 and the interoperability capabilities of the remote service with common cloud key stores such as AWS KMS or Azure Key Vault.
- Content Encryption Key (AES CEK): Locally generated key for key wrapping
- Key Encryption Key (RSA KEK): Key pair of the key consumer
Fig. 2: Transmission of a wrapped key to a remote service
The Data Encryption Key (DEK) is the target key material from the Vault Transit engine and first encrypted with an ephemeral AES wrapping key (CEK). In a second step, the CEK is encrypted with the public key of the receiver (KEK). The doubly encrypted keys are both part of the message sent to the remote service. The remote service decrypts the CEK and unpacks the DEK to finally encrypt user data.
An additional key hierarchy in the cloud service can benefit from the same double encryption technique at rest, similar to the one used during transport, to further organize and simplify key management or to improve performance of encryption/decryption operations for large amounts of data.
Different from the general technique of wrapping keys or data within multiple layers of encryption, the Double Key Encryption service is an actual piece of software developed by Microsoft to ensure that user data cannot be encrypted without a local key. Nevertheless, the RSA keys for this local service could also be sourced and managed with the HashiCorp Transit engine.
Similarly to the Distributey key wrapper in a mixed HYOK/BYOK model (see Fig. 1), the request to retrieve key material would also be initiated by the service provider. However, unlike the Distributey key wrapper, the Double Key Encryption service only returns the public key for encryption. This message does not require JWE or wrapping for protection. The purpose of the Double Key Encryption service is different from the Distributey (or any other) key wrapper API, because it is used to decrypt data locally and does not act as a proxy for transferring secret key material.
How to Distribute Keys from HashiCorp Vault to Azure Key Vault
The general process for distributing encryption keys from HashiCorp Vault to Azure Key Vault can be summarized as follows:
1. Enable the Key Management Secrets Engine in Vault
2. Create a named cryptographic key of a specific type (e.g., 2048 bit RSA key)
3. Configure the KMS provider in Vault with the credentials of the Azure service principal
4. Distribute the key from step (2) to Azure Key Vault
Vault Key Management for Azure Information Protection (AIP)
“Azure Information Protection (AIP) is a cloud-based solution that enables organizations to discover, classify, and protect documents and emails by applying labels to content.”
What is Azure Information Protection?
When the Vault Key Management Secrets Engine provisions the tenant root key for Azure Information Protection (AIP), the KEK used to protect the DEK from Vault is derived from an HSM protected Azure Key Vault (premium SKU). The tenant root key for AIP can be rekeyed later on in response to a data breach or changing organizational structures. Compared to a key solely managed by the cloud provider, the key lifecycle is primarily determined by the actions performed in HashiCorp Vault. With a BYOK created in HashiCorp Vault, organizations have more control over key operations compared to a tenant key which is only managed by Microsoft.
The key specifications for the intended target key store and application usage should be carefully planned for. For instance, to construct key material that can later be used for AIP, a 2048 bit RSA key is recommended. Fortunately this type of key is supported by the HashiCorp Key Management Secrets Engine as well. As mentioned previously, it is required to use the premium tier Key Vault backed by an HSM for performing BYOK procedures on Azure Key Vault, because the KEK can not be derived from keys stored in software protected Key Vaults (standard tier). Moreover, the Azure service principal needs the correct Azure access policy on the Azure Key Vault. Finally, the key purpose is not to be confused with the Azure Key Vault access policy. It defines the permitted Azure Key Vault operations and can be specified at distribution time.
To begin exploring HashiCorp Vault with the Transit and Key Management Secrets Engine on your own, start your free trial for Vault Enterprise today and let us know how Adfinis can support your business to keep being in charge of secrets and key material.
