Chapter 4 — Network Security Architecture

4.1 Zero Trust Networking

Zero Trust Principles

Never Trust, Always Verify

Every network request must be authenticated and authorized
No implicit trust based on network location or origin
Continuous validation of device and user posture

Least Privilege Access

Grant minimum required network access for specific tasks
Implement microsegmentation to limit lateral movement
Use time-bound access controls when possible

Assume Breach

Design networks with the expectation of compromise
Implement multiple layers of network security controls
Focus on detection and rapid response capabilities

Traditional vs. Zero Trust Architecture

Aspect	Traditional Network Security	Zero Trust Network Security
Trust Model	Trust internal network, distrust external	Trust nothing, verify everything
Access Control	Network-based (IP addresses, subnets)	Identity and context-based
Perimeter	Strong network perimeter, weak internal	No perimeter, microsegmentation
Authentication	Network authentication only	Continuous authentication
Visibility	Limited internal network visibility	Full visibility into all traffic

4.2 Secure VPC Design

Network Segmentation Strategy

Environment-Based Segmentation

VPC_Architecture:
  Production:
    CIDR: "10.0.0.0/16"
    Subnets:
      Private_Apps: "10.0.1.0/24"
      Private_Data: "10.0.2.0/24"
      Public_LB: "10.0.100.0/24"

  Staging:
    CIDR: "10.1.0.0/16"
    Subnets:
      Private_Apps: "10.1.1.0/24"
      Private_Data: "10.1.2.0/24"
      Public_LB: "10.1.100.0/24"

  Development:
    CIDR: "10.2.0.0/16"
    Subnets:
      Private_Apps: "10.2.1.0/24"
      Public_LB: "10.2.100.0/24"

Tier-Based Segmentation

Network Tier	Purpose	Security Controls
DMZ/Presentation	Load balancers, web gateways	WAF, DDoS protection, rate limiting
Application	Application servers, containers	NACLs, security groups, service mesh
Data	Databases, storage systems	Encryption, private endpoints, IAM controls
Management	Bastion hosts, monitoring tools	MFA, restricted access, audit logging

Private Subnet Architecture

Design Principles

No direct internet connectivity
All access through controlled gateways
NAT gateways for outbound-only traffic
VPC endpoints for AWS service access

Implementation Example

PrivateSubnetConfiguration:
  AppTier:
    CIDR: "10.0.1.0/24"
    RouteTable:
      - Destination: "10.0.0.0/16"  # Local VPC
        Target: "local"
      - Destination: "0.0.0.0/0"   # Internet outbound
        Target: "nat-gateway-app"

    SecurityGroup:
      Inbound:
        - Source: "10.0.100.0/24"  # Load balancer
          Protocol: "tcp"
          Ports: [80, 443]
      Outbound:
        - Destination: "10.0.2.0/24"  # Database tier
          Protocol: "tcp"
          Ports: [3306, 5432]
        - Destination: "0.0.0.0/0"    # Internet
          Protocol: "tcp"
          Ports: [443]  # HTTPS only

  DataTier:
    CIDR: "10.0.2.0/24"
    RouteTable:
      - Destination: "10.0.0.0/16"  # Local VPC only
        Target: "local"

    SecurityGroup:
      Inbound:
        - Source: "10.0.1.0/24"     # Application tier
          Protocol: "tcp"
          Ports: [3306, 5432]
      Outbound: []  # No outbound access

Secure Connectivity Options

AWS PrivateLink

Private connectivity to AWS services without internet
VPC endpoints for S3, DynamoDB, Lambda, etc.
Interface endpoints for custom applications

Transit Gateway

Central hub for VPC-to-VPC connectivity
Consolidated routing and security policies
Support for VPN and Direct Connect

Bastion Host Alternatives

Method	Advantages	Disadvantages
Traditional Bastion	Simple to implement	Single point of failure, SSH key management
AWS SSM Session Manager	No open ports, IAM integration	AWS-specific, requires agent
Teleport	Zero Trust, session recording	Additional infrastructure, cost
Cloudflare Access	Easy setup, good UX	Cloudflare dependency

4.3 Microsegmentation

Network Segmentation Layers

Layer 3: IP-Based Segmentation

Separate subnets for different application tiers
Route tables to control traffic flow
Network ACLs for additional filtering

Layer 4: Port-Based Segmentation

Security groups controlling port access
Application-specific port restrictions
Dynamic port allocation for containers

Layer 7: Application-Based Segmentation

Service mesh controls (Istio, Linkerd)
Application-aware firewall rules
API gateway-based access control

Implementation Strategies

Container-Based Microsegmentation

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: payment-service-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: payment-service
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api-gateway
    - podSelector:
        matchLabels:
          app: order-service
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432
  - to: []
    ports:
    - protocol: TCP
      port: 443  # External API calls

Service Mesh Segmentation

# Istio Authorization Policy
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: payment-service-authz
  namespace: production
spec:
  selector:
    matchLabels:
      app: payment-service
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/production/sa/api-gateway"]
    - source:
        principals: ["cluster.local/ns/production/sa/order-service"]
  - when:
    - key: request.auth.claims[role]
      values: ["payment_processor", "admin"]

Segmentation Best Practices

Design Principles

Start with deny-all policies
Gradually add specific allow rules
Group services by trust level
Implement both ingress and egress controls
Regular audit and cleanup of rules

Common Patterns

Web tier: Only allow inbound from load balancers
Application tier: Allow inbound from web tier and same-tier services
Data tier: Allow inbound only from application tier
Management tier: Allow inbound from bastion/management tools only

4.4 Flow Logging

Log Collection Strategy

AWS VPC Flow Logs Configuration

FlowLogConfiguration:
  VPCFlowLogs:
    TrafficType: "ALL"  # ACCEPT, REJECT, ALL
    LogFormat: "plain-text"
    MaxAggregationInterval: 600  # 60, 600 seconds

    Fields:
      - "version"
      - "account_id"
      - "interface_id"
      - "srcaddr"
      - "dstaddr"
      - "srcport"
      - "dstport"
      - "protocol"
      - "packets"
      - "bytes"
      - "start_time"
      - "end_time"
      - "action"
      - "log_status"

    Destination:
      Type: "CloudWatch Logs"
      LogGroup: "/aws/vpc/flow-logs"
      Retention: "90_days"

Azure NSG Flow Logs

{
  "properties": {
    "targetResourceId": "/subscriptions/sub-id/resourceGroups/rg-name/providers/Microsoft.Network/networkSecurityGroups/nsg-name",
    "storageId": "/subscriptions/sub-id/resourceGroups/rg-name/providers/Microsoft.Storage/storageAccounts/stgacct",
    "enabled": true,
    "format": {
      "type": "JSON",
      "version": 2
    },
    "retentionPolicy": {
      "days": 90,
      "enabled": true
    }
  }
}

Flow Log Analysis

Security Monitoring Use Cases

-- Detect unusual outbound connections
SELECT srcaddr, dstaddr, dstport, COUNT(*) as connection_count
FROM vpc_flow_logs
WHERE action = 'ACCEPT'
  AND dstaddr NOT LIKE '10.%'  -- External traffic
  AND dstport NOT IN (80, 443)  -- Non-standard ports
  AND start_time >= NOW() - INTERVAL '1 hour'
GROUP BY srcaddr, dstaddr, dstport
HAVING COUNT(*) > 100
ORDER BY connection_count DESC;

-- Identify blocked traffic patterns
SELECT srcaddr, dstaddr, dstport, COUNT(*) as blocked_count
FROM vpc_flow_logs
WHERE action = 'REJECT'
  AND start_time >= NOW() - INTERVAL '24 hours'
GROUP BY srcaddr, dstaddr, dstport
HAVING COUNT(*) > 50;

-- Detect data exfiltration patterns
SELECT srcaddr, dstaddr, SUM(bytes) as total_bytes
FROM vpc_flow_logs
WHERE action = 'ACCEPT'
  AND dstaddr NOT LIKE '10.%'
  AND start_time >= NOW() - INTERVAL '6 hours'
GROUP BY srcaddr, dstaddr
HAVING SUM(bytes) > 1000000000  -- 1GB
ORDER BY total_bytes DESC;

Integration with Security Tools

SIEM Integration

LogForwarding:
  Destination:
    Type: "SIEM"
    Provider: "Splunk"  # or "Elastic", "QRadar", "Sentinel"
    Endpoint: "https://splunk.company.com:8088"

  Transformation:
    - field: "srcaddr"
      mapping: "source_ip"
    - field: "dstaddr"
      mapping: "destination_ip"
    - field: "action"
      mapping: "traffic_action"
    - field: "bytes"
      mapping: "bytes_transferred"

  Filtering:
    Include:
      - action: "REJECT"
      - destination_ports: [22, 3389, 1433, 3306]
    Exclude:
      - source_addresses: ["10.0.0.0/8", "192.168.0.0/16"]  # Internal monitoring

Real-Time Alerting

AlertingRules:
  SuspiciousOutbound:
    Condition: "external_traffic_count > 1000 AND port != 443"
    Severity: "medium"
    Action: "create_ticket"

  DataExfiltration:
    Condition: "external_bytes_transferred > 1GB AND timeframe = 1h"
    Severity: "high"
    Action: "page_security_team"

  PortScanning:
    Condition: "unique_destination_ports > 100 AND timeframe = 5m"
    Severity: "high"
    Action: "block_source_ip"

Flow logging provides essential visibility for network forensics, compliance reporting, and security monitoring. When properly configured and analyzed, these logs become a powerful tool for detecting and investigating security incidents.