In this post, let us explore some of the security-related setup/configurations available on AEM as a Cloud platform to protect the platform.

Traffic Filter Rules:

Traffic filter rules can be used to block or allow requests at the CDN layer (Fastly). These traffic filter rules are available to all AEM as Cloud Service Sites and Forms customers OOTB.

The traffic filter rules can be used for multiple scenarios.

Rate Limit the requests based on client IPS’s.
Block traffic based on IP addresses, Request Path, Query String, method, domain, reqHeader, reqCookie, postParam, etc.
Black traffic from specific countries.

The traffic rules can be targeted to the Author or Publish tier or both together. You can also apply various operations — like equals, doesNotEquals, in, matches, etc. The CDN responds with a 406 return code if a rule is matched and blocked.

The traffic rules can be managed through a YAML file and deployed separately through the Cloud Manager Config pipeline to Non-prod and prod environments. Create a YAML file(cdn.yaml) specific to Dev environments and Stage/Prod environments, separate into different folders, e.g., Config-Dev/cdn.yaml and Config-Prod/cdn.yaml; the config files can be managed through a separate repository or within a Dispatcher module repository, crate config pipeline specific to dev and stage/prod environments and point to the corresponding config folder along with repository, branches and other configurations.

For more details, refer to this document — Traffic Filter Rules including WAF Rules | Adobe Experience Manager. Examples and result analysis of Traffic Filter rules including WAF rules | Adobe Experience Manager (mktossl.com)

WAF (Web Application Firewall):

A WAF helps protect web applications by filtering and monitoring HTTP traffic between a web application and the Internet. It typically protects web applications from attacks such as DDOS, cross-site forgery, cross-site scripting (XSS), file inclusion, and SQL injection. A shield is placed between the web application and the Internet by deploying a WAF in front of a web application. The WAF operates through a set of rules that aim to protect against vulnerabilities in the application by filtering out malicious traffic.

The WAF rules/flags, e.g., XSS, SQLI, LOG4J-JNDI, can be enabled along with the other traffic filter rules explained above. The WAF rules can be enabled through the same cdn.yaml file and the Config pipeline.

The WAF traffic filter rules require either an Enhanced Security license or a WAF-DDoS Protection license.

For more details, refer to this document — Traffic Filter Rules including WAF Rules | Adobe Experience Manager.

Mod_Security:

Mod_security is an Apache module that helps protect your website from various attacks. Mod_security acts as a Web Application Firewall (WAF) that filters and blocks known malicious HTTP requests. Blocked HTTP requests include many, but not all, forms of Brute Force, Cross-Site Scripting (XSS), Remote File Inclusion (RFI), Remote Execution, and SQL injection (SQLi) attacks. By default, the mod security module is enabled on AEM as a Cloud Dispatcher (Apache), but the required rules and configurations can be enabled based on your needs.

For more details, refer to this document — Use ModSecurity to protect your AEM site from DoS Attack | Adobe Experience Manager (mktossl.com)

IP Allow List:

IP allowlisting is a way of giving trusted individuals access to the business network. With an IP allow list, the network administrator can allow specific IP addresses to access your files, applications, and software remotely.

AEM as a cloud service is, by default, accessible via the internet. While security is handled through user authentication and authorization, IP allow-listing is a way to limit access only to trusted IP addresses. Cloud Manager’s IP allowlists can be used to limit and control access only to such trusted IP addresses.

Cloud Manager users with appropriate permissions can create allowlists of trusted IP addresses from which their site’s users can access their AEM domains. After adding IP allowlists — Enter an IP or IP CIDR block that can be applied/unapplied multiple times as a unit or entity to an author and/or publisher service in an environment. For instance, this would be helpful if you wish to allow access to your Author environment from your company’s network, VPN, or VDI but block external access.

For more details, refer to this document — Adding IP Allow Lists | Adobe Experience Manager Applying and Un-Applying IP Allow Lists | Adobe Experience Manager

CDN uses the IP Allowlists defined in Cloud Manager to block the incoming requests for a specific environment/tier. The IP Allow lists defined in Cloud Manager take precedence over Traffic Filters Rules.

Advanced Networking:

AEM as a Cloud Service provides advanced networking features that allow for precise management of connections to and from AEM as a Cloud Service program.

AEM as a Cloud supports various networking configurations, including — Flexible Port egress, Dedicated egress IP address, and VPN.

Virtual Private Network (VPN) allows an AEM as a Cloud Service customer to connect the AEM environments within a Cloud Manager Program to an existing, supported VPN. This allows secure and controlled connections between AEM as a Cloud Service and services within the customer’s network.

Flexible port egress allows for custom, specific port forwarding rules to be attached to AEM as a Cloud Service, allowing connections from AEM to external services to be made.

The dedicated egress IP address allows requests from AEM as a Cloud Service to use a dedicated IP address, allowing the external services to filter incoming requests by this IP address.

Dispatcher Filters:

The request can also be restricted at the dispatcher layer by the /filter section to specify the HTTP requests the Dispatcher accepts. All other requests are sent back to the web server with a 404 error code (page not found). If no /filter section exists, all requests are accepted.

The /filter section consists of a series of rules that either deny or allow access to content according to patterns in the request-line part of the HTTP request. Use an allowlist strategy for your /filter section:

First, deny access to everything.
Allow access to content as needed.

/filter {
    /0001  { /glob "*" /type "deny" }
    /0002 { /type "allow" /method "POST" /url "/content/[.]*.form.html" }
}

For more details, refer to this document — Configuring Dispatcher | Adobe Experience Manager

HIPPA (Health Insurance Portability and Accountability Act) Compliance:

HIPAA compliance ensures the protection and confidential handling of patient health information, adhering to strict standards set by the Health Insurance Portability and Accountability Act.

Adobe provides healthcare customers with services that are ready to accept PHI, referring to these services as HIPAA-Ready Services. These HIPAA-Ready Services have additional features and functionalities that allow both customers, Covered Entities or Business Associates, and Adobe to comply with their respective HIPAA obligations.

The Adobe Experience Manager (AEM) as a Cloud Service is part of the HIPPA-ready service provided by Adobe.

Additional licensing is associated with enabling the HIPPA-ready service for the AEM as a Cloud service.

For more details, refer to this document — HIPAA Ready (adobe.com)

Mutual Transport Layer Security (mTLS) authentication from AEM:

AEM supports integrating with the external APIs that require mTLS authentication. The mTLS or two-way TLS authentication enhances the security of the TLS protocol by requiring both the client and the server to authenticate each other. This authentication is done by using digital certificates. It is commonly used in scenarios where strong security and identity verification are critical.

For more details, refer to this document — Mutual Transport Layer Security (mTLS) authentication from AEM | Adobe Experience Manager (mktossl.com)

Server-to-server Token-Based Authentication:

AEM’s Developer Console grants access to Service Credentials, which are production-ready service-to-service access tokens used to facilitate external applications, systems, and services to interact with AEM Author or Publish services over HTTP programmatically. Also, Local Development Access Token can be used by developers building integrations that require programmatic access to AEM as a cloud service needs a simple, quick way to obtain temporary access tokens for AEM to facilitate local development activities. To satisfy this need, AEM’s Developer Console allows developers to self-generate temporary access tokens that can be used to access AEM programmatically.

For more details, refer to this document — Service credentials | Adobe Experience Manager (mktossl.com) Local Development Access Token | Adobe Experience Manager (mktossl.com)

Data encryption:

All data in transit between AEM as a Cloud Service and external components is conducted over secure, encrypted connections using TLS 1.2 or greater. The cloud service provider encrypts all data at rest.

AEM as a Cloud Service also has a FIPS-approved crypto library and support for encryption keys to crypt all the critical data present in the cloud repository.

For more details, refer to this document — aem-cloud-service-security-overview.pdf (adobe.com)

OAuth2 Support for the Mail Service:

AEM as a Cloud Service offers OAuth2 support for its integrated Mail Service, allowing organizations to adhere to secure email requirements.

For more details, refer to this document — OAuth2 Support for the Mail Service | Adobe Experience Manager

Secret Variable Management through Cloud Manager:

In AEM as a Cloud service, the environment-specific configurations can be enabled using the Cloud manager environment variable. Two value types can be enabled — secret values and standard variables. The secret values can be centrally managed through Cloud Manager UI rather than managed through the code base to improve security; the secret variables can be referred to OSGI services, JAVA code, etc.

For more details, refer to this document — Support Custom Run Modes in AEM as a Cloud | Environment Specific Variables in AEM as a Cloud | by Albin Issac | Tech Learnings | Medium

Network security:

The AEM as a Cloud Service security model includes tenant and node-level isolation for all services. Each AEM as a Cloud Service tenant exists within its own isolated namespaces, including its own networking policies, computing, and storage.

Reference — aem-cloud-service-security-overview.pdf (adobe.com)

IAM integration:

AEM as a Cloud Service integrates Adobe Identity Management Service (IMS) for user verification. Various other Adobe products, including the Adobe Admin Console, also utilize this IMS authentication method. For AEM Authors in AEM as a cloud service, Adobe IMS authentication is activated, a change from previous AEM versions where identity and access management (IAM) settings had to be implemented individually on each AEM author server. With AEM in the cloud, single sign-on (SSO) configurations for AEM Authors and user and group management are centrally handled through the Adobe Admin Console using Adobe IMS.

For more details, refer to this document — AEM as a Cloud: IMS based SSO Authentication for Authors | by Albin Issac | Tech Learnings | Dec, 2023 | Medium

Also, the IAM system can be integrated with the publishers to enable an authenticated experience for the users who visit AEM websites.

Security Headers:

Security headers are HTTP response headers that define whether a set of security precautions should be activated or deactivated on the web browser. The security headers can be enabled through the Dispatcher (Apache) layer also; if required, some of the security headers can be directly enabled through the AEM publisher,

For more details, refer to this document — Adobe Experience Manager(AEM): HTTP Security Headers for Websites | by Albin Issac | Medium

Protect against Cross-Site Scripting (XSS)

Cross-site scripting (XSS) allows attackers to inject code into web pages viewed by other users. Malicious web users can exploit this security vulnerability to bypass access controls.

AEM applies the principle of filtering all user-supplied content upon output. Preventing XSS is given the highest priority during both development and testing.

The XSS protection mechanism provided by AEM is based on the AntiSamy Java™ Library provided by OWASP (The Open Web Application Security Project). The default AntiSamy configuration can be found at

/libs/cq/xssprotection/config.xml

It is important that you adapt this configuration to your own security needs by overlaying the configuration file. The official AntiSamy documentation provides you with all the information you need to implement your security requirements.

Reference — How to Protect AEM Websites from Cross-Site Scripting(XSS) (youtube.com)

Protect against Cross-Site Request Forgery Attacks

Cross-site request forgery (CSRF) is a web vulnerability that lets a malicious hacker trick the victim into submitting a request that allows the attacker to perform state-changing actions on behalf of the victim.

AEM uses CSRF tokens, and the Sling Referrer Filter — Adobe Experience Manager’s Referrer Filter enables access from third-party hosts to protect the websites from CSRF attacks.

For more details, refer to this document — CSRF protection | Adobe Experience Manager Referrer Filter configuration with AEM Headless | Adobe Experience Manager

In summary, security is essential in the cybersecurity landscape for any platform or website. It is imperative that every platform implements necessary measures to safeguard both the platform and user data. As a cloud service, AEM offers multiple layers of security configurations to protect the platform, enabling these configurations as needed.

Blog posts around Oracle SOA Suite,Adobe Experience Manager(AEM),Dispatcher and Web technologies

Pages

Thursday, February 22, 2024

ReferenceError: XMLHttpRequest is not defined - Ollama Java Script

Error: Cannot find module '@npmcli/config'

Friday, February 9, 2024

Exploring Security Features in Adobe Experience Manager for Cloud Environments