Skip to content
Beta

Security and Compliance

In 1 trail

Last updated on

Purpose

Section titled “Purpose”

In landing zones, Security, and Compliance are implementation constraints that must follow the cross-cutting design baseline from the dedicated module.

Use this page to apply module outcomes to platform and application landing-zone decisions.

Use the dedicated module as source of truth

Section titled “Use the dedicated module as source of truth”

Landing-zone implementation focus

Section titled “Landing-zone implementation focus”
  • Audit Logging: Use central audit logging as the authoritative record for security-relevant platform actions and administrative changes. Documentation
  • Telemetry Router: Route and normalize telemetry streams so logs and metrics from distributed workloads can be collected consistently. Documentation
  • Logs: Establish centralized log collection patterns for operational and security analysis. Documentation
  • Observability: Design observability as a layered model: application log streams per application plus central audit logging and platform telemetry for governance and incident analysis. Documentation
  • Network Security: Apply network hardening principles for segmentation, controlled traffic paths, and reduced exposure surface. Documentation
  • Compute Security: Define workload hardening baselines and secure runtime practices for compute resources. Documentation
  • Secrets Manager: Store and govern sensitive credentials and application secrets through managed controls instead of ad hoc handling. Documentation
  • KMS: Manage key lifecycles and encryption governance through a centralized key management approach. Documentation
  • ACL patterns for PaaS services: Use service-level access control lists to constrain connectivity paths for managed services. PostgreSQL is one example, but this pattern applies across STACKIT PaaS services. PostgreSQL reference: Documentation .
  • Unified Firewall: Use centralized firewall controls for consistent network policy enforcement across zones and workloads. Documentation

How this applies to landing zones

Section titled “How this applies to landing zones”
  • Evidence and detection layer: Audit Logging, Logs, Telemetry Router, and Observability provide the data foundation for compliance evidence and incident analysis.
  • Preventive hardening layer: Network Security, Compute Security, Unified Firewall, and service ACLs reduce exposure and enforce approved traffic and runtime boundaries.
  • Data protection layer: Secrets Manager and KMS protect sensitive data paths and cryptographic assets throughout workload life cycles.
  • Operational model: Application teams provide workload telemetry while central teams run shared governance visibility across projects.

Translate the compute-hardening recommendations into an owned, testable VM baseline before onboarding workloads.

From the STACKIT docsSecurity in Compute Engine › System hardeningSource updated 06.07.2026 · copied 06.10.2026

The security of your virtual machines (VMs) is paramount to ensuring the integrity of your infrastructure. The following are recommended measures to harden the security of your VMs:

  • Installation: Install only the packages required for your use case. Reduce the number of running services and use a minimal installation image if possible.
  • User management: Disable root login and use sudo for administrative tasks instead. Implement strong password policies and remove or disable unused users and groups. For secure authentication, we recommend using SSH keys.
  • File permissions and ownership: Verify permissions for system files and directories using tools such as chmod and chown. The sticky bit should be set for global directories, such as /tmp, and ensure that there are no non-root files in directories such as /bin, /usr/bin, and /sbin.
  • Firewall and ports: Use a firewall, for example with iptables or firewalld, and allow only necessary ports. Deny all access by default and whitelist only the necessary services. You can also use STACKIT Security Groups to allow only necessary ports.
  • Service management: Disable and stop services that are not needed. Run services only with the minimum required rights.
  • SSH hardening: Change the default SSH port and disable root login via SSH by setting “PermitRootLogin no” in the sshd\_config. Use SSH keys instead of passwords and disable empty passwords by setting PermitEmptyPasswords no.

You can find additional recommendations and guidelines at the following links:

  • Choosing Policy, OpenSCAP Portal
  • BSI - SiSyPHuS Win10: Empfehlung zur Härtung von Windows 10 mit Bordmitteln
  • BSI - SYS.1.3 Server unter Linux und Unix
What is this?

This section is copied from the STACKIT docs automatically, several times a day. It cannot be changed here. Changes belong in the STACKIT docs.

Validate service-local access rules separately from network routing. The following ACL behavior is specific to PostgreSQL Flex; confirm the corresponding rules for every other managed service rather than assuming identical defaults.

From the STACKIT docsCreate and manage instances › ACLSource updated 24.09.2026 · copied 06.10.2026

With the ACL entries, you control which source IPs are allowed to connect to your instance. Note, that this is an additional security layer and does not replace the need for proper authentication and security best practices. There are two predefined entries: 193.148.160.0/19 and 45.129.40.0/21. They ensure that you can access your instance from STACKIT cloud services. If you want to access your instance from the public net, you need to add the client’s IPv4 address or subnet. The entries follow the CIDR notation. If you want to allow a single IP address (e.g. single host), then set 32as the subnet parameter. E.g. to allow a host with the source IPv4 address of 93.229.84.137, add 93.229.84.137/32 as ACL entry. At the moment, you can’t add IPv6 addresses.

Do not set 0.0.0.0/0 as an ACL IP, because then your instance can be accessed from every IP.

What is this?

This section is copied from the STACKIT docs automatically, several times a day. It cannot be changed here. Changes belong in the STACKIT docs.

Key design decisions

Section titled “Key design decisions”
  • Logging architecture boundaries: Define logging scope at application level, platform level, and audit level, and where each stream is retained.
  • Telemetry and observability model: Define routing, enrichment, and ownership for logs, metrics, and traces.
  • Hardening baseline scope: Define mandatory controls for network and compute domains, including firewall and service ACL patterns.
  • Secrets and key governance: Standardize Secrets Manager and KMS usage, ownership, and life cycle responsibilities.
  • Compliance operating model: Define who owns evidence collection, control verification, and reporting cadence.

Typical outputs

Section titled “Typical outputs”
  • Security baseline catalog: Controls for network, compute, identity, and data protection.
  • Logging and evidence architecture: Central audit logging plus workload observability with clear ownership boundaries.
  • Secrets and encryption standard: Defined usage model for Secrets Manager, KMS, and key and secret life cycle handling.
  • Response and escalation model: Operational runbooks for detection, assessment, and incident reporting.

Anti-patterns to avoid

Section titled “Anti-patterns to avoid”
  • Security deferred to late migration phases: Controls are added after workload onboarding instead of by design.
  • Disconnected telemetry stacks: Audit, platform, and application signals cannot be correlated in incidents.
  • Secrets in code or unmanaged stores: Sensitive values are not governed through dedicated secret management.
  • Flat network access without service controls: Missing firewall and ACL boundaries allow excessive lateral movement.