Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos
Administrar contas de usuário e grupos é uma parte essencial da administração de sistemas em uma empresa. Para executá-la de maneira eficaz, um bom administrador de sistemas deve primeiramente entender o que são contas de usuário, grupos e como eles funcionam.
A principal razão da existência de contas de usuário é a verificação da identidade de cada indivíduo usando um computador. Uma razão secundária (mas importante) é permitir a personalização de recursos e privilégios de acesso por indivíduo.
Os recursos podem incluir arquivos, diretórios e dispositivos. Controlar o acesso a estes recursos é uma grande parte da rotina diária de um administrador de sistemas. Frequentemente o acesso a um recurso é controlado por grupos. Grupos são formações lógicas que podem ser usadas para agrupar contas de usuários para um propósito comum. Por exemplo: se uma empresa tem diversos administradores de sistemas, eles podem ser alocados em um grupos de administradores de sistemas. O grupo, então, pode receber permissões para acessar recursos sensíveis do sistema. Desta maneira, os grupos podem ser uma ferramenta poderosa para administrar recursos e acesso.
As seções seguintes abordam contas de usuário e grupos com mais detalhes.
6.1. Administrando Contas de Usuário
Como mencionado anteriormente, as contas de usuário são o método através do qual um indivíduo é identificado e autenticado no sistema. As contas de usuário têm diversos componentes. Primeiro, há um nome de usuário (username). Em seguida, a senha (password), seguida pelas informações de controle de acesso.
As seções seguintes exploram cada um destes componentes com mais detalhes.
6.1.1. O Nome de Usuário
Do ponto de vista do sistema, o nome de usuário é a resposta à pergunta: "quem é você?" Como tal, o nome de usuário tem um requisito principal — deve ser único. Em outras palavras, cada usuário deve ter um nome de usuário diferente de todos os outros nomes de usuários no sistema.
Em função deste requisito, é vital determinar — com antecedência — como os nomes de usuário devem ser criados. Caso contrário, você pode se ver obrigado a intervir cada vez que um novo usuário requisitar uma conta.
Você precisa de uma convenção de nomenclatura para suas contas de usuário.
6.1.1.1. Convenções de Nomenclatura
Ao criar uma convenção de nomenclatura para nomes de usuário, você pode evitar diversos problemas. Ao invés de inventar nomes ao longo do curso (e enfrentar a dificuldade de inventar um nome razoável toda vez), você antecipa seu trabalho e impõe uma convenção a ser usada para todas as contas de usuário subsequentes. Sua convenção de nomenclatura pode ser muito simples ou então, apenas sua descrição, pode ter diversas páginas documentadas.
A natureza da sua convenção de nomenclatura deve considerar diversos fatores:
O tamanho de sua empresa
A estrutura de sua empresa
A natureza de sua empresa
O tamanho de sua empresa importa, pois dita quantos usuários sua convenção de nomenclatura deve suportar. Por exemplo: numa micro empresa pode ser possível que todos usem seu primeiro nome. Para uma empresa bem maior, essa convenção de nomenclatura não funcionará.
A estrutura de uma empresa também pode influenciar a convenção de nomenclatura mais apropriada. Em empresas com estruturas rígidas, pode ser apropriado incluir elementos da estrutura na convenção de nomenclatura. Por exemplo: você pode incluir os códigos dos departamentos de sua empresa como parte de cada nome de usuário.
A natureza da sua empresa também pode significar que algumas convenções de nomenclatura são mais apropriadas que outras. Um empresa que lida com dados altamente ordenados pode escolher uma convenção de nomenclatura que elimina quaisquer laços de identificação pessoal entre o indivíduo e seu nome. Numa empresa deste tipo, o nome de usuário João da Silva poderia ser LUH3417.
Aqui estão algumas convenções de nomenclatura que outras empresas utilizaram:
Primeiro nome (joão, paulo, jorge, etc.)
Último nome (silva, pereira, pontes, etc.)
Primeira inicial, seguida do último nome (jsilva, ppereira, jpontes, etc.)
Último nome, seguido do código do departamento (silva029, pereira454, pontes191, etc.)
 | Dica |
|---|---|
Atenção: se a sua convenção de nomenclatura inclui a junção de dados diferentes para formar um nome de usuário, existe a possibilidade do resultado ser hilário ou ofensivo. Portanto, mesmo se você tiver automatizado a criação dos nomes de usuário, é aconselhável ter algum tipo de revisão no processo. |
As convenções de nomenclatura abordadas aqui têm em comum a possibilidade de existirem dois indivíduos que, de acordo com a convenção, devem ter os mesmos nomes de usuário. Isto é conhecido como uma colisão. Como cada nome de usuário deve ser único, é necessário resolver a questão das colisões. A seção seguinte aborda este assunto.
6.1.1.1.1. Resolvendo as Colisões
Colisões ocorrem de fato — não importa o quanto você tenta, ocasionalmente você deverá resolvê-las. Você deve planejar como lidar com as colisões em sua convenção de nomenclatura. Há diversas maneiras de fazer isso:
Adicionar números sequenciais ao nome de usuário colidido (silva, silva1, silva2, etc.)
Adicionar dados específicos do usuário ao nome de usuário colidido (silva, esilva, eksilva, etc.)
Adicionar informações da empresa ao nome de usuário colidido (silva, silva029, silva454, etc.)
Ter algum método de resolver colisões é uma parte necessária de qualquer convenção de nomenclatura. No entanto, esta dificulta que alguém de fora da empresa determine o nome de usuário de um indivíduo corretamente. Portanto, a desvantagem da maioria das convenções de nomenclatura é a maior probabilidade do envio incorreto de e-mails.
6.1.1.2. Resolvendo Alterações de Nome
Se a sua empresa utiliza uma convenção de nomenclatura baseada no nome de cada usuário, é certeza que você terá que lidar com alterações de nome em algum momento. Mesmo que o nome verdadeiro de uma pessoa não mude, será necessário alterar alguns nomes de usuários de tempos em tempos. As razões podem variar; desde o usuário não estar satisfeito com seu nome de usuário até o fato do usuário ser um gerente sênior da empresa e querer usar sua influência para obter um nome de usuário "mais apropriado".
Independente da razão, há diversas questões a considerar ao alterar um nome de usuário:
Efetue a alteração em todos os sistemas afetados
Mantenha quaisquer identificações do usuário constantes
Altere a propriedade (ownership) de todos os arquivos e outros recursos específicos do usuário (se necessário)
Resolva questões relacionadas a e-mail
Primeiramente, é importante garantir que o novo nome de usuário seja propagado para todos os sistemas nos quais o nome de usuário original foi usado. Caso contrário, qualquer função do sistema operacional baseada no nome do usuário pode funcionar em alguns sistemas e não funcionar em outros. Determinados sistemas operacionais utilizam técnicas de controle de acesso baseadas em nomes de usuário; tais sistemas têm uma vulnerabilidade relacionada a problemas originados a partir de um nome de usuário alterado.
Muitos sistemas operacionais utilizam alguma espécie número de identificação do usuário para a maioria do processamento específico ao usuário. Para minimizar os problemas oriundos da alteração de um nome de usuário, tente manter este número de identificação constante entre os nomes do usuário novo e velho. Caso contrário, é provável ter um cenário no qual o usuário não consegue mais acessar arquivos e outros recursos que previamente possuía sob o nome de usuário original.
Se o número de identificação do usuário deve ser alterado, é necessário alterar a propriedade (ownership) de todos os arquivos e recursos específicos ao usuário para refletir a nova identificação do usuário. Este pode ser um processo propenso a erros, já que parece que sempre há algo esquecido em algum canto que acaba sendo negligenciado.
As questões relacionadas a e-mails provavelmente representam a área mais difícil para uma alteração de nome de usuário. A razão disto é que, a não ser que sejam tomadas ações para contra-atacar, os e-mails destinados ao nome de usuário velho não serão entregues ao nome de usuário novo.
Infelizmente, as questões que permeam o impacto das alterações de nome de usuário em e-mails são multi-dimensionais. No mínimo, uma alteração de nome de usuário significa que as pessoas não sabem mais o nome de usuário correto da pessoa. À primeira vista, este não parece ser um grande problema — notificar a todos de sua empresa sobre a alteração. Mas, e quanto às pessoas fora da empresa que enviaram e-mails para esta pessoa? Como elas devem ser notificadas? E as listas de discussão (internas e externas)? Como elas podem ser atualizadas?
Não há uma resposta simples para estas questões. A melhor resposta talvez seja criar um codenome de e-mail, de modo que todos os e-mails enviados ao nome de usuário velho sejam automaticamente encaminhados ao novo nome de usuário. O usuário pode ser aconselhado a alertar todos que enviam e-mails para ele, que seu nome de usuário foi alterado. Com o passar do tempo, menos e-mails serão entregues usando o codenome; eventualmente o codenome pode ser removido.
Enquanto o uso de codenome, de alguma maneira, perpetua uma suposição incorreta (de que o usuário agora conhecido como esilva ainda é conhecido como jpontes), é a única maneira de garantir que o e-mail seja entregue à pessoa correta.
 | Importante |
|---|---|
Se você usar codenome de e-mail, certifique-se de executar todos os passos necessários para proteger o nome de usuário velho de re-utilização. Se você não fizer isso e um novo usuário receber o nome de usuário velho, a entrega de e-mails (para ambos, o usuário original ou o novo) pode ser interrompida. A razão exata da interrupção depende de como a entrega de e-mails é implementada em seu sistema operacional, mas os dois sintomas mais prováveis são:
|
6.1.2. Senhas
Se o nome de usuário oferece uma resposta para a pergunta "quem é você?", a senha é a resposta para o pedido que segue inevitavelmente:
"Prove!"
Em termos mais formais, uma senha oferece um meio de provar a autenticidade da afirmação de uma pessoa ser o usuário indicado pelo nome de usuário. A eficiência de um esquema de autenticação com senha baseia-se em diversos aspectos da senha:
A discrição de senha
A resistência da senha em ser descoberta
A resistência da senha a um ataque brute-force
As senhas que atendem estes requisitos são chamadas de fortes, enquanto aquelas que não atendem um ou mais requisitos são chamadas de fracas. É importante criar senhas fortes para a segurança da empresa, já que este tipo de senha tem menor probabilidade de ser descoberta. Há duas opções para reforçar o uso de senhas fortes:
O administrador de sistemas pode criar senhas para todos os usuários.
O administrador de sistemas pode deixar que os usuários criem suas próprias senhas, enquanto verifica se as senhas são aceitáveis.
Criar senhas para todos os usuários garante que sejam fortes, mas torna-se uma tarefa desanimadora conforme a empresa cresce. Também aumenta o risco dos usuários anotarem suas senhas.
Por estes motivos, a maioria dos administradores de sistemas preferem que seus usuários criem suas próprias senhas. Entretanto, um bom administrador de sistemas executa alguns passos para garantir que as senhas sejam fortes.
Para obter instruções sobre a criação de senhas fortes, veja o capítulo intitulado Segurança da Estação de Trabalho no Guia de Segurança do Red Hat Enterprise Linux.
A necessidade de manter as senhas secretas deve ser uma parte intrínseca da mentalidade de todo administrador de sistemas. No entanto, este aspecto é frequentemente esquecido por muitos usuários. De fato, muitos usuários não entendem a diferença entre nomes de usuários e senhas. Portanto, é vital oferecer alguma forma de educação neste aspecto para os usuários, para que eles entendam que suas senhas devem ser tão bem guardadas quanto seus holeriths.
As senhas devem ser o mais difícil possível de serem descobertas. Uma senha forte é aquela que o atacante não consegue descobrir, mesmo que ele também conheça o usuário.
Um ataque brute-force a uma senha envolve tentar metodicamente (geralmente através de um programa conhecido como password-cracker) todas as combinações possíveis de caracteres na esperança de que a senha correta seja eventualmente encontrada. Uma senha forte deve ser construída de maneira a tornar o número de senhas a testar muito grande, forçando o atacante a levar bastante tempo na procura da senha.
As senhas fortes e fracas são abordadas detalhadamente nas seções seguintes.
6.1.2.1. Senhas Fracas
Como explanado anteriormente, uma senha fraca falha em um destes três testes:
É secreta
É resistente a ser descoberta
É resistente a um ataque brute-force
As seções seguintes mostram como as senhas podem ser fracas.
6.1.2.1.1. Senhas Curtas
Um senha curta (breve) é fraca porque é mais suscetível a um ataque brute-force. Para ilustrar isto, considere a tabela seguinte, onde o número de senhas potenciais que devem ser testadas num ataque brute-force é exibido. (Assume-se que as senhas consistem somente de letras em caixa baixa.)
| Tamanho da Senha | Senhas Potenciais |
|---|---|
| 1 | 26 |
| 2 | 676 |
| 3 | 17.576 |
| 4 | 456.976 |
| 5 | 11.881.376 |
| 6 | 308.915.776 |
Tabela 6-1. Tamanho da Senha Versus o Número de Senhas Potenciais
Como você pode ver, o número de senhas possíveis aumenta dramaticamente conforme seu tamanho aumenta.
 | Nota |
|---|---|
Apesar desta tabela terminar com seis caracteres, isto não é uma afirmação de que senhas de seis caracteres sejam longas o suficiente para uma boa segurança. Em geral, quanto mais longa a senha, melhor. |
6.1.2.1.2. Conjunto de Caracteres Limitado
O número de caracteres diferentes que podem compor uma senha tem um alto impacto na habilidade de um atacante conduzir um ataque brute-force. Por exemplo: ao invés de 26 caracteres diferentes que podem ser usados numa senha composta apenas de caixa baixa, por que não usamos também dígitos? Isto significa que cada caractere de uma senha pode ser um dos 36 caracteres ao invés de apenas 26. No caso de uma senha de seis caracteres, isto aumenta o número de senhas possíveis de 308.915.776 para 2.176.782.336.
Ainda há mais que pode ser feito. Se nós também incluirmos caixa alta e baixa nas senhas alfa-numéricas (para aqueles sistemas operacionais que as suportam), o número de senhas possíveis de seis caracateres aumenta para 56.800.235.584. Adicionando outros caracteres (tais como pontuação) aumenta ainda mais o número de senhas possíveis, tornando ainda mais difícil um ataque brute-force.
No entanto, tenha em mente que nem todo ataque contra uma senha é um ataque brute-force. As seções seguintes descrevem outros atributos que podem formar uma senha fraca.
6.1.2.1.3. Palavras Reconhecíveis
Muitos ataques contra senhas são baseados no fato da maioria das pessoas se sentirem mais confortáveis com senhas que possam lembrar. E, para a maioria das pessoas as senhas memoráveis são aquelas que contêm palavras. Consequentemente, a maioria dos ataques a senhas são baseados no dicionário. Em outras palavras, o atacante utiliza dicionários de palavras para tentar encontrar a palavra ou palavras que formam uma senha.
 | Nota |
|---|---|
Muitos programas de ataque a senhas baseadas em dicionário usam dicionários de múltiplos idiomas. Consequentemente, você não pode acreditar que tem uma senha forte apenas porque utilizou palavras não inglesas na sua senha. |
6.1.2.1.4. Informações Pessoais
Senhas que contêm informações pessoais (o nome ou data de aniversário de uma pessoa querida, de um animal de estimação ou um número de identificação pessoal) podem ou não ser pegas por um ataque a senha baseada em dicionário. No entanto, se o atacante te conhece pessoalmente (ou está suficientemente motivado a pesquisar sua vida pessoal), ele pode ser capaz de adivinhar sua senha com nenhuma ou pouca dificuldade.
Além dos dicionários, muitos crackers de senhas incluem nomes comuns, datas e outras informações deste tipo em suas procuras por senhas. Portanto, mesmo que o atacante não saiba que o nome do seu cachorro é Duque, ainda podem descobrir que sua senha é "meucaoduque" com um bom cracker de senhas.
6.1.2.1.5. Truques com Palavras Simples
Usar quaisquer das informações abordadas anteriormente é a base de uma senha, mas inverter a ordem dos caracteres não torna uma senha fraca numa senha forte. Muitos crackers de senhas executam este tipo de truques em senhas possíveis. Isto inclui substituir determinados números por letras em palavras comuns. Aqui estão alguns exemplos:
drowssaPdaB1
R3allyP00r
6.1.2.1.6. A Mesma Senha para Múltiplos Sistemas
Mesmo que você tenha uma senha forte, é uma má idéia usar exatamente a mesma senha em mais de um sistema. Obviamente, há pouco a ser feito se os sistemas estão configurados para usar algum tipo de servidor de autenticação central, mas em todos os outros casos, deve-se usar senhas diferentes para cada sistema.
6.1.2.1.7. Senhas no Papel
Uma outra maneira de enfraquecer uma senha é anotá-la. Ao escrever uma senha num papel, você não tem mais um problema de discrição, mas sim um problema de segurança física — agora você deve proteger um pedaço de papel. Consequentemente, anotar uma senha nunca é uma boa idéia.
No entanto, algumas empresas têm uma necessidade legítima de senhas escritas. Por exemplo: algumas empresas têm senhas escritas como parte do procedimento de recuperação após a perda de funcionários chave (tais como administradores de sistemas). Nestes casos, o papel contendo as senhas é armazenado num local protegido fisicamente, que requer a cooperação de diversas pessoas para acessar o papel. Passagens com vários cadeados e cofres de banco são frequentemente usados.
Qualquer empresa que utiliza este método de armazenar senhas para emergências deve estar ciente de que a existência de senhas escritas adiciona um elemento de risco à segurança de seus sistemas. Não importa o quão protegidas estejam as senhas escritas, principalmente se é de conhecimento geral que as senhas estão escritas (e onde estão armazenadas).
Infelizmente, as senhas escritas frequentemente não fazem parte de um plano de recuperação e não são armazenadas com segurança, mas são senhas de usuários comuns, armazenadas nos seguintes locais:
Na gaveta da mesa (trancada ou não)
Em baixo de um teclado
Numa carteira
Anexo ao lado de um monitor
Nenhum destes locais são apropriados para armazenar uma senha escrita.
6.1.2.2. Senhas Fortes
Nós já vimos como se parecem as senhas fracas; as seções seguintes abordam características presentes em todas as senhas fortes
6.1.2.2.1. Senhas Mais Longas
Quanto mais longa a senha, menor a possibilidade de um ataque brute-force ser bem sucedido. Consequentemente, se o seu sistema operacional a suporta, defina um tamanho mínimo relativamente grande para as senhas de seus usuários.
6.1.2.2.2. Conjunto de Caracteres Expandido
Estimule o uso de caixas alta e baixa, senhas alfa-numéricas e recomende fortemente a adição de pelo menos um caracter não alfa-numérico em todas as senhas:
t1Te-Bf,te
Lb@lbhom
6.1.2.2.3. Memorável
Uma senha é forte se pode ser lembrada. Entretanto, ser memorável e de fácil descoberta frequentemente andam juntas. Sendo assim, ofereça à sua comunidade de usuários algumas dicas para a criação de senhas memoráveis que não podem ser facilmente descobertas.
Por exemplo: pense numa frase ou ditado favorito e use as primeiras letras de cada palavra como o ponto de partida para a criação de uma nova senha. O resultado é memorável (porque a frase na qual baseia-se é memorável), mas não contém palavras.
| Nota |
|---|---|
Tenha em mente que usar apenas as primeiras letras de cada palavra de frase não é o suficiente para criar uma senha forte. Certifique-se de sempre aumentar o conjunto de caracteres da senha, incluindo caracteres alfa-numéricos em caixas alta e baixa e, pelo menos, um caracter especial também. |
6.1.2.3. Expiração de Senhas
Se for possível, implemente a expiração de senhas na sua empresa. A expiração de senhas é uma funcionalidade (disponível em diversos sistemas operacionais) que define limites de tempo para uma senha ser considerada válida. No fim da vida de uma senha, o usuário deve inserir uma nova senha, que pode ser usada até que (esta também) expire.
A principal questão relacionada à expiração de senhas vivenciada por muitos administradores de sistemas é o tempo de vida da senha. Quão longo deve ser?
Há duas questões cruciais e opostas relacionadas à expiração de senhas:
Conveniência do usuário
Segurança
Em um extremo, o tempo de vida de uma senha de 99 anos apresentaria pouca (ou nenhuma) inconveniência para o usuário. No entanto, ofereceria muito pouca (ou nenhuma) melhoria na segurança.
No outro extremo, uma senha com tempo de vida de 99 minutos seria uma grande inconveniência para seus usuários. Entretanto, a segurança seria bem maior.
A idéia é encontrar um equilíbrio entre a conveniência requerida por seus usuários e a necessidade de segurança de sua empresa. Para a maioria das empresas, o tempo de vida da senha no intervalo de semanas a meses é o mais comum.
6.1.3. Informações de Controle de Acesso
Juntamente ao nome de usuário e senha, as contas de usuário contêm informações de controle de acesso. Estas informações têm formatos diferentes de acordo com o sistema operacional. No entanto, os tipos de informação geralmente incluem:
Identificação específica do usuário para todo o sistema
Identificação específica do grupo para todo o sistema
Listas de grupos/funcionalidades adicionais às quais o usuário pertence
Informações de acesso default a serem aplicadas para todos os arquivos e recursos criados pelo usuário
Em algumas empresas, as informações de controle de acesso do usuário talvez nunca precisem ser alteradas. Isto é mais frequente nos casos com standalone e estações de trabalho pessoais, por exemplo. Outras empresas, especialmente aquelas que utilizam extensivamente o compartilhamento de recursos entre diferentes grupos de usuários através da rede, requerem que as informações de controle de acesso do usuário sejam bastante modificadas.
A carga de trabalho necessária para manter corretamente as informações de controle de acesso do usuário varia de acordo com a escala do uso que sua empresa faz das funcionalidades de controle de acesso do sistema operacional. Apesar de não ser ruim confiar veementemente nestas funcionalidades (talvez seja inevitável), significa que o ambiente de seu sistema pode precisar de um esforço maior para ser mantido, e que todas as contas de usuário têm maior probabilidade de serem configuradas incorretamente.
Consequentemente, se sua empresa requer este tipo de ambiente, você deve certificar-se de documentar exatamente os passos necessários para criar e configurar corretamente a conta de usuário. De fato, se há tipos diferentes de contas de usuário, você deve documentar cada uma delas (como criar uma nova conta de usuário da área financeira, da área de operações, etc.).
6.1.4. Administrando Contas e Acesso a Recursos no Dia-a-Dia
Como diz o velho ditado: a única constante é a mudança. E não é diferente ao lidar com sua comunidade de usuários. Pessoas vêm e vão, mudam de um conjunto de responsabilidades para outro. Sendo assim, administradores de sistemas devem ser capazes de responder às mudanças, muito comuns no dia-a-dia das empresas.
6.1.4.1. Novas Contratações
Quando uma nova pessoa é contratada pela empresa, normalmente recebe acesso a vários recursos (de acordo com suas responsabilidades). Provavelmente, ela recebe uma mesa para trabalhar, um aparelho de telefone e uma chave da porta principal.
Talvez ela também receba acesso a um ou mais computadores de sua empresa. Como administrador de sistemas, é sua responsabilidade executar esta tarefa rápida e apropriadamente. Como você deve fazer isso?
Antes de qualquer coisa, você deve estar ciente da chegada desta pessoa. Isto é feito de maneiras diferentes em empresas diversas. Aqui estão algumas possibilidades:
Crie um processo no qual o departamento de recursos humanos de sua empresa te notifica a chegada de um novo funcionário.
Crie um formulário a ser preenchido pelo supervisor do novo funcionário e usado para requerer uma nova conta.
Empresas diferentes requerem táticas diferentes. Independentemente de como é feito, é vital que você tenha um processo altamente confiável que possa alertá-lo sobre qualquer tarefa relacionada a contas a ser executada.
6.1.4.2. Desligamentos
É fato que algumas pessoas deixarão sua empresa. Às vezes, isto ocorre sob circunstâncias felizes e outras vezes não. Em ambos os casos, é vital que você seja notificado da situação, para que possa executar as ações apropriadas.
No mínimo, as ações apropriadas incluem:
Desabilitar o acesso do usuário a todos os sistemas e recursos relacionados (geralmente alterando/bloqueando a senha do usuário)
Fazer um backup dos arquivos do usuário, caso contenham alguma informação futuramente necessária
Coordenar o acesso aos arquivos do usuário junto ao seu gerente
A prioridade principal é proteger seus sistemas contra o funcionário recém-desligado. Isto é importante principalmente se o usuário foi desligado sob condições que o façam sentir-se prejudicado pela empresa. Entretanto, mesmo se as condições não forem tão ruins, é do interesse de sua empresa que você desabilite o acesso desta pessoa de maneira rápida e confiável.
Isto indica a necessidade de um processo que te alerte sobre todos os desligamentos — de preferência, até antes do desligamento ocorrer. Sendo assim, é aconselhável você trabalhar junto ao departamento de recursos humanos de sua empresa para garantir que seja alertado sobre futuros desligamentos.
| Dica |
|---|---|
Quando você enfrentar "lock-downs" do sistema em virtude de desligamentos, é importante agir rapidamente. Se o lock-down ocorrer após terminar o processo de desligamento, existe a possibilidade de acesso não-autorizado do funcionário recém-desligado. Por outro lado, se o lock-down ocorrer antes do início do processo de desligamento, pode alertar o funcionário sobre seu possível desligamento e dificultar o processo para todas as partes envolvidas. O processo de desligamento geralmente é iniciado numa reunião entre o funcionário a ser desligado, seu gerente e um representante do departamento de recursos humanos da empresa. Sendo assim, estabelecer um processo que te alerte sobre o desligamento quando esta reunião começar, garante que o lock-down seja feito oportunamente. |
Após desabilitar o acesso, é hora de fazer uma cópia backup dos arquivos do funcionário recém-desligado. Este backup pode ser parte do padrão de backups de sua empresa, ou pode ser um procedimento de backup dedicado a contas velhas de usuários. A maneira mais apropriada de lidar com backups abrange regulamentação de retenção, preservar evidências nos casos de desligamentos através de processos jurídicos e outros.
Em todos os casos, é bom fazer o backup já que o próximo passo (acesso do gerente aos arquivos do funcionário recém-desligado) pode resultar acidentalmente na remoção de arquivos. Nestas circunstâncias, ter um backup possibilita recuperar os arquivos facilmente, facilitando o processo para o gerente e para você.
Neste ponto, você deve determinar qual tipo de acesso o gerente do funcionário recém-desligado deve ter aos arquivos. Dependendo da empresa e da natureza das responsabilidades do ex-funcionário, pode não ser necessário nenhum acesso, ou então acesso a tudo.
Se o ex-funcionário usou seus sistemas para algo além de e-mails ocasionais, é provável que o gerente tenha que examinar os arquivos, determinar o que deve ser guardado e o que deve ser descartado. Ao término deste processo, ao menos alguns destes arquivos devem ser dados à pessoa ou pessoas assumindo as responsabilidades do ex-funcionário. Talvez sua ajuda seja necessária neste último passo do processo, ou talvez o gerente possa resolvê-lo sozinho. Tudo depende dos arquivos e da natureza do trabalho de sua empresa.
6.1.4.3. Alterações de Função
Responder aos pedidos de criação de contas para novos usuários e lidar com a sequência de eventos necessária para bloquear (lock-down) uma conta quando a pessoa é desligada são processos relativamente simples. No entanto, não é tão simples quando as responsabilidades de uma pessoa são alteradas dentro da empresa. Às vezes, a pessoa pode precisar de alterações em sua conta, outras vezes não.
Haverá ao menos três pessoas envolvidas para garantir que a conta do usuário seja reconfigurada corretamente para refletir suas novas responsabilidades:
Você
O gerente original do usuário
O novo gerente do usuário
Dentre vocês três, deve ser possível determinar o que deve ser feito para encerrar de forma clara as responsabilidades velhas do usuário e as ações para preparar a conta do usuário para suas novas responsabilidades. Sob vários aspectos, este processo pode ser equiparado a encerrar uma conta de usuário existente e criar uma nova conta. De fato, algumas empresas fazem isto para todas as mudanças de responsabilidade.
Entretanto, é mais provável que a conta do usuário seja mantida e alterada apropriadamente para suportar suas novas responsabilidades. Esta tática significa que você precisa rever cuidadosamente a conta para garantir que tenha somente aqueles recursos e privilégios apropriados às novas responsabilidades da pessoa.
Para complicar um pouco mais a situação, frequentemente existe um período de transição, no qual o usuário executa tarefas relacionadas aos dois conjuntos de responsabilidades. É neste ponto que os gerentes antigo e novo do usuário podem ajudá-lo, oferecendo-lhe um prazo para este período de transição.