<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Segurança de Bancos de Dados</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REL="HOME"
TITLE="Manual do PHP"
HREF="index.html"><LINK
REL="UP"
TITLE="Segurança"
HREF="security.html"><LINK
REL="PREVIOUS"
TITLE="Segurança do Sistema de Arquivos"
HREF="security.filesystem.html"><LINK
REL="NEXT"
TITLE="Conectando com o Banco de Dados"
HREF="security.database.connection.html"><META
HTTP-EQUIV="Content-type"
CONTENT="text/html; charset=UTF-8"></HEAD
><BODY
CLASS="chapter"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Manual do PHP</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="security.filesystem.html"
ACCESSKEY="P"
>Anterior</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="security.database.connection.html"
ACCESSKEY="N"
>Próxima</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="chapter"
><H1
><A
NAME="security.database"
>Capítulo 27. Segurança de Bancos de Dados</A
></H1
><DIV
CLASS="TOC"
><DL
><DT
><B
>Índice</B
></DT
><DT
><A
HREF="security.database.html#security.database.design"
>Desenhando Bancos de Dados</A
></DT
><DT
><A
HREF="security.database.connection.html"
>Conectando com o Banco de Dados</A
></DT
><DT
><A
HREF="security.database.storage.html"
>Modelo de Armazenamento Criptografado</A
></DT
><DT
><A
HREF="security.database.sql-injection.html"
>Injeção de SQL</A
></DT
></DL
></DIV
><P
> Hoje em dia, bancos de dados são componentes cardinais de qualquer aplicação web
permitindo que websites forneçam conteúdo dinâmico variável. uma ves que informação muito
sensível e/ou secreta pode ser guardada em um banco de dados, proteger seus
bancos de dados é essencial.
</P
><P
> Para retirar ou guardar qualquer informação, você precisa conectar-se ao banco
de dados, enviar uma consulta (query) legítima, puxar o resultado e fechar a conexão.
Atualmente, a linguagem mais usada para consulta nessa interação é a
Structured Query Language (SQL). Veja como um atacante pode <A
HREF="security.database.sql-injection.html"
>manipular uma consulta SQL</A
>.
</P
><P
> Como você pode perceber, o PHP não pode proteger seu banco de dados sozinho. As
seções a seguir tentam ser uma introdução básica em relação a como
acessa e manipular banco de dados a partir de scripts PHP.
</P
><P
> Mantenha em mente essa regra simples: defesa em profundidade. Quanto mais lugares
você faz ações para aumentar a proteção do seu banco, menor a probabilidade
de um atacante ter suceso em expor ou abusar de qualquer informação
guardada. Bom desenho do esquema (schema) de banco de dados e da aplicação
lida com seus maiores medos.
</P
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="security.database.design"
>Desenhando Bancos de Dados</A
></H1
><P
> O primeiro passo é sempre criar o banco de dados, a não ser que você queira
usar um de terceiros. Quando um banco de dados é criado, ele é
atribuído a um dono, que executou os comandos de criação. Normalmente, só
o dono (ou um superusuário) pode faz algo com os objetos naquele
banco de dados, e para permitir que outros usuários usem, privilégios devem
ser concedidos.
</P
><P
> Aplicações nunca devem conecta ao banco de dados como seu dono ou um
superusuário, porque esses usuários podem executar qualquer consulta que
quiserem, por exemplo, modificar o esquema (ex.: destruindo tabelas) ou
removendo seu conteúdo completamente.
</P
><P
> Você pode criar usuários de bancos de dados diferentes para cada aspecto
da sua aplicação com direitos muito limitados aos objetos do banco de dados.
Apenas os privilégios mais necessários devem ser concedidos, e evitar que o
mesmo usuário possa interagir com o banco de dados em casos de uso diferentes. Isso
significa que se invasores conseguirem acessar seu bando usando credenciais da sua
aplicação, eles só podem afetar o banco tanto quanto sua aplicação.
</P
><P
> Encorajamos não implementar toda a lógica de negócio na aplicação
web (ex.: seu script). Ao invés disso, faça parte no esquema do banco,
usando view, triggers ou rules. Se o sistema evoluir, crescerá a vontade de
criar novas maneiras de usar o banco, e você terá que reimplementar a lógica
em cada cliente separado do banco. Além disso, triggers podem ser usados
para lidar com certos campos de maneira automática e transparente, o que
permite dar informações quando depurar problemas com sua aplicação ou
rastreando transações.
</P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="security.filesystem.html"
ACCESSKEY="P"
>Anterior</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Principal</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="security.database.connection.html"
ACCESSKEY="N"
>Próxima</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Segurança do Sistema de Arquivos</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="security.html"
ACCESSKEY="U"
>Acima</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Conectando com o Banco de Dados</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
