autorizacion_en_postgresql_script_pdfa.pdf -...

This preview shows page 1 out of 60 pages.

You've reached the end of your free preview.

Want to read all 60 pages?

Unformatted text preview: Autorización en PostgreSQL Documento de apoyo para cursos Charles Clavadetscher 31.08.2015 There is no such thing as perfect security, only varying levels of insecurity. —Salman Rushdie Tabla de materias 1 Introducción 4 2 Conceptos básicos y deniciones 6 3 Acceso a la base de datos 8 4 Acceso a esquemas 11 5 Acceso a otros objetos de una base de datos 17 5.1 5.2 5.3 Tablas, vistas y secuencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Funciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Otros objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Organizar el acceso 6.1 6.2 6.3 6.4 Grupos y herencia . . . . . . . . . Vistas y funciones security definer Privilegios por defecto . . . . . . . Seguridad a nivel de filas . . . . . 17 23 30 32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 39 43 49 7 Agradecimientos 57 8 Anexos 58 8.1 58 Anexo 1: Lista de los privilegios . . . . . . . . . . . . . . . . . . . . . . . . . . Bibliografía 60 3 1 Introducción PostgreSQL ofrece un poderoso sistema de roles para controlar la forma en que los usuarios pueden acceder a los objetos en la base de datos. En el contexto de este artículo, “objetos” son tablas, vistas, secuencias y funciones, es decir las partes de una base de datos con las que interactúa un usuario normal, incluyendo usuarios técnicos compartidos por aplicaciones. Como veremos, antes de poder acceder a ese tipo de objetos, los usuarios necesitan tener privilegios sobre los contenedores en los que se encuentran, en particular bases de datos y esquemas. En este artículo, se asume, por supuesto que el administrador de la base de datos (DBA) tiene acceso superuser a un cluster PostgreSQL. El término “superuser” se refiere a un tipo de usuario muy particular que no está sujeto a los mecanismos de control de acceso. Es decir que tiene todos los derechos sobre todos los objetos en el clúster. A menudo este usuario se llama “postgres”, siendo este el nombre estándar durante la instalación. La instalación de PostgreSQL en sí queda fuera de los límites de este artículo. Hablando sobre acceso a sistemas es imprescindible diferenciar entre autenticación y autorización. Autenticación se refiere al proceso con el cual un usuario se identifica hacia un sistema. Es decir que la cuestión es si el usuario que está intentando acceder el sistema es realmente la persona (o en algunos casos la aplicación) quien afirma ser. Entre los mecanismos habituales para implementar una autenticación los más conocidos son el uso de un nombre de usuario y una palabra clave o de un certificado digital. La autenticación es un proceso que siempre antecede la autorización. Con autorización se entiende el conjunto de actividades que un usuario puede cumplir en un sistema. Otro término habitual y a menudo utilizado como sinónimo de autorización es lista de control de acceso (o su correspondiente en inglés access control list, ACL). En el caso de una base de datos esto resulta ser, por ejemplo, el derecho o privilegio de leer o modificar datos de una tabla. Los ejemplos de código son producidos utilizando psql. psql es el cliente que es instalado por defecto con el software del clúster PostgreSQL. Es posible, claro está, utilizar otros clientes, como por ejemplo pgAdminIII o DbVisualizer. Dado que va a ser importante en este contexto diferenciar los usuarios que ejecutan comandos, la línea de comando tiene el formato: [email protected][=|-][#|>] 4 1 Introducción Donde “=” indica la primera línea de un comando y “-” las siguientes. Los signos “#” y “>” indican respectivamente si el usuario con el nombre username es un superuser o no. Por ejemplo [email protected]=# [email protected]=> quiere decir que el usuario “postgres” está conectado con la base de datos “admin” como superuser y que el usuario “admin” está conectado con la base de datos uci como usuario normal. Cabe mencionar que usuarios pueden tener atributos que le otorguen algunas capacidades especiales, sin ser superuser (p. ej. crear bases de datos o usuarios). Para formatizar la línea de comando de esta manera, entre en psql los comandos reproducidos aquí abajo. \set PROMPT1 '%[email protected]%/=%# ' \set PROMPT2 '%[email protected]%/-%# ' 5 2 Conceptos básicos y deniciones PostgreSQL es un gestor de bases de datos relacionales organizado en diferentes niveles. El nivel más externo es el clúster. En un servidor se pueden instalar varios clústeres del gestor, siempre y cuando cada uno de ellos utilice un puerto diferente. El puerto por defecto es 5432 y es el mismo que asumiremos en este artículo. Un clúster contiene a su vez bases de datos. Una base de datos (database) es una colección de esquemas (schema), quienes a su vez, finalmente contienen los objetos que se conocen habitualmente en el contexto de técnicas de almacenamiento de datos, tales como tablas (table), vistas (view), secuencias (sequence) y así seguido. Es posible isolar cada usuario utilizando una base de datos por cada usuario. Lo mismo se puede alcanzar utilizando un esquema por cada usuario dentro de una sola base de datos. Cuáles de estas soluciones es la más apropiada depende de los requerimientos que se imponen al diseño del sistema. Sistemas que tienen que compartir datos optarán por poner estos datos en uno o más esquemas compartidos por los usuarios mientras que aplicaciones totalmente independientes podrían estar isoladas en sus propias bases de datos. Una base de datos recién creada en PostgreSQL siempre tiene un esquema public1 . Los privilegios por defecto del esquema public permiten a todos los usuarios de crear objetos en él. Lo que a primera vista parece ser, o puede volverse en un problema de seguridad, puede tener ciertas ventajas, como se verá más adelante. En PostgreSQL los usuario existen a nivel de clúster. Es decir que un usuario no está vinculado a una base de datos específica por defecto. El término utilizado en PostgreSQL para usuarios es rol (ROLE). Los roles no son tan solo usuarios sino que pueden ser grupos o ambos. En versiones anteriores a la 8.1, usuarios y grupos eran entidades distintas. Un usuario es un rol con el atributo (LOGIN), es decir con el derecho de conectarse a una base de datos. Cabe mencionar que con este atributo no se especifica para cuáles bases de datos el atributo es válido. Una manera de especificar la base de datos es utilizando el fichero de configuración pg_hba.conf (vease para detalles [RN11] y [Pos15a], Cap. 19.1). En la instalación por defecto la configuración permite el acceso a todos y para todas las bases de datos desde la misma compudadora en donde se encuentra el clúster (localhost). Este hecho no tiene por qué ser negativo. Como veremos más adelante es posible controlar el acceso a 1 De hecho nuevas bases de datos son creadas como copia de la base de datos estándar “template1”. Es decir que si un administrador borró el esquema public de esta base de datos, todas las nuevas bases de datos serán creadas sin este esquema. 6 2 Conceptos básicos y definiciones una base de datos con los mecanismos de autorización. Estos últimos son particularmente útiles en el caso en que un clúster es gestionado físicamente por una entidad externa (p.ej. el departamento de informática de una empresa) y el responsable de las bases de datos sólo tiene acceso al gestor mas no al sistema operativo2 . Autorización en PostgreSQL es, entonces, la posibilidad de otorgar privilegios sobre objetos en un clúster o una base de datos a uno o más usuarios o grupos con el objetivo de minimizar el impacto producido por errores de programación en aplicaciones o por usuarios con objetivos dañinos3 . Antes de entrar en los detalles de la autorización en PostgreSQL cabe mencionar el aspecto de la propriedad sobre objetos. Todos los objetos en un clúster, incluyendo bases de datos, tienen un proprietario. Por diseño el proprietario de un objeto es el usuario que creó el objeto (aunque es posible modificar el proprietario posteriormente) y tiene todos los privilegios que existen sobre este objeto. Usuarios que no son proprietarios de un objeto no tienen ningún privilegio sobre estos, de no ser que el proprietario o un superuser les haya otorgado alguno, ya sea directa o indirectamente por medio de un grupo o de PUBLIC. 2 El centro de investigaciones coyunturales del instituto politécnico federal de Zurich (ETHZ), p.ej. tiene un pequeño grupo de especialistas en informática para gestionar entre otros los datos de las encuestas. El gestor está instalado en un servidor Linux al que este grupo no tiene acceso. El grupo tiene sin embargo acceso al gestor por el puerto 5432 y tiene cuando menos un superuser. 3 Por lo general una empresa tiene confianza en sus empleados. Existen sin embargo cantidades de ejemplos de actividades criminales cometidas precisamente por empleados o por personas ajenas, cuyo acceso es obtenido de usuarios legítimos por medio de ingeniería social. Básicamente los seres humanos suelen ser el anillo más débil de la cadena de seguridad de un sistema informático. 7 3 Acceso a la base de datos El acceso a un clúster de PostgreSQL siempre exige la definición de una base de datos. Vimos en la sección antecedente que un clúster puede tener varias bases de datos. Apenas instalado un clúster tiene tres bases de datos para uso interno del gestor, esto implica que la primera tarea de cada DBA va a ser la creación de una base de datos. Dado que al comienzo no existe todavía ninguna base de datos definida para el uso de usuarios, podemos conectar a la base de datos estándar postgres. Si Usted no tiene todavía un superuser para la gestión del clúster, tendrá que conectarse como el superuser postgres. Es recomendable crear un superuser diferente de postgres para simplificar la gestión1 y un usuario con privilegios CREATEDB y CREATEROLE para la gestión de las bases de datos. Con este último podemos crear una base de datos que nos servirá para ilustrar con ejemplos los conceptos descritos. $ sudo -u postgres psql [email protected]=# CREATE ROLE admin CREATEDB CREATEROLE LOGIN PASSWORD 'xxx'; [email protected]=# \c - admin [email protected]=> CREATE DATABASE uci; [email protected]=> \c uci [email protected]=> La siguiente tarea consisten en crear unos usuarios que puedan utilizar la base de datos uci. La creación de usuarios en PostgreSQL requiere un superuser o un usuario con el atributo CREATEROLE. El comando SQL para crear un rol es estándar y su forma general puede averiguarse en la documentación oficial de PostgreSQL [Pos15a] o en un terminal psql con el comando \h CREATE ROLE. [email protected]=> CREATE ROLE user1 LOGIN PASSWORD 'xxx'; [email protected]=> CREATE ROLE user2 LOGIN PASSWORD 'xxx'; [email protected]=> \du List of roles Role name | Attributes | Member of -------------------+--------------------------+--------------------------admin | Create role, Create DB | {} user1 | | {} user2 | | {} 1 Esa es una medida de comodidad. Si Usted prefiere puede conectarse siempre como postgres 8 3 Acceso a la base de datos Hasta este punto no hemos tomado ninguna medida para modificar la configuración por defecto de la base de datos. A nivel de base de datos esto quiere decir que todos los usuarios existentes en el clúster pueden conectarse a uci. Es posible ver los privilegios configurados para una base de datos con el comando \l (lista de las bases de datos). Ÿ [email protected]=> \l List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges ---------------+-----------+----------+-------------+-------------+--------------------uci | admin | UTF8 | en_US.UTF-8 | en_US.UTF-8 | El campo con los privilegios está vacío lo que significa que los valores por defecto están en uso. Por lo general los privilegios por defecto se refieren a PUBLIC o sea privilegios otorgados a todos los usuarios en el clúster. El encontrar cuáles existen efectivamente puede ser una tarea algo difícil como leer toda la documentación o buscar informaciones en internet. Una manera más eficiente es utilizar las funciones presentes en cada instalación de PostgreSQL para este fin ([Pos15a] Tab. 9-57, p. 284). La forma más general de estas funciones es2 : has_<object_type>_privilege(user, object_name, privilege); Todas estas funciones retornan un valor boolean (t, f) indicando si el usuario tiene o no el privilegio indicado sobre el objeto. Para averiguar si todos los usuarios pueden conectarse a la base de datos, podemos entonces ejecutar la función como sigue. [email protected]=> SELECT has_database_privilege('public', 'uci', 'connect'); has_database_privilege -----------------------t En un clúster con varias bases de datos podemos limitar el acceso quitándole el privilegio a PUBLIC y otorgándoselo a nuestros usuarios. [email protected]=> REVOKE ALL ON DATABASE uci FROM PUBLIC; [email protected]=> GRANT CONNECT ON DATABASE uci TO user1; Si averiguamos ahora quiénes pueden conectar con la misma función de antemano observamos lo siguiente. 2 Según el objeto investigado pueden haber más parámetros. El conjunto de funciones existe también sin el parámetro user. En estos casos user es implicitamente el usuario que esta conectado en la base datos y que ejecuta la función. 9 3 Acceso a la base de datos [email protected]=> SELECT has_database_privilege('public', 'uci', 'connect') AS "public", has_database_privilege('user1', 'uci', 'connect') AS "user1", has_database_privilege('user2', 'uci', 'connect') AS "user2"; public | user1 | user2 --------+-------+------f | t | f PUBLIC no puede conectarse y por ende tampoco user2 al que no le hemos otorgado el privilegio. Ahora es obvio que si un usuario no puede conectarse a una base de datos, tampoco puede ocasionar daños. Así tan solo con esta medida ya mejoramos la seguridad de nuestra base de datos considerablemente3 . Además de CONNECT el nivel de base de datos conoce dos privilegios más: TEMPORARY: Permite al usuario crear tablas temporales. Estas tablas sólo existen durante la sesión y desaparecen una vez que el usuario se desconecta de la base de datos. CREATE: Permite al usuario crear esquemas en la base de datos. Es importante no confundir el significado de CREATE en diferentes niveles. Como veremos más adelante un privilegio con el mismo nombre existe a otros niveles, pero con otro significado. 3 De hecho un usuario tiene la posibilidad de otorgar su rol a otros roles, otorgandole con lo mismo todos sus privilegios, incluido el de conectarse a todas las bases de datos, a las que el usuario tiene acceso. Cabe notar que este comportamiento coincide con la documentación y no parece ser considerado un error por la comunidad. En la sección sobre la organización del accesso volveremos sobre este punto. 10 4 Acceso a esquemas Un esquema se puede entender como una sección dentro de una base de datos. Puesto que todos los demás objetos de una base de datos están contenidos en un esquema es imprescindible que haya al menos uno. Cuando se crea una base de datos, esa tiene por defecto un esquema public. Como el nombre dice el esquema es creado de tal manera que todos los usuarios pueden crear otros objetos en ello. Los privilegios que existen a nivel de esquema diferencian entre la posibilidad de crear nuevos objetos (CREATE) y utilizar objetos existentes (USAGE). Para ver quién tiene cuál privilegio sobre un esquema se pueden utilizar las funciones que mencionamos en la sección antecedente o el comando \dn+. [email protected]=> \dn+ List of schemas Name | Owner | Access privileges | Description --------+----------+----------------------+-----------------------public | postgres | postgres=UC/postgres+| standard public schema | | =UC/postgres | La lista de acceso nos dice que los usuarios postgres y PUBLIC tienen privilegios tanto USAGE como CREATE sobre el esquema public. La segunda línea no menciona un usuario antes de “=” lo que es equivalente a PUBLIC. Después del signo “/” en cada línea vemos el usuario quien ha otorgado el privilegio - en este caso postgres. Además vemos que el propietario es también postgres. La implicación de esto es que nuestro usuario admin no tienen suficientes privilegios para modificar los privilegios de acceso al esquema. Un superuser o el propietario del esquema podrían hacerlo. Por lo general la existencia de un esquema con estas características no es necesariamente un problema. De hecho hasta hay circunstancias en donde un esquema public tiene ventajas, por lo menos en cuanto se refiere al privilegio USAGE. Por ejemplo, funciones, extensiones, operadores o hasta vistas compartidas por varios usuarios podrían implementarse en este esquema. Lo que sí vale la pena limitar es la creación de nuevos objetos. De esta manera podemos crear un espacio controlado en el que solo unos cuantos pueden escribir y todos pueden leer. El primer paso para alcanzar este objetivo es hacer las modificaciones del acceso como acabamos de mencionar por medio de un superuser. La forma general de los comandos para otorgar y revocar privilegios se muestra aquí seguido. 11 4 Acceso a esquemas GRANT <list of privileges> ON [<object type] <list of object names> TO <list or roles>; REVOKE <list of privileges> ON [<object type] <list of object names> FROM <list or roles>; La lista de privilegios disponibles depende del objeto indicado en object type y los elementos tienen que estar separados por comas. La mención de object type se puede omitir si el objeto es una tabla o una vista. Los elementos de lista de objetos también tienen que estar separados por comas, así como los de la lista de roles. Es lógico que los objetos en la lista tienen que ser del mismo tipo. Existen además opciones para otorgar o revocar privilegios sobre todos los objetos de un mismo tipo en un esquema. Es posible permitirle a un usuario al que se le haya otorgado un privilegio de otorgar a su vez estos privilegios a otros usuarios usando la opción WITH GRANT OPTION inexistente por defecto. Esta característica puede ser útil en algunas ocasiones, mas por lo general no es necesaria si el DBA quiere mantener el control de acceso centralizado y más estricto. Todas las opciones para los comandos GRANT y REVOKE están documentadas en [Pos15a], GRANT, pp. 1522-1528. La sinopsis del comando se puede obtener también en psql con el comando \h [GRANT|REVOKE]1 . Con estos conocimientos podemos ahora modificar el acceso al esquema public con los siguientes comandos. [email protected]=# REVOKE CREATE ON SCHEMA public FROM PUBLIC; [email protected]=# GRANT USAGE, CREATE ON SCHEMA public TO admin; [email protected]=# \dn+ List of schemas Name | Owner | Access privileges | Description --------+----------+----------------------+-----------------------public | postgres | postgres=UC/postgres+| standard public schema | | =U/postgres +| | | admin=UC/postgres | Después vamos a crear un nuevo esquema en donde nuestros usuarios van a poder trabajar. Llamaremos al esquema uci y vamos a otorgar a user1 y user2 todos los privilegios. El usuario admin tiene el privilegio CREATE sobre la base de datos, así que puede crear esquemas. [email protected]=> CREATE SCHEMA uci; [email protected]=> GRANT ALL ON SCHEMA uci TO user1, user2; 1 Con el comando \h <command> pueden obtenerse sinopsis para todos los comandos existentes. 12 4 Acceso a esquemas [email protected]=> \dn+ uci List of schemas Name | Owner | Access privileges | Description ------+-------+-------------------+------------uci | admin | admin=UC/admin +| | | user1=UC/admin +| | | user2=UC/admin | En lugar de otorgar los privilegios a cada uno de los usuarios, hubieramos podido otorgarselos a PUBLIC de tal manera que también nuevos usuarios todavía no presentes en el clúster, tuvieran el privilegio por defecto2 . Antes de seguir con nuestras explicaciones tenemos que abrir un paréntesis sobre el tema visibilidad. Todos los objetos en una base de datos se encuentran en un esquema. Por esto se pueden identificar con una calificación completa según la convención: [<dat...
View Full Document

  • Fall '19
  • Test, PostgreSQL, Lógica, Base de datos relacional

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture