Faculdade ou Certificação???

"Uma geração vai, e outra geração vem; mas a terra para sempre permanece.

Nasce o sol, e o sol se põe, e apressa-se e volta ao seu lugar de onde nasceu.

O vento vai para o sul, e faz o seu giro para o norte; continuamente vai girando o vento, e volta fazendo os seus circuitos.

Todos os rios vão para o mar, e contudo o mar não se enche; ao lugar para onde os rios vão, para ali tornam eles a correr.

Todas as coisas são trabalhosas; o homem não o pode exprimir; os olhos não se fartam de ver, nem os ouvidos se enchem de ouvir.

O que foi, isso é o que há de ser; e o que se fez, isso se fará; de modo que nada há de novo debaixo do sol."

Em tese, Salomão disse isso há mais ou menos 2500 anos, e consta no livro de Eclesiastes 1 - 4:9. Na verdade, a data não importa. Nem o autor. É uma daquelas tipicas citações em que o conteúdo importa mais do que o autor.

Não sou dessa época (se fosse, até que estaria bem conservado), embora algumas vezes me sinta mais velho do que realmente sou.

É impressionante, mas questionamentos que existiam há 22 anos - quando iniciei minha carreira em TI -, e que já foram sistematicamente despidos, insistem em existir.

Mesmo com a informação disponível literalmente na palma das mãos e uma facilidade que sequer tenha sido imaginada pela maioria de nossa geração anterior.

Os dois leitores assíduos de minhas publicações podem se perguntar: "Porque essa introdução?"

A resposta é bem simples.

No decorrer desse ano interagi com centenas de pessoas através de minhas publicações, aulas e eventos. Estudantes de diversos cursos e segmentos e profissionais já atuantes em suas respectivas áreas. 

Muitos levantaram excelentes questões técnicas, algumas das quais geraram publicações incríveis no blog MCSE Brasil e que foram inteiramente replicadas no LinkedIn.

Mas uma questão que insiste em existir, de forma resumida, mas mantendo o contexto é: Faculdade ou Certificação?

De tanto responder a essa questão, através de meu sempre deficiente ponto de vista, consegui concatenar as idéias e traçar paralelos que me ajudam a respondê-la de forma mais eficaz.

No tempo de nossos pais, a maioria dos brasileiros não possuíam o segundo grau completo.  Não fui em busca da informação, mas algo me diz que seja assim ainda hoje. Ainda assim, os bons cursos profissionalizantes que existiam lhes garantia empregos cuja remuneração lhes permitia viver e sustentar suas famílias com dignidade e algum conforto.

Nessa mesma época, quem possuía terceiro grau completo - o famoso "nível superior" - possuía "vida de rei". Eram majoritariamente muito bem remunerados, tiveram carreiras ascendentes, criaram empresas das quais algumas se tornaram verdadeiros impérios, enfim ... Ser graduado era um baita diferencial.

Muitos desses são profissionais ou empreendedores influentes e renomados atualmente.

O tempo passou, e alguns anos depois, somente uma graduação já não era garantia de tanto sucesso profissional. Conhecer a língua inglesa já fazia alguma diferença.

Ser graduado e falar inglês era tudo de bom na época.

E novamente quem possuía esses requisitos, se dava bem no mercado de trabalho. Notem que falo de um tempo onde a oferta de emprego era abundante. Lembro de meu pai nos contando que a industria em que ele trabalhava (Santista) contratava religiosamente duas vezes por semana!!!

Mas o tempo não deixou de passar ... Com o avanço da tecnologia e o aumento da demanda por profissionais "mais antenados", dominar ou ao menos entender um pouco disso era muito bem visto pelo mercado de trabalho.

E todo esse avanço, criou por fim a categoria de profissionais que muitos de nós atuamos ainda hoje: T.I.

Com a maior oferta de produtos e serviços relacionados a esse segmento, os mais diversos fabricantes começaram a criar métodos para atestar o conhecimento dos profissionais em suas respectivas tecnologias. E com isso nasceram os cursos e exames de certificação, cujo proposito era atestar que o fulano era realmente capaz de atuar com seus produtos.

Entre os diferenciais mencionados pelos fabricantes, estava o fato de o profissional ser oficialmente reconhecido pelo fabricante e a certificação obtida ser válida em qualquer parte do mundo. Imagina você poder sair de seu país e ir para qualquer outro sem a necessidade de se submeter a sub-empregos? Era realmente tentador poder trabalhar em qualquer parte do planeta, dentro de sua área de atuação.

Assim, o mercado de trabalho brasileiro passou a valorizar profissionais certificados.

Minha primeira certificação oficial foi no Windows 2000, embora eu já tivesse feito todos os cursos de Windows NT e muitos de Novell Netware.

Jovem, certificado, com salário bem superior aos demais, múltiplas fontes de renda em função dos constantes freelas que apareciam, com o nível de empregabilidade lá em cima ... era bem interessante.

Fazer uma faculdade? Naquele momento nem pensar!!!

E isso permaneceu por algum tempo, até que criaram a necessidade de profissionais graduados e certificados. Percebendo isso, tive que correr atrás e me graduei.

Com 10 anos de experiencia em diversas consultorias e um nível de conhecimento bem acima da média, lá estava eu humildemente buscando meu diploma e adquirir conhecimentos que eu não possuía na época.

Mas naquela época, ser graduado e certificado deixou de ser diferencial. Se tornou pré-requisito para manter um bom nível de empregabilidade. O domínio da língua inglesa se tornou pré-requisito para muitas empresas e atualmente, vejo muitas vagas exigindo profissionais bilíngues. Espanhol está se tornando (ou já se tornou) pré-requisito.

Mas é só isso? Não!!!

Tenho visto algumas vagas anunciadas com a observação: "Desejável pós-graduação ou MBA".

Ou seja, o que se tornará pré-requisito num futuro muito próximo já está sendo anunciado. As cartas já estão na mesa e atender a esses pre-requisitos só serve para nos mantermos no jogo, mas dentro da média. Isso já não é mais diferencial.

Em tese, os mais preparados se destacarão e profissionalmente sobreviverão às mudanças impostas pelo tempo.

Por outro lado, para se destacar, é necessário fazer aquilo que poucos fazem. Possuir aquilo que poucos possuem.

Logo, entendo que não cabe mais a dúvida que dá título a essa postagem.

Minha recomendação é: Façam tudo o que puder, da melhor forma possível.

O que percebo como diferencial atualmente?

Não estou apto a falar de segmentos das quais não atuo (Skin in the game, sempre!!!), mas para profissionais de TI, noto carência de visão empresarial, corporativa. Sair um pouco daquele mundo de bits e bytes, manja?

À muitos, falta o entendimento de que a TI serve fundamentalmente para apoiar linhas de negócios, e que no final das contas, ao dono de uma metalúrgica (é só um exemplo) interessa mais a quantidade de peças que ele pode produzir no final do dia do que o quão sofisticado é seu ambiente tecnológico.

Noto desconhecimento de normas, procedimentos, boas práticas e regulamentações que impactam diretamente nossa área. 

Me pergunto quantos profissionais de TI realmente estudaram e entendem o quanto violar o disposto no Marco Civil da Internet pode ser prejudicial à sua empresa? 

Quantos já estudaram a LGPD? Quantos já fizeram, ainda que de forma modesta, uma análise de riscos relacionados ao ambiente tecnológico em que atuam?

Sabem como otimizar sua infra-estrutura e torná-la segura utilizando inicialmente somente os recursos nativos do sistema operacional em que atuam?

Conseguimos automatizar rotinas?

Sabemos estimar o custo da nossa infra-estrutura? E a depreciação dela ano a ano?

Pois é  ... esse conhecimento pode nos dar o diferencial necessário para nos fazer sair da média, nos destacar.

Talvez vale a pena refletir.

Abraço

AD CS - Parte II

Fim de ano chegando e junto com ele aqueles necessários momentos de reflexão, revisão de metas e planejamento para 2019.

Poxa, pelo menos pra mim, não dá pra reclamar desse ano. Profissionalmente me foi muito bom!!! Projetos novos iniciados e em andamento, meus artigos aqui e no blog MCSE Brasil tiveram uma aceitação bem acima do esperado, conheci e convivi com profissionais extremamente competentes, aulas enriquecedoras ... trabalhei bastante e talvez por isso, por mais esse ano a sorte me sorriu.

E com tanta correria, ainda consigo escrever algo de vez em quando. 

Não imaginei que isso aconteceria, mas já estou sendo cobrado por novas publicações. E por incrível que pareça, esse tipo de cobrança é legal!!!

Continuando o tema que iniciei mês passado (caso não tenham lido, sugiro que o façam clicando aqui), no artigo desse mês tratarei sobre gerenciamento de autoridades certificadoras.

Então vamos lá ...

A importância que uma autoridade de certificação possui exige grande cuidado em sua configuração e administração. Um erro bobo pode nos custar muito ...

A garantia de uma PKI segura envolve por exemplo, atribuir a usuários e grupos a permissão adequada para executar tarefas administrativas, ou ainda configurar as opções de registro e monitoramento para uma autoridade de certificação pela necessidade de registrar, armazenar e rastrear todas as tarefas e atividades importantes que nela tenham sido executadas.

Através da console da Autoridade de Certificação pode-se configurar as opções de gerenciamento de CA mais comuns. Somente as mais comuns ...

Entretanto, nem todas tarefas podem ser executadas com excelência através dessa console. Aí, contamos com nosso querido PowerShell e com a ferramenta de linha de comando certutil para gerenciar várias opções avançadas de CA e executar tarefas que não estão disponíveis no console gráfico.

No Windows Server 2016, os módulos ADCSDeployment e ADCSAdministration do Windows PowerShell estão disponíveis para implantar e administrar CAs.

Para utiliza-los, basta instalar os binários do AD CS,e após isso importar os módulos para uso no Windows PowerShell através dos seguintes comandos:

Import-Module ADCSDeployment

Import-Module ADCSAdministration

Para consultar todos os cmdlets disponíveis para implantação e administração da autoridade de certificação, podemos utilizar o seguinte comando no Windows PowerShell:

Get-Command –Module ADCS*

Abaixo a descrição de alguns (somente alguns) cmdlets para administração de CA:

- Add-CATemplate - Adiciona um modelo de certificado à autoridade de certificação.

- Add-CACrlDistributionPoint - Adiciona um Identificador Uniforme de Recursos (URI) do CDP, no qual a autoridade de certificação publica revogações de certificação.

- Add-CAAuthorityInformationAccess - Configura os URIs AIA ou OCSP em uma autoridade de certificação.

- Get-CATemplate - Obtém a lista de modelos definidos na CA para emissão de certificados.

- Get-CACrlDistributionPoint - Obtém todos os locais definidos na extensão CDP das propriedades da autoridade de certificação.

- Get-CAAuthorityInformationAccess - Obtém as informações de URI AIA e OCSP definidas na extensão AIA das propriedades da autoridade de certificação.

- Remove-CATemplate - Remove os modelos da CA que foram configurados para emissão de certificados.

- Remove-CACrlDistributionPoint - Remove o URI do CDP da CA.

- Remove-CAAuthorityInformationAccess - Remove URIs AIA ou OCSP do conjunto de extensões AIA na CA.

Uma lista bem extensa de cmdlets para implantação de CAs pode ser obtida em http://aka.ms/Giih2g.

Para conhecer mais cmdlets utilizados para administração de CAs, acesse http://aka.ms/Dekm5i.

Usando o CERTUTIL para administrar uma autoridade de certificação

Embora o PowerShell forneça grande quantidade de cmdlets que podem ser utilizados para o gerenciamento do AD CS, ele ainda não é completo.

Assim, para gerenciamento completo do AD CS via linha de comando, utilizamos o certutil que por sua vez é instalado como parte AD CS.

Através dele, podemos obter informações detalhadas de configuração da autoridade de certificação, configurar o AD CS, fazer backup e restaurar componentes da autoridade de certificação e verificar certificados, pares de chaves e cadeias de certificados.

Notem que para tarefas comuns de configuração e gerenciamento da CA, não é necessário usar o certutil.

Já para tarefas mais avançadas, o certutil pode ser sua única opção.

Para exemplo meramente educativo, se quiser revisar todas as definições de configuração da autoridade de certificação, poderá fazer isso através dos seguintes comandos:

Certutil –dump

Certutil –getreg

Certutil –getreg

Este comando fornece muito mais informações sobre sua configuração de CA. Isso inclui o tipo de informação que é definido pelo arquivo CAPolicy.inf ou após a instalação executando scripts de pós-configuração.

A verdade, é que ainda não dá pra acessar todas as informações usando apenas o console da Autoridade de Certificação, o que cá pra nós é uma pena, né?

Gerenciando PKI com Diretiva de Grupo

Depois que sua PKI estiver implantada,  é preciso utilizar GPO (Política de Grupos) para automatizar a distribuição de certificados digitais e definir as opções de configuração.

Diretivas de Grupo podem ser utilizadas para as seguintes áreas relacionadas ao AD CS:

Roaming Credential- Isso permite que os usuários mantenham seus certificados com o AD DS em vários computadores. Isso também elimina o requisito de gerenciar vários certificados de cliente e chaves privadas em várias estações de trabalho do cliente para um único usuário. Pois é ... agiliza um lado importante para os administradores.

Registro automático de certificados - Isso simplifica a emissão de certificados, permitindo que os computadores clientes solicitem e renovem certificados automaticamente. O registro automático requer uma autoridade de certificação corporativa e o uso da Diretiva de Grupo para habilitar os computadores e usuários em seu ambiente do AD DS para o registro automático. Particularmente, para obter maior controle, prefiro não utilizar essa opção.

Validação do caminho de certificado - Com a validação de caminho de certificado, você pode gerenciar certificados que são usados para assinatura de código, implantando certificados de autoridade de certificação subordinada, bloqueando certificados que não são confiáveis e definindo configurações de recuperação para certificados e CRLs.

Distribuição de certificados - Normalmente, você usa a Diretiva de Grupo para a distribuição automatizada de certificados ou para especificar configurações relacionadas ao registro.

Configurando a segurança da autoridade de certificação

Para gerenciar e configurar a segurança na CA, pode-se utilizar a guia “Segurança” para exibir as propriedades de uma autoridade de certificação no console da Autoridade de Certificação. Nela, pode-se definir as seguintes permissões de segurança:

Ler - As entidades que recebem essa permissão podem localizar essa autoridade de certificação no AD DS ou acessá-la usando o console da Web ou os serviços da Web se você implantou a autoridade de certificação como uma autoridade autônoma.

Emitir e gerenciar certificados - As entidades que recebem essa permissão podem aprovar ou negar solicitações de certificado que estejam em um estado pendente. Eles também podem revogar um certificado emitido, especificar um motivo de revogação e realizar uma revogação. As entidades de segurança também podem ler todos os certificados emitidos e exportá-los para arquivos.

Gerenciar CA - As entidades que recebem essa permissão podem gerenciar e configurar todas as opções na CA. Por padrão, eles não podem gerenciar certificados, mas podem conceder a si mesmos o direito.

Solicitar certificados - As entidades de segurança que recebem essa permissão podem executar solicitações de certificado para a autoridade de certificação. No entanto, isso não significa que eles possam se inscrever em um certificado. O modelo de certificado controla as permissões de inscrição.

Além de definir permissões de segurança na ACL (lista de controle de acesso) do objeto CA, você também pode usar a guia "Gerenciadores de certificados" na janela de propriedades da autoridade de certificação para restringir outras entidades de segurança que contenham a permissão “Emitir e Gerenciar certificados”.

Por exemplo, se você deseja delegar a permissão “Emitir e Gerenciar Certificados” para um modelo específico, você deve:

1 - Conceder à entidade de segurança o direito “Emitir e Gerenciar Certificados” na guia Segurança das propriedades da autoridade de certificação.

2 - Na guia “Gerenciadores de certificados” das propriedades da autoridade de certificação, selecione “Restringir gerenciadores de certificados”.

3 - Selecione a entidade de segurança que você deseja restringir e, em seguida, modifique os modelos que deseja que a entidade de segurança gerencie. Usando a guia “Gerenciadores de Certificados” das propriedades da autoridade de certificação, você pode delegar direitos a um modelo de certificado específico sem atribuir à entidade de segurança o direito de emitir e gerenciar certificados em todos os modelos publicados na autoridade de certificação.

Funções de segurança para a administração da autoridade de certificação

A administração baseada em função no AD CS fornece a capacidade de delegar as permissões predefinidas disponíveis em uma CA a grupos criados no AD DS para CAs corporativas ou no banco de dados local do Security Account Manager para CAs independentes que não sejam membros do domínio.

Embora possamos atribuir permissões de autoridade de certificação a um objeto de usuário específico, como prática recomendada, recomendo que as permissões sejam delegadas a grupos.

A delegação a um grupo reduz o esforço administrativo e fornece transparência sobre quais permissões foram atribuídas. Cada função criada só deve ser capaz de executar uma tarefa predeterminada ou uma série de tarefas atribuídas a um grupo de segurança.

A tabela a seguir mostra os detalhes das funções e grupos que normalmente estão envolvidos na administração baseada em função de uma implantação do AD CS.

OBS: O grupo Administradores local em uma autoridade de certificação tem as permissões para “Gerenciar CA” e “Emitir e Gerenciar Certificados” por padrão. Em CAs corporativas, essas permissões também se estendem aos grupos Admins. Do Domínio e Administradores de Empresa. Em CAs autônomas que ingressaram em um domínio, os membros do grupo Admins. Do Domínio também têm direitos administrativos completos na CA.

 

Criar funções de segurança para administração do AD CS

Por padrão, o AD CS não cria automaticamente as funções e os grupos listados na tabela acima no ato da instalação.

As funções listadas acima são representativas de uma implantação típica do AD CS em que se deseja a administração baseada em funções.

A administração baseada em função pode ser exclusiva para cada implantação do AD CS. Portanto, planeje e crie apenas as funções necessárias para sua organização.

Para tornar o entendimento mais fácil, vamos analisar o cenário a seguir e pensar numa possibilidade de configuração para atender aos requisitos.

Cenário: Você é o administrador do AD CS da empresa XPTO. Você implantou uma autoridade de certificação raiz independente associada ao domínio e duas autoridades de certificação subordinadas na empresa. Uma autoridade de certificação subordinada emitirá certificados de usuário e a outra autoridade de certificação subordinada emitirá certificados de computador. Você deseja configurar a administração baseada em funções para que tenha as seguintes funções:

1- Uma função com direitos Gerenciar CA e Emitir e gerenciar certificados em todas as CAs na hierarquia.

2- Uma função com os direitos Gerenciar CA e Emitir e Gerenciar Certificados somente em CAs subordinadas.

3- Uma função com os direitos Issue e Manage Certificates para o modelo de certificado do usuário.

4- Uma função com os direitos Issue e Manage Certificates para o modelo de certificado de computador.

Notem que embora seja um cenário hipotético, não é difícil encontrar cenário parecido na vida real.

Para atender a esses requisitos, podemos configurar a administração do AD CS baseada em função seguindo as seguintes etapas:

1. Criar um grupo de segurança no AD que se alinhe a cada função que desejamos atribuir no AD CS. Com base nos requisitos acima, criaríamos os seguintes grupos para cada função exigida:

- Administradores de PKI

- Administradores de CA subordinados

- Gerentes de certificado de usuário

- Gerentes de certificado de computador

2. Em cada CA da hierarquia, atribuímos ao grupo Administradores de PKI as permissões "Gerenciar CA" e "Emitir e Gerenciar Certificados" no console da Autoridade de Certificação.

3. Em cada CA subordinada, atribuímos ao grupo Administradores de CA subordinados as permissões "Gerenciar CA" e "Emitir e Gerenciar Certificado"s no console da Autoridade de Certificação.

4. Na autoridade de certificação subordinada que emitirá certificados de usuário, atribuímos ao grupo Gerenciadores de Certificados de Usuário a permissão "Emitir e Gerenciar Certificados" no console da Autoridade de Certificação. Na guia Gerenciadores de Certificados das propriedades da autoridade de certificação, restringimos o grupo Gerenciadores de Certificados do Usuário ao modelo de certificado do Usuário.

5. Na autoridade de certificação subordinada que emitirá certificados de computador, atribua ao grupo Administradores de Certificados de Computador a permissão "Emitir e Gerenciar Certificados" no console da Autoridade de Certificação. Na guia Gerenciadores de Certificados das propriedades da autoridade de certificação, você restringe o grupo Gerenciadores de Certificados de Computador ao modelo de certificado do Computador.

Configurando locais de CDPs e AIA

Para termos um ambiente de PKI que funcione corretamente, devemos configurar as extensões de certificado AIA e CDP para cada CA.

Isso garantirá que o ambiente de PKI encontre falhas mínimas quando os aplicativos ou serviços tentarem validar a cadeia de confiança ou o status de revogação de um certificado.

Basicamente, a função dos endereços AIA e CDP é:

- Os endereços AIA são as URLs que informam ao verificador de certificado a localização do certificado de autoridade de certificação. Os endereços AIA são necessários para que os aplicativos e serviços que usam um certificado possam estabelecer a validade da CA e de uma cadeia confiável para uma CA na qual o verificador confie explicitamente, se não confiar explicitamente na CA que emitiu o certificado diretamente.

- Os endereços CDP são os URLs que informam ao verificador de certificado a localização da CRL que a autoridade de certificação mantém. Os endereços CDP são necessários para que os aplicativos e serviços que usam um certificado possam estabelecer o status de revogação de um certificado. Cada certificado que você emite de sua CA contém os endereços AIA e CDP que configurado na CA no momento em que a CA emitiu o certificado. Todas as extensões AIA e CDP devem conter pelo menos uma URL acessível, ou o verificador pode assumir que o certificado não é válido, tornando-o inutilizável.

OBS: As URLs da AIA e CDP podem ser HTTP, FTP, LDAP (Lightweight Directory Access Protocol) ou endereços FILE.

Considerações sobre publicação de AIA e CDP

Se você estiver usando uma autoridade de certificação corporativa, os valores de extensão AIA e CDP serão configurados automaticamente para que o certificado de autoridade de certificação e a CRL estejam disponíveis na partição de configuração do AD DS que replica todos os controladores de domínio da floresta do AD DS.

No entanto, se implantarmos uma autoridade de certificação offline ou autônoma ou usar certificados que uma autoridade de certificação de fora do seu ambiente do AD, você deve considerar essas autoridades de certificação offline e autônomas não se integram ao AD DS. Logo, precisaremos garantir a acessibilidade de AIA e CDP manualmente publicando o certificado de autoridade de certificação offline ou independente e a CRL para AD DS usando o comando certutil.

Isso oferece o mesmo benefício que uma CA corporativa e torna as URLs da AIA e CDP acessíveis para clientes do AD em toda a floresta, mas devemos publicar manualmente as informações e configurar manualmente as extensões de CA com a URL do LDAP correta.

OBS: Além de configurar os pontos de publicação CDP e AIA, devemos nos certificar de que a CRL seja válida. Uma CA online renovará automaticamente a CRL periodicamente, mas uma CA offline não. Se a CRL da CA off-line expirar, as verificações de revogação falharão. Para evitar falhas, uma boa alternativa talvez seja configurar um período longo de validade para a CRL off-line, definir um lembrete para ativar essa autoridade de certificação e emitir uma nova CRL antes que a antiga expire.

Clientes que não são membros do domínio

Os clientes internos que não são membros do domínio não poderão acessar as URLs LDAP AIA ou CDP, que fazem referência à partição de configuração do AD DS.

Nesse caso, devemos disponibilizar o certificado de autoridade de certificação e a CRL em um servidor da Web acessível internamente e configurar uma URL HTTP válida para as extensões AIA e CDP.

Também podemos utilizar URLs FTP ou mesmo FILE, embora o recomendado seja usar apenas HTTP para garantirmos a máxima interoperabilidade e flexibilidade.

Importante salientar que clientes externos à sua rede, incluindo clientes de domínio em uma rede externa, também não poderão acessar as URLs AIA ou CDP, que fazem referência ao seu ambiente interno do AD DS. Além disso, eles podem não conseguir acessar URLs HTTP internos sem uma conexão VPN ou DirectAccess.

Se os clientes externos precisarem validar certificados emitidos por sua CA interna, talvez seja necessário publicar externamente as URLs HTTP internas usando o serviço Proxy de Aplicativo Web do Windows Server 2016 da função Acesso Remoto.

Outra alternativa é utilizar uma solução de proxy reverso de terceiros. Se as URLs internas e externas não corresponderem, você precisará configurar uma URL HTTP AIA / CDP adicional na CA.

Os clientes externos que não pertencem ao seu domínio do AD DS precisarão ter seu certificado de CA importado manualmente para os armazenamentos das Autoridades de Certificação Raiz Confiáveis ou das Autoridades de Certificação Intermediárias. Isso pode ser necessário, pois o cliente externo não confiará em outros certificados que sua CA interna emitiu.

OBS 01: A ordem de listagem das URLs CDP e AIA é importante porque o mecanismo de certificação verifica os URLs sequencialmente. Se os seus certificados são usados principalmente internamente em um ambiente do AD DS, coloque o URL do LDAP primeiro na lista. Solicite outros URLs com base na probabilidade de o URL estar disponível para clientes internos ou externos.

OBS 02: Se desativar as URLs AIA ou CDP nos certificados emitidos, removendo-as da autoridade de certificação, verifique se todos os certificados que contêm uma URL descomissionada expiraram, foram revogados ou contêm uma URL adicional que ainda seja válida e acessível.

Um outro utilitário extremamente útil para atestarmos o funcionamento e saúde de uma PKI é o PKIVIEW. Recomendo muito que o conheçam.

Maiores informações sobre o PKIVIEW pode ser obtida clicando aqui.

Espero que tenham gostado tanto do tema quanto da abordagem de mais esse artigo. Se gostaram, compartilhem a nos ajude a difundir o conhecimento.

Caso queiram que eu aborde alguém outro tema relacionado à serviços de infra Microsoft, me escrevam e emitam vossas sugestões.

Abraço e até a próxima!!!

Um pouquinho sobre ADCS

Quando um amigo do MBA me pediu para falar sobre ADCS, lembro-me de ter lhe respondido que esse seria tema para um livro. É realmente muita coisa e deveras difícil explorar todos os aspectos em artigos mensais.

Mas juro que ao menos tentarei. Entretanto, para ficar mais fácil para quem escreve (nesse caso, eu) e para quem ler, dividirei o conteúdo em algumas partes.

Uma infra-estrutura de chave pública (PKI) é composta por diversos componentes que juntos acrescentam uma camada de proteção às comunicações e transações diversas. Essa proteção ocorre através da distribuição, validação e gerenciamento de certificados digitais.

Em ambientes Microsoft, essa infra-estrutura é criada através da instalação e configuração do ADCS (Active Directory Certificate Services), que  pode ser instalado e configurado como uma autoridade de certificação raiz ou uma autoridade de certificação subordinada em sua organização. 

Em uma infra-estrutura de PKI, a primeira autoridade de certificação será uma autoridade de certificação raiz (Root CA) e a partir daí, pode-se configurar autoridade subordinadas para aplicar restrições de diretiva e emitir certificados. 

O que é o AD CS?

O ADCS é figurinha carimbada no mundo Microsoft, e foi disponibilizado pela primeira vez no Windows 2000 (se não me engano). Esse serviço permite implementar a PKI de modo relativamente fácil, mas não é tão intuitivo assim. É importante entendermos bem os conceitos envolvidos para sermos bem sucedidos em nossas implementações.

Para iniciar, vamos tentar definir uma PKI. De forma simplista, podemos definir uma PKI como a combinação de software, tecnologias de criptografia, processos e serviços que permitem a proteção de comunicações e transações diversas e depende da troca de certificados digitais entre usuários autenticados e recursos confiáveis. 

Visa atender aos seguintes requisitos de segurança:

Confidencialidade – Esse requisito é atendido pelo uso de criptografia de dados armazenados e transmitidos. Por exemplo, pode-se utilizar o EFS (sistema de arquivos com criptografia ativada para PKI) para criptografar e proteger dados, bem como manter a confidencialidade de dados transmitidos em redes públicas utilizando IPsec (Internet Protocol security) habilitado para PKI.

Integridade – Em dados assinados digitalmente ocorre a identificação de alteração de durante a transmissão. Para facilitar o entendimento, podemos tomar por exemplo uma mensagem de e-mail que tenha sido assinada digitalmente. Nesse caso há garantia de que o conteúdo da mensagem não foi modificado durante a trânsito entre remetente e destinatário. 

Autenticidade – Esse requisito é atendido ao considerar que os dados de autenticação são submetidos a algoritmos hash, como por exemplo o Secure Hash Algorithm 2 (SHA-2), para produzir um resumo de mensagens assinadas digitalmente usando a chave privada do remetente do certificado, que prova que o remetente realmente produziu o resumo da mensagem.

Não-repúdio - Quando os dados são assinados digitalmente com o certificado de um autor, a assinatura digital fornece provas da integridade dos dados assinados, bem como  prova a origem dos dados. 

Disponibilidade – Pode ser atingida através da instalação de várias CAs em sua infra-estrutura de PKI para emissão de certificados. Em caso de falha de uma autoridade de certificação, as outras podem prosseguir coma emissão de certificados. 

Através do Active Directory Certificate Services (AD CS) é possível implantar todos os componentes necessários em uma PKI. Embora trabalhem em conjunto, cada componente é responsável por uma parte específica da infraestrutura.

Entre esse componentes temos:

Autoridade de Certificação (Certification Authority) – Responsável pela emissão e revogação de certificados, bem como publicar informações de acesso a informações de autoridade (AIA). Pode-se ter uma ou mais CAs em uma rede, mas somente uma autoridade de certificação ocupará o ponto mais alto da hierarquia da autoridade de certificação, denominada “CA Raiz”. Também é possível possuir mais de uma hierarquia de CA, e consequentemente mais de uma CA raiz. 

Depois que uma autoridade de certificação raiz emite um certificado para si mesmo, as autoridades de certificação subordinadas que são inferiores na hierarquia recebem certificados da autoridade de certificação raiz. 

Inscrição na Web da Autoridade de Certificação (Certification Authority Web Enrollment) - Esse componente fornece um método para emitir e renovar certificados para usuários, computadores e dispositivos que não estão associados ao domínio, não estejam conectados diretamente à rede ou para usuários de sistemas operacionais que não sejamWindows. 

Respondente Online (Online Responder) - Esse componente pode ser utilizado para configurar e gerenciar a validação e revisão de revogação do OCSP (Online Certificate Status Protocol). Um Respondente Online decodifica solicitações de status de revogação para certificados específicos, avalia o status desses certificados e retorna uma resposta assinada que contém as informações de status do certificado solicitadas. 

Os dados de revogação de certificado podem vir de uma autoridade de certificação em um computador que esteja executando o Windows Server 2003 ou posterior. 

Serviço de Registro de Dispositivo de Rede (Network Device Enrollment Service) - Através desse componente, roteadores, comutadores e outros dispositivos de rede podem obter certificados emitidos pelo AD CS. 

Serviço Web de Registro de Certificado (Certificate Enrollment Web Service) – Disponibilizado no Windows 2008 R2, esse componente funciona como um cliente proxy entre um computador executando o Windows 7 ou posterior e a autoridade de certificação e exige que a floresta do Active Directory esteja, pelo menos, no nível funcional do Windows Server 2008 R2. 

Ele permite que usuários, computadores ou aplicativos se conectem a uma CA usando os serviços da Web para solicitar, renovar e instalar certificados emitidos, bem como recuperar listas de revogação de certificado (CRLs).

Serviço Web da Política de Inscrição de Certificados (Certificate Enrollment Policy Web Service) - Este componente permite que os usuários obtenham informações de política de inscrição de certificado. Combinado com o CES, permite o registro de certificado com base em políticas quando o computador cliente não é membro de um domínio ou quando um membro do domínio não está conectado ao domínio. 

Importante salientar que todos os serviços mencionados podem ser instalados na versão completa do Windows Server (Desktop Experience) ou no Server Core. Entretanto, o AD CS não pode ser executado no Nano Server.

Opções para implementar hierarquias de CA

Para implementação do AD CS, é fundamental projetar sua hierarquia de CA, determinando o design principal da PKI interna e determinar o objetivo de cada CA na hierarquia, considerando que cada hierarquia de CA geralmente inclui duas ou mais CAs. 

Geralmente, a segunda autoridade de certificação e todas as outras depois disso são implantadas com um propósito específico. Apenas a CA raiz é obrigatória.

Não é obrigatório possuir uma hierarquia de CA de vários níveis para utilizar PKI e certificados. Em ambientes menores e menos complexos, você pode ter uma hierarquia de CA com apenas uma CA implantada. Essa CA geralmente é implantada como uma autoridade de certificação raiz corporativa (Enterprise Root CA). 

Via de regra não é recomendado a criação de uma hierarquia de CA com mais que três níveis, a menos que esteja em um ambiente extremamente complexo e distribuído. 

O mais comum são hierarquias de dois níveis, com a autoridade de certificação raiz no nível superior e a autoridade de certificação subordinada no segundo nível. Simples assim!!!

Um ponto recomendado e de certa forma polêmico refere-se à recomendação de se manter a autoridade de certificação raiz offline (desligada) enquanto a autoridade de certificação subordinada emite e gerencia certificados para todos os clientes. 
Ocorre que pessoalmente, em mais de 20 anos de carreira, nunca encontrei (ou ao menos não me recordo) um ambiente onde essa recomendação fosse seguida. 

Normalmente, ela é mantida ligada para que receba patches de segurança e atualizações de anti-vírus, por exemplo.

Em geral, as hierarquias da CA se enquadram em uma das seguintes categorias: 

Hierarquias da CA com uma CA de política - CAs de política são autoridades de certificação subordinadas que estão diretamente abaixo da autoridade de certificação raiz. Você usa CAs de diretiva para emitir certificados à autoridades de certificação subordinadas que estão diretamente abaixo da autoridade de certificação da diretiva na hierarquia. A função de uma CA de política é descrever as políticas e procedimentos que uma organização implementa para proteger sua PKI, os processos que validam a identidade dos titulares de certificados e os processos que impõe os procedimentos que gerenciam certificados. Uma autoridade de certificação de política só emite certificados para outras autoridades de certificação, que recebem esses certificados e devem manter e impor as políticas definidas pela CA. O uso de CAs de política não é obrigatório, a menos que diferentes divisões, setores ou locais de sua organização exijam políticas e procedimentos de emissão diferentes. No entanto, se sua empresa exigir diretivas e procedimentos de emissão distintos, você deverá adicionar autoridades de certificação de diretivas à hierarquia para definir cada diretiva exclusiva. Por exemplo, uma organização pode implementar uma CA de política para todos os certificados que ela emite internamente para funcionários e outra para todos os certificados emitidos para terceiros. 

Hierarquias de CA com confiança de certificação cruzada - Nesse cenário, duas hierarquias de autoridade de certificação independentes interoperam quando uma autoridade de certificação de uma hierarquia emite um certificado de autoridade de certificação cruzada para uma autoridade de certificação de outra hierarquia. Isso estabelece confiança mútua entre diferentes hierarquias de autoridade de certificação. 

CAs com uma hierarquia de dois níveis - Em uma hierarquia de duas camadas, há uma CA raiz e pelo menos uma autoridade de certificação subordinada. Nesse cenário, a autoridade de certificação subordinada é responsável pelas diretivas e pela emissão de certificados para os solicitantes.

CAs Autonomas X CAs Corporativas

Basicamente pode-se implantar dois tipos de CAs: CAs autônomas e CAs corporativas. 

Isso não se refere à hierarquia, e sim sobre armazenamento de funcionalidades e configuração.

O que difere ambas é a integração e a dependência do Active Directory. 

Uma autoridade de certificação autônoma pode funcionar sem o Active Directory e não depende dele de nenhuma maneira. 

Uma CA corporativa exige o Active Directory e fornece vários benefícios, incluindo o registro automático. 

O recurso de registro automático permite que usuários e dispositivos membros do domínio se inscrevam automaticamente em certificados, se você tiver habilitado a inscrição automática de certificados por meio da Diretiva de Grupo. 

A tabela a seguir detalha as diferenças mais significativas entre autoridades de certificação independentes e corporativas.

OBS: Geralmente implanta-se a CA Root, que é a primeira autoridade de certificação implantada, como uma autoridade de certificação autônoma, que em tese é colocada offline após emitir um certificado para si mesma e para uma autoridade de certificação subordinada.

Considerações para implantar uma autoridade de certificação raiz

Conforme mencionado acima, antes de implantar uma autoridade de certificação raiz, é necessário criterioso planejamento para decidir se implantará uma CA raiz off-line, se implantará uma autoridade de certificação raiz autônoma ou uma autoridade de certificação raiz corporativa. 

Normalmente, se optar pela implantação de uma hierarquia de CA de camada única, é mais comum escolher uma autoridade de certificação raiz corporativa. 

Se optar por implantar uma hierarquia de duas camadas com uma autoridade de certificação subordinada, o cenário mais comum é implantar uma autoridade de certificação raiz autônoma por prover maior segurança à CA raiz.

Um outro ponto importante é que não é possível alterar nomes de computador, nome de domínio ou associações a domínios de computador após implantar uma autoridade de certificação de qualquer tipo nesse computador. Portanto, é importante determinar esses atributos antes de instalar uma CA.

Se você decidir implantar uma autoridade de certificação raiz autônoma off-line, tenha em mente algumas considerações específicas: 

- Antes de emitir um certificado subordinado da autoridade de certificação raiz, forneça pelo menos um ponto de distribuição de lista de revogação de certificado (CDP) e localização AIA que estará disponível à todos os clientes. Isso é necessário pois, por padrão, uma CA raiz autônoma tem o CDP e o AIA armazenados em si. Portanto, quando você tira a CA raiz da rede, uma verificação de revogação falhará porque os locais CDP e AIA estarão indisponíveis. Ao definir esses locais, você deve copiar manualmente as informações de CRL e AIA para esse local. 

- Não defina um período de validade longo demais para CRLs que a autoridade de certificação raiz publica. Talvez um período máximo de um ano seja razoável. Assim, caso opte por manter a Root CA desligada, será necessário liga-la uma vez por ano para publicar uma nova CRL e, em seguida, copiá-la para um local que esteja disponível para os clientes. Se isso não for feito, quando a CRL na CA raiz expirar, as verificações de revogação de todos os certificados falharão. 

- Utilize Diretivas de Grupo (GPO) para publicar o certificado da CA raiz em um armazenamento de CA raiz confiável em todos os servidores e computadores clientes. Você deve fazer isso manualmente caso utilize CA autônoma, ao contrário de uma autoridade de certificação corporativa. Outra possibilidade é publicar o certificado de CA raiz no AD DS utilizando o comando certutil.

Quando utiliza-se uma autoridade de certificação subordinada para emissão de certificados para usuários ou computadores que possuem uma conta no Active Directory, pode-se instalar a autoridade de certificação subordinada como uma autoridade de certificação corporativa (Enterprise CA). 

Em seguida, você pode utilizar os dados das contas de cliente no AD DS para emitir, gerenciar e publicar certificados no AD. 

Para isso é necessário ser membro do grupo Administradores local ou possuir permissões equivalentes e se a CA subordinada for corporativa é necessário ser membro do grupo Domain Admins ou ter permissões equivalentes.

Com a implantação de uma CA subordinada, as seguintes possibilidades se abrem:

Separação de políticas - Você pode emitir certificados para vários fins, como S/MIME (Secure / Multipurpose Internet Mail Extensions), EFS ou acesso remoto por exemplo e possuir políticas de emissão diferentes facilitando a administração.

Divisões organizacionais - Você pode ter políticas diferentes para emitir certificados que dependem da função de uma entidade na organização. Você pode criar autoridades de certificação subordinadas para separar e administrar essas políticas.

Segmentação geográfica – No caso da companhia possuir diversos escritórios (sites) e conectividade de rede limitada entre esses sites, pode-se utilizar CAs subordinadas individuais para essas localidades. 

Balanceamento de carga - Se você usar sua PKI para emitir e gerenciar um grande número de certificados e tiver apenas uma autoridade de certificação, isso poderá resultar em uma carga de rede considerável para essa única autoridade de certificação. O uso de várias CAs subordinadas para emitir o mesmo tipo de certificado permite a divisão de carga de rede entre as CAs. 

Tolerância a falhas – Possuir várias CAs diminui a possibilidade de indisponibilidade do serviço.

O arquivo CAPolicy.inf

A instalação de uma estrutura de PKI exige ou pode exigir, de acordo com cada ambiente e necessidade, a configuração de parâmetros que não estão disponíveis através da instalação padrão.

Para esses casos, utiliza-se u arquivo CAPolicy.inf para implantar uma autoridade de certificação raiz ou subordinada e definir valores e parâmetros durante ou após a instalação. 

Não é mandatório utilizar o arquivo CAPolicy.inf para instalar o AD CS, mas sem ele, as configurações padrões serão aplicadas e na maioria das vezes não suprirá as necessidades em ambientes mais complexos. 

Tal arquivo é dividido em seções e possui uma estrutura bastante simples, descrita da seguinte maneira: 

Sessão => É uma área no arquivo .inf que contém um grupo lógico de chaves. Uma sessão sempre aparecerá entre colchetes [] no arquivo. 

Chave => É o parâmetro que está à esquerda do sinal de igual (=). 

Valor => É o parâmetro que está à direita do sinal de igual (=). 

Abaixo, exemplo simples do arquivo CAPolicy.inf.

Você também pode usar o arquivo CAPolicy.inf ao instalar o AD CS para definir o seguinte: 

Instrução de prática de certificação - Isso descreve as práticas que a CA usa para emitir certificados. Isso inclui os tipos de certificados emitidos, informações sobre emissão, renovação e recuperação de certificados e outros detalhes sobre a configuração da autoridade de certificação. 

Identificador de objeto - Isso identifica um objeto ou atributo específico.

Intervalos de publicação de CRL - Isso define o intervalo entre as publicações para a CRL de base. 

Configurações de renovação da autoridade de certificação - Você pode definir as configurações de renovação da seguinte forma:

- Tamanho da chave => Isso define o comprimento do par de chaves usado durante uma renovação da autoridade de certificação raiz.

- Período de validade do certificado => Isso define o período de validade de um certificado de CA raiz.

- Caminhos CDP e AIA => Isso fornece o caminho para instalações e renovações de CA raiz.

Depois de criar o arquivo CAPolicy.inf, copie-o para a pasta %SystemRoot% do seu servidor (por exemplo, C:\Windows) antes de instalar a função do AD CS ou antes de renovar o certificado da autoridade de certificação.

Nota: O arquivo CAPolicy.inf é processado para instalações e renovações de CA raiz e subordinada.

No próximo artigo, tratarei um pouco sobre administração do AD CS.

Um abraço e até mais!!!