Como construir medidas de segurança robustas para proteger seus servidores

Introdução

Ao trabalhar em infraestrutura de nuvem, sua principal preocupação é garantir que seus aplicativos estejam totalmente operacionais. Uma inclusão importante do seu processo de configuração e implantação é criar medidas de segurança eficazes, completas e robustas em seus aplicativos ou sistemas antes que eles sejam oferecidos ao público. Em vez de implementar medidas de segurança retroativamente após a implantação, é importante garantir que haja uma configuração de base segura integrada à sua infraestrutura.

Este tutorial o ajudará nesse sentido. Ele destacará certas medidas práticas de segurança que podem ser implementadas enquanto a infraestrutura do seu servidor está sendo configurada. Embora esta não seja uma lista exaustiva de protocolos de segurança de servidor, é um ponto de partida útil. À medida que você trabalha e entende melhor as necessidades específicas do seu ambiente e aplicativos, você pode desenvolver medidas de segurança adicionais para ajudar a aprimorar sua base.

Chaves SSH (Secure Shell)

Enquanto você trabalha com seu servidor, a grande maioria do seu tempo será gasta trabalhando em uma SSH conexão com seu servidor em uma sessão de terminal. As chaves de segurança shell (SSH) fornecem um método de login mais seguro no servidor do que os logins baseados em senhas. Para fins de autenticação, com o uso de chaves SSH, duas chaves de acesso são preparadas. A primeira é uma chave secreta (privada), enquanto a outra é uma chave pública compartilhável.

A autenticação por chave SSH deve primeiro ser configurada. Isso é feito colocando a chave pública SSH no diretório apropriado no servidor. Quando seu cliente se conectar inicialmente ao servidor, será solicitada uma prova de posse da chave privada. Isso é feito gerando um valor aleatório que será enviado ao seu cliente SSH. O cliente SSH, por sua vez, usará a chave privada na criptografia de uma resposta. Essa resposta será enviada ao servidor. Em seguida, o servidor descriptografará a mensagem do cliente usando sua chave pública. Se o valor aleatório for descriptografado pelo servidor, isso indica que o cliente possui a chave privada. Nesse caso, a autenticação é confirmada e uma conexão com o servidor sem senha pode ser estabelecida.

Aumentando a Segurança com Chaves SSH

Embora a autorização por senha ou qualquer autenticação com SSH seja totalmente criptografada, o acesso ao servidor pode ser tentado por usuários mal-intencionados. Especialmente se eles passarem a possuir o endereço IP público do servidor. Ao tentar todas as combinações de chaves possíveis, a computação moderna permite logins baseados em senha e isso é frequentemente tentado por usuários mal-intencionados. Se alguém automatizasse essas tentativas de acesso, seria possível, tentando diferentes combinações sistematicamente, finalmente acessar a senha correta.

Ao aproveitar a autenticação criptografada por SSH, não há necessidade de habilitar senhas para fazer login. As chaves SSH normalmente contêm uma quantidade significativa de combinações possíveis que precisariam ser testadas por um invasor. O aumento do número de bits multiplica o potencial de diferentes combinações necessárias para quebrar a criptografia. Executar todas as combinações possíveis do algoritmo de chave SSH, portanto, consumiria muito tempo. Assim, torna-se um empreendimento que não vale o tempo de um invasor mal-intencionado. É por isso que a criptografia SSH é normalmente considerada 'inquebrável'.

Implementando Chaves SSH

Fazer login em qualquer servidor remoto Linux deve usar chaves SSH. Uma chave pode ser gerada no lado da máquina local, com a chave pública transferida de volta para o servidor em poucos minutos. Com este tutorial, você terá uma ideia básica sobre como usar o SSH para se conectar a um servidor remoto no Ubuntu. Você também pode acompanhar nosso detalhado tutorial sobre como configurar seu servidor Linux para usar autenticação baseada em chave SSH.

No geral, não permitir que o usuário root faça login diretamente via SSH é uma prática recomendada comumente utilizada, ao passo que fazer login como um usuário sem privilégios e usar uma ferramenta como o sudo para escalar privilégios conforme necessário. Isso é conhecido como o princípio do menor privilégio: um método de limitar as permissões de acesso. Uma vez que o login como uma conta sem privilégios tenha sido verificado com SSH, os logins de root podem ser desativados definindo a diretiva PermitRootLogin no em /etc/ssh/sshd_config no seu servidor. Em seguida, o servidor pode ser reiniciado com um comando de processo SSH sudo systemctl restart sshd.

Firewalls

Um software (ou dispositivo de hardware) que regula a exposição de serviços à rede é conhecido como um firewall. Um firewall, configurado de forma ideal, garante que apenas os serviços permitidos estejam disponíveis publicamente e autorizados a entrar e sair do servidor específico.

Vários serviços podem estar em execução por padrão em um servidor e estes podem ser categorizados nos seguintes grupos:

• Serviços internos: Estes devem ser acessados apenas internamente a partir do próprio servidor. Isso evita a exposição dos serviços à acessibilidade pública da internet (ex: um banco de dados acessível apenas por conexões locais).
• Serviços públicos: Serviços que podem ser acessados por qualquer pessoa, frequentemente de forma anônima, na internet. Isso inclui servidores web que permitem que seu site seja acessado por visitantes.
• Serviços privados: Apenas contas autorizadas de um conjunto exclusivo de locais podem acessar esses serviços (ex: painel de controle de banco de dados phpMyAdmin).

Embora os serviços públicos possam ser deixados disponíveis para serem acessados pela internet, os serviços privados podem ser restritos com base em parâmetros de acesso (como tipos de conexão), e os serviços internos têm qualquer acesso baseado na internet totalmente bloqueado. O acesso a esses serviços, juntamente com a granularidade com que é permitido, é todo controlado pelo firewall. Portas não utilizadas são comumente configuradas para bloquear totalmente o acesso a elas.

Melhoria de Segurança com o Uso de Firewall

Um firewall é uma linha de base para a proteção do servidor. Ele serve para limitar a conexão de e para os serviços antes que a aplicação processe o tráfego. Claro, você pode implementar recursos de segurança adicionais para seus serviços e restringi-los às interfaces desejadas.

Apenas os serviços que você escolher manter abertos não serão restritos por um firewall configurado corretamente. Isso limita os elementos vulneráveis à exploração, pois os softwares disponíveis são muito mais limitados e, portanto, menos propensos a sofrer um ataque.

Implementando Firewalls

Muitos firewalls estão disponíveis para sistemas Linux. Alguns deles são bastante complexos. No entanto, a configuração típica de um firewall só deve precisar ser feita no momento da configuração inicial do servidor, quando alterações nos serviços do servidor forem implementadas. Isso deve levar apenas alguns minutos do seu tempo. A seguir estão algumas opções a serem consideradas para configurar e ativar o firewall:

• Para o CentOS, você pode seguir o nosso guia de Configuração de um Firewall com o FirewallD no CentOS 7.
• Nosso guia do Iptables pode orientá-lo na listagem e exclusão de regras de firewall do Iptables.

O mais importante, independentemente do tutorial, é garantir que o firewall escolhido bloqueie o tráfego desconhecido de seus servidores, a fim de evitar que quaisquer novos serviços disponíveis sejam expostos na internet inadvertidamente. Ao precisar autorizar explicitamente o acesso, você será solicitado a avaliar totalmente como um serviço é acessado, executado e por quem ele tem permissão para ser acessado.

Redes de Nuvem Privada Virtual (VPC)

Os recursos da sua infraestrutura precisam operar dentro de uma rede privada conhecida como VPC. Essas redes são mais seguras, pois impedem o acesso de outras redes VPC baseadas na nuvem. Assim, elas tornam as interfaces da rede inacessíveis a partir da internet pública.

Melhorando a Segurança com Redes VPC

As redes privadas são preferíveis às suas contrapartes de rede pública para comunicação interna. A VPC permite o isolamento de grupos de recursos em redes privadas específicas. Como as redes VPC se comunicam apenas por meio de conexões privadas, o tráfego da rede é protegido contra a exposição à internet pública, onde essas informações poderiam estar vulneráveis a interceptação ou exposição. As redes VPC também podem ser usadas para isolar ambientes de execução, bem como inquilinos. Os gateways de internet também podem ser configurados como um ponto único de acesso entre a internet pública e os recursos na sua rede VPC.

Além disso, uma grande parte da segurança envolve analisar nossos sistemas e proteger todos os componentes da melhor forma possível. A auditoria de serviços nos permite conhecer os protocolos aceitáveis dos sistemas, os serviços em execução e quais portas estão sendo utilizadas para comunicação. Conhecer essas informações pode ajudar a tomar as melhores decisões em relação à configuração. Tais decisões podem ser configurações de firewall, monitoramento e alertas do sistema, e quais serviços devem estar acessíveis publicamente.

Aproveitando a Auditoria para Aumentar a Segurança

Cada serviço pode ser utilizado para lidar com clientes externos ou para fins internos. Independentemente da intenção, todos esses serviços são pontos de vulnerabilidade para usuários maliciosos. À medida que o número de serviços em execução aumenta, também aumenta o potencial de exploração de vulnerabilidades.

Você pode começar a analisar os serviços assim que tiver uma compreensão firme de quais serviços uma máquina está executando. Ao realizar uma auditoria de serviço, é benéfico fazer as seguintes perguntas:

• O serviço em questão deve estar em execução ativa?
• Ele está sendo executado nas interfaces de rede ideais?
• O serviço é mais adequado para uma interface de rede pública ou privada?
• As regras de firewall estão configuradas corretamente para permitir tráfego legítimo para este serviço?
• O tráfego ilegítimo está bloqueado com as minhas regras de firewall?
• Existe um sistema de alerta sobre vulnerabilidades de segurança ativado?

Ao adicionar um novo servidor à infraestrutura, as práticas acima devem ser padrão em seu processo de configuração. Um benefício adicional das auditorias de serviços é que elas permitirão identificar qualquer uma das configurações que tenham sido alteradas involuntariamente.

Realizando Auditorias de Serviços

Para auditar os serviços em execução, use o comando ss para listar todos os portas UDP e TCP ativamente usadas em um servidor. Aqui está um exemplo de uso do comando ss com o PID do nome do programa, verificando as portas TCP e UDP em escuta:

Algo semelhante ao seguinte será retornado:

Seu foco principal deve ser nas colunas Netid, Local Address:Port e Process:

• Se o valor de Local Address:Port for 0.0.0.0, isso significa que o serviço está aceitando ativamente todas as conexões em todas as interfaces de rede IPv4. Se o endereço for [::], então todas as conexões IPv6 estão aceitando tráfego.
• No exemplo acima, tanto o Nginx quanto o SSH estão escutando em todas as interfaces públicas em ambas as pilhas de rede (IPv4 e IPv6).

Com o exemplo acima, você poderia escolher se precisa permitir que o SSH e o Nginx escutem nas duas interfaces, ou apenas em uma delas. Geralmente, você desejaria desativar quaisquer serviços que não estejam em uso para evitar que sejam executados. Por exemplo, se o seu site deve ser acessível apenas através de IPv4, ajudaria desativar as interfaces IPv6 para limitar a exposição.

Mantendo-se Atualizado com Atualizações Automáticas

As atualizações automáticas reduzem o nível de esforço necessário para manter seus servidores seguros e ajudam a diminuir o tempo em que eles permanecem expostos a bugs conhecidos. Quanto mais tempo você demorar para executar as atualizações no seu servidor, mais tempo ele permanecerá exposto a vulnerabilidades conhecidas. As atualizações automáticas garantirão que, assim que os pacotes de correção estiverem disponíveis, eles possam ser instalados automaticamente no servidor para limitar o tempo de vulnerabilidade.

Além da auditoria do servidor, as atualizações automáticas podem reduzir drasticamente a exposição a ataques. Elas também reduzirão bastante o tempo gasto na manutenção do servidor.

Como as Atualizações Não Assistidas São Ativadas

As atualizações não assistidas são agora um recurso opcional na maioria das distribuições de servidor. No Ubuntu, por exemplo, a administração pode executar o seguinte comando:

Para informações adicionais sobre a implementação de atualizações não assistidas, consulte a seção de Atualizações Automáticas aqui. Para o Fedora, as instruções podem ser encontradas aqui. Observe que as atualizações automáticas instalarão apenas o software que foi inicialmente instalado por meio do sistema de gerenciamento de pacotes do seu sistema. Quaisquer aplicativos complementares, como os baseados na web, precisarão ser verificados separadamente para atualizações de forma manual ou configurados individualmente para atualizações automáticas.

Índices de Diretório

Quando um diretório não possui um arquivo de índice, a maioria dos servidores está configurada para exibir os índices do diretório por padrão. Em outras palavras, se um diretório chamado 'downloads' for criado no seu servidor web, qualquer pessoa que navegar por esse diretório poderá ver todos os arquivos nele contidos. Embora isso nem sempre seja um risco de segurança, expõe informações confidenciais a olhos não autorizados. Como exemplo, considere que seu servidor web pode ter um arquivo que contém as credenciais de acesso à página inicial do seu site e um arquivo com todas as configurações do back-end do banco de dados do site. Se os índices de diretório não estiverem desativados, esses arquivos serão vistos por qualquer pessoa que navegar por esse diretório.

Aumentando a Segurança Através da Desativação de Índices de Diretório

Embora os índices de diretório sejam úteis, eles podem deixar arquivos expostos involuntariamente. Para mitigar essa exposição involuntária e quaisquer riscos associados, os índices de diretório no servidor devem ser desativados por padrão. Embora os arquivos ainda possam ser acessados pelos visitantes, a exposição à visualização involuntária de dados é significativamente limitada.

Desativando Índices de Diretório

Na maioria dos casos, a adição de apenas mais uma linha à configuração do seu servidor web é suficiente para desativar os índices de diretório.

• Siga estes passos para desativar essas listagens de diretório no Apache Wiki. Certifique-se de que Options -Indexes estejam listadas nos blocos de configuração do Apache Directory.
• Os índices estão desativados por padrão no Nginx, não exigindo nenhuma ação adicional a esse respeito.

Backups Frequentes

Embora os backups não sejam uma medida de segurança, eles são imperativos para salvaguardar dados e sistemas inteiros caso o sistema seja comprometido. Também ajuda a analisar como o sistema pode ter sido atacado. Considere um cenário infeliz em que seu sistema é atacado por ransomware (um vírus ou ferramenta de malware que criptografa os arquivos no seu sistema, descriptografando-os apenas se você pagar dinheiro ao hacker). Se não houver backups dos dados, sua única escolha será pagar o dinheiro para recuperar o acesso aos seus dados. Se os dados tiverem um backup seguro, você ainda terá acesso a eles e poderá recuperá-los sem precisar acessar o sistema comprometido.

Melhoria da Segurança Através de Backups Frequentes

Backups frequentes ajudam a recuperar informações em caso de ataque, corrupção ou até mesmo perda não intencional (exclusão). Não importa que tipo de evento negativo leve à perda de dados, o risco é reduzido pela retenção de cópias dos dados do servidor.

Além dos ataques de ransomware, backups frequentes podem ajudar na investigação mensurável de ataques de longo prazo ao sistema. Se você não estiver armazenando seus dados com segurança em formato de backup, determinar a origem do ataque e quais dados foram comprometidos pode ser desafiador ou até impossível.

Implementando Backups Frequentes

Tratar a recuperação verificável de dados corrompidos, comprometidos ou excluídos como o objetivo dos seus esforços de recuperação ao fazer o backup dos seus sistemas é primordial. Para contextualizar melhor, considere quais ações exigiriam a menor quantidade de trabalho para colocá-lo de volta em funcionamento se o seu servidor desaparecesse amanhã.

Aqui estão alguns outros pontos a serem considerados ao pensar em um plano de recuperação de desastres:

• Se você estiver operando com dados que mudam dinamicamente, seus backups provavelmente precisarão ser mais frequentes. Em caso de perda de dados, se o seu último backup foi há muito tempo, você poderá ser forçado a voltar para dados desatualizados.
• Pense no processo real de restauração do backup. Será necessário adicionar um novo servidor para isso ou o existente pode ser restaurado?
• Qual é o período mais longo de tempo que você pode ter o servidor fora de operação?
• O backup externo (offsite) é uma solução necessária?

Para saber mais sobre as soluções de Disaster Recovery da CloudSigma, confira nossa postagem no blog detalhando por que o nosso Disaster-Recovery-as-a-Service é o companheiro perfeito para a nuvem. E aqui você pode descobrir mais sobre os recursos de segurança & continuidade de negócios da CloudSigma. Também temos um guia detalhado sobre como configurar facilmente a funcionalidade de backup da CloudSigma.

Redes Privadas e VPNs

Uma rede privada é aquela que está disponível apenas para acesso e uso de usuários ou servidores específicos. Uma conexão segura entre dispositivos remotos que permite que a conexão opere como se estivesse em uma rede privada é uma VPN (uma rede privada virtual). Ela oferece a capacidade de proteger conexões em uma rede privada e conectar servidores remotos.

Como as Redes Privadas Melhoram a Segurança?

Quando há a escolha de usar redes públicas versus privadas para comunicação interna, a última é sempre a opção preferível. Lembre-se, no entanto, de que outros usuários de dentro do data center ainda podem acessar a mesma rede. Isso significa que medidas de segurança suplementares ainda devem ser aplicadas para garantir que a comunicação entre os servidores seja segura.

Essencialmente, utilizar a VPN é uma abordagem para delinear o que os funcionários da sua organização podem ver. A correspondência será completamente segura e privada. As configurações do aplicativo permitiriam que o tráfego da interface virtual passasse pela VPN. Ao fazer isso, apenas os serviços destinados à interação com o cliente via internet poderão ser expostos a uma rede pública.

Quão Difícil É Implementar uma VPN?

Aproveitar redes privadas é tão simples para o seu data center quanto configurar seus aplicativos e firewall para usar uma rede privada e habilitar a VPN durante a criação do seu servidor. É importante lembrar que outros servidores compartilham o mesmo espaço de rede que as redes privadas de todo o data center.

A configuração inicial de uma VPN é um pouco mais complexa. No entanto, a segurança adicional que isso traz vale a pena para a maioria dos casos de uso. Os dados de configuração e a segurança compartilhada precisam ser instalados e configurados em cada servidor da rede. Para informações mais detalhadas sobre como funciona uma VPN e uma visão geral da configuração do OpenVPN no Ubuntu, siga este guia. Você também pode seguir este tutorial que orienta você pelas etapas para conectar uma rede VPN à infraestrutura da CloudSigma.

Criptografia SSL/TLS e Infraestrutura de Chaves Públicas

A geração, gerenciamento e validação de certificados para identificar indivíduos e a criptografia de comunicação são chamadas de Infraestrutura de Chaves Públicas (PKI). Diferentes entidades podem ser autenticadas entre si com o uso de SSL ou TLS certificados. Depois disso, eles também podem ser usados para estabelecer comunicação criptografada.

Como os Certificados Melhoram a Segurança

Para criptografar o tráfego e validar as identidades dos membros em um servidor, é vital estabelecer uma autoridade de certificação (CA) e poder ver todos os certificados da sua rede. Isso pode ajudar a evitar ataques do tipo 'man-in-the-middle', nos quais o servidor é imitado por um hacker e o tráfego é redirecionado.

A configuração de cada servidor pode ser definida para confiar em uma CA centralizada. Quaisquer assinaturas de certificado subsequentes podem então ser confiadas implicitamente. Se a criptografia SSL/TLS for suportada pelos protocolos e aplicativos que seu servidor usa, você poderá proteger seu sistema sem a sobrecarga do túnel VPN. Para mais informações, siga nosso tutorial sobre como automatizar as renovações de certificados SSL do LetsEncrypt para o Nginx.

Dificuldade de Implementação

Pode haver muito esforço inicial na configuração de uma autoridade certificadora e, em seguida, na configuração do restante da PKI. Além disso, quando novos certificados precisarem ser criados, revogados ou assinados, será necessário um esforço administrativo adicional.

Como a maioria das infraestruturas precisa crescer, implementar uma PKO completa é a abordagem mais sensata. Até que você atinja um ponto em que a PKI valha os custos administrativos extras, utilizar uma VPN para proteger os componentes do sistema pode servir como uma medida paliativa adequada.

Detectando Intrusão no Sistema e Utilizando Auditoria de Arquivos

A auditoria de arquivos é um processo usado para comparar os arquivos e seus atributos do seu sistema em um estado totalmente seguro e bom com os do seu sistema atualmente. Este é um bom método para encontrar e isolar alterações não autorizadas no sistema.

Um IDS, sistema de detecção de intrusão, refere-se a um software de monitoramento que acompanha qualquer atividade não autorizada no sistema. Geralmente, ele usa métodos de auditoria de arquivos para buscar quaisquer alterações inesperadas no sistema.

Melhoria de Segurança com IDS/Auditoria de Arquivos

Além da auditoria em nível de serviço, realizar auditorias em nível de arquivo é essencial para garantir a segurança do seu sistema. Isso pode ser feito por um processo automatizado de IDS ou realizado periodicamente pelo administrador do sistema.

Auditorias de arquivos e IDS são os únicos processos verdadeiros para garantir que o sistema não sofreu nenhuma alteração imprevista. A maioria dos invasores deseja explorar os servidores que invadem por longos períodos de tempo e, para fazer isso, deve manter a capacidade de realizar suas ações de forma oculta. Eles podem substituir binários por versões vulneráveis ou comprometidas. Quaisquer arquivos que tenham sido alterados no sistema serão detectados por uma auditoria do sistema de arquivos. Isso permite que você tenha a tranquilidade de saber muito rapidamente se a integridade do sistema foi comprometida.

Nível de Dificuldade de Implementação

A implementação de IDS e auditoria de arquivos pode ser um processo muito intenso. No início, o sistema deve ser configurado para definir caminhos a serem excluídos e estabelecer alterações não padronizadas que foram feitas no sistema, a fim de criar uma leitura de linha de base do sistema.

As operações do dia a dia também se tornam mais complicadas, pois os procedimentos precisarão verificar novamente o sistema antes que qualquer atualização seja executada. A linha de base das medições do sistema também precisará ser recriada ou reestabelecida para capturar as alterações de versão do software como parte da nova linha de base do sistema. Os relatórios de auditoria também precisarão ser transpostos para um local alternativo. Isso ocorre porque você precisa evitar que um invasor do sistema altere a auditoria para permanecer oculto, cobrindo seus rastros.

Embora isso certamente aumente a carga administrativa do seu sistema, é uma das únicas maneiras infalíveis de garantir que nenhum dos arquivos tenha sido alterado sem o seu conhecimento. Alguns dos sistemas de detecção de intrusão e auditoria de arquivos mais populares são Aide e Tripwire.

Ambientes Isolados

Qualquer método em que componentes individuais são executados em seu próprio espaço dedicado é chamado de ambientes de execução isolados.

Isso pode significar que componentes específicos do aplicativo serão hospedados em seus próprios servidores dedicados, ou que seus serviços podem ser configurados para operar em ambientes chroot (ou containers). O quão isolado o ambiente está depende principalmente das realidades da sua infraestrutura e dos requisitos do seu aplicativo.

Aumentando a Segurança com Ambientes Isolados

Ao isolar seu processo em ambientes individuais, você também está isolando quais processos poderiam ser afetados por falhas de segurança. Assim como compartimentos e anteparas ajudam a conter brechas no casco de navios, quando você separa as partes e componentes individuais do seu sistema, se um invasor obtiver acesso a um deles, ele não conseguirá acessar todo o sistema de rede interconectado.

Dificuldade de Implementação

A complexidade de isolar suas aplicações varia dependendo dos tipos de contenção que você decidiu usar. O Docker não considera o isolamento um recurso de segurança. No entanto, quando seus componentes são divididos entre diferentes contêineres, o isolamento é alcançado de forma muito mais fácil. Você pode seguir este tutorial para instalar o Docker em nossa infraestrutura.

Quando ambientes chroot são configurados, há também algum grau de isolamento proporcionado. No entanto, este não é um método completamente impenetrável, pois existem métodos para escapar de tal ambiente. Máquinas dedicadas para diferentes componentes são tipicamente a melhor e mais simples maneira de alcançar o isolamento. No entanto, é mais caro devido à necessidade de máquinas adicionais.

Considerações Finais

As estratégias fornecidas são apenas alguns dos passos que você pode tomar para aumentar a segurança do seu sistema. Vale a pena notar que quanto mais você demorar para implementar os recursos de segurança, menor será a eficácia deles. Com isso em mente, é importante garantir que a segurança não seja deixada para depois. Em vez disso, ela deve ser implementada como uma das primeiras provisões na construção da infraestrutura. Assim que seu sistema estiver suficientemente seguro com as proteções básicas, você poderá começar a ativar serviços e adicionar aplicações, sabendo que eles executarão por padrão em um ambiente seguro.

A segurança não é um processo estático, no entanto, mas sim fluido. Ela precisa ser mantida e iterada. Deve ser abordada com uma mentalidade de conscientização constante e vigilância persistente. Sempre questione quais são as implicações de segurança envolvidas em qualquer alteração no sistema.  Certifique-se de que os ambientes operacionais e as configurações padrão estejam sempre otimizando a segurança e funcionando com softwares suficientemente defensivos.

Boa computação!