Netzwerk- und SQL-Zugriff auf eine RDS-Datenbank beschränken

Einführung

Die Bestelldatenbank akzeptiert Verbindungen aus der gesamten Anwendungs-VPC, und die Anwendung verwendet eine Administratoridentität. Du schränkst Netzwerkzugriffe ein und erstellst einen eigenen Benutzer, der Bestellungen lesen und hinzufügen, aber nicht löschen darf.

Schließe zuerst die Verbindungs- und SQL-Labs ab. Diese unabhängige Umgebung enthält eine primäre PostgreSQL-Datenbank, drei Beispielbestellungen und eine Anwendung. Du prüfst beide Zugriffsgrenzen und entfernst am Ende die Übungsdatenbank.

Bezug zu Zertifizierungen

Dieses Lab bietet einführende praktische Übungen zu folgenden Prüfungsthemen.

Cloud Practitioner (CLF-C02) · Aufgabe 3.5: Sicherheitsgruppen als Grenze für Netzwerkzugriffe verstehen.
Solutions Architect – Associate (SAA-C03) · Aufgabe 1.3: Das Prinzip der geringsten Rechte anwenden und Zugriffe auf Anwendungsdaten beschränken.

Die PostgreSQL-Netzwerkquelle beschränken

In diesem Schritt ersetzt du den breiten VPC-Zugriff durch Zugriff aus der vorbereiteten Anwendungssicherheitsgruppe.

Eine Sicherheitsgruppe steuert, welche Netzwerkverbindungen die Datenbank erreichen dürfen. Sie bestimmt nicht, welche SQL-Operationen ein authentifizierter Datenbankbenutzer ausführen darf. Diese separate Grenze behandelst du im nächsten Schritt.

Lade die vorbereiteten Einstellungen:

cd /home/labex/project
source database.env

Prüfe die Datenbankgruppe und die beiden bereitgestellten Regeldokumente:

aws ec2 \
  describe-security-groups \
  --group-ids "$DB_SECURITY_GROUP_ID" \
  --query 'SecurityGroups[].{Group:GroupName,Ingress:IpPermissions}'

cat broad-rule.json
cat application-rule.json

Die bisherige Regel erlaubt TCP-Port 5432 aus 10.70.0.0/16, sodass auch andere VPC-Clients Verbindungen versuchen können. Die Ersatzregel verwendet UserIdGroupPairs als Referenz auf die Anwendungsgruppe. Eine Gruppenreferenz erlaubt Verkehr von Ressourcen, die dieser Quellgruppe zugeordnet sind; sie kopiert nicht deren Regeln.

Entferne die breite Regel und füge die Anwendungsregel hinzu:

aws ec2 \
  revoke-security-group-ingress \
  --group-id "$DB_SECURITY_GROUP_ID" \
  --ip-permissions file://broad-rule.json

aws ec2 \
  authorize-security-group-ingress \
  --group-id "$DB_SECURITY_GROUP_ID" \
  --ip-permissions file://application-rule.json

Teste eine neue Verbindung aus der Anwendungsquelle:

psql \
  "service=orders-db" \
  --command 'SELECT count(*) FROM orders;'

Du solltest 3 erhalten. Teste anschließend den bereitgestellten Client außerhalb der Anwendungsgruppe:

psql \
  "service=orders-db-external" \
  --command 'SELECT count(*) FROM orders;'

Die Verbindung des externen Clients sollte scheitern. Sein Datenbankpasswort ist gültig, aber seine Netzwerkquelle ist nicht erlaubt. Die vorbereiteten Verbindungsnamen wählen diese beiden Quellen aus. Die Übungsregeln verändern deine Verwaltungsverbindung zu Terminal oder AWS View nicht.

AWS View sollte die Anwendungsgruppe statt des breiten VPC-CIDR als PostgreSQL-Quelle der Datenbank anzeigen.

Einen Datenbankbenutzer für die Anwendung erstellen

In diesem Schritt erlaubst du das Lesen und Einfügen von Bestellungen, ohne administrative Rechte oder Löschrechte zu vergeben.

Eine PostgreSQL-Rolle kann Berechtigungen besitzen. Eine Rolle mit LOGIN kann sich als Datenbankbenutzer anmelden. Datenbankrollen sind von AWS-IAM-Identitäten getrennt: IAM verwaltet die RDS-Ressource, diese SQL-Rechte steuern dagegen Operationen innerhalb von PostgreSQL.

Netzzugriff, Anmeldung und SQL-Berechtigungen sind getrennte Grenzen

Konzeptdiagramm: Netzzugriff, Anmeldung und SQL-Berechtigungen sind getrennte Grenzen.

Erstelle orders_app mit der bereitgestellten privaten Passwortdatei. --set definiert eine psql-Variable; :'app_password' maskiert den Wert sicher als SQL-Zeichenfolge:

psql \
  "service=orders-db" \
  --set=ON_ERROR_STOP=1 \
  --set=app_password="$(cat app-password.txt)" <<'SQL'
CREATE ROLE orders_app LOGIN PASSWORD :'app_password';
GRANT CONNECT ON DATABASE orders TO orders_app;
GRANT USAGE ON SCHEMA public TO orders_app;
GRANT SELECT, INSERT ON orders TO orders_app;
SQL

CONNECT erlaubt Datenbankverbindungen. USAGE erlaubt den Zugriff über das Schema, einen Namensraum für Tabellen. SELECT und INSERT erlauben nur die benötigten Bestelloperationen. Du hast weder DELETE, UPDATE, CREATEDB, CREATEROLE noch Superuser-Rechte vergeben.

Teste die Anwendungsrolle, indem du den privaten Passwortwert an psql übergibst:

PGPASSWORD="$(cat app-password.txt)" psql \
  "service=orders-db-app" \
  --command 'SELECT current_user, count(*) FROM orders;'

Du solltest den Benutzer orders_app und 3 Bestellungen erhalten.

Versuche, eine nicht vorhandene Bestell-ID zu löschen. Die Anweisung kann selbst bei versehentlich zu breiten Rechten keine tatsächliche Bestellung entfernen:

PGPASSWORD="$(cat app-password.txt)" psql \
  "service=orders-db-app" \
  --command 'DELETE FROM orders WHERE order_id = -1;'

Du solltest permission denied for table orders erhalten. Dieser Fehler tritt nach erfolgreicher Netzwerkverbindung und Datenbankanmeldung auf. Er belegt daher eine andere Grenze als der Verbindungsfehler des externen Clients.

Die eingeschränkte Identität in der Anwendung verwenden

In diesem Schritt konfigurierst du die Rolle in der Anwendung und belegst, dass normale Bestelloperationen weiterhin funktionieren.

Ändere die Datenbankidentität und den Verweis auf die Passwortdatei. Behalte beide Endpoint-Felder bei:

jq \
  '.user = "orders_app" | .password_file = "app-password.txt"' \
  app-config.json > app-config.new
mv app-config.new app-config.json

Lies die aktuelle Bestellliste:

curl \
  --silent \
  --show-error \
  --fail \
  http://127.0.0.1:8080/application/orders | jq

Du solltest die drei ursprünglichen Bestellungen und user: orders_app erhalten.

Füge über den HTTP-Endpoint der Anwendung eine Bestellung hinzu. Content-Type teilt der Anwendung mit, dass der Anfrageinhalt JSON ist:

curl \
  --silent \
  --show-error \
  --fail \
  --request POST \
  --header 'Content-Type: application/json' \
  --data '{"order_id":104,"customer":"Kai","total":"5.00"}' \
  http://127.0.0.1:8080/application/orders

Du solltest saved: true und die Bestell-ID 104 erhalten. Lies die Liste erneut:

curl \
  --silent \
  --show-error \
  --fail \
  http://127.0.0.1:8080/application/orders | jq

Du solltest vier Bestellungen erhalten, darunter Kais Bestellung über 5.00. AWS View sollte dieselben gespeicherten Daten und die eingeschränkte Identität anzeigen. Die geringeren Rechte erhalten das benötigte Verhalten der Anwendung. Die Anwendung liest ursprüngliche und neue Bestellungen mit dem eingeschränkten Datenbankbenutzer orders_app.

Die Übungsdatenbank entfernen

In diesem Schritt entfernst du die Datenbank dieses Labs einschließlich ihrer Beispielbestellungen und SQL-Benutzer.

aws rds \
  delete-db-instance \
  --db-instance-identifier orders-db \
  --skip-final-snapshot \
  --query 'DBInstance.DBInstanceIdentifier'

aws rds \
  wait db-instance-deleted \
  --db-instance-identifier orders-db

aws rds \
  describe-db-instances \
  --query 'DBInstances[].DBInstanceIdentifier'

Du solltest [] erhalten. Die Engine und ihre Rollen sind entfernt; der alte Endpoint der Anwendung verbindet sich nicht mehr. Behalte das vorbereitete Netzwerk und seine eingeschränkte Datenbankgruppe. Für die Bereinigung musst du den Datenbankzugriff nicht wieder öffnen.

Zusammenfassung

Du hast PostgreSQL-Verbindungen auf die Anwendungsquelle beschränkt und der Anwendung eine eigene eingeschränkte Rolle gegeben. Der externe Client konnte sich nicht verbinden und die Rolle keine Bestellungen löschen, während normale Lesezugriffe und Einfügungen funktionierten. Anschließend hast du die Übungsdatenbank entfernt und die eingeschränkten Netzwerkregeln beibehalten.

Das nächste Lab stellt verlorene Bestellungen wieder her, indem es einen manuellen RDS-Snapshot in eine neue Datenbank zurückspielt.

Datenbankzugriff auf die Anwendung beschränken