SICHERHEIT IN DER AWS-CLOUD - TRENDTAGE MÄRZ 2019 CIROSEC GMBH JOSHUA TIAGO
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Sicherheit in der AWS-Cloud TrendTage März 2019 cirosec GmbH Joshua Tiago
Einleitung Sicherheit in der AWS-Cloud
Der Weg in die Cloud …
2
Der Weg in die Cloud …
▪ Anforderungen aus den Fachbereichen
▪ Anforderungen aus der Produktentwicklung
– IoT-Anwendung
– Smart Home
– Automotive
▪ Anforderungen der Softwareentwickler
– Agile Entwicklung
3
Bedrohungen
Cloud Security Alliance Top 12
▪ Data Breaches
▪ Insufficient Identity, Credential and Access Management
▪ Insecure Interfaces and APIs
▪ System Vulnerabilities
▪ Account Hijacking
▪ Malicious Insiders
▪ Advanced Persistent Threats
▪ Data Loss
▪ Insufficient Due Diligence
▪ Abuse and Nefarious Use of Cloud Services
▪ Denial of Service
▪ Shared Technology Vulnerabilities
4
Quelle: https://downloads.cloudsecurityalliance.org/assets/research/top-threats/treacherous-12-top-threats.pdf
Bedrohungen
OWASP Cloud Top 10 Security Risks
• AWS: „Als Kunde bleiben Sie
der Eigentümer Ihrer Inhalte“
▪ R1 - Accountability and Data Ownership • Wo ist der Speicherort?
Fehlerhafte Zuordnung von Rechten und Usern
▪ R2 - User Identity Federation zwischen On-Prem und Cloud
▪ R3 - Regulatory Compliance Kennen Sie die rechtlichen
Rahmenbedingungen? BaFin, DSGVO, …
▪ R4 - Business Continuity and Resiliency
• Abhängigkeit von einem Cloud-Anbieter?
▪ R5 - User Privacy and Secondary Usage of Data • Was passiert bei Preiserhöhungen?
▪ R6 - Service and Data Integration • DSGVO, …
▪ R7 - Multi Tenancy and Physical Security • Welche Rechte nimmt sich der
Cloud-Anbieter?
▪ R8 - Incidence Analysis and Forensic Support
▪ R9 - Infrastructure Security
▪ R10 - Non Production Environment Exposure
5
Quelle: https://www.owasp.org/index.php/Category:OWASP_Cloud_%E2%80%90_10_Project
Bedrohungen
OWASP Cloud Top 10 Security Risks
• Werden alle Daten
verschlüsselt übertragen?
• Existiert ein Zugriff von
▪ R1 - Accountability and Data Ownership unautorisierten Geräten?
▪ R2 - User Identity Federation
Sollen Ressourcen mit Partnern
▪ R3 - Regulatory Compliance geteilt werden?
▪ R4 - Business Continuity and Resiliency
▪ R5 - User Privacy and Secondary Usage of Data Welche Möglichkeiten bietet der
Cloud-Anbieter für forensische
▪ R6 - Service and Data Integration Untersuchungen?
▪ R7 - Multi Tenancy and Physical Security
Wie wird die „Infrastructure as a
▪ R8 - Incidence Analysis and Forensic Support Service“ betreut?
▪ R9 - Infrastructure Security
Wie wird sichergestellt, dass
▪ R10 - Non Production Environment Exposure Testumgebungen nicht in der
Cloud landen?
6
Quelle: https://www.owasp.org/index.php/Category:OWASP_Cloud_%E2%80%90_10_Project
Bedrohungen
▪ Allgemeine Risiken sind bekannt …
▪ Aber was bedeutet das für meine Cloud-Umgebung?
▪ Welche Dienste sind problematisch?
▪ Und wie kann ich meine Cloud-Umgebung sicher betreiben?
7
Risken erkennen und minimieren
▪ Um die genauen Risiken einschätzen zu können, muss das IT-
Sicherheitspersonal im Detail verstehen:
▪ Welche Dienste genutzt werden
▪ Wie die Dienste konfiguriert sind
▪ Wer berechtigt ist, auf die Dienste zuzugreifen
▪ Wer für die Systeme verantwortlich ist
8
AWS-Know-how in den Unternehmen
▪ Wer ist typischerweise Experte für AWS-Umgebungen?
– Entwickler oder IT-Sicherheitsverantwortlicher?
▪ In den meisten Fällen beschäftigen sich Entwickler schon seit langer Zeit
mit Cloud-Diensten und haben bereits Know-how aufgebaut
– Im Rahmen von Projekten
– Schulungen/Konferenzen
– Studium
9
AWS aus Sicht eines Entwicklers
▪ Vorteile
– Agile Entwicklung wird erleichtert
– dynamisch
– flexibel
– Hard- und Software wächst im Laufe des Projekts mit
– Kurze Bereitstellungszeiten für Hard- und Software
– Neuste Technologien und Stacks werden unterstützt
– Docker
– Kubernetes
– NoSQL-Datenbanken
– Beliebige Anzahl an Umgebungen
– Entwicklung 1, Entwicklung 2, Build, Test, QA, Prod, …
10AWS aus Sicht eines Entwicklers
▪ Nachteile?
Wenige oder keine!
11Aufgaben und Rollen des Entwicklers
▪ Wenn keine Einschränkungen und Vorgaben in AWS gemacht werden, ist
der Entwickler gleichzeitig:
▪ Architekt
▪ Entwickler
▪ Netzwerkadministrator
▪ FW-Administrator
▪ OS-Administrator
▪ IT-Sicherheitsverantwortlicher
▪ Betrieb
12Rollen und Aufgaben, Cloud vs. On-Premises
▪ In der „On-Premises-Welt“ wurden über Jahre Rollen geschaffen
– Administratoren für:
– OS
– FW
– Netzwerk
– DB
– IT-Sicherheitsexperten
– Entwickler
– Architekten
▪ Experten in den einzelnen Bereichen
▪ Verantwortung klar definiert
13Rollen und Aufgaben, Cloud vs. On-Premises
▪ In der „Cloud-Welt“
– Entwickler ist verantwortlich für Hardware, Design, Betrieb, Sicherheit, …
– Ist der Entwickler Experte in allen Bereichen?
– Kennt er alle Vorgaben und Richtlinien im Unternehmen?
14Vorfälle
15Vorfälle
Wie sieht das bei AWS speziell aus?
▪ Öffentlich erreichbares Management
– Tesla (Februar 2018)
▪ Öffentlich lesbare S3-Buckets
– Booze Allen Hamilton (Mai 2017)
– Dow Jones & Co (Juli 2017)
– Steuern59.ch (September 2018)
– GoDaddy (Juni 2018)
–…
▪ Öffentlich erreichbare Server
– Dow Jones (Februar 2019)
▪ Passwortverlust / entwendete AWS Keys
– Uber (November 2017)
▪ Budget-Attacken
– Greatfire.org
16AWS – Ziele und Strategie
17AWS – Ziele und Strategie
It’s always day one at Amazon
“The outside world can push you into Day 2 if you won’t
or can’t embrace powerful trends quickly. If you fight
them, you’re probably fighting the future. Embrace them
and you have a tailwind”—Jeff Bezos
“Day 2 is stasis. Followed by irrelevance. Followed by
excruciating, painful decline. Followed by death. And
that is why it is always Day 1.”—Jeff Bezos
18AWS – Ziele und Strategie
It’s always day one at Amazon
Bedeutung für die Kunden von AWS
▪ Ständig neue Dienste
▪ Ständig mehr Möglichkeiten
▪ Ständige Veränderung des Angebots
▪ Ständige Anpassung an den Markt
– Keine Fixkosten
– Erweiterung der Rechenkapazität und Standorte
▪ Hohe Flexibilität
19Überblick der AWS-Produkte
20Überblick der AWS-Produkte
Infrastructure as a Service (IaaS)
Platform/Function as a Service (PaaS/FaaS)
Management / Security / Audit (SaaS)
Spezialanwendungen (SaaS)
21Überblick der AWS-Produkte
Von Amazon vorgegebene Kategorien
▪ Compute ▪ Analytics
▪ Storage ▪ Security, Identity, & Compliance
▪ Database ▪ Mobile
▪ Migration & Transfer ▪ AR & VR
▪ Networking & Content Delivery
▪ Application Integration
▪ Developer Tools
▪ AWS Cost Management
▪ Robotics
▪ Customer Engagement
▪ Blockchain
▪ Satellite ▪ Business Applications
▪ Management & Governance ▪ Desktop & App Streaming
▪ Media Services ▪ Internet of Things
▪ Machine Learning ▪ Game Development
22Cloud-Computing oder „Something as a Service“
Gemeinsame/Geteilte Verantwortlichkeit
Daten Daten Daten Daten Daten
Applikationen Applikationen Applikationen Code Applikation
Plattform, Plattform, Plattform, Plattform, Plattform,
Runtime Runtime Runtime Runtime Runtime
Betriebssystem Betriebssystem Betriebssystem Betriebssystem Betriebssystem
Netzwerk Netzwerk Netzwerk Netzwerk Netzwerk Kunde
Kunde und
Hardware Hardware Hardware Hardware Hardware Amazon
Rechenzentrum Rechenzentrum Rechenzentrum Rechenzentrum Rechenzentrum Amazon
On-Prem Iaas PaaS FaaS SaaS
23Rechtemanagement: AWS Identity and Access Management (IAM)
24AWS Identity and Access Management:
Allgemein
▪ IAM verwaltet die Zugriffsrechte von
– User,
– Gruppen,
– Ressourcen
– EC2-Instanzen
– Lambda-Funktionen
–…
▪ auf AWS-Ressourcen wie z. B.
– EC2-Instanzen
– CloudWatch
– S3 Storage
–…
▪ mittels
– Richtlinien (Policies), Boundary Permissions, Service Control Policies
25AWS Identity and Access Management:
Überblick
▪ Grundsätzlich gibt es verschiedene Arten von Benutzern innerhalb von AWS
– IAM-Nutzer
– Rechte dieser Nutzer werden durch IAM-Richtlinien (Policies) gewährt
– Eventuelle Einschränkung der Rechte
– durch weitere IAM-Richtlinien mit „deny“-Regel
– durch Boundary Permissions
– durch Service Control Policies
– Der AWS „root“-Nutzer
– hat zunächst alle Rechte,
– diese können jedoch durch Service Control Policies (siehe Multi-Account-Umgebung) eigeschränkt werden.
– Benutzer, die sich nicht direkt an AWS authentisieren
– SAML, OpenID, weitere AWS-Accounts, …
26AWS Identity and Access Management:
Überblick
▪ IAM unterscheidet zwischen
– IAM-Benutzer (User)
– Gruppen (Groups)
– Können IAM-Benutzer enthalten User
– Rollen (Roles)
Groups
– Berechtigungen von Ressourcen (z. B. EC2-Instanz)
– Nutzer über SAML, weitere AWS-Accounts, …
Role
– IAM-Benutzer nur temporär über Switch Role oder AssumeRole
– Richtlinien (Policies) Policy
– Enthalten Berechtigungen bzw. Beschränkungen
– Können Gruppen, Benutzern Rollen und z.T. Ressourcen zugewiesen werden
– Boundary Permissions und Service Control Policies (werden im Folgenden erläutert)
▪ Die Namensgebung von AWS folgt hier nicht den üblichen Begriffen eines
Rollenkonzepts
27AWS Identity and Access Management:
Benutzer, Gruppen, Rollen
Policy
Groups
IAM User Policy
Policy
weitere
AWS-Accounts
Policy
Role
Policy
28
AWS ServiceAWS Identity and Access Management:
Benutzer, Gruppen und Rollen
▪ IAM-Benutzer
– Können Gruppen zugewiesen werden
– Können Richtlinien zugewiesen werden
▪ IAM-Gruppen
– Können Richtlinien zugewiesen werden
▪ IAM-Rollen ermöglichen das Zuweisen von Richtlinien an:
– IAM-Benutzer aus anderen Accounts
– Dienste und Ressourcen des AWS-Accounts (z. B. EC2-Instanzen)
– Benutzer von anderen Identity Providern (SAML, ADFS)
▪ IAM-Rollen nutzen nur kurzzeitig gültige API Keys (Standard: 3600 s)
29AWS Identity and Access Management:
Richtlinien (Policies)
▪ IAM Policies werden können Benutzern, Gruppen und Rollen zugewiesen
werden
▪ IAM Policies können API Funktionen erlauben („Allow“-Policiy) und
verbieten („Deny“-Policy)
▪ Es ist möglich so genannte Inline Policies zu erstellen.
– Diese werden in das Profil des Nutzers, der Gruppe oder Rolle geschrieben
– Können nicht an andere IAM Objekte angehängt werden
▪ Policies können eingeschränkt werden durch:
– Andere „Deny“ Policies
– Service Controle Policies (SCP)
– Permission Boundary
– Session Policy
30AWS Identity and Access Management:
Erstellen einer Richtlinie mit der GUI
Für welchen Service soll die
Richtlinie gelten? Welche Rechte werden
gewährt/verboten?
Gibt es weitere
Bedingungen? Für welche Ressource
gilt die Richtlinie?
31AWS Identity and Access Management:
IAM-Policy-Aufbau als JSON
{
Version der IAM-Definition
"Version": "2012-10-17",
"Statement": [ Array der Rechte
{
"Sid": "AllowDNSManipulation0",
"Effect": "Allow", Innerhalb der Statements eindeutige ID
"Action": [
"route53:*",
Deny oder Allow Policy
],
"Resource":[
"arn:aws:route53:::hostedzone/Z2HWYBQD3OOEQ"
Liste der API-Aufrufe
],
"Condition": {
"IpAddress": { Einschränkung auf ARNs
"aws:SourceIp": "195.243.60.224/28"
},
"BoolIfExists": { Weitere Bedingungen
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
32AWS Identity and Access Management:
Bedingungen für Richtlinien
▪ Globale Bedingungen ▪ Je nach Service sind
– aws:CurrentTime – aws:SourceIp zusätzliche Bedingungen
– aws:EpochTime – aws:SourceVpc möglich:
– aws:MultiFactorAuthAge – aws:SourceVpce ▪ z. B:
– aws:MultiFactorAuthPresent – aws:TokenIssueTime – ec2:AvailabilityZone
– ec2:EbsOptimized
– aws:PrincipalOrgID – aws:UserAgent
– ec2:InstanceProfile
– aws:PrincipalType – aws:userid
– ec2:InstanceType
– aws:Referer – aws:username
– ec2:PlacementGroup
– aws:RequestedRegion – aws:RequestTag – ec2:Region
– aws:SecureTransport – aws:TagKeys – ec2:ResourceTag
– aws:SourceArn – ec2:RootDeviceType
– ec2:Tenancy
33AWS Identity and Access Management:
Wie greifen die Rechte ineinander
Resource Policy (3)
(Erlaubt auf Basis
der Ressource
den Zugriff
eines
Principals)
Deny-Regel innerhalb einer Policy
für einen Nutzer (1)
Service Control Policy (2)
(beschränkt den Rahmen eines AWS-Accounts)
34AWS Identity and Access Management:
Wie greifen die Rechte ineinander
Resource Policy (3)
(Erlaubt auf Basis
der Ressource
den Zugriff Allow Permission (6)
eines
Principals)
Deny-Regel innerhalb einer Policy
für einen Nutzer (1)
Effective Permissions
Boundary Permission (4)
(beschränkt den Rahmen eines IAM-Nutzers / einer IAM-Gruppe)
Service Control Policy (2)
(beschränkt den Rahmen eines AWS-Accounts)
Assumed Session Boundary Policy (5)
(kann eine Rolle einschränken, die mit 35
AssumeRole impersioniert wird)AWS Identity and Access Management:
Wo können Rechte eingeschränkt und gewährt werden
36
Quelle: https://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/reference_policies_evaluation-logic.htmlKonfigurationsfehler bei S3
Absicherung von Infrastructure as a Service:
Amazon S3 - Überblick
▪ Viele Dienste nutzen S3 als Speicher
z. B.
– Snapshots und Images von VMs
– Logdaten aus CloudTrail/CloudWatch
▪ Einteilung in Buckets
– Innerhalb der Buckets können Ordner und Objekte (Dateien) abgelegt werden
▪ Beispiele:
– s3.aws.cirosec.com
– Da S3 Buckets auch über HTTP GET abgefragt werden kann, lässt sich das Bucket Server für statischen
Webcontent verwenden
38Absicherung von Infrastructure as a Service:
Amazon S3 - Überblick
▪ Bucketnamen sind AWS-weit eindeutig
– “The bucket names must match the names of the website that you are hosting.”
– Wenn also ein Bucket als Webserver verwendet werden soll, muss der FQDN auch als
Bucketname reserviert werden.
▪ Daher: Vorsicht beim Löschen von Buckets:
– “Amazon S3 buckets are unique. If you delete this bucket, you may lose the bucket
name to another AWS user.”
39
Quelle : https://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.htmlBekannte Vorfälle:
US Army, NSA, September 2017
“On September 27th, 2017, UpGuard Director of Cyber Risk
Research Chris Vickery discovered an Amazon Web Services
S3 cloud storage bucket configured for public access. Set
to allow anyone entering the URL to see the exposed
bucket’s contents, the repository, located at the AWS
subdomain “inscom,” contained 47 viewable files and
folders in the main repository, three of which were also
downloadable. The subdomain name provides some
indication as to the provenance of the data: INSCOM, an
intelligence command overseen by both the US Army and
the NSA.”
40
Quelle: https://www.upguard.com/breaches/cloud-leak-inscomAbsicherung von Infrastructure as a Service:
Amazon S3
▪ Vorsicht bei den IAM-Rechten für statische Webseiten
– für den Principal „All“
– IAM-Recht: s3:GetObject
➔ OK (wird benötigt, um GET-Anfragen zu erlauben)
– IAM-Recht: s3:ListObject
➔ Nicht OK (ermöglicht kein Directory Listing, sondern den AWS API-Aufruf:
aws s3 ls s3:/// --no-sign-request --region
– für den Principal „Authenticated User“
(das ist jeder bei AWS authentifizierte Nutzer)
▪ Problem:
– Auf welchen Buckets sind öffentliche Rechte vorhanden?
– Einzelnen Objekten können abweichende Rechte zugewiesen werden?
– Wie kann man hier den Überblick behalten?
▪ Lösungen
– Hier hat Amazon das Security Hub eingeführt.
– Regelmäßiges (automatisches) neu setzen der Berechtigungen
(S3 Batch Operation)
41
Quelle: https://docs.aws.amazon.com/AmazonS3/latest/dev/batch-ops.htmlAbsicherung von Infrastructure as a Service:
Amazon S3
42Logging und Monitoring
Logging und Monitoring:
Dienste bei AWS
▪ CloudWatch
– Zentraler Logserver
– Auswerten und Durchsuchen von Logdaten
– Erstellen von Metriken, Dashboards und Alarmen
– Benachrichtigungen und automatische Reaktion auf Ereignisse
▪ CloudTrail
– Erfassen aller AWS API-Aufrufe
– Abspeichern des Audit-Logs in einen S3 Bucket
– Weiterreichen der Logs an CloudWatch und SNS möglich
▪ X-Ray (nicht weiter betrachtet)
– Profiling von Applikationen
– Erkennung von DoS-Attacken
44Logging und Monitoring:
AWS CloudWatch
▪ Zentraler Logserver und Auswertung bei AWS
– Sammeln allgemeiner Logdaten
– Für die genutzten AWS-Dienste
– Sammeln benutzerdefinierter Logdaten möglich
▪ Auswertung von Logdaten und Erstellung von Metriken für
– AWS-Dienste
– EC2-Ressourcen (CPU, I/O)
– Log-Events
▪ Darstellen der Metriken in Dashboards
▪ Benachrichtigung
– Nachricht bei Überschreitung bestimmter Grenzwerte
– Nachricht bei Erkennung bestimmter Log-Einträge
▪ Automatisierung
– Lastabhängiges Skalieren der Infrastruktur
45Logging und Monitoring:
AWS CloudTrail
▪ Logquelle für alle AWS API-Aufrufe
▪ Kann je nach Konfiguration Logdaten erstellen für
– eine Region
– alle Regionen
– alle Accounts innerhalb einer AWS Organization
(siehe Multi-Account-Umgebung)
▪ Separate Logs möglich für
– Zugriffe auf S3 (vergleichbar mit access.log bei Apache)
– API-Aufrufe von Lambda-Funktionen
▪ Speichert Logdaten in einem S3-Bucket
▪ Kann Logdaten an CloudWatch und SNS weiterleiten
46Logging und Monitoring:
AWS CloudTrail
▪ Ein CloudTrail-Event enthält Informationen über:
– Zeit, Dienst, Region
– API-Aufruf
(inkl. der kompletten Parameter)
– Benutzer
(ARN, Account-ID, Typ, …)
– Verwendete Rolle
– Session-Informationen
(Nutzung von MFA, Session-Start)
47Logging und Monitoring:
Best Practice
▪ CloudTrail für alle Regionen/Accounts aktivieren
▪ Manipulation der Logdateien verhindern/erkennen
– S3 Storage gegen Löschen sicheren (mit IAM-Rechten)
– Aktivieren der S3-Features:
– Logfile Validation
– Bucket Access Logging
– KMS Encryption*
– CloudTrails an CloudWatch weiterleiten
– Zur Auswertung
– Zum Speichern * Hinweis:
KMS (Key Management Service): Dienst zum
Verwalten kryptografischer Schlüssel und
zum Verschlüsseln von Data at Rest
Quellen:
• https://aws.amazon.com/de/quickstart/architecture/compliance-cis-benchmark/ 48
• https://docs.aws.amazon.com/awscloudtrail/latest/userguide/create-s3-bucket-policy-for-cloudtrail.htmlLogging und Monitoring:
Best Practice
▪ Beispiele für Auslöser von Alarmen oder automatischen Reaktionen:
– Authentifizierungsfehler
– Zugriff ohne Mehrfaktor-Authentifizierung
– Unautorisierte API-Events
– Nutzung des Root-Accounts
– Änderung der IAM-Einstellungen
– Änderungen an der CloudTrail-Konfiguration
– Änderung einer S3 Policy (z. B. auf öffentlichen Zugriff erlauben)
– Änderungen an der AWS-Config-Konfiguration
– Änderungen an Security Groups und Netzwerk-ACLs
– Änderungen an den Netzwerk-GW und Routing-Tabellen, Subnetzen und VPCs
– Löschen von KMS-Schlüsseln
49
Quelle: https://aws.amazon.com/de/quickstart/architecture/compliance-cis-benchmark/AWS-Dienste zur Sicherstellung der Integrität der Architektur
AWS-Dienste zur Sicherstellung der Integrität der
Architektur: Überblick
▪ AWS Config
▪ AWS CloudFormation
▪ AWS Service Catalog
51AWS-Dienste zur Sicherstellung der Integrität der
Architektur: AWS Config
▪ AWS Config kann die Konfiguration von AWS-Accounts
(auf Compliance) überprüfen.
– Regelmäßig (alle 1-24 Stunden)
– Oder bei Konfigurationsänderungen
▪ AWS stellt 52 (Stand 16.01.2019) vordefinierte
Regeln bereit
– Weitere Regeln können mit AWS Lambda erstellt werden
▪ Beispiele für AWS-Config-Regeln:
– Alter von Passwörtern und Access Keys
– Konfiguration der Kennwortrichtlinie für IAM-Nutzer
– Nutzung von nicht zugelassenen Amazon Machine Images (AMI)
– Überprüfung der Einstellungen für Datenbankbackups
– Überprüfung, ob EBS Volumes, die keiner EC2-Instanz zugeordnet sind, existieren
52AWS-Dienste zur Sicherstellung der Integrität der
Architektur: AWS Config
53AWS-Dienste zur Sicherstellung der Integrität der
Architektur: AWS CloudFormation
▪ AWS CloudFormation ist der Infrastructure-as-Code-Dienst von AWS
– Infrastructure as Code: Provisionierung und Verwaltung von Ressourcen über Skripte
– In CloudFormation können Ressourcen per Skript (sogenannte Stacks) erstellt, geändert
und gelöscht werden
▪ Änderungen der Infrastruktur lassen sich über ein Update des
entsprechenden Stacks umsetzen
▪ AWS CloudFormation bietet auch eine „Drift Detection“
– Erkennt Abweichungen der definierten Konfiguration zum Stack
54AWS-Dienste zur Sicherstellung der Integrität der
Architektur: AWS CloudFormation
▪ AWS CloudFormation ist der Infrastructure as Code Dienst von AWS.
▪ Infrastructure as Code ermöglicht eine Cloud Infrastruktur, oder nur für
bestimmte Anwendungen per Skript (AWS-Sprech: Stack) erstellen, ändern
und zu löschen.
▪ Änderungen der Infrastruktur lassen sich über ein Update des
entsprechenden Stack umsetzen
▪ AWS CloudFormation bietet auch eine „Drift-Detection“. Diese kann
Abweichungen der aktuellen Konfiguration zum Stack erkennen
55Multi-Account-Umgebungen
Multi-Account-Umgebung:
Amazon-Architekturvorschlag Landing Zone
Root Account
Security Auditing / Billing Global Shared Network User
Logging Services
Development Test Production
Development Test Production
Development Test Production
Development Test Production
Development Test Production
57Multi-Account-Umgebung:
Amazon-Architekturvorschlag Landing Zone
Root Account • Verwalten der Organization
Security Auditing / Billing Global Shared Network User
Logging Services
• Security-Richtlinien
• Benutzerverwaltung
• Compliance • Abrechnung
Development • Controlling
Test Production
Development Test Production • DMZ
Sicheres Aufbewahren • Perimeterschutz
Development der Logdaten Test • Gemeinsame S3 Storages
Production • Transfer zum On-
• … Premises-Netzwerk
Development Test Production • DNS Konfiguration
Development Test Production
Je nach
Je
Development-, nach und
Test-
Bedarf 58
Bedarf müssen je
Production-Accounts
nach Bedarf erstellt werdenMulti-Account-Umgebung:
Amazon-Architekturvorschlag Landing Zone
▪ AWS Organizations Account:
– Single Sign-on (SSO)
– AWS Service Catalog
– Strukturierung der Organization in OUs
▪ Shared Services Account
– Netzwerk
– Gemeinsame Ressourcen
▪ Log Archive Account
– Speicher der CloudTrail- und
CloudWatch-Logs
▪ Security Account
– Überwachung der Security
– Guard Duty
59
Quelle: https://aws.amazon.com/de/answers/aws-landing-zone/Multi-Account-Umgebung:
Account Vending Machine
▪ Der CloudFormation-Stack für die Landing Zone erstellt die gemeinsam
genutzten Accounts und Dienste aus dem Architekturvorschlag von Amazon
▪ Die Accounts von Nutzern/Entwicklern sollten jedoch nach Bedarf erstellt
werden können
▪ Amazon Landing Zone stellt mit der Account Vending Machine eine
Möglichkeit bereit, neue, bereits dem Architekturvorschlag entsprechende
Accounts automatisiert und nach Bedarf zu erstellen
▪ Nutzer können neue Accounts über den AWS Service Catalog erstellen
– Nutzer benötigen nur entsprechende Zugriffsrechte auf AWS Service Catalog
– Nutzer benötigen keine privilegierten Rechte wie z. B. „CreateAccount“
(dies übernimmt AWS Service Catalog)
60Sicherheitslösungen von Amazon
Sicherheitslösungen von Amazon
Marcie
▪ Machine-Learning-basierte Überwachung von CloudTrail-Logs
▪ Klassifizierung von Daten in S3-Buckets anhand:
– Dateierweiterung
– Content-Type
– Schlüsselwörter innerhalb der Dateien
– Regular Expressions
▪ Nur in den Regionen US-West und US-East verfügbar
▪ Analyse der Daten für mehrere Accounts möglich
62Sicherheitslösungen von Amazon
GuardDuty
▪ Threat-Intelligence-Dienst von Amazon
▪ IP Reputation
– Abgleich aller externer Netzwerkverbindungen mit bekannten, für Angriffe
genutzten IP-Adressen
▪ Erkennung von Angriffen auf die Management-Konsole durch die
Überwachung von CloudTrail
▪ Erkennung von DNS-Tunneln über EC2-Instanzen
63Sicherheitslösungen von Amazon
GuardDuty
64Sicherheitslösungen von Amazon
AWS Inspector
▪ Schwachstellenscan von EC2-Instanzen
▪ Erstellung von Schwachstellenberichten
65Sicherheitslösungen von Amazon
AWS Inspector
▪ Schwachstellenscan von EC2-Instanzen
▪ Erstellung von Schwachstellenberichten
66Sicherheitslösungen von Amazon
Security Hub (Preview)
▪ Darstellung des Sicherheitsstatus der Infrastruktur
▪ Dashboard für die Ergebnisse aus
– GuardDuty
– Inspector
– Macie
▪ Zusätzliche Informationen über öffentliche S3-Buckets
▪ Bietet die Möglichkeit, über AWS Config einen CIS-Benchmark gegen die
aktuelle Umgebung laufen zu lassen
67Sicherheitslösungen von Amazon
Security Hub (Preview)
68Fazit
Sicherheit in der AWS-Umgebung
▪ AWS stellt viele Werkzeuge und Konfigurationsmöglichkeiten zur
Verfügung, um die Dienste sicher zu betreiben
– Rechte- und Rollenmanagement
– Logging
– Security Policies
– Monitoring
– Verschlüsselung
– Authentifizierung
– Kostenmanagement
70Sicherheit in der AWS-Umgebung ▪ IT-Sicherheitspersonal sollte kontinuierlich Know-how über AWS aufbauen – Beispielsweise: Schulung „Sicherheit in AWS-Cloud-Umgebungen“ ▪ Rollen und Aufgaben – Ziel: ähnliche Rollen und Verantwortlichkeiten wie in der „On-Premises-Welt“ definieren – Entwickler ist nicht der Experte in allen Bereichen ▪ Sicherheitskonzept für Cloud-Dienste entwickeln – Rechtemanagement – Vorgaben – Richtlinien – Einschränkungen 71
Fragen?
Sie können auch lesen
