Security Groups (SGs) act as stateful instance-level firewalls, providing fine-grained control for SAP workloads while complementing NACLs, Transit Gateway, and Palo Alto firewalls. The layered approach—common SGs for baseline rules + workload-specific SGs—simplifies management across multi-account, multi-AZ SAP environments.
Key Benefits
Stateful: Automatic return traffic handling.
Layered: Common rules update everywhere instantly.
Least Privilege: Application-specific isolation.
Scalable: Auto Scaling Groups inherit SGs automatically.
Objective
Implement layered SGs for SAP tiers (ASCS, App Servers, HANA DB, Web Dispatcher) ensuring:
Instance-level protection beyond subnet NACLs.
Controlled east-west (tier-to-tier) and north-south traffic.
Auditability via AWS Config and tagging.
Layered SG Design
Layer Purpose Examples
Common SGs Baseline subnet access SSH/RDP from VPN, NTP/DNS, Windows Update
Workload SGs Application-specific HANA 30015 (App→DB only), SAP GUI 32xx (LB→App)
Technical Implementation Steps
Step 1: Create Common Security Groups
SG-Common-Public (Bastions/Firewalls):
Inbound Rules Type Port Source
SSH Admin TCP 22 203.0.113.0/24 Corporate VPN
HTTPS Mgmt TCP 443 0.0.0.0/0 Admin access
Outbound: All traffic (0.0.0.0/0)
SG-Common-Private (All private instances):
Inbound Rules Type Port Source
NTP UDP 123 10.0.0.0/16 VPC CIDR
DNS UDP 53 10.0.0.0/16 VPC CIDR
Outbound: All traffic (0.0.0.0/0)
CLI: aws ec2 create-security-group --group-name SG-Common-Public --description "Public subnet baseline" --vpc-id vpc-0a1b2c3d
Step 2: Create Workload-Specific Security Groups
SG-SAP-ASCS (ASCS Server):
Inbound Type Port Source
SAP ASCS TCP 3600-3610 SG-SAP-App App Servers
Enqueue TCP 3601 SG-SAP-App App Servers
Outbound Ephemeral 1024-65535 SG-SAP-App Reply traffic
SG-SAP-App (Application Servers):
Inbound Type Port Port Range Source
HTTP/HTTPS TCP 80/443 SG-Web-Dispatcher Load Balancer
SAP Dialog TCP 3200-3299 SG-Web-Dispatcher SAP GUI
JCo TCP 50000-50100 SG-SAP-HANA HANA DB
Outbound Ephemeral 1024-65535 SG-SAP-HANA HANA Reply
SG-SAP-HANA (SAP HANA Database):
Inbound Type Port Range Source
HANA Port TCP 30015 SG-SAP-App
HANA System TCP 30017 SG-SAP-App
HANA Dist TCP 3##15-3##17 SG-SAP-App
Outbound Ephemeral 1024-65535 SG-SAP-App
CLI: aws ec2 authorize-security-group-ingress --group-id sg-0a1b2c3d --protocol tcp --port 30015 --source-group sg-sap-app
Step 3: Attach Layered SGs to Instances
Each EC2 instance gets 2 SGs:
SAP App Server: SG-Common-Private + SG-SAP-App
SAP HANA DB: SG-Common-Private + SG-SAP-HANA
SAP ASCS: SG-Common-Private + SG-SAP-ASCS
CLI: aws ec2 modify-instance-attribute --instance-id i-0a1b2c3d --groups sg-common-private sg-sap-app
Step 4: Tagging & Monitoring
Tags:
Environment: Production
Tier: Application
Compliance: PCI-DSS
Owner: SAP-Team
AWS Config Rule: Monitor SG changes:
json
{
"rule": "security-group-allow-ingress-from-internet-to-port",
"scope": "security-group"
}
Step 5: Validation Commands
# Test SAP GUI port from load balancer subnet
nc -zv sap-app.internal 3201
# Test HANA connectivity from app subnet
nc -zv hana-db.internal 30015
# List effective rules for instance
aws ec2 describe-network-interfaces --filters "Name=attachment.instance-id,Values=i-0a1b2c3d"
SG Architecture
Traffic Flow Example (SAP GUI → App Server):
NACL (Public subnet): Allow TCP 3200-3299 → App subnet
SG-Web-Dispatcher: Allow 3200-3299 from LB
SG-Common-Private: Allow ephemeral from public CIDR
SG-SAP-App: Allow 3200-3299 from SG-Web-Dispatcher
Best Practices
SG Referencing: Use SG IDs, not CIDRs for tier-to-tier communication.
No 0.0.0.0/0: Restrict to corporate VPN or specific CIDRs.
Naming: SG-{env}-{tier}-{function} (SG-prd-app-dialog).
Limits: Max 60 inbound rules per SG; use NACLs for subnet rules.
Automation: CloudFormation/Terraform + AWS Config for compliance.
Complete Defense Stack:
Internet → NACL(Public) → SG-Common-Public → Palo Alto FW →
NACL(App) → SG-Common-Private → SG-SAP-App → TGW → Other VPCs
No comments:
Post a Comment