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.
Le fondement de la sécurité est dans la compréhension de ses concepts. Je finis habituellement en écrivant des règles et des procédures pour des entités quasi-gouvernementales …. qui ne les suivent pas … mais qui ont le document papier si quelqu'un le demande. (Bureaucratie)… J'avais pensé que ce serait une bonne idée pour une audience élargie de comprendre la sécurité de notre point de vue.
Linux est considéré comme un système sûr, mais il existe de nombreux facteurs qui affecte cet état de « sécurité ». Vous devez être informés pour prendre les bonnes décisions de sécurité en pleine conscience. C'est ici que je vous aiderai. Je fournirai cette information. S'il vous plaît, pas de présupposé. Pour un assaillant, le saint Graal est toujours root. Root a le pouvoir de tout faire et partout ; ainsi, même les redoutables permissions de fichiers s'inclinent devant root. C'est la raison pour laquelle je dis toujours : ne lancer un service en étant root (et je vois ceci plus que je ne peux m'en rappeler). Linux est un système multi-utilisateur ; utilisez-le à votre avantage.
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.
Certains de principes que je mentionne ici ne sont pas que pour Linux ; ils peuvent s'appliquer à spectre beaucoup plus large. Quand on en vient au logiciel, il y a le BESOIN versus ce qu'on AIMERAIT AVOIR. Su un serveur Linux, si vous n'avez pas besoin d'un logiciel ou d'un service, apprêtez-le ou désinstallez-le. N'utilisez pas le même mot de passe pour tout et ne mettez pas tous vos œufs dans le même panier. Qu'est-ce que j'entends par là ? Si votre serveur fait tourner votre partage de fichiers, ou votre serveur Web, et votre base de données, ça signifie que si quelqu'un obtient un accès à votre serveur Web, il pourrait alors avoir accès à vos fichiers et à votre base de données. 9a signifie que si vos fichiers-journaux sont stockés sur ce même serveur, ce « quelqu'un » qui s'est ouvert un accès à votre serveur peut effacer ses traces. Si vous stocké des données sensibles, c'est une bonne idée d'avoir une authentification à plusieurs niveaux ; je dit multi-niveau - parce que l'authentification à deux facteurs n'est pas suffisante. Avec la nouvelle législation, vous devez pouvoir prouver que vous aviez tout fait ce qui était en votre pouvoir pour sécuriser vos données (tel que je le comprends). Ne relâchez pas votre sécurité simplement parce que vous êtes derrière un pare-feu ou que vos serveurs ne sont pas directement reliés à Internet. La sécurité n'est pas non plus quelque chose qu'on ne fait qu'une fois ; c'est un processus permanent. Enfin, je voudrais parler du principe du moindre privilège. Au besoin, imprimez-le sur un papier et coller-la au dos de la porte de votre bureau. C'est un principe important qui est ignoré à de très nombreux endroits. Il est tellement facile de modifier les permissions d'un fichier en 777 sur un serveur Web quand quelque chose ne marche pas ; et, parce que votre esprit est focalisé sur le problème, vous oubliez de le re-modifier. Tout le monde fait des erreurs ; nous devons être sûrs qu'ils n'en font pas.
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.
Regardons la sécurité physique : Est-il est facile d’accéder à vos serveurs ? Quand je dis sécurité physique, je pense aussi aux serveurs virtuels dans le nuage. Après tout, vous devez choisir votre fournisseur de services dans le nuage. Je ne suis pas l'avocat de cette nouvelle tendance des salles de serveurs où les salles de serveur sont derrière une vitre à la réception ou dans une zone d'accès public. Je comprend bien que vous payez un bon paquet d'argent pour ça et vous voulez que ça se voit, mais je crois que le public n'a même jamais su qu'il y avait une salle des serveurs.
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)