Différences

Ci-dessous, les différences entre deux révisions de la page.

--- issue153:mon_opinion1 [2020/02/04 11:14] – auntiee
+++ issue153:mon_opinion1 [2020/02/04 12:05] – auntiee
@@ Ligne 15: / Ligne 15: @@
 Si vous êtes complètement occupé en essayer de faire tourner vos conteneurs exactement comme vous voulez, il est facile d'oublier le fait que vous devriez d'abord accorder une attention particulière à la machine hôte sur laquelle ces conteneurs-là tournent. Il est évident que les sécurité de l'hôte sur lequel comptent vos conteneurs détermine combien de temps actif vous aurez pour les applications et, de plus, affecte le nombre de menaces qui pourrait vous causer des problèmes.
-Les règles habituelles s'appliquent quand il s'agit de vos machines hôte. Vous devrez mettre à jour les paquets dès la disponibilité d'une mise à jour, probablement replanifier les redémarrages pour les mises à jour du noyaut et également vous assurer que nombre minimal de paquets soient installé pour limiter la surface d'attaque.
+Les règles habituelles s'appliquent quand il s'agit de vos machines hôte. Vous devrez mettre à jour les paquets dès la disponibilité d'une mise à jour, probablement replannifier les redémarrages pour les mises à jour du noyaut et également vous assurer que nombre minimal de paquets soient installé pour limiter la surface d'attaque.
-Outre les mises à jour des paquets, bien connues, vous devraiez vous assusrer que uniquement des ports réseaux spécifiques soient exposés, localement et publiquement, puis mettre un pare-feu sur tous les autres points d'accès à un réseau. Là où c'est possible, je vous conseille de limiter l'accès aux applications et surveiller dans le détail les accès via des ports réseau publics.
+Outre les mises à jour des paquets, bien connues, vous devriez vous assurer que des seuls ports réseaux spécifiques soient exposés, localement et publiquement, puis mettre un pare-feu sur tous les autres points d'accès à un réseau. Là où c'est possible, je vous conseille de limiter l'accès aux applications et surveiller dans le détail les accès via des ports réseau publics.
 **Limiting Crosstalk
@@ Ligne 35: / Ligne 35: @@
 La sécurité d'un autre domaine peut être prise en charge de façon significative avec un peu de sens commun et de la logique.
-Supposez, par exemple, que vous avez trois conteneurs sur un seul hôte, chacun avec une application unique qui fournit un service quelconque. Je vous conseille de réflechir soigneusement à la façon dont ces conteneurs pourraient interagir du point de vue de l'architecture. Si le Conteneur A n'envoie des données qu'au Conteneur B, le Conteneur C n'a pas du tout besoin d'un accès direct au Conteneur A et devrait être isolé à la fois au niveau de l'hôte et au niveau du réseau interne.
+Supposez, par exemple, que vous avez trois conteneurs sur un seul hôte, chacun avec une application unique qui fournit un service quelconque. Je vous conseille de réfléchir soigneusement à la façon dont ces conteneurs pourraient interagir du point de vue de l'architecture. Si le Conteneur A n'envoie des données qu'au Conteneur B, le Conteneur C n'a pas du tout besoin d'un accès direct au Conteneur A et devrait être isolé à la fois au niveau de l'hôte et au niveau du réseau interne.
-Examinons un autre sénario où vous pourriez avoir deux serveurs Web en avant-plan qui tournent grâce à deux conteneurs et, aussi, un seul serveur de données en arrière-plan. Les serveurs en avant-plan envoie des requêtes re lecture et de l'écriture à la base de données et le TCP port 443 est le seul qui doit être exposé au public de la perspective du réseau.
+Examinons un autre scénario où vous pourriez avoir deux serveurs Web en avant-plan qui tournent grâce à deux conteneurs et, aussi, un seul serveur de données en arrière-plan. Les serveurs en avant-plan envoie des requêtes re lecture et de l'écriture à la base de données et le TCP port 443 est le seul qui doit être exposé au public de la perspective du réseau.
-Il y a cependant des foules d'autres conteneurs qui tournent sur la même machine hôte qui ne devraient avoir aucune visibilité du traffic potentiellement sensible passant au travers du serveur de la base de données avant d'être écrit et stocké en dehors du conteneur. Ici, je conseillerais d'utiliser un réseau de passerelles. En connectant  seulement les deux serveurs Web et l'unique serveur de la base de données à ce réseau privé, nous réussirons à limiter l'accès réseau et fournirons une couche d'isolation.
+Il y a cependant des foules d'autres conteneurs qui tournent sur la même machine hôte qui ne devraient avoir aucune visibilité du trafic potentiellement sensible passant au travers du serveur de la base de données avant d'être écrit et stocké en dehors du conteneur. Ici, je conseillerais d'utiliser un réseau de passerelles. En connectant  seulement les deux serveurs Web et l'unique serveur de la base de données à ce réseau privé, nous réussirons à limiter l'accès réseau et fournirons une couche d'isolation.
 Cela signifie que, si un autre conteneur sur l'hôte est attaqué et compromis, il y a plus de couches de sécurité qu'un attaquant devrait franchir pour avoir accès aux données de la base de données.
@@ Ligne 55: / Ligne 55: @@
 Les vulnérabilités communes
-Locking Down Access
+Les CVE (Common Vulnerabilities and Exploits) tant redoutés s'appliquent aux mises à jour de paquets, comme nous venons de le voir sur le système d'exploitation de l'hôte et vous devriez surveiller les CVE avec divers outils.
+L'approche de la mise à jour de paquets dans vos conteneurs est tout à fait autre chose. Un nombre d'approches convenables existent, mais il vous faut une stratégie qui, pourtant, est souvent rejetée comme étant traviale. Ainsi, les pratiques de correctifs ad hoc peuvent devenir dangereusement erratiques, parce que même les images très populaires de conteneur contiennent au mieux un nombre étonnant de CVE. En fait, les vendeurs ne rendent pas toujours disponible des correctifs pour beaucoup de paquets au moment où un conteneur est créé et potentiellement exposé au public, ce qui signifient qu'appliquer des correctifs est presque impossible.
+La recommandation est de bien réfléchir aux risques qui vous affectent le plus. Prenez le temps de comprendre pleinement vos priorités ainsi que les surfaces d'attaque qui vous présentez à l'interne comme à l'externe. Ensuite, décidez dans quelle mesure la mise à jour de chaque paquets pour des alertes déclenchés est réaliste et à quelle fréquence. Choisir un outil qui peut vous alerter automatiquement à des mises à jour de logiciels peut être décourageant, car il n'y en a que quelques-uns. Un outil sophistiqué, qui peut tourner à l'intérieur des conteneurs, s'appelle Anchore et se trouve ici (https://anchore.com/opensource).
+Comme mentionné tous les problèmes des CVE ne peuvent pas être mitigés en utilisant les mise à jour proposée par le gestionnaire des paquets, parce que les correctifs n'ont pas été publiés par les vendeurs. Des compromis entre l'utilisation de systèmes d'exploitations alternatifs et l'utilisation d'applications alternatives peuvent s'avérer nécessaire de temps en temps.
+**Locking Down Access
 As all containers share the same host kernel on a machine, it’s imperative that suitable isolation is put in place to protect the host. Without the host functioning correctly, ultimately there’s only downtime which means failure to stop a successful attack on one container from performing a “container escape” will mean that other containers, and their applications, or even the host itself, might succumb to the attack.
@@ Ligne 65: / Ligne 73: @@
 You might want to also read up on Kernel Capabilities – which can achieve all sorts of useful access restrictions. For example, do you really want a container to be able to change the time and date on your host’s system clock? It’s unlikely!
-Although we’ve just scratched the surface on this topic, you should also make sure that lesser privileged users can’t start and stop containers with permissions that an attacker can do bad things with. Leave that sort of thing to the “root” superuser alone.
+Although we’ve just scratched the surface on this topic, you should also make sure that lesser privileged users can’t start and stop containers with permissions that an attacker can do bad things with. Leave that sort of thing to the “root” superuser alone.**
+Verrouiller l'accès
+Puisque tous les conteneurs sur une même machine partage le noyau de l'hôte, il est essentiel pour sa protection que l'hôte soit convenablement isolé. Si l'hôte ne fonctionne pas correctement, à la longue il n'y a que des temps d'arrêt ce qui signifie qu'une attaque réussie sur un conteneur n'est pas empêchée et que celui-là peut « s'évader », ce qui, à son tour, signifiera que les autres conteneurs, et leurs applications, ou même l'hôte lui-même pourraient succomber à l'attaque.
+Au fil des ans, le noyau Linux a introduit de nombreuses techniques astucieuses d'isolation que nous n'examinerons pas en détail ici.
+Toutefois, vous devriez connaître les Kernel Namespaces, qui signifient que, si tout se passe bien d'une perspective sécuritaire, Client A ne peut pas voir ce ue fait Client B. De plus, vous devriez connaître les Control Groups,
 Orchestration