Ceci est une ancienne révision du document !
As we step into the era of the EU’s General Data Protection Regulation (GDPR), we have to look at security on our Linux boxes with a critical eye. I often hear: “Encrypt everything”. That is a good start, but Linux security is about so much more than encryption. Encryption is not the magic pill to fix all our problems. This month we will take you through some considerations when it comes to security. I will cover a brief introduction, then a quick touch on security guidelines. We will then go over the four pillars: P.A.N.S, Physical, Account, Network and System security. (S.N.A.P).
Alors que dans l'UE, nous entrons dans les temps du RGPD (Règlement général pour la protection des données), nous devons regarder la sécurité sur nos boîtes Linux avec un œil critique. J'ai souvent entendu : « Chiffrez tout ». C'est un bon début, mais la sécurité sous Linux est un eptit peu plus que le chiffrage. Le chiffrage n'est pas une pilule magique qui résout tous nos problèmes. Ce mois-ci, nous allons vous passer en revue certaines considérations qui se font jour à propos de sécurité. Je ferai une courte introduction, puis une approche rapide de la ligne de conduite pour la sécurité.
Ensuite, nous suvolerons quatre piliers : Matériel, Compte, Réseau et Sécurité du système (M.C.R.S.) (souvent désigné comme S.N.A.P, en anglais : System security, Network, Account, Physical).
The foundation of security is in understanding the concepts. I usually end up having to write policies and procedures for quasi-government entities… that they don't follow… but still need to have the paperwork if anyone asks. (Bureaucracy…). I thought it may be a good idea for the wider audience to understand security from our perspective. Linux is considered to be a secure system, but there are a lot of factors that affect this “secure” status. You need to be informed to make good security-conscious decisions. This is where I will help you. I will provide that information. Please don’t assume anything. For an attacker, the holy grail is always root. Root has the power to do anything and everything, so even the mighty file permissions crumble before root. This is also why I always say: never run a service as root (and I see this more than I care to remember). Linux is a multi-user system, use that to your advantage.
Some of the principles I mention here are not just Linux specific; they can be applied in a much broader spectrum. When it comes to software, there is NEED vs. NICE TO HAVE. On a Linux server, if you don't need the software or service, stop it or uninstall it. Do not use the same password for everything, and do not put all your eggs in one basket. What do I mean by that? If your server runs your file sharing, and your web server, and your database, it means that if someone gains access to your web server, they now potentially have access to your files and your database. That means if your log files are stored on that same server, the ‘someone’ who gained access to your server, can delete his tracks. If you store sensitive data, it is a good idea to have multi-level authentication; I say multi-level – because two-factor-authentication is not enough. With the new legislation, you will have to prove that you did everything in your power to secure your data (as I understand it). Do not relax security just because you are behind a firewall or your servers are not directly internet facing. Security is not fire-and-forget either; it is an ongoing process. Lastly, I want to touch on the principle of least privilege. If you need to, then print it on a piece of paper and stick it to the back of your office door. This is an important concept that most places ignore. It is so easy to change the permissions on a file in a web server to 777 when something is not working, and, because your mind is focused on the problem, you forget to change it back. Everyone makes mistakes, we need to make sure they do not.
Let’s look at Physical security: How easy is it to access your servers? When I say physical security, I also mean virtual servers in the cloud. After all, you have to choose your cloud service provider. I am not an advocate of the new hipster server rooms where the server rooms are behind glass in the reception area or common public place. I understand that you paid a lot of good money for it and want to show it off, but I'd rather the public did not even know I had a server room.
No other security matters if someone has access to your servers. ( I will not even go into the ways Linux can be compromised if someone has physical access to your servers.) Ideally, you’d want multiple layers between your servers and the outside world. My general rule of thumb is that no person enters the server room until it can be locked and someone can be held responsible to keep it locked. You want all the work in the server room done before moving the servers in. There is no use in having a locked door when you have to let painters and electricians and general labourers in to work around your servers for the next two weeks. Prioritise. CCTV is another necessity. Do not be penny wise and pound foolish. Years ago, I used to subcontract to the banks; the irony was not lost on me that the cash centres had multiple steel doors and armed guards, while the computer override was operator 20, to which I could get the password from the supervisor and transfer 100 times the money in the cash centre without an eyebrow being raised (if I were that way inclined). Your security is only as strong as its weakest link. Do not skimp on physical security. The current penalty, as per the GDPR, is up to 4% of annual global turnover or €20 Million (whichever is greater). This is the maximum fine that can be imposed for the most serious infringements. Thus adding a lock and maybe biometric scanners is a good start, though your physical security should extend beyond the server room. Virtual servers are not exempt from GDPR regulation, so assess the physical security of your cloud provider. Do not assume your cloud provider measures up, inspect. Should you run afoul of the law, the penalty is heavy. Join us again next issue as we look at the next part of P.A.N.S. (or S.N.A.P – whichever you prefer)