It seems to me like you're overanalyzing the issue - PCI DSS doesn't require you to ensure that the system is impossible to abuse, it requires you to perform due diligence along some basic abuse vectors.

Cites here are from [DSS 3.1][1] "Testing Procedures":

> 10.5.1 Only individuals who have a job-related need can view audit trail files.

Ensure that auth* type logs are readable only by root.  That can be pretty simple:

    $ grep authpriv /etc/rsyslog.conf
    # The authpriv file has restricted access.
    authpriv.*                                              /var/log/secure
    $ ls -l /var/log/secure
    -rw------- 1 root root 1085793 Nov 10 13:43 /var/log/secure
    $

And you're done.  Is it possible that a malicious administrator could go out of their way to log authpriv somewhere else and have it be obscure to see where, and to also have that be world readable?  It's *possible*, but that's not what the QSA is looking for, they're looking to ensure you didn't misconfigure your logs by mistake so everyone can read authpriv.

> 10.5.2 Current audit trail files are protected from unauthorized modifications via access control mechanisms, physical segregation,
> and/or network segregation.

Show that your log files aren't writable to any inappropriate groups or 'other':

    # find /var/log -type f -a \( -perm -g+w -or -perm -o+w \) -ls
    131282 2220 -rw-rw-r--   1 root     utmp      2265216 Oct 30 09:51 /var/log/wtmp-20151101
    133888  192 -rw-rw-r--   1 root     utmp       192000 Nov  9 16:12 /var/log/wtmp
    # 

`wtmp` is group-writable to utmp to allow it to be updated by non-root terminals, so that's normal.  No other findings.  Along with basic checks to show that your logs go to /var/log, you're all set.

> 10.5.3 Current audit trail files are promptly backed up to a centralized log server or media that is difficult to alter.
> 
> 10.5.4 Logs for external-facing technologies (for example, wireless, firewalls, DNS, mail) are written onto a secure, centralized, internal
> log server or media.


First, show the configuration indicating that logs are sent to your central SIEM.  Then show a query proving that logs from your machine can be found on your SIEM.  Repeat for whatever sample size your QSA requests.

You don't need to do a full reconciliation that every line found locally is found on the remote server.  You just need to prove that you've configured it to log to a remote server, and that it apparently functions properly.

> 10.5.5 Examine system settings, monitored files, and results from monitoring activities to verify the use of file-integrity monitoring
> or change-detection software on logs.

Confirm that /etc/rsyslog* and /var/log/* are monitored by your FIM (e.g., Tripwire).  That's it.

Are these steps enough to secure your environment?  No!  The PCI DSS is a floor, not a ceiling.  It's a basic, due-diligence checklist to get you started and to try and ensure everyone is at least buckling their seat belts.  So you can keep looking for ways to improve your security, but you'll likely pass your PCI audit on your way there.

Now, that being said, I'm detecting another issue in your question, which is that you lack centralized configuration control.  That's going to make your audits harder - when you say "here's the config file, and here's the Puppet config showing it's used by 95% of our servers" you make it easier for the QSA to sign off on a sample of your environment.  If you've got "valid configurations [that] tend to proliferate" you've got a problem that's not just impacting your PCI compliance, it's going to impact your overall security.  You should look into centralized management (here's a [comparison of four of such tools][2]).


  [1]: https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf
  [2]: http://www.infoworld.com/article/2609482/data-center/data-center-review-puppet-vs-chef-vs-ansible-vs-salt.html