La Sécurité, pilier d’un SI solide

Tels les murs d’une ville fortifiée la sécurité du SI va être mise à rude épreuve contre des événements inhabituels ou des attaques préméditées. Elles défini la limite entre l’intérieur et l’extérieur. Elle doit donner cette image de confiance et de satisfactions comme par un jour d’orage à l’intérieur d’un chez soi cosy, au chaud et bien isolé.

Continuons sur la métaphore de la cité avec le point de vue d’un urbaniste. Cette citée fortifiée va héberger les grandes richesse que sont nos données. Elle va aussi héberger une multitude d’individus. Ces individus vont devoir montrer patte blanche pour qu’on puisse à tout moment leur demander leur identité. Chaque individu est unique et va faire partie d’un cercle de population qui partage par exemple une mêmes activité. si on fait l’analogie d’un service qui représente un bâtiment, on ne voudra par exemple donner l’accès à la sale de repos d’un hôpital qu’aux employés et l’accès à la salle de chirurgie qu’aux médecins ou aux patients attendus. D’un point de vue « disponibilité » on appréciera aussi que notre cité propose différents moyens d’accès aux services. Si une route est inondée, on doit par exemple pouvoir la contourner quitte à faire plus de km. N’oublions pas qu’en cas de terrible incident dans notre cité, on doit aussi avoir prévu un bunker qui héberge les joyaux de la couronne.

Prévoir

Prévoir est la chose la plus importante à avoir en tête. En fait on se rends toujours compte à quel point on « aurait dû agir avant » au moment où on est face à un situation avec l’impossibilité d’agir. Pour ne pas tomber dans cette situation et se sentir démuni, s’être fait voler les clés de sa propre cité sans pouvoir y revenir, il est urgent de connaitre les bonnes pratiques et imposer une hygiène irréprochable structurelle, architecturale mais aussi des règles strictes à suivre par les individu constituant la population.

Une responsabilité partagée

Une chose importante à retenir c’est que quel que soit le fournisseur cloud souscrit, il ne sera probablement jamais entièrement responsable du vol, de la perte ou de l’altération de vos données. Par contre ce qui est clair c’est qu’il est responsable de la sécurité physique de son « data center ». Il est aussi responsable de n’y faire accéder que les personnes de la maintenance, de chiffrer vos données avec vos clés et de détruire vos données physiquement à la demande. Voyons par exemple l’exemple des 6 couches de protection d’un centre de calcul et de données google:

Maintenant si vous êtes dans le cas où vos données sont hébergées dans votre propre centre de calcul, posez-vous la question suivante: est-ce que j’en fait autant que les fournisseurs cloud? Est-ce que cela me coûte plus cher? Est-ce que j’ai des procédures internes pour essayer de contourner ma propre sécurité en utilisant mes propres employés?

Il y a a donc certes un certain avantage en terme de sécurité physique comme argument pour aller dans le cloud. Par contre il ne faut pas y aller les yeux fermés. Du point de vue contractuel vérifiez bien que vos données seront bien localisées là où vous le souhaitez, que vous pouvez les détruire (y compris physiquement) à tout moment et qu’il n’y ai pas de frein majeur de portabilité des données en cas de rupture de contrat. En effet le format de transfert de vos données ou le débit peut être ridiculement rédhibitoire lorsque vous voulez rapatrier vos données chez vous ou chez un autre fournisseur. Alors vérifiez votre contrat avant de le signer.

De votre côté vous êtes généralement responsable de mettre en place la bonne configuration des infrastructures de manière sécurisée. On vous donne une boite de légo et c’est à vous de créer votre propre système solide et sécurisé. Personne ne vous oblige à chiffrer vos données ou à mettre vos application backend dans un sous réseau privé de passerelle internet.

Pour ce faire il y a des objectifs et des règles de bonne pratique à appliquer à votre SI qu’il soit dans le cloud ou non. Dans le cloud il sera juste plus simple de trouver des « zones de disponibilité » et de ressources à la volée.

Objectifs de sécurité dans nos infrastructures

• Comment sécuriser les données à chaque niveau dans une application? Identifier les outils et services nécessaires à leur sécurité.
• Quels sont les principes d’architecture et les bonnes pratiques à mettre en place en termes de sécurité?

L’impact d’un incident doit toujours être contenu. On ne veut surtout pas qu’in incident se propage à d’autres services. On va alors avoir des procédures de redémarrage et les automatiser au maximum. Ainsi pour atténuer un incident nous avons les les outils suivants:

• Le contrôle des identités et des accès
• la détection d’incident
• la protection des infrastructures
• la protection des données
• la réponse à l’incident

Plus spécifiquement dans le cloud par rapport à un SI traditionnel un bonne pratique pour renforcer la sécurité est de se concentrer à mettre en place les services suivants

• Un fédération d’identité forte, centralisée
• De la traçabilité (alertes, logs, métriques, temps réel)
• Des barrières de sécurité à tout les niveaux (sur chaque entité, service ou ressource)
• Automatiser les principes de sécurité (pour passer à l’échelle ou rétablir un service rapidement sans pour autant mettre de côté les aspects sécurité)
• Protéger les données en veille ou en mouvement. (prendre en compte le niveau de criticité des données, les chiffrer si nécessaire, éliminer l’accès direct par un individu)
• Se préparer aux incidents avec des procédures de détection d’investigation et de rétablissement.

à quoi devrait-on se préparer?

Il existe un ensemble de failles communément exploitables et donc probables. Parmis ces attaques on a:

• DoS (Denial of Service) rend inutilisable les service à vos utilisateurs.
• DDoS (Distributed Denial of Service) une attaque simultanée depuis différentes systèmes.

Les attaquant vont cibler vos réseaux et vos ressources avec différentes techniques pour couper l’accès aux services.

Les fournisseurs cloud vont généralement proposer les moyens de rendre vos systèmes résilients à ces attaques. La responsabilité sur ce type d’attaque entre le fournisseur et le contractant du cloud est en général partagée. Le contractant doit en général s’inspirer des bonnes pratiques de sécurité exposées par le fournisseur qui va de son côté fournir un livre blanc. Voici un exemple de livre blanc de la sécurité chez AWS.

Une histoire de standards et de réglementation

Wow! L’idée est géniale, ta start-up va décoller comme une fusée! Ok, pas mal c’est une superbe idée! L’impression d’avoir trouvé l’idée du siècle? Doucement, est-ce que cela réponds à la réglementation?
Souvent on est confronté à ce type de situation: l’idée est bonne mais elle a l’air limite niveau réglementation, surtout si on réside en Europe ou lorsqu’il y a des lois locales en vigueur.

Tout ça pour dire que si on ne passe pas le mur du « légal et réglementaire », on n’ira nulle part. C’est pour cela que ce sujet est même plus important que le financement ou le projet lui même. Dans le cloud comment ça se passe? Pour cela, heureusement qu’il y a la CSA ou « Cloud Security Alliance » pour nous donner matière à réfléchir par rapport à la multitude de fournisseurs cloud public ou privé sur le marché. Il y a même un chapitre français pour les francophones.

Parmi le contenu exploitable et fourni par la CSA on doit d’abord commencer par exploiter la CCM ou Cloud Control Matrix. Cette matrice permet de contrôler la sécurité parmi une centaine d’objectifs divisés en 16 domaines. Cette matrice accompagne l’ensemble des sujets de sécurité dans le cloud et permet de se poser les bonnes questions en terme de sécurité. La CAIQ permet de différencier les fournisseurs sur les sujets sécurité. Le programme STAR regroupe ces pratiques.