Capa de base de datos

El enfoque de múltiples esquemas está bien, pero como siempre, el demonio está en el detalle.

Una de las principales técnicas de aislamiento que se subestiman son los esquemas separados para el propietario de los datos y para que la aplicación web acceda.

• Esto reduce el impacto de cualquier compromiso mediante el uso de privilegios mínimos, eliminando los derechos específicos del usuario de la base de datos de conexión para destruir realmente la base de datos (no se pueden eliminar tablas ni ver datos ocultos).
• Permite que la aplicación oculte datos (detrás de paquetes o vistas).
• Puede usar sinónimos para asignar entre el usuario de la aplicación web y los esquemas del propietario de la tabla.

Una configuración de ejemplo para comenzar.

Data Owner:   MYCLIENT_OWNER
Web User:     MYCLIENT_USER  <- Django points to this schema
Synonyms:     MYCLIENT_USER.TABLE1 -> MYCLIENT_OWNER.TABLE1 (for all required tables)
Grants:       MYCLIENT_USER Granted Select, Insert, Update Delete as appropriate.
Packages:     MYCLIENT_USER Synonyms/Grants for required Packages, Functions and Procedures.

Capa de autenticación

La autenticación de los usuarios se puede aislar en un servidor sso / ldap.

• Esto reduce el impacto de un compromiso de su aplicación web.
• El área de superficie del servicio de autenticación es mucho más pequeña que todo el sistema.
• Pero como siempre, esto es más complicado y generalmente más costoso (aunque solo sea por el tiempo de configuración).

Cifrado simétrico

He escuchado que el almacenamiento de claves de billetera fuera de la base de datos es la mejor práctica aquí, pero una alternativa es ocultar los datos detrás de las funciones como se muestra arriba.

Sospecho que un servicio de cifrado en una caja diferente podría ser una buena alternativa, pero nunca antes había visto este diseño.

Si bien esta es solo una respuesta parcial a su pregunta, puede usar la integración de selinux con postgresql y apache para ejecutar el servicio en diferentes dominios (es decir, el equivalente de usuario en selinux lingo, hablando en serio) y evitar el acceso a los datos ( en el nivel postgresql, por base de datos) desde una instancia del servicio que se ejecuta en apache bajo un dominio diferente.

Otro paso simple sería ejecutar diferentes procesos, uno para cada inquilino. No puede lograr esto con wsgi y asegurarse de que cada proceso sea separado. De esta manera, puede tener 1 base de datos por inquilino y no compartir la contraseña en absoluto.

Hay varias medidas de aislamiento, como lxc, vserver, vm que podrían usarse para restringir todo y la comunicación entre el inquilino, pero eso puede ser una exageración, por lo que depende de usted.

También, para el certificado comodín, es IMHO que debe evitarse ya que si alguien roba el certificado, esta persona podría espiar el tráfico de otros inquilinos (ya que tienen la clave privada en el certificado). Sin un certificado de comodín, alguien solo puede espiar 1 sitio web.

Para el (los) certificado (s) SSL: los certificados comodín tienen varios problemas, el mayor de los cuales es que tienden a ser caros. De hecho, el modelo de negocio de la mayoría de las CA existentes es vender certificados. Un certificado de comodín es un certificado que le permite comprar certificados menos de la CA, por lo que a la CA no le gusta y tratará de recuperar estas pérdidas mediante la asignación de precios al certificado de comodín correspondiente. Además, el navegador no permite certificados de comodín realmente genéricos (incluso si encuentra una CA que acepta venderle un certificado " *.com ", los navegadores web no lo aceptarán).

Por el contrario, los certificados destinados a un solo nombre de host no comodín pueden ser baratos, incluso tan baratos como para ser considerados como líderes de pérdida por algunos CA. Por ejemplo, StartSSL proporciona certificados SSL básicos de forma gratuita.

Un punto relacionado es sobre la gestión de IP. Compartir la misma IP entre dos servidores SSL, que están destinados a usar nombres distintos, sigue siendo difícil: el servidor debe adivinar el nombre con el que se contacta para enviar el certificado correcto. Esto se puede hacer con SNI , que desafortunadamente no es compatible con IE en WinXP (que todavía es una configuración común). El certificado de comodín puede ayudarle o no, según los nombres de dominio que desee admitir (ya que los navegadores rechazan los comodines demasiado genéricos). Probablemente tendrá que comprar un IP adicional, y el costo de estos IP puede exceder el de los certificados.