Wer einen Prozeß zur IT-Sicherheit im Unternehmen etablieren will, kommt am IT-Grundschutz nach BSI nicht vorbei. Dabei werden die einzelnen Komponenten eines IT-Verbunds (Anwendungen, Systeme, Infrastruktur, ...) durch Bausteine modelliert. Nach einer darauffolgenden Schutzbedarfsanalyse ergeben sich dann aus den verwendeten Bausteinen die notwendigen Maßnahmen und Informationen darüber, ob gegebenenfalls weiterführende Maßnahmen umzusetzen sind.
Bei in der Cloud gehosteten Servern und Anwendungen fällt die Formulierung bzw. Umsetzung der benötigten Bausteine und Maßnahmen naturgemäß ein ganzes Stück schwerer als bei Anwendungen in der eigenen Netzwerkinfrastruktur. Schwierigkeiten bereiten z.B. die Definition der Zuständigkeiten bzw. der vom Cloud-Anbieter umgesetzten Maßnahmen und erreichten Zertifizierungen.
TÜV TRUST IT hat jetzt in Zusammenarbeit mit Amazon Web Services das Arbeitsbuch "Compliance on Amazon Web Services" veröffentlicht, das Euch dabei helfen soll, IT-Grundschutz nach BSI für bei Amazon AWS gehosteten Servern und Anwendungen umzusetzen.
Ich betreue einige Projekte, bei denen im Hintergrund relationale Datenbanken laufen. Dabei liegt oft auch die Verantwortung für die Bereitstellung und den Betrieb der notwendigen Datenbank-Systeme in meinen Händen. Was liegt da näher, als einen Teil der daraus folgenden Arbeit abzugeben und Datenbanksysteme zu nutzen, deren Qualität ich selber nur mit unverhältnismäßig hohem Aufwand erreichen könnte.
Was sind die Nachteile selbstverwalteter Datenbanksystemen?
Was stört mich am Betrieb selbst verwalteter Datenbanksystemen? Hauptsächlich mein eigener Qualitätsanspruch: Ich möchte nicht, dass eine Anwendung Fehlermeldungen liefert, weil das Datenbank-Backend Probleme bereitet. Ich erwarte zum einen also eine möglichst hohe Verfügbarkeit. Zum anderen gibt es die meist schwammigen Aussagen zu den künftigen Lastanforderungen an das neue System. Dann hat man später entweder Probleme oder man startet gleich mit einem überdimensionierten System. Dazu kommt dann noch das konsistente Sichern der Daten und das regelmäßige Patchen der Systeme.
Ich gebe zu: die genannten Punkte lassen sich jeder einzeln für sich sicher und zufriedenstellend lösen. So habe ich das jahrelang selber gelebt. Aber muss ich mir die Arbeit wirklich selber machen? Kann ich meine Energie nicht viel besser in die bereitzustellende Anwendung stecken, als in die Administration der Datenbanken im Hintergrund der Systeme?
Weniger Arbeit und bessere Datenbanken durch die Cloud
Aus meiner Sicht bieten in der Cloud gehostete Datenbanken entscheidende Vorteile: In den Bereichen Verfügbarkeit, Skalierbarkeit, erreichbare Performance, Sicherheit und Backup werden da Qualitäten erreicht, die ich selber nur mit unverhältnismäßig hohem Aufwand (finanziell und administrativ) erreichen könnte.
Amazon bietet in seinem AWS Portfolio mit Amazon RDS einen für meine Einsatzzwecke nahezu perfekt zugeschnittenen Service an. Continue reading »
Darauf habe bestimmt nicht nur ich seit langem gewartet: Seit gestern ist es möglich, vom Chrome OS Filemanager direkt auf Dateien zuzugreifen, die von einem Server per sFTP zur Verfügung gestellt werden.
Erst im Januar wurde mit Chrome OS 40 die dafür notwendige API "fileSystemProvider" in den Chrome stable channel eingeführt. Diese API soll es Entwicklern ermöglichen, fremde Speicher-Systeme direkt in Chrome OS zu integrieren. Denkbar sind z.B. Webdav-Anbindungen oder Zugriffe auf Dropbox oder Amazon S3.
SFTP FileSystem
Jetzt hat der Entwickler Yoichiro Tanaka die erste App veröffentlicht, die diese API im Einsatz zeigt: sFTP File System. Startet man diese App, öffnet sich ein Dialog zum Anmelden an einem SFTP-Server. Bemerkenswert ist, wie ich finde, dass bereits in dieser ersten Version die Verwendung der Public-Key Authentifizierung vorgesehen ist.
Einmal angemeldet, findet sich das Wurzelverzeichnis des angebunden Servers in der "Dateien"-App. Von dort aus können Dateien dann kopiert oder z.B. direkt in einem lokalen Editor bearbeitet werden. Wenn das Dateisystem nicht mehr benötigt wird, wird es auf die selbe Art und Weise wie ein Wechseldatenträger ausgehängt.
Fazit
Die ersten Tests von SFTP Filesystem haben mich begeistert. Die Anbindung der getesteten SFTP-Server erfolgte problemlos. Dateien lassen sich wie gewohnt verwalten und z.B. nahtlos im Editor der Wahl - ich benutze dafür häufig Caret - bearbeiten. Ich denke, die App sFTP-Client, die ich bisher stattdessen verwendet habe, wird bald von meinen Systemen verschunden sein.
Bei Kunden sehe ich immer wieder interne Webangebote, die im Internet veröffentlicht werden. Häufige Beispiele für solche Webseiten sind Web-basierte Email-Zugänge, wie z.B. Outlook Web Access (owa), oder die Veröffentlichung von Intranet-Anwendungen wie Sharepoint-Seiten oder Wiki-Systemen.
Damit die dahinterliegenden Informationen nur von den richtigen Personen eingesehen werden können, erfolgt eine Authentifizierung der Benutzer beim Aufruf der betreffenden Seite.
Das Problem: die öffentlich zugängliche Benutzerauthentifizierung
Wo liegt das Problem mit derart veröffentlichten Web-Inhalten? Das Problem ist die öffentlich zugängliche Benutzerauthentifizierung. Ein potentieller Angreifer könnte hier beispielsweise von außen durch Ausprobieren (Brute-Force) an gültige Benutzerkennungen gelangen. Dem kann der Administrator dadurch entgegentreten, indem er Benutzerkennungen nach einer festgelegten Anzahl falscher Anmeldeversuche sperren lässt. Wozu das wohl führt, wenn ein automatisiertes Skript trotzdem versucht, die Website mit allen möglichen Benutzer/Passwort-Kombinationen anzusprechen?
Mögliche Lösung: Captchas
Viele Webseiten setzen als Lösung für dieses Problem auf den Einsatz von sogenannten Captchas. Website-Benutzer müssen kryptische Zeichenketten entziffern oder Rechenaufgaben lösen, und zu demonstrieren, dass es sich um eine echte Person handelt, die da gerade die Anmeldemaske ausfüllt.
Traditionell stellt Amazon die AWS Leistungen in US-Dollars (USD) in Rechnung. Das bedeutet für die eigene Buchhaltung natürlich etwas Mehraufwand: Auf der ausgestellten Rechnung sind USD ausgewiesen, von der Kreditkarte werden dagegen die Beträge in Euro zum jeweils aktuellen Umtauschkurs abgebucht.
Außerdem fallen möglicherweise noch Gebühren für den Auslandseinsatz der Kreditkarte an (typisch sind im Moment ca. 1,5% bis 2%).
Abrechnung ab jetzt in Euro möglich
Seit Montag lässt sich jetzt für den eigenen AWS-Account unter den Account Settings die bevorzugte Währung für die Abrechnung auswählen. Die anfallenden Kosten werden dann in die gewünschte Währung umgewandelt und entsprechend in Rechnung gestellt. Einmalzahlungen werden tagesaktuell umgerechnet, für die nutzungsbezogenen Kosten (z.B. EC2-Instanz-Stunden) erfolgt die Umrechnung am Tag der Rechnungsstellung.
Folgende Währungen sind verfügbar:
Australian Dollars (AUD)
Swiss Francs (CHF)
Danish Kroner (DKK)
Euros (EUR)
British Pounds (GBP)
Hong Kong Dollars (HKD)
Japanese Yen (JPY)
Norwegian Kroner (NOK)
New Zealand Dollars (NZD)
Swedish Kronor (SEK)
South African Rand (ZAR)
Die Umrechnungskurse werden von Amazon Services LLC festgelegt und können deshalb geringfügig von den Kursen abweichen, die die eigene Kreditkartenbank in Rechnung stellen würde.
Die Nutzung der Währungsumrechnung durch Amazon ist im Moment nur möglich, wenn als Zahlungsmethode eine Visa oder MasterCard Kreditkarte hinterlegt ist.
Implementierung eines Drop-Only Archiv-Verzeichnisses unter Linux
Wer schreiben darf, darf löschen! Diese Aussage ging mir durch den Kopf, als ein Kunde mir vor Kurzem am Telefon von seiner Idee erzählte: Für das interne Auftragsmanagement soll eine Ablagestruktur auf dem Samba-basierten Fileserver realisiert werden. Die Herausforderung: Die Ablagestruktur soll eine Art "Drop-only"-Ordner sein. Benutzer einer bestimmte Gruppe sollen beliebig Dateien in den Ablageordner schreiben dürfen, anschließend sollen die Dateien allerdings unveränderbar sein. Kein nachträgliches Bearbeiten, kein Umbenennen und schon gar kein Löschen - auch nicht für den Ersteller der Datei.
Problem: Wer schreiben darf, darf löschen
Mein erster Gedanke zu dieser Idee war der eingangs erwähnte: "Wer schreiben darf, darf löschen!" Wenn unter Linux einem Benutzer Schreibrechte auf einem Verzeichnis eingeräumt werden, kann dieser Benutzer in diesem Verzeichnis im Endeffekt alles: Dateien erzeugen, umbenennen und löschen. Dabei ist es total egal, wie die Rechte für die betroffenen Dateien gesetzt sind.
Weil ich bei solchen Problemfragen aber ungern "das geht nicht" sage, sagte ich am Telefon eher so etwas wie "Irgendwie geht das bestimmt - ich denke darüber nach".
Und tatsächlich - so ein Szenario lässt sich umsetzen, und der zugehörende Aufwand hält sich dabei in Grenzen.
Kurz nachdem Google die Alpha Version seines Management-Service für Docker-Container - die "Google Container Engine" - vorgestellt hat, bietet auch Amazon AWS mit dem "EC2 Container Service" eine Preview-Version für ein entsprechendes Werkzeug an. Gleichzeitig hat Microsoft in den letzten Monaten sehr viel Engagement in Richtung Docker gezeigt und eine Partnerschaft mit Docker Inc. bekannt gegeben. Und obwohl ich gestehen muss, dass ich die Entwicklung von Docker bis jetzt eher nur mit einem halben Auge und am Rande verfolgt habe, wird es jetzt höchste Zeit, das zu ändern. Continue reading »
The ShellToolBox 3.0
The only tool you need at first is this box of essential tools.
Ich verwende auf dieser Website Cookies, um den Datenverkehr zu analysieren und so den Inhalt über die Zeit zu optimieren. (für Details dazu, siehe meine Datenschutzerklärung)
