Microsoft Documentation

• https://docs.microsoft.com/en-us/azure/application-gateway/overview
• https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-faq

Overview

• Basic Information
  • It’s an application delivery controller with application level load balancing capabilities for web traffic 
    • Because it is application level, we can manage traffic beyond source/destination IP (Layer 3) and source/destination port (Layer 4) E.g. based on the path of the traffic
    • It’s ONLY for Web traffic and not other protocols
    • It enables us to manage traffic to our web applications.
  • It offers highly available and scalable service, which is fully managed by Azure.
    • Azure Application Gateway is an Application Delivery Controller (ADC) as a service, offering various layer 7 load-balancing capabilities for your applications

• Tiers
  • Standard and WAF
• Versions
  • v1 and v2
• v1 vs v2
  • v2 currently in public preview as at 09/11/2018 (which means no SLA and not recommended for production)
    • Available in East US 2, US Central, West US2, France Central, West Europe, and South East Asia.
      • Supports autoscaling
      • Supports availability zone redundancy
      • Supports Static VIP (so IP does not change on restart)
      • 5X better SSL offload performance
      • Faster deployment and update time

• Standard
  • SSL offloading
    • Self-Signed certs, CA certs, and wild-card certs are supported. 
    • EV certs are not supported.
    • TLS 1.0, 1.1 and 1.2 are allowed by default but you can configure to deny them
    • SSL 2.0 and 3.0 are disabled by default and not configurable
  • End to end SSL encryption
  • Cookie-based session affinity
    • By using gateway-managed cookies, the Application Gateway can direct subsequent traffic from a user session to the same server for processing
    • important in cases where session state is saved locally on the server for a user session.
  • Redirection
    • Global redirection from one port to another port on the Gateway. This enables HTTP to HTTPS redirection on a site.
    • Path-based redirection. This type of redirection enables HTTP to HTTPS redirection only on a specific site area, for example a shopping cart area denoted by /cart/*.
      • • Redirect to an external site.
  • URL path-based routing
  • Multi site hosting
    • Configure up to 20 web sites on the same application gateway instance. Each web site can be directed to its own backend pool
    • Two subdomains of the same parent domain can be hosted on the same application gateway deployment. Examples of using subdomains could include http://blog.contoso.com and http://app.contoso.com 
  • Connection draining
  • Custom error pages
  •  WebSocket and HTTP/2 support
    • Native support for HTTP, HTTPS, HTTP/2, and WebSocket protocols
    • By default, HTTP/2 support is disabled
      • HTTP/2 support can be enabled using Azure PowerShell
      • HTTP/2 protocol support is available to clients connecting to application gateway listeners only. The communication to backend server pools is over HTTP/1.1

• WAF
  • OWASP top 10
    • Based on rules from the OWASP (Open Web Application Security Project) core rule sets 2.2.9 and 3.0.
    • Protection of web applications from common exploits and vulnerabilities. 
      • SQL injection protection
      • Cross site scripting protection
      • Common Web Attacks Protection such as command injection, HTTP request smuggling, HTTP response splitting, and remote file inclusion attack
      • Protection against HTTP protocol violations
      • Protection against HTTP protocol anomalies such as missing host user-agent and accept headers
      • Prevention against bots, crawlers, and scanners
      • Detection of common application misconfigurations (that is, Apache, IIS, etc.)
  • WAF Configurability (Preview)
    • Control request body evaluation
    • Control request and file sizes
  • WAF Exclusion List (Preview)
    • Exclude request attributes from WAF evaluation
    • Apply to request header/cookies/parameters

• Standard v2
  • Standard plus the capabilities below
  • Autoscaling
  • Availability zone redundancy
  • Supports Static VIP (so IP does not change on restart)
  • 5X better SSL offload performance
  • Faster deployment and update time

• WAF v2
  • All of the above
    • Certificate authentication not supported

• 50 application gateways per subscription. Can be increased to 1000.
  • Each application gateway can have up to 10 instances each
  • Each application gateway can consist of 20 HTTP listeners
    • 1 site per HTTP listener which means up to 20 web sites per application gateway
    • 1 SSL certificate per http listener
  • https://docs.microsoft.com/en-us/azure/azure-subscription-service-limits#application-gateway-limits
• How else does Application Gateway support scalability?
  • The Application Gateway v1 SKU supports scalability by adding multiple instances of the same gateway to share the load.
    • Customer has more responsibility to monitor and add more instances to handle the load if needed.
    • No downtime when doing a manual scale up/down
  • The v2 SKU automatically ensures that new instances are spread across fault domains and update domains. If zone redundancy is chosen, the newest instances are also spread across availability zones to offer zonal failure resiliency.

• It is recommended to use a CNAME alias and point it to the DNS address of the application gateway because the VIP can change if the application gateway is stopped and started (the DNS name does no change)
  • Static VIPs can be used for v2
• How else does Application Gateway support high availability?
  • The Application Gateway v1 SKU supports high availability scenarios when you have two or more instances deployed. Azure distributes these instances across update and fault domains to ensure that all instances do not fail at the same time.
    • The customer has more responsibility to add more than one instance. Microsoft will ensure they are added to the same availability set.
    • No downtime when doing a manual scale up/down
  • The v2 SKU automatically ensures that new instances are spread across fault domains and update domains. If zone redundancy is chosen, the newest instances are also spread across availability zones to offer zonal failure resiliency.
• There is an availability SLA 
  • For Application Gateway service having two or more medium or larger instances , there is a SLA of 99.95%
  • There is no availability SLA for Application Gateway services with only one instance or with small instances

• Application Gateway is currently offered in three sizes: Small, Medium, and Large. Small instance sizes are intended for development and testing scenarios
  • Small has no WAF option. Only Medium and Large.
• The following table shows an average performance throughput for each application gateway instance with SSL offload enabled:
  • These values are approximate values for an application gateway throughput. The actual throughput depends on various environment details, such as average page size, location of back-end instances, and processing time to serve a page. For exact performance numbers, you should run your own tests.

• • The size can be changed from small to medium OR medium to large with no disruption

• Securing your security solution
  • NSGs can be used to lock down connectivity but must be done very carefully
    • Exceptions must be put in for incoming traffic on ports 65503-65534 for the Application Gateway v1 SKU and ports 65200 – 65535 for the v2 SKU. This port-range is required for Azure infrastructure communication. They are protected (locked down) by Azure certificates. Without proper certificates, external entities, including the customers of those gateways, will not be able to initiate any changes on those endpoints.
    • Outbound internet connectivity can’t be blocked.
    • Traffic from the AzureLoadBalancer tag must be allowed.

• https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-diagnostics
• Activity Log
  • Administrative Audit Logs (administrative changes that are made and who made them)
  • Audit logs are available for Application Gateway. In the portal, click Activity Log in the menu blade of an application gateway to access the audit log.
  • Activity log entries are collected by default (no need to enable), and you can view them in the Azure portal (Activity logging is automatically enabled for every Resource Manager resource)
  • 90 days history by default
    • The logs are preserved for 90 days in the Azure event logs store
    • Can be archived to storage account???
  • Can be viewed and analyzed using Azure PowerShell, Azure CLI, Azure REST API, or Azure portal
    • https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-audit
  • Can be viewed and analyzed using Power BI (with the Azure Activity Logs content pack for Power BI and preconfigured dashboards)
    • https://docs.microsoft.com/en-us/power-bi/service-connect-to-azure-audit-logs
    • Free Power BI download: https://powerbi.microsoft.com/en-us/pricing/
    • https://powerbi.microsoft.com/en-us/blog/monitor-azure-audit-logs-with-power-bi/
    • https://azure.microsoft.com/en-us/blog/analyze-azure-audit-logs-in-powerbi-more/

• Diagnostic Logs
  • https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-diagnostics
  • Three Logs – Access log, Performance log and Firewall log (descriptions below)
    • Not enabled by default. Must be enabled for collection to start.
    • Can be enabled using the Azure Portal (Diagnostic Logs of the application gateway) or through PowerShell (Set-AzureRmDiagnosticSetting; the resource ID of both the Azure storage account and the application gateway is needed)
    • Can be stored in an Azure storage account, Azure event hub or Azure log analytics
      • Retention Policy
        • Diagnostic logs flow to the customers storage account and customers can set the retention policy based on their preference. Diagnostic logs can also be sent to an Event Hub or Log Analytics. See Application Gateway Diagnostics for more details.
    • Can be viewed and analyzed using Azure Log analytics (visualizations and powerful search capabilities)
      • You can also connect to your storage account and retrieve the JSON log entries for access and performance logs. After you download the JSON files, you can convert them to CSV and view them in Excel, Power BI, or any other data-visualization tool.
      • We have published a Resource Manager template that installs and runs the popular GoAccess log analyzer for Application Gateway Access Logs. GoAccess provides valuable HTTP traffic statistics such as Unique Visitors, Requested Files, Hosts, Operating Systems, Browsers, HTTP Status codes and more. For more details, please see the Readme file in the Resource Manager template folder in GitHub.

• Three storage options for the logs
  • Storage account
    • Storage accounts are best used for logs when logs are stored for a longer duration and reviewed when needed.
    • The use of storage for access and performance logging incurs service charges.
  • Event hubs
    • Event hubs are a great option for integrating with other security information and event management (SEIM) tools to get alerts on your resources.
  • Log Analytics
    • Log Analytics is best used for general real-time monitoring of your application or looking at trends.

• Metrics
  • Metrics are a feature for certain Azure resources where you can view performance counters in the portal. 
    • Azure Portal → Application Gateway → Under Monitoring, click Metrics
    • We can start alert rules based on metrics for a resource. For example, an alert can call a webhook or email an administrator if the throughput of the application gateway is above, below, or at a threshold for a specified period.
      • Azure Portal → Application Gateway → Under Monitoring, click Metrics → Add metric alert → Add rule blade → Fill out conditions
    • For Application Gateway, the following metrics are available:
      • Current Connections
      • Failed Requests
      • Healthy Host Count
        • You can filter on a per backend pool basis to show healthy/unhealthy hosts in a specific backend pool.
      • Response Status
        • The response status code distribution can be further categorized to show responses in 2xx, 3xx, 4xx, and 5xx categories.
      • Throughput
      • Total Requests
      • Unhealthy Host count
        • You can filter on a per backend pool basis to show healthy/unhealthy hosts in a specific backend pool.

• Verifying the health of the backend pool members
  • You can use the PowerShell cmdlet Get-AzureRmApplicationGatewayBackendHealth or verify health through the portal by visiting Application Gateway Diagnostics
  • If you see a back-end health status of Unknown, ensure that access to the back end is not blocked by an NSG rule, a user-defined route (UDR), or a custom DNS in the virtual network.

• Azure ARM
• Azure PowerShell
• Azure CLI
• REST API

• Two things are charged
  • The amount of time that the gateway is provisioned and available
  • The amount of data processed by the application gateways.

• Running cost
  • This is a fixed fee
  • A partial hour is billed as a full hour
  • Is this a per-instance cost?

• Data processing
  • This is different from egress data. Data transferred out of Azure data centres from the application gateways will still be charged at standard data transfer rates.
  • Graduated cost model which means that costs reduce as you consume more
    • Difficult for this to be a major issue as first 10TB is free for medium size and first 40TB is free for large size

• Common compliance frameworks
  • Government Blueprints
    • FedRAMP Blueprint
      • https://servicetrust.microsoft.com/ViewPage/FedRAMPBlueprint
    • UK OFFICIAL Blueprint
      • https://servicetrust.microsoft.com/ViewPage/UKBlueprints
    • NIST SP 800-171 Blueprint
      • https://servicetrust.microsoft.com/ViewPage/NISTSP800171Blueprint
    • AU-PROTECTED
      • https://servicetrust.microsoft.com/ViewPage/AUBlueprints
  • Finance Blueprints
    • FFIEC Blueprint
      • https://servicetrust.microsoft.com/ViewPage/FFIECBlueprint
    • PCI-DSS Blueprint
      • https://servicetrust.microsoft.com/ViewPage/PCIBlueprint
  • Healthcare Blueprints
    • HIPAA / HITRUST Blueprint
      • https://servicetrust.microsoft.com/ViewPage/HIPAABlueprint
    • UK NHS Blueprint
      • https://servicetrust.microsoft.com/ViewPage/UKNHSBlueprint
  • Retail Blueprints
    • PCI-DSS Blueprint
      • https://servicetrust.microsoft.com/ViewPage/PCIBlueprint
  • Privacy Blueprints
    • GDPR Blueprint
      • https://servicetrust.microsoft.com/ViewPage/GDPRBlueprint
  • Additional Frameworks
    • https://servicetrust.microsoft.com/ViewPage/Blueprint

• Some sample evaluations
  • PCI/DSS Compliance
    • Finance and Retail industries
    • 262 PCI DSS 3.2 controls
    • Two main things to do:
      • Review the Azure PCI DSS AoC (Attestation of Compliance) and verify that the Azure Application Gateway is listed as being attested (it is! on page 10 of the AoC – Core document)
        • https://servicetrust.microsoft.com/ViewPage/MSComplianceGuide?command=Download&downloadType=Document&downloadId=e6719688-b0ca-452e-a400-b6af25a6ddb2&docTab=4ce99610-c9c0-11e7-8c2c-f908a777fa4d_PCI_DSS
        • https://azure.microsoft.com/en-us/blog/the-biggest-pci-coverage-in-the-industry-just-got-bigger/
        • https://www.microsoft.com/en-us/TrustCenter/Compliance/PCI
        • As part of this, also review other Microsoft Azure PCI DSS related documents
          • https://servicetrust.microsoft.com/ViewPage/PCIBlueprint
          • https://azure.microsoft.com/en-gb/blog/payment-processing-blueprint-for-pci-dss-compliant-environments/
          • https://servicetrust.microsoft.com/ViewPage/BlueprintOverview
      • Review your usage of the service in line with PCI DSS requirements. For example:
        • Requirement: Establish and implement firewall and router configuration standards that include the following: Current network diagram that identifies all connections between the cardholder data environment and other networks, including any wireless networks.
          • Remember to include the connections for Azure management communications.
        • Requirement: Track and monitor all access to network resources and cardholder data
          • Enable activity and diagnostic logs. Add alerts and other monitoring capabilities
        • Requirement: Use strong cryptography and security protocols (for example, TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks
          • Enable SSL offload; Enable SSL end-to-end; Disable TLS 1.0 and 1.1
        • Sample architectures
          • https://docs.microsoft.com/en-us/azure/security/blueprints/pcidss-iaaswa-overview (IaaS)
          • https://docs.microsoft.com/en-us/azure/security/blueprints/pcidss-paaswa-overview (PaaS)

• • HIPAA Compliance
    • Encrypt data in transit
      • Enable HTTP to HTTPS redirection
      • Use HTTPS with trusted certificate 
        • EV certificate not supported though. Evaluate if this impacts your compliance
      • Disable weak ciphers and TLS versions
    • Encrypt data at rest
      • For your activity and diagnostic logs, ensure they are stored in storage accounts with encryption enabled
        • Encryption a rest enabled by default
      • Ensure that those storage accounts storing the logs have insecure protocols disabled
      • If integrating with monitoring systems, ensure that 
        • Azure Blob, database, e.t.c
    • Enforcing least privileges
      • Use IAM and RBAC to lock down who can modify the resources and who has access to the logs in the storage accounts (of any monitoring and analysis solution integrated)
    • Auditing
      • Extend retention for activity logs beyond the default 90 days
      • Configure extended retention for the diagnostic logs also
    • Data Backup
    • HA and DR
    • Logging and logs integrity

• • GDPR Compliance
    • Review the GDPR articles
      • https://gdpr-info.eu/
    • Article 32 highlights right to the protection of personal data
      • https://gdpr-info.eu/art-32-gdpr/
      • The controller is responsible for implementing appropriate risk-based technical and organizational measures, including pseudonymization and encryption of personal data, security measures to adequately ensure ongoing confidentiality, integrity, availability, and resilience of systems and services
        • Enabling SSL offload, SSL end-to-end; Disabling TLS 1.0 and 1.1 all come into play but compliance with GDPR is way beyond this

• Technical support is provided for all Azure services released to general availability, including the Application Gateway, through Azure Support
  • Cost per subscription starts at £21.62/month.
  • Billing and subscription management support is provided at no cost.
• There is an availability SLA
  • For Application Gateway service having two or more medium or larger instances, there is a SLA of 99.95%
  • There is no availability SLA for Application Gateway services with only one instance or with small instances.