Instalação do Software em Windows
O Software PHC CS Desktop em Windows deve estar corretamente instalado.
Na instalação e manutenção automática, o processo é efetuado sem a intervenção do utilizador. A aplicação verifica se existem alterações às tabelas existentes na base de dados, em caso afirmativo, irá correr a instalação e manutenção apenas para essas mesmas tabelas.
Caso opte pela manutenção personalizada após lida a informação do 1º ecrã, clicar em "Próximo" e no passo "1 de 3" selecionar a opção "Todos";
Clicar em "Próximo"; No passo "2 de 3" clicar todas as opções do ecrã e de seguida em "Próximo";
No passo "3 de 3" é dada a informação relativa à manutenção a ser realizada. Deverá então clicar no botão "Terminar" e avançar para a manutenção.
Em alternativa pode na opção Instalação e Manutenção escolher a opção Atualizar tabela de dicionário de dados para todas as tabelas.
Configuração do SQL
As aplicações PHC necessitam do suporte de um sistema de base de dados. Este, para a PHC, é o Microsoft SQL Server.
Por ser um software que possui características de tratamento de dados, organização e a sua disponibilização, tem a necessidade de usar grandes quantidades de recursos. Por esse motivo, não é aconselhado que o servidor de base dados seja instalado no mesmo local (servidor) que o IIS.
Para além de tudo, a compartimentação de valências é algo muito importante para a gestão correta de sistemas de informações. Na queda de um servidor contendo um serviço exposto na internet, levaria tudo atrás (por exemplo o SQL). É conveniente estarem isolados em máquinas diferentes.
A comunicação entre as aplicações e o SQL é realizado via configuração de DSN (iremos mais à frente ver esta configuração). Devemos garantir os seguintes princípios:
-
Cada Site / app deverá ter um login próprio. Se possível um login de SQL com acessos apenas de Leitura/ escrita.
-
Devem ter password aleatórias com mínimo de 15 Caracteres (letras, números, caracteres especiais e maiúsculas / minúsculas) sendo que estas devem ser renovadas periodicamente.
-
Devemos ter em atenção alguns caracteres que possam interferir no acesso via DSN (Exemplo: “, ‘,@)
-
É possível que seja necessário que, em condições especiais, possa existir partilha de utilizador (appsettings) entre base de dados. Nestes casos, devemos documentar e realizar auditorias de acessos às BDs.
-
Se possível estes acessos devem ser por tempo limitado.
-
Uma boa prática é auditar via Event log os acessos. Podemos para isso criar Filtros no Event Viewer para determinados acessos.
O SQL, enquanto sistema de gestão de base de dados, permite a encriptação das bases de dados.
Apesar de ser possível, isto levanta uma série e questões associadas à recuperação, performance e tratamento da informação.
Para evitar estes handicaps, sugere-se que os discos (ao nível do file system) sejam encriptados. Não é igual, mas se a preocupação é garantir que a informação caso o equipamento seja comprometido (roubado), não seja acessível, então o resultado será idêntico.
O que a encriptação da base da dados irá permitir?
Caso seja obtido por falha de configuração ou acesso indevido, dados (resultado de queries) da base de dados, o “Atacante” não vai conseguir retirar informação pois ela está num formato ilegível.
Esta componente é vital em situações nas quais o conteúdo da base de dados coloca em causa a segurança do negócio e/ou pessoas. Deve, no entanto, ser pesada e relacionado com o custo de manutenção dos processos de certificação. Por exemplo numa falha de um sistema na qua a base de dados se encontre encriptada, não basta fazer restore num outro servidor. Toda a configuração relacionada com certificados, tem de ser preparada previamente, pelo que, sim é algo que deve ser implementado, mas apenas quando há a certeza de termos uma infraestrutura redundante, previamente inplace e capaz de transferir a base de dados. Normalmente estas infraestruturas são constituídas com clusters com vários nós nos quais as bases de dados são mantidas. Como o sistema já é operado como um só, uma qualquer falha num servidor encriptado. Não acarreta tempo de preparação de infraestrutura, tornando-se assim exequível. De outra forma o tempo de paragem é muito grande.
Este tipo de Infraestrutura representa um nível de preparação e manutenção de infraestrutura grande, o que leva a um considerável aumento de custos. Deve por isso ser considerada, mas com atenção a estes argumentos.
Os acessos às bases de dados são um ponto de falha no que se refere à segurança. Isto porque baseiam-se em passwords.
O SQL permite que a sua segurança seja associada ao Domínio (caso exista), no entanto isto não é de todo aconselhado. Porquê?
Existem ainda alguns Tweeks que podemos usar na configuração do SQL para permitir elevar a segurança e performance. De notar que o “linchpin” do sistema é o SQL. Se este cai, podemos ter toda a infraestrutura de serviços comprometida. Da mesma forma que a otimização do SQL levará benefícios aos restantes componentes da Infraestrutura (IIS por exemplo).
Algumas das otimizações passam por:
Estas operações de manutenção, podem ser otimizadas, usando alguns scripts disponíveis na internet. Um dos melhores locais de Scripting para SQL disponíveis é o www.brentozar.com . Aqui encontrarão uma panóplia muito grande de informação. De notar que todos estes scripts não são patrocinados pela PHC, pelo que deverão ser, caso sejam usados, testados em ambiente de teste. No caso da passagem para produção, esta será da inteira responsabilidade do implementador.
Como regra, o modo de compatibilidade deve estar sempre na última (mais recente) disponível pelo servidor e compatível com as indicações da PHC. Mas afinal o que é o modo compatibilidade? É simplesmente o toolbox de instruções que podem ser usadas quer funções do SQL, formas de gestão da base de dados etc.
-
Autoclose. Deve estar sempre a falso. Na prática estando ativo, o sql "para a base de dados sempre que nota que não existem conexões a ela. O problema é que o tempo de “reativação" da base de dados é sempre grande. Só poderá ser justificável em sistemas pequenos e de poucos recursos.
-
Auto create Statistics. Deve estar a true. Falamos nas estatísticas em tópico em cima.
-
Auto Srink. Deve estar a false. Esta opção está associada ao que é produzido com a “Caixa” que falamos em cima. Na verdade, o que faz é tentar otimizar o espaço livre em disco, reduzindo o espaço vazio no MDF, obrigando o processo continuo do SQL de “autogrow /Autosrink”. É péssimo para a performance, unicamente devendo ser usado quando as restrições no espaço físico de disco é algum impossível de endereçar de outro modo.
Uma necessidade das áreas de gestão do SQL, é a auditoria das interações com o servidor de SQL e suas bases de dados.
Recomenda-se que seja criado um trace log permanente de tudo o que é realizado. Isto é vital para análise forense caso existam problemas, detetar pontos de falha, pois estes logs podem ser tratados por parsers, procurando por determinados sinais, ou mesmo analisados para detetarem botlenecks (tempo de execução de uma query, número de reads, Writes, etc).
A forma mais simples é ativar o SQL Server Profiler, numa máquina externa ao SQL. Este durante o processo de captura do traces usa bastantes recursos de memória, pelo que não devemos criar esta pressão no servidor.
Devemos ter atenção na sua configuração. Facilmente criamos verdadeiros “monstros” de GB de disco, se não tivermos atenção às opções selecionadas.
-
Sugerimos assim um trace que aborde:
-
Errors and Warnings: CPU Threshold exceeded e User Error Messages
-
Security audit: Audit Login Failed
-
Store Procedures: RPC: Completed, SP:StmtCompleted e SP:StmtStarting
-
TSQL: Exec prepared SQL, SQL:BatchCompleted, SQL:StmtCompleted e SQL:StmtStarting
-
Transactions: TM: Rollback Tran Completed e TM: Rollback tran Starting Estes indicadores, deverão ter todas as colunas de seleção preenchidas.

De notar que estes indicadores são apenas alguns. Na verdade, estão balanceados entre o número de registos que geram em ficheiro com a quantidade de informação que podemos retirar deles. Muitos outros podem ser escolhidos se pretendemos ter uma abordagem de analise mais fina.
Será da escolha do administrador realizar a melhor seleção para o propósito pretendido.
Como foi indicado anteriormente este tipo de traces gera uma quantidade enorme de dados.
Devemos por isso usar um local de destino destes externos ao SQL. Recomendamos que sejam produzidos sobre a forma de ficheiros (apesar de poderem ser incluídos em base de dados diretamente, estas rapidamente tomam tamanhos gigantes. Da experiência, uma localização partilhada na rede com ficheiros a fazerem rollover é a melhor solução.
Sugerimos assim, ficheiros não mais que 256 Mb com rollover automático.

Utilizadores SQL
Conforme o tipo de aplicação que se pretende instalar, devem ser criados os respetivos utilizadores SQL:
- Tipo de Aplicação: Pública - Nome do Utilizador: Público
- Tipo de Aplicação: Interna - Nome do Utilizador: Interno
- Tipo de Aplicação: Externa - Nome do Utilizador: Externo
Estes utilizadores já vão configurados no ficheiro appSettings.config com os nomes anteriormente indicados. Se quiser alterar pode fazê-lo e neste caso deve alterar a seguinte chave: add key="DSN" value="server=A;uid=B;pwd=C;database=D;"/
Em que B deve ser substituído pelo nome do utilizador criado e, no caso de ter configurada uma password esta deve ser indicada em C.
- Aplicações internas (Intranet): No caso de estar a instalar uma aplicação interna, os utilizadores são criados no menu Sistema na opção Utilizadores. Qualquer utilizador normal do Software em Windows pode ter acesso às aplicações PHC CS Web, basta para tal na página PHC CS Web escolher a opção Tem acesso via PHC CS Web. Os utilizadores têm acesso por Package, isto é, o Software apresenta a listagem de todas as aplicações internas, mas o utilizador pode só ter acesso a uma delas. Neste caso deve ser passado o nome da aplicação para a janela do lado direito.
- Aplicações externas(Extranet): No caso das aplicações externas, os utilizadores são criados no módulo Supervisor, na opção Utilizadores de Clientes. É ainda necessário na ficha do cliente, na opção de menu Utilizadores deste cliente - PHC CS Web e na página Outras opções do Cliente escolher as aplicações que o cliente adquiriu.
Configuração do IIS
A configuração apresentada visa as vertentes de garantir um servidor de IIS capaz de permitir a evolução no que se refere às tecnologias usadas de desenvolvimento, capacidade de auditoria e isolamento das aplicações e Sites Instalados. Pressupõe que estes se encontram numa DMZ controlada por uma firewall.
Durante a instalação do Sistema Operativo uma das componentes será a instalação do servidor Web (IIS). Uma nota importante:
-
Se o sistema operativo for Windows 2019, devemos antes de iniciar a instalação dos roles e Features, instalar primeiro o .Net Framework 4.8. Este requisito deve-se a uma limitação do SO quando selecionarmos os componentes do .Net 3.5.
Para isso, contamos com as opções acessíveis via ServiceServer Manager que se encontram separadas entre Roles e Features.
Os Roles representam os “serviços” que o servidor irá disponibilizar. Neste caso, e como estamos a tratar de um servidor para disponibilizar aplicações Web, vamos instalar os “Roles” associados a estas valências.

Clicando em Manage, temos acesso às configurações dos componentes. Para os configurar, selecionámos “ADD Role and Feature”.

Aqui, ativamos a opção:
A aplicação vai questionar se pretendemos adicionar os pacotes (features) de Gestão pelo que indicamos que sim.
Fazemos Next e passamos às features. Nas features vamos personalizar quais as opções que o o nosso servidor deverá possibilitar configuração. Assim devemos selecionar:





Notas importantes:
-
Em alguns dos componentes (Roles e features), existem opções que estão previamente marcadas. Outras, teremos de as confirmar. Assim, e para garantir que todas as opções aqui apresentadas estão confirmadas, devemos abrir todos os nós.
-
Nas opções ativadas que apresentam a necessidade de instalação de outros componentes (herança) devemos confirmar sempre.
Após a instalação, podemos iniciar a configuração das aplicações CS Web.
Instalação do IIS (Internet Information Services)
No painel de controlo do Computador, opção Adicionar/Remover Programas tem de escolher a opção de Adicionar/Remover Componentes do Windows para instalar o IIS. Este componente vai ser instalado por defeito em: C:\Inetpub
Se ao instalar a aplicação encontrar um problema, a solução passa por aceder ao Painel de Controlo, Programas, Turn Windows features on or off, e definir as seguintes configurações:
Instalação da Aplicação
No CD de instalação, existe uma diretoria chamada 'Aplicacoes', dentro desta diretoria, existem as pastas com os nomes das aplicações e dentro de cada está um ficheiro zip.
- Para instalar o PHC CS Web é necessário ter o Web Pllaform Instaler (Deploy) instalado no IIS.
- Para instalar pode efetuar o download em http://www.iis.net/downloads/microsoft/web-deploy, ou no Cd de instalação na pasta Outros/ deploy, correr o setup.
No web Plaftorm installer 4.6 no separador "produts" proceder à instalação do Web Deploy 3.5.
No IIS, no Default Web Site efetuar clique direito e escolher a opção, deploy - Import application. O processo de instalação da aplicação passa por efetuar os seguintes passos:
1 - Selecionar o caminho onde se encontra o ficheiro da aplicação, por exemplo, "Intranet.zip".
2 - Na instalação surge os ficheiros que vão ser instalados. Não desseleccionar nenhum.
3 - O próximo passo devemos indicar qual o nome que pretendemos dar ao nosso projeto PHC CS Web
4- Ao clicar em next, será instalada a aplicação.
Poderá da mesma forma, instalar a aplicação da seguinte forma:
Poderá também, instalar a aplicação, ou atualizar o projeto do PHC CS Web de uma forma automática:
Podemos copiar os ficheiros da aplicação, que pretendemos instalar, para uma diretoria.
Dentro da pasta de PHC CS Web, no ficheiro intranet.setparameters.xml, editamos o ficheiro e colocamos o nome do projeto que pretendemos, dar exemplo: setParameter name="IIS Web Application Name" value="Default Web Site/intranet"
Abrir o Command prompt (como run as administrator) colocar o seguinte caminho (Exemplo): Cd:C:\XPTO \intranet\intranet.deploy.cmd /y
Ao correr este ficheiro vai efetuar a instalação e criar o projeto com o nome que foi dado no intranet.setparameters.xml.
E para que seja um processo automático poderá criar um bat.file com as seguintes configurações, efetuando os seguintes passos: @echo off
C:\intranet\intranet.deploy.cmd /y
Desta forma, cada vez que for necessário proceder a alguma atualização, basta correr o bat.file. Como fazer um bat.file
Abrir um ficheiro Notepad e gravar o mesmo com extensão de .bat
, editar o ficheiro e colocar a informação acima indicada.
A aplicação que instalou fica, por defeito, na seguinte diretoria: C:\inetpub\wwwroot\NomeDaAplicacao.
Se não estiver neste local é porque o IIS (Internet Information Services), não foi instalado em c:\inetpub, neste caso, terá que verificar qual o caminho para a diretoria do IIS.
Se utilizar o IIS7 deve aceder ao mesmo, selecionar a aplicação que acabou de instalar e efetuar clique direito sobre a mesma. Selecionar a opção "Manage Application" e depois a opção "Advanced Settings".
O IIS vai abrir um ecrã de configurações avançadas onde se deve clicar no botão relativo ao Application Pool.
A aplicação volta a abrir um ecrã no qual se pode observar a versão da Framework relativa à Application Pool selecionada. Deve estar selecionada a versão a 4.5.
De forma a melhorar o desempenho em termos de rapidez do PHC CS Web devem ser efetuados os seguintes passos no IIS:
- Aceder às Application Pools e selecionar a application pool utilizada pelo PHC CS Web;
- Aceder às "Advanced Settings..." e selecionar as seguintes opções:
- Start Mode: AlwaysRunning
- Idle Time Out Action: Suspended
- Maximum worker processes: 0
Depois das alterações é necessário fazer o "Recycling..." da application pool.
Feitas estas verificações deve continuar a instalação da aplicação.
Após a instalação, podemos iniciar a configuração das aplicações CS Web.
Configuração dos Logs
Uma das componentes importantes para a segurança de sistemas, é a capacidade de auditar as comunicações, os acessos, a receção e envio de informação.
Para isso devemos configurar um local onde todos estes registos ficam armazenados e podemos ser consultados.
Para isso, existem três registos importantes:
-
Registos de Sistema: Eventlog
-
Registos de acessos / comunicações com o IIS
-
Registo de comunicações do servidor de SMTP (quando instalado)
Os registos de eventlog são muito importantes para a avaliação de indicadores de saúde do sistema. Está dividido em três áreas principais para as quais devemos olhar:
-
Applications:
-
Security:
-
System:
-
Talvez o log mais importante do SO. Devemos sobre este ter em conta logs de Fontes como “WAS” (Associadas ao IIS e suas aplicações), “ServiceServer manager” (associada a serviços do Sistema Operativo entre os quais o IIS), Kernel (associadas a sistema)
É também importante observar os registos de acessos aos sites e apps.
Para isso, o servidor de IIS pode produzir um conjunto de Logs que registam as comunicações e para as aplicações alojadas nele.
No entanto, para que seja possível reduzir a pressão destes logs no sistema operativo, é conveniente que se crie um diretório num disco exterior ao Disco C.
Assim, criámos um Diretório para armazenar Logs. Por exemplo, E:\Logs.
Neste criámos um subdiretório para os logs de IIS. Desta forma, podemos configurar o IIS. Para isso, aceda ao IIS Manager, clique na raiz da árvore (link com o nome do Servidor). Encontrámos um shortcut associado aos logs. Acedendo ao “logging”, conseguimos configurar a forma como desejámos realizar os logs.

Sugerimos:

Devemos ter em conta os campos registados. Sugerimos que todas as opções estejam ativadas.
Uma nota adicional, é o tipo de log. Este deve ser por server. Isto, porque caso seja definido por site, apesar de se compartimentar os logs, a sua pesquisa e gestão torna-se muito mais difícil.
Por último, resta os logs do SMTP Server.
No momento da instalação, podemos verificar que instalámos o Servidor de SMTP. De notar que a origem deste servidor foi uma forma de dotar a capacidade de enviar email aos webmasters. Não dever por isso ser usado como método de envio de email (apear de ser passível de usar dessa forma).
Porquê?
As comunicações por emails foram das maiores conquistas de aproximação / partilha de informação originadas nesta evolução tecnológica. No entanto, todos sabemos os malefícios desta mesma partilha / facilidade de comunicação. Spam, Phishing entre outros malefícios atribuiu uma nota de desconfiança a este forma de comunicação.
Para contornar estes malefícios, a indústria começou a criar uma série de salvaguardas sobre a forma de email securities, content filters, RBL’s etc. Por esse motivo, um uso excessivo sem controlo deste tipo de servidor, pode facilmente colocar um domínio / IP em Blacklist, ou pior, gerar uma perda de reputação do domínio causando perdas que podem ser consideráveis de Dinheiro.
Para minimizar esta situação devemos configurar o servidor de smtp da seguinte forma:
- Aceder a Internet Information Service (IIS 6.0)

A primeira ação é definir, tal como o IIS, a localização dos Logs e o nível de logs, configurando as variáveis que serão armazenadas:


Tal como no IIS, devemos ativar todas as opções. Dessa forma, podemos analisar os logs de diversas perspetivas.
Configuramos agora, quem pode aceder ao servidor. Estes servidores de SMTP não devem permitir que sejam acedidos externamente, nem mesmo de computadores da mesma rede. Caso estes fiquem comprometidos, poderão usar o servidor como uma porta de envio de informação sem qualquer controlo.

O mesmo se passa com a possibilidade de relay. Este deve ser o mais controlável possível, pelo que apenas colocamos o IP do servidor.

As restantes configurações podem ficar como estão. Nota adicional para os seguintes pontos:
No entanto, juntamente com este diretório existem outros (queue email, pickup e drop mail). Todos estes diretórios encontram-se no mesmo local, pelo que alterar esta informação seria espalhar a informação. Devemos, por isso, ter alguma atenção a estes diretórios.
Configuração da Alarmística
A gestão de servidores expostos na internet é algo vital para a boa manutenção dos serviços que são lá executados. O abandono destes princípios de cuidado, podem colocar em causa a reputação de uma empesa.
Por esse motivo, o uso de Software que visa criar uma base de dados de análise e alerta de ocorrências que saem fora do que é padrão é essencial.
Existem vários, (Zabbix, Spiceworks, Diversos softwares da Microsoft agregados em Azure pelo Sentinel). No entanto e independente do usado, o importante é que observem os seguintes princípios:
-
Criem histórico: A análise de alarmística é tão ou mais importante o histórico que a ocorrência localizada. Exemplificando, um acréscimo de Hits num site a determinada hora durante vários meses, é diferente de um acréscimo de hits numa mesma hora quando isso não é normal. A Segunda pode ser um ataque, a 1ª uma ocorrência normal originada num processo de início de backup por exemplo.
-
Possibilidade e Alarme: Deve ter a capacidade de alerta em vários suportes (email, sms, etc), quando algo não está bem.
-
Configurável: Os falsos positivos são uma constante. A Capacidade da plataforma pode ser programada / configurada para tornar mais fina a malha na qual alertar de problemas deve ser um requisito.
Utilizador ASPNET
Aquando da instalação da Framework, é criado no sistema um utilizador chamado ASPNET, este utilizador deve ser passado para o grupo dos Administradores locais da máquina, este procedimento é temporário para o arranque da aplicação, pois este utilizador só deverá estar neste grupo (Administradores) durante o arranque das aplicações PHC CS Web. Assim que todas as aplicações tenham sido executadas com sucesso pela 1ª vez, deverá o mesmo ser removido do referido grupo. Esta situação é necessária para que sejam (no 1º arranque bem sucedido) criados no event viewer os logs de cada aplicação.
Só é necessário este passo se a key do appSettings estiver com o valor Sim.
Instalação do IduServer
O IduServer é um aplicativo que está no cd de instalação e que deve ser instalado para quem precisa de impressões de idus em pdf nas aplicações PHC CS Web. As impressões em idu estão disponíveis nas seguintes tabelas: BO, FT, RD, FO, PE, RE, CL, PA, MH e PR. Existe ainda uma configuração appSettings no ficheiro appSettings.config, de nome <add key="SMTPSERVER" value="localhost "/>, essencial para que esta impressão funcione.
Se após instalação deste setup ocorrer um erro na aplicação ao imprimir idêntico a este: "Erro IDU: Não foi possível inicial a aplicação de impressão." e "Erro IDU: Retrieving the COM class factory for component with CLSID {C05B3535-FA4F-4CBD-B3EA-AE999AD66101} failed due to the following error: 80040164", significa que o setup não conseguiu registar o ocx na máquina, neste caso deve registar à mão o seguinte ficheiro: iduserver.dll.
Poderá fazê-lo da seguinte forma: regsvr32 c:\inetpub\wwwroot\iduserver\iduserver.dll
Dica: Deve instalar o iduserver na diretoria proposta pelo setup.
Nota Importante: Caso já tenha uma versão anterior instalada é necessário desregistar a dll da versão anterior e efetuar o registo da nova dll.
Configuração do ficheiro appSettings
No local da instalação fica um ficheiro chamado appSettings.config.
Este ficheiro é muito importante pois é nele que existe muita da informação necessária à aplicação para que esta seja executada.
Nota: Este ficheiro é Case Sensitive, isto quer dizer que, por exemplo, On é diferente de on e nos casos de enganos as instruções não são lidas.
Entrada na Aplicação
Após a configuração do ficheiro appSettings a aplicação está preparada para arrancar, para tal basta no browser fazer:
Localhost/nome da aplicação [enter] (no caso do servidor local)
Nome do servidor/nome da aplicação [enter]
Nota: Depois de entrar uma vez na aplicação, deve retirar o utilizador ASPNET do grupo dos administradores.
Re-arranque da Aplicação
No caso de ser necessário re-arrancar a aplicação, é possível fazê-lo de diversas formas:
- alterando a chave do "ENOME" que se encontra no ficheiro appSettings.config e posteriormente, reiniciar o IIS (Internet Information Services);
- executando o comando: iisreset, na linha de comandos do DOS;
- através das opções de configuração acedidas pelo comando: ../programs/gensel.aspx?opcoes=sim (opção Re-arrancar a aplicação); ou
- re-arrancando o computador.
Dica: O PHC CS Web demora mais de 30 segundos a arrancar de cada vez que um utilizador entra no software após este ter sido arrancado. É o momento em que o sistema compila a aplicação. Assim, para evitar que isto aconteça a outros utilizadores, sempre que arrancar a aplicação, entre na aplicação para que esta faça a compilação inicial.
Configuração de certificados
Abordamos nuns tópicos em cima, a questão da reputação. A reputação de um domínio / serviço é algo importante, até porque os utilizadores estão cada vez mais informados, atentos e cuidadosos aos serviços que usam ou consomem. Por esse motivo, a necessidade de os descansar é essencial.
O uso de certificados é primordial.
Os certificados trazem duas principais capacidades:
A transferência de dados entre dois pontos, seja na cópia de ficheiros, seja no simples acesso a uma página de um qualquer site, é passível de ser escutada, capturada, podendo assim ser visualizada ou pior alterada. A associação de um certificado ao servidor é por isso muito importante.
Por outro lado, a certificação da entidade é também importantíssima. Se para a comunicação, um certificado “Gratuito” tipo Lets encript ou outro será suficiente, para a autenticação da entidade já é mais difícil sendo necessário um certificado obtido numa entidade certificadora credenciada.
A Explicação é simples: Ninguém confia numa fechadura cuja origem não conhecemos. É o mesmo para os certificados.
O âmbito do certificado é também de relevante importância. Um certificado pode ter uma ou várias valências podendo certificar um domínio, comunicação de email, código fonte etc.
Para os sites deve ser adquirido um certificado para múltiplos Alias/subdomínios, normalmente chamados Wildcard, p.e., *.Domínio.pt.
Desta forma, podemos associar vários sites ou apps sobre um mesmo domínio (Exemplo: Intranet.dominio.pt; Extranet.dominio.pt)
A instalação de um certificado normalmente é feito via duplo clique sobre o certificado (No caso do IIS o ideal é estar em formato PFX), e seguir os passos.

Devemos ter em conta que:
-
O certificado deve ser instalado em Local Machine;
-
Não se deve instalar a chave privada no servidor;
-
Não se deve permitir a exportação;
-
Deve ser instalado por defeito usando a opção “Automatically select the certificate store based on the type of Certificate”;
-
O ficheiro uma vez instalado, deve ser apagado do servidor; Com o certificado instalado, podemos configurar os sites com HTTPS.
Instalação das aplicações CS-Web
As aplicações são agora instaladas de forma muito mais automatizada. A PHC via Setup de instalação facilitou muito o trabalho técnico de configuração. No entanto, existem alguns pontos que poderemos otimizar garantindo um maior nível de segurança das aplicações.
-
Já abordado anteriormente, a localização dos sites / Aplicações, deve ser externa ao Disco C. No entanto, o diretório do Inetpub e Wwwroot não deve ser alterado. A razão é a já mencionada. Se colocarmos todo o impacto das apps no disco c (do sistema) ele próprio poderá ficar sobre esforço caso um ou vários sites fiquem com algum problema (excesso de tráfego, ataque, …). Se isto ocorrer e afetar o acesso ao disco (por estar por exemplo muito ocupado) vamos ter dificuldade em agir pois poderemos no limite não ter acesso a consola.
- Outro ponto é o crescimento. Podemos ter múltiplos sites, crescendo estes também em tamanho. Isto irá causar pressão por exemplo na quantidade de disco disponível para memória virtual. O que fazer?
* Num disco à Parte do Servidor criar uma pasta vazia Exemplo: Sites
-
Retirar desta pasta a herança dos acessos
-
Atribuir a esta pasta acessos ao user IIS_IUSR de full control (replicada na sua estrutura para diretórios e ficheiros)
-
Criar uma Application pool por cada Site / app:
-
Este ponto é muito importante. Desta forma, podemos interagir (recycle parar) cada um dos sites / apps sem por em causa os restantes.
-
Por template, os sites e apps são colocados no Default website. A sua application pool só deverá conter 1 app (ele próprio). O Default web site é muito mais que um site pois é ele que “coordena “ todo o servidor. Se cair, ficar instável, teremos muito provavelmente de reinstalar o servidor.
Cada App pool tem um conjunto de recursos / configurações que podem ser personalizadas. Alguns devemos alterar para maximizar o performance do servidor:
* Process model
Recomendamos esta opção.
-
Idle Timeout: No caso de sites de uso inconstante, os 20 m padrão é suficiente. O que este parâmetro indica é que ao fim de 20 minutos de inatividade do site, este liberta recursos e desliga-se. Permite assim que os recursos cativos, possam ser usado por outras aplicações.
-
Idle Time-out action: Por padrão a opção encontra-se em Terminate. No entanto nos casos de sites que não são usados regularmente mas precisam que sejam iniciados rapidamente, a melhor opção é Suspend. Dessa forma eles libertam parte dos recursos, mas ficam num estado que na 1ª chamada seguinte acordarão rapidamente sem levar o tempo normal de arranque de um site.
* Recycling
As aplicações Web possuem 2 ficheiros de configuração principais a ter em atenção:
· Web.Config
· Appsetting.config
Na verdade, o Appsettings.config é uma parte do web.config. No IIS, quando se altera o conteúdo do Ficheiro Web.config, a application pool faz automaticamente recycle. A PHC para evitar esta funcionalidade do IIS, extraiu destes a componente de configuração das aplicações (Appsettings.config).
O web.config é o ficheiro de configuração das apps / sites. Nele ficam descritos as configurações associadas por exemplo a Frameworks, redirects, regras de Url Rewrite, apresentação de erros, configurações de segurança, etc.
Alguns destes são de alteração opcional com o objetivo de otimizar a segurança e performance. Usando alguns addons ao IIS tal como URL Rewrite, podemos configurar regras para forçar o HTTPS.
Para isso precisamos de ter os sites associados a um certificado (ponto já anteriormente visto) e possuir uma regra que quando o utilizador faça um http:\\Site.tld seja redirecionado para Https://Site.tld.
Garantimos assim uma maior visibilidade ao site pois admite http e https sem comprometer a segurança.
Como fazemos isso?
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="HTTP/S to HTTPS Redirect" enabled="true" stopProcessing="true">
<match url="(.*)" />
<conditions logicalGrouping="MatchAny">
<add input="{SERVER_PORT_SECURE}" pattern="^0$" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Permanent" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
(Notar que as Chaves podem já existir. Deverá ser previamente confirmado e usado o exemplo como matriz.
Esta (“Mode”) deve estar a On (Case Sensitive), sendo que deveremos ter uma página de redireccionamento / manutenção em caso de mensagem de erro. Desta forma o comportamento do Servidor é sempre constante, esteja em falha ou a correr, reduzindo a possibilidade de existir uma abertura para ser explorada.
-
Outras configurações como costumheaders, serverheaders, as quais transitem informação sobre sites e servidores, podem ser removidas / personalizadas. No entanto isto deve ser realizado em conjunto com o desenvolvimento da aplicação, estando neste momento, a decorrer procedimentos para limitar a sua ação.
No que se refere ao Appsettings.config existem alguns cuidados que podemos ter para garantir uma maior segurança.
-
Não ter mais chaves que a quelas que são necessárias. Há muito a ideia que podemos copiar um Appsettings.config de uma app para outra. Isto até é verdade, mas a informação que é transportada para ele, além de ficar em ficheiro separado, torna confusa a gestão das configurações. Por esse motivo, e apesar de ser trabalhoso, devemos apenas ter a informação que seja necessária e esteja atualizada.
-
Tags associadas a email, contas e passwords, devem ser únicas por sites. Assim isolamos a origem e podemos facilmente alterar a password, sabendo onde ela está a ser usada
-
Ter atenção às tags de OnError, logerr, loglogin. Apesar de sugerido que estejam ativos, geram alguma informação, a qual terá de ser limpa manual e periodicamente. Estes logs contem informação interna e não devem ficar disponíveis duram longos períodos.
Falta ainda falar nos bindings.
Os sites possuem bindings (ligações a Ips). Isto porque no inicio cada site teria de ter associado um ip único externo. Já não é assim (à já algum tempo). Isto provocava que para cada ip só poderíamos ter um site por Ip/ porta (Ex: http://site.tld associado ao Ip AAA.BBB.CCC.DDD porta 80. Poderíamos ter outro site para o mesmo Ip mas para outra porta (Ex 81))
Atualmente podemos ter todos os Sites associados à Mesma porta. O IIS Fará as alterações automaticamente.
Para isso configuramos nos bindings
Para configurar estas ligações, podemos associar várias portas ao mesmo site / serviços. Configurando o Hostname a qual ele vai responder, o IIS redirecionará a comunicação para o local correto.
Exemplo: o IP 111.111.111.111 Está disponível para um servidor de iis. A este poderemos associar os sites:

Como fazemos isso?
No ecrã de Bindings associámos o tipo de protocolo (associado a uma porta), Hostname, que será o site sem o prefixo. Criámos assim uma base de dados de Bindings
No caso de serem HTTPS, teremos de associar um Certificado (já anteriormente visto) e no caso do Windows 2019 podemos e devemos configurar para que não sejam aceites certificados com Chaves Fracas.
Geral.css e User.css
Existe um ficheiro de configurações chamado geral.css, este ficheiro aquando da instalação da aplicação é colocado na diretoria CSS.
É no ficheiro de configurações geral.css, que estão definidos os formatos genéricos de toda a aplicação, sendo principalmente tamanhos, margens e alinhamentos.
Existem alguns CSS que permitem a definição das cores em função do tema cromático escolhido pelo utilizador, sendo os seguintes:
- Theme-default.css- Onde estão as definições do tema "Normal"
- Theme-classic.css - Onde estão as definições do tema "Cor"
- Theme-dark.css - Onde estão as definições do tema "Escuro"
- Theme-4.css - Onde estão as definições do tema "Aqua"
- Theme-5.css - Onde estão as definições do tema "Glaciar"
- Theme-6.css - Onde estão as definições do tema "Anil"
- Theme-7.css - Onde estão as definições do tema "Coral"
- Theme-8.css - Onde estão as definições do tema "Prado"
- Theme-9.css - Onde estão as definições do tema "Branco"
No caso de se pretenderem alterações, por exemplo às cores, estas devem ser feitas no ficheiro chamado user.css, que se encontra na diretoria PIMAGES e que fica vazio aquando da instalação. Não são aconselháveis alterações ao geral.css.
Existe um ficheiro para cada tema onde é possível pode sobrepor as definições de cores ao seu gosto:
- Pimages/user1.css para o tema "Normal"
- Pimages/user2.css para o tema "Cor"
- Pimages/user3.css para o tema "Escuro"
- Pimages/user4.css para o tema "Aqua"
- Pimages/user5.css para o tema "Glaciar"
- Pimages/user6.css para o tema "Anil"
- Pimages/user7.css para o tema "Coral"
- Pimages/user8.css para o tema "Prado"
- Pimages/user9.css para o tema "Branco"
Ficheiro App_Offline.htm.txt
O ficheiro App_Offline.htm.txt, que é instalado com o PHC CS Web, permite desligar temporariamente o site.
Quando se pretende, por exemplo, efetuar manutenção do site, basta renomear o ficheiro para App_Offline.Htm passando a surgir a informação de que o site se encontra temporariamente indisponível.
Para voltar a colocar o site disponível, ou seja, voltar a ligar, basta renomear o ficheiro para app_offline.htm.txt.