Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente |
issue139:mon_opinion [2018/12/12 14:20] – d52fr | issue139:mon_opinion [2018/12/15 10:14] (Version actuelle) – andre_domenech |
---|
We will then go over the four pillars: P.A.N.S, Physical, Account, Network and System security. (S.N.A.P).** | 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é. | 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 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). | 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. | **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. |
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. | 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. | 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.** | **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. | 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: | **Let’s look at Physical security: |
| |
Regardons la sécurité physique : | 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. | 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. |
| |
| |
| |
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) ** | 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). |
| |