Análisis en profundidad: Capacitación bajo demanda de Encryption Consulting sobre Thales Luna 7 HSM: un recorrido técnico.

La mayoría del material de capacitación de Luna 7 se detiene en el asistente de configuración del dispositivo y deja que los ingenieros averigüen por su cuenta la topología de partición, los procedimientos de custodia de claves PED, la selección de NTLS frente a STC y el ajuste del grupo HA, generalmente en producción, bajo presión y con configuraciones poco documentadas heredadas de quienquiera que haya creado el entorno hace tres años.

HCSE de Encryption Consulting Entrenamiento bajo demanda con Luna 7 Está estructurado de forma diferente. Este es un desglose de lo que abarca el curso a nivel técnico, módulo por módulo, con suficiente detalle para evaluar si se ajusta a las necesidades específicas que su equipo intenta subsanar.

Arquitectura de Luna 7 antes de tocar una línea de comandos

El límite del hardware, la validación FIPS 140-2 Nivel 3 y tres factores de forma que dan forma a cada decisión de diseño posterior.

El límite del hardware y por qué es importante

El Thales Luna Network HSM 7 es un dispositivo de montaje en rack de 1U o con conexión PCIe, construido alrededor de un procesador criptográfico dedicado con un entorno de ejecución físicamente aislado. llave privada El material se genera, almacena y utiliza exclusivamente dentro de ese entorno. El sistema operativo anfitrión y todos los procesos que se ejecutan en él no tienen acceso al material de la clave en texto plano en ningún momento del ciclo de vida de la clave.

El límite se aplica a nivel de hardware y se valida bajo FIP El nivel 3 de la norma 140-2 exige pruebas físicas de manipulación, resistencia a la manipulación y autenticación basada en la identidad. El nivel 3 va más allá del nivel 2 (que solo exige pruebas de manipulación) al obligar al HSM a borrar el material de clave al detectar cualquier intento de manipulación, eliminando así cualquier posibilidad de extracción de clave, incluso mediante acceso físico al dispositivo.

La línea de productos Luna 7 abarca tres modelos de implementación, cada uno de los cuales comparte el mismo núcleo criptográfico:

• Luna Network HSM 7Dispositivo independiente de 1U conectado a clientes a través de TCP/IP mediante NTLS o STC. Varios clientes pueden compartir una única interfaz. HSM a través del modelo de partición.
• Luna PCIe HSM 7Conexión PCIe directa a un servidor host. Elimina la latencia de red, pero limita el HSM a ese host físico. Es común en implementaciones de HSM para sistemas de pago, donde el rendimiento es la principal limitación.
• Luna Cloud HSMInstancias HSM gestionadas por Thales accesibles a través de la plataforma Data Protection on Demand (DPoD). Utiliza la misma interfaz PKCS#11 y JCA/JCE que los HSM Luna locales, lo que permite implementaciones híbridas sin necesidad de modificar el código del cliente.

El curso abarca los tres formatos. Comprender las diferencias topológicas es fundamental: el diseño de particiones, la estrategia de copias de seguridad, la configuración de grupos de alta disponibilidad y la conectividad de clientes difieren significativamente entre ellos.

Módulo 2: Autenticación de dispositivos PED, el mecanismo que la mayoría de los equipos utilizan incorrectamente

Los cinco colores de las teclas PED, el quórum M-of-N, el PED remoto y el modo de transporte seguro, la causa de la mayoría de los bloqueos de producción, explicados antes de que le cuesten una.

Cómo funciona realmente la autenticación de quórum multifactor

La autenticación mediante dispositivo de entrada PIN (PED) de Luna 7 es uno de los aspectos más complejos de la plataforma y la causa de la mayoría de los bloqueos en entornos de producción. El curso le dedica un módulo completo, y la profundidad con la que se aborda está justificada.

El PED es un dispositivo USB dedicado con teclado físico y pantalla. Es el único canal autorizado para introducir las credenciales de autenticación en el HSM para roles que requieren verificación de presencia física. Este diseño de seguridad es intencional: las credenciales nunca se escriben en el teclado del host, nunca se transmiten por la red sin cifrar y nunca se almacenan en la memoria del host.

Llaves PED son tokens USB iKey que almacenan secretos específicos de rol en formato cifrado. Cada rol en el HSM: Oficial de seguridad del HSM (SO), SO de partición, Oficial criptográfico (CO), Usuario criptográfico (CU) y Auditoría, tiene su propio Tecla PEDLa relación entre las claves PED y las funciones HSM merece ser comprendida con precisión:

• La Llave PED azul Almacena el secreto SO del HSM, que se utiliza para la administración a nivel de dispositivo, incluyendo la creación de particiones, los cambios en la política del HSM y las actualizaciones de firmware.
• La Llave PED negra Almacena el secreto de Partition SO, restringido a una partición específica. Partition SO controla las políticas de partición, el registro de CO y la pertenencia al dominio de clonación.
• La Llave PED gris Almacena el secreto CO, utilizado para la generación de claves, importación, exportación y operaciones criptográficas dentro de una partición.
• La Llave peatón naranja Almacena el vector Remote PED, utilizado para autenticar las sesiones Remote PED.
• La Llave PED morada La clave de dominio es un secreto compartido que determina qué HSM pueden clonar claves entre sí. Dos HSM solo pueden pertenecer al mismo grupo HA si comparten un dominio de clonación, lo que significa que se inicializaron con la misma clave Purple PED o que sus claves se migraron de forma segura entre ellos.

Autenticación de quórum (M de N) es una capacidad crítica para implementaciones de alta seguridad. En lugar de una única clave PED que otorga acceso, la HSM Se puede configurar para que M de N titulares de claves presenten sus claves PED antes de autorizar una operación sensible. El curso abarca cómo se configura M de N durante la inicialización, cómo se corresponden los procedimientos de custodia de conocimiento dividido con los requisitos de la Parte 2 de la norma NIST SP 800-57 y las implicaciones operativas de las diferentes proporciones M:N en los escenarios de recuperación.

PED remoto Extiende la autenticación PED a implementaciones distribuidas geográficamente. Una clave Orange PED autoriza un canal seguro fuera de banda entre el HSM y un servidor PED remoto (RPS), lo que permite operaciones PED sin presencia física en el dispositivo. La capacitación abarca la instalación del RPS, el proceso de establecimiento del canal autenticado y las implicaciones de seguridad del PED remoto en comparación con el PED local.

Modo de transporte seguro (STM) Este curso aborda la integridad de la cadena de suministro. Cuando un HSM se envía desde la fábrica o se transfiere entre custodios, STM garantiza que cualquier intento de manipulación durante el tránsito lo deje en un estado que requiere interacción autenticada con el PED para salir, y la credencial de salida de STM solo puede haber sido establecida por la parte de origen. El curso cubre cómo verificar el estado de STM y cómo realizar correctamente la transición de un HSM fuera del modo de transporte antes de su implementación.

Módulo 3: Arquitectura de particiones y separación de roles

Cómo la jerarquía SO/CO/CU y las políticas aplicadas mediante firmware proporcionan una arquitectura multiusuario con privilegios mínimos que se corresponde directamente con PCI DSS 3.7.

Comprender el modelo multiusuario del HSM

Un dispositivo Luna Network HSM 7 se presenta a los clientes conectados como uno o más puntajesCada partición es un contenedor criptográfico lógicamente aislado con su propio almacén de claves, conjunto de políticas y control de acceso. Las particiones son la unidad fundamental de la arquitectura multiusuario en los HSM de Luna.

Cada partición tiene una jerarquía de roles independiente:

Oficial de seguridad HSM (nivel de dispositivo) └── Oficial de seguridad de partición (nivel de partición) ├── Oficial criptográfico (gestión de claves dentro de la partición) └── Usuario criptográfico (solo operaciones criptográficas, sin gestión de claves)

La separación SO/CO/CU impone el principio de mínimo privilegio en la capa de operaciones criptográficas. Un proceso que realiza operaciones TLS como usuario criptográfico no puede generar nuevas claves, no puede exportar material de clave y no puede modificar las políticas de partición, incluso si se ve comprometido. Este modelo de rol se corresponde directamente con PCI DSS Requisitos de control dual y conocimiento dividido para la gestión de claves criptográficas, según lo estipulado en el requisito 3.7.

Políticas de partición Controlan qué operaciones están permitidas dentro de una partición y son aplicadas por el firmware del HSM, no por el software del host. Los atributos clave de la política incluyen:

• Algoritmos de clave y tamaños de clave permitidos
• Si las claves son extraíbles (para copias de seguridad/restauración mediante clonación) o no extraíbles (vinculadas permanentemente al HSM).
• Si las claves están marcadas como confidenciales (bloqueando la exportación de texto plano incluso por roles autorizados).
• Persistencia de objetos de sesión frente a persistencia de objetos de token
• Activación frente a activación automática para la credencial CO

Activación automática Es un concepto operativo importante. Cuando está habilitado, el PIN CO se almacena en la memoria HSM con respaldo de batería, lo que permite que el HSM sobreviva a un reinicio sin necesidad de que un humano vuelva a presentar la clave PED antes de que se reanuden las operaciones criptográficas. Esto es esencial para entornos de servidores desatendidos. La capacitación abarca las ventajas y desventajas de seguridad de la activación automática en comparación con las configuraciones que requieren activación manual.

Módulo 4: NTLS frente a STC: Elección del canal de cliente adecuado

La verdadera diferencia criptográfica entre los dos canales de cliente de Luna y por qué elegir la opción incorrecta abre una brecha entre el límite FIPS y la postura de seguridad real.

La diferencia técnica entre los dos modelos de conectividad de clientes de Luna

Este es uno de los aspectos más frecuentemente malinterpretados del despliegue de Luna 7. El curso cubre ambos modelos en profundidad, lo cual es fundamental porque elegir el incorrecto para su modelo de amenazas puede crear una brecha significativa entre su HSM. FIP límite de validación y su postura de seguridad operativa real.

NTLS (Servicio de enlace de confianza de red) Establece un canal TLS 1.2 entre el software Luna Client en el host y el dispositivo HSM. El canal se autentica mutuamente mediante un protocolo de enlace basado en certificados: el cliente presenta su certificado (registrado con el dispositivo durante el proceso de registro del cliente) y el dispositivo presenta su certificado (añadido al almacén de certificados del servidor del cliente). Ambas partes verifican el certificado de la otra con su almacén de confianza local antes de que se establezca la sesión TLS.

NTLS utiliza el puerto 1792 por defecto. El intercambio de certificados durante el registro del cliente es un proceso manual: el cliente exporta su certificado (client export), el administrador del aparato lo registra (client register), y la partición se asigna al cliente (client assignPartition). El curso cubre este flujo de trabajo, incluidos los modos de falla comunes, la expiración del certificado, la discrepancia de CN y los errores de asignación de particiones, que dan como resultado CKR_DEVICE_ERROR devuelve de las aplicaciones PKCS#11.

STC (Canal seguro de confianza) STC es el sucesor de NTLS y el canal preferido para implementaciones compatibles con FIPS. STC proporciona un canal criptográficamente más seguro con protecciones adicionales que NTLS no ofrece:

• Autenticacion mutua Utilizando claves de identidad generadas por el HSM, no certificados a nivel de host.
• Integridad a nivel de mensaje en cada comando y respuesta PKCS#11, lo que evita la manipulación de las solicitudes criptográficas en tránsito.
• Protección de repetición mediante numeración secuencial
• Unión de canales que vincula la sesión STC a la partición específica, impidiendo que un canal comprometido sea redirigido a una partición diferente.

STC opera en el mismo puerto que NTLS (1792), pero utiliza una pila de protocolos completamente diferente. La identidad STC del cliente es generada por el HSM durante el registro del cliente y se almacena en su repositorio de tokens. Cuando un cliente STC se conecta, el establecimiento del canal implica un intercambio criptográfico de prueba de posesión; el cliente demuestra que posee la clave privada correspondiente a su identidad registrada sin transmitir dicha clave a través de la red.

La guía práctica de la capacitación recomienda usar STC en cualquier implementación donde el HSM se utilice para generar o almacenar claves de CA raíz, claves de firma de código u otro material confidencial. Use NTLS solo cuando la pila de aplicaciones no admita STC o cuando el costo de integración sea prohibitivo. El curso aborda las limitaciones de compatibilidad; algunas versiones del SDK de Luna y los adaptadores PKCS#11 de terceros aún no admiten STC.

Módulo 5: Alta disponibilidad, configuración, quórum y modos de fallo

¿Qué sucede cuando un miembro abandona el programa, por qué la recuperación no es automática y en qué punto la llave Purple PED se convierte en una dependencia humana en tu manual de operaciones?

¿Qué sucede realmente cuando un miembro de un grupo de alta disponibilidad se desconecta?

La implementación de alta disponibilidad (HA) de Luna 7 se realiza mediante software: el software Luna Client gestiona un grupo HA, distribuyendo las operaciones criptográficas entre un conjunto de módulos de seguridad de hardware (HSM) que comparten un dominio de clonación. Desde la perspectiva de la aplicación, el grupo HA aparece como una única ranura PKCS#11. El cliente gestiona el equilibrio de carga y la conmutación por error de forma transparente.

Requisitos del grupo HATodos los HSM de un grupo deben compartir el mismo dominio de clonación (establecido durante la inicialización mediante la clave Purple PED). Las claves creadas en el grupo HA se sincronizan y clonan automáticamente en todos los miembros del grupo antes de que la operación que creó la clave devuelva una respuesta exitosa a la aplicación que la invocó. Esta clonación síncrona es lo que garantiza la consistencia del grupo HA: una clave solo es visible para la aplicación una vez que existe en todos los miembros activos.

Modo de recuperación de HA Es donde ocurren la mayoría de los problemas operativos. Cuando un miembro del HSM se desconecta del grupo HA (fallo de red, fallo de hardware o reinicio), los miembros restantes continúan realizando operaciones criptográficas. El miembro que falló entra en modo de recuperación. Cuando vuelve a estar en línea, no se reincorpora automáticamente, el lado del cliente haAdmin Se debe utilizar una utilidad para resincronizar el material clave de un miembro activo con el miembro en recuperación antes de que se vuelva a agregar al grupo.

La sincronización de claves durante la recuperación utiliza el mecanismo de clonación, que requiere que la clave secreta del dominio de clonación (clave Purple PED) esté disponible. En implementaciones con activación automática habilitada y un procedimiento de recuperación bien configurado, este proceso está en gran medida automatizado. En implementaciones donde la clave Purple PED se almacena en una bóveda física y requiere acceso de custodia por parte de dos personas, la recuperación de un miembro de alta disponibilidad puede requerir la intervención humana, una dependencia operativa real que debe estar contemplada en el manual de procedimientos.

Balanceo de carga En un grupo HA, las operaciones se distribuyen de forma rotativa entre los miembros activos por defecto. La configuración del cliente Luna admite opciones de balanceo de carga ponderado y de sesión persistente para aplicaciones donde el estado de la sesión es importante. La capacitación cubre haAdmin comandos para inspeccionar el estado del grupo, el estado de salud de los miembros y el estado de sincronización.

Migración de claves La migración entre particiones o entre HSM que utilizan diferentes dominios de clonación (por ejemplo, migrar de un HSM de prueba a un HSM de producción que se inicializó por separado) requiere encapsular el material de clave bajo una clave de cifrado de clave (KEK) y volver a importarlo. La capacitación cubre la cmu y el clonetool utilidades para este flujo de trabajo y los mecanismos de cifrado de claves compatibles con FIPS que admite Luna 7.

Módulo 6: Registro de auditoría, qué se registra y cómo verificarlo.

El registro criptográficamente encadenado y a prueba de manipulaciones que respalda los requisitos 10 y 3.7 de PCI DSS y la función de auditoría que impide a los administradores ocultar sus huellas.

Estructura del registro de auditoría de HSM y evidencia de manipulación

El subsistema de registro de auditoría de Luna 7 genera registros de registro encadenados criptográficamente. Cada entrada de registro está firmada por el HSM e incluye un hash de la entrada anterior, creando una cadena a prueba de manipulaciones: modificar o eliminar cualquier entrada de registro rompe la cadena, lo que puede detectarse durante la verificación de los registros.

El rol de Auditor es un puesto dedicado HSM Este rol está específicamente diseñado para la gestión de registros. Su diseño es intencional: el usuario Auditor puede leer y exportar registros, pero no puede realizar operaciones criptográficas ni modificar la configuración del HSM. Por el contrario, los roles SO y CO no pueden acceder al registro de auditoría ni borrarlo. Esta separación garantiza que un administrador no pueda ocultar sus huellas eliminando entradas del registro.

Captura de entradas de registro:

• Inicios y cierres de sesión de roles: marca de tiempo, rol, éxito/fracaso, ID de sesión
• Eventos clave del ciclo de vida: creación, eliminación, importación, exportación, con el identificador de clave, tipo de clave, algoritmo y tamaño de clave.
• Operaciones criptográficas: tipo de operación (firmar, verificar, cifrar, descifrar, envolver, desenvolver), mecanismo (por ejemplo, CKM_RSA_PKCS, CKM_AES_CBC), manija de llave
• Cambios necesarios en la pólizas¿Qué política se modificó? Valor anterior, valor nuevo, rol que realizó el cambio.
• Eventos de manipulación: detección de manipulación física, eventos de borrado, intentos de autenticación fallidos

Para el cumplimiento de PCI DSS, el registro de auditoría proporciona el rastro de evidencia requerido por el Requisito 10 (registrar todo el acceso a las claves criptográficas) y el Requisito 3.7 (registrar todos los eventos del ciclo de vida de la clave). La capacitación cubre cómo exportar registros usando audit exportcómo verificar la integridad de los registros mediante la función de auditoría y cómo enviar los registros de auditoría de Luna a un SIEM para una monitorización centralizada.

Códigos de estado de los electrodomésticosEn este mismo módulo se describe el mecanismo de informes de estado del dispositivo Luna. Los códigos de estado se corresponden con condiciones específicas de hardware, firmware y funcionamiento. El curso abarca los códigos más importantes desde el punto de vista operativo, incluidos los que indican fallos en la batería (fundamentales para el material clave en particiones no persistentes), problemas de memoria y errores en la interfaz de red.

Módulo 7: SDK, API e integración avanzada

La asignación de ranuras PKCS#11, la configuración del proveedor JCA/JCE, los módulos de funcionalidad, SKS/PKA y REST son los detalles de integración que provocan la mayoría de los fallos en las aplicaciones.

Asignación de ranuras PKCS#11, JCA/JCE, módulos de funcionalidad y REST

PKCS # 11 es la interfaz principal a través de la cual las aplicaciones interactúan con Luna 7. El cliente Luna instala una biblioteca de proveedor PKCS#11 (libCryptoki2_64.so en Linux cryptoki.dll (en Windows) que asigna particiones HSM a ranuras PKCS#11. Cada partición aparece como una ranura; un grupo HA aparece como una única ranura virtual con los miembros físicos abstraídos.

Comprender el mapeo de ranuras es esencial para la integración de aplicaciones. slot list comando en el lunacm La utilidad muestra la configuración actual de las ranuras, incluyendo el índice de ranura, la etiqueta de partición, el número de serie de partición y la pertenencia al grupo HA. Las aplicaciones que codifican los números de ranura (en lugar de seleccionarlos por etiqueta de token) son vulnerables a los cambios en el HSM; la capacitación abarca ambos enfoques y cuándo es apropiado cada uno.

Mecanismos del SDK de Luna, los identificadores de algoritmos criptográficos utilizados en las llamadas PKCS#11, incluyen extensiones específicas de Luna más allá de la lista de mecanismos PKCS#11 estándar. Por ejemplo, CKM_LUNA_AES_CBC_PAD Además, existen ciertos mecanismos RSA con variantes de relleno específicas para Luna que permiten optimizar el rendimiento. El curso explica qué mecanismos cuentan con la certificación FIPS y cuáles solo están disponibles en modo no FIPS.

JCA/JCE La integración de (Arquitectura de criptografía de Java / Extensión de criptografía de Java) utiliza la LunaProvider como un proveedor JCE conectable. El proveedor asigna las llamadas a la API criptográfica de Java a operaciones PKCS#11 en el HSMLos patrones de integración comunes incluyen el uso de LunaProvider Como proveedor prioritario para la generación de claves, al tiempo que se permite que el proveedor JCE predeterminado gestione las operaciones con claves de software, la formación abarca la configuración de la prioridad del proveedor y el error común de la generación inadvertida de claves de software cuando la pila de proveedores está mal configurada.

Módulos de Funcionalidad (FM) Los módulos de funciones (FM) son módulos de código personalizados que se ejecutan dentro del entorno seguro del HSM. Permiten a las organizaciones implementar protocolos criptográficos personalizados, esquemas de derivación de claves o lógica de negocio que deben ejecutarse dentro del hardware, lo cual resulta útil para aplicaciones donde la operación criptográfica no puede expresarse como una llamada PKCS#11 estándar. La capacitación abarca la API de FM, el proceso de firma y carga, y los requisitos de revisión de seguridad para la implementación de FM.

Almacenamiento de claves escalable (SKS) y el Activación de clave privada (PKA) Aborda el desafío de gestionar un gran número de claves privadas en una sola partición. SKS permite que el almacenamiento de claves se escale más allá de la capacidad de memoria flash integrada del HSM mediante almacenamiento externo cifrado, manteniendo el HSM la clave de envoltura. PKA añade un paso de activación al flujo de trabajo de uso de claves, requiriendo una operación de desbloqueo explícita antes de que se pueda utilizar una clave, lo que permite el acceso a claves con restricciones de tiempo o condiciones sin modificar el material de la clave.

Las API REST y la puerta de enlace de conexión a la nube (CCC) Este módulo incorpora la funcionalidad de Luna HSM a aplicaciones nativas de la nube y en contenedores que no pueden utilizar el modelo de biblioteca PKCS#11 tradicional. El CCC expone una interfaz REST que actúa como proxy para la capa PKCS#11, lo que permite realizar operaciones de claves con respaldo HSM desde cualquier cliente HTTP. La capacitación abarca la implementación del CCC, la autenticación en el punto final REST y la correspondencia entre las operaciones REST y las llamadas PKCS#11 subyacentes.

Módulo 8: Certificación y créditos de formación profesional continua (CPE)

Al completar el curso y aprobar la evaluación final, se obtiene un Certificado de Finalización que incluye créditos de formación continua (CPE), válidos para las certificaciones CISSP, CISM y otras que requieren documentación de formación continua. El examen evalúa los siete módulos técnicos y está diseñado para validar la comprensión operativa, no solo la memorización de definiciones.

¿A quién va dirigido este curso?

La profundidad del módulo descrita anteriormente se corresponde con perfiles específicos de profesionales:

• Administradores de PKI que gestionan CA respaldadas por LunaLos módulos 2, 3, 5 y 6 tienen la máxima prioridad. Los procedimientos de custodia de PED Key, la separación de roles de partición, el flujo de trabajo de recuperación de HA y los requisitos del registro de auditoría son directamente operativos para cualquier persona responsable de una CA raíz o emisora ​​respaldada por Luna.
• Ingenieros de seguridad que integran aplicaciones con Luna a través de PKCS#11 o JCA/JCE.Los módulos 4 y 7 son fundamentales. La selección entre NTLS y STC, la asignación de ranuras, la configuración del proveedor y la compatibilidad de los mecanismos son los problemas que causan la mayoría de los fallos de integración.
• Ingenieros de operaciones de seguridad responsables de la supervisión y el cumplimiento de HSMEl módulo 6 es el punto de entrada, mientras que el módulo 3 es necesario para comprender el contexto sobre las funciones y su relación con los eventos auditables.
• Ingenieros que desarrollan programas de migración de PQCLa capacidad FM de Luna 7 y el flujo de trabajo de migración de claves (Módulo 5 y Módulo 7) son directamente relevantes. Las jerarquías de certificados híbridos que necesitan admitir operaciones RSA/ECDSA y ML-DSA/ML-KEM requerirán HSMCambios de nivel en las políticas de partición y, en algunos casos, en la implementación de FM para la compatibilidad con algoritmos que aún no están en el firmware estándar.

Inscríbase

La formación bajo demanda HCSE Luna 7 de Encryption Consulting está disponible en: formación.consultoríaencriptación.comLa inscripción incluye acceso durante 90 días a todos los módulos, guías de laboratorio y materiales de referencia. El programa completo del curso está disponible para su descarga antes de la inscripción.

Para equipos que requieran impartición dirigida por instructores, entornos de laboratorio personalizados o capacitación en Luna 7 combinada con implementaciones o migraciones activas de HSM, contacte con nosotros. [email protected].

Encryption Consulting es un líder mundial de confianza en criptografía aplicada, infraestructura de clave pública (PKI), gestión del ciclo de vida de certificados, implementación de módulos de seguridad de hardware (HSM) y preparación para la era post-cuántica. Cuenta con la confianza de más de 100 empresas de la lista Fortune 500. consultoríaencriptación.com