Rechten op uitsluitend een secondary database

Posted on by

In log shipping omgevingen bestaat regelmatig de wens om een (service-)account
uitsluitend leesrechten te geven op de secondary database, terwijl dit account
geen toegang mag hebben tot de primary database.
Typische use-cases zijn rapportages, exports of monitoring die bewust buiten
de productieomgeving worden gehouden.

SQL Server Log Shipping leent zich hier goed voor, omdat een log shipping secondary
geen automatische failover kent. Een eventuele promotie van de secondary
naar primary gebeurt altijd handmatig en bewust, wat deze inrichting
goed beheersbaar maakt.

Uitgangspunten

  • Log Shipping is een Disaster Recovery mechanisme, geen High Availability oplossing
  • De secondary database staat in STANDBY / READ ONLY modus
  • Er vindt geen automatische rolwissel plaats tussen primary en secondary
  • Deze inrichting is bedoeld voor leesgeoriënteerde, niet-kritische workloads

Technische achtergrond

Bij SQL Server Log Shipping gelden de volgende technische eigenschappen:

  • Database-objecten en database-rechten worden doorgezet via transaction log restores
  • Logins zijn server-level objecten en worden niet meegenomen in log shipping
  • Toegang wordt bepaald door:
    • de status van de login (enabled / disabled)
    • de aanwezigheid van een database user

Dit onderscheid maakt het mogelijk om toegang functioneel te beperken tot uitsluitend
de secondary database.

De inrichting

Stap 1 – Maak een Active Directory service account aan

Gebruik één vast AD-account dat bedoeld is voor rapportage- of leesdoeleinden.

Stap 2 – Maak de login aan op beide SQL Servers

Maak dezelfde login aan op:

  • De primary SQL Server instance
  • De secondary SQL Server instance

Omdat het om een AD-account gaat, is de SID op beide servers gelijk.

Stap 3 – Maak een database user aan in de primary database

  • Koppel de database user aan de login
  • Geef uitsluitend db_datareader rechten

Deze database-rechten worden via log shipping automatisch doorgezet naar
de secondary database.

Stap 4 – Disable de login op de primary SQL Server

Door de login te disablen op de primary SQL Server:

  • kan het account niet verbinden met de primary instance
  • blijven de database-rechten wel bestaan

Stap 5 – Laat de login enabled op de secondary SQL Server

Op de secondary SQL Server blijft de login enabled, waardoor:

  • verbinding met de secondary database mogelijk is
  • alleen leesacties kunnen worden uitgevoerd

Resultaat

  • Het account heeft leesrechten op de secondary database
  • Het account kan niet verbinden met de primary database
  • Rapportage- en leesprocessen zijn gescheiden van productie
  • De inrichting blijft overzichtelijk en beheersbaar

Beheer en aandachtspunten

Wanneer een log shipping secondary handmatig wordt gepromoveerd tot primary
(bijvoorbeeld in een DR-situatie), is het belangrijk om:

  • de status van de login opnieuw te beoordelen
  • expliciet te bepalen of het account toegang mag behouden

Omdat dit een bewuste beheeractie is, kan dit eenvoudig worden opgenomen
in bestaande DR-procedures.

Conclusie

Binnen een log shipping omgeving is het technisch en operationeel goed
verdedigbaar om een account uitsluitend toegang te geven tot de secondary database
door het combineren van database-rechten met een gecontroleerde login-status.

Deze oplossing past bij de aard van log shipping als DR- en reporting-mechanisme
en biedt een praktische en veilige scheiding tussen productie en leesworkloads,
zonder de complexiteit van Always On Availability Groups.