Chapter 1
Onboarding
El proceso de onboarding en el equipo de infraestructura de IT está diseñado para integrar de la mejor forma a nuevos clientes y sus operaciones, evitando errores conocidos y procurando el servicio más óptimo posible desde el inicio.
Este documento busca guíar este proceso iniciando con asegurar la documentación, configurando los accesos necesarios a sistemas y herramientas. En la fase de incorporación, se lleva a cabo una presentación formal del cliente al equipo de IT, se explican las políticas de seguridad y cumplimiento, y se clarifican las expectativas y responsabilidades mutuas. La capacitación inicial incluye sesiones de orientación sobre el uso de sistemas y herramientas específicas, proporcionando acceso a manuales y recursos esenciales. Durante la integración, se realizan reuniones clave para revisar los proyectos en curso y se asignan tareas iniciales para asegurar una transición fluida. El seguimiento incluye reuniones periódicas para evaluar el progreso, resolver dudas y ajustar el servicio según las necesidades del cliente. Finalmente, se fomentan actividades de colaboración para consolidar la relación, asegurando que el cliente se sienta plenamente integrado y apoyado en todas sus operaciones.
Propuesta de arquitectura de Onboarding a clientes
Parte 1
-> ¿Quiénes somos y qué hacemos? resumen indispensable.
Nosotros que somos fulanitos de tal ofrecemos lo siguiente:
Servicios a.
Servicio b.
Servicio c.
-> Nosotros tomamos el control de…
<- ¿Qué, dónde, cómo lo tienes y cómo lo haces?
- Diagrama de arquitectura (¿Qué componentes son los que tienen?).
- Listado de servidores (De preferencia el acceso al Panel de administración).
- Endpoints/urls productivas (para agregarlas a monitoreo).
- Listado de usuarios que requieren acceso (Revisar separación de responsabilidades en liga de documentación abajo).
- Nombres y correos electrónicos de los usuarios que levantarán tickets a nuestra mesa de servicios.
Parte 2
-> Para que lo llevemos nosotros se hace ….
Servicios a.
–>Proceso 1
–>Proceso n
Servicio b.
–>Proceso 1
–>Proceso n
Servicio c.
–>Proceso 1
–>Proceso n
<- De lo que hacemos ¿Quién nos puede pedir…?
–>En el proceso 1 del servicio a quien puede participar o pedir o solicitar
–>En el proceso n del servicio c
[Matriz RACI y Matriz de escalamiento]
Subsections of Onboarding
Chapter 1
División de responsabilidades
División de responsabilidades
Tip
El área de Infraestructura AMX es responsable del estado de salud y correcto funcionamiento de los servidores que se encuentran bajo su cargo, reservándose las tareas de administración sobre estos.
Es por ello que se cuenta con un acceso controlado de usuarios a los diferentes servicios albergados en las máquinas virtuales encomendadas al área. Dichos servicios se exponen a través de dominios protegidos con certificados, y son monitoreados a petición y bajo priorización del cliente.
Ambientes
Los ambientes son entornos controlados y configurados para distintas fases del ciclo de vida del desarrollo de software. Cada ambiente cumple una función específica, desde el desarrollo inicial hasta la producción final, asegurando la calidad y estabilidad del software a medida que avanza de cara al cliente.
Desarrollo (Dev)
Desarrollo
Cambios continuos
Sin Monitoreo
El ambiente de Desarrollo (Dev) es el espacio dedicado a que los desarrolladores puedan crear, implementar y probar nuevas funcionalidades de manera libre y sin restricciones significativas. Es un entorno en constante cambio.
Aunque no se monitorean de manera exhaustiva los artefactos que corren sobre este ambiente, se reconoce la importancia de su funcionamiento continuo. Una disrupción en el ambiente de desarrollo puede causar demoras significativas en el progreso de los proyectos.
Los permisos hacia el equipo de desarrollo son amplios y flexibles que les permiten implementar, modificar y depurar código. Pueden realizar cualquier cambio necesario para desarrollar y probar sus funcionalidades, siempre y cuando se adhieran a buenas prácticas, como evitar cambios manuales que no sean reproducibles. Esto asegura que los desarrollos puedan ser replicados y mantenidos en otros ambientes.
Calidad (QA)
QA
Cambios controlados
Sin Monitoreo
El ambiente de Calidad (QA) se utiliza para realizar pruebas exhaustivas de las funcionalidades desarrolladas. Aquí, los testers evalúan el desempeño, seguridad, y cumplimiento de requisitos de las aplicaciones antes de que pasen a producción. Este entorno replica las condiciones de producción lo más fielmente posible para asegurar que las pruebas sean representativas.
Las pruebas incluyen, pero no se limitan a:
- Pruebas unitarias.
- Pruebas de integración.
- Pruebas de rendimiento.
- Pruebas de seguridad.
Los cambios en este ambiente están restringidos al equipo de QA y a los desarrolladores, quienes deben seguir procedimientos estrictos para implementar nuevas versiones.
Pre-producción (Preprod/Release/UAT)
Pre-producción
Cambios controlados
Monitoreo APM
El ambiente de Pre-producción (Preprod/Release) sirve como un paso intermedio entre QA y Producción. Aquí se realizan pruebas finales y verificaciones antes de que cualquier cambio sea llevado a producción. Este entorno es prácticamente idéntico al de producción y se utiliza para realizar pruebas de aceptación de usuario (UAT).
Preproducción está conectado exactamente a los mismos servicios y las mismas fuentes de datos que el ambiente de Producción. La única diferencia son los cambios en servicios que no están de cara al cliente final. En este ambiente se validan:
- La integración final de todos los componentes.
- La estabilidad del sistema bajo condiciones de producción.
- La preparación para el lanzamiento.
Sandbox
Sandbox
Cambios por RfC
Sin monitoreo
El ambiente Sandbox es una réplica del ambiente de producción utilizado para evaluación de equipos terceros. Los clientes pueden probar el uso e integración sin afectar datos de producción. Se busca resguardar la consistencia de funcionalidades con relación a producción.
Este ambiente es ideal para:
- Probar nuevas versiones de software.
- Evaluar nuevas herramientas o tecnologías.
- Experimentar con configuraciones avanzadas.
Producción (Prod)
Producción
Cambios por RfC
Monitoreo APM/Sintético
El ambiente de Producción (Prod) es donde las aplicaciones y servicios están disponibles para los usuarios finales. Este entorno requiere la mayor estabilidad, seguridad y rendimiento. Todas las funcionalidades deben estar completamente validadas y probadas antes de ser desplegadas aquí.
En este ambiente se deben seguir procedimientos estrictos de:
- Gestión de cambios.
- Monitoreo y alertas.
- Seguridad y cumplimiento normativo.
El acceso a este ambiente está altamente restringido y controlado para minimizar riesgos y asegurar la continuidad del servicio.
Matriz de responsabilidades
| Actividades Generales |
Dev |
QA |
Preproducción/Release |
Producción/Sandbox |
| Comandos linux |
Lectura logs y curl |
Lectura logs y curl |
n/a |
n/a |
| Apagados y reinicios de servicios |
Ticket |
Ticket |
Ticket |
Ticket |
| Operaciones bash |
Ticket |
Ticket |
Ticket |
Ticket |
| Programación/ejecución de crones |
Ticket/CI |
Ticket/CI |
Ticket |
Ticket |
| Gestión de usuarios sobre S.O. |
Ticket |
Ticket |
Ticket |
Ticket |
| Operaciones sobre BD |
Usuario admin |
Usuario admin |
Usuario r/o sobre datos no sensibles |
Usuario r/o sobre datos no sensibles |
| Gitlab |
Permisos Maintainer |
n/a |
n/a |
n/a |
| Despliegues/bajas de aplicativos |
CI |
CI con botón de autorizar |
Solicitud vía CI |
Ticket |
| Edición de archivos de configuración |
Ticket |
Ticket |
Ticket |
Ticket |
| Edición de archivos war/php |
Usuario con permisos rw |
Usuario con permisos ro |
Ticket |
Ticket |
1.0.0
Subsections of Manuales
Actualización de contenido estático en Telmex StaaS
Info
Este manual explica el proceso para añadir o modificar contenido de un sitio que está utilizando la herramienta de almacenamiento de recursos Amazon S3, detallando los pasos requeridos para configurar la AWS CLI y llevar a cabo las actualizaciones necesarias.
1. Prerrequisitos
2. Configuración de AWS CLI
La carga de contenido en sitios estáticos con almacenamiento en Amazon S3, utilizan AWS CLI. Presentamos los pasos para preparar la misma.
- Establecimiento de Credenciales
Después de instalar AWS CLI, usa el siguiente comando para ajustar tu usuario:
Con aws configure se establecerán los parámetros del propio usuario. Los campos AWS Access Key ID y AWS Secret Access Key deberán ser llenados con las credenciales previamente proporcionadas para su acceso. Se recomienda utilizar el nombre de la región cómo mxqr y el formato de salida por defecto cómo text
Una vez configurado su usuario de aws s3, puedes ejecutar el siguiente comando para listar el contenido del bucket:
aws s3 ls s3://<nombre-bucket>/ --endpoint-url https://s3-mxqr.almnube.telmex.com --no-verify-ssl
Desglosando el comando anterior:
-
aws s3 – > Comando para conexión a s3 de por aws cli
-
ls —> Comando list
-
s3://< nombre-bucket >/ —> Indicador s3, asegúrate de configurar el nombre correspondiente del bucket.
-
–endpoint-url https://s3-mxqr.almnube.telmex.com —> Endpoint de consulta para s3-telmex
3. Actualización de contenido sobre sitio estático
La carga de contenido se realizará mediante la interfaz de comandos de AWS, la cuál se instaló y configuró previamente.
Supongamos que se quiere visualizar contenido en la ruta https://<dominio-productivo>/ruta/contenido/imagen-carga-de-prueba.png , donde imagen-carga-de-prueba.png es el archivo que desea revisar como parte de los cambios recientes.
El bucket especificado es s3://<nombre-bucket>/, por lo que el contenido, a partir del primer /, se reflejará directamente en el sitio productivo.
Para visualizar el cambio, usaremos el contexto /ruta/contenido/imagen-carga-de-prueba.png y lo agregaremos al comando de carga de la siguiente manera:
s3://<nombre-bucket>/ruta/contenido/imagen-carga-de-prueba.png
Este será el archivo que se desea modificar
Ubica la ruta de tu archivo localmente y usa el siguiente comando para subir el archivo /ruta/contenido/imagen-carga-de-prueba.png
aws s3 cp /home/user/Downloads/imagen-carga-de-prueba.png s3://<nombrebucket>/ruta/contenido/imagen-carga-de-prueba.png --endpoint-url https://s3-mxqr.almnube.telmex.com --no-verify-ssl
Visto en la terminal de la siguiente manera
Desglosando el comando anterior:
-
aws s3 – > Comando para conexión a s3 de por aws cli
-
cp —> Comando copy
-
/home/user/Downloads/imagen-carga-de-prueba.png —> Archivo local
-
s3://<nombre-bucket>/ruta/contenido/imagen-carga-de-prueba.png —> Endpoint del dominio productivo donde se desea visualizar el contenido
-
–endpoint-url https://s3-mxqr.almnube.telmex.com —> Endpoint de consulta para s3-telmex
Obteniendo como resultado final la imagen cargada sobre la ruta https://<dominio-productivo>/ruta/contenido/imagen-carga-de-prueba.png
Ejemplo de carga de contenido en Telmex StaaS
- Visualizar Contenido en el Sitio
En este modelo se pretende visualizar un archivo para el sitio https://bucket-testing.prod.amxdigital.net en la ruta /portal/recursos-estaticos/imagen-carga-de-prueba.png, el archivo debe subirse en el bucket designado, para este caso será s3://bucket-test/ en la ubicación /portal/recursos-estaticos/imagen-carga-de-prueba.png
- Ubicación del archivo local
Localiza el archivo en tu máquina local, por ejemplo:
/home/user/imagen-carga-de-prueba.png
- Subir el contenido
El siguiente comando ejemplifica cómo subir un archivo al bucket de S3 utilizando las instrucciones descritas anteriormente.
aws s3 cp /home/user/Downloads/imagen-carga-de-prueba.png s3://bucket-test/portal/recursos-estaticos/imagen-carga-de-prueba.png --endpoint-url https://s3-mxqr.almnube.telmex.com --no-verify-ssl
- Resultado final
El archivo subido estará disponible en la URL:
https://bucket-testing.prod.clarodigital.net/portal/recursos-estaticos/imagen-carga-de-prueba.png
Diagrama de flujo del proceso
Ejemplo programático con python
import boto3
from botocore.config import Config
from botocore.exceptions import NoCredentialsError, PartialCredentialsError
# Configuración
S3_ENDPOINT = "https://s3-mxqr.almnube.telmex.com"
ACCESS_KEY = "your-access-key"
SECRET_KEY = "your-secret-key"
BUCKET_NAME = "your-bucket-name"
# Crear cliente S3
def create_s3_client():
try:
client = boto3.client(
"s3",
endpoint_url=S3_ENDPOINT,
aws_access_key_id=ACCESS_KEY,
aws_secret_access_key=SECRET_KEY,
config=Config(signature_version="s3v4"),
)
return client
except (NoCredentialsError, PartialCredentialsError) as e:
print(f"Error en las credenciales: {e}")
return None
# Subir un archivo
def upload_file(file_path, object_name):
s3_client = create_s3_client()
if s3_client:
try:
s3_client.upload_file(file_path, BUCKET_NAME, object_name)
print(f"Archivo {file_path} subido como {object_name}")
except Exception as e:
print(f"Error al subir el archivo: {e}")
# Descargar un archivo
def download_file(object_name, download_path):
s3_client = create_s3_client()
if s3_client:
try:
s3_client.download_file(BUCKET_NAME, object_name, download_path)
print(f"Archivo {object_name} descargado a {download_path}")
except Exception as e:
print(f"Error al descargar el archivo: {e}")
# Generar una liga firmada (Manejo de ligas para actualización pública de objetos).
def generate_presigned_url(object_name, expiration=3600):
s3_client = create_s3_client()
if s3_client:
try:
url = s3_client.generate_presigned_url(
"get_object",
Params={"Bucket": BUCKET_NAME, "Key": object_name},
ExpiresIn=expiration,
)
return url
except Exception as e:
print(f"Error al generar la liga firmada: {e}")
return None
# Ejemplo de uso
if __name__ == "__main__":
# Subir un archivo
upload_file("local_file.txt", "uploaded_file.txt")
# Descargar un archivo
download_file("uploaded_file.txt", "downloaded_file.txt")
# Generar una liga firmada
url = generate_presigned_url("uploaded_file.txt")
if url:
print(f"Liga firmada: {url}")
Manual de OTRS
OTRS
Info
El sistema de tickets es una herramienta útil para poder dar seguimiento a cada una de la soliciudes y controles de cambio, nos permite iterativamente estandarizar procesos y procedimientos para proporcionar consistencia y certidumbre a nuestros clientes y usuarios finales. El presente manual contiene la información necesaria para levantar una solicitud o incidencia, dar seguimientoo retroalimenatación y cierre en OTRS.
Acceso a OTRS
- El usuario ingresa al sistema OTRS al teclear en su buscador la siguiente URL:
https://otrs.amxdigital.net/otrs/customer.pl
Aparecerá la página de acceso al sistema:
-
El usuario ingresa el nombre de usuario “Username” y contraseña “Password” y pulsa sobre el botón “log In”
-
La página de inicio que aparece es la siguiente:
Creación de una solicitud
- Para la creación de una nueva solicitud, un usuario autenticado navega sobre el menú de inicio del sistema, identifica el botón “Tickets” y pulsa sobre el botón para desplegar un menú. Para crear una nueva solicitud, pulsar sobre la opción “New Ticket”.
- Posterior a la selección de New Ticket, se despliega el asistente de creación de solicitudes.
- Aparece en pantalla un botón con la frase “Seleccione un componente”, se debe pulsar el botón para desplegar un menú para visualizar la lista de posibles tipos de solicitudes.
Tipos de Solicitudes
- Reporte de Incidente: Afectación o interrupción en la funcionalidad de un servicio.
- Operaciones recurrentes: Solicitudes estandarizadas y repetibles para mantener activo un servicio
- Control de Cambios: Solicitudes únicas que impactan arquitectura, topología de red o seguridad.
- Una vez seleccionado el componente específico, se despliegan en pantalla las opciones para “crear solicitud” o “reportar incidencia”
- Una vez que se haya seleccionado la opción, se abre una nueva ventana que contiene el formato vigente de solicitud o incidencia correspondiente a la selección previa:
-
En la sección “To” aparecen las iniciativas a las que tiene acceso y debe seleccionar la iniciativa a la que va dirigida la solicitud. En caso de que su iniciativa no aparezca favor de contactar a Cecilia Martínez (cecilia.martinez@americamovil.com) para dar de alta la iniciativa correspondiente para AMX o a Rafael Herández Meza (rafael.hernandez@claroshop.com) para dar de alta la iniciativa correspondiente para GS
-
Incluir toda la información solicitada en el formato. En caso de dejar información en blanco,esta se solicitará hasta que este completa.
-
En la sección “Priority” De preferencia colocar “Default”, ya que esta es asignada por el equipo de Infraestructura.
- Finalmente deberá oprimir el botón “Submit” para generar la solicitud.
Seguimiento de Solicitudes
Visualización de mis tickets
- El usuario puede visualizar sus solicitudes al dirigirse al menú de opciones para tickets y seleccionar la opción “My tickets”, en consecuencia, aparecerá en pantalla un listado con las solicitudes generadas por el usuario para su consulta.
-
Todas las solcitudes tienen una confirmacioń automática de recepción, a partir de ese momento el equipo de infraestructura revisará que la prioridad marcada sea adecuada o este bien justificada y revisará que el formato tenga toda la información. En caso de encontrar dudas el equipo de infraestructura le solicitará la información necesaria.
-
Para obtener más información de la solicitud, presione sobre el nombre y aparecerá en pantalla un listado con los mensajes y la información relacionada con esa solicitud.
- Ticket Number: Es el identificador único de solicitud en el sistema OTRS.
- State: Es el estado en que se encuentra la solicitud.
- Priority: Es la prioridad de la solicitud asignada por el equipo de Infraestructura
- Queue: Es la inicitiva de la solicitud.
Estados de una solicitud
|
|
| Estado de Ticket |
Criterio |
| Pending Missing Information |
Se identificó que la solicitud carece de información necesaria para ejecutar la solicitud y el usuario deberá proporcionar la información de acuerdo a las indicaciones del equipo de Infraestructura. |
| Pending Authorization |
Se identificó que el solicitante no tiene autorización para generar la solicitud y esta requiere de la aprobación del responsable correspondiente para ejecutarse. |
| Awaiting Scheduled Time |
Se identificó que la solicitud tiene una fecha y hora indicada para ejecutarse dentro de las instrucciones de la solicitud. |
| Awaiting Precedent Requirement |
Se identificó que es necesaria la ejecución de alguna solicitud previa antes de ejecutar la solicitud generada. |
| Queued-L2 |
La solicitud está en atención de un líder técnico especializado. |
| Pending Validation |
La solicitud tiene una respuesta de atención por parte del equipo de infraestructura que el usuario deberá validar. |
| Closed Successful//Closed Without Validation |
La respuesta por parte del equipo de infraestructura fue validada por el usuario. // La solicitud ha pasado dos días hábiles en “Pending Validation” |
Solicitudes del mismo País o Iniciativa
El sistema de tickets OTRS, permite a los usuarios de un mismo país o iniciativa dar seguimiento a las solicitudes generadas por otros usuarios que igualmente pertenezcan al mismo país o iniciativa.
Para esta tarea el usuario deberá dirigirse al menú de opciones Tickets y seleccionar la opción “Company Tickets”, se desplegará un listado con todas las solicitudes generadas por el mismo país o iniciativa. En caso de necesitar más información sobre alguna solicitud específica, deberá pulsar sobre el nombre de la solicitud y aparecerán los detalles de dicha solicitud.
Seguimiento a Incidentes
Para la atención de incidentes es necesario otorgar la mayor cantidad de información disponible para la pronta resolución de esta y estar en constante comunicación con el equipo de infraestructura. Por favor tomar en cuenta que los incidentes se atienden con la máxima prioridad posible, un falso positivo puede retrasar otras solicitudes importantes, asegurarse de que en verdad se trata de una incidencia permite mantener mejores flujos de trabajo.
Autorización solicitudes BAU
-
Las solicitudes recurrentes para ambientes productivos deberán tener por lo menos la autorización del Líder de Iniciativa o Proyecto.
-
Para ello, en caso de que la solicitud no sea levantada directamente por el líder de Iniciativa o Proyecto, se soliciatará la autorización correspondiente.
Autorización y Aprobación de solicitudes RFC
-
Las solicitudes de cambio, que por su naturaleza, impactan la arquitectura, topología de red o seguridad, necesitan además de la autorización del Líder de Iniciativa o Proyecto, la aprobación del Gerente de Infraestructura correspondiente.
-
Para ello se solicitará la autorización del Líder de Iniciativa o Proyecto y posteriormente se informará de un estimado de tiempo para la aprobación del Gerente de Infraestructura o en su defecto las acciones a seguir para evaluar el cambio.
Retroalimentación de una Solicitud
- El usuario puede dar retroalimentación, pulsando sobre el botón “Reply”, aparecerá una forma web con campos que no se recomiendan modificar, así como un campo de texto libre donde puede colocar, según sea el caso, la información faltante, la autorización correspondiente o la validación del ticket. Para finalizar el proceso, se debe pulsar sobre el botón “submit”.
- Igualmente si su correo esta copiado en la línea de tickets, puede contestar el correo de la misma manera como contestaria algún otro correo desde su cliente de correo electrónico.
Cierre de una Solicitud.
Todos los tickets
- Una vez que el requerimiento haya sido atendido y no se cuente con retroalimentación relevante a la correcta ejecución de las actividades originadas en la solicitud, se deberá proceder al correcto cierre de la solicitud. Para realizar el cierre de solicitud se debe utilizar la forma de retroalimentación de una solicitud y escribir:
“Validado, favor de cerrar ticket” y presionar el botón “Submit”
Recuperación de contraseña de OTRS
- El usuario deberá presionar el botón “Forgot password?”
- Después, deberá ingresar su nombre de usuario “User name” y presionar el botón “submit” para generar una nueva contraseña que podrá ser revisada en el correo con el que fue dado de alta.
Configuraciones en OTRS
En la página de inicio de OTRS presionar el botón “Preferences” donde se pueden cambiar parámetros como la contraseña, el lenguaje, el intervalo de actualiación de información y el número de tickets desplegados por página.
Configuración OpenVPN MacOS
Note
El presente manual se emite exclusivamente como instrumento de apoyo para las áreas competentes en la administración, custodia, y soporte de equipos de cómputo local (laptops o computadoras) para cumplimentar la solicitud de soporte de infraestructura para el trámite de acceso por VPN mediante la creación de Llaves RSA. Este documento es de carácter práctico, queda bajo total responsabilidad de los clientes el: uso, aseguramiento, resguardo, mantenimiento, y tratamiento de los artefactos generados. El equipo de infraestructura se deslinda de cualquier intervención o solicitud de soporte para la: ejecución, implementación o supervisión de procedimientos a equipos locales por quedar fuera del tramo de responsabilidad, limitando su participación a la atención de la disponibilidad del servicio de autenticación, autorización y conectividad al servicio de VPN y la subsecuente conectividad entre los servicios de TIC soportados dentro de la misma.
Prerrequisitos
- Certificado de Autoridad (CA)
- Certificado del usuario, este es personal
- Llave privada, la misma con la que se generó el CSR
- Tener instalado OpenVPN
Procedimiento
1.- Deberás descargar todos los recursos necesarios y colocarlos en un directorio especifico para esta configuración
2.- Ahora crea un nuevo archivo en este directorio, que se llame auth.
Debe contener el usuario y contraseña de la vpn compartidos para tu acceso
3.- Crea otro archivo que identifiques, con la extensión " .ovpn " y el contenido debe ser similar a este ejemplo
Es necesario editar aquellos detalles como nombres, ip, puertos, etc.
4.- Ahora iniciamos openvpn, y veremos la interfaz de esta tecnología
5.- Hacemos clic en las tres lineas de la parte superior derecha
6.- vamos a la sección “File” y seleccionamos “Browser”
7.- Buscamos y cargamos el archivo “.ovpn” que creamos
8.- De estar correcta la información, nos actualizará la pantalla y solo basta con hacer clic en “ADD”
9.- Nos regresará a la pantalla de inicio, entonces podemos presionar el botón de encendido y se conectará
10.- Listo, tu vpn esta activa. Si te desplazas hacia abajo, puedes ver la información como ip asiganda, ip servidor, puerto, protocolo
Creación de llaves para OpenVPN
Llaves RSA
Info
Las llaves RSA son un tipo de criptografía asimétrica que se utiliza para asegurar la comunicación y proteger la información. La criptografía asimétrica se basa en la utilización de dos llaves: una pública y otra privada. La llave pública se puede compartir abiertamente, mientras que la llave privada debe mantenerse en secreto. Cuando se envía un mensaje cifrado con la llave pública, solo puede ser descifrado con la llave privada correspondiente. De esta manera, si alguien intercepta el mensaje, no podrá leerlo sin conocer la llave privada.
Note
El presente manual se emite exclusivamente como instrumento de apoyo para las áreas competentes en la administración, custodia, y soporte de equipos de cómputo local (laptops o computadoras) para cumplimentar la solicitud de soporte de infraestructura para el trámite de acceso por VPN mediante la creación de Llaves RSA. Este documento es de carácter práctico, queda bajo total responsabilidad de los clientes el: uso, aseguramiento, resguardo, mantenimiento, y tratamiento de los artefactos generados. El equipo de infraestructura se deslinda de cualquier intervención o solicitud de soporte para la: ejecución, implementación o supervisión de procedimientos a equipos locales por quedar fuera del tramo de responsabilidad, limitando su participación a la atención de la disponibilidad del servicio de autenticación, autorización y conectividad al servicio de VPN y la subsecuente conectividad entre los servicios de TIC soportados dentro de la misma.
Creación de llaves por tipo de sistema Operativo
flowchart TD
id1["<b>¿Qué tipo de Sistema Operativo tengo?</b>"]
id1 -->id2[<a>Windows</a>]
id1 -->id3[<a>Linux</a>]
id1 -->id4[<a>Mac</a>]
click id2 href "/clientes/manuales/llavesrsa-manual/#windows"
click id3 href "/clientes/manuales/llavesrsa-manual/#linux"
click id4 href "/clientes/manuales/llavesrsa-manual/#mac"Windows
Note
Ésta guía está basada en Windows XP para fines demostrativos.
Obtener cliente de OpenVPN
- Obtener el cliente de openvpn que mejor se adapte al sistema operativo y versión actual
Note
La versión 2.4.9 ha sido reportada como no compatible).
- Ejecute el instalador de su sistema operativo de acuerdo a los procedimientos intrínsecos de la misma.
Note
Asegúrese de instalar los componentes de OpenSSL.
Note
Acepte las alertas de seguridad cuando su SO le pregunte si desea instalar los drivers no seguros.
- Finalice instalación
Pasos previos
- Mueva el directorio easy-rsa a una ruta fácil de administrar.
c:\Archivos de programa\OpenVPN>move easy-rsa ../../
- Genere un directorio de llaves
c:\Archivos de programa\OpenVPN\easy-rsa>mkdir keys
Creación de llave privada
Warning
NUNCA COMPARTA EL .key FILE
- Para construir su llave privada utilice el siguiente comando:
openssl req -days 365 -nodes -new -keyput keys/name.lastnamen
Enviar CSR para firmar
- Deberá de enviar su CSR a firmar de acuerdo al formato 2. CREACIÓN O ACTUALIZACIÓN DE CERTIFICADOS DE USUARIO
- Se le regresarán dos archivos: su certificado firmado y la CA. Instale el certificado de la CA en el repositorio de certificados de su sistema operativo.
Arranque y Validación de VPN
- Después de instalar el certificado de la CA, la firma del certificado que se le entregó será marcado como “de confianza”.
- Edite y almacene el archivo de configuración.
- Una vez que haya guardado dicho archivo de click en “Start OpenVPN on this config file”
- Podrá apreciar una conexión exitosa si las rutas de la vpn son agregadas a su sistema.
Linux
Generar Llave privada
Warning
ARCHIVO PRIVADO - ¡NO COMPARTIR NUNCA!
openssl genrsa -des3 -out nombre.apellido.key 4096
Note
En linux, después de generar el key, de preferencia se deben cambiar los permisos para sólo lectura del usuario de creación.
chmod 600 nombre.apellido.key
Generar llave pública
Note
Se debe utilizar la llave privada creada en el punto anterior
ssh-keygen -y -f nombre.apellido.key > nombre.apellido.pub
Generar CSR
Generar el archivo CSR para solicitar acceso por VPN y SSH
openssl req -out nombre.apellido.csr -key nombre.apellido.key -sha256 -new
Un ejemplo de llenado es el siguiente:
|
|
| Organization Name(Company) |
Grupo Carso |
| Organizational Unit Name (department, division) |
Gerencia de Sistemas |
| Email Address |
correo@correocorporativo.com |
| Locality Name (city, district) |
CDMX |
| Country Name (2 letter code) |
MX |
| Common Name (hostname, IP, or your name) |
Julio Florencio Cortázar |
Verificar el archivo
Para CSR
openssl rsa -in nombre.crt -noout -text
para .key
openssl rsa -in nombre.key -noout -text
Note
El valor de módulo debe ser igual, también se puede verificar las primeras 6 letras y las últimas 6, deben de coincidir.
MAC
Chapter 2
Crear servicio - Backstage
Para que sirve esta pagina
Esta pagina te ayuda a registrar un servicio en Backstage y, si lo necesitas, dejar listo su flujo de integracion y despliegue.
Al finalizar tendras:
- El servicio visible en Backstage.
- La relacion del servicio con su proyecto y su equipo.
- El registro del servicio en el repositorio.
- El pipeline de CI/CD, si elegiste crearlo.
Antes de comenzar
Antes de llenar el formulario, ten a la mano esta informacion:
- El nombre del proyecto o iniciativa al que pertenece el servicio.
- El nombre del servicio.
- El equipo responsable.
- El grupo de GitLab dueño del repositorio.
- El nombre del repositorio.
- El nombre real del proyecto en GitLab, si vas a crear pipeline.
- El lenguaje del servicio, si vas a crear pipeline.
Donde entrar
Ingresa a la siguiente direccion:
https://corehub.amxdigital.net/create/templates/default/service-simple-register-ci-promotion
Luego inicia sesion con tus credenciales habituales.
Sigue los campos en este orden.
1. Que deseas hacer
Aqui debes elegir el escenario que mejor describe tu caso.
Crear nuevo repositorio vacio para un servicio
> Usa esta opcion cuando todavia no existe repositorio y vas a comenzar desde cero.
Agregar un servicio nuevo con repositorio existente
> Usa esta opcion cuando el repositorio ya existe y solo quieres registrar el servicio y dejar su configuracion lista.
Actualizar servicio y su repositorio
> Usa esta opcion cuando el servicio ya existe y necesitas corregir o actualizar su informacion.
2. Nombre del proyecto o iniciativa
Selecciona de la lista el proyecto al que pertenece el servicio.
Todos los servicios de una misma iniciativa deben usar el mismo proyecto. Eso ayuda a que queden agrupados correctamente en Backstage.
Ejemplos de proyecto:
- Alertas Competencia
- Dashboard Digital
- Portal Comercial GT
- Telcel Carrito
- Sustentabilidad
3. Nombre del servicio
Es el nombre principal del servicio.
Ese nombre se usara como referencia en varios lugares, por ejemplo en Backstage y en recursos creados para el servicio.
Recomendacion:
- Usa un nombre claro.
- NO uses espacios.
- Usa el mismo nombre que ya maneja el equipo si el servicio ya existe.
Sigue la siguiente formula para nombrar los aplicativos:
amx-{Iniciativa}-{servicio}
Por ejemplo,
- Un servicio llamado “Reporte Catalogo Uni”
- Parte de la iniciativa “Portal Reportes EC”
El nombre es:
amx-portal-reportes-ec-reporte-catalogo-uni
- Un servicio llamado “Planes Promo MS BE”
- Parte de la iniciativa “Portal Reportes EC”
El nombre es:
amx-portal-reportes-ec-planes-promo-ms-be
- Un servicio llamado “Authentication”
- Parte de la iniciativa “Registro Ventas”
El nombre es:
amx-registro-ventas-authentication
- Un servicio llamado “SSOLoginRedisV2.4”
- Parte de la iniciativa “App CENAM”
El nombre es:
amx-app-cenam-sso-login-redis-v2-4
4. Que tipo de componente es
Selecciona el tipo de componente que mejor describe el servicio.
Esto ayuda a clasificarlo correctamente dentro de Backstage.
Si tienes duda, elige la opcion que normalmente use tu equipo para servicios similares.
5. Equipo asociado
Selecciona el equipo responsable del servicio.
Esto permite que el servicio quede asociado al grupo correcto y que las personas adecuadas puedan identificarlo y administrarlo.
Verifica este dato con cuidado, porque es una de las partes mas importantes del registro.
6. Repositorio de GitLab
En esta parte veras dos campos:
Owner AvailableRepository
Debes separar la informacion del repositorio en esas dos partes.
Ejemplo 1
Si tu repositorio es:
https://portal-developers.amxdigital.net/Claro-Chile/cl_ms_fe_bancoestado_backstage
Debes capturarlo asi:
Owner Available: Claro-ChileRepository: cl_ms_fe_bancoestado_backstage
Ejemplo 2
Si tu repositorio es:
https://portal-developers.amxdigital.net/amx_dashboarddigital/dd-logmanagement
Debes capturarlo asi:
Owner Available: amx_dashboarddigitalRepository: dd-logmanagement
Si tambien quieres crear pipeline de CI/CD
Si deseas que el servicio quede con pipeline desde este mismo proceso, llena tambien esta seccion.
7. Quieres crear un pipeline de CI/CD
Marca esta opcion solo si quieres crear el pipeline ahora.
Ten presente lo siguiente:
- Si el pipeline ya existe, no lo vuelvas a crear.
- Si no estas seguro, primero confirma con tu equipo.
8. Nombre del repositorio
Aqui debes colocar el nombre real del proyecto dentro de GitLab.
Este valor puede no verse igual que el nombre escrito en la URL.
Ejemplo
Si la URL es:
https://portal-developers.amxdigital.net/amx_dashboarddigital/dd-logmanagement
El valor correcto podria ser:
DD-LogManagement
Si tienes duda, abre el proyecto en GitLab y revisa el nombre mostrado en la parte general.
9. Lenguaje del servicio
Selecciona el lenguaje principal del servicio.
Este dato es importante porque define la configuracion base del pipeline.
Elige con cuidado la opcion correcta para evitar configuraciones equivocadas.
Recomendaciones antes de enviar
Antes de continuar, revisa especialmente estos datos:
- Proyecto o iniciativa.
- Nombre del servicio.
- Equipo asociado.
- Owner de GitLab.
- Nombre del repositorio.
- Nombre del proyecto en GitLab, si vas a crear pipeline.
- Lenguaje del servicio, si vas a crear pipeline.
Si alguno de estos datos queda mal, el alta puede requerir correcciones despues.
Resultado esperado
Si todo fue llenado correctamente, el servicio quedara registrado y visible en Backstage.
Si tambien elegiste crear pipeline, el flujo de CI/CD quedara generado junto con la configuracion base necesaria para su uso.
Gravitee Api Manager
Introducción
Info
Gravitee es una solución integral para la gestión de API, que ayuda a los desarrolladores a crear, desplegar y monitorear sus API de manera eficiente, proporciona una serie de herramientas para el desarrollo, el despliegue, la seguridad y la monitorización.
Inicio rápido
Gravitee API Manager consta de dos componentes principales para desarrolladores:
- Consola de administración proporciona una interfaz web para administrar y configurar las APIs.
- Portal para desarrolladores proporciona una interfaz para que los desarrolladores registren, documenten, prueben y monitoreen las APIs.
Ambos componentes trabajan juntos para ofrecer una experiencia completa y fácil de usar para desarrolladores y administradores de APIs.
Arquitectura general
Console UI:
Es una interfaz web que permite a los administradores configurar y gestionar la plataforma de manera sencilla.
Los desarrolladores pueden realizar varias actividades en la consola de usuario (UI) de Gravitee API Manager, algunas de las principales incluyen:
- Crear y gestionar APIs: Los desarrolladores pueden crear nuevas APIs y configurar sus detalles, como la autenticación, autorización y políticas de seguridad. También pueden editar y eliminar APIs existentes.
- Manejo de usuarios y roles: Los desarrolladores pueden crear y gestionar usuarios y roles, asignando diferentes permisos para acceder y utilizar las APIs.
- Monitoreo y análisis: La consola de usuario proporciona herramientas para monitorear el rendimiento de las APIs, como estadísticas de tráfico y errores, y herramientas para analizar el uso de las APIs.
- Documentación y soporte: Los desarrolladores pueden crear y publicar documentación para las APIs, incluyendo ejemplos de código y detalles de las solicitudes y respuestas. También pueden proporcionar soporte para los usuarios de las APIs.
- Gestión de versión: Los desarrolladores pueden manejar versiones de sus API, ya sea cambiando o creando nueva versiones, y asignando diferentes políticas de seguridad.
Alta de API
-
El registro de un API en Gravitee API Manager se hace a través del menú principal en la izquierda. En la sección de APIs, haga clic en el botón ‘+Agregar API’.
-
El asistente de creación de API nos guía a través de varios pasos. Se recomienda seguir las mejores prácticas para REST, disponibles en la guía mejores prácticas.
2.1 Se selecciona “Continue in the wizard”
2.2 Se especifica el nombre, la versión conforme al versionado semántico, una descripción, y un contexto único por cada servicio.
2.3 Se crea el primer plan con: el nombre del plan, el tipo de seguridad, la descripción del plan, y los recursos que debe involucrar.
2.4 En caso de contar con el diseño en OpenAPI se puede cargar en este paso, en caso contrario se da click sobre “skip”.
2.5 Se finaliza el asistente creando e iniciando la api.
-
Consola de administración general de API
Portal de desarrolladores:
Es una interfaz web que permite a los desarrolladores registrar sus aplicaciones y solicitar claves de API.
- Los desarrolladores pueden realizar varias actividades en el portal para desarrolladores de Gravitee API Manager, algunas de las principales incluyen:
- Registro y obtención de claves de acceso: Los desarrolladores pueden registrarse en el portal y solicitar claves de acceso para utilizar las APIs.
- Documentación y soporte: El portal proporciona documentación detallada y ejemplos de código para ayudar a los desarrolladores a utilizar las APIs. También proporciona una sección de soporte para que los desarrolladores puedan hacer preguntas y obtener ayuda.
- Pruebas de APIs: El portal permite a los desarrolladores probar las APIs antes de implementarlas en sus aplicaciones, ya sea a través de una consola interactiva o mediante una herramienta de prueba automatizada.
- Monitoreo y análisis: Los desarrolladores pueden monitorear el rendimiento de las APIs y analizar su uso, mediante las estadísticas y gráficos proporcionados en el portal.
- Analítica de datos: El portal proporciona analítica de datos de las APIs, para ayudar a los desarrolladores a entender como los usuarios utilizan las APIs y para mejorar la experiencia de usuario.
- Gestión de versión: Los desarrolladores pueden obtener acceso a diferentes versiones de las APIs y también pueden verificar cambios en las versiones.
Alta de aplicación
En Gravitee API Manager, una API se compone de varios elementos básicos, algunos de los cuales incluyen:
- Endpoints: Un endpoint es un punto de acceso de una API que se utiliza para recibir y responder a las solicitudes de los clientes.
- Plan de precios: Un plan de precios es un conjunto de reglas que especifican el número de solicitudes permitidas, el ancho de banda, el almacenamiento y otros límites de uso.
- Autenticación y autorización: Una API puede requerir autenticación y autorización para garantizar que solo los usuarios autorizados puedan acceder a ella.
- Documentación: Una API debe proporcionar documentación detallada sobre cómo usarla, incluyendo ejemplos de código y descripciones de los parámetros de entrada y salida.
Api Gateway:
Es el componente principal de Gravitee que se encarga de recibir las solicitudes de las API y de aplicar las políticas de seguridad y autenticación configuradas.
Management API:
Es una API que permite a gravitee gestionar y configurar la plataforma.
Ligas de referencia
Procedimiento de solicitud de modificación de API-Manager
-
El usuario genera el ticket en OTRS utilizando el siguiente formato:
[05.RFC - Modificación de componentes de infraestructura (modificación a los componentes ya instalados).]
- El equipo de Infraestructura Analizará la información proporcionada y:
- Solicita al remitente la información faltante
- o
- Solicita el VoBo o Autorización del jefe inmediato o de algún superior facultado.
- El usuario responde:
- Con la información restante reiniciando en el punto 2
- o
- Adjunta evidencia de VoBo o autorización que impida el repudio posterior del jefe inmediato o algún superior facultado
- El equipo de infraestructura atiende enviando evidencia de la ejecución.
- El usuario valida la correcta ejecución o contesta indicando el error.
Guía de actualización MySQL 5.7 a 8.0
Warning
El ciclo de vida de MySQL 5.7 terminó el 21 de Octubre de 2023. A fin de mantener soporte y actualizaciones de seguridad todas las instancias que tengan este motorbases de datos con esta versión deben de ser actualizados.
Info
Antes de realizar un upgrade a MySQL 8, tanto los usuarios como los desarrolladores deben considerar una serie de aspectos importantes para garantizar una transición fluida y minimizar posibles problemas.
Algunas consideraciones clave son:
Para Usuarios Finales:
-
Compatibilidad de Aplicaciones: Verificar que todas las aplicaciones y herramientas que dependen de MySQL sean compatibles con la versión 8. Algunas características o cambios pueden romper la compatibilidad con versiones anteriores.
-
Pruebas en un Entorno de Desarrollo: Realizar pruebas exhaustivas de las aplicaciones en un entorno de desarrollo que simule las condiciones del entorno de producción. Esto ayudará a identificar posibles problemas de compatibilidad o funcionalidad antes de realizar la actualización en producción.
-
Documentación: Revisar la documentación oficial de MySQL 8 para comprender las nuevas características, cambios y consideraciones de migración.
https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-sql-changes
Para Desarrolladores:
-
Compatibilidad de Consultas: Revisar y actualizar consultas SQL para garantizar que sean compatibles con MySQL 8. Algunas características o sintaxis pueden haber cambiado o mejorado en la nueva versión.
-
Manejo de Errores y Excepciones: Reforzar el manejo de errores y excepciones en las aplicaciones para anticipar posibles cambios en el comportamiento de MySQL 8 y garantizar una respuesta adecuada a situaciones inesperadas.
-
Optimización de Consultas: Aprovechar las nuevas características de optimización de consultas introducidas en MySQL 8 para mejorar el rendimiento de las aplicaciones y consultas SQL existentes.
-
Seguridad y Privilegios: Revisar y actualizar los mecanismos de seguridad y control de acceso para aprovechar las mejoras de seguridad introducidas en MySQL 8, como la autenticación basada en roles y el plugin de Autenticación. *Los usuarios deberan ser recreados para que use dicho plugin de autenticación.
https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatible-connectors
https://dev.mysql.com/downloads/connector/cpp/
-
Validación de compatibilidad de clientes: Es fundamental verificar la compatibilidad de los drivers del cliente, que se están utilizando, sean compatibles con MySQL 8. Esta revisión es necesaria para garantizar un funcionamiento óptimo y sin problemas del sistema.
https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatible-connectors
https://dev.mysql.com/downloads/connector/cpp/
-
Pruebas Unitarias y de Integración: Realizar pruebas exhaustivas de todas las funcionalidades de la aplicación, incluyendo pruebas unitarias y de integración, para verificar que todo funcione correctamente en MySQL 8.
-
Documentación: Revisar la documentación oficial de MySQL 8 para comprender las nuevas características, cambios y consideraciones de migración.
https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-sql-changes
