Automating Compliance: Surviving the Post-Safe Harbor Fallout in Norway
The ink is barely dry on the European Court of Justice's decision to invalidate the Safe Harbor agreement, and the panic in the boardroom is palpable. If you are a Systems Architect or CTO operating in Norway today, December 4, 2015, your reality has shifted. Relying on US-based cloud giants is now a legal minefield. Data sovereignty isn't a buzzword anymore; it is the only way to keep Datatilsynet (The Norwegian Data Protection Authority) from knocking on your door.
But moving workloads back to Norwegian soil is only half the battle. The other half is ensuring those servers meet rigorous security standards like PCI-DSS and the upcoming EU Data Protection reforms without hiring an army of consultants. Manual hardening is a dead end. If you are SSH-ing into servers to manually edit /etc/ssh/sshd_config, you have already failed the audit.
The "Infrastructure as Code" Imperative
Security must be reproducible. Whether you are deploying a single node for a client in Oslo or a cluster in Trondheim, the baseline must be identical. We are seeing a massive shift away from complex Chef cookbooks towards Ansible for this specific use case. It is agentless, uses SSH (which you already have), and is readable by auditors.
Here is a real-world scenario we faced last week: A fintech client needed to ensure 50+ nodes instantly rejected weak ciphers to mitigate threats like Logjam and POODLE. Doing this manually takes hours. With Ansible, it takes seconds.
Hardening SSH via Ansible
Stop allowing root login. Stop using passwords. Here is the exact playbook task we use to enforce key-based authentication across our CoolVDS infrastructure:
- name: Secure SSH Configuration
lineinfile:
dest: /etc/ssh/sshd_config
regexp: "{{ item.regexp }}"
line: "{{ item.line }}"
state: present
validate: '/usr/sbin/sshd -t -f %s'
with_items:
- { regexp: '^PasswordAuthentication', line: 'PasswordAuthentication no' }
- { regexp: '^PermitRootLogin', line: 'PermitRootLogin no' }
- { regexp: '^Protocol', line: 'Protocol 2' }
- { regexp: '^MaxAuthTries', line: 'MaxAuthTries 3' }
notify: restart ssh
This snippet ensures that even if a junior admin accidentally enables password auth during a late-night debug session, the next playbook run will mercilessly revert it to the secure state. That is compliance automation.
Firewall Management with CentOS 7 and Firewalld
Many of you are still comfortable with raw iptables scripts. I get it. They work. But with the adoption of RHEL 7 and CentOS 7 this year, firewalld offers dynamic management without dropping connections—critical for high-availability systems.
If you are hosting a web application, you should strictly limit exposure. Do not leave port 22 open to the world. Use a VPN or a bastion host. If you must expose it, rate limit it.
# Permanent configuration to allow HTTP/HTTPS and rate-limit SSH
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
# Rate limiting SSH to prevent brute force (Log entry on drop)
firewall-cmd --permanent --add-rich-rule='rule service name="ssh" limit value="4/m" log prefix="SSH_BRUTE: " level="info" accept'
firewall-cmd --reload
Running these commands on a high-performance NVMe VPS ensures that your packet filtering happens at the kernel level with minimal overhead. We have seen software firewalls choke on high-traffic nodes when the I/O is slow. This is why underlying hardware matters. On a CoolVDS instance, the I/O throughput ensures that logging dropped packets doesn't starve your database of disk cycles.
Continuous Auditing with OpenSCAP
How do you prove to an auditor that your servers are patched? Screenshots don't cut it. You need the Security Content Automation Protocol (SCAP). The oscap tool is available in the standard repositories and can scan your system against the XCCDF (The Extensible Configuration Checklist Description Format) standard.
To install and run a compliance scan for PCI-DSS on a CentOS 7 server:
yum install openscap-scanner scap-security-guide -y
# Run the scan and generate an HTML report
oscap xccdf eval --profile pci-dss \
--results /var/www/html/compliance-report.xml \
--report /var/www/html/compliance-report.html \
/usr/share/xml/scap/ssg/content/ssg-centos7-ds.xml
Pro Tip: run this as a nightly cron job. If a package update reverts a config file or a new vulnerability is disclosed, you will have a red flag on your dashboard the next morning. Compliance is a process, not a destination.
The Encryption Revolution: Let's Encrypt
Just yesterday, December 3rd, Let's Encrypt entered Public Beta. This is huge. The days of paying expensive CAs for standard SSL certificates are numbered. We are already integrating the Let's Encrypt client into our deployment scripts.
Automating SSL issuance means you never have an expired certificate causing a scary browser warning for your users. While the client is still in beta, it is stable enough for non-critical production workloads.
# Cloning the client (official method as of Dec 2015)
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
./letsencrypt-auto --help
Why Infrastructure Choice Dictates Compliance
You can script security all day, but if your underlying host is insecure, it is theater. This is where the distinction between "Container VPS" (OpenVZ/LXC) and "Hardware Virtualization" (KVM/Xen) becomes critical for Norwegian businesses.
In container-based hosting, you share the kernel with your neighbors. If a kernel exploit is discovered, your data is potentially exposed to other customers on the same physical box. This is unacceptable for sensitive data under strict Norwegian privacy laws.
| Feature | OpenVZ (Common VPS) | KVM (CoolVDS Standard) |
|---|---|---|
| Kernel Isolation | Shared Kernel | Dedicated Kernel |
| Memory Allocation | Burstable (Can be stolen) | Dedicated RAM |
| Compliance Readiness | Low | High (PCI-DSS/HIPAA friendly) |
At CoolVDS, we strictly use KVM. Each instance is a self-contained server. Furthermore, our datacenters are located here in the Nordic region. This ensures that your data remains under EEA jurisdiction, safe from the legal uncertainties currently plaguing US-based hosting providers post-Safe Harbor.
Final Thoughts
The regulatory environment in 2015 is unforgiving. Data sovereignty is now a legal requirement for many, not a feature. By combining the low-latency and legal safety of Norwegian hosting with the rigorous automation of Ansible and OpenSCAP, you build a fortress that is both compliant and performant.
Don't wait for the audit letter to arrive. Start hardening your infrastructure today. Deploy a KVM-based, NVMe-powered instance on CoolVDS and own your data.