quarta-feira, 8 de setembro de 2010

Gerenciamento de usuários e segurança

Temos nos TSMServer, desde a versão 5.3 a atual, dois tipos de usuários administradores.: Administradores default que possuem permissão para executar ações administrativas no ambiente e usuários que utilizam o Centro de Administração, através do ISC (Integrated Solutions Console).

Todas as vezes que um novo administrador é registrado no TSMServer, o mesmo é criado com perfil default, ou seja, com o nível de permissão mais baixo, onde possui limitada capacidade de executar tarefas.

Por default, estes administradores conseguem executar, via command line, queries(consultas) básicas e chamar o help.

Para terem permissão de executar outras tarefas, classes de privilégio são associadas a esses usuários.

As classes de privilégio são.:

  • policy

  • storage

  • operator

  • analyst

  • node

  • system
As classes de privilégio são associadas através do comando granth authority e somente o usuário com classe system pode dar privilégio para outro usuário.

Acompanhe a ilustração abaixo sobre as classes de privilégio. Em seguida uma explanação sobre cada uma delas e como efetuar a criação de um usuário, associar a uma classe de privilégio e como remover esse privilégio.







SYSTEM.:
Um administrador com privilégio SYSTEM é o que possui o maior nível de autoridade no ambiente do TSM. Com este perfil, é possível executar qualquer comando administrativo, tem permissão para gerencial todas as policys domains e todos os storage pools. Somente um administrador com perfil SYSTEM possui permissão para associar ou retirar classes de privilégio a outros usuários.

POLICY.:
Um administrador com privilégio POLICY possui permissão sem restrição alguma para o gerenciamento das definições de BACKUP e ARCHIVE, como por exemplo, MGMT Class, Copygroups e schedules) para os nodes associados a qualquer policy domain.
No entanto um administrador com privilégio POLICY não possui permissão para definit, deletar ou copiar uma policy domain. Somente o usuário SYSTEM tem essa permissão.

Quando uma nova policy domain é criada no ambiente, o usuário com privilégio POLICY, automaticamente terá permissão para gerenciá-la.

STORAGE.:
Um administrador com privilégio STORAGE possui permissão sem restrição para administração do TSM database, recovery log, stgpools e alocação e controle dos recursos de storage do servidor. No entanto este usuário, não possui privilégio para definir ou deletar storage pools existentes.

O administrador com privilégio STORAGE terá a permissão irrestrita a um storage pool, somente se o stgpool for informado, ou seja, pode-se limitar a atuação deste administrador a somente algum storage pool e não todos.

Se o administrador com privilégio STORAGE possuir alguma restrição, o mesmo não terá permissão para administrar o DB / LOG do TSMServer.

OPERATOR.:
Um administrador com privilégio OPERATOR é capaz de controlar a operação imediata do TSM e a disponibilidade dos devices de media, por exemplo, gerenciar as sessões de clients e o gerenciamento de tapes.

ANALYST.:
Um administrador com privilégio ANALYST é capaz de efetuar comandos que zere, ou resetem os contadores que seguem as estatísticas do servidor, mas por outro lado, pode apenas realizar consultas simples.

NODE.:
Um administrador com privilério NODE é capaz de acessar remotamente a interface Web, do backup-archive client e executar operações de backup e restore, desde que possua o nome e senha do node. Este privilégio pode ser concedido para um node específico ou para todos os nodes de um domínio.


Exemplo.:
Suponha que você administrador que possui privilégio de system, precise criar um usuário chamado joao.

TSMSRV>register admin joao joao123 passexp=60 contact='Joao da Silva(Depto. Backup Restore - Ramal 000)' forcepwreset=yes
ANR2068I Administrator JOAO registered.

Atente para o comando e os parâmetros utilizados.:
1- Foi registrado um novo usuário chamado joao
2- A senha inicial atribuída a este usuário é joao123
3- passexp é o parâmetro que obriga o usuário a trocar de senha a cada 60 dias
4- Contact é o parâmetro para descrever o contato do usuário, exemplo, (departamento, ramal, nome completo, matrícula..etc..)
5- forcepwreset é o parâmetro que força o usuário a trocar de senha no primeiro logon.
 
Vamos verificar o usuário criado.:
 
TSMSRV> query admin joao f=d

Administrator Name: JOAO
Last Access Date/Time: 09/08/10 11:44:30
Days Since Last Access: <1
Password Set Date/Time: (?)
Days Since Password Set: (?)
Invalid Sign-on Count: 0
Locked?: No
Contact: Joao da Silva(Depto. Backup Restore - Ramal 000)
System Privilege:
Policy Privilege:
Storage Privilege:
Analyst Privilege:
Operator Privilege:
Client Access Privilege:
Client Owner Privilege:
Registration Date/Time: 09/08/10 11:44:30
Registering Administrator: ADMIN
Managing profile:
Password Expiration Period: 60 Day(s)
Email Address:

Note que o joao ainda não possui nenhuma classe de privilégio associada e portanto o mesmo não possui permissão para realizar quase nenhuma tarefa.
 
Vamos atribuir a classe system.:
 
TSMSRV>grant authority JOAO class=system
ANR2076I System privilege granted to administrator JOAO.

TSMSRV> query admin joao f=d
Administrator Name: JOAO

Last Access Date/Time: 09/08/10 11:44:30
Days Since Last Access: <1
Password Set Date/Time: (?)
Days Since Password Set: (?)
Invalid Sign-on Count: 0
Locked?: No
Contact: Joao da Silva(Depto. Backup Restore - Ramal 000)
System Privilege: Yes
Policy Privilege: ** Included with system privilege **
Storage Privilege: ** Included with system privilege **
Analyst Privilege: ** Included with system privilege **
Operator Privilege: ** Included with system privilege **
Client Access Privilege: ** Included with system privilege **
Client Owner Privilege: ** Included with system privilege **
Registration Date/Time: 09/08/10 11:44:30
Registering Administrator: ADMIN
Managing profile:
Password Expiration Period: 60 Day(s)
Email Address:

Percebam a diferença nas classes de privilégio em negrito. Com a classe SYSTEM, o joao tem permissão para realizar qualquer coisa no ambiente.
 
Vamos agora retirar a classe SYSTEM e associar a classe STORAGE, informando que o joao somente terá permissão para trabalhar com o storage pool de disco chamado TAPE_POOL
 
TSMSRV> revoke authority joao class=system
ANR2083I System privilege revoked for administrator JOAO.

TSMSRV> grant auth joao class=storage stgpool=tape_pool
ANR2080I Restricted storage privilege granted to administrator JOAO - storage pool TAPE_POOL.

TSMSRV> query admin joao f=d

Administrator Name: JOAO
Last Access Date/Time: 09/08/10 11:44:30
Days Since Last Access: <1
Password Set Date/Time: (?)
Days Since Password Set: (?)
Invalid Sign-on Count: 0
Locked?: No
Contact: Joao da Silva(Depto. Backup Restore - Ramal 000)
System Privilege:
Policy Privilege:
Storage Privilege: TAPE_POOL
Analyst Privilege:
Operator Privilege:
Client Access Privilege:
Client Owner Privilege:
Registration Date/Time: 09/08/10 11:44:30
Registering Administrator: ADMIN
Managing profile:
Password Expiration Period: 60 Day(s)
Email Address:

Desta forma garantimos que o joao somente terá permissão em um único stgpool.


Para verificar os demais parâmetros para cada comando, utilize o help.

TSMSRV> help register admin
TSMSRV> help grant authority

E assim por diante.


Caso tenham alguma dúvida, ou sugestão, mande um email.: tsmnapratica@gmail.com


Tenham todos um ótimo dia!

quinta-feira, 2 de setembro de 2010

Política de Backup baseada em versionamento

Hoje quero falar sobre política de backup baseada em verionamento, respondendo a uma dúvida de um leitor.
Como foi dito anteriormente, o TSM possui a capacidade de trabalhar não somente com retenção de dados por dias, mas também por versão.
Como funciona? Basicamente, o TSM irá aplicar os parâmetros que foram configurados no COPYGROUP, se recordam quais eram essas opções ?

VEREXISTS.: É o número máximo de versões de um mesmo objeto que serão retidas se esse objeto existir fisicamente no servidor. Default é 2, e pode ser setado de 1 a 9999, ou Nolimit.
VERDELETED.: É o número máximo de versões de um mesmo objeto que serão retidas se esse objeto for DELETADO fisicamente no servidor. Default é 1, e pode ser setado de 1 a 9999, ou Nolimit.
RETEXTRA.: É o número de dias de retenção de um objeto após ele se tornar inativo. O default é 30 dias. Pode ser setado de 0 a 9999 , ou Nolimit.
RETONLY.: É o número de dias de retenção de um objeto após ser deletado fisicamente do servidor. O default é 60 dias. Pode ser setado de 0 a 9999 , ou Nolimit

Vamos acompanhar a ilustração abaixo, onde é possível acompanhar passo-a-passo como se aplica.:
 

 
 














Espero assim ter contribuído um pouco para sanar as dúvidas do leitor. Caso tenham outras dúvidas, ou sugestões de temas a serem abordados aqui, entrem em contato.: tsmnapratica@gmail.com
 
 
Tenham todos um ótimo dia.