Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Edición de los controles de origen del paquete
En Amazon CodeCatalyst, las versiones de los paquetes se pueden añadir a un repositorio de paquetes publicándolas directamente, retirándolas de un repositorio anterior o incorporándolas desde un repositorio público externo a través de una puerta de enlace. Si permites que las versiones de un paquete se añadan publicándolas directamente o ingiriéndolas desde repositorios públicos, estás expuesto a un ataque de sustitución de dependencias. Para obtener más información, consulte Ataques de sustitución de dependencias. Para protegerse de un ataque de sustitución de dependencias, configura los controles de origen del paquete en un repositorio para limitar la forma en que se pueden añadir las versiones de ese paquete al repositorio.
Deberías considerar la posibilidad de configurar los controles de origen de los paquetes para que las nuevas versiones de distintos paquetes procedan tanto de fuentes internas, como la publicación directa, como de fuentes externas, como los repositorios públicos. De forma predeterminada, los controles de origen de los paquetes se configuran en función de cómo se agrega la primera versión de un paquete al repositorio.
Configuración de control de origen del paquete
Con los controles de origen de los paquetes, puede configurar cómo se pueden añadir las versiones de los paquetes a un repositorio. Las siguientes listas incluyen la configuración y los valores de control de origen de los paquetes disponibles.
Publicación
Esta configuración configura si las versiones de los paquetes se pueden publicar directamente en el repositorio mediante administradores de paquetes o herramientas similares.
ALLOW: Las versiones de los paquetes se pueden publicar directamente.
BLOCK: Las versiones de los paquetes no se pueden publicar directamente.
Repositorios ascendentes
Esta configuración configura si las versiones de los paquetes pueden ingerirse desde repositorios públicos externos o conservarse desde repositorios originales cuando lo solicite un administrador de paquetes.
ALLOW: Se puede conservar cualquier versión del paquete en otros CodeCatalyst repositorios configurados como repositorios originales o bien se puede ingerir desde una fuente pública con una conexión externa.
BLOCK: Las versiones de los paquetes no se pueden conservar de otros CodeCatalyst repositorios configurados como repositorios ascendentes ni se pueden ingerir desde una fuente pública con una conexión externa.
Configuración de control de origen de paquetes predeterminada
Los controles de origen de los paquetes predeterminados se basarán en la forma en que se añada la primera versión de ese paquete al repositorio de paquetes.
Si un administrador de paquetes publica directamente la primera versión del paquete, la configuración será Publicar: ALLOW y Upstream:. BLOCK
Si la primera versión del paquete se ingiere desde una fuente pública, la configuración será Publicar: BLOCK y Upstream:. ALLOW
Escenarios comunes de control de acceso a paquetes
En esta sección se describen algunos escenarios comunes en los que se agrega una versión de paquete a un repositorio de CodeCatalyst paquetes. La configuración de control de origen del paquete se establece para los paquetes nuevos en función de cómo se añada la primera versión del paquete.
En los siguientes escenarios, un paquete interno se publica directamente desde un administrador de paquetes en su repositorio, como un paquete que usted mantiene. Un paquete externo es un paquete que existe en un repositorio público y que se puede introducir en tu repositorio a través de un repositorio de puerta de enlace en sentido ascendente.
Se publica una versión de paquete externo para un paquete interno existente
En este escenario, consideremos un paquete interno, packageA. Tu equipo publica la primera versión del paquete del paquete A en un CodeCatalyst repositorio de paquetes. Como esta es la primera versión del paquete, la configuración del control de origen del paquete se establece automáticamente en Publish: Allow and Upstream: Block. Una vez publicado el paquete en tu repositorio, se publica un paquete con el mismo nombre en un repositorio público que está conectado a tu repositorio de CodeCatalyst paquetes. Podría tratarse de un intento de ataque de sustitución de dependencias contra el paquete interno o podría ser una coincidencia. En cualquier caso, los controles de origen de los paquetes están configurados para bloquear la ingesta de la nueva versión externa y protegerse así de un posible ataque.
En la siguiente imagen, RePoA es el repositorio de CodeCatalyst paquetes con una conexión ascendente al repositorio. npm-public-registry-gateway
Su repositorio contiene las versiones 1.1 y 2.1 de packageA, pero la versión 3.0 está publicada en el repositorio público. Normalmente, RePoA ingiere la versión 3.0 después de que un administrador de paquetes solicite el paquete. Como la ingesta de paquetes está configurada como Bloquear, la versión 3.0 no se ingiere en su repositorio de CodeCatalyst paquetes y no está disponible para los administradores de paquetes conectados a él.
![Gráfico sencillo que muestra el bloqueo de una nueva versión de un paquete externo en un repositorio público.](images/packages/package-origin-controls-one.png)
Se publica una versión de paquete interno para un paquete externo existente
En este escenario, un paquete, el paquete B, existe externamente en un repositorio público que usted ha conectado a su repositorio. Cuando un administrador de paquetes conectado a su repositorio solicita el packageB, la versión del paquete se introduce en su repositorio desde el repositorio público. Como esta es la primera versión de paquete del paquete B que se agrega a su repositorio, los ajustes de origen del paquete están configurados como Publish: y Upstream: BLOCK. ALLOW Más adelante, intenta publicar una versión con el mismo nombre de paquete en el repositorio. Es posible que no conozcas el paquete público y estés intentando publicar un paquete no relacionado con el mismo nombre, que estés intentando publicar una versión parcheada o que estés intentando publicar directamente la versión exacta del paquete que ya existe externamente. CodeCatalyst rechaza la versión que está intentando publicar, pero puede anular el rechazo de forma explícita y publicar la versión, si es necesario.
En la imagen siguiente, RePoA es el repositorio de CodeCatalyst paquetes con una conexión ascendente al repositorio. npm-public-registry-gateway
El repositorio de paquetes contiene la versión 3.0 que ingirió del repositorio público. Desea publicar la versión 1.2 en su repositorio de paquetes. Normalmente, puede publicar la versión 1.2 en RePoA, pero como la publicación está configurada como Bloquear, la versión 1.2 no se puede publicar.
![Gráfico sencillo que muestra la publicación de paquetes bloqueada.](images/packages/package-origin-controls-two.png)
Publicar una versión parcheada de un paquete externo existente
En este escenario, un paquete, el paquete B, existe externamente en un repositorio público que usted ha conectado a su repositorio de paquetes. Cuando un administrador de paquetes conectado a su repositorio solicita el packageB, la versión del paquete se introduce en su repositorio desde el repositorio público. Como esta es la primera versión de paquete del paquete B que se agrega a su repositorio, los ajustes de origen del paquete están configurados como Publish: y Upstream: BLOCK. ALLOW Tu equipo decide publicar las versiones de los paquetes parcheados de este paquete en el repositorio. Para poder publicar las versiones de los paquetes directamente, tu equipo cambia la configuración del control de origen de los paquetes a Publish: ALLOW y Upstream:. BLOCK Las versiones de este paquete ahora se pueden publicar directamente en su repositorio e ingerir desde los repositorios públicos. Una vez que su equipo publique las versiones de los paquetes parcheados, su equipo revertirá la configuración de origen del paquete a Publicar: BLOCK y Upstream:. ALLOW
Edición de los controles de origen del paquete
Los controles de origen de los paquetes se configuran automáticamente en función de cómo se agrega la primera versión de un paquete al repositorio de paquetes. Para obtener más información, consulte Configuración de control de origen de paquetes predeterminada. Para añadir o editar los controles de origen de un paquete en un repositorio de CodeCatalyst paquetes, lleve a cabo los pasos del siguiente procedimiento.
Para añadir o editar los controles de origen de los paquetes
-
En el panel de navegación, elija Packages (Paquetes).
-
Elija el repositorio de paquetes que contiene el paquete que desea editar.
-
En la tabla Paquetes, busque y elija el paquete que desee editar.
-
En la página de resumen del paquete, selecciona Origin Controls.
-
En los controles de origen, selecciona los controles de origen del paquete que deseas configurar para este paquete. Los dos ajustes de control de origen del paquete, Publish y Upstream, deben configurarse al mismo tiempo.
-
Para permitir la publicación directa de las versiones de los paquetes, en Publicar, seleccione Permitir. Para bloquear la publicación de versiones de paquetes, seleccione Bloquear.
-
Para permitir la ingesta de paquetes de repositorios externos y la extracción de paquetes de repositorios anteriores, en Recursos ascendentes, seleccione Permitir. Para bloquear la ingestión y extracción de versiones de paquetes desde repositorios externos y ascendentes, seleccione Bloquear.
-
-
Seleccione Guardar.
Repositorios editoriales y originales
En CodeCatalyst, no puede publicar versiones de paquetes que estén presentes en repositorios ascendentes o repositorios públicos accesibles. Por ejemplo, supongamos que desea publicar un paquete npm en un repositorio y lodash@1.0
que myrepo
tiene un repositorio ascendente con una conexión externa a npmjs.com. myrepo
Considere los siguientes escenarios.
Los ajustes de control de origen de los paquetes
lodash
son Publish: y Upstream:. ALLOW ALLOW Silodash@1.0
está presente en el repositorio original o en npmjs.com, CodeCatalyst rechaza cualquier intento de publicación en élmyrepo
emitiendo un error de conflicto 409. Aún puede publicar una versión diferente, por ejemplolodash@1.1
.Los ajustes de control de origen de los paquetes
lodash
son Publish: y Upstream: ALLOW. BLOCK Puede publicar en su repositorio cualquier versión delodash
que aún no exista porque no se puede acceder a las versiones de los paquetes.Los ajustes de control de origen de los paquetes
lodash
son Publish: BLOCK y Upstream:. ALLOW No puede publicar ninguna versión del paquete directamente en su repositorio.
Ataques de sustitución de dependencias
Los gestores de paquetes simplifican el proceso de empaquetar y compartir código reutilizable. Estos paquetes pueden ser paquetes privados desarrollados por una organización para usarlos en sus aplicaciones, o pueden ser públicos, generalmente paquetes de código abierto que se desarrollan fuera de una organización y se distribuyen en repositorios de paquetes públicos. Al solicitar paquetes, los desarrolladores confían en su administrador de paquetes para obtener nuevas versiones de sus dependencias. Los ataques de sustitución de dependencias, también conocidos como ataques de confusión de dependencias, aprovechan el hecho de que un administrador de paquetes normalmente no tiene forma de distinguir las versiones legítimas de un paquete de las versiones maliciosas.
Los ataques de sustitución de dependencias pertenecen a un subconjunto de ataques conocidos como ataques a la cadena de suministro de software. Un ataque a la cadena de suministro de software es un ataque que aprovecha las vulnerabilidades en cualquier punto de la cadena de suministro de software.
Un ataque de sustitución de dependencias puede dirigirse a cualquier persona que utilice tanto paquetes desarrollados internamente como paquetes extraídos de repositorios públicos. Los atacantes identifican los nombres de los paquetes internos y, a continuación, colocan estratégicamente el código malicioso con el mismo nombre en los repositorios de paquetes públicos. Normalmente, el código malicioso se publica en un paquete con un número de versión alto. Los administradores de paquetes obtienen el código malicioso de estas fuentes públicas porque creen que los paquetes maliciosos son las últimas versiones del paquete. Esto provoca una «confusión» o una «sustitución» entre el paquete deseado y el paquete malicioso, lo que hace que el código quede comprometido.
Para evitar los ataques de sustitución de dependencias, Amazon CodeCatalyst proporciona controles de origen de los paquetes. Los controles de origen de los paquetes son ajustes que controlan cómo se pueden añadir los paquetes a tus repositorios. Los controles se configuran automáticamente cuando se añade la primera versión de un paquete nuevo a un CodeCatalyst repositorio. Los controles pueden garantizar que las versiones de los paquetes no puedan publicarse directamente en su repositorio ni ingerirse desde fuentes públicas, lo que le protege de los ataques de sustitución de dependencias. Para obtener más información sobre los controles de origen de los paquetes y cómo cambiarlos, consulte Edición de los controles de origen del paquete.