Automating Security Compliance: Surviving the 2018 Regulatory Shift with Ansible and OpenSCAP

The Era of Manual Hardening is Over

If you are still manually editing /etc/ssh/sshd_config on every new server deployment, you are already non-compliant. With the General Data Protection Regulation (GDPR) enforcement date set for May 2018, the grace period for European businesses is rapidly evaporating. As a CTO, my concern isn't just malicious actors; it's the inconsistency of my own team.

In the Norwegian market, we face a dual challenge: strict local oversight from Datatilsynet and the broader European mandate. Security is no longer a state; it is a continuous process. If you cannot prove the state of your infrastructure at any given second, you are vulnerable. This guide focuses on automating that proof using tools available right now in 2017: Ansible for configuration management and OpenSCAP for continuous auditing.

Pro Tip: Compliance is impossible on oversold infrastructure. We strictly use KVM virtualization at CoolVDS because container-based solutions (like OpenVZ) share a kernel. If a neighbor panics the kernel, your "secure" environment goes down with it. For strict isolation, KVM is the only professional choice.

Phase 1: Infrastructure as Code (IaC) for Hardening

The first step to compliance is reproducibility. We need a baseline security policy that applies to every single node, whether it's a load balancer or a database slave. We use Ansible (currently version 2.3) to enforce this.

Here is a production-grade Ansible task list to harden SSH. This disables root login and enforces key-based authentication—two absolute requirements for any server exposed to the internet.

---# roles/security/tasks/ssh_hardening.yml- name: Ensure SSH Protocol 2 is set  lineinfile:    dest: /etc/ssh/sshd_config    regexp: '^Protocol'    line: 'Protocol 2'    state: present- name: Disable Root Login via SSH  lineinfile:    dest: /etc/ssh/sshd_config    regexp: '^PermitRootLogin'    line: 'PermitRootLogin no'    state: present  notify: restart sshd- name: Disable Password Authentication  lineinfile:    dest: /etc/ssh/sshd_config    regexp: '^PasswordAuthentication'    line: 'PasswordAuthentication no'    state: present  notify: restart sshd- name: Ensure SSH key files have correct permissions  file:    path: /etc/ssh/ssh_host_rsa_key    owner: root    group: root    mode: 0600

Running this playbook ensures that no matter who deployed the server, the door is locked tight. However, applying the config is only half the battle. You must verify it.

Phase 2: Automated Auditing with OpenSCAP

How do you prove to an auditor that your servers are secure? You don't show them scripts; you show them reports. The Security Content Automation Protocol (SCAP) is the industry standard for this.

On our standard CoolVDS CentOS 7 images, you can install the SCAP scanner and the security guide immediately:

yum -y install openscap-scanner scap-security-guide

Once installed, you can run a scan against the PCI-DSS (Payment Card Industry Data Security Standard) profile. This is crucial for any e-commerce operation running on our platform.

oscap xccdf eval \  --profile xccdf_org.ssgproject.content_profile_pci-dss \  --results /tmp/pci-dss-results.xml \  --report /tmp/pci-dss-report.html \  /usr/share/xml/scap/ssg/content/ssg-centos7-ds.xml

This command checks your system against hundreds of rules. It verifies partition mounting options, checks for legacy services, and validates permission bits. The output provides a pass/fail grade for every check.

Interpreting the Results

You will likely fail your first scan. That is normal. Common failures in 2017 include:

• IP Forwarding enabled: Often default, but a security risk if not acting as a router.
• UMASK settings: Default user creation often allows too much read access.
• Legacy Protocols: Having telnet or rsh installed.

Phase 3: Network Level Isolation

Software hardening is useless if your network layer is Swiss cheese. Using iptables directly is complex and error-prone. On CentOS 7, firewalld allows for zone-based management which is easier to automate.

Here is how we configure a "Drop by Default" policy using Ansible. This ensures that only specifically allowed traffic (SSH, HTTP, HTTPS) enters your VPS.

- name: Install firewalld  yum:    name: firewalld    state: present- name: Start and enable firewalld  service:    name: firewalld    state: started    enabled: yes- name: Set default zone to drop  command: firewall-cmd --set-default-zone=drop- name: Allow SSH (limited)  firewalld:    service: ssh    permanent: yes    state: enabled- name: Allow HTTP/HTTPS  firewalld:    service: {{ item }}    permanent: yes    state: enabled  with_items:    - http    - https

The Data Sovereignty Factor

We are seeing a massive shift in 2017 regarding where data physically sits. With the invalidation of Safe Harbor and the precarious nature of the Privacy Shield framework, hosting data outside the EEA (European Economic Area) is a legal minefield.

This is where physical infrastructure becomes a compliance tool. When you deploy on CoolVDS, you aren't just getting a virtual machine; you are getting a guarantee of location.

Conclusion: Consistency is Security

The days of the "cowboy sysadmin" are over. In preparation for the stringent regulations arriving in 2018, your infrastructure must be defined as code and audited by machines. By combining Ansible for enforcement and OpenSCAP for verification, you create a self-healing, self-documenting compliance engine.

However, your code is only as secure as the platform it runs on. You need a host that respects data sovereignty and provides raw, unthrottled I/O for these audit processes.

Ready to audit your infrastructure? Deploy a KVM instance in our Oslo datacenter today and run your first OpenSCAP scan in under 5 minutes.