Comment prendre le contrôle de votre infrastructure réseau. Chapitre un Rétention

Cet article est le premier d'une série d'articles intitulée «Comment prendre l'infrastructure réseau sous votre contrôle». Le contenu de tous les articles de la série et les liens peuvent être trouvés ici .

J'admets pleinement qu'il existe un nombre suffisant d'entreprises où un simple réseau d'une heure voire d'une journée n'est pas critique. Malheureusement ou heureusement, je n'ai pas eu l'occasion de travailler dans de tels endroits. Mais, bien sûr, les réseaux sont différents, les exigences sont différentes, les approches sont différentes, et pourtant, sous une forme ou une autre, la liste ci-dessous sera dans bien des cas «mast-do».

Donc, les conditions initiales.

Vous êtes dans un nouveau lieu de travail ou vous avez une promotion, ou vous décidez de revoir vos responsabilités. Le réseau d'entreprise est votre domaine de responsabilité. Pour vous, c'est en grande partie un défi et un nouveau, ce qui justifie quelque peu le ton de mentorat de cet article :). Mais j'espère que l'article pourra également être utile à tout ingénieur réseau.

Votre premier objectif stratégique est d'apprendre à résister à l'entropie et à maintenir le niveau de service fourni.

Bon nombre des tâches décrites ci-dessous peuvent être résolues par divers moyens. Je ne soulève pas intentionnellement le sujet de la mise en œuvre technique, car en principe, la manière dont vous avez résolu un problème particulier n'est pas toujours aussi importante, mais la manière dont vous l'utilisez et si vous l'utilisez est importante. Il est peu utile, par exemple, de votre système de surveillance professionnel, si vous n'y regardez pas et ne répondez pas aux alertes.

Équipement

Vous devez d'abord comprendre où sont les plus grands risques.

Encore une fois, cela pourrait être différent. J'admets que quelque part, par exemple, ce seront des problèmes de sécurité, et quelque part des problèmes liés à la continuité du service, et quelque part, peut-être, autre chose. Pourquoi pas?

Supposons pour être certain qu'il s'agit néanmoins d'une continuité de service (ce fut le cas dans toutes les entreprises où j'ai travaillé).

Ensuite, vous devez commencer avec l'équipement. Voici une liste de sujets à surveiller:

• classification de criticité de l'équipement
• redondance des équipements critiques
• support, licences

Vous devez envisager les pannes possibles, en particulier avec des équipements en haut de votre classification de criticité. Habituellement, la probabilité de problèmes doubles est négligée, sinon votre solution et votre support peuvent devenir excessivement coûteux, mais dans le cas d'éléments de réseau vraiment critiques, dont la défaillance peut affecter considérablement l'entreprise, vous devriez y penser.

Exemple

Supposons que nous parlons d'un commutateur racine dans un centre de données.

Puisque nous avons convenu que la continuité de service est le critère le plus important, il est raisonnable de prévoir une «redondance» de cet équipement. Mais ce n'est pas tout. Vous devez également décider combien de temps, en cas de panne du premier interrupteur, il est acceptable que vous viviez avec un seul interrupteur restant, car il existe un risque de rupture.

Important! Vous n'avez pas à résoudre ce problème vous-même. Vous devez décrire les risques, les solutions possibles et la valeur pour votre direction ou la direction de votre entreprise. Ils doivent prendre des décisions.

Donc, s'il a été décidé que, compte tenu de la faible probabilité d'une double panne, travailler pendant 4 heures sur un interrupteur est, en principe, acceptable, alors vous pouvez simplement prendre le support approprié (pour lequel l'équipement sera remplacé dans les 4 heures).

Mais il y a un risque qu'ils ne soient pas livrés. Malheureusement, une fois que nous nous sommes retrouvés dans une telle situation. Au lieu de quatre heures, l'équipement a fonctionné pendant une semaine !!!

Par conséquent, ce risque doit également être discuté, et il serait peut-être plus correct pour vous d'acheter un autre commutateur (troisième) et de le conserver dans des pièces de rechange (sauvegarde à froid) ou de l'utiliser à des fins de laboratoire.

Important! Faites un tableau de tous les supports dont vous disposez avec les dates de fin et ajoutez-les au calendrier afin qu'au moins un mois plus tard, vous receviez une lettre que vous devriez commencer à vous soucier de l'extension du support.

Vous ne serez pas pardonné si vous oubliez d'étendre le support et le lendemain de sa fin, votre équipement tombera en panne.

Travaux d'urgence

Quoi qu'il arrive sur votre réseau, idéalement, vous devez conserver l'accès à votre équipement réseau.

Important! Vous devez avoir un accès console à tous les équipements et cet accès ne doit pas dépendre de l'opérabilité du réseau de transmission de données utilisateur (données).

Vous devez également prévoir les scénarios négatifs possibles et documenter les actions nécessaires. La disponibilité de ce document est critique, il doit donc non seulement être partagé sur une ressource partagée par le service, mais également stocké localement sur des ordinateurs d'ingénieurs.

Il doit y avoir

• informations nécessaires pour ouvrir une application à l'appui d'un fournisseur ou d'un intégrateur
• informations sur l'accès à n'importe quel équipement (console, gestion)

Bien entendu, toute autre information utile peut être contenue, par exemple, une description de la procédure de mise à niveau pour divers équipements et des commandes de diagnostic utiles.

Partenaires

Vous devez maintenant évaluer les risques associés aux partenaires. Habituellement,

• Fournisseurs de services Internet et points d'échange de trafic (IX)
• fournisseurs de canaux de communication

Quelles questions devez-vous vous poser? Comme dans le cas de l'équipement, il est nécessaire d'envisager diverses options pour les situations d'urgence. Par exemple, pour les fournisseurs de services Internet, cela pourrait être quelque chose comme:

• Que se passera-t-il si le FAI X cesse de vous fournir un service pour une raison quelconque?
• Avez-vous suffisamment de bande passante pour les autres fournisseurs?
• quelle sera la cohérence?
• Dans quelle mesure vos FAI sont-ils indépendants et un accident grave dans l'un d'eux entraînera-t-il des problèmes avec les autres?
• combien d'entrées optiques dans votre centre de données?
• Que se passe-t-il si l'une des entrées est complètement détruite?

En ce qui concerne les intrants, dans ma pratique dans deux sociétés différentes, dans deux centres de données différents, l'excavatrice a détruit les puits et ce n'est que par miracle que notre optique n'a pas été affectée. Ce n'est pas un cas si rare.

Eh bien, bien sûr, vous devez non seulement poser ces questions, mais, encore une fois, avec le soutien des dirigeants, pour fournir une solution acceptable dans toutes les situations.

Sauvegarde

La prochaine priorité peut être une sauvegarde des configurations matérielles. En tout cas, c'est un point très important. Je ne vais pas énumérer les cas où vous pouvez perdre la configuration, il est préférable de faire une sauvegarde régulière et de ne pas y penser. De plus, une sauvegarde régulière peut être très utile pour contrôler les modifications.

Important! Faites une sauvegarde quotidiennement. Ce n'est pas une si grande quantité de données à économiser. Le matin, l'ingénieur de service (ou vous) devrait recevoir un rapport du système qui indique clairement si la sauvegarde a réussi ou non, et en cas de sauvegarde infructueuse, le problème doit être résolu ou un ticket doit être créé (voir les processus du service réseau).

Version du logiciel

La question de la mise à niveau ou non du logiciel matériel n'est pas aussi claire. D'une part, les anciennes versions sont des bogues et des vulnérabilités connues, mais d'autre part, les nouveaux logiciels ne sont pas, d'une part, toujours une procédure de mise à niveau indolore, et d'autre part, de nouveaux bogues et vulnérabilités.

Ici, vous devez trouver la meilleure option. Quelques recommandations évidentes

• uniquement des versions stables
• Pourtant, vous ne devriez pas vivre sur de très anciennes versions de logiciels
• faire un signe avec des informations où n'importe quel logiciel est
• lire régulièrement des rapports sur les vulnérabilités et les bogues dans les versions logicielles, et en cas de problèmes critiques, il vaut la peine de penser à une mise à niveau

À ce stade, ayant accès à l'équipement depuis la console, les informations de support et une description de la procédure de mise à niveau, vous êtes, en principe, prêt pour cette étape. L'option idéale est lorsque vous disposez d'un équipement de laboratoire où vous pouvez vérifier l'ensemble de la procédure, mais, malheureusement, cela ne se produit pas souvent.

Dans le cas d'un équipement critique, vous pouvez contacter le support du fournisseur avec une demande pour vous aider avec la mise à niveau.

Système de ticket

Vous pouvez maintenant regarder autour de vous. Vous devez établir des processus d'interaction avec les autres départements et au sein du département.

Ce n'est peut-être pas obligatoire (par exemple, si votre entreprise est petite), mais je recommanderais fortement d'organiser le travail de manière à ce que toutes les tâches externes et internes passent par le système de ticket.

Un système de ticket est essentiellement votre interface pour les communications internes et externes, et vous devez décrire cette interface avec un degré de détail suffisant.

Prenons un exemple d'une tâche importante et fréquemment rencontrée d'ouverture d'accès. Je vais décrire un algorithme qui a très bien fonctionné dans l'une des entreprises.

Exemple

Pour commencer, les clients d'accès expriment souvent leur désir dans un langage incompréhensible pour un ingénieur réseau, à savoir, dans le langage de l'application, par exemple, «donnez-moi accès à 1C».

Par conséquent, nous n'avons jamais accepté les demandes directement de ces utilisateurs.
Et c'était la première exigence

• les demandes d'accès doivent provenir des services techniques (dans notre cas, il s'agissait d'unix, windows, helpdesk)

La deuxième exigence est que

• cet accès doit être enregistré (par le service technique duquel nous avons reçu cette demande) et en tant que demande, nous obtenons un lien vers cet accès enregistré

La forme de cette demande doit être claire pour nous, c'est-à-dire

• la demande doit contenir des informations sur les accès et sous-réseaux qui doivent être ouverts, ainsi que sur le protocole et les ports (dans le cas de tcp / udp)

Il faut également indiquer

• description des raisons pour lesquelles cet accès est ouvert
• temporaire ou permanent (si temporaire, jusqu'à quelle date)

Et un point très important est

• du chef du département qui a initié l'accès (p. ex. comptabilité)
• du chef du service technique, d'où cette demande est venue au service réseau (par exemple, helpdesk)

Dans le même temps, le «propriétaire» de cet accès est considéré comme le chef du département qui a initié l'accès (comptabilité dans notre exemple), et il est responsable de la mise à jour de la page avec accès enregistré pour ce département.

Journalisation

C'est quelque chose à noyer. Mais si vous souhaitez mettre en œuvre une approche proactive, vous devez apprendre à gérer ce flux de données.

Voici quelques suggestions pratiques:

• afficher les journaux dont vous avez besoin quotidiennement
• dans le cas d'une visualisation planifiée (et non d'une urgence), vous pouvez vous limiter à des niveaux de gravité de 0, 1, 2 et ajouter vos modèles préférés à partir d'autres niveaux si vous le jugez nécessaire
• écrire un script qui analyse les journaux et ignore les journaux dont vous avez ajouté les modèles à la liste d'ignorance

Cette approche permettra au fil du temps de compiler une liste des journaux qui ne vous intéressent pas et de ne laisser que ceux que vous considérez vraiment importants.
Cela a très bien fonctionné pour nous.

Suivi

Il n'est pas rare qu'une entreprise ne dispose pas d'un système de surveillance. Vous pouvez, par exemple, compter sur les journaux, mais l'équipement peut simplement "mourir" sans avoir à "dire" quoi que ce soit, ou le package de protocole udp syslog peut être perdu et ne pas atteindre. En général, bien sûr, une surveillance active est importante et nécessaire.

Deux exemples les plus demandés dans ma pratique:

• surveiller le chargement des canaux de communication, les liens critiques (par exemple, la connexion aux fournisseurs). Ils vous permettent de voir de manière proactive le problème potentiel de dégradation des services dû à la perte de trafic et, par conséquent, de l'éviter.
• Graphes basés sur NetFlow. Ils permettent de détecter facilement les anomalies de trafic et sont très utiles pour détecter certains types d'attaques de pirates simples mais importants.

Important! Configurez la notification sms pour les événements les plus critiques. Cela s'applique à la fois à la surveillance et à la journalisation. Si vous n'avez pas de quart de travail, alors les SMS devraient également arriver après les heures.

Pensez au processus de manière à ne pas réveiller tous les ingénieurs. Nous avions un ingénieur de service pour cela.

Changer le contrôle

À mon avis, il n'est pas nécessaire de contrôler tous les changements. Mais, dans tous les cas, vous devriez être en mesure, si nécessaire, de trouver facilement qui et pourquoi ont effectué ces modifications ou d'autres dans le réseau.

Quelques conseils:

• utiliser le système de ticket pour une description détaillée de ce qui a été fait dans le cadre de ce ticket, par exemple, copier la configuration appliquée sur le ticket
• Utilisez les capacités de commentaire sur le matériel réseau (par exemple, validez le commentaire sur Juniper). Vous pouvez enregistrer le numéro de ticket
• utiliser diff de vos sauvegardes de configuration

Vous pouvez entrer cela comme un processus en parcourant tous les tickets quotidiennement pour les changements.

Les processus

Vous devez formaliser et décrire les processus dans votre équipe. Si vous avez atteint ce point, alors au moins les processus suivants devraient déjà fonctionner dans votre équipe:

Processus quotidiens:

• travailler avec des billets
• travailler avec des journaux
• contrôle du changement
• feuille de vérification quotidienne

Processus annuels:

• extension des garanties, licences

Processus asynchrones:

• réponse à diverses urgences

Conclusion de la première partie

Vous avez remarqué que tout cela ne concerne pas la configuration réseau, la conception, les protocoles réseau, le routage ou la sécurité ... C'est quelque chose autour. Mais ceux-ci, bien que peut-être ennuyeux, mais, bien sûr, des éléments très importants de l'unité de réseau.

Jusqu'à présent, comme vous le voyez, vous n'avez rien amélioré sur votre réseau. S'il y avait des failles de sécurité, alors elles restaient; s'il y avait une mauvaise conception, alors elle restait. Jusqu'à ce que vous appliquiez vos compétences et vos connaissances d'un ingénieur réseau, qui a probablement dépensé beaucoup de temps, d'efforts et parfois d'argent. Mais vous devez d'abord créer (ou renforcer) la fondation, puis faire la construction.

Les parties suivantes expliquent comment rechercher et corriger les erreurs, puis améliorer votre infrastructure.

Bien sûr, il n'est pas nécessaire de tout faire séquentiellement. Le temps peut être critique. Faites en parallèle si les ressources le permettent.

Et un ajout important. Communiquez, demandez, consultez votre équipe. Au final, c'est à eux de soutenir et de faire tout cela.