tecRacer ist jetzt Trend Micro Deep Security Cloud Service Provider

TM_Partner_Portal_Logo_150319

Seit Anfang Mai ist tecRacer offizieller Trend Micro Deep Security Cloud Service Provider und verfügt über eine eigene mandantenfähige Deep Security Plattform, die wir unseren Kunden im Rahmen unseres AWS Managed Hosting oder anderen Kunden als SaaS Plattform zur Verfügung stellen.

Der Vorteil für unsere Kunden ist hierbei insbesondere:

  • das pro Server individuell gewählt werden kann, welches der Deep Security Module aktiviert werden soll und nur diese Module müssen dann entsprechend bezahlt werden
  • das die Deep Security Module pro 100-Stunden-Block pro Monat bezahlt werden, so dass auch bei Cloud AutoScaling- oder z.B. Test-Szenarien, bei denen Server nicht immer laufen, der Einsatz von DeepSecurity in diesem Preismodell wesentlich günstiger ist.

Deep Security bietet automatisierte und hoch skalierbare Cloud-Sicherheit:

  • Malware-Schutz mit Web Reputation zum Schutz vor häufig verwendeten Infektionsquellen
  • Überwachung von Datei- und Systemintegrität zu Compliance-Zwecken
  • Erkennung und Abwehr von Eindringlingen zur Abschirmung von ungepatchten Schwachstellen
  • Stateful-Firewall zur Bereitstellung einer anpassbaren Firewall für jeden einzelnen Server
  • Logüberprüfung zur Erkennung wichtiger Sicherheitsereignisse und Erstellung entsprechender Berichte

cloud-service-providers-address-requirements-en

Encrypt files in S3

Last time I wrote about encrypting EBS boot volumes, this week I will continue with the encryption as the main topic by writing about S3 encryption and since it could not have turned out any other way, we will use again KMS for that.

Files in S3 also can be encrypted by using KMS, providing an extra layer of security.
In the example I will use to explain it, I will use:

  • An EC2 instance
  • An IAM role (I will call it “sync”) attached to the EC2 instance
  • S3 Bucket  (I will call it “encrypted-sync”)
  • Key in KMS

Remember that to use roles for applications that run on Amazon EC2 instances instead of AWS credentials is an AWS best practice.

 

Use Case

Files in the server will synchronise with S3 every 5 minutes. The files will be encrypted in S3.

 

Graphical overview

 

Solution

As simple as our scenario: Just a command.

/usr/local/bin/aws s3 --region eu-central-1 sync --sse aws:kms --sse-kms-key-id 611g215z-a7j3-3c6f-g59e-f1e6f53b2et3 /data/ s3://encrypted-sync

 
Here a small explanation for some parts of the command:

--sse (string) Specifies server-side encryption of the object in S3.

--sse-kms-key-id (string) The AWS KMS key ID that should be used to server-side encrypt the object in S3.

 
In order that the synchronisation takes place every 5 minutes, you just need to create a cronjob.

 

Encrypted EBS Boot Volumes

Encryption is an important part of any data protection strategy, and because of that today we are showing how encryption for EBS boot volumes works.

This will aid your security, compliance, and auditing efforts by allowing you to verify that all of the data that you store on EBS is encrypted. Further, because this feature makes use of KMS, you can track and audit all uses of the encryption keys.

 

Creating an Encrypted EBS Boot Volume

First of all you need to create the key you will use to encrypt the boot volume. This is done in IAM:

IAM Management Console

Note that the key must be created in the same region where you want to encrypt the boot volume.

(mehr …)

AWS Monatsrückblick – März 2016

AWS ist eine innovative und schnell wachsende Plattform. Dies ist eine Zusammenfassung des vergangenen Monats.

Ankündigungen und Neuigkeiten

Fehlt eine wichtige Meldung? Ich freue mich über Feedback! Direkt an @andreaswittig oder als Kommentar zu diesem Beitrag.

Rolling Update mit AWS CloudFormation

Wie spielt man am besten ein Update auf alle EC2 Instanzen in einer Auto Scaling Gruppe ein?

Wenn man dem “Immutable Infrastructure” Ansatz folgt  wird ein Update als eine neue Version ausgerollt in dem neue EC2 Instanzen gestartet. Es werden nie Instanzen von einer Version auf die nächste gehoben. Alte Instanzen werden abgeschaltet und durch neue Instanzen ersetzt.

CloudFormation bietet eine einfache Möglichkeit via Update Policy eine Auto Scalling Gruppe in Batches zu aktualisieren.

Ein Beispiel: Eine Auto Scaling Gruppe besteht aus vier Instanzen (grau) die alle auf Version A laufen. Das Rolling Update von Version B (schwarz) wir mit einer Batch Size von 2 durchgeführt. Instanzen die gerade starten sind in blau gehalten.  Die folgende Animation verdeutlicht was passiert:rolling_update

 

 

Qualitätssicherung von AWS-Architekturen

Ist eine Infrastruktur zu AWS migriert oder dort neu entwickelt, stellt sich häufig die Frage nach der Qualitätssicherung. Entspricht das Setup den Best Practices für AWS-Infrastrukturen?

Einen Ordnungsrahmen zur strukturierten Untersuchung der Umgebung kann hierbei das AWS Well-Architected Framework bilden.

AWS_Well-Architected

Betrachtet werden darin die Bereiche Ausfallsicherheit (Skalierungsfähigkeit, Zero-Downtime Deployments, Backup und Desaster Recovery, etc.), Security (Konformität mit AWS Security Best Practices, Compliance in Design und Betrieb, IDS/IPS und WAF-Architekturen, etc.), Performance  (Optimierung von EC2, Netzwerk und EBS, Storage- und DB-Optimierung, Performance-Monitoring, etc.) und Kostenoptimierung (Einsatz und Kombination von Reserved-, On Demand- und Spot-Instances, Nutzung von AWS-Services, Schaffung von Kostentransparenz nach dem Verursachungsprinzip, etc.).

AWS RDS und Oracle Lizenzen

Beim Launch von RDS-Instanzen gibt es für Microsoft SQL Server und Oracle die Option “Bring your own license”. Bei Microsofts SQL Server kann man in der Enterprise und Standard Edition seine eigene Lizenz mitbringen, bei Oracle  muss man bei allen Editionen außer SE One seine eigene Lizenz mitbringen.

Wieviele Lizenzen muss man dann aber konkret besitzen?

In einer OnPremise-Virtualisierungsumgebung (bspw. auf ESX-Hosts) verlangt Oracle, dass alle physikalischen CPU Kerne der zugrundeliegenden Host-Maschine lizenziert werden, weil es theoretisch möglich ist, dass die Oracle-Instanz alle diese Kerne verwendet. Praktisch muss man also u.U. viel mehr CPU-Kerne lizenzieren, als man tatsächlich benutzt.

In AWS RDS verhält es sich anders. Hier werden die virtuellen CPU-Kerne, die über den Instanztypen provisioniert werden, von Oracle lizenztechnisch wie physikalische CPU-Kerne betrachtet.

Wähle ich also z.B. für meine RDS-Oracle Instanz in einem Single-AZ Deployment den Instanztyp db.m4.xlarge aus, so werden mir 4 vCPU zur Verfügung gestellt und genau so viele Oracle CPU-Lizenzen benötige ich dann auch.

Beim Multi-AZ-Deployment verdoppelt sich die Anzahl der benötigten Lizenzen, auch wenn die zweite Instanz nur als Standby im anderen AZ betrieben wird.

Für Microsoft SQL Server stellt sich die Problematik der physikalischen CPU-Kerne nicht, weil hier von vornherein die Maschine (Standard-Edition) bzw. die vCPU-Kerne (Enterprise-Edition) lizenziert werden. Allerdings gelten für die Verwendung der eigenen Microsoft-Lizenzen in der Cloud die Bestimmungen des License-Mobility-Programms von Microsoft.

Sicherheit bei AWS: CIS Benchmarks

Wer sich mit AWS-Sicherheit beschäftigt, kennt die Differenzierung zwischen “Security of the Cloud” (Amazonseitig) und “Security in the Cloud” (Betreiberseite). Auf die Zuständigkeiten beim Accountsetup, Firewalls und Monitoring wird immer wieder hingewiesen – oft fehlt im Praxisbetrieb aber eine ausführliche Richtschnur, welche Punkte für ein gutes Setup sinnvoll und wichtig sind.

Ende Februar ist nun der “CIS Amazon Web Services Foundations”-Benchmark erschienen, der eine strukturierte Übersicht über die grundlegendsten Tätigkeiten beinhaltet und eine Checkliste hierfür direkt mitliefert.

Das CIS (Center for Internet Security) ist eine herstellerunabhängige Organisation, die unter anderem solche Sicherheitsleitlinien und Checklisten herausgibt. Die bereitgestellten Dokumenten decken dabei einen großen Umfang ab, von Webbrowsern über Serverprozesse bis Betriebssystem-Hardening ist fast alles vertreten. Der nun herausgegebene Benchmark ergänzt die schon länger existierenden Benchmarks für Betriebssysteme (u.a. Amazon Linux, Ubuntu, Windows, SLES12) und oft genutzten Daemons (z.B. Apache, SQL Server, Tomcat, MySQL), die sich auch in den meisten AWS-Projekten wiederfinden.

Wem das Durcharbeiten der für Betriebssysteme sehr langen Dokumente zuviel Arbeit ist, der kann mittlerweile auch im Amazon Marketplace vorgehärtete AMIs des CIS erwerben.

Kontrollierter Zugriff ins Internet von privaten Instanzen. Wie geht das?

Sollen EC2 Instanzen ohne öffentliche IP Adresse (im privaten Sub-Netz) den Zugang zum Internet erhalten, ist eine entpsrechende “network address translation” (NAT) Einheit notwendig. Entweder als entsprechende EC2 NAT-Instanz oder seit kurzem mittels dem lang ersehnten NAT-Gateway.

Damit ist der Weg frei für IP-Verbindungen wenn sie von der Instanz im privaten Sub-Netz aufgebaut werden ( initiate outbound connection). Der umgekehrte Weg, Datenverkehr von IP-Verbindungen die aus dem Internet aufgebaut (connection initiated from the internet) werden ist nicht möglich.

Welche Möglichkeiten gibt es nun, den Zugriff ins Internet von den privaten Instanzen weiter einzuschränken (z.B. bestimmte Internet-Domänen) um Risiken des Missbrauchs zu minimieren?

In der Praxis haben sich Proxy basierte Lösungen mittels Squid bewährt. Eine Beschreibung wie eine solche Lösung aussehen kann, wird in diesem Blog-Post “How to Add DNS Filtering to Your NAT Instance with Squid” vom AWS Security Blog gegeben.

Eine weitere Möglichkeit ist der Einsatz einer Sophos UTM Lösung.

Weitere Informationen und Einsatzbeispiele von Squid Proxy Instanzen in Amazon VPC’s sind in diesen Foren-Beiträgen nachzulesen.