Richtlijnen voor het gebruik van Azure Database for PostgreSQL in een multitenant-oplossing

Veel multitenant-oplossingen in Azure maken gebruik van het opensource-relationele databasebeheersysteem Azure Database for PostgreSQL. In dit artikel worden de functies van Azure Database for PostgreSQL beschreven die handig zijn wanneer u met multitenant-systemen werkt. Het artikel bevat ook koppelingen naar richtlijnen en voorbeelden voor het gebruik van Azure Database for PostgreSQL in een multitenant-oplossing.

Implementatieopties

De volgende opties zijn beschikbaar voor Azure Database for PostgreSQL en zijn geschikt voor gebruik met multitenant-toepassingen:

  • Azure Database for PostgreSQL is een goede keuze voor de meeste multitenant-implementaties die geen hoge schaalbaarheid vereisen die Azure Cosmos DB voor PostgreSQL biedt.

  • Azure Database for PostgreSQL elastische clusters biedt horizontaal schalen binnen een beheerde service. Het is geschikt voor multitenant-toepassingen die moeten schalen van een paar naar veel tenants.

  • Azure Cosmos DB for PostgreSQL is een door Azure beheerde databaseservice die is ontworpen voor oplossingen waarvoor een hoge schaal is vereist, zoals multitenant-toepassingen. Deze service maakt deel uit van de Azure Cosmos DB-serie producten.

    Belangrijk

    Azure Cosmos DB for PostgreSQL bevindt zich op een buitengebruikstellingspad en wordt niet meer aanbevolen voor nieuwe projecten.

Azure Database for PostgreSQL-functies die ondersteuning bieden voor multitenancy

Wanneer u Azure Database for PostgreSQL gebruikt om een multitenant-toepassing te bouwen, kunnen de volgende functies uw oplossing verbeteren.

Notitie

Sommige functies zijn alleen beschikbaar in specifieke implementatieopties. In de volgende richtlijnen wordt beschreven welke functies beschikbaar zijn.

Beveiliging op rijniveau

Beveiliging op rijniveau is handig voor het afdwingen van isolatie op tenantniveau wanneer u gedeelde tabellen gebruikt. In PostgreSQL implementeert u beveiliging op rijniveau door rijbeveiligingsbeleid toe te passen op tabellen om de toegang tot rijen per tenant te beperken.

Het implementeren van beveiliging op rijniveau in een tabel kan van invloed zijn op de prestaties. Mogelijk moet u andere indexen maken voor tabellen waarvoor beveiliging op rijniveau is ingeschakeld om ervoor te zorgen dat de prestaties niet worden beïnvloed. Wanneer u beveiliging op rijniveau toepast, is het belangrijk om prestatie-testhulpmiddelen te gebruiken om te valideren dat uw workload aan de basisprestatievereisten voldoet.

Zie Access-beheer voor Azure Database voor PostgreSQL voor meer informatie over beveiliging op rijniveau.

Tenantcontext voor beveiliging op rijniveau

Beveiligingsbeleid op rijniveau vereist toegang tot de huidige tenant-id. Azure Database for PostgreSQL biedt twee extensies waarmee u tenantcontext kunt beheren:

  • session_variable: biedt variabelen met sessiebereik die u kunt gebruiken om de tenant-id in een sessie op te slaan en op te halen. Gebruik deze variabelen in uw beveiligingsbeleid op rijniveau.
  • login_hook: voert een functie uit tijdens de aanmelding. Gebruik deze extensie om automatisch de tenantcontext in te stellen wanneer er een verbinding tot stand wordt gebracht.

Zie Extensions en extensieversies voor Azure Database for PostgreSQL voor meer informatie.

Horizontaal schalen met sharding

Met het Sharding-patroon kunt u uw workload schalen op meerdere databases of databaseservers.

Oplossingen die een hoog schaalniveau nodig hebben, kunnen Gebruikmaken van Azure Cosmos DB voor PostgreSQL. Deze implementatiemodus maakt horizontale sharding van tenants mogelijk op meerdere servers of knooppunten. Gebruik gedistribueerde tabellen in multitenant-databases om ervoor te zorgen dat alle gegevens voor een tenant op hetzelfde knooppunt worden opgeslagen. Deze aanpak verbetert de prestaties van query's.

Zie de volgende artikelen voor meer informatie:

Elastische clusters

Elastische clusters zijn een functie van Azure Database for PostgreSQL. Ze bieden horizontale schaalmogelijkheden binnen één beheerde service. Deze implementatieoptie maakt gebruik van gedistribueerde tabelfunctionaliteit voor workloads met meerdere tenants waarvoor uitschaalmogelijkheden zijn vereist.

In multitenant-oplossingen maken elastische clusters sharding van tenantgegevens mogelijk op meerdere knooppunten. Elastische clusters ondersteunen twee shardingmodellen:

  • Op rij gebaseerde sharding: U kunt tabellen distribueren op Tenant ID om ervoor te zorgen dat tenantgegevens op specifieke knooppunten worden geclusterd. Deze benadering kan de queryprestaties voor tenantspecifieke query's verbeteren, maar vereist dat query's de distributiekolom bevatten.
  • Op schema gebaseerde sharding: U kunt tenants isoleren met behulp van een afzonderlijk schema per tenant. Deze methode is ideaal voor ISV's die toepassingen implementeren die geen querywijzigingen kunnen ondergaan om sharding op basis van rijen te ondersteunen. Sharding op basis van schema's is geschikt voor workloads met tussen 1 en 10.000 tenants.

Zie de volgende artikelen voor meer informatie:

Groepsgewijze verbinding

Postgres maakt gebruik van een procesmodel voor verbindingen. Dit model maakt het inefficiënt om grote aantallen niet-actieve verbindingen te onderhouden. Voor sommige multitenant-architecturen zijn veel actieve verbindingen vereist, wat de prestaties van de Postgres-server negatief beïnvloedt.

Verbindingspooling via PgBouncer wordt standaard geïnstalleerd in Azure Database for PostgreSQL.

Zie de volgende artikelen voor meer informatie:

Microsoft Entra-verificatie

Azure Database for PostgreSQL ondersteunt verbindingsverificatie met behulp van Microsoft Entra ID. Met deze functie kunnen applicatieworkloads in een multitenantomgeving zich authentiseren bij de database met behulp van een tenantspecifieke service-principal of beheerde identiteit. De toegang tot de database kan worden beperkt tot een afzonderlijke tenant. Door Microsoft Entra ID-verificatie te combineren met tenantspecifiek rijbeveiligingsbeleid, kunt u het risico beperken dat een toepassing toegang heeft tot de gegevens van een andere tenant vanuit een database met meerdere tenants.

Zie de volgende artikelen voor meer informatie:

Azure Confidential Computing

Azure Database for PostgreSQL biedt ondersteuning voor Azure confidential computing via vertrouwde uitvoeringsomgevingen (TEE's), die beveiliging op basis van hardware bieden voor gegevens die in gebruik zijn. Met deze functie worden tenantgegevens beschermd tegen onbevoegde toegang door het besturingssysteem, de hypervisor of andere toepassingen.

Voor oplossingen met meerdere tenants die gevoelige gegevens verwerken, biedt confidential computing bescherming op hardwareniveau tijdens de verwerking. Gebruik vertrouwelijke computing wanneer tenants strikte vereisten voor gegevensbescherming of nalevingsvereisten voor regelgeving hebben of wanneer u ervoor moet zorgen dat de toepassingsprovider geen toegang heeft tot tenantgegevens.

Voor meer informatie, zie Azure confidential computing voor Azure Database for PostgreSQL.

Encryptie

Gegevens die zijn opgeslagen in Azure Database for PostgreSQL worden standaard versleuteld met behulp van door Microsoft beheerde sleutels, maar u kunt ook door de klant beheerde sleutels (CMK's) gebruiken om tenants toe te staan hun eigen versleutelingssleutels op te geven.

Wanneer u CMK's gebruikt, kunt u uw eigen versleutelingssleutels opgeven die zijn opgeslagen in Azure Key Vault. In omgevingen met meerdere tenants kunt u met deze methode verschillende versleutelingssleutels gebruiken voor verschillende tenants, zelfs wanneer hun gegevens worden opgeslagen op dezelfde databaseserver. Deze mogelijkheid biedt tenants ook controle over hun eigen versleutelingssleutels. Als een tenant ervoor kiest om het account te deactiveren, zorgt het verwijderen van de bijbehorende sleutel ervoor dat hun gegevens niet meer toegankelijk zijn.

Azure Database for PostgreSQL ondersteunt updates van automatische sleutelversies voor CMK's. Deze functie wordt automatisch bijgewerkt naar nieuwe sleutelversies na rotatie in Key Vault en vereist geen handmatig beheer van sleutelversies. In omgevingen met meerdere tenants waarbij naleving van regelgeving regelmatig sleutelrotatie vereist, vermindert deze automatisering handmatige operationele taken en onderhoudt deze gegevensbescherming zonder onderbreking van de service.

Bijdragers

Microsoft onderhoudt dit artikel. De volgende inzenders hebben dit artikel geschreven.

Hoofdauteur:

Andere Inzenders:

  • John Downs | Principal Software Engineer, Azure Patterns & Practices
  • Arsen Vladimirskiy | Principal Customer Engineer, FastTrack voor Azure
  • Paul Burpo | Principal Customer Engineer, FastTrack voor Azure ISV's
  • Assaf Fraenkel | Senior Engineer/Data Architect, Azure FastTrack voor ISV's en start-ups

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.