Políticas y Plan de seguridad para una base de datos.docx

Políticas y Plan de seguridad para una base de datos.

Es la capacidad del Sistema para proteger Datos, Servicios y Recursos de usuarios no autorizados. El fin de la seguridad es garantizar la protección o estar libre de todo peligro y/o daño, y que en cierta manera es infalible. Confidencialidad: nos dice que los objetos de un sistema han de ser accedidos únicamente

 por elementos elementos autorizados autorizados a ello, y que esos elementos elementos autorizados autorizados no van a convertir esa esa información en disponible para otras entidades. Integridad: significa que los objetos sólo pueden ser modificados por elementos autorizados,

y de una manera controlada. Disponibilidad: indica que los objetos del sistema tienen que permanecer accesibles a

elementos autorizados; es el contrario de la negación de servicio.

•

En las grandes organizaciones administrar la seguridad de los datos es una tarea compleja.

•

La apertura de las bases de datos corporativas a internet aumenta los riesgos de ataques.

•

Los manejadores de bases de datos comerciales estas limitados en cuanto a modelos de seguridad

Seguridad en bases de datos comerciales •

Privilegios del sistema son administrados por un super-usuario.

•

Privilegios sobre objetos son en principio responsabilidad del propietario

•

La introducción de roles facilita la administración

•

La autenticación de usuarios y maquinas y servicios en la red introduce nuevas necesidades

CREAR Y GESTIONAR CUENTAS DE USUARIO DE BASE DE DATOS. La cuenta debe ser especificada por su nombre y autentificada por algún medio. La manera que la cuenta fue creada fijara un rango de atributos para la sesión, algunos de los cuales puede ser cambiado posteriormente mientras la sesión está en curso. Existe una serie de cuentas creadas en el momento de creación de la Base de Datos y el DBA generalmente creara muchas más posteriormente. En algunas aplicaciones, cada usuario tendrá su propia cuenta de usuario de Base de Datos. Esto significa que la Base de Datos es plenamente consciente a quien pertenece cada sesión realmente. Este modelo de seguridad funciona bien para pequeñas aplicaciones pero es a menudo impráctico para grandes sistemas con muchas cientos o miles de usuarios. Para grandes sistemas, muchos usuarios se conectarán con la misma cuenta de usuario. Este modelo se basa en la aplicación para asignar el usuario final real a una cuenta de usuario de Base de Datos, y se puede hacer de la seguridad a nivel usuario y auditoria más complejo. Este capítulo se asume que conocen a cada usuario a la Base de Datos; todos ellos tienen su propia cuenta de usuario.

ATRIBUTOS DE LAS CUENTAS DE USUARIO.

Una cuenta de usuario tiene una serie de atributos definido en la cuenta en tiempo de creación. Estos serán aplicados a las sesiones que se conectan a la cuenta, aunque algunos puede ser modificados por la sesión o el DBA mientras la sesión esta ejecutándose, estos atributos son:

• • • • • • •

Username. Authentication Method. Default Tablespace. Tablespace Quotas. Temporary Tablespace. User profile. Account Status.

Todos esto debe ser especificado al crear el usuario, aunque sólo nombre de usuario y métodos de autenticación son obligatorios, los demás tienen valores por defecto.

USERNAME

El username debe ser único en la Base de Datos y debe ajustarse por ciertas reglas. Un username debe iniciar con una Letra, debe ser no más de 30 caracteres, y consiste de solo letras, dígitos y el carácter dólar ($) y guion bajo (_). Un username no puede ser una palabra reservada. Las letras son case sensitive pero serán convertidas automáticamente a mayúsculas. Todas estas reglas (con la excepción de la longitud) puede ser evadidas sin el username es especificado dentro de comillas dobles, como lo muestra en la Figura 8-1. En el primer ejemplo de la figura, un username JOHN es creado. Este fue ingresado en minúsculas, pero se han convertido a mayúsculas, como puede verse en la primera consulta. El segundo ejemplo utiliza doble comillas para crear el usuario con un nombre en

minúsculas. El tercer y cuarto ejemplo utilizada doble comillas para eludir las reglas en caracteres y palabras reservadas; ambos fallarían sin las comillas dobles. Si un username incluye letras en minúsculas o caracteres no validos o una palabra reservada, entonces las comillas dobles deben ser siempre utilizadas para conectarse a la cuenta posteriormente.