SQL Server 2014: Ankündigung RTM

Am 18. März 2014 wurde von der SQL Server Product Group das Verfügbarkeitsdatum für den SQL Server 2014 bekanntgegeben – der 1. April 2014 (hoffentlich kein vorgezogener Aprilscherz). Ab diesem Tag sollen die Datenträger für die Installation und auch die Images für Windows Azure bereitgestellt werden.

Die Liste der Neuerungen in dieser Version findet Ihr unter “What’s New in SQL Server 2014” – und ist für diese Version sehr übersichtlich. Einige der angekündigten Neuerungen wurden bereits ausführlich im Flurfunk behandelt.

Solltet Ihr Fragen zu der kommenden SQL Server-Version oder zu anderen SQL Server-/BI-Themen haben, könnt Ihr Euch jederzeit gerne an unsere SQL Server-eXperts wenden.

SQL Server-Passwortsicherheit

In diesem Artikel möchte ich Ihnen zeigen, dass es ohne große Vorkenntnisse möglich ist, den Passwortschutz bei der SQL Server-Authentifizierung innerhalb vertretbarer Zeiträume zu durchbrechen. Dies soll keine Anleitung für Hacker sein! Deshalb habe ich zwar die verwendeten Tools aufgelistet, aber keine Schritt-für-Schritt-Anleitung beigefügt. Mein Ziel ist es Ihnen damit die Risiken der SQL Server-Authentifizierung aufzeigen und diese den Vorteilen der Windows-Authentifizierung gegenüber zu stellen.

Vorbetrachtungen

Der SQL Server hat zwei verschiedene Authentifizierungsmodi: "Windows Authentifizierung" und "gemischter Modus" (Windows- und SQL Server-Authentifizierung). Welchen Modus Sie verwenden wollen, können Sie bei der Installation festlegen bzw. später im Betrieb jederzeit ändern.

image

Bei der Verwendung des gemischten Modus, können Sie sich entscheiden, welches der beiden Authentifizierungsverfahren Sie verwenden möchten. Leider entscheiden sich jedoch viele Kunden für die SQL Server-Authentifizierung. Dieses Verfahren verwendet die im SQL Server integrierte Benutzerverwaltung, d. h. alle SQL Server-Benutzer müssen im SQL Server angelegt und verwaltet werden.

Windows-Authentifizierung

Bei der Windows-Authentifizierung verwendet der SQL Server die Benutzerverwaltung von Windows (entweder lokal am Computer oder aus der Domäne). Die Passwortsicherheit bei der Windows-Authentifizierung ist im Domänenumfeld gewährleistet, da das Passwort durch Advanced Encryption Standard (AES) geschützt wird. Dieses Verfahren wird derzeit als so sicher eingestuft, z. B. ist es in den USA für staatliche Dokumente mit höchster Geheimhaltungsstufe zugelassen.
In Windows werden folgende Verfahren zum Schutz von Passwörtern eingesetzt:

Schema Verfahren

Schlüssel-länge1

Windows-Versionen
LM DES

56-bit

Windows XP, Windows Server 20032
NT MD4

128-bit

in allen unterstützten Windows-Versionen
Digest MD5

128-bit

in allen unterstützten Windows-Versionen
AES3 AES

128-bit
256-bit

Windows Vista, Windows 7
Windows 8, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012

1Ein längeres Passwort als die Schlüssellänge bietet keinen zusätzlichen Schutz. (56bit=7 Zeichen, 128bit=16 Zeichen, 256bit=32 Zeichen).
2Dieses Verfahren ist auch in späteren Windows-Versionen verfügbar, jedoch standardmäßig deaktiviert.
3Nur bei Computern verfügbar, die mit einer Windows-Domäne verbunden sind.

Zusätzlich verfügt das Active Directory noch über weitere Sicherheitssysteme (wie z. B. das Sperren von Konten nach mehrmaliger Falscheingabe des Passworts). Durch die Verwendung entsprechend komplexer Passwortregeln, wird eine Reproduktion des Passwortes weiter erschwert bzw. mit heutigen Mitteln nahezu unmöglich gemacht. Das soll natürlich nicht heißen, dass ein solches Passwort nicht zu reproduzieren wäre – auch dafür gibt es Tools.

Meldet sich ein Benutzer auf einen Windows-Computer an, so werden seine Credentials (auch Domänen-Credential) lokal in drei verschiedenen Formen zwischengespeichert (als LM (LanMan) hash, NT hash und cached-credentials hash). Diese Credentials lassen sich auslesen und analysieren (siehe Artikel: Protecting Privileged Domain Accounts: LM Hashes — The Good, the Bad, and the Ugly). Dieses Verfahren wird auch als Pass-the-Hash Attacke bezeichnet und Microsoft hat dieser Angriffsmethode ein umfassendes White Paper mit entsprechenden Vorschlägen zur Vermeidung gewidmet.

Ein großer Vorteil der Windows-Authentifizierung im SQL Server besteht darin, dass die Anwender mit ihren eigenen Windows-Benutzerkonten arbeiten können und zwischen einer Client-Anwendung und dem Server kein Austausch der Credentials erforderlich ist.

Das Standardvorgehen für eine Anwendung ist Benutzergruppen (Security Group) im Active Directory anzulegen und diesen Gruppen entsprechende Berechtigungen für die jeweilige Aufgabe in der SQL Server-Datenbank zuzuweisen. Anschließend müssen nur noch die jeweiligen Benutzer in die Gruppe aufgenommen werden. Dadurch ist es nicht notwendig, jeden einzelnen Anwender Ihres Unternehmens im SQL Server zu berechtigen.

Betrachten wir dies am Beispiel der AdventureWorks-Datenbank. Gehen wir davon aus, dass es eine Gruppe von Benutzern gibt, die volles Administrationsrecht für die Datenbank benötigen (z. B. Anlegen und Löschen von Datenbankobjekten). Dafür legen Sie eine Gruppe “dbAdventureWorks_Admin” an. Eine zweite Gruppe soll das Recht bekommen Daten in der Datenbank zu ändern: Gruppe “dbAdventureWorks_Writer”. Eine dritte Gruppe soll nur Auswertungen in der Datenbank durchführen dürfen: Gruppe “dbAdventureWorks_Reader”. Danach können Sie den Gruppen die entsprechenden Benutzer aus dem Active Directory zuweisen, die die jeweiligen Aufgaben übernehmen sollen. Im nächsten Schritt müssen Sie die Benutzergruppen im SQL Server eintragen und können jeder Benutzergruppe die erforderlichen Berechtigungen zuweisen. In dem Beispiel würde das folgendermaßen aussehen:

   1: USE [master]

   2: GO

   3: CREATE LOGIN [W2K12R2dbAdventureWorks_Admin]  FROM WINDOWS WITH DEFAULT_DATABASE=[AdventureWorks]

   4: CREATE LOGIN [W2K12R2dbAdventureWorks_Writer] FROM WINDOWS WITH DEFAULT_DATABASE=[AdventureWorks]

   5: CREATE LOGIN [W2K12R2dbAdventureWorks_Reader] FROM WINDOWS WITH DEFAULT_DATABASE=[AdventureWorks]

   6: GO

   7: USE [AdventureWorks]

   8: GO

   9: CREATE USER [W2K12R2dbAdventureWorks_Admin] FOR LOGIN [W2K12R2dbAdventureWorks_Admin]

  10: CREATE USER [W2K12R2dbAdventureWorks_Writer] FOR LOGIN [W2K12R2dbAdventureWorks_Writer]

  11: CREATE USER [W2K12R2dbAdventureWorks_Reader] FOR LOGIN [W2K12R2dbAdventureWorks_Reader]

  12: GO

  13: ALTER ROLE [db_securityadmin] ADD MEMBER [W2K12R2dbAdventureWorks_Admin]

  14: ALTER ROLE [db_datawriter]    ADD MEMBER [W2K12R2dbAdventureWorks_Writer]

  15: ALTER ROLE [db_datareader]    ADD MEMBER [W2K12R2dbAdventureWorks_Reader]

  16: GO

SQL Server-Authentifizierung

Bei der Verwendung der SQL Server-Authentifizierung, werden Anmeldeinformationen in SQL Server erstellt, die nicht auf Windows-Benutzerkonten basieren. Sowohl der Benutzername als auch das Kennwort werden im SQL Server (master-Datenbank) gespeichert. Benutzer, die mit SQL Server-Authentifizierung eine Verbindung herstellen wollen, müssen ihre Anmeldeinformationen (Anmeldename und Kennwort) verwenden.

Die Gründe die ich bei Kunden höre, warum sie die SQL Server-Authentifizierung verwenden sind sehr vielseitig und einige möchte ich hier nennen und versuchen Gegenargumente anzubringen:

  • “Der Benutzer und das Passwort sind in der Datenbankanwendung hinterlegt.”

    Anmerkung: Leider sind auch heute noch viele Anwendungen auf dem Markt, bei denen der Benutzername und das Passwort fest in der Anwendung hinterlegt sind. Das stellt in sich schon ein Sicherheitsrisiko dar, denn wenn Passwörter in der Anwendung im Klartext abgelegt werden, sind diese mit sehr einfachen Mitteln wieder auszulesen.
  • “Wird von der SQL Server-Authentifizierung auf Windows-Authentifizierung umgestellt, so kann bei einem Domänenbenutzerkonten als Dienstkonto innerhalb der Anwendung das Passwort ablaufen, das Konto gesperrt sein usw.”

    Anmerkung: Wenn es sich um einen Serverdienst handelt, kann man Managed Service Accounts verwenden. Dieser Benutzertyp wurde mit Windows Server 2008 eingeführt und bietet neben den genannten Anforderungen noch viele weitere Vorteile. Des Weiteren gibt es auch für “normale” Domänenbenutzerkonten eine Reihe von Möglichkeiten dieses vor ablaufenden Passwörtern, Kontensperren u. ä. zu schützen.
  • “SQL Server-Konten sind einfacher zu administrieren, da dies auch durch jemanden erfolgen kann, der keine Berechtigungen im Active Directory hat.”

    Anmerkung: Im Active Directory kann man Berechtigungen delegieren. So ist es z. B. möglich Benutzerkonten/Benutzergruppen in eine eigene Organizational Unit (OU) abzulegen und diese OU einem Benutzer zur Verwaltung zuzuweisen.
  • “Windows-Administratoren sollen keinen Zugriff auf die Daten im SQL Server bekommen.”

    Anmerkung: Wenn Sie Ihren Windows-Administratoren nicht vertrauen, sollten Sie diese ersetzen. Ein Windows-Administrator hat immer Zugriff auf die Daten in Datenbanken auf SQL Server auch wenn die Daten in der Datenbank verschlüsselt mit Transparent Data Encryption (TDE) verschlüsselt sind. TDE hat jedoch nichts mit der Authentifizierungsmethode zu tun.

Bei SQL Server 2008 R2 und früheren Versionen liegt das Passwort bei Benutzerkonten mit SQL Server-Authentifizierung im Klartext im Arbeitsspeicher und lässt sich von dort mit einfachen Mitteln auslesen (http://midnightdba.itbookworm.com/VidPages/RecoverSQLPasswords/RecoverSQLPasswords.wmv).

Tatsächliche Gründe für die Verwendung der SQL Server-Authentifizierung sind nur dann gegeben, wenn eine Authentifizierung über die Windows Authentifizierung nicht bzw. nur eingeschränkt möglich ist, wie z. B.

  • in Umgebungen mit gemischten Betriebssystemen (wie z. B. UNIX/LINUX, mobile Geräte mit iOS/Android) zu unterstützen, in denen nicht alle Benutzer von einer Windows-Domäne authentifiziert werden.
  • bei Verbindungen von unbekannten oder nicht vertrauenswürdigen Domänen.
  • in einem SQL Azure-Umfeld.
  • bei der Verwendung von Contained Databases, die zwischen verschiedenen Domänen austauschbar sein sollen.

Die SQL Server-Authentifizierung verwendet Secure Hash Algorithmen (SHA) zum Schutz der Passwörter in der Benutzerverwaltung von SQL Server. Abhängig von der Version werden unterschiedliche Prüfsummenverfahren verwendet:

SQL Server 2000 hat eine ganze Reihe von Möglichkeiten Passwörter auszuspähen (hier einige wenige: MS02-035, SQL Server Information Disclosure Non Vulnerability).

Eines der größten Sicherheitsprobleme bestand in den Versionen vor SQL Server 2005 beispielsweise darin, dass nach der Installation der “System Administrator” (sa) nicht mit einem Passwort geschützt war. Viele Kunden haben vergessen das Passwort zu setzen und so war es jedem Angreifer einfach möglich, eine SQL Server-Instanz zu übernehmen.

Aus den genannten Gründen sollten Kunden dringend auf eine neuere und somit sichere SQL Server-Version migrieren.

SQL Azure arbeitet ausschließlich mit SQL Server-Authentifizierung. Windows-Authentifizierung wird nicht unterstützt. Die Verbindung zu einer SQL Azure-Datenbank erfolgt per SSL. Jedoch muss die Verbindungszeichenfolge innerhalb der Anwendung das Passwort enthalten. Dies stellt wiederum ein Sicherheitsrisiko dar, denn Programme lassen sich analysieren und Passwörter daraus extrahieren. Eine mögliche Lösung ist der Schutz der Verbindungszeichenfolge durch ein Zertifikat.

Die Schlüsselgenerierung mit SHA basieren auf einem mathematischen Verfahren zur Berechnung eines kryptografischen Hashwertes. Besonderheiten eines kryptografischen Hashes auf Basis von SHA sind die Kollisionsfreiheit (es gibt keine zwei Zeichenketten mit demselben Hashwert) und die Unumkehrbarkeit (es gibt kein Verfahren, mit dem man aus einem Hashwert das Passwort bestimmen kann).

Ist man im Besitz des Hashwertes kann man aus diesem mit Hilfe der Brute-Force-Methode das Passwort wieder generieren, indem man aus einem beliebigen Zeichensatz alle möglichen Kombinationen für das Passwort generiert und daraus wird pro Passwort ein Hashwert berechnet. Diesen Hashwert vergleicht man dann mit dem Ausgangs-Hashwert. Die Brute-Force-Methode ist das aufwendigste Verfahren, da man alle möglichen Zeichenkombinationen ausprobiert. Andere Methoden wie z. B.

arbeiten mit vorgegebenen Listen von Passwörtern oder Hashwerten zur Beschleunigung der Berechnung. Die verschiedenen Methoden sind auch miteinander kombinierbar.

Allgemein gilt jedoch: Je länger die Zeichenkette für das Passwort ist, desto aufwendiger ist es mit der Brute-Force-Methode dieses zu reproduzieren. Somit ist es nur eine Frage der Rechenleistung und der Zeit, bis ein Passwort reproduziert werden kann. Die Empfehlung von Microsoft "Sie sollten möglichst lange und komplexe Kennwörter verwenden." hat somit seine Berechtigung und Sie sollten sich deshalb auch an die Empfehlungen von Microsoft bei der Generierung von Passwörtern für den SQL Server halten. Eine einfache Möglichkeit dies sicherzustellen, ist sind die Passwort-Policies zu aktivieren und das Passwort regelmäßig zu ändern.

Passwort-Hashwerte

Wenn ein Benutzer im SQL Server sein Passwort ändert, wird das Passwort nicht im Klartext im SQL Server gespeichert, sondern es wird nur ein berechneter Hashwert des Passworts abgelegt. Das Passwort existiert nicht mehr im Klartext. Wird ein Benutzer bei der Anmeldung am SQL Server aufgefordert, sein Passwort einzugeben, so wird dieses im Hintergrund automatisch in einen Hashwert umgewandelt und mit dem im System hinterlegte Hashwert verglichen. Stimmen beide Hashwerte überein, so geht das System davon aus, dass es sich um das richtige Passwort handelt und melden den Benutzer am System an.

Zur Vorbereitung dieses Tests habe ich neun Benutzer mit verschiedenen Passwörtern auf einem Testsystem angelegt. Da ich Passwörter mit verschiedenen Längen und Komplexität anlegen wollte, habe ich für die Benutzer die Passwort-Policy deaktiviert. Zum Erzeugen der SQL Server-Benutzerkonten habe ich folgendes TSQL-Statement verwendet:

   1: CREATE LOGIN [U1] WITH PASSWORD=N'x', DEFAULT_DATABASE=[master], CHECK_EXPIRATION=OFF,CHECK_POLICY=OFF 

Um ein realistisches Szenario zu verwenden, kann jedes einzelne Zeichen des Passworts aus 95 verschiedenen Zeichen bestehen:

  • Zahlen: 0123456789
  • Buchstaben: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
  • Sonderzeichen: !"#$%&'()*+,-/:;<=>?@[]^_`{|}~

Rein mathematisch ergeben sich nun folgende mögliche Zeichenkombinationen:

Anzahl Zeichen Kombinationen mögliche Passwörter
1 951 95
2 952 9025
3 953 857375
4 954 81450625
5 955 7737809375
6 956 735091890625
7 957 69833729609375
8 958 6634204312890625

Zum Auslesen des Hashwertes für das Passwort stellt Ihnen SQL Server die Sicht sys.sql_logins zur Verfügung. Zum Anzeigen der Passwort-Hashwerte sind Control Server-Berechtigungen im SQL Server erforderlich. Sollten Sie nicht über die entsprechenden Berechtigungen verfügen, so wird der Passwort-Hash als NULL angezeigt.

   1: SELECT [NAME], [PasswordHash]

   2: FROM [SYS].[SQL_LOGINS]

Das Ergebnis der Abfrage sieht folgendermaßen aus:

image

Eine Methode zum Überprüfen eines Passworts mit einem Hashwert stellt die Funktion PWDCOMPARE zur Verfügung.

   1: SELECT name FROM sys.sql_logins 

   2: WHERE PWDCOMPARE('x', password_hash) = 1 ;

Wenn Sie jede mögliche Passwortkombination auf diesem Weg überprüfen wollen, ist dies natürlich sehr aufwendig und belastet den SQL Server.

Einfacher ist es auf einem beliebigen Computer die Hashwerte zu den Passwörtern abzulegen und diese mit einem Programm in die Originalpasswörter zurück zu verwandeln.

Passwortanalyse

Zur Berechnung der Hashwerte zur Reproduktion eines Passworts habe ich das Tool HashCat verwendet. Hierzu gibt es mehrere verschiedene Versionen/Editionen:

hashcat v0.46 Verwendung der CPUs
hashcat lite v0.15  
hashcat plus v0.15 Verwendung der Grafikprozessoren (GPU)

Das Handbuch zu dem Tool findet Sie unter http://hashcat.net/files/hashcat_user_manual.pdf.

Wer mit dem Kommandozeilen-Tool nicht zurechtkommt, für den steht auch eine Oberfläche zur Verfügung. Diese habe ich jedoch in dem Test nicht verwendet.

Die Tests habe ich auf meinem Notebook mit folgender Konfiguration durchgeführt:

  • Processor: Intel Core i7-2760QM (2.40GHz, 4 Kerne)
  • RAM: 32GB
  • Graphics: NVIDIA Quadro 3000M 2GB (240 CUDA-Kerne) an PCIe X16 Gen. 2
  • Betriebssystem: Windows 8
  • Grafikkartentreiber: 320.86

Ich habe alle drei Tools ausprobiert und festgestellt, dass auf meinem System das “hashcat plus” die besten Ergebnisse geliefert hat. Ich habe das Programm anschließend mit verschiedenen Parametern getestet und bin in der optimalen Variante zu folgenden Ergebnissen gekommen:

Passwortlänge geschätzte Zeit (max.) reale Zeit
1   1 s
2   1 s
3 40 ms 1 s
4 3,7 s 3 s
5 6 m 2 m 39s
6 9h 6m 7h 42m
7 36 Tage  
8 9,36 Jahr  

Aufgrund der voraussichtlichen Dauer für die Generierung von Passwörtern mit einer Länge größer als 6 Zeichen habe ich den Test an dieser Stelle beendet.

Bei den geschätzten Zeiten für die Berechnung der Hash-Werte durch die Anwendung kann man auch hier wieder ein mathematisches Modell zugrunde legen. Meine Grafikkarte ist bei der Verwendung von 160 CUDA-Kernen in der Lage 22,5 Millionen Hashwerte pro Sekunde zu berechnen (140.000 Hashwerte pro Kern). Wenn Sie nun wissen, wie viele mögliche Kombinationen der Zeichen innerhalb des Passworts möglich sind (siehe erste Tabelle in diesem Blog), können Sie berechnen, wie lange es maximal dauert, bis ein Passwort einer bestimmten Länge analysiert ist. Wie Sie an meinem Test sehen können, wird das Passwort meistens bereits vor der geschätzten Zeit ausgegeben.

Neben dem Hashcat-Tool gibt es noch eine Reihe weiterer Tools. Diese habe ich jedoch nicht in diesem Test betrachtet.

Fazit

Die Reproduktion von Passwörten mithilfe der Brute-Force-Methode ist nur eine Frage der Rechenleistung und der Zeit. Den Test habe ich, wie bereits geschildert, auf einem fast zwei Jahre alten Notebook durchgeführt. Moderne Grafikkarten (wie z. B. die Quadro 6000) verfügen über mehr als das Zehnfache an parallelen Recheneinheiten. Zusätzlich unterstützt das Tool hashcat auch die Verwendung von mehreren parallelen Grafikkarten (bis zu 128 GPUs). Mit einer entsprechenden Konfiguration von einigen 1.000 € sollte es somit auch kein Problem sein, mit SHA-2 geschützte Passwörter mit einer Zeichenlänge von 8 oder 9 Zeichen noch in einer vertretbaren Zeit (kleiner als 30 Tage) zu reproduzieren. Ein Passwort, das mit dem SHA1-Verfahren geschützt war, konnten auf meinem System nach nur einem Viertel der Zeit entschlüsselt werden, die für ein mit SHA2 geschützten Passwort erforderlich war.

Persönliche Anmerkung: Warum Microsoft sich entschlossen hat im SQL Server 2012 ein Sicherheitsmechanismus aus dem Jahr 2002 zu integrieren, kann ich nicht nachvollziehen. Zwischenzeitlich gibt es bessere Verfahren z. B. bcrypt, bei denen der Berechnungsaufwand des Hashwertes wesentlich höher ist.

Die Entwicklung der Hardware schreitet immer weiter voran (eine Verdopplung der Leistung moderner Prozessoren erfolgt ca. alle 20 Monate – siehe: Mooreschem Gesetz). Dadurch geraten Verfahren irgendwann an ihre Grenzen, die es ermöglichen Passwörter ohne die Validierung gegen einen Serverdienst zu akzeptieren. Deshalb sollte ein Serversystem keine Hashwerte von Passwörtern zurückgeben, sondern eine Authentifizierung sollte nur gegen das Serversystem direkt möglich sein.
 
Das im SQL Server verwendete Verfahren zur Speicherung von Passwörtern betrachte ich als unsicher. Deshalb ist meine Empfehlung alle Anwendungen, die heute SQL Server-Authentifizierung, auf Windows-Authentifizierung umzustellen. 

Starten von Android auf einem Windows 8-PC

autorImgDiv”>
Sylvio Hellmann

Sylvio Hellmann, Chief eXpert, Manager BI Services
Wenn Sie unter Windows für verschiedene Geräteklassen (Handys, Tabs) und Betriebssysteme wie z. B. Android Anwendungen testen/entwickeln möchte, haben Sie oft das Problem, die entsprechende Hardware dafür bereitzustellen. Außerdem ist dies mit zusätzlichen Kosten verbunden, da Sie die Geräte in einem solchen Fall nur kurzzeitig für Entwicklung/Test benötigen. Eine andere Alternative ist die Verwendung speziellen Emulatoren wie z. B. Bluestacks. Diese haben jedoch oft Limitierungen, die es erforderlich machen, Ihre Software an die entsprechenden Forderungen anzupassen. Doch es gibt eine Alternative, mit der Sie ein Android-System auf einem normalen Windows 8-PC starten können.

image
Eigentlich durch Zufall bin ich auf ein Projekt gestoßen, dass die Portierung von Android auf eine X86-Plattform vorantreibt (http://www.android-x86.org). Auf dieser Projektseite stehen ISO-Images für die verschiedensten Android-Versionen (von Version 2.2 bis 4.3) zum Download zur Verfügung. Nach dem Download haben Sie zwar die Möglichkeit Android als ein Standardbetriebssystem auf die lokale Festplatte Ihres PCs zu installieren, jedoch hat dies den Nachteil, dass Sie Windows nicht parallel nutzen können, denn auch wenn Sie einen Bootlader (z. B. Grub) verwenden, müssen Sie bereits beim Start des PCs entscheiden, welches Betriebssystem Sie verwenden möchte. Doch auch die Verwendung einer Hypervisor-Technologie hat Nachteile z. B. dass es nicht mehr möglich ist direkt auf Hardwarekomponenten (Kamera, Sensoren u. ä.) zuzugreifen.
Für meinen PC habe ich mich dazu entschlossen, Android direkt auf meinem Windows-System zu starten und zwar so, dass ich beide Systeme parallel verwenden kann. Dazu habe ich den Hypervisor von Windows 8 aktiviert – alternativ können Sie auch andere Hypervisor wie z. B. VMWare, VirtualBox oder Quem verwenden. Da aber mit Windows 8 in der Pro und Enterprise Edition bereits HyperV als HyperVisor mitgeliefert wird, war dies für mich die einfachste Lösung. Zum HyperV unter Windows 8 sollten Sie jedoch einiges wissen, dass Oliver Niehus auf seinem Blog sehr schön zusammengestellt hat.
Eine Anleitung mit Screenshots zur Konfiguration der virtuellen Maschine und der Installation und Konfiguration von Android finden Sie auf meinem Skydrive.

Fazit: Das Einrichten einer Android-Umgebung auf einem “normalen” PC ist ohne Probleme möglich und kann auch ohne tiefergehende Kenntnisse schnell aufgesetzt werden. Die Lösung ist für Test und Entwicklung vollkommen ausreichend, solange man nicht aus der Anwendung nativ auf Hardwarekomponenten zugreifen möchten.