style
content

Security Overview

This security guide covers Edge Delivery Services in Adobe Experience Manager Sites as a Cloud Service, the Admin API for Edge Delivery Services, the Sharepoint integration, and the developer tooling for Edge Delivery Services. There is a separate security guide for the AEM Sidekick. Familiarity with the overall architecture is recommended and assumed for the rest of this guide.

Overall Considerations

Tenant Isolation

All services that are a part of aem.live are multi-tenant. Tenant isolation is built into the publish and delivery services as well as the Content Hub to help ensure required content and data protection.

Write operations (preview or publish) require project details (GitHub owner, repository, branch and, if configured, an access token) and content paths be included in requests. This is required to inform the Admin Service which source document to fetch and where to store the processed content in the Content Hub. Similarly, a content request coming from a customer’s CDN must include the project details and path in its URL structure so the delivery service knows which content to deliver.

Data Encryption

All data in transit is exchanged over secure, encrypted connections using Transport Layer Security (TLS) 1.2 or greater. All data at rest is encrypted using AES256, with keys managed by two (2) independent cloud service providers.

Product Code

Adobe uses scaled trunk-based development for continuous deployment of AEM Sites as a Cloud Service. We push incremental changes to aem.live as soon as they pass our rigorous reviews and automated testing.

Preview and Delivery

Request Filtering

aem.live applies strict path filtering on the edge for any content it delivers to help reduce potential attack surface. This path filtering is functionally equivalent to a web application firewall (WAF) and prevents thousands of attacks every minute.

Other than generic web application firewalls that are based on deny-lists of known security exploits, AEM uses a strict list of permissible patterns to only permit legitimate traffic.

The deep integration of the edge layer and the underlying services that make up delivery and preview ensures maximum security and high performance without the overhead of a dedicated web application firewall.

Rate and Volume Limiting

All requests and usage of the preview and publish services are subject to rate and volume limits that are applied on a project-by-project basis and continuously monitored. This prevents denial-of-service attacks (DoS), in the form of distributed denial of service (DDoS) attacks, and self-inflicted Denial of Service attacks through misconfigured monitoring, bots, and crawlers. The vast majority of attacks prevented fall into the latter category..

Secure Network Routing

Edge Delivery services enforces TLS and HTTP Strict Transport Security (HSTS) to help ensure that every request is effectively secured.

Site Authentication

Site authentication, once enabled, ensures that only authorized requests can be made to the preview and publish tiers of an AEM site. Requests are required to present one of a list of configured site tokens to be permitted. Users can issue and revoke tokens through the Admin API.

Authors can use the AEM Sidekick to access protected sites using transient site tokens.

Disaster Recovery

The Content Hub is where all published content, media, and code is stored. For this tier, we rely on active/active replication in a multi-cloud setup. Unlike traditional approaches to disaster recovery where like active/standby or multi-region deployments, an active/active multi-cloud setup ensures that any content, media, or code that gets previewed or published is stored redundantly in at least two different cloud providers with different, but functionally identical software stacks.

In case of an outage, even a global outage of a cloud provider's control plane that would affect a multi-region setup, all content is still available in the second cloud provider and operations can resume without data loss.

The active/active deployment means that during normal operations, the workloads are split roughly equally between our cloud providers and only in an outage of one the remaining providers will pick up the load.

The delivery service itself is also deployed redundantly, so in case of an outage at one cloud provider, Adobe can plan to switch to the other and resume delivery instantaneously, if possible. The intended recovery time objective (RTO) for this service is 15 minutes.

Admin API

Authentication

The Admin API strictly requires authentication for all administrative operations and can be set up to require authentication for content operations like previewing or publishing through the sidekick. This requirement extends to the use of the AEM Sidekick.

Authentication is delegated to the identity provider (IdP) that backs the content source of the site, such as Microsoft or Google authentication.

Roles and Permissions

Authors can be assigned different roles based on the tasks they need to perform. The mapping is done in the project configuration. The following roles are built-in:

Disaster Recovery

The Admin API is currently a single-cloud deployment. In case of an outage in this service, the intended RTO is 12 hours. Adobe regularly conducts disaster recovery tests to validate that both delivery and API services can be restored well within their respective intended RTOs.

Rate and Volume Limiting

All requests and usage of the Admin API are subject to rate and volume limits that ensure smooth operation of the service. In addition to the published limits, Adobe can apply secondary limits on a case-by-case basis.

Sharepoint Integration

Please see Sharepoint integration (application) or Sharepoint integration (delegated), depending on your setup.

Author Tooling

AEM Sidekick

The AEM Sidekick is a browser extension installed via Chrome Web Store or Apple App Store and helps authors preview and publish their content. See Sidekick Security for more detailed information.

Developer Tooling

AEM Code Sync GitHub Application

The AEM Code Sync GitHub application uses GitHub permissions to provide access to your GitHub repository, so that code can be made available for serving in the code bus. Following permissions are requested:

The Code Sync GitHub app will not perform writes to your repository, but raise PRs, so that your approval will be given for each code change.

AEM Command Line Application

The AEM Command Line Application is installed via npm and requires access to the developer's file system, so that the site under development can be previewed using code from the developer's working copy.

It also requires network access to *.aem.live and *.aem.page, and validates all requests using Transport Layer Security (TLS) against the node.js certificate store. When man-in-the-middle attacks or tampering with request routing are detected, the command line application refuses to serve a preview site.

Trust, but verify

If you'd like to verify our security claims, as a customer, you are allowed to perform penetration tests against our services, even without advance notice. We ask you to stick to the following rules:

  1. Perform load tests incl. simulated (D)DoS attacks only against production infrastructure, which includes your CDN
  2. If you find a vulnerability, disclose it responsibly to psirt@adobe.com and we'll get back to you