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 l'ère du RGPD (Règlement général pour la protection des données), nous devons regarder la sécurité de nos boîtes Linux avec un œil critique. J'entends souvent : « Chiffrez tout ». C'est un bon début, mais la sécurité sous Linux est un petit 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 passer en revue avec vous certaines considérations sur la sécurité. Je ferai une courte introduction, puis une rapide approche de la ligne de conduite pour la sécurité.
Ensuite, nous survolerons 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 affectent cet état de « sécurité ». Vous devez être informés pour prendre les bonnes décisions de sécurité. 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 jamais lancer un service en étant root (et je vois ceci plus souvent que je voudrais 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 des principes que je mentionne ici ne sont pas que pour Linux ; ils peuvent s'appliquer à un spectre beaucoup plus large. Quand on en vient aux logiciels, il y a le BESOIN versus ce qu'on AIMERAIT AVOIR. Sur un serveur Linux, si vous n'avez pas besoin d'un logiciel ou d'un service, arrê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. Si vos fichiers-journaux sont stockés sur ce même serveur, ça signifie que ce « quelqu'un » qui s'est ouvert un accès à votre serveur peut effacer ses traces. Si vous stockez 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 absolument tout fait 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 seule fois ; c'est un processus permanent. Enfin, je voudrais parler du principe du moindre privilège. Au besoin, imprimez-le sur un papier et collez-le 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'elles n'arrivent 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 serveurs sont derrière une vitre à la réception ou dans une zone d'accès public. Je comprends bien que vous ayez payé un bon paquet d'argent pour ça et vous voulez que ça se voit, mais j'aimerais plutôt que le public ne sache jamais qu'il y a une salle de 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)
Aucun autre sujet de sécurité n'a d'importance si tout le monde a accès à vos serveurs. (Je n'irai même pas jusqu'à décrire les façons de compromettre Linux si quelqu'un a un accès physique à vos serveurs.) Idéalement, vous voudriez avoir plusieurs couches entre vos serveurs et le monde extérieur. Ma règle empirique générale est que personne n'entre dans la salle des serveurs jusqu'à ce qu'il soit verrouillé et qe quelqu'un peut être tenu responsable du maintien de son verrouillage. Vous voulez que tout le travail dans la salle des serveurs soit fait avant d'y faire rentrer les serveurs. Il est inutile d'avoir une porte verrouillée si vous devez laisser entrer les peintres et les électriciens et les travailleurs généraux pour travailler autour de vos serveurs pendant les deux prochaines semaines. Priorisez. Un circuit vidéo interne est une autre nécessité. Ne soyez pas avare de vos centimes et dépensier de vos euros. Il y a des années, j'étais souvent sous-contractant pour des banques ; c'était assez ironique parce que les coffres avaient plusieurs portes blindées et des gardes armés, alors que la récupération de l'ordinateur se faisait par l'opérateur 20, à partir duquel je pouvais obtenir le mot de passe de l'administrateur et transférer 100 fois l'argent présent dans le coffre sans que personne ne sourcille (si j'avais été tenté). Votre sécurité n'est pas plus solide que son maillon le plus faible. Ne lésinez pas sur la sécurité physique. L'amende actuelle, avec les RGPD, se monte à 4 % du revenu annuel global ou 20 millions d'euros (selon le montant le plus élevé). C'est l'amende maximum qui peut être appliquée pour les infractions les plus sérieuses. Cela dit, un verrou et peut-être des scanners biométriques sont un bon début, bien que votre sécurité physique doit s'étendre au-delà de la salle des serveurs. Les serveurs virtuels ne sont pas exclus des RGPD ; aussi, vérifiez la sécurité physique de votre fournisseur dans le nuage. Ne supposez pas que votre fournisseur dans le nuage fait ce qu'il faut, inspectez-le. S'il vous arrivait d'enfreindre la loi, la pénalité serait lourde.
Retrouvez-nous dans le prochain numéro pour regarder la partie suivante des S.N.A.P. (ou M.C.R.S., si vous préférez).