Ajouter la sécurité à une solution en fin de cycle de conception et de développement entraîne souvent des remaniements coûteux et des sacrifices d’ergonomie qui nuisent à la capacité et à l’expérience utilisateur de la solution. Concevoir des solutions sécurisées dès le départ permet d’assurer un équilibre approprié entre utilisabilité, interopérabilité, résilience et sécurité pour la solution finale.

La sécurité dès la conception est le principe selon lequel les pratiques de conception, de développement et de livraison d’un projet doivent inclure des pratiques de sécurité et de conformité fournies par une équipe compétente et expérimentée. Les principes de conception de la sécurité, tels que ceux qui suivent, guident les pratiques de réflexion architecturale.

Le processus de conception doit commencer par l’utilisation du design thinking d’entreprise afin de se concentrer sur les résultats utilisateurs requis des parties prenantes en matière de risque, de conformité et de sécurité, qu’elles soient internes ou externes à une organisation. Les parties prenantes externes incluent les clients, les gouvernements et les régulateurs. Les parties prenantes internes comprennent les responsables de la gestion des risques, de la conformité et de la sécurité.

Le processus de conception continue avec une réflexion architecturale pour définir les caractéristiques architecturales, la décision architecturale, l’architecture fonctionnelle et le modèle de déploiement cloud. La définition des caractéristiques, telles que la résilience, la performance et l’évolutivité, est ensuite finalisée pour les services de sécurité.

Une fois les exigences et l’architecture définies, l’ingénierie des fonctionnalités et de l’infrastructure de sécurité peut avoir lieu, notamment en suivant le principe de sécurité par défaut.

IBM applique depuis longtemps une approche de sécurité et de confidentialité intégrée dès la conception de ses produits. Il est utile de consulter la publication IBM Redpaper sur la Sécurité en développement : le cadre d’ingénierie sécurisée d’IBM.

Lorsque les utilisateurs ou les logiciels d’un système disposent de privilèges excessifs, il existe un risque d’utilisation abusive, accidentelle ou délibérée. Les acteurs de la menace peuvent compromettre les comptes privilégiés des utilisateurs internes et utiliser leurs droits pour parcourir le réseau et les systèmes.

Le principe du moindre privilège stipule que le système doit donner aux utilisateurs ou aux logiciels le minimum de capacités nécessaires pour accomplir la tâche prévue. Le système doit le mettre en œuvre depuis le niveau le plus élevé d’une application jusqu’à une connexion individuelle entre deux composants logiciels.

Pour mettre en œuvre le principe du moindre privilège, vous devez comprendre les actifs de votre environnement informatique dynamique. L’accès privilégié n’est pas seulement un problème humain ; vous devez savoir quelles applications ont accès à quelles données. Le processus de découverte, de classification et d’évaluation des risques est continu. Rassemblez les données de risque de vos actifs numériques pour découvrir de nouvelles informations sur les risques au niveau de l’entreprise et vous aider à établir les bonnes politiques.

Un utilisateur ou un logiciel peut disposer d’un contexte sécurisé au moment de l’identification et de l’authentification initiales pour une session, mais un acteur de la menace peut compromettre la session active et l’utiliser pour compromettre davantage un système.

La vérification continue est le principe selon lequel un utilisateur ou un logiciel doit être constamment vérifié pour évaluer s’il dispose toujours d’un contexte sécurisé. L’objectif de la vérification continue est de détecter les problèmes de sécurité et les vulnérabilités le plus tôt possible, et dans l’idéal avant les acteurs de la menace.

La vérification continue permet de confirmer que les entités sont ce qu’elles prétendent être en utilisant des défis, comme une demande d’authentification à deux facteurs. Un workload peut nécessiter une mise à jour pour prendre en charge la vérification continue des utilisateurs et des logiciels à l’aide de solutions utilisant une architecture de réseau Zero Trust (ZTNA). Les entreprises axées sur la fourniture d’expériences de premier ordre hésitent à perturber l’utilisateur avec des requêtes inutiles ; cependant, ce niveau d’assurance d’identité est critique pour la sécurité Zero Trust.

Un acteur de la menace a peut-être déjà réussi à s’introduire dans une entreprise. Si celle-ci se contente de rechercher les menaces au niveau de la périphérie externe sans tenir compte de celles qui ont utilisé un mécanisme valide pour contourner les contrôles qui s’y trouvent, la violation peut rester longtemps sans être détectée.La présomption de violation est le principe selon lequel une entreprise considère qu’une intrusion a été commise par un acteur de la menace.

L’approche requiert que la gestion des menaces soit complétée par une détection interne proactive, la recherche de signes d’alerte précoce, la traque des menaces et l’utilisation de dossiers d’exploitation éprouvés. La détection et la réponse doivent être étroitement intégrées aux couches d’informations et d’application, partageant le contexte et ajustant de façon dynamique les politiques de contrôle d’accès en réponse aux menaces identifiées.

Un système d’information présente des vulnérabilités au niveau du logiciel, du microprogramme et du matériel. Les configurations et les logiciels changeront, et de nouvelles vulnérabilités apparaîtront. Si une couche de défense est vulnérable, le système doit rester sécurisé.

La défense en profondeur est le principe selon lequel un système possède plusieurs couches de défense, de sorte qu’en cas de défaillance de l’une d’elles, une autre reste en place pour protéger les données sensibles du système. L’utilisation d’une approche multicouche pour une stratégie de sécurité garantit qu’une organisation est en mesure d’arrêter un attaquant à une couche supérieure lors de la violation d’une couche de défense.

La stratégie de sécurité d’entreprise et l’architecture doivent inclure des mesures qui offrent une protection de l’ensemble des couches suivantes du modèle de réseau informatique traditionnel. En règle générale, une entreprise doit planifier la sécurité au niveau le plus élémentaire (sécurité au niveau du système) jusqu’au plus complexe (sécurité au niveau de la transmission).

La surface d’attaque d’une entreprise est l’ensemble des vulnérabilités, des chemins et des méthodes, ou vecteurs d’attaque, que les acteurs de la menace peuvent utiliser pour obtenir un accès non autorisé au réseau ou aux données sensibles, ou encore pour mener une cyberattaque. Au fur et à mesure que les entreprises cumulent services cloud et modèles de travail hybrides (sur site/télétravail), leurs réseaux et les surfaces d’attaque associées s’agrandissent et deviennent de plus en plus complexes.

Minimiser la surface d’attaque est le principe selon lequel un système doit réduire la portée des vecteurs d’attaque pour restreindre les moyens par lesquels un acteur de la menace peut y accéder. Les experts en sécurité décomposent la surface d’attaque en trois parties : la surface d’attaque numérique, la surface d’attaque physique et la surface d’attaque d’ingénierie sociale.

1. La surface d’attaque numérique rend l’infrastructure cloud et sur site de l’entreprise potentiellement accessible à tout acteur de la menace disposant d’une connexion Internet. Les vecteurs d’attaque les plus courants incluent l’accès au réseau, les vulnérabilités logicielles, l’activation de ressources inutilisées, le shadow IT et les logiciels obsolètes.

2. La surface d’attaque physique expose les actifs et les informations généralement accessibles uniquement aux utilisateurs autorisés à accéder aux appareils et périphériques de l’entreprise. Cela inclut les attaques par initiés malveillants, le vol d’appareils et l’appât, une attaque qui consiste pour les acteurs de la menace à laisser dans un lieu public une clé USB infectée par un logiciel malveillant que les utilisateurs pourront télécharger à leur insu en branchant le périphérique sur leur ordinateur.

3. L’attaque d’ingénierie sociale vise à manipuler les individus pour qu’ils communiquent des informations confidentielles, qu’ils téléchargent des logiciels malveillants, qu’ils se rendent sur des sites Web dangereux, qu’ils envoient de l’argent à des criminels ou qu’ils commettent d’autres erreurs qui compromettent leurs actifs ou sécurité personnels ou ceux de leur organisation.

Une entreprise doit évaluer le risque pour les données sensibles traitées par le système en examinant chacune de ces surfaces d’attaque.

Les utilisateurs pourraient avoir accès à des données hautement sensibles permettant de contourner les contrôles, comme les clés de chiffrement, ou avoir le droit d’effectuer des actions hautement privilégiées, comme transférer d’importantes sommes d’argent. Même si un système surveille les utilisateurs, ceux-ci peuvent abuser de leurs droits, ce qui peut avoir des conséquences catastrophiques pour l’entreprise.

La séparation des tâches est le principe selon lequel les utilisateurs ayant un accès puissant à des données ou à des actions ont besoin de plus d’un utilisateur pour réaliser l’action. Elle permet à une entreprise de répartir les fonctions administratives entre plusieurs personnes sans que les responsabilités ne se chevauchent, de sorte qu’un seul utilisateur ne dispose pas d’une autorité illimitée.

Dans le cas d’activités telles que la gestion des clés de chiffrement, l’entreprise exigera des administrateurs qu’ils gèrent différentes parties d’une clé, de sorte qu’aucun administrateur n’ait connaissance de l’ensemble de la clé. En ce qui concerne les transactions commerciales, l’application peut obliger la personne qui demande une transaction à avoir un ou plusieurs approbateurs pour l’exécuter.

Dans certains secteurs, un organisme de réglementation peut exiger la séparation des tâches pour les fonctions importantes dans le cadre des orientations réglementaires. La séparation des tâches aide les entreprises à se conformer aux réglementations gouvernementales et simplifie la gestion des autorités.

Les produits ou services comportent de nombreux points de configuration différents et il est souhaitable de les rendre aussi faciles à utiliser que possible. Par conséquent, le produit présente une configuration de sécurité non sécurisée, avec par exemple des ports réseau ouverts ou des mots de passe faciles à mémoriser.

La sécurité par défaut est le principe selon lequel une entreprise reçoit des produits ou des services configurés en état sécurisé dès leur installation. Les produits sont configurés pour protéger contre les menaces et les vulnérabilités les plus répandues sans que les utilisateurs finaux aient à prendre des mesures supplémentaires pour les sécuriser.

Un système peut être configuré de manière sécurisée au début, mais un développeur peut ensuite modifier la configuration ou un acteur de la menace peut apporter un changement via une vulnérabilité qui compromet le système.

La conformité continue est le principe selon lequel la configuration de sécurité du système est constamment vérifiée, en commençant par le développement du système jusqu’à son fonctionnement continu. L’objectif de la conformité continue est de détecter les problèmes de sécurité et les vulnérabilités avant que les acteurs de la menace ne le fassent.

Dans l’idéal, les contrôles de conformité sont tous automatisés et couvrent toutes les configurations de sécurité, y compris la plateforme cloud, la plateforme de conteneurs, le middleware et les images de calcul telles que les serveurs virtuels et les conteneurs. Avec les images de calcul, une meilleure approche peut être d’utiliser l’infrastructure en tant que code (IaC) pour remplacer régulièrement l’image entière.

Les responsabilités partagées pour la sécurité et la conformité dans un environnement de cloud hybride dépendent des modèles de service, des plateformes de calcul et des fournisseurs de services cloud utilisés par le workload ou l’application. Un architecte de sécurité doit documenter et communiquer les responsabilités couvrant la conception, l’élaboration et l’exploitation des services de sécurité. Sans clarté, la sécurité de la solution peut présenter des lacunes.

Chaque dimension a un impact différent sur les responsabilités partagées :

• Modèle de service cloud - La définition NIST du cloud computing prévoit des responsabilités différentes selon le modèle de service cloud, tel que IaaS, PaaS, SaaS ou cloud distribué. Les services de sécurité font partie des responsabilités partagées. Par exemple, les responsabilités partagées pour IBM Cloud incluent la gestion des identités et des accès, ainsi que la sécurité et la conformité réglementaire. Les responsabilités partagées pour ces catégories varient selon le modèle de service cloud.
   

• Plateforme de calcul - L’hébergement d’un workload peut être une ou plusieurs plateformes de calcul, telles que des Bare Metal Servers, des virtual servers, des plateformes de conteneurs et des plateformes sans serveur. Chaque plateforme de calcul a un ensemble différent de responsabilités partagées. Par exemple, les Bare Metal Servers exigent que le propriétaire du workload soit responsable de tous les contrôles de sécurité sur la plateforme, à l’exception du matériel physique et de l’Intégration au réseau.
   

• Fournisseur de services cloud - Les responsabilités varient également selon le fournisseur de services cloud. Par exemple, les plateformes Kubernetes de chaque fournisseur de service cloud sont différentes (sauf si vous utilisez Red Hat OpenShift), car chacune se compose d’un ensemble différent de paquets open source organisés.

Alors pourquoi un architecte de sécurité devrait-il s’intéresser aux différences en matière de propriété des services ? L’équipe chargée des opérations de sécurité peut disposer de services de sécurité prédéfinis pour soutenir le fonctionnement du service. Les services de sécurité peuvent faire partie de la plateforme cloud ou être sur site, nécessitant une intégration étendue.

Par exemple, une équipe chargée des opérations de sécurité interne peut utiliser une technologie différente de celle d’un intégrateur de systèmes mondiaux (GSI) comme IBM Consulting. Le plan de contrôle de sécurité hébergeant les services de sécurité de l’équipe de sécurité interne peut être sur site, tandis que le GSI peut utiliser des services de sécurité cloud fournis par un autre fournisseur de services cloud.

Pour le modèle de service cloud Software-as-a-Service (SaaS), seule l’administration de la sécurité des applications est accessible aux utilisateurs du service cloud. La sécurité est normalement intégrée à l’application en tant que partie du service, avec une marge de manœuvre limitée pour contrôler la configuration de la sécurité. Dans ce cas, le fournisseur SaaS assume la plupart des responsabilités liées aux opérations de sécurité.

En l’absence de responsabilités documentées, il se peut qu’aucun responsable ne soit chargé de concevoir, d’élaborer et d’exécuter les composants de sécurité qui dépendent du fonctionnement du workload. La compréhension des responsabilités partagées pour les services de sécurité permet à l’architecture de la solution de répondre aux besoins opérationnels et d’éviter une refonte de la solution à un stade ultérieur du projet.

Les services de sécurité dans une architecture de cloud hybride utilisent différents modèles de services cloud, plateformes de calcul et fournisseurs de services cloud. Ces services ont besoin d’une architecture de plan de contrôle convenue pour assurer une gestion et une surveillance cohérentes de la sécurité et de la conformité.

Dans une entreprise disposant de workloads dans un centre de données sur site, le plan de contrôle peut résider dans un centre de données sur site afin d’être résilient en cas de défaillance d’un fournisseur de service cloud. Toutefois, un service de sécurité sur site n’aura pas nécessairement la capacité de gérer entièrement la plateforme cloud. Par conséquent, concevez une architecture de plan de contrôle pour signaler l’état de sécurité et identifier les risques liés aux différents fournisseurs de services cloud.

Pour les entreprises natives du cloud, l’hébergement du plan de contrôle peut se faire sur un autre cloud, dans un point de présence (POP) ou dans un centre de données en colocalisation. Le plan de contrôle de sécurité doit rester disponible, même en cas de défaillance d’un fournisseur de services cloud.

En tant qu’architecte de sécurité, il est important de documenter et de prendre une décision architecturale afin de garantir l’alignement de l’architecture du plan de contrôle de sécurité au sein de l’organisation. Prenez cette décision dès le début du projet afin de vous assurer que la solution répond à la stratégie de l’organisation.

La sécurité ne consiste pas en premier lieu à déployer des capacités de sécurité, mais à protéger les données et processus métier contre les menaces. Utilisez une approche systématique pour retracer les flux de données dans le système afin d’identifier les contrôles de sécurité destinés à protéger les données en transit, au repos et en cours d’utilisation.

Les architectes doivent identifier les données sensibles à protéger en commençant par un diagramme de contexte système pour identifier la frontière du système et les interactions externes qui initient les flux de données à travers le système. Les flux de données internes de l’application sont ensuite examinés à l’aide d’un diagramme décrivant les composants fonctionnels, tel qu’un diagramme de composants.

Lorsque les architectes passent à l’implémentation, ils examinent les flux de données entre les composants déployés sur l’infrastructure cloud à l’aide d’un schéma d’architecture cloud. IBM a créé un langage de conception de schémas techniques qui permet une conception indépendante du fournisseur de service cloud.

Pour identifier les menaces pesant sur ces flux de données, utilisez la modélisation des menaces tant pour les composants fonctionnels des workloads que pour leur infrastructure.

Ensemble, ces techniques et artefacts offrent une approche reproductible et cohérente de la réflexion architecturale en matière de sécurité et de conformité.

Lorsque vous traitez les données les plus sensibles, pensez à ajouter une couche de protection supplémentaire associant confidential computing et chiffrement homomorphe.

Un système doit répondre à de nombreuses exigences de contrôle, et la liste peut s’avérer longue et difficile à gérer. Au lieu de travailler avec de nombreuses exigences individuelles, travaillez avec des processus, des services ou des capacités qui regroupent les exigences en capacités de livraison. Par exemple, la gestion du cycle de vie des identités ou la détection des composants non autorisés sont des capacités de livraison potentielles.

Suivez ces étapes pour mieux gérer la conformité :

1. Créer un cadre de conformité unique avec traçabilité jusqu’aux sources d’origine.
2. Mapper les exigences du cadre à un ensemble de capacités de livraison
3. Garantir la conformité des capacités à chaque étape de la conception, de la construction, des tests et des opérations.
4. Continuer à respecter les exigences en production.

L’architecte de sécurité doit veiller à ce que les capacités de sécurité soient associées à des objectifs de niveau de service (SLO), à des accords de responsabilité, etc.

Il est souvent nécessaire de s’assurer que les données d’un client, d’un secteur d’activité ou d’un environnement ne sont pas divulguées à un autre. La séparation doit avoir lieu pour l’exécution des workloads et le stockage des données. Il peut s’agir simplement d’une table différente dans une base de données ou de serveurs physiques distincts.

Le cloud hybride offre de nombreuses options pour assurer la séparation du traitement de données. La séparation doit avoir lieu entre :

1. Workloads ou applications (par exemple, comptabilité ou ressources humaines)
2. Environnements (par exemple, développement, test et production)
3. Clients (par exemple, client A et client B)
4. Emplacement (par exemple, Royaume-Uni et États-Unis)

Il existe de nombreuses options de ségrégation au sein d’un environnement de cloud hybride, qui offrent des capacités et des garanties différentes :

1. Compte Enterprise
2. Compte cloud
3. Groupe de ressources
4. Cloud privé virtuel
5. Domaine d’exécution (par exemple, une image de conteneur ou de serveur)
6. Projet
7. Domaine de la gestion des clés
8. Dispositifs physiques

Les politiques de l’entreprise doivent définir le type de séparation adapté à la workload qui traite les données. Par exemple, la politique peut exiger que l’hébergement des données clients de production ne se fasse pas dans un environnement hors production. Le niveau minimum de séparation requis est un compte cloud différent, car c’est là que se fait la gestion des identités et des accès.

La question de la souveraineté des données est liée à celle de la séparation des données. Certains pays imposent des contraintes sur les lieux de traitement et d’accès aux données. L’article de blog intitulé « Répondre aux réglementations et stimuler l’innovation grâce au cloud souverain » aborde la hiérarchie des besoins en matière de souveraineté des données.

La modélisation des menaces est souvent considérée comme une technique permettant d’identifier et de valider les contrôles de sécurité des données circulant dans un système.

Cependant, la modélisation des menaces a un second objectif : identifier les menaces à surveiller dans un système de surveillance des menaces. L’architecte de sécurité se doit d’identifier les menaces à prioriser. Il doit définir ensuite les cas d’utilisation requis pour la capacité de détection des menaces. Mettre en œuvre et tester les cas d’utilisation de la détection avec des dossiers d’exploitation de réponse aux incidents pour permettre une réponse efficace aux menaces.

Assurer une traçabilité documentée entre les menaces, les cas d’utilisation de la détection des menaces et les dossiers d’exploitation de la réponse aux incidents, afin de garantir une conception et une livraison complètes du projet.

Dans le passé, avec les centres de données sur site, les équipes chargées des opérations de sécurité réalisaient leurs activités en quelques jours ou quelques heures, et n’exigeaient pas de niveaux de service stricts. Avec l’automatisation de l’infrastructure en tant que code (IaC), la perte d’un service de sécurité centralisé tel que la gestion des secrets ou des certificats, a un impact immédiat sur la disponibilité des applications. Par conséquent, les services de sécurité requièrent des niveaux de service et une architecture pour répondre aux exigences de disponibilité.

Définir pour chaque fonctionnalité ou service de sécurité :

1. Horaires de service
2. Temps de réponse aux incidents, aux problèmes et aux changements
3. Compétences et expérience du personnel chargé des opérations
4. Procédures testées en détail pour répondre aux exigences du service
5. Automatiser pour répondre aux exigences du service

Si l’équipe chargée des opérations de sécurité interne ne peut pas répondre aux exigences d’une workload cloud native, réfléchissez à l’option de faire appel à un fournisseur de services de sécurité gérés.

Si vous y pensez, de nombreux services de sécurité ont aujourd’hui besoin d’une résilience et de niveaux de service au moins aussi bons que la workload qu’ils prennent en charge.

Avec les anciennes méthodes de travail, la sécurité n’était pas prise en compte qu’après coup, ce qui rendait la configuration de la sécurité et l’application des correctifs difficiles à mettre en œuvre, car elles n’étaient pas intégrées au début du cycle de développement. Avec les pratiques professionnelles DevOps, les normes de sécurité doivent être :

1. Intégré aux environnements de développement et de test.
2. Cohérentes du développement à la production.
3. Testées en permanence pour garantir une conformité continue.

Les processus de construction doivent empêcher les déploiements non sécurisés d’un workload à tous les stades du développement et de l’opération, afin de garantir que la sécurité ne soit pas une préoccupation secondaire.