Rodrigo Moreira

MS-Rio Podcast!

2008-07-28T14:31:00Z

Há algum tempo atrás, eu e Alexandro Prado (líderes dos grupos MSRio.net e MS-InfraRio respectivamente) decidimos criar uma série de Podcasts. Para quem não conhece, os podcasts são como "programas de rádio", distribuídos via internet via MP3, com suas atualizações notificadas via RSS.

No nosso "programa de rádio", decidimos seguir um estilo de "mesa redonda", ou seja: Trazemos sempre convidados (MVPs, MSPs, Líderes de Grupos, Speakers, enfim: profissionais de destaque) para debater sobre tecnologia, trazendo o máximo de informação nesses 45-60 minutos de programa.

Acabamos de lançar a nossa segunda edição, com o tema "Novidades do IIS 7", trazendo como convidado especial Igor Humberto (Instrutor, Culminis Speaker, moderador de webcast e etc).

Mais do que só um debate, o MSRio Podcast é uma solução prática para aquele velho problema "Preciso me atualizar com o que há de mais novo no mercado, porém não tenho tempo de estudar/pesquisar sobre o assunto". Com o Podcast, é só baixar o áudio, colocar em seu mp3 player/rádio e escutar no caminho do trabalho, ou naquele tempinho vago.

Visite o blog do grupo MSRio.net e confira!

http://msriodotnet.jackflashfactory.com/2008/07/28/msrio-podcast-edição-2.aspx

Metodologias de Desenvolvimento Seguro - SDL x CLASP

2008-07-12T21:33:00Z

Falando em segurança no desenvolvimento de aplicações, é ponto fechado a necessidade de se pensar em segurança a cada fase do desenvolvimento. Pensar em segurança somente na hora de encriptar informações, ou autenticar um usuário, não pode ser considerado como levar segurança a sério.

No contexto mundial atual, onde as aplicações se tornam cada vez mais interconectadas, é importante que todos envolvidos no processo de construção do software estejam alinhados e comprometidos com a segurança, de Gerentes de Projeto até Testadores.

Com o objetivo de formalizar e padronizar as interações dos papéis nos diversos momentos da construção de software, surgiu o conceito de Metodologia de Desenvolvimento Seguro. Na linha das metodologias, quem já foi em minhas palestras ou costuma ler os meus blogs há algum tempo, vai lembrar da metodologia segura desenvolvida e utilizada pela Microsoft, a SDL (Secure Development Lifecycle). Apesar de eficiente e totalmente alinhada com o conceito da Computação Confiável, a SDL não é a única metodologia disponível.

Criada pela OWASP (Open Web Application Security Project), o CLASP (Comprehensive, Lighweight Application Security Process) também é um mundo a ser considerado e é dele que falarei brevemente por aqui.

O CLASP, assim como o SDL, é uma excelente iniciativa, mas se você pensa em comparar "qual é o melhor", com certeza entrará em uma cruzada em direção ao erro. Acontece que as duas metodologias possuem sensíveis diferenças de filosofia e de impactos nos projetos, sendo necessário a avaliação de acordo com a realidade da equipe e dos projetos para que a decisão de adoção de uma das duas (ou uma terceira) seja tomada adequadamente.

A principal diferença entre os dois em meu ver é como as duas se relacionam com a metodologia de desenvolvimento habitual (Seja RUP, seja xP, seja o tão em moda SCRUM). A SDL prega ser, por si só, uma metodologia fechada de desenvolvimento, focado em segurança, exigindo inclusive uma equipe própria, dedicada e não interligada a equipe do desenvolvimento funcional, o que sem dúvidas aumenta o custo do projeto e de gerenciamento de pessoal. Já o CLASP, prega ser um "framework", um conjunto de processos que devem ser inclusos dentro dos processos definidos pela metodologia de desenvolvimento funcional escolhida. Devido a esta característica, o CLASP não exige uma equipe focada somente na segurança do software, possuindo uma tabela "de-para", relacionando quais papéis de sua metodologia se relacionam com quais papéis da metodologia funcional.

Já nessa pequena análise, se faz notório diferenças práticas dos impactos em custo e prazo que as duas metodologias trarão aos seus projetos (pois para ter segurança é necessário um impacto, que deve ser visto como um investimento de retorno garantido). O SDL tende a obter, em um mundo real, resultados mais claros e diretos pelo fato de que os profissionais estarão focados somente na segurança, esquecendo a parte funcional do projeto, porém exigirá um custo alto em contratação e gerência de pessoal. Já o CLASP, é mais viável de utilização em projetos comerciais menores, pois não exige uma nova equipe, o que diminui considerávelmente o custo, mesmo trazendo um impacto maior em prazos.

Para conhecer melhor o CLASP, visite o site da OWASP (www.owasp.org) e encontre a documentação completa da metodologia de desenvolvimento. A leitura dos documentos é importante, pois mesmo que essa não seja a metodologia escolhida, o conhecimento adquirido ao ler os documentos será de grande valia ao profissional.

Ainda com relação ao CLASP, considero que o capítulo 5 da documentação do CLASP é um "must have" para todo profissional, por ser uma documentação extensa e detalhada (mais de 200 páginas) somente de possíveis falhas de segurança, devidamente classificadas.

Por último, devo dizer que o site da OWASP é uma página obrigatória nos favoritos de cada desenvolvedor. O portal possui um excelente projeto de categorização de boas práticas e soluções de segurança no desenvolvimento, em especial para as duas plataformas mais populares do momento: O Java e o .net. Não deixe de passar por lá e de incorporar segurança aos seus projetos. O cliente agradece!

Virtualização do UAC no Windows Vista

2008-07-04T14:08:00Z

Um dos fatores mais críticos na troca de sistemas operacionais em meio corporativo é a compatibilidade dos softwares utilizados no ambiente com o novo sistema operacional – e o Windows Vista com tantas mudanças, não é exceção a regra. Muito se falou, na época do lançamento em especial, sobre ferramentas como o Windows Vista Upgrade Advisor, que informa quais softwares deixam de funcionar no novo sistema operacional, mas o buraco infelizmente é mais embaixo. Apesar do WVUA detectar um número grande problemas, ele não detecta, por exemplo, problemas em aplicações web utilizadas pela própria companhia, pelo simples e lógico fato de que tais aplicações não se encontram literalmente “instaladas”.

O UAC é realmente uma revolução na segurança do usuário comum, mas isso não vem de graça. Além do custo da paciência do usuário, sistemas poderiam facilmente deixar de funcionar graças ao mal uso de ferramentas. Para amenizar o problema, o UAC possui um conceito chamado “Virtualização”, que deve ser aproveitado apenas para migração de plataforma (porque mal usado, pode ser utilizado como uma maneira comodista de se “resolver” problemas).

A Virtualização surge para resolver problemas de permissões. Por exemplo, imagine uma aplicação que grava informações na pasta “Arquivos de Programas” (já discutimos alguns problemas dessa prática no post anterior). Apesar do Windows XP e anteriores considerar isso uma prática “comum”, certamente o Windows Vista irá reclamar e sua aplicação passará a não funcionar corretamente (ao menos se fosse executada em contexto administrativo). Apesar de sabermos que isso é um problema, em certos casos o custo para corrigir a aplicação pode ser elevado, ou até mesmo impossível (caso a aplicação já venha de um fornecedor “fechada”, exemplo, uma aplicação da Adobe) e aí a virtualização entra em ação. Basicamente o UAC irá indicar para o Windows Vista uma pasta especifica e virtualizará todo o acesso ao diretório protegido para a pasta virtualizada. Além disso, o Windows Vista mantém todas as pastas “virtuais” em um mesmo diretório, facilitando perceber quais sistemas estão necessitando da virtualização e gerência dos arquivos virtualizados. Uma outra feature importante é que o diretório virtualizado é localizado dentro do perfil do usuário, fazendo com que arquivos temporários ou de contexto de um usuário específicos, não fiquem acessíveis a outro usuário (um dos problemas de se criar arquivos dentro de pastas como “Arquivos de Programas”).

O diretório onde as pastas virtualizadas se encontra é C:\Users\username\AppData\Local\VirtualStore

É possível verificar se um processo está ou não sendo virtualizado através do Gerenciador de Tarefas, como demonstrado na figura abaixo.

Vale lembrar que os seguintes processos nunca são virtualizados:
- Processos 64-bit
- Processos Administrativos
- Serviços
- Aplicações com manifesto exigindo “requestedExecutionLevel” (Veremos o que é a questão do manifesto em uma próxima conversA).

É possível desabilitar a virtualização de um processo em específico através do Gerenciador de Tarefas, apenas desmarcando a virtualização, clicando com o botão direito no processo virtualizado, porém o processo poderá não funcionar corretamente caso ele não tenha sido adaptado para funcionar sem a virtualização.

Também é possível desabilitar a virtualização através do Snap-In do Local Security Policy. Veja como habilitar o Snap-In do Local Security Policy aqui.

User Account Control (UAC): Vilão ou mocinho?

2008-06-18T18:16:00Z

O UAC (User Account Control) é um recurso realmente polêmico do Windows Vista, e acredito que isso ocorre devido ao não conhecimento do mesmo. Nesse momento você deve dizer “mas eu conheço sim, ele é aquela tela chata que aparece toda hora perguntando se eu autorizo ou nego uma ação” e eu digo que você está errado. Sim, ao contrário do que muita revista “especializada” prega, esta tela é apenas a maneira mais comum de interação de um usuário com o UAC, sendo o UAC um mecanismo muito maior do sistema operacional, que mais do que exibe popups, mas sim gerencia as permissões nas ações executadas no sistema operacional.

Tela de confirmação do User Account Control

Explico:

Por questões de segurança, o ideal em qualquer plataforma é nunca operar sobre um sistema com usuário de alto poder administrativo. O motivo simples e lógico é que um software que seja executado estará no contexto do usuário ativo e programas maliciosos infelizmente existem. Para exemplificar, você bem sabe que os malwares certamente tentarão gravar algo no registro do seu SO, além de se auto-copiar para pastas de sistema (System, por exemplo), porém, se o seu usuário não for administrador, não tem jeito: ele simplesmente não conseguirá gravar. O grande problema nesse assunto é o fato de ser consideravelmente trabalhoso possuir duas contas, uma administradora e outra não, e trabalhar somente com a conta não administradora. Veja um exemplo: Programar sem ser administrador é possível? Sim, é. Mas não sem um pouco de suor. É necessário configurar a conta para privilégios de debug, privilégios nas pastas de aplicação, além da configuração em utilitários para compiladores e etc. Talvez este trabalho excessivo, que só nos toma tempo hábil de trabalho, seja o motivo de que quase ninguém no mundo venha a seguir tal recomendação de não usar usuários administradores.

A Microsoft tentou dar um jeito isso anteriormente. No Windows XP, para evitar que você precisasse deslogar e logar novamente no sistema operacional para instalar um software (assumindo que o seu usuário padrão não é administrador), existe a caixa de diálogo “executar como”, mas ela também não foi o suficiente para que as pessoas usassem somente usuários restritos, por isso surgiu o famigerado “User Account Control” (UAC) no Windows Vista.

A idéia por detrás do UAC é simples. Tanto os usuários administradores quanto usuários comuns, não possuem privilégios administrativos no sistema operacional. Sim, é isso mesmo que estou dizendo. Os dois tipos de usuários possuem os mesmos privilégios, exceto por uma questão: O usuário administrativo tem o poder de “exigir” do sistema operacional o poder administrativo para um contexto específico, ou seja, exigir que durante a execução de uma determinada instância de um aplicativo (Uma janela do Windows Explorer, por exemplo), ou que durante uma ação específica dentro de um aplicativo (Alterar uma pasta restrita do sistema, por exemplo), o usuário possua tais direitos administrativos. No mundo do conto de fadas, isso deixaria todos mais seguros e felizes, já que não precisariam mais usar duas contas de usuários, memorizarem duas senhas e etc, mas não foi isso o que se viu por aí.

O UAC é chato, mas a culpa não é da Microsoft. Na verdade, o fato de todos usarem seus usuários administradores provocou uma acomodação aos desenvolvedores de software, que simplesmente desenvolvem software que só funcionam para administradores. Um exemplo claro e simples disso é a escrita de arquivos. Solicitar permissão ao diretório específico, planejar se o arquivo irá ficar no IsolatedStorage, na pasta de perfil, simplesmente gravam os arquivos em um diretório qualquer ou até mesmo, erroneamente na pasta onde o sistema está instalado. Isso sem contar as pessoas que ignoram a existência do enum “System.Environment.SpecialFolder” e colocam hardcoded “gravar em Arquivos de Programas”. Por isso que as vezes você está em um sistema operacional em português, todos os softwares estão instalados em “Arquivos de Programas” porém um ou outro estão em “Program Files”. Neste caso, alguém deixou fixo no código a gravação do arquivo na pasta “Program Files” ao invés de usar o endereço relativo representado no enum criando essa bagunça em seu querido HD.

Sim, isso é um problema. A questão é simples. Olhe para a sua pasta “Arquivo de Programas”. Certamente você encontrará arquivos e pastas de sistemas que foram desinstalados do computador. Como os arquivos possuíam dados referentes ao seu uso do software (jogos salvos, ou informações exportadas para uma planilha, quem sabe?), os mesmos não foram removidos do computador no momento da instalação. Pronto, agora você tem um monte de lixo espalhado pelo computador. Arquivo temporário deve ir para a pasta temporária não? E arquivos referentes ao uso de um usuário, para a pasta de seu perfil, correto?

Mais do que simplesmente livrar os usuários de sofrerem os problemas do uso administrativo, vejo o UAC como um “conscientizador” da indústria do software. Para funcionar no Windows Vista, você precisa conviver com o UAC e fazer as coisas do jeito certo. Quem sabe quando o usuário reclamar que o software exige muito privilégio administrativo, o fabricante não resolva fazer um software que exija menos direitos possíveis para a sua execução?

Nas próximas semanas estarei falando de maneira um pouco mais detalhada sobre o funcionamento do UAC dentro do Windows Vista e principalmente sobre como trabalhar com ele dentro do Visual Studio, desenvolvendo aplicações altamente funcionais para Windows Vista e ainda, sobre como o Windows Vista se comportará com as suas aplicações desenvolvidas para plataformas anteriores.

E que a força esteja conosco nessa jornada detalhada sobre o mundo do UAC.

Discutindo C#: Funções do Question Mark

2008-06-13T13:19:00Z

Tipos anuláveis

Tipos comuns por valor não possuem valor nulo. Por exemplo, um inteiro sem valor, armazena o valor "0", uma string, recebe o valor vazio (representado pela constante String.Empty). Porém, em situações específicas, é possível extrair vantagens no uso do valor nulo em tais tipos (Por exemplo, em inserção de dados em campos nullable no banco de dados).
A partir do C# 2.0, foi introduzido o conceito de tipos anuláveis, ou seja, tornar possível que tais tipos convivam com o valor "nulo", sendo este o primeiro uso do operador "?" que veremos por aqui.

int? variavel = null;

if (variavel == null)

// seu codigo

Operador Ternário

Esse também é bem popular. Ele não oferece uma funcionalidade diferenciada, mas sim uma economia de código, uma estrutura diferente em termos de sintaxe. A idéia é simples: As vezes é necessário realizar decisões simples, que são resolvidas através de "if". Porém a utilização do operador ternário, pode economizar algumas linhas de código.

int a = 1;

int b;

b = (a == 1) ? a : 10;

Seu equivalente utilizando a estrutura “if” seria:

if (a == 1)

{

b = a;

}

else

{

b = 10
}

Portanto a sintaxe do operador ternário é:
Variável = (condição) ? valor caso true : valor caso false

Coalesce Operator

Sim, o nome está em inglês porque nunca vi o termo em português, então não inventar por aqui :P Acredito que dos três operadores com “Question Mark” (“?”), esse é o menos “famoso”, porém de uso também simples. A idéia é diminuir a quantidade de código para verificações com o objetivo de descobrir se o valor é nulo ou não. Ele também pode ser fácilmente substituído pelo uso de “Ifs”.

int? a = null;

int b;
b = a ?? 10;

Seu equivalente seria:

if (a == null)

b = 10;

else
b = (int) a;

Repare que, apesar da mesma funcionalidade, utilizando a estrutura de “IF”, já surge a preocupação da conversão dos tipos (no caso de um inteiro anulável e um inteiro).

Discussão

Um esforço antigo da engenharia de software é tornar o código cada vez mais “legível” a humanos, ou seja, torná-lo simples, de fácil entendimento. Exatamente por isso, existe uma resistência ao uso dos operadores descritos acima, justamente porque eles viriam a tornar mais “obscuro” o código do que se utilizassem estruturas simples de decisão. A minha opinião particular é que, partindo do pressuposto que programadores devem conhecer a sintaxe da linguagem utilizada, não acredito que o uso de tais operadores seja prejudicial, na verdade, devido à redução do número de linhas de código dentro do método que usa os tais operadores, acredito que se perca menos tempo tentando entender lógicas obtusas de comparações, se dando o luxo de prestar mais atenção as regras de negócio. E vocês? A discussão está em aberto :-)