L'échelle à l'ère du « tout sécurisé »

Lors de la WWDC (World Wide Developer Conference) d'Apple en juin, le magnat du mobile a annoncé qu'à compter du 1er janvier 2017, toutes les applications de l'App Store DEVRAIENT (c'est le style RFC qui DOIT pour les réseauteurs qui suivent) utiliser App Transport Security (ATS).

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

Cela signifie que les gens n’ont plus que quelques mois pour :

1. Mettre à jour leurs applications mobiles
   Cela semble évident. Après tout, l’exigence est que les applications mobiles sur iOS utilisent HTTPS. Alors oui, il y a ça.
2. Prise en charge HTTPS sur le backend
   Cela n’est peut-être pas si évident, mais l’objectif du HTTPS est de sécuriser les communications, ce qui implique au moins deux parties impliquées. Dans le cas d'applications mobiles, il s'agit d'une sorte de point de terminaison (application, service, passerelle API) sur site ou dans le cloud. Cela doit également prendre en charge HTTPS.

C’est cette deuxième exigence qui est plus complexe, techniquement et opérationnellement, que la première, car il ne s’agit pas simplement d’appuyer sur un interrupteur. Il existe des fonctionnalités de gestion des certificats et des clés, de distribution, de mises à niveau, de modifications de configuration sur les serveurs Web et les passerelles API qui auparavant ne prenaient pas en charge HTTPS. Des changements importants dans l'infrastructure (et l'architecture) peuvent être nécessaires pour assurer la prise en charge. Il faut ensuite procéder à des changements opérationnels, notamment en surveillant les expirations des certificats et en les remplaçant.

À l’ère du « tout sécurisé », l’évolutivité n’est pas seulement une question de capacité, mais également de capacité opérationnelle. L’impact opérationnel sur la prise en charge d’une infrastructure d’application sécurisée n’est pas négligeable. Il ne s’agit pas simplement de cases à cocher ou d’un nouveau fichier de configuration.

1. Changements de processus

Si vous « faites du DevOps » (ou même si vous ne le faites pas), vous devez examiner votre processus de pipeline de déploiement et vous assurer qu’il inclut les composants nécessaires pour prendre en charge HTTPS. Cela signifie que les clés, les certificats et la configuration doivent être inclus dans le processus.

2. Changements de direction

Les certificats expirent. Et quand ils le font, c’est une mauvaise chose™. Les opérations doivent savoir quand les certificats expireront et s’assurer qu’un processus est en place pour renouveler ces certificats, puis les déployer (ce qui est fondamentalement GOTO #1 – Changement de processus).

3. Changements de capacité

Le chiffrement et le déchiffrement coûtent cher en termes de calcul. Même si elles ne sont plus aussi gourmandes qu’avant, les connexions sécurisées consomment toujours plus de ressources que les connexions non sécurisées. Vous ne verrez peut-être aucune différence notable pour les applications qui ont très peu d’utilisateurs. Mais pour ceux qui sont fortement utilisés (simultanément), vous devrez examiner la capacité disponible pour évoluer. Et pas seulement les serveurs (virtuels ou physiques), mais aussi l’infrastructure. Cela inclut les passerelles API (ou les appareils/systèmes agissant comme des passerelles API) et, potentiellement, les registres de services (si vous utilisez déjà des conteneurs et des microservices).

4. Changements architecturaux

Une connexion sécurisée de bout en bout peut paralyser tous les services de sécurité entre l’utilisateur et l’application, les rendant pratiquement inutiles pour empêcher les logiciels malveillants ou les codes malveillants d’atteindre les applications et les services qui ont accès à des données sensibles. La capacité d’intercepter des connexions sécurisées et de les inspecter – à la fois à l’entrée (requête) et à la sortie (réponse) – est un élément important d’une stratégie de sécurité réussie. Des changements architecturaux peuvent être nécessaires pour garantir que l’infrastructure de sécurité critique continue de bénéficier de la visibilité nécessaire pour jouer son rôle de prévention des brèches 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 associées à la dispersion des certificats et des clés dans l'infrastructure de l'application. C'est parce que la connexion sécurisée peut être interrompue dans le réseau central par un proxy sécurisé. La communication avec les applications back-end peut continuer à être en texte brut, si vous le souhaitez, ou rechiffrée pour maintenir une communication sécurisée de bout en bout. Les données non chiffrées peuvent être mises en miroir vers des solutions de sécurité (comme IDS/IPS) pour une inspection plus approfondie, préservant ainsi l'investissement dans l'infrastructure existante. Cela signifie un emplacement central où les certificats et les clés doivent être déployés, gérés et surveillés. Il fournit également un point stratégique dans le chemin de données NS où l'interception et l'inspection peuvent se produire sans interférer dans les communications mobiles <—> des applications .

Quoi qu’il en soit, l’impact sur l’échelle d’une approche « Secure Everything » pour les applications (mobiles et autres) n’est pas seulement un problème de ressources informatiques, mais également un problème opérationnel. Et même si Apple est certainement l’un des moteurs de ces changements, il n’est pas le seul. N'oubliez pas que malgré l'élimination de l'exigence SSL/TLS pour HTTP/2 de la norme officielle, la communauté des navigateurs Web ne prendra en charge HTTP/2 que sur SSL/TLS. Cela signifie qu'à mesure que de plus en plus de sites Web passent de HTTP/1x à HTTP/2, Secure Everything va simplement continuer à étendre sa portée.

Cette marche continue vers l’élimination de tout type de communication non cryptée entre les applications et les utilisateurs (par décret ou fonctionnalité) nécessitera pour certaines organisations des changements importants dans les processus ainsi que dans les produits.