Seguridad e implementación

CoRoid realiza trabajos de ingeniería autónomos en tu código. Esta página detalla dónde se ejecuta ese trabajo, a qué puede acceder, cómo se protegen las credenciales y los datos, y qué registro deja. También describe los controles implementados actualmente. Los controles planificados se identifican como tales.

Dónde se ejecuta el trabajo de los agentes#

Cada tarea se ejecuta en su propio espacio de trabajo en la nube aislado. El espacio de trabajo se crea para esa tarea y se elimina después de finalizarla. Los agentes solo leen y escriben en el repositorio que se haya extraído en él.

Existen tres zonas:

El trabajo abandona el espacio de trabajo en una única forma: un pull request. Tu equipo decide si se fusiona y, a partir de ahí, tu propio proceso de despliegue lo gestiona. CoRoid no necesita ninguna extensión IDE, ni agente local, ni acceso a tu red privada.

A qué puede acceder un espacio de trabajo en Internet#

Un espacio de trabajo que compila y prueba tu código accede directamente a direcciones de Internet públicas, por lo que las instalaciones y descargas funcionan igual que en una máquina de desarrollador. Nunca accede a direcciones privadas: la red interna del clúster, el servicio de metadatos de la nube y las rangos privados están bloqueados para él.

Red de entornos aislados, bajo Seguridad → Configuración, y envía los espacios de trabajo de un ámbito a través del proxy de salida de CoRoid. Este modo está desactivado hasta que lo actives, ya sea como configuración predeterminada de la organización o para un proyecto concreto, en todos los planes:

• Activado (observar). Toda conexión pasa por el proxy, que registra el host y el puerto de la tarea, pero nunca la ruta ni el contenido. No se rechaza nada.
• Rechazar lo que no está permitido (aplicar), seleccionado en el panel de protección. El proxy permite el acceso a los registros de paquetes públicos (npm, PyPI, módulos Go, crates.io, RubyGems, Maven Central y Gradle, NuGet, Packagist, Hex, pub.dev, conda), al host de Git de tu proyecto y a los hosts incluidos en la lista de permitidos de la configuración. Rechaza todo lo demás. Si un comando falla tras un rechazo, se informa al agente qué host fue rechazado y por qué motivo.

El panel muestra dónde se conectaron los entornos aislados en los últimos 30 días: cada host y puerto, cuántas tareas y conexiones hubo, la tarea que accedió por última vez y si fue permitida, rechazada o lo sería bajo la modalidad 'aplicar' con la lista actual. Permitir añade un host a la lista. Comienza en modo 'observar': la lista muestra qué sería rechazado bajo la modalidad 'aplicar' antes de activarla.

El Red En la sección correspondiente, en su vista de Fábrica, se enumeran los destinos a los que llegaron sus espacios de trabajo, empezando por los rechazados. Un escaneo que CoRoid ejecuta por sí mismo (por ejemplo, un escaneo de seguridad) mantiene su espacio de trabajo en una tarea propia; dicha tarea indica qué tipo de escaneo fue y lista sus destinos de la misma manera.

En ambos modos, una conexión que omita el proxy, como una conexión TCP directa, fallará, y el proxy nunca se conectará a una dirección privada. Las herramientas detectan el proxy mediante las variables de proxy estándar que establece CoRoid; Maven solo lee su proxy desde settings.xml, por lo que una compilación de Maven no podrá acceder a Internet mientras la Red de entornos aislados esté activada. Las búsquedas de nombres siguen pasando por el resolutor del clúster. Los cambios se aplican a los espacios de trabajo creados después de realizarlos.

Cada entrada de la lista de permitidos es un host (api.example.com), sus subdominios (*.example.com), o bien ambos con un puerto (example.com:8443; sin puerto, se usan los puertos 80 y 443). Un proyecto con su propia configuración tiene su propia modalidad y lista; Usar the default lo devuelve a la configuración de la organización. La configuración viaja con portabilidad de la configuración, al igual que el resto de los ajustes de Seguridad.

Identidad y acceso#

La autenticación está centralizada en la puerta de enlace. Soporta:

• Sesiones de usuario basadas en JWT para acceso al portal
• Tokens de servicio a servicio con rotación gestionada
• Claves de API para integraciones externas
• Protecciones para puntos de acceso de usuario, servicio y acceso mixto

El acceso al repositorio está limitado al proyecto. Las credenciales de un proyecto no pueden ser utilizadas por otro proyecto, y CoRoid no necesita credenciales a nivel de organización para trabajar en un repositorio. Consulta Conecta tu código.

Los propietarios y administradores de la organización gestionan a los miembros, las sesiones y el feed de eventos de seguridad en Configuración → Identidad y acceso. SSO/SAML con aprovisionamiento SCIM forma parte de la edición Enterprise, disponible en vista previa privada.

Protección de datos#

• Los datos se cifran en tránsito y en reposo.
• Las credenciales de tu organización, como claves de proveedor, tokens de repositorio y otros secretos de integración, se cifran con una clave de datos propia de tu organización. Un servicio de gestión de claves cifra a su vez esa clave de datos. Solo el broker de credenciales de CoRoid puede descifrarlas y registra cada uso. Consulta Claves de proveedor.
• Los propios secretos de configuración de CoRoid se almacenan cifrados.
• El servicio en la nube pública ofrece un perfil de alojamiento en la UE para equipos con requisitos de GDPR o de residencia de datos. El Solo UE El perfil de AI mantiene la inferencia del modelo con proveedores alojados en la UE. Consulte Perfiles de AI.
• Usted controla cuánto tiempo se conservan el historial de ejecución, las transcripciones y los artefactos. Consulte Retención de datos.

El historial de decisiones#

Cada cambio autónomo se explica en términos que los revisores y los equipos de seguridad ya utilizan:

• la especificación, la actividad del agente, la revisión y la decisión de aprobación permanecen vinculadas a la tarea
• El historial de ejecución registra cada ejecución del agente, incluidos los intentos fallidos y los motivos de los mismos.
• El historial de solicitudes de fusión muestra la evidencia final antes de fusionar el código.
• La evidencia de seguridad, dependencias, cobertura, visualización, pruebas end-to-end y de navegador se puede adjuntar a una revisión. Consulte Evidencia de revisión.

Las puertas de fusión mantienen los cambios en producción bajo políticas explícitas. Nada se fusiona sin la aprobación de sus puertas de calidad lo requieran.

Operaciones de producción#

• Generación de SBOM y escaneo de imágenes de contenedores en CI
• Puntos de acceso públicos exclusivamente HTTPS con terminación TLS
• Instantáneas automatizadas de base de datos y runbooks de restauración
• Supervisión y alertas sobre métricas, registros y errores

Opciones de despliegue#

CoRoid opera bajo tres modelos operativos. El flujo de trabajo es el mismo en todos ellos; lo que varía es dónde residen el tiempo de ejecución, el almacenamiento, el acceso al repositorio y las credenciales.

En las instalaciones#

Los despliegues en las instalaciones permiten a los equipos regulados mantener el acceso al repositorio, el almacenamiento, las credenciales y las políticas de red dentro de la infraestructura que ellos gestionan.

• Docker Compose resulta ideal para instalaciones en un único servidor y pilotos. Los volúmenes persistentes almacenan la base de datos, los repositorios y los registros.
• Kubernetes es adecuado para instalaciones en varios servidores y escalables automáticamente. Helm gestiona los servicios de aplicación, trabajadores, sincronización y ejecución, y funciona con PostgreSQL gestionado o autoalojado y almacenamiento de objetos.
• Redes restringidas puede utilizar estrategias de modelo y dependencias offline, gestión de secretos autoalojada y TLS interno.

El acceso a Git utiliza tokens de acceso personal en lugar de la instalación de una aplicación de terceros y puede apuntar a hosts de repositorio internos.

Certificaciones#

CoRoid no cuenta actualmente con un informe SOC 2 ni otra certificación de seguridad de terceros. El cumplimiento de SOC 2 es un objetivo de preparación. No describiremos un control como certificado hasta que lo esté.

Relacionado#

• Seguridad: encontrar y corregir vulnerabilidades en su propio código y dependencias
• Retención de datos
• Claves de proveedor
• Planes y precios
• Evidencia de revisión