Configurar Surfing e Network Traffic Quota na Sophos Firewall

Uma Surfing quota limita o tempo de Internet utilizável por um utilizador autenticado. Uma Network traffic quota, por outro lado, limita o volume de dados transferido. Ambas as políticas são atribuídas a um utilizador ou grupo e são adequadas, por exemplo, para salas de formação, convidados ou pacotes de utilização claramente definidos.

Para convidados temporários, a criação da conta, a validade, o Captive Portal e a limpeza são planeados separadamente. O ciclo de vida completo está descrito em Criar e gerir utilizadores convidados em segurança na Sophos Firewall; este artigo concentra-se nas quotas.

O caminho curto para uma introdução controlada é o seguinte:

1. Definir se será limitado o consumo de tempo, o volume de dados ou ambos.
2. Criar uma nova política piloto em Profiles > Surfing quota ou Profiles > Network traffic quota.
3. Atribuir a política a um pequeno grupo piloto em Authentication > Groups ou a um único utilizador de teste em Authentication > Users.
4. Voltar a autenticar o utilizador e verificar a identidade reconhecida em Current activities > Live users.
5. Utilizar no teste uma regra de firewall baseada no utilizador com Log firewall traffic.
6. Abrir o utilizador em Authentication > Users e verificar o consumo através de View usage.
7. Testar o limite, o ciclo seguinte e o rollback antes de adicionar mais utilizadores.

⚠️ Reset user accounting repõe tanto o tempo de navegação consumido como os contadores de tráfego de rede. Trata-se de uma alteração de estado e não de um botão geral de diagnóstico. Antes de uma reposição, documentam-se o utilizador, os valores atuais, a hora e o motivo. Uma quota de produção partilhada também não é alterada diretamente; para os testes utiliza-se uma política piloto separada.

Escolher a função adequada ao requisito

Quatro funções com nomes semelhantes resolvem tarefas diferentes:

• Access Time permite ou bloqueia utilizadores em janelas horárias fixas. Não contabiliza consumo.
• Surfing quota atribui a um utilizador um crédito de tempo consumível para acesso à Internet.
• Network traffic quota atribui a um utilizador um crédito de dados consumível.
• Traffic Shaping limita ou prioriza a largura de banda. Uma velocidade de dados baixa não é uma quota de dados.

Além disso, uma Web Policy oferece a ação Quota para acesso temporário a determinadas categorias web. Esta Policy Quota pertence à lógica do proxy web e não é a mesma função que a Surfing Quota baseada no utilizador deste artigo.

Uma quota não cria uma regra de firewall nem uma identidade de utilizador. A firewall tem de reconhecer o utilizador, o caminho de rede tem de estar permitido e o tráfego de teste tem de corresponder à regra esperada. Só então é possível validar a quota de forma significativa.

Para a quota separada de categorias web, Policy quota status apresenta o tempo restante por utilizador e Web Policy num período de 24 horas. Para uma reposição aprovada, selecionar aí os utilizadores afetados e Reset. Antes, documentar o utilizador, a política e o tempo restante; depois, verificar a apresentação e um pedido de teste permitido. Não confundir esta reposição com Reset user accounting: uma quota de categorias web esgotada não justifica apagar os contadores de navegação e dados do utilizador.

Planear o exemplo e os pré-requisitos

O exemplo contínuo utiliza um pequeno grupo piloto com duas políticas separadas:

• Grupo: Quota_Pilot
• Utilizador de teste: 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

Estes são deliberadamente pequenos exemplos de documentação: cada ciclo de 24 horas disponibiliza duas horas de Internet e cada dia 5000 MB de volume de dados. Os nomes, o tempo, o volume de dados, o ciclo e o limite total são adaptados ao acordo de utilização real. Os limites pequenos de teste não devem ser copiados para uma política exclusivamente produtiva sem verificar o seu impacto.

Antes da configuração, verificam-se os seguintes pontos:

1. O utilizador piloto consegue iniciar sessão com o método de autenticação previsto.
2. O nome de utilizador e o endereço de origem aparecem em Current activities > Live users.
3. Para utilizadores AD, o campo Group em Authentication > Users está correto.
4. Uma regra de firewall adequada e baseada no utilizador permite o tráfego de teste e tem Log firewall traffic ativado.
5. As atribuições existentes de Surfing quota, Network traffic, Access time e Traffic shaping estão documentadas.
6. O estado anterior e um utilizador de teste alternativo são conhecidos.

Se o utilizador não estiver visível como Live User, corrige-se primeiro a autenticação. Uma quota não consegue atribuir de forma fiável tráfego desconhecido ou tratado apenas por IP a um crédito normal de utilizador.

Criar uma Surfing Quota

Uma Surfing Quota contabiliza o tempo de Internet consumido. Na ajuda do SFOS 22, o mesmo objeto está documentado tanto em Profiles > Surfing quota como em Web > Surfing quotas. Utiliza-se a entrada apresentada pelo WebAdmin na build instalada.

Também se podem utilizar as quotas predefinidas existentes; uma Surfing Quota existente abre-se com Edit. É necessário considerar o impacto em todos os utilizadores e grupos atribuídos.

Escolher Cyclic ou Non-cyclic

• Cyclic (repeat access): O crédito de tempo volta a ficar disponível em ciclos recorrentes. O tempo não utilizado não transita para o ciclo seguinte.
• Non-cyclic (one-time access): O crédito de tempo é disponibilizado uma única vez. Depois de o consumir, o utilizador é desligado.

Além disso, Validity period limita o número de dias durante os quais a política permanece válida. Maximum access time define o tempo utilizável. Quando se atinge o máximo, o utilizador é desligado mesmo que a validade da quota ainda não tenha expirado.

Se forem aplicadas várias Surfing Quotas a um utilizador, a firewall restringe o acesso assim que a primeira dessas políticas atinge o respetivo limite. Por isso, todas as atribuições diretas e baseadas em grupos devem ser verificadas em conjunto; uma segunda política mais generosa não anula um limite já atingido.

Unlimited em Maximum access time remove apenas o limite de tempo consumido, não a validade configurada separadamente. Para utilização ilimitada concedida uma única vez durante uma semana, selecionar, por exemplo, Non-cyclic (one-time access), definir Validity period como 7 dias e Maximum access time como Unlimited. Este requisito é diferente de duas horas por ciclo de 24 horas.

Para o exemplo piloto:

1. Abrir Profiles > Surfing quota > Add. Se a build apresentar a função em Web > Surfing quotas, selecionar aí Add.
2. Definir Name como Students_InternetTime.
3. Introduzir, por exemplo, Pilot: 2h per 24h, Owner IT como Description.
4. Definir Cycle type como Cyclic (repeat access).
5. Definir Cycle hours como 24.
6. Definir conscientemente o Validity period para o piloto ou selecionar Unlimited apenas se não for necessário um limite de expiração.
7. Definir Maximum access time como 02:00.
8. Guardar com Save.

A política guardada ainda não tem efeito. Só a atribuição a um utilizador ou grupo associa o crédito de tempo a uma identidade.

Enquadrar SurfingQuotaPolicy na API XML

Para automações, o crédito de tempo associado ao utilizador chama-se SurfingQuotaPolicy. Não é uma Network Traffic Quota nem a ação Quota de uma Web Policy. A proteção do acesso, as operações explícitas de escrita e a distinção entre o transporte HTTP e o resultado XML são explicadas em Proteger o acesso à API XML. Antes de uma alteração, guardar o nome exato do objeto, todos os valores guardados e as atribuições a utilizadores e grupos; editar apenas uma política piloto separada.

As referências XML para SFOS 22.0 e 23.0 indicam os campos seguintes. Trata-se de informações documentadas, não de uma serialização testada numa firewall:

• Name é obrigatório: String, no máximo 60 caracteres, sem vírgulas; UTF-8 é permitido. Isto também se aplica a Delete Surfing Quota Policy. Description é opcional e está limitado a 255 caracteres. A coluna de valores predefinidos não indica valores para estes campos; não deduzir daí um valor predefinido em tempo de execução.
• CycleType aparece no modelo como Cyclic/NonCyclic; para um pedido, seria necessário escolher exatamente um valor confirmado, não a expressão com a barra. No entanto, a tabela de parâmetros indica simultaneamente o tipo String e o intervalo 1–87840. Não transferir esta indicação contraditória de intervalo para outro campo nem interpretá-la como uma codificação numérica do ciclo.
• CycleHours é descrito como uma String opcional para as horas do ciclo, sem intervalo numérico. CycleMinutes é descrito como um campo obrigatório do tipo Integer com, no máximo, quatro algarismos. Em particular, isto não confirma um intervalo de 0–59 para este campo. O modelo contém ainda PerDay com Days/Weekly/Monthly/Yearly, mas a tabela de parâmetros não explica este campo. Por isso, não converter a definição Cycle hours da interface e a duração do ciclo do piloto para estes campos XML sem verificação prévia.
• Para uma validade finita, Validity é descrito como uma String com 0–3660 dias. MaximumHours descreve o total finito de horas de navegação como uma String com, no máximo, sete caracteres; Minutes é o valor adicional de minutos, como uma String no intervalo 0–59. A validade em dias e o tempo consumível em horas/minutos continuam a ser limites separados; a validade não é um crédito de tempo.

Um excerto de campos com valores finitos, expressamente não um pedido completo ou pronto a enviar, ilustra esta última distinção:

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

Os valores de exemplo representam sete dias de validade e duas horas de tempo total de navegação, sem minutos adicionais. Não mostram a implementação completa do piloto cíclico da interface «duas horas por 24 horas». Os campos de ciclo, a atribuição e a operação explícita foram deliberadamente omitidos. Os dias e o crédito de tempo são escolhidos com base no acordo de utilização aprovado; para a serialização completa, comparar primeiro a API help da build instalada com um objeto piloto obtido por leitura.

Para valores ilimitados, o modelo apresenta, para Validity e MaximumHours, o texto Unlimited/{Days}; em contrapartida, linhas separadas da tabela para Validity e Maximum Hours indicam -11 e a cadeia de caracteres vazia ''. Isto não confirma que estas formas de representação sejam intercambiáveis, que campos vazios preservem os valores existentes ou que Maximum Hours, com espaços, seja uma tag XML. Além disso, a descrição das horas não corresponde ao marcador de posição {Days} em MaximumHours. Enquanto a representação do ciclo ou a codificação de Unlimited não estiverem esclarecidas, não enviar nenhum pedido de escrita e solicitar esclarecimentos específicos para a build.

Verificar as respostas antes de uma nova tentativa de escrita

Em Add Surfing Quota Policy, Edit Surfing Quota Policy e Delete Surfing Quota Policy, a operação, o código XML e o símbolo de referência devem ser considerados em conjunto. As referências para SFOS 22.0 e 23.0 contêm as mesmas correspondências:

Message.* são aqui chaves literais e não resolvidas da referência, não mensagens comprovadas em tempo de execução. Um sucesso HTTP não é um sucesso da operação XML. Mesmo um código XML 200 não substitui uma nova leitura do objeto de destino guardado: o nome, o ciclo, a validade, as horas e os minutos têm de corresponder aos valores aprovados. Só depois validar a atribuição e o efeito com View usage, um novo início de sessão e o teste limitado de consumo e de limite deste artigo; guardar, por si só, não comprova a aplicação efetiva da política.

Perante 500, 502, 504, uma resposta ambígua ou um timeout, guardar primeiro a resposta expurgada de dados sensíveis e ler o estado real do objeto antes de considerar qualquer nova tentativa. Perante 502, verificar se já está guardado, com o nome exato, o objeto pretendido ou outro objeto; não passar automaticamente de Add para Edit. No caso de Delete com 504, verificar as referências existentes e as atribuições a utilizadores/grupos; não remover regras dependentes com base em suposições. Antes de uma eliminação aprovada, migrar as atribuições de forma controlada, verificar novamente as dependências e, depois, confirmar que apenas a política piloto foi removida e que os serviços anteriores continuam a funcionar. Um código de erro não comprova que o estado permaneceu inalterado nem que uma nova tentativa seja segura. Uma reposição do accounting não permite reverter uma atualização pela API ou uma eliminação.

Criar uma Network Traffic Quota

Uma Network Traffic Quota contabiliza o volume de dados transferido. Não limita a velocidade. Um utilizador pode, portanto, consumir o crédito rapidamente ou lentamente; se for necessário um limite de largura de banda, planeia-se adicionalmente uma política de Traffic Shaping adequada.

Limitar o tráfego total ou separar upload e download

• Total network traffic: Um crédito comum contabiliza upload e download em conjunto.
• Individual network traffic (Upload & download): Upload e download recebem limites separados. Isto só é adequado quando o requisito trata realmente as duas direções de forma separada.

Também existem dois modelos de ciclo:

• Cyclic: O crédito aplica-se a cada ciclo selecionado. Estão disponíveis Day, Week, Month e Year. O volume de dados não utilizado não transita.
• Non-cyclic: O crédito aplica-se a um único período de ciclo.

Quota per cycle define o crédito por ciclo. Uma Maximum quota opcional adiciona um limite total e tem de ser superior à quota do ciclo. Quando o limite do ciclo ou o limite total se esgota, a firewall desliga o utilizador. Para o voltar a ligar antes da reposição normal, é necessário Reset user accounting.

Para o exemplo piloto:

1. Abrir Profiles > Network traffic quota > Add.
2. Definir Name como Students_DataVolume.
3. Introduzir, por exemplo, Pilot: 5000 MB per day, Owner IT como Description.
4. Definir Restriction como Total network traffic.
5. Definir Cycle type como Cyclic.
6. Definir Cycle period como Day.
7. Definir Quota per cycle como 5000 MB.
8. Manter Maximum quota em Unlimited neste exemplo recorrente. Se for necessário um limite total, este tem de ser superior à quota do ciclo.
9. Guardar com Save.

Os 5000 MB são um valor de introdução para este exemplo, não um valor obrigatório nem uma referência de conversão. Numa política real, o valor é derivado do crédito aprovado e introduzido na unidade esperada pelo WebAdmin. Uma política com upload e download separados recebe valores próprios e fundamentados para cada direção.

Também existem políticas Network Traffic predefinidas; as políticas existentes abrem-se com Edit. Para uma Maximum quota finita, desmarcar a caixa Unlimited correspondente e introduzir um valor superior à quota do ciclo. Depois de guardar, voltar a abrir e verificar os valores; não alterar uma política de produção partilhada para um teste piloto.

Atribuir quotas a um grupo ou utilizador

Utilizar um grupo como método operacional normal

Para utilizadores com o mesmo crédito, uma política de grupo é mais fácil de operar do que muitos valores individuais:

1. Abrir Authentication > Groups.
2. Criar o grupo Quota_Pilot ou editar um grupo piloto claramente delimitado.
3. Em Surfing quota, selecionar Students_InternetTime.
4. Em Network traffic, selecionar Students_DataVolume.
5. Não alterar incidentalmente outros valores de Access Time, Traffic Shaping, Remote Access ou portal.
6. Guardar.
7. Voltar a autenticar o utilizador piloto e verificar o grupo realmente utilizado.

Gerir grupos de utilizadores da Sophos Firewall em segurança explica como interagem grupos locais e importados, o grupo principal e as substituições dos utilizadores. A importação AD propriamente dita continua descrita em Ligar o Active Directory à Sophos Firewall.

Verificar em conjunto a substituição no utilizador e a seleção na regra

Em Authentication > Users, Surfing quota e Network traffic podem ser definidos de forma diferente para um utilizador individual. No entanto, a documentação descreve a prioridade de forma diferente: o guia de criação de utilizadores dá geralmente prioridade à política do utilizador, enquanto a visão geral dos utilizadores a faz depender da seleção nas regras e políticas. Indica os valores do grupo quando apenas o grupo está selecionado e os do utilizador quando estão selecionados o utilizador e o seu grupo. Por isso, não se deve presumir que uma substituição se aplica incondicionalmente.

Para o piloto, documentar a seleção real de utilizadores e grupos na regra ou política afetada e os dois valores de quota. Com um novo início de sessão, View usage e um fluxo de teste limitado, determinar qual o valor aplicado nessa build e nesse caminho. Se a apresentação e o limite esperado não coincidirem, parar a implementação; não alargar uma regra de produção nem reordenar grupos como correção rápida. Depois, restaurar as atribuições e a seleção anteriores e voltar a verificar.

Se uma alteração de grupo não tiver efeito num utilizador, verifica-se primeiro o respetivo objeto de utilizador. Uma substituição é adequada para uma exceção documentada ou um piloto, mas pode criar casos especiais ocultos a longo prazo. Para voltar à política de grupo, repõe-se de forma controlada o estado de herança anterior do utilizador.

No Active Directory apenas conta a Main Group

Para utilizadores AD, Surfing Quota e Network Traffic não utilizam Other group memberships. Aplica-se a Main Group apresentada no campo Group em Authentication > Users, ou uma política explícita no utilizador.

A ordem em Authentication > Groups > Reorder pode alterar a Main Group e afetar várias políticas em simultâneo. Por isso, não é alterada como correção rápida de uma quota. Após uma alteração planeada do grupo, volta-se a autenticar o utilizador e verifica-se novamente a Main Group.

Os Clientless Users estão excluídos

Os Clientless Users não suportam Surfing Quota nem Network Traffic. Para um dispositivo fixo sem início de sessão de utilizador, o caminho de rede, o schedule e, se necessário, Traffic Shaping são planeados numa regra de firewall restrita. As quotas de utilizador não são utilizadas como substituto baseado em IP.

Verificar o consumo e validar o limite

View usage no WebAdmin

Para apresentar o consumo, a Sophos exige uma regra de firewall baseada no utilizador com Log firewall traffic ativado. Em seguida:

1. Voltar a autenticar o utilizador piloto.
2. Verificar o nome de utilizador e o endereço de origem em Current activities > Live users.
3. Abrir Authentication > Users e selecionar o utilizador piloto.
4. Abrir View usage.
5. Para Surfing Quota, verificar o tempo atribuído, a expiração e o tempo de Internet consumido.
6. Para Network Traffic, verificar Cycle renewal, upload, download e quota atribuída.
7. Gerar uma pequena transferência de teste permitida e verificar novamente a alteração.
8. No Log Viewer, correlacionar utilizador, Source, Destination, Service, Firewall Rule ID, Action e timestamp.

A vista mensal apresenta também o IP de origem, início, fim, duração, upload e download. No entanto, um valor de consumo isolado não prova que foram utilizados o caminho previsto e a regra correta. Por isso, View usage, Log Viewer e um fluxo de teste real devem ser combinados. Testar corretamente uma regra da Sophos Firewall explica a validação da regra.

Em View usage, é importante distinguir as diferentes secções:

• Policy information: Em AD, Group apresenta apenas a Main Group. Time allotted to user é o tempo de navegação atribuído, Surfing quota expiry date a respetiva data de expiração e Internet usage time o consumo desde o início ou a última reposição. Data transfer cycle renewal apresenta a renovação de uma quota de dados recorrente; para quotas não recorrentes aparece N.A..
• Usage information: Upload network traffic e Download network traffic apresentam o consumo total e o da sessão atual. Aqui, Allotted significa a quota máxima de dados atribuída.
• Current cycle usage information: Nas quotas recorrentes, Cycle upload network traffic e Cycle download network traffic referem-se apenas ao ciclo diário, semanal, mensal ou anual atual. Aqui, Allotted significa a quota do ciclo, não o máximo total. Para consultar sessões anteriores, selecionar o mês pretendido na lista de View usage.

Controlo pelo utilizador no User Portal

A vista do utilizador em Internet usage distingue-se da vista administrativa View usage:

• Policy information apresenta o grupo do utilizador, as horas de navegação atribuídas, a data de expiração da Surfing Quota, a data de renovação do ciclo de dados e o tempo de Internet já consumido. No caso de uma conta de convidado, apresenta também a expiração da conta; a expiração da conta e o consumo da quota respondem a questões diferentes.
• Usage information apresenta a quota de dados atribuída, consumida e restante para upload e download.
• Monthly usage apresenta o tempo de navegação e a transferência de dados mensais e ajuda a compreender o consumo anterior, em vez de mostrar apenas a quota restante atual.

Nem todos os utilizadores veem todos os campos: o tipo de conta e as políticas atribuídas determinam o que é apresentado. Por isso, a ausência de uma data de expiração de conta de convidado numa conta normal não comprova um erro de quota. Esta vista do utilizador serve para controlar o consumo, não constitui uma instrução para alterar a política ou repor os contadores.

No User Portal, em Internet usage, um utilizador pode verificar, consoante o tipo de conta e a política, o tempo de navegação atribuído e consumido, a renovação do ciclo, bem como upload, download e crédito restante. Isto reduz as dúvidas, mas não substitui a validação administrativa da atribuição, Main Group, regra e logs.

Testar o limite de consumo de forma controlada

Para um teste de limite, utiliza-se uma política piloto separada com um crédito deliberadamente pequeno, mas suficiente. O teste não pode afetar um grupo de produção.

1. Documentar os valores iniciais em View usage.
2. Iniciar um fluxo de teste HTTP ou HTTPS claramente limitado.
3. Observar o consumo e o Log Viewer durante o teste.
4. Confirmar que atingir o limite provoca a desconexão esperada.
5. Após a desconexão, voltar a abrir View usage e documentar o valor do contador e a hora.
6. Testar o ciclo regular seguinte ou uma reposição expressamente aprovada.
7. Restaurar depois a política piloto e a atribuição anterior.

Utilizar Reset user accounting em segurança

Reset user accounting repõe o tempo de navegação e o consumo de tráfego de rede do utilizador. Com uma Network Traffic Quota esgotada, esta reposição é necessária se o utilizador tiver de voltar a ligar-se antes do ciclo regular seguinte. Este procedimento não permite restaurar os valores anteriores dos contadores; os valores guardados previamente servem como prova, não como cópia de segurança restaurável.

Uma reposição controlada é realizada da seguinte forma:

1. Documentar o utilizador, o ticket, o motivo, os valores atuais das quotas e a hora.
2. Verificar se é possível aguardar a mudança do ciclo regular.
3. Garantir que está selecionado o utilizador correto.
4. Abrir o utilizador em Authentication > Users.
5. Abrir View usage e guardar os valores iniciais.
6. Acionar Reset user accounting apenas com a aprovação prevista.
7. Voltar a autenticar o utilizador e verificar os novos contadores.
8. Verificar um pequeno fluxo de teste, a Firewall Rule ID e os logs.

A reposição não corrige uma Main Group errada, a falta de reconhecimento do utilizador nem uma política de firewall ou web que bloqueie. Se estas causas não forem resolvidas primeiro, o problema regressa apesar dos contadores repostos.

Delimitar sistematicamente os erros

A quota parece não ser contabilizada

Primeiro, verificar em Current activities > Live users se a identidade e o endereço de origem esperados estão visíveis. Depois, confirmar se o tráfego corresponde a uma regra de firewall baseada no utilizador com Log firewall traffic. Se faltar o registo ou o fluxo utilizar outra regra, View usage pode ficar incompleto.

Em seguida, comparar a política de grupo, a substituição no utilizador e, para AD, a Main Group. A quota não é reduzida precipitadamente apenas para forçar um efeito visível.

A quota de grupo afeta apenas alguns utilizadores

Não presumir que uma política explícita do utilizador constitui uma substituição efetiva sem verificar a seleção de utilizadores e grupos. Em Authentication > Users, verificar os dois campos de quota e a Main Group, bem como a seleção na regra ou política que realmente corresponde ao tráfego. Em AD, as Other group memberships não são avaliadas. Voltar a autenticar o utilizador após uma alteração de grupo.

O utilizador é desligado inesperadamente

Em View usage, verificar se foi atingida Cycle quota, Maximum quota ou Maximum access time. Depois, verificar separadamente Access Time, Web Policy, a regra de firewall e a autenticação. O Captive Portal também pode aparecer devido a credenciais incorretas ou outros problemas de autenticação; a quota não é automaticamente a causa. Configurar e testar o Captive Portal na Sophos Firewall explica o caminho completo de início de sessão.

O consumo não corresponde ao esperado

Verificar se está configurado Total network traffic ou limites separados de upload e download. Em seguida, comparar os detalhes mensais, o IP de origem, a Firewall Rule ID e a transferência de teste real. Uma Network Traffic Quota contabiliza volume de dados, não apenas downloads visíveis no navegador; o tráfego em segundo plano do utilizador autenticado também pode contribuir para o consumo.

A reposição ajuda apenas por pouco tempo

Se o utilizador voltar a ser desligado pouco depois da reposição, verificam-se os valores da política, o ciclo, o máximo, a substituição no utilizador e o consumo real. O contador não é reposto repetidamente antes de se compreender a causa.

Rollback e operação

Um rollback controlado restaura as atribuições anteriores das políticas. No entanto, uma reposição do accounting já executada continua em vigor:

1. Restaurar as atribuições Surfing e Network Traffic anteriores para o utilizador ou grupo piloto.
2. Em AD, voltar a autenticar o utilizador e verificar a Main Group.
3. Documentar View usage e o consumo atual.
4. Repor o accounting de forma controlada apenas se isso tiver sido acordado para o teste.
5. Executar um pequeno fluxo de teste e verificar a Firewall Rule ID e os logs.
6. Remover as políticas piloto apenas quando já não existir qualquer dependência de utilizador ou grupo.
7. Atualizar o ticket, o owner, os limites e o resultado do teste.

Em operação, cada quota partilhada precisa de um nome compreensível, uma Description, um owner e uma justificação documentada para o ciclo, o crédito e o limite total. As alterações são validadas com um utilizador piloto, um teste de consumo positivo e um teste de limite negativo.

Lista de verificação operacional

• O consumo de tempo e o consumo de dados foram planeados separadamente.
• Surfing Quota e Network Traffic Quota têm nomes e owners compreensíveis.
• Cycle, Validity, Quota per cycle e Maximum estão justificados.
• As políticas estão atribuídas ao grupo ou utilizador correto.
• As substituições no utilizador foram verificadas.
• Em AD, a Main Group está correta; não se pressupõem Other group memberships.
• Os Clientless Users não são planeados com quotas de utilizador.
• O utilizador piloto aparece como Live User.
• A regra de firewall baseada no utilizador regista o tráfego de teste.
• View usage, User Portal, Firewall Rule ID e o consumo real estão alinhados.
• Reset user accounting só é utilizado com documentação e aprovação.
• O estado anterior e o rollback estão documentados.

Perguntas frequentes