#multitenancy — Public Fediverse posts on home.social

JohnnyD @[email protected] · 2026-03-17 · 19:23 UTC

🚀 New blog post + django-rls-tenants 1.1.0 is out!
TL;DR: PostgreSQL RLS policies can't use your indexes because current_setting() isn't leakproof. The query planner falls back to sequential scans and applies tenant filtering row-by-row. On large tables, this hurts.

v1.1 fixes this by adding automatic ORM-level WHERE tenant_id = X alongside RLS - so Postgres uses your composite indexes for the fast path while RLS still enforces isolation as a safety net.

Also in this release:
→ select_related() now propagates tenant filters across joins
→ threading.local replaced with contextvars (ASGI-safe)
→ Superuser detection at startup (RLS is silently bypassed otherwise!)
→ Better exception handling in middleware
→ CASE WHEN policy rewrite for cleaner evaluation
Full write-up: https://dev.to/dvoraj75/postgresql-rls-is-fail-closed-but-is-it-fast-making-django-rls-tenants-index-friendly-2j18
GitHub: https://github.com/dvoraj75/django-rls-tenants
#Django #PostgreSQL #Python #MultiTenancy #RLS #OpenSource

#django #postgresql #python #multitenancy #rls #opensource

JohnnyD @[email protected] · 2026-03-17 · 19:23 UTC

🚀 New blog post + django-rls-tenants 1.1.0 is out!
TL;DR: PostgreSQL RLS policies can't use your indexes because current_setting() isn't leakproof. The query planner falls back to sequential scans and applies tenant filtering row-by-row. On large tables, this hurts.

v1.1 fixes this by adding automatic ORM-level WHERE tenant_id = X alongside RLS - so Postgres uses your composite indexes for the fast path while RLS still enforces isolation as a safety net.

Also in this release:
→ select_related() now propagates tenant filters across joins
→ threading.local replaced with contextvars (ASGI-safe)
→ Superuser detection at startup (RLS is silently bypassed otherwise!)
→ Better exception handling in middleware
→ CASE WHEN policy rewrite for cleaner evaluation
Full write-up: https://dev.to/dvoraj75/postgresql-rls-is-fail-closed-but-is-it-fast-making-django-rls-tenants-index-friendly-2j18
GitHub: https://github.com/dvoraj75/django-rls-tenants
#Django #PostgreSQL #Python #MultiTenancy #RLS #OpenSource

#django #postgresql #python #multitenancy #rls #opensource

JohnnyD @[email protected] · 2026-03-17 · 19:23 UTC

🚀 New blog post + django-rls-tenants 1.1.0 is out!
TL;DR: PostgreSQL RLS policies can't use your indexes because current_setting() isn't leakproof. The query planner falls back to sequential scans and applies tenant filtering row-by-row. On large tables, this hurts.

v1.1 fixes this by adding automatic ORM-level WHERE tenant_id = X alongside RLS - so Postgres uses your composite indexes for the fast path while RLS still enforces isolation as a safety net.

Also in this release:
→ select_related() now propagates tenant filters across joins
→ threading.local replaced with contextvars (ASGI-safe)
→ Superuser detection at startup (RLS is silently bypassed otherwise!)
→ Better exception handling in middleware
→ CASE WHEN policy rewrite for cleaner evaluation
Full write-up: https://dev.to/dvoraj75/postgresql-rls-is-fail-closed-but-is-it-fast-making-django-rls-tenants-index-friendly-2j18
GitHub: https://github.com/dvoraj75/django-rls-tenants
#Django #PostgreSQL #Python #MultiTenancy #RLS #OpenSource

#opensource #rls #multitenancy #python #postgresql #django

JohnnyD @johnnyd · 2026-03-17 · 19:23 UTC

🚀 New blog post + django-rls-tenants 1.1.0 is out!
TL;DR: PostgreSQL RLS policies can't use your indexes because current_setting() isn't leakproof. The query planner falls back to sequential scans and applies tenant filtering row-by-row. On large tables, this hurts.

v1.1 fixes this by adding automatic ORM-level WHERE tenant_id = X alongside RLS - so Postgres uses your composite indexes for the fast path while RLS still enforces isolation as a safety net.

Also in this release:
→ select_related() now propagates tenant filters across joins
→ threading.local replaced with contextvars (ASGI-safe)
→ Superuser detection at startup (RLS is silently bypassed otherwise!)
→ Better exception handling in middleware
→ CASE WHEN policy rewrite for cleaner evaluation
Full write-up: https://dev.to/dvoraj75/postgresql-rls-is-fail-closed-but-is-it-fast-making-django-rls-tenants-index-friendly-2j18
GitHub: https://github.com/dvoraj75/django-rls-tenants
#Django #PostgreSQL #Python #MultiTenancy #RLS #OpenSource

#django #postgresql #python #multitenancy #rls #opensource

JohnnyD @[email protected] · 2026-03-15 · 15:33 UTC

Your Django ORM protects tenant data. Your raw SQL doesn't. 😬

That's why I built django-rls-tenants — multitenancy powered by PostgreSQL Row-Level Security, enforced at the database level.

🔒 Every query is filtered — ORM, raw SQL, even dbshell
🚫 Missing tenant context? Zero rows returned, never a data leak
📦 Single schema, no connection routing headaches
⚡ Drop-in: one base model, one middleware, done

Unlike schema-based or ORM-rewriting approaches, RLS policies live in PostgreSQL itself. The database becomes your last line of defense — not your app code.

Supports Python 3.11+, Django 4.2–6.0, PostgreSQL 15+.

Just shipped v1.0.0 🚀

pip install django-rls-tenants

📖 Docs & source: https://github.com/dvoraj75/django-rls-tenants

Feedback, stars & contributions welcome! ⭐

#Django #Python #PostgreSQL #MultiTenancy #RowLevelSecurity #OpenSource #WebDev #SaaS #InfoSec #Database

#django #python #postgresql #multitenancy #rowlevelsecurity #opensource

JohnnyD @[email protected] · 2026-03-15 · 15:33 UTC

Your Django ORM protects tenant data. Your raw SQL doesn't. 😬

That's why I built django-rls-tenants — multitenancy powered by PostgreSQL Row-Level Security, enforced at the database level.

🔒 Every query is filtered — ORM, raw SQL, even dbshell
🚫 Missing tenant context? Zero rows returned, never a data leak
📦 Single schema, no connection routing headaches
⚡ Drop-in: one base model, one middleware, done

Unlike schema-based or ORM-rewriting approaches, RLS policies live in PostgreSQL itself. The database becomes your last line of defense — not your app code.

Supports Python 3.11+, Django 4.2–6.0, PostgreSQL 15+.

Just shipped v1.0.0 🚀

pip install django-rls-tenants

📖 Docs & source: https://github.com/dvoraj75/django-rls-tenants

Feedback, stars & contributions welcome! ⭐

#Django #Python #PostgreSQL #MultiTenancy #RowLevelSecurity #OpenSource #WebDev #SaaS #InfoSec #Database

#database #infosec #saas #webdev #opensource #rowlevelsecurity

JohnnyD @johnnyd · 2026-03-15 · 15:33 UTC

Your Django ORM protects tenant data. Your raw SQL doesn't. 😬

That's why I built django-rls-tenants — multitenancy powered by PostgreSQL Row-Level Security, enforced at the database level.

🔒 Every query is filtered — ORM, raw SQL, even dbshell
🚫 Missing tenant context? Zero rows returned, never a data leak
📦 Single schema, no connection routing headaches
⚡ Drop-in: one base model, one middleware, done

Unlike schema-based or ORM-rewriting approaches, RLS policies live in PostgreSQL itself. The database becomes your last line of defense — not your app code.

Supports Python 3.11+, Django 4.2–6.0, PostgreSQL 15+.

Just shipped v1.0.0 🚀

pip install django-rls-tenants

📖 Docs & source: https://github.com/dvoraj75/django-rls-tenants

Feedback, stars & contributions welcome! ⭐

#Django #Python #PostgreSQL #MultiTenancy #RowLevelSecurity #OpenSource #WebDev #SaaS #InfoSec #Database

#django #python #postgresql #multitenancy #rowlevelsecurity #opensource

JohnnyD @[email protected] · 2026-03-11 · 22:22 UTC

🚀 Day 1 on django-rls-tenants — bringing true PostgreSQL Row-Level Security to Django multitenancy!

Instead of separate schemas or filtered querysets, this library leverages native RLS policies at the DB level to isolate tenant data automatically.

✅ Pros:
• True DB-level isolation — tenants can't bleed into each other
• Transparent to Django ORM — no custom managers needed
• Leaner than schema-per-tenant approaches
• Scales well for high tenant counts
• Security enforced even outside the app layer

❌ Cons:
• PostgreSQL-only (no MySQL/SQLite support)
• RLS policies add complexity to migrations
• Debugging cross-tenant issues can be tricky
• Superuser connections bypass RLS — needs care
• Less community tooling than shared-schema approaches

Still very early, but the foundations are solid. Would love feedback from anyone who's tackled multitenancy in Django before! 🐘🐍

#Django #PostgreSQL #Python #Multitenancy #RLS #RowLevelSecurity #OpenSource #WebDev #SaaS #DjangoORM #DevLife

#django #postgresql #python #multitenancy #rls #rowlevelsecurity

JohnnyD @johnnyd · 2026-03-11 · 22:22 UTC

🚀 Day 1 on django-rls-tenants — bringing true PostgreSQL Row-Level Security to Django multitenancy!

Instead of separate schemas or filtered querysets, this library leverages native RLS policies at the DB level to isolate tenant data automatically.

✅ Pros:
• True DB-level isolation — tenants can't bleed into each other
• Transparent to Django ORM — no custom managers needed
• Leaner than schema-per-tenant approaches
• Scales well for high tenant counts
• Security enforced even outside the app layer

❌ Cons:
• PostgreSQL-only (no MySQL/SQLite support)
• RLS policies add complexity to migrations
• Debugging cross-tenant issues can be tricky
• Superuser connections bypass RLS — needs care
• Less community tooling than shared-schema approaches

Still very early, but the foundations are solid. Would love feedback from anyone who's tackled multitenancy in Django before! 🐘🐍

#Django #PostgreSQL #Python #Multitenancy #RLS #RowLevelSecurity #OpenSource #WebDev #SaaS #DjangoORM #DevLife

#django #postgresql #python #multitenancy #rls #rowlevelsecurity

Habr @[email protected] · 2026-01-27 · 05:02 UTC

PostgreSQL RLS в Go, Часть 2: Архитектура Highload. Паника, гонки и 10 000 партиций

В первой части было разобрано, как настроить RLS в Go, почему is_local=true спасает от утечек в PgBouncer, и как покрыть это интеграционными тестами. Если вы еще не настроили базовую изоляцию, начните оттуда. Сегодня мы пойдем глубже. Мы не будем говорить о синтаксисе. Мы поговорим об архитектуре. О том, почему RLS - это не просто "удобный фильтр", а нативный механизм инкапсуляции, который решает проблемы распределенных систем и рисков безопасности прямо в слое данных, не раздувая Ops-сложность до сотен схем и баз. Кому и зачем читать? Junior/Middle: Поймете, почему RLS - это архитектурный выбор, а не просто WHERE tenant_id = ? . Узнаете про TOCTOU и как его избежать. Senior/Architect: Увидите паттерны для highload (партиционирование + RLS) и production-грабли (матвьюхи, репликация).

https://habr.com/ru/articles/988744/

#Go #Golang #PostgreSQL #RLS #Multitenancy #Backend #Database_Security #архитектура #highload

#highload #архитектура #database_security #backend #multitenancy #rls

Habr @[email protected] · 2026-01-27 · 05:02 UTC

PostgreSQL RLS в Go, Часть 2: Архитектура Highload. Паника, гонки и 10 000 партиций

В первой части было разобрано, как настроить RLS в Go, почему is_local=true спасает от утечек в PgBouncer, и как покрыть это интеграционными тестами. Если вы еще не настроили базовую изоляцию, начните оттуда. Сегодня мы пойдем глубже. Мы не будем говорить о синтаксисе. Мы поговорим об архитектуре. О том, почему RLS - это не просто "удобный фильтр", а нативный механизм инкапсуляции, который решает проблемы распределенных систем и рисков безопасности прямо в слое данных, не раздувая Ops-сложность до сотен схем и баз. Кому и зачем читать? Junior/Middle: Поймете, почему RLS - это архитектурный выбор, а не просто WHERE tenant_id = ? . Узнаете про TOCTOU и как его избежать. Senior/Architect: Увидите паттерны для highload (партиционирование + RLS) и production-грабли (матвьюхи, репликация).

https://habr.com/ru/articles/988744/

#Go #Golang #PostgreSQL #RLS #Multitenancy #Backend #Database_Security #архитектура #highload

#highload #архитектура #database_security #backend #multitenancy #rls

Habr @[email protected] · 2026-01-27 · 05:02 UTC

PostgreSQL RLS в Go, Часть 2: Архитектура Highload. Паника, гонки и 10 000 партиций

В первой части было разобрано, как настроить RLS в Go, почему is_local=true спасает от утечек в PgBouncer, и как покрыть это интеграционными тестами. Если вы еще не настроили базовую изоляцию, начните оттуда. Сегодня мы пойдем глубже. Мы не будем говорить о синтаксисе. Мы поговорим об архитектуре. О том, почему RLS - это не просто "удобный фильтр", а нативный механизм инкапсуляции, который решает проблемы распределенных систем и рисков безопасности прямо в слое данных, не раздувая Ops-сложность до сотен схем и баз. Кому и зачем читать? Junior/Middle: Поймете, почему RLS - это архитектурный выбор, а не просто WHERE tenant_id = ? . Узнаете про TOCTOU и как его избежать. Senior/Architect: Увидите паттерны для highload (партиционирование + RLS) и production-грабли (матвьюхи, репликация).

https://habr.com/ru/articles/988744/

#Go #Golang #PostgreSQL #RLS #Multitenancy #Backend #Database_Security #архитектура #highload

#highload #архитектура #database_security #backend #multitenancy #rls

Habr @[email protected] · 2026-01-27 · 05:02 UTC

PostgreSQL RLS в Go, Часть 2: Архитектура Highload. Паника, гонки и 10 000 партиций

В первой части было разобрано, как настроить RLS в Go, почему is_local=true спасает от утечек в PgBouncer, и как покрыть это интеграционными тестами. Если вы еще не настроили базовую изоляцию, начните оттуда. Сегодня мы пойдем глубже. Мы не будем говорить о синтаксисе. Мы поговорим об архитектуре. О том, почему RLS - это не просто "удобный фильтр", а нативный механизм инкапсуляции, который решает проблемы распределенных систем и рисков безопасности прямо в слое данных, не раздувая Ops-сложность до сотен схем и баз. Кому и зачем читать? Junior/Middle: Поймете, почему RLS - это архитектурный выбор, а не просто WHERE tenant_id = ? . Узнаете про TOCTOU и как его избежать. Senior/Architect: Увидите паттерны для highload (партиционирование + RLS) и production-грабли (матвьюхи, репликация).

https://habr.com/ru/articles/988744/

#Go #Golang #PostgreSQL #RLS #Multitenancy #Backend #Database_Security #архитектура #highload

#go #golang #postgresql #rls #multitenancy #backend

Habr @[email protected] · 2026-01-21 · 09:32 UTC

Как перестать писать WHERE tenant_id и отдать безопасность базе (PostgreSQL RLS в Go)?

В одном из прошлых проектов случился «кошмар техлида»: в суматохе хотфикса было забыто добавление фильтра WHERE tenant_id = ? в одну из ручек API. В итоге один клиент увидел отчеты другого. Все быстро откатили, но я навсегда запомнил то холодное чувство в животе. Когда начали проектировать архитектуру следующего проекта, я понял, что полагаться на внимательность разработчиков на код-ревью - это тупик. Рано или поздно кто-то устанет, ошибется, и данные снова протекут. Искал способ гарантировать изоляцию данных так, чтобы ее физически нельзя было забыть. Почему стандартные решения не подошли? Перебрал классическую тройку вариантов, и у каждого нашлись фатальные минусы для задачи: 1. Логическая изоляция (WHERE в коде)? Как это работает: Тысячи строк кода, и в каждом запросе ты обязан помнить про tenant_id . Проблема: Человеческий фактор. Это бомба замедленного действия. 2. Схема на клиента (Schema-per-tenant) Как это работает: У каждого клиента своя схема ( schema_01 , schema_02 ...). Проблема: Это работает, пока клиентов 100. Когда их становится 10 000, база начинает задыхаться. Детали: Проблема даже не в миграциях, а в файловой системе. 10 000 клиентов × 50 таблиц = 500 000 файлов. Postgres (и Linux) сходят с ума от такого количества открытых дескрипторов, а VACUUM превращается в ад. 3. Отдельная БД на клиента Как это работает: Полная физическая изоляция. Проблема: Ценник на инфраструктуру. Держать тысячи коннектов или инстансов RDS - экономическое самоубийство для стартапа. Тогда посмотрел в сторону PostgreSQL Row Level Security (RLS) . Честно говоря, поначалу было страшно. Отдавать логику безопасности "черному ящику" внутри БД казалось рискованным. Плюс, все вокруг пугали: "RLS убьет производительность".

https://habr.com/ru/articles/987364/

#Golang #PostgreSQL #RLS #Multitenancy #Backend #Testcontainers #Database_Security #Архитектура

#архитектура #database_security #testcontainers #backend #multitenancy #rls

Habr @[email protected] · 2026-01-21 · 09:32 UTC

Как перестать писать WHERE tenant_id и отдать безопасность базе (PostgreSQL RLS в Go)?

В одном из прошлых проектов случился «кошмар техлида»: в суматохе хотфикса было забыто добавление фильтра WHERE tenant_id = ? в одну из ручек API. В итоге один клиент увидел отчеты другого. Все быстро откатили, но я навсегда запомнил то холодное чувство в животе. Когда начали проектировать архитектуру следующего проекта, я понял, что полагаться на внимательность разработчиков на код-ревью - это тупик. Рано или поздно кто-то устанет, ошибется, и данные снова протекут. Искал способ гарантировать изоляцию данных так, чтобы ее физически нельзя было забыть. Почему стандартные решения не подошли? Перебрал классическую тройку вариантов, и у каждого нашлись фатальные минусы для задачи: 1. Логическая изоляция (WHERE в коде)? Как это работает: Тысячи строк кода, и в каждом запросе ты обязан помнить про tenant_id . Проблема: Человеческий фактор. Это бомба замедленного действия. 2. Схема на клиента (Schema-per-tenant) Как это работает: У каждого клиента своя схема ( schema_01 , schema_02 ...). Проблема: Это работает, пока клиентов 100. Когда их становится 10 000, база начинает задыхаться. Детали: Проблема даже не в миграциях, а в файловой системе. 10 000 клиентов × 50 таблиц = 500 000 файлов. Postgres (и Linux) сходят с ума от такого количества открытых дескрипторов, а VACUUM превращается в ад. 3. Отдельная БД на клиента Как это работает: Полная физическая изоляция. Проблема: Ценник на инфраструктуру. Держать тысячи коннектов или инстансов RDS - экономическое самоубийство для стартапа. Тогда посмотрел в сторону PostgreSQL Row Level Security (RLS) . Честно говоря, поначалу было страшно. Отдавать логику безопасности "черному ящику" внутри БД казалось рискованным. Плюс, все вокруг пугали: "RLS убьет производительность".

https://habr.com/ru/articles/987364/

#Golang #PostgreSQL #RLS #Multitenancy #Backend #Testcontainers #Database_Security #Архитектура

#архитектура #database_security #testcontainers #backend #multitenancy #rls

Habr @[email protected] · 2026-01-21 · 09:32 UTC

Как перестать писать WHERE tenant_id и отдать безопасность базе (PostgreSQL RLS в Go)?

В одном из прошлых проектов случился «кошмар техлида»: в суматохе хотфикса было забыто добавление фильтра WHERE tenant_id = ? в одну из ручек API. В итоге один клиент увидел отчеты другого. Все быстро откатили, но я навсегда запомнил то холодное чувство в животе. Когда начали проектировать архитектуру следующего проекта, я понял, что полагаться на внимательность разработчиков на код-ревью - это тупик. Рано или поздно кто-то устанет, ошибется, и данные снова протекут. Искал способ гарантировать изоляцию данных так, чтобы ее физически нельзя было забыть. Почему стандартные решения не подошли? Перебрал классическую тройку вариантов, и у каждого нашлись фатальные минусы для задачи: 1. Логическая изоляция (WHERE в коде)? Как это работает: Тысячи строк кода, и в каждом запросе ты обязан помнить про tenant_id . Проблема: Человеческий фактор. Это бомба замедленного действия. 2. Схема на клиента (Schema-per-tenant) Как это работает: У каждого клиента своя схема ( schema_01 , schema_02 ...). Проблема: Это работает, пока клиентов 100. Когда их становится 10 000, база начинает задыхаться. Детали: Проблема даже не в миграциях, а в файловой системе. 10 000 клиентов × 50 таблиц = 500 000 файлов. Postgres (и Linux) сходят с ума от такого количества открытых дескрипторов, а VACUUM превращается в ад. 3. Отдельная БД на клиента Как это работает: Полная физическая изоляция. Проблема: Ценник на инфраструктуру. Держать тысячи коннектов или инстансов RDS - экономическое самоубийство для стартапа. Тогда посмотрел в сторону PostgreSQL Row Level Security (RLS) . Честно говоря, поначалу было страшно. Отдавать логику безопасности "черному ящику" внутри БД казалось рискованным. Плюс, все вокруг пугали: "RLS убьет производительность".

https://habr.com/ru/articles/987364/

#Golang #PostgreSQL #RLS #Multitenancy #Backend #Testcontainers #Database_Security #Архитектура

#архитектура #database_security #testcontainers #backend #multitenancy #rls

Habr @[email protected] · 2026-01-21 · 09:32 UTC

Как перестать писать WHERE tenant_id и отдать безопасность базе (PostgreSQL RLS в Go)?

В одном из прошлых проектов случился «кошмар техлида»: в суматохе хотфикса было забыто добавление фильтра WHERE tenant_id = ? в одну из ручек API. В итоге один клиент увидел отчеты другого. Все быстро откатили, но я навсегда запомнил то холодное чувство в животе. Когда начали проектировать архитектуру следующего проекта, я понял, что полагаться на внимательность разработчиков на код-ревью - это тупик. Рано или поздно кто-то устанет, ошибется, и данные снова протекут. Искал способ гарантировать изоляцию данных так, чтобы ее физически нельзя было забыть. Почему стандартные решения не подошли? Перебрал классическую тройку вариантов, и у каждого нашлись фатальные минусы для задачи: 1. Логическая изоляция (WHERE в коде)? Как это работает: Тысячи строк кода, и в каждом запросе ты обязан помнить про tenant_id . Проблема: Человеческий фактор. Это бомба замедленного действия. 2. Схема на клиента (Schema-per-tenant) Как это работает: У каждого клиента своя схема ( schema_01 , schema_02 ...). Проблема: Это работает, пока клиентов 100. Когда их становится 10 000, база начинает задыхаться. Детали: Проблема даже не в миграциях, а в файловой системе. 10 000 клиентов × 50 таблиц = 500 000 файлов. Postgres (и Linux) сходят с ума от такого количества открытых дескрипторов, а VACUUM превращается в ад. 3. Отдельная БД на клиента Как это работает: Полная физическая изоляция. Проблема: Ценник на инфраструктуру. Держать тысячи коннектов или инстансов RDS - экономическое самоубийство для стартапа. Тогда посмотрел в сторону PostgreSQL Row Level Security (RLS) . Честно говоря, поначалу было страшно. Отдавать логику безопасности "черному ящику" внутри БД казалось рискованным. Плюс, все вокруг пугали: "RLS убьет производительность".

https://habr.com/ru/articles/987364/

#Golang #PostgreSQL #RLS #Multitenancy #Backend #Testcontainers #Database_Security #Архитектура

#golang #postgresql #rls #multitenancy #backend #testcontainers

Reddit Tech VN Bot @[email protected] · 2026-01-19 · 20:19 UTC

Tuần 1: PropelKit - boilerplate SaaS Next.js. Hoàn thành quản lý tổ chức, phân quyền role (owner/admin/member), hệ thống mời email, chuyển đổi org UI, RLS policies trên Supabase. Sửa bug RLS: dùng bảng organization_members thay auth.uid(). Học: RLS cần thiết kế từ đầu. Tiếp: hệ thống credits, tích hợp Razorpay, webhook. Stack: Next.js 15, Supabase, TypeScript, Tailwind. #SaaS #Nextjs #Supabase #RLS #MultiTenancy #CôngNghệ #PhátTriển

https://www.reddit.com/r/SideProject/comments/1qherhk/week_1_b

#saas #nextjs #supabase #rls #multitenancy #congnghệ

Agnieszka Serafinowicz @[email protected] · 2026-01-09 · 12:00 UTC

Cisco nadrabia zaległości. Multitenancy w Security Cloud Control ułatwi życie MSP

Zarządzanie bezpieczeństwem kilkudziesięciu klientów na raz to dla firm typu MSP chleb powszedni. Do tej pory w ekosystemie Cisco wymagało to jednak sporej gimnastyki i żonglowania oknami. Gigant w końcu postanowił posprzątać ten bałagan, wprowadzając natywną wielodostępność (multitenancy). Pytanie brzmi: dlaczego dopiero teraz?

Koniec ery „Alt-Tab”, czyli standard z opóźnieniem

Cisco ogłosiło aktualizację platformy Security Cloud Control, której głównym punktem jest wprowadzenie jednego panelu do zarządzania wieloma klientami jednocześnie.

Dla administratorów to oczywiście świetna wiadomość – koniec z przelogowywaniem się między kontami czy utrzymywaniem piętnastu otwartych zakładek. Warto jednak uczciwie zaznaczyć: Cisco w tym aspekcie goni rynek, a nie go wyznacza.

Konkurencyjne rozwiązania (jak choćby te od Fortinet czy chmurowe panele Sophos) oferują taką funkcjonalność od dawna. Dla Cisco to więc nie tyle innowacja, co nadrabianie długu technologicznego w zakresie User Experience.

Hybrydowy firewall i testy laboratoryjne

System opiera się na Hybrid Mesh Firewall i ma ułatwić wdrażanie spójnych polityk bezpieczeństwa zarówno w chmurze, jak i w lokalnych serwerowniach. Przy okazji firma chwali się nowym sprzętem:

Secure Firewall 200: budżetowa seria do małych oddziałów (dobry stosunek ceny do wydajności).
Secure Firewall 6100: seria pod centra danych, gotowa na obciążenia AI.

W nadesłanym do naszej redakcji komunikacie czytamy też, że skuteczność rozwiązań potwierdziła organizacja NetSecOPEN, wskazując na wyniki rzędu 99,5–100% wykrywalności. Brzmi imponująco, ale jak zawsze w przypadku sterylnych testów laboratoryjnych, zalecamy ostrożność. Benchmarki to jedno, a realne środowisko klienta – pełne niestandardowych konfiguracji i „dziurawego” softu – zweryfikuje te deklaracje szybciej niż jakakolwiek pieczątka.

Dla kogo to jest (a dla kogo nie)?

Żeby nie było wątpliwości – ta aktualizacja to ukłon w stronę dużych partnerów. Skorzystają z tego głównie dostawcy usług zarządzanych, którzy obsługują setki podmiotów i toną w logach. Dla nich konsolidacja narzędzi to realna oszczędność czasu.

Natomiast mniejsze firmy z własnym działem IT (tzw. single-tenant) raczej nie zauważą różnicy. Jeśli zarządzacie tylko własną infrastrukturą, to „rewolucyjne” zmiany w panelu MSP będą dla was kompletnie nieistotne.

Nowe funkcje mają być dostępne w lutym 2026 roku. Dobrze, że Cisco w końcu zauważyło problem ergonomii pracy swoich partnerów.

Rok 2026 według Cisco: Twój nowy kolega z biurka to algorytm

#b2b #Cisco #cyberbezpieczeństwo #firewall #MŚP #multitenancy #news #SecurityCloudControl

#b2b #cisco #cyberbezpieczenstwo #firewall #msp #multitenancy