Política de Segurança

Esboço de uma Política de Segurança da Informação

A Segurança da Informação divide-se basicamente em duas partes:

1 - Física - acesso ao prédio e aos computadores
1.1 - Acesso pela portaria
1.1.1 - Estranhos somente com identificação
1.1.2 - Todo computador que entrar ou sair deve ser cadastrado no sistema da portaria
1.1.3 - Identificar entrada de notebooks com estranhos
2 - Lógica - acesso ao software dos computadores
1 - Estações
1.1 - Senhas dos Usuários comuns
1.2 - Senhas dos Administradores
1.3 - Privilégios dos usuários
1.4 - Backup dos e-mails, arquivos, etc
1.5 - Manter página com dicas de segurança no site, assim como periódicos treinamentos e cursos para usuários e técnicos

2 - Servidores da Rede
2.1 - Acesso à sala
2.2 - Senhas dos usuários
2.3 - Senhas de root
2.4 - Segurança dos servidores
2.5 - Backup dos servidores
2.6 - Bom esquema de atualizações
2.7 - Manter somente aplicativos que estão em uso
2.8 - Cuidadosa atenção ao sistema de permissões  dos arquivos e diretórios
2.9 - A instalação de cada servidor deve ser precedida de um projeto, mesmo que seja simples
2.10 - Manter boas ferramentas de monitoração e auditoria dos servidores

3 - Código em PHP
3.1 - Segurança no php.ini
3.2 - Segurança no Apache
3.3 - Scripts com senha fora do Apache
3.4 - Validações em JavaScript e também em PHP
3.5 - Tratamento de erros
3.6 - Evitar uso do método GET e do atributo HIDDEN com dados sigilosos
3.7 - Backup dos scripts
3.8 - Usar captchas em forms de login
3.9 - Usar require ao invés de include
3.10 - Usar session para bloquear entrada direta nas páginas
3.11- Manter somente bancos em uso
3.12 - Todo aplicativo deve ser precedido de um projeto, mesmo que simples
3.13 - Padronizar nomes de constantes, variáveis, funções, classes, arquivos e diiretórios
3.14 - Evitar uso de funções em depreciação
3.15 - Usar boas ferramentas de monitoração de segurança como o phpSecInfo e o securityScanner
3.16 - Sempre filtrar dados dos usuários antes de adicionar ao banco
3.17 - Somente um desenvolvedor deve ter acesso a alguns scripts como o funcoes.inc.ph6p
3.18 - Devemos criar um manual de procedimentos que oriente o programmador a criar aplicativos

4 - Bancos de dados
4.1 - Um usuários por aplicativo
4.2 - Usuários com Privilégios rstritos
4.3 - Senhas dos usuários
4.4 - Senhas dos super usuários
4.5 - Integridade  das informações
4.6 - Backup dos bancos
4.7 - Todo banco deve ser precedido de um projeto, mesmo que seja simples
4.8 - Padronizar os nomes de bancos, tabelas, campos, etc
4.9 - Os SGBDs devem ficar sob a responsabilidade de um DBA
4.10 - Devemos criar um manual de procedimentos que oriente o programmador a criar bancos de dados, sob a orientação do DBA

5 - Servidor de Teste
5.1 - Manter no servidor de teste uma cópia atualizada de todos os aplicativos do servidor de produção
5.2 - Manter no servidor de testes uma cópia de todos os bancos  do servidor de produção
5.3 - Todos os desenvolvedores devem trabalhar diretamente com o servidor de teste e somente após bons testes o
aplicativo juntamente com o banco devem ser copiados para o servidor de produção
5.4 - Deve ser escolhido um desenvolvedor para que efetue a homologação nos aplicativos

6 - Computadotes particulares
5.1 - Não adicionar em nossa rede

7 - Sobre a divulgação deste documento


Política de Backup

- O que guardar? scripts de configuração (etc), alguns logs, /home, /var/spool/mail, bancos de dados, scripts em PHP e outros
- Periodicidade: diária, semanal, mensal e anual
- Quando apagar fita? Após um ano?
- Tipo de backup: diferencial
- Onde armazenar


Padronizações para agilizar trabalho

- Nomes dos servidores deve ser coerente, relacionados a sua função
- Criar grupos de usuários: desennvolvedores, coordenadores, etc. e definir restrições e privilégios adequadamente.
- Definir política de cotas: e-mails, espaço em disco (homes dos usuários no servidor, NIS e Samba), banda, etc.
- Manter um diagrama dos servidores, com informações detalhadas para melhor administrar: servidores, storages, robô, switchs, roteadores, no-breaks, disjuntores, IPs, MACs, consumo de potência dos servidores, etc
- Realizar uma verificação geral da rede: servidores, switchs, cabos, etc e fazer isso periodicamente como manutenção preventiva
- Planejar procedimentos de pré-instalação, instalação e pós-instalação


- As informações existentes sobre os servidores (IPs, serviços, usuários, etc) devem ficar em sigilo
- Mudar as portas default de todos os serviços para portas altas, acima de 5000 ou de 60000.
- Instalar bons softwares de monitoramente e auditoria e realizar um monitoramente geral de vez em quando ou periodicamente.
- Palestras e treinamentos para os usuários, no sentido de torná-los mais aptos para suas funções, atentos para segurança, etc. Também criar site com dias e orientações em geral, como também usar o e-mail para envio de mensagens mais urgentes.
Promover reciclagens internas entre colegas (suporte, desenvolvedores, rede, etc), assim como bons treinameentos externos.
- Acesso SSH permitido apenas internamente na rede, com exceção de uma máquina externa e também para as iDRAC.s
- Incidentes de segurança no Brasil devem ser comunicados para:
http://www.cert.br
- Instalar e manter atualizado antivirus num servidor Linux para varrer máquinas windows e também da rede 
- Integrar antivirus com Squid, Postfix e instalar também antispam


Política de Senhas

Toda senha devem ser memorizada apenas e nunca anotada
Evitar ao máximo pronunciar senhas próximo de pessoas não autorizadas
Senhas fortes nos servidores para o root e que os sysadim evitem seu uso, preferindo usar um usuário com menor privilégio e só assumir como root se necessário.


Segurança das Estações de Trabalho

Nos micros das estações de trabalho (micros dos usuários) existem informaçõess importantes para o usuário e também para a instituição, números de documentos, de cartão de crédito, planilhas, documentos texto, etc. Esses micros podem ser manipulados sem o conhecimento do usuário por cracrers para comandarem um ataque aos servidores (como slavers).  É importante conhecer as vulnerabilidades das estações para evitar formatações e reinstalações do sistema operacional.

Para agilizar as instalações e reinstalações manter uma imagem dos micros com Windows e um CD remasterizado para os micros com Linux (remastersys é uma boa alternativa). Para criar uma imagem personalizada dos micros com Windows o “partimage” é uma ótima alternativa.

Elaborar uma cartilha simples e clara, com procedimentos básicos de segurança, como criação de senhas fortes, recomendações sobre a abertura de e-mails com anexos e que incitam usuários a instalar softwares eoutras armadilhas. 

Essa cartilha deve ser distribuída no formato impresso e deve existir no formato digital na Intranet.

Fonte: http://servidores.ribafs.org/seguranca/44-seguranca-em-redes/17-politica-de-seguranca