Users and systems MUST be authorized separately for each environment.
Access servers SHOULD be separated instances for all environments but MUST be at least use separate realms.
System hardening: Systems (e.g. web servers, application servers, container platforms or content management systems, cloud platforms or other runtime environments) MUST be hardened according to common best practices. This includes:
A hardened OS (e.g. using a hardened base image, see below),
Deactivation of all services, plugins and other functionality that is not needed, especially if they are exposed (executable from remote).
Execution of network services (e.g. web or application servers) with only minimal privileges and isolated from other processes if possible (e.g. as an isolated container or dedicated server instance, VM or host).
Network services bound to localhost if access only required from same system.
Network services should only be accessible from certain IPs if possible.
Deactivation of file handlers that are not required (e.g. “.php” for a Java application).
Deactivation of insecure HTTP methods (e.g. TRACE and TRACK).
Web and application servers must not disclose details on the server-side software stack (e.g. version numbers). Related HTTP response headers such as “Server” or “X-Powered-By” are to be deactivated or filtered.
Docker images MUST only be build using trusted repositories.
Docker images MUST only use selected base images.
Docker images MUST be updating OS packages at build.
Docker images MUST be scanned for insecure 3rd party components and insecure configuration.
Docker images MUST not consists of a remote shell like SSH or telnet.
Docker container MUST have a maximal lifetime after which they have to be rebuild with updated OS dependencies.
Securing access to backend resources:
Every process MUST only have the required permissions to resources such as on the file system or database (least privilege principle). Example: “no root permission on databases”.