Lições sobre a cloud computing

O texto abaixo reproduz uma matéria publicada na ComputerWorld que elenca cinco características da computação na nuvem que parecem ter sido melhor assimiladas no ano que passou, gerando uma melhor compreensão do significado dessa tecnologia e que deverão ser usadas como base para os próximos níveis de adoção. A matéria original pode ser acessada aqui.

2010 foi o ano em que a "computação na nuvem" (cloud computing) se tornou apenas “nuvem” (cloud), e todos perceberam que “nuvem”, “SaaS” e todos os outros XaaS (PAAS, IAAS, DAAS) eram implementações diferentes da mesma ideia – um conjunto de serviços de computação disponíveis online que se podem expandir ou contrair de acordo com as necessidades.

Nem toda a confusão foi esclarecida, claro. Mas, vendo os serviços específicos oferecidos pela Amazon, Microsoft, Oracle, Citrix, VMware e uma série de outras empresas, muitos profissionais de TI puderam ter uma ideia mais concreta do que a “nuvem” é realmente.

Cinco aspectos se tornaram mais claros até mesmo para os mais experientes gestores de TI. São eles:

1. Nuvens “externas” e “internas” não são tão diferentes
No início de 2010, a questão mais comum era se a nuvem deveria ser inserida no firewall ou contratada fora.

Uma vez que os mesmos dados e aplicações empresariais migrem para a nuvem, interna (em servidores dentro do firewall) ou pública, a empresa proprietária dos dados enfrenta o mesmo risco. Razão pela qual muitas empresas estejam apostando mais em nuvens “híbridas” do que apenas internas ou públicas, de acordo com o guru da virtualização da Gartner, Chris Wolf.

“Com as nuvens internas, tem-se uma determinada quantidade de benefícios desde a partilha de recursos e eficiência, mas não se tem a elasticidade que é o real motivo para a venda da nuvem”, explicou Wolf à CIO.com.

2. De que são feitas as nuvens? De outras nuvens
Durante 2010, muitas empresas de computação na nuvem minimizaram o papel da virtualização e da visão “end-to-end” da VMware, na qual as empresas usam infraestruturas de servidores virtuais para suportar o compartilhamento de recursos e a gestão de recursos na nuvem dentro do firewall, antes de partir para o uso da nuvem pública.

Os fornecedores de cloud computing oferecem aplicações, armazenamento, poder de computação, etc., à vontade, sob demanda, através de uma ligação à Internet, sem a necessidade de ter uma infraestrutura de servidores virtuais dentro da empresa.

Os dois ambientes, por definição, são virtualizados, concordam os analistas. E quase sempre estão instalados em centros de dados, “parques” de servidores virtuais ou até mesmo em serviços completos de cloud fornecidos por outras empresas.

3. “Nuvens” não libertam as TI de “porcas e parafusos”
Há uma suposição de que a cloud computing consiga tornar sofisticados serviços de TI transparentes para o usuário final, fazendo com que deixem de se preocupar com o hardware e o software que os executam.

Isso não significa que as pessoas que gerem os servidores não tenham que conhecer do seu negócio, de acordo com Bob Laliberte, analista no Enterprise Strategy Group. Suportar as clouds significa tornar os servidores, armazenamento, redes e aplicações mais rápidos e estáveis, com menos atrasos do que nunca, segundo Vince DiMemmo, gestor de cloud e serviços de TI no prestador de serviços e infra-estrutura do centro de dados Equinix.

Sem infra-estrutura “à prova de balas”, a computação na nuvem é lenta, diz, e os usuários finais não aceitam a lentidão.

4. Pequenas coisas fazem grandes diferenças
A virtualização permite que várias aplicações e sistemas operacionais sejam executados pelo mesmo hardware, como se cada um deles tivesse o seu próprio servidor. O problema com isso, diz o analista da IDC, Gary Chen, é que todos pensam que têm a interface de rede e o “bus” de entrada/saída (input/output para o processador também só para si.

Em um servidor com variados sistemas operacionais virtuais, o “engarrafamento” para o desempenho já não é a velocidade com que os dados podem ir e vir entre o servidor e o armazenamento externo, mas o número de bits que podem passar pelo “bus” de dados ao mesmo tempo, diz Chen.

Essa é uma razão pela qual o Virtual I/O esteja se tornando um tema cada vez mais "quente", levando ao que o analista da Forrester, John Rymer, chama de “virtualização distribuída” – na qual I/O, memória e outros componentes são abstraídos uns dos outros, assim como os sistemas operacionais externos, e a definição de “servidor” altera-se para significar que recursos uma aplicação necessita no momento.

5. “Ano - e não Era - do Desktop Virtual”
2010 era para ser o Ano do Desktop Virtual, com a Microsoft, Citrix e VMware competindo para capturar o que os analistas esperavam ser uma onda de adopção das empresas.

Os desktops virtuais foram um tema quente em 2010 mas o crescimento não foi tão grande quanto os analistas ou fornecedores esperavam.

Em vez de padronizar os desktops virtuais e mover todos os seus utilizadores imediatamente para facilitar a migração para o Windows 7, a maioria das empresas adotou por um número crescente de “sabores” da tecnologia, mas apenas onde fazia mais sentido.

“Estamos vendo um monte de projetos táticos, mas não um monte de projetos estratégicos”, diz o analista da IDC, Ian Song.

Isso não quer dizer que não tenha havido um grande crescimento ou adoção até das versões DAAS. Mas 2010 não foi uma onda, diz Song.

As duas principais razões, segundo ele, foram a complexidade e o ROI comparativamente baixo da virtualização de desktops em relação aos servidores virtuais. Outro foi o crescente foco – até dentro das empresas – dos tablets, smartphones e outros dispositivos não-PC que têm de ser virtualizados para se tornarem seguros, confiáveis para clientes de aplicações empresariais.

“Esperamos ouvir muito sobre isso da Citrix e da VMware e de um conjunto de operadoras de telecomunicações” este ano, diz Song. E “vai ser grande”.

Mais Informações
5 Lições sobre Cloud Computing, Profissional de TI precisa se preparar para a computação em nuvem

Criando Esquema para validar um XML - parte V

Nos exemplos incluídos no último post, as regras de validação se baseiam na especificação de uma cadeia de caracteres permitidos, sendo que cada posição no texto final tem que estar declarada na regra. Embora isso resolva as situações em que o tamanho do texto exigido é fixo - como no caso do código de um produto - , é bastante inconveniente termos que declarar cada caracter quando o tamanho do texto é muito grande. Isso é especialmente verdade quando as regras para cada caracter se repetem ao longo do padrão.

Imagine, por exemplo, criar a regra de validação para um campo texto de 255 caracteres em que apenas letras maiúsculas e dígitos são aceitos. Pela forma apresentada no outro post, teríamos que repetir 255 vezes o padrão aceito em cada posição : "[A-Z0-9]". Para resolver isso de uma forma mais elegante, a sintaxe para restrições do XSD fornece um recurso que nos permite estabelecer critérios para repetições em parte do padrão - ou nele todo, se isso for necessário.

Critérios para repetições são adicionados à direita do caracter - ou caracteres - que se quer repetir. Os símbolos válidos e seus significados são listados a seguir :

* Um asterisco indica que o(s) caractere(s) à esquerda dele pode(m) ser repetido(s) quantas vezes forem necessárias, incluindo zero. Isto é, o padrão associado ao asterisco pode ser omitido e ainda assim o valor será considerado válido. Por exemplo, aplicar o padrão abaixo a um campo num XML permitiria valores válidos desde um texto vazio até a ocorrência de quantas letras minúsculas, maiúsculas ou dígitos desejássemos:

<xs:pattern value="[azA-Z0-9]*" />

+ O sinal de "mais" sinaliza que o padrão à esquerda dele deve ser repetido uma ou mais vezes para que o valor no XML seja aceito. Assim, é obrigatório que o padrão ocorra ao menos uma vez. No exemplo abaixo, é obrigatória a ocorrência de ao menos um dígito mas não há limite máximo de quantidade de dígitos para um valor ser válido:

<xs:pattern value="[0-9]+" />

? Uma interrogação sinaliza que o padrão à esquerda é opcional, isto é, ele pode ser omitido mas se for incluído deve aparecer uma única vez. O padrão abaixo permite que se informe um dígito, uma letra X maiúscula ou que se omita o valor:

<xs:pattern value="[0-9X]?" />

{n} Especificar um número entre chaves determina uma quantidade exata de repetições do padrão. No caso do código de produto, poderíamos criar uma regra como a que segue para que tal código tenha obrigatoriamente 14 caracteres, que podem ser letras maiúsculas ou dígitos:

<xs:pattern value="[A-Z0-9]{14}" />

Esta sintaxe também permite fixar limites mínimos e máximos de repetição do padrão, bastando separar o valor desses limites por uma vírgula. Assim, informar {2,4} determina que o padrão deve ocorrer no mínimo 2 vezes e no máximo 4, enquanto informar {3,} obriga a ocorrência do padrão no mínimo 3 vezes, sem especificar um limite máximo.

Para associar uma regra de repetição a vários caracteres, declare o padrão desejado entre parênteses. Assim, todo o padrão interno terá que respeitar a regra de repetição. O padrão abaixo, por exemplo, dita que um valor para ser válido tem que ser composto por um ou mais pares de caracteres, o primeiro sendo um letra maiúscula e o segundo sendo um dígito :

<xs:pattern value="([A-Z][0-9])+" />

É importante ressaltar ainda que todas as regras descritas nos posts sobre a restrição do tipo pattern num XSD podem ser combinadas para gerar regras mais complexas. É possível até mesmo criar uma lista de padrões aceitos para um determinado valor, ligando as diversas regras com um caracter | (que significa "OU"). Quando houver uma lista fixa de valores aceitáveis, eles também podem ser declarados num pattern separados pelo caracter |:

<xs:pattern value="casado|solteiro|divorciado|viúvo" />

Um outro aspecto a se preocupar na criação de regras é o que fazer quando espaços em branco - incluindo quebras de linhas e tabulações - são informados no valor. O default é manter todos esses caracteres a aplicar também a eles as restrições de sequência estabelecidas. Mas, através da tag xs:whiteSpace, é possível fazer com que todos eles sejam substituidos por espaços em branco simples antes de aplicar a regra de sequência (valor replace) ou remover completamente esses espaços no começo e no fim do texto, além de juntar num único espaço as duplicidades que aparecerem no meio :

<xs:whiteSpace value="collapse" />

O xs:whiteSpace pode ser combinado na mesma restrição com outras tags, como o xs:pattern e o xs:minLength.

Mais Informações
Criando esquema para validar um xml - parte I, parte II, parte III e parte IV, Tratamento de restrições no XSD

Criando Esquema para validar um XML - parte IV

A flexibilidade das especificações para um XML feitas através de XSD pode chegar ao ponto de garantirmos que o valor de um determinado elemento no XML está de acordo com uma máscara previamente projetada. Um bom exemplo disso é a formatação do código do produto, campo que usei nos outros posts sobre esse assunto. Muitas empresas usam uma formatação inteligente para o código do produto, isto é, partes do código ajudam a identificar e classificar o produto de modo que é imprescindível que ele esteja formatado corretamente.

A tag no XSD responsável por essa parametrização é a xs:pattern, inserida dentro da tag xs:restriction exatamente como as outras restrições apresentadas até agora. Em xs:pattern podemos especificar a série de valores aceitos na tag correspondente do XML, montando caracter a caracter a máscara desejada. Basicamente, a posição de um novo caracter é marcada com um par abre-e-fecha colchetes envolvendo os valores aceitos. O trecho abaixo, por exemplo, exige que o código seja formado por 3 letras maiúsculas :

<xs:element name="codigo" >
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="[A-Z][A-Z][A-Z]" />
</xs:restriction>
</xs:simpleType>
</xs:element>

Veja que para especificar a faixa de caracteres aceitos em cada posição eu usei um hífen separando o caracter inicial e o final da faixa : A-Z. Se quiser permitir também que letras minúsculas e algarismos sejam aceitos, basta inserir as faixas correspondentes no mesmo par de colchetes. Na tag pattern abaixo, o código continua a ter obrigatoriamente 3 caracteres mas o primeiro deles pode ser uma letra maiúscula, uma minúscula ou um algarismo enquanto nas duas posições finais apenas letras maiúsculas continuam a ser permitidas:

<xs:pattern value="[A-Za-z0-9][A-Z][A-Z]" />

Não é necessário qualquer separador para delimitar as faixas pois, como cada par de colchetes representa apenas um caracter no texto, a separação entre elas fica implícita. Com a restrição publicada acima, os códigos aBC ou 9ER são válidos mas não AbC, por exemplo. Por causa disso, poderemos chegar ao ponto de especificar uma lista de caracteres aceitos numa determinada posição do nosso código. Suponha que nosso código tenha que ser iniciado com uma das seguintes letras : A, C, M ou P, indicando uma classificação qualquer do produto. Imagine também que o código seja finalizado com um dígito verificador, totalizando 4 caracteres. Segue abaixo a montagem dessa restrição no XSD:

<xs:pattern value="[ACMP][A-Z][A-Z][0-9X]" />

O dígito verificador nesse exemplo pode ser qualquer algarismo ou a letra X maiúscula. Note que o XSD não é capaz de garantir que o dígito verificador informado tenha sido calculado corretamente. Validações desse tipo já caracterizam regras de negócio específicas e não são abordadas pelo XSD. O objetivo dele se restringe a garantir que um XML baseado nele esteja minimamente bem construído. É o mesmo tipo de situação da Nota Fiscal Eletrônica, onde a Receita disponibiliza um XSD com o básico da formação do XML mas algumas consistências têm que ser feitas fora desse escopo, cruzando informações com outros sistemas - por exemplo, para verificar se o CNPJ do emissor está mesmo ativo.

Embora eu só tenha usado exemplos com letras e números, qualquer caracter pode fazer parte de uma restrição pattern - até mesmo o hifen (-) e o fecha colchete (]). No entanto, como esses caracteres têm significado especial na sintaxe do XSD, use uma barra (\) para indicar que você quer usar esse caracter como parte da regra de restrição. A regra reproduzida abaixo mostra o exemplo anterior modificado para que um hifen seja usado para separar o dígito verificador do resto do código:

<xs:pattern value="[ACMP][A-Z][A-Z][\-][0-9X]" />

A própria barra é um caracter especial e, para usá-la numa regra, ela terá que ser incluída dobrada. Os seguintes códigos são válidos segundo a restrição acima: AER-8, CUR-0 e PAR-X.

No próximo post, abordo outras regras aplicáveis à criação de restrições, como tratamento de caracteres em branco, lista de valores fixos válidos e como repetir padrões para simplificar a montagem de regras.

Mais Informações
Criando esquema para validar um xml - parte I, parte II e parte III, Tratamento de restrições no XSD

Sua rede está bem protegida contra invasões ?

Segurança é - ou ao menos deveria ser - uma grande preocupação em empresas de todos os tamanhos. Invariavelmente, a rede das empresas costuma ser a porta de entrada mais comum para invasões de hackers e ataques de pragas virtuais. A partir de um único computador afetado, toda a rede interna pode acabar comprometida, com consequências que vão desde lentidão em sistemas até vazamento de informações sensíveis das empresas.

Por isso, é imprescindível se valer das ferramentas disponíveis para deixar essa porta menos vulnerável. O uso de firewalls, antivírus, softwares de restrição de acesso à internet, configurações específicas em roteadores e outros equipamentos da rede são medidas amplamente adotadas para aumentar a segurança. No entanto, muitas empresas negligenciam ou subestimam os riscos de uma ameaça muito mais próxima : atitudes dos seus próprias funcionários. Mesmo um funcionário bem intencionado pode infectar a rede com um virus ao abrir um email contaminado ou ao usar um pen-drive em seu computador.

Uma das reportagens mais lidas no site da ComputerWorld em 2010 aborda justamente a questão da vulnerabilidade das redes empresariais frente aos novos avanços tecnológicos. São gadgets e outras ferramentas (inclusive softwares) que no geral trazem melhorias de produtividade mas que se não forem utilizadas com bom senso podem acarretar muitas dores de cabeça. A reportagem enumera 10 brechas frequentes que compromentem a segurança da rede e dá dicas de como enfrentá-las. Reproduzo a lista de brechas e as dicas abaixo abaixo. O conteúdo original pode ser acessado neste link.

1. Flash drives (Pendrives): São, disparados, a maneira mais comum de contaminar um ambiente de rede cercado por firewalls. Baratos, portáteis e capazes de carregar muitos dados, ainda são passíveis de passear por diversas máquinas diferentes. Essas características motivaram o desenvolvimento de vírus especialmente para essa mídia. É o caso do worm Conficker, que se espalha assim que o drive é conectado na máquina. Para piorar, a maioria dos sistemas operacionais monta esses dispositivos assim que são ligados .

O que fazer? Modifique as políticas de acesso automático às novas mídias do seus sistemas operacionais.

2. Laptops, notebooks, netbook e tablets: Discretos, portáteis, munidos de sistemas operacionais completos e capazes de operar usando baterias, os gadgets têm, ainda, conexão Ethernet sem fio (alguns têm portas físicas tradicionais também), e podem se comunicar com o ambiente de rede, de subrede etc. Se estiver contaminado, pode, assim que se conectar à rede, procurar por outros participantes que possam ser infectados.

Mas os dispositivos móveis têm outra fragilidade. Mobilidade. Permitir que essas máquinas passeiem livremente para cima e para baixo enquanto carregam dados de cunho confidencial é para lá de perigoso. Sugere-se que os arquivos estejam criptografados e que sejam munidos de recursos que permitam a deleção do sistema de arquivos à distância no caso de um deles “se perder”.

Logo: limite o tipo de informação armazenada nos dispositivos móveis. Dados de login em redes VPN, DV e Wi-Fi não devem ser salvos nos sistemas. Criptografar os arquivos existentes? Sim. Já.

3. Pontos de acesso de rede: essas interfaces providenciam acesso à rede sem fio para qualquer um que queira se conectar e esteja no raio de alcance da antena. Ataques executados por wardrivers - pessoas que passam o dia em vans circulando por cidades na busca por redes abertas - têm sido cada dia mais comuns. Um rede de lojas teve seu sistema invadido dessa maneira. Os dados de transações de clientes, como números de cartões de crédito, endereços, tipo de operação etc. foram parar na mão dos criminosos. Como resultado, os danos chegaram a meio milhão de dólares.

Criptografadas ou abertas, as redes Wi-Fi são, por natureza, frágeis. Existe uma série de modalidades de ataque, que podem comprometer a rede. Mesmo conexões protegidas (WPA ou WPA2) são pouco eficazes quando uma senha robusta não lhes é atribuída.

O que fazer? Separe as redes abertas das corporativas, não dê acesso aos participantes de um ambiente ao outro. Além disso, é interessante usar recursos de autenticação complementares nas redes Wi-Fi. Permissão para determinadas MACs (identificação física do adaptador de rede e único para cada placa) é uma maneira de fazer isso.

4. Mais USB: Se pensa que os flash drives (pendrives) são os únicos dispositivos USB que podem contaminar sua rede, está redondamente enganado. Máquinas digitais, MP3 players, impressoras e até porta-retratos digitais são todos capazes de armazenar arquivos potencialmente danosos à rede. Quem nunca usou uma máquina fotográfica para transportar um arquivo do Word?

Em 2008, a BestBuy, rede de lojistas, informou que fora encontrado um vírus dentro de uma desses porta-retratos digitais, recém-chegado do fabricante.

A solução: Restringir o acesso e a entrada desses dispositivos em seu ambiente de trabalho corporativo. Deixe evidente, o tempo todo, que essas mídias não devem ser conectadas nas máquinas. Há quase três anos, o Departamento de Defesa dos EUA proíbe terminantemente a entrada de qualquer dispositivo USB em suas dependências.

5. Acesso interno: não raramente, os funcionários de empresas têm acesso a ambientes de rede delicados, cheios de arquivos importantes. Se esse for o caso, todas as opções anteriores de infecção se tornam potencialmente aplicáveis. Já viu um colaborador “emprestar” o terminal de trabalho de outro colega enquanto este saiu para almoçar? E quando um empregado pede que outro libere o acesso à rede? Essas coisas são mais comuns que se pensa.

O antídoto: Troque regularmente as senhas. Funcionários só devem ter acesso às áreas de rede que sejam essenciais para seu trabalho. Qualquer pedido de acesso complementar deve ser feito para uma equipe de TI e não a um único encarregado.

6. O trojan humano: Parecidos com a versão digital inspirada no cavalo de Tróia, esses dispositivos bípedes podem vir até as empresas disfarçados de técnicos de manutenção, de limpeza ou similar. Já foram registrados casos em que esses malfeitores conseguiram acesso às salas superprotegidas de servidores.

Talvez seja uma questão cultural, mas poucos de nós impedem a entrada de alguém devidamente identificado, mesmo que seja estranho ao ambiente de trabalho. Depois de ter a entrada garantida, a infecção do ambiente de rede pode acontecer em questão de um minuto.

Como se prevenir? Expor claramente as condições de acesso de prestadores de serviço no ambiente de trabalho e verificar as informações dadas. Jamais confie no feeling.

7. Mídias óticas: Junho de 2010. Um analista de segurança do Exército dos EUA foi preso depois de roubar e publicar informações confidenciais em círculos públicos. Fontes informam que o sujeito entrou no ambiente trazendo consigo CDs de cantores populares; tudo farsa. Uma vez sentado nas máquinas, o criminoso acessou os dados que interessavam e os gravou no “CD de música” que ouvia enquanto trabalhava. Dizem, ainda, que o rapaz assoviava os sucessos que curtia enquanto roubava os dados.

Essa forma de crime é absolutamente comum. Mídias portáteis são uma maneira de transportar informações de um lugar para outro e, às vezes, isso dá problemas. Além de os drives de CD serem usados para vazar dados, é importante lembrar que também são portas de entrada de vírus, trojans etc.

Como sair dessa? Da mesma forma que lida com os dispositivos USB: restringindo seu acesso e esclarecendo as políticas aos funcionários – constantemente.

8. A mente humana: Se muitas das opções descritas até agora têm por objetivo mitigar as ameaças que pairam sobre as redes corporativas, é absolutamente necessário lembrar que a criatividade e a capacidade da mente humana em guardar informações é quase ilimitada. Será que tem alguém de olho no que você digita quando vai realizar o login em uma rede? Onde você costuma armazenar os dados importantes? É de seu costume ler documentos confidenciais quando está esperando em aeroportos ou em um café?

Como se prevenir? A melhor saída é a prevenção. Levante a cabeça enquanto visualiza conteúdo classificado como confidencial e seja cauteloso ao entrar em redes públicas.

9. Smartphones e outros gadgets: Os celulares já não são mais como eram antigamente. Hoje em dia, carregam câmeras de alta resolução e portas de conectividade de todas as espécies e tamanhos. Os sistemas operacionais também podem dar conta de vários processos ao mesmo tempo e suportam uma vasta gama de aplicativos.

Além disso, esses dispositivos têm entrada permitida em vários ambientes corporativos em que são tratados assuntos delicados, muitas vezes estratégicos. As ameaças representadas por esses gadgets são as mesmas que se observa em laptops e notebooks.

O que impede um usuário de smartphone capturar uma imagem que revele informações importantes e transmiti-la via rede 3G?

A solução para os smartphones é mesma que serve para os dispositivos USB e às mídias óticas. Esclareça aos funcionários em que condições esses dispositivos podem entrar no ambiente corporativo.

10. E-mail: Originalmente ele serve para otimizar o fluxo de trabalho e realizar a comunicação entre pares envolvidas em um processo. Mas isso é teoria. O e-mail é muito usado para enviar e receber dados. Dados estes que podem ser anexados em uma mensagem sem que se tenha certeza da idoneidade de quem os recebe.

As caixas de entrada são, ainda , poderosas portas de entrada para viroses binárias. Se conseguirem entrar na conta de e-mail, podem roubar dados de acesso e levar a um segundo ataque, de proporções hercúleas.

Tem jeito de evitar? O nome da solução é “identificação de origem”. Atribuir uma identidade a quem enviou a mensagem, usando soluções como PGP, ou uma simples rotina de perguntas antes de enviar informações confidenciais deve dar conta da questão.

Também vale restringir o banco de dados de e-mails que podem receber mensagens a partir do serviço interno. Como sempre, educação é palavra-chave: deixe claro na organização que o uso de email deve ser feito com olhos voltados à segurança.

Mais Informações
10 brechas pelas quais sua rede pode ser invadida