Styr hanteringsarbetsflöde för IT-efterlevnad

Exempel från början till slut: RBAC-tillämpningskontroll

Följ hur Sarah, en efterlevnadsadministratör, skapar och hanterar en RBAC-kontroll (Role-Based Access Control) som uppfyller policyn för krav på lägsta behörighet, tillämpar organisationens dataåtkomstpolicy och minskar risken för överprivilegierad åtkomst.

Fas 1: Definiera kontroll och förfarande

Sarah börjar med att skapa en efterlevnadsprocess som heter Hantering av produktionsåtkomst. Denna procedur grupperar alla kontroller relaterade till hantering av åtkomsträttigheter i produktionssystem.

Enligt denna procedur skapar hon en efterlevnadskontroll som heter RBAC-kontroll. Kontrollens mål är att verifiera att alla användare av produktionssystemet har rollbaserade åtkomsträttigheter anpassade till deras jobbfunktioner och att ingen användare har överprivilegierad åtkomst till kunddata.

Sarah skapar en RBAC-kontroll av efterlevnadskontrollversion (v1.0) och dokumenterar kontrollens omfattning, frekvens (kvartalsvis) och förväntade bevis (skärmbilder av IAM-rolltilldelningar, CSV-exporter av användar-till-roll-mappningar).

Fas 2: Mappa kontrollen till föreskrifter, policyer och verksamhetsprocesser

Sarah mappar kontrollversionen till de poster den tillämpar och skyddar. Hon använder knutpunktsposter för att skapa spårbara länkar:

• Mappning av föreskrifter: Hon länkar kontrollversionen till policyn för regelklausulen Logisk och fysisk åtkomst med hjälp av en post för kontroll av efterlevnad av version av regelklausul. Denna mappning bevisar att kontrollen uppfyller det externa lagstadgade kravet.
• Policymappning: Hon länkar kontrollversionen till policyklausulen Dataåtkomst (RBAC med minsta behörighet) med hjälp av en post för Version för efterlevnadskontroll av efterlevnadspolicyklausul. Denna mappning visar att kontrollen tillämpar den interna policyn.
• Mappning av verksamhetsprocesser: Hon länkar kontrollversionen till verksamhetsprocessen Kunddatabearbetning med hjälp av en post för kontroll av efterlevnad av verksamhetsprocesser. Denna mappning visar att kontrollen skyddar organisationens kärnflöde för kunddata.
• Tillgångsmappning: Hon länkar kontrollversionen till de AWS-konton för produktion som spåras som tillgångar i CMDB. Denna mappning låter tillgångsägare se vilka efterlevnadskrav som gäller för deras system.

Fas 3: Länka kontrollen till de risker den minskar

Sarah har redan registrerat en efterlevnadsrisk som heter Överprivilegierad åtkomst till kunddata. Denna risk beskriver hotet att IT-personal kan få obehörig åtkomst till kunddata på grund av överdrivna behörigheter. Nu länkar hon kontrollen av efterlevnad av RBAC till denna risk för att visa hur kontrollen minskar riskens allvarlighetsgrad.

Hon skapar en post för Versionsrisk för efterlevnadskontroll som länkar kontrollversionen till risken. Hon tilldelar ett effektivitetsbetyg på 80 %, vilket indikerar att när kontrollen fungerar korrekt minskar den riskens påverkan med 80 %.

Om den inbyggda riskpoängen är 12 (Medelhög sannolikhet × Hög påverkan) och kontrolleffektiviteten är 80 % blir den återstående risken:

Residual Risk = 12 × (1 - 0.80) = 2.4 (Low)

Denna beräkning visar intressenterna att RBAC-kontrollen ger en betydande riskminskning. Om kontrollen senare misslyckas med ett test sjunker effektivitetsbetyget till 0 % och den återstående risken återgår till den inbyggda risknivån 12, vilket utlöser varningar och saneringsflöden.

Fas 4: Definiera och utför efterlevnadstester

Sarah skapar ett efterlevnadstest som heter Kvartalsvis RBAC-granskning.

Hon länkar testet till kontrollversionen med hjälp av en testpost för efterlevnadskontrollversion. Hon schemalägger testet att köras varje kvartal, med det första utförandet den 31 mars 2024.

När testet körs skapar systemet en post för Testkörning av efterlevnadskontrollversion med resultatet Godkänt. Utförandeposten samlar in dessa detaljer:

• Datum och tidpunkt för utförande
• Godkänt/underkänt resultat
• Insamlat bevis (skärmbilder av IAM-roller, CSV-export av användar-till-roll-mappningar)
• Testarens namn (om manuellt) eller ID för automatiserat testskript (om automatiserat)
• Observationer och anteckningar

Eftersom testet klarades förblir kontrollens effektivitetsbetyg 80 % och residualriskbetyget förblir 2,4 (Lågt). Teamet för efterlevnad är säkra på att kontrollen fungerar som den ska.

Fas 5: Kontroller Kanal till bevissamling

Under en granskning av efterlevnad skapar David, ansvarig för granskningsprogrammet, en bevisbegäran som heter Produktions RBAC-konfigurationsbevis. Han länkar bevisbegäran till kontrollversionen av RBAC:s tillämpningskontroll för att visa vilket skydd som granskas.

James, den som uppfyller bevis, samlar in de bevis som behövs och skickar in en bevisartefakt som inkluderar:

• Skärmbilder av IAM-rollkonfigurationer
• CSV-export av användar-till-roll-mappningar
• Skärmbilder av tillämpningsinställningar för MFA

När efterlevnadsgranskaren accepterar artefakten låses den omedelbart, vilket bevarar vårdnadskedjan för externa granskare. Artefakten länkas tillbaka till kontrollversionen, vilket skapar en spårbar anslutning från regleringskravet via kontrollen till det verifierade beviset som bevisar att kontrollen fungerar.

Fas 6: Kontrollfel utlöser avhjälpande

I Q2 körs testet RBAC-granskning kvartalsvis igen. Denna gång är resultatet Misslyckades. Testet upptäckte att tre användare i IT-driftteamet har administrativa åtkomsträttigheter som överskrider deras krav på jobbfunktioner.

I samma ögonblick som testet misslyckas sker flera saker automatiskt.

• Eftersom kontrollen misslyckades med sitt test återställs effektivitetsbetyget till 0 %.
• Verksamhetsregelmotorn omberäknar den återstående risken. Med 0 % kontrolleffektivitet återgår den återstående risken till den inneboende risknivån: Residual Risk = 12 × (1 - 0.00) = 12 (High). Risknivån hoppar från Låg till Hög.
• En agent för bakgrundsövervakning upptäcker kontrollfelet och skapar en Efterlevnadssökning.
• Maria, riskägaren för Överprivilegierad åtkomst, får en varning om att restriskbetyget har ökat från 2,4 till 12.

Sarah konverterar upptäckten till ett efterlevnadsproblem som kallas Överprivilegierade åtkomsträttigheter upptäckta i IT-opteam. Hon länkar problemet till kontrollversionen, risken, regleringsklausulen och policyklausulen. Hon tillämpar en färdig mall för åtgärdsplan för avhjälpande som innehåller uppgifter för att granska användaråtkomsträttigheter, återkalla överdrivna behörigheter och köra kontrolltestet igen.

Maria och hennes team slutför saneringsarbetet. De återkallar de överflödiga behörigheterna och kör RBAC-testet igen. Resultatet är: Godkänt. Kontrolleffektiviteten återställs till 80 % och residualriskbetyget sjunker tillbaka till 2,4 (Låg). Efterlevnadsproblemet avslutas med bevis på korrigering.

Fas 7: Kontinuerlig övervakning och kontrollutveckling

Sarah konfigurerar en agent för bakgrundsövervakning för att leta efter ändringar i miljön för produktionsåtkomstkontroll. Agenten lyssnar efter:

• Nya användare som lagts till i produktionssystem
• Ändringar av IAM-rolltilldelningar
• Uppdateringar av policyer för MFA-tillämpning
• Kontrollera testfel

När agenten upptäcker en relevant ändring utlöser den automatiskt en ny riskbedömning och meddelar riskägaren. Om ändringen representerar en potentiell kontrollsvaghet kan agenten skapa en proaktiv upptäckt innan kvartalstestet körs.

Sex månader senare ändras efterlevnadskravet till att kräva kontinuerlig övervakning istället för kvartalsvisa tester. Sarah klonar kontrollversionen för att skapa v2.0, uppdaterar testfrekvensen från kvartal till månad och drar tillbaka v1.0. Den nya versionen ärver alla mappningar till föreskrifter, policyer, risker, verksamhetsprocesser och tillgångar från v1.0, vilket bevarar granskningsloggen samtidigt som den anpassas till nya krav.