Multi-tenant portals: πώς προστατεύετε τα δεδομένα κάθε πελάτη σε μία εφαρμογή

Πολλά B2B portals και SaaS εργαλεία λειτουργούν με multi-tenant μοντέλο. Μία εφαρμογή εξυπηρετεί πολλούς πελάτες, εταιρείες ή οργανισμούς. Κάθε πελάτης έχει χρήστες, αρχεία, αιτήματα, παραγγελίες, ρυθμίσεις και δεδομένα που πρέπει να μείνουν απομονωμένα.

Αυτό είναι ισχυρό μοντέλο γιατί μειώνει κόστος και απλοποιεί τη συντήρηση. Αλλά έχει ένα κρίσιμο ρίσκο: κανένας χρήστης δεν πρέπει ποτέ να δει δεδομένα άλλου tenant.

Τι είναι tenant

Tenant είναι ένας ξεχωριστός πελάτης ή οργανισμός μέσα στην ίδια εφαρμογή.

Παραδείγματα:

• εταιρεία μέσα σε B2B portal
• πελάτης με δικό του dashboard
• franchise location
• σχολή ή υποκατάστημα
• ομάδα μέσα σε SaaS προϊόν
• συνεργάτης με πρόσβαση σε συγκεκριμένα έργα

Το tenant boundary πρέπει να εφαρμόζεται παντού: στη βάση, στα APIs, στην αναζήτηση, στα files, στα logs και στα background jobs.

Το πιο συνηθισμένο λάθος

Το συνηθισμένο λάθος είναι να βασίζεται η απομόνωση μόνο στο frontend.

Για παράδειγμα, το UI κρύβει records άλλων πελατών, αλλά το API επιτρέπει request με διαφορετικό ID. Αυτό είναι σοβαρό κενό. Τα permissions πρέπει να εφαρμόζονται server-side σε κάθε query και action.

Αν ένας χρήστης έχει πρόσβαση στο tenant A, κάθε API call πρέπει να περιορίζεται στο tenant A, ανεξάρτητα από το τι στέλνει ο browser.

Database design

Υπάρχουν διαφορετικά μοντέλα multi-tenancy:

• κοινή βάση και κοινά tables με tenant_id
• κοινή βάση με ξεχωριστά schemas
• ξεχωριστή βάση ανά tenant

Κάθε μοντέλο έχει tradeoffs σε κόστος, συντήρηση, απομόνωση, reporting και scaling.

Για πολλές μικρές και μεσαίες εφαρμογές, κοινά tables με σωστό tenant_id και αυστηρό authorization είναι πρακτική λύση. Για πιο απαιτητικά enterprise σενάρια, μπορεί να χρειάζεται ισχυρότερη απομόνωση.

Tenant-aware queries

Κάθε query πρέπει να είναι tenant-aware.

Αυτό σημαίνει ότι δεν ψάχνετε απλώς order_id = 123. Ψάχνετε order_id = 123 και tenant_id = current_tenant.

Το ίδιο ισχύει για:

• search results
• exports
• file downloads
• dashboards
• notifications
• webhook processing
• admin actions
• background jobs

Τα περισσότερα data leaks σε multi-tenant εφαρμογές δεν είναι θεαματικά. Είναι μικρά λάθη σε ένα endpoint που ξέχασε το tenant scope.

Ρόλοι μέσα στον tenant

Το tenant isolation δεν αρκεί. Χρειάζονται και ρόλοι μέσα σε κάθε tenant.

Παραδείγματα:

• owner
• admin
• billing user
• support user
• readonly user
• external collaborator

Ένας χρήστης μπορεί να ανήκει σε tenant, αλλά αυτό δεν σημαίνει ότι βλέπει τα πάντα μέσα σε αυτόν.

Files και attachments

Τα αρχεία είναι συχνό σημείο ρίσκου.

Αν τα URLs των αρχείων είναι προβλέψιμα ή δημόσια χωρίς έλεγχο, μπορεί να υπάρξει διαρροή.

Χρειάζονται:

• tenant-scoped storage paths
• signed URLs με περιορισμένο χρόνο
• authorization πριν από download
• έλεγχος MIME/type όπου γίνεται upload
• audit logs για ευαίσθητα downloads

Σε portals με έγγραφα πελατών, αυτό είναι βασικό.

Πώς βοηθά η Ai Foundry

Στην Ai Foundry σχεδιάζουμε multi-tenant portals με την απομόνωση δεδομένων ως βασική αρχή, όχι ως έλεγχο της τελευταίας στιγμής. Χαρτογραφούμε tenants, χρήστες, ρόλους, αρχεία, APIs και background εργασίες ώστε το tenant scope να εφαρμόζεται συνεπώς.

Για B2B portals, CRM, customer dashboards και SaaS εργαλεία, αυτό είναι κρίσιμο για εμπιστοσύνη. Η εφαρμογή πρέπει να είναι εύχρηστη για κάθε πελάτη, αλλά και αυστηρή στο ποιος βλέπει τι.

Checklist

Πριν βγει live multi-tenant portal, ελέγξτε:

• κάθε table έχει σωστό tenant scope;
• κάθε API ελέγχει tenant access server-side;
• τα search results φιλτράρονται ανά tenant;
• τα exports περιορίζονται σωστά;
• τα files απαιτούν authorization;
• υπάρχουν ρόλοι μέσα στον tenant;
• τα background jobs δεν μπερδεύουν tenants;
• υπάρχουν audit logs;
• τα tests καλύπτουν cross-tenant access;
• υπάρχει διαδικασία για αλλαγή ή μεταφορά χρήστη;

Συμπέρασμα

Το multi-tenant μοντέλο είναι ισχυρό, αλλά απαιτεί πειθαρχία. Δεν αρκεί να υπάρχει tenant_id στη βάση. Πρέπει όλη η εφαρμογή να σκέφτεται με tenant boundaries.

Για B2B portals και custom web apps, η απομόνωση δεδομένων είναι κομμάτι της αξιοπιστίας του προϊόντος.

Πηγές για περαιτέρω ανάγνωση: OWASP Authorization Cheat Sheet, OWASP API Security Top 10, PostgreSQL Row Security Policies.