Frase celebre en el mundo de la seguridad y los sistemas: Tu sistema será tan bueno y/o seguro como las habilidades de administración que poseas sobre esa materia...
Poco más que hablar sobre esto. Atrás queda la época de Windows Xp sp2,sp3, Windows 2003. Atrás quedan los "zero days para cualquier windows version 32bits". Estamos en 2013. Windows Server 2008 tiene 5 años, pero admitimos sus procedimientos relacionados con la seguridad como válidos.
Vamos a empezar por comentar una reglas básicas o leyes que Microsoft publicó en Noviembre de 2000 y aún siguen siendo más que válidas.
Ley # 1: Nadie cree que algo malo le puede suceder a ellos, hasta que lo sucede.
A no ser que trabajes en una central nuclear, gobierno, educación, sanidad y similares no eres objetivo de un ataque informático ...FALSO. Hoy en día todos podemos sufrir un ataque informático simplemente porque hay gente buscando fallos para comprometer sistemas, For Fun. Pero en las organizaciones hay despidos, empleados descontentos, proveedores descontentos, competencia. Todo lo que se conecta a Internet es susceptible de ser hackeado, y por lo tanto asegurado.
Ley # 2: Seguridad sólo funciona si el modo seguro también pasa a ser la forma más fácil
Cuando buscamos soluciones para proteger los activos en nuestra organización, no debemos pensar como técnicos, e implementar una solución basada en doble firma, con claves de más de 15 caracteres, tarjeta de claves RSA, y solo a unas horas del día.Debemos establecer políticas y mecanismos acordes con la Misión y Visión de la empresa. Poco éxito va a tener una medida de ese tipo, en un ambiente con poco grado de conocimiento informático ( el típico trabajador de la vieja escuela que aún piensa que van a volver las máquinas de escribir, o simplemente no tiene aptitud para las nuevas tecnologías). Hay que facilitar el trabajo a los usuarios.
Ley # 3: Si no se mantienen al día con las actualizaciones de seguridad, la red no será tuyo para siempre
Las actualizaciones de seguridad dan mucho miedo a los administradores de sistemas ( por la cantidad de problemas que creaban en el mundo NT sobre todo en temas de compatibilidad) y a los usuarios ( el vecino te instala el Windows pirata pero te dice que nunca actualices) Cuando compras un pc con S.O. legal, sigues con tus prácticas.
Imagínate que vas al médico, y te detecta una enfermedad la cual no tenía síntomas aparentes. Te prescribe un medicamento para solucionarlo, y te indica que si no lo tomas, en un futuro esa enfermedad te va a matar. ¿qué haces? ¿te tomas las pastillas?
Ley # 4: No sirve de mucho para instalar parches de seguridad en un equipo que nunca se fija, para empezar
Entiendo que se refiere a que no solo basta con parchear nuestros sistemas, en el mejor caso que lo hagas xD.
Ley # 5 La vigilancia eterna es el precio de la seguridad
Vale, correcto, se que parcheas tus sistemas. Se que como eres "perro viejo" pruebas en un laboratorio los parches. Te vas en agosto de vacaciones con la familia a La Manga (Murcia) a desconectar del trabajo. Ese segundo martes de agosto, MS saca un Security RollUp Package (conjunto de parches sin llegar a ser un Services Pack)
Ley # 6: No hay realmente alguien por ahí tratando de adivinar sus contraseñas
Lo primero de todo es saber que algo malo está pasando para intentar solventarlo.Creo que se refiere más al tema contraseñas. Una contraseña es segura mediante una combinación de características como complejidad (mi_clave!) case sensitive (Mi_Clave), longitud ("Mi_Clave_es_muy_larga). El factor clave para proporcionar seguridad mediante contraseñas es la caducidad. Gracias a la capacidad de computo de los sistemas actuales, las claves se sacan. Se tardará más o menos tiempo y más o menos recursos, pero se obtienen. Cambiar la clave cada cierto tiempo es indispensable para fortificar nuestros sistemas.
Ley # 7: La red más segura es un bien administrado una
Lo dicho al empezar !!! la frase !!!
Ley # 8: La dificultad de defender una red es directamente proporcional a su complejidad
No pretendas implementar una solucion de Firewall, IDS/IDP, HoneyPots, Proxys, balaceadores, dispositivos de control de acceso a redes...en una organización de 4 personas trabajando con Office´s. Pero no pongas un antivirus y un firewall pre-configurado en una organización con 200 trabajadores...
Ley # 9: La seguridad no se trata de evitar riesgos, se trata de la gestión de riesgos
Me parece interesante establecer una analogía con la actual LOPD española. No se trata de que no se te pierda un papel o dato, sino de tener controlado el papel/dato, notificar el incidente,establecer medidas de mejora para evitar futuros incidentes de ese tipo, etc. Es muy importante saber que existe ese papel, que se ha perdido, quien ha podido estar cerca de ese papel, se han perdidos más papeles o solo ese...
Ley # 10: La tecnología no es una panacea
La seguridad no es un producto, es un proceso !!. Otra frase mítica en el mundo de la seguridad. Poner una clave super segura,en el famoso post-it no es seguro !!! Hacer oídos sordos a la advertencia del AntiVirus de que "nominas_agosto_2013.jpg.exe" no es un documento, no es seguro !!
En este artículo de opinión personal voy a meterme con algunos xD.
Instalar un servidor Windows, un sql server, montar un dominio, un dns, un dhcp, un servicio de archivos y una intranet se hace en una jornada de trabajo, y si me apuras, siguiendo unas pocas páginas. Nuestro trabajo como administradores de sistemas NO es ofrecer esos servicios, sino hacerlos de manera segura, duradera y que satisfagan las necesidades concretas de la organización.
Si queréis leer la actualización a estas reglas o consejos podéis verlo aquí.
Como siempre, gracias por leerme. El próximo artículo de esta serie nos meteremos en faena con la fortificación de servidores 2012 y entornos Active Directory.
Google +
viernes, 31 de mayo de 2013
jueves, 23 de mayo de 2013
Tips & Tricks. BranchCache, Windows Update Services, Internet Information Services y Firewall en Windows Server 2012
BranchCache es una tecnología implementada en Windows 2008 y Windows 7 para el manejo de datos en ubicaciones remotas. En este post vamos a hablar de su versión para Windows Server 2012 y Windows 8.
En concreto, vamos a implementar una solución de BranchCache distribuida, y sobre ella una instalación de WSUS.
Vamos a imaginar un típico escenario de una organización con servidores de ficheros, carpetas compartidas y documentos públicos. Tenemos alguna delegación con enlaces WAN de alta calidad, pero tenemos una delegación pequeña, una oficina regional, sin grandes estructuras de sistemas, es decir, una ADSL y unos cuantos PC sin servidor. Muy típico para pequeñas y medianas empresas.
BranchCache nos proporciona un método de caché de contenidos descentralizado entre pc´s clientes. Es decir. Un cliente en esa oficina remota accede al servidor de la empresa para trabajar con un recurso, un fichero Word, una aplicación web, etc. Dentro de esa pequeña sede, al rato otro usuario quiere acceder a ese mismo documento. Puede pasar que en ese momento la conexión hacia la sede principal, donde se encuentra el servidor de ficheros esté caído, o lento. Por qué no usar el documento descargado previamente por el primer usuario en la sede pequeña, para evitar el tráfico hacia la sede principal vía Internet? Eso es BranchCache. Sobre esto podemos montar WSUS para realizar lo mismo. Un cliente descarga una actualización de Windows, y está se "propaga" al resto de clientes de esa pequeña sede sin necesidad de ir cada pc cliente a la sede principal a buscar dicha actualización.
Como podéis imaginar, es una de las funcionas más interesantes en cuanto a experiencia de usuario que nos proporciona Windows Server 2012.
Hay dos maneras de implementar esta solución, de manera distribuida y/o hospedada ( Se puede implementar de las dos maneras al unísono). Cuando hablamos de distribuida nos referimos al escenario que comento más arriba. BranchCache hospedada requiere de un servidor de contenido en ese delegación pequeña para hacer de cache, y este distribuye hacia los clientes de esa red. Sería algo así como cuando configuramos BRIDGEHEADER o servidores de cabeza de puente "Inter Site" para optimizar la replicación de controladores de dominio( 1 a 1 entre Sites y no DC a DC).
Para poder utilizar dicha función, debemos contar con un parque de PC´s cliente Windows 7 o superior.
Para implementar un servidor de contenido, el que digamos estaría cacheando el contenido en la ubicación pequeña debe ser Windows 2008r2 ( no es posible con las versiones core enterprise y datacenter)o Windows 2012.
Branchcache emplea un método que divide la información, los datos en pequeños bloques. A estos bloques les aplica un algoritmo de HASH (SHA256) con el que se consigue reducir la información en un ratio aproximado de 1:2000. Esta es la información que se publica/consulta en la oficina remota para agilizar el proceso de búsqueda de un cliente, es decir, saber si está disponible ese contenido en la sede local o debe ir al servidor central. Importante saber que solo se "cachea" contenido mayor a 64kb. Importante a la hora de las pruebas con el típico txt etc.xD. Al HASH de la información se le añade un secreto compartido, una pre-shared key y le aplica al conjunto un algoritmo de cifrado AES128. De esta manera se evita que mediante la captura de paquetes, un atacante pueda interceptar las peticiones/envios de información y pueda averiguar los cambios atacando al cliente de BranchCache.
Desde el panel central de administración de Windows Server 2012 agregamos la función de BranchCache dentro del ROL de servidor de ficheros. Listo !!.
Fin del post xD.
Vamos a ver una serie de comandos PowerShell relativos a BranchCache. O mejor no, si luego se nos olvida. Mejor saber como buscar.
Lanzamos un Status para ver si todo ha ido bien.
Los hash de los ficheros se generan automaticamente en el servidor, no mediante una tarea programada. Si eres de los que sufre el sindrome de F5 puedes forzar el "hasheado" mediante hashgen -f C:\ruta compartida
Ahora toca la configuración, pero al estilo siguiente siguiente siguiente.
Lo primero que vamos a hacer es configurar una política de seguridad para el servidor que ejecuta los servicios de BranchCache respecto al firewall. Damos, por echo que está configurado el Firewall en el servidor, y damos por echo que vamos a hacer las cosas bien xD. Podríamos deshabilitar el firewall, podríamos configurar el firewall a pelo, pero NO. Aprovechando las capacidades de gestión centralizada de Active Directory y Windows Server 2012, vamos a preparar una Unidad organizativa para albergar nuestro servidor de contenido, y configurar las reglas del firewall desde ahí. Esto nos proporciona un mayor control de los elementos de configuración, y sobre todo, nos facilita el escalado horizontal en el caso de crecimiento de nuestra empresa. En este caso muestro como crear la UNO aunque la GPO de Firewall podría aplicarla a nivel de servidor local, pero la parte de BranchCache si la haría a nivel de UO.
La configuración sería crear una Unidad Organizativa, mover el servidor, crear una GPO mediante el editor de directivas, y vincularla a dicha UO.
Ahora tocamos la parte del Firewall.
Realizamos la misma acción para las reglas de salida para los dos elementos predefinidos.
Ahora configuramos la GPO de BranchCache que permite publicación de contenidos.
Configuramos la GPO de clientes para habilitar el uso de BranchCache, por ejemplo, si tenemos los equipos de esa ubicación agrupados en alguna UO.
Vamos a probarlo en funcionamiento.Para emular el comportamiento de varios pc conectados por un enlace lento, como podría ser una conexión wan vamos a usar una herramienta muy interesante, sobre todo para pruebas rendimiento, balanceo y demás.
Network Emulator Client. Lo podemos descargar en 32 y 62 bits desde este skydrive de un amable usuario.
Instalamos y configuramos un filtro de tarjetas, o incluso por direcciones ip, y configuramos opciones de red tan bonitas como las que veis en la pantalla.
Con el delay de 300ms creo que será suficiente. Si no lo es, podemos el BandWith.
Lo probamos con un ping desde un cliente.
El valor por defecto en ms de latencia entre servidor-pc para identificarlo como una oficina remota es 80 ms.
Podemos modificar este parámetro para ajustarlo a nuestra realidad dentro de la organización mediante netsh branchcache smb set latency 0
Ahora vamos a habilitar el BranchCache para una carpeta compartida en concreto. Desde el servicio de ficheros, nos ubicamos en la carpeta compartida ( o en el momento de compartirla por este procedimiento) y habilitamos BranchCache.
O podemos hacerlo desde el explorador de archivos desde las opciones de compartir clásicas.
Podemos apreciar como a medida que vamos recuperando contenido, ficheros de carpetas compartidas en el servidor en nuestro cliente "lento" Windows 8 va aumentando el tamaño de la cache. Si recuperamos el contenido en un segundo equipo veremos como esos mismos ficheros se recuperan a la velocidad del enlace PC-PC. Puedes analizar una captura de red para ver como va al servidor BranchCache a recuperar el hash pero que obtiene el fichero del PC cliente.
Podemos aprovechar esta función para despliegue de aplicaciones en oficinas remotas con enlaces lentos. Sin más configuración por parte de BranchCache.
El servidor WSUS usa los puertos 8530 y 8531 para comunicarse con los servicios de Windows Update, por lo que tenemos que tenerlo en cuenta en nuestro Firewall de servidor/perimetral.
No vamos a profundizar en las características avanzadas de WSUS, ya que requeriría no solo un post... ya que existen diferentes escenarios para su implantación (distribuido, desconectado,en NLB,etc) sino que vamos a instalar un servidor WSUS principal para toda la organización, que aproveche las características de BranchCache para nustra sede remota. Tampoco vamos a realizar una instalación de Sql Server para manejar los datos de WSUS, sino que nos vamos a contentar con los 10 gigas disponibles de la base de datos Internal de Windows Server 2012. En el caso de implementaciones de NLB necesitaríamos Sql Server ( en casi todas las implementaciones de servicios balanceados necesitaremos un sql server, sino dos...).
La instalación de WSUS comienza agregando un nuevo rol dentro del DASHBOARD de Windows Server 2012. agregamos el role, autorizamos las dependencias, elegimos el servidor de destino, autorizamos el reinicio en caso necesario y a correr.
En la pantalla anterior debemos proporcionar una ruta válida en nuestro servidor o recurso de red para almacenar las actualizaciones.
Una de las dependencias necesarias, ASP.NET 4.5 me ha dado problemas a la hora de instalarla desde el CD, por lo que si tienes ganas de pelea, puedes instalarla por separado desde la web.
Puestos a pedir, porque no mejor un solo PowerShell para la instlación? Install-WindowsFeature -Name UpdateServices, UpdateServices-Ui
Una vez instalado el Role, vamos a realizar los pasos post-intalación como indican las siguientes pantallas.
Con esto tenemos instalado el servidor Wsus básico, aunque aún no operativo al 100%.
***Al realizar la instalación de WSUS se nos instala el Role de Internet Informatión Services pero no la consola de administración, para ellos, debemos agregar la característica dentro del rol de IIS por el GUI o bien mediante Powershell, para poder trabajar con IIS.
***
Habría que registrar los clientes, y aprobar las actualizaciones.
Con esta configuración, se usará la característica de BranchCache tanto para Wsus, como para todo lo que corra sobre IIS sobre ese servidor.
Como siempre, espero que os guste el artículo y que lo probéis en algún laboratorio o penséis en implementar soluciones de este tipo de cache de contenidos para vuestras organizaciones.
En concreto, vamos a implementar una solución de BranchCache distribuida, y sobre ella una instalación de WSUS.
Vamos a imaginar un típico escenario de una organización con servidores de ficheros, carpetas compartidas y documentos públicos. Tenemos alguna delegación con enlaces WAN de alta calidad, pero tenemos una delegación pequeña, una oficina regional, sin grandes estructuras de sistemas, es decir, una ADSL y unos cuantos PC sin servidor. Muy típico para pequeñas y medianas empresas.
BranchCache nos proporciona un método de caché de contenidos descentralizado entre pc´s clientes. Es decir. Un cliente en esa oficina remota accede al servidor de la empresa para trabajar con un recurso, un fichero Word, una aplicación web, etc. Dentro de esa pequeña sede, al rato otro usuario quiere acceder a ese mismo documento. Puede pasar que en ese momento la conexión hacia la sede principal, donde se encuentra el servidor de ficheros esté caído, o lento. Por qué no usar el documento descargado previamente por el primer usuario en la sede pequeña, para evitar el tráfico hacia la sede principal vía Internet? Eso es BranchCache. Sobre esto podemos montar WSUS para realizar lo mismo. Un cliente descarga una actualización de Windows, y está se "propaga" al resto de clientes de esa pequeña sede sin necesidad de ir cada pc cliente a la sede principal a buscar dicha actualización.
Como podéis imaginar, es una de las funcionas más interesantes en cuanto a experiencia de usuario que nos proporciona Windows Server 2012.
Hay dos maneras de implementar esta solución, de manera distribuida y/o hospedada ( Se puede implementar de las dos maneras al unísono). Cuando hablamos de distribuida nos referimos al escenario que comento más arriba. BranchCache hospedada requiere de un servidor de contenido en ese delegación pequeña para hacer de cache, y este distribuye hacia los clientes de esa red. Sería algo así como cuando configuramos BRIDGEHEADER o servidores de cabeza de puente "Inter Site" para optimizar la replicación de controladores de dominio( 1 a 1 entre Sites y no DC a DC).
Para poder utilizar dicha función, debemos contar con un parque de PC´s cliente Windows 7 o superior.
Para implementar un servidor de contenido, el que digamos estaría cacheando el contenido en la ubicación pequeña debe ser Windows 2008r2 ( no es posible con las versiones core enterprise y datacenter)o Windows 2012.
Branchcache emplea un método que divide la información, los datos en pequeños bloques. A estos bloques les aplica un algoritmo de HASH (SHA256) con el que se consigue reducir la información en un ratio aproximado de 1:2000. Esta es la información que se publica/consulta en la oficina remota para agilizar el proceso de búsqueda de un cliente, es decir, saber si está disponible ese contenido en la sede local o debe ir al servidor central. Importante saber que solo se "cachea" contenido mayor a 64kb. Importante a la hora de las pruebas con el típico txt etc.xD. Al HASH de la información se le añade un secreto compartido, una pre-shared key y le aplica al conjunto un algoritmo de cifrado AES128. De esta manera se evita que mediante la captura de paquetes, un atacante pueda interceptar las peticiones/envios de información y pueda averiguar los cambios atacando al cliente de BranchCache.
Desde el panel central de administración de Windows Server 2012 agregamos la función de BranchCache dentro del ROL de servidor de ficheros. Listo !!.
Fin del post xD.
Vamos a ver una serie de comandos PowerShell relativos a BranchCache. O mejor no, si luego se nos olvida. Mejor saber como buscar.
Get-Command -Module BranchCache
Los hash de los ficheros se generan automaticamente en el servidor, no mediante una tarea programada. Si eres de los que sufre el sindrome de F5 puedes forzar el "hasheado" mediante hashgen -f C:\ruta compartida
Ahora toca la configuración, pero al estilo siguiente siguiente siguiente.
Lo primero que vamos a hacer es configurar una política de seguridad para el servidor que ejecuta los servicios de BranchCache respecto al firewall. Damos, por echo que está configurado el Firewall en el servidor, y damos por echo que vamos a hacer las cosas bien xD. Podríamos deshabilitar el firewall, podríamos configurar el firewall a pelo, pero NO. Aprovechando las capacidades de gestión centralizada de Active Directory y Windows Server 2012, vamos a preparar una Unidad organizativa para albergar nuestro servidor de contenido, y configurar las reglas del firewall desde ahí. Esto nos proporciona un mayor control de los elementos de configuración, y sobre todo, nos facilita el escalado horizontal en el caso de crecimiento de nuestra empresa. En este caso muestro como crear la UNO aunque la GPO de Firewall podría aplicarla a nivel de servidor local, pero la parte de BranchCache si la haría a nivel de UO.
La configuración sería crear una Unidad Organizativa, mover el servidor, crear una GPO mediante el editor de directivas, y vincularla a dicha UO.
Ahora configuramos la GPO de BranchCache que permite publicación de contenidos.
Network Emulator Client. Lo podemos descargar en 32 y 62 bits desde este skydrive de un amable usuario.
Instalamos y configuramos un filtro de tarjetas, o incluso por direcciones ip, y configuramos opciones de red tan bonitas como las que veis en la pantalla.
Lo probamos con un ping desde un cliente.
Podemos modificar este parámetro para ajustarlo a nuestra realidad dentro de la organización mediante netsh branchcache smb set latency 0
Ahora vamos a habilitar el BranchCache para una carpeta compartida en concreto. Desde el servicio de ficheros, nos ubicamos en la carpeta compartida ( o en el momento de compartirla por este procedimiento) y habilitamos BranchCache.
Podemos aprovechar esta función para despliegue de aplicaciones en oficinas remotas con enlaces lentos. Sin más configuración por parte de BranchCache.
El servidor WSUS usa los puertos 8530 y 8531 para comunicarse con los servicios de Windows Update, por lo que tenemos que tenerlo en cuenta en nuestro Firewall de servidor/perimetral.
No vamos a profundizar en las características avanzadas de WSUS, ya que requeriría no solo un post... ya que existen diferentes escenarios para su implantación (distribuido, desconectado,en NLB,etc) sino que vamos a instalar un servidor WSUS principal para toda la organización, que aproveche las características de BranchCache para nustra sede remota. Tampoco vamos a realizar una instalación de Sql Server para manejar los datos de WSUS, sino que nos vamos a contentar con los 10 gigas disponibles de la base de datos Internal de Windows Server 2012. En el caso de implementaciones de NLB necesitaríamos Sql Server ( en casi todas las implementaciones de servicios balanceados necesitaremos un sql server, sino dos...).
La instalación de WSUS comienza agregando un nuevo rol dentro del DASHBOARD de Windows Server 2012. agregamos el role, autorizamos las dependencias, elegimos el servidor de destino, autorizamos el reinicio en caso necesario y a correr.
Puestos a pedir, porque no mejor un solo PowerShell para la instlación? Install-WindowsFeature -Name UpdateServices, UpdateServices-Ui
Una vez instalado el Role, vamos a realizar los pasos post-intalación como indican las siguientes pantallas.
***Al realizar la instalación de WSUS se nos instala el Role de Internet Informatión Services pero no la consola de administración, para ellos, debemos agregar la característica dentro del rol de IIS por el GUI o bien mediante Powershell, para poder trabajar con IIS.
Install-WindowsFeature Web-Server -IncludeManagementTools
***
Habría que registrar los clientes, y aprobar las actualizaciones.
Con esta configuración, se usará la característica de BranchCache tanto para Wsus, como para todo lo que corra sobre IIS sobre ese servidor.
Como siempre, espero que os guste el artículo y que lo probéis en algún laboratorio o penséis en implementar soluciones de este tipo de cache de contenidos para vuestras organizaciones.
lunes, 20 de mayo de 2013
Tips & Tricks.Parte III.Token Kerberos, Dynamic Access Control y servidor de ficheros en Windows Server 2012
Seguimos con este artículo y vamos a crear valor a la empresa con estas configuraciones que hemos aprendido. Vamos a configurar el acceso a recursos basado en la clasificación automática y alguna cosita mas...
Entramos en el centro de control administrativo de Active Directory. Configuramos una regla de acceso central, en la que configuramos una condición que será que el atributo Ciudad sea Sodoma, y dentro de esa condición, establecemos los permisos que queremos para nuestro grupo de usuarios.
Sencillo, pero insisto, lo complicado de todo esto es establecer una política que satisfaga las necesidades de la organización. La implementación técnica es bastante sencilla como podéis ver.
Una vez creada la regla, creamos la política para publicar en Active Directory y que sea válida.
Otra opción que me parece muy interesante comentar es el tema de las notificaciones de acceso.
Imaginemos un entorno como el que contábamos, de varios países, departamentos, ciudades, en el que el mensaje "Consulte con su administrador" ayuda más bien poco. Puede que haya 20 administradores para los ficheros y no sepamos a quien acceder. Esto reduce la carga del Servides Desk considerablemente.
En la ventana de administración del servidor de ficheros, pulsamos botón derecho sobre la raíz ( al igual que hacíamos para configurar el calendario para la clasificación automática).
Podemos configurar opciones para mensajes más descriptivos, usando variables para las carpetas como puedan ser Owner, y habilitando la opción de enviar e-mail directamente al administrador responsable.
Vamos a probar un acceso no válido desde un usuario ( deben ser entornos cliente Windows 8) para ver el mensaje.
Muy muy interesante esta opción para garantizar el acceso a los recursos de los empleados, y al menos, para procesos de migración, salvarnos un poco de "parar" a los usuarios.
Espero que os haya gustado esta serie de artículos y que los pongáis en marcha, eso si, papel en mano.
Un saludo y en próximos artículos extenderemos estas propiedades con DRM.
Entramos en el centro de control administrativo de Active Directory. Configuramos una regla de acceso central, en la que configuramos una condición que será que el atributo Ciudad sea Sodoma, y dentro de esa condición, establecemos los permisos que queremos para nuestro grupo de usuarios.
Sencillo, pero insisto, lo complicado de todo esto es establecer una política que satisfaga las necesidades de la organización. La implementación técnica es bastante sencilla como podéis ver.
Una vez creada la regla, creamos la política para publicar en Active Directory y que sea válida.
Otra opción que me parece muy interesante comentar es el tema de las notificaciones de acceso.
Imaginemos un entorno como el que contábamos, de varios países, departamentos, ciudades, en el que el mensaje "Consulte con su administrador" ayuda más bien poco. Puede que haya 20 administradores para los ficheros y no sepamos a quien acceder. Esto reduce la carga del Servides Desk considerablemente.
En la ventana de administración del servidor de ficheros, pulsamos botón derecho sobre la raíz ( al igual que hacíamos para configurar el calendario para la clasificación automática).
Podemos configurar opciones para mensajes más descriptivos, usando variables para las carpetas como puedan ser Owner, y habilitando la opción de enviar e-mail directamente al administrador responsable.
Vamos a probar un acceso no válido desde un usuario ( deben ser entornos cliente Windows 8) para ver el mensaje.
Muy muy interesante esta opción para garantizar el acceso a los recursos de los empleados, y al menos, para procesos de migración, salvarnos un poco de "parar" a los usuarios.
Espero que os haya gustado esta serie de artículos y que los pongáis en marcha, eso si, papel en mano.
Un saludo y en próximos artículos extenderemos estas propiedades con DRM.
Tips & Tricks.Parte II.Token Kerberos, Dynamic Access Control y servidor de ficheros en Windows Server 2012
Os ha dado tiempo a preparar vuestras máquinas con lo visto en el anterior capítulo de Tips & Tricks.Token Kerberos, Dynamic Access Control y servidor de ficheros en Windows Server 2012
Para centrarnos resumimos. Hemos configurado el servicio de archivos, hemos configurado una carpeta compartida y hemos configurado los User Claims de usuario y los Resources Proporties. Uno para clasificación manual y otro para clasificación automática. Vamos a ponerlo a correr.
Como podemos ver en la siguiente imagen, aquí tenemos definidas las propiedades.
Como veis, están definidas a nivel Global, el resto ( Correo, Mensaje y Uso)son ofrecidas por el sistema por defecto, pero solo en el ámbito del servidor local en el que se almacenen.
Vamos a crear otra carpeta, y vamos a asignarle el Resource de Departamento para que el contenido de esa carpeta se clasifique automáticamente bajo ese departamento.
NOTA MENTAL.- Cuando en el anterior post creamos esta propiedad en Active Directory, solo puse el valor de Murcia. Ahora para enseñaros este concepto he añadido mediante el centro de administración de Active Directory un segundo valor posible para ese propiedad. Si queréis que esté disponible no olvidéis hacer lo que contábamos de actualizar el FSRM mediante la powershell
Update-FSRMClassificationPropertyDefinition
Hasta aquí un poco de resumen del anterior artículo. Una vez establecidas las propiedades o atributos por los que queremos clasificar, vamos a crear las reglas de clasificación para poder usarlas.
Como podéis leer en la última pantalla, si queremos "machacar" propiedades previas de ese documento, y re-organizarlo bajo el criterio que estamos empleando, debemos habilitar el check, sino, conservará los metadatos de clasificación, si los tuviese, y bloquearía la clasificación automática para ese recurso.
Con esto tendremos ejecutándose la regla de clasificación. Hasta aquí solo se definía.
Hay un tipo de clasificación MUY interesante de ficheros y carpetas y es la posibilidad de organizar por contenido... Esto es un regalo para los gestores documentales. Podemos definir una regla que sea que se clasifiquen los documentos como privados, si aparece dentro del documento un valor DNI: por ejemplo...
Como podéis apreciar, es una herramienta muy versátil y potente.
Microsoft está apostando claramente por una estrategia de facilitar el trabajo a los administradores de sistemas, en lo relativo al proceso de configuración técnico, pero aquí la complejidad reside en la definición de las reglas de clasificación que queremos emplear y de su supervisión día a día. Es muy sencillo hacer unos clicks en estos menús como podéis ver, pero establecer una política lógica para nuestra empresa, que nos proporcione el control de acceso y disponibilidad que necesitamos no lo es tanto.
Ejecutamos la regla de clasificación inicialmente.
Una vez terminado el proceso de clasificación nos muestra un informe con los archivos clasificados. Para este ejemplo he creado un fichero BMP de nombre curioso dentro de la carpeta Marketing, como hemos definido en la regla de clasificación, para que establezca la propiedad Ciudad=Sodoma.
Sería interesante ejecutar esta regla cada cierto tiempo para comprobar su funcionamiento? Welcome Mister Powershell xD –RunDuration Start-FSRMClassification 0 - confirmar:$ false
O bien usamos el asistente para generación de Reports que es mucho más cómodo xD.
Esta parte se merece toda una entrada, ya que nos permite crear reports a medida sobre las opciones de configuración de nuestro entorno de archivos, seleccionado las categorías para la clasificación, pero no solo para eso, sino para detectar ficheros grandes, pequeños, duplicados, uso de cuotas etc etc. Muy recomendable indagar un poco más en este aspecto.
Debemos establecer una programación de tareas para efectuar el proceso de clasificación automática en nuestro servidor? Si, donde? en la raíz del servicio de Almacenamiento, botón derecho, configurar opciones.
Como podéis apreciar, podemos configurar no solo las opciones de calendario, sino configurar el nivel de Log que queremos registrar, el formato, ubicación, envío de correos etc.
Fijaros en Permitir clasificación continua de archivos nuevos... Es recomendable monitorizar la carga de trabajo para el servidor que le va a suponer esta clasificación en un entorno grande, y en el caso de clasificación por contenido. En la regla de clasificación por contenido que hemos creado para "DNI:" imaginaros una regular expressión mas avanzada, en un entorno de muchos muchos ficheros...
Vale, parece ser que tenemos el tema de la clasificación de carpetas/archivos medianamente controlado xD. Pero esto no nos sirve para ser personas ordenadas ( porque no veis mi escritorio) sino para garantizar el acceso a los recursos dentro de nuestra empresa. CAP Central Access Policy.
ACL basadas en expresiones. No solo basadas en grupos de usuarios, sino que podemos extender estas características mediante expresiones, por ejemplo, que para acceder a un recurso fichero deba pertenecer a dos grupos !! Por ejemplo Marketing y Nivel confidencial alto, sin tener que implementar una estructura de carpetas basada en este criterio. A su vez, podemos definir el ámbito efectivo para un servidor de ficheros concreto, o para todo el bosque de servidores de archivos. Como no, también podemos controlar el acceso al archivo mediante la propiedad clasificada Claims configuradas en el anterior post.
Vamos a poner un ejemplo típico en nuestras organizaciones.
Carpeta de empresa (x1) dentro comunidades autónomas (x17) dentro por deparamentos marketing, rrhh e IT (x3) y dentro un par de niveles de confidencialidad (x2).102 posibilidades de pertenencia a grupo... Cuando realmente deberíamos tener un grupo de comunidades, otro de departamentos y otro de confidencialidad, y establecer condiciones regulares para la configuración de la ACL.
También podemos usar los Devices Claims predefinidos dentro de Active Directory (200), no solo el que hemos configurado para Departamento, sino una configuración de equipo, en donde creamos unos grupos basados en tipos de pc, por ejemplo, PC nuevos, PC viejos, PC portátiles. Prepararemos las reglas de clasificación, clasificaremos los PC manualmente para este propósito, y podremos hacer uso de DAC combinado con las reglas ACL y los CLAIMS ( en el anterior ejemplo de grupos, que sea de España, de RRHH, NIVEL de confidencialidad 1, y sumamos que se esté accediendo desde un pc PC NUEVO)...
La necesidad de mejora respecto al antiguo enfoque de permisos ACL es evidente !!!
Tenéis ganas de configurar las reglas de acceso verdad...
Gracias por leerme, y atentos a la siguiente entrega.
Un saludo.
PARTE III
Google +
Para centrarnos resumimos. Hemos configurado el servicio de archivos, hemos configurado una carpeta compartida y hemos configurado los User Claims de usuario y los Resources Proporties. Uno para clasificación manual y otro para clasificación automática. Vamos a ponerlo a correr.
Como podemos ver en la siguiente imagen, aquí tenemos definidas las propiedades.
Como veis, están definidas a nivel Global, el resto ( Correo, Mensaje y Uso)son ofrecidas por el sistema por defecto, pero solo en el ámbito del servidor local en el que se almacenen.
Vamos a crear otra carpeta, y vamos a asignarle el Resource de Departamento para que el contenido de esa carpeta se clasifique automáticamente bajo ese departamento.
NOTA MENTAL.- Cuando en el anterior post creamos esta propiedad en Active Directory, solo puse el valor de Murcia. Ahora para enseñaros este concepto he añadido mediante el centro de administración de Active Directory un segundo valor posible para ese propiedad. Si queréis que esté disponible no olvidéis hacer lo que contábamos de actualizar el FSRM mediante la powershell
Update-FSRMClassificationPropertyDefinition
Hasta aquí un poco de resumen del anterior artículo. Una vez establecidas las propiedades o atributos por los que queremos clasificar, vamos a crear las reglas de clasificación para poder usarlas.
Con esto tendremos ejecutándose la regla de clasificación. Hasta aquí solo se definía.
Hay un tipo de clasificación MUY interesante de ficheros y carpetas y es la posibilidad de organizar por contenido... Esto es un regalo para los gestores documentales. Podemos definir una regla que sea que se clasifiquen los documentos como privados, si aparece dentro del documento un valor DNI: por ejemplo...
Como podéis apreciar, es una herramienta muy versátil y potente.
Microsoft está apostando claramente por una estrategia de facilitar el trabajo a los administradores de sistemas, en lo relativo al proceso de configuración técnico, pero aquí la complejidad reside en la definición de las reglas de clasificación que queremos emplear y de su supervisión día a día. Es muy sencillo hacer unos clicks en estos menús como podéis ver, pero establecer una política lógica para nuestra empresa, que nos proporcione el control de acceso y disponibilidad que necesitamos no lo es tanto.
Ejecutamos la regla de clasificación inicialmente.
Una vez terminado el proceso de clasificación nos muestra un informe con los archivos clasificados. Para este ejemplo he creado un fichero BMP de nombre curioso dentro de la carpeta Marketing, como hemos definido en la regla de clasificación, para que establezca la propiedad Ciudad=Sodoma.
Sería interesante ejecutar esta regla cada cierto tiempo para comprobar su funcionamiento? Welcome Mister Powershell xD –RunDuration Start-FSRMClassification 0 - confirmar:$ false
O bien usamos el asistente para generación de Reports que es mucho más cómodo xD.
Esta parte se merece toda una entrada, ya que nos permite crear reports a medida sobre las opciones de configuración de nuestro entorno de archivos, seleccionado las categorías para la clasificación, pero no solo para eso, sino para detectar ficheros grandes, pequeños, duplicados, uso de cuotas etc etc. Muy recomendable indagar un poco más en este aspecto.
Debemos establecer una programación de tareas para efectuar el proceso de clasificación automática en nuestro servidor? Si, donde? en la raíz del servicio de Almacenamiento, botón derecho, configurar opciones.
Como podéis apreciar, podemos configurar no solo las opciones de calendario, sino configurar el nivel de Log que queremos registrar, el formato, ubicación, envío de correos etc.
Fijaros en Permitir clasificación continua de archivos nuevos... Es recomendable monitorizar la carga de trabajo para el servidor que le va a suponer esta clasificación en un entorno grande, y en el caso de clasificación por contenido. En la regla de clasificación por contenido que hemos creado para "DNI:" imaginaros una regular expressión mas avanzada, en un entorno de muchos muchos ficheros...
Vale, parece ser que tenemos el tema de la clasificación de carpetas/archivos medianamente controlado xD. Pero esto no nos sirve para ser personas ordenadas ( porque no veis mi escritorio) sino para garantizar el acceso a los recursos dentro de nuestra empresa. CAP Central Access Policy.
ACL basadas en expresiones. No solo basadas en grupos de usuarios, sino que podemos extender estas características mediante expresiones, por ejemplo, que para acceder a un recurso fichero deba pertenecer a dos grupos !! Por ejemplo Marketing y Nivel confidencial alto, sin tener que implementar una estructura de carpetas basada en este criterio. A su vez, podemos definir el ámbito efectivo para un servidor de ficheros concreto, o para todo el bosque de servidores de archivos. Como no, también podemos controlar el acceso al archivo mediante la propiedad clasificada Claims configuradas en el anterior post.
Vamos a poner un ejemplo típico en nuestras organizaciones.
Carpeta de empresa (x1) dentro comunidades autónomas (x17) dentro por deparamentos marketing, rrhh e IT (x3) y dentro un par de niveles de confidencialidad (x2).102 posibilidades de pertenencia a grupo... Cuando realmente deberíamos tener un grupo de comunidades, otro de departamentos y otro de confidencialidad, y establecer condiciones regulares para la configuración de la ACL.
También podemos usar los Devices Claims predefinidos dentro de Active Directory (200), no solo el que hemos configurado para Departamento, sino una configuración de equipo, en donde creamos unos grupos basados en tipos de pc, por ejemplo, PC nuevos, PC viejos, PC portátiles. Prepararemos las reglas de clasificación, clasificaremos los PC manualmente para este propósito, y podremos hacer uso de DAC combinado con las reglas ACL y los CLAIMS ( en el anterior ejemplo de grupos, que sea de España, de RRHH, NIVEL de confidencialidad 1, y sumamos que se esté accediendo desde un pc PC NUEVO)...
La necesidad de mejora respecto al antiguo enfoque de permisos ACL es evidente !!!
Tenéis ganas de configurar las reglas de acceso verdad...
Gracias por leerme, y atentos a la siguiente entrega.
Un saludo.
PARTE III
Google +
Suscribirse a:
Entradas (Atom)