Warum ein AWS-Konto nicht ausreicht

Die meisten AWS-Reisen beginnen auf die gleiche Weise. Jemand erstellt ein Konto mit einer Firmenkreditkarte, startet ein paar Dinge und es funktioniert. Dann kommen mehr Teams, Produktion und Testing teilen sich denselben Account, jemand hat Administratorrechte, der nicht sollte, und niemand kann sagen, welche Ressourcen zu welchem Projekt gehören.

Die Lösung ist ein Multi-Account-Setup, das normalerweise als Anlandungsgebiet- Ich weiß . Es klingt wie Unternehmensbürokratie, aber es ist eine der besten Investitionen, die ein wachsendes Unternehmen in AWS machen kann. (Azure und Google Cloud haben ähnliche Konzepte, die ich am Ende behandeln werde.)

Warum die Konten aufteilen?

Ein AWS-Konto ist die stärkste Isolationsgrenze, die AWS bietet. Die separaten Konten geben Ihnen:

• Sicherheitseinzelung. Ein kompromittiertes Entwicklerkonto kann die Produktion nicht berühren.
• Grenzen des Explosionsradius. Ein ausgelaufenes Skript oder eine falsche Konfiguration bleibt auf einem Konto.
• Klarer Kostenverteilung. Jede Rechnung gehört einem Team oder einer Umgebung.
• Dienstleistungskvoten pro Konto, so dass ein Team nicht alle Grenzen ausgeschöpft haben kann.
• Einfache Berechtigungen. Statt komplexer IAM-Richtlinien, die Teams in einem Konto trennen, geben Sie Teams Zugriff auf ihre eigenen Konten.
• Einsicht in die Konformität. Regulierte Arbeitslasten (wie die Zahlungsabwicklung) werden in ihren eigenen Rechnungen mit strengeren Kontrollen erfasst, was die Prüfungserfordernisse einschränkt.

Eine typische Kontostruktur

AWS Organisations ermöglicht es Ihnen, viele Konten zentral zu verwalten und in Gruppen zu gruppieren Organisationseinheiten (OE):

Root (management account: billing and organisation only)
├── Security OU
│   ├── Log Archive      (central, immutable logs)
│   └── Security Tooling (GuardDuty, Security Hub, audit access)
├── Infrastructure OU
│   ├── Network          (Transit Gateway, shared networking, DNS)
│   └── Shared Services  (CI/CD, container registry)
├── Workloads OU
│   ├── Prod OU
│   │   ├── shop-prod
│   │   └── search-prod
│   └── Non-Prod OU
│       ├── shop-staging
│       └── shop-dev
└── Sandbox OU
    └── personal and experiment accounts (with budgets)

Schlüsselregeln: keine Arbeitslasten im Managementkonto, und halten Sie die Protokolle in einem separaten Konto, das die Arbeitsbelastungsteams nicht ändern können.

Konten sind billig. Ein gemeinsames Konto später zu entwirren, ist sehr teuer.

Organisationen, Kontrollturm und SCP

AWS-Organisationen stellt die Hierarchie, konsolidierte Abrechnung und Richtlinien bereit.

Dienstleistungssteuerungsrichtlinien (SCP) sind auf OU oder Konten angewandte Geländer. Sie definieren die maximal zulässigen Berechtigungen, die jeder in diesen Konten haben kann, sogar Administratoren. Beispiele:

• Verweigern Sie die Nutzung von Gebieten, in denen Sie nicht tätig sind.
• Verweigern Sie die Deaktivierung von CloudTrail, GuardDuty oder AWS Config.
• Verweigern Sie, die Organisation zu verlassen.
• Verweigern Sie die Erstellung von IAM-Benutzern mit langlebigen Zugangsschlüsseln.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideEU",
    "Effect": "Deny",
    "NotAction": ["iam:*", "organizations:*", "sts:*", "support:*", "cloudfront:*", "route53:*"],
    "Resource": "*",
    "Condition": {
      "StringNotEquals": { "aws:RequestedRegion": ["eu-central-1", "eu-west-1"] }
    }
  }]
}

(Globale Dienste sind ausgeschlossen, da sie aus US-Regionen bedient werden.)

AWS hat auch Ressourcenkontrolle für die Schutzgeländer an Ressourcen und Erklärungspläne für die Durchsetzung von Dienstkonfigurationen über Konten hinweg.

AWS-Kontrollturm Die Anlage von Landezonen automatisiert: sie erstellt die Kernkonten (Logarchiv, Audit), konfiguriert die Schranken und bietet eine Kontofabrik neue Konten mit einer Standardbasis zu erstellen. Es ist der schnellste Weg, um zu beginnen. Für mehr Anpassung verwenden viele Teams Account Factory für Terraform (AFT) oder Konten ganz bei Terraform verwalten.

Zugriff: IAM Identity Center

Erstellen Sie keine IAM-Benutzer in jedem Konto. Verwendung IAM-Identitätszentrum (ehemals AWS SSO) mit Ihrem Firmenidentitätsanbieter verbunden (Entra ID, Okta, Google Workspace):

• Die Leute melden sich einmal an und wählen aus, welches Konto und welche Rolle sie verwenden.
• Zulassungssätze definieren Rollen wie ReadOnly, Entwickler, Administrator.
• Der Zugriff wird von der Gruppe gewährt und automatisch entfernt, wenn die Personen gehen.
• Die CLI verwendet kurzlebige Anmeldeinformationen (aws sso login).

Alles miteinander verbinden

Konten sind standardmäßig isoliert, also braucht das Netzwerk einen Plan:

• A Netzwerkkonto mit Transit-Gateway die VPCs auf verschiedenen Konten zu verknüpfen oder Geltungsbereich der VPC (RAM) zum Teilen von Subnetzen.
• IP-Pläne Die VPCs werden nicht überlappen.
• Zentralisierte Aus- und Kontrollen gegebenenfalls zum Beispiel gemeinsame NAT oder Firewalls.
• Route 53 private gehostete Zonen, die für interne DNS-Konten gemeinsam genutzt werden.

Sicherheitsbasis für jedes Konto

Automatisch auf jedes neue Konto angewendet:

• CloudTrail (Organisationsspur) zum Protokollarchivkonto
• GuardDuty, Security Hub und AWS Config, verwaltet über das Security Tooling-Konto
• Standard EBS-Verschlüsselung, öffentlicher Zugang zu S3-Blöcken
• Budgets und Kostenmeldungen
• Standard-IM-Rollen für CI/CD mit OIDC

Azure- und GCP-Äquivalente

• BlauDie Datenbank wird von den verschiedenen Netzwerken, die für die Bereitstellung von Datenverarbeitungsprozessen zuständig sind, überwacht. Die Zwischenlandungszone Die Referenzarchitektur (Teil des Cloud-Adoptionsrahmens) ist dem Control Tower gleich.
• Google Cloud wird: die Ressourcenhierarchie der Organisation, Ordner und Projekte mit Organisation Richtlinien. Google stellt eine Anlandungsgebiet Plan und Terraform-Grundbaumodule.

Die Konzepte sind dieselben: Hierarchie, Isolation pro Umgebung und Team, zentrale Geländer, zentrales Logging und Identität.

Also, wo fange ich an?

Wenn Sie noch in einem Konto sind, stellen Sie AWS Organisations und Control Tower jetzt ein, erstellen Sie separate Produktions- und Nichtproduktionskonten und verschieben Sie neue Workloads dorthin. Verlagern Sie alte Arbeitslasten schrittweise. Wenn Sie bereits viele Konten haben, überprüfen Sie, ob SCPs, zentrale Logging und Identitätszentrum vorhanden sind.

Meine Meinung: Eine Landezone ist das Fundament Ihres Wolkenhauses. Es ist langweilig zu bauen, und du wirst es jeden Tag danach danken.

Desly