Condiciones de uso
Q1. ¿Qué información se recopila durante el descubrimiento de activos?
Asset Discovery recopila información detallada sobre los dispositivos de su red, que incluye:
- Tipo de dispositivo y especificaciones de hardware (por ejemplo, CPU, memoria, espacio en disco).
- Detalles de la red, como las direcciones IP y MAC.
- Detalles del software instalado y del sistema operativo.
Puede configurar los datos que desea recopilar en función del alcance de sus escaneos. Más información sobre la configuración de los escaneos.
SEGUNDO TRIMESTRE. ¿Cómo recopila Asset Discovery los datos?
ADE utiliza un enfoque sin agentes y aprovecha protocolos como ICMP, ARP, NetBIOS, DNS, LDAP, TCP, SNMP, SSH/Telnet y WMI para descubrir y recopilar datos de los recursos.
- La detección basada en dominios utiliza ARP, DNS, LDAP y TCP para el análisis a nivel de dominio.
- La detección de rangos de IP emplea ICMP, SNMP, SSH y Telnet para escanear dispositivos dentro de rangos de IP específicos.
- Los escaneos detallados recuperan información detallada mediante SNMP, WMI, SSH/Telnet y otros métodos.
TERCER TRIMESTRE. ¿Qué protocolos se utilizan para el descubrimiento basado en dominios?
La detección basada en dominios se basa en ARP, DNS, LDAP, WinNT y TCP para localizar los recursos en los dominios especificados.
CUARTO TRIMESTRE. ¿Qué credenciales se necesitan para escanear?
ADE admite tres tipos de credenciales:
- Credenciales de dominio: para acceder a los recursos del dominio (nombre de usuario y contraseña).
- Credenciales de rango de IP: se utilizan para escaneos basados en SSH/Telnet (nombre de usuario, contraseña y contraseña de administrador opcional).
- Cadenas de comunidad SNMP: necesarias para los dispositivos compatibles con SNMP.
Q5. ¿Se requieren credenciales de administrador de dominio?
No, las credenciales de usuario de dominio normales son suficientes para la detección básica. Sin embargo, para obtener información más detallada, como las especificaciones del hardware, se requiere un usuario con privilegios de administrador local.
Q6. ¿Cómo se almacenan las credenciales?
Las credenciales se almacenan de forma segura mediante el cifrado AES de 128 bits en el registro de ChangeGear. Durante su uso, se cifran en la memoria con la estructura de datos del sistema .NET, Security y Secure String y se eliminan inmediatamente después de su uso.
Q7. ¿Cómo accede ADE a las credenciales almacenadas?
Durante un análisis, ADE recupera las credenciales del registro y las descifra. Según el protocolo, las credenciales se aplican de forma segura:
- Las credenciales SSH se transmiten a través de canales cifrados.
- Las cadenas de comunidad SNMP se transmiten en texto sin formato.
Q8. ¿Afectará ADE a mi red?
ADE está diseñado para minimizar el impacto en la red. Factores como el tamaño, la latencia y la capacidad de la red afectan al rendimiento. Programar los escaneos fuera del horario laboral o en oficinas remotas puede reducir los gastos generales.
Q9. ¿El ADE activará mi sistema de detección de intrusos (IDS)?
ADE no utiliza exploits activos ni paquetes «diseñados», por lo que es poco probable que active un IDS.
Q10. ¿Debo configurar SNMP en todos mis dispositivos?
No, la configuración de SNMP es opcional. Sin embargo, habilitarla permite clasificar mejor los dispositivos (por ejemplo, las impresoras) y recopilar información más detallada.
Q11. ¿Existen requisitos de red para ADE?
- Las máquinas Windows requieren que se ejecuten WMI y DCOM.
- Las máquinas Linux necesitan tener SSH (preferido) o Telnet habilitado, con autenticación basada en contraseña.
- El escáner también debe tener WMI y DCOM en ejecución y estar unido a un dominio.
What Luma can automate
In practice, Luma can automate or orchestrate anything an ESM platform can support, provided the fulfillment system(s) exposes the appropriate API, service interface, or MCP server. That includes request fulfillment, approvals, access workflows, onboarding and offboarding, asset and software provisioning, incident triage, knowledge-assisted resolution, service catalog interactions, status tracking, outbound notifications, and cross-functional workflows spanning ITSM, HR, ERP, CRM, and other enterprise systems.
- Run workflows natively in Luma when speed, consistency, or central governance is the priority OR existing workflows do not exist.
- Invoke an existing workflow in another vendor application when an external workflow engine already handles the process or the system of record such as a ITSM or CRM system has the workflow in its catalog.
- Use Luma as the intelligent front-end either way, handling conversation, triage, data collection, policy checks, status updates, approvals, and outbound communications.
Why common IT examples matter
Password reset and account unlock are useful examples not because they define the limits of Luma, but because they reveal what enterprise service automation really requires. Even these seemingly simple workflows can depend on where identity resides, which controls must be enforced, and how risk is managed.
The same pattern extends far beyond IT. Luma can front-end multi-step workflows across HR, finance, facilities, customer operations, and any domain where an organization needs guided interaction plus controlled execution.
System-of-record agnostic by design
Enterprise deployments are rarely homogeneous. The system of record may be a leading ITSM or ESM platform, a specialized identity product, a SaaS application, a legacy on-premise system, or a custom workflow engine. Luma is designed for this reality. It can execute natively where appropriate, or call existing automations in another application and still own the user experience end to end.
- Integrate through APIs, webhooks, and service interfaces when that is the best enterprise fit.
- Prefer MCP-based integration when available to simplify tool discovery, invocation, and governance
- Preserve the external platform as the system of record while Luma manages conversation, triage, workflow selection, notification, approval interactions, and follow-up communications.
Enterprise controls, policy enforcement, and responsible AI
Luma should not be positioned as a lightweight task chain or a happy-path automation utility. Enterprise service automation requires controls. Luma supports policy-aware execution so that automation can enforce required rules before action is taken, not after a mistake has already propagated. That includes conditional approvals, entitlement checks, segregation of duties, environment-specific logic, and audit-ready execution records.
- Protect sensitive information through role-based access controls, data minimization, and masking of personal or corporate data where it should not be exposed.
- Support responsible AI patterns so confidential enterprise content and personal data are not unnecessarily sent to an LLM or retained in logs.
- Provide human-in-the-loop handling for exceptions, approvals, and higher-risk actions where policy or compliance demands oversight.
- Maintain the operational discipline expected in enterprise environments, including traceability, status visibility, exception handling, and controlled escalation paths.
The business value
The result is a more scalable and more trustworthy service experience: users get fast, intelligent assistance; service teams reduce manual effort and ticket volume; and the enterprise retains the policy enforcement, compliance posture, and architectural flexibility required for real-world operations. Luma combines conversational intelligence with governed execution, making it suitable not just for simple automations, but for true enterprise service transformation.
