News
Das Neuste aus der Welt von Adfinis SyGroup
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.
You have a vision: you want the development of your infrastructure to be as scalable and agile as the development of your applications. Infrastructure as code will help you achieve that goal. So you’ve found the right tool – Terraform – but is your organization ready for the transformation? We’ll show you the four cultural and organizational elements you need to successfully adopt infrastructure as code.
It goes without saying that to build the foundation for a successful infrastructure as code practice you need the right tool. But do you know how to use that tool properly? And have you thought about how that tool will sit in your IT ecosystem? Which clouds do you want to support with that tool? The answers to these questions will bring you up to speed. However, they won’t make a long-lasting difference until you look at the impact of infrastructure as code on your team and culture.
A shared vision – supported by leadership
Just implementing a potentially successful tool won’t help if you don’t have a vision. You need to know what you’re actually looking to achieve in order to know what tool suits your organization best. Of course, sometimes you just want to jump on the bandwagon. You’ve thought about DevOps and you’ve heard that infrastructure as code is a great first step to embracing this philosophy. But what do you want to achieve?
Or perhaps you’ve got a clear vision of what you want, but have you shared that vision with the rest of the organization? You need a vision that is supported by leadership, so you can have a top-down approach, inspire teams, including the necessary operation engineers, to dive into all things ‘code’ and have all the resources in place to make the transition. Once you’ve got everyone working towards the same goal, it’s time to look at how you can create the right culture.
A testing culture
The right culture is the translation of the infrastructure as code philosophy for your organization. The right culture is built up from different elements. Such as having a testing culture. Testing is a fundamental step for application developers: in order to know what to build and to check whether the feature actually does what it’s supposed to do, they’ll write tests and execute them before the application goes live.
Infrastructure as code is no different from application development: it should do something and once you’ve coded a certain automation, it should do what it was designed for. Makes sense, right? Well, that means you need to think about testing before you code your infrastructure, so you can checkmark your way through your day. It’s oddly satisfying of course, but it’s also a matter of hygiene.
A versioning culture
Since the development of your infrastructure occurs a lot faster today than before, when you were manually building your machines, it’s vital that you know when you did what. We recommend using any type of GIT program to keep track of your versions. GIT doesn’t only help you keep track of who did what, but it also helps you revert to specific versions, just in case something major goes wrong.
A culture of collaboration
What GIT version management also supports is collaboration: code is shared and can be worked on simultaneously. And since all parts of the infrastructure are built and managed with the same code, work can actually be shared or transferred. Which is also great if your engineer decides to leave the company or becomes ill. With GIT, new staff can easily see how the structure is built, what changes were made, and make any corrections.
Of course, change is always difficult. If you’ve been working a certain way for a long time, it’s often hard to see the value in anything else. However, you also need a more agile way of managing your infrastructure and easily scaling up or sizing down any cloud in order to support your business. See it like this: when you’re building the playground, make sure it’s safe and big enough for all the kids to play in. That’s a big deal, because your role saves lives. Bearing this piece of wisdom in mind might make stepping into the unknown a little easier.
And don’t forget – we can help you with just this challenge: how to prepare your organization for the infrastructure as code revolution with Terraform. We offer a Terraform training, tailor-made for your organization. In other words: it doesn’t matter how far you are on your infrastructure as code journey, we’re here to help.
