1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Qubes OS angeschaut: Abschottung…

Virtualisierung != Sicherheit

  1. Thema

Neues Thema Ansicht wechseln


  1. Virtualisierung != Sicherheit

    Autor: thewayne 21.10.14 - 12:29

    Um Theo de Raadt zu zitieren:

    "x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit. You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes."

    Erst vor zwei Wochen wurde das beim Bug in Xen mal wieder unter Beweis gestellt. Hier geht es zwar nicht um einen riesen x86 stack aber der glaube das Virtualisierung uns alle retten wird ist ein Irrtum.



    2 mal bearbeitet, zuletzt am 21.10.14 12:33 durch thewayne.

  2. Re: Virtualisierung != Sicherheit

    Autor: Wallbreaker 21.10.14 - 12:42

    Ein Bug? Verglichen mit der ansonsten, sehr hohen Zuverlässigkeit, darf das gerne mal passieren.
    Dieser Typ sollte grundsätzlich, immer gänzlich still sein, wenn er als Frontmann des OpenBSD Projektes, nichts Anderes zustande bringt, als Software Anderer als minderwertig zu bezeichnen. Natürlich mit Ausnahme der eigenen.

  3. Re: Virtualisierung != Sicherheit

    Autor: The-Master 21.10.14 - 12:42

    Also wenn es nur so typen gäbe, wie den den du zitiert hast, wären wir jetzt alle noch in einer höhle und würden solange steine aufeinander schlagen bis ein funke entsteht.

  4. Re: Virtualisierung != Sicherheit

    Autor: lala1 21.10.14 - 13:43

    Soso - das kann halt nur jemand sagen, der OpenBSD nicht kennt. Aber ich will dich nicht aus deiner Illusion von "Zukunft" heraus reisen - auf die Virtualisierung!

  5. Re: Virtualisierung != Sicherheit

    Autor: Dino13 21.10.14 - 13:50

    Es ist sowieso ein Fehler zu glauben es würde "die Zukunft" geben. Man sollte sich nie noch mehr einengen als nötig.

  6. Re: Virtualisierung != Sicherheit

    Autor: jaykay2342 21.10.14 - 13:57

    Mit der Argumentation kann man auch sagen: Was sollen all die Sandboxansätze in Browsern. Da wird ja auch immer mal wieder raus aus gebrochen. Es ist halt ein extra Layer, der natürlich nicht 100% sicher ist. 100% Sicherheit gibt es halt nicht außer man trennt sein Gerät von jeder Spannungsquelle. Dann ist es 100% sicher aber eben auch 100% nutzlos. Mit zunehmender Sicherheit sinkt halt der Komfort.

  7. Re: Virtualisierung != Sicherheit

    Autor: Sinnfrei 21.10.14 - 15:03

    Naja, kauf Du nur das Schlangenöl - alles hilft, solange man nur fest genug daran glaubt ...

    __________________
    ...

  8. Re: Virtualisierung != Sicherheit

    Autor: Marentis 21.10.14 - 15:49

    Qubes OS kostet nichts.
    Falls Du von Security Suites sprichst: diese hat jaykay2342 nicht einmal erwähnt.

  9. Re: Virtualisierung != Sicherheit

    Autor: jaykay2342 21.10.14 - 16:09

    Nein ich kauf kein Schlangenöl. Sandboxes oder VMs als Schlangenöl zu bezeichnen finde ich ehrlich gesagt auch etwas übertrieben. Wie ich sagte: sie sind ein extra Layer.

  10. Re: Virtualisierung != Sicherheit

    Autor: The-Master 21.10.14 - 19:27

    Doch doch, das kann ich durchaus sehr gut sagen.
    Vielleicht solltest du dir hier einfach mal die ersten paar sätze durchlesen:
    > https://de.wikipedia.org/wiki/OpenBSD#Geschichte_und_Verbreitung

    Zusammen mit dem zitat ergibt das schon ein recht gutes bild von dem typen und seinen umgangsformen.

  11. Re: Virtualisierung != Sicherheit

    Autor: drasojem 21.10.14 - 22:02

    Richtig Virtualisierung != Sicherheit. Aber das liegt wohl daran das es soetwas wie Sicherheit nicht gibt. Jede Software hat ihre Fehler oder Schwachstellen.
    Je größer die Software desto wahrscheinlicher ist es das sie Fehler enthält.
    Das Ziel von Qubes ist es die TCB (trusted code base) so klein wie möglich zu halten.
    Im falle von Xen sind das "nur" ein paar hundert tausend Zeilen code, was im vergleich zu Modernen OSs mit Millionen Zeilen und riesigen komplexen APIs wenig ist.

    Qubes optimiert sämtliche APIs die den VMs zur verfügung stellen (GUI, sound, etc.) nicht auf performance optimiert und überläd sie mit features sondern hält sie schlank und sehr einfach.
    Damit ist es zwar nicht ausgeschlossen das Schadsoftware aus einer VM ausbrechen kann, aber um Gößenordnungen unwahrscheinlicher als ein "einfacher" Kernel expliot.

  12. Re: Virtualisierung != Sicherheit

    Autor: gadthrawn 28.10.14 - 12:23

    drasojem schrieb:
    --------------------------------------------------------------------------------
    > Das Ziel von Qubes ist es die TCB (trusted code base) so klein wie möglich
    > zu halten.

    Das ist ja widerlich. Im allgemeinen Sprachjargon ist TCB trusted computing base.
    Und besteht aus allen Schichten (Hardware bis Softwareausführung) - und genau die TCB wird durch Virtualisierung verschlechtert. (Gibts beim acm viele papers zu..)

  13. Re: Virtualisierung != Sicherheit

    Autor: drasojem 03.12.14 - 11:34

    gadthrawn schrieb:
    --------------------------------------------------------------------------------
    > drasojem schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Das Ziel von Qubes ist es die TCB (trusted code base) so klein wie
    > möglich
    > > zu halten.
    >
    > Das ist ja widerlich. Im allgemeinen Sprachjargon ist TCB trusted computing
    > base.
    > Und besteht aus allen Schichten (Hardware bis Softwareausführung) - und
    > genau die TCB wird durch Virtualisierung verschlechtert. (Gibts beim acm
    > viele papers zu..)

    Das ist ja sehr interesannt, also ist es sinnvoller dem kompletten Linux Kernel inklusive sämtlicher treiber und APIs zu vertrauen, als einem schlanken type 1 Hypervisor? Ist es also einfacher mit einem Bug aus einer xen vm auszubrechen, als mit irgendeinem Bug in den zig apis in Linux (xserver, wifi/ ethernet treiber, etc.) root rechte zu erlangen? (zumal user rechte ja schon reichen um die nutzerdaten zu stehlen)
    Alleine das fehlen einer Vernünftigen gui-level isolation unter linux...

    Natürlich wird eine zusätzliche Schicht eingefürht, aber dafür wird eine viel größere und fettere Schicht abgetrennt die dann eben nicht mehr teil der TCB (egal ob code oder computing) ist.

    Edit:
    Auch wenn ich ihre Antwort spät gelesen habe würde mich brennend Interessieren in welchem Scenario Qubes verwundbarer ist als ein normales Linux. Da Sie sich in dem Thema ja scheinbar richtig gut auskennen und ganz viele Papers gelesen haben sollte das ja kein Problem sein.



    4 mal bearbeitet, zuletzt am 03.12.14 11:45 durch drasojem.

  14. Re: Virtualisierung != Sicherheit

    Autor: gadthrawn 03.12.14 - 14:41

    drasojem schrieb:
    --------------------------------------------------------------------------------
    > gadthrawn schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > drasojem schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Das Ziel von Qubes ist es die TCB (trusted code base) so klein wie
    > > möglich
    > > > zu halten.
    > >
    > > Das ist ja widerlich. Im allgemeinen Sprachjargon ist TCB trusted
    > computing
    > > base.
    > > Und besteht aus allen Schichten (Hardware bis Softwareausführung) - und
    > > genau die TCB wird durch Virtualisierung verschlechtert. (Gibts beim acm
    > > viele papers zu..)
    >
    > Das ist ja sehr interesannt, also ist es sinnvoller dem kompletten Linux
    > Kernel inklusive sämtlicher treiber und APIs zu vertrauen, als einem
    > schlanken type 1 Hypervisor? Ist es also einfacher mit einem Bug aus einer
    > xen vm auszubrechen, als mit irgendeinem Bug in den zig apis in Linux
    > (xserver, wifi/ ethernet treiber, etc.) root rechte zu erlangen? (zumal
    > user rechte ja schon reichen um die nutzerdaten zu stehlen)
    > Alleine das fehlen einer Vernünftigen gui-level isolation unter linux...
    >
    > Natürlich wird eine zusätzliche Schicht eingefürht, aber dafür wird eine
    > viel größere und fettere Schicht abgetrennt die dann eben nicht mehr teil
    > der TCB (egal ob code oder computing) ist.
    >
    > Edit:
    > Auch wenn ich ihre Antwort spät gelesen habe würde mich brennend
    > Interessieren in welchem Scenario Qubes verwundbarer ist als ein normales
    > Linux. Da Sie sich in dem Thema ja scheinbar richtig gut auskennen und ganz
    > viele Papers gelesen haben sollte das ja kein Problem sein.

    Einstieg wäre z.b. "An Exploration of L2 covert Channels" von Xu & Co.

  15. Re: Virtualisierung != Sicherheit

    Autor: drasojem 04.12.14 - 21:20

    Passend zur Überschrift Desktop != Server:

    Sie behaupten also ernsthaft, das ein covert channel, der nur unzuverlässig Zugriff auf häufig genutzte daten könnte auf einem Desktop(!) betriebssystem gefährlicher ist als z.B. unisolierte USB treiber? Klar auf einem Server werden teilweise grade private-keys sehr häufig verwendet und liegen daher oft im cache, aber das ist auf einem Desktop OS einfach nicht so der Fall. Zumal so ein Covert chanel auch vom Hypervisor verhindert werden kann (abgesehn von cooperative covert channels aber die sind eh nicht das Problem).
    Und natürlich kann ein Hypervisor einen Bug / Desingfehler enthalten, aber das Ihr einziges Argument gegen einen Hypervisor ein auf einem DesktopOS schwer auszunutzender Fehler ist, bestärkt eigentlich nur die Idee.

    Mal davon abgesehen, was hindert einen Prozess mit userrechten den eigenen rsa private key auszulesen und dann bei der passwortabfrage das passwort mitzuschneiden?
    Ist da nicht der weg über einen L2 covert channel erheblich schwieriger? (also ein sicherheits gewinn bei zusätzlicher isolationsschicht?)



    1 mal bearbeitet, zuletzt am 04.12.14 21:22 durch drasojem.

  16. Re: Virtualisierung != Sicherheit

    Autor: WolfgangS 07.12.14 - 16:14

    drasojem schrieb:
    --------------------------------------------------------------------------------
    > Passend zur Überschrift Desktop != Server:
    >
    > Sie behaupten also ernsthaft, das ein covert channel, der nur unzuverlässig
    > Zugriff auf häufig genutzte daten könnte auf einem Desktop(!)
    > betriebssystem gefährlicher ist als z.B. unisolierte USB treiber?

    Das ist relativ irrelevant. Einige Banken hierzulande warten mit USB Leser auf. Auch die Lesegeräte für verbindliche Amtsgeschäfte mit dem elektronischen Personalausweis laufen über USB. Elektronische Krankenkassenkarten - raten Sie mal. Alles mit Treibern und über Browser oder Software.



    1 mal bearbeitet, zuletzt am 07.12.14 16:17 durch WolfgangS.

  17. Re: Virtualisierung != Sicherheit

    Autor: gadthrawn 07.12.14 - 16:20

    drasojem schrieb:
    --------------------------------------------------------------------------------
    > Passend zur Überschrift Desktop != Server:
    >
    > Sie behaupten also ernsthaft, das ein covert channel, der nur unzuverlässig
    > Zugriff auf häufig genutzte daten könnte auf einem Desktop(!)
    > betriebssystem gefährlicher ist als z.B. unisolierte USB treiber?

    Virtualisierung hilft hierbei - gar nicht. Der Treiber muss ja nur bei qubes angesiedelt werden

    Hypervisor haben selbst Schwachstellen. Sie tun nur so als erhöhen sie die Sicherheit. Browserbanking? - Alle Probleme sind in einer Maschine vereint.

    Kennen sie http://www.insinuator.net/2012/05/vmdk-has-left-the-building/ ?
    (Kurz Ausbruch aus einer VM um Laufwerke des Hosts zu nutzen. )

    > Klar auf
    > einem Server werden teilweise grade private-keys sehr häufig verwendet und
    > liegen daher oft im cache, aber das ist auf einem Desktop OS einfach nicht
    > so der Fall. Zumal so ein Covert chanel auch vom Hypervisor verhindert
    > werden kann (abgesehn von cooperative covert channels aber die sind eh
    > nicht das Problem).

    Ich rede nicht über Side Channels. Wobei die sicherlich auch bei VMs zum Tragen kommen. Sie können mit einer VM eher wenig verhindern.

    > Und natürlich kann ein Hypervisor einen Bug / Desingfehler enthalten, aber
    > das Ihr einziges Argument gegen einen Hypervisor ein auf einem DesktopOS
    > schwer auszunutzender Fehler ist, bestärkt eigentlich nur die Idee.

    Der Hypervisor als Sicherheitsfeature ist der Bug an sich.

    > Mal davon abgesehen, was hindert einen Prozess mit userrechten den eigenen
    > rsa private key auszulesen und dann bei der passwortabfrage das passwort
    > mitzuschneiden?
    > Ist da nicht der weg über einen L2 covert channel erheblich schwieriger?
    > (also ein sicherheits gewinn bei zusätzlicher isolationsschicht?)

    Der Gewinn ist nicht da - Ist der Prozess der Browser des Users der zum ausspähen genutzt wird läuft das ganze völlig unbeeinflußt von der VM ab.

    Nehmen wir mal ein ähnliches Konzept. Bei Android wird ja versucht, Prozessen eigene Räume zu bieten. Ob wir es Dalvik VM oder ART nennen - Prozesse sollen nur in einer sicheren Schicht, einer Sandbox, ausgeführt werden. Nichts anderes wird ja mit Quobes OS auch versucht. Isolierung von Prozessen und Ausführung in Containern. (Ob man das Konzept Container oder Sandbox nennt ist relativ egal).

    Bei Android sieht man recht gut, dass das Abschottungskonzept nicht funktioniert. Die ersten Programme um Root zu erlangen (z.b. Rage against the Cage) brachen aus der Sandbox aus. Malware muss dabei gar nicht ausbrechen, es reicht wenn in den Programmen Zahlfunktionen etc.pp. enthalten sind. Vielleicht haben sie im September über den großen Browserbug bei Android gelesen? Da muß gar nichts ausbrechen, der Browser an sich reicht als große Lücke aus.

    Die Abschottung kann man sehr simpel mit einem nicht mal 30 Zeilen langen Covert Channel Programm umgehen - das sind No Brainer.

    Also welchen Angriffsvektor soll dann noch die VM verhindern?

  18. Re: Virtualisierung != Sicherheit

    Autor: drasojem 08.12.14 - 14:41

    gadthrawn schrieb:
    --------------------------------------------------------------------------------
    > drasojem schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Passend zur Überschrift Desktop != Server:
    > >
    > > Sie behaupten also ernsthaft, das ein covert channel, der nur
    > unzuverlässig
    > > Zugriff auf häufig genutzte daten könnte auf einem Desktop(!)
    > > betriebssystem gefährlicher ist als z.B. unisolierte USB treiber?
    >
    > Virtualisierung hilft hierbei - gar nicht. Der Treiber muss ja nur bei
    > qubes angesiedelt werden
    >
    Qubes an sich ist nur die ansammlung von einem Hypervisor und einigen tools die das Aufteilen des eigenen "digigalen Leben" in Zonen einfach und sicherer gestaltet.
    Und die USB treiber liegen eben bei Qubes nicht in der dom0 oder dem Hypervisor sondern in einer "untrusted" usbVM, die per vt-d vor dma geschützt ist.

    > Hypervisor haben selbst Schwachstellen. Sie tun nur so als erhöhen sie die
    > Sicherheit. Browserbanking? - Alle Probleme sind in einer Maschine
    > vereint.
    >
    > Kennen sie www.insinuator.net ?
    > (Kurz Ausbruch aus einer VM um Laufwerke des Hosts zu nutzen. )
    >
    Natürlich haben Hypervisor selbst schwachstellen, aber es ist eben schwieriger erst z.B. einen Browser und danach den Hypervisor zu explioten als nur den Browser.
    Zumal Qubes grade beim hypervisor möglichst auf zusätzliche features versichtet um die Angriffsfläche zu verringern. (z.B. wo wir beim Thema storage sind: Qubes nutzt als Speicher backend nur raw Images, die wesentlich einfacher zu parsen sind als vmwares vmdk. Und einfacher zu behandeln bedeutet gleichzeitig weniger raum für Fehler)
    > > Klar auf
    > > einem Server werden teilweise grade private-keys sehr häufig verwendet
    > und
    > > liegen daher oft im cache, aber das ist auf einem Desktop OS einfach
    > nicht
    > > so der Fall. Zumal so ein Covert chanel auch vom Hypervisor verhindert
    > > werden kann (abgesehn von cooperative covert channels aber die sind eh
    > > nicht das Problem).
    >
    > Ich rede nicht über Side Channels. Wobei die sicherlich auch bei VMs zum
    > Tragen kommen. Sie können mit einer VM eher wenig verhindern.
    >
    > > Und natürlich kann ein Hypervisor einen Bug / Desingfehler enthalten,
    > aber
    > > das Ihr einziges Argument gegen einen Hypervisor ein auf einem DesktopOS
    > > schwer auszunutzender Fehler ist, bestärkt eigentlich nur die Idee.
    >
    > Der Hypervisor als Sicherheitsfeature ist der Bug an sich.
    >
    Der Hypervisor an sich ist eben nicht direkt das sicherheitsfeature von Qubes.
    Er stellt nur eine bessere möglichkeit der isolierung, als z.B. einfache Prozesse da.
    vgl. http://theinvisiblethings.blogspot.de/2011/04/linux-security-circus-on-gui-isolation.html
    > > Mal davon abgesehen, was hindert einen Prozess mit userrechten den
    > eigenen
    > > rsa private key auszulesen und dann bei der passwortabfrage das passwort
    > > mitzuschneiden?
    > > Ist da nicht der weg über einen L2 covert channel erheblich schwieriger?
    > > (also ein sicherheits gewinn bei zusätzlicher isolationsschicht?)
    >
    > Der Gewinn ist nicht da - Ist der Prozess der Browser des Users der zum
    > ausspähen genutzt wird läuft das ganze völlig unbeeinflußt von der VM ab.
    >
    Richtig er läuft ganz unbeeinflusst. Wenn man aber (wie Qubes nunmal gedacht ist) den Private Key nicht in seiner Pr0n vm liegen hat, sondern in der vault vm und nur per qubes-split-pgp darauf zugreift, hat der Angreifer schlechte karten.

    > Nehmen wir mal ein ähnliches Konzept. Bei Android wird ja versucht,
    > Prozessen eigene Räume zu bieten. Ob wir es Dalvik VM oder ART nennen -
    > Prozesse sollen nur in einer sicheren Schicht, einer Sandbox, ausgeführt
    > werden. Nichts anderes wird ja mit Quobes OS auch versucht. Isolierung von
    > Prozessen und Ausführung in Containern. (Ob man das Konzept Container oder
    > Sandbox nennt ist relativ egal).
    >
    > Bei Android sieht man recht gut, dass das Abschottungskonzept nicht
    > funktioniert. Die ersten Programme um Root zu erlangen (z.b. Rage against
    > the Cage) brachen aus der Sandbox aus. Malware muss dabei gar nicht
    > ausbrechen, es reicht wenn in den Programmen Zahlfunktionen etc.pp.
    > enthalten sind. Vielleicht haben sie im September über den großen
    > Browserbug bei Android gelesen? Da muß gar nichts ausbrechen, der Browser
    > an sich reicht als große Lücke aus.
    >
    Qubes ist nichts anderes als Sandboxing, das stimmt. Allerdungs hat ein Android Prozess eine riesige API die ihm zur Verfügung steht die nur nach exploiots schreit.
    zumal teilen sich alle Prozesse AFAIK den selben GUI Prozess.
    Unter Qubes hat eine VM eine sehr begrenzte und sehr einfach gehaltene api so das fehler sehr unwahrscheinlich werden. So wird auch auf 3D Beschleunigung verzichtet, da diese im Moment einfach noch viel zu Komplex ist.

    Innerhalb einer vm stehen jedem Angreifer die Türen natürlich genauso offen wie in einem Normalen Linux, da bringt ein Hypervisor natürlich garnichts (abgesehen von dem RO rootfs aber das kann man nicht wirklich als Sicherheitsfeature zählen).
    Aber das Ziel von Qubes ist es ja auch nicht sämtliche Angriffe zu verhindern (meiner Meinung nach unmöglich), sondern die Tragweite eines solchen Angriffs zu verringern.
    So kann z.B. ein von einem Kollegen geschicktes infiziertes PDF nur schwer aus seiner wegwerf vm ausbrechen (vorallem schwerer als einfach nur den PDF reader zu exploiten was unter einem normalen Linux ausreichend wäre).

    > Die Abschottung kann man sehr simpel mit einem nicht mal 30 Zeilen langen
    > Covert Channel Programm umgehen - das sind No Brainer.
    >
    > Also welchen Angriffsvektor soll dann noch die VM verhindern?

    Angriffszenario: Ich lade von ihnen ihren 30 Zeilen No Brainer runter und führe ihn in meiner "untrusted" vm aus. Sie müssen sich also nichtmal um einen Browser exploit kümmern. Ich gebe zu das Sie mit allem recht haben, wenn sie dadurch meinen pgp-key erhalten.
    (edit: von mir aus auch nur den Verschlüsselten, den sie ja sofort hätten wenn ich obiges auf einem normalen Linux tun würde).



    2 mal bearbeitet, zuletzt am 08.12.14 14:46 durch drasojem.

  19. Re: Virtualisierung != Sicherheit

    Autor: drasojem 08.12.14 - 17:19

    WolfgangS schrieb:
    --------------------------------------------------------------------------------
    > drasojem schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Passend zur Überschrift Desktop != Server:
    > >
    > > Sie behaupten also ernsthaft, das ein covert channel, der nur
    > unzuverlässig
    > > Zugriff auf häufig genutzte daten könnte auf einem Desktop(!)
    > > betriebssystem gefährlicher ist als z.B. unisolierte USB treiber?
    >
    > Das ist relativ irrelevant. Einige Banken hierzulande warten mit USB Leser
    > auf. Auch die Lesegeräte für verbindliche Amtsgeschäfte mit dem
    > elektronischen Personalausweis laufen über USB. Elektronische
    > Krankenkassenkarten - raten Sie mal. Alles mit Treibern und über Browser
    > oder Software.
    Was ändert das an der Tatsache das ein präperiertes USB-Gerät einen Bug im USB-Controller triggern kann und so per dma das ganze System übernehmen, ohne das das OS da etwas gegen tun könnte?
    Abgesehen dafür waren usb-treiber als Beispiel für Netzwerk, gui oder sonst irgendwelche Hardware oder Api gemeint.



    1 mal bearbeitet, zuletzt am 08.12.14 17:21 durch drasojem.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. IT-Administrator (w/m/d)
    Caesar & Loretz GmbH, Hilden
  2. Leiter*in der Gruppe IT-Service Center
    Deutsche Gesellschaft für Internationale Zusammenarbeit (GIZ) GmbH, Eschborn
  3. Mitarbeiter für Konzeption und Qualitätssicherung (m/w/d)
    ADG Apotheken-Dienstleistungsgesellschaft mbH, Fürth, Mannheim
  4. DevOps Engineer Schwerpunkt Microsoft Azure DevOps (m/w/d)
    SEW-EURODRIVE GmbH & Co KG, Bruchsal

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Greenland, The 800, Rampage, Glass, 2067: Kampf um die Zukunft)
  2. (u. a. Planet Zoo für 13,49€, NieR Replicant ver.1.22474487139... für 33,99€, Landwirtschafts...
  3. (u. a. WD Black SN750 1TB für 109,90€, MSI MPG B550 Gaming Edge WiFi Mainboard AM4 für 139...
  4. (u. a. Dorfromantik für 7,19€, Cartel Tycoon für 18,99€ plus jeweils One Finger Death Punch 2...


Haben wir etwas übersehen?

E-Mail an news@golem.de