Passer à l’échelle à l’ère de la sécurisation généralisée

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

Lors de la WWDC (Worldwide Developers Conference) d’Apple en juin, le géant du mobile a annoncé qu’à compter du 1er janvier 2017, toutes les applications de l’App Store DEVRAIENT OBLIGATOIREMENT (il s’agit bien du « MUST » au sens des RFC, pour les spécialistes des réseaux qui suivent) utiliser App Transport Security (ATS).

En gros, cela oblige les applications à utiliser HTTPS plutôt que HTTP.

Concrètement, cela signifie qu’il ne leur reste que quelques mois pour :

1. Mettre à jour leurs applications mobiles
   Cela semble évident. Après tout, les applications mobiles sous iOS doivent utiliser le protocole HTTPS. Donc oui, il y a ça.
2. Prendre en charge HTTPS côté serveur
   Cela peut sembler moins évident, mais l’objectif même de HTTPS est de sécuriser les communications, ce qui implique au moins deux parties. Dans le cas des applications mobiles, l’autre partie est une sorte de point de terminaison (application, service, passerelle API), hébergé sur site ou dans le cloud. Celui-ci doit également prendre en charge HTTPS.

C’est cette deuxième exigence qui est plus complexe que la première, tant sur le plan technique qu’opérationnel, car il ne suffit pas d’actionner un interrupteur. Il faut gérer et distribuer les certificats et les clés, effectuer des mises à niveau et modifier la configuration des serveurs web et des passerelles d’API qui ne prenaient auparavant pas en charge HTTPS. Cela peut nécessiter des modifications importantes de l’infrastructure (et de l’architecture). Des changements opérationnels doivent également être apportés, notamment pour surveiller les dates d’expiration des certificats et les remplacer.

À l’ère de la sécurisation généralisée, la mise à l’échelle n’est pas seulement une question de capacité, mais aussi de capacité opérationnelle. La prise en charge d’une infrastructure applicative sécurisée a un impact opérationnel non négligeable. Il ne suffit pas de cocher quelques cases ou d’ajouter un nouveau fichier de configuration.

1. Changements de processus

Si vous « faites du DevOps » (et même si ce n’est pas le cas), vous devez examiner le processus de votre pipeline de déploiement et vous assurer qu’il comprend les composants nécessaires à la prise en charge du protocole HTTPS. Cela signifie que les clés, les certificats et la configuration doivent être intégrés au processus.

2. Changements de gestion

Les certificats expirent. Et lorsque cela arrive, c’est une Mauvaise Chose™. L’équipe d’exploitation doit connaître leur date d’expiration et s’assurer qu’un processus est en place pour les renouveler, puis les déployer (ce qui revient essentiellement à GOTO n° 1 – Changement de processus).

3. Changements de capacité

Le chiffrement et le déchiffrement sont coûteux en ressources de calcul. Même s’ils sont moins gourmands qu’auparavant, les connexions sécurisées consomment toujours davantage de ressources que les connexions non sécurisées. La différence peut être imperceptible pour les applications qui comptent très peu d’utilisateurs. En revanche, pour celles qui sont fortement sollicitées (simultanément), vous devrez déterminer quelles capacités sont disponibles pour effectuer une mise à l’échelle horizontale. Cela concerne non seulement les serveurs (virtuels ou physiques), mais aussi l’infrastructure. Il faut notamment prendre en compte les passerelles API (ou les appareils/systèmes qui en font office) et, éventuellement, les registres de services (si vous utilisez déjà des conteneurs et des microservices).

4. Modifications architecturales

Une connexion sécurisée de bout en bout peut entraver tous les services de sécurité situés entre l’utilisateur et l’application, les rendant pratiquement inutiles pour empêcher des logiciels malveillants ou du code malveillant d’atteindre des applications et des services ayant accès à des données sensibles. La capacité à intercepter les connexions sécurisées et à les inspecter, aussi bien à l’entrée (requête) qu’à la sortie (réponse), constitue un élément important d’une stratégie de sécurité efficace. Des modifications architecturales peuvent être nécessaires pour garantir que les infrastructures de sécurité critiques conservent la visibilité requise pour remplir leur rôle dans la prévention des intrusions et des infections.

Une architecture à deux niveaux, dans laquelle les connexions sécurisées sont gérées par le réseau central, peut atténuer une grande partie des difficultés opérationnelles liées à la dispersion des certificats et des clés dans l’infrastructure applicative. En effet, la connexion sécurisée peut être terminée dans le réseau central par un proxy sécurisé. Les communications avec les applications back-end peuvent rester en texte clair, si nécessaire, ou être chiffrées à nouveau afin de maintenir une communication sécurisée de bout en bout. Les données non chiffrées peuvent être répliquées vers des solutions de sécurité (telles que des systèmes IDS/IPS) pour une inspection approfondie, ce qui permet de préserver les investissements réalisés dans l’infrastructure existante. Les certificats et les clés peuvent ainsi être déployés, gérés et surveillés depuis un emplacement central unique. Cette architecture fournit également un point stratégique sur le chemin de données nord-sud, où l’interception et l’inspection peuvent avoir lieu sans perturber les communications mobile <—> application .

Quoi qu’il en soit, l’impact à grande échelle d’une approche visant à tout sécuriser pour les applications (mobiles ou autres) ne concerne pas seulement les ressources informatiques, mais aussi l’exploitation. Et si Apple est assurément l’un des moteurs de ces changements, l’entreprise n’est pas la seule. Rappelons que, malgré la suppression de l’exigence SSL/TLS pour HTTP/2 dans la norme officielle, les navigateurs web prendront uniquement en charge HTTP/2 via SSL/TLS. Ainsi, à mesure que le Web passe de HTTP/1.x à HTTP/2, l’approche visant à tout sécuriser ne fera qu’étendre sa portée.

Cette évolution continue vers l’élimination de toute forme de communication non chiffrée entre les applications et les utilisateurs (par obligation ou par conception) imposera à certaines organisations des changements importants, tant au niveau des processus que des produits.

À 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