-
HINTERGRUND DER ERFINDUNG
-
Gebiet der Erfindung
-
Die vorliegende Erfindung bezieht sich auf Software und mobile Geräte bzw. Einrichtungen. Genauer gesagt, bezieht sie sich auf die Sicherung, Beherrschung und Verwaltung von Apps (Applikation) in Geräten wie etwa Handgerätesätzen, Fernsehern, Kraftfahrzeugen und anderen neu auftretenden Kategorien von smarten bzw. intelligenten Geräten.
-
Beschreibung des verwandten Standes der Technik
-
Wie es nun in der Industrie von berechnenden (computing) und mobilen Handgerätesätzen und Smartphones bekannt ist, ist ein neues Berechnungs- bzw. Verarbeitungsparadigma in der Entstehung und wird durch die Verbreitung von Software-Applikationen angetrieben, die nun allgemein als Apps für in der Hand gehaltene oder mobile Einrichtungen bzw. Geräte bekannt sind. Diese Verbreitung ist direkt mit der Adoption von Smartphones und Tablets bzw. Tablet-Computern verknüpft. Unternehmen kreieren nun ihre eigenen, einzigartigen Apps und verteilen diese an Angestellte, Kunden und Partner. Unternehmen schreiben nun ihre eigenen Anwendungen für ihre Mitarbeiter und Partner für die Benützung. Mit diesem Wachstum entsteht jedoch ein weiteres Problem, nämlich das der Sicherheit und Verwaltung von diesen Apps auf bzw. in Handseteinrichtungen bzw. Handapparaten. Apps können eine erhebliche Beschädigung bei einem in der Hand gehaltenen Gerät hervorrufen und können den Verlust von Daten oder eine nicht beabsichtigte Übertragung von Daten verursachen. Diese führen zu Verletzbarkeiten bezüglich des Geräts und zu einem Sicherheitsrisiko für den Benutzer.
-
Ein herkömmlicher Anti-Viren- bzw. Virenschutz-Ansatz wie er beispielsweise durch MyLookOut bereitgestellt wird, beseitigt eine Beschädigung nicht, die durch eine App (App-Anwendung) bei einem Handsetgerät bzw. Handapparat hervorgerufen ist. Während eine Schwarz-Listung von Apps partiell für den Schutz von Geräten adäquat ist (nicht nur Apps auf der Liste, die herunterzuladen sind), wäre es besser, wenn eine Methode für die Begrenzung eines Schadens vorhanden wäre, die eine durch Malware bzw. Schadsoftware infizierte App an einem mobilen Gerät ausgerichtet hat. Es wäre bevorzugt, falls der Kernel der Software des Betriebssystems für das mobile Gerät nicht geändert werden müsste. Es wäre weiterhin vorzuziehen, falls der Autor des Apps nicht in der Kunst des sicheren Programmierens oder in dem Schreiben von irgendwelchen Spezialitäten oder Kundenanpassung für die Sicherheit geschult werden müsste, wenn er die Anwendung bzw. App schreibt – sie sollten in den Stand gesetzt sein, mit dem Schreiben von Apps einfach fortzufahren, wie sie dies auch aktuell tun.
-
KURZFASSUNG DER ERFINDUNG
-
Bei einem Gesichtspunkt der vorliegenden Erfindung werden bzw. sind Apps gesichert oder sicherheitsverpackt entweder bevor sie auf ein Gerät wie etwa ein Smartphone oder ein Tablet-Gerät heruntergeladen werden, oder nachdem sie heruntergeladen worden sind, bevor ihnen aber gestattet wird, auf das Betriebssystem des Geräts zuzugreifen und irgendwelche potentiellen Beschädigungen zu verursachen. Ein Provider bzw. Bereitsteller von Apps wie etwa ein Mitarbeiter oder ein Provider von drahtlosen Zellen- bzw. Mobilfunktelefonen kann seine Apps sichern, bevor Verbraucher ein App von ihrem App-Store bzw. App-Laden, Marktplatz und dergleichen herunterladen. Die App ist bzw. wird gesichert, bevor gestattet wird, dass sie auf das Betriebssystem oder andere Komponenten des Geräts zugreifen kann, wodurch die App an einem bösartigen Verhalten in dem Gerät gehindert wird.
-
Gemäß einem Gesichtspunkt der Erfindung ist ein Verfahren zum Sichern einer App für die Ausführung auf einem Gerät unter Verwendung eines Sicherheitsprogramms beschrieben. Ein Kern-Objekt-Code der App wird erhalten bzw. ermittelt und die digitale Signatur wird entfernt. Ein App-Objekt-Code wird durch einen Objekt-Code eines Sicherheitsprogramms ersetzt, wodurch eine hinsichtlich der Sicherheit verpackte App erzeugt wird. Die hinsichtlich der Sicherheit verpackte bzw. sicherheitsverpackte App wird für die Ausführung auf dem Gerät vorbereitet und wird mit einem neuen Schlüssel neu signiert. Auf diese Weise ist eine zentralisierte Politik bzw. Handhabung für die Steuerung und Sicherung des Zugriffs zu Daten in dem Gerät implementiert.
-
Bei einem anderen Aspekt der Erfindung ist ein Verfahren zum Hindern einer App an der Beschädigung eines Geräts beschrieben. Eine hinsichtlich der Sicherheit verpackte App wird auf dem Gerät ausgeführt. Eine Sicherheitsüberprüfung durch das Sicherheitsprogramm der App bzw. App-Sicherheitprogramm wird bei einem Anruf bzw. Aufruf angewendet, den die App bei dem Betriebssystem des Geräts ausführt. Auf der Basis der Ergebnisse der Sicherheitsüberprüfung für den Anruf bzw. Aufruf führt das App-Sicherheitprogramm eines der Folgenden durch: (a) zulassen, dass der Anruf bzw. Aufruf zu dem Betriebssystem durchgeleitet wird; (b) Verstärkung bzw. Verbesserung des Aufrufs; (c) blockieren des Aufrufs; oder (d) beenden der Ausführen der hinsichtlich der sicherheitverpackten App.
-
KURZE BESCHREIBUNG DER ZEICHNUNGEN
-
Auf die beigefügten Zeichnungen wird Bezug genommen, die einen Teil der Beschreibung darstellen und in denen anhand von Illustrationen spezielle Ausführungsbeispiele der vorliegenden Erfindung gezeigt sind:
-
1A zeigt ein Blockschaltbild, das einen Überblick über den App-Steuerprozess bzw. das App-Steuerverfahren gemäß der vorliegenden Erfindung veranschaulicht;
-
1B zeigt ein Blockschaltbild, das ein alternatives Ausführungsbeispiel eines App-Steuerprozesses bzw. -Steuerverfahrens gemäß der vorliegenden Erfindung veranschaulicht;
-
2 zeigt ein Blockschaltbild, in dem Komponenten eines App-Sicherheitsprogramms in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht sind;
-
3 zeigt ein Ablaufdiagramm, das einen Prozess zur Sichermachung einer App vor deren Herunterladen auf ein Gerät in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht;
-
4 zeigt ein Ablaufdiagramm eines Verfahrens, das in einem Policy Manager bzw. einer Richtlinienverwaltungseinrichtung in Übereinstimmung mit einem Ausführungsbeispiel ausgeführt wird;
-
5 zeigt ein Ablaufdiagramm, das einen Prozess einer hinsichtlich ihrer Sicherheit eingehüllten bzw. sicherheitsverpackten App, der auf einem Handgerät oder einem mobilen Gerät ausgeführt wird, in Übereinstimmung mit einem Ausführungsbeispiel veranschaulicht;
-
6 zeigt ein Diagramm einer Systemarchitektur eines in Übereinstimmung mit einem Ausführungsbeispiel stehenden App Sicherheitssteuerungssystems zeigt; und
-
7A und 7B zeigen Blockschaltbilder eines Berechnungssystems, das für die Implementierung von verschiedenartigen Ausführungsbeispielen der vorliegenden Erfindung geeignet sind.
-
DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
-
Es werden als Beispiel dienende Ausführungsbeispiele eines Applikations- bzw. Anwendungs-Sicherheitsprozesses und Systems beschrieben. Diese Beispiele und Ausführungsformen sind lediglich dazu bereit gestellt, Kontext hinzuzufügen und bei dem Verständnis der Erfindung zu helfen. Für den Fachmann wird es folglich offensichtlich werden, dass die vorliegende Erfindung auch ohne einige oder alle der hier beschriebenen speziellen Details in die Praxis umgesetzt werden kann. In anderen Fällen sind gut bekannte Konzepte nicht im Einzelnen beschrieben worden, um ein unnötiges Verdunkeln der vorliegenden Erfindung zu vermeiden. Andere Applikationen bzw. Anwendungen und Beispiele sind möglich, derart, dass die folgenden Beispiele, Illustrationen und Kontexte nicht als definitiv oder beschränkend, und zwar weder hinsichtlich des Umfangs noch der Einstellung, herangezogen werden sollten. Auch wenn diese Ausführungsbeispiele in ausreichenden Einzelheiten beschrieben sind, um einen Fachmann in die Lage zu versetzen, die Erfindung in die Praxis umzusetzen, sind diese Beispiele, Illustrationen und Kontexte nicht beschränkend, und es können andere Ausführungsbeispiele eingesetzt werden und Änderungen durchgeführt werden, ohne dass der Gehalt und Umfang der Erfindung verlassen wird.
-
Methoden und Systeme für die Verhinderung, dass Geräte-Softwareapplikationen bzw. -anwendungen ein Gerät, insbesondere ein mobiles Gerät, infizieren oder anderweitig beschädigen können, sind in den verschiedenen Zeichnungen beschreiben. Diese Typen von Applikationen bzw. Anwendungen, die oftmals in einer Vielfalt von mobilen Geräten wie etwa von Smartphones, Tablet-Computern, Spieleinrichtungen und tragbaren Computereinrichtungen benutzt werden, werden üblicherweise gemeinsam als „Apps” bezeichnet. Diese Apps können auch auf nicht-mobile Geräte wie etwa Fernseher (TVs), Computer, Kraftfahrzeuge und andere neu auftretende Kategorien von smarten bzw. intelligenten Geräten heruntergeladen werden. Verfahren und Systeme, wie hier beschrieben, sind nicht dazu gedacht, auf die Arbeitsweise bzw. den Betrieb in mobilen Geräten beschränkt zu sein. Diese Geräteprogramme oder Apps haben sich vermehrt und sind nun sehr weit verbreitet. Aktuell sind Apps typischerweise entweder in Java oder C geschrieben. Die Methoden und Systeme, wie hier beschrieben, können bei Apps, die in einer dieser Sprachen geschrieben sind, oder bei Apps angewendet werden, die in anderen Sprachen für unterschiedliche Plattformen geschrieben sind. Die meisten Apps, wenn nicht alle, müssen mit dem Betriebssystem des mobilen Geräts kommunizieren, um einen spezifischen Service bzw. eine spezielle Dienstleistung zu erhalten, die von der App benötigt werden, um ihre beabsichtigte Funktion auszuführen, und es steht dieser Service üblicherweise lediglich seitens des Betriebssystems zur Verfügung. Ein allgemeiner eines solchen benutzten Services bzw. einer solchen benutzten Dienstleistung ist GPS, um die Position des Geräts zu erhalten, die die App benötigen kann. Aufgrund dieser Exposition stellen Apps allerdings eine Verwundbarkeit für das Gerät dar und erweisen sich als ein Sicherheitsrisiko und ein Privacy- bzw. Vertraulichkeits-Risiko für den Benutzer. Unternehmen wünschen, imstande zu sein, eine zentralisierte Policy bzw. Richtlinie für die Steuerung und Sicherung des Zugriffes zu ihren Daten und ihrer Software in Kraft zu setzen. Dies ist auch für Endbenutzer (d. h. für Individuen, Benutzer zu Hause und dergleichen) zutreffend. Dies ermöglicht es, IT Abteilungen von Unternehmen die Beherrschung von bzw. Aufsicht über Unternehmensdaten zu behalten. Die hier beschriebenen Methoden stellen einen zentralisierten Weg für die Steuerung der Sicherheit im Hinblick auf Apps dar, die auf mobile Geräte herunter geladen sind bzw. werden, wobei die Geräte entweder ein persönliches Telefon eines Angestellten oder ein Telefon eines Arbeitgebers sind, derart, dass diese Apps keine Bedrohung der Sicherheit darstellen. Verschiedenartige Ausführungsbeispiele der Erfindung können auch von Eltern und Einzelpersonen (d. h. in Umgebungen zuhause oder außerhalb des Arbeitsbereichs) benutzt werden, um sicherzustellen, dass ihre persönlichen mobilen Geräte gegenüber bösartiger Software (Malware) gesichert sind, und können weiterhin dazu benutzt werden, Steuerungen wie etwa bezüglich der Benutzung auszuüben. Ausführungsbeispiele der App Steuersoftware gemäß der vorliegenden Erfindung können auch für den Schutz von Daten von mobilen Geräten und eine Sicherung (back-up) sowie für Telemetrieanwendungen auf Anwendungsebene benutzt werden.
-
1A zeigt ein Blockschaltbild, das einen Überblick über den App Steuerprozess gemäß der vorliegenden Erfindung veranschaulicht. Es ist eine allgemeine Beschreibung eines Prozesses gegeben, ohne dass dieser mit einer spezifischen Konfiguration oder Umgebung verknüpft ist. Ein Anwendungsprogramm bzw. eine App 102 ist oder wird durch einen App Provider 100 bereitgestellt, der jede beliebige Art von Einheit sein kann (Individuum, Softwarentwickler, Arbeitgeber usw.). Sie ist generell nicht geschützt, und die einzige Sicherheitsumgebung, die sie umgibt, wird durch das Betriebssystem bereitgestellt. Die einzige Abschirmung und Überprüfung, die dahingehend durchgeführt wird, wie sie auf dem Gerät ausgeführt wird, sobald sie geladen worden ist, wird durch das Betriebssystem bereitgestellt.
-
Die vorliegende Erfindung erlaubt eine zusätzliche Sicherheit der Anwendungen bzw. Apps, die nicht durch das Betriebssystem des Geräts geboten wird. Ein Sicherheitsanwendungsprogramm 104 wird auf die App 102 angewendet. Oder es wird die App 102 in ein Programm 104 eingegeben, das durch einen als dritte Partei vorhandenen Provider von Applikationssicherheit bereitgestellt wird. In einem Ausführungsbeispiel weist das Sicherheitsanwendungsprogramm 104 einen Policy Manager bzw. eine Richtlinienverwaltung und einen Policy Verpacker auf, die an unterschiedlichen Positionen vorhanden sein können. Diese sind in 2 in größeren Einzelheiten beschrieben. Sobald das Sicherheitsprogramm 104 auf die App 102 angewendet worden ist, ist die App mit einer Sicherheitsschicht verpackt bzw. umhüllt, so dass das Gerät geschützt ist. Sie ist als eine gesicherte App 106 veranschaulicht. In einem Ausführungsbeispiel wird eine gesicherte App 106 dann auf ein mobiles Gerät 108, wie etwa auf ein Smartphone oder einen Tablet-Computer heruntergeladen, in dem sie sicher ohne die Gefahr von Beschädigungen des Geräts 108 abgearbeitet wird. Ein weiterer Vorteil besteht darin, dass die gesicherte App 102 auch durch das Unternehmen oder eine andere Entität verwaltet werden kann, das bzw. die die App für den Benutzer bereitstellt, wie beispielsweise für einen Arbeitgeber, der die App für einen Angestellten bereitstellt. Als ein Beispiel kann das Unternehmen dann, wenn der Benutzer das Unternehmen verlässt, die App und jegliche hiermit zusammenhängenden Daten von dem Gerät automatisch löschen. Bei einem anderen Beispiel kann ein Elternteil imstande sein, die Apps, die durch eine andere Person (z. B. ein Kind) benutzt werden, zu begrenzen, oder die zeitliche Länge bzw. Zeitdauer zu beschränken, z. B. auf 10 Minuten je Tag, oder er kann auch einschränken, auf welche Webseiten durch eine App zugegriffen werden kann. Als weiteres Beispiel kann ein Elternteil besorgt sein, dass eine App die Position eines Kindes für unbekannte dritte Parteien leckweise kundtut. Es können auch zahlreiche weitere Beispiele vorhanden sein. Wie angegeben, dient 1A dazu, den generellen Prozess der Sicherung einer App und des Herunterladens derselben auf ein Gerät zu veranschaulichen. Es ist anzumerken, dass die App 102 bei diesem Ausführungsbeispiel gegenüber der Verursachung von Beschädigungen bei dem Gerät nicht nachdem sie auf das Gerät heruntergeladen ist, sichergemacht wird, sondern bevor dies erfolgt. In einem weiteren Ausführungsbeispiel ist bzw. wird die App gesichert, nachdem sie auf das Gerät heruntergeladen worden ist, jedoch bevor sie mit dem Betriebssystem interagieren kann.
-
1B zeigt ein Blockschaltbild, das ein alternatives Ausführungsbeispiel veranschaulicht. Eine nicht gesicherte App 110 (ebenfalls von einem App-Provider bereitgestellt) wird auf das mobile Gerät 112 heruntergeladen. Bei diesem Ausführungsbeispiel kann jedoch eine speziell entworfene App auf bzw. in dem Gerät 112 vorhanden sein, die die aktuelle Installation der nicht gesicherten App 110 blockiert. Die spezielle App (nicht gezeigt) leitet die nicht gesicherte App 110 zu einem App Sicherheitsprogramm 114 um. Die nicht gesicherte App 110 wird in bzw. gemäß einer Sicherheitsrichtlinie verpackt, wobei die resultierende App als gesicherte App 116 gezeigt ist. Sie wird dann durch die spezielle App heruntergeladen und zugelassen, dass sie in dem Gerät 112 installiert wird. Auf diese Weise kann ein individueller oder zu Hause befindlicher Benutzer, der beispielsweise ihr Telefon gegenüber Sicherheitsbedrohungen, die durch Apps geboten werden, schützen möchte, erreichen, dass Apps durch einen von dritter Seite bereitgestellten Service oder durch ihren Mobiltelefon-Bereitsteller bzw. Träger gesichert (verpackt) werden, um lediglich zwei Beispiele zu erwähnen, bevor sie auf ihr Telefon heruntergeladen werden. Es sei hier angemerkt, dass diese Sicherheitsverpackung auf eine App unabhängig davon angewendet werden kann, von wo aus der Benutzer die App herunterlädt. Es kann weiterhin festgestellt werden, dass das Netzwerk und die Verbindungen zwischen den Komponenten und der Software in den 1A und 1B generisch bzw. allgemein gezeigt sind. Die Übertragungen finden primär über das Internet (nicht gezeigt) statt, können aber auch innerhalb eines privaten Netzwerks, oder in beiden erfolgen.
-
2 zeigt ein Blockschaltbild, das Komponenten eines App Sicherheitsprogramms in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht. In einem Ausführungsbeispiel weist das Sicherheitsprogramm zwei hauptsächliche Komponenten auf, nämlich einen Policy Manager bzw. eine Richtlinienverwaltungseinrichtung und einen Policy Wrapper bzw. eine Richtlinien-Verpackungseinrichtung auf. Eine Richtlinienverwaltungseinrichtung (Policy Manager) 202 akzeptiert Eingaben von einem Administrator oder einem anderen Individuum, der bzw. das für die Festlegung der Sicherheit für das mobile Gerät verantwortlich ist. Die Person kann als der Gouverneur bzw. Direktor (Master) bezeichnet werden, da er die Sicherheit des einen oder der mehreren mobilen Geräte dirigiert bzw. beherrscht. Die Sicherheitspolicy bzw. Sicherheitsrichtlinie kann unter Verwendung von verschiedenartigen Benutzerschnittstellenschirmen festgelegt werden bzw. sein. Es gibt zahlreiche Beispiele für Richtlinien, einschließlich von Geo-Fencing (geographische Einschränkung, wobei die App beispielsweise lediglich in einem Gebäude benutzt werden kann) und Weitere. Der Serviceprovider oder die Entität, die das App Sicherheitsprogramm bereitstellt, kann auch Richtlinien- und Sicherheitseinstellungen als Sollwert ohne anderweitige Auswahl („default”) bereitstellen, die für Heimbenutzer bzw. Benutzer zuhause nützlich sein können. Beispiele von Richtlinieneinstellungen werden nachstehend beschrieben. Eine Richtlinieneingabe 204 wird in den Policy Manager bzw. Richtlinien-Manager bzw. die Richtlinienverwaltungseinrichtung 202 eingegeben. Der Policy Manager bzw. Richtlinien-Manager 202 übernimmt die Eingabe/Einstellungen von dem Direktor und erzeugt Richtlinien oder Meta-Daten 206. Das Format oder die Form der Meta-Daten 206 kann variieren. Diese reflektieren im Wesentlichen die Richtlinieneinstellungen seitens des Direktors.
-
Metadaten (Richtlinien) 206 können als eine Eingabe für eine Richtlinienverpackungseinrichtung bzw. Policy Wrapper 208 benutzt werden. Bei einem Ausführungsbeispiel übernimmt diese Komponente des Programms die Richtlinien und benutzt diese, um eine App 210 zu sichern, indem sie diese verpackt. Der Verpacker bzw. die Verpackungseinrichtung 208 empfängt eine App 210 von einem in der Hand haltbaren Gerät 212. Bei einem Ausführungsbeispiel empfängt die Verpackungseinrichtung 208 eine Kopie einer App 210 anstelle der originalen App 214, die auf das Telefon 212 heruntergeladen wurde (siehe die obige 1B). Hier versucht der Benutzer des in der Hand haltbaren Geräts 212, eine nicht gesicherte bzw. gesicherte App 216 von einem App Provider 218 herunterzuladen. In dem in 1A beschriebenen Szenario kann sie an der App selbst anstelle einer Kopie arbeiten. Dies kann der Fall sein, wenn ein Marktplatz oder ein App Store Kunden eine gesicherte Version der App zusammen mit einer ungesicherten Version anbietet (oder lediglich die gesicherte Version offeriert). Eine gesicherte Version 220 (eine sicherheitsverpackte Version) wird von der Richtlinien- bzw. Policy-Verpackungseinrichtung 208 zu dem Gerät 212 zurückgeleitet.
-
Metadaten 206 können auch dazu benutzt werden, eine lokale Policy- bzw. Richtliniendatei (eine existierende Richtlinie, die bereits in der Einrichtung bzw. dem Gerät vorhanden ist) zu aktualisieren. Eine lokale Richtliniendatei wird dazu benutzt, Policy- bzw. Richtlinienparameter zu aktualisieren, die in dem Gerät 212 vorhanden sind. Als ein Beispiel ist es in dem Fall einer „Geoumzäunung” bzw. „geofencing” (d. h. bei einer Beschränkung der Benutzung einer App auf eine bzw. mehrere gewisse physikalische Bereiche) wahrscheinlich, dass die GPS Positionen, die durch den Direktor gesteuert werden, sich über die Zeit hinweg ändern. Wenn eine solche Änderung auftritt, können die neuen Richtlinien in zwei unterschiedlichen Weisen angewendet werden. Eine besteht darin, eine neue Richtlinie zu generieren und diese auf die ursprüngliche App anzuwenden (d. h. die App mit der neuen Richtlinie zu verpacken). Ein anderer Weg besteht darin, eine dynamische Konfiguration auf der Basis einer lokalen Policy- bzw. Richtlinien-Datendatei zuzulassen, wobei der „variable” Teil der Richtlinie in deren Inneren verschlüsselt/signiert ist. Als ein Beispiel kann eine IT Person die Fähigkeit wünschen, eine Konfiguration in einem Gerät direkt durch eine IT App, die in dem Gerät vorhanden ist, für diagnostische Zwecke/Diagnose Zwecke zu übersteuern.
-
In einem Ausführungsbeispiel haben Richtlinien (Policies) zwei Komponenten: einen festen Teil und einen variablen Teil. Der feste Teil ist der Inhalt, der in der Richtliniendatei beschrieben ist (beispielsweise „schützen der GPS zu bestimmten Zeiten des Tages”). Der variable Teil wird typischerweise durch den Direktor über eine Konsole bereitgestellt (z. B. „Was sind die Zeiten, zu denen das GPS geschützt werden sollte?”). Der variable Teil kann sich ohne Anwenden einer neuen Richtlinie ändern.
-
Richtliniendesigner bzw. -entwickler können auswählen, auf die variable Komponente der Richtlinie zu verzichten und grundsätzlich alle Daten oder einen Inhalt statisch in der Richtliniendatei „einzubetten”. In diesem Fall weist die Konsole keinerlei Möglichkeit zur kundenspezifischen Anpassung der Richtlinie auf.
-
Falls der Gestalter der Richtlinie wählt, eine variable Komponente in der Richtlinie einzuschließen, wenn Änderungen zu den variablen Daten durchgeführt werden (auf der Konsole), kann eine neue Datei bzw. ein neues Daten-File zu dem Gerät gesendet werden, um die letzten Änderungen widerzuspiegeln. Eine solche Datei würde verschlüsselt/signiert (um eine bösartige App zu verhindern, die die Richtlinie umgeht), zu dem Gerät heruntergeladen, und durch den App-Sicherheitscode in dem Gerät benutzt werden, um die neuen Daten auf die geeignete Policy bzw. Richtlinie anzuwenden.
-
Solche Änderungen und Aktualisierungen können durch die lokale Policy- bzw. Richtlinienaktualisierungskomponente 222 während der Laufzeit durchgeführt werden. Diese Komponente kreiert aktualisierte Richtlinienparameter in dem Gerät 212. Im Anschluss hieran wird die verpackte App 220 die aktualisierten Richtlinienparameter benützen.
-
Bei einem Ausführungsbeispiel stellen der Policy- bzw. Richtlinienmanager 202 (Richtlinienverwaltungseinrichtung) und die Policy- bzw. Richtlinienverpackungseinrichtung 208 Komponenten in dem gleichen App-Sicherheitsprogramm dar und können auf dem gleichen Computer arbeiten. In anderen Ausführungsbeispielen können der Manager und die Verpackungskomponenten auf separaten Computern vorhanden sein. Als ein Beispiel kann der Policy-Manager bzw. Richtlinienmanager 202 auf einem Server an einer Stelle vorhanden sein, und es kann die Richtlinienverpackungseinrichtung 208 auf einem Computer an einer anderen Stelle vorhanden sein und kann durch eine unterschiedliche Entität oder durch dieselbe Entität verwaltet werden. Kollektiv bilden der Manager und die Verpackungseinrichtung das App Sicherheitsprogramm, das bei einem Ausführungsbeispiel durch einen Sicherheitsserviceprovider bzw. Sicherheitsdienstleistungsanbieter betrieben wird. Es kann auch durch ein Unternehmen wie etwa einen Betrieb, einen Arbeitgeber, einen Geschäftspartner und dergleichen oder durch einen Mobilfunkträger bzw. Mobilfunk-Anbieter bereitgestellt werden.
-
3 zeigt ein Ablaufdiagramm, das einen Prozess für die Durchführung einer Sicherung einer App veranschaulicht, bevor sie auf ein Gerät heruntergeladen wird, und zwar in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung. Bei einem Schritt 302 wird auf dem Gerät eine Kopie oder ein Klon der App erstellt, die zu sichern bzw. sicher zu machen ist. Bei einem Ausführungsbeispiel kann dies in dem mobilen Gerät selbst erfolgen, oder kann außerhalb des Geräts durchgeführt werden, beispielsweise durch Komponenten in dem Internet, in der Cloud, auf einem Server eines Unternehmens oder auf einem Server eines Trägers bzw. Carriers. Wie es in dem Gebiet bekannt ist, kann eine App in einer Anzahl von Weisen erhalten werden, am typischsten von einem App Store oder einem App Markt, oder direkt von dem App Entwickler oder einem Provider oder in jeglicher geeigneten Weise. Durch die Erstellung einer Kopie wird die ursprüngliche App beibehalten, was dem Benutzer eine Option bietet, entweder die gesicherte oder die ungesicherte Version zu benutzen, und ferner auch die Fähigkeit des Benutzers schützt, die App zu verwenden, falls bei dem Prozess der Steuerung der App etwas schiefgehen sollte. Es ist anzumerken, dass die App bei einem Ausführungsbeispiel noch nicht auf das Telefon bzw. Phon heruntergeladen ist. Bei einem Ausführungsbeispiel werden die nachstehend beschriebenen Methoden auf separaten Berechnungseinrichtungen ausgeführt. Bei einem anderen Ausführungsbeispiel kann der Prozess in einem mobilen Gerät ausgeführt werden, wobei aber die App lediglich in dem Gerät ausgeführt wird, nachdem der Prozess vollständig bzw. abgeschlossen ist und die App sicher gemacht worden ist.
-
Bei einem Schritt 304 wird die App entkapselt. Die meisten, wenn nicht sogar alle Apps, haben digitale Signaturen, die durch den Autor/Entwickler signiert sind. Bei dem Schritt 304 wird die digitale Signatur von der App als ein Teil der Entkapselung entfernt. Dies kann unter Verwendung von Techniken durchgeführt werden, die in dem Stand der Technik bekannt sind. Das Entschlüsseln der der App kann ebenfalls bei diesem Schritt ausgeführt werden. Diese und weitere Schritte stellen den Kernobjektcode der App bereit, der nun durch das App Steuerprogramm bearbeitet werden kann. Die Natur und spezifischen Eigenheiten dieser Operation können von dem Betriebssystem des mobilen Geräts abhängen.
-
Es gibt mehrere Beispiele von Betriebssystemen von Smartphones wie etwa iOS (für das iPhone), Android (in Handgeräten von verschiedenartigen Herstellern benutzt), Windows Mobile 7, Web O/S, Palm und Weitere. Bei einem Schritt 306 kann die Kernobjektcode-App entweder disassembliert oder dekompiliert werden, um den ausführbaren Objektcode zu erhalten. Als Beispiel kann er entweder ein „nativer Code” (CPU Instruktionen) oder ein Bytecode (Instruktionen einer virtuellen Maschine wie etwa Java oder .Net) sein. Bei einem Ausführungsbeispiel kann dieses eher ein Modifikationsprozess sein, falls das Gerät mit iOS läuft, bei dem die Deassemblierung näher bei einem Prozess der Lokalisierung und Ersetzung von gewissen Links und Terms liegt. Jedoch kann der Prozess der Deassemblierung für die Bildung des Objektcodes einer App, nachdem sie entkapselt worden ist, unter Verwendung von Techniken durchgeführt werden, die in dem Stand der Technik bekannt sind, wie etwa beispielsweise unter Verwendung von Disassemblern bzw. Deassemblierer.
-
Bei einem Schritt 308 wird der App Objektcode mit einem Objektcode von dem App Sicherheitsprogramm verstärkt bzw. angereichert. Als ein Beispiel kann dieser Objektcode Klassendateien enthalten, die durch Klassendateien von dem Sicherheitsprogramm ersetzt werden. Der Objektcode stellt im Allgemeinen eine Schnittstelle (Interface) zu dem Betriebssystem des mobilen Geräts dar. Der Objektcode des Sicherungsprogramms der App Steuerung wird zum Teil von den vorstehend beschriebenen Richtlinie-Metadaten abgeleitet. In dem Fall von iOS ist die Arbeitsweise dahingehend unterschiedlich, dass ein Prozess „Lokalisieren und Ersetzen” auftritt anstatt dass eine Ersetzung des Objektcodes erfolgt. Dies stellt eine Berücksichtigung eines Interrupt-Ansatzes dar, der von iOS benutzt wird. Im Allgemeinen geht das App Sicherheitsprogramm durch den Assembly Sprachcode hindurch. Die spezifischen Merkmale, die lokalisiert sind, sind Software Interrupts (SWIs = Software Interrupts) innerhalb des Objektcodes, die durch eine Verzweigung zu einer Schicht des Sicherheitsprogramms der App Steuerung bzw. des App Steuersicherheitsprogramms ersetzt werden, die dann bestimmen kann, welche weiteren Aktionen zu ergreifen sind, wie etwa das Erstellen der Anforderung, das Verbessern bzw. Anreichern (enhancing) der Ergebnisse und Weiteres, wie es nachstehend beschrieben ist.
-
Nachdem der Ersatz des Objektcodes (oder die Ersetzungen von SWIs) durchgeführt worden ist, bereitet das App Sicherheitsprogramm bei einem Schritt 310 die sicherheitsverpackte App für die Ausführung auf dem mobilen Gerät vor. Der Objektcode, der durch das Sicherheitsprogramm in die App bzw. der App ersetzt worden ist, stellt generell eine Brücke oder Verbindung zwischen der App und dem Betriebssystem des mobilen Geräts bereit. Die Klassendateien des Sicherheitsprogramms können derart beschrieben werden, als ob sie um die Klassendateien des Betriebssystems herum gewickelt sind. Die Klassendateien des App Sicherheitsprogramms werden auf der Basis der Richtlinien generiert, die früher erzeugt worden sind (durch die Eingabe seitens des Direktors). Die App wird im Wesentlichen neu verdrahtet für die Ausführung auf dem Handgerät. Sie wird neu verdrahtet, um die Programmschicht des App Sicherheitsprogramms zusätzlich zu der Sicherheit zu verwenden, die durch die Systemschicht des Betriebssystems des mobilen Geräts bereitgestellt ist. Dies bedeutet, dass die gesicherte App weiterhin ein Gegenstand für die Sicherheitsvorkehrungen des Betriebssystems sein kann. Bei einem Ausführungsbeispiel können auch gewisse kosmetische Änderungen bei der App ausgeführt werden, wie etwas das Ändern des Icons für die App, um anzuzeigen, dass sie gesichert ist. Indem dies gemacht wird, kann der Benutzer sicher sein, dass dann, wenn das Icon bzw. Symbol der App auf dem Bildschirm des Handgeräts erscheint, die gesicherte Version der App ausgeführt wird. Die App ist nun durch das Sicherheitsprogramm im Wesentlichen neu faktoriert oder neu programmiert bzw. umprogrammiert.
-
Bei einem Schritt 312 wird die App mit einem neuen Schlüssel signiert, beispielsweise mit dem Schlüssel des Serviceproviders bzw. Dienstanbieters oder dem Schlüssel des Unternehmens, das die gesicherte App bereitstellt. Die neu faktorierte, gesicherte Version der App wird zu dem Handgerät zurückgeleitet. Bei einem anderen Ausführungsbeispiel wird die App mit der Sicherheitsschicht auf bzw. in dem Telefon umwickelt bzw. umgeben. Bei einem Schritt 314 wird die originale, nicht gesicherte Kopie der App bei einem Ausführungsbeispiel aus dem Handgerät gelöscht. Dies kann durch die gesicherte Version der App durchgeführt werden, sobald diese auf das Handgerät heruntergeladen worden ist. Bei anderen Ausführungsbeispielen wird dies nicht durchgeführt, und es verbleiben beide Versionen auf dem mobilen Gerät. An dieser Stufe ist der Prozess abgeschlossen.
-
4 zeigt ein Ablaufdiagramm einer Methode, die in dem Policy- bzw. Richtlinienmanager 202 in Übereinstimmung mit einem Ausführungsbeispiel ausgeführt wird. Bei einem Schritt 402 wird der Direktor oder ein anderes Individuum der Sicherheitsrichtlinie in die Lage versetzt, Sicherheitsrichtlinien zu definieren, zu generieren und zu kreieren. Dies kann ein Netzwerkadministrator für ein Unternehmen sein, der eine breite Anordnung von Sicherheitsrichtlinien für mobile Geräte für Hunderte von Angestellten unter Verwendung von Dutzenden von Unternehmens-Apps (speziell für die Arbeit) entscheidet, die auf Hunderte oder Tausende von mobilen Geräten heruntergeladen werden können. An dem anderen Endes des Spektrums kann es ein Elternteil sein, das eine Sicherheitsrichtlinie für drei oder vier Apps festlegt, die für ihr Kind auf ein neues mobiles Gerät heruntergeladen worden sind. Andere Beispiele umfassen das Verhindern oder Zerquetschen einer Spiele App, die GPS verwendet, wodurch eine App daran gehindert wird, ein Mikrofon an dem Gerät für die Aufzeichnung oder die Belauschung einer Konversation, unter vielen anderen, zu benutzen. In jedem Fall kann der Direktor die Kategorie des Apps, den Typus und die Natur des Apps, den Autor, die altersmäßige Geeignetheit und zahlreiche weitere Faktoren in Betracht ziehen. Als Beispiel kann berücksichtigt werden, ob derselbe Autor irgendwelche anderen Apps geschrieben hat, die als schädliche Software klassifiziert worden sein kann oder die eine Sicherheitsbedrohung für das Gerät dargestellt haben. Es kann bestimmt bzw. ermittelt werden, ob es weitere Apps von dem gleichen Autor gibt. Es ist in diesem Stadium der Fall, dass der Direktor entscheidet, welche Regeln für jede App anzuwenden sind. Bei einem Ausführungsbeispiel wird dies durch den Direktor offline durchgeführt. Dies bedeutet, dass es unter Verwendung von Benutzerschnittstellen an einem Heimcomputer oder an einem Netzwerkcomputer eines Unternehmens durchgeführt werden kann, der von einem Administrator benutzt wird, und zwar dort wo Sicherheitstemplates bzw. Sicherheitsschablonen, die durch den Serviceprovider des Sicherheitsprogramms (im Wesentlichen Default-templates) bereitgestellt sind, verwendet werden können oder sehr spezielle Regeln unter Verwendung der Templates bzw. Schablonen festgelegt werden können.
-
Bei einem Schritt 404 werden die Sicherheitsdaten, die bei dem Schritt 402 eingegeben worden sind, durch das Sicherheitsprogramm der App Steuerung für die Schaffung der aktuellen Richtlinien benutzt. Bei einem Schritt 406 wird der Objektcode des Sicherheitsprogramms der App Steuerung auf der Basis der Eingabe seitens des Direktors im Hinblick auf die Sicherheitsrichtlinien generiert, die bei dem Schritt 404 erzeugt worden sind. Der Direktor oder der Serviceprovider kann auch existierende Sicherheitsrichtlinien aktualisieren, falls dies erforderlich ist. Wie vorstehend beschrieben, kann der Objektcode zur Förderung bzw. Verbesserung eines gewissen ursprünglichen Objektcodes verwendet werden, der von der disassemblierten App erhalten ist. Der Verstärkungscode bzw. verbesserte Code wird eingeführt, um die Sicherheits- und Privatsphäreneinstellungen für eine App zu justieren, um hierdurch das Unternehmen und den Endbenutzer zu schützen. Das Verhalten der ursprünglichen App wird geändert, was es dem Direktor erlaubt, zu steuern, wie sich die App verhält. Als Beispiel kann dann, wenn eine App sensitive Kontoinformationen in der Klarform (d. h. nicht verschlüsselt) speichert, das Verhalten geändert werden, derart, dass alle Informationen, die die App kreiert, in verschlüsselter Form gespeichert werden, und die lediglich für jene App zugreifbar sind, unter der Voraussetzung, dass der Schlüssel zu den gespeicherten, persistenten Daten einzigartig für die App sein sollten. In manchen Fällen kann der Verbesserungscode das Verhalten der Apps verbessern, da der Code für ein bestimmtes Einsatzszenario optimiert ist.
-
5 zeigt ein Ablaufdiagramm, das einen Prozess einer sicherheitsverpackten App veranschaulicht, der auf einem Handsatz oder einem mobilen Gerät in Übereinstimmung mit einem Ausführungsbeispiel abgearbeitet wird. Bei einem Schritt 502 wird das Verhalten der App geändert oder modifiziert, wenn die App ausgeführt wird, oder unmittelbar bevor sie auf dem Gerät ausgeführt wird. Als Beispiel kann die Modifikation des Verhaltens eine Authentifizierung während der Initialisierung der App umfassen; beispielsweise eine smart/CAC Karte, oder eine Passwort-Challenge bzw. Herausforderung. Manche Apps, wie sie ursprünglich entworfen sind, mögen eventuell kein Passwort für die Sicherheit fordern, wobei jedoch eine gesicherte Version einer App, die modifiziert worden ist, fordern kann, dass der Benutzer ein Passwort eingibt. Bei einem Schritt 504 wird die gesicherte App auf dem mobilen Gerät durch den Benutzer ausgeführt, der sie aktiviert hat (beispielsweise ein Anklopfen an dem Icon bzw. Symbol, falls das Gerät einen berührungsempfindlichen Bildschirm bzw. Touch-Screen aufweist). Auf die Ausführung der App hin kann die Steuerung bei einem Ausführungsbeispiel eine aus vier Optionen herausgreifen. Wie es im Stand der Technik bekannt ist, führt eine App, wenn sie ausgeführt wird, Aufrufe oder Anforderungen an das Betriebssystem des Geräts durch, um ihre Funktionen auszuführen. In manchen Fällen können diese Anrufe bzw. Aufrufe harmlos sein oder kein signifikantes Sicherheitsrisiko für das Telefon oder das Gerät darstellen. Falls dies der Fall ist, kann zugelassen werden, dass der Aufruf zu dem Betriebssystem durchgeleitet wird, wie dies im Schritt 506 veranschaulicht ist. Hierbei wird der Anruf zu dem Betriebssystem des Geräts durchgeführt und es wird die App in einer normalen Weise abgearbeitet.
-
Falls die Sicherheitsschicht oder Umhüllung um die App herum erkennt, dass die App eine Anforderung ausführt, die eine Sicherheitsbedrohung für das Gerät darstellen kann, kann die App-Sicherheitsschicht die Anforderung verstärken bzw. verbessern oder modifizieren, bevor sie zu dem Betriebssystem oder einer anderen Software oder Hardwarekomponente in dem Telefon weitergeleitet wird. Dies ist bei einem Schritt 508 gezeigt. Bei einem Ausführungsbeispiel bestimmt der Direktor, welche Anrufe zulässig sind, indem die eine oder mehrere Richtlinien überprüft wird bzw. werden. Als ein Beispiel kann der Direktor bestimmen, dass alle Daten in verschlüsselter Form gesichert werden sollten. Bei einem anderen Beispiel kann der Direktor entscheiden, dass lediglich eine ausgewählte Gruppe von vertrauenswürdigen Apps Daten bezüglich einer GPS Koordinate eines Soldaten haben sollte. Bei einem Ausführungsbeispiel gibt es keine Runtime- bzw. Laufzeit-Logik für die Bestimmung dessen, was sicher, eine potentielle Bedrohung oder eine aktuelle Bedrohung ist; dies ist im Wesentlichen vorab durch den Direktor in der Richtlinie deklariert, die bei dem vorstehenden Schritt 404 erzeugt worden ist. Bei einem weiteren Ausführungsbeispiel kann etwas Laufzeitlogik vorhanden sein. Als ein Beispiel kann eine App versuchen, teure SMS Textnachrichten auszusenden. Das App Steuerprogramm kann dies erkennen und die App daran hindern, dass sie mehr als eine gewisse Anzahl von Textnachrichten sendet, wobei sie beispielsweise eine Beschränkung auf die Übertragung von einer Nachricht vorgeben kann. Die Verbesserung bzw. Verstärkung (enhancement) kann etwas Neues hinzufügen, wie beispielsweise eine Passwortanforderung. Bei einem anderen Beispiel kann die gesicherte App dann, wenn der Aufruf bzw. Anruf darin besteht, Daten in dem Speicher des mobilen Geräts zu speichern, aktuell eine Unterstützung bzw. Sicherung der Daten in einem Speicherbereich in der Cloud oder in dem Internet ausführen (d. h. außerhalb des Geräts). Bei einem anderen Beispiel können die Daten, die sich auf den Anruf beziehen, verschlüsselt sein.
-
Bei einem Schritt 510 kann die gesicherte App bestimmen, dass der Anruf bzw. Aufruf eine aktuelle Bedrohung ist und dass er in einer ernsthafteren Weise als bei dem Schritt 508 behandelt werden sollte. Als Beispiel kann entschieden worden sein, dass, basierend auf der Richtlinie für eine App dann, wenn auf eine Kamera an dem Gerät während eines Aufenthalts in einem sicheren Gebäude (z. B. dem Pentagon) zugegriffen wird, die App sofort beendet werden sollte. Bloßes Verbessern der Forderung kann in diesem Fall eventuell nicht ausreichend sein. Bei dem Schritt 510 kann vorgesehen sein, nicht zuzulassen, dass die Anforderung zu dem Betriebssystem oder zu irgendeiner anderen Komponente des Geräts weitergeleitet wird. Allerdings wird in einem Ausführungsbeispiel eine Antwort zu der App zurückgeleitet, wobei allerdings diese Antwort absichtlich nicht genau oder korrekt ist. Sie ist im Wesentlichen eine verschleierte Antwort. Als Beispiel kann sie eine GPS Koordinate sein, die nicht die aktuelle physikalische Koordinate des Geräts ist (beispielsweise befindet sich das Gerät in Kalifornien, wobei aber die GPS Koordinate, die zu der App zurückgeleitet wird, eine Koordinate in Nebraska ist). Dies kann wünschenswert sein, wenn Apps durch Kinder benutzt werden. Andere Beispiele können sein, dass schlechte oder entstellte Datenresultate zurückgegeben werden, falls ermittelt wird, dass eine App, die lediglich innerhalb einer begrenzten Umgebung laufen sollte (z. B. in einem sicheren Bürobereich), außerhalb jener Umgebung läuft (z. B. zu Hause). In diesem Beispiel kann die App partiell verstümmelt werden, so dass die App lediglich auf unklassifizierte Daten zugreifen kann und wobei klassifizierte Informationen auf Null gesetzt werden. In einem weiteren Beispiel kann das App Steuerprogramm dann, wenn ein Benutzer versucht, sensitive Daten von einer klassifizierten App an eine nicht klassifizierte App anzuhängen oder zu kopieren, die Kopie der Daten, die angeheftet werden, auf Abfall ändern oder sie im Wesentlichen bedeutungslos zu machen. Nachdem ein jeweiliger der Schritte 506, 508 oder 510 abgeschlossen ist, führt die sicherheitsverpackte App die Abarbeitung auf dem mobilen Gerät bei einem Schritt 514 weiter.
-
Bei dem Schritt 512 hat die Sicherheitsschicht um die App herum bestimmt bzw. ermittelt, dass der Aufruf, der von der App durchgeführt wird, oder dass das Ausführungsverhalten der App im Generellen ein zu hohes Maß an Sicherheitsbedrohung für das mobile Gerät darstellt. In diesem extremen Fall bestimmt die Sicherheitsschicht, dass die Ausführung der App beendet wird und/oder dass die App gelöscht wird. Als Beispiel kann die App zu viele Ressourcen in dem Telefon wie etwa Bandbreite benutzen, oder sie kann zu viele hoch riskante Aufrufe zu dem Betriebssystem durchführen, wodurch das mobile Gerät übermäßig exponiert wird. In diesem Fall kann die App einfach von dem Telefon gelöscht werden, oder es kann die App beendet werden. Der Benutzer kann gegebenenfalls nicht imstande sein, sie erneut auszuführen oder erneut zu installieren. Als Beispiel kann ein Angestellter die App nicht erneut auf dem Telefon des Unternehmens installieren, da sie sensitive Unternehmensdaten freigelegt hat. Oder es kann bestimmt bzw. ermittelt werden, dass eine App heimlich Daten auf dem Telefon sammelt oder bösartige Software installiert.
-
6 ist ein Diagramm der Systemarchitektur des App-Sicherheit-Steuersystems in Übereinstimmung mit einem Ausführungsbeispiel. Eine Trigger- bzw. Auslöser-Manager-Komponente 602 handhabt zwei Ereignisse, von denen eines für die Erzeugung einer neuen Policy bzw. Richtlinie 604 und das andere für die Aktualisierung von Richtlinienparametern 602 dient. Solche Ereignisse können durch verschiedenartige Systeme getriggert werden. Als Beispiel könnte ein Administrator der Konsole oder ein Direktor eine neue Richtlinie für alle Geräte anwenden (eine manuelle Betätigung). Oder es könnte eine das Netzwerk überwachende Anwendung nach der Erfassung eines verdächtigen Verkehrs, der von einem Gerät (oder einer App) als Ursprung ausgeht, eine neue Richtlinie vorgeben, die einen Benutzer/ein Gerät/eine App daran hindert, auf Netzwerkressourcen zuzugreifen (ein Beispiel einer automatisierten Operation). Die verschiedenartigen Systeme oder Entitäten, die die Autorität zur Veränderung/Aktualisierung von Richtlinien haben, führen dies über den Trigger-Manager 602 durch.
-
Ein neuer Richtlinienausgang bzw. eine neue Richtlinienausgabe 604 wird in eine Richtliniendefinitionsdatei 608 eingegeben, die während der Laufzeit generiert werden kann und die verschiedenartige Typen von Codes und Erweiterungen enthalten kann, beispielsweise spezifisch für die App Steuerung des Serviceproviders, oder für die App/den Benutzer/das Gerät, auf die/den/das die Richtlinie zutrifft. Die Richtliniendefinitionsdatei 608 wird in einen Richtlinien-Compiler 610 eingegeben, der zwei Ausgänge aufweist. Ein Ausgang ist eine Verpackungsdefinitionsdatei 612. Diese Datei wird in eine App Verpackungskomponente 614 eingegeben. Die App Verpackungskomponente 614 ist für die Erzeugung einer sicheren bzw. gesicherten App verantwortlich, indem ein binärer Code des Kunden (nativ oder Bytecode) in eine App injiziert wird, die beispielsweise direkt von einem App Store heruntergeladen worden ist. Oder es könnte die App eine App sein, die der Benutzer auf sein Gerät herunter geladen hat und anschließend zu einem „AppControl” Server bzw. Server für die App Steuerung hochgeladen hat.
-
Die App Verpackungskomponente 614 kann drei Eingänge aufweisen: Apps von einem oder mehreren App Stores 616, Zertifikations-Schlüssel-Managementdaten von einer Komponente 618 für die Identitätsverwaltung, und gehärtete bzw. als Hardware ausgeführte bzw. unflexibler gemachte Komponenten 620. Schlüsselverwaltungsdaten werden dazu benutzt, die Identitäten des Benutzers, des Geräts und der App zu verknüpfen, und um sicherzustellen, dass jegliche Verarbeitung, die einer Richtliniensteuerung unterzogen wird, mit einem/einer spezifischen Benutzer/Gerät/App verknüpft werden kann. Dies stellt auch sicher, dass eine verpackte Anwendung lediglich auf einem spezifischen Gerät laufen kann, um zu verhindern, dass eine bösartige App Richtlinien und gehärtete bzw. gesicherte Komponenten 620 umgeht (als Beispiel „Gerätesicherheitsrahmenwerk”). Der Ausgang von dem App Verpacker 614 ist eine verpackte App 622, die auf ein mobiles Gerät 624 über die Steuerung 626 des Geräts herunter geladen oder installiert wird. Die Verantwortlichkeiten der Gerätesteuerung 626 umfassen: Das Herunterladen einer App von dem App Verpacker; das Sicherstellen, dass eine App, die auf den Geräten läuft, geeignet verpackte Apps sind (als Beispiel sollte eine App, die für einen Benutzer 1 verpackt ist, nicht auf einem Gerät für einen Benutzer 2 installiert werden/laufen; Berichten der Liste/Version von installierten Anwendungen, um der Verwaltungskonsole zu erlauben, Richtlinien für jedes Gerät/jeden Benutzer/jede Anwendung zu steuern; und Richtlinienparameter herunter zu laden, wenn dies geeignet ist. Eine verpackte App 622 residiert auf dem Gerät 624, das mit Richtlinienparametern 628 gekoppelt ist.
-
Nun zurückkehrend zu dem Richtliniencompiler 610 ist der andere Ausgang eine Laufzeit-Richtlinien-Definitionsdatei 630. Diese Datei wird in einen Laufzeit-Richtlinien-Compiler 632 eingespeist, der als Eingabe auch Richtlinienparameter 606 akzeptiert (durch die Verwaltungskonsole oder andere Subsysteme spezifiziert). Der Ausgang von dem Compiler 632 ist eine Geräte-Laufzeit-Richtlinien-Datei 634. Diese Datei 634 wird auf das Gerät 624 heruntergeladen, wie dies als Richtlinienparameter 628 gezeigt ist, und wird dazu benutzt, die Richtlinien anzupassen, die auf die verpackte App 622 angewendet werden.
-
Im Folgenden sind verschiedenartige Benutzungsfälle und Fähigkeiten des App-Steuerungs-Sicherheitsprogramm gemäß der vorliegenden Erfindung beschrieben. Ein Benutzungsfall umfasst die Separierung des Arbeitslebens und des persönlichen Lebens auf einem mobilen Telefon. Es gibt Apps für die persönliche Benutzung durch den Benutzer, und Apps, die der Arbeitgeber des Benutzers (oder ein Geschäftspartner des Arbeitgebers) bereitgestellt haben mag, und es arbeiten die Apps in dem gleichen Telefon, was häufig das persönliche Telefon des Benutzers ist. Der Direktor, der die Sicherheit der Apps bestimmt, die auf dem Telefon des Benutzers gesichert werden müssen, kann Kopier-/Anheftungsvorgänge zwischen Apps blockieren (wie etwa bei Email Apps). Der Direktor kann Richtlinien für die arbeitsbezogenen Apps festlegen, die selektive Bereinigungen von Apps und zugeordneten Dateien ausführen. Auf der Position des Benutzers basierende Richtlinien können auch steuern, wo gewisse Apps ausgeführt werden können. Beispiele für Ebenen des Schutzes aufgrund von bösartiger Software (Malware) sind das Verweigern des Zugriffs zu Kontakten, das Verweigern der Übertragung von SMS ohne Inhalt, und Ähnliches.
-
Ein weiteres Beispiel eines Benutzungsfalls ist eine App-Steuerung. Unter Verwendung der vorliegenden Erfindung kann eine Weiß- und Schwarz-Listung von Apps implementiert sein, und ebenso eine volle Löschung von Apps in Entsprechung zu den Richtlinien, die durch einen Direktor festgelegt sind. Eine App kann isoliert („sand-boxed”) werden, um die anderen Apps, Software und Hardware des Geräts zu schützen. Andere Fähigkeiten können die auf der Identität basierende Steuerung von Apps oder Dienstleistungen und eine stark körnige Steuerung über das Verhalten von Apps enthalten. Eine Identifikation von Trojanern ist ein anderer Einsatzfall, der mit dem App-Sicherheitsprogramm implementiert werden kann. Als ein Beispiel können jede App und jeder Inhalt verschlüsselt werden, um zu verhindern, dass aggressive Apps Zugriff zu vertraulichen Daten auf dem Telefon erhalten und diese stehlen. Das Sicherheitsprogramm kann auch dazu imstande sein, ein anormales Verhalten von Systemaufrufen einer App zu identifizieren, um bösartige Trojaner Apps zu identifizieren, die außerhalb ihrer publizierten Absicht agieren.
-
Ein weiterer Benutzungsfall ist das Back-up Sichern und die Wiedergewinnung von Daten von Apps, bei dem Administratoren der IT Sicherheit und Direktoren eine Datenrevisionskontrolle haben und eine Migration bzw. Wanderung von Apps und Geräteinhalt durch Back-up und Wiederherstellungsoperationen implementieren können. Bei einem weiteren Benutzungsfall erfolgt eine Überwachung des Netzwerkverkehrs. Die App auf dem mobilen Gerät kann unter die Sichtbarkeit bzw. Sichtungsüberprüfung von existierender Infrastruktur des Unternehmens für IDS/IPS/Web-Filterung gebracht werden, um eine Inspektion und eine Steuerung von App Kommunikationen zu erlauben. Das App Sicherheitsprogramm kann auch mit DNS Dienstleistungen von dritter Seite wie etwa mit dem DNS Service von Symantec integriert werden, um bösartige Software zu identifizieren. Alle App Kommunikationen können verschlüsselt werden, einschließlich von Kommunikationen bei dem Serviceprovider des Mobiltelefons. Andere Benutzungsfälle umfassen die Sitzungskontinuität, die Privatsphäre des Verbrauchers (beispielsweise eine GPS Verschleierung, das Implementieren von sicheren DNSs), und das Abfangen von Zahlungs-/Transaktionsnachrichten von dem mobilen Gerät (d. h. das Arbeiten in der Mitte von mobilen kommerziellen Strömen bzw. streams).
-
Bei einem Ausführungsbeispiel wird der App Sicherheitsservice durch einen Serviceprovider von dritter Seite angeboten, um beispielsweise Apps zu erzeugen, die durch Endbenutzer oder Individuen benutzt werden (d. h. durch Benutzer, die nicht mit einem Arbeitgeber oder einem Unternehmen verknüpft sind. Als ein Beispiel kann ein Elternteil wünschen, dass die GPS eines Telefons eines Kindes verschleiert wird, da der Elternteil nicht wünscht, dass eine soziale Netzwerk-Seite wie etwa Facebook weiß, wo sich das Kind befindet, indem im Wesentlichen GPS deaktiviert wird. In einem anderen Ausführungsbeispiel kann ein App Store, der durch einen Mobilfunkanbieter (beispielsweise Verizon, AT&T) betrieben wird, gesicherte App für eine zusätzliche Aufladung oder Prämie bzw. Prämiendienste anbieten. Ein Kunde des Anbieters kann die gesicherte App von dem Marktplatz oder einem Online-Geschäft anstelle der ungesicherten Version herunter laden, indem er einen zusätzlichen Betrag bezahlt. Bei einem weiteren Ausführungsbeispiel kann ein Unternehmen seinen eigenen App Store bzw. sein eigenes App Geschäft für seine Angestellten, Partner und dergleichen haben, von dem Benutzer lediglich gesicherte Versionen der Apps (die als „harte” bzw. „gesicherte” Apps bezeichnet werden können) herunter laden können. Diese Apps können viele der vorstehend beschriebenen Sicherheitsmerkmale haben, wie sie durch einen Direktor (einen Sicherheitsadministrator) bei dem Unternehmen definiert sind, wie etwa das Blockieren des Kopierens und Anheftens von Emails oder von Unternehmensdaten, das Beseitigen einer App von dem Telefon eines Benutzers, falls der Benutzer das Unternehmen verlässt, und dergleichen. Eine DNS des Mobilfunkanbieters kann typischerweise auf eine beliebige Seite zugreifen, wobei aber das App Sicherheitsprogramm einen Browser des mobilen Geräts blockieren kann, so dass er lediglich auf ein sicheres DNS (z. B. DNS von Symantec) zugreifen kann, von wo aus lediglich auf sichere Webseiten zugegriffen werden kann. In einem anderen Ausführungsbeispiel kann der Provider des App Sicherheitsprogramms mit dem Hersteller des mobilen Geräts zusammenarbeiten, um das App Sicherheitsprogramm oder die Funktionalität in die Hardware- und Sofwareoperationen des Gerätes zu inkorporieren. Bei diesem Ausführungsbeispiel, wie es nachstehend beschrieben ist, kann ein Benutzer eine nicht gesicherte App herunter laden und kann sie auf dem Telefon oder Gerät selbst sichern, bevor sie ausgeführt wird, und muss nicht auf eine Dienstleistung von dritter Seite zugreifen, um die App zu sichern oder sicherzustellen, dass die App gesichert ist, bevor sie auf das Gerät heruntergeladen wird.
-
Wie anhand der verschiedenartigen, vorstehend beschriebenen Ausführungsbeispiele ersichtlich ist, erstreckt sich die Sicherheit des mobilen Geräts über das Gerät selbst hinaus und wird direkt auf die Apps angewendet, die auf das Gerät heruntergeladen werden bzw. sind. Unternehmen und andere Entitäten sind imstande, den Vorteil auszunutzen, dass Apps noch freier sind, ohne dass sie sich Sorgen über die Sicherheitsrisiken machen müssen, wie etwa über eine Leckage von Daten oder eine Infektion durch Malware des IT Systems des Unternehmens der Firma. Firmen können eine Herrschaft über ihre Unternehmensdaten aufrecht erhalten.
-
Die 7A und 7B veranschaulichen ein Berechnungssystem 700, das für die Implementierung von Ausführungsbeispielen gemäß der vorliegenden Erfindung geeignet ist. 7A zeigt eine mögliche physikalische Form des Berechnungssystems bzw. Computersystems. Selbstverständlich kann das Berechnungssystem viele physikalische Formen einschließlich einer integrierten Schaltung, einer gedruckten Schaltungsplatine, eines kleinen, in der Hand gehaltenen Geräts (wie etwa eines mobilen Telefons, eines Handgeräts oder eines PDA), eines persönlichen Computers oder eines Supercomputers haben. Das Berechnungssystem 700 weist einen Monitor 702, eine Anzeige bzw. Display 704, ein Gehäuse 706, ein Plattenlaufwerk 708, eine Tastatur 710 und eine Maus 712 auf. Die Platte 714 ist ein computerlesbares Medium, das dazu benutzt wird, Daten zu und von dem Computersystem 700 zu übertragen.
-
7B ist ein Beispiel eines Blockschaltbilds für das Berechnungssystem 700. An einem Systembus 720 ist eine breite Vielzahl von Untersystemen angeschlossen. Ein (bzw. mehrere) Prozessor(en) 722 (auch als zentrale Verarbeitungseinheiten oder CPUs bezeichnet) ist bzw. sind mit Speichereinrichtungen gekoppelt, die einen Speicher 724 enthalten. Der Speicher 724 umfasst einen Direktzugriffsspeicher (random access memory, RAM) und einen Festwertspeicher (read-only memory, ROM). Wie im Stand der Technik gut bekannt ist, agiert das ROM bezüglich der Übertragung von Daten und Instruktionen in nur einer Richtung zu der CPU, und das RAM wird typischerweise dazu verwendet, Daten und Instruktionen in einer bidirektionalen Weise zu übertragen. Beide dieser Typen von Speichern können jegliche geeignete der nachstehend beschriebenen computerlesbaren Medien enthalten. Eine Festplatte 726 ist ebenfalls in bidirektionaler Weise mit der CPU 722 gekoppelt; sie stellt eine zusätzliche Datenspeicherkapazität bereit und kann auch jegliche der nachstehend beschriebenen computerlesbaren Medien enthalten. Die Festplatte 726 kann dazu benutzt werden, Programme, Daten und dergleichen zu speichern, und ist typischerweise ein sekundäres Speichermedium (wie etwa eine Festplatte), die langsamer ist als ein primärer Speicher. Es ist positiv anzumerken, dass die Information, die in der Festplatte 726 beibehalten bzw. gespeichert ist, in geeigneten Fällen in standardmäßiger Weise als ein virtueller Speicher in dem Speicher 724 inkorporiert werden kann. Eine entfernbare bzw. tragbare Platte 714 kann die Form von jeglichen der nachstehend beschriebenen computerlesbaren Medien aufweisen.
-
Die CPU 722 ist auch mit einer Vielzahl von Eingabe/Ausgabegeräten wie etwa der Anzeige 704, der Tastatur 710, der Maus 712 und Lautsprechern 730 gekoppelt. Im Allgemeinen kann eine Eingabe/Ausgabeeinrichtung jede beliebige der folgenden sein: Videoanzeigen, Track balls, Mäuse, Tastaturen, Mikrophone, berührungsempfindliche Anzeigen, Wandler-Kartenleser, magnetische oder Papierband-Leser, Tablets, Griffel, Sprach- oder Handschrift-Erkennunungsgeräte, biometrische Lesegeräte oder andere Computer. Die CPU 722 kann optional mit einem weiteren Computer- oder Telekommunikationsnetzwerk unter Verwendung der Netzwerkschnittstelle 740 gekoppelt sein. Bei einer solchen Netzwerkschnittstelle wird in Betracht gezogen, dass die CPU Informationen von dem Netzwerk empfangen könnte, oder Informationen in dem Verlauf der vorstehend beschriebenen Schritte des Verfahrens zu dem Netzwerk ausgeben könnte. Ferner können Ausführungsbeispiele des Verfahrens gemäß der vorliegenden Erfindung lediglich auf der CPU 722 ausgeführt werden, oder können über ein Netzwerk wie etwa das Internet in Verbindung mit einer entfernten CPU ausgeführt werden, die einen Teil der Verarbeitung in aufgeteilter Weise übernimmt.
-
Auch wenn hier illustrierende Beispiele und Anwendungen dieser Erfindung beschrieben und gezeigt sind, sind viele Variationen und Modifikationen möglich, die innerhalb des Konzepts, des Umfangs und des Gehalts der Erfindung bleiben, und es würden diese Varianten für die mit durchschnittlichen Fähigkeiten versehenen Personen des Standes der Technik nach der Durchsicht dieser Anmeldung klar werden. Demgemäß kann davon ausgegangen werden, dass die beschriebenen Ausführungsbeispiele als illustrativ und nicht beschränkend zu betrachten sind, und es ist die Erfindung nicht auf die hier gegebenen Einzelheiten zu beschränken, sondern kann innerhalb des Umfangs und von Äquivalenten der beigefügten Ansprüche modifiziert werden.
