如何避免在 COBOL 程序中硬编码凭据？

Posted 2023-02-16

【中文标题】如何避免在 COBOL 程序中硬编码凭据？

【英文标题】：How to avoid hardcoding credentials inside a COBOL program?

【发布时间】：2018-05-13 15:15:53

【问题描述】：

我有以下代码连接到 COBOL 程序内的外部数据库：

MOVE 'I2SFG04'  TO WK-USER
MOVE '12345'    TO WK-PASS

EXEC SQL 
    CONNECT TO :WK-EXT-MACHINE 
    USER :WK-USER 
    USING :WK-PASS
END-EXEC.

但正如您猜到的，我不想硬编码用户并在 COBOL 程序中传递。那么是否有一种安全的方式来存储它们，以便有权查看 COBOL 程序的任何人都看不到凭据？

我的第一个方法是使用 SYSIN 内容创建一个文件（受 RACF 保护），这样 COBOL 程序可以加载它，但它不会显示在源代码中。像这样的：

//STEP001  EXEC PGM=IKJEFT01
//STEPLIB  DD DSN=I2SJR04.SYS.DBRMLIB,DISP=SHR
//SYSIN    DD DSN=EF35.PRIVATE.DB.LOGIN,DISP=SHR
//SYSOUT   DD SYSOUT=*
//SYSTSIN  DD *
    DSN SYSTEM(SSID)
    RUN PROGRAM(MYCOBB) PLAN(PLANNAME) -
    LIB('I2SJR04.SYS.LOADLIB')
    END
/*

EF35.PRIVATE.DB.LOGIN 文件的内容：

I2SFG04
12345

有没有更好的方法来处理这种情况？

【参考方案1】：

更复杂和安全的解决方案是编写一个简短的汇编程序，从安全系统（RACF、ACF2、Top Secret）本身获取用户和密码。

如果您将 IBM RACF 产品作为您的安全产品，下面是一个叙述： https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ichd100/pas-s-ret.htm

这种方法所做的是将是否允许获取密码的逻辑交给安全管理员而不是程序员。您可以向全世界展示您的源代码，但如果安全系统不授予对凭据的访问权限，那么用户可以看到什么并不重要。另外，这种类型的东西通常可以被审计，所以你可以很容易地获得每次引用用户/密码的完整列表。

【讨论】：

这是 DB2 的默认行为。不需要写任何东西。

原发帖人没有特别提到 DB2，只是 COBOL 连接到外部数据库，所以我给出了一个通用的答案，适用于任何类型的外部服务。

【参考方案2】：

如果是 IBM zOS 大型机，则无需提供任何凭据。

您的连接将使用正在运行的作业的用户 ID。

您只需要告诉您的 DBA 作业将使用什么 JCL 用户 ID run under - 然后他将授予对您正在使用的计划的访问权限。

【讨论】：

不错！您能否提供任何参考或文件？干杯！

【参考方案3】：

我能看到的唯一缺陷是，如果有人在哪里重新编码和重新编译程序以输出详细信息。

因此，也许您可​​以采取额外的步骤，使用受 RACF 保护的程序库来编译程序。

【参考方案4】：

我会尽力回答这个问题。我没有直接在 COBOL 中调用数据库。我们有一堆由另一个小组维护的服务器程序，但我确实做了一些挖掘工作。这就是我们使用 DB2 数据库的方式。我也不知道我们在幕后做什么，所以你的里程可能会有所不同。以下是我的理解：

我们有一个 JCL 来执行如下所示的程序：

//STEP01 EXEC PGM=PGM001                                    
//*                                                                     
//*------- DB2 Plan ------------------------*                           
//DSNPARMS DD DSN=XX.DBNAME.DBPLAN.JOBNAME,                               
//            DISP=(MOD,DELETE,DELETE),                                 
//            UNIT=SYSDA,                                               
//            SPACE=(TRK,(0))                                           
//*                       
//INPUT (input files for job)
//OUTPUT (output files for job)              

DSNPARMS 文件本身是空的，它用作占位符，其中包含调用数据所需的所有相关信息。文件名的结构是SystemResourceCode.DatabaseName.PlanName.JobName

根据我的理解（对于 DB2 数据库），所需要做的就是相应地设置计划和集合，并将它们与 ACID 绑定。

所以基本上 ACID 与数据库集合相关联，该集合包含一组数据库计划。

数据库计划指向数据库包。简而言之，如果与您的 ACID 关联的集合中包含正确的计划，您应该能够在没有登录凭据的情况下访问数据库，因为 DBMS 知道基于 ACID 的所有计划都是您实际可以访问的。

这也意味着需要设置 TSS 访问权限，以便需要访问权限以运行具有该 ACID 的 JCL 的任何人都可以运行它。

我真的没有任何后端示例代码，但我希望这个解释足以让您在某个地方通过硬编码凭据。与数据库人员交谈并询问他们有关设置计划和集合的问题。他们或许可以从那里帮助您。

【讨论】：

不错！感谢您的解释。现在让我们假设我想将凭据用于不相关的数据库目的。您认为 SYSIN 方法是处理它的最佳方式吗？干杯！

这有点取决于你想做什么。如果您有其他问题，请附上详细信息（作为单独的问题），如果我能提供帮助，我会的！