Uso de Schemas en SQL Server 2005

En SQL Server 2005 cada esquema es un espacio de nombres distinto que existe de forma independientemente del usuario de base de datos que lo creó. Es decir, un esquema simplemente es un contenedor de objetos (vistas, tablas, stored procedures, etc).

Algunas características importantes de los schemas son:

• La propiedad de los esquemas y de los elementos que se pueden proteger (con ámbito de esquema es transferible): ALTER AUTHORIZATION (Transact-SQL).
• Es posible mover objetos entre esquemas: ALTER SCHEMA (Transact-SQL).
• Un mismo esquema puede contener objetos que sean propiedad de varios usuarios de base de datos.
  Varios usuarios de base de datos pueden compartir un mismo esquema predeterminado.
• Se pueden administrar los permisos sobre esquemas y sobre elementos que se pueden proteger con mayor precisión que en las versiones anteriores: GRANT (permisos de esquema de Transact-SQL) y GRANT (permisos de objeto de Transact-SQL).
• Cualquier entidad de seguridad de base de datos puede ser propietaria de un esquema. Esto incluye funciones y funciones de aplicación.
• Es posible eliminar un usuario de base de datos sin necesidad de eliminar objetos en un esquema correspondiente.
• El código escrito para las versiones anteriores de SQL Server puede producir resultados incorrectos si el código considera que los esquemas son equivalentes a los usuarios de base de datos.
• Las vistas de catálogo diseñadas para las versiones anteriores de SQL Server pueden producir resultados incorrectos. Esto incluye a sysobjects.

Realicé un par de pruebas referidas al uso de Schemas en una aplicación multitenant.

1 - Crear el inicio de sesión
2 - Crear el usuario de la base de datos
3 - Crear el schema en la base de datos
4 - Asignar el usuario creado al schema
5 - Asignar permisos a nivel de schema
6 - Las tablas/procedimientos que se agreguen al schema van a tener esos permisos

Notas:
- Los SP y Tablas tienen que estar dentro de cada schema para facilitar la seguridad

Create Table Schema1.Tabla1 ( Texto Varchar(10) )

Insert Into Schema1.Tabla1 Values ( 'Prueba' )

Create Procedure Schema1.usp2

- Si el usuario tiene como default un schema, entonces los SP no se tienen que ejecutar con el nombre de ese schema

Exec usp1 (el Usuario tiene como default Schema1 => el motor de base de datos busca usp1 dentro de ese schema. Si no lo encuentra busca dentro del schema dbo y sino da error)

- Dentro de los SP no hace falta usar el schema de la tabla: Esto permite que el mismo script se pueda recompilar en cada schema si tener que cambiar las intrucciones

Create Procedure Schema1.usp2

As

Select * From Tabla1 --> Accede a Schema1.Tabla1

Create Procedure Schema2.usp2

As

Select * From Tabla1 --> Accede a Schema2.Tabla1

Inspeccionando el File System con FileSystemWatcher (.Net Framework)

Fuente: http://msdn.microsoft.com/es-es/library/system.io.filesystemwatcher.aspx
Artículo: http://articles.techrepublic.com.com/5100-10878_11-6165137.html

La clase FileSystemWatcher escucha las notificaciones de cambio del sistema de archivos y provoca eventos cuando cambia un directorio o un archivo de un directorio.

Existen varios tipos de cambios que puede inspeccionar en un directorio o archivo. Por ejemplo, es posible inspeccionar cambios en los atributos (Attributes), la hora y la fecha de última escritura (LastWrite) o el tamaño (Size) de archivos o directorios.

Es posible inspeccionar el cambio de nombre, la eliminación o la creación de archivos o directorios.

El sistema operativo Windows notifica al componente los cambios realizados en los archivos en un búfer creado por el objeto FileSystemWatcher. Si se producen muchos cambios en poco tiempo, el búfer se puede desbordar. Como consecuencia, el componente pierde el control de los cambios realizados en el directorio y sólo puede proporcionar una notificación general.

Usabilidad – Diseño de sitios web

Este es un resúmen del libro "Usabilidad - Diseño de sitios web" de Jakob Nielsen.

Sus datos en Wikipedia:
Jakob Nielsen (nacido en 1957, en Copenhague, Dinamarca) es una de las personas más respetadas en el ámbito mundial sobre usabilidad en la web. Este ingeniero de interfaces obtuvo su doctorado en diseño de interfaces de usuario y ciencias de la computación en la Universidad Técnica de Dinamarca. Su andadura profesional le ha hecho pasar por empresas como Bellcore, IBM y Sun Microsystems. Actualmente figura como co-fundador de Nielsen Norman Group con Donald Norman, otro experto en usabilidad.
Su trayectoria se inició en 1997 cuando escribió dos breves artículos sobre cómo preparar los textos. Los títulos de estos artículos fueron "Sea breve! (escribir para la web)" y "Cómo leen los usarios en la web". Las ideas de los artículos de Nielsen se citan en muchos otros artículos que ofrecen pautas sobre cómo escribir para la web y mejorar su usabilidad.

Los 10 errores de seguridad más comunes en ASP .NET

Fuente: http://www.chicodotnet.com/2007/05/los-10-errores-de-seguridad-ms-comunes.html

A continuación les enumeraré los 10 errores más comunes que se cometen cuando desplegamos una aplicación ASP.NET, les explico la razón por la que esos errores pueden ser peligrosos y les indico la manera más adecuada de corregirlos. Espero que les sea de utilidad:

1. Custom Errors deshabilitado

En el archivo Web.config de nuestras aplicaciones ASP.NET la etiqueta custom Errors se encuentra comentada por defecto cuando creamos una nueva aplicación, esto deja el valor RemoteOnly por defecto. Sin embargo muchas veces cuando estamos probando el software en un servidor remoto hay ocasiones en las que por comodidad dejamos el valor en Off, esto permite a todos los usuarios que ingresan a las páginas de la aplicación enterarse de los errores que suceden en la aplicación, al momento de depurar. Sin embargo esto no es bueno al momento de desplegar, puesto que cualquiera puede también ver pedazos de código cuando hay alguna falla. Lo más adecuado es prender la opción, lo cual puedes aprovechar para mostrar errores más amigables al usuario, esto incluso te sirve para optimizar para buscadores ;-). Un ejemplo de cómo prender esta opción es el siguiente:

2. Dejar habilitado el seguimiento de la página

El seguimiento de página (tracing) normalmente se encuentra apagado, sin embargo también por cuestiones de depuración puede encenderse, la forma más sencilla es hacerlo en el archivo que estemos trabaando utilizando la etiqueta Trace en la declaración de página del formulario en el que estamos trabajando, sin embargo una buena práctica es hacerlo de modo sólo local (por si necesitamos que el seguimiento esté de todos modos encendido) desde el archivo Web.config y luego apagarlo al desplegar, hacerlo de esta manera encenderá el seguimiento en todos los formularios del proyecto y evitará que se nos olvide apagarlo, lo haces con la etiqueta trace de la siguiente manera:

3. Depuración habilitada

Tener esta opción habilitada, afecta al rendimiento de la aplicación, muestra errores más detallados y sólo debe encenderse mientras estamos desarrollando precisamente para el proceso de depuración, la forma correcta de desplegar es dejando en el archivo Web.config la opción de depuración apagada, otra buena práctica en el caso de las aplicaciones ASP.NET creadas con Visual Basic es dejar las opciones explicit y strict encendidas, de este modo hacemos código mejor construído (léase 100 veces: no garantiza que perfectamente construído, pero ayuda). La forma de configurar esto es de la siguiente manera:

4. Cookies suplantables

Los hackers pueden realizar ataques de XSS (Cross Site Scripting) cuando las cookies son accesibles del lado del cliente, intentan este tipo de ataques cuando se encuentran por ejemplo con saludos del tipo Hola ChicoDotNet en las páginas en la que se inicia sesión agregando su propio código del lado del cliente. Esto puedes dificultarlo fácilmente -valga la redundancia- cuando enciendes las cookies HttpOnly, esto se hace de la siguiente forma:

5. Sesión sin cookies

Para hacer disponible una aplicación a los clientes que no aceptan cookies se tiene la opción de colocar la sesión en la URL, muchos las utilizan por defecto para no complicarse asignando a la etiqueta sessionState el atributo cookieless con el valor UseUri, sin embargo esto abre la posibilidad de suplantar a un usuario determinado visitando la dirección que contiene la sesión, esto puedes evitarlo almacenando la sesión en una cookie que expire pronto, pero queda el problema de los clientes que no aceptan cookies, para ellos necesitas enviar la sesión en la URL, ¿Cómo resolver eso?, enciende la autodetección, eso hará que los clientes que las acepten las usen y los que no las reciban en la URL, se hace con el siguiente código en Web.config:

6. No emitir cookies seguras

Las cookies seguras se emiten utilizando SSL, esto hace que la transmisión se realice en forma encriptada, para configurar SSL en IIS puedes ver el artículo en MSDN que te indica como hacerlo en IIS 6.0, en el caso de IIS 7.0 es mucho más sencillo como ya había mencionado anteriormente. Para la configuración de la transmisión de las cookies por medio de SSL utiliza el siguiente código:

7. Sesiones alargables

Para alargar el tiempo de expiración de una sesión se utiliza el atributo slidingExpiration de la etiqueta forms, esto da mayor tiempo a los hackers para suplantar a un usuario determinado, la recomendación es dejarlo como se indica a continuación:

8. Uso de cookies de autenticación por defecto

El nombre por defecto de una cookie de autenticación es .ASPXAUTH, una buena práctica es nombrar estas de manera distinta, por ejemplo utilizando un GUID, de esta manera evitamos que alguien que se firme en una aplicación del servidor y pueda modificar la cookie para firmarse en otra utilizando la primera cookie obtenida. Este valor se pondría en el lugar que indico a continuación:

9. Paso de variables por URL

El uso de Request.Querystring("variable") para operaciones de negocios debe ser evitado, sobre todo si se trata de información sensible, se debe preferir el uso de variables de sesión o de ViewState, de otro modo cualqueir persona con algo de conocimientos de programación podría hacer ataques de XSS o de SQL injection.

10. Credenciales o cadenas de conexión en Web.config

Esto es lo más común de la lista, debe evitarse a toda costa el guardar usuarios y contraseñas en etiquetas credentials y cadenas de conexión o configuraciones de aplicación en Web.config sin antes cifrarlas adecuadamente. O. K., IIS evita la descarga de estos archivos de forma remota, pero ¿Qué me dicen de los del hosting? Hay que tener mucho cuidado con esto.