CAPTULO XIII

Segregao de Ambiente e Funes

Introduo
Um dos muitos itens que constam na norma a segregao de funo.
A segregao de funo pode ser explicada com um exemplo simples: um
DBA cria a base dados, um programador ir criar os programas que trabalham
com esta base, mas ser o usurio que ir popular a base. Nem o DBA e nem o
programador poder ter permisses para alterar as informaes cadastradas pelo
usurio do sistema.
A segregao de ambientes, consiste em trabalhar com pelo menos 3
ambientes idnticos em termos de configurao de mquina (ou no mnimo, em
termos de funcionalidade) e software, estes ambientes so chamados
popularmente de Desenvolvimento, Homologao e Produo. Teoricamente, o
programador somente tem acesso total no ambiente de desenvolvimento. O
processo de transferncia de software de um ambiente para outro, deve ser
realizada por uma pessoa ou rea especfica e deve estar o mais bem
documentado possvel.
A proteo destes ambientes simples, o desenvolvedor somente tem
acesso ao ambiente de desenvolvimento (baseando em autenticao do prprio
sistema operacional, com login e senha) e ele no pode ter o domnio de nenhuma
chave de acesso aos ambientes de homologao e produo (no pode ter
acesso ao sistema operacional e nem ao banco de dados destes ambientes).
Caso exista a necessidade de um acesso, deve ser criada uma chave temporria
de acesso e todas as informaes (comandos de sistema operacional e banco de
dados) devem ser registradas.
A empresa deve ter uma norma rgida para tentativas de acesso indevidas e
detectadas. Deve-se estabelecer uma poltica clara e que deve ser cumprida. Uma
sugesto de punio uma multa para o funcionrio infrator com possvel
demisso no caso de re-incidncia.
Vamos ver os conceitos a seguir, extrados diretamente da norma.

Segregao de Funes
A segregao de funes um mtodo para reduo do risco de mau uso
acidental ou deliberado dos sistemas. Convm que a separao da administrao
ou execuo de certas funes, ou reas de responsabilidade, a fim de reduzir
oportunidades para modificao no autorizada ou mau uso das informaes ou
dos servios, seja considerada.
As pequenas organizaes podem considerar esse mtodo de controle
difcil de ser implantado, mas o seu princpio deve ser aplicado to logo quanto
possvel e praticvel. Onde for difcil a segregao, convm que outros controles,
como a monitorao das atividades, trilhas de auditoria e o acompanhamento

gerencial sejam considerados. importante que a auditoria da segurana

permanea como uma atividade independente.
Convm que sejam tomados certos cuidados para que as reas nas quais a
responsabilidade seja apenas de uma pessoa no venha a ser alvo de fraudes
que no possam ser detectadas. Recomenda-se que o incio de um evento seja
separado de sua autorizao. Recomenda-se que os seguintes controlem sejam
considerados:
9 importante segregar atividades que requeiram cumplicidade para a
concretizao de uma fraude, por exemplo, a emisso de um pedido de
compra e a confirmao do recebimento da compra.
9 Se existir o perigo de conluios, ento necessrio o planejamento de
controles de modo que duas ou mais pessoas necessitem estar envolvidas,
diminuindo dessa forma a possibilidade de conspiraes.

Separao dos ambientes de desenvolvimento e de produo

A separao dos ambientes de desenvolvimento, teste (homologao) e
produo so importantes para se alcanar segregao de funes envolvidas.
Convm que as regras para a transferncia de software de desenvolvimento para
produo sejam bem definidas e documentadas.
As atividades de desenvolvimento e teste podem causar srios problemas,
como, por exemplo, modificaes no autorizadas total ou parcialmente de
arquivos ou do sistema. Convm que seja avaliado o nvel de separao
necessrio entre o ambiente de produo e os ambientes de teste e de
desenvolvimento, para prevenir problemas operacionais. Convm que uma
separao semelhante tambm seja implementada entre as funes de
desenvolvimento e de teste. Nesse caso, necessria a existncia de um
ambiente confivel e estvel, no qual possam ser executados os testes e que seja
capaz de prevenir o acesso indevido do pessoal de desenvolvimento.
Quando o pessoal de desenvolvimento e teste possui acesso ao ambiente
de produo, eles podem introduzir cdigos no testados ou autorizados, ou
mesmo alterar os dados reais do sistema. Em alguns sistemas essa capacidade
pode ser mal utilizada para a execuo de fraudes, ou introduo de cdigos
maliciosos ou no testados. Esse tipo de cdigo pode causar srios problemas
operacionais. O pessoal de desenvolvimento e os encarregados dos testes
tambm representam uma ameaa a confidencialidade das informaes de
produo.
As atividades de desenvolvimento e teste podem causar modificaes no
intencionais no software e a informao se eles compartilham o mesmo ambiente
computacional. A separao dos recursos de desenvolvimento, de teste e
operacionais dessa forma bastante desejvel para a reduo do risco de
modificao acidental ou acesso no autorizado ao software operacional e dados
dos negcios. Recomenda-se que os seguintes controles sejam considerados:

9 Convm que o software de desenvolvimento e o software de produo

sejam, sempre que possvel, executados em diferentes processadores, ou
diferentes domnios ou diretrios.
9 Convm que as atividades de desenvolvimento e teste ocorram de forma
separada, tanto quanto possvel.
9 Convm que compiladores, editores e outros programas utilitrios no
sejam acessveis a partir do ambiente de produo, quando isso no for
uma necessidade.
9 Convm que o processo de acesso ao ambiente de produo seja diferente
do acesso de desenvolvimento para reduzir a possibilidade de erro.
Convm que os usurios sejam incentivados a usar diferentes senhas para
esses ambientes e as telas de abertura exibam mensagens de identificao
apropriadas.
Convm que o pessoal de desenvolvimento receba senhas para acesso ao
ambiente de produo, e de forma controlada e apenas para suporte a sistemas
no ambiente de produo. Convm que sejam utilizados controles que garantam
que tais senhas sejam alteradas aps o uso.