locked
Entendendo passos para Criação Usuários RRS feed

  • Pergunta

  • Pessoal, já vi algumas threads falando sobre esse assunto e vi algumas coisas do tipo.

    - Criação de login antes de criação do usuario e o inverso também.

    Por isso estou na dúvida. Porque tenho que ter um Create Login e um Create User? Minhas pergunta é porque o usuario SA tem apenas o login e não um user para ele(vi que não tem um user entrando em um banco específico, Security, Users), e mesmo assim ele acessa as tabelas.

    Estou começando a estudar usuários para tirar de vez o uso apenas do SA aos nossos bancos.
    • Movido Gustavo Maia Aguiar quinta-feira, 4 de março de 2010 17:48 (De:SQL Server - Desenvolvimento Geral)
    quinta-feira, 4 de março de 2010 14:05

Respostas

  • Bom Dia,

    Acho que a forma mais didática para explicar logins e usuário é a seguinte:

    Imaginemos um prédio comercial com vários escritórios e pessoas nesses escritórios. Para que você consiga falar com alguma pessoa você terá várias etapas para percorrer.

    É necessário que você tenha permissão para entrar no prédio
    É necessário que você tenha permissão para entrar no escritório
    É necessário que você tenha permissão para falar com a pessoa desejada

    O login é o que te dará acesso ao prédio, ou seja, ao possuir um login você pode conectar-se ao SQL Server e nada mais. O fato de entrar no prédio não lhe dá direito a entrar em nenhum escritório.

    O usuário é o que lhe dá direito de entrar em um escritório específico e assim como para cada escritório você precisará de uma permissão, com cada banco não é diferente. Você precisará de um usuário para cada banco especificamente. Veja que em tese, não há como ter um usuário sem um login, ou seja, você não conseguirá entrar no escritório senão pode entrar no prédio

    A pessoa é uma tabela, ou seja, para falar com ela você precisará ter permissão. Mas você não conseguirá falar com a pessoa se não tiver previamente a permissão de entrar no escritório e nem conseguirá entrar no escritório sem ter a permissão de entrar no prédio. Ou seja, para acessar uma tabela é preciso ter um login na instância, um usuário no banco e a permissão na tabela mapeada para esse usuário.

    No caso do SA, podemos simplesmente dizer que ele é o dono do prédio e por isso não necessitará de permissões para entrar em escritórios ou de falar com pessoas.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Encontrando tabelas não utilizadas
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!957.entry
    Classifique as respostas. O seu feedback é imprescindível
    quinta-feira, 4 de março de 2010 14:37
  • Oi Danilo,

    Há roles com escopo de servidor que se relacionam com logins e há roles com escopo de banco que se relacionam com usuários. Como as permissões nas tabelas tem escopo de banco você terá que criar roles em vários bancos e associar os usuários daquele banco com a role.

    -- Cria a ROLE
    CREATE ROLE rTabelas
    -- Concede permissão para acessar as tabelas
    GRANT SELECT ON A TO rTabelas
    GRANT SELECT ON B TO rTabelas
    GRANT SELECT ON C TO rTabelas
    GRANT SELECT ON D TO rTabelas
    GRANT SELECT ON E TO rTabelas
    -- Adiciona o usuário a um grupo
    EXEC sp_addrolemember 'rTabelas', 'UsuarioX'


    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Encontrando tabelas não utilizadas
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!957.entry


    Classifique as respostas. O seu feedback é imprescindível
    • Sugerido como Resposta Gustavo Maia Aguiar quinta-feira, 4 de março de 2010 17:48
    • Não Sugerido como Resposta Danilo Rogério quarta-feira, 15 de junho de 2011 16:41
    • Marcado como Resposta Danilo Rogério sexta-feira, 17 de junho de 2011 12:39
    quinta-feira, 4 de março de 2010 17:48

Todas as Respostas

  • O sa tem somente o login criado porque ele é SysAdmin então não precisa ter o user criado nos bancos.

    Beeeeem a grosso modo o Login, vc tem que criar para "logar" no servidor/instancia do SQLServer já a partir desse login, vc criar os usuários em cada um dos bancos que ele vai acessar no servidor.

     

     


    Tks. Fausto Fiorese Branco MCTS, MCITP/DBA 2005 | MCITP/DBA 2008 São Paulo - Brasil * http://www.linkedin.com/in/faustobranco
    • Marcado como Resposta Danilo Rogério quinta-feira, 4 de março de 2010 15:41
    • Não Marcado como Resposta Danilo Rogério quarta-feira, 15 de junho de 2011 16:42
    quinta-feira, 4 de março de 2010 14:18
  • Bom Dia,

    Acho que a forma mais didática para explicar logins e usuário é a seguinte:

    Imaginemos um prédio comercial com vários escritórios e pessoas nesses escritórios. Para que você consiga falar com alguma pessoa você terá várias etapas para percorrer.

    É necessário que você tenha permissão para entrar no prédio
    É necessário que você tenha permissão para entrar no escritório
    É necessário que você tenha permissão para falar com a pessoa desejada

    O login é o que te dará acesso ao prédio, ou seja, ao possuir um login você pode conectar-se ao SQL Server e nada mais. O fato de entrar no prédio não lhe dá direito a entrar em nenhum escritório.

    O usuário é o que lhe dá direito de entrar em um escritório específico e assim como para cada escritório você precisará de uma permissão, com cada banco não é diferente. Você precisará de um usuário para cada banco especificamente. Veja que em tese, não há como ter um usuário sem um login, ou seja, você não conseguirá entrar no escritório senão pode entrar no prédio

    A pessoa é uma tabela, ou seja, para falar com ela você precisará ter permissão. Mas você não conseguirá falar com a pessoa se não tiver previamente a permissão de entrar no escritório e nem conseguirá entrar no escritório sem ter a permissão de entrar no prédio. Ou seja, para acessar uma tabela é preciso ter um login na instância, um usuário no banco e a permissão na tabela mapeada para esse usuário.

    No caso do SA, podemos simplesmente dizer que ele é o dono do prédio e por isso não necessitará de permissões para entrar em escritórios ou de falar com pessoas.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Encontrando tabelas não utilizadas
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!957.entry
    Classifique as respostas. O seu feedback é imprescindível
    quinta-feira, 4 de março de 2010 14:37
  • Gustavo e Fausto, obrigado pela ajuda. Mesmo iniciando o uso de usuarios agora, tenho um cenario com muitos usuarios. E provavelmente irei gerenciá-los via Roles.

    Pensando nisso me deparei com o seguinte. As Roles também são criadas dentro de um banco de dados específico, correto?

    Eu necessitaria, por exemplo de criar uma Role X que acessa tabelas dos bancos A, B, C, D, E por exemplo.

    Para posteriormente dar os acessos aos usuários a essa role.

    Como posso proceder para fazer isso?


    quinta-feira, 4 de março de 2010 15:45
  • Oi Danilo,

    Há roles com escopo de servidor que se relacionam com logins e há roles com escopo de banco que se relacionam com usuários. Como as permissões nas tabelas tem escopo de banco você terá que criar roles em vários bancos e associar os usuários daquele banco com a role.

    -- Cria a ROLE
    CREATE ROLE rTabelas
    -- Concede permissão para acessar as tabelas
    GRANT SELECT ON A TO rTabelas
    GRANT SELECT ON B TO rTabelas
    GRANT SELECT ON C TO rTabelas
    GRANT SELECT ON D TO rTabelas
    GRANT SELECT ON E TO rTabelas
    -- Adiciona o usuário a um grupo
    EXEC sp_addrolemember 'rTabelas', 'UsuarioX'


    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Encontrando tabelas não utilizadas
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!957.entry


    Classifique as respostas. O seu feedback é imprescindível
    • Sugerido como Resposta Gustavo Maia Aguiar quinta-feira, 4 de março de 2010 17:48
    • Não Sugerido como Resposta Danilo Rogério quarta-feira, 15 de junho de 2011 16:41
    • Marcado como Resposta Danilo Rogério sexta-feira, 17 de junho de 2011 12:39
    quinta-feira, 4 de março de 2010 17:48