Console Login

Automating GDPR Compliance: OpenSCAP and Ansible on Norwegian Infrastructure

Automating the Audit: Continuous Security Compliance for Norwegian Enterprises

The era of managing server security via Excel spreadsheets effectively ended in May 2018. If you are still manually checking checklist boxes to satisfy GDPR Article 32, you aren't just inefficient; you are a liability. As a CTO, my job isn't just to ensure uptime; it's to mitigate risk. And in the Norwegian market, where the Datatilsynet (Data Protection Authority) is rightfully aggressive about citizen privacy, infrastructure compliance is not optional.

We are going to look at how to automate security compliance using OpenSCAP and Ansible on a CentOS 7 environment. We focus on the CIS (Center for Internet Security) benchmarks, which provide the prescriptive guidance needed to harden a server properly. This is the exact methodology we recommend when deploying critical workloads on CoolVDS NVMe instances.

The "Data Residency" Reality Check

Before we touch the terminal, let's address the architecture. You can have the most hardened OS in the world, but if that VM resides on a chaotic, oversubscribed host in a jurisdiction with weak privacy laws, you have failed before you started.

This is why we architect CoolVDS with strict KVM (Kernel-based Virtual Machine) virtualization. Unlike OpenVZ or LXC containers often found in budget hosting, KVM ensures your kernel is yours alone. There is no "noisy neighbor" bleeding into your memory space, and more importantly, the isolation layer is robust enough for PCI-DSS and GDPR compliance standards. Furthermore, keeping data within Norwegian borders (Oslo) minimizes latency to the NIX (Norwegian Internet Exchange) and simplifies your legal standing regarding data export.

Step 1: Assessing the Baseline with OpenSCAP

OpenSCAP is an open-source implementation of the SCAP (Security Content Automation Protocol) standard. It allows us to scan a system against a specific profile (like PCI-DSS or CIS) and generate a report. In 2019, this is the standard tool for RHEL/CentOS systems.

First, let's install the scanner and the security guides on your CoolVDS CentOS 7 instance:

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

Once installed, we can view available profiles. We aren't guessing here; we want to see exactly what policies are available for our OS version.

oscap info /usr/share/xml/scap/ssg/content/ssg-centos7-ds.xml

You will see a list of profiles. For a standard web server handling sensitive data, we typically look at the xccdf_org.ssgproject.content_profile_standard or, for higher security, the CUI (Controlled Unclassified Information) profile. Let's run a scan against the standard profile and output the results to an HTML file.

oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_standard \
  --results scan-results.xml \
  --report report.html \
  /usr/share/xml/scap/ssg/content/ssg-centos7-ds.xml

If you run this on a fresh, unoptimized installation, you will likely fail 30-40% of the checks. Do not panic. This is normal. The report will highlight issues like empty passwords, SSH root login enabled, or insecure partition mounting options.

Step 2: Remediation via Ansible

Scanning is passive. Remediation is active. While OpenSCAP can generate bash scripts to fix issues, running generated bash scripts in production is reckless. It breaks idempotency—the core principle that running a script twice shouldn't break the system. Instead, we use Ansible.

Pro Tip: Do not blindly apply the DISA STIG or CIS Level 2 profiles to a production web server without testing. These profiles often disable kernel modules (like IPv6 or specific filesystems) that modern web applications might rely on. Always test in a staging environment on CoolVDS first.

We can write a playbook that specifically targets the failures identified in our scan. Below is a snippet of a robust Ansible playbook designed to fix common SSH and Kernel vulnerabilities found in 2019-era audits.

---
- name: Harden CentOS 7 Server
  hosts: all
  become: yes
  tasks:

    - name: Ensure SSH Protocol is set to 2
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^Protocol'
        line: 'Protocol 2'
        state: present
      notify: restart sshd

    - name: Disable SSH Root Login
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^PermitRootLogin'
        line: 'PermitRootLogin no'
        state: present
      notify: restart sshd

    - name: Set Password Expiration (GDPR Requirement)
      lineinfile:
        path: /etc/login.defs
        regexp: '^PASS_MAX_DAYS'
        line: 'PASS_MAX_DAYS 90'
        state: present

    - name: Restrict Core Dumps (Security Best Practice)
      sysctl:
        name: fs.suid_dumpable
        value: '0'
        state: present
        reload: yes

  handlers:
    - name: restart sshd
      service:
        name: sshd
        state: restarted

Step 3: Continuous Monitoring with Auditd

Hardening is not a "set it and forget it" task. Configuration drift occurs when a junior developer temporarily opens a port for debugging and forgets to close it. To satisfy compliance, we need an audit trail.

We configure the Linux Audit Daemon (auditd) to watch critical files. If /etc/passwd is modified, you need to know. Here is a configuration snippet for /etc/audit/rules.d/audit.rules ensuring that any change to user identity is logged:

# Watch for changes to user/group databases
-w /etc/group -p wa -k identity
-w /etc/passwd -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/security/opasswd -p wa -k identity

# Lock the audit configuration (must be the last rule)
-e 2

Reload the rules using augenrules --load. Now, every attempt to change user privileges is immutable logged.

Infrastructure Performance vs. Security Overhead

A common objection to running aggressive audit logging and real-time security scanning is the performance penalty. On legacy spinning rust (HDD) VPS, high I/O wait times caused by auditd writing to disk can indeed kill your application's response time.

This is where the hardware underlying the compliance strategy matters. CoolVDS runs exclusively on enterprise-grade NVMe storage. NVMe queues are capable of handling the concurrent write operations of detailed audit logs without stalling your database queries. When we talk about "compliance at speed," we mean that your security posture shouldn't cost you milliseconds on the frontend.

The Final Verdict

Compliance in 2019 is about proving control. By combining the rigid scanning of OpenSCAP with the idempotent enforcement of Ansible, you transform security from a quarterly panic into a daily routine.

However, software automation cannot fix hardware vulnerabilities or weak jurisdiction. For your next high-compliance project, ensure your foundation is as solid as your code. Deploy a hardened CentOS 7 instance on CoolVDS today, and keep your data safely within Norway's borders.