3  Buenas prácticas de seguridad en el desarrollo de paquetes

Este es un capítulo en construcción que incluye consejos sobre la gestión de información confidencial en los paquetes y enlaces a lecturas adicionales.

3.1 Miscelaneos

Recomendamos el artículo Ten quick tips for staying safe online (Diez consejos rápidos sobre seguridad en Internet) de Danielle Smalls y Greg Wilson.

3.2 Seguridad al acceder a GitHub

  • Te recomendamos proteger tu cuenta de GitHub con autenticación de dos factores (2FA). Esto es obligatorio para miembros de la organización ropensci en GitHub y quienes colaboren de manera externa, así que asegúrate de habilitarla antes de que se apruebe tu paquete.

  • También te recomendamos que compruebes regularmente quién tiene acceso al repositorio de tu paquete, y que elimines cualquier acceso no utilizado (como el de personas que hayan dejado de colaborar).

3.3 https

  • Si el servicio web al que se conecta tu paquete tiene opciones de https y http, usa https.

3.4 Credenciales usadas en paquetes

Esta sección incluye consejos para cuando desarrolles un paquete que interactúa con un recurso web que requiere credenciales (claves API, tokens, etc.). Consulta también la viñeta de httr sobre compartir credenciales.

3.4.1 Credenciales de quien usa el paquete

Supongamos que tu paquete necesita una clave para hacer consultas a una API en nombre de quien usa el paquete.

  • En la documentación de tu paquete, brinda consejos para que la clave de la API no se almacene en el archivo .Rhistory o en los scripts.

    • Fomenta el uso de variables de entorno para almacenar la clave de la API (o incluso elimina la posibilidad de pasarla como argumento a las funciones). Puedes mencionar esta introducción a los archivos de arranque y la función usethis::edit_r_environ().

    • Otra posibilidad es usar o fomentar el uso del paquete keyring para almacenar variables en los sistemas de almacenamiento de credenciales del sistema operativo (que son más seguros que guardarlas en el archivo .Renviron). Para esto tu paquete tendría una función para guardar la clave en el keyring y una para recuperarla; alternativamente quien use tu paquete podría escribir Sys.setenv(CLAVESUPERSECRETA = keyring::key_get("miservicio")) al principio de su script.

    • No imprimas la clave de la API en ningún mensaje, advertencia o error, ni siquiera en modo verboso.

  • La plantilla de issues en GitHub debe advertir de no compartir ninguna credencial. Si alguien comparte accidentalmente las credenciales en un issue, asegúrate de avisarle para que revoque la clave (es decir, pregúntale explícitamente si se ha dado cuenta de que ha compartido su clave).

3.4.2 Credenciales en paquetes y desarrollo

Durante el desarrollo del paquete tendrás que proteger tus credenciales igual que proteges las credenciales de quienes usan tu paquete, pero hay más cosas a considerar y tener en cuenta.

3.4.2.1 Credenciales y consultas guardadas en los tests

Si utilizas vcr o httptest en los test para almacenar las respuestas de la API en caché, tienes que asegurarte de que las consultas grabadas o fixtures no contengan credenciales. Consulta la guía de seguridad de vcr y la guía Redacting and Modifying Recorded Requests (Censurando y modificando consultas grabadas) de httptest e inspecciona tus consultas grabadas y fixtures antes de hacer un primer commit para asegurarte de que tienes la configuración correcta.

Como vcr es un paquete de rOpenSci, puedes hacer cualquier pregunta que tengas en el foro de rOpenSci.

3.4.2.2 Compartir credenciales con servicios de integración contínua

Si utilizas un servicio de integración continua (CI por sus siglas en inglés), es posible que necesites compartir credenciales con el mismo.

Puedes almacenar las claves de la API como variables de entorno o secretos consultando la documentación del servicio de CI.

Para más detalles y consejos sobre el flujo de trabajo, consulta al artículo de gargle Managing tokens securely (Gestionando claves de forma segura) y el capítulo de seguridad del libro HTTP testing in R.

Documenta los pasos que has seguido en CONTRIBUTING.md para que tú, o alguien en el futuro, pueda recordar cómo hacerlo la próxima vez.

3.4.2.3 Credenciales y colaboraciones

¿Qué pasa con los pull requests de contribuciones externas? En GitHub, por ejemplo, los “secretos” sólo están disponibles para las acciones de GitHub para los pull requests iniciados desde el propio repositorio, no desde el fork. Los test que utilicen tus credenciales fallarán a menos que utilices algún tipo de respuesta simulada/en caché, por lo que es posible que quieras omitirlos dependiendo del contexto. Por ejemplo, en tu cuenta CI podrías crear una variable de entorno llamada ESTE_SOY_YO y luego omitir los test en función de la presencia de esta variable. Obviamente, esto significa que los tests del PR por parte del servicio de CI no serán exhaustivos, por lo que tendrás que comprobar el PR localmente para ejecutar todos los tests.

Documenta el comportamiento de tu paquete frente a PRs externos en CONTRIBUTING.md por el bien de la gente que hace PRs y de la gente que los revisa (tú dentro de unas semanas, y otras personas que mantengan del paquete).

3.4.3 Credenciales y CRAN

En CRAN, omite las pruebas y los ejemplos que requieran credenciales utilizando skip_on_cran() y dontrun respectivamente.

También omite las viñetas que requieran credenciales.

3.5 Lecturas adicionales

Recursos útiles sobre seguridad: