COMO CONVERSAR DE MODO SEGURO?
Bom dia!
Por uma questão de segurança,
Foi decidido na TI da empresa, que não poderemos mais criar
uma aplicação que estando fora da empresa, possa
acessar um dado dentro de nossa rede local.
Como algumas aplicações "externas" , dependem de dados de nossa BD ficou
o seguinte dilema:
"Como disponibilizar as informações necessárias para as aplicações externas sem permitir
seu acesso a nossa rede local ( E portanto a BD )"
Bom...
Uma das opções e que foi a mais bem aceita foi a de enviar as informações (Arquivos)necessários
pot FTP para estes servidores externos.
No entanto,um colega citou que a transferencia de arquivos por FTP não é segura, por poder ser interceptada.
Como meu conhecimento de segurança da informação é limitado, peço a orientação dos colegas:
Perguntas:
1.) A preocupação dele é valida?
2.) Num cenário "como este", o envio de informações para servidores externos deve mesmo ser feito por FTP
ou existem métodos melhores???
Por uma questão de segurança,
Foi decidido na TI da empresa, que não poderemos mais criar
uma aplicação que estando fora da empresa, possa
acessar um dado dentro de nossa rede local.
Como algumas aplicações "externas" , dependem de dados de nossa BD ficou
o seguinte dilema:
"Como disponibilizar as informações necessárias para as aplicações externas sem permitir
seu acesso a nossa rede local ( E portanto a BD )"
Bom...
Uma das opções e que foi a mais bem aceita foi a de enviar as informações (Arquivos)necessários
pot FTP para estes servidores externos.
No entanto,um colega citou que a transferencia de arquivos por FTP não é segura, por poder ser interceptada.
Como meu conhecimento de segurança da informação é limitado, peço a orientação dos colegas:
Perguntas:
1.) A preocupação dele é valida?
2.) Num cenário "como este", o envio de informações para servidores externos deve mesmo ser feito por FTP
ou existem métodos melhores???
Colega, enviar arquivos para FTP tem dois problemas iniciais que já tiram esta opção do rol de opções:
1) Duplicidade de informação, violando completamente a Consistencia e Disponibilidade dos Dados. Redundância é sói para backup, que deve ser feito em várias mÃÂdias, incluindo deixar uma fora da empresa, por questões de incendio, por exemplo.
2) Acesso às informações por criminosos é mais fácil em um FTP do que em uma rede privada e com mecanismos de segurança.
Basta a pergunta: será que o Google guarda as informações deles em um TXT localizado em FTP externo? Parece piada, mas é um argumento e tira a questão do "ftp" como opção.
Sei que o "FTP" poderia ser um servidor de dados espelhado, mas quem vai garantir a segurança no FTP, que alguém não vá lá, viole a integridade dos dados ou até altere dados?
E o custo para manter o FTP, que é não só dinheiro para mensalidade de um provedor, precisa de equipe para isto e banda do servidor interno para alimentar banco de dados no FTP.
E o FTP terá banda suficiente para receber o que vier do servidor interno da sua empresa?
Esqueça FTP, colega.
O foco deve ser a segurança da sua rede. Pode até n]ao ter conhecimentos sobre segurança da informação, mas certamente vai conseguir boas soluções, como a criação de um Bastião (servidor e rede falsos em que os invasores caem e vem dados irreais, que voce não precisa alimentar como certo, não precisa e nem deve ser espelho do servidor interno e real), além de criptografia dos dados, que ficam embaralhados no banco de dados, se um hacker invadir e conseguir acessar o banco de dados, ou mesmo copiar o banco de dados, será inútil para ele, porque somente nos teus fontes tem as rotinas de descriptografia.
E se o hacker bagunçar alguma coisa, fica claro que a informação é violada, porque violar dado encriptado faz o dado se tornar ilegÃÂvel quando desencriptado. E a bagunça pode ser desfeita com backup rotineiro, duas vezes ao dia.
Para começar: Bastião e criptografia, além do óbvio, que é checagem de login, criação de logs de acesso, incluindo no login a permissão por validação de equipamentos (baseados no MAC de cada equipamento).
1) Duplicidade de informação, violando completamente a Consistencia e Disponibilidade dos Dados. Redundância é sói para backup, que deve ser feito em várias mÃÂdias, incluindo deixar uma fora da empresa, por questões de incendio, por exemplo.
2) Acesso às informações por criminosos é mais fácil em um FTP do que em uma rede privada e com mecanismos de segurança.
Basta a pergunta: será que o Google guarda as informações deles em um TXT localizado em FTP externo? Parece piada, mas é um argumento e tira a questão do "ftp" como opção.
Sei que o "FTP" poderia ser um servidor de dados espelhado, mas quem vai garantir a segurança no FTP, que alguém não vá lá, viole a integridade dos dados ou até altere dados?
E o custo para manter o FTP, que é não só dinheiro para mensalidade de um provedor, precisa de equipe para isto e banda do servidor interno para alimentar banco de dados no FTP.
E o FTP terá banda suficiente para receber o que vier do servidor interno da sua empresa?
Esqueça FTP, colega.
O foco deve ser a segurança da sua rede. Pode até n]ao ter conhecimentos sobre segurança da informação, mas certamente vai conseguir boas soluções, como a criação de um Bastião (servidor e rede falsos em que os invasores caem e vem dados irreais, que voce não precisa alimentar como certo, não precisa e nem deve ser espelho do servidor interno e real), além de criptografia dos dados, que ficam embaralhados no banco de dados, se um hacker invadir e conseguir acessar o banco de dados, ou mesmo copiar o banco de dados, será inútil para ele, porque somente nos teus fontes tem as rotinas de descriptografia.
E se o hacker bagunçar alguma coisa, fica claro que a informação é violada, porque violar dado encriptado faz o dado se tornar ilegÃÂvel quando desencriptado. E a bagunça pode ser desfeita com backup rotineiro, duas vezes ao dia.
Para começar: Bastião e criptografia, além do óbvio, que é checagem de login, criação de logs de acesso, incluindo no login a permissão por validação de equipamentos (baseados no MAC de cada equipamento).
Cinclair,
Entendi perfeitamente seus argumentos:
Mas...
Digamos que :
- A segurança do servidor para onde a informação será enviada por FTP, seja muito boa.
- O aplicativo neste servidor (Externo), esteja preparado para ler os arquivos recebidos e abastecer sua BD
- As informações não são muitas . E serão enviadas ocasionalmente ( Talvez, 2 ou 3 vezes por mes)
Considerando o que citei acima, ainda sim , o método de envio por FTP é perigoso?
Ou , feitas estas ressalvas que citei é algo seguro?
Entendi perfeitamente seus argumentos:
Mas...
Digamos que :
- A segurança do servidor para onde a informação será enviada por FTP, seja muito boa.
- O aplicativo neste servidor (Externo), esteja preparado para ler os arquivos recebidos e abastecer sua BD
- As informações não são muitas . E serão enviadas ocasionalmente ( Talvez, 2 ou 3 vezes por mes)
Considerando o que citei acima, ainda sim , o método de envio por FTP é perigoso?
Ou , feitas estas ressalvas que citei é algo seguro?
Colega, eu diria que sendo duas ou 3 vezes por mes parecer ser algo pequeno, ocasional.
Cairia na questão de quantidade de dados, mas voce também já disse que são poucas.
Também relatou que o FTP é seguro.
Neste caso, em primeiro momento, parece que o FTP é a melhor opção, porém... (sempre tem um porém)... sua rede e dados internos continuarão a ser alvos de terceiros/criminosos com ou sem FTP, portanto montar a segurança de sua rede interna continuaria sendo necessário.
Imagine como seria ter um FTP para segurança dos dados e mesmo assim os dados serem bagunçados/violados no servidor interno. Seria considerado um trabalho inócuo montar/ter o FTP.
E, se precisa cuidar da segurança da rede interna, o FTP existir ou não fica disposto apenas para: vale a pena redundar informações, ter um trabalho quinzenal ou mesmo a cada 10 dias?
Vale a pena manter o FTP funcionando e resolver problemas com FTP caso apresente anomalias?
Seria uma solução ou apenas mais um trabalho que é desnecessário?
Enfim, partindo da trÃÂade Consistencia, Independencia e Disponibilidade de dados (muito falado em segurança da informação) eu coloria o acesso direto ao servidor interno da empresa e as tarefas de atualização do FTP a cada 10 dias eu substituiria por backup 4 vezes ao dia.
Mas o cenário interno, incluindo a forma de pensar dos administradores, é que vai definir os rumos.
Cairia na questão de quantidade de dados, mas voce também já disse que são poucas.
Também relatou que o FTP é seguro.
Neste caso, em primeiro momento, parece que o FTP é a melhor opção, porém... (sempre tem um porém)... sua rede e dados internos continuarão a ser alvos de terceiros/criminosos com ou sem FTP, portanto montar a segurança de sua rede interna continuaria sendo necessário.
Imagine como seria ter um FTP para segurança dos dados e mesmo assim os dados serem bagunçados/violados no servidor interno. Seria considerado um trabalho inócuo montar/ter o FTP.
E, se precisa cuidar da segurança da rede interna, o FTP existir ou não fica disposto apenas para: vale a pena redundar informações, ter um trabalho quinzenal ou mesmo a cada 10 dias?
Vale a pena manter o FTP funcionando e resolver problemas com FTP caso apresente anomalias?
Seria uma solução ou apenas mais um trabalho que é desnecessário?
Enfim, partindo da trÃÂade Consistencia, Independencia e Disponibilidade de dados (muito falado em segurança da informação) eu coloria o acesso direto ao servidor interno da empresa e as tarefas de atualização do FTP a cada 10 dias eu substituiria por backup 4 vezes ao dia.
Mas o cenário interno, incluindo a forma de pensar dos administradores, é que vai definir os rumos.
Resolva tudo isso contratando google cloud, voce vai ter seu banco de dados em nuvem, com possiblidade de replicas e alta disponibilidade também, se ainda precisar de envio de arquivos utilize os buckets que são seguros e rápidos, é possÃÂvel criar um buckets pra cada cliente. o espaço em disco é monstruoso por preços baixos(é claro vai depender do fluxo, mas tem que ser muito mesmo pra isso ficar caro).
Passei por uma situação relativamente parecida.
Solução ?
Dados disponibilizados via API (com o auth2) e com criptografia via AES-128 que era enviada via "chave" no header do usuário, ou seja, além de se autenticar, só ele saberia desfazer a criptografia o que recebeu.
Com isso, arquivo em FTP não são necessários pois o dado vem sob demanda (ou claro, voce pode do seu lado ler arquivos estáticos e não do banco).
Outro ponto, usar uma VPN garante muuuuuito mais segurança para toda a camada.
Além disso, dar manutenção e intervir em um acesso indevido via API é bem mais simples do que ficar gerindo uma arquitetura de FTP (bloquear usuário, bloquear IP, mudar chaves de acesso, etc...)
Pense nisso...
Solução ?
Dados disponibilizados via API (com o auth2) e com criptografia via AES-128 que era enviada via "chave" no header do usuário, ou seja, além de se autenticar, só ele saberia desfazer a criptografia o que recebeu.
Com isso, arquivo em FTP não são necessários pois o dado vem sob demanda (ou claro, voce pode do seu lado ler arquivos estáticos e não do banco).
Outro ponto, usar uma VPN garante muuuuuito mais segurança para toda a camada.
Além disso, dar manutenção e intervir em um acesso indevido via API é bem mais simples do que ficar gerindo uma arquitetura de FTP (bloquear usuário, bloquear IP, mudar chaves de acesso, etc...)
Pense nisso...
Uma WebAPI resolve todos esses problemas.
Pessoal,
Quando voces estão sugerindo a alternativa da criação de uma "API", estão querendo
dizer, colocar uma API num servidor aqui, na qual os aplicativos "externos" possam vir buscar as informações
que necessitem?
Obs: Se for este o caso, infelizmente a empresa decidiu que "não quer nenhuma aplicação externa" vindo buscar
informações aqui. (A infraestrutura considera isso "perigoso" para a rede local). Foi por isso que surgiu a idéia de enviar por FTP.
Quando voces estão sugerindo a alternativa da criação de uma "API", estão querendo
dizer, colocar uma API num servidor aqui, na qual os aplicativos "externos" possam vir buscar as informações
que necessitem?
Obs: Se for este o caso, infelizmente a empresa decidiu que "não quer nenhuma aplicação externa" vindo buscar
informações aqui. (A infraestrutura considera isso "perigoso" para a rede local). Foi por isso que surgiu a idéia de enviar por FTP.
Olha...tá faltando um pouco de criatividade (e até de estudo) desse teu povo de infra.
Voce não precisa expor a sua rede local, pode botar isso numa VPS, num Cloud, enfim... em um lugar "publico" onde as pessoas batem nele, e ele bate na tua rede (ou voce pode replicar o conteúdo para lá e não expor sua rede).
Sinceramente, saÃÂdas tem um monte, o problema é que o povo tá embarreirando coisas que podem ser contornadas de diversas formas.
Sugestões:
- réplicas de banco de dados
- servidor externo somente para API
- servidor externo somente para BANCO
- servidores se falam (API => BANCO)
Tem muita VPS baratinha por ai, com qualidade garantida...só pesquisar e botar a mão na massa
Voce não precisa expor a sua rede local, pode botar isso numa VPS, num Cloud, enfim... em um lugar "publico" onde as pessoas batem nele, e ele bate na tua rede (ou voce pode replicar o conteúdo para lá e não expor sua rede).
Sinceramente, saÃÂdas tem um monte, o problema é que o povo tá embarreirando coisas que podem ser contornadas de diversas formas.
Sugestões:
- réplicas de banco de dados
- servidor externo somente para API
- servidor externo somente para BANCO
- servidores se falam (API => BANCO)
Tem muita VPS baratinha por ai, com qualidade garantida...só pesquisar e botar a mão na massa
WebMaster,
Nossos aplicativos externos estão em uma VPS já.
É justamente a comunicação de nossos aplicativos externos (Que estão num VPS), que a infra
considera perigoso se comunicar com qualquer coisa na nossa rede interna.
Já sugerimos usar um WebService aqui, mas também foi considerado arriscado.
Acredito que o receio, é que alguém consiga invadir o servidor VPS e de lá faça um ataque
a rede local.
Nossos aplicativos externos estão em uma VPS já.
É justamente a comunicação de nossos aplicativos externos (Que estão num VPS), que a infra
considera perigoso se comunicar com qualquer coisa na nossa rede interna.
Já sugerimos usar um WebService aqui, mas também foi considerado arriscado.
Acredito que o receio, é que alguém consiga invadir o servidor VPS e de lá faça um ataque
a rede local.
Colega, o que o WebMater falou está certinho. Teu pessoal de infra está criando barreiras desnecessárias.
Vou ser mais radical: teu pessoal de infra está neurótico, muito além de "pré-ocupados" com algo.
Parece até que estão com medo de respirar e terem os pulmões hiper insuflados.
Parece que estão com medo de viver porque quem está vivo corre o risco de morrer.
A meu ver, resta só e realmente o FTP, que é lento, custoso, dispendioso, muito suscetÃÂvel a erros. Ou sugerir para teu pessoal de infra (que estão atrasando tua vida) que desenvolvam uma nova forma de transmissão de dados por sinais de fumaça.
Vou ser mais radical: teu pessoal de infra está neurótico, muito além de "pré-ocupados" com algo.
Parece até que estão com medo de respirar e terem os pulmões hiper insuflados.
Parece que estão com medo de viver porque quem está vivo corre o risco de morrer.
A meu ver, resta só e realmente o FTP, que é lento, custoso, dispendioso, muito suscetÃÂvel a erros. Ou sugerir para teu pessoal de infra (que estão atrasando tua vida) que desenvolvam uma nova forma de transmissão de dados por sinais de fumaça.
Faça seu login para responder