Apresentação Lock & Wipe no M3 da Mobiltec

Muito já falamos aqui no blog sobre os conceitos de lock & wipe e como implementar essa funcionalidade, para Windows Mobile e para Android.

Como vocês já sabem, trata-se de uma funcionalidade crítica no que tange segurança para uso e gestão de dispositivos móveis corporativos. Com ela, é possível bloquear remotamente um dispositivo móvel e apagar seus dados, retornando as configurações originais.

Hoje, vamos mostrar em vídeo como se executa essa operação, utilizando como exemplo o M3 da Mobiltec. O vídeo tem pouco mais de três minutos. Confira!

Arquitetura de um servidor para oferecer alta disponibilidade

O uso de sistemas móveis está sendo amplamente disseminado entre as empresas, com a promessa de aumentar a produtividade e acelerar seus processos. No entanto, para que esse objetivo seja atingido, todos os sistemas envolvidos seja cliente ou servidor, hardwares ou softwares, precisam funcionar de forma ininterrupta, 24×7. Diversas situações podem interromper esse processo, desde problemas físicos nos equipamentos até falhas nos sistemas. O objetivo deste post é auxiliar os leitores a identificarem a existência de Single Point of Failure (SPOF) ou pontos únicos de falha na arquitetura dos servidores e apresentar um modelo de arquitetura que minimize esses problemas.

SPOF são pontos que realizam alguma tarefa exclusiva na arquitetura do sistema e que se ficarem inoperantes vão tornar o sistema “inútil”, servindo tanto para hardware quanto para software. Para resolver o problema dos SPOF, a alternativa é criar uma redundância desses pontos. Assim, no caso de algum deles falhar, outro assumirá sua função imediatamente.

Como exemplo na figura abaixo é apresentado um ambiente de alta disponibilidade. Podemos observar que todos os pontos são redundantes, desde o link de fornecimento de internet até o espelhamento de um banco de dados e na utilização de um storage, garantindo que se qualquer ponto falhar, outro poderá assumir as tarefas do sistema.

O espelhamento de banco de dados consiste em manter um banco escravo idêntico, “espelho” do banco principal. Caso o principal tenha algum problema, o escravo assume sua posição. Geralmente esses bancos de dados ficam em máquinas diferentes, pois se houver algum problema isso não afetará ambos os bancos. Já o storage é um dispositivo que consiste em oferecer na rede uma área de armazenamento, sendo composta por um hardware redundante desde a placa de rede, fonte de energia até discos rígidos. Os discos rígidos são sincronizados/espelhados por meio da utilização, principalmente, de RAIDs. Um storage também permite a troca quente de discos rígidos danificados e a inclusão de novos discos para aumentar o espaço compartilhado entre os servidores e sistemas, facilitando a sua manutenção.

Como exemplo prático, na Mobiltec há projetos móveis menos sensíveis que exigem apenas a troca de informação ou sincronização entre o cliente e o servidor, uma vez ao dia sem importância de horário. Nesse caso, a utilização de um nobreak ou gerador já poderia ser o suficiente para garantir o funcionamento dos servidores. No entanto, há projetos que exigem a urgência na sincronização para que seja realizado algum atendimento/operação em campo o mais breve possível, sendo o cliente informado e sua tarefa realizada em poucas horas. Isso exige que o sistema servidor esteja operacional 24/7, não permitindo falhas e inoperação por grandes períodos. O exemplo apresentado a seguir é utilizado para oferecer a alta disponibilidade em um servidor M3, implantando para dar suporte a um sistema de atendimento de Ordem de Serviços (OS) e Leituras de medidores em campo. Sendo que o sistema de OSs exige que o sistema esteja online 24/7 e o sistema de Leituras exige que o sistema esteja operacional todos os dias das 6:00 às 19:00, sem falhas.

A arquitetura que será apresenta está baseada em sistemas operacionais Microsoft, porém também é possível a implantação de um ambiente de alta disponibilidade em sistemas Linux, com base principalmente na ferramenta Heartbeat que monitora os servidores do ambiente. Caso o servidor principal tenha algum problema, o segundo assume. Nessa arquitetura também pode ser utilizado o DRBD (Distributed Replicated Block Device) para manter os HDs dos servidores sincronizados. Dessa forma, quando um servidor secundário assumir o posto de primário, garantimos que não haja divergência de informações. Mais informações podem ser obtidas no site http://www.linux-ha.org, que se trata de um projeto que busca estudar e desenvolver novas tecnologias de alta disponibilidade para ambientes Linux com base nas ferramentas aqui apresentadas.

Na figura a seguir é apresentado o ambiente de alta disponibilidade com servidores M3, como mencionado anteriormente. Nessa arquitetura não serão apresentadas questões de redundância de roteadores, switch e interfaces de rede, pois os servidores estão alocados em um sistema de Blade Server ou Blade Systems.  Em resumo, um sistema de Blades é um rack composto pela redundância de fonte de energia, ventilação e interfaces de rede, permitindo que sejam alocadas diversas Blades, sendo que cada uma é um computador com memória(s), processador(es) e um HD para a instalação do sistema operacional ou máquinas virtuais. Em geral é um conjunto de servidores com todo o hardware redundante, que garante a alta disponibilidade. No entanto, nada impede que a mesma arquitetura seja implantada utilizando roteadores, switches e servidores separados, não integrados em um cluster.

Como pode ser visto, também optamos pela utilização do conceito de servidores DMZ (DeMilitarized Zone). Esse conceito permite separar os servidores que trabalham com conteúdo importante/secreto/sigiloso do acesso direto a internet pública, evitando a invasão da rede, pois entre a DMZ e a rede local há um firewall que permite somente o acesso necessário para que o sistema funcione corretamente. Basicamente, em uma infraestrutura do M3 o M3FTS fica alocado na DMZ com o objetivo de validar os pacotes recebidos e direcioná-los para os módulos M3 internos, por isso torna-se obrigatória a redundância do M3FTS. Para evitar mais um SPOF, cada servidor DMZ é ligado a um link de internet diferente, permitindo que o sistema continue operante mesmo no caso de algum fornecedor de internet ter algum problema e até que o mesmo seja corrigido.

Vocês devem se questionar sobre, como o sistema cliente será capaz de saber em que servidor M3FTS ele deve se conectar? Teremos que ficar selecionando/testando qual dos servidores está operando? A resposta é não. Para isso, utilizamos o DNS Round Robin (DNS RR), que é uma técnica que permite configurar diversos IP para o mesmo nome de rede. Por meio dessa técnica, o próprio sistema operacional dos dispositivos recebe do servidor DNS uma a lista de IPs associados ao nome, ao resolver o nome de rede para acesso aos servidores do M3. Com isso o SO (Sistema Operacional) é capaz de alterar o IP caso seja verificado que o servidor atual não está mais respondendo as requisições, trocando o IP principal para o próximo IP da lista apresentado pelo servidor DNS. Com o DNS RR também é possível utilizar-se do balanceamento de carga, pois a cada pedido de resolução de nome, o servidor de DNS entrega a lista de IPs diferente. O primeiro IP da lista para cada dispositivo será intercalado e como conseqüência cada dispositivo irá acessar os servidores intercaladamente.

Até aqui já garantimos a redundância de hardware e garantimos que ao menos um servidor de DMZ estará operante para responder as requisições dos clientes. Porém, o M3 utiliza servidores internos para realizar o processamento dos dados de forma segura com acesso a serviços de banco de dados, repositórios e autenticação de usuários. Nesse momento, é necessário que o módulo M3FTS seja inteligente o suficiente para lidar com a redundância de máquinas, realizando a troca de um servidor principal para um secundário caso haja erro ou até mesmo realizando o balanceamento de carga entre os servidores de destino. Para isso, também é possível a utilização de ferramentas que auxiliem no desenvolvimento e implantação do sistema. Nesse caso, ambos os servidores M3FTS utilizam o plug-in ARR (Application Request Routing) do IIS (Internet Information Services).

O ARR, como seu nome diz, tem como objetivo rotear requisições HTTP entre uma fazenda de servidores conforme for configurado. Nesse caso, cada servidor M3FTS possui um ARR, que possui uma fazenda que aponta para todos os M3 internos e os fica monitorando periodicamente para verificar se cada um está respondendo as requisições de HTTP. Caso algum deles demore a responder, será considerado inoperante até que volte a responder em um novo teste. Para realizar o roteamento é possível configurar para que o ARR trabalhe de diversas maneiras, como enviando a requisição sempre para o primeiro servidor operante, ou fazendo com que ele realize um Roud Robin com base no tamanho dos pacotes ou tempo de resposta dos servidores da fazenda. Como apresentado na figura abaixo, mais informações como instalar e configurar podem ser vistas no site: http://www.iis.net/download/applicationrequestrouting.

Com a utilização do ARR, cada vez que o M3FTS necessita se comunicar com os servidores internos, ele na verdade envia uma requisição para a fazenda do seu ARR que irá rotear o pacote, retornando posteriormente a resposta do servidor interno. Assim, garante-se que mesmo que um servidor interno falhe, os módulos de M3 FTS continuem operando normalmente.

Já os servidores internos utilizam-se de tecnologias que já possuem funcionalidades de redundância, como:

  • Storage que garante uma área de armazenamento na rede redundante para o compartilhamento de arquivos entre os módulos replicados;
  • Oracle possui pacote Oracle RAC (Real Application Clusters- http://www.oracle.com/technetwork/database/clustering/overview/index.html) que monta um cluster do banco de dados. Caso o banco de dados principal falhe o seu escravo assumirá sua posição;
  • Active Directory pode ser implantando em diversos servidores e configurados para que respondam a requisição de autenticação sobre o mesmo nome de domínio da rede, garantindo que sempre haverá um servidor que possa responder a autenticação;

 Como pode ser observado, a arquitetura de alta disponibilidade apresentada não possui nenhum SPOF. No entanto, não podemos garantir que nunca haverá nenhuma falha, pois ainda existem fatores externos. Para que o sistema de alta disponibilidade seja o melhor possível, temos que possuir todos os pontos únicos da arquitetura redundantes. Em questão de hardware não há muitos problemas, a maior questão é que o seja software capaz de lidar a redundância verificando se o servidor está operacional e, em caso negativo, saber qual é o próximo que ele deve acessar. Para isso também podemos utilizar ferramentas que possam dar suporte nessas questões. Num próximo post iremos apresentar como o M3 é capaz de lidar com a redundância de forma paralela e como o mesmo pode ser disposto nesse ambiente, aumentando ainda mais a alta disponibilidade.

Escrito por Giovani Barili

Gestão de aplicativos móveis

Em minha postagem anterior aqui no blog abordei de forma suscinta um conjunto de funcionalidades de gestão de dispositivos móveis importantes para as organizações que o Gartner, em pesquisa publicada recentemente, considera essenciais nas plataformas de MDM (Mobile Device Management).

A primeira das cinco áreas citadas no texto é distribuição de software. No uso do dispositivo móvel como ferramenta de trabalho, o usuário necessariamente trabalha através do uso de aplicativos. Por outro lado são aplicativos (internet, jogos, redes sociais, etc) os grandes vilões da produtividade do funcionário equipado com um dispositivo móvel.

Assim, a correta e eficiente distribuição e gestão destes aplicativos é essencial para o sucesso da adoção da mobilidade nas organizações. Meu objetivo então é analisar mais profundamente a capacidade de gestão de aplicativos dos Sistemas Operacionais (SOs) móveis suportados pelo M3-MDM, entre eles Android, iOS, Windows Mobile e Windows Phone, com base na experiência da equipe da Mobiltec no desenvolvimento do produto.

Gerência de aplicativos no Windows Mobile

Pouco expressivo como sistema operacional nos Smartphones modernos, o Windows Mobile (WM) ainda é muito relevante no cenário corporativo. A base instalada de dispositivos rodando WM é grande e executa principalmente aplicações operacionais. Neste contexto podemos citar equipes de vendas, entrega e inspeção, entre outros.

O WM faz parte de uma geração de SOs móveis em que ainda se tem muito poder sobre a plataforma, sendo possível interagir com bibliotecas de baixo nível e drivers de hardware, por exemplo. Embora de implementação mais complexa, essa característica nos permite realizar controles sofisticados de gerência de aplicativos.

Distribuiçāo e gerência de aplicativos e atualizações

Aplicativos e atualizações no WM são tipicamente módulos EXE, DLLs e artefatos, que podem ser empacotados em arquivos CAB, por exemplo. Não há estrutura própria de distribuição no WM. É necessário construir software próprio para a distribuição dos pacotes e correta gerência do processo de instalação, que incorpore:

  • Transmissão de pacote ao dispositivo. É importante ser realizado remotamente (over-the-air) e ser assistido por tecnologia Push.
  • Plataforma administrativa, onde é possível cadastrar e gerar pacotes, controlar a sua distribuição e gerir o inventário de software dos dispositivos.

Instalaçāo e remoção de aplicativos

Uma vez presente no dispositivo, instalação e desinstalação destes pacotes são procedimentos simples, realizados pelo uso de funções próprias do SO. Algumas considerações são importantes:

  • Não é possível desinstalar aplicativos distribuidos na imagem original dos dispositivos
  • A desinstalação de aplicativos que não foram instalados pelo procedimento convencional (i.e. instalação de pacote CAB) necessitam de procedimento específico de desinstalação
  • Nas últimas versões do WM é necessário manipular permissões nos processos de instalação e desinstalação de aplicativos.

Monitoramento e bloqueio de aplicativos

Como o WM é forte no operacional das organizações, é grande a demanda por soluções de MDM que contemplem recursos de controle, com objetivo de maximização da produtividade das equipes.

Neste aspecto, o WM apresenta um bom conjunto de possibilidades para controle e monitoramento das aplicações nos dispositivos móveis:

Monitoramento de processos

O primeiro estágio do controle é o monitoramento. O funcionário sabe que está sendo monitorado em suas atividades e pode sofrer punições legais pelo mau uso do dispositivo na realização de suas atividades.

Uma forma de monitorar os aplicativos acessados pelo usuário é através do monitoramento dos processos em execução no dispositivo. No WM recupera-se facilmente a lista de processos em execução. Através da construção de uma boa ferramenta de análise, é possível identificar os padrões de uso deste dispositivo.

Blacklist de aplicativos

É possível classificar módulos de programas (EXEs, DLLs, …) em uma blacklist no dispositivo, assim bloqueando o direito de execução por parte do usuário. É importante observar que este conceito é mais fraco que de uma whitelist, pois programas novos ou desconhecidos, que podem acarretar mau uso do dispositivo, precisam ser catalogados e explicitamente bloqueados.

Agente de bloqueio

Quando se deseja um controle mais rígido sobre o dispositivo, o conceito ideal é o da whitelist de aplicativos, onde só um conjunto previamente determinado de aplicativos podem ser executados. O WM não oferece recurso nativo para este propósito. Por isso, as soluções hoje oferecidas no mercado são sistemas denominados quiosque: Um agente de bloqueio sobrepõe-se ao sistema operacional e oferece acesso limitado aos recursos do sistema. Um exemplo é o M3CLauncher, da Mobiltec.

Conclusões

Como é possível ver, são muitos detalhes envolvidos no desenvolvimento de uma plataforma de MDM que faça uma completa gestão de aplicativos móveis e que seja adequada para diversos cenários de negócio.

Como o Windows Mobile não oferece nativamente conceitos importantes, algumas das funcionalidades possuem alto custo e complexidade de desenvolvimento. Por outro lado, a flexibilidade do Windows Mobile nos permite chegar a implementação destas funcionalidades. Algumas impossíveis em SOs mais modernos, como o Android, iOS e Windows Phone, que tiram do desenvolvedor de aplicativos um maior controle sobre a plataforma.

De qualquer forma, a mudança de paradigmas dos SOs móveis mais modernos, que já consolidaram um novo padrão, modificam drasticamente os processos da gestão de aplicativos. Trarei minhas considerações sobre esta outra abordagem no meu próximo post, onde pretendo tratar a gestão de aplicativos móveis em dispositivos Android, iOS e Windows Phone.

Escrito por Eduardo Klein

O Despertar do MDM (Mobile Device Management) no Brasil

Mesmo com certo atraso devido às restrições de importações até então existentes, entre o final da década de 80 e o início da década de 90, os escritórios das empresas brasileiras começaram a serem inundados por PC’s desktops, inicialmente isolados e depois conectados através de redes locais. Logo se criou um grande problema, cuja solução não foi simples e demandou muito tempo e investimentos: a necessidade de gerenciamento desses equipamentos. Num primeiro momento cada usuário fazia o que bem entendia com o seu PC: instalava e desinstalava softwares (muitas vezes piratas); não havia proteção dos programas nem dos dados armazenados; utilizava programas muitas vezes desatualizados; ocorria contaminação por vírus de toda a rede por culpa de um usuário ter instalado um programa pirata; ocorriam perdas de trabalhos por falta de uma política de backup adequada; etc. Logo esse problema foi ainda agravado com o surgimento dos primeiros laptops, que agregaram a esse contexto a dimensão da mobilidade, porém com as severas limitações da tecnologia de comunicação então disponível. Enfim, tudo era permitido e possível de acontecer nessas redes. Essa insegurança, adicionada ao custo elevado dos equipamentos, ajudava a inibir e retardar o avanço dos processos de automação em muitas empresas, principalmente nas médias e pequenas.

Esse quadro começou a mudar quando as empresas passaram a dispor de sistemas, inicialmente complexos e caros, para fazer o gerenciamento e proteção de suas redes de PC’s desktops e notebooks. Além de uma variedade de softwares especializados, também passaram a surgir no mercado muitas empresas oferecendo esse gerenciamento como serviço, o que facilitou bastante a adoção dessa tecnologia por todo tipo e porte de organização.

Agora, estamos perante a um novo desafio, com as mesmas características, porém bem mais complexo. Os mesmos problemas que tivemos no passado, quando da popularização dos desktops, passaram agora a existir com a atual explosão da demanda dos smartphones e tablets.  O agravante é que hoje esses dispositivos móveis, embora pequenos, são bem mais poderosos que os PC’s de então e, portanto, capazes de gerar grandes estragos nas políticas de segurança das empresas.  O problema é ainda agravado pelo fato de que quase todos os funcionários carregam no bolso (…ou na bolsa) um ou mais dispositivos de sua propriedade, ou fornecido pela empresa, capazes de conectarem-se nas redes corporativas onde quer que estejam, através de redes Wi-Fi ou 3G (e…logo teremos a 4G, ainda muito mais rápida e eficiente).  Os recursos desses equipamentos permitem ao usuário transportar imensas quantidades de dados e executar programas muito complexos, totalmente fora do controle das suas organizações. Num primeiro momento o problema não era crítico porque as empresas só permitiam o acesso às suas redes dos dispositivos de sua propriedade, utilizados pelos seus funcionários para atividades específicas de automação ou para a recepção ou transmissão de emails. Entretanto, a popularização dos smartphones está forçando a quebra dessas restrições, tanto que já existe até um nome para isso: BYOD, que significa: “Bring Your Own Device”, ou seja, que estimula os funcionários a utilizarem seus próprios dispositivos pessoais também para as suas atividades profissionais.  O argumento é de que o indivíduo não mais precisará carregar dois dispositivos, um para seu uso pessoal e outro para uso profissional. A recente disseminação do uso de tablets reforça ainda mais esse argumento, pois, tratando-se de um equipamento bem maior, faria ainda menos sentido carregar mais de um.

A solução para esses problemas é a adoção pelas empresas da tecnologia chamada de MDM, ou Mobile Device Management. Os sistemas de MDM permitem às empresas fazerem, em tempo real, a completa gestão dos dispositivos que fazem acesso à sua rede e aos seus dados corporativos, assim como permite também manter a proteção desses dados quando armazenados nos dispositivos. Utilizando um sistema MDM, as empresas terão condições de se assegurar que seus dados estarão protegidos em qualquer situação, mesmo no caso de extravio ou roubo do dispositivo, assim como estabelecer restrições de uso e acesso, particularmente quando o dispositivo for de sua propriedade.

As principais funcionalidades de um sistema MDM são:

- Monitoramento dos programas e processos em execução;

- Instalação, desinstalação e atualização de programas “over the air”;

- Controle do uso de bateria e memória;

- Controle da localização e rota percorrida pelo dispositivo num período de tempo;

- Controle do acesso e exigência de senhas;

- Operação remota e atualização ou remoção de arquivos;

- Controle e segurança de dados armazenados;

Agora, que o problema se tornou visível e o risco latente, as empresas brasileiras passaram realmente a se preocupar com os aspectos de gerenciamento e perceberam de que precisam adotar algum sistema de gestão dos dispositivos móveis próprios, ou dos funcionários, que acessam os seus dados, sob pena de perderem o controle sobre os mesmos. A variedade de sistemas operacionais e a multiplicidade de aplicações disponíveis para os mesmos tornam a gestão ainda mais complexa e necessária.

A MOBILTEC antecipou-se à necessidade do mercado nacional e investiu no desenvolvimento do M3 – MDM, que atende a todos os requisitos dos produtos similares ofertados no mercado internacional. O M3-MDM gerencia dispositivos que operam com Windows, Windows mobile, Android e iOS e, além disso, oferece também as funcionalidades próprias de um “mobile middleware”, e muito importantes para as empresas, tais como: sincronização de arquivos de dados, integração com sistemas corporativos, gerenciamento  de arquivos transmitidos e recebidos, gerenciamento das atividades desenvolvidas pelos usuários, obtenção de logs, traces, etc.

Escrito por Roni Silveira – Presidente da Mobiltec