Le contexte est roi

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Objets grand public. Objets professionnels. Objets industriels.

Téléphones. Tablettes. Phablettes. Ordinateurs portables. Ordinateurs de bureau.

Calcul intensif. Réseau intensif. Stockage intensif.

Maison. Travail. Restaurant. Voiture. Parc. Hôtel.

Le paysage évolue des deux côtés de l’activité : applications et clients. Le terme « utilisateur » ne désigne plus seulement un être humain. Il englobe également les systèmes et les objets qui se connectent, partagent des données et interagissent automatiquement avec les applications dans l’ensemble du centre de données.

Prenons, par exemple, la tendance émergente de l’architecture de microservices, qui consiste à décomposer les applications monolithiques en leurs différents composants. Chaque composant constitue un service à part entière et propose une API (interface) par laquelle les autres composants (services) et les « utilisateurs » peuvent communiquer.

Vous ne faites pas partie des 36 % qui s’essaient aux microservices ? (Typesafe, 2015) Vous en tenir à des architectures applicatives éprouvées ne vous protégera pas des effets de la diversité croissante des « utilisateurs », surtout si vous vous lancez dans l’Internet des objets. Nos données indiquent que certains d’entre vous le font : 22 % de l’ensemble des répondants estiment que ce domaine revêtira une importance stratégique au cours des 2 à 5 prochaines années, tandis que 15 % prennent de l’avance en prévoyant d’acheter des technologies compatibles avec l’IoT au cours des 12 prochains mois.

Cela signifie que les « objets » devront être considérés comme des « utilisateurs », avec leurs propres besoins et exigences en matière de sécurité et de performances, sans oublier la disponibilité.

Cela signifie que les services réseau et applicatifs chargés de fournir un éventail d’applications toujours plus diversifié à un nombre croissant de clients, dans des lieux toujours plus nombreux, doivent être capables de faire la distinction entre un utilisateur humain et un objet connecté. Pour optimiser les performances et garantir la sécurité, il est impératif que les services responsables de ces aspects puissent appliquer la bonne politique au bon moment, en fonction de l’ensemble des variables du moment.

Cela signifie qu’ils doivent gérer le trafic (les données et les communications, dans le contexte des applications) en tenant compte de l’ensemble de la transaction : l’utilisateur, l’application et l’objectif de la communication en question.

Vous pouvez envisager le contexte un peu comme on vous a peut-être enseigné (si vous êtes assez âgé — et non, vous n’êtes pas obligé de l’avouer si vous préférez éviter) les cinq questions essentielles à poser lors d’une collecte d’informations de base : qui, quoi, où, quand et pourquoi. En analysant le trafic et en répondant à chacune de ces questions, vous pouvez réunir suffisamment d’éléments contextuels pour prendre une décision appropriée quant au traitement de l’échange. Le refuser. L’autoriser. L’analyser. Le nettoyer. L’optimiser. L’acheminer. Voilà le genre d’opérations que les services applicatifs effectuent « dans le réseau », avec davantage d’efficacité et d’impact lorsqu’ils tiennent compte du contexte de l’échange.

• Qui
  Identifie l’utilisateur. S’agit-il d’un être humain ? Si oui, est-ce un utilisateur professionnel ou un particulier ? S’agit-il d’un objet ou d’une autre application ? Si oui, de quel objet et de quelle application ? Mon ampoule connectée peut avoir accès à une application de reporting de données, mais pas aux systèmes comptables.
• Quoi
  Que font-ils ? Envoient-ils des données ? Demandent-ils des données ? Effectuent-ils une recherche ? HTTP contient une multitude d’informations qui peuvent aider à le déterminer sans avoir à creuser très loin. S’agit-il d’une requête HTTP POST ou GET ? D’une requête UPDATE ou DELETE ? Le statut à lui seul peut nous donner des indices sur l’objectif de cet échange.
• Où
  D’où le font-ils ? Sont-ils chez eux ? Au siège de l’entreprise ? Au Starbucks d’en face ou à l’autre bout du monde ? Sur un réseau local ou via Internet ? La géolocalisation est un moyen couramment utilisé pour restreindre l’accès aux applications, aux ressources et aux données. Lors de la mise à disposition d’applications aux utilisateurs, quel que soit leur type, leur localisation est importante, en particulier si les politiques de l’entreprise interdisent l’accès à certains types de données ou d’applications depuis des lieux publics tels qu’un aéroport ou le Starbucks du quartier.
• Quand
  Quelle heure est-il ? Et surtout, quelle heure est-il ici, ainsi qu’à l’endroit où se trouve l’utilisateur ? Essaie-t-il d’accéder à un système à 3 h depuis un endroit où il est 8 h ? Par exemple, les recherches montrent que le trafic des bots augmente considérablement en dehors des heures de bureau, entre 18 h et 21 h. En recoupant ces données avec celles concernant le « qui », nous pourrions déterminer instantanément qu’il est normal qu’Alice travaille à 3 h lorsqu’elle se trouve au siège de l’entreprise.
• Pourquoi
  Le « pourquoi » s’apparente à une couche 8 inexistante. Il ne peut être déduit qu’à partir du « quoi » et nécessite de recouper des indices issus de données par ailleurs assez élémentaires, comme l’URI (en supposant qu’elle repose sur HTTP, ce qui est aujourd’hui une hypothèse raisonnable). Une fois que nous savons ce qu’ils font, par exemple envoyer des données, nous pouvons chercher à savoir pourquoi ils les envoient. S’agit-il d’une mise à jour de profil ou envoient-ils des données de capteurs ? Effectuent-ils une recherche ou passent-ils une commande ?

Ce sont ces éléments qui constituent le contexte. Il n’est pas forcément nécessaire de les réunir tous les cinq (après tout, ce n’est pas Pokémon) pour pouvoir décider de la marche à suivre. Mais vous devez avoir une visibilité (un accès) sur chacun d’eux, au cas où cela s’avérerait nécessaire. C’est pourquoi la visibilité sur l’ensemble de la pile réseau — des couches 2 à 7 — est si importante pour les services applicatifs. En effet, chacun d’eux peut avoir besoin d’évaluer une requête ou une réponse dans le contexte dans lequel elle a été formulée, et seule une visibilité sur l’ensemble de la pile permet d’accéder à ces informations lorsqu’elles sont nécessaires.

C’est l’un des avantages qu’offre un proxy intelligent : la visibilité nécessaire pour permettre aux architectes (et ingénieurs) réseau, sécurité et infrastructure de mettre en œuvre des politiques qui s’appuient sur le contexte afin de garantir la sécurité, la rapidité et la fiabilité dont tout utilisateur — qu’il s’agisse d’un humain, d’un capteur ou d’un logiciel — a besoin en définitive.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie