Scenario 2-oplossing - Bedrijfskritieke toepassing
In de vorige eenheid werkte u met een scenario met hoge beschikbaarheid voor een 911-verzendsysteem. In dit gedeelte beoordeelt u één potentiele oplossing en een aantal andere items waarmee u rekening moet houden.
Tijdens de beoordeling moet u de aangeboden oplossing vergelijken met de oplossing die u in het vorige gedeelte hebt ontwikkeld. Vaak bestaan er meerdere oplossingen voor een probleem: wat zijn de belangrijkste verschillen. Welke items van uw oplossing wijken af van de voorgestelde oplossing? Is er iets aan uw oplossing dat u zou willen aanpassen? Is iets aan de aangeboden oplossing waarvan u denkt dat het beter is uitgewerkt in uw oplossing?
Implementatieoptie en -configuratie
Het eerste wat u moet doen in het aanpakken van een scenario is vaak om te identificeren welke optie voor Azure SQL-implementatie het beste bij u past. Als u alleen een service level agreement (SLA) overweegt, is een SLA van 99,995 procent vereist, die momenteel alleen wordt aangeboden door Azure SQL Database. Als u deze SLA wilt ophalen, moet u de bedrijfskritische servicelaag implementeren en het gebruik van beschikbaarheidszones inschakelen.
Een andere reeks beslissingen is gerelateerd aan het inschakelen van geo-redundantie en het behouden van hoge beschikbaarheid in noodgevallen. Hoewel de groepen geo-replicatie en auto-failover hier beide opties zijn, kunnen groepen voor automatische failover de klant in staat stellen om een failover uit te voeren als dit nodig is, zonder verbindingsreeksen te wijzigen. Deze installatie kan u helpen bij het verminderen van downtime voor het bijwerken van verbindingsreeksen van de toepassingen, omdat dit niet nodig is. U kunt ook bewakingsquery's configureren om de status te controleren. Op die manier kunt u zelfs een failover afdwingen als er iets fout gaat.
In deze configuratie, moet u ook nadenken over de rol van colocatie. Om hoge beschikbaarheid te behouden, moet uw toepassing zich zo dicht mogelijk bij de database worden bevinden, in ieder geval in dezelfde regio. U wilt er zeker van zijn dat uw toepassing wordt geïmplementeerd in beide regio's van de groep voor automatische failover, waardoor er een redundante kopie van de toepassing (bijvoorbeeld een web-app) bestaat. Als er een failover is, kunt u Azure Traffic Manager gebruiken om verkeer door te sturen naar de toepassing in de secundaire regio.
DBA's en gevoelige gegevens
De coördinatoren van het 911-oproepsysteem de hebben hun bezorgdheid geuit voor de bescherming van gevoelige gegevens (zoals medische historie en andere persoonsgegevens), terwijl DBA's hun taken uitvoeren.
Om ervoor te zorgen dat DBA's geen gevoelige gegevens kunnen zien die zijn opgeslagen in specifieke kolommen en dat alle toegang tot tabellen met gevoelige gegevens moet worden bewaakt, kunt u enkele Azure SQL-technologieën gebruiken. Het gebruik van SQL Audit is een aanbevolen procedure om de toegang te bewaken, maar DBA's kunnen de gegevens nog steeds zien. Het classificeren van gevoelige gegevens met gegevensclassificatie helpt, omdat de gevoelige gegevens worden gelabeld en u deze kunt volgen met SQL Audit. Als deze zijn geïmplementeerd, kunnen DBA's echter nog steeds gevoelige gegevens zien. Dynamische gegevensmaskering kan worden gebruikt om te helpen bij het maskeren van gevoelige gegevens, maar het is niet mogelijk om in te stellen dat een db_owner gebruikersgegevens alleen met machtigingen kan weergeven.
Als er zeer gevoelige gegevens in een database staan, kan Always Encrypted worden gebruikt om veilig te voorkomen dat zelfs db_owners deze te zien krijgen. U kunt de Always Encrypted-sleutels beheren met functiescheiding, zodat de beveiligingsbeheerder geen toegang krijgt tot de database, en de DBA geen toegang krijgt tot de fysieke sleutels in niet-versleutelde tekst. Door deze strategie te gebruiken in combinatie met bewaking met SQL Audit kunt u de toegang tot gevoelige gegevens bewaken, maskeren en bijhouden, zelfs van DBA's met db_owner-rechten.
Terwijl DBA's gevoelige gegevens moeten maskeren, moeten ze tegelijkertijd de prestatieproblemen kunnen oplossen met behulp van Azure Portal en SQL Server Management Studio of Azure Data Studio. En ze moeten nieuwe ingesloten databasegebruikers kunnen maken die moeten worden toegewezen aan Microsoft Entra-principals.
Eén oplossing is het maken van een Microsoft Entra-groep met de naam SQL DBA voor de DBA's op elk exemplaar. Wijs vervolgens de groep toe aan de rol op rollen gebaseerd toegangsbeheer van Azure (RBAC) van Inzender voor SQL Server. Ten slotte kunt u de groep instellen als de Microsoft Entra-beheerder op de logische server.