Pues me acabo de quedar de piedra.
He pedido a ChatGPT "Make me a powershell script to configure a server as domain controller.
y aquí está su respuesta:
jueves, 8 de diciembre de 2022
miércoles, 7 de diciembre de 2022
Automatizar Backup a raíz de etiqueta forzada en recursos
Hola,
En el presente artículo voy a explicaros como forzar el etiquetado de recursos y a través de esta etiqueta y su valor, incluir por ejemplo una VM en un Recovery Service.
Esta configuración nos fuerzar a posicionarnos en cuanto a si queremos tener backup o no de las máquinas virtuales.
Forzar etiqueta Backup en recursos
Vamos a trabajar con una política pre estrablecida con nombre "Require a tag on resources"
Al hacer click sobre la política, podremos desplegarla a través de la opción "Assign"
Ahí tendremos que elegir el "scope" o sea a qué suscripción y posible grupo de recursos se va a aplicar.Podremos configurar una excepción y poner nombre a la asignación de forma que sea más descriptiva que el nombre genérico inicial.
En parámetros, podremos crear la etiqueta que vamos a forzar
En la siguiente opción, "Remediation" podríamos por ejemplo forzar a que todo recursos sin etiqueta, reciba una etiqueta "Backup" con valor "No", pero yo en mi caso no voy a remediarlo para que la crear un recurso, este muestre un error si no tiene la etiqueta Backup con un valor.
Configuraremos entonces un mensaje en la opción "Non-compliance messages" y crearemos la asignación de la política.
Test
Al crear una VM, si no tenemos la etiqueta en cuestión, nos aparecerá este error.
Hasta que en mi caso, he creado la etiqueta Backup con valor No.
Posteriormente, tras etiquetar correctamente la VM, ya me deja crearla.
Configuración de Backup tras aparición de etiqueta en recurso
Ahora configuraremos la inclusión automática de máquinas virtuales en un recovery vault a partir de la aparición de valor "Si" en la etiqueta Backup.
Esta vez y por cambiar la forma de asignación, nos iremos a la opción "Assignments" en las políticas de nuestro portal de Azure.
Configuraremos también el scope al que aplicará la asignación
En los parámetros, configuraremos el nombre de la etiqueta y el valor que estaremos esperando para considerar "compliant" al recurso. en este caso será Tag name "Backup" Value "si"
Configuraremos también la remediación, que no es otra que incluir al recurso en el recovery vault y política que hemos indicado en los parámetros.
Con esto ya tendremos configurada la respuesta que queríamos a nuestra etiqueta.
Test
Comprobamos que nuestra VM aparece como "Non-compliant" ya que dispone de la etiqueta pero no del valor requerido.
Nos vamos a buscar la VM con etiqueta "Backup" = "No" y cambiamos su valor a "Si"
La máquina ya aparece en el Vault de backup
Y la VM ya aparece como "Compliant".
domingo, 4 de diciembre de 2022
Pasar de 99,9% a 99,95% o 99,99% en Azure Compute es casi gratis y está en tu mano.
Pues sí, contar con una
disponibilidad del 99,9%, 99,95% o 99,99%, es la diferencia entre tener
una VM en Azure -con cierta calidad-, ubicar dos VMS de calidad media en grupos de
disponibilidad o ubicar esas mismas dos máquinas, en dos zonas de la misma región.
99,9%.
Este es la disponibilidad
garantizada que obtienes si montas en Azure una VM con SSD Premium o Ultra
disk.
Cabe tener en cuenta, que esta
cifra no incluye paradas planeadas de actualización y mantenimiento de Microsoft y
paradas previsibles por parte del administrador a la hora de actualizar y
reiniciar la máquina. Así que podemos decir que todo servicio que corre en
una sola VM con SSD Premium en Azure, además de los hasta 43 minutos posibles
por SLA, va a tener bastante más tiempo de indisponibilidad del servicio que ese 99,9%.
99,95%
Pongamos el ejemplo de dos
controladores de dominio con rol además de DNS. Estará garantizado que estos
servidores funcionen un 99,95% del tiempo, o lo que es igual, de antemano has de
contar que el servicio que los servicios de Active Directory y DNS podrán no
funcionar durante 21 minutos cada mes, si las dos máquinas virtuales,
están colocadas en el mismo conjunto de disponibilidad y diferente dominio de error.
Cabe destacar también que en
esta configuración y al contar con dos VMS, estas podrán reiniciarse de forma ordenada,
sin que caiga els servicio. No como en la configuración anterior.
Grupos de disponibilidad y
dominios de error.
Los conjuntos de
disponibilidad, vienen a indicar a Microsoft que durante sus actualizaciones y problemas técnicos, estas dos máquinas virtuales no han de reiniciarse o caer por
estar en un mismo "bastidor" o "pasillo". De no ubicar
estos DCs del ejemplo, en el mismo conjunto de disponibilidad y si además, las máquinas se
crearon a la vez, hay grandes probabilidades que estén conviviendo incluso en el mismo host.
Vale la pena que leáis el
artículo siguiente, porque en el caso de tener más de tres servidores en un mismo servicio, vas a
tener que "jugar" también con los dominios de error.
Más info.: Información
general sobre los conjuntos de disponibilidad - Azure Virtual Machines |
Microsoft Learn
Grupo de disponibilidad: VMS
ubicadas en grupos de hosts que no se reiniciarán al mismo tiempo durante
actualizaciones.
Dominio de error: VMs ubicadas
en conjuntos de bastidores que no están alimentados ni cuentan con conexión a
red compartida, por lo que seguirán funcionando a pesar de caídas de
electrónica de red y alimentación conjunta, pongamos que si cada armario o
pasillo, comparte electricidad y red, estas máquinas estarán en dos bastidores o
dos pasillos diferentes.
99,99%
Esta es la cifra de disponibilidad
que cuenta el servicio si ubicamos dos VMs en dos zonas diferentes de la misma
región, eso si, siempre que tengamos el servicio bien diseñado, porque si ubicamos dos
VMS en dos Zonas, pero no tenemos VPN y una IP pública multi zona, realmente no
tendremos nada :(.
En comparación con la
disponibilidad anterior, estamos ubicando dos VMS en dos datacenters separados
un mínimo de 300 millas, no penalizando prácticamente en nada la latencia y
solo teniendo un incremento en coste por el dato saliente.
Impacto del dato saliente
entre zonas
El precio del Gb. entre zonas es
de 0,010€ y tenemos que considerar lo siguiente:
1. No tenemos VPN del tipo
VPNGTWXAZ, la cual redundan entre zona.
2. Según lo anterior, tendremos cargo
de tráfico entre zonas, por cada búsqueda de la máquina no asociada a la zona, donde tenemos una VPN básica o VPNGTWX normal.
3. Tráfico saliente de cada VM
hacia la otra.
4. No tendremos cargo de
tráfico hacia el Recovery Vault al ser este un recurso multizona.
Contar con una VPNGTWX del tipo que termina su nombr en AZ, es un fallo bastante habitual. El precio atractivo de estas
VPN frente a las multi zona -las terminadas en AZ- hace que el día que falle la zona a
la que está asociada la VPN, no tengamos acceso al DC que se mantiene
funcionando en la zona lejana. No olvidéis, como ya he dicho anteriormente, que la
IP pública asociada al VPN Gateway también ha de ser multi zona.
Planificación
del mantenimiento y el tiempo de inactividad - Training | Microsoft Learn
Notas:
- Puedes provocar que la VM se
reubique en otro Host, realizando un Redeploy de la misma.
- No puedes ubicar una VM en un
conjunto de disponibilidad, una vez creada. Para ubicarla en uno, has de
recuperar la VM de un Backup y con ello, crear una VM nueva.
lunes, 28 de noviembre de 2022
Levántate, configura cumplimiento de ISO 27001 en Azure, vete a desayunar
Pues sí, con Azure puedes levantarte, encontrar que ya tienes creada una suscripción, aplicar la ISO 27001:2013, la UKOFFICIAL and UK NHS y la Australian Government ISM Protected y salir para la oficina.
A la hora de cumplir ciertos requisitos o políticas propias de la compañía, poca gente sabe que se pueden crear esas lineas generales de cumplimiento o advertencia a través de las Políticas.
A mí personalmente me gustan las políticas que obligan a que se utilicen ciertas etiquetas o advertir, e incluso configurar automáticamente, el backup de VMs que cumplan ciertos criterios que les identifican como VMs en producción.
Cumplir la ISO 27001
A lo que iba. Hay una forma no solo de crear ciertas políticas, sino de crear toda una batería de ellas que sumadas todas, nos hacen cumplir buenas prácticas, tales como los Microsoft Managed Controls (hay más de 1.600 plantillas de securización de entornos)
azure-policy/built-in-policies/policyDefinitions at master · Azure/azure-policy (github.com)
La cuestión es que un buen número de políticas prediseñadas que se engloban para cumplir una norma, en Azure se llama Policy Initiatives y a través de esta opción, es muy muy fácil que apliques cumplimiento de toda una ISO 27001: 2013 con un par de clicks.
Resultado tras aplicación de lo que ahora vais a ver.
Ejemplos de advertencias:
Configuración paso a paso:
Para aplicar esto, solo tienes que seguir los siguientes pasos:
1. Ve a tu suscripción y elige políticas (Policies) en el grupo de opciones de configuración.
4. Podrás parametrizarlo un poco a tu entorno. Por ejemplo configurando si tienes Azure Arc o no.
5. Podrás revisar también los avisos y advertencias que trae la norma de cumplimiento.
Saludos.
viernes, 25 de noviembre de 2022
Inmutabilidad de copias en Azure Backup
Hola,
Abro aquí el primero de dos posts, donde hablaré de Inmutabilidad en Azure. En este primer artículo, me centraré en la inmutabilidad en el servicio de Backup, la cual está actualmente en preview.
La opción en cuestión, la tenéis en las propiedades del Recovery Service Vault que utilices.
Sobra decir, que Azure backup puede ser también nuestro sistema de copia de seguridad de servidores e información On Premise, ya que Microsoft integró
Una vez allí puedes habilitar la inmutabilidad en dos fases que describo a continuación.
- Inmutabilidad habilitada pero no bloqueada "Not Locked"
Con esta configuración tendremos inmutabilidad en nuestro sistema de almacenamiento del backup y nadie podrá variar los archivos e información resultante del backup mientras dure el tiempo de retención de la política que hemos aplicado.
Esto significa que si tenemos una retención de 7 días y una copia el último día del último mes, esta información desaparecerá progresívamente tras este tiempo y está garantizado la integridad del dato salvado, sabiendo que es exactamente el que se salvó, sin que el ransomware u otra clase de peligros, pueda cifrarlo dado que en sí, esto es una varación del datos.
- Inmutabilidad habilitada y bloqueada "Locked"
habilitar el Locked está lleno de advertencias y es que una vez activemos esta opción, nada ni nadie podrá borrar la información salvada mientras no venza. Esto significa que si tenemos un backup con retención 2 años, tendremos dos archivos pertenecientes al 31 de Diciembre de los dos últimos años y estos solo se borrarán llegado los dos años posteriores. Nosotros mismos como administradores, no podremos borrar esta información aun eliminando la máquina virtual, su backup e incluso la baja de la suscripción de Azure.
Tendremos por tanto asegurado y que acarrear el pago de la información salvada durante el tiempo de retención.
Aquí tenéis copias de mis máquinas virtuales, una vez he parado el backup de las mismas. Podréis apreciar que no aparece la opción de eliminar la información. De hecho, al eliminar el backup de la máquina, me ofrece dos opciones; una es eliminar la información tras el periodo de retención y otra es guardar la información para siempre.
Suscribirse a:
Entradas (Atom)
