BYOC vs traditionnel SaaS : lequel est le plus sécurisé ?

Aucun des deux modèles n’est magiquement « inpiratable » – mais ils échouent de manières très différentes. Le multi-tenant traditionnel SaaS conserve chaque client dans une base de données centrale, donc une seule violation peut exposer des milliers d’organisations à la fois. BYOC (Apportez votre Own Cloud) supprime entièrement cette base de données centrale : les données de chaque organisation sont conservées isolé sur son propre compte cloud, donc le rayon d’explosion d’un incident par locataire est un locataire, pas l’ensemble de la clientèle. Cette différence structurelle — plus ce qu’il fait pour la résidence et la sortie des données - c’est ce que signifie réellement “plus sécurisé” ici.

Cet article compare honnêtement les deux modèles de sécurité : sur le rayon d’explosion, le locataire l’isolement, la résidence des données, le confinement des violations et ce qui se passe lorsque vous partez. Il s’appuie sur le modèle décrit dans qu’est-ce qu’un système d’exploitation d’agence BYOC ; si vous êtes nouveau dans le terme, commencez par là.

Comment le multi-tenant traditionnel SaaS stocke-t-il vos données ?

La plupart des logiciels d’entreprise que vous utilisez sont multi-tenants SaaS. Le vendeur en gère un application sur une base de données centrale, et chaque client — « locataire » dans le jargon – le partage. Vos contacts CRM et ceux d’un concurrent sont assis aux mêmes tables, séparés par la logique de l’application : généralement une colonne d’ID de locataire sur chaque ligne qui le code est censé filtrer pour chaque lecture et écriture.

Il s’agit d’un très bon modèle d’ingénierie. Son fonctionnement est peu coûteux, facile à mise à jour, et il évolue. Mais cela concentre les données. Des milliers de dossiers d’entreprises se retrouver dans un seul schéma, sur l’infrastructure uniquement contrôlé par le fournisseur, accessible via une application et un ensemble d’informations d’identification de base de données. Cette concentration est la racine du compromis en matière de sécurité.

Qu’est-ce que le « rayon d’explosion » et pourquoi favorise-t-il BYOC ?

Le rayon d’explosion correspond à la quantité exposée en cas de problème : une fuite informations d’identification, un compartiment de stockage mal configuré, une vulnérabilité non corrigée, un initié malveillant. La question n’est pas seulement « quelle est la probabilité d’un incident » mais « comment c’est mauvais quand cela arrive“.

Dans le SaaS multi-tenant, le rayon d’explosion d’un incident au niveau de la base de données est la totalité clientèle. Une violation du magasin central concerne potentiellement les données de chacun à la fois. L’histoire le confirme : les plus grandes violations du SaaS sont précisément importantes parce qu’un point de défaillance était devant des milliers de locataires.

Dans un modèle BYOC, il n’y a pas de magasin central à violer. Les données de chaque organisation vit sur son propre compte cloud, donc un incident par locataire est limité à celui-ci locataire. Il n’existe pas de base de données partagée à parcourir ni de cible unique dont le compromis donne les dossiers de tout le monde. Vous n’avez pas rendu un incident impossible… vous avez limité la distance à laquelle on peut se propager.

Mes données sont-elles vraiment isolées ? Isolation multi-locataire ou par locataire

« L’isolement » est le point où le marketing et l’architecture se séparent souvent. Cela vaut donc la peine en étant précis sur les niveaux :

• Isolement logique (typique SaaS). Une base de données, un schéma, des locataires séparés par un identifiant de locataire et un code d’application. Si ce code a un bug - un filtre manquant, contrôle d’accès défectueux - ou si quelqu’un obtient un accès au niveau de la base de données accès sous l’application, la séparation entre les locataires peut échouer. C’est le risque de sécurité multi-tenant classique : l’isolation dépend du comportement du logiciel parfaitement, partout et à tout moment.
• Isolement d’instance (“dédié au compte du fournisseur”). Certains fournisseurs donnent les clients plus importants disposent d’une base de données distincte, mais toujours sur le compte cloud du fournisseur. Mieux qu’un schéma partagé, le fournisseur conserve néanmoins les données de chaque client. sous son propre contrôle, l’objectif global demeure donc.
• Isolement du compte (BYOC). La base de données de chaque organisation est provisionnée sur son propre compte cloud. L’isolement est une frontière entre des comptes distincts, et non un filtre à l’intérieur d’un système partagé. Il n’existe pas de lieu central où tous les données des clients coexistent, donc les fuites entre locataires entre les clients n’ont pas support partagé pour voyager.

sSystm utilise l’isolation de compte : lors de l’inscription avec votre compte Cloudflare, le la plateforme met à disposition une base de données Cloudflare D1 dédiée sur votre compte. Le l’isolement entre votre agence et tout autre client est l’isolement entre deux comptes cloud distincts. Vous pouvez lire exactement comment ce modèle de données est construit sur le Page Sécurité et modèle de données.

BYOC vs multi-tenant SaaS : le comparatif de sécurité

Dimensions	Multi-tenant traditionnel SaaS	BYOC (Bring Your Own Cloud)
Où vivent les données	Une base de données centrale sur le compte du fournisseur	Une base de données dédiée sur votre compte cloud
Rayon de souffle de brèche	Tous les locataires : une seule violation peut exposer tout le monde	Un locataire — contenu dans un seul compte
Isolement des locataires	Logique (ID locataire + code application)	Au niveau du compte (comptes cloud distincts)
Cible unique de grande valeur	Oui – le magasin partagé	Aucun magasin central à cibler
Résidence des données	Politique des fournisseurs (“nous hébergeons dans le EU”)	Choisi à l’approvisionnement, garantie dure EU en option
Confinement des violations	Dépend de la détection et de la réponse du fournisseur	Structurellement contenu dans un seul compte
Sortie / propriété	Exportez les données, puis reconstruisez ailleurs	Base de données déjà la vôtre — rien à exporter

Le modèle dans le tableau est cohérent : le multi-tenant SaaS optimise pour le la commodité opérationnelle du fournisseur et concentre les risques ; BYOC distribue les données et, avec cela, le risque.

Quel modèle contient le mieux une brèche ?

Le confinement concerne ce qu’un attaquant peut atteindre après un premier point d’ancrage. Dans un système central multi-tenant, un attaquant qui s’introduit sous l’application - jusqu’au base de données, aux sauvegardes, aux outils d’administration - se trouve déjà devant chaque locataire. Le mouvement latéral est trivial car il n’y a nulle part où se déplacer : c’est tout un magasin.

Dans un modèle BYOC, compromettre la couche application de la plateforme ne remet pas le relais une base de données centrale, car il n’y en a pas. Les données de chaque locataire se trouvent derrière le limite d’un compte cloud distinct. Pour atteindre une deuxième organisation, un attaquant devrait pirater un deuxième compte. C’est la différence entre une violation qui évolue et celui qui ne évolue pas.

C’est pourquoi nous définissons BYOC comme un changement de surface d’attaque et de rayon d’explosion plutôt que de promettre l’invulnérabilité. Une vulnérabilité dans n’importe quel logiciel encore a besoin de correctifs et votre compte cloud fait désormais partie du système de sécurité : vous vous en êtes propriétaire, vous devez donc le sécuriser (informations d’identification solides, accès au moindre privilège, MFA). BYOC vous confère une certaine responsabilité en échange de la suppression du plus grand point de défaillance globale. C’est un métier, et pour les agences dont toute l’activité ce sont des données client, ce sont généralement les bonnes.

Qu’en est-il de la résidence des données et du GDPR ?

La résidence est le point où les deux modèles divergent le plus visiblement. En SaaS conventionnel, “nous hébergeons dans le EU” est une politique — une promesse qui peut changer avec un nouveau sous-traitant ultérieur, une nouvelle région ou un nouveau propriétaire d’entreprise. Lorsqu’un régulateur ou un le client d’entreprise demande où se trouve exactement cet enregistrement et qui peut y accéder, un Le cluster central multi-tenant est une chose inconfortable à signaler.

Avec BYOC la réponse est structurelle. Étant donné que la base de données est provisionnée sur votre compte, vous choisissez sa juridiction lors de sa création. sSystm vous permet de choisir votre région lors de la connexion, y compris une garantie dure de juridiction EU pour le base de données — résidence par construction, pas par promesse. Nous approfondissons le angle de conformité dans résidence des données, GDPR et agences. Rien de tout cela n’est un avis juridique, mais « les données résident physiquement dans un fichier épinglé EU. base de données pour notre propre compte“ est une position matériellement plus forte qu’une ligne dans un conditions du vendeur.

Qu’arrive-t-il à mes données si je pars ?

La sécurité inclut la fin de la relation, pas seulement le milieu. Avec traditionnel SaaS, quitter signifie exporter vos enregistrements via n’importe quel API le offres des fournisseurs et reconstruire les relations entre eux ailleurs - et jusqu’à ce que vous le faites, vos données continuent de se trouver dans le magasin du fournisseur. La déprovisionnement est activée leur chronologie, pas la vôtre.

Avec BYOC, la sortie est un non-événement pour les données. La base de données était toujours sur votre compte ; déconnectez la plateforme et le vendeur perd l’accès pendant que vous conservez tout – les enregistrements, le contenu et les sauvegardes – exactement là où ils se trouvaient. Il y a pas d’étape d’exportation car il n’y a rien à laisser derrière soi. Cette propriété chevauche fortement avec le verrouillage, que nous couvrons dans SaaS verrouillage du fournisseur et comment l’éviter.

Alors, qu’est-ce qui est le plus sécurisé ?

Honnêtement : cela dépend de votre modèle de menace, et aucune architecture ne peut remplacer pour bien faire les bases. Mais si votre principale préoccupation est le scénario qui maintient les propriétaires d’agences veillent la nuit — un incident expose tous nos clients à la fois — alors BYOC est le modèle le plus fort, car ce mode de défaillance spécifique ne prend pas en compte existent lorsqu’il n’y a pas de base de données centrale. Cela réduit le rayon de l’explosion de tout le monde à un, transforme l’isolement des locataires en une frontière entre les comptes, et crée des propriétés de résidence et de sortie de l’architecture au lieu de clauses dans un contrat.

C’est le pari sur lequel sSystm est construit. Vous pouvez inspecter le fonctionnement du modèle de données sur la page Sécurité et modèle de données plutôt que de nous croire sur parole, et voir la philosophie plus large dans qu’est-ce qu’un système d’exploitation d’agence BYOC.