AZ-500 Objective 2.3: Plan and Implement Security for Public Access to Azure Resources

Understanding Public Access Security

Public-facing applications and APIs require robust security protecting against diverse threats while maintaining performance and availability. Unlike private resources accessible only within VNets, public resources expose endpoints to internet increasing attack surface. Security challenges for public access include: encryption in transit protecting data between clients and applications from eavesdropping and tampering, distributed denial of service (DDoS) attacks overwhelming resources with traffic floods preventing legitimate access, web application attacks exploiting vulnerabilities like SQL injection and cross-site scripting to steal data or compromise systems, unauthorized access attempts trying to breach authentication and authorization controls, data exfiltration risks where attackers steal sensitive information through application vulnerabilities, and compliance requirements mandating specific security controls for public-facing systems handling regulated data.

Azure provides layered security services addressing these threats at different layers: TLS/SSL encryption secures data in transit between clients and services using industry-standard cryptographic protocols. Azure Firewall provides centralized network and application layer filtering with threat intelligence blocking known malicious actors at network perimeter. Application Gateway offers regional layer 7 load balancing with integrated Web Application Firewall protecting applications in VNet. Azure Front Door delivers global load balancing, CDN for performance, and edge WAF protection distributed across Microsoft's global network. Web Application Firewall defends against OWASP Top 10 vulnerabilities inspecting HTTP traffic for malicious patterns. DDoS Protection Standard mitigates volumetric and protocol attacks automatically scaling to handle massive attack volumes. This objective explores these services enabling design and implementation of comprehensive security architecture for public-facing Azure resources combining encryption, perimeter defense, application protection, and resilience against attacks.

Transport Layer Security (TLS)

TLS Implementation for Azure App Service

Transport Layer Security (TLS) encrypts data transmitted between web browsers and servers preventing eavesdropping, tampering, and message forgery. TLS succeeded SSL but term "SSL" still commonly used. Azure App Service provides comprehensive TLS support including free managed certificates, custom domain HTTPS, and configurable TLS versions. Free managed certificate: App Service automatically provisions SSL certificate for custom domains using Let's Encrypt, auto-renews before expiration, supports apex domains and www subdomains. Configuration: App Service → Custom domains → Add custom domain → Add binding → Create App Service Managed Certificate. Certificate provisioned within minutes and automatically bound to domain. Limitations: Doesn't support wildcard certificates, exported certificates not available. Custom certificates: Purchase App Service Certificate (managed by Azure stored in Key Vault with automatic renewal), import from Azure Key Vault, or upload PFX file. App Service Certificates provide automatic renewal integrated with Key Vault, support for wildcard domains, exportable for use elsewhere. Import from Key Vault: Create Key Vault, import certificate, grant App Service managed identity access to Key Vault secrets, import to App Service from Key Vault.

TLS/SSL settings configuration: HTTPS Only redirect—forces all HTTP traffic to HTTPS in Configuration → General settings, returns 301 permanent redirect for HTTP requests, ensures all connections encrypted. Minimum TLS version: Set to 1.2 (recommended minimum) or 1.3 (latest, best security) in TLS/SSL settings, prevents clients using vulnerable legacy protocols (TLS 1.0, 1.1). SNI SSL vs IP-based SSL: Server Name Indication (SNI) allows multiple SSL certificates on single IP address, modern browsers support SNI, included in Basic tier and above, recommended for most scenarios. IP-based SSL assigns dedicated IP address per certificate, required for legacy clients not supporting SNI (very rare), available in Standard tier and above, additional cost. Certificate binding: App Service → Custom domains → Add binding → Select certificate, Choose SNI SSL or IP-based SSL, save. HTTPS URLs immediately functional. HSTS (HTTP Strict Transport Security): Configure through web.config or application code, instructs browsers to always use HTTPS for specified duration, prevents SSL stripping attacks, header format: Strict-Transport-Security: max-age=31536000; includeSubDomains. Implement carefully as clients won't access site over HTTP even if HTTPS misconfigured.

TLS for Azure API Management

API Management provides gateway for APIs requiring TLS for client-to-gateway and gateway-to-backend connections. Custom domains for gateway endpoints: Default domain (apim-service-name.azure-api.net) has Microsoft-managed certificate. Custom domains (api.contoso.com) require custom certificates. Configure in API Management → Custom domains → Add → Select endpoint type (Gateway, Developer portal, Management), upload certificate (PFX with private key), specify hostname, optionally enable negotiate client certificate for mutual TLS. Certificate sources: Upload directly (PFX file), reference from Key Vault (preferred for automatic renewal), use App Service Certificate. Certificate requirements: Valid certificate chain, minimum 2048-bit RSA key, PFX format with exportable private key, not expired. Mutual TLS (mTLS): Enable "Negotiate client certificate" requiring clients present certificate for authentication, certificates validated at gateway, thumbprint or subject passed to backend APIs for authorization, enhances security for sensitive APIs requiring strong client authentication.

Backend TLS configuration: API Management connects to backend APIs potentially over internet requiring encryption. Backend settings specify protocol (HTTP or HTTPS), validate backend certificate chain preventing man-in-the-middle attacks, configure trusted root certificates for self-signed backend certificates, set client certificate for mutual TLS to backends. SSL/TLS versions: Minimum protocol version configured globally or per API, disable insecure protocols (TLS 1.0, 1.1), enforce TLS 1.2 minimum, support TLS 1.3 when available. Cipher suites: API Management uses secure cipher suites by default, custom configuration available for specific compliance requirements (may impact performance), disable weak ciphers (DES, RC4, MD5) preventing cryptographic attacks. Certificate management: Monitor certificate expiration dates with alerts, automate renewal using Key Vault integration (certificates retrieved automatically), test certificate updates in non-production first, document certificate dependencies and renewal procedures. Best practices: Use Key Vault for certificate storage enabling automatic rotation, implement minimum TLS 1.2 across all endpoints, enable client certificate authentication for internal APIs requiring strong authentication, validate backend certificates preventing man-in-the-middle, configure custom error pages for certificate validation failures, monitor TLS handshake failures in Application Insights, implement certificate pinning for mobile apps providing additional security, regularly audit TLS configuration for compliance, test disaster recovery procedures for certificate loss scenarios.

Azure Firewall and Firewall Manager

Azure Firewall Architecture and Capabilities

Azure Firewall is managed, cloud-based network security service protecting Azure virtual networks with stateful packet inspection, application-level filtering, threat intelligence, and built-in high availability. Unlike traditional firewalls requiring hardware and manual configuration, Azure Firewall is fully managed PaaS with automatic scaling and updates. Azure Firewall deployed in dedicated subnet (AzureFirewallSubnet, minimum /26 recommended) receiving public IP address for SNAT (source NAT) of outbound traffic and DNAT (destination NAT) for inbound rules. Traffic routes through firewall using user-defined routes (UDRs) forcing subnet traffic to firewall as next hop. Firewall inspects traffic against configured rules allowing, denying, or logging based on criteria. SKUs: Standard provides core features (network and application rules, threat intelligence, automatic scaling), Premium adds advanced features (TLS inspection, IDPS, URL filtering, web categories). Choose Standard for basic outbound filtering and threat intelligence, Premium for TLS inspection and deep packet inspection requirements.

Azure Firewall features: Stateful firewall maintains connection state automatically allowing return traffic without explicit rules. Built-in high availability with 99.95% SLA, redundancy across availability zones in supported regions. Unrestricted cloud scalability automatically scales based on traffic (Standard: 30 Gbps, Premium: 100 Gbps). Threat intelligence blocks traffic to/from known malicious IP addresses and domains (Microsoft Threat Intelligence feed updated continuously), modes: Off (disabled), Alert (logs threats), Alert and deny (blocks and logs). FQDN filtering in application rules allows outbound traffic to specific domains (*.microsoft.com) regardless of IP address changes. FQDN tags simplify rules for Microsoft services (Windows Update, Azure Backup) without specifying full domain lists. Service tags in network rules reference Azure services (Storage, Sql, AzureActiveDirectory) without specific IP ranges. IDPS (Premium) detects and prevents known attack patterns including exploits, malware, command-and-control, port scanning. TLS inspection (Premium) decrypts outbound HTTPS traffic, inspects content, re-encrypts forwarding to destination. Web categories (Premium) filters outbound traffic by content category (gambling, social media) simplifying policy creation. DNS proxy enables firewall to resolve DNS queries applying FQDN rules correctly. Forced tunneling routes default traffic (0.0.0.0/0) to on-premises for scenarios requiring internet egress through on-premises firewall.

Firewall Rules and Configuration

Azure Firewall processes three rule types in order: NAT rules (DNAT) for inbound traffic routing, Network rules for layer 3-4 filtering, Application rules for layer 7 FQDN filtering. Rule processing stops at first match—if NAT rule matches, no further rules processed. NAT rules: Used for inbound connections from internet, destination NAT translates public IP and port to internal private IP and port, typically for publishing internal services (RDP to VMs, HTTPS to web servers), creates implicit network rule allowing return traffic. Example: Translate firewall public IP:3389 to VM private IP:3389 enabling RDP. NAT rule includes destination address (firewall public IP), destination port, translated address (internal private IP), translated port, protocol (TCP/UDP). Network rules: IP-based filtering matching source IP, destination IP, port, and protocol, used for non-HTTP/HTTPS traffic (SSH, RDP, database, custom ports). Rules allow or deny based on 5-tuple. Example: Allow on-premises range 10.0.0.0/8 to Azure VNet 172.16.0.0/16 on port 1433 (SQL). Supports IP addresses, CIDR ranges, service tags, IP groups (reusable address lists). Application rules: FQDN-based filtering for HTTP/HTTPS outbound traffic, allows traffic to specific domains regardless of IP, uses DNS resolution or HTTP(S) inspection. Example: Allow *.microsoft.com enabling all Microsoft domains. Supports wildcards, FQDN tags (WindowsUpdate, AzureBackup), HTTP and HTTPS protocols. TLS inspection (Premium) required for HTTPS traffic inspection—without it, only SNI (Server Name Indication) visible.

Rule collection groups organize rules with priority (100-65000, lower number higher priority): NAT rule collection group processed first, Network rule collection group processed second, Application rule collection group processed last. Within group, collections processed by priority, within collection rules processed sequentially until match. Inheritance from parent policy: Child policies inherit parent rules plus add their own, inherited rules can't be modified in child (modify in parent), child rules processed after parent rules of same type. Best practices: Organize rules logically in rule collection groups, use IP groups for reusable address lists reducing rule duplication, leverage service tags instead of IP ranges for Azure services, use FQDN tags for Microsoft services simplifying updates, enable threat intelligence in Alert and Deny mode, implement DNS proxy for proper FQDN resolution, log all traffic for security analysis and troubleshooting, start with minimal allow rules (deny by default), test rules thoroughly before production, document rule purpose and business justification, regularly review removing obsolete rules, use parent policies for baseline rules applied across firewalls, create child policies for environment or region-specific rules.

Azure Firewall Manager

Azure Firewall Manager provides centralized management for Azure Firewalls and secured virtual hubs at scale. Addresses challenge of managing multiple firewalls individually across regions and environments. Firewall Manager capabilities: Create and manage Azure Firewall policies, apply policies to multiple firewalls, policy inheritance with parent-child relationships, secured virtual hub integration with Virtual WAN, DDoS Protection plan association, partner security provider integration. Firewall Policy contains complete firewall configuration including rule collection groups (NAT, network, application), threat intelligence mode and allow list, DNS settings, IDPS mode (Premium), TLS inspection with certificates (Premium), and intrusion detection signatures. Policy inheritance: Create parent policy with organizational baseline rules (mandatory blocks, threat intelligence, logging), create child policies inheriting parent and adding environment-specific rules (dev allows more permissive, prod more restrictive), associate policies with firewalls in each environment. Changes to parent propagate to all children automatically ensuring baseline consistency. Secured virtual hub: Virtual WAN hub with integrated Azure Firewall, routing intent automatically routes traffic through firewall (private traffic, internet traffic, or both), simplifies hub-spoke management without manual UDRs, provides centralized security for all hub-connected resources.

Firewall Manager workflow: Design policy hierarchy—identify baseline requirements for parent policy, determine environment-specific needs for child policies, document policy structure and ownership. Create parent policy—define mandatory security rules, configure threat intelligence, set DNS and logging, establish IDPS baseline (Premium). Create child policies—inherit from parent, add environment or application-specific rules, configure policy for each firewall group (region, environment, tenant). Deploy firewalls—create firewalls in required regions, associate with appropriate child policy, configure routing (UDRs or secured hub). Monitor and maintain—review firewall logs aggregated in Firewall Manager, identify top blocked domains and IPs, track policy compliance, update policies as requirements change. Firewall Manager benefits: Single pane of glass for all firewalls, consistent policy across deployments, simplified management at scale, faster deployment with policy templates, improved compliance through policy enforcement, reduced operational overhead. Integration: Azure Security Center recommendations for firewall configuration, Azure Sentinel for SIEM correlation, Azure Monitor for metrics and alerting, Terraform and ARM templates for automation. Best practices: Use Firewall Manager for multi-region or multi-firewall deployments, implement policy hierarchy for scalable management, leverage parent policies for consistent baseline, test policy changes in non-production first, enable diagnostic logs on all firewalls, integrate with Azure Sentinel for security operations, automate policy deployment in CI/CD pipelines, document policy hierarchy and ownership, conduct regular reviews of firewall rules, monitor threat intelligence blocks identifying attack patterns.

Azure Application Gateway

Application Gateway Features and Architecture

Azure Application Gateway is layer 7 (application layer) load balancer providing web traffic routing, SSL termination, WAF protection, and advanced HTTP load balancing capabilities. Operates within Azure VNet analyzing HTTP request properties (URL path, headers, cookies, hostname) to make routing decisions. Application Gateway components: Frontend IP (public, private, or both accepting incoming traffic), Backend pools (targets like VMs, VMSS, App Service, IP addresses, FQDNs), HTTP settings (port, protocol, cookie-based session affinity, connection draining, request timeout, custom probes), Listeners (port, protocol, hostname, SSL certificate), Routing rules (basic or path-based connecting listeners to backend pools), Health probes (custom or default monitoring backend health), SSL certificates (for HTTPS listeners and end-to-end SSL), and WAF policy (protecting against attacks). Deployed in dedicated subnet (minimum /26 recommended for production, allows scale to 32 instances) in VNet. Subnet can't contain other resources except multiple Application Gateways.

Application Gateway SKUs: Standard v2 includes autoscaling (1-125 instances), zone redundancy, static VIP, header rewrite, URL routing, multiple site hosting, SSL termination, end-to-end SSL, connection draining, custom error pages, WebSocket and HTTP/2 support. WAF v2 adds Web Application Firewall with OWASP protection, bot protection, custom rules, geo-filtering, per-URI policy, DDoS protection (when public IP is DDoS Standard protected). Choose Standard v2 for internal applications or applications not exposed to internet threats. Choose WAF v2 for all internet-facing applications requiring attack protection. v2 benefits over v1: Better performance (up to 5x faster), autoscaling eliminates manual capacity planning, faster deployment (<6 minutes vs 30 minutes), built-in redundancy, lower cost with reserved capacity. All new deployments should use v2. Routing capabilities: URL-based routing directs requests to different backend pools based on URL path (example: /images to image servers, /api to API servers), enables microservices architecture with single gateway frontend. Multi-site hosting supports multiple websites on same gateway differentiating by hostname (shop.contoso.com and blog.contoso.com both on one gateway), eliminates need for multiple gateways reducing costs. Basic routing sends all requests to single backend pool providing simple load balancing. Redirection rules automatically redirect HTTP to HTTPS or one URL pattern to another.

SSL/TLS and Security Configuration

SSL termination: Application Gateway decrypts SSL at gateway offloading certificate processing from backend servers, reduces backend server load enabling more concurrent connections, allows WAF inspection of encrypted traffic (can't inspect content without decryption), simplifies certificate management at single point. Configuration: Upload SSL certificate to Application Gateway (PFX with private key), create HTTPS listener using certificate, configure routing rule to backend. Backends can use HTTP (SSL terminated at gateway) or HTTPS (end-to-end SSL). End-to-end SSL: Encrypts traffic from client to gateway (SSL termination), re-encrypts traffic from gateway to backend, ensures traffic encrypted throughout path, required for compliance scenarios mandating encryption in transit, backends must present valid certificates for Application Gateway to trust. Configure authentication certificates or trusted root certificates in HTTP settings. Backend must be whitelisted by certificate thumbprint or CA.

SSL policy: Configure supported SSL/TLS protocols and cipher suites. Predefined policies: AppGwSslPolicy20150501 (legacy, includes TLS 1.0), AppGwSslPolicy20170401 (default, TLS 1.0-1.2), AppGwSslPolicy20170401S (TLS 1.2 only, secure), AppGwSslPolicy20220101 (TLS 1.2 only, latest ciphers), AppGwSslPolicy20220101S (TLS 1.3 only, most secure). Custom policy allows specifying exact protocols and cipher suites. Best practice: Use TLS 1.2 minimum policy (AppGwSslPolicy20170401S) or TLS 1.3 (AppGwSslPolicy20220101S) for maximum security. Health probes: Application Gateway monitors backend health routing only to healthy backends. Default probe sends requests to backends every 30 seconds marking unhealthy after 3 failures. Custom probes specify protocol (HTTP/HTTPS), path, interval, timeout, unhealthy threshold, host name, status codes considered healthy. Implement custom probes for accurate health detection especially for applications with specific health endpoints. Connection draining: Gracefully removes servers from backend pool without dropping existing connections. Configure drain timeout (1-3600 seconds) allowing existing connections to complete before server removal. Essential for maintenance scenarios preventing dropped user sessions.

Application Gateway Best Practices

Deployment: Use v2 SKU for all deployments (v1 reaching end of life), enable autoscaling configuring minimum and maximum instances, deploy in zone-redundant configuration for high availability, use dedicated subnet sized appropriately (/26 for production), configure NSG on Application Gateway subnet (only port 65200-65535 from GatewayManager required, allow frontend listener ports, allow health probe traffic from internet or AzureLoadBalancer tag). Security: Enable WAF for all internet-facing applications, use SSL termination for certificate management simplification, implement end-to-end SSL for sensitive applications, configure minimum TLS 1.2, use custom health probes for accurate backend health, enable connection draining for graceful maintenance, restrict backend access using NSGs (only Application Gateway subnet should reach backends), use Private Link (v2) for private gateway access. Performance: Configure session affinity only when required (stateless backends preferred), adjust connection timeout based on application needs (default 4 minutes), implement caching at backend when possible, use HTTP/2 for improved performance with browser support, monitor gateway metrics (CPU, connections, throughput, failed requests) adjusting capacity, enable diagnostic logs for troubleshooting performance issues. High availability: Configure multiple backend instances in pool (minimum 2), use health probes ensuring failed backends removed from rotation, implement zone redundancy distributing instances across availability zones, test failover scenarios validating high availability, document recovery procedures, configure alerts on gateway health metrics. Cost optimization: Right-size capacity using autoscaling instead of over-provisioning, use reserved instances for predictable workloads (up to 60% savings), share gateway across multiple applications using path-based or multi-site routing, monitor and right-size v2 capacity units (CU) usage, eliminate unused or idle gateways, evaluate if Standard v2 sufficient rather than WAF v2 for internal apps. Integration: Use Application Gateway with Azure Front Door (Front Door global load balancing to regional Application Gateways), integrate with Azure Monitor for centralized logging, configure alerts in Azure Monitor or Action Groups, use Network Watcher for connectivity troubleshooting, implement Azure Policy enforcing gateway configurations, leverage ARM templates or Terraform for repeatable deployments.

Azure Front Door and CDN

Azure Front Door Global Load Balancing

Azure Front Door is global load balancer and CDN providing fast delivery of web applications across Microsoft's global edge network. Unlike Application Gateway which operates regionally, Front Door operates globally routing traffic to closest available backend across any region. Front Door architecture: Frontend endpoints (custom domains with SSL certificates), Routing rules (URL path-based routing to backend pools), Backend pools (origins—Azure App Service, VMs, Application Gateway, public endpoints, on-premises services via public IP), Health probes (monitoring backend health globally), WAF policies (protecting at edge), Caching rules (CDN functionality), Rules engine (advanced request/response manipulation). Front Door operates on Microsoft's global network with 100+ edge locations (Points of Presence - PoPs) distributed worldwide. Users connect to nearest PoP over anycast, traffic routes through Microsoft's backbone to backend.

Global load balancing: Front Door selects optimal backend based on: Latency (lowest latency to user), Health (only healthy backends eligible), Priority (preferential backend ordering), Weighted distribution (traffic split percentage). Scenarios: Active-active (distribute across all regions for load distribution and high capacity), Active-passive (primary region handles traffic, secondary for failover), Weighted distribution (gradual traffic shift during blue-green deployments). Automatic failover: Health probes monitor backends continuously (configurable interval, timeout, success threshold), unhealthy backends removed from rotation automatically, traffic shifts to healthy backends in seconds, backends automatically added back when health restores. Session affinity: Cookie-based pinning users to same backend, required for stateful applications, applied per backend pool. Caching: Static content cached at edge PoPs (images, CSS, JavaScript, videos), cache rules specify cache behavior (query string handling, expiration), significantly reduces latency for static content, reduces origin load, cache purge available for immediate content updates. Custom domains: Add custom domains to Front Door (shop.contoso.com), CNAME points domain to Front Door endpoint, managed SSL certificates with automatic renewal, wildcard domain support (*.contoso.com).

Front Door Features and Configuration

Rules engine: Advanced traffic routing and manipulation beyond basic rules. Conditions include HTTP headers, cookies, query strings, request method, URL path, device type, geographic location. Actions include redirect, URL rewrite, modify headers (request and response), cache override, forward to backend pool. Examples: Redirect mobile users to mobile-specific backend, add security headers to responses, rewrite URLs for SEO-friendly addresses, cache specific content types aggressively. HTTP/2 and WebSocket support: Front Door supports HTTP/2 improving performance with multiplexing, WebSocket for real-time applications, automatic protocol negotiation with clients. Protocol and security: IPv6 support connecting clients over IPv6, URL filtering allowing or denying specific URL patterns, geo-filtering restricting access by country/region. Private Link: Front Door Premium supports Private Link connecting to Application Gateway or App Service privately, traffic stays on Microsoft backbone without internet exposure, combines global Front Door scale with private VNet-integrated backends.

Front Door monitoring: Metrics include requests per second, latency, error rates by status code, cache hit ratio, requests by geographic location, backend health status. Diagnostic logs capture access logs (all requests), WAF logs (threats detected), health probe logs. Integrate with Azure Monitor for alerts, Application Insights for application telemetry, Log Analytics for log analysis. Traffic Analytics provides insights into traffic patterns, top countries, devices, referrers. Best practices: Enable WAF on Front Door for edge protection, use managed SSL certificates for automatic renewal, implement caching for static content reducing latency and load, configure health probes for accurate backend availability detection, use session affinity sparingly (stateless backends preferred), leverage rules engine for advanced routing scenarios, enable diagnostic logging for troubleshooting and security, configure alerts on health and performance metrics, test failover scenarios validating high availability, document routing and caching configurations, implement geo-filtering if application serves specific regions only, use priority-based routing for active-passive scenarios, configure rate limiting preventing abuse, regularly review and optimize cache rules. Front Door vs CDN: Front Door includes CDN plus load balancing, WAF, advanced routing. Azure CDN (Verizon/Akamai) pure CDN without load balancing or WAF. Choose Front Door for applications requiring global load balancing plus CDN. Choose CDN for pure content delivery without application routing needs.

Web Application Firewall (WAF)

WAF Protection and Rule Types

Web Application Firewall (WAF) protects web applications from common exploits and vulnerabilities operating at layer 7 inspecting HTTP/HTTPS traffic. Available on Application Gateway WAF (regional VNet protection), Front Door WAF (global edge protection), and Azure CDN WAF (CDN-integrated protection). WAF analyzes request body, headers, cookies, query strings detecting malicious patterns and blocking before reaching application. OWASP protection: Managed rule sets based on OWASP Core Rule Set (CRS) protect against OWASP Top 10 threats. CRS versions: 3.2 (latest, recommended), 3.1, 3.0, 2.2.9 (legacy). Rules detect SQL injection (SELECT, UNION, DROP, OR 1=1 patterns), cross-site scripting (XSS—script tags, JavaScript injection, DOM manipulation), command injection (system commands, shell metacharacters), local file inclusion (directory traversal, ../../patterns), remote file inclusion (external URL inclusion), protocol attacks (HTTP request smuggling, HTTP splitting), session fixation, directory traversal, remote code execution.

Managed rule sets: Microsoft-managed rules updated automatically as new threats emerge, include protection based on threat intelligence from Azure Security Center, categorized into rule groups (SQL injection prevention, XSS prevention, protocol enforcement, general security), each rule has severity (critical, high, medium, low), rules can be enabled/disabled individually. Bot protection (Front Door Premium): Detects good bots (search engines, monitors), bad bots (scrapers, scanners, vulnerability scanners), unknown bots (requires investigation), blocks malicious bots at edge before reaching application, reduces fake traffic and backend load. Custom rules: Organization-specific protections beyond managed rules. Rate limiting—limits requests from single IP per time period (example: max 100 requests per minute) preventing DDoS and brute force attacks. Geo-filtering—allows or blocks traffic from specific countries (example: block all except US, Canada, UK for region-specific application). IP filtering—allow or block specific IP addresses or ranges (whitelist trusted IPs, blacklist known attackers). Custom match conditions—detect application-specific patterns in headers, cookies, body, query strings (example: block requests without specific header indicating authentication token).

WAF Configuration and Management

WAF policy: Contains rule configuration applied to Application Gateway or Front Door. Policy settings: Mode (Detection logs violations without blocking for testing, Prevention blocks violations), Request body inspection (inspects POST body up to 128 KB), File upload limit (maximum file size, prevents large file attacks), Maximum request body size. Rule configuration: Enable/disable managed rule sets, Enable/disable specific rules within rule set, Configure rule sensitivity (paranoia level—higher level more sensitive detections but more false positives), Add custom rules. Exclusions: Prevent false positives where legitimate application behavior triggers WAF rules. Exclude request attributes (specific headers, cookies, query string parameters, POST body arguments) from specific rules. Example: Rich text editor sends HTML in POST body triggering XSS rules—exclude request body from XSS rules for that URL path. Exclusion types: Request header, Request cookie, Request body, Query string parameter. Exclusions can be global (all rules) or per-rule (specific rules only).

WAF modes: Start in Detection mode when first implementing WAF, analyze logs identifying false positives (legitimate traffic blocked), create exclusions for known false positives, after tuning switch to Prevention mode blocking actual attacks. Detection mode advantages: Safe to deploy without application impact, time to tune rules, identifies normal traffic patterns. Prevention mode: Blocks attacks protecting application, may block legitimate traffic if not tuned properly, requires ongoing maintenance. WAF logging: Diagnostic logs capture detailed information about requests, rule matches, actions taken (allow, block, log). Logs sent to Log Analytics for analysis, Storage for long-term retention, Event Hub for SIEM integration. WAF logs include request details (URL, headers, IP), matched rules, rule severity, action taken, timestamp. Analyze logs identifying: Top triggered rules, False positives requiring exclusions, Real attacks and patterns, Geographic distribution of attacks, Attack trends over time. Best practices: Enable WAF on all internet-facing applications, use latest managed rule set (OWASP CRS 3.2) getting newest protections, start in detection mode tuning before prevention, create exclusions for legitimate traffic triggering rules, implement custom rules for application-specific threats, combine managed and custom rules for comprehensive protection, enable bot protection (Front Door) detecting automated attacks, configure rate limiting preventing brute force and DDoS, use geo-filtering if application serves specific regions only, monitor WAF logs regularly identifying attack trends, integrate WAF alerts with SIEM for correlation, document exclusions with business justification, test WAF with penetration testing, tune rules based on application changes, configure custom error pages providing user-friendly messages without revealing WAF, regularly review and update configuration, conduct security assessments validating protection effectiveness.

Azure DDoS Protection

DDoS Protection Tiers and Features

Distributed Denial of Service (DDoS) attacks overwhelm applications with traffic floods making them unavailable to legitimate users. Azure provides two DDoS protection tiers: Basic (free, automatically enabled on all Azure resources, protects Azure platform with always-on monitoring, real-time attack mitigation, global network scale absorbing attacks, sufficient for Azure infrastructure protection), and Standard (paid service with enhanced capabilities, adaptive tuning learning application traffic patterns, attack analytics and metrics, expert support during attacks, cost protection guarantee, integration with Azure Monitor). DDoS attack types: Volumetric attacks flood network with traffic (UDP floods, ICMP floods, DNS amplification, NTP amplification) measured in Gbps, aim to saturate bandwidth preventing legitimate traffic. Protocol attacks exploit layer 3-4 protocol weaknesses (SYN floods, fragmented packet attacks, Ping of Death) measured in packets per second, exhaust connection tables on firewalls and load balancers. Resource layer attacks target web application layer (HTTP floods, slowloris attacks, DNS query floods) measured in requests per second, appear legitimate but overwhelm application resources.

DDoS Protection Standard features: Adaptive tuning automatically learns normal traffic patterns (baseline traffic volume, request patterns, protocols used), detects anomalies deviating from baseline, adjusts detection thresholds dynamically, adapts to traffic pattern changes (seasonal variations, marketing campaigns). Always-on traffic monitoring analyzes all traffic 24/7 without performance impact, instant detection responds within seconds, automated mitigation activates automatically without manual intervention. Multi-layered protection defends at network edge (before traffic reaches Azure resources), Azure backbone (distributed mitigation capacity), resource level (Application Gateway, Azure Firewall integration). Massive scale handles attacks up to terabits per second exceeding most attack capacities, Microsoft's global network absorbs attack traffic, automatic scaling to handle attack volume. DDoS Rapid Response (DRR) support provides expert assistance during active attacks, access to DDoS specialists for attack investigation, best practice recommendations, post-attack analysis and reports. Cost protection guarantee credits account for auto-scale costs during documented DDoS attack, covers scale-out expenses for resources under attack. Telemetry and analytics: Real-time metrics during attacks (inbound traffic, dropped packets, forwarded packets, mitigation triggers), attack details (attack vectors, sources, packet rates, bandwidth), post-attack reports with comprehensive analysis. Integration with Azure Monitor, Azure Sentinel, third-party SIEM for security correlation.

DDoS Protection Implementation

Protected resources: Public IP addresses (VMs, Application Gateway, Load Balancer, VPN Gateway, Azure Firewall, Azure Front Door automatically protected), entire VNets (all public IPs in VNet protected simultaneously). Front Door automatically includes DDoS Protection Standard on its public IPs at no additional cost. Enable DDoS Protection Standard: Create DDoS protection plan (one plan can protect multiple VNets across subscriptions), associate VNet with plan (all public IPs in VNet protected), configure diagnostic settings sending telemetry to Log Analytics, set up alerts for attack detection, mitigation triggered, or exceeding thresholds. Configuration options: Telemetry collection (metrics sent to Azure Monitor for analysis), Diagnostic logging (detailed logs for investigation), Alerts (notifications on attack start, mitigation, metrics exceeding thresholds), Attack analytics (requires Log Analytics workspace for detailed reporting).

When to use DDoS Protection Standard: Mission-critical applications where downtime impacts revenue or reputation (e-commerce, banking, healthcare, SaaS platforms), organizations experiencing DDoS attacks historically, compliance requirements mandating DDoS protection (financial services, government), public-facing APIs requiring high availability, multi-region deployments needing consistent protection, applications with predictable traffic patterns where deviations indicate attacks. When Basic sufficient: Development and test environments, internal applications without public IPs, non-critical workloads where downtime acceptable, cost-sensitive scenarios, applications behind existing DDoS protection (third-party service or on-premises). Cost considerations: DDoS Protection plan $2,944/month includes 100 public IPs, additional IPs $30 each/month, cost protection guarantee credits for scale-out during attacks. Compare against downtime costs (revenue loss, reputation damage), incident response expenses (staff time, emergency response), bandwidth overages during attack, third-party DDoS mitigation services. For mission-critical applications, typically cost-effective given attack impact.

DDoS best practices: Enable Standard on all production VNets with public resources, configure diagnostic logs capturing attack telemetry, integrate with Azure Sentinel for security correlation, set up alerts for immediate attack notification, document incident response procedures, simulate DDoS attacks testing protection (requires Azure approval), combine with WAF for multi-layer protection (DDoS handles volumetric, WAF handles application), implement rate limiting at application level as additional defense, use Azure Front Door for global distribution reducing regional attack impact, ensure sufficient backend capacity for legitimate traffic spikes, configure health probes ensuring availability detection, monitor attack reports improving defenses, maintain incident response playbook, review and update DDoS strategy regularly. Monitoring DDoS: Metrics include inbound traffic (baseline and during attack), dropped packets (traffic mitigated), packets forwarded (legitimate traffic), DDoS TCP SYN packets, mitigation triggered status, attack details (vectors, sources, packet rates). Attack analytics provide detailed reports including attack characteristics, mitigation techniques applied, timeline, sources, recommendations. Post-attack review: Analyze attack reports understanding patterns, identify mitigation effectiveness, adjust thresholds if needed, improve application resilience, update incident response procedures, conduct post-mortem with stakeholders.

Exam Preparation Tips

Key Concepts to Master

• TLS for App Service: Free managed certificates, HTTPS only redirect, minimum TLS 1.2, SNI vs IP-based SSL, HSTS header
• API Management TLS: Custom domains with certificates, mutual TLS (mTLS) for client authentication, backend validation, Key Vault integration
• Azure Firewall: Stateful firewall in AzureFirewallSubnet, NAT/network/application rules, threat intelligence, IDPS (Premium), TLS inspection (Premium)
• Firewall Manager: Centralized policy management, parent-child inheritance, secured virtual hub with routing intent
• Application Gateway: Layer 7 load balancer, SSL termination, URL routing, multi-site hosting, WAF integration, v2 with autoscaling
• Front Door: Global load balancer with CDN, anycast routing, session affinity, caching, WAF at edge, Private Link (Premium)
• WAF: OWASP CRS protection, managed rule sets, custom rules (rate limiting, geo-filtering), detection vs prevention mode, exclusions
• DDoS Protection: Basic (free, platform) vs Standard (paid, enhanced); Standard: adaptive tuning, DRR support, cost protection, $2,944/month
• Service selection: Application Gateway (regional VNet), Front Door (global multi-region), Firewall (centralized filtering), WAF (OWASP protection), DDoS Standard (volumetric attacks)

Practice Questions

Hands-On Practice Lab

Lab Activities

Lab Outcomes

After completing this lab, you'll have hands-on experience with public access security services. You'll understand how to configure TLS for App Service forcing encrypted connections, deploy Azure Firewall with application rules filtering outbound traffic, implement Application Gateway with WAF protecting against web attacks, and configure monitoring capturing security events for analysis. These practical skills demonstrate public access security capabilities tested in AZ-500 exam and provide foundation for implementing comprehensive protection for internet-facing Azure resources in production environments.

Frequently Asked Questions