AWS nicht betroffen von Venom-Lücke in Diskettentreiber von KVM und Xen

AWS ist nicht betroffen von der Venom-Lücke in Diskettentreiber von KVM und Xen …

“We are aware of the QEMU security issue assigned CVE-2015-3456, also known as “VENOM,” which impacts various virtualized platforms. There is no risk to AWS customer data or instances.”

http://aws.amazon.com/de/security/security-bulletins/XSA_Security_Advisory_CVE_2015_3456/

German GirlsDay @ AWS Architecture Training

Amazon AWS Architecture Training in Hannover … heute mit neuen Talenten, da bei uns GirlsDay / Zukuznftstag ist und Mitarbeiter-Kinder mal unsere Berufswelt schnuppern sollen. Die 5 Mädchen im Alter von 12-14 Jahren haben tapfer 1 Stunde AWS SQS und SNS ertragen …

(In Germany today we have the Girlsday where young girls have to go for 1 day into companies to learn how Companies are working. So 5 young ladies aged 12-14 years joined my AWS Architecture Course for 1 hour and learned everything about SQS and SNS … 😉

AWS-Training-GirlsDay

Vortrag Datenbank am Limit: spaltenorientiert als Ausweg

Wir alle kennen und schätzen SQL- und NoSQL-­Datenbanken. Doch es gibt Anwendungsfälle, in denen diese Datenbanken an ihre Grenzen stoßen. Zum Beispiel bei der Analyse von Finanzmarktdaten. Dort müssen Zeitreihen von enormer Größe verarbeitet werden.

Am 22. April 2015 hält Michael Wittig, Senior Consultant bei tecRacer, einen Vortrag auf der BigDataCon in Mainz (Link: http://bigdatacon.de/2015/sessions/datenbank-am-limit-spaltenorientiert-als-ausweg) und zeigt auf, wie spaltenorientierte Datenbanken funktionieren. Die Architektur von Tick-Data­-Systeme wird beleuchtet. Der Vortrag endet mit dem Beispiel einer technischen Implementierung für Finanzmarktdaten.

Folien zum Vortrag bei Speacker Deck.

Herr Wittig berät Sie gerne während der Konferenz oder per E-Mail

(mwittig@tecracer.de) inwiefern ein Tick-Data­-System Ihren Datenschatz zugänglich machen kann.

Unser AWS Buch-Projekt “Amazon Web Services in Action”

Es gibt viele Wege, die einem den Einstieg in AWS erleichtern: ein AWS Training mit tecRacer, die umfangreiche Dokumentation von AWS und unzählige Artikel im Internet. Wer gerne mit einem Buch in der Hand in ein Thema einsteigt hatte es bisher aufgrund der sehr gerningen Auswahl schwer.

Michael und Andreas Wittig, beide Senior Consultants bei tecRacer, wollen das ändern.

wittig_cover150Seit Januar 2015 schreiben die beiden Brüder an einem Sachbuch mit dem Titel Amazon Web Services in Action (http://manning.com/wittig?a_aid=awittig&a_bid=cc17df85). Unser Ziel ist es einen umfangreichen Überblick über die Konzepte und Services von AWS zu geben, sagt Andreas Wittig. Ein besonderer Fokus liegt dabei auf dem Thema “Infrastructure as Code”, mit dem eine Automatisierung des Rechenzentrums erreicht werden kann.

Das Know-How und die Erfahrungen bei der Umsetzung von AWS Projekten der beiden Brüder soll im Rahmen von Amazon Web Services in Action mit folgendem Inhaltsverzeichnis weitergegeben werden.

Inhaltsverzeichnis von Amazon Web Services in Action

Part 1: Introduction
1 Introducing Amazon Web Services
2 Rapid Deployment of a Blogging Infrastructure

Part 2: Computing & Network
3 Starting a Virtual Server
4 Programming your Infrastructure
5 Deploying Applications
6 Securing Your System

Part 3: Storage
7 Storing Objects
8 Network attached storage
9 Relational Databases
10 NoSQL database

Part 4: Architecture
11 Designing a highly available infrastructure
12 Decoupling : Avoid dependencies within your system
13 Architecting a Fault Tolerant System
14 Scaling up and down

Ab sofort ist die Vorab-Version von Amazon Web Services in Action verfügbar. Man kann das Buch also schon lesen, bevor es fertig ist. Verrückte agile Welt …

Mit dem Gutschein-Code mlwittig gibt es 50% Rabatt: Amazon Web Services in Action (http://manning.com/wittig?a_aid=awittig&a_bid=cc17df85)
Michael (mwittig@tecracer.de) und Andreas Wittig (awittig@tecracer.de) freuen sich per E-Mail oder in den Kommentaren zu diesem Beitrag über Feedback zum Inhaltsverzeichnis und den ersten Kapiteln.

Danke AWS … CloudTrail Analyse stark vereinfacht

CloudTrail sollte in jedem Account in jeder Region aktiviert sein. Nur dann loggt AWS automatisch alle Aktionen, die von Admins interaktiv in der AWS Console, über die AWS Command Line oder über AWS API-Aufrufe durchgeführt wurden.

Das Logging selbst findet statt in Form von Json-Dateien, die im Gzip-Format in Intervallen von ca. 5 Minuten auf S3 abgelegt werden. Wollte man nun auswerten, wer in einer Security-Gruppe was gemacht hat, kam man eigentlich nur mit Tools weiter, die in der Lage sind, diese grosse Anzahl von Dateien sinnvoll zu importieren und entsprechend auszuwerten (z.B. Splunk oder Loggly).

Seit kurzem hat aber nun AWS uns das Leben wieder ein Stückchen einfacher gemacht. Die letzten 7 Tage sind nun stets über eine Suchmaske sehr einfach auswertbar.

2015-03-25 18_02_48-CloudTrail Management Console

Damit lassen sich spontane Fragen (AWS spricht hier von Troubleshooting Operational Issues) wer hat wann was gemacht lösen.

 

Backup von S3 Content

Wir haben zunehmend Applikationen, die ihre Assets direkt auf S3 speichern und nicht mehr auf irgendwelchen File-Shares.

Braucht man denn da nun noch ein Backup dieser Daten, denn S3 ist ja multi-redundant, d.h. ein physikalischer Datenverlust ist nahezu ausgeschlossen … ?

Ja, man braucht ein Backup, denn auch User löschen versehentlich Daten oder die Applikation könnte einen Bug haben und versehentlich Daten löschen oder überschreiben.

Da die Datenmengen unserer betreuten Applikationen auf S3 recht hoch sind, macht ein stündliches oder nächtliches Script, welches die Daten auf einen anderen S3 Bucket synchronisiert/kopiert, nicht wirklich viel Freude.

Aktuell fahren wir da folgende Ansätze für ein Backup-Konzept von S3-Daten:

Versionierung:

Auf dem entsprechendem S3 Bucket wird Versionierung aktiviert. Dadurch wird beim Überschreiben einer Datei automatisch die alte Version versioniert. Auch beim Löschen einer Datei wird die gelöschte Datei versioniert. Aus diesen versionierten Daten kann man dann jederzeit über entsprechendes Scripting einen gewünschten Status der S3 Daten wider herstellen.

Zusätzlich kann man dann eine entsprechende Lifecycle Rule auf dem S3 Bucket definieren, die älterne Versionen löscht, die älter sind als X Tage. Leider kann man hier nicht definieren, dass man einfach nur die letzen X Versionen haben möchte …

Cross-Region-Replication (existiert seit dem 25.3.2015):

Zusätzlich zu der breits dargestellten Versionierung kann man nun definieren, dass die Inhalte eines S3 Buckets in einen anderen Bucket in einer anderen Region repliziert werden sollen. Dann hat man zum einen noch eine stets aktuelle Sicherung seines Ist-Datenzustands in einer anderen AWS-Region (just in case of ..) und man muss sich bei einem Überschreiben oder versehentlichen Löschen der Daten nicht mit dem Thema Herstellen aus einer Versionierung beschäftigen …

 

Deutsche AWS Enterprise Summit am 24. März 2015

Am 24. März 2015 findet in Frankfurt die erste AWS Enterprise Summit statt. Diese kostenlose 1 Tagesveranstaltung richtig sich an Unternehmen, die Interesse an einem Einstieg in die Amazon AWS Cloud haben.

tecRacer wird als Silver Sponsor mit einem eigenen Stand vertreten sein.

Wir freuen uns besonders, dass unser langjähriger Kunde Herr Barthelmes von B.Braun Aesculap einen Vortrag über unser aktuelles Projekt “Aesculap Academy Website Framework goes AWS” halten wird.

Eine ausführliche Agenda und die Anmeldung finden Sie hier: http://aws.amazon.com/de/campaigns/event-enterprise/

 

Management von n-AWS-Accounts … manchmal hilft Aussitzen

Als autorisierter AWS Managed Service Provider verwalten wir inzwischen richtig viele AWS Accounts für unsere Kunden.

Abrechnungs-technisch ist das Handling von n-AWS Accounts im Rahmen von Consolidated Billing kein Problem, wenn man die Feinheiten verstanden hat … dazu vielleicht mal mehr an anderer Stelle.

Unsere Kollegen im Managed Services Team müssen allerdings stets zwischen diversen AWS Accounts hin und her wechseln. Bisher haben wir das so gelöst, dass die Kollegen in jedem AWS Account einen eigenen IAM-User mit entsprechenden Rechten hatten … und durch das hervorragende Tool 1Password war der Login-Prozess für die Kollegen handhabbar, allerdings war die ständige Eingabe der Tokens im Rahmen der Multi-Factor Authentication sehr nervig.

Gewünscht haben wir uns immer eine zentrale Userverwaltung und ein zentraler Login für alle AWS Accounts. Auf reiner API-Ebene war das schon lange möglich … und man hätte sich damit eine Lösung bauen können wie z.B. diese hier … oder man hätte auch 3rd-Party-Tools von z.B. Okta oder PingOne nehmen können. War aber alles nicht perfekt.

Das Gute an AWS ist, das stets was Neues kommt und wenn man wartet, ist irgendwann die Lösung da. Deswegen hilft bei AWS manchmal auch die Strategie des Aussitzens …

Seit dem 7. Januar unterstützt AWS Offiziell Cross-Account Access in the AWS Management Console.

Alle unsere Kollegen sind nun als IAM-User in einem dedizierten Management-Account angelegt und melden sich da natürlich mittels MFA-Token an. Über entsprechende Links und definierte Rollen haben die Kollegen dann einen Zugang zu den anderen AWS Accounts.

Kommt spät, ist aber gut, danke AWS.

Public Cloud Outages Fewer in 2014

Outages von Cloud-Diensten sind absolut ärgerlich. Im November gab es z.B. einen globalen Ausfall von VisualStudio Online … und ein Programmierer-Team von 4 Leuten konnte an diesem Tag bei uns nicht richtig an einem .NET Projekt weiterentwickeln …

In diesem Artikel wird ein sehr guter Überblick über die Situation der Outages in 2014 bei den grossen Cloud-Providern gegeben.

Einige kommen nicht wirklich gut dabei weg, zu AWS allerdings wird folgendes geschrieben:

Although Amazon Web Services Elastic Compute Cloud (EC2) fared the best overall of the major cloud infrastructure-as-a-service (IaaS) providers with 2.43 hours of downtime total across all regions, based on reports from CloudHarmony

Fatale Abhängigkeiten und Angriffe (aus dem Leben eines Chef / OpsWorkers)

Gestern Abend haben wir noch die letzten Anpassungen am X-OpsWorks-Projekt vorgenommen und noch ein paar Kleinigkeiten optimiert.

Gegen 23:45, als wir gerade die Aktualisierungen auf die letzten Instanzen deployen wollte, mussten wir feststellen, dass keine Deployments mehr möglich waren.

Ursache hierfür war die Nichterreichbarkeit von Rubygems.org, welche von OpsWorks benötigt wird um die entsprechenden Abhängigkeiten für Ruby, sowie der Chef-Module herunterzuladen und zu installieren.

Nach ein wenig Recherche konnten wir herausfinden, dass der Dienst DNSimple, welcher von Rubygems.org genutzt wird, unter weltweiten massiven DDoS-Attacken litt.

Auszug aus http://dnsimplestatus.com/

Update – Our network provider is presently working on increasing capacity to deal with the flood of traffic. We will continue to post updates as we have more details.
Dec 1, 20:42 UTC

Update – We are still working with our network provider to mitigate the volume of traffic and will post more details here as we have them.
Dec 1, 20:21 UTC

UpdateThis attack is volumetric in nature. While we have measures in place for DDoS attacks, they have been overwhelmed by the volume of this attack.
Dec 1, 20:03 UTC

Identified – We have identified a DDoS attack and are working with our network provider to mitigate it.
Dec 1, 19:45 UTC

Investigating – We are seeing DNS connection timeouts on all systems. Currently investigatin

 

Die Attacken auf den Dienst dauerten schon einige Stunden an. Rubygems nutzt zum großteil AWS Ressourcen, unter anderem auch EC2 und CloudFront, hat allerdings die DNS-Verwaltung auf den ServiceDNSimple ausgelagert.

Bis heute morgen um 08:15 waren keine Deployments in OpsWorks dadurch möglich, somit konnten keine neuen Instanzen initialisiert werden und in bestimmten Fällen auch keine bestehenden Instanzen aktualisiert werden.

Dies scheint auch wieder ein gutes Beipiel zu sein, dass das Risiko-Management nicht optimal lief. Wir fragen uns eigentlich nur, warum Rubygems nicht Route 53 genutzt hat, wo doch schon alle anderen Ressourcen auch überwiegend in AWS gehostet sind.