none
Documento ou procedimento com as melhores práticas de acesso de usuários no SQL Server RRS feed

  • Pergunta

  • Boa noite a todos,
    Gostaria de saber se alguém conhece algum documento ou procedimento com as melhores práticas de acesso de usuários no SQL Server, pois estou redefinindo as permissões de acesso de todos os usuários do banco.
    Ex: Usuários de aplicação pode por exemplo criar tabelas no banco ... etc etc etc? 
    São esses tipos de permissões que preciso organizar no banco de dados. 
    Alguém pode me ajudar????
    sábado, 28 de maio de 2016 11:20

Respostas

  • Você encontra algumas informações em

    https://msdn.microsoft.com/en-us/library/bb283235.aspx

    https://www.mssqltips.com/sqlservertip/3159/sql-server-security-checklist/

    http://www.hexatier.com/microsoft-sql-server-database-security-best-practices/

    Mas eu entendo sua preocupação, que na verdade não está relacionado a como configurar a segurança do seu SQL Server, mas sim, qual é a prática no mercado em relação às permissões que são dadas, pois bem, acredito que tinha uma das linhas de segurança mais interessantes que já vi para atender questões de SARBOX. Era assim:

    • Usuário de Aplicação: Somente tinha acesso de INSERT, UPDATE, DELETE, SELECT e EXECUTE. Desta forma, a aplicação não tinha privilégios para criação de nenhum objeto;
    • Desnvolvedores: Não tinham acesso ao ambiente de produção para manipulação de dados ou criação de objetos, se necessário fosse alguma manipulação, então após uma solicitação o acesso era concedido temporariamente e monitorado;
    • DBA: Responsável por executar os scripts DDL, ou seja, CREATE, ALTER e DROP no banco de dados das aplicações;
    • Triggers de Acesso: Para evitar que usuários comuns utilizassem o usuário de aplicação para manipular informações, ou seja, o usuário de aplicação era para uso restrito do sistema, qualquer coisa, diferente do que era sistema era dropada a conexão;

    Na prática se a empresa não "comprar" essa ideia, é bem difícil, pois você "engessa" bastante a empresa, mas eu sou extremamente a favor de o usuário da aplicação não ser o Owner, pois em caso de um SQL Injection ou qualquer acesso indevido você tem um alto risco.

    Espero que responda sua dúvida!


    Vithor da Silva e Silva | SQL Server Consultant and Trainer | vithor@vssti.com.br | Blog: http://www.vssti.com.br/blog ** Por favor, lembre-se de “Marcar como Resposta” as respostas que resolveram o seu problema. **

    quarta-feira, 8 de junho de 2016 14:36

Todas as Respostas

  • EduPortoSantos,

    O próprio Books On-Line é uma ótima referência no que se relaciona a segurança do SQL Server.


    Pedro Antonio Galvao Junior [MVP | MCC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitario | SoroCodigos | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    domingo, 29 de maio de 2016 01:16
    Moderador
  • Você encontra algumas informações em

    https://msdn.microsoft.com/en-us/library/bb283235.aspx

    https://www.mssqltips.com/sqlservertip/3159/sql-server-security-checklist/

    http://www.hexatier.com/microsoft-sql-server-database-security-best-practices/

    Mas eu entendo sua preocupação, que na verdade não está relacionado a como configurar a segurança do seu SQL Server, mas sim, qual é a prática no mercado em relação às permissões que são dadas, pois bem, acredito que tinha uma das linhas de segurança mais interessantes que já vi para atender questões de SARBOX. Era assim:

    • Usuário de Aplicação: Somente tinha acesso de INSERT, UPDATE, DELETE, SELECT e EXECUTE. Desta forma, a aplicação não tinha privilégios para criação de nenhum objeto;
    • Desnvolvedores: Não tinham acesso ao ambiente de produção para manipulação de dados ou criação de objetos, se necessário fosse alguma manipulação, então após uma solicitação o acesso era concedido temporariamente e monitorado;
    • DBA: Responsável por executar os scripts DDL, ou seja, CREATE, ALTER e DROP no banco de dados das aplicações;
    • Triggers de Acesso: Para evitar que usuários comuns utilizassem o usuário de aplicação para manipular informações, ou seja, o usuário de aplicação era para uso restrito do sistema, qualquer coisa, diferente do que era sistema era dropada a conexão;

    Na prática se a empresa não "comprar" essa ideia, é bem difícil, pois você "engessa" bastante a empresa, mas eu sou extremamente a favor de o usuário da aplicação não ser o Owner, pois em caso de um SQL Injection ou qualquer acesso indevido você tem um alto risco.

    Espero que responda sua dúvida!


    Vithor da Silva e Silva | SQL Server Consultant and Trainer | vithor@vssti.com.br | Blog: http://www.vssti.com.br/blog ** Por favor, lembre-se de “Marcar como Resposta” as respostas que resolveram o seu problema. **

    quarta-feira, 8 de junho de 2016 14:36