How the division of responsibility works between MedStack and Your App

Note: MedStack does not provide our customers with root or sudo access to systems.

One of the most important things to understand when using MedStack is how we divide responsibility between ourselves and you.

Our overall goal is to have an appropriate and flexible division of responsibility with three tiers:

  • You: your application source code, deployment, and the database internals.
  • MedStack: system services, system libraries, operating systems, secure virtual networking, and hardening of these for security, privacy and compliance.
  • Major public cloud infrastructure providers: underlying hypervisors, (virtual) hardware and facilities (e.g. AWS and Azure).

What you manage

You have full control over:

  • application source code
  • deployment
  • database internals

We do not generally examine your application source code or database internals, leaving these under your full control.

We provide a sandbox for your application which we call the deploy user. This is a regular Unix user with no root or sudo access. The advantage of this design is that a potential attacker who might gain control of your web app (for example using a command injection attack) would have much greater difficult attacking the rest of the system because they do not have sudo or root.

We generally provide you with the deploy user with SSH key access, and either a specific directory for your code (for PHP) a port number (for other runtimes) which we will proxy with nginx.

We generally provide you with a database administrative user and password, and we may also for convenience create a regular database user and password for your use. The structure of the database(s) and the creation of additional users is under your full control.

What we manage

We manage:

  • system services
  • system libraries
  • operating systems
  • virtual networking
  • hardening of these for security, privacy and compliance

System services, such as the nginx web server, the database server, cache server, backup system, and the filesystem outside of the deploy directory, are generally under our control.

Libraries that need to be installed at the system level, such as many PHP modules, are installed and managed by us.

In general we maintain a whitelist of available services and libraries, and you may request a service or package from that whitelist at any time. We also will always consider requests for services that are not currently on the whitelist.

Flow of data diagram

Data flows through a number of layers between the internet, your app, and the database.

Example 1: Simple monolith architecture

The first diagram shows what this flow looks like in a monolithic single-VM architecture. In this example:

  1. Data flows from the public internet into the public cloud infrastructure provider's network, where they subject it to various security measure to protect their customers.
  2. Next, it hits the our managed IP Tables firewall, which only permits certain traffic.
  3. Next it connects with our managed nginx proxy server, which handles TLS encryption.
  4. The proxy sends to the data to your application server, or uses PHP-FPM in the case of PHP runtimes.
  5. Your app connects through the database engine, which we manage, to the database tables, which you have full control over.

Example 2: complex multi-factor architecture

The second diagram shows what this flow may look like in a multi-factored architecture. This example builds on the first, and adds the following additional elements:

  • A network-based Load Balancer directs traffic to one of three Virtual Machine application servers.
  • Within the application server, the App Server connects to port 3306 on localhost in order to connect to the database.
  • The database is actually managed by MedStack on a separate system.
  • MedStack manages a secure encrypted Stunnel between the application server and the database server.
  • You have full control over the database tables as in the simple example, and the tunnel is transparent to your use (making the database connections as though they were on the same system).

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.

Still need help? Submit a request for support Submit a request for support