Adobe(Magento) Commerce Cloud is not PCI DSS compliant by design
Magento Comunity found another fake published by Adobe (https://magento.com/trust/compliance), a Magento company about theirs Commerce Cloud. Magento salespersons sales Magento Clous as PCI DSS (Payment Card Industry Data Security Standard) compliant shower by this Cloud architecture can’t be compliant.
PCI-DSS is the compliancy of your entire online environment which includes your systems, practices, software, etc. This is the standard that is required to be able to process on-site payments. Magento IS PCI-DSS compliant when the rules of PCI-DSS are followed which include:
– Build and Maintain a Secure Network
– Protect Cardholder Data
– Maintain a Vulnerability Management Program
– Implement Strong Access Control Measures
– Regularly Monitor and Test Networks
– Maintain an Information Security Policy
A eVommerce software can never be “PCI compliant” by itself. A Magento can be PCI compliant if the environment is also PCI compliant, which would include the way an application flows. An application can be PA-DSS compliant, but the environment may or may not be PCI compliant.
PSS DSS has a strict standard :
PCI DSS CONTROL 1.3
Control Intent: The University prohibits direct public access between the Internet and any system component in the Cardholder Data Environment (CDE).
Standard: Data custodians are responsible for ensuring that firewall and router configuration standards are established and managed to prohibit direct public access between the Internet and any system component in the Cardholder Data Environment (CDE) that includes, but is not limited to:
(a) Demilitarized Zones (DMZ) are required to be implemented to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports;
(b) Inbound Internet traffic shall be limited to IP addresses within the DMZ; (c) Implement anti-spoofing measures to detect and block forged source IP addresses from entering the network;
(d) Unauthorized outbound traffic from the CDE to the Internet is prohibited;
(e) Stateful inspection (dynamic packet filtering) must be implemented;
(f) System components that store cardholder data must be placed within an internal network zone, segregated from the DMZ and other untrusted networks;
(g) Private IP addresses and routing information are prohibited from being disclosed to unauthorized parties.
Link to the document:
What is a DMZ Network?
A demilitarized zone (DMZ) is a perimeter network that protects an organization’s internal local-area network (LAN) from untrusted traffic.
A common DMZ meaning is a subnetwork that sits between the public internet and private networks. It exposes external-facing services to untrusted networks and adds an extra layer of security to protect the sensitive data stored on internal networks, using firewalls to filter traffic.
The end goal of a DMZ is to allow an organization to access untrusted networks, such as the internet, while ensuring its private network or LAN remains secure. Organizations typically store external-facing services and resources, as well as servers for the Domain Name System (DNS), File Transfer Protocol (FTP), mail, proxy, Voice over Internet Protocol (VoIP), and web servers, in the DMZ.
These servers and resources are isolated and given limited access to the LAN to ensure they can be accessed via the internet but the internal LAN cannot. As a result, a DMZ approach makes it more difficult for a hacker to gain direct access to an organization’s data and internal servers via the internet.
How Does a DMZ Network Work?
Businesses with a public website that customers use must make their web server accessible from the internet. Doing so means putting their entire internal network at risk. To prevent this, an organization could pay a hosting firm to host the website or their public servers on a firewall, but this would affect performance. So instead, the public servers are hosted on a network that is separate and isolated.
A DMZ network provides a buffer between the internet and an organization’s private network. The DMZ is isolated by a security gateway, such as a firewall, that filters traffic between the DMZ and a LAN. The DMZ is protected by another security gateway that filters traffic coming in from external networks.
It is ideally located between two firewalls, and the DMZ firewall setup ensures incoming network packets are observed by a firewall — or other security tools — before they make it through to the servers hosted in the DMZ. This means that even if a sophisticated attacker is able to get past the first firewall, they must also access the hardened services in the DMZ before they can do damage to a business.
If an attacker is able to penetrate the external firewall and compromise a system in the DMZ, they then also have to get past an internal firewall before gaining access to sensitive corporate data. A highly skilled bad actor may well be able to breach a secure DMZ, but the resources within it should sound alarms that provide plenty of warning that a breach is in progress.
Organizations that need to comply with regulations, such as the Health Insurance Portability and Accountability Act (HIPAA), will sometimes install a proxy server in the DMZ. This enables them to simplify the monitoring and recording of user activity, centralize web content filtering, and ensure employees use the system to gain access to the internet.
What’s in PCI Requirement 1.3.6?
To meet PCI Requirement 1.3.6, your eCommerce must not store cardholder data within the DMZ. PCI Requirement 1.3.6 states, “Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks.” PCI Requirement 1.3.6 also says, “Examine firewall and router configurations to verify that system components that store cardholder data are on an internal network zone, segregated from the DMZ and other untrusted networks.”
The purpose and intent behind PCI Requirement 1.3.6 is to move cardholder data into an internal and secure environment, as opposed to the DMZ. Your organization has already spent so much time hardening the assets and networks within your environment, and if cardholder data exists within the DMZ, all of that work is diminished. PCI DSS states:
If cardholder data is located within the DMZ, it is easier for an external attacker to access this information since there are fewer layers to penetrate. Securing system components that store cardholder data in an internal network zone that is segregated from the DMZ, and other untrusted networks, by a firewall can prevent unauthorized network traffic from reaching the system component.
If your organization is storing cardholder private, sensitive data within your DMZ, assessors must examine the means and methods for moving that data into the internal environment. Magento Cloud has and issues with this when a Database server or web server is processing data. When that data comes in, rather than writing it in to the local system within the DMZ, write that data into the corporate private network or into a server that resides within the cardholder data environment (CDE).
Magento (Adobe) Cloud has the next architecture
The Adobe Cloud environment has three virtual machines (VMs) behind an Elastic Load Balancer managed by an HAProxy per VM. Each VM includes the following technologies:
- Fastly CDN — HTTP caching and CDN
- NGINX — web server using PHP-FPM, one instance with multiple workers
- GlusterFS — file server for managing all static file deployments and synchronization with four directory mounts:
var, pub/media, pub/static, app/etc - Redis — one server per VM with only one active and the other two as replicas
- Elasticsearch — search for Magento Commerce Cloud 2.2 and later
- Galera — database cluster with one MariaDB MySQL database per node with an auto-increment setting of three for unique IDs across every database
The following figure shows the technologies used in the Magento Cloud:
So, as we can See no DMZ and any network separation. It is just a legacy singe serve Magento installation when all layers: Web PHP, Database MySQL, Cache Redis located in the single network and even on the same server with the minimum of security. If somebody has access to one server, it can access all layers and customer data.
Get Public IP address of Cloud instance
Use ping command for retrieving IP address for particular Cloud instance.
Example of usage:
ping integration-abcd123-abcd78910.us-3.magentosite.cloudSample response:
PING integration-abcd123-abcd78910.us-3.magentosite.cloud (34.210.133.187): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2Also, your Magento Cloud store shares The same Network with other Magento cloud customers.
AWS Magento DMZ
With the SelfHosted AWS Magento Hosting, you can easily achieve DMZ best practices.
If you use AWS RDS database to store cardholder data, set the instance PubliclyAccessible field to 'false'. Allowing public access to your replication instance might violate the requirement to place system components that store cardholder data in an internal network zone, segregated from the DMZ and other untrusted networks.
Amazon RDS databases can be launched in the public or private subnet of a VPC. Connection problems can be caused by an incorrect VPC configuration or by configuration or connectivity issues on the client that you are connecting from.
My DB instance is in a public subnet, and I can’t connect to it over the internet from my local computer
This issue can occur when the Publicly Accessible property of the DB instance is set to No.
My DB instance is in a private subnet, and I can’t connect to it from my local computer
You can resolve this issue by using a public subnet. When you use a public subnet, all the resources on the subnet are accessible from the internet. If this solution doesn’t meet your security requirements, use AWS Site-to-Site VPN. With Site-to-Site VPN, you configure a customer gateway that allows you to connect your VPC to your remote network.
Requirement 2.2.1 Implement only one primary function per server
Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, cache servers, database servers, and DNS should be implemented on separate servers.)
For example:
A database, which needs to have strong security measures in place, would be at risk-sharing a server with a web application, which needs to be open and directly face the Internet. Failure to apply a patch to a seemingly minor function could result in a compromise that impacts other, more important functions (such as a database) on the same server.
This requirement is meant for all servers within the cardholder data environment. This requirement may not apply to systems that have the ability to natively implement security levels on a single server (e.g. mainframe).
So basically what the requirement is saying is that you need to assign one primary function per server.
Requirement 6.4.1 Separate development/test environments from production environments, and enforce the separation with access controls.
Magento has a Staging environment and production environment hosted on the same servers for the starter plans. Also, the integration environment uses shared servers and networks with another Magento customer.
Be, careful and whatever salesperson is telling you Magento (Adobe) Cloud is not PCI DSS compliant however Magento salespersons and Magento minions(Agencies) will tell you that it is a complaint high-performance cloud solution. Fakes makes Magento 2 strong.
To reiterate, Magento 2 does have the built in ability to store cardholder data in its own database, but you will never be PA-DSS compliant in doing so which prevents you from being PCI-DSS compliant. The Magento application (at any level: CE, PE, EE) has not been PA-DSS certified. Remember, PA-DSS applies to software only, and not the infrastructure. Storing cardholder data in a non-PA-DSS compliant application like Magento will invalidate PCI compliance.
