How much effort is it to self-manage servers? PCI / SOC2 compliance?

Question

TL;DR: How much effort is required to self-manage a low-traffic SaaS app? Is PCI / SOC2 compliance too much of a hassle?

---

Currently we are using GCP. Our infrastructure is straightforward: A load-balanced SaaS, Postgres instance, and Memcache instance. We have two copies of this for our production and QA environments. Our site is very low traffic. We are also required to be PCI and SOC2 compliant.

Now, I have some gripes with GCP which I won't get into. I'm also the type of person who is always pushing for the simpler solution. I like to know how things work so that if it stops working I know exactly how to fix it.

With that, it shouldn't come as a surprise to know that I prefer to work with providers like Linode.

When I approached my boss with a plan to migrate to another provider it was immediately shot down. Also not a surprise; we are a small company and time spent improving infrastructure means time not spent on feature development. The main reasons cited were that it would take too long, there would be too much maintenance, it would be a disaster if I left the company, we would have to be audited again, etc.

I deemed that an uphill battle not worth fighting for, but it got me thinking how much maintenance effort is actually required.

My plan was to setup a small Docker Swarm cluster for each environment. Kubernetes is an option but I find it's way overkill for our use-case and has a steep learning curve.

Setting up the initial server(s) takes a day or two, but once you have a server image or setup script, adding new ones takes a matter of minutes. I wouldn't expect regular maintenance to be any more than upgrading system packages.

Are my expectations for maintenance effort realistic? No matter how I look at it this doesn't seem like a complicated endeavor.

Answer 1

Reliably standing up compute instances, and updating their software, is a core competency. Necessary for any IT environment. But getting servers running is a small component of ensuring a new hosting provider fits into a compliance environment.

New privileged accounts will exist with control over this new infrastructure, who manages those?

Every person needs to be assigned only permissions suitable for their role. Is an identity system change planned?

What networking changes are required to reach this new provider? Can production and QA be entirely segmented from each other?

How are data at rest protected? Depending on your risk profile and paranoia level, you may wish to implement database or file system level encryption. Even if the service provider has evidence that their storage system does disk level encryption.

Secrets, how are they managed? Keys, passphrases, and certificates will exist, so approved tools should be selected.

How do change management procedures work?

What security controls are associated with the infrastructure? Network firewall rules, ideally segmenting QA from production. Multiple auth methods. Resilience of the external facing services to denial of service. Software update compliance and vulnerability scanning.

Hosting providers sometimes make portability difficult by introducing their own special sauce APIs. Any of the above may be relying on features that do not have an obvious replacement at another provider.

What is a worst case scenario if this project fails compliance catastrophically? In the case of PCI, the organization may face large fines, and lose payment processor relationships. Unlikely, but business continuity is all about risk management.

Absolutely this new implementation would need to be audited to achieve the same confidence level. Ideally, improve security and availability over the previous designs.

Designing for a hosting provider switch gives choices, always good for competition. But beware claiming that doing things properly is easy, even for small systems.