Contributors mailing list archives
Re: Proposal for new repo - Clouderby
There is a standard, which is about to become a big issue in the following months - the EU General Data Protection Regulation, and the Network and Information Security Directive , which are scheduled to take full effect by mid 2018. With these regulation, every system, that holds personal data, must be properly secured in order to assure the customer data protection. In GDPR, there is no as strict definition, as in the PCI or the ISO 27k standards, but the core security principles are becoming a must for every single merchant holding data - OS & Apps Hardening, Auditing, IDS & Logging.
The Clouder project will be used by businesses, and will store customer data, the majority of the instance running on top of it will need to be GDPR compliant. And GDPR is required for all companies that operate in EU and/or hold EU citizens personal data (Name, ID, address, phone, mail). This means that if you even run a small web-shop/e-commerce site, your infrastructure has to be properly secured, and very important - with “immediate hack/data leak detection”.
The CISecurity benchmarks and some of the PCI compliance points, if implemented, could help a lot. Dockers are great, as they really reduce the attack surface, but the hosts must also be in a top-secured state and provide the auditing infrastructure. In this regard having an orchestration system, which also acts as a "configuration change management" is of great value, as if done right, it ticks multiple compliance standard boxes.
Clouder already has Salt integrated, but the majority of the available CIS benchmark scripts on GitHub are Puppet based. Things like AIDE and Auditd must both work on the host and the container, in order to "tick these boxes” ...
Having said these, I’m not sure of the benefit of keeping clouder containers only, mostly because of the Security Integrity across the entire infrastructure.
On Oct 14, 2016, at 4:53 PM, Dave Lasley <email@example.com> wrote:We might be expanding our scope of this repo a bit too much if we start including Ansible/Chef/Puppet as well. IMO these are related to the underlying server spin-ups & management, and should be contained within a repo of their own. `Infrastructure-inventory` I believe fits this purpose in terms of naming of the inventory files. Alternatively, `infrastructure-configuration` or `infrastructure-puppeteer` may better describe the actions performed by the modules within the repo.