Scenario 2-lösning – Verksamhetskritiskt program
I föregående lektion arbetade du med ett scenario som innefattade hög tillgänglighet för ett nödnummersystem. I den här lektionen granskar du en potentiell lösning och några element att överväga.
Under granskningen bör du jämföra den lösning som tillhandahålls med den som du utvecklade i föregående lektion. Det finns vanligtvis mer än en korrekt lösning på problemen och det krävs nästan alltid kompromisser. Vilka element i din lösning skiljer sig från det föreslagna? Finns det något i din lösning som du kan tänka annorlunda kring? Finns det något i den tillhandahållna lösningen som du tycker är mer noggrant utformat i din lösning?
Distributionsalternativ och konfiguration
Den första uppgiften är ofta att se vilket alternativ för Azure SQL-distributionen som kan vara mest lämpligt. Om du endast vill ha serviceavtal (SLA) måste kravet vara ett serviceavtal på 99,995 procent, vilket bara Azure SQL Database kan erbjuda. För att få detta serviceavtal måste du distribuera den affärskritiska tjänstnivån och aktivera användningen av tillgänglighetszoner.
En annan uppsättning beslut handlar om hur du skapar geo-redundans och upprätthåller hög tillgänglighet under haverier. Även om både geo-replikering och automatiska redundansgrupper är alternativ här, kommer kunden med automatiska redundansgrupper att kunna redundansväxla om det behövs, utan att behöva ändra några anslutningssträngar. Den här installationen kan potentiellt minska stilleståndstiden vid uppdatering av programmens anslutningssträngar, eftersom det inte behövs. Du kan också konfigurera övervakningsfrågor om du vill kunna kontrollera statusen. Du kan då framtvinga en redundansväxling om något fel uppstår.
I den här konfigurationen är det också viktigt att tänka på vad samlokalisering kan innebära. För att upprätthålla hög tillgänglighet måste ditt program vara så nära databasen som möjligt, i alla fall i samma region. Du bör se till att ditt program är distribuerat i båda regionerna i gruppen för automatisk redundans, så att en redundant kopia av programmet (till exempel en webbapp) finns. Om det sker en redundansväxling kan du använda Azure Traffic Manager för att omdirigera trafiken till programmet i den sekundära regionen.
Databasadministratörer och känsliga data
Koordinatorerna för dirigeringssystemet för nödnumret har uttryckt oro för hur man kan skydda känsliga data (t.ex. hälsohistorik och annan personlig information) och samtidigt tillåta databasadministratörerna att utföra sina jobb.
För att säkerställa att DBA:erna inte kan se känsliga data som lagras i vissa kolumner och att all åtkomst till tabeller som innehåller känsliga data övervakas, finns det några Azure SQL-tekniker som kan användas. SQL Audit är en bra metod för att övervaka åtkomst, men DBA:erna kommer fortfarande att kunna se datan. Att klassificera känsliga data med dataklassificering kan vara användbart, eftersom känsliga data etiketteras och du kan spåra dem med SQL Audit. Men med dessa metoder implementerade kommer DBA:erna fortfarande att kunna se känsliga data. Du kan använda dynamisk datamaskering för att maskera känsliga data, men det går inte att hindra att en db_owner ser användardata med enbart behörigheter.
Om det finns mycket känsliga data i en databas, kan Always Encrypted användas för att på ett säkert sätt förhindra att db_owners ser den. Du kan hantera Always Encrypted-nycklarna med rollseparering, så att säkerhetsadministratören inte har åtkomst till databasen och DBA:n inte har åtkomst till de fysiska nycklarna i klartext. Genom att använda den här strategin i kombination med övervakning med SQL Audit kan du övervaka, maskera och spåra åtkomst till känsliga data, även från DBA:er med db_owner-behörighet.
DBA:er måste kunna ha maskerade känsliga data, men de måste ändå kunna felsöka prestandan med hjälp av Azure-portalen, SQL Server Management Studio och Azure Data Studio. Och de måste kunna skapa nya inneslutna databasanvändare som måste mappas till Microsoft Entra-huvudnamn.
En lösning är att skapa en Microsoft Entra-grupp med namnet SQL DBA för dbas på varje instans. Tilldela sedan gruppen till den Azure-rollbaserade åtkomstkontrollen (RBAC) i rollen SQL-serverdeltagare. Slutligen kan du ange att gruppen ska vara Microsoft Entra-administratör på den logiska servern.