No Azure é possível alterar o tamanho de um disco de uma máquina virtual utilizando comandos powershell.

Para o modo do Azure Service Manager (ASM) existe um cmdlet powershell chamado Update-AzureDisk com vasta documentação na internet. Agora, para o Azure Resource Manager (ARM) não existe o comando equivalente. Após estudar o problema um pouco, é possível notar que esta é uma das diversas diferenças entre os dois modos (ARM e ASM).

No ARM, as propriedades do disco (inclusive o tamanho) estão associadas ao perfil de armazenamento da máquina virtual (i.e. “VM Storage Profile”). Também é possível atualizar algumas destas propriedades através do powershell. No caso dos discos da máquina virtual, é possível aumentar o tamanho alterando a propriedade DiskSizeInGb do objeto OSDisk (para discos de sistema) ou de cada um dos objetos DataDisks associados à máquina virtual.

Recentemente precisei realizar esta tarefa para o disco de sistema operacional de algumas máquinas e montei um script powershell para fazer esta tarefa. Segue abaixo um exemplo de como utilizar estes comandos powershell:

 
Nota: a Microsoft não oferece suporte a este script; use por sua conta e risco.

Observe que o script irá parar a máquina virtual, realizar a alteração de tamanho do disco e reiniciá-la. Este é um requisito pois não é possível alterar a configuração de hardware (Storage Profile) com a máquina em execução.

[]s

PT

“Uma vez que eu armazenei minhas chaves de criptografia no Azure Key Vault, a Microsoft pode ter acesso as mesmas?”

Talvez nem todo mundo tenha clareza que todas as chaves armazenadas em um Vault tem um objetivo único que é ser acessada por algum sistema ou aplicação. Então, por “a Microsoft pode ter acesso a chave” eu imagino que os clientes estejam querendo dizer “Uma pessoa ou recurso não autorizado poderia exportar/copiar essa chave para um outro ambiente, e juntamente com uma cópia dos dados dos discos dos clientes, decriptografar o conteúdo e acessá-lo”. 

Assumindo que seja isso, começo explicando que para adicionar uma chave ao Key Vault o cliente (e só ele) deve criar um ‘secret’ (uma senha), como exemplificado:

Só o cliente tem acesso a esse senha, e somente é possível exportar as chaves usando esta senha. Esse é um primeiro nível de segurança, mas adicionalmente o cliente pode escolher entre armazenar esta chave no Azure Key Vault usando um armazenamento ‘em Software’ ou ‘em Hardware  HSM’.

Embora pouco provável, em teoria ao armazenar a chave em Software seria possível invadir um Datacenter do Azure burlando todas as medidas de segurança, alarmes, controle de acesso físico, etc e identificar num pool de milhares de servidores quais rodam o serviço do Azure Key Vault, colocá-lo debaixo do braço e levá-lo embora.

Depois, inicializar os servidores usando algum outro sistema (ex: Linux) e via software e tentar quebrar bitlocker, criptografia, etc para conseguir extrair/exportar as chaves dos clientes. E usando métodos de força bruta, após alguns anos, se conseguiria descobrir a senha que o cliente usou para finalmente ter acesso a chave.

Mesmo assim, imaginando que existam clientes que precisem de um nível de segurança acima do que já expliquei, também é possível armazenar as chaves dos clientes em hardware (via Thales HSM, na SKU Premium); estas chaves uma vez armazenadas nesses HSMs *não podem mais ser exportadas* (nem pelo próprio cliente, já que isso está garantido no hardware HSM).

Finalmente, o cliente pode ter o próprio HSM e usá-lo para gerar suas próprias chaves on-premises. Então, usando um pacote BYOK (bring your own key), armazenar as chaves nos HSMs do Azure Key Vault. Com este cenário, as chaves são virtualmente inviolávies (a não ser que se descubra algum método de hackear os HSMs e se consiga ter acesso físico aos mesmos). Este cenário está detalhado aqui: https://azure.microsoft.com/en-us/documentation/articles/key-vault-hsm-protected-keys/

Assim (e finalmente), respondendo efetivamente a pergunta:

“Só o cliente tem a chave ou a Microsoft tem condições de ter acesso a essa chave ?”

R: Não. A Microsoft não tem como ter acesso as chaves. Todavia, as chaves estão armazenadas no serviço Key Vault e portanto podem (e devem) ser acessadas por aplicações na plataforma Azure (ou fora dela) de acordo com as regras que o cliente estabelece (através de policies por ele definidas).

A Microsoft não possui mecanismos para exportar estas chaves do Azure Key Vault e reutilizá-las em outros ambientes para ter acesso à dados de clientes; somente o cliente conseguirá exportar as suas chaves (e se ele perder as senhas, então nem ele, nem a Microsoft conseguirão exportá-las). O cliente pode optar por armazenar suas chaves em HSMs do Azure Key Vault que acrescentam uma camada extra de proteção e não permitem que as chaves sejam exportadas;

Por último, além de todo o tequiniquês sobre HSMs, criptografia, chaves, etc, o cliente também tem a Garantia Legal pela certificação FIPS 140-2, dentre outras.

Para mais informações, vejam https://azure.microsoft.com/en-us/documentation/services/key-vault/  e https://azure.microsoft.com/en-us/documentation/articles/key-vault-get-started/

Abraços,

PT

Depois de um longo inverno, estou de volta aos posts aqui no Blog.

E com uma boa novidade, agora sou 100% Cloud, então vão aparecer vários posts sobre Azure.

[]s
PT

O que aconteceu é que mudei de função e não estou mais trabalhando com suporte à aplicações Web (ao menos não oficialmente). Por outro lado, isso não é ruim pois agora o foco principal é em Cloud Computing (aka Microsoft Azure).

Resumindo, continuo trabalhando com cenários em que envolvem Infra e Dev e que até ganhou um nome "bonito": DevOps. E, como tem muita novidade e questões interessantes sobre Azure, em breve vou publicar alguns posts sobre o assunto. Stay tuned!

Um abraço,

PT

O interessante é que eles criaram esse script para resolver um pequeno “side effect” da versão inicial que eu havia escrito: o meu script carregava a DLL via powershell, e por consequência ela ficava bloqueada (durante o tempo de execução do script) não podendo sofrer nenhuma alteração.

Com isso, se a aplicação fosse recompilada naquele período de tempo, isso poderia gerar um erro. Além disso, a forma de verificar se os assemplies estão compilados em modo debug foi aperfeiçoada e dados adicionais são exibidos. O resultado final ficou muito bom e por isso eu pedi a autorização deles para publicar o script aqui no blog.

Segue:

##

if ($args[0] -eq $null) {
    $path = $(Split-Path $MyInvocation.InvocationName)
} else {
    if (Test-Path($args[0])) {
        $path = $args[0]
    } else {
        write-host "O diretório" $args[0] "não existe!"
        Break
    }
}

##

function Get-DotNetDebuggableAttribute
{
    [CmdletBinding()]
    Param(
        [Parameter(
            Mandatory=$True,
            ValueFromPipeline=$True
        )] [string[]]$files
    )

    Begin
    {
        $list = @()
    }

    Process
    {
        foreach ( $filename in $files )
        {
            if ( Test-Path $filename )
            {
                $file = Get-Item $filename
                if ( $file.Extension -eq '.dll' )
                {
                    try
                    {
                        $assembly = [System.Reflection.Assembly]::Load([System.IO.File]::ReadAllBytes($file.FullName))
                        $file | Add-Member NoteProperty ImageRuntimeVersion $assembly.ImageRuntimeVersion
                       
                        $modules = $assembly.GetModules($false)
                        if ($modules.Length -gt 0) {
                            $portableExecutableKinds = New-Object System.Reflection.portableExecutableKinds
                            $imageFileMachine = New-Object System.Reflection.imageFileMachine
                            $modules[0].GetPEKind([ref]$portableExecutableKinds, [ref]$imageFileMachine)

                            $file | Add-Member NoteProperty PortableExecutableKinds $portableExecutableKinds
                            $file | Add-Member NoteProperty ImageFileMachine $imageFileMachine

                            Switch($portableExecutableKinds.ToString().Split(',').Trim()){
                                "Required32Bit" {$platformTarget = "x86"}
                                "PE32Plus" {$platformTarget = "x64"}
                                "ILOnly" {$platformTarget = "Any CPU"}
                                default {$platformTarget = "Unknown"}
                            }

                            $file | Add-Member NoteProperty PlatformTarget $platformTarget

                        } else {
                            $file | Add-Member NoteProperty PortableExecutableKinds $null
                            $file | Add-Member NoteProperty ImageFileMachine $null
                            $file | Add-Member NoteProperty PlatformTarget $null
                        }

                        $attrs = $assembly.GetCustomAttributes([System.Type]::GetType("System.Diagnostics.DebuggableAttribute"), 0)
                        if ($attrs.Count -eq 1) {
                            $attr = $attrs[0]
                            $file | Add-Member NoteProperty IsJITTrackingEnabled $attr.IsJITTrackingEnabled
                            $file | Add-Member NoteProperty IsJITOptimizerDisabled $attr.IsJITOptimizerDisabled
                        } else {
                            $file | Add-Member NoteProperty IsJITTrackingEnabled $null
                            $file | Add-Member NoteProperty IsJITOptimizerDisabled $null
                        }
                         $list += $file
                    }
                    catch
                    {
                        Write-Debug "Error trying to access the file using System.Reflection.Assembly"
                        Write-Debug "Error: $_"
                    }
                }
            }
        }       
    }

    End
    {
        if ( $list.Count -gt 0 )
        {
            #Write-Output $list | Format-Table Mode, LastWriteTime, Length, Name, IsJITOptimizerDisabled, IsJITTrackingEnabled -AutoSize
            return $list
        }
    }
}

get-childitem $path -Recurse -include *.dll | Get-DotNetDebuggableAttribute | Format-Table LastWriteTime, Name, ImageRuntimeVersion, PlatformTarget, IsJITOptimizerDisabled -AutoSize

Lembrando que este script não é suportado de forma alguma pela Microsoft, use por sua conta e risco.

PS: ele não faz nenhuma alteração no seu ambiente, e portanto, não deveria causar problemas. De qualquer forma, eu recomendo utilizado em ambientes de teste, homologação ou pré-produção.

abraços,

Paulo. 

Você está trabalhando para migrar uma aplicação .NET do IIS6 para o IIS 7.x/8 e após fazer toda a configuração imediatamente no primeiro acesso já recebe a seguinte mensagem de erro:

Request is not available in this context

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Web.HttpException: Request is not available in this context

Logo abaixo você poderá encontrar detalhes adicionais (linha onde ocorreu o erro) além de uma pilha similar ao seguinte:

[HttpException (0x80004005): Request is not available in this context]   
System.Web.HttpContext.get_Request() +3467061    ASP.global_asax.Application_Start(Object source,
EventArgs e) in c:\inetpub\wwwroot\global.asax:5

[HttpException (0x80004005): Request is not available in this context]   
System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode(…

Como podemos observar, o erro foi gerado no módulo/método ASP.global_asax.Application_Start da aplicação. Este é um problema conhecido quando se faz a migração de aplicações ASP.NET do IIS6 para versões superiores, e está descrito no seguinte blog: https://mvolo.com/iis7-integrated-mode-request-is-not-available-in-this-context-exception-in-applicationstart

Para resolver o problema você precisará solicitar ao desenvolvedor que abra o arquivo GLOBAL.ASAX.CS (ou .VB) da aplicação e localize, dentro do método ApplicationStart() qualquer uso do objeto HttpContext.Current.Request. Em geral você encontrará algo como:

str = HttpContext.Current.Request.QueryString["key"];

Será necessário remover este código substituindo-o por algum outro mecanismo. A explicação para este erro é bem simples: no IIS7 o novo pipeline integrado irá executar o método Application_Start() antes que qualquer request chegue ao servidor, e portanto, o objeto Request não está disponível.

Um abraço e até a próxima,

PT

Olá pessoal!

Poucos desenvolvedores fazem uso de um dos recursos mais interessantes disponíveis para aplicações ASP.NET, a capacidade de criar traces diretamente a partir do seu código e usá-los para resolver problemas durante a etapa de desenvolvimento.

O uso de "técnicas para criação de traces" é algo muito comum: lembra-se de ter escrito um bom e velho "Response.Write" em aplicações ASP Clássico para validar se os dados em uma determinada rotina está conforme o esperado? Pois é... era assim no ASP Clássico, em C, C++, etc

Nas aplicações ASP.NET este processo é realmente muito simples: basta habilitar o registro de entradas de trace no arquivo web.config, adicionando a seguinte tag:

<trace enabled="true" localOnly="false" pageOutput="false" />

Maiores detalhes sobre a diretiva <trace> do arquivo web.config pode ser obtida em: https://msdn.microsoft.com/en-us/library/6915t83k(v=vs.80).aspx

Com a diretiva trace configurada no seu arquivo web.config agora basta adicionar as diretivas de trace em sua aplicação. O desenvolvedor deverá adicionar algumas linhas de código na sua aplicação, para imprimir os valores que precisam ser validados. Para isso, em cada modulo que se deseja utilizer o trace, deve-se adicionar o namespace System.Web. Um exemplo simples do uso de trace em uma página ASP.NET (em C# e .NET Framework 4.5) é mostrado a seguir:

using System;
using System.Collections.Generic;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace TraceSample
{
  public partial class LongRunningPage : System.Web.UI.Page
  {
    protected void Page_Load(object sender, EventArgs e)
    {
      //
      // This is just a page where any GET requests will take...
      // well, very long

      Trace.Warn("Warning! Entering in the PAGE_LOAD event");

      DateTime start = DateTime.Now;
      int delay = new Random().Next(5000, 15000);
      Thread.Sleep(delay);

DateTime end = DateTime.Now;
myLabel.Text = String.Format("Total page exec took:{0} ms", (end - start).TotalMilliseconds);

      Trace.Write("PAGE_LOAD event finished");

    }
  }
}

No código acima você encontra duas diretivas: Trace.Warn e Trace.Write ... existem poucas diferenças entre elas, a mais visível é que a primeira irá produzir uma entrada em vermelho na saída do trace.

Uma vez que o código da aplicação tenha sido ajustado para criar a saída necessária, você poderá acessar a página e testar a sua aplicação. Após ter executado a página, você poderá visualizar o resultado do trace através do handler TRACE.AXD. Por exemplo, se a página chama-se LongRunning.aspx., você deve primeiro chamar:

https://meusite/LongRunning.aspx

e depois:

https://meusite/trace.axd

Com isso, uma página de trace similar ao seguinte sera exibida:

Ao se clicar em uma das entradas você poderá observer detalhes do trace daquela página, algo similar ao seguinte:

Acima podemos ver o resultado das diretivas de trace que foram adicionadas no código da aplicação. Voilá!

Agora, o mais um ponto: É possível visualizar o resultado das diretivas Trace.Warn nos logs FREB (ou Failed Request Tracing) do IIS. Basta configurar o seu servidor para gerar este tipo de log (conforme as regras que você estabelecer) e ao visualizá-lo você encontrará as saídas geradas pelo seu aplicativo.  Esta é a outra diferença entre as duas diretivas: Trace.Write não irá aparecer nos logs do IIS, e portanto, se precisar usar este recurso de uma forma regular, use somente o Trace.Warn.

E finalmente, aquela dica de sempre: não deixe as diretivas de trace habilitadas em servidores de produção! Sempre podem existir questões relacionadas à segurança de sua aplicação e não custa descuidar!

É isso ai! Não perca tempo e aproveite para usar este recurso durante o processo de desenvolvimento da sua aplicação.

Abraços,

PT

Faz um tempo um cliente me perguntou a diferença entre Web Site e Web Application.De início eu nem tinha entendido direito a pergunta, mas depois ficou claro a dúvida: a questão estava relacionada aos tipos de projeto disponíveis no Visual Studio.

No Visual Studio, você pode escolher entre dois tipos de projetos Web: Web Site Project (WSP) ou o Web Application Project (WAP).

A grande diferença entre estes dois tipos de projeto é a forma que ocorre o deployment da aplicação. Em um Web Site Project o Visual Studio irá fazer a publicação de todos os arquivos do projeto (incluíndo o código-fonte da sua aplicação). Já em um Web Application Project somente será publicado o código HTML (markup) e o código compilado da sua aplicação.

Em outras palavras, em um Web Application Project o Visual Studio irá se encarregar de compilar a sua aplicação, gerando vários binarios dentro da pasta /BIN. Ao se fazer a publicação somente estes arquivos serão colocados no servidor Web. 

Existem prós e contras para cada um dos tipos de projeto, mas eu pessoalmente sou muito mais a favor do uso de Web Application Projects, por um fator muito simples: você evita que o código-fonte fique visível no servidor Web (ponto para a questão de segurança), e também evita que o servidor Web fique responsável pela compilação da aplicação durante o primeiro acesso (uma outra hora faço  um post com mais detalhes sobre isso).

Uma comparação mais detalhada entre estes dois tipos de projeto pode ser encontrada em  https://msdn.microsoft.com/en-us/library/aa730880(VS.80).aspx#wapp_topic5 (em inglês)

[]s
PT

Olá pessoal! Imagine o seguinte cenário:

Você possui uma aplicação antiga construída em ASP.NET mas que por algum motivo específico ainda usa componentes COM através de Interop.

Este, apesar de não desejado, é um cenário muito comum, em particular em ambientes corporativos: muitas vezes os componentes COM foram construídos em VB6 ou VC++ e encapsulam regras de negócio que não mudaram. Como as áreas de TI nem sempre possuem orçamento para fazer a conversão deste código para uma linguagem .NET como o Visual Basic.NET ou C#, esses componentes costumam ser usados por um logo período de tempo, até que um novo projeto substitua inteiramente a aplicação.

Agora, imagine que a área de TI da empresa resolve evoluir a plataforma Web para as versões mais recentes do Windows Server, só disponíveis em 64-bits. Para este cenário sempre existe a possibilidade de rodar os Application Pools do IIS 7.x (e superior) em modo 32-bits, mas seria desejável que asp aplicações ASP.NET pudessem explorar o máximo da nova plataforma, com o poder total da arquitetura 64-bits. Mas ai, surge o problema dos velhos componentes VB6 32-bits. Por padrão, não é possível carregar uma DLL (Componente COM) 32-bits em um processo (Application Pool) 64-bits. O que fazer???

Uma forma simples de continuar utilizando o código legado desses componentes COM de 32-bits sem custo extra é passar a usá-los no COM+ (Component Services). Basta seguir os seguintes passos:

1. Primeiro, se você tiver registrado a DLL do seu componente no seu Windows x64, você terá que desfazer este processo. Execute o comando “regsvr32 /u <path_e_nome_da_dll>”
2. Vá no Control Panel / Administrative Tools/ Component Services. Depois, no treeview abra My Computer, e então COM+ Applications. Clique com o botão direito e selecione “New –> Application”
3. Na tela “Welcome to the COM Application Install Wizard” clique em “Next >”.
4. Selecione o botão “Create an Empty Application”.
5. Dê um nome para a sua aplicação (qualquer nome serve, mas é bom colocar algo que lembre o nome do componente que será executado). Depois entre “Library / Server”, selecione o tipo “Server”.
6. Clique em “Next >” e depois  “This User”.
7. Selecione o usuário com o qual o componente será executado. Pode ser um usuário de domínio previamente criado para executar o componente ou um dos usuários de sistema existentes (NOTA: escolha o usuário tentando manter o mais seguro possível; evite LOCAL SYSTEM pois o mesmo tem direitos de administrador no Sistema Operacional, a menos que isso seja um pré-requisito da aplicação).
8. Depois pressione “Next >” nas telas seguintes (não altere nada), até concluir a criação da aplicação.
9. O próximo passo é adicionar o seu componente a esta aplicação recém-criada. Você encontrará a aplicação em Component Services -> Computers -> My Computer -> COM+ Application . Clique no ícone “+” e você verá um item “Components”. Selecione este item.
10. Usando o Windows Explorer, arraste a DLL para a janela à direita na tela em “Components”. Com isso o componente será registrado automaticamente no Component Services. Aparecerá um ícone de forma circular e de cor amarelada que representa o Componente recém-instalado.
11. Em seguida vá em Component Services -> Computers -> My Computer -> COM+ Application e selecione sua aplicação. Clique com o botão direito e abra as propriedades selecionando “Properties” no menu de contexto.
12. Clique na guia “Security” e em “Authorization” desmarque a opção “Enforce access checks for this application”.
13. Em “Security Level” marque a opção “Perform access checks only at the process level.”
14. Também garanta que “Apply restriction policy” está desmarcado.
15. Configure o “Impersonate Level” para “Anonymous”
16. O último passo será garantir que o usuário que roda o Application Pool poderá utilizar o seu componente. Para isso, em COM+ Application –> <Nome_da_sua_aplicacao> -> Roles -> CreateOwner –> Users você deverá adicionar o usuário do IIS (em geral IUSR) ou o grupo IIS_USRS (para o IIS 7.X/8).
17. Também garanta que a pasta onde está instalado o componente esteja com permissões NTFS que permitam ao usuário do Application Pool possa ler o arquivo do componente. Em geral é suficiente adicionar a permissão de Execução nesta pasta para o grupo IIS_USRS.

Agora basta testar a sua aplicação. Configure o Application Pool para rodar em modo 64bits e faça o teste: a aplicação, mesmo usando componentes antigos escritos em VB6 deverá executar sem problemas.

Até a próxima!

PT

Olá pessoal!

Esse é só um post daqueles que a gente escreve para dizer que está fazendo uma faxina na casa. Aproveitando a inspiração de ontem,  acabei fazendo uns updates nos posts antigos sobre ARR (pouca coisa, somente umas referências atualizadas e algumas informações adicionais para deixar o conteúdo mais claro).

Também devo iniciar uma série de posts sobre assuntos diversos, boa parte deles com foco em problemas que ocorrem durante a migração de aplicações de IIS5/6 (32bits) para IIS 7.x/8.

A gente se vê em breve!

[]s
PT