locked
Porta SQL RRS feed

  • Pergunta

  • Tenho um sistema que sera instalado em um servidor Win2003 server como banco de dados SQL Server, algumas estacoes nao estarao interligadas fisicamente mas possuem internet. Gostaria de uma opiniao sobre a melhor forma de conectar essas estacoes com o banco de dados.
    A principio pensei em usar terminal server mas ficaria caro pois existem mais de 30 clientes. Andei pesquisando e vi que posso liberar uma porta diretamente do SQL mas fiquei preocupada com a seguranca do servidor. Eh seguro deixar liberado essa porta pra mais de 30 estacoes? E o desempenho?

    Autor
    segunda-feira, 24 de agosto de 2009 17:01

Respostas

  • Olá,

    Se a idéia é apenas conectar ao SQL Server, basta liberar apenas a porta 1433 ( que é a porta padrão do SQL Server ) no firewall e o SQL Server Browser.

    Segue artigo muito bom:

    http://www.linhadecodigo.com.br/ArtigoImpressao.aspx?id=1260

    Abraços
    Demétrio Silva
    segunda-feira, 24 de agosto de 2009 17:56
  • Minha sugestão:

      1 - Desabilite o serviço SQL Browser, pois o mesmo é responsável por informar em qual porta o SQL Server está escutando.
      2 - Libere uma porta no SQL Server, a porta padrão é a 1433, como é muito conhecida é uma boa prática alterar para outro valor, por exemplo 64455.
      3 - A porta liberada deve ser de conhecimento apenas da(s) estações que irão utilizar o SQL Server.
      4 - Terminal Services ou Citrix, seria uma opção para colocar a aplicação, mas como não existe licensa e você possui apenas 30 estações pode apontar a   aplicação diretamente.
      5 - O ideal é que apenas as estações onde a aplicação esteja instalada e os micros das pessoas responsáveis pela administração do SQL Server, consiga enxergar e se comunicar com o servidor SQL Server, você consegue fazer isso através de configurações de rede e firewall.
     6 - Use a politica de permissões o mais restritivo possível, ou seja, apenas de permissão para o que realmente for necessário, normalmente (leitura e escrita).
     7 - Crie um nome de serviço para a aplicação se comunicar com o sql server ex: servsqlprd@meudominio.com.br, assim na aplicaçao você não informa o IP do servidor, permitindo assim se necessário trocar o ip do servidor sem afetar a aplicação.
     8 - Login e senha do SQL Server ñão deve ser de conhecimento de usuários da aplicação, a mesma deve estar encapsulada na aplicação.
     9 - O ideal é que nem o desenvolvedor soubesse a senha de conexão do ambiente de produção, você pode fazer isso, disponibilizando um arquivo com usuários e senhas por exemplo em um webservice, onde a aplicação efetuaria leitura deste arquivo para pegar o login e senha, o ideal também seria usar autenticação integrada do windows, porém na maioria dos casos isso não é possível.
    10 - O fato do SQL estar instalado no WIn Server 2003, possibilita utilizar politicas de logins e senhas do windows, evitando assim ataques para quebrar a senha por foça bruta, configure por exemplo para bloquear o usuário após 5 tentativas de logins com senha incorreta.

    estas são apenas algumas dicas de segurança, nem sempre é simples conseguir implantar todas elas, mas espero que seja um ponto de partida para conseguir configurar seu ambiente de forma mais segura possível.

    Relacionado a desempenho 30 conexões simultaneas que também não é seu caso, pois 30 estações não significa que os 30 serão usuários simultaneos, é praticamente insignificante para o SQL Server, caso sua aplicação apresente problemas de performance, com certeza não será devido a terem 30 estações se comunicando com o banco de dados, e sim devido a algum problema de muito locks wait, transações mal projetada, consultas mal planejadas, ou uma outra de infinidade de problemas que pode gerar lentidão.

    abraço e mãos a obra.
    DBA SQL Server MCTS - SQL Server 2005 | ITIL Foundation V2 http://www.bydocs.com
    terça-feira, 25 de agosto de 2009 03:47

Todas as Respostas

  • Olá,

    Se a idéia é apenas conectar ao SQL Server, basta liberar apenas a porta 1433 ( que é a porta padrão do SQL Server ) no firewall e o SQL Server Browser.

    Segue artigo muito bom:

    http://www.linhadecodigo.com.br/ArtigoImpressao.aspx?id=1260

    Abraços
    Demétrio Silva
    segunda-feira, 24 de agosto de 2009 17:56
  • Minha sugestão:

      1 - Desabilite o serviço SQL Browser, pois o mesmo é responsável por informar em qual porta o SQL Server está escutando.
      2 - Libere uma porta no SQL Server, a porta padrão é a 1433, como é muito conhecida é uma boa prática alterar para outro valor, por exemplo 64455.
      3 - A porta liberada deve ser de conhecimento apenas da(s) estações que irão utilizar o SQL Server.
      4 - Terminal Services ou Citrix, seria uma opção para colocar a aplicação, mas como não existe licensa e você possui apenas 30 estações pode apontar a   aplicação diretamente.
      5 - O ideal é que apenas as estações onde a aplicação esteja instalada e os micros das pessoas responsáveis pela administração do SQL Server, consiga enxergar e se comunicar com o servidor SQL Server, você consegue fazer isso através de configurações de rede e firewall.
     6 - Use a politica de permissões o mais restritivo possível, ou seja, apenas de permissão para o que realmente for necessário, normalmente (leitura e escrita).
     7 - Crie um nome de serviço para a aplicação se comunicar com o sql server ex: servsqlprd@meudominio.com.br, assim na aplicaçao você não informa o IP do servidor, permitindo assim se necessário trocar o ip do servidor sem afetar a aplicação.
     8 - Login e senha do SQL Server ñão deve ser de conhecimento de usuários da aplicação, a mesma deve estar encapsulada na aplicação.
     9 - O ideal é que nem o desenvolvedor soubesse a senha de conexão do ambiente de produção, você pode fazer isso, disponibilizando um arquivo com usuários e senhas por exemplo em um webservice, onde a aplicação efetuaria leitura deste arquivo para pegar o login e senha, o ideal também seria usar autenticação integrada do windows, porém na maioria dos casos isso não é possível.
    10 - O fato do SQL estar instalado no WIn Server 2003, possibilita utilizar politicas de logins e senhas do windows, evitando assim ataques para quebrar a senha por foça bruta, configure por exemplo para bloquear o usuário após 5 tentativas de logins com senha incorreta.

    estas são apenas algumas dicas de segurança, nem sempre é simples conseguir implantar todas elas, mas espero que seja um ponto de partida para conseguir configurar seu ambiente de forma mais segura possível.

    Relacionado a desempenho 30 conexões simultaneas que também não é seu caso, pois 30 estações não significa que os 30 serão usuários simultaneos, é praticamente insignificante para o SQL Server, caso sua aplicação apresente problemas de performance, com certeza não será devido a terem 30 estações se comunicando com o banco de dados, e sim devido a algum problema de muito locks wait, transações mal projetada, consultas mal planejadas, ou uma outra de infinidade de problemas que pode gerar lentidão.

    abraço e mãos a obra.
    DBA SQL Server MCTS - SQL Server 2005 | ITIL Foundation V2 http://www.bydocs.com
    terça-feira, 25 de agosto de 2009 03:47