Konfigurera Surfing och Network Traffic Quota på Sophos Firewall

En Surfing quota begränsar den användbara internettiden för en autentiserad användare. En Network traffic quota begränsar i stället mängden överförda data. Båda policyerna tilldelas en användare eller grupp och passar exempelvis för utbildningslokaler, gäster eller tydligt definierade användningspaket.

För tillfälliga gäster planeras kontoskapande, giltighet, Captive Portal och rensning separat. Hela livscykeln beskrivs i Skapa och hantera gästanvändare säkert i Sophos Firewall; den här artikeln fokuserar på kvoterna.

Snabbvägen för ett kontrollerat införande är:

1. Fastställ om tidsförbrukning, datamängd eller båda ska begränsas.
2. Skapa en ny pilotpolicy under Profiles > Surfing quota respektive Profiles > Network traffic quota.
3. Tilldela policyn till en liten pilotgrupp under Authentication > Groups eller till en enskild testanvändare under Authentication > Users.
4. Autentisera användaren på nytt och kontrollera den identifierade identiteten under Current activities > Live users.
5. Använd en användarbaserad brandväggsregel med Log firewall traffic för testet.
6. Öppna användaren under Authentication > Users och kontrollera förbrukningen med View usage.
7. Testa gränsen, nästa cykel och rollback innan fler användare läggs till.

⚠️ Reset user accounting återställer både förbrukad surftid och nätverkstrafikräknarna. Det är en tillståndsändring och inte en allmän diagnosknapp. Före en återställning dokumenteras användare, aktuella värden, tidpunkt och orsak. En delad produktionskvot ändras inte heller direkt; en separat pilotpolicy används för tester.

Välj den funktion som passar kravet

Fyra funktioner med liknande namn löser olika uppgifter:

• Access Time tillåter eller blockerar användare under fasta tidsfönster. Den räknar ingen förbrukning.
• Surfing quota ger en användare en förbrukningsbar tidskvot för internetåtkomst.
• Network traffic quota ger en användare en förbrukningsbar datakvot.
• Traffic Shaping begränsar eller prioriterar bandbredd. En låg datahastighet är inte en datakvot.

Dessutom erbjuder en Web Policy åtgärden Quota för tidsbegränsad åtkomst till vissa webbkategorier. Denna Policy Quota hör till webbproxylogiken och är inte samma funktion som den användarbaserade Surfing Quota som beskrivs här.

En kvot skapar varken en brandväggsregel eller en användaridentitet. Brandväggen måste identifiera användaren, nätverkssökvägen måste vara tillåten och testtrafiken måste matcha den förväntade regeln. Först då kan kvoten verifieras på ett meningsfullt sätt.

För den separata kvoten för webbkategorier visar Policy quota status återstående tid per användare och Web Policy inom en 24-timmarsperiod. För en godkänd återställning väljer man berörda användare där och sedan Reset. Dokumentera först användare, policy och återstående tid; kontrollera efteråt visningen och en tillåten testbegäran. Blanda inte ihop denna återställning med Reset user accounting: en förbrukad webbkategorikvot är inte skäl att nollställa användarens surf- och dataräknare.

Planera exempel och förutsättningar

Det genomgående exemplet använder en liten pilotgrupp med två separata policyer:

• Grupp: Quota_Pilot
• Testanvändare: quota-pilot
• Surfing Quota: Students_InternetTime
• Cycle type: Cyclic (repeat access)
• Cycle hours: 24
• Maximum access time: 02:00
• Network Traffic Quota: Students_DataVolume
• Restriction: Total network traffic
• Cycle type: Cyclic
• Cycle period: Day
• Quota per cycle: 5000 MB
• Maximum quota: Unlimited

Värdena är avsiktligt små dokumentationsexempel: varje 24-timmarscykel ger två timmars internettid och varje dag 5000 MB datamängd. Namn, tid, datamängd, cykel och totalgräns anpassas till den faktiska användningsöverenskommelsen. Små testgränser får inte kopieras till en ren produktionspolicy utan att deras effekt först kontrolleras.

Före konfigurationen kontrolleras följande:

1. Pilotanvändaren kan logga in med den avsedda autentiseringsmetoden.
2. Användarnamn och källadress visas under Current activities > Live users.
3. För AD-användare är fältet Group under Authentication > Users korrekt.
4. En lämplig användarbaserad brandväggsregel tillåter testtrafiken och har Log firewall traffic aktiverat.
5. Befintliga tilldelningar för Surfing quota, Network traffic, Access time och Traffic shaping är dokumenterade.
6. Det tidigare läget och en alternativ testanvändare är kända.

Om användaren inte visas som Live User korrigeras autentiseringen först. En kvot kan inte tillförlitligt koppla okänd eller enbart IP-baserad trafik till en normal användarkvot.

Skapa en Surfing Quota

En Surfing Quota räknar förbrukad internettid. I hjälpen för SFOS 22 dokumenteras samma objekt både under Profiles > Surfing quota och Web > Surfing quotas. Använd den ingång som WebAdmin visar i den installerade builden.

Även befintliga standardkvoter kan användas; öppna en befintlig Surfing Quota med Edit. Ta hänsyn till påverkan på alla tilldelade användare och grupper.

Välj Cyclic eller Non-cyclic

• Cyclic (repeat access): Tidskvoten görs tillgänglig på nytt i återkommande cykler. Outnyttjad tid förs inte över till nästa cykel.
• Non-cyclic (one-time access): Tidskvoten tillhandahålls en gång. När den är förbrukad kopplas användaren från.

Dessutom begränsar Validity period hur många dagar policyn är giltig. Maximum access time anger den användbara tiden. När maxvärdet nås kopplas användaren från även om kvotens giltighetstid ännu inte har löpt ut.

Om flera Surfing Quotas gäller för en användare begränsar brandväggen åtkomsten så snart den första av dessa policyer når sin gräns. Kontrollera därför alla direkta och gruppbaserade kvottilldelningar tillsammans; en generösare andra policy upphäver inte en gräns som redan har nåtts.

Unlimited för Maximum access time tar endast bort gränsen för förbrukad tid, inte den separat inställda giltigheten. För obegränsad användning som beviljas en gång under en vecka väljer man exempelvis Non-cyclic (one-time access), ställer in Validity period på 7 dagar och Maximum access time på Unlimited. Detta är ett annat krav än två timmar per 24-timmarscykel.

För pilotexemplet:

1. Öppna Profiles > Surfing quota > Add. Om builden visar funktionen under Web > Surfing quotas, välj Add där.
2. Ange Students_InternetTime som Name.
3. Ange exempelvis Pilot: 2h per 24h, Owner IT som Description.
4. Ställ in Cycle type på Cyclic (repeat access).
5. Ställ in Cycle hours på 24.
6. Ange medvetet en Validity period för piloten eller välj Unlimited endast om ingen utgångsgräns behövs.
7. Ställ in Maximum access time på 02:00.
8. Spara med Save.

Den sparade policyn har ännu ingen effekt. Först när den tilldelas en användare eller grupp kopplas tidskvoten till en identitet.

SurfingQuotaPolicy i XML API

För automatisering heter den användarbaserade tidskvoten SurfingQuotaPolicy. Den är varken en Network Traffic Quota eller åtgärden Quota i en Web Policy. Åtkomstskydd, explicita skrivoperationer och skillnaden mellan HTTP-transport och XML-resultat förklaras i Säkra åtkomsten till XML API. Spara det exakta objektnamnet, alla sparade värden samt användar- och grupptilldelningar före en ändring; redigera endast en separat pilotpolicy.

XML-referenserna för SFOS 22.0 och 23.0 anger följande fält. Detta är dokumenterade uppgifter, inte en serialisering som har testats på en brandvägg:

• Name är obligatoriskt: sträng, högst 60 tecken, inget kommatecken; UTF-8 är tillåtet. Detta gäller även för Delete Surfing Quota Policy. Description är valfritt och begränsat till 255 tecken. Kolumnen för standardvärden anger inga värden för dessa fält; dra inte slutsatser om standardvärden vid körning utifrån detta.
• CycleType visas i mallen som Cyclic/NonCyclic; i en begäran ska exakt ett bekräftat värde väljas, inte uttrycket med snedstreck. Parametertabellen anger dock samtidigt sträng och intervallet 1–87840. Flytta inte denna motsägelsefulla intervalluppgift till ett annat fält och tolka den inte som en numerisk kodning av cykeln.
• CycleHours beskrivs som en valfri sträng för cykeltimmar, utan numeriskt intervall. CycleMinutes beskrivs som ett obligatoriskt fält av typen Integer med högst fyra siffror. Detta innebär framför allt inte att intervallet 0–59 är bekräftat för detta fält. Mallen innehåller dessutom PerDay med Days/Weekly/Monthly/Yearly, men parametertabellen förklarar inte detta fält. Räkna därför inte om UI-inställningen Cycle hours och pilotens cykellängd till dessa XML-fält utan föregående kontroll.
• För begränsad giltighet beskrivs Validity som en sträng med 0–3660 dagar. MaximumHours beskriver ett begränsat totalt antal surftimmar som en sträng med högst sju tecken; Minutes är det extra minutvärdet som en sträng i intervallet 0–59. Giltighet i dagar och förbrukningsbar tid i timmar/minuter förblir separata gränser; giltigheten är inget tidssaldo.

Ett fältutdrag med begränsade värden, uttryckligen inte en fullständig begäran eller en begäran som är klar att skickas, visar den sistnämnda åtskillnaden:

<Validity>7</Validity>
<MaximumHours>2</MaximumHours>
<Minutes>0</Minutes>

Exempelvärdena står för sju dagars giltighet och två timmars total surftid utan extra minuter. De visar inte den fullständiga implementeringen av den cykliska UI-piloten ”två timmar per 24 timmar”. Cykelfält, tilldelning och explicit operation saknas avsiktligt. Dagar och tidsbudget väljs utifrån den godkända användningsöverenskommelsen; för den fullständiga serialiseringen ska först API help för den installerade builden jämföras med ett pilotobjekt som har hämtats genom läsning.

För obegränsade värden visar mallen för Validity och MaximumHours texten Unlimited/{Days}; separata tabellrader för Validity och Maximum Hours anger däremot -11 och den tomma strängen ''. Detta bekräftar inte att dessa skrivsätt är utbytbara, att tomma fält bevarar befintliga värden eller att Maximum Hours med mellanslag är en XML-tagg. Beskrivningen av timmar stämmer dessutom inte med platshållaren {Days} vid MaximumHours. Så länge cykelrepresentationen eller Unlimited-kodningen är oklar ska ingen skrivbegäran skickas, och ett build-specifikt klargörande ska begäras.

Kontrollera svar före ett nytt skrivförsök

För Add Surfing Quota Policy, Edit Surfing Quota Policy och Delete Surfing Quota Policy hör operation, XML-kod och referenssymbol ihop. Referenserna för SFOS 22.0 och 23.0 innehåller samma kopplingar:

Message.* är här ordagranna, oupplösta nycklar från referensen, inte verifierade meddelanden vid körning. Ett lyckat HTTP-anrop innebär inte att XML-operationen har lyckats. Inte heller XML-koden 200 ersätter en efterföljande läsning av det sparade målobjektet: namn, cykel, giltighet, timmar och minuter måste stämma med det godkända önskade läget. Först därefter ska tilldelningen och effekten valideras med View usage, en ny inloggning och det begränsade förbruknings- och gränstestet i denna artikel; enbart sparandet bevisar inte att begränsningen tillämpas.

Vid 500, 502, 504, ett oklart svar eller en timeout ska först det rensade svaret sparas och det faktiska objekttillståndet läsas innan något nytt försök övervägs. Vid 502 ska det kontrolleras om det önskade objektet eller ett annat objekt redan finns sparat under det exakta namnet; växla inte automatiskt från Add till Edit. Vid Delete med 504 ska befintliga referenser och användar-/grupptilldelningar kontrolleras; ta inte bort beroende regler på chans. Före en godkänd borttagning ska tilldelningar migreras kontrollerat och beroenden kontrolleras på nytt. Bekräfta därefter att exakt pilotpolicyn saknas och att de tidigare tjänsterna fortfarande fungerar. En felkod bevisar varken att tillståndet är oförändrat eller att ett nytt försök är riskfritt. En accounting-återställning är inte en rollback för en API-uppdatering eller en borttagning.

Skapa en Network Traffic Quota

En Network Traffic Quota räknar mängden överförda data. Den begränsar inte hastigheten. En användare kan därför förbruka kvoten snabbt eller långsamt; om en bandbreddsgräns behövs planeras dessutom en lämplig Traffic Shaping-policy.

Begränsa total trafik eller uppladdning och nedladdning separat

• Total network traffic: En gemensam kvot räknar uppladdning och nedladdning tillsammans.
• Individual network traffic (Upload & download): Uppladdning och nedladdning får separata gränser. Detta passar endast när kravet faktiskt behandlar riktningarna var för sig.

Det finns även två cykelmodeller:

• Cyclic: Kvoten gäller per vald cykel. Tillgängliga perioder är Day, Week, Month och Year. Outnyttjad datamängd förs inte över.
• Non-cyclic: Kvoten gäller för en enda cykelperiod.

Quota per cycle anger kvoten för varje cykel. En valfri Maximum quota lägger till en totalgräns och måste vara högre än cykelkvoten. När cykel- eller totalgränsen är förbrukad kopplar brandväggen från användaren. För en ny anslutning före den ordinarie återställningen krävs Reset user accounting.

För pilotexemplet:

1. Öppna Profiles > Network traffic quota > Add.
2. Ange Students_DataVolume som Name.
3. Ange exempelvis Pilot: 5000 MB per day, Owner IT som Description.
4. Ställ in Restriction på Total network traffic.
5. Ställ in Cycle type på Cyclic.
6. Ställ in Cycle period på Day.
7. Ställ in Quota per cycle på 5000 MB.
8. Låt Maximum quota vara Unlimited i detta återkommande exempel. Om en totalgräns behövs måste den vara högre än cykelkvoten.
9. Spara med Save.

5000 MB är ett inmatningsvärde för exemplet, inte ett obligatoriskt värde eller ett konverteringsstöd. I en verklig policy härleds värdet från den godkända kvoten och anges i den enhet som WebAdmin förväntar sig. En separat uppladdnings-/nedladdningspolicy får i stället egna motiverade värden för båda riktningarna.

Det finns även standardpolicyer för Network Traffic; öppna befintliga policyer med Edit. För en ändlig Maximum quota avmarkerar man motsvarande Unlimited-kryssruta och anger ett värde över cykelkvoten. Öppna och kontrollera värdena igen efter att de sparats; ändra inte en delad produktionspolicy för ett pilottest.

Tilldela kvoter till en grupp eller användare

Använd en grupp som normal driftmetod

För användare med samma kvot är en gruppolicy enklare att hantera än många enskilda värden:

1. Öppna Authentication > Groups.
2. Skapa gruppen Quota_Pilot eller redigera en tydligt avgränsad pilotgrupp.
3. Välj Students_InternetTime vid Surfing quota.
4. Välj Students_DataVolume vid Network traffic.
5. Ändra inte andra värden för Access Time, Traffic Shaping, Remote Access eller portal av misstag.
6. Spara.
7. Autentisera pilotanvändaren på nytt och kontrollera vilken grupp som faktiskt används.

Hantera användargrupper i Sophos Firewall säkert förklarar hur lokala och importerade grupper, huvudgruppen och användaråsidosättningar samverkar. Själva AD-importen finns kvar i Anslut Active Directory till Sophos Firewall.

Kontrollera användaroverride och regelval tillsammans

Under Authentication > Users kan Surfing quota och Network traffic anges annorlunda för en enskild användare. Dokumentationen beskriver dock företrädet olika: guiden för att skapa användare ger generellt användarpolicyn företräde, medan användaröversikten gör det beroende av valet i regler och policyer. Den anger gruppvärden när endast gruppen är vald och användarvärden när både användaren och dennes grupp är valda. Utgå därför inte från att en override fungerar utan villkor.

Dokumentera det faktiska valet av användare och grupper i berörd regel eller policy samt båda kvotvärdena för piloten. Fastställ med en ny inloggning, View usage och ett begränsat testflöde vilket värde som gäller på denna build och sökväg. Stoppa utrullningen om visningen och den förväntade gränsen inte stämmer överens; bredda inte en produktionsregel och ändra inte gruppordningen som en snabb lösning. Återställ sedan tidigare tilldelningar och regelval och kontrollera igen.

Om en gruppändring inte påverkar en viss användare kontrolleras därför först användarobjektet. En override passar för ett dokumenterat undantag eller en pilot, men kan med tiden skapa dolda specialfall. För att återgå till gruppolicyn återställs användaren kontrollerat till det tidigare ärvda läget.

I Active Directory räknas endast Main Group

Surfing Quota och Network Traffic använder inte Other group memberships för AD-användare. Det är den Main Group som visas i fältet Group under Authentication > Users, eller en uttrycklig användarpolicy, som gäller.

Ordningen under Authentication > Groups > Reorder kan ändra Main Group och därmed påverka flera policyer samtidigt. Den ändras därför inte som en snabb kvotkorrigering. Efter en planerad gruppändring autentiseras användaren på nytt och Main Group kontrolleras igen.

Clientless Users är undantagna

Clientless Users stöder varken Surfing Quota eller Network Traffic. För en fast enhet utan användarinloggning planeras nätverkssökväg, schedule och vid behov Traffic Shaping i en snäv brandväggsregel. Användarkvoter används inte som en IP-baserad ersättning.

Kontrollera förbrukning och validera gränsen

View usage i WebAdmin

För förbrukningsvisningen kräver Sophos en användarbaserad brandväggsregel med Log firewall traffic aktiverat. Därefter:

1. Autentisera pilotanvändaren på nytt.
2. Kontrollera användarnamn och källadress under Current activities > Live users.
3. Öppna Authentication > Users och välj pilotanvändaren.
4. Öppna View usage.
5. För Surfing Quota, kontrollera tilldelad tid, utgång och förbrukad internettid.
6. För Network Traffic, kontrollera Cycle renewal, uppladdning, nedladdning och tilldelad kvot.
7. Skapa en liten tillåten testöverföring och kontrollera ändringen igen.
8. Korrelera användare, Source, Destination, Service, Firewall Rule ID, Action och tidsstämpel i Log Viewer.

Månadsvyn visar dessutom käll-IP, start, stopp, varaktighet, uppladdning och nedladdning. Ett förbrukningsvärde i sig bevisar dock inte att avsedd sökväg och rätt regel användes. Därför ska View usage, Log Viewer och ett verkligt testflöde kombineras. Testa en Sophos Firewall-regel tillförlitligt beskriver regelvalideringen.

Skilj mellan de olika delarna i View usage:

• Policy information: För AD visar Group endast Main Group. Time allotted to user är den tilldelade surftiden, Surfing quota expiry date dess utgångsdatum och Internet usage time förbrukningen sedan starten eller den senaste återställningen. Data transfer cycle renewal visar förnyelsen av en återkommande datakvot; för engångskvoter visas N.A..
• Usage information: Upload network traffic och Download network traffic visar total förbrukning och förbrukningen i den aktuella sessionen. Här betyder Allotted den maximala tilldelade datakvoten.
• Current cycle usage information: För återkommande kvoter avser Cycle upload network traffic och Cycle download network traffic endast den aktuella dags-, vecko-, månads- eller årscykeln. Här betyder Allotted cykelkvoten, inte det totala maximumet. Välj önskad månad i listan i View usage för att visa tidigare sessioner.

Användarkontroll i User Portal

Användarvyn under Internet usage ska skiljas från den administrativa View usage:

• Policy information visar användargrupp, tilldelade surftimmar, Surfing Quota-utgångsdatum, datum för förnyelse av datacykeln och redan förbrukad internettid. För ett gästkonto visas även kontots utgångsdatum; kontots giltighet och kvotförbrukningen besvarar olika frågor.
• Usage information visar tilldelad, förbrukad och återstående datakvot för uppladdning och nedladdning.
• Monthly usage visar månadens surftid och dataöverföring och hjälper användaren att följa tidigare förbrukning, inte bara den aktuella återstående kvoten.

Alla användare ser inte alla fält: kontotyp och tilldelade policyer avgör vad som visas. Att ett vanligt konto saknar ett utgångsdatum för gästkonto är därför inget bevis på ett kvotfel. Denna användarvy är till för att kontrollera förbrukning, inte en anvisning för att ändra policyn eller återställa räknarna.

I User Portal kan en användare under Internet usage, beroende på kontotyp och policy, kontrollera tilldelad och förbrukad surftid, cykelförnyelse, uppladdning, nedladdning och återstående kvot. Det minskar frågor men ersätter inte administratörens validering av tilldelning, Main Group, regel och loggar.

Testa förbrukningsgränsen kontrollerat

För ett gränstest används en separat pilotpolicy med en medvetet liten men tillräcklig kvot. Testet får inte påverka en produktionsgrupp.

1. Dokumentera startvärdena i View usage.
2. Starta ett tydligt begränsat HTTP- eller HTTPS-testflöde.
3. Observera förbrukning och Log Viewer under testet.
4. Bekräfta att gränsen leder till den förväntade frånkopplingen.
5. Öppna View usage igen efter frånkopplingen och dokumentera räknarvärdet och tidpunkten.
6. Testa nästa ordinarie cykel eller en uttryckligen godkänd återställning.
7. Återställ därefter pilotpolicyn och den tidigare tilldelningen.

Använd Reset user accounting säkert

Reset user accounting återställer användarens surftid och förbrukning av nätverkstrafik. När en Network Traffic Quota är förbrukad krävs denna återställning om användaren måste ansluta igen före nästa ordinarie cykel. Den här proceduren kan inte återställa de tidigare räknarvärdena; värdena som sparades i förväg är bevis, inte en återställningsbar säkerhetskopia.

En kontrollerad återställning går till så här:

1. Dokumentera användare, ärende, orsak, aktuella kvotvärden och tidpunkt.
2. Kontrollera om det går att vänta på den ordinarie cykelväxlingen.
3. Säkerställ att rätt användare är vald.
4. Öppna användaren under Authentication > Users.
5. Öppna View usage och spara startvärdena.
6. Aktivera Reset user accounting endast med avsett godkännande.
7. Autentisera användaren på nytt och kontrollera de nya räknarna.
8. Kontrollera ett litet testflöde, Firewall Rule ID och loggar.

Återställningen korrigerar inte fel Main Group, saknad användaridentifiering eller en blockerande brandväggs- eller webbpolicy. Om dessa orsaker inte reds ut först återkommer problemet trots återställda räknare.

Avgränsa fel systematiskt

Kvoten verkar inte räknas

Kontrollera först under Current activities > Live users om förväntad identitet och källadress visas. Kontrollera därefter att trafiken matchar en användarbaserad brandväggsregel med Log firewall traffic. Om loggning saknas eller flödet använder en annan regel kan View usage förbli ofullständig.

Jämför sedan gruppolicy, användaroverride och, för AD, Main Group. Kvoten sänks inte förhastat bara för att framtvinga en synlig effekt.

Gruppkvoten påverkar bara vissa användare

Utgå inte från att en uttrycklig användarpolicy är en verksam override utan att kontrollera valet av användare och grupper. Kontrollera båda kvotfälten och Main Group under Authentication > Users, samt valet i den regel eller policy som faktiskt matchas. För AD utvärderas inte Other group memberships. Autentisera användaren på nytt efter en gruppändring.

Användaren kopplas från oväntat

Kontrollera under View usage om Cycle quota, Maximum quota eller Maximum access time har nåtts. Kontrollera därefter Access Time, Web Policy, brandväggsregel och autentisering var för sig. Captive Portal kan också visas på grund av felaktiga inloggningsuppgifter eller andra autentiseringsproblem; kvoten är inte automatiskt orsaken. Konfigurera och testa Captive Portal på Sophos Firewall beskriver hela inloggningsvägen.

Förbrukningen motsvarar inte förväntningen

Kontrollera om Total network traffic eller separata gränser för uppladdning och nedladdning är konfigurerade. Jämför därefter månadsdetaljer, käll-IP, Firewall Rule ID och den faktiska testöverföringen. En Network Traffic Quota räknar datamängd, inte bara synliga webbläsarnedladdningar; bakgrundstrafik från den autentiserade användaren kan också bidra till förbrukningen.

En återställning hjälper bara kortvarigt

Om användaren kopplas från igen kort efter återställningen kontrolleras policyvärden, cykel, maximum, användaroverride och faktisk förbrukning. Räknaren återställs inte upprepade gånger innan orsaken har förståtts.

Rollback och drift

En kontrollerad rollback återställer de tidigare policytilldelningarna. En redan utförd accounting-återställning fortsätter däremot att gälla:

1. Återställ tidigare Surfing- och Network Traffic-tilldelning för pilotanvändare eller pilotgrupp.
2. För AD, autentisera användaren på nytt och kontrollera Main Group.
3. Dokumentera View usage och aktuell förbrukning.
4. Återställ accounting kontrollerat endast om detta avtalades för testet.
5. Kör ett litet testflöde och kontrollera Firewall Rule ID och loggar.
6. Ta bort pilotpolicyer först när inga användar- eller gruppberoenden finns kvar.
7. Uppdatera ärende, owner, gränsvärden och testresultat.

I drift behöver varje delad kvot ett begripligt namn, en Description, en owner och en dokumenterad motivering för cykel, kvot och totalgräns. Ändringar valideras med en pilotanvändare, ett positivt förbrukningstest och ett negativt gränstest.

Driftchecklista

• Tidsförbrukning och dataförbrukning har planerats separat.
• Surfing Quota och Network Traffic Quota har begripliga namn och owners.
• Cycle, Validity, Quota per cycle och Maximum är motiverade.
• Policyerna är tilldelade rätt grupp eller användare.
• Användaroverrides har kontrollerats.
• För AD är Main Group korrekt; Other group memberships förutsätts inte.
• Clientless Users planeras inte med användarkvoter.
• Pilotanvändaren visas som Live User.
• Den användarbaserade brandväggsregeln loggar testtrafiken.
• View usage, User Portal, Firewall Rule ID och verklig förbrukning stämmer överens.
• Reset user accounting används endast dokumenterat och godkänt.
• Det tidigare läget och rollback är dokumenterade.

Vanliga frågor