Das Thema BYOD hat in den letzten Monaten offenbar an Bedeutung eingebüßt, weil viele Verantwortliche mittlerweile erkannt haben, dass die damit verbundenen technischen und rechtlichen Probleme inhärent nicht beherrschbar sind und am Ende - insbesondere in Europa - die Verantwortung für dieses weitgehend verantwortungslose Konzept ganz allein bei den IT-Experten hängen bleibt. Dies wurde insbesondere in den letzten Blog Artikel offensichtlich.
Die grundsätzlich ähnlichen Konzepte von BlackBerry BALANCE oder Samsung KNOX, die zur Trennung von geschäftlichen und privaten Inhalten genutzt werden können, bringen neuen Schwung in die Diskussion über sichere und seriöse BYOD Konzepte. Unabhängig davon, dass man die rechtlichen Hürden in Deutschland, die BYOD mit keiner seriösen Technologie lösen kann, ist Samsung KNOX konzeptionell mehr als fragwürdig.
Ohne die Technologie an dieser Stelle aus der Anwendersicht erklären zu wollen soll mit diesem Beitrag auf die grundlegende Technologien verdeutlicht werden, die mehr als fragwürdig sind. Der Smartphoneanbieter Samsung verwendet seit der Einführung von KNOX das Security Enhanced Android (SE Android) als Basis seiner Geräte. Wie bereits in einem anderen Blogeintrag ausführlich erläutert, klingt dies offenbar unverfänglich, ist es jedoch nicht, wenn man weiß, wer SE Android entwickelt hat. Hinter dem Smartphonebetriebssystem SE Android steht die unter erheblich öffentliche Kritik geratene Dachorganisation der amerikanischen Geheimdienste NSA. Vor diesem Hintergrund gewinnen die Sicherheitslücken des von Samsung genutzten Betriebssystems eine komplett andere Dimension und sollten auch unverbesserliche Optimisten der Open Source Bewegung eher nachdenklich machen.
Doch Samsung KNOX ist nicht nur wegen des darunterliegenden SE Android als fragwürdig zu bezeichnen. KNOX nutzt ergänzend ein weiteres ebenso fragwürdiges Produkt „Centrify“, welches vom Samsung als Single-Sign-On-Service in der Cloud genutzt wird. Um Centrify verwenden zu können, muss der Anwender sein komplettes Active Directory erst einmal in einer amerikanischen Cloud abliefern, ohne hiervon wirklich etwas mitzubekommen. Denn Centrify ist ein amerikanischer Anbieter auf dessen Ressourcen amerikanische Behörden aufgrund des Patriotic Acts jederzeit uneingeschränkten Zugriff haben.
Was ist dies doch für ein geniales Konzept. Ein vom amerikanischen Geheimdienst entwickeltes Android-Derivat wird mit einem den amerikanischen Behörden uneingeschränkt zugänglichen Cloud-Service kombiniert, der sinnigerweise dann alle Authentifizierungsdaten des betroffenen Unternehmens enthält! Die Situation ist ähnlich bei dem kanadischen BlackBerry BALANCE, auch wenn die Software-Quelle hier nicht ebenso offensichtlich für die Öffentlichkeit zugänglich ist. Die Daten werden gebündelt geschützt ohne wirkliche Kontrolle durch den Nutzer, da das Unternehmen der NSA uneingeschränkten Zugriff gewährleisten muss.
Produktversprechen an einem eigenen Szenario überprüfen. Die im Beitrag genannten Lösungen sind im historischen Produktkontext zu lesen. Testen Sie eine heutige Lösung mit konkreten Anforderungen an Datentrennung, Updates und Entzug von Zugängen. Entscheidend ist der nachgewiesene Ablauf im eigenen Betrieb, nicht die Bezeichnung einer Schutzfunktion.
{tmamazon asin="B0HCK3HKX1" layout="mini" align="none" label="ISO27001 – Alles was man wissen muss" text="Eine umfassende Auseinandersetzung mit ISO/IEC 27001 und ihrem Einsatz zur systematischen Informationssicherheitssteuerung. Im Vordergrund stehen ein wirksames ISMS, die Zuordnung von Verantwortung und belastbare Nachweise." shorttext="Eine umfassende Auseinandersetzung mit ISO/IEC 27001 und ihrem Einsatz zur systematischen Informationssicherheitssteuerung." image="images/mg-publikationen/cover/buch-iso27001-alles-was-man-wissen-muss-system-nachweis-wirksamkeit.jpg" book="1" note="Von Dr. Markus Groß" price="0" rating="0" count="0" features="0" disclosure="1" width="100%"}
Somit müssen beide Systeme nur vordergründig als Sicher und als Heilsbringer für Bring your own Device Skeptiker gesehen werden.
Vertiefung: Sind Samsung KNOX oder Blackberry BALANCE die Lösung
Die damalige Beobachtung zu „Sind Samsung KNOX oder Blackberry BALANCE die Lösung“ wird hier nicht ersetzt, sondern praktisch weitergedacht. Im Fokus stehen bei Ausstiegsweg überprüfbare Voraussetzungen, erkennbare Grenzen und ein im Alltag belastbarer Umgang.
Sind Samsung KNOX oder Blackberry BALANCE die Lösung – Architektur praktisch fassen
Im Mittelpunkt von „Sind Samsung KNOX oder Blackberry BALANCE die Lösung“ steht weniger das Schlagwort als die damit verbundene Entscheidung: Es ist zu klären, wie Komponenten, Schnittstellen und Vertrauensgrenzen zusammenspielen. Beim Schwerpunkt „Sind Samsung KNOX oder Blackberry BALANCE die Lösung“ geht es um mobile Plattformen, Container, Apps und ihre betriebliche Einbindung sowie um den Bezug zu „Hersteller-Support“; zu entscheiden ist, welche technische Abgrenzung dauerhaft administrierbar und herstellerunabhängig genug ist. Ein vorschneller Schluss würde diese Grenze ignorieren: Eine gute Produktfunktion löst nur den Teil des Problems (hier bezogen auf „Interoperabilität“), für den sie technisch ausgelegt wurde; der Belastungstest erfolgt mit Blick auf „Ausstiegsweg“. Die praktische Konsequenz heißt: Datenweg, Identität, Administration und Ausfallverhalten als Gesamtbild prüfen. Der vorgesehene Nachweis lautet: eine freigegebene Architektur mit getesteten Annahmen; „Versionswechsel“ liefert dafür den praktischen Anwendungsfall. Als Messperspektive dient: Fehlkonfigurationen, Supportaufwand, Updateverzug, Plattformausnahmen und Zeit bis zur Wiederherstellung; der Belastungstest erfolgt mit Blick auf „Versionswechsel“. Die bisherige Diskussion liefert mit „wirksame Sicherheit unter realen Arbeitsbedingungen“ einen zusätzlichen Prüfstein; er sollte mit „Hersteller-Support“ verbunden und nicht isoliert bewertet werden.
Hersteller-Support – Mindeststandard praktisch fassen
Aus dem historischen Befund entsteht für „Hersteller-Support“ eine praktische Steuerungsfrage: Es ist zu klären, welche unverzichtbaren Bedingungen jede zulässige Variante erfüllen muss. Beteiligt sind hier vor allem Architektur, Endgerätebetrieb, Support, Informationssicherheit, Einkauf und Anwendungsverantwortliche; ihre Perspektiven treffen beim Aspekt „Containerlösung“ unmittelbar aufeinander. Besondere Aufmerksamkeit verdient das Szenario, in dem eine Produktfunktion mit einem vollständigen Betriebsmodell verwechselt wird oder nach einem Update ihre Wirkung verliert – betrachtet im Kontext „Geräteverwaltung“. Ein schlanker, aber wirksamer Ansatz lautet: wenige klare Basiskriterien mit automatischer oder manueller Prüfung formulieren. Der vorgesehene Nachweis lautet: eine prüfbare Baseline samt begründetem Ausnahmeweg; im vorliegenden Abschnitt wird dies an „Geräteverwaltung“ konkretisiert. Als Messperspektive dient: der Zusammenhang zwischen „Hersteller-Support“ und „Containerlösung“. Eine brauchbare Gegenprobe ist die Frage, ob dieselbe Entscheidung bei einer Störung rund um „Hersteller-Support“ noch nachvollziehbar wäre.
Integration ohne blinden Fleck bei „Updatepfad“
Eine nüchterne Fortführung trennt bei „Schnittstellen“ den damaligen Anlass von der bleibenden Organisationsfrage: Es ist zu klären, welcher bestehende Prozess den neuen Prüfschritt sinnvoll aufnehmen kann. Als belastbare Grundlage dienen Architekturentscheidung, unterstützte Versionen, Konfigurationsbaseline, Tests, Abhängigkeiten und Ausstiegsweg; für den Aspekt „Schnittstellen“ muss ihre Herkunft nachvollziehbar bleiben. Die Entscheidung über „Updatepfad“ sollte deshalb ausdrücklich festhalten, welche technische Abgrenzung dauerhaft administrierbar und herstellerunabhängig genug ist; für den Aspekt „Supportmatrix“ wird daraus ein eigener Prüfschritt. Statt einer neuen Parallelstruktur genügt zunächst: Beschaffung, Berechtigung, Änderung oder Offboarding gezielt erweitern; im vorliegenden Abschnitt wird dies an „Konfigurationsprofil“ konkretisiert. Überprüfbar wird der Schritt durch folgendes Ergebnis: ein eingebetteter Kontrollpunkt ohne parallelen Sonderprozess. Relevant bleibt dabei: die beobachtbare Veränderung beim Aspekt „Tests und Lernen aus erkannten Abweichungen“; der Belastungstest erfolgt mit Blick auf „Plattformarchitektur“. Die bisherige Diskussion liefert mit „Tests und Lernen aus erkannten Abweichungen“ einen zusätzlichen Prüfstein; er sollte mit „Updatepfad“ verbunden und nicht isoliert bewertet werden.
Was „Ausstiegsweg“ für Herstellerabhängigkeit bedeutet
Der Beitrag gewinnt beim Aspekt „Ausstiegsweg“ an Aktualität, sobald sein Kerngedanke in eine heutige Entscheidung übersetzt wird: Es ist zu klären, welche Zusage technisch, vertraglich oder nur marketingseitig besteht. Die alltagstaugliche Übersetzung für „Ausstiegsweg“ lautet: Plattformwahl, Konfiguration und Betriebsverantwortung werden als zusammenhängende Entscheidung dokumentiert. Damit wird zugleich die Grenze beim Aspekt „Konfigurationsprofil“ sichtbar: Eine gute Produktfunktion löst nur den Teil des Problems (hier bezogen auf „Supportmatrix“), für den sie technisch ausgelegt wurde. Statt einer neuen Parallelstruktur genügt zunächst: Supportdauer, Updateweg, Export und Wechseloption vor Auswahl bewerten; die Bewertung erfolgt hier aus der Perspektive „Sind Samsung KNOX oder Blackberry BALANCE die Lösung“. Der Prüfpfad endet nicht beim Dokument; für den Aspekt „Hersteller-Support“ wird daraus ein eigener Prüfschritt. Als Verbindung zwischen Nachweis und Messung dienen: eine Abhängigkeitsübersicht mit realistischem Ausstiegsszenario; Fehlkonfigurationen, Supportaufwand, Updateverzug, Plattformausnahmen und Zeit bis zur Wiederherstellung; der Prüfkontext ist hier „Hersteller-Support“. Eine brauchbare Gegenprobe ist die Frage, ob dieselbe Entscheidung bei einer Störung rund um „Ausstiegsweg“ noch nachvollziehbar wäre.
Was „Containerlösung“ für Lizenzen bedeutet
Der Beitrag gewinnt beim Aspekt „Containerlösung“ an Aktualität, sobald sein Kerngedanke in eine heutige Entscheidung übersetzt wird: Es ist zu klären, ob private und geschäftliche Nutzung vom Nutzungsrecht gedeckt sind. Kritisch wird die Lage insbesondere dann, wenn eine Produktfunktion mit einem vollständigen Betriebsmodell verwechselt wird oder nach einem Update ihre Wirkung verliert – betrachtet im Kontext „Plattformarchitektur“. Für die beteiligten Rollen – Architektur, Endgerätebetrieb, Support, Informationssicherheit, Einkauf und Anwendungsverantwortliche – braucht der Aspekt „Containerlösung“ daher einen vorab geklärten Entscheidungsweg. Für den nächsten Review wird vereinbart: Lizenztyp, Nutzerkreis, Gerät, Übertragbarkeit und Beendigung prüfen; „Ausstiegsweg“ liefert dafür den praktischen Anwendungsfall. Überprüfbar wird der Schritt durch folgendes Ergebnis: ein Lizenznachweis bis zum Entzug oder zur Neuvergabe; für „Containerlösung“ ist das Ergebnis gesondert festzuhalten. Relevant bleibt dabei: der Zusammenhang zwischen „Containerlösung“ und „Sind Samsung KNOX oder Blackberry BALANCE die Lösung“. Für den Dialog unter dem Beitrag ist „Messbarkeit und nachgewiesene Wirkung“ der passende Belastungstest: Gerade beim Aspekt „Sind Samsung KNOX oder Blackberry BALANCE die Lösung“ muss die Regel im Alltag tragen.
Supportmodell ohne blinden Fleck bei „Ausstiegsweg“
Für die heutige Einordnung von „Versionswechsel“ ist zunächst eine Unterscheidung entscheidend: Es ist zu klären, welche Hilfe zugesagt wird und wo Eigenverantwortung beginnt. Folgende Messperspektive zeigt, ob sich der Aspekt „Versionswechsel“ tatsächlich verbessert oder nur formell bearbeitet wurde: Fehlkonfigurationen, Supportaufwand, Updateverzug, Plattformausnahmen und Zeit bis zur Wiederherstellung. Für „Ausstiegsweg“ bleibt dabei verbindlich: Eine gute Produktfunktion löst nur den Teil des Problems (hier bezogen auf „Plattformarchitektur“), für den sie technisch ausgelegt wurde. Ein schlanker, aber wirksamer Ansatz lautet: Servicegrenzen, unterstützte Varianten und Eskalationswege veröffentlichen; der Prüfkontext ist hier „Interoperabilität“. Die Dokumentation hält zwei Dinge fest – Supportdaten zu Ursache, Aufwand und wiederkehrenden Problemen; zusätzlich sichtbar wird: die beobachtbare Veränderung beim Aspekt „wirksame Sicherheit unter realen Arbeitsbedingungen“. Beim Aspekt „Ausstiegsweg“ ist nicht die Menge der Aktivitäten entscheidend, sondern die erkennbare Veränderung des Ergebnisses.
Für Hersteller-Support sollte am Ende kein umfangreiches Zusatzdokument stehen, sondern eine klare Entscheidung mit Eigentümer, Nachweis und Wiedervorlage für Schnittstellen. Genau daran lässt sich erkennen, ob die Vertiefung zu Ausstiegsweg praktische Wirkung entfaltet.