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.
Please note that while there is no technical need for a WAF in aem.live, requests that are classified as DDoS are still fully billed, unless the WAF option is part of the AEM contract.
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. There are two authentication options available, token-based and mutual Transport Layer Security (mTLS).
With token-based authentication only requests that present one of a list of user-managed tokens are permitted. Users can issue and revoke tokens through the Admin API.
With mTLS, only requests that present a certificate for a user-configured hostname and that have been provided by an accepted certificate agency (CA) are permitted.
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. 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:
admin.role.author
: This role allows a user to update content in the Preview environmentadmin.role.publish
: This role allows a user to update content in the Preview and Live environments
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:
- read access to metadata – so that code gets assigned to the correct Code Bus space for your repository
- read/write access to checks – so that the pull request status can be set when the Pagespeed Insights performance test passes
- read/write access to content – so that content can be replicated to the Code Bus. Write access is required to send
repositotry_dispatch
events and trigger GitHub actions - read/write access to deployments – so that each branch in your GitHub repository can correspond to a deployment on aum.live
- read/write access to issues – so that Adobe can raise issues with your code when detected
- read/write access to pull requests – so that Adobe can suggest code updates, if required
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.
Previous
Staging & Environments
Up Next