Increased security for Enterprise and Elite

As a Platform.sh customer, your protection is paramount and every single one of your projects is secure. For Enterprise and Elite customer projects we go the extra mile and offer a rich selection of enhanced security features, which can be used right now.

• Multifactor authentication (MFA) over SSH
• Firewall
• Reverse proxies for external origins

Let’s dig into each of them.

MFA over SSH

MFA increases security by requiring users to use more than one method to identify themselves. So even if malicious actors gain access to one method, they can’t access your systems.

You can now enforce MFA over SSH within your organization. With this option enabled, every contributor within your organization must use MFA to run Git commands or SSH into an environment.

MFA over SSH requires users to have the command line interface (CLI), as this is what’s used for authentication. With MFA enforced, users can no longer authenticate with SSH keys. Instead, they’re granted short-lived SSH certificates. See more details about this process in a previous blog post.

To enable MFA over SSH, simply open a support ticket with the request. You can have it enabled for all projects within your organization or a select list of projects. Just let us know which you prefer.

Firewall

You might want to lock down your network so your apps can only access certain sites. If so, you can take advantage of our firewall to secure access.

We recently added the firewall property to .platform.app.yaml so you can specify IP addresses, ports, and protocols for access. This feature gives you the flexibility to secure your network according to your specific rules and helps ensure PCI compliance.

You can even filter outbound traffic by domain, which is even more specific and secure. For example, if you use an IP address for a service with a CDN, you have to allow the IP address for the CDN. This means that you’re allowing potentially hundreds or thousands of other servers also using that CDN.

To use the firewall, simply specify the firewall key in your .platform.app.yaml file like in the following example:

firewall:
  outbound:
    - protocol: tcp
      ips: ["192.0.2.0/24"]
      ports: [443]
    - protocol: tcp
      ips: ["203.0.113.123"]
    - protocol: tcp
      domains: ["api.example.com"]
      ports: [80, 443]

These rules define what outbound traffic is allowed and anything unspecified is blocked. They don’t affect inbound traffic.

See all of the details about adding firewalls in our firewall documentation.

Reverse proxies for external origins

Proxy routes allow you to pass requests to locations outside your Platform.sh project, including to a different Platform.sh project. This means you can use the same base URL across different projects, such as pointing example.com/fr to one project and example.com/de to another.

Visitors to your site (example.com in this case) see everything as coming from one location. But you’re free to handle the requests as you like in the background, so you can offload services to projects specialized in handling them.

You can define an external proxy for your Platform.sh project by defining a route in your .platform/routes.yaml file like in the following example:

https://{default}/no-slash:
    type: proxy
    to: https://example.net
https://{default}/with-slash:
    type: proxy
    to: https://example.org/

If your default domain is example.com, this means that requests for https://example.com/no-slash/index.html are passed to https://example.net/no-slash/index.html. The full path is preserved in the proxied request.

But requests for https://example.com/with-slash/index.html are passed to https://example.org/index.html. The trailing slash means that part of the path is overwritten.

As you can see, you have flexibility in defining your external proxies. See all of your options in our proxy route documentation.

Note that for larger projects our recommendation is to handle this through a CDN. The router scales with the size of the project and can potentially become a bottleneck and a single point of failure for all projects in the domain.