【问题标题】:Criteria for accessing R packages?访问 R 包的标准?
【发布时间】:2020-07-25 12:46:34
【问题描述】:

作为一名 IT 管理员,在批准将 R 包安装到我的环境中时,我应该使用什么标准?

目前,RStudio 用户(不专注于 IT)拥有下载和安装任何软件包的完全访问权限。我理解为什么这是个问题……但如果我限制访问现有软件包的自定义白名单,用户最终会要求新的软件包,我将无法评估该软件包是否合适。

【问题讨论】:

    标签: security package rstudio rstudio-server


    【解决方案1】:

    我没有特定于 R 的知识,但我想说,就像用户带入您的组织的任何软件一样,您应该包括一些“谱系和后代”的度量;即它是从哪里来的,它是否有良好的声誉。

    最终应该由请求该软件的用户来做后续工作,所以除了在请求表上,我会包括一些这样的问题,以促使人们自己进行尽职调查:

    • 软件包托管在哪里(您从哪里下载的)?
    • 它是一个被广泛使用和知名的包吗?
    • (可能不适用于 R:软件项目是否仍在维护,是否定期发布安全补丁。是否存在针对它的公开 CVE 漏洞?)
    • 如果您不确定上述内容,您是否打开了源代码以检查其是否符合其声称的功能?

    【讨论】:

      【解决方案2】:

      这取决于其他用户在什么环境中工作。您的普通用户是否可以访问生产服务器,或者他们是否在本地机器上进行开发?如果他们有生产访问权限并在那里进行开发,那么您可能会遇到与整体变更管理相关的更大问题。有关谁有权执行哪些操作的更多信息可以帮助我们给出更详细的答案。

      不过,一般来说,对生产中使用的任何软件包都有一个批准流程或文档是很好的;这样,如果您稍后遇到问题,您可以确定最后所做的更改(例如 plyr 和 dplyr 冲突破坏脚本)。

      审批流程可以这么简单:

      • 申请日期
      • 提出请求的个人姓名
      • 请求新包(名称和版本)
      • 新包的用途
      • 任何其他相关信息

      作为管理员,如果您信任用户,您可以简单地在请求上签名并安装软件包(或让他们安装)。要添加另一层安全性,您可以在签名之前搜索该包并确保它是合法的。

      您还可以采取将软件包下载限制到 CRAN 存储库的方式。它并不完美,但您依赖的是一个稍微更精心策划的列表。

      【讨论】:

        猜你喜欢
        • 2014-04-05
        • 2014-09-23
        • 2014-10-24
        • 1970-01-01
        • 2019-10-21
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2018-08-29
        相关资源
        最近更新 更多